Hogyan lehet akár 90%-kal csökkenteni a biztonsági mentések tárolását objektumtárolóban?

Török ügyfeleink kértek minket, hogy megfelelően állítsuk be a biztonsági mentést az adatközpont számára. Ilyen projekteket végzünk Oroszországban is, de itt a történet inkább arról szólt, hogyan lehet a legjobban megoldani.

Adott: van egy helyi S3 tároló, van a Veritas NetBackup, amely új, kiterjesztett funkcióval bővült, lehetővé téve az adatok objektumtárolókba történő áthelyezését most már deduplikáció támogatásával, és van egy probléma a helyi tárolóban az üresedéssel.

Feladat: úgy megoldani, hogy a biztonsági mentések tárolási folyamata gyors és olcsó legyen.

Alapvetően az S3-ba eddig csak fájlok formájában tölthettük fel az adatokat, és ezek a kritikus adatközponti gépek teljes másolatai voltak. Nem volt tehát éppen optimális, de legalább minden az induláskor működött. Most viszont eljött az idő, hogy rendbe tegyük a dolgokat.

A képen látható az, amire jutottunk:

Hogyan lehet akár 90%-kal csökkenteni a biztonsági mentések tárolását objektumtárolóban?

Mint látható, az első biztonsági mentés lassan készült (70 MB/s), míg a további mentések azonos rendszerek esetén sokkal gyorsabbak voltak.

Most pedig kicsit több részlet a sajátosságokról.

A biztonsági mentések naplói azok számára, akik készen állnak fél oldalt olvasni a dumpbólTeljes újraszkennelés
2018. december 18., 12:09:43 — Info bpbkar (pid=4452) gyorsítósáv küldött 14883996160 byte-ot a 14883994624 byte-ból a szerverre, optimalizálás 0,0%
2018. december 18., 12:10:07 — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Jelentés=PDDO statisztikák (több szálon használt áramlás) (NBCC) számára: beolvasott: 14570817 KB, CR elküldve: 1760761 KB, CR elküldve FC-n: 0 KB, deduplikáció: 87,9%, gyorsítótár kikapcsolva

Teljes
2018. december 18., 12:13:18 — Info bpbkar (pid=2864) gyorsítósáv küldött 181675008 byte-ot a 14884060160 byte-ból a szerverre, optimalizálás 98,8%
2018. december 18., 12:13:40 — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Jelentés=PDDO statisztikák (NBCC) számára: beolvasott: 14569706 KB, CR elküldve: 45145 KB, CR elküldve FC-n: 0 KB, deduplikáció: 99,7%, gyorsítótár kikapcsolva

Növekményes
2018. december 18., 12:15:32 — Info bpbkar (pid=792) gyorsítósáv küldött 9970688 byte-ot a 14726108160 byte-ból a szerverre, optimalizálás 99,9%
2018. december 18., 12:15:53 — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Jelentés=PDDO statisztikák (NBCC) számára: beolvasott: 14383788 KB, CR elküldve: 15700 KB, CR elküldve FC-n: 0 KB, deduplikáció: 99,9%, gyorsítótár kikapcsolva

Teljes
2018. december 18., 12:18:02 — Info bpbkar (pid=3496) gyorsítósáv küldött 171746816 byte-ot a 14884093952 byte-ból a szerverre, optimalizálás 98,8%
2018. december 18., 12:18:24 — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Jelentés=PDDO statisztikák (NBCC) számára: beolvasott: 14569739 KB, CR elküldve: 34120 KB, CR elküldve FC-n: 0 KB, deduplikáció: 99,8%, gyorsítótár kikapcsolva

Mi a probléma?

A megrendelők gyakran szeretnék, ha a biztonsági másolatok készítése minél gyakoribb lenne, és azokat minél olcsóbban tárolnák. A legjobb megoldás az objektum tárolók, mint az S3, mivel ezek a legolcsóbbak az MB-ra vetített fenntartási költséget tekintve, ahonnan ésszerű időn belül vissza lehet állítani a biztonsági másolatot. Amikor sok biztonsági másolat készül, az nem igazán olcsó, mivel az adattárolás nagy részét az azonos adatok másolatai foglalják el. A török kollégák HaaS esetében a tárolás sűrítése körülbelül 80-90% -kal lehetséges. Nyilvánvaló, hogy ez kifejezetten az ő sajátos helyzetükre vonatkozik, de a legalább 50% -os deduplikációt biztosan elvárnám.

