Si të ngjeshim deri në 90% ruajtjen e kopjeve rezervë në ruajtjen objektive

Klientët tanë turq na kërkuan të konfiguroni në mënyrë të duhur backup për qendrën e të dhënave. Ne realizojmë projekte të tilla në Rusi, por këtu historia ishte më shumë për hulumtimin e mënyrave më të mira për ta bërë këtë.

E dhëna: ekziston një ruajtje lokale S3, ka Veritas NetBackup, i cili ka fituar një funksionalitet të ri të avancuar për të transferuar të dhëna në ruajtjet objekt, tani me mbështetje për deduplikimin dhe ka një problem me hapësirën e lirë në këtë ruajtje lokale.

Detyra: të bëjmë gjithçka që procesi i ruajtjes së kopjeve rezervë të jetë i shpejtë dhe i lirë.

Faktikisht, deri tani në S3 gjithçka u ruajt si skedarë, për më tepër këto ishin kopje të plota të makinave kritike të qendrës së të dhënave. Pra, nuk ishte shumë optimizuar, por gjithçka funksiononte gjithsesi në fillim. Tani ka ardhur koha të merremi me këtë dhe ta bëjmë siç duhet.

Në figurë, është ajo që arritëm:

Si të ngjeshim deri në 90% ruajtjen e kopjeve rezervë në ruajtjen objektive

Siç duket, backup i parĂ« u realizua ngadalĂ« (70 Mb/s), ndĂ«rsa backup-et e tjera tĂ« tĂ« njĂ«jtave sisteme — ndjeshĂ«m mĂ« shpejt.

Faktikisht, më poshtë janë disa detaje më shumë mbi karakteristikat atje.

Log-et e backup-eve për ata që janë gati të lexojnë gjysmë faqe dump-iPlot me rishikim
18 Dhjetor 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator dĂ«rgoi 14883996160 byte nga 14883994624 byte nĂ« server, optimizimi 0.0%
18 Dhjetor 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=PDDO Stats (rrjedhĂ« shumĂ«-fije) pĂ«r (NBCC): skanuar: 14570817 KB, CR dĂ«rguar: 1760761 KB, CR dĂ«rguar pĂ«rmes FC: 0 KB, dedup: 87.9%, cache e çaktivizuar

Full
18 Dhjetor 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator dĂ«rgoi 181675008 byte nga 14884060160 byte nĂ« server, optimizimi 98.8%
18 Dhjetor 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=PDDO Stats pĂ«r (NBCC): skanuar: 14569706 KB, CR dĂ«rguar: 45145 KB, CR dĂ«rguar pĂ«rmes FC: 0 KB, dedup: 99.7%, cache e çaktivizuar

Incremental
18 Dhjetor 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator dĂ«rgoi 9970688 byte nga 14726108160 byte nĂ« server, optimizimi 99.9%
18 Dhjetor 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=PDDO Stats pĂ«r (NBCC): skanuar: 14383788 KB, CR dĂ«rguar: 15700 KB, CR dĂ«rguar pĂ«rmes FC: 0 KB, dedup: 99.9%, cache e çaktivizuar

Full
18 Dhjetor 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator dĂ«rgoi 171746816 byte nga 14884093952 byte nĂ« server, optimizimi 98.8%
18 Dhjetor 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport=PDDO Stats pĂ«r (NBCC): skanuar: 14569739 KB, CR dĂ«rguar: 34120 KB, CR dĂ«rguar pĂ«rmes FC: 0 KB, dedup: 99.8%, cache e çaktivizuar

Cila është problemi

Klientët duan të bëjnë backup sa më shpesh dhe të ruajnë sa më lirë. Ruajtja më e lirë mund të bëhet në depozita objektesh si S3, sepse ato janë më të lira për shërbim për Megabajt, nga ku mund të rikuperohet backup në një kohë të arsyeshme. Kur ka shumë backup, kjo nuk bëhet shumë e lirë, sepse një pjesë e madhe e ruajtjes zë kopjet e të njëjtave të dhëna. Në rastin e HaaS të kolegëve turq, mund të kompaktësohet ruajtja për rreth 80-90%. Natyrisht, kjo lidhet me specifikat e tyre, por unë do të llogaritja të paktën 50% dedupikim.

