🥇Hur man utnyttjar upp till 90% av lagringen för säkerhetskopior i objektlagring

Våra turkiska kunder bad oss att ställa in backupen korrekt för datacentret. Vi gör liknande projekt i Ryssland, men här handlar historien mer om att undersöka hur man gör det på bästa sätt.

Givet: det finns en lokal S3-lagring, det finns Veritas NetBackup som har fått nya avancerade funktioner för att flytta data till objektlagring med stöd för deduplicering, och det finns ett problem med utrymmet i denna lokala lagring.

Uppgift: göra så att backup-processen är snabb och kostnadseffektiv.

Tidigare lagrades allt i S3 helt enkelt som filer, och dessa var fullständiga kopior av kritiska maskiner i datacentret. Det var alltså inte särskilt optimerat, men allt fungerade från början. Nu är det dags att förstå och göra det rätt.

På bilden ser vi vad vi har kommit fram till:

Som vi ser gjordes den första backupen långsamt (70 MB/s), medan efterföljande backupar av samma system blev mycket snabbare.

Här är lite mer detaljer om vilka egenskaper som finns.

Backup-loggar för den som är beredd att läsa en och en halv sida av dumpen.Fullt med omskanning
Dec 18, 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator skickade 14883996160 bytes av 14883994624 bytes till servern, 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-trådad ström använd) för (NBCC): skannat: 14570817 KB, CR skickat: 1760761 KB, CR skickat över FC: 0 KB, dedup: 87.9%, cache inaktiverad.

Full
Dec 18, 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator skickade 181675008 bytes av 14884060160 bytes till servern, 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 för (NBCC): skannat: 14569706 KB, CR skickat: 45145 KB, CR skickat över FC: 0 KB, dedup: 99.7%, cache inaktiverad.

Inkrementell
Dec 18, 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator skickade 9970688 bytes av 14726108160 bytes till servern, 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 för (NBCC): skannat: 14383788 KB, CR skickat: 15700 KB, CR skickat över FC: 0 KB, dedup: 99.9%, cache inaktiverad.

Full
Dec 18, 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator skickade 171746816 bytes av 14884093952 bytes till servern, 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 för (NBCC): skannat: 14569739 KB, CR skickat: 34120 KB, CR skickat över FC: 0 KB, dedup: 99.8%, cache inaktiverad.

Vad är problemet

Kunder vill göra backup så ofta som möjligt och lagra dem så billigt som möjligt. Det är allra billigast att lagra dem i objektlagring som S3, eftersom de har den lägsta kostnaden för underhåll per megabyte och är tillgängliga för att återställa backup inom rimlig tid. När det finns många backup gör det inte så billigt längre, eftersom det mesta av lagringen upptas av kopior av samma data. I fallet med HaaS kan de turkiska kollegorna komprimera lagring med ungefär 80-90%. Det är uppenbart att detta gäller deras specifika behov, men jag skulle definitivt räkna med åtminstone 50% deduplicering.

För att lösa problemet har de främsta leverantörerna länge skapat gateways till Amazons S3. Alla deras metoder är kompatibla med lokala S3, förutsatt att de stödjer Amazons API. I det turkiska datacentret görs backupen till vår S3, precis som i T-III "Kompressor" i Ryssland, eftersom denna arbetsmetod har visat sig effektiv för oss.

Vår S3 är helt kompatibel med backupmetoderna för Amazon S3. Det innebär att alla backupverktyg som stöder dessa metoder kan kopiera allt till en liknande lagring "out of the box".

I Veritas NetBackup har de skapat en funktion som heter CloudCatalyst:

Det vill säga, mellan de maskiner som ska säkerhetskopieras och gatewayen står en mellanliggande Linux-server, genom vilken backuptrafik från SRK-agenterna går och där deduplicering görs "on-the-fly" innan de överförs till S3. Om det tidigare fanns 30 backupkopior på 20 GB med komprimering, har det nu (på grund av maskinernas likhet) blivit 90% mindre i volym. Den dedupliceringsmotor som används är densamma som för lagring på vanliga diskar med hjälp av NetBackup.

Så här ser det ut innan den mellanliggande servern:

Vi har testat och kommit fram till att implementeringen i våra datacenter ger oss en platsbesparing i S3-lagring för oss och våra kunder. Som ägare av kommersiella datacenter tar vi förstås betalt baserat på den upptagna volymen, men det är fortfarande mycket fördelaktigt för oss också — eftersom vi börjar tjäna pengar på mer skalbara platser i mjukvaran, snarare än på hyra av hårdvara. Och detta minskar också våra interna kostnader.

Loggar228 jobb (0 i kö 0 aktiva 0 väntande på omförsök 0 avbrutna 0 ofullständiga 228 klara — 13 valda)
(Filter tillämpat [13])

