Sådan komprimeres lagring af sikkerhedskopier i objektlager op til 90 %

Vores tyrkiske kunder bad os om at konfigurere backup korrekt til deres datacenter. Vi laver lignende projekter i Rusland, men her handlede historien mere om at undersøge, hvordan man bedst gør det.

Givet: der er et lokalt S3 lager, der er Veritas NetBackup, som har fået ny udvidet funktionalitet til at flytte data til objektlager, nu med understøttelse af deduplikering, og der er et problem med ledig plads i dette lokale lager.

Opgave: at gøre alt, så processen med at gemme sikkerhedskopier er hurtig og billig.

Faktisk, før dette, var alt i S3 simpelthen filer, og disse var komplette afstøbninger af de kritiske maskiner i datacentret. Det vil sige, at det ikke er særlig optimeret, men alt fungerede i starten. Nu er det tid til at finde ud af det og gøre det rigtigt.

Billedet viser, hvad vi kom til:

Sådan komprimeres lagring af sikkerhedskopier i objektlager op til 90 %

Som du kan se, blev den første backup lavet langsomt (70 Mb/s), og efterfølgende backup af de samme systemer var meget hurtigere.

Faktisk længere fremme er der lidt flere detaljer om, hvilke funktioner der er.

Backup logs for dem, der er klar til at læse en halv side dumpFuld med genscanning
Dec 18, 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator sendte 14883996160 bytes ud af 14883994624 bytes til serveren, optimering 0.0 %
Dec 18, 2018 12:10:07 PM - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik (multi-threaded stream brugt) for (NBCC): scannet: 14570817 KB, CR sendt: 1760761 KB, CR sendt over FC: 0 KB, dedup: 87.9%, cache deaktiveret

Fuld
Dec 18, 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator sendte 181675008 bytes ud af 14884060160 bytes til serveren, optimering 98.8 %
Dec 18, 2018 12:13:40 PM - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik for (NBCC): scannet: 14569706 KB, CR sendt: 45145 KB, CR sendt over FC: 0 KB, dedup: 99.7%, cache deaktiveret

Trinvis
Dec 18, 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator sendte 9970688 bytes ud af 14726108160 bytes til serveren, optimering 99.9 %
Dec 18, 2018 12:15:53 PM - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik for (NBCC): scannet: 14383788 KB, CR sendt: 15700 KB, CR sendt over FC: 0 KB, dedup: 99.9%, cache deaktiveret

Fuld
Dec 18, 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator sendte 171746816 bytes ud af 14884093952 bytes til serveren, optimering 98.8 %
Dec 18, 2018 12:18:24 PM - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik for (NBCC): scannet: 14569739 KB, CR sendt: 34120 KB, CR sendt over FC: 0 KB, dedup: 99.8%, cache deaktiveret

Hvad er problemet

Kunderne ønsker at lave sikkerhedskopier så ofte som muligt og opbevare dem så billigt som muligt. Det er bedst at gemme dem billigt i objektlager såsom S3, fordi de er de billigste på bekostning af service pr. Megabyte, hvorfra du kan rulle en backup tilbage i rimelig tid. Når der er meget backup, bliver det ikke særlig billigt, fordi det meste af lageret er optaget af kopier af de samme data. I tilfældet med HaaS af tyrkiske kolleger kan lageret fortættes med cirka 80-90 %. Det er klart, at dette relaterer sig specifikt til deres detaljer, men jeg vil helt sikkert regne med mindst 50% bedstefar.

For at løse problemet har hovedleverandørerne længe lavet gateways til Amazon S3. Alle deres metoder er kompatible med lokale S3, så længe de understøtter Amazon API. I det tyrkiske datacenter laves der backup til vores S3 såvel som i T-III "Compressor" i Rusland, da dette arbejdsskema har fungeret godt for os.

Og vores S3 er fuldt ud kompatibel med Amazon S3 backup metoder. Det vil sige, at alle sikkerhedskopieringsværktøjer, der understøtter disse metoder, giver dig mulighed for at kopiere alt til et sådant lager "ud af boksen."

Veritas NetBackup tilføjede CloudCatalyst-funktionen:

Sådan komprimeres lagring af sikkerhedskopier i objektlager op til 90 %

Det vil sige, at mellem de maskiner, der skal sikkerhedskopieres, og gatewayen, er der en mellemliggende Linux-server, som backup-trafik fra SRK-agenterne passerer igennem og deduplikeres i farten, inden den overføres til S3. Hvis der tidligere var 30 sikkerhedskopier på 20 GB med komprimering, er deres volumen nu (på grund af maskinernes lighed) blevet 90 % mindre. Deduplikeringsmotoren bruges på samme måde som ved lagring på almindelige diske ved hjælp af Netbackup.

