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

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

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

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

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

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

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

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

• Компания А создает профиль диспетчера трафика.
• Используя метод маршрутизации по приоритету, компания А создает две конечные точки — первичную для внутреннего пользования и отказоустойчивую для Azure. Первичной присваивается приоритет 1, а отказоустойчивой — приоритет 2.
• Так как первичная конечная точка размещена за пределами Azure, она создается как внешняя.
• При использовании Azure Site Recovery на сайте 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 в случае сбоя. Метод маршрутизации трафика по приоритету позволяет компании В легко реализовать эту схему отработки отказа.

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

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

В случае сбоя компания В может выполнить отработку отказа в регион восстановления 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 приложения.

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

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

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

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

Дальнейшие действия

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