Kuidas tihendada objektikonteineris backupide salvestust kuni 90%

Meie Türgi kliendid palusid meil andmepankade jaoks varukoopiaid õigesti seadistada. Teeme sarnaseid projekte Venemaal, kuid siin oli lugu rohkem uurimise kohta, kuidas seda paremini teha.

Eeltingimus: on kohalik S3-salvestus, on Veritas NetBackup, mis on saanud uue laiendatud funktsionaalsuse andmete liigutamiseks objekti salvestustesse, toetades nüüd juba deduplikatsiooni, ja on probleem selle kohalikus salvestuses oleva vabade kohtadega.

Küsimus: teha nii, et varukoopiate salvestamise protsess oleks kiire ja odav.

Kuni nüüd laaditi S3-sse lihtsalt faile, ja need olid kriitiliste andmekeskuse masinate täislipid. See ei olnud nii öelda väga optimeeritud, kuid vähemalt töötas see alguses. Nüüd on aeg asjad õigesti korda seada.

Pildil on see, mille oleme saavutanud:

Kuidas näha, esimene varukoopia tehti aeglaselt (70 Mb/s), aga järjestikused varukoopiad samadelt süsteemidelt — tunduvalt kiiremini.

Edasijärgnevalt mõned detailid, millised seal omadused on.

Varukoopiate logid neile, kes on valmis lugema pool lehekülge väljavõttuTäis koos uuesti skannimisega
18. detsember 2018 12:09:43 — Info bpbkar (pid=4452) kiirendaja saatis serverile 14883996160 baiti, millest 14883994624 baidi, optimeerimine 0,0%
18. detsember 2018 12:10:07 — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Aruanne=PDDO statistika (mitme lõime kasutatud) (NBCC) jaoks: skaneeritud: 14570817 KB, CR saadetud: 1760761 KB, CR saadetud FC üle: 0 KB, dedup: 87,9%, vahemälu keelatud

Täielik
18. detsember 2018 12:13:18 — Info bpbkar (pid=2864) kiirendaja saatis serverile 181675008 baiti, millest 14884060160 baidi, optimeerimine 98,8%
18. detsember 2018 12:13:40 — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Aruanne=PDDO statistika (NBCC) jaoks: skaneeritud: 14569706 KB, CR saadetud: 45145 KB, CR saadetud FC üle: 0 KB, dedup: 99,7%, vahemälu keelatud

Inkrementaalne
18. detsember 2018 12:15:32 — Info bpbkar (pid=792) kiirendaja saatis serverile 9970688 baiti, millest 14726108160 baidi, optimeerimine 99,9%
18. detsember 2018 12:15:53 — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Aruanne=PDDO statistika (NBCC) jaoks: skaneeritud: 14383788 KB, CR saadetud: 15700 KB, CR saadetud FC üle: 0 KB, dedup: 99,9%, vahemälu keelatud

Täielik
18. detsember 2018 12:18:02 — Info bpbkar (pid=3496) kiirendaja saatis serverile 171746816 baiti, millest 14884093952 baidi, optimeerimine 98,8%
18. detsember 2018 12:18:24 — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Aruanne=PDDO statistika (NBCC) jaoks: skaneeritud: 14569739 KB, CR saadetud: 34120 KB, CR saadetud FC üle: 0 KB, dedup: 99,8%, vahemälu keelatud

Mis on probleem?

Kliendid soovivad varundada nii sageli kui võimalik ja hoida seda võimalikult odavalt. Odavat säilitamist on kõige parem teha objektide salvestustes, nagu S3, kuna need pakuvad madalaimat teeninduskulu megabaidi kohta, kust saab varukoopia kiirelt taastada. Kui varukoopiaid on palju, muutub see siiski kalliks, kuna suur osa salvestusest on sama teabe koopiad. Türgi kolleegide HaaS puhul saab salvestust kokku suruda umbes 80-90%. Loomulikult kehtib see just nende spetsiifilisuse kohta, kuid minimaalset 50% deduplikeerimist võiksin kindlasti oodata.

