Onze Turkse klanten vroegen ons om de back-up voor het datacenter correct in te stellen. We doen soortgelijke projecten in Rusland, maar hier was het verhaal meer gericht op het onderzoeken van de beste aanpak.
Gegeven: er is een lokale S3-opslag, er is Veritas NetBackup, dat nu een uitgebreidere functionaliteit heeft gekregen voor het verplaatsen van gegevens naar objectopslag met ondersteuning voor deduplicatie, en er is een probleem met vrije ruimte in deze lokale opslag.
Taak: alles zo organiseren dat het back-up opslagproces snel en goedkoop is.
Tot nu toe werden in S3 gewoon bestanden opgeslagen, waarbij volledige kopieƫn van kritische servers in het datacenter werden gemaakt. Dit was niet bijzonder geoptimaliseerd, maar het werkte toen wel. Nu is het tijd om het goed aan te pakken.
Op de afbeelding wat we hebben bereikt:
Zoals te zien, werd de eerste back-up langzaam gemaakt (70 MB/s), maar de volgende back-ups van dezelfde systemen gingen aanzienlijk sneller.
Hier zijn wat meer details over de specifieke kenmerken.
Back-uplogboeken voor degenen die bereid zijn om een halve pagina dump te lezenVolledig met rescan
Dec 18, 2018 12:09:43 PM - Info bpbkar (pid=4452) accelerator heeft 14883996160 bytes van 14883994624 bytes naar de server gestuurd, optimalisatie 0,0%
Dec 18, 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 over FC: 0 KB, dedup: 87,9%, cache uitgeschakeld
Volledig
Dec 18, 2018 12:13:18 PM - Info bpbkar (pid=2864) accelerator heeft 181675008 bytes van 14884060160 bytes naar de server gestuurd, optimalisatie 98,8%
Dec 18, 2018 12:13:40 PM - 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 over FC: 0 KB, dedup: 99,7%, cache uitgeschakeld
Incremental
Dec 18, 2018 12:15:32 PM - Info bpbkar (pid=792) accelerator heeft 9970688 bytes van 14726108160 bytes naar de server gestuurd, optimalisatie 99,9%
Dec 18, 2018 12:15:53 PM - 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 over FC: 0 KB, dedup: 99,9%, cache uitgeschakeld
Volledig
Dec 18, 2018 12:18:02 PM - Info bpbkar (pid=3496) accelerator heeft 171746816 bytes van 14884093952 bytes naar de server gestuurd, optimalisatie 98,8%
Dec 18, 2018 12:18:24 PM - 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 over FC: 0 KB, dedup: 99,8%, cache uitgeschakeld
Wat is het probleem
Klanten willen zo vaak mogelijk back-ups maken en ze zo goedkoop mogelijk opslaan. Goedkoop opslaan kan het beste in objectopslag zoals S3, aangezien deze het goedkoopst zijn qua opslagkosten per Megabyte vanuit waar een back-up in redelijke tijd kan worden teruggezet. Wanneer er veel back-ups zijn, wordt het niet erg goedkoop, omdat een groot deel van de opslagruimte in beslag wordt genomen door kopieĆ«n van dezelfde gegevens. In het geval van HaaS kunnen onze Turkse collegaās de opslag met ongeveer 80-90% compacter maken. Dit is duidelijk verbonden aan hun specifieke situatie, maar ik zou zeker op minstens 50% deduplicatie rekenen.
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, mits ze de Amazon API ondersteunen. In het Turkse datacenter worden back-ups naar onze S3 gemaakt, net zoals in T-III 'Compressor' in Rusland, omdat deze werkwijze zich bij ons goed heeft bewezen.
Onze S3 is volledig compatibel met de back-upmethoden in Amazon S3. Dat wil zeggen, alle back-upmiddelen die deze methoden ondersteunen, kunnen alles 'out-of-the-box' naar een dergelijke opslag verplaatsen.
In Veritas NetBackup hebben ze de functie CloudCatalyst geĆÆntroduceerd:
Er tussen de machines die geback-upd moeten worden en de gateway staat een tussenliggende Linux-server, waar het back-upverkeer van de SRK-agenten doorheen gaat en hun deduplicatie 'on-the-fly' plaatsvindt voordat ze naar S3 worden verzonden. Als er eerder 30 back-ups van 20 GB met compressie waren, is dat nu (door de gelijkenis van de machines) met 90% verminderd. De deduplicatiemechanisme is hetzelfde als dat voor opslag op gewone schijven met NetBackup.
Dit is wat er gebeurt vĆ³Ć³r de tussenliggende server:
We hebben getest en geconcludeerd dat de implementatie in onze datacenters resulteert in besparingen in S3-opslag voor ons en voor de klanten. Als eigenaar van commerciĆ«le datacenters rekenen we natuurlijk op basis van de ingenomen ruimte, maar het is voor ons ook heel voordelig ā omdat we beginnen te verdienen aan meer schaalbare plaatsen in software, en niet aan de verhuur van hardware. En dit vermindert ook onze interne kosten.
Logs228 Jobs (0 In de wachtrij 0 Actief 0 Wachtend op herhaling 0 Opgeschort 0 Incomplete 228 Voltooid ā 13 geselecteerd)
(Filter toegepast [13])
Taak-id Type Toestand Toestand Details Status Taak Beleid Taak Schema Klant Media Server Starttijd Verstreken Tijd Eindtijd Opslag Eenheid Poging Operatie Kilobytes Bestanden Pad % Voltooid (Geschat) Taak PID Eigenaar Kopie Ouder Taak-ID KB/Sec Actief Start Actief Verstreken Robot Kluis Profiel Sessie-ID Media om te Ejecten Gegevensbeweging Off-Host Type Master Prioriteit Deduplicatie Percentage Transport Versneller Optimalisatie Instantie of Database Delen Host
ā 1358 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1360 Backup Voltooid 0 VMware Volledig 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 Schijf Standaard WIN-*********** 0 99,8% 99%
1352 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1354 Backup Voltooid 0 VMware Incrementeel 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 Schijf Standaard WIN-*********** 0 99,9% 100%
1347 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1349 Backup Voltooid 0 VMware Volledig 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 Schijf Standaard WIN-*********** 0 99,7% 99%
1341 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1342 Backup Voltooid 0 VMware Volledig_Herzoeken 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 Schijf Standaard WIN-*********** 0 87,9% 0%
1339 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1327 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1328 Backup Voltooid 0 VMware Volledig *******.********.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 Schijf Standaard WIN-*********** 0 87,9% 0%
1136 Snapshot Voltooid 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 Schijf Standaard WIN-*********** 0
1140 Backup Voltooid 0 VMware Volledig_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 Schijf Standaard WIN-*********** 0 45,2% 0%
De accelerator vermindert het verkeer van agents, omdat alleen gegevenswijzigingen worden doorgegeven. Zelfs volledige backups worden niet in hun geheel verzonden, omdat de mediaserver volgende volledige back-ups uit incrementele back-ups verzamelt.
De tussenserver heeft zijn eigen opslag, waarin hij een 'cache' van gegevens schrijft en een database voor deduplicatie behoudt.
In de volledige architectuur ziet het er als volgt uit:
- De masterserver beheert de configuratie, updates en andere zaken en bevindt zich in de cloud.
- De mediaserver (tussenliggende *nix-machine) moet zich zo dicht mogelijk bij de te reserveren systemen bevinden in termen van netwerktoegankelijkheid. Hier vindt deduplicatie van backups van alle te reserveren machines plaats.
- Op de te reserveren machines zijn agents aanwezig die in het algemeen alleen dat naar de mediaserver sturen wat niet in zijn opslag staat.
Alles begint met een volledige scan ā dit is een volledige backup. Op dit moment haalt de mediaserver alles binnen, doet deduplicatie en verzendt het naar S3. De snelheid tot de mediaserver is laag, maar van de mediaserver omhoog. De belangrijkste beperking is de rekenkracht van de server.
De volgende backups worden vanuit het perspectief van alle systemen als volledig beschouwd, maar in werkelijkheid zijn dit iets als synthetische volledige backups. Dat wil zeggen, de feitelijke overdracht en registratie op de mediaserver gebeurt alleen voor die gegevensblokken die nog niet in eerdere backups van de VM zijn aangetroffen. En de overdracht en registratie in S3 betreft alleen die gegevensblokken waarvan de hash niet in de deduplicatiedatabase van de mediaserver staat. Simpel gezegd: wat in geen enkele backup van een VM eerder is voorgekomen.
Bij een herstel vraagt de mediaserver de benodigde deduplicatieobjecten bij S3 aan, hydratiseert deze en geeft ze door aan de agents van het SRK, wat betekent dat je rekening moet houden met het verkeersvolume tijdens het herstel, dat gelijk zal zijn aan het werkelijke volume van de te herstellen gegevens.
Zo ziet het eruit:
En hier is nog een stukje logs169 Jobs (0 In de wachtrij 0 Actief 0 Wachtend op opnieuw proberen 0 Gegevens 0 Incomplete 169 Voltooid - 1 geselecteerd)
Taak-id Type Toestand Toestand Details Status Taak Beleid Taak Schema Klant Media Server Starttijd Verstreken Tijd Eindtijd Opslag Eenheid Poging Operatie Kilobytes Bestanden Pad % Voltooid (Geschat) Taak PID Eigenaar Kopie Ouder Taak-ID KB/Sec Actief Start Actief Verstreken Robot Kluis Profiel Sessie-ID Media om te Ejecten Gegevensbeweging Off-Host Type Master Prioriteit Deduplicatie Percentage Transport Versneller Optimalisatie Instantie of Database Delen Host
ā 1372 Herstel Voltooid 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
De integriteit van de gegevens wordt verzekerd door de bescherming van S3 zelf - daar is er goede redundantie ter bescherming tegen hardwarestoringen zoals een defecte schijfspindel.
Media-server 4 TB cache is nodig - dit is de aanbeveling van Veritas voor het minimumvolume. Meer is beter, maar we hebben het precies zo gedaan.
Conclusie
Toen de partner 20 GB naar onze S3 stuurde, slaagden we 60 GB op, omdat we drievoudige geografische gegevensredundantie bieden. Momenteel is het verkeer veel minder, wat zowel goed is voor de bandbreedte als voor de opslagkosten.
In dit geval zijn de routes afgesloten van het 'grote Internet', maar je kunt verkeer ook via VPN L2 via Internet sturen, maar het is beter om de mediaserver vĆ³Ć³r de provider-ingang te plaatsen.
Als je meer wilt weten over deze functies in onze Russische datacenters of als je vragen hebt over de implementatie voor jezelf, vraag het dan in de opmerkingen of via e-mail ekorotkikh@croc.ru.
Bron: habr.com