Për të zgjidhur problemin, ofruesit kryesorë tashmë kanë bërë gateway për S3 të Amazon. Të gjitha metodat e tyre janë të përputhshme me S3 lokale, nëse ata mbështesin API-në e Amazon. Në Qendrën tonë të të Dhënave të Turqisë, backup bëhet në S3 tonë, ashtu si në T-III "Kompresori" në Rusi, sepse kjo skemë është treguar se funksionon mirë për ne.

S3 jonë është plotësisht e përputhshme me metodat e backup-it në Amazon S3. Kështu që të gjitha mjetet për backup që mbështesin këto metoda lejojnë kopjimin e gjithçkaje në një depozitë të ngjashme "nga kutia".

Në Veritas NetBackup kanë bërë një funksion CloudCatalyst:

Si të ngjeshim deri në 90% ruajtjen e kopjeve rezervë në ruajtjen objektive

Pra, midis makinave që duhen backup dhe gateway veç një server Linux ndërmjetës është vendosur, përmes të cilit kalon trafiku i backup-it me agjentët SRK dhe bëhet dedupikimi i tyre "në flakë" para se t'i dërgojnë në S3. Nëse më parë kishte 30 backup-e prej 20 Gb me kompresion, tani (për shkak të ngjashmërisë së makinave) ka pasur 90% më pak në volum. Motori i dedupikimit është po ai që përdoret për ruajtjen në disqe të zakonshëm me mjete Netbackup.

Ja çfarë ndodh deri në serverin ndërmjetës:

Si të ngjeshim deri në 90% ruajtjen e kopjeve rezervë në ruajtjen objektive

Ne e kemi testuar dhe arritĂ«m nĂ« pĂ«rfundimin se duke u implementuar nĂ« Qendrat tona tĂ« tĂ« DhĂ«nave, kjo jep kursim tĂ« hapĂ«sirĂ«s nĂ« depozitat S3 pĂ«r ne dhe pĂ«r klientĂ«t. Si pronar i Qendrave Komerciale tĂ« tĂ« DhĂ«nave, natyrisht, tarifojmĂ« sipas volumit tĂ« zĂ«nĂ«, por megjithatĂ«, kjo Ă«shtĂ« shumĂ« e dobishme pĂ«r ne gjithashtu — sepse fillojmĂ« tĂ« fitojmĂ« nĂ« hapĂ«sira mĂ« tĂ« shkallĂ«zuara nĂ« software, e jo nĂ« qiranĂ« e pajisjeve. Dhe, kjo gjithashtu redukton kostot e brendshme.

DĂ«gjimet228 PunĂ« (0 nĂ« radhĂ« 0 aktive 0 duke pritur pĂ«r rikthim 0 tĂ« pezulluara 0 tĂ« paplota 228 tĂ« pĂ«rfunduara — 13 tĂ« zgjedhura)
(Filtri i Aplikuar [13])

Tipi i Punës ID Shtet Detajet e Shtetit Statusi Politika e Punës Orari i Punës Klienti Media Server Koha e Fillimit Koha e Kaluer Koha e Mbarimit Njësia e Ruajtjes Tentativa Operacioni Kilobajtë Skedarët Emri i Rrugës % Përfunduar (I Vlerësuar) Job PID Pronari Kopja ID e Prindit të Punës KB/Sek Aktiv Fillimi Aktiv Koha e Kaluer Profili i Arkivimit ID e Sesionit Media për të Nxjerrë Lëvizja e të Dhënave Of-Host Tipi Master Prioriteti Rates e Dedupikimit Transporti Akcelator Optimizimi Instanca ose Baza e të Dhënave Pjesa e Hosting
— 1358 Snapshot Kryer 0 VMware — NGNCloudADC NBCC 18 Dhjetor, 2018 12:16:19 PM 00:02:18 18 Dhjetor, 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 Dhjetor, 2018 12:16:27 PM 00:02:10 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1360 Backup Kryer 0 VMware Plotë NGNCloudADC NBCC 18 Dhjetor, 2018 12:16:48 PM 00:01:39 18 Dhjetor, 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 Dhjetor, 2018 12:16:48 PM 00:01:39 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 99.8% 99%
1352 Snapshot Kryer 0 VMware — NGNCloudADC NBCC 18 Dhjetor, 2018 12:14:04 PM 00:02:01 18 Dhjetor, 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 Dhjetor, 2018 12:14:14 PM 00:01:51 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1354 Backup Kryer 0 VMware Incremental NGNCloudADC NBCC 18 Dhjetor, 2018 12:14:34 PM 00:01:21 18 Dhjetor, 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 Dhjetor, 2018 12:14:34 PM 00:01:21 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 99.9% 100%
1347 Snapshot Kryer 0 VMware — NGNCloudADC NBCC 18 Dhjetor, 2018 12:11:45 PM 00:02:08 18 Dhjetor, 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 Dhjetor, 2018 12:11:45 PM 00:02:08 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1349 Backup Kryer 0 VMware Plotë NGNCloudADC NBCC 18 Dhjetor, 2018 12:12:02 PM 00:01:41 18 Dhjetor, 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 Dhjetor, 2018 12:12:02 PM 00:01:41 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 99.7% 99%
1341 Snapshot Kryer 0 VMware — NGNCloudADC NBCC 18 Dhjetor, 2018 12:05:28 PM 00:04:53 18 Dhjetor, 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 Dhjetor, 2018 12:05:28 PM 00:04:53 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1342 Backup Kryer 0 VMware Plotë_Rescan NGNCloudADC NBCC 18 Dhjetor, 2018 12:05:47 PM 00:04:24 18 Dhjetor, 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 Dhjetor, 2018 12:05:47 PM 00:04:24 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 87.9% 0%