Probleemi lahendamiseks on peamised tootjad ammu juba loonud S3 Amazoni väravad. Kõik nende meetodid on ühilduvad kohalike S3-dega, kui need toetavad Amazoni API-d. Türgi andmekeskuses tehakse varukoopia meie S3-s, nagu ka Venemaa T-III "Kompressoris", kuna selline töömeetod on meie jaoks hästi toiminud.

Ja meie S3 on täielikult ühilduv varukoopiametoodikatega Amazoni S3 jaoks. See tähendab, et kõik varundamistooted, mis toetavad neid meetodeid, võimaldavad kõike sellesse salvestusse "karbist välja" kopeerida.

Veritas NetBackup on loonud funktsiooni CloudCatalyst:

Seega on masinate vahel, mida tuleb varundada, ja värava vahel vahepealne Linux-server, mille kaudu toimub varundusliiklus SRK agentidelt ning toimub nende deduplikatsioon "lennul" enne edastamist S3sse. Kui varem oli seal 30 varundust 20 GB kompresseerituna, siis nüüd (masinate sarnaste tõttu) on nende maht vähenenud 90%. Kasutatav deduplikatsioonimootor on sama, mis tavaliste ketaste peal hoidmise korral Netbackup'iga.

See, mis juhtub enne vaheserverit:

Oleme testinud ja järeldanud, et meie andmekeskustes rakendamine annab meile ja meie klientidele S3 salvestusruumi kokkuhoidu. Kaubanduse andmekeskuste omaniku poolest, loomulikult tasustame kasutatava mahu järgi, kuid see on meie jaoks ka väga kasulik — sest hakkame rohkem teenima skaleeritaval tarkvarapinnal, mitte riistvara rendil. Ja see vähendab ka sisemisi kulusid.

Logid228 tööd (0 ootel 0 aktiivne 0 ootab uuesti proovimist 0 peatatud 0 lõpetamata 228 tehtud — 13 valitud)
(Filtrit rakendatud [13])

Töö ID Tüüp Riik Riigi üksikasjad Staatus Töö poliitika Töö ajakava Klient Meedia Serveri algusaeg Läbimise aeg Lõppaeg Salvestusühik Katse Operatsioon Kilobaitide Failid Failitee % Täiustatud (Hinnanguline) Töö PID Omanik Koopia Vanema töö ID KB/Sek Aktiivne Algus Aktiivne Läbimine Robot Vault Profiil Sessiooni ID Meedia, mille soovite eemaldada Andmete edastamine Off-Host Tüüp Peamine Prioriteet Deduplication Määr Transport Kiirendaja Optimeerimise instants või andmebaas Jagada Host
— 1358 Snapshot Tehtud 0 VMware — NGNCloudADC NBCC 18. detsember 2018 12:16:19 PM 00:02:18 18. detsember 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18. detsember 2018 12:16:27 PM 00:02:10 Instant Recovery Disk Standard WIN-*********** 0
1360 Varundamine Tehtud 0 VMware Täielik NGNCloudADC NBCC 18. detsember 2018 12:16:48 PM 00:01:39 18. detsember 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18. detsember 2018 12:16:48 PM 00:01:39 Instant Recovery Disk Standard WIN-*********** 0 99.8% 99%
1352 Snapshot Tehtud 0 VMware — NGNCloudADC NBCC 18. detsember 2018 12:14:04 PM 00:02:01 18. detsember 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18. detsember 2018 12:14:14 PM 00:01:51 Instant Recovery Disk Standard WIN-*********** 0
1354 Varundamine Tehtud 0 VMware Korrigeeritud NGNCloudADC NBCC 18. detsember 2018 12:14:34 PM 00:01:21 18. detsember 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18. detsember 2018 12:14:34 PM 00:01:21 Instant Recovery Disk Standard WIN-*********** 0 99.9% 100%
1347 Snapshot Tehtud 0 VMware — NGNCloudADC NBCC 18. detsember 2018 12:11:45 PM 00:02:08 18. detsember 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18. detsember 2018 12:11:45 PM 00:02:08 Instant Recovery Disk Standard WIN-*********** 0
1349 Varundamine Tehtud 0 VMware Täielik NGNCloudADC NBCC 18. detsember 2018 12:12:02 PM 00:01:41 18. detsember 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18. detsember 2018 12:12:02 PM 00:01:41 Instant Recovery Disk Standard WIN-*********** 0 99.7% 99%
1341 Snapshoot lõpetatud 0 VMware — NGNCloudADC NBCC 18. detsember 2018 12:05:28 PM 00:04:53 18. detsember 2018 12:10:21 PM STU_DP_S3_****varukoopia 1 100% root 1341 18. detsember 2018 12:05:28 PM 00:04:53 Instant Recovery Disk Standard WIN-*********** 0
1342 Varukoopia lõpetatud 0 VMware Täis_uuring NGNCloudADC NBCC 18. detsember 2018 12:05:47 PM 00:04:24 18. detsember 2018 12:10:11 PM STU_DP_S3_****varukoopia 1 14,535,151 149653 100% 22999 root 1341 70,380 18. detsember 2018 12:05:47 PM 00:04:24 Instant Recovery Disk Standard WIN-*********** 0 87.9% 0%

1339 Snapshoot lõpetatud 150 VMware — NGNCloudADC NBCC 18. detsember 2018 11:05:46 AM 00:00:53 18. detsember 2018 11:06:39 AM STU_DP_S3_****varukoopia 1 100% root 1339 18. detsember 2018 11:05:46 AM 00:00:53 Instant Recovery Disk Standard WIN-*********** 0
1327 Snapshoot lõpetatud 0 VMware — *******.********.cloud NBCC 17. detsember 2018 12:54:42 PM 05:51:38 17. detsember 2018 6:46:20 PM STU_DP_S3_****varukoopia 1 100% root 1327 17. detsember 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Varukoopia lõpetatud 0 VMware Täis *******.********.cloud NBCC 17. detsember 2018 12:55:10 PM 05:29:21 17. detsember 2018 6:24:31 PM STU_DP_S3_****varukoopia 1 222,602,719 258932 100% 12856 root 1327 11,326 17. detsember 2018 12:55:10 PM 05:29:21 Instant Recovery Disk Standard WIN-*********** 0 87.9% 0%
1136 Snapshoot lõpetatud 0 VMware — *******.********.cloud NBCC 14. detsember 2018 4:48:22 PM 04:05:16 14. detsember 2018 8:53:38 PM STU_DP_S3_****varukoopia 1 100% root 1136 14. detsember 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Varukoopia lõpetatud 0 VMware Täis_Uuring *******.********.cloud NBCC 14. detsember 2018 4:49:14 PM 03:49:58 14. detsember 2018 8:39:12 PM STU_DP_S3_****varukoopia 1 217,631,332 255465 100% 26438 root 1136 15,963 14. detsember 2018 4:49:14 PM 03:49:58 Instant Recovery Disk Standard WIN-*********** 0 45.2% 0%

Akselerator võimaldab vähendada liiklust agentidelt, kuna edastatakse vaid andmete muudatused, mis tähendab, et isegi täielikke varukoopiaid ei edastata tervikuna, kuna meedia-server kogub järgnevaid täielikke varukoopiaid inkrementaalsetest varukoopiatest.

Vahe-serveril on oma salvestusruum, kuhu ta kirjutab andmete "vahekihid" ja hoiab andmebaasi dedupeerimiseks.

Täielik arhitektuur näeb välja järgmine:

