Ich muss vor Ort Hunderte Gigabyte große Backups von einigen Xen-VMs auf einem Speicher durchführen, der auf einem dedizierten Server im selben Netzwerk mit Gigabit-Verbindung verfügbar ist. Die Daten sind hauptsächlich MySQL-Daten – ich verwende Percona XtraDB Cluster –, die lokal auf den Servern mit Xtrabackup gesichert werden. Daher gehe ich davon aus, dass diese Daten hochgradig komprimierbar sein sollten.
Im Moment verwende ich Duplicity 0.6.08b mit Verschlüsselung mit Passphrase (ich verwende keine Schlüssel), da ich die mit Duplicity erstellten Backup-Volumes auch per Rsync auf einen externen Speicher übertrage. Der Komprimierungsgrad liegt derzeit bei 6 und die Volsize bei 250. Backups dauern länger als einen Tag, weshalb ich nach empfohlenen Duplicity-Einstellungen suche, die schnelle Backups auf den lokalen, im Netzwerk gemeinsam genutzten Speicher ermöglichen, ohne zu viel Speicherplatz zu beanspruchen.
Irgendeine Idee?
Antwort1
Sie sagen in einem Kommentar, dass Sie bei diesen Backups einen Durchsatz von etwa 50 MB/s sehen.
50 MB/s istIm Auftrag vonwas Sie für einen halbzufälligen Datenträgerdurchsatz mit einzelnen rotierenden Festplatten erwarten können (d. h. kein gespiegeltes oder gestreiftes RAID, um Lesevorgänge auf mehrere Festplatten zu verteilen und so den Durchsatz zu erhöhen). Beachten Sie, dass einige RAID-Konfigurationen sogar den Durchsatz im besten Fall effektiv auf den des langsamsten Laufwerks beschränken. Ja, viele Festplatten sind auf bis zu ~200 MB/s ausgelegt, aber denken Sie daran, dass diese Zahlen im besten Fall sequentielle Zugriffszahlen sind. 50 MB/s sind auch etwa 400 Mbit/s, was mit etwas Schummelei für IP-Overhead usw. 500-600 Mbit/s auf der Netzwerkleitung ergibt, sodass Sie die Gigabit-Verbindung zwar nicht nur damit überlasten, aber schon ziemlich nahe an den Bereich herankommen, in dem Kollisionen wahrscheinlich sind.
Sie geben keine Zahlen zur CPU-Auslastung an, während Backups ausgeführt werden, außer dass Sie „drei Hypervisoren mit jeweils einer Reihe von VMs haben, die mehr oder weniger ausgelastet sind“. Das Kopieren und Komprimieren von Daten ist jedoch nicht besonders CPU-intensiv, und wenn Sie während der Ausführung der Backups etwas CPU-Zeit übrig haben, sind Sie nicht CPU-gebunden.Die einzige Möglichkeit, diese Frage tatsächlich zu beantworten, besteht darin, herauszufinden, welcher Faktor den Durchsatz begrenztund konzentrieren Sie dann Ihre Bemühungen dort.
Meine Vermutungwäre, dass Sie I/O-gebunden sind, entweder beim Lesen oder Schreiben, und dass Siekönntenetzwerkgebunden sein. Sie sprechen von einem dedizierten Backup-Speicherserver mit einer Gigabit-Ethernet-Verbindung, sagen aber nichts über die Art dieser Verbindung. Ist die Netzwerkverbindung für Backups zwischen den physischen Hosts gemeinsam genutzt oder dediziert? (Ein separates physisches Netzwerk, das jeden der HVs mit dem Backup-Server verbindet, wäre akzeptabel, wenn immer nur eine VM oder HV Backup-Daten gleichzeitig überträgt.)
Wenn die physische Netzwerkverbindung zum Backup-Server mit dem übrigen Netzwerkverkehr geteilt wird, können Sie zu einer dedizierten Verbindungsarchitektur wechseln. Wie viel Nutzen Sie daraus ziehen, hängt stark davon ab, wo die Daten komprimiert werden und wie viele Kollisionen Sie derzeit wirklich sehen, aber wenn Sie dies und nichts anderes tun,könnteSie können den Netzwerkdurchsatz verdoppeln und so bei einer Netzwerkanbindung die Sicherungszeiten halbieren.
Wenn Sie beim Lesen und/oder Schreiben I/O-gebunden sind, kann der Wechsel zu einem gespiegelten oder gestreiften Setup, das die Verteilung der Festplatten-E/A auf mehrere Festplatten ermöglicht, den Durchsatz erhöhen; es würde den gesamten Festplattenbusdurchsatz erhöhen. Natürlich bringt das seine eigenen Nachteile mit sich. Je nachdem, wie viele Daten Sie gleichzeitig übertragen, kann das Hinzufügen weitererschnellFestplattencache zum Backup-Speicherserverkönntehilft auch, aber ich würde vermuten, dass, wenn Sie E/A-gebunden sind, dies auf der Leseseite der Fall ist, da die Schreibvorgänge wahrscheinlich mehr oder weniger sequentiell sind. In diesem Fall würde Ihnen das Hinzufügen eines Caches nicht viel helfen.
Sie könnten auch erwägen, entweder auf ein Dateisystem auf den VMs oder HVs und/oder auf dem Backup-Speicherserver umzusteigen, das die Daten beim Schreiben auf die Festplatte sofort komprimiert, oder eine solche Komprimierung zu aktivieren, wenn sie unterstützt wird. Dies kostet CPU-Zeit, erhöht aber dieWirksamFestplattendatentransferrate, da weniger Daten zu und von den physischen Platten verschoben werden müssen, um die gleiche Menge an gespeicherten Benutzerdaten zu erhalten. Ob dies in einer bestimmten Situation ein Nettogewinn wäre, ist im Grunde ein Glücksfall und muss von Fall zu Fall bewertet werden, aber es ist sicherlich eineWahrscheinlichkeitfür die Situation, in der Sie I/O-gebunden sind, insbesondere wenn die Daten von vornherein stark komprimierbar sind. Selbst wenn die Daten nur um 20 % komprimiert werden können (entspricht einem Komprimierungsverhältnis von 1,25:1 und ist beispielsweise bei Texten in natürlicher Sprache definitiv erreichbar; zum Vergleich: ZFS mit gzip-9-Komprimierung erreicht bei einer Stichprobe von Internet-Websites eine Komprimierung von 1,20:1),inklusive Bilder), ermöglichen dieselben Platterübertragungsraten von 50 MB/s plötzlich eine Nutzdatenübertragung von über 60 MB/s, vorausgesetzt, die Host-CPU kann mit der Komprimierung und Dekomprimierung Schritt halten.Beachten Sie, dass verschlüsselte Datenangeblichsehr schlecht zu komprimieren, da es zufälligem Rauschen ähneln sollte; Sie würden im Allgemeinen vor der Verschlüsselung komprimieren, wenn Sie die Daten verschlüsseln möchten, in diesem Fall nützt Ihnen eine Komprimierung auf Dateisystemebene auf der verschlüsselten Seite nichts.