1339 Snapshot Kryer 150 VMware — NGNCloudADC NBCC 18 Dhjetor, 2018 11:05:46 AM 00:00:53 18 Dhjetor, 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 Dhjetor, 2018 11:05:46 AM 00:00:53 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1327 Snapshot Kryer 0 VMware — *******.********.cloud NBCC 17 Dhjetor, 2018 12:54:42 PM 05:51:38 17 Dhjetor, 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 Dhjetor, 2018 12:54:42 PM 05:51:38 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1328 Backup Kryer 0 VMware Plotë *******.********.cloud NBCC 17 Dhjetor, 2018 12:55:10 PM 05:29:21 17 Dhjetor, 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 Dhjetor, 2018 12:55:10 PM 05:29:21 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 87.9% 0%
1136 Snapshot Kryer 0 VMware — *******.********.cloud NBCC 14 Dhjetor, 2018 4:48:22 PM 04:05:16 14 Dhjetor, 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 Dhjetor, 2018 4:48:22 PM 04:05:16 RimĂ«kĂ«mbje e MenjĂ«hershme Disk Standard WIN-*********** 0
1140 Backup Kryer 0 VMware Plotë_Scan *******.********.cloud NBCC 14 Dhjetor, 2018 4:49:14 PM 03:49:58 14 Dhjetor, 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 Dhjetor, 2018 4:49:14 PM 03:49:58 Rimëkëmbje e Menjëhershme Disk Standard WIN-*********** 0 45.2% 0%

Akseleratori lejon uljen e trafikut nga agentët, pasi që transferohen vetëm ndryshimet në të dhëna, domethënë edhe kopjet e plota rezervë nuk dërgohen tërësisht, pasi serveri medial mbledh kopjet e plota rezervë pasuese nga kopjet incrementale.

Serveri ndërmjetës ka depozitat e tij, ku shkruan "cache" të dhënash dhe ruan një bazë për deduplication.

Në arkitekturën e plotë, ajo duket kështu:

  1. Serveri master menaxhon konfigurimet, azhurnimet dhe tjera dhe ndodhet në cloud.
  2. Serveri medial (makina ndërmjetëse *nix) duhet të jetë sa më afër sistemeve që rezervohen në aspektin e aksesit rrjetor. Këtu bëhet deduplication e backup-eve nga të gjitha makinat që rezervohen.
  3. Në makinat që rezervohen ka agjentë, të cilët në përgjithësi dërgojnë në serverin medial vetëm atë që nuk ndodhet në depozitat e tij.

Çdo gjĂ« fillon me njĂ« skanim tĂ« plotĂ« — kjo Ă«shtĂ« njĂ« backup i plotĂ« i plotĂ«. NĂ« kĂ«tĂ« moment, serveri medial merr gjithçka, bĂ«n deduplication dhe e transferon nĂ« S3. ShpejtĂ«sia deri te serveri medial Ă«shtĂ« e ulĂ«t, por prej tij Ă«shtĂ« mĂ« e lartĂ«. Kufizimi kryesor Ă«shtĂ« fuqia pĂ«rpunuese e serverit.

