Våra turkiska kunder bad oss att korrekt konfigurera säkerhetskopiering för deras datacenter. Vi gör liknande projekt i Ryssland, men här handlade historien mer om att undersöka hur man bäst gör det.
Givet: det finns en lokal S3-lagring, det finns Veritas NetBackup, som har skaffat ny utökad funktionalitet för att flytta data till objektlagring, nu med stöd för deduplicering, och det är problem med ledigt utrymme i denna lokala lagring.
Uppgift: att göra allt så att processen med att lagra säkerhetskopior är snabb och billig.
Faktiskt, innan detta var allt i S3 helt enkelt filer, och dessa var kompletta avgjutningar av de kritiska maskinerna i datacentret. Det vill säga, det är inte särskilt optimerat, men allt fungerade i början. Nu är det dags att ta reda på det och göra det rätt.
Bilden visar vad vi kom fram till:
Som du kan se gjordes den första säkerhetskopieringen långsamt (70 Mb/s), och efterföljande säkerhetskopieringar av samma system var mycket snabbare.
Längre fram finns det faktiskt lite mer detaljer om vilka funktioner som finns.
Backuploggar för de som är redo att läsa en halv sida dumpFull med rescan
18 dec 2018 12:09:43 — Info bpbkar (pid=4452) accelerator skickade 14883996160 byte av 14883994624 byte till servern, optimering 0.0 %
18 dec 2018 12:10:07 - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik (flertrådad ström används) för (NBCC): skannad: 14570817 KB, CR skickad: 1760761 KB, CR skickad över FC: 0 KB, dedup: 87.9%, cache inaktiverad
full
18 dec 2018 12:13:18 — Info bpbkar (pid=2864) accelerator skickade 181675008 byte av 14884060160 byte till servern, optimering 98.8 %
18 dec 2018 12:13:40 PM - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik för (NBCC): skannat: 14569706 KB, CR skickat: 45145 KB, CR skickat över FC: 0 KB, dedup: 99.7 %, cache inaktiverad
Inkrementell
18 dec 2018 12:15:32 — Info bpbkar (pid=792) accelerator skickade 9970688 byte av 14726108160 byte till servern, optimering 99.9 %
18 dec 2018 12:15:53 PM - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik för (NBCC): skannat: 14383788 KB, CR skickat: 15700 KB, CR skickat över FC: 0 KB, dedup: 99.9 %, cache inaktiverad
full
18 dec 2018 12:18:02 — Info bpbkar (pid=3496) accelerator skickade 171746816 byte av 14884093952 byte till servern, optimering 98.8 %
18 dec 2018 12:18:24 PM - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistik för (NBCC): skannat: 14569739 KB, CR skickat: 34120 KB, CR skickat över FC: 0 KB, dedup: 99.8 %, cache inaktiverad
Vad är problemet
Kunderna vill göra säkerhetskopior så ofta som möjligt och lagra dem så billigt som möjligt. Det är bäst att lagra dem billigt i objektlagringar som S3, eftersom de är billigast till kostnaden för service per Megabyte varifrån du kan rulla tillbaka en säkerhetskopia inom rimlig tid. När det finns mycket backup blir det inte särskilt billigt, eftersom det mesta av lagringen upptas av kopior av samma data. När det gäller HaaS av turkiska kollegor kan lagringen förtätas med cirka 80-90 %. Det är uppenbart att detta relaterar specifikt till deras detaljer, men jag skulle definitivt räkna med minst 50% farfar.
För att lösa problemet har huvudleverantörerna länge gjort gateways till Amazon S3. Alla deras metoder är kompatibla med lokal S3 så länge de stöder Amazon API. I det turkiska datacentret görs säkerhetskopiering till vår S3, såväl som i T-III "Compressor" i Ryssland, eftersom detta arbetsschema har fungerat bra för oss.
Och vår S3 är helt kompatibel med Amazon S3 säkerhetskopieringsmetoder. Det vill säga att alla säkerhetskopieringsverktyg som stöder dessa metoder låter dig kopiera allt till sådan lagring "utanför lådan."
Veritas NetBackup lade till CloudCatalyst-funktionen:
Det vill säga, mellan maskinerna som behöver säkerhetskopieras och gatewayen finns det en mellanliggande Linux-server genom vilken säkerhetskopieringstrafik från SRK-agenterna passerar och dedupliceras i farten innan den överförs till S3. Om det tidigare fanns 30 säkerhetskopior på 20 GB med komprimering, nu (på grund av likheten mellan maskinerna) har deras volym blivit 90% mindre. Dedupliceringsmotorn används på samma sätt som vid lagring på vanliga diskar med Netbackup.
Här är vad som händer före mellanservern:
Vi testade och kom fram till att när det implementeras i våra datacenter sparar detta utrymme i S3-lagring för oss och för kunderna. Som ägare av kommersiella datacenter tar vi givetvis betalt efter den ockuperade volymen, men det är fortfarande väldigt lönsamt för oss också – eftersom vi börjar tjäna pengar på mer skalbara platser i mjukvaran, och inte på att hyra hårdvara. Tja, och detta är en minskning av de interna kostnaderna.
Loggar228 jobb (0 i kö 0 aktiv 0 väntar på nytt försök 0 avstängd 0 ofullständig 228 klar — 13 valda)
(Filter tillämpat [13])
Jobb-ID Typ Status Status Detaljer Status Jobbpolicy Jobbschema Klient Media Server Starttid Förfluten tid Sluttid Lagringsenhet Försök Operation Kilobyte Filer Sökväg % slutfört (uppskattat) Jobb PID Ägare Kopiera Förälder Jobb-ID KB/sek Aktiv Start Aktiv Förfluten Robotvalv-profilsession ID-media för att mata ut datarörelse utanför värdtyp Huvudprioritet Dedupliceringshastighet Transportacceleratoroptimeringsinstans eller värd för databasdelning
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 Dec 2018 12:16:19 PM 00:02:18 Dec 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 Säkerhetskopiering klar 0 VMware Full 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 1358, 335,098 % 18 2018 12 16 48 00 dec , 01 39:0:99.8 PM 99:XNUMX:XNUMX Instant Recovery Disk Standard WIN-************* XNUMX XNUMX% XNUMX%
1352 Snapshot Klar 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% 1352% dec 18% 2018:12 PM 14:14:00 Instant Recovery Disk Standard WIN-************* 01
1354 Säkerhetskopiering klar 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 147 100 rot 23617 1352 500,817 18 2018 12 dec , 14 34:00:01 PM 21:0:99.9 Instant Recovery Disk Standard WIN-************* 100 XNUMX% XNUMX%
1347 Snapshot Klar 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% 1347% dec 18% 2018:12 PM 11:45:00 Instant Recovery Disk Standard WIN-************* 02
1349 Säkerhetskopiering klar 0 VMware Full 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 1347, 316,319 % 18 2018 12 12 02 00 dec , 01 41:0:99.7 PM 99:XNUMX:XNUMX Instant Recovery Disk Standard WIN-************* XNUMX XNUMX% XNUMX%
1341 Snapshot Klar 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% 1341% dec 18% 2018:12 PM 05:28:00 Instant Recovery Disk Standard WIN-************* 04
1342 Säkerhetskopiering klar 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_****säkerhetskopiering 1 14,535,151 149653 100 rot 22999 1341 70,380 18 dec 2018 , 12 05:47:00 PM 04:24:0 Instant Recovery Disk Standard WIN-************* 87.9 0% XNUMX%
1339 Snapshot Klar 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% 1339% 18% 2018% 11:05 AM 46:00:00 Instant Recovery Disk Standard WIN-************* 53
1327 Snapshot Klar 0 VMware - *******.********.cloud NBCC 17 dec 2018 12:54:42 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 Klar 0 VMware Full *******.********.cloud NBCC 17 dec 2018 12:55:10 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 0%87.9IN 0 %
1136 Snapshot Klar 0 VMware - *******.********.cloud NBCC 14 dec 2018 4:48:22 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 Säkerhetskopiering klar 0 VMware Full_Scan *******.********.cloud NBCC 14 dec 2018 4:49:14 03:49:58 14 dec 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100 26438 1136% 15,963 root 14 2018 4 49 dec 14 03:49:58 0:45.2:0 Instant Recovery Disk. XNUMX*** Standard XNUMX%XNUMX-XNUMX***** XNUMX %
Med acceleratorn kan du minska trafiken från agenter, eftersom Endast dataändringar överförs, det vill säga inte ens fullständiga säkerhetskopior laddas upp helt, eftersom mediaservern samlar in efterföljande fullständiga säkerhetskopior från inkrementella säkerhetskopior.
Den mellanliggande servern har sin egen lagring, där den skriver en "cache" av data och underhåller en databas för deduplicering.
Hela arkitekturen ser ut så här:
- Masterservern hanterar konfiguration, uppdateringar etc. och är placerad i molnet.
- Mediaservern (mellanliggande *nix-maskin) bör placeras närmast de redundanta systemen vad gäller nätverkstillgänglighet. Här görs deduplicering av säkerhetskopior från alla reserverade maskiner.
- På de säkerhetskopierade maskinerna finns agenter som vanligtvis bara skickar till mediaservern det som inte finns i dess lagring.
Det hela börjar med en fullständig genomsökning - detta är en fullfjädrad fullständig säkerhetskopia. Vid denna tidpunkt tar mediaservern allt, deduplicerar det och överför det till S3. Hastigheten till mediaservern är låg, men från den är den högre. Den huvudsakliga begränsningen är serverns datorkraft.
Följande säkerhetskopior görs kompletta ur alla systems synvinkel, men i verkligheten är de ungefär som syntetiska fullständiga säkerhetskopior. Det vill säga, den faktiska överföringen och inspelningen till mediaservern sker endast av de datablock som ännu inte har påträffats i VM-säkerhetskopior tidigare. Och endast de datablock vars hash inte finns i mediaserverns dedupliceringsdatabas överförs och registreras i S3. Med enklare ord är detta något som aldrig har setts i någon backup av en enda VM tidigare.
Under återställning begär mediaservern de nödvändiga deduplicerade objekten från S3, rehydrerar dem och överför dem till IRB-agenterna, d.v.s. det är nödvändigt att ta hänsyn till trafikvolymen under återställning, vilket kommer att vara lika med den faktiska datavolymen som återställs.
Så här ser det ut:
Och här är en annan bit stock169 jobb (0 i kö 0 aktiv 0 väntar på nytt försök 0 avstängd 0 ofullständig 169 klar — 1 valda)
Jobb-ID Typ Status Status Detaljer Status Jobbpolicy Jobbschema Klient Media Server Starttid Förfluten tid Sluttid Lagringsenhet Försök Operation Kilobyte Filer Sökväg % slutfört (uppskattat) Jobb PID Ägare Kopiera Förälder Jobb-ID KB/sek Aktiv Start Aktiv Förfluten Robotvalv-profilsession ID-media för att mata ut datarörelse utanför värdtyp Huvudprioritet Dedupliceringshastighet Transportacceleratoroptimeringsinstans eller värd för databasdelning
- 1372 Återställning Klar 0 NBPR01 NBCC 19 dec 2018 1:05:58 PM 00:04:32 19 dec 2018 1:10:30 PM 1 14,380,577 1 100% 8548 1372 70,567% 19 2018 1:06 :00 PM 00:04:30 WIN-************* 90000
Dataintegriteten säkerställs genom skyddet av S3 själv - det finns bra redundans där för att skydda mot hårdvarufel som en död hårddiskspindel.
Mediaservern behöver 4 TB cache - det här är Veritas rekommendation om minsta storlek. Mer är bättre, men det är vad vi gjorde.
Totalt
När en partner kastade 3 GB i vår S20 lagrade vi 60 GB, eftersom vi tillhandahåller tredubbla georeservationer av data. Nu är det mycket mindre trafik, vilket är bra både för kanalen och för lagringstarifferna.
I det här fallet är rutterna stängda förbi det "stora Internet", men du kan driva trafik genom VPN L2 över Internet, men det är bättre att installera mediaservern innan leverantörens entré.
Om du är intresserad av att lära dig om dessa funktioner i våra ryska datacenter eller har frågor om implementering hemma, fråga i kommentarerna eller via e-post [e-postskyddad].
Källa: will.com