🥇Kā saspiest līdz 90% datus backupu glabāšanā objektu krātuvē

Mūsu Turcijas klienti lūdza mūs pareizi iestatīt dublējumkopiju datu centram. Mēs veicam līdzīgus projektus Krievijā, taču šajā gadījumā stāsts vairāk bija par izpēti, kā to izdarīt labāk.

Dota: ir lokāla S3 glabātuve, ir Veritas NetBackup, kas ieguvis jaunu paplašinātu funkcionalitāti datu pārvietošanai objektu glabātuvēs ar atbalstu deduplikācijai, un ir problēma ar brīvo vietu šajā lokālajā glabātuvē.

Uzdevums: panākt, lai dublēšanas process būtu ātrs un lēts.

Faktiski iepriekš S3 glabāja vienkārši kā failus, un tie bija pilni kritisko datu centra mašīnu attēli. Tas nebija gluži optimizēti, bet darbojās sākumā. Tagad ir pienācis laiks to izprast un izdarīt pareizi.

Attēlā redzams tas, pie kā mēs esam nonākuši:

Kā redzams, pirmais dublējums tika veikts lēni (70 MB/s), bet nākamie to pašu sistēmu dublējumi – ievērojami ātrāk.

Faktiski tālāk ir nedaudz vairāk sīkumu par to, kādas ir šīs īpatnības.

Dublēšanas žurnāli tiem, kas gatavi lasīt puslapa ietilpīgu atskaitiPilns ar atkārtotu skenēšanu
2018. gada 18. decembris 12:09:43 PM — Info bpbkar (pid=4452) paātrinātājs nosūtīja 14883996160 baitus no 14883994624 baitiem serverim, optimizācija 0.0%
2018. gada 18. decembris 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Atskaites=PDDO statistika (vairāku pavedienu plūsma izmantota) (NBCC): skenēti: 14570817 KB, CR nosūtīts: 1760761 KB, CR nosūtīts pa FC: 0 KB, dedup: 87.9%, kešatmiņa atslēgta

Pilns
2018. gada 18. decembris 12:13:18 PM — Info bpbkar (pid=2864) paātrinātājs nosūtīja 181675008 baitus no 14884060160 baitiem serverim, optimizācija 98.8%
2018. gada 18. decembris 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Atskaites=PDDO statistika (NBCC): skenēti: 14569706 KB, CR nosūtīts: 45145 KB, CR nosūtīts pa FC: 0 KB, dedup: 99.7%, kešatmiņa atslēgta

Inkrementāls
2018. gada 18. decembris 12:15:32 PM — Info bpbkar (pid=792) paātrinātājs nosūtīja 9970688 baitus no 14726108160 baitiem serverim, optimizācija 99.9%
2018. gada 18. decembris 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Atskaites=PDDO statistika (NBCC): skenēti: 14383788 KB, CR nosūtīts: 15700 KB, CR nosūtīts pa FC: 0 KB, dedup: 99.9%, kešatmiņa atslēgta

Pilns
2018. gada 18. decembris 12:18:02 PM — Info bpbkar (pid=3496) paātrinātājs nosūtīja 171746816 baitus no 14884093952 baitiem serverim, optimizācija 98.8%
2018. gada 18. decembris 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Atskaites=PDDO statistika (NBCC): skenēti: 14569739 KB, CR nosūtīts: 34120 KB, CR nosūtīts pa FC: 0 KB, dedup: 99.8%, kešatmiņa atslēgta

Kāda ir problēma

Pasūtītāji vēlas veikt rezerves kopijas cik bieži vien iespējams un glabāt tās par iespējami zemākām cenām. Lētāk tās vislabāk glabāt objektu krātuvēs, piemēram, S3, jo tās ir visizdevīgākās uzturēšanas izmaksu ziņā par megabaitu, no kuras rezerves kopiju var atjaunot saprātīgā laikā. Kad rezerves kopiju ir daudz, izmaksas kļūst ne tik lētas, jo lielāko daļu krātuves aizņem vienas un tās pašas datu kopijas. HaaS gadījumā ar turku kolēģiem glabāšanu var saspiest apmēram par 80-90%. Saprotams, ka tas attiecas tieši uz viņu specifiku, taču vismaz par 50% deduplicēšanas es noteikti gribētu cerēt.