Backup-et e ardhshme bĂ«hen me pikĂ«pamjen e tĂ« gjitha sistemeve tĂ« plota, por nĂ« tĂ« vĂ«rtetĂ« ato janĂ« diçka si backup-e sintetikĂ« tĂ« plota. DomethĂ«nĂ«, transferimi dhe regjistrimi nĂ« serverin medial ndodh vetĂ«m pĂ«r ato blloqe tĂ« dhĂ«nash qĂ« nuk janĂ« takuar mĂ« parĂ« nĂ« backup-et e VM-ve. Transferimi dhe regjistrimi nĂ« S3 ndodh vetĂ«m pĂ«r ato blloqe tĂ« dhĂ«nash, pĂ«r tĂ« cilat hash-i nuk ndodhet nĂ« bazĂ«n e deduplication tĂ« serverit medial. NĂ«se e thjeshtojmĂ« — ajo qĂ« nuk Ă«shtĂ« takuar nĂ« asnjĂ« backup tĂ« asnjĂ« VM mĂ« parĂ«.

Kur bëhet rikuperimi, serveri medial kërkon objektet e nevojshme të deduplicaura nga S3, i rikrijon ato dhe i dërgon agjentëve të SRK, pra duhet të merret parasysh volumi i trafikut gjatë rikuperimit, i cili do të jetë i barabartë me volumin e saktë të të dhënave që po rikuperohen.

Ja si duket kjo:

Si të ngjeshim deri në 90% ruajtjen e kopjeve rezervë në ruajtjen objektive

Dhe ja njĂ« tjetĂ«r copĂ« log169 Jobs (0 tĂ« radhitur 0 aktive 0 duke pritur pĂ«r riprovim 0 tĂ« pezulluar 0 tĂ« papĂ«rfunduara 169 tĂ« pĂ«rfunduara — 1 e zgjedhur)

Tipi i Punës ID Shtet Detajet e Shtetit Statusi Politika e Punës Orari i Punës Klienti Media Server Koha e Fillimit Koha e Kaluer Koha e Mbarimit Njësia e Ruajtjes Tentativa Operacioni Kilobajtë Skedarët Emri i Rrugës % Përfunduar (I Vlerësuar) Job PID Pronari Kopja ID e Prindit të Punës KB/Sek Aktiv Fillimi Aktiv Koha e Kaluer Profili i Arkivimit ID e Sesionit Media për të Nxjerrë Lëvizja e të Dhënave Of-Host Tipi Master Prioriteti Rates e Dedupikimit Transporti Akcelator Optimizimi Instanca ose Baza e të Dhënave Pjesa e Hosting
— 1372 Rikuperimi i pĂ«rfunduar 0 nbpr01 NBCC 19 Dhjetor 2018 1:05:58 PM 00:04:32 19 Dhjetor 2018 1:10:30 PM 1 14,380,577 1 100% 8548 root 1372 70,567 19 Dhjetor 2018 1:06:00 PM 00:04:30 WIN-*********** 90000

Integriteti i tĂ« dhĂ«nave sigurohet nga mbrojtja e vetĂ« S3 — aty ka njĂ« redundancĂ« tĂ« mirĂ« pĂ«r mbrojtjen nga dĂ«shtimet harduerike siç Ă«shtĂ« ndalimi i njĂ« spindle tĂ« diskut tĂ« ngurtĂ«.

Media-serverit nevojiten 4 TB cache — kjo Ă«shtĂ« njĂ« rekomandim nga Veritas pĂ«r volumin minimal. MĂ« mirĂ« mĂ« shumĂ«, por ne e bĂ«mĂ« saktĂ«sisht kĂ«shtu.

Përfundimi

Kur partneri ngarkonte 20 GB në S3 tonë, ne ruanim 60 GB, sepse ofrojmë triple georedundancë të të dhënave. Tani, trafiku është shumë më i ulët, që është mirë si për kanalin, ashtu edhe për faturimin për ruajtjen.

Në këtë rast, rrugët janë të bllokuara përmes "internetit të madh", por mund të kaloni trafikun edhe përmes VPN L2 përmes internetit, por është më mirë të vendosni serverin e mediave para hyrjes së ofruesit.

Nëse jeni të interesuar të mësoni rreth këtyre funksioneve në qendrat tona të të dhënave në Rusi ose keni pyetje për implementimin në kompaninë tuaj - pyesni në komentet ose në e-mailin ekorotkikh@croc.ru.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster