Hallo, kürzlich stieß ich auf eine interessante Aufgabe, einen Speicher für die Sicherung einer großen Anzahl von Blockgeräten einzurichten.
Jede Woche führen wir ein Backup aller virtuellen Maschinen in unserer Cloud durch. Daher muss man in der Lage sein, Tausende von Sicherungen zu verwalten und dies so schnell und effektiv wie möglich zu tun.
Leider sind die Standardkonfigurationen RAID5, RAID6 in diesem Fall nicht geeignet, da der Wiederherstellungsprozess auf so großen Festplatten wie unseren quälend lange dauern würde und wahrscheinlich niemals abgeschlossen wird.
Schauen wir uns an, welche Alternativen es gibt:
— Analog zu RAID5, RAID6, aber mit einem konfigurierbaren Paritätslevel. Dabei wird das Backup nicht blockweise, sondern für jedes Objekt einzeln durchgeführt. Der einfachste Weg, Erasure Coding auszuprobieren, ist die Bereitstellung von .
— das ist derzeit noch nicht veröffentlichte Funktion von ZFS. Im Gegensatz zu RAIDZ hat DRAID einen verteilten Paritätsblock und nutzt bei der Wiederherstellung sofort alle Festplatten des Arrays, wodurch es besser mit Festplattenausfällen umgeht und schneller nach einem Ausfall wiederhergestellt wird.
Zur Verfügung steht ein Server Fujitsu Primergy RX300 S7 mit einem Prozessor Intel Xeon CPU E5-2650L 0 @ 1.80GHz, neun RAM-Riegel Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9), einem Festplattenschrank Supermicro SuperChassis 847E26-RJBOD1, verbunden über Dual LSI SAS2X36 Expander und 45 Festplatten Seagate ST6000NM0115-1YZ110 nach jeweils 6TB. Bevor wir eine Entscheidung treffen, müssen wir zunächst alles gründlich testen.
Zu diesem Zweck habe ich mich vorbereitet und verschiedene Konfigurationen getestet. Dafür verwendete ich minio, das als S3-Backend fungierte, und startete es in verschiedenen Modi mit unterschiedlichen Zielsetzungen.
Mainly wurde der minio-Fall in Erasure Coding vs. Software-RAID mit der gleichen Anzahl an Festplatten und Paritätsfestplatten getestet, also RAID6, RAIDZ2 und DRAID2.
Zur Information: Wenn Sie minio mit nur einem Ziel starten, läuft minio im S3-Gateway-Modus und gibt Ihr lokales Dateisystem als S3-Speicher aus. Wenn Sie minio jedoch mit mehreren Zielen starten, wird automatisch der Erasure-Coding-Modus aktiviert, der die Daten zwischen Ihren Zielen verteilt und Redundanz bietet.
Zur Information: Wenn Sie minio mit nur einem Ziel starten, funktioniert minio im S3-Gateway-Modus und gibt Ihr lokales Dateisystem als S3-Speicher aus. Wenn Sie jedoch minio mit mehreren Zielen starten, wird automatisch der Erasure Coding-Modus aktiviert, der die Daten auf Ihre Ziele verteilt und Redundanz bereitstellt.
Standardmäßig teilt minio die Ziele in Gruppen von 16 Festplatten auf, wobei jede Gruppe 2 Parity hat. Das bedeutet, dass gleichzeitig zwei Festplatten ausfallen können, ohne Datenverlust.
Für die Leistungstests habe ich 16 Festplatten mit jeweils 6 TB verwendet und kleine Objekte mit einer Größe von 1 MB darauf geschrieben. Dies beschreibt unsere zukünftige Last so genau wie möglich, da alle modernen Backup-Tools Daten in Blöcke von mehreren Megabyte aufteilen und sie auf diese Weise schreiben.
Für die Durchführung des Benchmarks wurde das Tool s3bench verwendet, das auf einem Remote-Server ausgeführt wird und minio zigtausende solcher Objekte in hunderten von Streams sendet. Anschließend versucht es auf dieselbe Weise, diese zurück anzufordern.
Die Ergebnisse des Benchmarks sind in der folgenden Tabelle aufgeführt:
Wie wir sehen, arbeitet minio im Modus des eigenen Erasure Coding deutlich schlechter beim Schreiben als minio, das auf einem Software-RAID6, RAIDZ2 und DRAID2 in derselben Konfiguration läuft.
Separat wurde ich minio auf ext4 vs XFS zu testen. Erstaunlicherweise stellte sich heraus, dass XFS für meine Art von Last deutlich langsamer war als ext4.
In der ersten Testserie zeigte Mdadm eine Überlegenheit gegenüber ZFS, doch später , dass die Leistung von ZFS durch die Installation der folgenden Optionen verbessert werden kann:
xattr=sa atime=off recordsize=1Mund danach waren die Tests mit ZFS deutlich besser.
Außerdem kann man feststellen, dass DRAID keinen nennenswerten Leistungsvorteil gegenüber RAIDZ bietet, theoretisch jedoch sicherer sein sollte.
In den letzten beiden Tests habe ich auch versucht, die Metadaten (special) und ZIL (log) auf ein Spiegel-SSD auszulagern. Die Auslagerung der Metadaten brachte jedoch keinen nennenswerten Geschwindigkeitsvorteil beim Schreiben, und bei der Auslagerung von ZIL kamen meine an ihre Grenzen mit 100% Auslastung, sodass ich diesen Test als gescheitert betrachte. Ich schließe nicht aus, dass, wenn ich schnellere SSDs gehabt hätte, dies meine Ergebnisse erheblich verbessert hätten, leider hatte ich diese jedoch nicht.
Schließlich habe ich beschlossen, beim DRAID zu bleiben, und trotz seines Beta-Status ist es die schnellste und effektivste Lösung für unsere Anforderungen.
Ich habe ein einfaches DRAID2 mit drei Gruppen und zwei verteilten Spares erstellt:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsGut, das Storage-System haben wir geklärt; jetzt geht es darum, womit wir das Backup machen. Hier möchte ich sofort von drei Lösungen sprechen, die ich ausprobieren konnte:
— ein Fork , spezialisierte Lösung für das Backup von Blockgeräten mit enger Integration in Ceph. Kann Diffs zwischen Snapshots erfassen und daraus inkrementelle Backups erstellen. Unterstützt eine große Anzahl von Speicher-Backends, einschließlich lokaler und S3-Optionen. Benötigt eine separate Datenbank zur Speicherung der Hash-Tabelle für die Deduplizierung. Nachteile: ist in Python geschrieben, hat ein wenig unresponsive CLI.
— ein Fork , seit langem ein bekanntes und bewährtes Werkzeug für die Datensicherung, kann Daten sichern und sie gut deduplizieren. Kann Backups sowohl lokal als auch auf einem entfernten Server über SCP speichern. Kann Blockgeräte sichern, wenn es mit dem Flag --special, Nachteile: Während der Erstellung eines Backups wird das Repository vollständig blockiert, daher wird empfohlen, für jede virtuelle Maschine ein separates Repository zu erstellen. Das ist grundsätzlich kein Problem, da sie sehr einfach erstellt werden können.
— ein aktiv entwickeltes Projekt, in Go geschrieben, ziemlich schnell und unterstützt eine große Anzahl von Speicher-Backends, darunter sowohl lokale Speicher als auch SCP, S3 und viele mehr. Besonders hervorzuheben ist, dass es einen speziell entwickelten für Restic gibt, der es ermöglicht, das Repository am schnellsten für den Remote-Einsatz zu exportieren. Von all den oben genannten hat mir dieses am besten gefallen. Kann von stdin sichern. Hat kaum nennenswerte Nachteile, hat aber einige Besonderheiten:
Erstens habe ich versucht, es im Modus eines gemeinsamen Repositories für alle virtuellen Maschinen (wie Benji) zu verwenden, und es funktionierte sogar recht gut, aber die Wiederherstellungsoperationen dauerten ziemlich lange, da Restic vor jeder Wiederherstellung versucht, die Metadaten aller Backups zu lesen. Dieses Problem ließ sich, wie bei Borg, leicht lösen, indem ich für jede virtuelle Maschine ein separates Repository erstellt habe. Dieser Ansatz erwies sich auch als sehr effektiv für das Management von Sicherungskopien. Abgeschottete Repositories können ein separates Passwort für den Zugriff auf die Daten haben und wir müssen uns keine Sorgen machen, dass das globale Repo irgendwie kaputtgehen kann. Neue Repositories können ebenso einfach erstellt werden wie beim Borg Backup.
In jedem Fall erfolgt die Deduplizierung nur im Hinblick auf die vorherige Version des Backups. Das vorherige Backup wird anhand des Pfades zum angegebenen Backup bestimmt, sodass, wenn Sie verschiedene Objekte aus stdin in ein gemeinsames Repository sichern, Sie die Option nicht vergessen sollten.
--stdin-filename, oder Sie müssen die Option jedes Mal ausdrücklich angeben.--parent.
Zweitens dauert die Wiederherstellung in stdout erheblich länger als die Wiederherstellung im Dateisystem aufgrund ihrer Parallelität. In Zukunft ist eine engere Unterstützung von Backups für Blockgeräte geplant.
Drittens wird momentan empfohlen, die , da die Version 0.9.6 einen Fehler mit der langen Wiederherstellung großer Dateien hat.
Um die Effizienz des Backups und die Geschwindigkeit des Schreibens/wiederherstellens aus dem Backup zu testen, habe ich ein separates Repository erstellt und versucht, ein kleines Image einer virtuellen Maschine (21 GB) zu sichern. Es wurden zwei Backups durchgeführt, ohne das Original zu verändern, wobei jedes der aufgeführten Verfahren verwendet wurde, um zu überprüfen, wie viel schneller/langsame deduplizierte Daten kopiert werden.
Wie wir feststellen können, hat Borg Backup den besten Effizienzgrad für das anfängliche Backup, verloren jedoch sowohl hinsichtlich der Schreib- als auch der Wiederherstellungsgeschwindigkeit.
Restic erwies sich als schneller als Benji Backup, benötigt jedoch länger, um in stdout wiederherzustellen, und kann, leider, noch nicht direkt in ein Blockgerät schreiben.
Nach Abwägung aller Vor- und Nachteile habe ich mich entschieden, bei restic c rest-server zu bleiben, als der benutzerfreundlichsten und vielversprechendsten Lösung für Backups.
In diesem Screencast können Sie sehen, wie die 10-Gigabit-Verbindung bei mehreren gleichzeitig laufenden Backup-Operationen vollständig ausgeschöpft wird. Es sei darauf hingewiesen, dass die Auslastung der Festplatten dabei nicht über 30 % steigt.
Mit der gefundenen Lösung bin ich mehr als zufrieden!
Quelle: habr.com
