🥇Hvordan komprimere opp til 90% av lagringen av sikkerhetskopier i objektlagring

Våre tyrkiske kunder ba oss om å sette opp backupen riktig for datasenteret. Vi har gjort lignende prosjekter i Russland, men her handlet det mer om å utforske hvordan vi kan gjøre det best mulig.

Gitt: vi har et lokalt S3-lager, vi har Veritas NetBackup, som har fått utvidet funksjonalitet for flytting av data til objektlagre, nå med støtte for deduplisering, og vi har et problem med ledig plass i dette lokale lageret.

Oppgaven: gjøre det slik at prosessen for lagring av sikkerhetskopier er rask og rimelig.

Tidligere ble alt lagt ut i S3 som filer, og det var komplette kloner av kritiske maskiner i datasenteret. Så det var ikke særlig optimalisert, men det fungerte i starten. Nå har tiden kommet til å finne ut av det og gjøre det riktig.

På bildet er det vi har oppnådd:

Som man kan se, ble den første sikkerhetskopien laget sakte (70 Mb/s), mens påfølgende sikkerhetskopier av de samme systemene ble betydelig raskere.

Her er litt mer informasjon om hvilke spesialiteter som finnes.

Backuplogger for de som er klare til å lese en hel side med dumpFull med rescanning
18. des 2018 12:09:43 PM — Info bpbkar (pid=4452) akselerator sendte 14883996160 byte ut av 14883994624 byte til server, optimalisering 0.0%
18. des 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistikk (flere tråder brukt) for (NBCC): skannet: 14570817 KB, CR sendt: 1760761 KB, CR sendt over FC: 0 KB, dedup: 87.9%, cache deaktivert

Full
18. des 2018 12:13:18 PM — Info bpbkar (pid=2864) akselerator sendte 181675008 byte ut av 14884060160 byte til server, optimalisering 98.8%
18. des 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistikk for (NBCC): skannet: 14569706 KB, CR sendt: 45145 KB, CR sendt over FC: 0 KB, dedup: 99.7%, cache deaktivert

Inkrementell
18. des 2018 12:15:32 PM — Info bpbkar (pid=792) akselerator sendte 9970688 byte ut av 14726108160 byte til server, optimalisering 99.9%
18. des 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistikk for (NBCC): skannet: 14383788 KB, CR sendt: 15700 KB, CR sendt over FC: 0 KB, dedup: 99.9%, cache deaktivert

Full
18. des 2018 12:18:02 PM — Info bpbkar (pid=3496) akselerator sendte 171746816 byte ut av 14884093952 byte til server, optimalisering 98.8%
18. des 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO Statistikk for (NBCC): skannet: 14569739 KB, CR sendt: 34120 KB, CR sendt over FC: 0 KB, dedup: 99.8%, cache deaktivert

Hva er problemet

Kundene ønsker å ta sikkerhetskopier så ofte som mulig og lagre dem så billig som mulig. De mest kostnadseffektive lagringsløsningene for dette er objektsystemer som S3, fordi de gir den laveste kostnaden for vedlikehold per megabyte, fra hvor man kan gjenopprette sikkerhetskopier innen rimelig tid. Når det er mange sikkerhetskopier, blir dette ikke så billig, ettersom store deler av lagringsplassen okkuperes av kopier av de samme dataene. For HaaS kan våre tyrkiske kolleger komprimere lagringen omtrent 80-90%. Det er åpenbart at dette gjelder spesifikt for deres kontekst, men jeg ville definitivt regnet med minst 50% deduplisering.

For å løse dette problemet har de viktigste leverandørene lenge laget porter til Amazons S3. Alle deres metoder er kompatible med lokale S3-løsninger, så lenge de støtter Amazons API. I det tyrkiske datasenteret blir sikkerhetskopier gjort til vår S3, på samme måte som i T-III «Kompressor» i Russland, fordi denne arbeidsmetoden har vist seg å fungere godt for oss.

Vår S3 er helt kompatibel med sikkerhetskopieringsmetodene til Amazon S3. Dette betyr at alle verktøy for sikkerhetskopiering som støtter disse metodene kan kopiere alt til en lignende lagringsløsning «rett ut av boksen».

I Veritas NetBackup har de laget en funksjon kalt CloudCatalyst:

