🥇Cum să comprimăm până la 90% stocarea backup-urilor în stocarea obiectelor

Clienții noștri turci ne-au cerut să configurăm corect backup-ul pentru centrul de date. Am realizat astfel de proiecte în Rusia, dar aici povestea a fost mai mult despre a explora cum să facem cel mai bine acest lucru.

Dat fiind: există un depozit local S3, există Veritas NetBackup, care a primit o nouă funcționalitate extinsă pentru mutarea datelor în depozitele obiect, acum cu suport pentru deduplicare, și există o problemă cu spațiul liber în acest depozit local.

Sarcina: să ne asigurăm că procesul de stocare a backup-urilor este rapid și ieftin.

Așadar, anterior, în S3, totul era stocat pur și simplu ca fișiere, și erau copie complete ale mașinilor critice din centrul de date. Deci, nu era o optimizare foarte bună, dar totuși, totul funcționa la început. Acum a venit timpul să ne ocupăm și să facem corect.

În imagine este ceea ce am realizat:

După cum se poate observa, primul backup a fost realizat încet (70 MB/s), iar backup-urile ulterioare ale acelorași sisteme au fost semnificativ mai rapide.

Așadar, aici sunt câteva detalii suplimentare despre caracteristicile acestora.

Jurnalele de backup pentru cei care sunt pregătiți să citească o pagină din dumpFull with rescan
Dec 18, 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator a trimis 14883996160 bytes din 14883994624 bytes către server, optimizare 0.0%
Dec 18, 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats (flux multi-threaded folosit) pentru (NBCC): scannat: 14570817 KB, CR trimis: 1760761 KB, CR trimis prin FC: 0 KB, dedup: 87.9%, cache dezactivat

Full
Dec 18, 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator a trimis 181675008 bytes din 14884060160 bytes către server, optimizare 98.8%
Dec 18, 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats pentru (NBCC): scannat: 14569706 KB, CR trimis: 45145 KB, CR trimis prin FC: 0 KB, dedup: 99.7%, cache dezactivat

Incremental
Dec 18, 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator a trimis 9970688 bytes din 14726108160 bytes către server, optimizare 99.9%
Dec 18, 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats pentru (NBCC): scannat: 14383788 KB, CR trimis: 15700 KB, CR trimis prin FC: 0 KB, dedup: 99.9%, cache dezactivat

Full
Dec 18, 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator a trimis 171746816 bytes din 14884093952 bytes către server, optimizare 98.8%
Dec 18, 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO Stats pentru (NBCC): scannat: 14569739 KB, CR trimis: 34120 KB, CR trimis prin FC: 0 KB, dedup: 99.8%, cache dezactivat

Care este problema

Clienții doresc să facă backup-uri cât mai frecvent și să le stocheze cât mai ieftin. Cel mai bine este să le stocați ieftin în stocări de tip obiect, precum S3, deoarece acestea au cel mai mic cost de întreținere pe megabyte, din care se poate restaura backup-ul în termene rezonabile. Când sunt multe backup-uri, devine costisitor, deoarece o mare parte a stocării este ocupată de copii ale acelorași date. În cazul HaaS al colegilor turci, stocarea poate fi compactată cu aproximativ 80-90%. Este evident că aceasta se referă la specificul lor, dar cu siguranță aș conta pe un minim de 50% deduplicare.

Pentru a rezolva problema, principalii furnizori au creat de mult gateway-uri pentru S3 Amazon. Toate metodele lor sunt compatibile cu S3 local, dacă acestea suportă API-ul Amazon. În centrul nostru de date din Turcia, backup-ul se face în S3-ul nostru, la fel ca în T-III „Compresor” din Rusia, deoarece acest tip de lucru a dat rezultate bune pentru noi.

Iar S3-ul nostru este complet compatibil cu metodele de backup pentru Amazon S3. Asta înseamnă că toate instrumentele pentru backup care susțin aceste metode permit copierea totul într-un astfel de stocaj „din cutie”.

În Veritas NetBackup a fost realizată o funcție CloudCatalyst:

Astfel, între mașinile care trebuie să fie salvate și gateway-ul a fost inserat un server intermediar Linux, prin care trece traficul de backup de la agenții SRK și se face deduplicarea acestora „în curs” înainte de a fi transferate în S3. Dacă înainte erau 30 de backup-uri de 20 GB cu compresie, acum (datorită similarității mașinilor) volumul acestora a scăzut cu 90%. Motorul de deduplicare utilizat este același ca și în cazul stocării pe discuri obișnuite prin NetBackup.

Iată ce se întâmplă înainte de serverul intermediar:

Am testat și am concluzionat că implementarea în centrele noastre de date aduce economie de spațiu în stocările S3 pentru noi și pentru clienți. Ca deținător de centre de date comerciale, desigur, tarifăm în funcție de volumul ocupat, dar totuși, este foarte avantajos și pentru noi — deoarece câștigăm din locuri mai scalabile în software, nu din închirierea de echipamente. Și, de asemenea, aceasta reduce costurile interne.

