Unsere türkischen Kunden baten uns, die Sicherung für ihr Rechenzentrum richtig zu konfigurieren. Wir führen ähnliche Projekte in Russland durch, aber hier ging es eher darum, herauszufinden, wie man das am besten macht.
Vorausgesetzt: Es gibt einen lokalen S3-Speicher, es gibt Veritas NetBackup, das neue erweiterte Funktionen zum Verschieben von Daten in den Objektspeicher erhalten hat, jetzt mit Unterstützung für Deduplizierung, und es gibt ein Problem mit dem freien Speicherplatz in diesem lokalen Speicher.
Aufgabe: Alles so zu gestalten, dass das Speichern von Sicherungskopien schnell und kostengünstig ist.
Tatsächlich bestand in S3 davor alles nur aus Dateien, und das waren komplette Abgüsse der kritischen Maschinen des Rechenzentrums. Das heißt, es ist nicht sehr optimiert, aber am Anfang hat alles funktioniert. Jetzt ist es an der Zeit, es herauszufinden und es richtig zu machen.
Das Bild zeigt, worauf wir gekommen sind:
Wie Sie sehen, wurde das erste Backup langsam durchgeführt (70 Mbit/s) und nachfolgende Backups derselben Systeme waren viel schneller.
Tatsächlich gibt es weiter unten etwas mehr Details zu den Funktionen, die es gibt.
Sicherungsprotokolle für diejenigen, die bereit sind, eine halbe Dump-Seite zu lesenVollständig mit erneutem Scan
18. Dezember 2018 12:09:43 – Info bpbkar (pid=4452) Beschleuniger hat 14883996160 Bytes von 14883994624 Bytes an den Server gesendet, Optimierung 0.0 %
18. Dezember 2018 12:10:07 – Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken (verwendeter Multithread-Stream) für (NBCC): gescannt: 14570817 KB, CR gesendet: 1760761 KB, CR gesendet über FC: 0 KB, Dedup: 87.9 %, Cache deaktiviert
Vollständiger
18. Dezember 2018 12:13:18 – Info bpbkar (pid=2864) Beschleuniger hat 181675008 Bytes von 14884060160 Bytes an den Server gesendet, Optimierung 98.8 %
18. Dezember 2018 12:13:40 Uhr – Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14569706 KB, CR gesendet: 45145 KB, CR gesendet über FC: 0 KB, Dedup: 99.7 %, Cache deaktiviert
Inkremental
18. Dezember 2018 12:15:32 – Info bpbkar (pid=792) Beschleuniger hat 9970688 Bytes von 14726108160 Bytes an den Server gesendet, Optimierung 99.9 %
18. Dezember 2018 12:15:53 Uhr – Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14383788 KB, CR gesendet: 15700 KB, CR gesendet über FC: 0 KB, Dedup: 99.9 %, Cache deaktiviert
Vollständiger
18. Dezember 2018 12:18:02 – Info bpbkar (pid=3496) Beschleuniger hat 171746816 Bytes von 14884093952 Bytes an den Server gesendet, Optimierung 98.8 %
18. Dezember 2018 12:18:24 Uhr – Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14569739 KB, CR gesendet: 34120 KB, CR gesendet über FC: 0 KB, Dedup: 99.8 %, Cache deaktiviert
Was ist das Problem
Kunden möchten so oft wie möglich Backups erstellen und diese möglichst kostengünstig aufbewahren. Es ist am besten, sie kostengünstig in Objektspeichern wie S3 zu speichern, da diese hinsichtlich der Servicekosten pro Megabyte am günstigsten sind und Sie ein Backup in angemessener Zeit zurücksetzen können. Wenn viele Backups vorhanden sind, ist dies nicht sehr günstig, da der größte Teil des Speichers durch Kopien derselben Daten belegt ist. Bei HaaS türkischer Kollegen kann die Speicherverdichtung um etwa 80-90 % erfolgen. Es ist klar, dass dies speziell auf ihre Besonderheiten zutrifft, aber ich würde definitiv mit mindestens 50 % Großvater rechnen.
Um das Problem zu lösen, bieten die wichtigsten Anbieter seit langem Gateways zu Amazon S3 an. Alle ihre Methoden sind mit lokalem S3 kompatibel, solange sie die Amazon-API unterstützen. Im türkischen Rechenzentrum wird ein Backup auf unserem S3 sowie im T-III „Compressor“ in Russland erstellt, da dieses Arbeitsschema für uns gut funktioniert hat.
Und unser S3 ist vollständig kompatibel mit den Backup-Methoden von Amazon S3. Das heißt, alle Backup-Tools, die diese Methoden unterstützen, ermöglichen es Ihnen, alles „out of the box“ auf einen solchen Speicher zu kopieren.
Veritas NetBackup hat die CloudCatalyst-Funktion hinzugefügt:
Das heißt, zwischen den Maschinen, die gesichert werden müssen, und dem Gateway befindet sich ein zwischengeschalteter Linux-Server, über den der Sicherungsverkehr von den SRK-Agenten läuft und im laufenden Betrieb dedupliziert wird, bevor er an S3 übertragen wird. Gab es früher 30 Backups von 20 GB mit Komprimierung, ist ihr Volumen jetzt (aufgrund der Ähnlichkeit der Maschinen) um 90 % kleiner geworden. Die Deduplizierungs-Engine wird genauso verwendet wie beim Speichern auf normalen Festplatten mit Netbackup.
Folgendes passiert vor dem Zwischenserver:
Wir haben es getestet und sind zu dem Schluss gekommen, dass dies bei der Implementierung in unseren Rechenzentren für uns und unsere Kunden Platz im S3-Speicher spart. Als Besitzer kommerzieller Rechenzentren rechnen wir natürlich nach dem belegten Volumen ab, aber es ist auch für uns immer noch sehr profitabel – weil wir anfangen, Geld an skalierbareren Stellen in der Software zu verdienen und nicht an der Miete von Hardware. Nun, und das ist eine Reduzierung der internen Kosten.
Protokolle228 Jobs (0 in der Warteschlange, 0 aktiv, 0 auf Wiederholung wartend, 0 angehalten, 0 unvollständig, 228 erledigt – 13 ausgewählt)
(Filter angewendet [13])
Job-ID-Typ Status Statusdetails Status Job-Richtlinie Jobplan Client Medienserver Startzeit verstrichene Zeit Endzeit Speichereinheit Versuchsvorgang Kilobyte Dateien Pfadname % abgeschlossen (geschätzt) Job-PID-Besitzer Kopie der übergeordneten Job-ID KB/Sek. Aktiv Aktive abgelaufene Robot Vault-Profilsitzung starten ID-Medien zum Auswerfen der Datenbewegung Off-Host-Typ Master-Priorität Deduplizierungsrate Transportbeschleuniger-Optimierungsinstanz oder Datenbank-Freigabehost
— 1358 Snapshot Fertig 0 VMware — NGNCloudADC NBCC 18. Dezember 2018 12:16:19 00:02:18 18. Dezember 2018 12:18:37 STU_DP_S3_****backup 1 100 % Root 1358 18. Dezember 2018 12 :16:27 00:02:10 Instant Recovery Disk Standard WIN-*********** 0
1360 Sicherung erledigt 0 VMware Full NGNCloudADC NBCC 18. Dezember 2018 12:16:48 00:01:39 18. Dezember 2018 12:18:27 STU_DP_S3_****backup 1 14,535,248 149654 100 % 23858 Root 1358 335,098 .18 2018. Dezember , 12 16:48:00 01:39:0 Instant Recovery Disk Standard WIN-*************** 99.8 99 % XNUMX %
1352 Snapshot erledigt 0 VMware – NGNCloudADC NBCC 18. Dezember 2018 12:14:04 00:02:01 18. Dezember 2018 12:16:05 STU_DP_S3_****backup 1 100 % Root 1352 18. Dezember 2018 12: 14:14 Uhr 00:01:51 Instant Recovery Disk Standard WIN-*********** 0
1354 Sicherung erledigt 0 VMware Inkrementell NGNCloudADC NBCC 18. Dezember 2018 12:14:34 00:01:21 18. Dezember 2018 12:15:55 STU_DP_S3_****backup 1 14,380,965 147 100 % 23617 Root 1352 500,817, 18 2018. Dezember , 12 14:34:00 01:21:0 Instant Recovery Disk Standard WIN-*************** 99.9 100 % XNUMX %
1347 Snapshot erledigt 0 VMware – NGNCloudADC NBCC 18. Dezember 2018 12:11:45 00:02:08 18. Dezember 2018 12:13:53 STU_DP_S3_****backup 1 100 % Root 1347 18. Dezember 2018 12: 11:45 Uhr 00:02:08 Instant Recovery Disk Standard WIN-*********** 0
1349 Sicherung erledigt 0 VMware Full NGNCloudADC NBCC 18. Dezember 2018 12:12:02 00:01:41 18. Dezember 2018 12:13:43 STU_DP_S3_****backup 1 14,535,215 149653 100 % 23508 Root 1347 316,319 .18 2018. Dezember , 12 12:02:00 01:41:0 Instant Recovery Disk Standard WIN-*************** 99.7 99 % XNUMX %
1341 Snapshot erledigt 0 VMware – NGNCloudADC NBCC 18. Dezember 2018 12:05:28 00:04:53 18. Dezember 2018 12:10:21 STU_DP_S3_****backup 1 100 % Root 1341 18. Dezember 2018 12: 05:28 Uhr 00:04:53 Instant Recovery Disk Standard WIN-*********** 0
1342 Sicherung erledigt 0 VMware Full_Rescan NGNCloudADC NBCC 18. Dezember 2018 12:05:47 00:04:24 18. Dezember 2018 12:10:11 STU_DP_S3_****backup 1 14,535,151 149653 100 % 22999 Root 1341 70,380 18 Dez 2018 12:05:47 00:04:24 Instant Recovery Disk Standard WIN-*********** 0 87.9 % 0 %
1339 Snapshot erledigt 150 VMware – NGNCloudADC NBCC 18. Dezember 2018 11:05:46 00:00:53 18. Dezember 2018 11:06:39 STU_DP_S3_****backup 1 100 % Root 1339 18. Dezember 2018 11: 05:46 00:00:53 Instant Recovery Disk Standard WIN-*********** 0
1327 Snapshot fertig 0 VMware – *******.********.cloud NBCC 17. Dez. 2018 12:54:42 05:51:38 17. Dez. 2018 6:46:20 STU_DP_S3_****backup 1 100 % Root 1327 17. Dezember 2018 12:54:42 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Sicherung abgeschlossen 0 VMware Full *******.********.cloud NBCC 17. Dezember 2018 12:55:10 05:29:21 17. Dezember 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100 % 12856 Root 1327 11,326 17. Dezember 2018 12:55:10 05:29:21 Instant Recovery Disk Standard WIN-*********** 0 87.9 % 0%
1136 Snapshot fertig 0 VMware – *******.********.cloud NBCC 14. Dez. 2018 4:48:22 04:05:16 14. Dez. 2018 8:53:38 STU_DP_S3_****backup 1 100 % Root 1136 14. Dezember 2018 4:48:22 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Sicherung erledigt 0 VMware Full_Scan *******.********.cloud NBCC 14. Dez. 2018 4:49:14 03:49:58 14. Dez. 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100 % 26438 Root 1136 15,963 14. Dezember 2018 4:49:14 03:49:58 Instant Recovery Disk Standard WIN-*********** 0 45.2 % 0%
Mit dem Beschleuniger können Sie den Verkehr von Agenten reduzieren, weil Es werden nur Datenänderungen übertragen, d.h. auch Vollsicherungen werden nicht vollständig hochgeladen, da der Medienserver nachfolgende Vollsicherungen aus inkrementellen Sicherungen sammelt.
Der Zwischenserver verfügt über einen eigenen Speicher, in den er einen „Cache“ mit Daten schreibt und eine Datenbank zur Deduplizierung verwaltet.
Die komplette Architektur sieht so aus:
- Der Master-Server verwaltet Konfiguration, Updates usw. und befindet sich in der Cloud.
- Der Medienserver (zwischengeschaltete *nix-Maschine) sollte sich im Hinblick auf die Netzwerkzugänglichkeit am nächsten an den redundanten Systemen befinden. Hier erfolgt die Deduplizierung der Backups aller reservierten Maschinen.
- Auf den gesicherten Maschinen gibt es Agenten, die im Allgemeinen nur das an den Medienserver senden, was sich nicht in seinem Speicher befindet.
Alles beginnt mit einem vollständigen Scan – das ist ein vollwertiges Voll-Backup. An diesem Punkt übernimmt der Medienserver alles, dedupliziert es und überträgt es an S3. Die Geschwindigkeit zum Medienserver ist gering, von dort jedoch höher. Die Hauptbeschränkung ist die Rechenleistung des Servers.
Die folgenden Sicherungen sind aus Sicht aller Systeme vollständig, in Wirklichkeit handelt es sich jedoch um so etwas wie synthetische Vollsicherungen. Das heißt, die tatsächliche Übertragung und Aufzeichnung auf den Medienserver erfolgt nur für die Datenblöcke, die noch nicht in VM-Backups aufgetreten sind. Und es werden nur die Datenblöcke übertragen und in S3 aufgezeichnet, deren Hash nicht in der Deduplizierungsdatenbank des Medienservers enthalten ist. Einfacher ausgedrückt ist dies etwas, was noch nie zuvor bei einem Backup einer einzelnen VM beobachtet wurde.
Beim Wiederherstellen fordert der Medienserver die notwendigen deduplizierten Objekte von S3 an, rehydriert sie und übergibt sie an die IRB-Agenten, d. h. Bei der Wiederherstellung muss das Verkehrsaufkommen berücksichtigt werden, das dem tatsächlich wiederherzustellenden Datenvolumen entspricht.
Hier ist, wie sieht es aus:
Und hier ist ein weiteres Stück Protokoll169 Jobs (0 in der Warteschlange, 0 aktiv, 0 auf Wiederholung wartend, 0 angehalten, 0 unvollständig, 169 erledigt – 1 ausgewählt)
Job-ID-Typ Status Statusdetails Status Job-Richtlinie Jobplan Client Medienserver Startzeit verstrichene Zeit Endzeit Speichereinheit Versuchsvorgang Kilobyte Dateien Pfadname % abgeschlossen (geschätzt) Job-PID-Besitzer Kopie der übergeordneten Job-ID KB/Sek. Aktiv Aktive abgelaufene Robot Vault-Profilsitzung starten ID-Medien zum Auswerfen der Datenbewegung Off-Host-Typ Master-Priorität Deduplizierungsrate Transportbeschleuniger-Optimierungsinstanz oder Datenbank-Freigabehost
. :1372 Uhr 0:01:19 WIN-*************** 2018
Die Datenintegrität wird durch den Schutz von S3 selbst gewährleistet – dort gibt es eine gute Redundanz zum Schutz vor Hardwarefehlern wie einer toten Festplattenspindel.
Der Medienserver benötigt 4 TB Cache – dies ist die Mindestgrößenempfehlung von Veritas. Mehr ist besser, aber genau das haben wir getan.
Ergebnis
Als ein Partner 3 GB in unseren S20 steckte, haben wir 60 GB gespeichert, da wir eine dreifache Georeservierung der Daten anbieten. Jetzt gibt es viel weniger Verkehr, was sowohl für den Kanal als auch für die Speichertarife gut ist.
In diesem Fall sind die Routen über das „große Internet“ hinaus gesperrt, Sie können den Datenverkehr jedoch über VPN L2 über das Internet leiten, es ist jedoch besser, den Medienserver vor dem Eingang des Anbieters zu installieren.
Wenn Sie mehr über diese Funktionen in unseren russischen Rechenzentren erfahren möchten oder Fragen zur Implementierung zu Hause haben, fragen Sie uns in den Kommentaren oder per E-Mail [E-Mail geschützt] .
Source: habr.com