Her er, hvad der sker før den mellemliggende server:

Sådan komprimeres lagring af sikkerhedskopier i objektlager op til 90 %

Vi testede og kom til den konklusion, at når det implementeres i vores datacentre, sparer dette plads i S3-lageret for os og for kunderne. Som ejer af kommercielle datacentre opkræver vi selvfølgelig efter den besatte mængde, men det er stadig meget rentabelt for os også - fordi vi begynder at tjene penge på mere skalerbare steder i softwaren, og ikke på leje af hardware. Nå, og det er en reduktion i interne omkostninger.

Logs228 job (0 i kø 0 Aktiv 0 Venter på at prøve igen 0 Suspenderet 0 Ufuldstændig 228 Udført — 13 udvalgte)
(Filter anvendt [13])

Job-id Type Status Status Detaljer Status Jobpolitik Jobplan Klient Media Server Starttid Forløbet Tid Sluttid Lagerenhed Forsøg Operation Kilobytes Filer Stinavn % Fuldført (estimeret) Job PID Ejer Kopi Overordnet Job ID KB/Sek Aktiv Start Aktiv Forløbet Robot Vault Profilsession ID-medie til at udskyde databevægelse uden for værtstype Masterprioritet deduplikeringshastighed Transportacceleratoroptimeringsinstans eller databasedelingsvært
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18. december 2018 12:16:19 PM 00:02:18 18. december 2018 12:18:37 PM STU_DP_S3_****backup 1 100% 1358 18% root 2018 12% :16:27 PM 00:02:10 Instant Recovery Disk Standard WIN-************* 0
1360 Sikkerhedskopiering udført 0 VMware Fuld NGNCloudADC NBCC 18. dec. 2018 12:16:48 PM 00:01:39 18. december 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248, 149654% 100 rod 23858 1358 335,098. dec , 18 2018:12:16 PM 48:00:01 Instant Recovery Disk Standard WIN-************* 39 0% 99.8%
1352 Snapshot Færdig 0 VMware - NGNCloudADC NBCC 18. dec. 2018 12:14:04 PM 00:02:01 18. december 2018 12:16:05 PM STU_DP_S3_****backup 1 100% 1352% 18% 2018:12 PM 14:14:00 Instant Recovery Disk Standard WIN-************* 01
1354 Sikkerhedskopiering udført 0 VMware Incremental NGNCloudADC NBCC 18. dec., 2018 12:14:34 PM 00:01:21 18. dec. 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 rod 147 100 % 23617 1352 500,817. dec , 18 2018:12:14 PM 34:00:01 Instant Recovery Disk Standard WIN-************* 21 0% 99.9%
1347 Snapshot Færdig 0 VMware - NGNCloudADC NBCC 18. dec. 2018 12:11:45 PM 00:02:08 18. december 2018 12:13:53 PM STU_DP_S3_****backup 1 100% 1347% 18% 2018:12 PM 11:45:00 Instant Recovery Disk Standard WIN-************* 02
1349 Sikkerhedskopiering udført 0 VMware Fuld NGNCloudADC NBCC 18. dec. 2018 12:12:02 PM 00:01:41 18. december 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215, 149653% 100 rod 23508 1347 316,319. dec , 18 2018:12:12 PM 02:00:01 Instant Recovery Disk Standard WIN-************* 41 0% 99.7%
1341 Snapshot Færdig 0 VMware - NGNCloudADC NBCC 18. dec. 2018 12:05:28 PM 00:04:53 18. december 2018 12:10:21 PM STU_DP_S3_****backup 1 100% 1341% 18% 2018:12 PM 05:28:00 Instant Recovery Disk Standard WIN-************* 04
1342 Backup Done 0 VMware Full_Rescan NGNCloudADC NBCC 18. dec. 2018 12:05:47 PM 00:04:24 18. dec. 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100 22999 1341 rod 70,380 18 2018 Dec 12, 05 47:00:04 PM 24:0:87.9 Instant Recovery Disk Standard WIN-************* 0 XNUMX% XNUMX%

1339 Snapshot Færdig 150 VMware - NGNCloudADC NBCC 18. december 2018 11:05:46 AM 00:00:53 18. december 2018 11:06:39 AM STU_DP_S3_****backup De root 1 100% 1339% 18% 2018:11 AM 05:46:00 Instant Recovery Disk Standard WIN-************* 00
1327 Snapshot Done 0 VMware - *******.********.cloud NBCC 17. december 2018 12:54:42 05:51:38 17. december 2018 6:46:20 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 Sikkerhedskopiering udført 0 VMware fuld *******.********.cloud NBCC 17. december 2018 12:55:10 05:29:21 17. december 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17. dec. 2018 12:55:10 PM 05:29:21 Øjeblikkelig gendannelsesdisk.-******** Standard 0-******** Standard 87.9%0IN XNUMX %
1136 Snapshot Done 0 VMware - *******.********.cloud NBCC 14. december 2018 4:48:22 04:05:16 14. december 2018 8:53:38 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 Done 0 VMware Full_Scan *******.********.cloud NBCC 14. december 2018 4:49:14 03:49:58 14. december 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Dec 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk.*** Standard 0%45.2-0***** XNUMX %

