Проектирование географически распределенной архитектуры сети
В распределенном приложении важно обеспечить надежное взаимодействие компонентов и маршрутизацию запросов в другой компонент или регион в случае сбоя.
Мы решили переделать портал отслеживания в Azure, чтобы снизить уязвимость к региональным сбоям. Мы хотим убедиться, что приложение выполняет отработку отказа на компоненты в дополнительном регионе, если основной регион недоступен. Отработка отказа должна привести к минимальному нарушению доставки служб пользователям.
Здесь мы узнаем, как Azure DNS, Диспетчер трафика, Front Door и Azure CDN поддерживают архитектуру приложения нашей компании доставки.
Azure DNS
Как уже говорилось ранее, вносить изменения в реализацию Azure DNS не нужно. Мы используем Azure DNS для размещения записей доменных имен, определяющих наше приложение.
Azure DNS обеспечивает разрешение имен исключительно с помощью инфраструктуры Azure. Эта служба по своей природе является многорегиональной, поэтому изменять существующую конфигурацию Azure DNS для поддержки новой архитектуры не требуется.
Соглашение об уровне обслуживания Azure DNS также обеспечивает 100 % гарантии того, что допустимые запросы DNS получают ответ по крайней мере от одного сервера доменных имен Azure DNS все время.
Выбор маршрутизатора трафика
Нам нужна служба, позволяющая распределять нагрузку и перенаправлять трафик распределенного веб-приложения между несколькими регионами.
Azure предоставляет несколько разных служб, которые могут маршрутизировать трафик между интерфейсными компонентами. Как вы помните, нам нужно заменить Шлюз приложений Azure, так как он привязан к одному региону. В случае сбоя этого региона маршрутизацию выполнять нечему.
В Azure есть два маршрутизатора трафика, которые могут производить глобальную маршрутизацию между несколькими регионами и поэтому устойчивы к сбоям в одном регионе:
- Диспетчер трафика Azure
- Azure Front Door
Давайте рассмотрим эти службы подробнее, чтобы выбрать подходящую для нашего приложения.
Что такое диспетчер трафика Azure
Диспетчер трафика Azure — это глобальная подсистема балансировки нагрузки, которая использует записи DNS для маршрутизации трафика в назначения в нескольких регионах Azure.
Диспетчер трафика можно настроить так, чтобы все запросы маршрутизировались в основной регион и в этом регионе отслеживалась скорость реакции Службы приложений. В случае сбоя Службы приложений в основном регионе диспетчер трафика автоматически перенаправляет запросы пользователей в Службу приложений в дополнительном регионе. Благодаря такому перенаправлению обеспечивается отработка отказа для непрерывного обслуживания. Такая схема работы называется режимом маршрутизации по приоритету.
Так как диспетчер трафика использует систему DNS, он маршрутизирует трафик по любым протоколам, а не только HTTP. Однако диспетчер трафика не может маршрутизировать или фильтровать трафик на основе свойств HTTP, таких как коды стран клиентов или заголовки агентов пользователя. Он также не может служить точкой завершения протокола TLS, то есть расшифровывать запросы и зашифровывать ответы, чтобы снять эту задачу с виртуальных серверов Службы приложений. Если нам нужна любая из этих функций, мы должны использовать Azure Front Door.
Диспетчер трафика обеспечивает гибкую настройку мониторинга конечных точек. Например, можно определить протокол, порт, путь, настраиваемые параметры заголовка, ожидаемые диапазоны кодов состояния и допустимое количество сбоев. Мониторинг конечных точек дает полное представление об общей работоспособности всех частей приложения.
Что такое Azure Front Door?
Как и диспетчер трафика, Azure Front Door — это глобальная подсистема балансировки нагрузки. В отличие от диспетчера трафика, он работает на прикладном уровне сети (уровень 7) и использует свойства HTTP и HTTPS для фильтрации и маршрутизации.
С помощью Front Door можно выполнять различные типы маршрутизации, которые не поддерживаются диспетчером трафика. Например, можно маршрутизировать трафик на основе кода страны браузера. Front Door также поддерживает завершение протокола TLS.
Однако есть исключение. Если мы хотим маршрутизировать трафик для любого протокола, отличного от ПРОТОКОЛА HTTP и HTTPS, необходимо использовать Диспетчер трафика.
Front Door позволяет назначать приоритеты различным внутренним службам, которые составляют портал отслеживания. Исходя из этих приоритетов, Front Door маршрутизирует запросы требуемым образом. Мы назначаем наши службы основного региона с главным приоритетом и службой дополнительных регионов с более низким приоритетом.
В службе Front Door реализованы проверки работоспособности для отслеживания состояния работоспособности служб, чтобы в случае сбоя она могла маршрутизировать трафик правильно. Режим маршрутизации по приоритету и мониторинг конечных точек в службе Front Door аналогичны этим функциям в диспетчере трафика за тем исключением, что проверки работоспособности всегда выполняются по протоколу HTTP.
Весь трафик пользовательского веб-интерфейса и интерфейсов API портала отслеживания передается по протоколу HTTPS, что позволяет заменить диспетчер трафика Azure службой Front Door. Мы также можем настроить Front Door с приоритетом назначения серверной части.
Azure CDN
В архитектуре с одним регионом мы использовали Azure CDN для кэширования статического содержимого из хранилища BLOB-объектов Azure. Служба Azure CDN — это глобальная сеть серверов, которая кэширует статическое содержимое ближе к пользователям. Изменять эту службу для архитектуры, охватывающей несколько регионов, не нужно. Однако в следующем уроке рассматриваются вопросы, касающиеся нашей служба хранилища Azure учетной записи.