Диспетчер трафика Azure с Azure Site Recovery

Диспетчер трафика Azure позволяет управлять распределением трафика между конечными точками приложения. Конечная точка — это любая служба, размещенная в среде Azure или за ее пределами, с доступом в Интернет.

Диспетчер трафика использует службу доменных имен (DNS) для направления клиентских запросов к наиболее подходящей конечной точке в зависимости от метода маршрутизации трафика и работоспособности конечных точек. Диспетчер трафика предоставляет целый ряд методов маршрутизации трафика и параметров мониторинга конечных точек, подходящих для приложений с различными потребностями и моделями автоматической отработки отказа. Клиент напрямую подключается к выбранной конечной точке. Диспетчер трафика — это не прокси-сервер или шлюз, и он не видит трафик, проходящий между клиентом и службой.

В этой статье описывается, как можно объединить интеллектуальную маршрутизацию диспетчера трафика Azure с эффективными возможностями аварийного восстановления и миграции Azure Site Recovery.

Переключение с локальной среды на Azure

В первом случае мы рассмотрим компанию А со всей инфраструктурой приложений в локальной среде. Для обеспечения непрерывности бизнес-процессов и соблюдения требований компания A решает использовать Azure Site Recovery для защиты своих приложений.

Компания А запускает приложения с общедоступными конечными точками и хочет эффективно перенаправлять трафик в Azure в случае сбоя. Метод маршрутизации трафика по приоритету в Azure Traffic Manager позволяет компании A легко реализовать эту модель отказоустойчивости.

Конфигурация выглядит следующим образом:

• Компания А создает профиль диспетчера трафика.
• Используя метод маршрутизации по приоритету, компания А создает две конечные точки — первичную для внутреннего пользования и отказоустойчивую для Azure. Главной присваивается приоритет 1, а резервной — приоритет 2.
• Так как первичная конечная точка размещена за пределами Azure, она создается как внешняя.
• При использовании Azure Site Recovery на платформе Azure не работают виртуальные машины или приложения перед отработкой отказа. Таким образом, отказоустойчивая конечная точка также создается как внешняя.
• По умолчанию пользовательский трафик направляется в локальное приложение, потому что эта конечная точка имеет самый высокий приоритет. Трафик не направляется в Azure, если первичная конечная точка работоспособна.

В случае чрезвычайной ситуации компания А может инициировать отработку отказа в Azure и восстановить свои приложения в Azure. Когда диспетчер трафика Azure обнаруживает, что первичная конечная точка больше не работоспособна, он автоматически использует отказоустойчивую конечную точку в ответе DNS и пользователи подключаются к приложению, восстановленному в Azure.

В зависимости от бизнес-требований компания А может выбрать более высокий или более низкий интервал проверки, чтобы перейти из локальной среды в Azure в случае аварии и сократить время простоя для пользователей.

Когда авария сдерживается, компания А может восстановить среду из Azure в локальную среду (VMware или Hyper-V) с использованием Azure Site Recovery. Теперь, когда диспетчер трафика обнаруживает, что первичная конечная точка снова работоспособна, он автоматически использует эту конечную точку в своих ответах DNS.

Перенос из локальной среды в Azure

В дополнение к аварийному восстановлению Azure Site Recovery также позволяет выполнять перенос в Azure. Используя мощные возможности проверки отказоустойчивости в Azure Site Recovery, клиенты могут оценивать производительность приложений в Azure, не затрагивая свои локальные среды. И когда клиенты готовы выполнить миграцию, они могут выбрать перенос всех рабочих нагрузок или постепенный перенос и масштабирование.

Метод взвешенной маршрутизации диспетчера трафика Azure позволяет направлять часть входящего трафика в Azure, в то время как большинство трафика направляется в локальную среду. Этот подход может помочь оценить производительность масштабирования, так как вы можете продолжать увеличивать присвоенное Azure значение веса, когда вы переносите все свои рабочие нагрузки в Azure.

