🥇Wie man die Speicherung von Backups in einem Objektspeicher um bis zu 90 % verdichten kann

Unsere türkischen Kunden haben uns gebeten, das Backup für das Rechenzentrum richtig einzurichten. Solche Projekte führen wir in Russland durch, aber hier ging es mehr um die Erforschung, wie man es besser machen kann.

Gegeben: Es gibt einen lokalen S3-Speicher, es gibt Veritas NetBackup, das über eine neue erweiterte Funktionalität zum Verschieben von Daten in Objektspeicher mit Unterstützung für Deduplizierung verfügt, und es gibt ein Problem mit dem Speicherplatz in diesem lokalen Speicher.

Aufgabe: Alles so gestalten, dass der Prozess der Backup-Speicherung schnell und kostengünstig ist.

Vorher wurde im S3 alles einfach als Dateien abgelegt, und das waren vollständige Abbilder kritischer Maschinen des Rechenzentrums. Das war nicht besonders optimiert, aber es funktionierte beim Start. Jetzt ist es an der Zeit, das richtig zu machen.

Auf dem Bild ist das, was wir erreicht haben:

Wie zu sehen ist, wurde das erste Backup langsam durchgeführt (70 MB/s), während die nachfolgenden Backups derselben Systeme deutlich schneller waren.

Hier sind nun einige weitere Details zu den Besonderheiten.

Backup-Protokolle für diejenigen, die bereit sind, eine halbe Seite Dump zu lesenVoll mit Rescan
18. Dez. 2018 12:09:43 — Info bpbkar (pid=4452) Beschleuniger sendete 14883996160 Bytes von 14883994624 Bytes an den Server, Optimierung 0,0%
18. Dez. 2018 12:10:07 — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht=PDDO-Statistiken (multithreaded Stream verwendet) für (NBCC): gescannt: 14570817 KB, CR gesendet: 1760761 KB, CR über FC gesendet: 0 KB, Deduplizierung: 87,9%, Cache deaktiviert

Voll
18. Dez. 2018 12:13:18 — Info bpbkar (pid=2864) Beschleuniger sendete 181675008 Bytes von 14884060160 Bytes an den Server, Optimierung 98,8%
18. Dez. 2018 12:13:40 — 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 über FC gesendet: 0 KB, Deduplizierung: 99,7%, Cache deaktiviert

Inkremental
18. Dez. 2018 12:15:32 — Info bpbkar (pid=792) Beschleuniger sendete 9970688 Bytes von 14726108160 Bytes an den Server, Optimierung 99,9%
18. Dez. 2018 12:15:53 — 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 über FC gesendet: 0 KB, Deduplizierung: 99,9%, Cache deaktiviert

Voll
18. Dez. 2018 12:18:02 — Info bpbkar (pid=3496) Beschleuniger sendete 171746816 Bytes von 14884093952 Bytes an den Server, Optimierung 98,8%
18. Dez. 2018 12:18:24 — 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 über FC gesendet: 0 KB, Deduplizierung: 99,8%, Cache deaktiviert

Was ist das Problem?

Kunden möchten Backup so oft wie möglich erstellen und so günstig wie möglich speichern. Am günstigsten kann dies in Objektspeichern wie S3 erfolgen, da diese bei den Kosten für die Wartung pro Megabyte am günstigsten sind, wenn das Backup innerhalb angemessener Zeit zurückgespielt werden kann. Wenn es viele Backups gibt, wird es jedoch nicht sehr günstig, da ein Großteil des Speichers von Kopien derselben Daten belegt ist. Bei HaaS können türkische Kollegen die Speicherung um etwa 80-90 % verdichten. Es ist klar, dass sich dies auf ihre spezifischen Anforderungen bezieht, aber mindestens 50 % Deduplizierung würde ich auf jeden Fall annehmen.

Um das Problem zu lösen, haben die großen Anbieter bereits seit langem Gateways für S3 von Amazon erstellt. Alle ihre Methoden sind mit lokalen S3 kompatibel, sofern sie die Amazon-API unterstützen. Im türkischen Rechenzentrum wird das Backup in unser S3 erstellt, genau wie im T-III „Kompressor“ in Russland, da sich ein solches Arbeitsmodell bei uns bewährt hat.

