13. November 2011

Server Migration

Heute stand wieder mal eine Server-Migration an. Die Weblins wurden vom Ein-Server-Testbetrieb zum aktuellen Produktiv-Cluster migriert. Das war meine bisher schönste Migration:

- Server installieren,
- Konfigurationsdaten anpassen,
- Daten migrieren,
- Integrationstests checken,
- DNS umschalten,
- fertig.

Zugegeben, langsam bekomme ich Übung. Angefangen hat alles mit einem Entwicklungsserver. Dann kam das erste Produktiv-System aus 2 Hetzner-Servern. Darauf folgte ziemlich schnell das erste echte Rechenzentrum aus 10 Servern, genannt: der Proton-Cluster. Der wurde dann ausgebaut bis zu 60 Hosts. Vor 2 Monaten habe ich alles auf einem Server installiert als Testbetrieb mit einem simulierten Cluster (genannt Delta). Zwischendurch gab es noch eine Installation des gesamten Systems auf einer VMware. Heute dann die bisher letzte Installation (genannt Atlas) auf mehreren Servern, die sich die ca. 8 Rollen teilen.

Weblin ist ein komplexes System. Viele Subsysteme, zusätzlich zur Website auch noch ein Client und das Instant Message-System. Trotzdem ist es gut handhabbar, läuft stabil und ist flexibel, wie die unterschiedlichen Setups zeigen. Wäre es nicht so gut in Schuss, dann hätte ich es nicht wieder zum Laufen bekommen.

An Weblin Client und Portal haben viele Leute gearbeitet. Bei denen möchte ich mich hier für mich und im Namen der User bedanken: Entwickler im T-Team und iTeam, Research-Team und Praktikanten, Operating und Code-Review, Design und Content, Partner-Integration und Community-Management. Und nicht zuletzt die, die in letzter Zeit mit Rat (=Consulting) und Tat (=Twincoding) geholfen haben.

Ein paar meiner "Learnings":
- Viele gut ausgeprägte Server-Rollen helfen dabei groß (und klein) zu skalieren.
- Konfiguration zentralisieren und das dann durchhalten, wenn viele Rollen und Subsysteme dazukommen.
- Konsequentes Durchziehen einer verteilten Architektur hilft, auch wenn es manchmal mehr Arbeit macht.
- Ausführliche Integrationstests helfen Konfigurationsprobleme aufzuspüren.
- Refactoring hält jung.
- Technische Lösungen nicht ausreizen. Immer noch eine Optimierung in petto haben.
- Ich kann programmieren, deshalb funktionieren für mich eigene Lösungen, z.B. beim Backup (scp, rsync, tar) und beim Setup (svn und Shellskripte). Und das ist auch gut so.

Jetzt sind wir richtig online.

Weblin is back.

Und das ist erst der Anfang.

_happy_migrating()

5. November 2011

Throttling Bandwidth with Linux Tools

As a semi-professional admin I do backups of production systems all the time. This means various "tar", "scp", "rsync" and even "lftp" operations depending on what is to be backup-ed.

The problem: Backup interferes with normal operation

Backup is running at the same time as the normal operation of the production system and the system is already quite busy. Copy and transfer tools take as many resources as they can get from CPU, DMA and network. This usually interferes with the normal server operations and can even bring down the server (thank you DMA).

The solution: Throttling

Many of the tools have a throttling option, which can limit the bandwidth in network transfers and file system operations.

scp:
  • Option -l limits the used bandwidth, specified in Kbit/s. 
  • Example for max 5 MByte/sec: scp -l 40000 myfile $user@$host:
rsync:
  • Option --bwlimit limits I/O bandwidth in KBytes per second. 
  • Example for max 5 MByte/sec: rsync --bwlimit 5000 myfile destfolder 
lftp:
  • Setting "net:limit-rate" limits transfer rate on data connection in bytes per second. 
  • Example for max. 5 MByte/sec: echo "set net:limit-rate 5000000; put myfile" | lftp -u $user,$password $host
Anything else, e.g. tar, use the cstream command:
  • cstream can limit throughput of pipes with option -t in bytes per second.
  • Example for max 5 MByte/sec: tar cf - myfolder | cstream -t -5000k > myfolder.tar
  • Use "-5000k" instead of "5000k" to never exceed the max. Otherwise cstream saves throughput it could not use for later, which may be more bursty.
happy_throttling()