Job Id Typ Status Statusdetaljer Status Jobpolicy Jobschema Klient Media Server Starttid Förfluten tid Sluttid Lagringsenhet Försök Operation Kilobyte Filer Vägar % Slutfört (Beräknat) Job PID Ägare Kopiera Förälder Job ID KB/Sek Aktiv Start Aktiv Förfluten Robot Vault Profil Sessions-ID Media att utföra Dataöverföring Off-Host Typ Master Prioritet Dedupliceringsgrad Transportaccelerator Optimeringsinstans eller databas Dela värd
— 1358 Snapshot Klar 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 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 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 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% root 1352 18 dec 2018 12:14:14 PM 00:01:51 Instant Recovery Disk Standard WIN-*********** 0
1354 Backup Klar 0 VMware Inkrementell 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 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% root 1347 18 dec 2018 12:11:45 PM 00:02:08 Instant Recovery Disk Standard WIN-*********** 0
1349 Backup 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 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 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% root 1341 18 dec 2018 12:05:28 PM 00:04:53 Instant Recovery Disk Standard WIN-*********** 0
1342 Backup 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_****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 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% root 1339 18 dec 2018 11:05:46 AM 00:00:53 Instant Recovery Disk Standard WIN-*********** 0
1327 Snapshot Klar 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 Klar 0 VMware Full *******.********.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 Klar 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 Klar 0 VMware Full_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%

Accelerator minskar trafiken från agenter, eftersom endast ändringar i data överförs, vilket innebär att även fulla säkerhetskopior inte överförs helt, eftersom mediaservern samlar in de efterföljande fullständiga säkerhetskopiorna från inkrementella säkerhetskopior.

Mellanservern har sin egen lagring där den skriver "cache" av data och håller databasen för deduplicering.

I den fullständiga arkitekturen ser det ut så här:

Mästerservern hanterar konfigurationen, uppdateringar och annat och är placerad i molnet.
Mediaservern (en mellan *nix-maskin) bör befinna sig så nära de säkerhetskopierade systemen som möjligt i termer av nätverksåtkomst. Här görs deduplicering av säkerhetskopior från alla säkerhetskopierade maskiner.
På de säkerhetskopierade maskinerna finns agenter som vanligtvis skickar till mediaservern endast det som inte finns i dess lagringsutrymme.

Allt börjar med en fullständig skanning — detta är en verklig komplett säkerhetskopiering. Vid detta tillfälle hämtar mediaservern allt, gör deduplicering och överför till S3. Hastigheten till mediaservern är låg, men från den är den högre. Den största begränsningen är serverns beräkningskraft.

De följande säkerhetskopiorna görs ur alla system perspektiv som fullständiga, men i verkligheten är detta något som liknar syntetiska fullständiga säkerhetskopior. Det vill säga den faktiska överföringen och inspelningen på mediaservern sker bara av de datablokkar som tidigare inte har funnits i säkerhetskopiorna för VM. Och överföringen och inspelningen till S3 sker endast av de datablokkar vars hash inte finns i dedupliceringsdatabasen för mediaservern. Med enklare ord — det som inte har förekommit i någon säkerhetskopiering av någon VM tidigare.

Vid återställning begär mediaservern de nödvändiga deduplicerade objekten från S3, regenererar dem och överför dem till agenterna SРК, dvs. man måste ta hänsyn till trafikvolymen vid återställning, som kommer att motsvara den faktiska volymen av återställda data.

Så här ser det ut:

Och här är ytterligare en del av loggarna169 Jobb (0 Köade 0 Aktiva 0 Väntar på omstart 0 Stoppade 0 Ofullständiga 169 Klara — 1 vald)

Dataintegritet säkerställs genom skyddet av själva S3 — där finns en bra redundans för att skydda mot hårdvarufel såsom en död spindel på hårddisken.

Media-servern det behövs 4 TB cache — detta är Veritas rekommendation för minimala volym. Bättre att ha mer, men vi har gjort så här.

Resultat

När partnern laddade upp 20 GB i vårt S3, lagrade vi 60 GB eftersom vi erbjuder trefaldig geografisk datavalidering. Nu är trafiken betydligt mindre, vilket är bra både för kanalen och för lagringskostnaderna.

I det här fallet är vägarna stängda bortom det "stora Internet", men det går att dirigera trafik via VPN L2 genom Internet, men det är bättre att placera mediasever före leverantörens ingång.

Om du är intresserad av att veta mer om dessa funktioner i våra ryska datacenter eller har frågor om implementering i ditt eget företag – fråga gärna i kommentarerna eller via e-post ekorotkikh@croc.ru.

Källa: habr.com

Hur man komprimerar lagring av säkerhetskopior i objektlagring med upp till 90%

Vad är problemet

Resultat