Lai atrisinātu problēmu, galvenie piegādātāji jau sen ir izstrādājuši vārti uz Amazon S3. Visi viņu paņēmieni ir saderīgi ar vietējiem S3, ja tie atbalsta Amazon API. Turku datu centrā rezerves kopija tiek veidota mūsu S3, tāpat kā T-III „Kompresorā” Krievijā, jo šāda darba shēma ir labi sevi pierādījusi pie mums.

Mūsu S3 ir pilnīgi saderīga ar rezerves kopēšanas paņēmieniem, kuri tiek izmantoti Amazon S3. Tas nozīmē, ka visi rīki rezerves kopijām, kas atbalsta šos paņēmienus, ļauj visu kopēt līdzīgā krātuvē „no kastes”.

Veritas NetBackup izstrādāja funkciju CloudCatalyst:

Tas nozīmē, ka starp mašīnām, kuras jārezerves kopē, un vārtiem ir starpniekserveris Linux, caur kuru pāriet rezerves kopēšanas satiksme no SRK aģentiem un tiek veikta to deduplicēšana „lidojuma laikā” pirms nodošanas uz S3. Ja agrāk tur bija 30 rezerves kopiju pa 20 GB ar kompresiju, tad tagad (dēļ mašīnu līdzības) to apjoms ir samazinājies par 90%. Deduplicēšanas dzinējs ir tas pats, kāds tiek izmantots, glabājot uz parastajiem diskiem ar NetBackup līdzekļiem.

Šeit ir tas, kas notiek līdz starpniekserverim:

Mēs esam veikuši testus un secinājuši, ka, ieviešot to mūsu datu centros, tas sniedz ietaupījumu krātuvēs S3 gan mums, gan klientiem. Kā komerciālo datu centru īpašnieks, protams, mēs iekasējam maksu par aizņemto apjomu, taču tas ir ļoti izdevīgi arī mums — jo mēs sākam pelnīt uz vairāk mērogainiem projektiem programmatūrā, nevis uz dzelžiem. Nu, un tas samazina iekšējos izdevumus.

Žurnāli228 Darbi (0 Gaida 0 Aktīvi 0 Gaidot atkārtot 0 Apturēti 0 Nepabeigti 228 Pabeigti — 13 izvēlēti)
(Filtrs piemērots [13])