A probléma megoldására a fő szállítók már régóta készítettek S3 gateway-eket az Amazon számára. Minden módszerük kompatibilis a helyi S3-as rendszerekkel, ha támogatják az Amazon API-t. A törökországi adatközpontban a biztonsági mentés a mi S3 rendszerünkbe történik, akárcsak a T-III „Kompresszorban” Oroszországban, tekintve, hogy ez a munkafolyamat jól bevált nálunk.

A mi S3 rendszerünk teljes mértékben kompatibilis az Amazon S3 mentési módszereivel. Tehát minden olyan mentési eszköz, amely támogatja ezeket a módszereket, lehetővé teszi az adat másolását egy hasonló tárolóba „dobozban”.

A Veritas NetBackup rendszerében létrehoztak egy CloudCatalyst funkciót:

Hogyan lehet akár 90%-kal csökkenteni a biztonsági mentések tárolását objektumtárolóban?

Tehát azok között a gépek között, amelyeket menteni kell, és a gateway között egy köztes Linux szerver állt, amelyen keresztül a mentési forgalom befut az SRK ügynököktől, és ezeket valós időben deduplikálják, mielőtt továbbítják őket az S3-ba. Ha korábban 30 biztonsági másolat volt 20 GB-on tömörítéssel, akkor most (a gépek hasonlósága miatt) a mennyiségük 90%-kal csökkent. A deduplikáló motor ugyanaz, mint a klasszikus lemezes tárolásnál a Netbackup eszközeivel.

Ez történik a köztes szerver előtt:

Hogyan lehet akár 90%-kal csökkenteni a biztonsági mentések tárolását objektumtárolóban?

Teszteltük és arra a következtetésre jutottunk, hogy a mi adatközpontjainkba való bevezetés során ez helymegtakarítást eredményez az S3 tárolókban számunkra és az ügyfelek számára. Mint kereskedelmi adatközpont tulajdonos, természetesen az elfoglalt mennyiség szerint tarifázzuk, de ez nekünk is nagyon előnyös, mert úgy kezdünk el pénzt keresni, hogy a szoftver nagyobb méretezhetőségén dolgozunk, nem pedig a hardver bérbeadásán. Nos, és ez csökkenti a belső költségeinket.

Naplok228 Feladat (0 Várakozó 0 Aktív 0 Visszavárakozásra váró 0 Felfüggesztett 0 Hiányos 228 Kész - 13 kiválasztott)
(Alkalmazott szűrő [13])

