Vores tyrkiske kunder bad os om at konfigurere backup korrekt for datacentret. Vi laver sådanne projekter i Rusland, men her handlede historien mere om at finde ud af, hvordan man gør det bedst.
Givet: der er et lokalt S3-lager, der er Veritas NetBackup, som har fået ny udvidet funktionalitet til at flytte data til objektlagre nu med støtte for deduplication, og der er et problem med ledig plads i dette lokale lager.
Opgaven: at sikre, at backup-processen er hurtig og billig.
Faktisk blev der tidligere kun lagt filer i S3, og dette var komplette snapshots af kritiske maskiner i datacentret. Så det var ikke nødvendigvis meget optimeret, men alt fungerede ved starten. Nu er det tid til at forstå det rigtigt og gøre det korrekt.
På billedet er det, vi er nået til:
Som man kan se, blev den første backup lavet langsomt (70 MB/s), mens efterfølgende backups af de samme systemer var betydeligt hurtigere.
Faktisk er her lidt flere detaljer om, hvilke særlige aspekter der er.
Backup-logs for dem, der er klar til at læse halve sider af dumpsFuldt med rescan
18. dec 2018 kl. 12:09:43 — Info bpbkar (pid=4452) accelerator sendte 14883996160 bytes ud af 14883994624 bytes til serveren, optimering 0.0%
18. dec 2018 kl. 12:10:07 — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistiks (multitrådet stream brugt) for (NBCC): scannet: 14570817 KB, CR sendt: 1760761 KB, CR sendt over FC: 0 KB, dedup: 87.9%, cache deaktiveret
Full
18. dec 2018 kl. 12:13:18 — Info bpbkar (pid=2864) accelerator sendte 181675008 bytes ud af 14884060160 bytes til serveren, optimering 98.8%
18. dec 2018 kl. 12:13:40 — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistiks for (NBCC): scannet: 14569706 KB, CR sendt: 45145 KB, CR sendt over FC: 0 KB, dedup: 99.7%, cache deaktiveret
Inkrementel
18. dec 2018 kl. 12:15:32 — Info bpbkar (pid=792) accelerator sendte 9970688 bytes ud af 14726108160 bytes til serveren, optimering 99.9%
18. dec 2018 kl. 12:15:53 — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistiks for (NBCC): scannet: 14383788 KB, CR sendt: 15700 KB, CR sendt over FC: 0 KB, dedup: 99.9%, cache deaktiveret
Full
18. dec 2018 kl. 12:18:02 — Info bpbkar (pid=3496) accelerator sendte 171746816 bytes ud af 14884093952 bytes til serveren, optimering 98.8%
18. dec 2018 kl. 12:18:24 — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistiks for (NBCC): scannet: 14569739 KB, CR sendt: 34120 KB, CR sendt over FC: 0 KB, dedup: 99.8%, cache deaktiveret
Hvad er problemet
Kunder ønsker at foretage backup så ofte som muligt og opbevare det så billigt som muligt. Det er bedst at opbevare dem billigt i objektlagre som S3, da de har de laveste driftsomkostninger per megabyte, fra hvor man kan genskabe backupen inden for rimelig tid. Når der er mange backups, bliver det ikke så billigt, da en stor del af lageret optages af kopier af de samme data. I tilfælde af HaaS kan de tyrkiske kolleger komprimere opbevaringen med cirka 80-90%. Det er klart, at dette kun gælder deres specifikationer, men jeg ville helt klart forvente en deduplikeringsrate på mindst 50%.
For at løse problemet har de vigtigste leverandører længe lavet gateways til Amazons S3. Alle deres metoder er kompatible med lokale S3, hvis de understøtter Amazons API. I det tyrkiske datacenter laves backup til vores S3, ligesom i T-III "Kompressoren" i Rusland, da denne arbejdsmetode har vist sig effektiv for os.
Og vores S3 er helt kompatibel med backupmetoderne til Amazon S3. Det vil sige, at alle værktøjer til backup, der understøtter disse metoder, gør det muligt at kopiere alt til et lignende lager "ud af boksen".
I Veritas NetBackup har de lavet en funktion ved navn CloudCatalyst:
Det vil sige, at der mellem maskinerne, der skal backs up, og gatewayen står en mellemvirkende Linux-server, gennem hvilken backup-trafikken fra SRK-agenterne passerer og derefter deduplikeres "on the fly" før overførsel til S3. Hvis der tidligere var 30 backups á 20 GB med kompression, er de nu (på grund af maskinernes lighed) blevet 90% mindre i volumen. Den samme deduplikeringsmotor bruges som til opbevaring på almindelige diske med NetBackup-værktøjerne.
Her er, hvad der sker før den mellemvirkende server:
Vi har testet og konkluderet, at implementeringen i vores datacentre giver os og vores kunder besparelser i lagerpladsen i S3. Som ejer af kommercielle datacentre tager vi selvfølgelig betaling for den optagne plads, men det er stadig meget fordelagtigt for os, da vi begynder at tjene penge på mere skalerbare områder i softwaren, frem for at leje hardware. Og det reducerer jo også vores interne omkostninger.
Logs228 job (0 i kø 0 aktive 0 venter på genoptagelse 0 suspenderede 0 ufuldstændige 228 færdige — 13 udvalgte)
(Filter anvendt [13])
Job Id Type State Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Pathname % Complete (Estimated) Job PID Owner Copy Parent Job ID KB/S Active Start Active Elapsed Robot Vault Profile Session ID Media to Eject Data Movement Off-Host Type Master Priority Deduplication Rate Transport Accelerator Optimization Instance or Database Share Host
— 1358 Snapshot Udført 0 VMware — NGNCloudADC NBCC 18. dec 2018 12:16:19 PM 00:02:18 18. dec 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18. dec 2018 12:16:27 PM 00:02:10 Instant Recovery Disk Standard WIN-*********** 0
1360 Backup Udført 0 VMware Fuldt NGNCloudADC NBCC 18. dec 2018 12:16:48 PM 00:01:39 18. dec 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18. dec 2018 12:16:48 PM 00:01:39 Instant Recovery Disk Standard WIN-*********** 0 99.8% 99%
1352 Snapshot Udført 0 VMware — NGNCloudADC NBCC 18. dec 2018 12:14:04 PM 00:02:01 18. dec 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18. dec 2018 12:14:14 PM 00:01:51 Instant Recovery Disk Standard WIN-*********** 0
1354 Backup Udført 0 VMware Inkrementel 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 147 100% 23617 root 1352 500,817 18. dec 2018 12:14:34 PM 00:01:21 Instant Recovery Disk Standard WIN-*********** 0 99.9% 100%
1347 Snapshot Udført 0 VMware — NGNCloudADC NBCC 18. dec 2018 12:11:45 PM 00:02:08 18. dec 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18. dec 2018 12:11:45 PM 00:02:08 Instant Recovery Disk Standard WIN-*********** 0
1349 Backup Udført 0 VMware Fuldt NGNCloudADC NBCC 18. dec 2018 12:12:02 PM 00:01:41 18. dec 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18. dec 2018 12:12:02 PM 00:01:41 Instant Recovery Disk Standard WIN-*********** 0 99.7% 99%
1341 Snapshot Udført 0 VMware — NGNCloudADC NBCC 18. dec 2018 12:05:28 PM 00:04:53 18. dec 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18. dec 2018 12:05:28 PM 00:04:53 Instant Recovery Disk Standard WIN-*********** 0
1342 Backup Udført 0 VMware Fuldt_Overscan 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 root 1341 70,380 18. dec 2018 12:05:47 PM 00:04:24 Instant Recovery Disk Standard WIN-*********** 0 87.9% 0%
1339 Snapshot Udført 150 VMware — NGNCloudADC NBCC 18. dec 2018 11:05:46 AM 00:00:53 18. dec 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18. dec 2018 11:05:46 AM 00:00:53 Instant Recovery Disk Standard WIN-*********** 0
1327 Snapshot Udført 0 VMware — *******.********.cloud NBCC 17. dec 2018 12:54:42 PM 05:51:38 17. dec 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17. dec 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Backup Udført 0 VMware Fuldt *******.********.cloud NBCC 17. dec 2018 12:55:10 PM 05:29:21 17. dec 2018 6:24:31 PM 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 Instant Recovery Disk Standard WIN-*********** 0 87.9% 0%
1136 Snapshot Udført 0 VMware — *******.********.cloud NBCC 14. dec 2018 4:48:22 PM 04:05:16 14. dec 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14. dec 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Backup Udført 0 VMware Fuldt_Scan *******.********.cloud NBCC 14. dec 2018 4:49:14 PM 03:49:58 14. dec 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14. dec 2018 4:49:14 PM 03:49:58 Instant Recovery Disk Standard WIN-*********** 0 45.2% 0%
Acceleratoren reducerer trafik fra agenter, da der kun overføres ændringer i dataene, hvilket betyder, at selvom der laves fulde sikkerhedskopier, sendes de ikke i sin helhed, fordi medieserveren samler de efterfølgende fulde sikkerhedskopier fra inkrementelle sikkerhedskopier.
Den mellemledsserver har sit eget lager, hvor den skriver "cache" af data og opbevarer en database til deduplicering.
I den fulde arkitektur ser det således ud:
- Masterserveren styrer konfigurationen, opdateringerne og andet, og den er placeret i skyen.
- Medieserveren (den mellemledte *nix-maskine) skal befinde sig så tæt som muligt på de systemer, der skal sikkerhedskopieres, med hensyn til netværksadgang. Her udføres deduplicering af sikkerhedskopier fra alle de systemer, der skal sikkerhedskopieres.
- På de sikkerhedskopierede maskiner er der agenter, der i almindelighed kun sender til medieserveren det, der ikke er i dens lager.
Det hele begynder med en fuld scanning - det er en komplet fuld sikkerhedskopiering. På dette tidspunkt henter medieserveren alt, udfører deduplicering og sender det til S3. Hastigheden til medieserveren er lav, men højere fra den. Den vigtigste begrænsning er den beregningsmæssige kraft fra serveren.
De følgende sikkerhedskopier laves set fra alle systemer som komplette, men i virkeligheden er det noget, der ligner syntetiske fulde sikkerhedskopier. Det vil sige, at den faktiske overførsel og skrivning til medieserveren kun sker for de datablokke, der ikke tidligere er stødt på i sikkerhedskopier af VM'er. Og overførslen og skrivningen til S3 sker kun for de datablokke, hvis hash ikke findes i medieserverens dedupliceringsdatabase. Med enklere ord - hvad der ikke er set i nogen sikkerhedskopi af nogen VM før.
Ved gendannelse anmoder medieserveren om de nødvendige deduplicerede objekter fra S3, rehydreres de og sendes til agenterne i SRK, dvs. man skal tage højde for trafikvolumen ved gendannelse, som vil svare til det reelle volumen af data, der skal gendannes.
Sådan ser det ud:
Og her er endnu et stykke logfiler169 Jobs (0 Køet 0 Aktiv 0 Venter på Forsøg 0 Suspenderet 0 Incomplete 169 Færdig - 1 valgt)
Job Id Type State Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Pathname % Complete (Estimated) Job PID Owner Copy Parent Job ID KB/S Active Start Active Elapsed Robot Vault Profile Session ID Media to Eject Data Movement Off-Host Type Master Priority Deduplication Rate Transport Accelerator Optimization Instance or Database Share Host
— 1372 Gendannelse Færdig 0 nbpr01 NBCC 19. dec 2018 13:05:58 00:04:32 19. dec 2018 13:10:30 1 14,380,577 1 100% 8548 root 1372 70,567 19. dec 2018 13:06:00 00:04:30 WIN-*********** 90000
Datas integritet sikres af beskyttelsen af selve S3 - der er god redundans for at beskytte mod hardwarefejl som en ødelagt spindel i harddisken.
Medier-server der er behov for 4 TB cache - det er Veritas' anbefaling til minimum volumen. Bedre mere, men vi har gjort det sådan.
Resultat
Når partneren kunne overføre 20 GB til vores S3, opbevarede vi 60 GB, da vi sikrer en tredobbelt geografisk databeskyttelse. Nu er trafikken betydeligt lavere, hvilket er godt både for båndbredden og for opbevaringsafgiften.
I dette tilfælde er ruterne lukket udenom det "store internet", men det er muligt at dirigere trafikken via VPN L2 gennem internettet, men det er bedst at placere medieserveren før udbyderens indgang.
Hvis du er interesseret i at vide mere om disse funktioner i vores russiske datacentre, eller har spørgsmål om implementering hos dig selv — spørg i kommentarerne eller på mail til ekorotkikh@croc.ru.
Kilde: habr.com
