Sebastian Kraus — 24.03.2010
Wie viele andere Unternehmen auch führen auch wir auf unseren Servern täglich Backups durch. Ab gewissen Datenmengen wird plötzlich die Nacht ganz schnell zu kurz, um alle Daten einzusammeln, zu komprimieren und auf einen Backup-Server zu schieben.
Grundsätzlich kennen viele Computerbenutzer das Wort "Datensicherung". Zumindest haben sie es schon mal gehört. Nur ein kleinerer Teil dieser Leute könnte auch sagen, ob die Datensicherung von gestern Nacht in Ihrem Unternehmen funktioniert hat.
Wir sichern derzeit die Nutzdaten von 7 Servern täglich auf einen Backup-Server. Dieser Backup-Server ist mit 100MBit/s an das Internet angebunden. Da tagsüber Backups nicht wirklich praktikabel sind, da die zu sichernden Server massive Performanceeinbußen verzeichnen würden, kann man nur nachts sichern, wenn die Leute die Dienste nicht oder nur stark eingeschränkt in Anspruch nehmen. Als brauchbar hat sich hier ein Zeitfenster von 02:00 bis ca 5:30 erwiesen. Das sind 3,5 Stunden. In dieser Zeit muss jeder Server seine eigenen Daten sammeln, komprimieren und verschicken. Da der Zielserver "nur" eine 100MBit/s-Anbindung hat, kann dieser maximal 12.5 MB pro Sekunde empfangen. Das ist allerdings der theoretische Maximalwert. Realistisch sind etwa 10.0 - 10.5 MB. Wenn man die Zeit dann noch auf 7 Server aufteilt, merkt man, dass die Nacht tatsächlich sehr kurz ist.
Ein Beispiel: Ein Server hat 64GB Webdaten. HTML-Dokumente, PHP-Scripte, Grafiken, Logdateien. Von allem ein wenig. Alleine diese Menge an Dateien benötigt unter optimalen Bedingungen 1 Stunde und 45 Minuten zur Datenübertragung. Nach dem zweiten Server wäre das Zeitfenster überschritten und die restlichen 5 Server können nicht mehr gesichert werden.
Man muss die Daten also vorher verkleinern. Glücklicherweise lassen sich Web-Dokumente sehr gut komprimieren. Mit gzip wird unser 64GB großer Tarball auf ca 11GB verkleinert. Der Nachteil: Das dauert auf einer Core i7 920-Maschine mit 8 CPUs ca. 45 Minuten. gzip verwendet zum Komprimieren nur eine CPU, die es aber voll auslastet. Die anderen 7 CPUs sehen dabei zu und langweilen sich.
Die Lösung: pigz. pigz lässt sich unter Ubuntu per apt-get installieren und ersetzt die Funktionalität von gzip. Die Parameter bleiben gleich mit einer Ausnahme: -p für die Anzahl parallel ausgeführter Threads, sprich: gleichzeitig verwendete CPUs.
Um das zu demonstrieren, werde ich einen 1GB großen MySQL-Dump zunächst klassisch mit gzip komprimieren, anschließend noch mal mit pigz unter Verwendung von 7 (der insgesamt 8 vorhandenen) CPU-Kernen. Hier das Ergebnis:
root@anubis /tmp/bench # ls -la
-rw-r--r-- 1 root root 1002M 2010-03-24 22:04 dump.sql
root@anubis /tmp/bench # date; gzip -c dump.sql > dump.gzip; date; pigz -p 7 -c dump.sql > dump.pigz; date
Wed Mar 24 22:05:34 CET 2010
Wed Mar 24 22:06:06 CET 2010
Wed Mar 24 22:06:17 CET 2010
root@anubis /tmp/bench # ls -la
-rw-r--r-- 1 root root 175M 2010-03-24 22:06 dump.gzip
-rw-r--r-- 1 root root 175M 2010-03-24 22:06 dump.pigz
-rw-r--r-- 1 root root 1002M 2010-03-24 22:04 dump.sql
Beide Befehle haben die 1GB große Datei auf 175MB komprimiert. gzip benötigte dazu 32 Sekunden, pigz nur 11. Gemessen wurden die Werte auf einer RAMdisk, sodass Festplattenlatenzen das Ergebnis nicht verfälschen. pigz bekommt also eine klare Empfehlung im Backup-Einsatz.