Feladat Azonosító Típus Állapot Állapot Részletek Státusz Feladat Politika Feladat Ütemezés Ügyfél Média Szerver Kezdési Idő Előző Idő Befejezési Idő Tárolóegység Kísérlet Művelet Kilobájt Fájlok Útvonal % Teljesítmény (Becsült) Feladat PID Tulajdonos Másolat Szülő Feladat ID KB/Sek Aktív Kezdés Aktív Előző Robot Vault Profil Ülés ID Média Kivonás Adatmozgás Külső Típus Mester Prioritás Dedupikációs Arány Szállító Gyorsító Optimalizálás Példány vagy Adatbázis Megosztás Gazda
— 1358 Pillanatkép Kész Sikeres 0 VMware — NGNCloudADC NBCC 2018. dec. 18. 12:16:19 00:02:18 2018. dec. 18. 12:18:37 STU_DP_S3_****backup 1 100% root 1358 2018. dec. 18. 12:16:27 00:02:10 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1360 Biztonsági Másolat Kész Sikeres 0 VMware Teljes NGNCloudADC NBCC 2018. dec. 18. 12:16:48 00:01:39 2018. dec. 18. 12:18:27 STU_DP_S3_****backup 1 14 535 248 149 654 100% 23 858 root 1358 335 098 2018. dec. 18. 12:16:48 00:01:39 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 99,8% 99%
1352 Pillanatkép Kész Sikeres 0 VMware — NGNCloudADC NBCC 2018. dec. 18. 12:14:04 00:02:01 2018. dec. 18. 12:16:05 STU_DP_S3_****backup 1 100% root 1352 2018. dec. 18. 12:14:14 00:01:51 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1354 Biztonsági Másolat Kész Sikeres 0 VMware Növekményes NGNCloudADC NBCC 2018. dec. 18. 12:14:34 00:01:21 2018. dec. 18. 12:15:55 STU_DP_S3_****backup 1 14 380 965 147 100% 23 617 root 1352 500 817 2018. dec. 18. 12:14:34 00:01:21 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 99,9% 100%
1347 Pillanatkép Kész Sikeres 0 VMware — NGNCloudADC NBCC 2018. dec. 18. 12:11:45 00:02:08 2018. dec. 18. 12:13:53 STU_DP_S3_****backup 1 100% root 1347 2018. dec. 18. 12:11:45 00:02:08 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1349 Biztonsági Másolat Kész Sikeres 0 VMware Teljes NGNCloudADC NBCC 2018. dec. 18. 12:12:02 00:01:41 2018. dec. 18. 12:13:43 STU_DP_S3_****backup 1 14 535 215 149 653 100% 23 508 root 1347 316 319 2018. dec. 18. 12:12:02 00:01:41 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 99,7% 99%
1341 Pillanatkép Kész Sikeres 0 VMware — NGNCloudADC NBCC 2018. dec. 18. 12:05:28 00:04:53 2018. dec. 18. 12:10:21 STU_DP_S3_****backup 1 100% root 1341 2018. dec. 18. 12:05:28 00:04:53 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1342 Biztonsági Másolat Kész Sikeres 0 VMware Teljes Újraszkennelés NGNCloudADC NBCC 2018. dec. 18. 12:05:47 00:04:24 2018. dec. 18. 12:10:11 STU_DP_S3_****backup 1 14 535 151 149 653 100% 22 999 root 1341 70 380 2018. dec. 18. 12:05:47 00:04:24 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 87,9% 0%

1339 Pillanatkép Kész Sikeres 150 VMware — NGNCloudADC NBCC 2018. dec. 18. 11:05:46 00:00:53 2018. dec. 18. 11:06:39 STU_DP_S3_****backup 1 100% root 1339 2018. dec. 18. 11:05:46 00:00:53 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1327 Pillanatkép Kész Sikeres 0 VMware — *******.********.cloud NBCC 2018. dec. 17. 12:54:42 05:51:38 2018. dec. 17. 18:46:20 STU_DP_S3_****backup 1 100% root 1327 2018. dec. 17. 12:54:42 05:51:38 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1328 Biztonsági Másolat Kész Sikeres 0 VMware Teljes *******.********.cloud NBCC 2018. dec. 17. 12:55:10 05:29:21 2018. dec. 17. 18:24:31 STU_DP_S3_****backup 1 222 602 719 258 932 100% 12 856 root 1327 11 326 2018. dec. 17. 12:55:10 05:29:21 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 87,9% 0%
1136 Pillanatkép Kész Sikeres 0 VMware — *******.********.cloud NBCC 2018. dec. 14. 16:48:22 04:05:16 2018. dec. 14. 20:53:38 STU_DP_S3_****backup 1 100% root 1136 2018. dec. 14. 16:48:22 04:05:16 Azonnali Visszaállítási Lemez Standard WIN-*********** 0
1140 Biztonsági Másolat Kész Sikeres 0 VMware Teljes_Szkennelés *******.********.cloud NBCC 2018. dec. 14. 16:49:14 03:49:58 2018. dec. 14. 20:39:12 STU_DP_S3_****backup 1 217 631 332 255 465 100% 26 438 root 1136 15 963 2018. dec. 14. 16:49:14 03:49:58 Azonnali Visszaállítási Lemez Standard WIN-*********** 0 45,2% 0%

Az akcelerátor lehetővé teszi az ügynökök forgalmának csökkentését, mivel csak az adatváltozások kerülnek átvitelre, vagyis még a teljes biztonsági másolatok sem kerülnek teljes egészében átkonvertálásra, mivel a média szerver az inkrementális biztonsági mentésekből állítja össze a további teljes biztonsági másolatokat.

A köztes szerver saját tárolóval rendelkezik, ahová írja a „cache” adatokat, és fenntart egy adatbázist a deduplikáláshoz.

