Міжрегіональне проектування резервного відновлення для аварійного відновлення
Міжрегіональне відновлення після відмови забезпечує безперервність бізнесу під час серйозних збоїв, автоматично переносячи робочі навантаження з основного регіону до додаткового. Цей підхід ідеально підходить для масштабних перебоїв, таких як урагани або регіональні збої в електропостачанні. Однак він пов'язаний з вищими витратами та значною складністю порівняно з іншими методами аварійного відновлення.
Ключові моменти, які слід врахувати:
- НадійністьЗабезпечує надійний захист від регіональних збоїв завдяки автоматичному перемиканню на резервний архів та реплікації даних.
- ВитратиДорого через дублювання інфраструктури та плату за передачу даних.
- СкладністьПотрібне розширене налаштування, включаючи маршрутизацію DNS та процеси повернення до роботи після відмови.
- Цільовий час відновлення (RTO)Залежить від налаштувань:
- Активний-активний: майже нульовий RTO.
- Теплий режим очікування: хвилини.
- Холодний режим очікування: години.
Інші варіанти включають активно-активне резервування (висока надійність, найвища вартість) та активно-пасивне резервування (доступніший, повільніше відновлення). Вибір правильної стратегії залежить від стійкості вашого бізнесу до простоїв та бюджету.
| Варіант резервування | Надійність | Вартість | RTO |
|---|---|---|---|
| Міжрегіональне резервне перемикання | Високий (регіональні перебої) | Високий | Хвилини-години |
| Активний-Активний | Найвищий (глобальний розподіл трафіку) | Дуже висока | секунд |
| Активно-Пасивний | Помірний (режим очікування) | Помірний | Хвилини-години |
Вибір правильного методу передбачає балансування надійності, вартості та швидкості відновлення залежно від критичності вашої системи. Регулярне тестування та автоматизація є важливими для успіху.
Порівняння варіантів резервування для аварійного відновлення: вартість, RTO та надійність
Як налаштувати перехід на резервний застосунок між регіонами?
Правильна конфігурація часто вимагає вибору правильного центр обробки даних місцях, щоб мінімізувати затримку та забезпечити резервування.
sbb-itb-59e1987
1. Міжрегіональне резервне перемикання
Міжрегіональне відновлення після відмови – це підхід до аварійного відновлення, розроблений для перенесення виробничих навантажень з основного регіону до додаткового, розташованого далеко. У той час як стратегії Multi-AZ обробляють локальні збої в центрах обробки даних у радіусі приблизно 60 миль, міжрегіональне відновлення після збоїв використовується для вирішення набагато більших катастроф – наприклад, землетрусів, повеней або регіональних відключень електроенергії. Ця схема спирається на інфраструктуру, розташовану за сотні або навіть тисячі миль одна від одної. Нижче ми розглянемо її надійність, економічні аспекти, експлуатаційні проблеми та те, як вона впливає на цільовий час відновлення (RTO).
Надійність
Міжрегіональне резервне перемикання забезпечує географічна ізоляція, що робить його надійним рішенням для регіональних перебоїв у електропостачанні. Наприклад, якщо ураган спричиняє відключення електроенергії в усьому регіоні, вторинний регіон безперешкодно бере на себе управління. Автоматизовані системи моніторингу виявляють проблеми з продуктивністю та запускають перемикання на резервний аварійний режим, а безперервна реплікація на рівні блоків гарантує збереження даних, захищаючи як інфраструктуру, так і критично важливу інформацію.
У рамках програми AWS Well-Architected Framework підкреслюється, що пропуск належних практик відновлення після відмови створює "Високий" рівень ризику для стійкості до робочого навантаження. Регулярні тренування з відновлення є ключовими для забезпечення того, щоб ваш план аварійного відновлення справді працював, коли це необхідно. Ці тренування перетворюють плани з теоретичних на перевірені, що має вирішальне значення для підтримки роботи послуг та уникнення втрати доходів.
Міркування щодо вартості
Міжрегіональне резервування коштує дорожче порівняно з рішеннями для кількох зон доступу. Причина? Ви, по суті, подвоїти ваші витрати на зберігання та експлуатацію шляхом підтримки дзеркальних баз даних і програм у віддалених регіонах. Крім того, плата за передачу даних для міжрегіональної реплікації може швидко накопичуватися, причому витрати суттєво відрізняються залежно від регіону.
Для великих організацій з понад 2000 співробітниками витрати на аварійне відновлення з використанням власних рішень можуть коливатися від від 675 000 до 1 750 000 річних $. Якщо ви прагнете майже нульового показника RTO, очікуйте, що ці витрати зростуть ще більше. Реплікація в режимі реального часу для задоволення мінімальних вимог RPO ще більше збільшує витрати. Щоб керувати цими витратами, багато компаній вирішують реплікувати лише найважливіші програми, а не все середовище.
Операційна складність
Налаштування міжрегіонального резервного перемикання не таке просте, як перемикання перемикача – воно вимагає розширена оркестрація. Вам потрібно буде керувати глобальною маршрутизацією DNS, асинхронною реплікацією даних та автоматизованими процесами відновлення після збою у віддалених регіонах. Використання інфраструктури як коду (IaC) є критично важливим для підтримки узгодженості та повторюваності між вашими основними та вторинними налаштуваннями.
Процес повернення до основного регіону після відновлення – ще складніший. Він включає повторну синхронізацію даних для запобігання втратам, перенаправлення трафіку через DNS та керування зворотною реплікацією для захисту нових активних екземплярів. Такий рівень складності вимагає кваліфікованих команд та детальної документації для безперебійного виконання.
Цільовий час відновлення (RTO)
Ваш RTO значною мірою залежить від обраної вами моделі резервного копіювання. Активно-активні конфігурації дозволяють обом регіонам одночасно обробляти трафік, досягаючи майже нульового показника RTO. Теплий режим очікування налаштування, де мінімальні сервіси працюють у вторинному регіоні, можуть забезпечити RTO, що вимірюється лічені хвилини. З іншого боку, холодний режим очікування Підходи, де ресурси розкручуються лише після збою, призводять до RTO, що вимірюються в годинах.
Для систем, що потребують доступності 99.999%, RTO зазвичай вимірюються в секунди, тоді як менш критичні системи з доступністю 99.9% можуть переносити простої, що вимірюються годинами. Автоматизовані книги запуску та інструменти IaC знижують ризик людської помилки під час відновлення після відмови, допомагаючи вам дотримуватися жорстких цільових показників RTO, особливо коли кожна хвилина простою призводить до втрати доходу та довіри клієнтів.
2. Активно-активне резервування
Активно-активне резервування гарантує одночасну роботу програм у двох або більше регіонах, а активний трафік розподіляється між усіма ними. На відміну від активно-пасивних конфігурацій, де вторинний регіон залишається неактивним або мінімально активним, активно-активні конфігурації передбачають обробку запитів реальних користувачів кожним регіоном. Це усуває проблеми холодного запуску, оскільки всі регіони завжди працюють. Давайте розглянемо, як ця конфігурація підвищує надійність навіть під час серйозних регіональних збоїв.
Надійність
Активно-активні конфігурації забезпечують найвищий рівень надійності серед стратегій відновлення після катастроф. Такі сервіси, як Контролер відновлення програм Amazon Route 53 постійно контролювати стан кількох регіонів та автоматично перенаправляти трафік від несправної інфраструктури. Ця конфігурація ідеально підходить для критично важливих робочих навантажень (рівень 0), які вимагають цілей рівня обслуговування, що перевищують 99.99%. Для підприємств, де навіть кілька секунд простою можуть призвести до втрати доходу або підриву довіри клієнтів, такий рівень надійності є незамінним.
"Автоматизація перемагає героїзм: автоматизований процес відновлення після збою набагато кращий, ніж покладатися на когось, хто вручну виправлятиме проблеми під час збою". – Алекс Брукс, архітектор рішень AWS
Ефективність витрат
Активно-активне резервування – це найдорожчий варіант аварійного відновлення. Це пояснюється тим, що ви платите за повну обчислювальну та сховищну потужність у кількох регіонах цілодобово. Витрати ще більше збільшуються через безперервну реплікацію даних між регіонами та погодинну оплату за такі ресурси, як томи та знімки Amazon EBS. Однак для підприємств, де час простою безпосередньо впливає на дохід, ці витрати часто вважаються виправданими. Для менш критичних систем активно-пасивні налаштування теплого резервування можуть запропонувати більш економічну альтернативу.
Складність впровадження
Налаштування резервування типу «актив-актив» є складнішим, ніж стандартні моделі резервування. Воно вимагає точної глобальної синхронізації, включаючи синхронізоване кешування (наприклад, ЕластіКеш), розширена маршрутизація трафіку та підтримка узгоджених даних у різних регіонах.
Узгодженість даних створює значну проблему. Синхронна реплікація забезпечує точність, але збільшує затримку запису та зазвичай обмежується одним регіоном. Асинхронна реплікація підтримує відновлення між регіонами, але вносить затримку, яка може призвести до застарілих даних. Щоб впоратися з цими складнощами, інфраструктура як код (IaC) може реплікувати мережеві топології та конфігурації безпеки в різних регіонах. Інструменти автоматизації та runbooks обробляють просування бази даних та маршрутизацію трафіку під час збоїв, тоді як Amazon CloudWatch агрегує показники, щоб вирішити, коли має відбуватися відновлення після відмови.
Цільовий час відновлення (RTO)
Активно-активне резервування забезпечує RTO вимірюється в секундах, часто досягаючи майже нульового часу простою. Оскільки всі регіони вже обслуговують активний трафік, перехід на резервний режим передбачає просте коригування ваг трафіку, а не очікування, поки ресурси розкрутяться, або бази даних перейдуть на новий рівень. Такі інструменти, як Глобальний акселератор AWS використовувати статичні IP-адреси, які залишаються незмінними, навіть коли кінцеві точки сервера виходять з ладу, що дозволяє швидше перемикати трафік порівняно з методами резервного перемикання на основі DNS.
| Вимір | Активно-активне резервування | Активно-пасивний (теплий режим очікування) |
|---|---|---|
| Надійність | Найвищий; трафік активний у всіх регіонах | Високий; вимагає успішного перемикання на резервний комп'ютер |
| Ефективність витрат | Найдорожчий; повний спектр ресурсів у всіх регіонах | Більш економічно ефективний; зменшений масштаб вторинного регіону |
| Складність | Високий; потрібна глобальна синхронізація даних | Помірний; потрібні автоматизовані сценарії відновлення |
| RTO | Майже нульовий; рух транспорту змінюється миттєво | Від хвилин до годин; залежить від масштабування/просування |
У цій таблиці висвітлено ключові відмінності між конфігураціями «активно-активна» та «активно-пасивна», пропонуючи чіткіше уявлення про їхні переваги.
3. Активно-пасивне резервування
Активно-пасивне резервування – це схема аварійного відновлення, де ваш основний регіон обробляє весь активний трафік, тоді як вторинний регіон залишається в режимі очікування, готовий взяти на себе управління за потреби. Цей підхід пропонує більш бюджетну альтернативу конфігураціям типу «активний-активний», але має свої недоліки, зокрема, у швидкості перемикання на резервний рахунок. На відміну від конфігурацій типу «активний-активний», вторинний регіон не обробляє запити, доки не станеться збій. Існує два основних типи конфігурацій типу «активний-пасивний»: Пілотний ліхтар, який підтримує роботу лише найважливіших ресурсів, таких як бази даних, та Теплий режим очікування, який підтримує спрощену, але працездатну версію вашого робочого навантаження у вторинному регіоні.
Надійність
Активно-пасивні конфігурації залежать від безперервна реплікація даних для забезпечення надійності, при цьому основний регіон регулярно синхронізує дані з вторинним регіоном. Ці дані захищені шифруванням, а відновлення після збою запускається через зміни DNS, часто контролюється та автоматизується за допомогою таких інструментів, як CloudWatch.
Однак, існують труднощі. Найбільше занепокоєння викликає затримка реплікації, де оновлення даних можуть бути не повністю синхронізовані між регіонами. Деякі інструменти оркестрації не перевіряють автоматично наявність затримки перед ініціюванням відновлення після збою, а це означає, що може знадобитися ручне втручання, щоб уникнути втрати даних. Після відновлення після збою системі потрібна "зворотна реплікація" для захисту нового активного регіону, що не відбувається автоматично. Крім того, якщо пропускна здатність мережі недостатня, безперервна реплікація може завершитися невдало, що призведе до збою ваших даних, що залишить ваші дані незахищеними.
Ефективність витрат
Активно-пасивне резервування забезпечує баланс між вартістю та продуктивністю. Воно доступніше за активно-активні конфігурації, але дорожче за прості методи резервного копіювання та відновлення. Вартість залежить від типу конфігурації:
- Пілотний ліхтар підтримує низькі витрати, використовуючи лише необхідні ресурси, такі як бази даних, тоді як обчислювальні ресурси залишаються підготовчими, але неактивними.
- Теплий режим очікування є дорожчим, оскільки він підтримує роботу зменшеної версії вашого робочого навантаження у вторинному регіоні.
Інші поточні витрати включають плату за передачу даних між регіонами, плату за сховище Amazon EBS та погодинну вартість послуг аварійного відновлення. Для оптимізації витрат можна використовувати безсерверні технології, такі як AWS Lambda та Amazon API Gateway, у пасивному регіоні, уникаючи плати за простої обчислювальних ресурсів. Для мереж піринг VPC є простішим та доступнішим варіантом порівняно з Transit Gateway.
Складність впровадження
Налаштування активно-пасивного резервування вимагає помірні зусилля. Вам потрібно буде налаштувати перенаправлення DNS, автоматизовані механізми відновлення після збою та чіткий процес повернення операцій до основного регіону. Такі інструменти, як AWS CloudFormation або HashiCorp Terraform, можуть спростити розгортання, забезпечуючи узгоджене налаштування ресурсів у всіх регіонах. Регулярні тренування з відновлення після збою є важливими для перевірки того, що все працює належним чином, та для навчання вашої команди цьому процесу.
Процес повернення до резервного регіону додає ще один рівень складності. Щоб повернутися до основного регіону, вам потрібно буде скопіювати дані назад з регіону відновлення, що може зайняти багато часу. Це часто передбачає видалення застарілих основних баз даних та створення нових реплік. Підвищення безпеки шляхом сегментації критично важливих даних на окремі облікові записи AWS для проміжних та відновлювальних регіонів може збільшити операційні витрати, що ще більше ускладнює відновлення. Ці фактори зрештою впливають на час відновлення, який ми розглянемо далі.
Цільовий час відновлення (RTO)
RTO для активно-пасивних конфігурацій залежить від обраної вами стратегії:
- Резервне копіювання та відновленняЗазвичай відновлення триває до 24 годин.
- Пілотний ліхтарДосягає RTO за десятки хвилин, оскільки обчислювальні ресурси необхідно виділити та масштабувати під час відновлення.
- Теплий режим очікуванняЗабезпечує швидше відновлення, часто протягом кількох хвилин, оскільки екземпляри вже запущені та потребують лише масштабування.
AWS Elastic Disaster Recovery – це корисний інструмент, який поєднує економію коштів Pilot Light зі швидшим відновленням Warm Standby.
Автоматизація відіграє вирішальну роль у зменшенні RTO, виключаючи ручні кроки. Наприклад, налаштування DNS TTL та оновлення маршрутизації Route 53 визначають, як швидко користувачі перенаправляються до регіону відновлення. Крім того, використання API площини даних може підвищити надійність резервного копіювання під час регіональних збоїв, забезпечуючи плавніший перехід.
Переваги та недоліки
Кожен метод резервування має свій власний набір компромісів, балансуючи вартість, складність та швидкість відновлення. Ось детальніший огляд того, як ці методи порівнюються між собою:
Міжрегіональне резервне перемикання є надійним вибором для високопріоритетних робочих навантажень, які потребують безперебійної роботи бізнесу під час регіональних збоїв. Він підтримує автоматичне перемикання на резервний рахунок із визначеним цільовим часом відновлення (RTO). Однак ця зручність недешева. Передача даних та синхронізація можуть призвести до значних витрат, а процес повернення до резервного рахунку може бути складним, включаючи зворотну реплікацію та ручне очищення. Як зазначає Джон Форменто з Amazon Web Services:
"Якщо багаторегіональна архітектура побудована неправильно, загальна доступність робочого навантаження може знизитися"."
Активно-активне резервування забезпечує блискавично швидке відновлення з майже нульовим RTO та гарантує, що користувачі обслуговуються з найближчого географічного розташування. Така конфігурація ідеально підходить для глобальної аудиторії, якій потрібна найвища продуктивність. З іншого боку, підтримка повністю працездатних стеків додатків у кількох регіонах призводить до збільшення витрат. Синхронізація даних також може бути головним болем, а погано спроектована система може ненавмисно знизити загальну доступність.
Активно-пасивне резервування – це більш бюджетний варіант, що використовує тепле резервування або пілотні налаштування для економії коштів. Оскільки ви не платите за простої обчислювальних ресурсів, це економніше для вашого гаманця. Крім того, відмовостійкі перевірки не порушують роботу основного середовища. Компроміс? Вищий показник RTO порівняно з активними налаштуваннями. Відновлення залежить від того, як швидко масштабуються пасивні ресурси та перенаправляється DNS-трафік. Крім того, керування реплікацією даних є критично важливим для уникнення таких проблем, як затримка реплікації, яка може призвести до втрати даних під час відмовостійкості.
| Метод резервування | Ключові переваги | Основні недоліки |
|---|---|---|
| Міжрегіональне резервне перемикання | Автоматизоване відновлення; визначений час очікування (RTO); забезпечення безперервності бізнесу | Високі витрати на передачу даних; складний процес повернення до попереднього стану; ризик втрати даних через затримку реплікації |
| Активний-Активний | Майже нульовий час виходу на ринок; покращує глобальну продуктивність; найвища доступність | Дорого; складна синхронізація даних; потенційна знижена доступність у разі неправильного налаштування |
| Активно-Пасивний | Економічно ефективний; свердла не впливають на основні системи; швидший, ніж холодне резервне копіювання | Вищий RTO, ніж у режимі активного-активного; вимагає ретельного управління реплікацією для запобігання втраті даних |
У цьому розділі висвітлено ключові міркування, які слід враховувати під час вибору найкращої стратегії резервування для вашого плану аварійного відновлення. Кожен метод має свої сильні та слабкі сторони, що робить правильний вибір значною мірою залежним від ваших конкретних потреб і пріоритетів.
Висновок
Вибір правильного методу резервування залежить від розуміння потреб вашого бізнесу та критичності ваших систем. Для критично важливі системи (рівень 0), де навіть кілька секунд простою є неприйнятними, активно-активне резервування – це правильний шлях. Ці системи часто вимагають цільового рівня обслуговування (SLO) 99.999% або вище та цільового часу відновлення (RTO), який практично дорівнює нулю.
для помірно критичні системи (рівень 1), де короткочасні перерви є контрольованими, активно-пасивний теплий режим очікування Налаштування пропонує надійний компроміс між вартістю та швидким відновленням. Цей метод особливо ефективний для клієнтських програм, яким потрібна надійна продуктивність без перевитрат. Однак регулярне тестування має вирішальне значення для забезпечення роботи вашого плану аварійного відновлення, коли це найбільше потрібно.
Коли справа доходить до операційні системи (рівень 2), де прийнятні довші RTO, що тривають кілька годин, активно-пасивний холодний режим очікування забезпечує економічно ефективний варіант. Аналогічно, адміністративні навантаження (рівень 3) часто покладаються на методи резервного копіювання та відновлення, при цьому час відновлення становить від годин до днів. Ці багаторівневі стратегії формують основу надійного плану аварійного відновлення.
Щоб ці стратегії працювали безперебійно, узгодьте методи резервування з критичністю ваших робочих навантажень. Керовані служби можуть спростити цей процес, автоматизуючи завдання резервування та реплікації. Автоматизація механізмів відновлення після відмови – ще один ключовий крок до скорочення часу простою. Як рекомендує Microsoft Azure Well-Architected Framework:
"Більше резервування робочого навантаження означає збільшення витрат. Ретельно розгляньте можливість додавання резервування та регулярно переглядайте свою архітектуру, щоб переконатися, що ви керуєте витратами"."
Почніть з категоризації робочих навантажень за рівнями та встановлення чітких цільових показників RTO та RPO для кожного з них. Найефективніший підхід не обов'язково є найдорожчим – це той, який поєднує захист та сталий розвиток.
Для забезпечення операційної стійкості розгляньте можливість партнерства з Serionion. Завдяки їхньому багаторегіональному хостингу ви можете забезпечити безперебійну роботу навіть під час регіональних збоїв, зберігаючи роботу ваших критично важливих систем у будь-якому випадку.
поширені запитання
Які витрати слід враховувати під час налаштування міжрегіонального відновлення після збою для аварійного відновлення?
Налаштування міжрегіонального резервного перемикання пов'язане з різноманітними витратами, які потребують ретельного розгляду. Значні витрати пов'язані з обчислювальні ресурси у вторинному регіоні. Якщо ви оберете конфігурацію з теплим або гарячим резервуванням, ви зіткнетеся з вищими витратами через запуск додаткових екземплярів, вимоги до сховища та ліцензування. З іншого боку, конфігурація з холодним резервуванням, як правило, є більш економічною, оскільки вона в основному передбачає підтримку реплікованих даних без безперервної роботи екземплярів.
Ще одна значна витрата, яку слід врахувати, це сховище реплікації даних, що оплачується окремо в кожному регіоні. Вибір регіонів з нижчими тарифами на зберігання може допомогти контролювати ці витрати. Крім того, плата за міжрегіональну передачу даних застосовуються до поточної реплікації даних та будь-якого трафіку, що генерується під час подій відновлення після збою. Ці витрати можуть швидко зростати під час роботи з великими наборами даних.
Також слід врахувати витрати на управління та ліцензування для інструментів аварійного відновлення, систем моніторингу та будь-яких сторонніх служб, на які ви покладаєтеся. Для ефективного управління витратами багато організацій застосовують багаторівневий підхід. Наприклад, вони можуть тримати лише критично важливі служби в стані теплого резервування, використовувати економічно ефективні рішення для зберігання даних та ретельно планувати використання пропускної здатності на основі цілей відновлення.
Призначаючи конкретні значення цим елементам витрат, таким як плата за використання екземплярів (наприклад, $0.10/годину), плата за зберігання (наприклад, $0.023/ГБ на місяць) та вартість передачі даних (наприклад, $0.02/ГБ), компанії можуть розробити стратегію відновлення після збою, яка поєднує надійність та доступність.
Як міжрегіональне резервне перемикання на резервне копіювання покращує надійність даних під час регіональних збоїв?
Міжрегіональне резервне перемикання забезпечує доступність ваших даних завдяки збереженню синхронізоване резервне копіювання в додатковому регіоні. Якщо основний регіон вийде з ладу через збій, трафік буде безперешкодно перенаправлено до додаткового регіону. Це означає, що користувачі можуть продовжувати отримувати доступ до найновіших даних без перерв.
Цей метод відіграє ключову роль у планах відновлення після катастроф, допомагаючи підприємствам досягти висока доступність та скорочення часу простою під час регіональних перебоїв. Реплікуючи дані між віддаленими місцями, компанії можуть захистити свою діяльність та забезпечити користувачам стабільний досвід, незалежно від обставин.
Що слід враховувати, вибираючи між активно-активною та активно-пасивною системами резервування?
При виборі між активний-активний і активно-пасивний При налаштуванні резервування важливо зважити такі фактори, як вартість, вимоги до продуктивності та складність експлуатації.
Ан активно-пасивна схема загалом є більш бюджетним. Він використовує основний сервер із резервним, що спрощує його розгортання та обслуговування. З іншого боку, конфігурація «активний-активний» передбачає вищі витрати, оскільки подвоює інфраструктуру та вимагає більше зусиль для управління.
Потреби в продуктивності та толерантність до простоїв також є критично важливими факторами. Активно-активні налаштування блискучі в середовищах з високим трафіком, де стабільна продуктивність є обов'язковою. Розподіляючи трафік між усіма вузлами, вони усувають затримки при збоях. Однак для менших програм або систем з помірними вимогами, активно-пасивна схема часто достатньо і легше впоратися.
Зрештою, подумайте про можливості вашої команди та про те, який час простою є прийнятним. Активно-активні системи вимагають розширеного управління та синхронізації, що може потребувати більш кваліфікованих ресурсів. Тим часом, активно-пасивні налаштування простіші та добре підходять для команд з обмеженими ресурсами або тих, хто може керувати короткими періодами відновлення після збою. Обидва варіанти можна налаштувати, щоб досягти правильного балансу між вартістю, продуктивністю та доступністю відповідно до ваших конкретних потреб.
