Нашы турэцкія кліенты папрасілі нас правільна наладзіць бэкап для дата-цэнтра. Мы робім падобныя праекты ў Расіі, але менавіта тут гісторыя была больш пра даследаванне таго, як лепш зрабіць.
Дадзена: ёсць лакальнае S3-сховішча, ёсць Veritas NetBackup, які абзавёўся новым пашыраным функцыяналам па перасоўванні дадзеных у аб'ектныя сховішчы зараз ужо з падтрымкай дэдуплікацыі, і ёсць праблема са вольным месцам у гэтым лакальным сховішчы.
Задача: зрабіць усё так, каб працэс захоўвання рэзервовых дзід быў хуткі і танны.
Уласна, да гэтага ў S3 усё складалася проста файламі, прычым гэта былі поўныя злепкі крытычных машын дата-цэнтра. То бок, не так, каб вельмі аптымізавана, але затое ўсё працавала на старце. Цяпер жа прыйшоў час разабрацца і зрабіць правільна.
На малюнку тое, да чаго мы прыйшлі:
Як бачна, першы бэкап рабіўся павольна (70 Мб/с), а наступныя бэкапы тых жа сістэм - значна хутчэй.
Уласна, далей крыху больш дэталяў пра тое, якія там асаблівасці.
Логі бэкапаў для тых, хто гатовы чытаць паўстаронкі дампаFull with rescan
Dec 18, 2018 12:09:43 PM — Info bpbkar (pid=4452) accelerator sent 14883996160 bytes out of 14883994624 bytes to server, optimization 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 (multi-threaded stream used) for (NBCC): scanned: 14570817 KB, CR sent: 1760761 KB, CR sent over FC: 0 KB, dedup: 87.9%, cache disabled
Поўны
Dec 18, 2018 12:13:18 PM — Info bpbkar (pid=2864) accelerator sent 181675008 bytes out of 14884060160 bytes to server, optimization 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 for (NBCC): scanned: 14569706 KB, CR паменшыць: 45145 KB, CR паменшыць FC: 0 KB, страты: 99.7%, cache disabled
дадатковы
Dec 18, 2018 12:15:32 PM — Info bpbkar (pid=792) accelerator sent 9970688 bytes out of 14726108160 bytes to server, optimization 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 for (NBCC): scanned: 14383788 KB, CR паменшыць: 15700 KB, CR паменшыць FC: 0 KB, страты: 99.9%, cache disabled
Поўны
Dec 18, 2018 12:18:02 PM — Info bpbkar (pid=3496) accelerator sent 171746816 bytes out of 14884093952 bytes to server, optimization 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 for (NBCC): scanned: 14569739 KB, CR паменшыць: 34120 KB, CR паменшыць FC: 0 KB, страты: 99.8%, cache disabled
У чым праблема
Заказчыкі хочуць рабіць бекапы як мага часцей і захоўваць як мага танней. Танна захоўваць іх лепш за ўсё ў аб'ектных сховішчах тыпу S3, таму што яны абыходзяцца танней за ўсё па кошце абслугоўвання на Мегабайт з таго, адкуль можна накаціць бэкап назад у разумныя тэрміны. Калі бэкапу шмат, гэта становіцца не вельмі танна, таму што большую частку сховішчы займаюць копіі адных і тых жа дадзеных. У выпадку HaaS турэцкіх калег можна ўшчыльніць захоўванне прыкладна на 80-90%. Зразумелая справа, што гэта адносіцца менавіта да іх спецыфікі, але мінімум на 50% дэдупа я б дакладна разлічваў.
Для вырашэння праблемы асноўныя вендары ўжо даўно зрабілі гейтвеі на S3 Амазона. Усе іх метады сумяшчальныя з лакальнымі S3, калі яны падтрымліваюць API Амазона. У турэцкім ЦАД бэкап робіцца ў нашу S3, як і ў T-III Кампрэсары у Расіі, паколькі такая схема працы добра сябе паказала ў нас.
А наша S3 цалкам сумяшчальная з метадамі бэкапу ў Амазон S3. Гэта значыць усе сродкі для бэкапу, якія падтрымліваюць гэтыя метады, дазваляюць капіяваць усё ў падобнае сховішча «са скрынкі».
У Veritas NetBackup зрабілі фічу CloudCatalyst:
Гэта значыць паміж машынамі, якія трэба бэкапіць, і гейтвеем устаў прамежкавы Linux-сервер, праз які праходзіць бэкапны трафік з агентаў СРК і робіцца іх дэдуплікацыя налёту перад перадачай іх у S3. Калі раней тамака было 30 бэкапаў па 20 Гб з кампрэсіяй, то зараз (з-за падобнасці машын) іх стала па аб'ёме на 90% менш. Рухавічок дэдуплікацыі выкарыстоўваецца той жа, што і пры захоўванні на звычайных дысках сродкамі Netbackup.
Вось што адбываецца да прамежкавага сервера:
Мы пратэставалі і прыйшлі да высновы, што пры ўкараненні ў нашых ЦАД гэта дае эканомію месца ў сховішчах S3 для нас і для заказчыкаў. Як уладальнік камерцыйных ЦАД, вядома, тарыфікуем па займаемым аб'ёме, але ўсё роўна гэта вельмі выгадна для нас таксама - таму што зарабляць мы пачынаем на больш маштабуюцца месцах у софце, а не на арэндзе жалеза. Ну, і гэтае скарачэнне ўнутраных выдаткаў.
Логі228 Jobs (0 Queued 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 228 Done — 13 selected)
(Filter Applied [13])
Job Id Type State State Details Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Пат. Праграмнае забеспячэнне ID Media для выдалення Data Movement Off-Host Type Master Priority Deduplication Rate Transport Accelerator Optimization Instance or Database Share Host
- 1358 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:16:19 PM 00:02:18 Dec 18, 2018 12:18:37 PM STU_DP_S3_****backup 1 100 :1358:18 PM 2018:12:16 Instant Recovery Disk Standard WIN-*********** 27
1360 Backup Done 0 VMware Full NGNCloudADC NBCC Dec 18, 2018 12:16:48 PM 00:01:39 Dec 18, 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 ot 100 23858 Dec 1358 , 335,098 18:2018:12 PM 16:48:00 Instant Recovery Disk Standard WIN-*********** 01 39% 0%
1352 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:14:04 PM 00:02:01 Dec 18, 2018 12:16:05 PM STU_DP_S3_****backup 1 100% 1352 18:2018 PM 12:14:14 Instant Recovery Disk Standard WIN-*********** 00
1354 Backup Done 0 VMware Incremental NGNCloudADC NBCC Dec 18, 2018 12:14:34 PM 00:01:21 Dec 18, 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965, 147 100 23617 Dec 1352 , 500,817 18:2018:12 PM 14:34:00 Instant Recovery Disk Standard WIN-*********** 01 21% 0%
1347 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:11:45 PM 00:02:08 Dec 18, 2018 12:13:53 PM STU_DP_S3_****backup 1 100% 1347 18:2018 PM 12:11:45 Instant Recovery Disk Standard WIN-*********** 00
1349 Backup Done 0 VMware Full NGNCloudADC NBCC Dec 18, 2018 12:12:02 PM 00:01:41 Dec 18, 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 ot 100 23508 Dec 1347 , 316,319 18:2018:12 PM 12:02:00 Instant Recovery Disk Standard WIN-*********** 01 41% 0%
1341 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:05:28 PM 00:04:53 Dec 18, 2018 12:10:21 PM STU_DP_S3_****backup 1 100% 1341 18:2018 PM 12:05:28 Instant Recovery Disk Standard WIN-*********** 00
1342 Backup Done 0 VMware Full_Rescan NGNCloudADC NBCC Dec 18, 2018 12:05:47 PM 00:04:24 Dec 18, 2018 12:10:11 PM STU_DP_S3_****backup1 14,535,151 149653 100 root 22999 1341 Dec 70,380 , 18 2018:12:05 PM 47:00:04 Instant Recovery Disk Standard WIN-*********** 24 0% 87.9%
1339 Snapshot Done 150 VMware - NGNCloudADC NBCC Dec 18, 2018 11:05:46 AM 00:00:53 Dec 18, 2018 11:06:39 AM STU_DP_S3_****backup 1 100 1339:18 AM 2018:11:05 Instant Recovery Disk Standard WIN-*********** 46
1327 Snapshot Done 0 VMware — *******.********.cloud NBCC Dec 17, 2018 12:54:42 PM 05:51:38 Dec 17, 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 Dec 17, 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Backup Done 0 VMware Full *******.********.cloud NBCC Dec 17, 2018 12:55:10 PM 05:29:21 Dec 17, 2018 6:24:31 PM 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 S***** 0%
1136 Snapshot Done 0 VMware — *******.********.cloud NBCC Dec 14, 2018 4:48:22 PM 04:05:16 Dec 14, 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 Dec 14, 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Backup Done 0 VMware Full_Scan *******.********.cloud NBCC Dec 14, 2018 4:49:14 PM 03:49:58 Dec 14, 2018 8:39:12 PM 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 0%
Акселератар дазваляе паменшыць трафік з агентаў, т.я. перадаюцца толькі змены дадзеных, гэта значыць нават поўныя бэкапы не льюцца цалкам, паколькі медыя-сервер збірае наступныя поўныя рэзервовыя копіі з інкрыментальных бэкапаў.
Прамежкавы сервер мае сваё сховішча, куды ён піша "кэш" дадзеных і трымае базу для дэдуплікацыі.
У поўнай архітэктуры выглядае так:
- Майстар-сервер кіруе канфігурацыяй, абнаўленнямі і іншым і знаходзіцца ў воблаку.
- Медыя-сервер (прамежкавая *nix-машына) павінен знаходзіцца найболей блізка да рэзерваваных сістэм у плане сеткавай даступнасці. Тут робіцца дэдуплікацыя бекапаў з усіх машын, якія рэзервуюцца.
- На машынах, якія рэзервуюцца, ёсць агенты, якія ў агульным выпадку адпраўляюць на медыя-сервер толькі тое, чаго няма ў яго сховішчы.
Пачынаецца ўсё з поўнага сканавання - гэта паўнавартасны поўны бекап. У гэты момант медыя-сервер забірае ўсё, робіць дэдуплікацыю і перадае ў S3. Хуткасць да медыя-сервера нізкая, ад яго - вышэй. Галоўнае абмежаванне - вылічальная магутнасць сервера.
Наступныя бэкапы робяцца з пункту гледжання ўсіх сістэм поўнымі, але на справе гэта нешта накшталт сінтэтычных поўных бэкапаў. Гэта значыць фактычная перадача і запіс на медыя-сервер ідзе толькі тых блокаў дадзеных, якія яшчэ не сустракаліся ў рэзервовых копіях ВМ раней. А перадача і запіс у S3 ідзе толькі тых блокаў дадзеных, хэша якіх няма ў базе дэдуплікацыі медыя-сервера. Калі больш простымі словамі - што не сустракалася ні ў адным бэкапе ні адной ВМ раней.
Пры рэстары медыя-сервер запытвае патрэбныя дэдуплікаваныя аб'екты з S3, регидрирует іх і перадае агентам СРК, г.зн. трэба ўлічваць аб'ём трафіку пры рэстары, які будзе роўны рэальнаму аб'ёму аднаўляльных дадзеных.
Вось як гэта выглядае:
І вось яшчэ кавалак логаў169 Jobs (0 Queued 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 169 Done — 1 selected)
Job Id Type State State Details Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Пат. Праграмнае забеспячэнне ID Media для выдалення Data Movement Off-Host Type Master Priority Deduplication Rate Transport Accelerator Optimization Instance or Database Share Host
— 1372 Restore Done 0 nbpr01 NBCC Dec 19, 2018 1:05:58 PM 00:04:32 Dec 19, 2018 1:10:30 PM 1 14,380,577 1 100% 8548 1372 70,567:19:2018 PM 1:06:00 WIN-*********** 00
Цэласнасць дадзеных забяспечваецца абаронай самога S3 – там ёсць добрая надмернасць для абароны ад апаратных збояў тыпу загінулага шпіндзеля цвёрдай кружэлкі.
Медыя-серверу трэба 4 Тб кэша - гэта рэкамендацыя Верытаса па мінімальным аб'ёме. Лепш болей, але мы рабілі менавіта так.
Вынік
Калі партнёр кідаў у наша S3 20 Гб, мы захоўвалі 60 Гб, таму што забяспечваем трохразовае геарэзерваванне дадзеных. Цяпер трафіку куды менш, што добра і для канала, і для тарыфікацыі па захоўванні.
У дадзеным выпадку маршруты зачыненыя міма "вялікага Інтэрнэту", але можна ганяць трафік і праз VPN L2 праз Інтэрнэт, але толькі медыя-сервер лепш ставіць да правайдэрскага ўваходу.
Калі цікава даведацца пра гэтыя фічы ў нашых расійскіх ЦАДах ці ёсць пытанні па рэалізацыі ў сябе - пытайцеся ў каментарах ці ў пошце [электронная пошта абаронена].
Крыніца: habr.com