Диспетчер трафика Azure по сравнению с другие методы балансировки
Когда мы берем его «снизу», т.е. с серверов, мы обычно строим их в каком-то режиме HA. Поэтому они расположены близко друг к другу, а для других должны отображаться под одним IP-адресом, что уравновешивает трафик между участниками. Нам нужно простое и универсальное решение, независимое от протокола, то есть работающее на L4 и поддерживающее как HTTP, так и протоколы баз данных и что угодно еще. Azure Load Balancer позаботится об этом за нас.
Однако иногда нам может понадобиться получить представление о самом протоколе, обычно HTTP. Мы хотели бы использовать постоянство сеанса cookie, ускорение SSL или маршрутизацию URL (то есть даже с тем же доменным именем, в зависимости от URL, вы можете добраться до других серверов — например, /images будет идти куда-то кроме /web). В результате этот перехватывающий балансировщик L7 может направить трафик на балансировщик L4. В мире Azure, в дополнение к этим трем сторонам (F5, KEMP, A10), вы также можете использовать собственный и экономичный шлюз приложений Azure.
Выше может быть диспетчер трафика Azure. Основное его преимущество в том, что он работает на уровне DNS, поэтому он полностью прозрачен для используемых протоколов и, самое главное, не находится на пути прохождения пакета. Все коммуникации приложений, такие как сеть или база данных, выходят за пределы балансировщика. Играет роль только в момент DNS-разрешения имени, а дальше все идет гладко (согласно настройкам TTL, DNS-системы какое-то время его запоминают, статус по умолчанию на данный момент 300, но можно дойти до 30). Благодаря этим функциям он идеально подходит для глобальной балансировки (до ближайшего центра обработки данных), автоматического аварийного переключения (DR) между двумя вашими контроллерами домена, между несколькими регионами Azure или из локальной среды в Azure и т. д., а также может быть используется для миграцийзеленое/синее развертывание.
Как работает диспетчер трафика
DNS — это глобальный адрес в Интернете, огромная, возможно, последовательно распределенная база данных, содержащая перевод красивого имени на неприглядный (для пользователей) IP-адрес. Например, введите в браузере www.tomaskubica.cz, и каждый DNS-сервер в сотрудничестве с авторитетными серверами обеспечит перевод на определенный общедоступный IP-адрес (это так называемый список A). Кроме того, протокол DNS может делать много других вещей, и одна из них — это CNAME, так что скажем псевдоним. То есть, если определенное имя не имеет конкретного IP-адреса (нет записи A), а является «псевдонимом» для другого имени. Затем клиент продолжает и запрашивает возвращенное имя, и это продолжается до тех пор, пока кто-то, наконец, не вернет запись A, которая завершает ее (и кэшируется). И это магия. Ваше основное имя приложения возвращает не список A, а только CNAME, и это не всегда одно и то же, но в зависимости от того, что имеет смысл — может быть, любое другое в соответствии с географическим положением, сбалансированное или первое по порядку и т. д. Таким образом, трафик Менеджер у него будет одно имя, но под ним задано несколько конечных точек (DNS-имен), на которые он будет отправлять пользователя по какому-то ключу.
Сам DNS-сервер часто использует только статические записи (с ним этого не происходит) и в частности он не может следить за доступностью конечных точек и автоматически удалять/добавлять их, если они перестают отвечать или, наоборот, начинают заново. Таким образом, диспетчер трафика представляет собой комбинацию мониторинга работоспособности, нескольких алгоритмов балансировки и DNS-сервера (по сути, это надежный DNS Azure в фоновом режиме, которым, конечно же, управляет диспетчер трафика).
Однако я должен указать на одно ограничение, основанное на свойствах протокола DNS. Балансировка DNS не работает с «голым» доменом, как правилонапример root по умолчанию. Причина в том, что стандарт DNS не позволяет записи CNAME существовать для одного имени одновременно с другими, а минимальный корневой домен должен также содержать записи SOA и NS (т.е. делегирование). В моем случае я не могу использовать tomaskubica.cz для приложения, кроме www.tomaskubica.cz, потому что я не могу ввести CNAME для первого в диспетчере трафика и для последнего региона и т. д. Это будет пустым Не использовать или, в случае веб-сервера, запустить перенаправление не на уровне DNS (через CNAME), а также по протоколу HTTP (перенаправление HTTP). На данный момент я не делал этого с диспетчером трафика (это поиск DNS, а не веб-сервер), поэтому вы можете использовать простой веб-сервер для поиска этих перенаправлений (например, tomaskubica.cz после того, как запрос DNS вернет список и он ведет к веб-серверу, который сделал перенаправление на www.tomaskubica.cz, что инициировало следующий DNS-запрос, который возвращает CNAME диспетчеру трафика, который также балансирует по мере необходимости).
Давайте настроим диспетчер трафика Azure
Создайте новый профиль диспетчера трафика.
Выберите имя по умолчанию для вашего приложения. Он должен быть уникальным в домене trafficmanager.net (позже мы узнаем, как направить туда ваш домен).
Выберите метод балансировки. У вас есть следующие варианты на выбор:
- Производительность — Azure будет смотреть на исходный IP-адрес запроса (это не адрес клиента, а его основной DNS-сервер, который обычно находится очень близко к нему, например в той же компании) Даже с региональным провайдером) и сравните ее с таблицей задержек, которую она постоянно ведет по отношению к регионам Azure. Идеально подходит для глобально распределенных приложений.
- Взвешенный — если вы присвоите одинаковый вес всем конечным точкам.будет результатом циклического перебора, т.е. диспетчер трафика будет делать это по одному. Однако вы можете приоритизировать некоторые конечные точки (придать им больший вес), что очень хорошо используется для постепенной миграции и сине-зеленого развертывания (например, установить новую версию приложения или конечную точку, перенесенную в облако, только до 5 %). трафика и медленно увеличиваться на небольшом количестве пользователей).
- Приоритет — вы также можете легко настроить конечные точки, и диспетчер трафика направит пользователя к первой доступной системе в заказе. Поэтому он идеально подходит для автоматического аварийного восстановления, аварийного переключения и т. д.
- Географический . Диспетчер трафика отправляет пользователя в определенный регион на основе исходного IP-адреса DNS-запроса (т. е. на основе его DNS-сервера). Идея состоит в том, чтобы гарантировать, что пользователь в Европе получает доступ только к европейским источникам.
Вы закончите диалог с водой. Обратите внимание, что если вы выберете регион, сервис в принципе станет глобальным и выдержит сбой всего региона (геоизбыточность является частью сервиса).
Давайте посмотрим на страницу конфигурации. В первой строке мы можем изменить время жизни по умолчанию с исходных 300 секунд. Для целей этой статьи я выберу крайний вариант, то есть 0. Это означает отсутствие кэширования на DNS-серверах и клиентах. Это позволит добиться очень короткого времени переключения, но нам придется через каждый запрос запрашивать установленное соединение (это может вообще не иметь значения, особенно если приложение устанавливает долгосрочную сессию TCP, это не имеет значения при все). Подумайте о том, что это повысит стоимость услуги (вы платите за количество запросов) — для бытовых ситуаций оставьте 300 минут, это идеальный компромисс.
Диспетчер трафикаследить за доступностью приложения, чтобы оно могло заменить конечные точки, которые перестали отвечать. Вы можете протестировать HTTP и HTTPS или стандартное соединение TCP (для приложений, не являющихся веб-приложениями).
Я выбираю HTTP, стандартный порт и корневой путь.
Ниже приведены настройки того, как часто диспетчер трафика может определять доступность приложения и после скольких сбоев он может объявить конечную точку недействующей. Помимо самих DNS-запросов, вы платите за количество отслеживаемых конечных точек (в Azure они несколько дешевле внешних) и собственно за количество тестов (либо 10, либо 30 одновременно).
Давайте сохраним настройки и добавим конечные точки.
Во-первых, давайте выберем тип конечной точки. Это может быть конечная точка Azure — в таком случае мы можем удобно обратиться напрямую к надежному источнику, а мониторинг доступности обходится несколько дешевле (поскольку проверка работоспособности не проходит через Интернет). Второй вариант — это внешняя конечная точка, то есть любое воображаемое имя. Эта опция предназначена для внутренней балансировки DNS, т. е. ситуации, когда вы хотите иерархически развернуть два метода разделения разрешения. Например, на первом уровне вы можете перейти и сбалансировать производительность по отчетам, а затем в отчете вы хотите, чтобы режим приоритета был основным и злым регионом.
В Azure я могу легко выбрать облачную службу, службу приложений или конкретный слот развертывания, а также общедоступный IP-адрес (его можно передать на конкретную виртуальную машину или, возможно, в Azure Load Balancer). Я выберу одну службу приложений.
Теперь воспользуемся dig, nslookup или другой утилитой и посмотрим на ответы DNS (переходим в РАЗДЕЛ ОТВЕТОВ).
Диспетчер трафика возвращает нам CNAMEmojewebaplikace.azurewebsites.net, т.е. в мое приложение App Services (оттуда продолжается дальше в сторону этого сервиса, пока не дойдем до IP-адреса).
Теперь мы перейдем к «локальной» версии приложения (на самом деле я тоже запускаю его в Azure, но это не беда — мы введем его вручную как внешний ресурс), но с более высокий приоритет.
Давайте посмотрим на мониторинг и выясним, оба ли варианта приложения онлайн. Поскольку мы балансируем с приоритетным режимом, основное имя приложения mojeappka.trafficmanager.net по-прежнему относится к первому яблоку в заказе. Теперь отключим первую конечную точку. Диспетчер трафика должен быть в порядке, если он больше не работает. В случае с некоторыми ресурсами Azure он находится быстрее (понимает, что приложение отключено в Azure), однако последняя ошибка проверки работоспособности сработает для всех из них.
Теперь посмотрим, что возвращает адрес mojeappka.trafficmanager.net.
VГЅbornД›, перешел на mapadoazure.tomaskubica.cz.
Прежде чем мы рассмотрим некоторые сцены, мы хотим знать одну вещь: что, если вы не хотите давать пользователям свое собственное имя пользователя. Затем просто введите CNAME на mapadoazure.trafficmanager.com на свой DNS-сервер под выбранным вами именем. Я использую Azure DNS, поэтому я заполню его там, но он работает одинаково для всех других DNS-серверов.
Теперь мы можем перейти прямо к моему собственному домену mojeappka.azure.tomaskubica.cz:
Сцена развернута
Давайте рассмотрим пару сцен подробнее.
Географически распределенные приложения
Первый вариант — это приложения, работающие в режиме Active/Active в разных регионах (и даже в Azure или у вас дома). Это характерно для глобальных приложений — игровых серверов, Uber, Office365,но и небольшие приложения и игры на мобильных устройствах. Например, создайте службы приложений в нескольких регионах Azure и добейтесь сохранения данных с помощью Cosmos DB, которые можно реплицировать глобально. Кроме того, разверните Диспетчер трафика в настройках «Производительность», чтобы пользователь был перенаправлен в регион с наименьшей задержкой для него и в то же время перенаправлен во второй ближайший регион в случае любого сбоя.
Аварийное восстановление
Другим очень типичным сценарием является аварийное переключение центра обработки данных или региона. Например, с помощью Azure Site Recovery вы можете обеспечить регулярную репликацию хранилища ваших виртуальных машин, чтобы их можно было быстро восстановить в другом регионе. Или вы выполняете транзакционную репликацию базы данных в другой регион, и там вы можете быстро открыть внешний интерфейс в службах приложений из GitHub. Или используйте Azure в качестве места аварийного восстановления для вашего центра обработки данных. В некоторых из этих сценариев технически возможна передача и IP-адресов, но это влечет за собой ряд неудобств. С точки зрения внешнего пользователя (остальное для другой статьи) DNS-имя имеет существенное значение. Это можно связать с диспетчером трафика, если вы используете режим приоритета и первый сайт — это ваш центр обработки данных, а второй — общедоступный IP-адрес в Azure (отказ виртуальной машины здесь). Важно то, что диспетчер трафика знает, что живо, а что нет, и направляет пользователя в нужный город. Вы должны запланировать DNS-имена следующим образом:
- mojeappka.domain.cz — здесь подключаются пользователи, а CNAME в DNS — mojeappka.trafficmanager.net
- myappka.trafficmanager.net — это ваш профиль диспетчера трафика
- mojeappka.internal.domain.cz — пусть это будет доменное имя вашего приложения в локальной версии
- myappka.westeurope.azure.domena.cz — это приложение в Azure в регионе Западной Европы
Мы могли бы поговорить о том, что добавить в ваш DNS, а что перенести в Azure DNS или следует ли переместить весь DNS после аварийного восстановления и т. д. — это тема для другого обсуждения и отдельной статьи.
Миграция
Переход от одного действия к другому идеально подходит для диспетчера трафика, который позволяет выполнять весь процесс очень легко. Предыдущее состояние все еще существует, и вы строите новое состояние на стороне. В определенный момент вы можете использовать взвешенную маршрутизацию DNS и отправлять только очень небольшое количество запросов в новое состояние и медленно тестировать новое состояние. постепенно увеличивайте, пока, наконец, вы полностью не перевернете весы и не уберете исходное состояние.
Что может быть «государство»? Например, местоположение можно перенести из локальной среды в облако или наоборот. Это также может быть литой выпуск в зелено-синем развертывании. Таким образом можно разворачивать большие изменения не в существующей инфраструктуре, а в совершенно новой (иногда так бывает и с серверами phoenix) и постепенно перемещать туда пользователей в Traffic Manager. Для обычных релизов хотелось бы на уровне балансировщика L7 (эта другая фича в виде слота развертывания и тестирования в продакшене напрямую входит в App Service, так что можно использовать уже в готовом окне), глобальный ( DNS), который находится в балансе во время массовых изменений.
Как спланировать геоизбыточность, геораспределенные приложения, автоматизировать аварийное восстановление и упростить сценарии миграции? Попробуйте Azure Traffic Manager — он встроен в Azure (использует приложения Azure в PaaS и IaaS), очень доступен (оплата в соответствии с фактическим использованием, единая лицензия) и прост в развертывании.