Darba ID Tips Valsts Valsts detaļu Statuss Darba politika Darba grafiks Klients Mediji Serveris Sākuma laiks Pārejošais laiks Beigu laiks Glabāšanās vienība Mēģinājuma darbība Kilobaiti Faili Ceļa nosaukums % Pabeigts (aptuveni) Darba PID Īpašnieks Kopēt vecāku darba ID KB/Sek Aktīvs sākums Aktīvs ilgums Robots Vault profils Sesijas ID Mediji, kas jāizņem Datu pārvietošana Off-Host tips Master Prioritāte Deduplikācijas līmenis Transportēšanas paātrinājums Optimizācijas instance vai datubāze Koplietošanas viesis
— 1358 Snapshot pabeigts 0 VMware — NGNCloudADC NBCC 2018. gada 18. decembris 12:16:19 PM 00:02:18 2018. gada 18. decembris 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 2018. gada 18. decembris 12:16:27 PM 00:02:10 Instant Recovery Disk Standarta WIN-*********** 0
1360 Dublēšana pabeigta 0 VMware Pilns NGNCloudADC NBCC 2018. gada 18. decembris 12:16:48 PM 00:01:39 2018. gada 18. decembris 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 2018. gada 18. decembris 12:16:48 PM 00:01:39 Instant Recovery Disk Standarta WIN-*********** 0 99.8% 99%
1352 Snapshot pabeigts 0 VMware — NGNCloudADC NBCC 2018. gada 18. decembris 12:14:04 PM 00:02:01 2018. gada 18. decembris 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 2018. gada 18. decembris 12:14:14 PM 00:01:51 Instant Recovery Disk Standarta WIN-*********** 0
1354 Dublēšana pabeigta 0 VMware Inkrementāla NGNCloudADC NBCC 2018. gada 18. decembris 12:14:34 PM 00:01:21 2018. gada 18. decembris 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 2018. gada 18. decembris 12:14:34 PM 00:01:21 Instant Recovery Disk Standarta WIN-*********** 0 99.9% 100%
1347 Snapshot pabeigts 0 VMware — NGNCloudADC NBCC 2018. gada 18. decembris 12:11:45 PM 00:02:08 2018. gada 18. decembris 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 2018. gada 18. decembris 12:11:45 PM 00:02:08 Instant Recovery Disk Standarta WIN-*********** 0
1349 Dublēšana pabeigta 0 VMware Pilns NGNCloudADC NBCC 2018. gada 18. decembris 12:12:02 PM 00:01:41 2018. gada 18. decembris 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 2018. gada 18. decembris 12:12:02 PM 00:01:41 Instant Recovery Disk Standarta WIN-*********** 0 99.7% 99%
1341 Snapshot pabeigts 0 VMware — NGNCloudADC NBCC 2018. gada 18. decembris 12:05:28 PM 00:04:53 2018. gada 18. decembris 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 2018. gada 18. decembris 12:05:28 PM 00:04:53 Instant Recovery Disk Standarta WIN-*********** 0
1342 Dublēšana pabeigta 0 VMware Pilns_Rescan NGNCloudADC NBCC 2018. gada 18. decembris 12:05:47 PM 00:04:24 2018. gada 18. decembris 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 2018. gada 18. decembris 12:05:47 PM 00:04:24 Instant Recovery Disk Standarta WIN-*********** 0 87.9% 0%

1339 Snapshot pabeigts 150 VMware — NGNCloudADC NBCC 2018. gada 18. decembris 11:05:46 AM 00:00:53 2018. gada 18. decembris 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 2018. gada 18. decembris 11:05:46 AM 00:00:53 Instant Recovery Disk Standarta WIN-*********** 0
1327 Snapshot pabeigts 0 VMware — *******.********.cloud NBCC 2018. gada 17. decembris 12:54:42 PM 05:51:38 2018. gada 17. decembris 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 2018. gada 17. decembris 12:54:42 PM 05:51:38 Instant Recovery Disk Standarta WIN-*********** 0
1328 Dublēšana pabeigta 0 VMware Pilns *******.********.cloud NBCC 2018. gada 17. decembris 12:55:10 PM 05:29:21 2018. gada 17. decembris 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 2018. gada 17. decembris 12:55:10 PM 05:29:21 Instant Recovery Disk Standarta WIN-*********** 0 87.9% 0%
1136 Snapshot pabeigts 0 VMware — *******.********.cloud NBCC 2018. gada 14. decembris 4:48:22 PM 04:05:16 2018. gada 14. decembris 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 2018. gada 14. decembris 4:48:22 PM 04:05:16 Instant Recovery Disk Standarta WIN-*********** 0
1140 Dublēšana pabeigta 0 VMware Pilns_Scan *******.********.cloud NBCC 2018. gada 14. decembris 4:49:14 PM 03:49:58 2018. gada 14. decembris 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 2018. gada 14. decembris 4:49:14 PM 03:49:58 Instant Recovery Disk Standarta WIN-*********** 0 45.2% 0%