Und unser S3 ist vollständig mit den Backup-Methoden von Amazon S3 kompatibel. Das bedeutet, dass alle Backup-Tools, die diese Methoden unterstützen, alles „out of the box“ in ein ähnliches Speicherformat kopieren können.

In Veritas NetBackup haben sie die Funktion CloudCatalyst eingeführt:

Das bedeutet, dass zwischen den Maschinen, die gesichert werden müssen, und dem Gateway ein Zwischen-Linux-Server eingerichtet wurde, über den der Backup-Verkehr von den SRK-Agenten läuft und deren Deduplizierung 'on the fly' erfolgt, bevor sie an S3 übermittelt werden. Früher gab es dort 30 Backups à 20 GB mit Kompression, jetzt sind es (aufgrund der Ähnlichkeit der Maschinen) volumenmäßig 90 % weniger. Die gleiche Deduplizierungsengine wird verwendet wie beim Speichern auf herkömmlichen Festplatten mit NetBackup.

Folgendes geschieht vor dem Zwischenserver:

Wir haben getestet und sind zu dem Schluss gekommen, dass die Implementierung in unseren Rechenzentren den Platz in den S3-Speichern sowohl für uns als auch für die Kunden spart. Als Eigentümer von kommerziellen Rechenzentren berechnen wir selbstverständlich nach dem belegten Volumen, aber dennoch ist es auch für uns sehr vorteilhaft – denn wir beginnen, in skalierbaren Bereichen der Software zu verdienen, und nicht durch die Vermietung von Hardware. Außerdem reduziert das die internen Kosten.

Logs228 Jobs (0 Wartend 0 Aktiv 0 Warten auf Wiederholung 0 Ausgesetzt 0 Unvollständig 228 Erledigt - 13 ausgewählt)
(Filter angewendet [13])

Job-ID Typ Zustand Zustandsdetails Status Job-Richtlinie Job-Zeitplan Client Medienserver Startzeit Abgelaufene Zeit Endzeit Speichereinheit Versuch Operation Kilobyte Dateien Dateipfad % abgeschlossen (geschätzt) Job PID Eigentümer Kopie Übergeordnete Job-ID KB/Sek. Aktiv Start Aktiv Abgelaufen Roboter Vault-Profil Sitzungs-ID Medien zum Auswerfen Datenbewegung Off-Host Typ Master Priorität Deduplication-Rate Transportbeschleuniger Optimierung Instanz oder Datenbank Freigabe-Host
— 1358 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:16:19 Uhr 00:02:18 18. Dez 2018 12:18:37 Uhr STU_DP_S3_****backup 1 100% root 1358 18. Dez 2018 12:16:27 Uhr 00:02:10 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1360 Backup abgeschlossen 0 VMware Vollständig NGNCloudADC NBCC 18. Dez 2018 12:16:48 Uhr 00:01:39 18. Dez 2018 12:18:27 Uhr STU_DP_S3_****backup 1 14.535.248 149654 100% 23858 root 1358 335.098 18. Dez 2018 12:16:48 Uhr 00:01:39 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 99.8% 99%
1352 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:14:04 Uhr 00:02:01 18. Dez 2018 12:16:05 Uhr STU_DP_S3_****backup 1 100% root 1352 18. Dez 2018 12:14:14 Uhr 00:01:51 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1354 Backup abgeschlossen 0 VMware Inkremental NGNCloudADC NBCC 18. Dez 2018 12:14:34 Uhr 00:01:21 18. Dez 2018 12:15:55 Uhr STU_DP_S3_****backup 1 14.380.965 147 100% 23617 root 1352 500.817 18. Dez 2018 12:14:34 Uhr 00:01:21 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 99.9% 100%
1347 Snapshot abgeschlossen 0 VMware — NGNCloudADC NBCC 18. Dez 2018 12:11:45 Uhr 00:02:08 18. Dez 2018 12:13:53 Uhr STU_DP_S3_****backup 1 100% root 1347 18. Dez 2018 12:11:45 Uhr 00:02:08 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0
1349 Backup abgeschlossen 0 VMware Vollständig NGNCloudADC NBCC 18. Dez 2018 12:12:02 Uhr 00:01:41 18. Dez 2018 12:13:43 Uhr STU_DP_S3_****backup 1 14.535.215 149653 100% 23508 root 1347 316.319 18. Dez 2018 12:12:02 Uhr 00:01:41 Sofortige Wiederherstellung Festplatte Standard WIN-*********** 0 99.7% 99%
1341 Snapshot abgeschlossen 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 abgeschlossen 0 VMware Vollständiger Neu-Scan 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 abgeschlossen 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 abgeschlossen 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 abgeschlossen 0 VMware Vollständig *******.********.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 abgeschlossen 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 abgeschlossen 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 ermöglicht die Reduktion des Traffics von Agenten, da nur Datenänderungen übertragen werden. Selbst vollständige Backups werden nicht vollständig gesendet, da der Medienserver nachfolgende vollständige Backups aus inkrementellen Backups erstellt.