1. Meister-server haldab konfiguratsiooni, uuendusi ja muud ning asub pilves.
2. Meedia-server (vahe *nix-masin) peaks asuma kõige lähemal varundatavate süsteemide võrguühendusele. Siin toimub varukoopiate dedupeerimine kõikidest varundatavatest masinatest.
3. Varundatavatel masinatel on agendid, kes üldjuhul saadavad meedia-serverile vaid seda, mida tema salvestusruumis ei ole.

Kõik algab täieliku skaneerimisega — see on täieõiguslik täielik varukoopia. Sel hetkel võtab meedia-server kõik, viib läbi dedupeerimise ja edastab S3. Kiirus meedia-serverisse on madal, sealt edasi — kõrgem. Peamine piirang on serveri arvutusvõime.

Järgmised varukoopiad tehakse kõikide süsteemide vaatepunktist täielikena, kuid tegelikult on need midagi sünteetiliste täielike varukoopiate taolist. See tähendab, et andmete edastamine ja salvestamine meedia serverisse käib ainult nende andmeplokkide osas, mida ei ole varasemates VM-i varukoopiate hulgas kohtatud. Andmete edastamine ja salvestamine S3-s toimub ainult nende andmeplokkide osas, mille hash ei ole meedia serveri deduplikatsioonibaasis. Lihtsamalt öeldes — mis ei ole varem üheski VM-i varukoopias olnud.

Taastamise ajal küsib meedia server vajalikud deduplikatsiooni objektid S3-lt, regeneriseerib need ja edastab SRK agentidele, seega tuleb väga arvestada taastamise ajal edastatava liikluse mahuga, mis vastab taastatavate andmete tegelikule mahule.

Nii see välja näeb:

Ja veel üks logi tükk169 Tööd (0 Ootel 0 Aktiivne 0 Uuesti Proovimise Ootel 0 Peatatatud 0 Täitmata 169 Tehtud — 1 valitud)

Töö ID Tüüp Riik Riigi üksikasjad Staatus Töö poliitika Töö ajakava Klient Meedia Serveri algusaeg Läbimise aeg Lõppaeg Salvestusühik Katse Operatsioon Kilobaitide Failid Failitee % Täiustatud (Hinnanguline) Töö PID Omanik Koopia Vanema töö ID KB/Sek Aktiivne Algus Aktiivne Läbimine Robot Vault Profiil Sessiooni ID Meedia, mille soovite eemaldada Andmete edastamine Off-Host Tüüp Peamine Prioriteet Deduplication Määr Transport Kiirendaja Optimeerimise instants või andmebaas Jagada Host
— 1372 Taastamine Tehtud 0 nbpr01 NBCC 19. dets 2018 13:05:58 00:04:32 19. dets 2018 13:10:30 1 14,380,577 1 100% 8548 root 1372 70,567 19. dets 2018 13:06:00 00:04:30 WIN-*********** 90000

Andmete terviklikkust tagab S3 enda kaitse — seal on hea üleliigsus, et kaitsta seadme rikke eest, näiteks rikutud kõvaketta spindli eest.

Meedia-serverile 4 TB vahetust on Veritase miinimumnõue. Mida rohkem, seda parem, aga me tegime just nii.

Kokkuvõte

Kui partner laadis meie S3-sse 20 GB, siis hoidsime 60 GB, sest garanteerime andmete kolmekordse georegulatsiooni. Hetkel on liiklus tunduvalt madalam, mis on hea nii kanali kui ka ladustamisarvestuse jaoks.

Antud juhul on marsruudid suletud mööda 'suurt Internetti', kuid liiklust saab suunata ka VPN L2 kaudu Internetis, kuid media-server tuleks paigaldada enne teenusepakkuja sisendit.

Kui soovid nende funktsioonide kohta meie Venemaa andmekeskustes rohkem teada saada või on küsimusi rakendamise kohta endal — küsi kommentaarides või e-posti teel ekorotkikh@croc.ru.

Allikas: habr.com