Image-Dateien virtueller Maschinen flink übers Netzwerk kopieren
Image-Dateien virtueller Maschinen sind groß, aber nicht unbedingt komplett mit Daten gefüllt. Will man sie auf einen anderen Rechner kopieren, kann man viel Zeit sparen, wenn man die richtige Methode wählt.
Unter Linux dürften allgemein die Programme »scp« und »rsync« bekannt sein, um Dateien von einem auf einen anderen Rechner zu übertragen. Im Rahmen unserer Virtualisierungslösung ArchivistaVM sowie der freien Version ArchivistaMini werden die Instanzen mit DRDB jeweils auf zwei Maschinen gespeichert. Die erste Maschine überträgt die Daten der ersten Platte auf die zweite Platte der zweiten Maschine, die zweite Maschine überträgt ihre Daten (erste Platte) auf den dritten Rechner (zweite Platte) und so weiter, bis der letzte Rechner des Clusters die Daten auf die erste Maschine in die zweite Platte überträgt.
Geht es darum, Instanzen innerhalb des Clusters von einem Knoten auf einen anderen Knoten zu übertragen, so können dabei beträchtliche Daten anfallen. Virtuelle Festplatten-Dateien in der Größenordnung mehrer hundert Gbyte sollen dabei möglichst effizient auf den gewünschten Zielrechner übertragen werden. Erschwerend hinzu kommt, dass diese Festplatten-Dateien meist im sogenannten Sparse-Format vorliegen, d.h. zu Beginn wird eine Datei erzeugt, die maximal z.B. 200 Gbyte groß werden kann, allerdings nehmen diese Images nur soviel Platz ein, wie es bereits Daten in der Instanz gibt. So gesehen kann eine Sparse-Datei mit 200 Gbyte angelegt werden, sie benötigt am Anfang aber nur 0 Bytes. Der Unterschied wird ersichtlich, wenn die Dateien mit ls -ls gelistet werden:
0 -rw-r--r-- 1 root root 214748364800 Nov 18 13:51 vm-230-disk-2.raw
12378804 -rw-r--r-- 1 root root 13128695808 Mar 23 2013 vm-230-disk.qcow2
29440368 -rw-r--r-- 1 root root 128849018880 Nov 3 12:38 vm-230-disk.raw
Die erste Zeile zeigt eine solche Datei. In der Datei sind 0 Bytes belegt, bei der zweiten Angabe wird die maximale Größe der Datei (hier 200 Gbyte) ausgeweisen. Beim zweiten Beispiel handelt es sich um eine Datei, die nicht mit dem Sparse-Format erstellt wurde und bei der dritten Datei sind ca. 29 GB belegt, die Datei kann jedoch bis zu 120 Gbyte Platz einnehmen.
Geht es darum, derartige Dateien von einem Rechner auf einen anderen Rechner zu verschieben, was bei der Migration von Maschine A auf B der Fall ist, so gilt es einige Besonderheiten zu beachten. Erstens eignet sich scp grundsätzlich nicht dafür, solche Dateien zu kopieren. Eine Sparse-Datei mit 0 Bytes und 200 Gbyte Maximalgrösse wird mit scp auf 200 Gbyte »aufgeblasen«. Auch rsync löst den Job nicht wirklich ideal, denn ohne die Option --sparse oder -S wird auf dem Zielrechner ebenfalls eine Datei mit 200 Gbyte erstellt. Vor allem aber lässt sich rsync beim Kopiervorgang viel Zeit. Sofern die Daten über eine 1 Gbit-Netzwerkkarte übertragen werden, können gut und gerne mehrere Stunden vergehen, bis die Daten den Zielrechner erreichen, auch wenn auf beiden Maschinen schnelle SSD-RAID-Verbünde (Durchsatz 800 MB/s) vorhanden sind. Sofern mit 1 Gbit-Netzwerkkarten gerarbeitet wird, lässt sich ja noch halbwegs erahnen, dass die Karte den Flaschenhals darstellt, da pro Sekunde ja maximal ca. 125 Mbyte übertragen werden können.
Bei 10 Gbit-Netzwerkkarten müsste dies anders aussehen, da hier pro Sekunde um die 1 Gbyte übertragen werden können. Dennoch konnte mit rsync, egal welche Dateien übertragen wurden, nicht mehr als ein Durchsatz von 200 MB/s erreicht werden. Die Fragestellung lautete daher, lässt sich dieser Prozess schneller gestalten und wenn ja, wie?
Ein Netzlaufwerk mit Samba oder NFS ist eine Alternative. NFS ist unter Linux viel unkomplizierter und in der Regel auch schneller und wird daher vorgezogen. Das Paket wird unter Debian mit apt-get install nfs-kernel-server installiert. Allfällig ist noch apt-get install rpcbind notwendig. Um nun von einem anderen Knoten mit NFS zugreifen zu können, ist die Datei /etc/exports anzulegen. Ein Eintrag kann wie folgt aussehen:
/var/lib/vz/images 10.0.1.126(ro,no_root_squash,async,no_subtree_check)
Nun kann vom betreffenden Rechner aus das Verzeichnis /var/lib/vz/images eingebunden werden, womit die Daten bequem mit cp -rp quelle ziel kopiert werden können. Die ersten Ergebnisse ließen aufhorchen, die großen Dateien konnten viel schneller kopiert werden. Nur die eingangs erwähnte Sparse-Datei mit 0 Bytes wollte irgendwie noch immer nicht so richtig.
Daher wurde der Versuch gestartet, die Daten direkt über das DRBD-Laufwerk zu lesen. Nun können diese Laufwerke ja nur gelesen werden, wenn der DRBD-Knoten den »primary«-Status hat. Dennoch kann der »secondary«-Knoten mit drbdadm down <Name des Devices> heruntergefahren werden. Dann spricht nichts mehr dagegen, das darunterliegende Device lesend zu öffnen. Angenommen, /dev/drbd1 liegt über der Partion /dev/sdb4, so kann mit mount -r -o noatime /dev/sdb4 /mnt/save der »secondary«-Knoten des DRBD-Verbundes auf dem Zielrechner lesend eingebunden werden, dies freilich natürlich nur, wenn der Knoten mit drbdadm down xy zuvor ausgeklinkt wurde.
Hier muss natürlich darauf hingewiesen werden, dass die DRBD-Methode nur möglich ist, wenn man den Cluster von vornherein mit DRBD konfiguriert hat, da eine nachträgliche Einrichtung von DRBD die Partition neu formatieren würde. Um schnell einmal beliebige Dateien zu kopieren, ist DRBD nicht nutzbar. Eine Anleitung zur Einrichtung von DRBD wurde im Rahmen des Workshops »Virtueller hochverfügbarer Linux-Server« veröffentlicht.
Interessanterweise lassen sich die Sparse-Dateien mit cp nun ohne jegliche Zeitverzögerung kopieren, genau dies gelingt bei NFS mit cp so nicht. Die nachfolgenden Zahlen geben einen Einblick, was mit zwei SSD-Platten, einer 10 Gbit-Karte und einem mITX-Board heute machbar ist, wobei immer auch das Zeitverhalten mit rsync mit angegeben ist.
