Clienții noștri turci ne-au cerut să configurăm corect backupul pentru centrul lor de date. Facem proiecte similare în Rusia, dar aici povestea a fost mai mult despre cercetarea modului de a face cel mai bine.
Având în vedere: există o stocare S3 locală, există Veritas NetBackup, care a dobândit o nouă funcționalitate extinsă pentru mutarea datelor în stocarea obiectelor, acum cu suport pentru deduplicare și există o problemă cu spațiul liber în această stocare locală.
Sarcină: să faci totul astfel încât procesul de stocare a copiilor de rezervă să fie rapid și ieftin.
De fapt, înainte de aceasta, totul în S3 era pur și simplu fișiere, iar acestea erau modele complete ale mașinilor critice ale centrului de date. Adică nu este foarte optimizat, dar totul a funcționat la început. Acum este timpul să-ți dai seama și să o faci corect.
Imaginea arată la ce am ajuns:
După cum puteți vedea, primul backup a fost făcut lent (70 Mb/s), iar backup-urile ulterioare ale acelorași sisteme au fost mult mai rapide.
De fapt, mai departe sunt câteva detalii despre ce caracteristici există.
Jurnalele de rezervă pentru cei care sunt gata să citească o jumătate de pagină de dumpPlin cu rescanarea
18 decembrie 2018 12:09:43 — Informații bpbkar (pid=4452) acceleratorul a trimis 14883996160 octeți din 14883994624 octeți către server, optimizare 0.0%
18 decembrie 2018 12:10:07 - Informații NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport = Statistici PDDO (flux cu mai multe fire utilizate) pentru (NBCC): scanat: 14570817 KB, CR trimis: 1760761 KB, CR trimis peste FC: 0 KB, dedup: 87.9%, memoria cache dezactivată
Complet
18 decembrie 2018 12:13:18 — Informații bpbkar (pid=2864) acceleratorul a trimis 181675008 octeți din 14884060160 octeți către server, optimizare 98.8%
18 decembrie 2018 12:13:40 - Informații NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport = Statistici PDDO pentru (NBCC): scanat: 14569706 KB, CR trimis: 45145 KB, CR trimis peste FC: 0 KB, dedup: 99.7%, memoria cache dezactivată
incrementală
18 decembrie 2018 12:15:32 — Informații bpbkar (pid=792) acceleratorul a trimis 9970688 octeți din 14726108160 octeți către server, optimizare 99.9%
18 decembrie 2018 12:15:53 - Informații NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport = Statistici PDDO pentru (NBCC): scanat: 14383788 KB, CR trimis: 15700 KB, CR trimis peste FC: 0 KB, dedup: 99.9%, memoria cache dezactivată
Complet
18 decembrie 2018 12:18:02 — Informații bpbkar (pid=3496) acceleratorul a trimis 171746816 octeți din 14884093952 octeți către server, optimizare 98.8%
18 decembrie 2018 12:18:24 - Informații NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Raport = Statistici PDDO pentru (NBCC): scanat: 14569739 KB, CR trimis: 34120 KB, CR trimis peste FC: 0 KB, dedup: 99.8%, memoria cache dezactivată
Care este problema
Clienții doresc să facă copii de siguranță cât mai des posibil și să le stocheze cât mai ieftin. Cel mai bine este să le stocați ieftin în depozite de obiecte precum S3, deoarece sunt cele mai ieftine la costul serviciului pe Megaoctet de unde puteți rula o copie de rezervă într-un timp rezonabil. Când există o mulțime de copii de rezervă, nu devine foarte ieftin, deoarece cea mai mare parte a spațiului de stocare este ocupat de copii ale acelorași date. În cazul HaaS al colegilor turci, stocarea poate fi densificată cu aproximativ 80-90%. Este clar că acest lucru se referă în mod specific la specificul lor, dar cu siguranță m-aș baza pe cel puțin 50% bunicul.
Pentru a rezolva problema, principalii furnizori au făcut de mult timp porți către Amazon S3. Toate metodele lor sunt compatibile cu S3 local, atâta timp cât acceptă API-ul Amazon. În centrul de date turc, backup-ul se face pe S3-ul nostru, precum și în „Compresorul” T-III din Rusia, deoarece această schemă de lucru a funcționat bine pentru noi.
Și S3-ul nostru este pe deplin compatibil cu metodele de backup Amazon S3. Adică, toate instrumentele de rezervă care acceptă aceste metode vă permit să copiați totul într-o astfel de stocare „din cutie”.
Veritas NetBackup a adăugat caracteristica CloudCatalyst:
Adică, între mașinile care trebuie să facă backup și gateway, există un server Linux intermediar prin care trece traficul de rezervă de la agenții SRK și este deduplicat din mers înainte de a-l transfera pe S3. Dacă mai devreme existau 30 de copii de rezervă de 20 GB cu compresie, acum (datorită asemănării mașinilor) volumul lor a devenit cu 90% mai mic. Motorul de deduplicare este utilizat la fel ca atunci când stocați pe discuri obișnuite folosind Netbackup.
Iată ce se întâmplă înainte de serverul intermediar:
Am testat și am ajuns la concluzia că, atunci când este implementat în centrele noastre de date, acest lucru economisește spațiu în stocarea S3 pentru noi și pentru clienți. În calitate de proprietar al centrelor de date comerciale, desigur, taxăm în funcție de volumul ocupat, dar tot este foarte profitabil și pentru noi - pentru că începem să facem bani pe locuri mai scalabile în software, și nu pe închirierea hardware-ului. Ei bine, și aceasta este o reducere a costurilor interne.
Bușteni228 Lucrări (0 În coadă 0 Activ 0 În așteptarea reîncercării 0 Suspendat 0 Incompletat 228 Terminat — 13 selectate)
(Filtrul aplicat [13])
Tip ID job Stare Starea Detalii Stare Politica job Programare job Client Media Server Ora de pornire Timp scurs Ora de încheiere Unitate de stocare Încercare Operațiune Kilobyți Fișiere Nume cale % Completat (estimat) PID Job Proprietar Copiere Parent ID job KB/sec Pornire activă Sesiune de profil robot Vault ID-ul media pentru a scoate datele Mișcarea în afara gazdei Tip principal Prioritate deduplicare Rata de deduplicare Accelerator de transport Optimizare Instanță sau partajare bază de date Gazdă
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 decembrie 2018 12:16:19 00:02:18 18 decembrie 2018 12:18:37 STU_DP_S3_****backup 1 100% rădăcină 1358, 18% Dec 2018 12, 16 :27:00 PM 02:10:0 Standard Instant Recovery Disk WIN-*********** XNUMX
Backup 1360 Terminat 0 VMware Complet NGNCloudADC NBCC 18 decembrie 2018 12:16:48 PM 00:01:39 18 decembrie 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248, 149654, 100 23858 1358 335,098 18 2018 12 16 decembrie , 48 00:01:39 PM 0:99.8:99 Instant Recovery Disk Standard WIN-********** XNUMX XNUMX% XNUMX%
1352 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 decembrie 2018 12:14:04 00:02:01 18 decembrie 2018 12:16:05 STU_DP_S3_****backup 1 100% rădăcină 1352 18, 2018 dec.: 12:14 14:00 PM 01:51:0 Standard Instant Recovery Disk WIN-*********** XNUMX
1354 Backup Terminat 0 VMware Incremental NGNCloudADC NBCC 18 decembrie 2018 12:14:34 PM 00:01:21 18 decembrie 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147% 100% 23617 1352 decembrie , 500,817 18:2018:12 PM 14:34:00 Standard Instant Recovery Disk WIN-********** 01 21% 0%
1347 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 decembrie 2018 12:11:45 00:02:08 18 decembrie 2018 12:13:53 STU_DP_S3_****backup 1 100% rădăcină 1347 18, 2018 dec.: 12:11 45:00 PM 02:08:0 Standard Instant Recovery Disk WIN-*********** XNUMX
Backup 1349 Terminat 0 VMware Complet NGNCloudADC NBCC 18 decembrie 2018 12:12:02 PM 00:01:41 18 decembrie 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215, 149653, 100 23508 1347 316,319 18 2018 12 12 decembrie , 02 00:01:41 PM 0:99.7:99 Instant Recovery Disk Standard WIN-********** XNUMX XNUMX% XNUMX%
1341 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 decembrie 2018 12:05:28 00:04:53 18 decembrie 2018 12:10:21 STU_DP_S3_****backup 1 100% rădăcină 1341 18, 2018 dec.: 12:05 28:00 PM 04:53:0 Standard Instant Recovery Disk WIN-*********** XNUMX
1342 Backup gata 0 VMware Full_Rescan NGNCloudADC NBCC 18 decembrie 2018 12:05:47 PM 00:04:24 18 decembrie 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151% 149653 100 22999 1341 70,380 18 Dec 2018 , 12 05:47:00 PM 04:24:0 Instant Recovery Disk Standard WIN-*********** 87.9 0% XNUMX%
1339 Snapshot Done 150 VMware - NGNCloudADC NBCC 18 decembrie 2018 11:05:46 00:00:53 18 decembrie 2018 11:06:39 STU_DP_S3_****backup 1 100% rădăcină 1339 18, 2018 11 dec. 05:46 AM 00:00:53 Standard Instant Recovery Disk WIN-*********** 0
1327 Snapshot Done 0 VMware - *******.********.cloud NBCC 17 decembrie 2018 12:54:42 05:51:38 17 decembrie 2018 6:46:20 STU_DP_S3_****backup 1 100% root 1327 17 decembrie 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Backup gata 0 VMware complet *******.********.cloud NBCC 17 decembrie 2018 12:55:10 05:29:21 17 decembrie 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 Instant Recovery Disk Standard WIN. 0******* 87.9%
1136 Snapshot Done 0 VMware - *******.********.cloud NBCC 14 decembrie 2018 4:48:22 04:05:16 14 decembrie 2018 8:53:38 STU_DP_S3_****backup 1 100% root 1136 14 decembrie 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Backup gata 0 VMware Full_Scan *******.********.cloud NBCC 14 decembrie 2018 4:49:14 03:49:58 14 decembrie 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Dec 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk Standard WIN-******** 0 WIN-********. 45.2%
Acceleratorul vă permite să reduceți traficul de la agenți, deoarece Sunt transmise doar modificările de date, adică chiar și copiile de siguranță complete nu sunt încărcate în întregime, deoarece serverul media colectează copiile de siguranță complete ulterioare din copiile de siguranță incrementale.
Serverul intermediar are propria sa stocare, unde scrie un „cache” de date și menține o bază de date pentru deduplicare.
Arhitectura completă arată astfel:
- Serverul principal gestionează configurația, actualizările etc. și se află în cloud.
- Serverul media (mașină intermediară *nix) ar trebui să fie situat cel mai aproape de sistemele redundante în ceea ce privește accesibilitatea rețelei. Aici se face deduplicarea backup-urilor de pe toate mașinile rezervate.
- Pe mașinile cu copii de rezervă există agenți care, în general, trimit către serverul media doar ceea ce nu este în stocarea acestuia.
Totul începe cu o scanare completă - aceasta este o copie de rezervă completă. În acest moment, serverul media preia totul, îl deduplică și îl transferă pe S3. Viteza către serverul media este scăzută, dar de la acesta este mai mare. Principala limitare este puterea de calcul a serverului.
Următoarele backup-uri sunt realizate complete din punctul de vedere al tuturor sistemelor, dar în realitate sunt ceva de genul unor backup-uri complete sintetice. Adică, transferul și înregistrarea efectivă pe serverul media are loc numai a acelor blocuri de date care nu au fost încă întâlnite înainte în backup-urile VM. Și numai acele blocuri de date al căror hash nu se află în baza de date de deduplicare a serverului media sunt transferate și înregistrate în S3. Cu cuvinte mai simple, acesta este ceva ce nu a mai fost văzut niciodată în nicio copie de rezervă a unui singur VM.
În timpul restaurării, serverul media solicită obiectele deduplicate necesare de la S3, le rehidratează și le transferă agenților IRB, de exemplu. este necesar să se țină cont de volumul de trafic în timpul restaurării, care va fi egal cu volumul real de date restaurate.
Iată cum arată:
Și iată o altă bucată de bușteni169 Lucrări (0 În coadă 0 Activ 0 În așteptarea reîncercării 0 Suspendat 0 Incompletat 169 Terminat — 1 selectate)
Tip ID job Stare Starea Detalii Stare Politica job Programare job Client Media Server Ora de pornire Timp scurs Ora de încheiere Unitate de stocare Încercare Operațiune Kilobyți Fișiere Nume cale % Completat (estimat) PID Job Proprietar Copiere Parent ID job KB/sec Pornire activă Sesiune de profil robot Vault ID-ul media pentru a scoate datele Mișcarea în afara gazdei Tip principal Prioritate deduplicare Rata de deduplicare Accelerator de transport Optimizare Instanță sau partajare bază de date Gazdă
- 1372 Restaurare Terminat 0 NBPR01 NBCC 19 dec. 2018 1:05:58 00:04:32 19 dec. 2018 1:10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 2018 dec. :1 PM 06:00:00 WIN-*********** 04
Integritatea datelor este asigurată de protecția S3 în sine - există o bună redundanță acolo pentru a proteja împotriva defecțiunilor hardware, cum ar fi un ax de hard disk mort.
Serverul media are nevoie de 4 TB de cache - aceasta este dimensiunea minimă recomandată de Veritas. Mai mult este mai bine, dar asta am făcut.
Total
Când un partener a aruncat 3 GB în S20-ul nostru, am stocat 60 GB, deoarece oferim triplă rezervare geografică a datelor. Acum este mult mai puțin trafic, ceea ce este bun atât pentru canal, cât și pentru tarifele de stocare.
În acest caz, rutele sunt închise dincolo de „Internetul mare”, dar puteți conduce trafic prin VPN L2 prin Internet, dar este mai bine să instalați serverul media înainte de intrarea furnizorului.
Dacă sunteți interesat să aflați despre aceste funcții în centrele noastre de date din Rusia sau aveți întrebări despre implementare acasă, întrebați în comentarii sau prin e-mail [e-mail protejat].
Sursa: www.habr.com