Например, компания Б решает выполнять миграцию поэтапно, переместив часть своей среды приложений, а другую оставив в локальной среде. На начальных этапах, когда большая часть среды расположена локально, больший вес присваивается локальной среде. Диспетчер трафика возвращает конечную точку с учетом веса, присвоенного доступным конечным точкам.

Во время переноса обе конечные точки активны и большая часть трафика направляется в локальную среду. По мере того, как выполняется перенос, больший вес может быть присвоен конечной точке в Azure, а локальная конечная точка может быть деактивирована после миграции.

Отказоустойчивость в Azure на Azure

В первом случае мы рассмотрим компанию В со всей инфраструктурой приложений в Azure. Для обеспечения непрерывности бизнес-процессов и соблюдения требований компания В решает использовать Azure Site Recovery для защиты своих приложений.

Компания В запускает приложения с общедоступными конечными точками и хочет эффективно перенаправлять трафик в другой регион Azure в случае сбоя. Метод маршрутизации трафика по приоритету позволяет компании C легко реализовать эту схему отработки отказа.

Конфигурация выглядит следующим образом:

• Компания В создает профиль диспетчера трафика.
• Используя метод маршрутизации по приоритету, компания В создает две конечные точки — первичную для исходного региона Azure (Восточная Азия) и отказоустойчивую для региона восстановления Azure (Юго-Восточная Азия). Первичной присваивается приоритет 1, а отказоустойчивой — приоритет 2.
• Так как первичная конечная точка размещается в Azure, она может использоваться как конечная точка Azure.
• При использовании Azure Site Recovery на сайте восстановления Azure не работают виртуальные машины или приложения до переключения на резервный узел. Таким образом, точку отказоустойчивости можно создать как внешнюю конечную точку.
• По умолчанию пользовательский трафик направляется в исходный регион (Восточная Азия), потому что эта конечная точка имеет самый высокий приоритет. Трафик не направляется в регион восстановления, если первичная конечная точка работоспособна.

В случае сбоя компания C может выполнить переключение и восстановить свои приложения в восстановительном регионе Azure. Когда диспетчер трафика Azure обнаруживает, что первичная конечная точка больше не работоспособна, он автоматически использует отказоустойчивую конечную точку в ответе DNS и пользователи подключаются к приложению, восстановленному в регионе восстановления Azure (Юго-Восточная Азия).

В зависимости от бизнес-требований Компания В может выбрать более высокий или более низкий интервал проверки, чтобы перейти из исходного региона в регион восстановления и сократить время простоя для пользователей.

Когда ситуация с катастрофой взята под контроль, компания С может возвращаться из восстановительного региона Azure в исходный регион Azure, используя Azure Site Recovery. Теперь, когда диспетчер трафика обнаруживает, что первичная конечная точка снова работоспособна, он автоматически использует эту конечную точку в своих ответах DNS.

Защита корпоративных приложений в нескольких регионах

Глобальные компании часто улучшают качество обслуживания клиентов, адаптируя свои приложения в соответствии с региональными потребностями. Локализация и сокращение задержки помогают рационально разделить инфраструктуру приложений между регионами. Предприятия также связаны региональными законами о данных в определенных областях и предпочитают изолировать часть инфраструктуры приложений в пределах региональных границ.

Рассмотрим пример, когда компания Г разделила конечные точки приложения, чтобы отдельно обслуживать Германию и весь остальной мир. Для этой цели компания Г использует метод географической маршрутизации диспетчера трафика Azure. Любой трафик, исходящий из Германии, направляется в конечную точку 1, а весь внешний трафик по отношению к Германии направляется в конечную точку 2.

Сложность такой конфигурации заключается в том, что если конечная точка 1 перестает работать по какой-либо причине, трафик не перенаправляется в конечную точку 2. Трафик из Германии по-прежнему направляется в конечную точку 1 независимо от ее работоспособности, в результате чего пользователи в Германии не могут получить доступ к приложению компании Г. Аналогичным образом, если конечная точка 2 переходит в автономный режим, перенаправление трафика в конечную точку 1 не происходит.

