Eis tierkesch Clienten hunn eis gefrot fir de Backup fir hiren Datenzenter richteg ze konfiguréieren. Mir maachen ähnlech Projeten a Russland, awer hei war d'Geschicht méi iwwer d'Fuerschung wéi et am Beschten ass.
Gitt: et gëtt eng lokal S3-Speicherung, et gëtt Veritas NetBackup, déi nei erweidert Funktionalitéit kritt huet fir Daten op Objektlagerung ze verschécken, elo mat Ënnerstëtzung fir Deduplikatioun, an et gëtt e Problem mat fräiem Raum an dëser lokaler Späichere.
Aufgab: alles ze maachen fir datt de Prozess vu Backupkopien séier a bëlleg ass.
Eigentlech, virdru war alles am S3 einfach Dateien, an dës ware komplette Casts vun de kritesche Maschinnen vum Rechenzentrum. Dat ass, et ass net ganz optimiséiert, awer alles huet am Ufank geschafft. Elo ass et Zäit et erauszefannen an et richteg ze maachen.
D'Bild weist wat mir ukomm sinn:
Wéi Dir gesitt, gouf den éischte Backup lues gemaach (70 Mb/s), a spéider Backupe vun de selwechte Systemer ware vill méi séier.
Eigentlech, weider ginn et e bësse méi Detailer iwwer wéi eng Features et ginn.
Backup Logbicher fir déi, déi bereet sinn eng hallef Säit Dump ze liesenVoll mat rescan
Dezember 18, 2018 12:09:43 PM - Info bpbkar (pid=4452) Beschleuniger geschéckt 14883996160 Bytes vun 14883994624 Bytes op de Server, Optimisatioun 0.0%
Dez 18, 2018 12:10:07 PM - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht = PDDO Statistiken (Multi-threaded Baach benotzt) fir (NBCC): gescannt: 14570817 KB, CR geschéckt: 1760761 KB, CR iwwer FC geschéckt: 0 KB, dedup: 87.9%, Cache behënnert
Full
Dezember 18, 2018 12:13:18 PM - Info bpbkar (pid=2864) Beschleuniger geschéckt 181675008 Bytes vun 14884060160 Bytes op de Server, Optimisatioun 98.8%
18. Dezember 2018 12:13:40 PM - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht = PDDO Statistike fir (NBCC): gescannt: 14569706 KB, CR geschéckt: 45145 KB, CR iwwer FC geschéckt: 0 KB, dedup: 99.7%, Cache behënnert
Incremental
Dezember 18, 2018 12:15:32 PM - Info bpbkar (pid=792) Beschleuniger geschéckt 9970688 Bytes vun 14726108160 Bytes op de Server, Optimisatioun 99.9%
18. Dezember 2018 12:15:53 PM - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht = PDDO Statistike fir (NBCC): gescannt: 14383788 KB, CR geschéckt: 15700 KB, CR iwwer FC geschéckt: 0 KB, dedup: 99.9%, Cache behënnert
Full
Dezember 18, 2018 12:18:02 PM - Info bpbkar (pid=3496) Beschleuniger geschéckt 171746816 Bytes vun 14884093952 Bytes op de Server, Optimisatioun 98.8%
18. Dezember 2018 12:18:24 PM - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Bericht = PDDO Statistike fir (NBCC): gescannt: 14569739 KB, CR geschéckt: 34120 KB, CR iwwer FC geschéckt: 0 KB, dedup: 99.8%, Cache behënnert
Wat ass de Problem
D'Clientë wëllen Backups sou dacks wéi méiglech maachen an se sou bëlleg wéi méiglech späicheren. Et ass am beschten se bëlleg an Objektspeicher wéi S3 ze späicheren, well se déi bëllegst sinn op Käschte vum Service pro Megabyte vu wou Dir e Backup an enger vernünftbarer Zäit zréckrolle kënnt. Wann et vill Backupsatellit gëtt, gëtt et net ganz bëlleg, well de gréissten Deel vun der Späichere vu Kopien vun de selwechten Donnéeën besat ass. Am Fall vun HaaS vun tierkesche Kollegen kann d'Lagerung ëm ongeféier 80-90% densifizéiert ginn. Et ass kloer datt dëst speziell op hir Spezifizitéiten bezitt, awer ech géif definitiv op op d'mannst 50% Grousspapp zielen.
Fir de Problem ze léisen, hunn d'Haaptverkeefer laang Paarte op Amazon S3 gemaach. All hir Methoden si kompatibel mat lokalen S3 soulaang se d'Amazon API ënnerstëtzen. Am tierkeschen Rechenzentrum gëtt de Backup op eise S3 gemaach, wéi och am T-III "Kompressor" a Russland, well dëst Aarbechtsschema gutt fir eis geschafft huet.
An eise S3 ass voll kompatibel mat Amazon S3 Backup Methoden. Dat ass, all Backup-Tools, déi dës Methoden ënnerstëtzen, erlaben Iech alles op sou Späichere "aus der Këscht" ze kopéieren.
Veritas NetBackup huet d'CloudCatalyst Feature bäigefüügt:
Dat ass, tëscht de Maschinnen, déi musse gebackupt ginn an dem Paart, gëtt et en Zwëschen Linux-Server, duerch deen de Backup-Traffic vun den SRK-Agenten passéiert an deduplizéiert gëtt, ier en op S3 transferéiert gëtt. Wa fréier 30 Backups vun 20 GB mat Kompressioun waren, elo (wéinst der Ähnlechkeet vun de Maschinnen) ass hire Volume 90% méi kleng ginn. Den Deduplikatiounsmotor gëtt d'selwecht benotzt wéi wann Dir op normale Disken mat Netbackup späichert.
Hei ass wat geschitt virum Zwëschenserver:
Mir hunn getest an sinn zur Conclusioun komm datt wann se an eisen Datenzenter implementéiert gëtt, dëst Plaz an der S3-Späichere fir eis a fir Clienten spuert. Als Propriétaire vu kommerziellen Datenzenter berechnen mir natierlech no dem besat Volumen, awer et ass nach ëmmer ganz rentabel fir eis - well mir fänken un Suen op méi skalierbare Plazen an der Software ze verdéngen, an net op Hardware ze lounen. Gutt, an dëst ass eng Reduktioun vun den internen Käschten.
Logbicher228 Aarbechtsplazen (0 Queued 0 Aktiv 0 Waart op Retry 0 Suspendéiert 0 Onkomplett 228 Fäerdeg - 13 ausgewielt)
(Filter ugewannt [13])
Job Id Typ Staat Staat Detailer Status Job Politik Job Zäitplang Client Media Server Start Zäit Vergaangen Zäit Enn Zäit Späicher Eenheet Versuch Operatioun Kilobytes Dateien Pathnumm % Komplett (Geschätzte) Job PID Besëtzer Kopie Elteren Job ID KB/Sek Aktiv Start Aktiv Oflaf Robot Vault Profil Sessioun ID Medien fir Datebewegung Off-Host Typ Master Prioritéit Deduplication Rate Transport Accelerator Optimiséierung Instanz oder Datebank Share Host
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC Dezember 18, 2018 12:16:19 PM 00: 02: 18 Dezember 18, 2018 12: 18: 37 PM STU_DP_S3_**** Backup 1 100% De root 1358 18% :2018:12 PM 16:27:00 Instant Recovery Disk Standard WIN-************* 02
1360 Backup gemaach 0 VMware Voll NGNCloudADC NBCC Dezember 18, 2018 12:16:48 PM 00: 01: 39 Dezember 18, 2018 12: 18: 27 PM STU_DP_S3_**** Backup 1 14,535,248% 149654 100 23858 1358 Dez 335,098, 18 2018:12:16 PM 48:00:01 Instant Recovery Disk Standard WIN-************* 39 0% 99.8%
1352 Snapshot gemaach 0 VMware - NGNCloudADC NBCC Dezember 18, 2018 12:14:04 PM 00: 02: 01 Dezember 18, 2018 12: 16: 05 PM STU_DP_S3_**** Backup 1 100% De root 1352 18% 2018% 12:14 PM 14:00:01 Instant Recovery Disk Standard WIN-************* 51
1354 Backup gemaach 0 VMware Incremental NGNCloudADC NBCC Dezember 18, 2018 12: 14: 34 PM 00: 01: 21 Dezember 18, 2018 12: 15: 55 PM STU_DP_S3_**** Backup 1 14,380,965 root 147 100 root 23617 1352 500,817 Dec 18, 2018 12:14:34 PM 00:01:21 Instant Erhuelung Disk Standard WIN-************* 0 99.9% 100%
1347 Snapshot gemaach 0 VMware - NGNCloudADC NBCC Dezember 18, 2018 12:11:45 PM 00: 02: 08 Dezember 18, 2018 12: 13: 53 PM STU_DP_S3_**** Backup 1 100% De root 1347 18% 2018% 12:11 PM 45:00:02 Instant Recovery Disk Standard WIN-************* 08
1349 Backup gemaach 0 VMware Voll NGNCloudADC NBCC Dezember 18, 2018 12:12:02 PM 00: 01: 41 Dezember 18, 2018 12: 13: 43 PM STU_DP_S3_**** Backup 1 14,535,215% 149653 100 23508 1347 Dez 316,319, 18 2018:12:12 PM 02:00:01 Instant Recovery Disk Standard WIN-************* 41 0% 99.7%
1341 Snapshot gemaach 0 VMware - NGNCloudADC NBCC Dezember 18, 2018 12:05:28 PM 00: 04: 53 Dezember 18, 2018 12: 10: 21 PM STU_DP_S3_**** Backup 1 100% De root 1341 18% 2018% 12:05 PM 28:00:04 Instant Recovery Disk Standard WIN-************* 53
1342 Backup gemaach 0 VMware Full_Rescan NGNCloudADC NBCC Dezember 18, 2018 12:05:47 PM 00: 04: 24 Dezember 18, 2018 12: 10: 11 PM STU_DP_S3_**** Backup 1 14,535,151, 149653 Root 100 22999 1341 70,380 18 Dez 2018, 12 05:47:00 PM 04:24:0 Instant Recovery Disk Standard WIN-************* 87.9 0% XNUMX%
1339 Snapshot gemaach 150 VMware - NGNCloudADC NBCC Dezember 18, 2018 11:05:46 AM 00: 00: 53 Dezember 18, 2018 11: 06: 39 AM STU_DP_S3_**** Backup 1 100% De root 1339 18% 2018% 11:05 AM 46:00:00 Instant Recovery Disk Standard WIN-************* 53
1327 Snapshot gemaach 0 VMware - *******.********.cloud NBCC Dezember 17, 2018 12:54:42 PM 05:51:38 Dezember 17, 2018 6:46:20 PM STU_DP_S3_****Backup 1 100% root 1327 Dec 17, 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-************* 0
1328 Backup gemaach 0 VMware Voll *******.********.cloud NBCC Dezember 17, 2018 12:55:10 PM 05:29:21 Dezember 17, 2018 6:24:31 PM STU_DP_S3_****Backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Dezember 17, 2018 12:55:10 PM 05:29:21 Instant Recovery Disk 0******** Standard 87.9% WIN 0%
1136 Snapshot gemaach 0 VMware - *******.********.cloud NBCC Dezember 14, 2018 4:48:22 PM 04:05:16 Dezember 14, 2018 8:53:38 PM STU_DP_S3_****Backup 1 100% root 1136 Dec 14, 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-************* 0
1140 Backup gemaach 0 VMware Full_Scan *******.********.cloud NBCC Dezember 14, 2018 4:49:14 PM 03:49:58 Dezember 14, 2018 8:39:12 PM STU_DP_S3_****Backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Dezember 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk 0*** Standard 45.2%0-XNUMX***** XNUMX%
D'Accelerator erlaabt Iech Verkéier vun Agenten ze reduzéieren, well Nëmmen Datenännerunge ginn iwwerdroen, dat heescht, souguer voll Backupe ginn net ganz eropgelueden, well de Medienserver spéider voll Backupe vun inkrementelle Backupe sammelt.
Den Zwëschenserver huet seng eege Späichere, wou en e "Cache" vun Daten schreift an eng Datebank fir Deduplikatioun ënnerhält.
Déi komplett Architektur gesäit esou aus:
- De Master-Server geréiert d'Konfiguratioun, d'Aktualiséierungen etc. a läit an der Wollek.
- De Medienserver (Zwëschen *nix Maschinn) soll am nootste bei de redundante Systemer a punkto Netzaccessibilitéit sinn. Hei gëtt Deduplikatioun vu Backups vun all reservéiert Maschinnen gemaach.
- Op de gebackene Maschinnen ginn et Agenten déi allgemeng nëmmen op de Medienserver schécken wat net a senger Späichere ass.
Et fänkt alles mat engem vollen Scan un - dëst ass e vollwäertege komplette Backup. Zu dësem Zäitpunkt hëlt de Medienserver alles, deduplizéiert et an transferéiert et op S3. D'Geschwindegkeet op de Medienserver ass niddereg, awer dovun ass et méi héich. D'Haaptlimitatioun ass d'Rechenkraaft vum Server.
Déi folgend Backupe gi komplett aus der Siicht vun all Systemer gemaach, awer a Wierklechkeet si se eppes wéi synthetesch voll Backups. Dat ass, den aktuellen Transfert an den Opnahmen op de Medienserver geschitt nëmme vun deenen Datenblocken, déi nach net virdrun a VM-Backups begéint sinn. An nëmmen déi Datenblocken, deenen hiren Hash net an der Deduplikatiounsdatebank vum Medienserver ass, ginn an S3 transferéiert an opgeholl. An méi einfache Wierder, dëst ass eppes wat nach ni an engem Backup vun engem eenzege VM gesi gouf.
Wärend der Restauratioun freet de Medienserver déi néideg deduplizéiert Objete vum S3, rehydratéiert se an iwwerdréit se un d'IRB Agenten, d.h. Et ass néideg de Volume vum Traffic während der Restauratioun ze berücksichtegen, wat gläich ass mam aktuellen Volumen vun Daten déi restauréiert ginn.
Hei ass wéi et ausgesäit:
An hei ass en anert Stéck Logbicher169 Aarbechtsplazen (0 Queued 0 Aktiv 0 Waart op Retry 0 Suspendéiert 0 Onkomplett 169 Fäerdeg - 1 ausgewielt)
Job Id Typ Staat Staat Detailer Status Job Politik Job Zäitplang Client Media Server Start Zäit Vergaangen Zäit Enn Zäit Späicher Eenheet Versuch Operatioun Kilobytes Dateien Pathnumm % Komplett (Geschätzte) Job PID Besëtzer Kopie Elteren Job ID KB/Sek Aktiv Start Aktiv Oflaf Robot Vault Profil Sessioun ID Medien fir Datebewegung Off-Host Typ Master Prioritéit Deduplication Rate Transport Accelerator Optimiséierung Instanz oder Datebank Share Host
— 1372 Restauréieren gemaach 0 nbpr01 NBCC Dezember 19, 2018 1:05:58 PM 00:04:32 Dezember 19, 2018 1:10:30 PM 1 14,380,577 1 100 root% 8548 Dec 1372 :70,567:19 PM 2018:1:06 WIN-************* 00
Dateintegritéit ass gesuergt duerch de Schutz vum S3 selwer - et gëtt gutt Redundanz do fir géint Hardwarefehler ze schützen wéi eng doudege Festplack Spindel.
De Medienserver brauch 4 TB Cache - dëst ass Veritas seng Mindestgréisst Empfehlung. Méi ass besser, awer dat ass wat mir gemaach hunn.
D 'Resultat
Wann e Partner 3 GB an eise S20 geheit huet, hu mir 60 GB gespäichert, well mir dräifach Geo-Reservéierung vun Daten ubidden. Elo gëtt et vill manner Traffic, wat gutt ass fir de Kanal a fir d'Späichertariffer.
An dësem Fall sinn d'Strecken iwwer de "grousse Internet" zougemaach, awer Dir kënnt Traffic iwwer VPN L2 iwwer Internet féieren, awer et ass besser de Medienserver virun der Entrée vum Provider z'installéieren.
Wann Dir interesséiert sidd iwwer dës Fonctiounen an eise russeschen Datenzenter ze léieren oder Froen iwwer d'Ëmsetzung doheem hutt, frot Iech an de Kommentarer oder per E-Mail [Email geschützt].
Source: will.com