Решение для аварийного восстановления виртуальной машины Azure [закрыто]
У меня есть некоторые сомнения в том, как реализовать и гарантировать аварийное восстановление виртуальной машины Azure.
У меня есть виртуальная машина, на которой запущено несколько служб IIS в одном регионе Azure1 (предположим, в Центральной части США). Я знаю, что для достижения высокой доступности мне нужно создать группу доступности. Проблема в том, что если регион 1 выйдет из строя, моя служба будет недоступна.
Итак, я хочу спросить, как мне лучше всего гарантировать восстановление виртуальной машины в регион 2 (юг центральной части США) в кратчайшие сроки и без какого-либо вмешательства человека (если возможно). Обратите внимание, что я говорю только в случае отказа Region1.
Я знаю, что на случай повреждения данных мне понадобятся другие механизмы.
С уважением,
Проще говоря: DR зависит от вас (или, точнее, от архитектуры вашего приложения). Нет возможности гарантировать восстановление в другой регион. Хотя вы можете направлять трафик в другой регион (будь то через диспетчер трафика, как предложил @Bruno, или ваше собственное решение на основе DNS), это ничего не говорит о ваших данных. Это касается только уровня веб / API / приложений с внешним доступом.
Почему я говорю, что это зависит от вас (архитектуры вашего приложения)? Подумайте только, на сколько вопросов нет встроенного ответа:
- Как вы будете реплицировать данные из основного региона, чтобы обеспечить их доступность в дополнительном регионе? Вы используете службу хранения данных, которая реплицируется в альтернативные регионы (например, хранилище таблиц / BLOB-объектов)? Используете ли вы решения баз данных на основе виртуальных машин, для которых требуется настройка репликации (а затем, как вы справляетесь с согласованностью)?
- Как будет работать ваше приложение, если для него нет данных? Он отключается? Он переходит в режим только для чтения? Работает ли он с устаревшими данными?
- Что произойдет, если дополнительные службы станут недоступны (например, электронная почта, кеш, идентификация, сторонние службы и т. Д.)?
- Как вы убедитесь, что не потеряете контент, записанный на первичный узел данных, когда ваши вторичные узлы теперь являются единственными доступными?
- Как вы будете справляться с восстановлением, когда первичный регион снова подключится к сети?
- Как вы будете справляться со сценариями, когда несколько регионов отключаются - у вас будет дополнительные локальные ресурсы?
- И т.д.
Вы упомянули наборы доступности, которые не имеют ничего общего с аварийным восстановлением (как вы уже догадались). Наборы доступности просто уменьшают вероятность перехода вашего кластера виртуальных машин в автономный режим, гарантируя, что виртуальные машины распределены по доменам сбоя и обновления.
Итог: аварийное восстановление не является чем-то встроенным и потребует тщательного планирования и понимания того, как ваша система будет (или не будет) работать в период сбоя.
Вы можете использовать диспетчер трафика. По сути, вы добавляете конечную точку для Region1 и другую конечную точку для Region2.Настройте его для аварийного переключения, и он сотворит чудеса, если ваш основной сайт выйдет из строя. Весь ваш входящий трафик управляется диспетчером трафика, а не направляется напрямую на виртуальные машины.
Что такое диспетчер трафика?
https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-overview/