Det betyr at det står en mellomliggende Linux-server mellom maskinene som må sikkerhetskopieres og porten, gjennom hvilken sikkerhetskopieringstrafikken fra SRK-agenter passerer, og dedupliseringen av dem skjer «on-the-fly» før de overføres til S3. Hvis det tidligere var 30 sikkerhetskopier på 20 GB med komprimering, så har volumet nå (på grunn av likheten mellom maskinene) blitt 90% mindre. Den samme dedupliseringsmotoren brukes som ved lagring på vanlige disker med NetBackup.

Slik ser det ut før den mellomliggende serveren:

Vi har testet dette og konkludert med at innføringen i våre datasentre gir lagringsbesparelser i S3 for oss og for kundene våre. Som eier av kommersielle datasentre tar vi selvfølgelig betalt basert på det opptatte volumet, men det er fortsatt veldig fordelaktig for oss også – fordi vi begynner å tjene mer på mer skalerbare programvareplasser, snarere enn på leie av maskinvare. Og dette reduserer interne kostnader.

Logger228 jobber (0 køet, 0 aktive, 0 venter på gjenoppretting, 0 suspendert, 0 ufullstendige, 228 fullført – 13 valgt)
(Filter brukt [13])

Job Id Type Statuss Statuss Detaljer Status Jobb Policy Jobbplan Klient Medie Server Starttid Forløpt tid Sluttid Lagringsenhet Forsøk Operasjon Kilobyte Filer Sti % Komplett (Estimert) Jobb PID Eier Kopier Foreldres Jobb ID KB/Sek Aktiv Start Aktiv Forløpt Robot Vault Profil Økt ID Medie å kaste Dataflyt Off-Host Type Master Prioritet Deduplication Rate Transport Accelerator Optimalisering Instans eller Database Del Vert
— 1358 Snapshot Fullført 0 VMware — NGNCloudADC NBCC 18. des 2018 12:16:19 00:02:18 18. des 2018 12:18:37 STU_DP_S3_****backup 1 100% root 1358 18. des 2018 12:16:27 00:02:10 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1360 Backup Fullført 0 VMware Full NGNCloudADC NBCC 18. des 2018 12:16:48 00:01:39 18. des 2018 12:18:27 STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18. des 2018 12:16:48 00:01:39 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 99.8% 99%
1352 Snapshot Fullført 0 VMware — NGNCloudADC NBCC 18. des 2018 12:14:04 00:02:01 18. des 2018 12:16:05 STU_DP_S3_****backup 1 100% root 1352 18. des 2018 12:14:14 00:01:51 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1354 Backup Fullført 0 VMware Inkrementell NGNCloudADC NBCC 18. des 2018 12:14:34 00:01:21 18. des 2018 12:15:55 STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18. des 2018 12:14:34 00:01:21 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 99.9% 100%
1347 Snapshot Fullført 0 VMware — NGNCloudADC NBCC 18. des 2018 12:11:45 00:02:08 18. des 2018 12:13:53 STU_DP_S3_****backup 1 100% root 1347 18. des 2018 12:11:45 00:02:08 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1349 Backup Fullført 0 VMware Full NGNCloudADC NBCC 18. des 2018 12:12:02 00:01:41 18. des 2018 12:13:43 STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18. des 2018 12:12:02 00:01:41 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 99.7% 99%
1341 Snapshot Fullført 0 VMware — NGNCloudADC NBCC 18. des 2018 12:05:28 00:04:53 18. des 2018 12:10:21 STU_DP_S3_****backup 1 100% root 1341 18. des 2018 12:05:28 00:04:53 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1342 Backup Fullført 0 VMware Full_Rescan NGNCloudADC NBCC 18. des 2018 12:05:47 00:04:24 18. des 2018 12:10:11 STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18. des 2018 12:05:47 00:04:24 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 87.9% 0%

