Ons Turkse kliënte het ons gevra om rugsteun vir hul datasentrum behoorlik op te stel. Ons doen soortgelyke projekte in Rusland, maar hier het die storie meer gegaan oor die navorsing hoe om dit die beste te doen.
Gegee: daar is 'n plaaslike S3-berging, daar is Veritas NetBackup, wat nuwe uitgebreide funksionaliteit verkry het om data na objekberging te skuif, nou met ondersteuning vir deduplisering, en daar is 'n probleem met vrye spasie in hierdie plaaslike berging.
Taak: om alles so te maak dat die proses van die stoor van rugsteunkopieë vinnig en goedkoop is.
Eintlik, voor dit was alles in S3 bloot lêers, en dit was volledige afsettings van die kritieke masjiene van die datasentrum. Dit wil sê, dit is nie baie geoptimaliseer nie, maar alles het aan die begin gewerk. Nou is dit tyd om dit uit te vind en dit reg te doen.
Die prentjie wys waartoe ons gekom het:
Soos u kan sien, is die eerste rugsteun stadig gemaak (70 Mb/s), en die daaropvolgende rugsteun van dieselfde stelsels was baie vinniger.
Eintlik, verder is daar 'n bietjie meer besonderhede oor watter kenmerke daar is.
Rugsteunlogboeke vir diegene wat gereed is om 'n halwe bladsy van stortingsterrein te leesVol met herskandering
18 Des 2018 12:09:43 PM — Info bpbkar (pid=4452) versneller het 14883996160 grepe uit 14883994624 grepe na bediener gestuur, optimalisering 0.0%
18 Des 2018 12:10:07 - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Verslag=PDDO-statistieke (meerdraadstroom gebruik) vir (NBCC): geskandeer: 14570817 KB, CR gestuur: 1760761 KB, CR gestuur oor FC: 0 KB, dedup: 87.9%, kas gedeaktiveer
Volle
18 Des 2018 12:13:18 PM — Info bpbkar (pid=2864) versneller het 181675008 grepe uit 14884060160 grepe na bediener gestuur, optimalisering 98.8%
18 Des 2018 12:13:40 PM - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Verslag=PDDO-statistieke vir (NBCC): geskandeer: 14569706 KB, CR gestuur: 45145 KB, CR gestuur oor FC: 0 KB, dedup: 99.7%, kas gedeaktiveer
inkrementele
18 Des 2018 12:15:32 PM — Info bpbkar (pid=792) versneller het 9970688 grepe uit 14726108160 grepe na bediener gestuur, optimalisering 99.9%
18 Des 2018 12:15:53 PM - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Verslag=PDDO-statistieke vir (NBCC): geskandeer: 14383788 KB, CR gestuur: 15700 KB, CR gestuur oor FC: 0 KB, dedup: 99.9%, kas gedeaktiveer
Volle
18 Des 2018 12:18:02 PM — Info bpbkar (pid=3496) versneller het 171746816 grepe uit 14884093952 grepe na bediener gestuur, optimalisering 98.8%
18 Des 2018 12:18:24 PM - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Verslag=PDDO-statistieke vir (NBCC): geskandeer: 14569739 KB, CR gestuur: 34120 KB, CR gestuur oor FC: 0 KB, dedup: 99.8%, kas gedeaktiveer
Wat is die probleem
Kliënte wil so gereeld as moontlik rugsteun maak en dit so goedkoop as moontlik stoor. Dit is die beste om hulle goedkoop in voorwerpbergings soos S3 te stoor, want hulle is die goedkoopste teen die koste van diens per Megagreep vanwaar jy 'n rugsteun in 'n redelike tyd kan terugrol. Wanneer daar baie rugsteun is, word dit nie baie goedkoop nie, want die meeste van die berging word beset deur kopieë van dieselfde data. In die geval van HaaS van Turkse kollegas, kan berging met ongeveer 80-90% verdicht word. Dit is duidelik dat dit spesifiek met hul besonderhede verband hou, maar ek sal beslis op ten minste 50% oupa staatmaak.
Om die probleem op te los, het die hoofverkopers lank reeds poorte na Amazon S3 gemaak. Al hul metodes is versoenbaar met plaaslike S3 solank hulle die Amazon API ondersteun. In die Turkse datasentrum word rugsteun op ons S3 gemaak, sowel as in die T-III "Compressor" in Rusland, aangesien hierdie werkskema goed vir ons gewerk het.
En ons S3 is ten volle versoenbaar met Amazon S3-rugsteunmetodes. Dit wil sê, alle rugsteunnutsmiddels wat hierdie metodes ondersteun, laat jou toe om alles "uit die boks" na sulke berging te kopieer.
Veritas NetBackup het die CloudCatalyst-funksie bygevoeg:
Dit wil sê, tussen die masjiene wat gerugsteun moet word en die poort, is daar 'n tussenliggende Linux-bediener waardeur rugsteunverkeer van die SRK-agente verbygaan en dadelik gededupliseer word voordat dit na S3 oorgedra word. As daar vroeër 30 rugsteune van 20 GB met kompressie was, het hul volume nou (as gevolg van die ooreenkomste van die masjiene) 90% kleiner geword. Die dedupliseringsenjin word dieselfde gebruik as wanneer dit op gewone skywe gestoor word met Netbackup.
Hier is wat voor die tussenbediener gebeur:
Ons het getoets en tot die gevolgtrekking gekom dat wanneer dit in ons datasentrums geïmplementeer word, dit spasie in S3-berging vir ons en vir kliënte bespaar. As die eienaar van kommersiële datasentrums hef ons natuurlik volgens die volume wat beset word, maar dit is steeds vir ons ook baie winsgewend – want ons begin geld maak op meer skaalbare plekke in sagteware, en nie op die huur van hardeware nie. Wel, en dit is 'n vermindering in interne koste.
Logs228 take (0 in tou 0 aktief 0 wag vir herprobeer 0 opgeskort 0 onvoltooid 228 klaar – 13 gekies)
(Filter toegepas [13])
Werk-ID Tipe Staat Besonderhede Status Werkbeleid Werkskedule Kliënt Mediabediener Begintyd Verstreke Tyd Eindtyd Berging-eenheid Poging Operasie Kilogrepe Lêers Padnaam % Voltooi (Geskatte) Werk PID Eienaar Kopieer Ouer Job ID KB/Sek Aktief Begin Aktief Verstreke Robot Vault-profielsessie ID-media om databeweging buite-gasheertipe uit te stoot Hoofprioriteit-dedupliseringtempo vervoerversneller-optimaliseringsinstansie of databasisdeelgasheer
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 Des. 2018 12:16:19 PM 00:02:18 Des. :18:2018 PM 12:18:37 Instant Recovery Disk Standard WIN-************* 3
1360 Rugsteun gedoen 0 VMware Volledige NGNCloudADC NBCC 18 Desember 2018 12:16:48 PM 00:01:39 18 Desember 2018 12:18:27 PM STU_DP_S3_****rugsteun 1 14,535,248, 149654% 100, 23858% 1358 335,098 18 2018 12 Des , 16 48:00:01 PM 39:0:99.8 Instant Recovery Disk Standard WIN-************* 99 XNUMX% XNUMX%
1352 Snapshot klaar 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:14:04 PM 00:02:01 18 Des 2018 12:16:05 PM STU_DP_S3_****rugsteun 1 100% De wortel 1352 18% 2018% 12:14 PM 14:00:01 Instant Recovery Disk Standard WIN-************* 51
1354 Rugsteun gedoen 0 VMware Incremental NGNCloudADC NBCC 18 Des. 2018 12:14:34 PM 00:01:21 18 Des. 2018 12:15:55 PM STU_DP_S3_****rugsteun 1 14,380,965% 147 100 23617 1352 Des , 500,817 18:2018:12 PM 14:34:00 Instant Recovery Disk Standard WIN-************* 01 21% 0%
1347 Snapshot klaar 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:11:45 PM 00:02:08 18 Des 2018 12:13:53 PM STU_DP_S3_****rugsteun 1 100% De wortel 1347 18% 2018% 12:11 PM 45:00:02 Instant Recovery Disk Standard WIN-************* 08
1349 Rugsteun gedoen 0 VMware Volledige NGNCloudADC NBCC 18 Desember 2018 12:12:02 PM 00:01:41 18 Desember 2018 12:13:43 PM STU_DP_S3_****rugsteun 1 14,535,215, 149653% 100, 23508% 1347 316,319 18 2018 12 Des , 12 02:00:01 PM 41:0:99.7 Instant Recovery Disk Standard WIN-************* 99 XNUMX% XNUMX%
1341 Snapshot klaar 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:05:28 PM 00:04:53 18 Des 2018 12:10:21 PM STU_DP_S3_****rugsteun 1 100% De wortel 1341 18% 2018% 12:05 PM 28:00:04 Instant Recovery Disk Standard WIN-************* 53
1342 Rugsteun gedoen 0 VMware Full_Rescan NGNCloudADC NBCC 18 Des 2018 12:05:47 PM 00:04:24 18 Des 2018 12:10:11 PM STU_DP_S3_****rugsteun 1 14,535,151 149653 100 wortel 22999 1341 70,380 18 Des 2018 , 12 05:47:00 PM 04:24:0 Kitsherstelskyfstandaard WIN-************* 87.9 0% XNUMX%
1339 Snapshot klaar 150 VMware - NGNCloudADC NBCC 18 Des 2018 11:05:46 AM 00:00:53 18 Des 2018 11:06:39 AM STU_DP_S3_****rugsteun Des 1 100% 1339% 18% 2018% 11:05 AM 46:00:00 Instant Recovery Disk Standard WIN-************* 53
1327 Snapshot Done 0 VMware - *******.********.cloud NBCC 17 Des 2018 12:54:42 05:51:38 17 Des 2018 6:46:20 PM STU_DP_S3_****rugsteun 1 100% wortel 1327 Des 17, 2018 12:54:42 PM 05:51:38 Onmiddellike Herstelskyf Standaard WIN-************* 0
1328 Rugsteun gedoen 0 VMware Vol *******.********.cloud NBCC 17 Des 2018 12:55:10 05:29:21 17 Des 2018 6:24:31 PM STU_DP_S3_****rugsteun 1 222,602,719 258932 100% 12856 wortel 1327 11,326 17 Des 2018 12:55:10 05:29:21 Onmiddellike herstelskyf 0******** Standaard WIN 87.9%
1136 Snapshot Done 0 VMware - *******.********.cloud NBCC 14 Des 2018 4:48:22 04:05:16 14 Des 2018 8:53:38 PM STU_DP_S3_****rugsteun 1 100% wortel 1136 Des 14, 2018 4:48:22 PM 04:05:16 Onmiddellike Herstelskyf Standaard WIN-************* 0
1140 Rugsteun gedoen 0 VMware Full_Scan *******.********.cloud NBCC 14 Des 2018 4:49:14 03:49:58 14 Des 2018 8:39:12 PM STU_DP_S3_****rugsteun 1 217,631,332 255465 100% 26438 wortel 1136 15,963 14 Des 2018 4:49:14 03:49:58 Onmiddellike herstelskyf. 0*** Standaard WIN *** 45.2%0-XNUMX***** XNUMX%
Die versneller laat jou toe om verkeer van agente te verminder, want Slegs dataveranderings word oorgedra, dit wil sê, selfs volledige rugsteun word nie heeltemal opgelaai nie, aangesien die mediabediener daaropvolgende volledige rugsteun van inkrementele rugsteun versamel.
Die tussenbediener het sy eie berging, waar dit 'n "kas" van data skryf en 'n databasis vir deduplisering onderhou.
Die volledige argitektuur lyk soos volg:
- Die hoofbediener bestuur konfigurasie, opdaterings, ens. en is in die wolk geleë.
- Die mediabediener (intermediêre *nix-masjien) moet die naaste aan die oortollige stelsels geleë wees in terme van netwerktoeganklikheid. Hier word deduplisering van rugsteun van alle gereserveerde masjiene gedoen.
- Op die gerugsteunde masjiene is daar agente wat oor die algemeen slegs dit wat nie in die stoor daarvan is, na die mediabediener stuur nie.
Dit begin alles met 'n volledige skandering - dit is 'n volwaardige volledige rugsteun. Op hierdie stadium neem die mediabediener alles, dedupliseer dit en dra dit oor na S3. Die spoed na die mediabediener is laag, maar daaruit is dit hoër. Die belangrikste beperking is die rekenaarkrag van die bediener.
Die volgende rugsteun word volledig gemaak vanuit die oogpunt van alle stelsels, maar in werklikheid is dit iets soos sintetiese volledige rugsteun. Dit wil sê, die werklike oordrag en opname na die mediabediener vind slegs plaas van daardie datablokke wat nog nie voorheen in VM-rugsteun teëgekom is nie. En net daardie datablokke waarvan die hash nie in die mediabediener se dedupliseringsdatabasis is nie, word oorgedra en in S3 aangeteken. In eenvoudiger woorde, dit is iets wat nog nooit voorheen in enige rugsteun van 'n enkele VM gesien is nie.
Tydens die herstel versoek die mediabediener die nodige gededupliseerde voorwerpe vanaf S3, rehidreer dit en dra dit oor na die IRB-agente, d.w.s. dit is nodig om die volume verkeer tydens die herstel in ag te neem, wat gelyk sal wees aan die werklike volume data wat herstel word.
So lyk dit:
En hier is nog 'n stuk stompe169 take (0 in tou 0 aktief 0 wag vir herprobeer 0 opgeskort 0 onvoltooid 169 klaar – 1 gekies)
Werk-ID Tipe Staat Besonderhede Status Werkbeleid Werkskedule Kliënt Mediabediener Begintyd Verstreke Tyd Eindtyd Berging-eenheid Poging Operasie Kilogrepe Lêers Padnaam % Voltooi (Geskatte) Werk PID Eienaar Kopieer Ouer Job ID KB/Sek Aktief Begin Aktief Verstreke Robot Vault-profielsessie ID-media om databeweging buite-gasheertipe uit te stoot Hoofprioriteit-dedupliseringtempo vervoerversneller-optimaliseringsinstansie of databasisdeelgasheer
- 1372 Herstel Klaar 0 NBPR01 NBCC 19 Des. 2018 1:05:58 PM 00:04:32 Des. 19, 2018 1:10:30 PM 1 14,380,577 1 100% 8548 1372 70,567% 19 2018 1% 06 00 00:04 :30 PM 90000:XNUMX:XNUMX WEN-************* XNUMX
Data-integriteit word verseker deur die beskerming van S3 self - daar is goeie oortolligheid daar om te beskerm teen hardewarefoute soos 'n dooie hardeskyfspil.
Die mediabediener benodig 4 TB se kas – dit is Veritas se minimum grootte aanbeveling. Meer is beter, maar dit is wat ons gedoen het.
Totale
Toe 'n vennoot 3 GB in ons S20 gegooi het, het ons 60 GB gestoor, want ons verskaf drievoudige geo-reservering van data. Nou is daar baie minder verkeer, wat goed is vir beide die kanaal en vir bergingstariewe.
In hierdie geval is die roetes verby die "groot internet" gesluit, maar jy kan verkeer deur VPN L2 oor die internet bestuur, maar dit is beter om die mediabediener voor die verskaffer se ingang te installeer.
As jy belangstel om oor hierdie kenmerke in ons Russiese datasentrums te leer of vrae het oor implementering by die huis, vra in die kommentaar of per e-pos [e-pos beskerm].
Bron: will.com