Чтобы избежать этой проблемы и обеспечить отказоустойчивость приложения, компания Г использует вложенные профили диспетчера трафика и Azure Site Recovery. При использовании вложенного профиля трафик направляется не в отдельные конечные точки, а в другие профили диспетчера трафика. Эта конфигурация работает следующим образом:

• Вместо использования географической маршрутизации с отдельными конечными точками компания Г использует географическую маршрутизацию с профилями диспетчера трафика.
• В каждом дочернем профиле диспетчера трафика используется маршрутизация по приоритету с первичной конечной точкой и конечной точкой восстановления с вложением маршрутизации по приоритету в географическую маршрутизацию.
• Для обеспечения отказоустойчивости приложений, каждое распределение рабочих нагрузок использует Azure Site Recovery для переключения на регион восстановления в случае аварийной ситуации.
• Когда родительский Менеджер трафика получает запрос DNS, он перенаправляется на соответствующий дочерний Менеджер трафика, который отвечает на запрос, предоставляя доступную конечную точку.

Например, если конечная точка в регионе "Центральная Германия" выходит из строя, приложение может быть быстро восстановлено в регионе "Северо-Восточная Германия". Новая конечная точка обрабатывает трафик из Германии с минимальным временем простоя. Аналогичным образом при сбое конечной точки в Западной Европе можно восстановить рабочую нагрузку приложения в Северной Европе, при этом диспетчер трафика Azure перенаправляет запросы DNS в доступную конечную точку.

Вышеупомянутую конфигурацию можно расширить, чтобы включить как можно больше комбинаций регионов и конечных точек. Диспетчер трафика допускает до 10 уровней вложенных профилей и не разрешает циклы внутри вложенной конфигурации.

Рекомендации относительно целевого времени восстановления (RTO)

В большинстве организаций добавление или изменение записей DNS обрабатывается отдельной командой или кем-то вне организации. Это делает задачу изменения записей DNS очень сложной. Время, затраченное на обновление записей DNS другими командами или организациями, управляющими инфраструктурой DNS, варьируется от организации к организации и влияет на RTO приложения.

Используя Traffic Manager, вы можете заранее подготовить работы, необходимые для обновления DNS. Во время фактического переключения отказа не требуется никаких действий вручную или скриптов. Такой подход помогает быстро переключаться (и, следовательно, снижает RTO), а также избегать ошибок изменения DNS в случае сбоя, которые отнимают много времени. Диспетчер трафика позволяет автоматизировать процесс возврата, который в противном случае пришлось бы управлять отдельно.

Установка правильного интервала проверки с помощью базовой или быстрой проверки работоспособности может значительно снизить RTO при переключении на резервный сервер и сократить время простоя для пользователей.

Вы можете дополнительно оптимизировать значение срока жизни (TTL) DNS для профиля диспетчера трафика. TTL — это значение, для которого запись DNS будет кэшироваться клиентом. Для записи DNS не будет запрашиваться дважды в промежутке TTL. Каждая запись DNS имеет связанный с ней TTL. Уменьшение этого значения приводит к увеличению количества запросов DNS к диспетчеру трафика, но может сократить RTO благодаря высокой скорости обнаружения сбоев.

TTL, который видит клиент, также не увеличивается, если число резолверов DNS между клиентом и полномочным DNS-сервером увеличивается. Резолверы DNS уменьшают TTL и передают только те значения TTL, которые отражают время, прошедшее с момента кэширования записи. Это гарантирует, что запись DNS будет обновлена в клиенте после истечения TTL, независимо от количества сопоставителей DNS в цепочке.

Следующие шаги

• Подробнее о методах маршрутизации диспетчера трафика.
• Узнайте больше о вложенных профилях диспетчера трафика.
• Узнайте больше о мониторинге конечных точек.
• Узнайте больше о планах восстановления для автоматизации перехода на резервный сервер.