Akselerators ļauj samazināt datu plūsmu no aģentiem, jo tiek nosūtītas tikai izmaiņas, tātad pat pilni dublējumus netiek pārsūtīti uzreiz, jo multimediju serveris veido turpmākus pilnus dublējumus no inkrementālajiem dublējumiem.

Starpposms serveris ir aprīkots ar savu krātuvi, kurā tas raksta "kešu" datiem un glabā datu deduplikācijai.

Pilnā arhitektūra izskatās šādi:

Meistara serveris pārvalda konfigurāciju, atjauninājumus un citas funkcijas, un atrodas mākonī.
Multimediju serverim (starpposma *nix mašīnai) jābūt pēc iespējas tuvāk rezervētajām sistēmām līdz tīkla pieejamības ziņā. Šeit tiek veikta dublējumu deduplikācija no visām rezervētajām mašīnām.
Uz rezervētajām mašīnām ir aģenti, kas vispārīgi sūta uz multimediju serveri tikai to, kā nav tā krātuvē.

Viss sākas ar pilnu skenēšanu — tas ir pilnvērtīgs pilns dublējums. Šajā brīdī multimediju serveris iegūst visu, veic deduplikāciju un pārsūta uz S3. Ātrums līdz multimediju serverim ir zems, no tā — augstāks. Galvenais ierobežojums ir servera aprēķinu jauda.

Nākamie dublējumi tiek veikti visu sistēmu skatījumā kā pilni, bet patiesībā tie ir kaut kas līdzīgs sintētiskiem pilniem dublējumiem. Tātad faktiskā datu bloku pārsūtīšana un ierakstīšana uz multimediju serveri notiek tikai ar tiem blokiem, kas iepriekš nav sastopami VM dublējumos. Savukārt pārsūtīšana un ierakstīšana uz S3 notiek tikai ar tām datu bloku shēmām, kuru nav deduplikācijas datubāzē multimediju serverī. Ja vienkāršiem vārdiem sakot — tas, kas iepriekš nav bijis nevienā VM dublējumā.

Atjaunošanas procesā multimediju serveris pieprasa nepieciešamos deduplikāciju objektus no S3, atdzīvinot tos un nosūtot aģentiem CKR, tātad jāņem vērā datu plūsmas apjoms atjaunošanas procesā, kas būs vienāds ar faktisko atjaunojamo datu apjomu.

Lūk, kā tas izskatās:

Un šeit ir vēl kāds žurnāla fragments169 darbi (0 rindā 0 aktīvi 0 gaida atkārtotu mēģinājumu 0 apturēti 0 nepabeigti 169 pabeigti — 1 atlasīts)

Datu integritāte tiek nodrošināta ar S3 pašu aizsardzību — tur ir laba redundance, lai pasargātu no aparatūras kļūdām, piemēram, mirušā cietā diska.

Multimediju-serverim ir nepieciešami 4 TB keša — tas ir Veritas ieteikums par minimālo apjomu. Labāk ir vairāk, bet mēs tieši tā arī darījām.

Rezultāts

Kad partneris augšupielādēja 20 GB mūsu S3, mēs uzglabājām 60 GB, jo nodrošinām trīskāršu datu ģeoredundanci. Tagad datu plūsma ir daudz zemāka, kas ir labi gan kanāla, gan uzglabāšanas tarifam.

Šajā gadījumā maršruti ir slēgti gar «lielo internetu», taču ir iespējams virzīt datu plūsmu arī caur VPN L2 caur internetu, taču labāk ir novietot multivides serveri pirms pakalpojumu sniedzēja pieslēguma.

Ja vēlaties uzzināt vairāk par šīm funkcijām mūsu Krievijas datu centros vai ja ir jautājumi par realizāciju jūsu pusē — jautājiet komentāros vai uz ekorotkikh@croc.ru.

Avots: habr.com

Kā saspiest līdz 90% datus, glabājot dublējumus objektu glabātuvē

Kāda ir problēma

Rezultāts