Server-Umzug in schnell

So ein Server-Umzug ist immer eine langwierige Sache. Der @moellus weiss wovon ich Rede. Die letzten beiden Umzüge von einem dedizierten Root-Server bei Hetzner auf den anderen haben bei mir jedesmal Monate gedauert. Ich hatte alle Services direkt auf dem Host laufen: Webserver, Datenbanken, Mailserver, IMAP-Server etc.

Webserver sind ja relativ schnell rüberkopiert. Aber Mailserver sind immer ein bissl schmerzhaft. Gerade wenn man in diesem Schritt auch noch die Linux-Distribution wechselt, oder aufs nächste Major-Release der Software geht.

Beim (vor-)letzten Umzug habe ich mich daher entschieden die einzelnen Funktionen in eigene virtualle Maschinen (KVM guests) auszulagern. Zum einen um sie besser von einander zu trennen (ich teile mache der Maschinen mit anderen Leuten), zum anderen, um beim nächsten Umzug einfach nur die VMs kopieren zu müssen. Damit würde sich der Aufwand für den Umzug auf das Kopieren der VM daten und ein paar IP-Anpassungen beschränken.

Mein letzter Root-Server bei Hetzner hatte 8GB RAM und hostete zwei Webserver VMs, eine Datenbank VM, eine Mailserver VM und eine OpenVPN VM. Bei dieser Anzahl an Maschinen und einigen speicherhunrigen Java-Anwendungen kam es schon des öfteren zu Performance-Engpässen. Eine Maschine geht in den SWAP und verlangsamt dadurch für alle anderen die Filesystem-Zugriffe. Eine Lösung musste her. Da die Hardware-Preise ja rapide fallen, gibt es nun nach etwas mehr als einem Jahr bei Hetzner für den gleichen Monatspreis eine Maschine mit doppelt so viel RAM (16GB) und auch mehr Festplattenkapazität. 

Und die Leute von Hetzner sind ja wirklich unglaublich gut. Von der Bestellung des Servers bis zur Bereitstellung vergehen selbst am Wochenende keine 2 Stunden. Dann noch schnell ein kleines IPv4 Subnetz bestellt und schon kann der Umzug losgehen. Es war an der Zeit mein Konzept auf den Prüfstand zu stellen. Rahmenbedingung: die Downtime der einzelnen VMs sollte so kurz wie möglich sein. Da die VMs teilweise untereinander verbunden sind (Webserver -> Datenbank) musste ich auch am besten alle VMs gleichzeitig umziehen. Verbindungen vom alten zum neuen Server wären natürlich auch gegangen, aber dann hätte ich diverse Firewalls temp. umkonfigurieren müssen.

Erste Herausforderung: wie bekommt man die LVM Volumes auf die andere Maschine? LVM Volumes sind ja Blockdevices. Das heißt der Hypervisor (die eigentliche physische Maschine) kann die Daten auf dem Volume nicht selbst als Dateien lesen und effiziente Transfertools wie “rsync” versagen hier. Die Datenverbindung zwischen den beiden Hetzner Rechenzentren schien maximal 10MByte/s zuzulassen. Das Kopieren der bis zu 40GB großen LVM Volumes kann da schonmal eine Weile dauern.

Da sich die LVM Volumes während des Datentransfers natürlich nicht verändern dürfen (und auch danach möglichst nicht) hätte man die VMs eigentlich runterfahren müssen. Aber hier kommt ein Vorteil von LVM zum Einsatz: LVM Snapshots. Hierbei kann die VM weiterarbeiten, während von einer Read-Only Kopie (es handelt sich natürlich nicht um eine Kopie sondern um COW Voodoo) gelesen werden kann. Nach dem Transfer des großen Volumes, müssten dann nur noch die Änderungen aus dem Snapshot übertragen werden.

Hierfür gibt es glücklicherweise ein Tool von “mpalmer” namens lvmsync. Es überträgt die Snapshot-Informationen eines LVM Volumes auf wendet sie auf einer Remote-Maschine an. Kurz gesagt, soetwas wie rsync für LVM block devices. Das hat auch sehr geschmeidig funktioniert: LVM Snapshot anlegen, diesen per dd und netcat auf die neue Maschine blasen, VM runterfahren, mit lvmsync die Änderungen während des ersten Transfers auf die neue Maschine übertragen, fertig.

Die KVM guests selbst ließen sich mit libvirts “virsh” Kommando schnell als XML-Dateien exportieren. Auf dem neuen Host schnell importiert und noch den Namen des Bridge-Interfaces angepasst. Die LVM-Volumes hatte ich exakt genau so angelegt und benannt wie auf der alten Maschine, so daß hier keine Anpassungen notwendig waren.

Prompt booteten auch alle VMs sehr brav. Jetzt musste initial noch die Netwzwerk-Konfiguration geändert werden. Der neue Server hat ein neues IPv4-Subnetz bekommen. Damit bekamen auch alle VMs neue public IPs. Diese mussten in der Netzwerkkonfiguration selbst, in der /etc/hosts, den lokalen Firewalls, dem Mailserver (mynetworks) und der Datenbank (für die Berechtigungen) und den Webservern geändert werden. Hierbei half das gute alte Perl beim suchen und ersetzen.

Da ich auch mein eigener DNS Provider bin, konnte ich sämtliche DNS-Einträge selbst ändern. Der DNS-Server ist als erster Service auf den neuen Host umgezogen und wurde via Hetzner Robot als neuer Authoritive Name Server etabliert. Alle anderen DNS-Änderungen konnten dann sehr fix über entsprechende Zone-Transfers erledigt werden.

Alles in allem ging der Umzug diesmal extrem schnell. Am längsten musste ich auf das IP-Subnetz von Hetzner warten. Der eigentliche Umzug hat dann nicht einmal eine Nacht gedauert und alles lief wieder auf dem neuen Server. Ein paar kleine Nacharbeiten sind noch notwendig, da diverse Tools mit geänderten IP-Adressen so ihre Problemchen haben (SSH known_hosts, Puppet SSL certificates, iptables ). Aber ich bin mit dem Ergebnis sehr zufrieden. Hetzner bietet hier wirklich einen super Service. Die sind sehr schnell und ihrem Wiki finden sich eine Menge guter Tipps.

 

Autor: falko

a *nix nerd

Comments are closed.