A teljes architektúra így néz ki:

  1. A mester szerver felügyeli a konfigurációt, frissítéseket és egyebeket, és felhőben található.
  2. A média szervernek (köztes *nix gép) a lehető legközelebb kell lennie a biztonsági mentés alatt álló rendszerekhez hálózati elérhetőség szempontjából. Itt végezni kell a biztonsági mentések deduplikálását az összes biztonsági mentett gépről.
  3. A biztonsági mentett gépeken ügynökök találhatók, amelyek általában csak azt küldik el a média szerverre, ami még nincs a tárolóban.

Minden a teljes átvizsgálással kezdődik – ez egy teljes biztonsági mentés. Ebben a pillanatban a média szerver mindent összegyűjt, deduplikálja, és átadja az S3-nak. A média szerverhez való elérhetőség alacsony, onnan viszont magasabb. A legfőbb korlátozás a szerver számítási teljesítménye.

A következő biztonsági mentések az összes rendszer szempontjából teljesnek számítanak, de valójában ez valami ilyesmi, mint a szintetikus teljes biztonsági mentések. Tehát a tényleges adatblokkok átvitele és rögzítése a média szerveren csak azokat a blokkokat érinti, amelyek korábban nem fordultak elő a virtuális gépek biztonsági mentéseiben. Az S3-ra való átvitel és rögzítés csak azoknak az adatblokkoknak történik, amelyek hash értéke nem szerepel a média szerver deduplikáló adatbázisában. Egyszerűbben szólva — ami korábban egyetlen biztonsági mentésben sem fordult elő az összes virtuális gép esetében.

A visszaállítás során a média szerver lekéri a szükséges deduplikált objektumokat az S3-ból, rehidratálja azokat, és átadja a CRK ügynököknek, tehát figyelembe kell venni a visszaállítás során a forgalom mennyiségét, amely megegyezik a helyreállított adatok tényleges mennyiségével.

Így néz ki:

Hogyan lehet akár 90%-kal csökkenteni a biztonsági mentések tárolását objektumtárolóban?

És itt van még egy rész a naplókból169 Feladat (0 Várakozik 0 Aktív 0 Újrapróbálásra vár 0 Felfüggesztett 0 Hiányos 169 Kész — 1 kiválasztva)

Feladat Azonosító Típus Állapot Állapot Részletek Státusz Feladat Politika Feladat Ütemezés Ügyfél Média Szerver Kezdési Idő Előző Idő Befejezési Idő Tárolóegység Kísérlet Művelet Kilobájt Fájlok Útvonal % Teljesítmény (Becsült) Feladat PID Tulajdonos Másolat Szülő Feladat ID KB/Sek Aktív Kezdés Aktív Előző Robot Vault Profil Ülés ID Média Kivonás Adatmozgás Külső Típus Mester Prioritás Dedupikációs Arány Szállító Gyorsító Optimalizálás Példány vagy Adatbázis Megosztás Gazda
— 1372 Visszaállítás kész 0 nbpr01 NBCC 2018. dec. 19. 13:05:58 00:04:32 2018. dec. 19. 13:10:30 1 14,380,577 1 100% 8548 root 1372 70,567 2018. dec. 19. 13:06:00 00:04:30 WIN-*********** 90000

Az adatok integritását az S3 saját védelme biztosítja – ott jó redundancia található a hardverhibák, például a meghalt merevlemez-spindle ellen.

Média-szerverhez 4 TB cache szükséges – ez a Veritas javaslata a minimális mennyiségre. Jobb, ha több, de pontosan így csináltuk.

Result

Amikor a partnerünk 20 GB-ot töltött fel az S3-ba, mi 60 GB-ot tároltunk, mert háromszoros geo-redundanciával biztosítjuk az adatokat. Most sokkal kevesebb a forgalom, ami jónak mondható mind a csatorna, mind a tárolás díjazása szempontjából.

Ebben az esetben az útvonalak el vannak zárva a 'nagy Interneten' kívül, de a forgalom átirányítható. VPN L2-n keresztül az Interneten, de a média szerverünket jobb a szolgáltató bejárata elé telepíteni.

Ha érdeklik ezek a funkciók a hazai adatközpontjainkban, vagy kérdése van a saját megvalósításával kapcsolatban, kérdezzen kommentben vagy írjon az ekorotkikh@croc.ru címre.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster