Unsere türkischen Kunden baten uns, das Backup für das Rechenzentrum richtig einzurichten. Solche Projekte realisieren wir auch in Russland, aber hier ging es mehr darum zu erforschen, wie man es besser machen kann.
Gegeben: Es gibt einen lokalen S3-Speicher, es gibt Veritas NetBackup, das über neue erweiterte Funktionen zur Datenübertragung in Objektspeicher mit Unterstützung für Deduplizierung verfügt, und es gibt ein Problem mit dem freien Speicherplatz in diesem lokalen Speicher.
Aufgabe: Alles so zu gestalten, dass der Backup-Prozess schnell und kostengünstig ist.
Bisher wurden im S3 einfach Dateien abgelegt, wobei es sich um vollständige Abbilder kritischer Maschinen im Rechenzentrum handelte. Es war nicht besonders optimiert, aber zumindest funktionierte alles zu Beginn. Jetzt ist es an der Zeit, das richtig anzugehen.
Auf dem Bild sieht man, wohin wir gekommen sind:
Wie zu sehen ist, verlief das erste Backup langsam (70 MB/s), während die nachfolgenden Backups derselben Systeme deutlich schneller waren.
Hier sind einige weitere Details zu den Besonderheiten.
Backup-Protokolle für diejenigen, die bereit sind, ein halbes Seiten-Dump zu lesen.Vollständige Analyse mit erneuter Überprüfung
18. Dezember 2018 12:09:43 — Info bpbkar (pid=4452) Accelerator hat 14.883.996.160 Bytes von 14.883.994.624 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 (Multi-Threaded Stream verwendet) für (NBCC): gescannt: 14.570.817 KB, CR gesendet: 1.760.761 KB, CR gesendet über FC: 0 KB, Dedup: 87,9%, Cache deaktiviert
Voll
18. Dezember 2018 12:13:18 — Info bpbkar (pid=2864) Accelerator hat 181.675.008 Bytes von 14.884.060.160 Bytes an den Server gesendet, Optimierung 98,8%
18. Dezember 2018 12:13:40 — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14.569.706 KB, CR gesendet: 45.145 KB, CR gesendet über FC: 0 KB, Dedup: 99,7%, Cache deaktiviert
Inkremental
18. Dezember 2018 12:15:32 — Info bpbkar (pid=792) Accelerator hat 9.970.688 Bytes von 14.726.108.160 Bytes an den Server gesendet, Optimierung 99,9%
18. Dezember 2018 12:15:53 — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14.383.788 KB, CR gesendet: 15.700 KB, CR gesendet über FC: 0 KB, Dedup: 99,9%, Cache deaktiviert
Voll
18. Dezember 2018 12:18:02 — Info bpbkar (pid=3496) Accelerator hat 171.746.816 Bytes von 14.884.093.952 Bytes an den Server gesendet, Optimierung 98,8%
18. Dezember 2018 12:18:24 — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken für (NBCC): gescannt: 14.569.739 KB, CR gesendet: 34.120 KB, CR gesendet über FC: 0 KB, Dedup: 99,8%, Cache deaktiviert
Was ist das Problem?
Kunden möchten ihre Backups so häufig wie möglich erstellen und so kostengünstig wie möglich speichern. Die günstigste Möglichkeit zur Speicherung erfolgt in Objekt-Speichern wie S3, da sie die niedrigsten Betriebskosten pro Megabyte bieten, von wo aus Backups zeitnah wiederhergestellt werden können. Bei einer großen Anzahl von Backups wird es jedoch nicht besonders günstig, da der größte Teil des Speichers Kopien derselben Daten benötigt. Im Falle von HaaS können unsere türkischen Kollegen die Speicherung um etwa 80-90 % optimieren. Das bezieht sich natürlich auf ihre spezifischen Anforderungen, aber ich würde mindestens mit einer 50 %igen Deduplizierung rechnen.
Um dieses Problem zu lösen, haben die führenden Anbieter schon lange Gateways zu Amazon S3 entwickelt. Alle ihre Methoden sind mit lokalem S3 kompatibel, sofern sie die Amazon-API unterstützen. Im türkischen Rechenzentrum erfolgt das Backup in unser S3, genau wie im T-III "Kompressor" in Russland, da dieses Arbeitsmodell sich bei uns bewährt hat.
Unser S3 ist vollständig kompatibel mit den Backup-Methoden von Amazon S3. Das bedeutet, dass alle Backup-Tools, die diese Methoden unterstützen, es ermöglichen, alles sofort in einen ähnlichen Speicher zu kopieren.
Veritas NetBackup hat die Funktion CloudCatalyst entwickelt:
Das bedeutet, dass zwischen den Maschinen, die gesichert werden müssen, und dem Gateway ein Zwischen-Linux-Server steht, über den der Backup-Verkehr von den SRK-Agenten läuft und deren Deduplication "on-the-fly" erfolgt, bevor sie an S3 übertragen werden. Früher gab es 30 Backups von je 20 GB mit Kompression, nun ist deren Volumen aufgrund der Ähnlichkeit der Maschinen um 90 % reduziert worden. Die gleiche Deduplication-Engine wird verwendet, wie beim Speichern auf regulären Festplatten mit Netbackup.
So läuft es vor dem Zwischenspeicher-Server:
Wir haben getestet und sind zu dem Schluss gekommen, dass die Implementierung in unseren Rechenzentren Platz in S3-Speichern für uns und unsere Kunden spart. Als Betreiber kommerzieller Rechenzentren berechnen wir natürlich nach dem genutzten Volumen, aber es ist dennoch sehr vorteilhaft für uns — denn wir verdienen an skalierbaren Softwarelösungen und nicht an der Miete von Hardware. Zudem reduziert es auch unsere internen Kosten.
Protokolle228 Jobs (0 Wartend 0 Aktiv 0 Wartend auf Wiederholung 0 Ausgesetzt 0 Unvollständig 228 Erledigt — 13 ausgewählt)
(Filter angewendet [13])
Auftrags-ID Typ Status Statusdetails Status Auftragsrichtlinie Auftragszeitplan Client Medienserver Startzeit Verstrichene Zeit Endzeit Speichergerät Versuch Operation Kilobytes Dateien Dateipfad % abgeschlossen (geschätzt) Auftrags-PID Eigentümer Kopie übergeordnete Auftrags-ID KB/Sek. Aktiv Start Aktiv Verstrichen Roboter Tresorprofil Sitzungs-ID Medien zum Auswerfen Datenbewegung Off-Host-Typ Master Priorität Deduplicationsrate Transportbeschleuniger Optimierung Instanz oder Datenbank Freigabe-Host
— 1358 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:16:19 PM 00:02:18 18. Dez 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18. Dez 2018 12:16:27 PM 00:02:10 Sofortige Wiederherstellung Disk Standard WIN-*********** 0
1360 Backup abgeschlossen 0 VMware Vollständig NGNCloudADC NBCC 18. Dez 2018 12:16:48 PM 00:01:39 18. Dez 2018 12:18:27 PM STU_DP_S3_****backup 1 14.535.248 149654 100% 23858 root 1358 335.098 18. Dez 2018 12:16:48 PM 00:01:39 Sofortige Wiederherstellung Disk Standard WIN-*********** 0 99,8% 99%
1352 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:14:04 PM 00:02:01 18. Dez 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18. Dez 2018 12:14:14 PM 00:01:51 Sofortige Wiederherstellung Disk Standard WIN-*********** 0
1354 Backup abgeschlossen 0 VMware Inkremental NGNCloudADC NBCC 18. Dez 2018 12:14:34 PM 00:01:21 18. Dez 2018 12:15:55 PM STU_DP_S3_****backup 1 14.380.965 147 100% 23617 root 1352 500.817 18. Dez 2018 12:14:34 PM 00:01:21 Sofortige Wiederherstellung Disk Standard WIN-*********** 0 99,9% 100%
1347 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:11:45 PM 00:02:08 18. Dez 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18. Dez 2018 12:11:45 PM 00:02:08 Sofortige Wiederherstellung Disk Standard WIN-*********** 0
1349 Backup abgeschlossen 0 VMware Vollständig NGNCloudADC NBCC 18. Dez 2018 12:12:02 PM 00:01:41 18. Dez 2018 12:13:43 PM STU_DP_S3_****backup 1 14.535.215 149653 100% 23508 root 1347 316.319 18. Dez 2018 12:12:02 PM 00:01:41 Sofortige Wiederherstellung Disk Standard WIN-*********** 0 99,7% 99%
1341 Snapshot erfolgreich 0 VMware — NGNCloudADC NBCC 18. Dez. 2018 12:05:28 Uhr 00:04:53 18. Dez. 2018 12:10:21 Uhr STU_DP_S3_****backup 1 100% root 1341 18. Dez. 2018 12:05:28 Uhr 00:04:53 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1342 Backup erfolgreich 0 VMware Vollständiger Rescan NGNCloudADC NBCC 18. Dez. 2018 12:05:47 Uhr 00:04:24 18. Dez. 2018 12:10:11 Uhr STU_DP_S3_****backup 1 14.535.151 149653 100% 22999 root 1341 70.380 18. Dez. 2018 12:05:47 Uhr 00:04:24 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 87,9% 0%
1339 Snapshot erfolgreich 150 VMware — NGNCloudADC NBCC 18. Dez. 2018 11:05:46 Uhr 00:00:53 18. Dez. 2018 11:06:39 Uhr STU_DP_S3_****backup 1 100% root 1339 18. Dez. 2018 11:05:46 Uhr 00:00:53 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1327 Snapshot erfolgreich 0 VMware — *******.********.cloud NBCC 17. Dez. 2018 12:54:42 Uhr 05:51:38 17. Dez. 2018 18:46:20 Uhr STU_DP_S3_****backup 1 100% root 1327 17. Dez. 2018 12:54:42 Uhr 05:51:38 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1328 Backup erfolgreich 0 VMware Vollständiges *******.********.cloud NBCC 17. Dez. 2018 12:55:10 Uhr 05:29:21 17. Dez. 2018 18:24:31 Uhr STU_DP_S3_****backup 1 222.602.719 258932 100% 12856 root 1327 11.326 17. Dez. 2018 12:55:10 Uhr 05:29:21 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 87,9% 0%
1136 Snapshot erfolgreich 0 VMware — *******.********.cloud NBCC 14. Dez. 2018 16:48:22 Uhr 04:05:16 14. Dez. 2018 20:53:38 Uhr STU_DP_S3_****backup 1 100% root 1136 14. Dez. 2018 16:48:22 Uhr 04:05:16 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1140 Backup erfolgreich 0 VMware Vollscan *******.********.cloud NBCC 14. Dez. 2018 16:49:14 Uhr 03:49:58 14. Dez. 2018 20:39:12 Uhr STU_DP_S3_****backup 1 217.631.332 255465 100% 26438 root 1136 15.963 14. Dez. 2018 16:49:14 Uhr 03:49:58 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 45,2% 0%
Der Accelerator reduziert den Datenverkehr von den Agenten, da nur Datenänderungen übertragen werden. Selbst vollständige Backups werden nicht komplett übertragen, da der Media-Server aus inkrementellen Backups die nachfolgenden vollständigen Sicherungen erstellt.
Der Zwischenserver hat seinen eigenen Speicher, in dem er Daten-„Cache“ schreibt und eine Datenbasis für die Deduplication hält.
In der vollständigen Architektur sieht es folgendermaßen aus:
- Der Master-Server verwaltet die Konfiguration, Updates und andere Aspekte und befindet sich in der Cloud.
- Der Media-Server (eine Zwischen-*nix-Maschine) sollte möglichst nah an den zu sichernden Systemen in Bezug auf die Netzwerkverfügbarkeit stehen. Hier findet die Deduplication der Backups von allen zu sichernden Maschinen statt.
- Auf den zu sichernden Maschinen befinden sich Agenten, die in der Regel nur die Daten an den Media-Server senden, die nicht in dessen Speicher vorhanden sind.
Alles beginnt mit einem vollständigen Scan – das ist ein vollwertiges vollständiges Backup. In diesem Moment zieht der Media-Server alles ab, führt die Deduplication durch und überträgt es in S3. Die Geschwindigkeit bis zum Media-Server ist niedrig, von ihm ist sie höher. Die Hauptbeschränkung ist die Rechenleistung des Servers.
Die nachfolgenden Backups werden aus der Perspektive aller Systeme als vollständige Backups durchgeführt, sind jedoch in Wahrheit synthetische Voll-Backups. Das bedeutet, dass die tatsächliche Übertragung und Speicherung auf dem Medien-Server nur der Datenblöcke erfolgt, die in den bisherigen Backups der virtuellen Maschinen noch nicht aufgetaucht sind. Die Übertragung und Speicherung in S3 betrifft nur die Datenblöcke, deren Hash nicht in der Deduplizierungsdatenbank des Medien-Servers vorhanden ist. Einfacher ausgedrückt: Es werden nur Daten gesichert, die in keinem Backup jeglicher virtueller Maschine zuvor enthalten waren.
Beim Wiederherstellen fordert der Medien-Server die benötigten deduplizierten Objekte von S3 an, regidriert sie und übergibt sie an die SRK-Agenten. Daher ist das Verkehrsvolumen beim Wiederherstellen zu berücksichtigen, was dem tatsächlichen Umfang der wiederherzustellenden Daten entspricht.
So sieht es aus:
Und hier ein weiterer Log-Ausschnitt169 Jobs (0 In der Warteschleife 0 Aktiv 0 Wartend auf Wiederholung 0 Ausgesetzt 0 Unvollständig 169 Fertig — 1 ausgewählt)
Auftrags-ID Typ Status Statusdetails Status Auftragsrichtlinie Auftragszeitplan Client Medienserver Startzeit Verstrichene Zeit Endzeit Speichergerät Versuch Operation Kilobytes Dateien Dateipfad % abgeschlossen (geschätzt) Auftrags-PID Eigentümer Kopie übergeordnete Auftrags-ID KB/Sek. Aktiv Start Aktiv Verstrichen Roboter Tresorprofil Sitzungs-ID Medien zum Auswerfen Datenbewegung Off-Host-Typ Master Priorität Deduplicationsrate Transportbeschleuniger Optimierung Instanz oder Datenbank Freigabe-Host
— 1372 Wiederherstellung abgeschlossen 0 nbpr01 NBCC 19. Dez. 2018 13:05:58 00:04:32 19. Dez. 2018 13:10:30 1 14.380.577 1 100% 8548 root 1372 70.567 19. Dez. 2018 13:06:00 00:04:30 WIN-*********** 90000
Die Datenintegrität wird durch die Sicherheit von S3 gewährleistet – dort gibt es eine gute Redundanz zum Schutz vor Hardwarefehlern wie dem Ausfall eines Festplattenspindels.
Medien-Server 4 TB Cache sind die Empfehlungen von Veritas für das Mindestvolumen. Mehr ist besser, aber genau so haben wir es gemacht.
Zusammenfassung
Als unser Partner 20 GB in unser S3 geladen hat, haben wir 60 GB gespeichert, weil wir eine dreifache geografische Datensicherung anbieten. Der Datenverkehr ist jetzt viel geringer, was sowohl für den Kanal als auch für die Speicherabrechnung vorteilhaft ist.
In diesem Fall sind die Routen abseits des 'großen Internets' geschlossen, aber man kann den Verkehr auch über VPN L2 über das Internet leiten, aber es ist besser, den Medienserver vor dem Anbieter-Eingang zu platzieren.
Wenn Sie mehr über diese Funktionen in unseren russischen Rechenzentren erfahren möchten oder Fragen zur Implementierung haben — fragen Sie in den Kommentaren oder per E-Mail an ekorotkikh@croc.ru.
Quelle: habr.com