1339 Snapshot Fullført 150 VMware — NGNCloudADC NBCC 18. des 2018 11:05:46 00:00:53 18. des 2018 11:06:39 STU_DP_S3_****backup 1 100% root 1339 18. des 2018 11:05:46 00:00:53 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1327 Snapshot Fullført 0 VMware — *******.********.cloud NBCC 17. des 2018 12:54:42 05:51:38 17. des 2018 18:46:20 STU_DP_S3_****backup 1 100% root 1327 17. des 2018 12:54:42 05:51:38 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1328 Backup Fullført 0 VMware Full *******.********.cloud NBCC 17. des 2018 12:55:10 05:29:21 17. des 2018 18:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17. des 2018 12:55:10 05:29:21 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 87.9% 0%
1136 Snapshot Fullført 0 VMware — *******.********.cloud NBCC 14. des 2018 16:48:22 04:05:16 14. des 2018 20:53:38 STU_DP_S3_****backup 1 100% root 1136 14. des 2018 16:48:22 04:05:16 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0
1140 Backup Fullført 0 VMware Full_Scan *******.********.cloud NBCC 14. des 2018 16:49:14 03:49:58 14. des 2018 20:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14. des 2018 16:49:14 03:49:58 Umiddelbar gjenoppretting Disk Standard WIN-*********** 0 45.2% 0%

Akseleratoren lar deg å redusere trafikken fra agenter, da det kun sendes endringer i dataene, det vil si at selv fullstendige sikkerhetskopier ikke overføres helt, ettersom medieserveren samler de påfølgende fullstendige sikkerhetskopiene fra inkrementelle sikkerhetskopier.

Mellomserveren har sitt eget lagringsrom, hvor den skriver "cache" data og holder basen for deduplisering.

I det komplette arkitekturen ser det slik ut:

Mester-serveren styrer konfigurasjonen, oppdateringene og annet, og ligger i skyen.
Medieserveren (mellomliggende *nix-maskin) bør være plassert nærmest de systemene som skal sikkerhetskopieres når det gjelder nettverks tilgjengelighet. Her utføres deduplisering av sikkerhetskopier fra alle maskiner som sikkerhetskopieres.
På de sikkerhetskopierte maskinene finnes det agenter som i all hovedsak sender til medieserveren kun det som ikke finnes i lagringsplassen.

Alt begynner med en full skanning — dette er en fullstendig backup. På dette tidspunktet henter medieserveren alt, gjør deduplisering og overfører til S3. Hastigheten til medieserveren er lav, mens hastigheten fra den er høyere. Den viktigste begrensningen er serverens datakraft.

De påfølgende sikkerhetskopiene gjøres fra alle systemers perspektiv komplette, men i virkeligheten er dette noe som ligner på syntetiske komplette sikkerhetskopier. Det vil si at den faktiske overføringen og registreringen til medieserveren kun skjer for de datablokkene som ikke har blitt møtt i sikkerhetskopiene til VM tidligere. Og overføringen og lagringen til S3 skjer bare for de datablokkene hvis hasher ikke finnes i medieserverens dedupliseringsbase. Med enklere ord — det som ikke har vært møtt i noen sikkerhetskopi av noen VM tidligere.

Ved gjenoppretting ber medieserveren om nødvendige dedupliserte objekter fra S3, regenererer dem og sender til agentene SRK, det vil si at man må ta hensyn til volumet av trafikken ved gjenoppretting, som vil være lik det faktiske volumet av gjenopprettede data.

Slik ser det ut:

Og her er en annen del av loggene169 Jobber (0 Køet 0 Aktiv 0 Venter på Nytt Forsøk 0 Suspendert 0 Incomplete 169 Utført — 1 valgt)

Dataintegriteten sikres av beskyttelsen til S3 — der er det god redundans for å beskytte mot maskinvarefeil som en defekt harddiskspindle.

Media-server det er nødvendig med 4 TB cache — dette er Veritas' anbefaling for minimumsvolum. Helst mer, men vi gjorde nettopp slik.

Resultat

Når partneren sendte 20 GB til vår S3, lagret vi 60 GB, fordi vi tilbyr tredobbelt geografisk databeskyttelse. Nå er trafikken mye mindre, noe som er bra både for kanalen og for lagringspriser.

I dette tilfellet er rutene stengt mot «det store Internettet», men man kan styre trafikk også gjennom VPN L2 via Internettet, men det er best å plassere medieserveren før leverandørens inngang.

Hvis du er interessert i å vite mer om disse funksjonene i våre russiske datasentre, eller har spørsmål om implementering hos deg selv — spør gjerne i kommentarfeltet eller send en e-post til ekorotkikh@croc.ru.

Kilde: habr.com

Hvordan komprimere lagring av sikkerhetskopier i objekter til opptil 90%

Hva er problemet

Resultat