Jurnale228 Jobs (0 Așteptate 0 Active 0 Așteptând Retries 0 Suspendate 0 Incomplete 228 Finalizate — 13 selectate)
(Filtru Aplicat [13])

Tip Job Id Tip Statut Detalii Statut Politica Job Program Job Client Media Server Timp Începere Timp Ecart Timp Final Unitate Stocare Operatie Încercare Kilobytes Fișiere Cale % Complet (Estimare) Job PID Proprietar Copiere Job Părinte ID KB/Sec Activ Începere Activ Ecart Robot Profil Vault ID Sesiune Media de Eliminat Mișcare Date Tip Off-Host Master Prioritate Rata Deduplicare Accelerator Transport Optimizare Instanță sau Bază de Date Partajare Host
— 1358 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1360 Backup Finalizat 0 VMware Complet 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 Recuperare Instantanee Disk Standard WIN-*********** 0 99.8% 99%
1352 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1354 Backup Finalizat 0 VMware Incremental 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 Recuperare Instantanee Disk Standard WIN-*********** 0 99.9% 100%
1347 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1349 Backup Finalizat 0 VMware Complet 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 Recuperare Instantanee Disk Standard WIN-*********** 0 99.7% 99%
1341 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1342 Backup Finalizat 0 VMware Complet_Rescan 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 Recuperare Instantanee Disk Standard WIN-*********** 0 87.9% 0%

1339 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1327 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1328 Backup Finalizat 0 VMware Complet *******.********.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 Recuperare Instantanee Disk Standard WIN-*********** 0 87.9% 0%
1136 Instantaneu Finalizat 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 Recuperare Instantanee Disk Standard WIN-*********** 0
1140 Backup Finalizat 0 VMware Complet_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 Recuperare Instantanee Disk Standard WIN-*********** 0 45.2% 0%

Acceleratorul permite reducerea traficului de la agenți, deoarece se transmit doar modificările datelor, adică chiar și backup-urile complete nu sunt transferate integral, deoarece serverul media compilează backup-uri complete ulterioare din backup-uri incrementale.

Serverul intermediar are un stocare proprie, unde scrie «cache» de date și păstrează o bază pentru deduplicare.

În arhitectura completă arată astfel:

Serverul principal gestionează configurația, actualizările și altele și se află în cloud.
Serverul media (mașină *nix intermediară) trebuie să fie cât mai aproape de sistemele rezervate în ceea ce privește accesibilitatea rețelei. Aici se face deduplicarea backup-urilor din toate mașinile rezervate.
Pe mașinile rezervate există agenți, care în general trimit către serverul media doar ceea ce nu există în stocarea acestuia.

Totul începe cu un scan complet — acesta este un backup complet adevărat. În acel moment, serverul media preia totul, efectuează deduplicarea și transferă în S3. Viteza către serverul media este scăzută, de la el — mai mare. Principala limitare este puterea de calcul a serverului.

Următoarele backup-uri sunt efectuate din punctul de vedere al tuturor sistemelor ca fiind complete, dar în realitate reprezintă ceva de genul backup-urilor complete sintetice. Adică transferul și scrierea efectivă pe serverul media se face doar pentru acele blocuri de date care nu au mai fost întâlnite în backup-urile VM anterior. Iar transferul și scrierea în S3 se fac doar pentru acele blocuri de date, a căror hash nu se află în baza de deduplicare a serverului media. Cu alte cuvinte, ceea ce nu a fost întâlnit în niciun backup al vreunei VM anterior.

Atunci când se restaurează, serverul media solicită obiectele deduplicated necesare de la S3, le rehidratează și le trimite agenților SRK, adică trebuie să se țină cont de volumul de trafic în timpul restaurării, care va fi egal cu volumul real al datelor restabilite.

Iată cum arată:

Și iată încă un fragment din jurnale169 Jobs (0 Queued 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 169 Done — 1 selected)

Integritatea datelor este asigurată prin protecția S3 — acolo există o redundanță bună pentru a proteja împotriva defecțiunilor hardware, cum ar fi un spindle de hard disk mort.

Media-server este nevoie de 4 TB de cache — aceasta este recomandarea Veritas pentru volumul minim. Mai bine mai mult, dar noi am procedat exact astfel.

Rezultatul

Când partenerul ne-a trimis 20 GB în S3, am stocat 60 GB, deoarece oferim o rezervare geografică de date de trei ori. Acum traficul este mult mai mic, ceea ce este bine și pentru canal, și pentru tarifarea stocării.

În acest caz, rutele sunt închise departe de „internetul mare”, dar este posibil să redirecționezi traficul și prin VPN L2 prin Internet, dar este mai bine să plasezi serverul media înainte de intrarea furnizorului.

Dacă ești interesat să afli despre aceste caracteristici în centrele noastre de date din Rusia sau ai întrebări despre implementarea la tine — întreabă în comentarii sau la adresa de email ekorotkikh@croc.ru.

Sursa: habr.com