Onze Turkse klanten vroegen ons om de back-up voor hun datacenter goed te configureren. We doen soortgelijke projecten in Rusland, maar hier ging het verhaal meer over onderzoeken hoe we dit het beste konden doen.
Gegeven: er is een lokale S3-opslag, er is Veritas NetBackup, die nieuwe uitgebreide functionaliteit heeft gekregen voor het verplaatsen van gegevens naar objectopslag, nu met ondersteuning voor deduplicatie, en er is een probleem met de vrije ruimte in deze lokale opslag.
Taak: alles zo maken dat het proces van het opslaan van back-upkopieën snel en goedkoop is.
Eigenlijk bestond alles in S3 voorheen uit gewoon bestanden, en dit waren complete afgietsels van de kritieke machines van het datacenter. Dat wil zeggen, het is niet erg geoptimaliseerd, maar alles werkte in het begin. Nu is het tijd om erachter te komen en het goed te doen.
De foto laat zien waar we voor kwamen:
Zoals u kunt zien, werd de eerste back-up langzaam gemaakt (70 Mb/s) en gingen de daaropvolgende back-ups van dezelfde systemen veel sneller.
Eigenlijk zijn er verderop wat meer details over welke functies er zijn.
Back-uplogboeken voor degenen die bereid zijn een halve pagina dump te lezenVol met opnieuw scannen
18 december 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator stuurde 14883996160 bytes van de 14883994624 bytes naar de server, optimalisatie 0.0%
18 december 2018 12:10:07 PM - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistieken (multi-threaded stream gebruikt) voor (NBCC): gescand: 14570817 KB, CR verzonden: 1760761 KB, CR verzonden via FC: 0 KB, ontdubbeling: 87.9%, cache uitgeschakeld
Vol
18 december 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator stuurde 181675008 bytes van de 14884060160 bytes naar de server, optimalisatie 98.8%
18 december 2018 12:13:40 uur - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistieken voor (NBCC): gescand: 14569706 KB, CR verzonden: 45145 KB, CR verzonden via FC: 0 KB, ontdubbeling: 99.7%, cache uitgeschakeld
Incrementeel
18 december 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator stuurde 9970688 bytes van de 14726108160 bytes naar de server, optimalisatie 99.9%
18 december 2018 12:15:53 uur - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistieken voor (NBCC): gescand: 14383788 KB, CR verzonden: 15700 KB, CR verzonden via FC: 0 KB, ontdubbeling: 99.9%, cache uitgeschakeld
Vol
18 december 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator stuurde 171746816 bytes van de 14884093952 bytes naar de server, optimalisatie 98.8%
18 december 2018 12:18:24 uur - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Rapport=PDDO-statistieken voor (NBCC): gescand: 14569739 KB, CR verzonden: 34120 KB, CR verzonden via FC: 0 KB, ontdubbeling: 99.8%, cache uitgeschakeld
Wat is het probleem
Klanten willen zo vaak mogelijk back-ups maken en deze zo goedkoop mogelijk opslaan. Het is het beste om ze goedkoop op te slaan in objectopslagplaatsen zoals S3, omdat ze het goedkoopst zijn qua servicekosten per Megabyte van waaruit je binnen een redelijke tijd een back-up kunt terugdraaien. Als er veel back-up is, wordt het niet erg goedkoop, omdat het grootste deel van de opslagruimte wordt ingenomen door kopieën van dezelfde gegevens. In het geval van HaaS van Turkse collega’s kan de opslag met ongeveer 80-90% worden verdicht. Het is duidelijk dat dit specifiek betrekking heeft op hun specifieke kenmerken, maar ik zou zeker rekenen op minstens 50% grootvader.
Om het probleem op te lossen, hebben de belangrijkste leveranciers al lang gateways voor Amazon S3 gemaakt. Al hun methoden zijn compatibel met lokale S3, zolang ze de Amazon API ondersteunen. In het Turkse datacenter wordt een back-up gemaakt naar onze S3, evenals naar de T-III “Compressor” in Rusland, aangezien dit werkschema voor ons goed heeft gewerkt.
En onze S3 is volledig compatibel met Amazon S3-back-upmethoden. Dat wil zeggen dat alle back-uptools die deze methoden ondersteunen, u in staat stellen alles “out of the box” naar een dergelijke opslag te kopiëren.
Veritas NetBackup heeft de CloudCatalyst-functie toegevoegd:
Dat wil zeggen, tussen de machines waarvan een back-up moet worden gemaakt en de gateway, bevindt zich een tussenliggende Linux-server waar het back-upverkeer van de SRK-agents doorheen gaat en on-the-fly wordt gededupliceerd voordat het naar S3 wordt overgebracht. Waren er eerder 30 back-ups van 20 GB met compressie, nu (vanwege de gelijkenis van de machines) is hun volume 90% kleiner geworden. De deduplicatie-engine wordt op dezelfde manier gebruikt als bij het opslaan op gewone schijven met behulp van Netbackup.
Dit gebeurt er vóór de tussenliggende server:
We hebben het getest en kwamen tot de conclusie dat dit, wanneer het in onze datacenters wordt geïmplementeerd, ruimte in S3-opslag bespaart voor ons en voor klanten. Als eigenaar van commerciële datacenters brengen we uiteraard kosten in rekening op basis van het gebruikte volume, maar het is ook voor ons nog steeds erg winstgevend - omdat we geld gaan verdienen op meer schaalbare plaatsen in software, en niet op het huren van hardware. Welnu, en dit is een verlaging van de interne kosten.
Logboeken228 opdrachten (0 in wachtrij 0 actief 0 wachtend op nieuwe poging 0 opgeschort 0 onvoltooid 228 gereed — 13 geselecteerd)
(Filter toegepast [13])
Taak-ID Type Staat Statusdetails Status Taakbeleid Taakschema Client Mediaserver Begintijd Verstreken tijd Eindtijd Opslageenheid Poging tot bewerking Kilobytes Bestanden Padnaam % voltooid (geschat) Taak-PID Eigenaar Kopiëren Bovenliggende taak-ID KB/Sec Actieve start Actief verstreken Robotkluisprofielsessie ID Media om gegevensverplaatsing uit te werpen Type off-host Hoofdprioriteit Deduplicatiesnelheid Transportversneller Optimalisatie Instantie of Database Share Host
— 1358 Snapshot klaar 0 VMware — NGNCloudADC NBCC 18 december 2018 12:16:19 00:02:18 18 december 2018 12:18:37 STU_DP_S3_****back-up 1 100% root 1358 18 december 2018 12 :16:27 PM 00:02:10 Instant Recovery Disk Standaard WIN-************ 0
1360 Back-up gereed 0 VMware volledig NGNCloudADC NBCC 18 december 2018 12:16:48 00:01:39 18 december 2018 12:18:27 STU_DP_S3_****back-up 1 14,535,248 149654 100% 23858 root 1358 335,098 ,18 2018 december , 12 16:48:00 PM 01:39:0 Instant Recovery Disk Standaard WIN-************ 99.8 99% XNUMX%
1352 Momentopname gereed 0 VMware - NGNCloudADC NBCC 18 december 2018 12:14:04 00:02:01 18 december 2018 12:16:05 STU_DP_S3_****back-up 1 100% root 1352 18 december 2018 12: 14:14 PM 00:01:51 Instant Recovery Disk Standaard WIN-************ 0
1354 Back-up gereed 0 VMware Incrementeel NGNCloudADC NBCC 18 december 2018 12:14:34 00:01:21 18 december 2018 12:15:55 STU_DP_S3_****back-up 1 14,380,965 147 100% 23617 root 1352 500,817, 18 2018 december , 12 14:34:00 PM 01:21:0 Instant Recovery Disk Standaard WIN-************ 99.9 100% XNUMX%
1347 Momentopname gereed 0 VMware - NGNCloudADC NBCC 18 december 2018 12:11:45 00:02:08 18 december 2018 12:13:53 STU_DP_S3_****back-up 1 100% root 1347 18 december 2018 12: 11:45 PM 00:02:08 Instant Recovery Disk Standaard WIN-************ 0
1349 Back-up gereed 0 VMware volledig NGNCloudADC NBCC 18 december 2018 12:12:02 00:01:41 18 december 2018 12:13:43 STU_DP_S3_****back-up 1 14,535,215 149653 100% 23508 root 1347 316,319 ,18 2018 december , 12 12:02:00 PM 01:41:0 Instant Recovery Disk Standaard WIN-************ 99.7 99% XNUMX%
1341 Momentopname gereed 0 VMware - NGNCloudADC NBCC 18 december 2018 12:05:28 00:04:53 18 december 2018 12:10:21 STU_DP_S3_****back-up 1 100% root 1341 18 december 2018 12: 05:28 PM 00:04:53 Instant Recovery Disk Standaard WIN-************ 0
1342 Back-up gereed 0 VMware Full_Rescan NGNCloudADC NBCC 18 december 2018 12:05:47 00:04:24 18 december 2018 12:10:11 STU_DP_S3_****back-up 1 14,535,151 149653 100% 22999 root 1341 70,380 18 december 2018 12 05:47:00 PM 04:24:0 Instant Recovery Disk Standaard WIN-************ 87.9 0% XNUMX%
1339 Momentopname gereed 150 VMware - NGNCloudADC NBCC 18 december 2018 11:05:46 00:00:53 18 december 2018 11:06:39 STU_DP_S3_****back-up 1 100% root 1339 18 december 2018 11: 05:46 AM 00:00:53 Instant Recovery Disk Standaard WIN-************ 0
1327 Momentopname gereed 0 VMware - *******.**********.cloud NBCC 17 december 2018 12:54:42 05:51:38 17 december 2018 6:46:20 STU_DP_S3_****back-up 1 100% root 1327 17 december 2018 12:54:42 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Back-up gereed 0 VMware vol ******.**********.cloud NBCC 17 december 2018 12:55:10 05:29:21 17 december 2018 6:24:31 STU_DP_S3_****back-up 1 222,602,719 258932 100% 12856 root 1327 11,326 17 december 2018 12:55:10 PM 05:29:21 Instant Recovery Disk Standard WIN-************ 0 87.9% 0%
1136 Momentopname gereed 0 VMware - *******.**********.cloud NBCC 14 december 2018 4:48:22 04:05:16 14 december 2018 8:53:38 STU_DP_S3_****back-up 1 100% root 1136 14 december 2018 4:48:22 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Back-up gereed 0 VMware Full_Scan *******.********.cloud NBCC 14 december 2018 4:49:14 03:49:58 14 december 2018 8:39:12 STU_DP_S3_****back-up 1 217,631,332 255465 100% 26438 root 1136 15,963 14 december 2018 4:49:14 PM 03:49:58 Instant Recovery Disk Standaard WIN-************ 0 45.2% 0%
Met de accelerator kunt u het verkeer van agenten verminderen, omdat Alleen gegevenswijzigingen worden verzonden, dat wil zeggen dat zelfs volledige back-ups niet volledig worden geüpload, omdat de mediaserver daaropvolgende volledige back-ups verzamelt van incrementele back-ups.
De tussenliggende server heeft zijn eigen opslag, waar hij een “cache” met gegevens schrijft en een database bijhoudt voor deduplicatie.
De volledige architectuur ziet er als volgt uit:
- De masterserver beheert de configuratie, updates etc. en bevindt zich in de cloud.
- De mediaserver (tussenliggende *nix-machine) moet qua netwerktoegankelijkheid het dichtst bij de redundante systemen worden geplaatst. Hier wordt de deduplicatie van back-ups van alle gereserveerde machines uitgevoerd.
- Op de machines waarvan een back-up is gemaakt, bevinden zich agenten die doorgaans alleen naar de mediaserver sturen wat zich niet in de opslag bevindt.
Het begint allemaal met een volledige scan - dit is een volwaardige volledige back-up. Op dit punt neemt de mediaserver alles, dedupliceert het en draagt het over naar S3. De snelheid naar de mediaserver is laag, maar vanaf daar hoger. De belangrijkste beperking is de rekenkracht van de server.
De volgende back-ups zijn vanuit het oogpunt van alle systemen compleet gemaakt, maar in werkelijkheid zijn het zoiets als synthetische volledige back-ups. Dat wil zeggen dat de daadwerkelijke overdracht en opname naar de mediaserver alleen plaatsvindt van die datablokken die nog niet eerder zijn aangetroffen in VM-back-ups. En alleen die datablokken waarvan de hash niet in de deduplicatiedatabase van de mediaserver staat, worden overgedragen en vastgelegd in S3. In eenvoudiger woorden: dit is iets dat nog nooit eerder is gezien bij een back-up van een enkele VM.
Tijdens het herstellen vraagt de mediaserver de benodigde gededupliceerde objecten op bij S3, rehydrateert ze en draagt ze over aan de IRB-agents, d.w.z. het is noodzakelijk om tijdens het herstellen rekening te houden met het verkeersvolume, dat gelijk zal zijn aan het werkelijke volume aan gegevens dat wordt hersteld.
Zo ziet het eruit:
En hier is nog een stukje log169 opdrachten (0 in wachtrij 0 actief 0 wachtend op nieuwe poging 0 opgeschort 0 onvoltooid 169 gereed — 1 geselecteerd)
Taak-ID Type Staat Statusdetails Status Taakbeleid Taakschema Client Mediaserver Begintijd Verstreken tijd Eindtijd Opslageenheid Poging tot bewerking Kilobytes Bestanden Padnaam % voltooid (geschat) Taak-PID Eigenaar Kopiëren Bovenliggende taak-ID KB/Sec Actieve start Actief verstreken Robotkluisprofielsessie ID Media om gegevensverplaatsing uit te werpen Type off-host Hoofdprioriteit Deduplicatiesnelheid Transportversneller Optimalisatie Instantie of Database Share Host
- 1372 Herstel voltooid 0 NBPR01 NBCC 19 december 2018 1:05:58 00:04:32 19 december 2018 1:10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 december 2018 1:06 :00 PM 00:04:30 WIN-*************** 90000
De gegevensintegriteit wordt verzekerd door de bescherming van S3 zelf - er is een goede redundantie ter bescherming tegen hardwarefouten zoals een defecte harde schijf.
De mediaserver heeft 4 TB cache nodig - dit is de aanbeveling van Veritas voor de minimale grootte. Meer is beter, maar dat is wat wij deden.
Totaal
Toen een partner 3 GB in onze S20 stopte, hebben we 60 GB opgeslagen, omdat we drievoudige geo-reservering van gegevens bieden. Nu is er veel minder verkeer, wat zowel goed is voor de zender als voor de opslagtarieven.
In dit geval zijn de routes voorbij het “grote internet” gesloten, maar u kunt verkeer via VPN L2 over internet leiden, maar het is beter om de mediaserver vóór de ingang van de provider te installeren.
Als u geïnteresseerd bent om meer te weten te komen over deze functies in onze Russische datacenters of als u vragen heeft over de implementatie thuis, stel deze dan in de reacties of per e-mail [e-mail beveiligd].
Bron: www.habr.com