Нашите турски клиенти ни поискаха да настроим правилно резервното копиране за дата центъра. Правим подобни проекти в Русия, но в случая става въпрос за проучване на най-добрия начин за изпълнението му.
Дадено: има локално S3 хранилище, има Veritas NetBackup, който вече предлага разширена функционалност за пренос на данни в обектни хранилища с поддръжка на дедупликация и има проблем с наличното пространство в локалното хранилище.
Задача: да осигурим бързо и икономично резервно копиране.
Преди това в S3 просто се съхраняваха файлове, а именно пълни дубликати на критичните машини в дата центъра. Не беше много оптимизирано, но поне всичко работеше. Сега е време да се направи както трябва.
На изображението е резултатът от нашата работа:
Както се вижда, първото резервно копие беше направено бавно (70 MB/s), а последващите резервни копия на същите системи са значително по-бързи.
Тук ще предоставим малко повече подробности относно специфичните аспекти.
Лога на резервните копия за тези, които са готови да прочетат половин страница от дампа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
Full
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 sent: 45145 KB, CR sent over FC: 0 KB, dedup: 99.7%, cache disabled
Incremental
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 sent: 15700 KB, CR sent over FC: 0 KB, dedup: 99.9%, cache disabled
Full
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 sent: 34120 KB, CR sent over FC: 0 KB, dedup: 99.8%, cache disabled
Какъв е проблемът
Клиентите искат да правят резервни копия колкото се може по-често и да ги съхраняват на колкото се може по-ниска цена. Най-добре за ниска цена е да ги съхраняват в обектни хранилища като S3, защото те са най-евтини по отношение на обслужването на мегабайт, от които може да се възстанови резервната копия в разумни срокове. Когато резервните копия са много, това става не особено евтино, защото голяма част от хранилището заемат копия на едни и същи данни. В случай на HaaS, колегите от Турция могат да компресират съхранението с около 80-90%. Ясно е, че това се отнася именно до тяхната специфика, но най-малко на 50% дедупликация бих определено очаквал.
За решаване на проблема, основните доставчици отдавна са направили гейтове за S3 на Amazon. Всички техни методи са съвместими с локалните S3, при условие че те поддържат API на Amazon. В турския ЦОД резервната копия се прави в нашето S3, подобно на T-III „Компресор“ в Русия, тъй като тази схема на работа се е доказала добре при нас.
Нашето S3 е напълно съвместимо с методите за резервно копиране в Amazon S3. Тоест, всички средства за резервно копиране, които поддържат тези методи, позволяват копиране на всичко в подобно хранилище "извън кутията".
В Veritas NetBackup е разработена функцията CloudCatalyst:
Тоест между машините, които трябва да бъдат резервирани, и гейта е междинен Linux сървър, през който преминава резервният трафик от агентите СРК и се извършва тяхната дедупликация "в движение" преди предаването им в S3. Ако преди там имаше 30 резервни копия по 20 Гб с компресия, то сега (заради подобието на машините) количеството им е намаляло с 90%. Движокът за дедупликация е същият, който се използва при съхранение на обикновени дискове чрез средства на NetBackup.
Ето какво се случва преди междинния сървър:
Тествахме и достигнахме до извода, че при внедряване в нашите ЦОД показва икономия на място в хранилищата S3 за нас и за клиентите. Като собственик на търговски ЦОД, разбира се, таксуваме по заето пространство, но все пак е много изгодно и за нас — защото започваме да печелим от по-мащабируеми места в софтуера, а не от наем на техника. Освен това, това намалява вътрешните разходи.
Логове228 Jobs (0 Waiting 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 228 Done — 13 selected)
(Приложен филтър [13])
Идентификатор Вид Состояние Подробности Состояния Статус Полис Задание Клиент Медия Сървър Време на Започване Време на Изтичане Време на Край Единица за Съхранение Опит Операция Килобайти Файлове Път % Завършване (Оценка) Идентификатор на Задача Собственик Копие Идентификатор на Родителска Задача KB/Сек Активен Започнат Активен Изтекъл Профил на Робот Vault Идентификатор на Сесия Медия за Излъчване Движение на Данни Off-Host Тип Master Приоритет Степен на Дедупликация Транспортен Ускорител Оптимизационен Инстанс или База Данни Споделен Хост
— 1358 Снимка Завършена 0 VMware — NGNCloudADC NBCC 18 декември 2018 12:16:19 PM 00:02:18 18 декември 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 декември 2018 12:16:27 PM 00:02:10 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1360 Резервно Копие Завършено 0 VMware Пълно NGNCloudADC NBCC 18 декември 2018 12:16:48 PM 00:01:39 18 декември 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 декември 2018 12:16:48 PM 00:01:39 Моментално Възстановяване Диск Стандарт WIN-*********** 0 99.8% 99%
1352 Снимка Завършена 0 VMware — NGNCloudADC NBCC 18 декември 2018 12:14:04 PM 00:02:01 18 декември 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 декември 2018 12:14:14 PM 00:01:51 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1354 Резервно Копие Завършено 0 VMware Инкрементално NGNCloudADC NBCC 18 декември 2018 12:14:34 PM 00:01:21 18 декември 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 декември 2018 12:14:34 PM 00:01:21 Моментално Възстановяване Диск Стандарт WIN-*********** 0 99.9% 100%
1347 Снимка Завършена 0 VMware — NGNCloudADC NBCC 18 декември 2018 12:11:45 PM 00:02:08 18 декември 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 декември 2018 12:11:45 PM 00:02:08 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1349 Резервно Копие Завършено 0 VMware Пълно NGNCloudADC NBCC 18 декември 2018 12:12:02 PM 00:01:41 18 декември 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 декември 2018 12:12:02 PM 00:01:41 Моментално Възстановяване Диск Стандарт WIN-*********** 0 99.7% 99%
1341 Снимка Завършена 0 VMware — NGNCloudADC NBCC 18 декември 2018 12:05:28 PM 00:04:53 18 декември 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 декември 2018 12:05:28 PM 00:04:53 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1342 Резервно Копие Завършено 0 VMware Пълно_Пресканиране NGNCloudADC NBCC 18 декември 2018 12:05:47 PM 00:04:24 18 декември 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 декември 2018 12:05:47 PM 00:04:24 Моментално Възстановяване Диск Стандарт WIN-*********** 0 87.9% 0%
1339 Снимка Завършена 150 VMware — NGNCloudADC NBCC 18 декември 2018 11:05:46 AM 00:00:53 18 декември 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 декември 2018 11:05:46 AM 00:00:53 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1327 Снимка Завършена 0 VMware — *******.********.cloud NBCC 17 декември 2018 12:54:42 PM 05:51:38 17 декември 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 декември 2018 12:54:42 PM 05:51:38 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1328 Резервно Копие Завършено 0 VMware Пълно *******.********.cloud NBCC 17 декември 2018 12:55:10 PM 05:29:21 17 декември 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 декември 2018 12:55:10 PM 05:29:21 Моментално Възстановяване Диск Стандарт WIN-*********** 0 87.9% 0%
1136 Снимка Завършена 0 VMware — *******.********.cloud NBCC 14 декември 2018 4:48:22 PM 04:05:16 14 декември 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 декември 2018 4:48:22 PM 04:05:16 Моментално Възстановяване Диск Стандарт WIN-*********** 0
1140 Резервно Копие Завършено 0 VMware Пълно_Сканиране *******.********.cloud NBCC 14 декември 2018 4:49:14 PM 03:49:58 14 декември 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 декември 2018 4:49:14 PM 03:49:58 Моментално Възстановяване Диск Стандарт WIN-*********** 0 45.2% 0%
Акселераторът позволява да се намали трафикът от агентите, тъй като се предават само измененията на данните, т.е. дори пълните бекъпи не се прехвърлят изцяло, тъй като медиа-серверът събира последващи пълни резервни копия от инкременталните бекъпи.
Промеждутъчният сървър разполага със свое хранилище, където записва «кеша» на данните и съхранява базата за дедупликация.
В пълната архитектура изглежда така:
- Майстор-сървърът управлява конфигурацията, актуализациите и всичко останало и се намира в облака.
- Медиа-сървърът (промеждутъчна *nix-машина) трябва да бъде възможно най-близо до резервираните системи по отношение на мрежовата достъпност. Тук се прави дедупликация на бекъпите от всички резервирани машини.
- На резервираните машини има агенти, които в общия случай изпращат на медиа-сървъра само това, което липсва в неговото хранилище.
Всичко започва с пълно сканиране — това е пълен бекъп. В този момент медиа-сървърът взема всичко, прави дедупликация и предава в S3. Скоростта до медиа-сървъра е ниска, от него — по-висока. Основното ограничение е изчислителната мощ на сървъра.
Следващите бекъпи се извършват от гледна точка на всички системи пълни, но всъщност това е нещо като синтетични пълни бекъпи. Т.е. фактическото предаване и запис на медиа-сървъра се извършва само за онези блокове данни, които не са се срещали в резервните копия на ВМ преди. А предаването и записът в S3 се извършват само за онези блокове данни, чийто хеш не е в базата за дедупликация на медиа-сървъра. По-просто казано — това, което не се е срещало в нито едно бекъп на нито една ВМ преди.
При възстановяване медиа-сървърът заявява необходимите дедуплицирани обекти от S3, регидрира ги и предава на агентите на СРК, т.е. трябва да се отчете обемът на трафика при възстановяване, който ще бъде равен на действителния обем на възстановяваните данни.
Ето как изглежда:
И ето още един фрагмент от логовете169 Задачи (0 В опашка 0 Активни 0 Чакащи за повторно опитване 0 Спирани 0 Непълни 169 Завършени — 1 избрани)
Идентификатор Вид Состояние Подробности Состояния Статус Полис Задание Клиент Медия Сървър Време на Започване Време на Изтичане Време на Край Единица за Съхранение Опит Операция Килобайти Файлове Път % Завършване (Оценка) Идентификатор на Задача Собственик Копие Идентификатор на Родителска Задача KB/Сек Активен Започнат Активен Изтекъл Профил на Робот Vault Идентификатор на Сесия Медия за Излъчване Движение на Данни Off-Host Тип Master Приоритет Степен на Дедупликация Транспортен Ускорител Оптимизационен Инстанс или База Данни Споделен Хост
— 1372 Възстановяване завършено 0 nbpr01 NBCC 19 декември 2018 1:05:58 PM 00:04:32 19 декември 2018 1:10:30 PM 1 14,380,577 1 100% 8548 root 1372 70,567 19 декември 2018 1:06:00 PM 00:04:30 WIN-*********** 90000
Цялостността на данните се осигурява от защитата на самото S3 — там има добра излишност за защита от хардуерни повреди, като например повреден шпиндел на твърдия диск.
Медиа-сървъра нужен е 4 Тб кеш — това е препоръката на Веритас за минимален обем. По-добре повече, но ние правихме точно така.
Резюме
Когато партньорът качи 20 Гб в нашето S3, ние съхранявахме 60 Гб, тъй като осигуряваме трикратна георезервираност на данните. Сега трафикът е значително по-малък, което е добре както за канала, така и за начисляването на разходите за съхранение.
В този случай маршрутите са затворени извън „голямото интернет пространство“, но можете да пренасочите трафика и през VPN L2 през интернет, но е по-добре медийният сървър да се постави преди входа на доставчика.
Ако искате да научите повече за тези функции в нашите руски ЦОД или имате въпроси относно реализирането при вас, моля, питайте в коментарите или на имейл ekorotkikh@croc.ru.
Източник: habr.com
