Наші турецькі клієнти попросили нас правильно налаштувати бекап для дата-центру. Ми робимо подібні проекти в Росії, але саме тут історія була більшою про дослідження того, як краще зробити.
Дано: є локальне сховище 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 — 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 — 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
Інкрементний
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 — 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
Повний
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 — 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 Амазона. Усі їх методи сумісні з локальними 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_****backup 1 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