🥇Как да компресираме до 90% съхранението на резервни копия в обектно хранилище

Нашите турски клиенти ни помолиха да настроим правилно резервното копие за дата центъра. Правим подобни проекти в Русия, но тук историята беше повече за изследване на най-добрия начин за изпълнение.

Дадено: има локално S3 хранилище, има Veritas NetBackup, който придоби нови разширени функции за преместване на данни в обектни хранилища, вече с поддръжка на дедупликация, и има проблем с свободното пространство в това локално хранилище.

Задача: да се осигури процесът на съхранение на резервни копия да бъде бърз и икономичен.

Всъщност, преди това в S3 всичко се съхраняваше просто като файлове, а именно това бяха пълни копия на критични машини от дата центъра. Тоест, не беше така да е оптимизирано, но пък всичко работеше от самото начало. Сега е време да се справим и да направим нещата както трябва.

На картинката е това, до което достигнахме:

Както се вижда, първото резервно копие беше направено бавно (70 Мб/с), а последващите резервни копия на същите системи — значително по-бързо.

Всъщност, следват малко повече детайли за особеностите.

Логове на резервните копия за тези, които са готови да четат половин страница от дампаFull with rescan
18 декември 2018 12:09:43 PM — Инфо bpbkar (pid=4452) ускорителят изпрати 14883996160 байта от 14883994624 байта към сървъра, оптимизация 0.0%
18 декември 2018 12:10:07 PM — Инфо NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Доклад=PDDO Статистики (използван многонишков поток) за (NBCC): сканирано: 14570817 KB, CR изпратено: 1760761 KB, CR изпратено през FC: 0 KB, дедуп: 87.9%, кеш неактивен

Full
18 декември 2018 12:13:18 PM — Инфо bpbkar (pid=2864) ускорителят изпрати 181675008 байта от 14884060160 байта към сървъра, оптимизация 98.8%
18 декември 2018 12:13:40 PM — Инфо NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Доклад=PDDO Статистики за (NBCC): сканирано: 14569706 KB, CR изпратено: 45145 KB, CR изпратено през FC: 0 KB, дедуп: 99.7%, кеш неактивен

Инкрементално
18 декември 2018 12:15:32 PM — Инфо bpbkar (pid=792) ускорителят изпрати 9970688 байта от 14726108160 байта към сървъра, оптимизация 99.9%
18 декември 2018 12:15:53 PM — Инфо NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Доклад=PDDO Статистики за (NBCC): сканирано: 14383788 KB, CR изпратено: 15700 KB, CR изпратено през FC: 0 KB, дедуп: 99.9%, кеш неактивен

Full
18 декември 2018 12:18:02 PM — Инфо bpbkar (pid=3496) ускорителят изпрати 171746816 байта от 14884093952 байта към сървъра, оптимизация 98.8%
18 декември 2018 12:18:24 PM — Инфо NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Доклад=PDDO Статистики за (NBCC): сканирано: 14569739 KB, CR изпратено: 34120 KB, CR изпратено през FC: 0 KB, дедуп: 99.8%, кеш неактивен

В какво е проблемът

Клиентите искат да правят резервни копия колкото се може по-често и да ги съхраняват колкото се може по-евтино. Най-евтиното място за съхранение са обектни хранилища като S3, тъй като те предлагат най-ниска цена за обслужване на мегабайт, откъдето резервната копия може да бъде възстановена в разумни срокове. Когато резервните копия са много, това става относително скъпо, тъй като голяма част от хранилището заемат копия на едни и същи данни. В случай на HaaS, турските колеги могат да уплътнят съхранението приблизително с 80-90%. Разбира се, че това се отнася за тяхната специфичност, но поне на 50% дедупликация бих определено очаквал.

За решаване на проблема, основните търговци отдавна направиха гейтвеите за S3 на Amazon. Всичките им методи са съвместими с локалните S3, ако поддържат API на Amazon. В турския ЦОД резервната копия се прави в нашето S3, както и в T-III „Компресор“ в Русия, тъй като такава схема на работа показва добри резултати при нас.

Нашето S3 е напълно съвместимо с методите за резервни копия в Amazon S3. Тоест, всички средства за резервно копиране, които поддържат тези методи, позволяват копирането на всичко в подобно хранилище „извън кутията“.

В Veritas NetBackup направиха функцията CloudCatalyst:

Тоест между машините, които трябва да бъдат резервирани, и гейтвея има междинен Linux-сървър, през който преминава трафикът за резервни копия от агенти на SRK и се извършва тяхната дедупликация „в движение“ преди да бъдат предадени в S3. Ако по-рано имаше 30 резервни копия по 20 Гб с компресия, то сега (заради сходството на машините) обемът им е намален с 90%. Движок за дедупликация е същият, който се използва при съхранение на обикновени дискове с Netbackup.

Ето какво се случва преди междинния сървър:

Тествахме и стигнахме до извода, че при внедряване в нашите ЦОД даваме икономия на пространство в хранилищата S3 както за нас, така и за клиентите. Като собственик на търговски ЦОД, разбира се, таксуваме въз основа на заетия обем, но все пак това е много изгодно и за нас, защото започваме да печелим от по-мащабируеми места в софтуера, а не от наемане на хардуер. И освен това, това намалява вътрешните разходи.

Логове228 Jobs (0 Queued 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 228 Done — 13 selected)
(Филтър приложен [13])

Идентификатор на работа Тип Състояние Подробности за състоянието Статус Политика на работа График на работа Клиент Медиен сървър Начален час Изминало време Краен час Единица за съхранение Опит Операция Килобайти Файлове Име на пътя % Завършено (оценка) Идентификатор на работа Собственик Копие ID на родителската работа KB/Сек Активен Начало Активно Изминало време Роба Профил на Vault Идентификатор на сесия Медия за изтегляне Прехвърляне на данни Външен тип Майстор Приоритет Степен на дублиране Ускорител на транспорт Оптимизация Инстанция или база данни Споделен хост
— 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 избрано)

Цялостността на данните се осигурява от защитата на самото S3 — там има добра излишност за защита срещу повреда на хардуера като погибнал шпиндел на твърдия диск.

Медиа-сървър необходими са 4 Тб кеш — това е препоръка на Веритас за минимален обем. По-добре е да е повече, но ние направихме точно така.

Резюме

Когато партньорът ни качи 20 ГБ в нашето S3, ние съхранихме 60 ГБ, тъй като осигуряваме тройно георезервиране на данните. В момента трафикът е значително по-малък, което е добре както за канала, така и за таксуването по съхранение.

В този случай маршрутите са затворени за "голямото Интернет", но можем да пренасочим трафика и през VPN L2 през Интернет, но е по-добре медиа-серверът да се настрои преди входа на доставчика.

Ако искате да научите повече за тези функции в нашите руски ЦОД или имате въпроси относно прилагането им при вас — задавайте ги в коментарите или на имейл ekorotkikh@croc.ru.

Източник: habr.com

Как да се компресира до 90% съхранението на бекъпи в облачно хранилище

В какво е проблемът

Резюме