Acceleratoren giver dig mulighed for at reducere trafikken fra agenter, fordi Kun dataændringer overføres, det vil sige, at selv fulde backups ikke uploades helt, da medieserveren indsamler efterfølgende fulde backups fra inkrementelle backups.

Den mellemliggende server har sit eget lager, hvor den skriver en "cache" af data og vedligeholder en database til deduplikering.

Den komplette arkitektur ser således ud:

  1. Masterserveren administrerer konfiguration, opdateringer osv. og er placeret i skyen.
  2. Medieserveren (mellemliggende *nix-maskine) bør placeres tættest på de redundante systemer med hensyn til netværkstilgængelighed. Her foretages deduplikering af backups fra alle reserverede maskiner.
  3. På de sikkerhedskopierede maskiner er der agenter, der generelt kun sender det, der ikke er på dens lager, til medieserveren.

Det hele starter med en fuld scanning - dette er en fuldgyldig fuld backup. På dette tidspunkt tager medieserveren alt, deduplikerer det og overfører det til S3. Hastigheden til medieserveren er lav, men fra den er den højere. Den største begrænsning er serverens computerkraft.

Følgende sikkerhedskopier er lavet komplet set fra alle systemers synspunkt, men i virkeligheden er de noget i retning af syntetiske fuld backup. Det vil sige, at den faktiske overførsel og optagelse til medieserveren kun sker af de datablokke, som endnu ikke er stødt på i VM-sikkerhedskopier før. Og kun de datablokke, hvis hash ikke er i medieserverens deduplikeringsdatabase, overføres og optages i S3. Med enklere ord er dette noget, der aldrig er set i nogen backup af en enkelt VM før.

Under gendannelse anmoder medieserveren om de nødvendige deduplikerede objekter fra S3, rehydrerer dem og overfører dem til IRB-agenterne, dvs. det er nødvendigt at tage højde for mængden af ​​trafik under gendannelse, som vil være lig med den faktiske mængde data, der gendannes.

Sådan ser det ud:

Sådan komprimeres lagring af sikkerhedskopier i objektlager op til 90 %

Og her er endnu et stykke log169 job (0 i kø 0 Aktiv 0 Venter på at prøve igen 0 Suspenderet 0 Ufuldstændig 169 Udført — 1 udvalgte)

Job-id Type Status Status Detaljer Status Jobpolitik Jobplan Klient Media Server Starttid Forløbet Tid Sluttid Lagerenhed Forsøg Operation Kilobytes Filer Stinavn % Fuldført (estimeret) Job PID Ejer Kopi Overordnet Job ID KB/Sek Aktiv Start Aktiv Forløbet Robot Vault Profilsession ID-medie til at udskyde databevægelse uden for værtstype Masterprioritet deduplikeringshastighed Transportacceleratoroptimeringsinstans eller databasedelingsvært
- 1372 Gendan Udført 0 NBPR01 NBCC 19. dec. 2018 1:05:58 PM 00:04:32 19. december 2018 1:10:30 PM 1 14,380,577 1 100% 8548 1372. 70,567. 19. 2018. 1. 06. 00. 00. 04:30 :90000 PM XNUMX:XNUMX:XNUMX WIN-************* XNUMX

Dataintegriteten sikres af beskyttelsen af ​​selve S3 - der er god redundans der for at beskytte mod hardwarefejl såsom en død harddiskspindel.

Medieserveren har brug for 4 TB cache - dette er Veritas' minimumsstørrelsesanbefaling. Mere er bedre, men det var det, vi gjorde.

Total

Da en partner smed 3 GB i vores S20, gemte vi 60 GB, fordi vi sørger for tredobbelt geo-reservation af data. Nu er der meget mindre trafik, hvilket er godt både for kanalen og for lagertaksterne.

I dette tilfælde er ruterne lukket forbi det "store internet", men du kan drive trafik gennem VPN L2 over internettet, men det er bedre at installere medieserveren før udbyderens indgang.

Hvis du er interesseret i at lære om disse funktioner i vores russiske datacentre eller har spørgsmål om implementering derhjemme, så spørg i kommentarerne eller via e-mail [e-mail beskyttet].

Kilde: www.habr.com

Tilføj en kommentar