Der Zwischenserver hat seinen eigenen Speicher, in dem er den "Cache" der Daten schreibt und eine Datenbank für die Deduplizierung hält.

In der vollständigen Architektur sieht es so aus:

Der Master-Server verwaltet die Konfiguration, Updates und weiteres und befindet sich in der Cloud.
Der Medienserver (eine Zwischen *nix-Maschine) sollte sich in der Nähe der zu sichernden Systeme hinsichtlich der Netzverfügbarkeit befinden. Hier erfolgt die Deduplizierung der Backups von allen zu sichernden Maschinen.
Auf den zu sichernden Maschinen gibt es Agenten, die im Allgemeinen nur das an den Medienserver senden, was nicht in seinem Speicher vorhanden ist.

Alles beginnt mit einem vollständigen Scan – das ist ein echtes vollständiges Backup. In diesem Moment holt der Medienserver alles, führt die Deduplizierung durch und überträgt es in S3. Die Geschwindigkeit zum Medienserver ist niedrig, von ihm aus ist sie hingegen höher. Die Hauptbeschränkung ist die Rechenleistung des Servers.

Die nächsten Backups werden aus der Sicht aller Systeme als vollständig betrachtet, sind in Wirklichkeit jedoch etwas wie synthetische vollständige Backups. Das bedeutet, dass die tatsächliche Übertragung und Speicherung auf dem Medienserver nur der Datenblöcke erfolgt, die zuvor nicht in den Backups der VMs vorhanden waren. Die Übertragung und Speicherung in S3 erfolgt nur für die Datenblöcke, deren Hash nicht in der Deduplizierungsdatenbank des Medienservers vorhanden ist. Einfacher ausgedrückt: was noch nie in einem Backup einer VM vorhanden war.

Beim Restore fragt der Medienserver die benötigten deduplizierten Objekte von S3 an, regeneriert sie und überträgt sie an die KR-Agenten. Das heißt, man muss das Volumen des Traffics beim Restore berücksichtigen, das dem tatsächlichen Volumen der wiederherzustellenden Daten entspricht.

So sieht das aus:

Und hier ist noch ein Abschnitt der Protokolle169 Jobs (0 Wartend 0 Aktiv 0 Wartend auf Wiederholung 0 Ausgesetzt 0 Unvollständig 169 Fertig — 1 ausgewählt)

Die Integrität der Daten wird durch den Schutz von S3 gewährleistet – dort gibt es eine gute Redundanz zum Schutz vor Hardwareausfällen wie einem defekten Festplattenspindel.

Medien-zu einem Server es sind 4 TB Cache erforderlich – das ist die Empfehlung von Veritas für das minimale Volumen. Besser ist mehr, aber wir haben es genau so gemacht.

Fazit

Als unser Partner 20 GB in unser S3 hochlud, speicherten wir 60 GB, da wir eine dreifache Datengeoredundanz gewährleisten. Der Verkehr ist jetzt deutlich geringer, was sowohl für die Bandbreite als auch für die Speicherungskosten vorteilhaft ist.

In diesem Fall sind die Routen außerhalb des "großen Internets" geschlossen, aber es ist möglich, den Verkehr auch über VPN L2 über das Internet zu leiten, allerdings sollte der Mediaserver besser vor dem Anbieteranschluss eingerichtet werden.

Wenn Sie mehr über diese Funktionen in unseren russischen Rechenzentren erfahren möchten oder Fragen zur Umsetzung bei Ihnen haben - fragen Sie in den Kommentaren oder per E-Mail an ekorotkikh@croc.ru.

Quelle: habr.com

Wie man die Speicherung von Backups im Objektspeicher auf 90% verdichten kann.

Was ist das Problem?

Fazit