Резервне копіювання віртуальної інфраструктури – це лише один із заходів, які слід виконувати для її повноцінного захисту. Очевидно, що від одиничного збою віртуальної машини або фізичного сервера вас захистять процедури відновлення з резервної копії, а ось при масовому збої або аварії (затопило поверх, зламалося блейд-шасі тощо) потрібен план відновлення, що забезпечує вимоги до контрольної точки відновлення (RPO), так і вимоги до часу відновлення (RTO), від якого залежить здатність компанії продовжувати бізнес.
Ключовими функціями у цьому процесі є оркестрація (Orchestration), яка передбачає виконання операцій відновлення за суворо визначеним планом, і навіть автоматизація (Automation), що передбачає виконання плану аварійного відновлення у повністю автоматичному режимі після натискання кнопки оператором. Важливо, що ініціювання Disaster Recovery плану відбувається вручну оператором, оскільки це дуже затратна і складна процедура, що вносить серйозні зміни в інфраструктуру, але виконання кроків після цього йде повністю автоматично.
Реальність така, що якщо у великій інфраструктурі ви втратите свої дані, то лише 6% можуть успішно відновити їх, а в інших випадках компанії доведеться закритися в проміжку 2 років:
Зараз великі компанії використовують географічно рознесені датацентри, щоб забезпечити захист даних на рівні будівель та міст, а також застосовують гібридні хмарні середовища (комбінація власного ЦОД та хмари сервіс-провайдера) з метою підвищення доступності сервісів для кінцевих користувачів, а також захисту від аварій та катастроф . Ще одна перевага використання таких датацентрів – це follow-the-sun та follow-the-moon стратегії, які дозволяють покращити якість сервісу та знизити витрати.
Вартість простою при аварії в середньому по світу коштує наступні суми:
- Малий бізнес – $8 580 за годину
- Средній – $215 637 за годину
- Великий – $686 250 (кілька годин обходяться дорожче за куплені ліцензії на продукт і залізо для забезпечення катастрофостійкості)
А якщо врахувати, що середня тривалість простою при аварії становить 18 годин, то можна сказати, що технічно вона може вбити майже будь-який бізнес, який залежить від роботи ІТ-систем і доступності даних. Тому на якомусь етапі впроваджувати DR-рішення потрібно, питання лише у витратах, які компанія готова понести.
Рішення NAKIVO Backup and Replication дозволяє комбінувати техніки резервного копіювання та реплікації спільно з Disaster Recovery функціями, що не потребує витрат на додаткове ПЗ (але в залізо для резервного майданчика та канали комунікації доведеться все одно вкластися). Тут треба ще відзначити, що рішення NAKIVO призначені для компаній будь-якого масштабу, а отже вам не доведеться витрачатися на нові продукти зі зростанням інфраструктури.
Отже, як загалом працює схема аварійного відновлення NAKIVO B&R:
- Зупинка віртуальних машин VMware або Hyper-V, а також інстансів у хмарі EC2
- Виконання операцій з відновлення (Failover) або зворотного відновлення (Failback) для ВМ
- Запуск завдань відновлення даних, створених у NAKIVO Backup & Replication
- Виконання кастомних специфічних сценаріїв для ІТ-систем
- Розмонтування та монтування сховищ даних
- Надсилання адміністратору листів про завершення завдань
Ключова особливість NAKIVO тут у тому, що робота із завданнями Site Recovery побудована дуже просто, всі операції виконуються в кілька кліків у графічному інтерфейсі. Ось кілька прикладів простого та універсального підходу, реалізованого у продукті:
- Ви можете налаштувати рішення так, щоб завдання Site Recovery перевіряло доступність ваших ВМ щогодини і сповіщало про можливі проблеми.
- Ви можете налаштувати завдання Site Recovery таким чином, щоб вона реагувала на невеликі аварії, наприклад, шляхом міграції ключових навантажень у DR-локацію, після чого надсилала лист про успішне її завершення.
- Можна створити багаторівневе завдання Site Recovery для обробки складних ситуацій, коли потрібно враховувати можливі наслідки аварії. Наприклад, можна зупинити деякі поточні завдання (наприклад, реплікацію), виконати кастомні скрипти, дати можливість щось доналаштувати адміністратору (наприклад, приєднати репозиторії) та запустити процес далі.
При створенні DR-плану слід враховувати такі аспекти його реалізації:
- Визначте масштаб процедури – які ВМ та сервіси стоять у найвищому пріоритеті та мають бути відновлені першими.
- Визначте вашу RPO (вимоги до контрольної точки відновлення) – на це впливає, скільки даних у часі вам потрібно реплікувати на резервний майданчик.
- Визначте RTO (вимоги до часу відновлення) – функції Site Recovery у NAKIVO Backup & Replication дозволяють задати RTO та дізнатися, чи дозволяє поточна інфраструктура резервування забезпечити його.
- Визначте ресурси резервної інфраструктури – вам знадобляться ресурси RAM і CPU для розміщення віртуальних машин, потрібно зрозуміти, де будуть репліки ВМ, а також чітко уявляти, як працюватиме мережа після відновлення ВМ.
- Розробте регламент тестування процедури відновлення – дуже важливо не лише створити DR-план, а й регулярно перевіряти його у тестовому середовищі. Особливо це важливо, коли кроки по відновленню включають складні процедури і кастомні операції.
Пам’ятайте, що перший крок створення інфраструктури аварійного відновлення – це налаштування реплікації на резервний майданчик. Тільки після того, як репліки буде створено, ви можете починати створювати DR-план.
Давайте подивимося, як виглядає процес створення завдання реплікації з метою Site Recovery у NAKIVO Backup & Replication:
Майстер завдання реплікації проведе вас по всіх кроках налаштування процесу – це не складно. Головне – це правильно налаштувати сховища даних для реплік, пам’ятайте, що вони у разі аварії візьмуть на себе продуктивні ВМ із великим навантаженням на системи зберігання.
Друга важлива частина – відображення IP-адрес (Network Mapping), щоб на резервному майданчику віртуальні машини “вписалися” в інфраструктуру з іншою схемою адресації. У процесі виконання плану аварійного відновлення перепризначення IP-адрес відбувається автоматично, відповідно до налаштованих правил.
Під час створення плану Site Recovery можна створити кілька завдань. Як говорилося вище, можна зробити завдання для невеликого сегмента найбільш критичних систем, а можна відновити всю інфраструктуру цілком. Також, наприклад, можна зробити окреме завдання моніторингу доступності вашої віртуальної інфраструктури, яка тестує її кожні 5 хвилин та надсилає лист адміністратору у разі аварії.
Також, на відміну від інших рішень, NAKIVO Backup & Replication має розширений функціонал під час налаштування кроків аварійного відновлення. Наприклад, ви можете в рамках одного з кроків погасити некритичні віртуальні машини на резервному майданчику, щоб важливі віртуальні машини, які переїдуть туди, отримали більше обчислювальних ресурсів.
Для того, щоб усі кроки працювали узгоджено, у NAKIVO є механізм Action Options. При виконанні кожного кроку ви можете встановити поведінку системи в рамках DR-плану:
- Run this action in – ця опція визначає, чи потрібно виконувати цю дію лише у виробничому режимі відновлення, або лише під час тестування, або в обох випадках.
- Waiting behavior – ви можете вирішити, чи потрібно очікувати якийсь час перед запуском наступного кроку, щоб поточне завдання завершилося.
- Error handling – ця опція регулює обробку помилок, які можуть виникнути у процесі плану аварійного відновлення.
Також можна задати не лише план аварійного відновлення (Failover), а й план відновлення інфраструктури назад (Failback) для випадку, коли роботу основного майданчика буде відновлено.
Ну і ви можете задати тип плану – тестовий чи виробничий, а також визначити розклад для регулярного виконання тестового плану:
Після виконання тестового плану адміністратор отримає на пошту звіт про виконані та невиконані кроки, що дозволить зрозуміти найбільш вузькі місця плану, а також доналаштувати його, щоб він працював як годинник.
Якщо ви виконуєте тестовий план, то після закінчення процедури Failover буде проведено процедуру зворотного відновлення (Failback), щоб привести інфраструктуру у вихідний стан. Ну і зручно те, що відновлення продуктивних систем буде проводитися в ізольований сегмент мережі, щоб не торкнутися виробничих процесів компанії.
Є 2 типи повноцінного аварійного відновлення:
- Planned Failover – цей метод використовується для штатного відновлення систем, коли ви знаєте, що з основним майданчиком щось трапиться. Наприклад, вам сказали, що електрика в датацентрі відключиться через 30 хвилин.
- Emergency Failover – ця операція виконується у ситуації непередбачуваної аварії. У цьому випадку всі процедури будуть проводитися якнайшвидше, без фінальної синхронізації даних при перемиканні на резервний майданчик, щоб забезпечити необхідний показник RTO.
При відновленні в рамках виробничого робочого процесу автоматичного Failback не відбудеться – для цього вам потрібно буде створити окреме завдання. Для Failback вам потрібно попередньо створити завдання зворотної реплікації, щоб потім перейти назад на колишній основний майданчик. До речі, відновлення даних можна провести і в іншу локацію. Наприклад, ваш основний майданчик втрачений назавжди або виводиться з експлуатації, а ваші продуктивні навантаження переїжджають у хмару.
Бажаєте використовувати інноваційні та ефективні технології? У будь-який час звертайтесь у формі зворотнього зв’язку на сайті wiseit.com.ua або електронною адресою info@wiseit.com.ua.