Traffic Manager — Это балансировщик нагрузки as a Service, работающий как с Azure, так и с сервисами вне его.
Нагрузка может быть поделена между узлами как равномерно, так и пропорционально заданным весам [1-1000], там же поддерживаются проверки работоспособности узлов (Health Check).
В случае, если в балансировщике несколько групп серверов, один, например, в регионе US, второй в EU, то клиент будет перенаправляться к той группе серверов, до которой ближе к клиенту (ping меньше).
На хабре были 1, 2 статьи про использование Traffic Manager, я же, как всегда, чуть более подробно попытаюсь рассказать.
Термины
Чтобы при дальнейшем обсуждении говорить на одном языке, нужно дать определения 2 терминам.
- EndPoint — URL, по которому отвечает каждый конкретный сервис/сервер/сайт. Таких точек может быть в profile много, и уж точно более 1, т.к. иначе зачем вообще TM!
- Profile – объединение Endpoints и содержит в себе стратегию распределения нагрузки и внешний балансируемый URL.
Настройка
В примере настройки, используемом ниже, считается, что наши сервисы отвечают по адресам myapp-eu.cloudaupp.net, myapp-us.cloudapp.net
Настройку TM можно провести либо через Management Portal, либо используя .net sdk (до сих пор в версии preview), либо через powershell командлеты. В любом случае, это работает через один и тот же API. SDK для java, node пока не готовы.
Минимальная настройка состоит из 2 шагов.
- Создание Profile
- Добавление EndPoint к Profile
А дальше уже действуем по обстоятельствам.
API
Весь API — это десяток операций
- Получить весь список, создание, обновление, удаление, блокирование Profile.
- Добавление/Удаление/Изменение свойств EndPoint в Profile.
- Проверка свободен ли DomainName, который будет балансировать.
Мониторинг состояния узлов/EndPoint
В плане мониторинга состояния узлов TM не предлагает ничего сверхъестественного. Он просто проверяет 200 код ответа по определенному URL (+если необходимо относительный путь до ресурса типа /index.html). Из настроек есть порт (80-443) и протокол (http/https). Никакого умного анализа контента — только базовые фичи. Хотя для многих и этого будет достаточно.
Как работает проверка работоспособности узла
Traffic Manager каждые 30 секунд отправляет Get запрос к EndPoint и ждет не более 10 секунд. Если EndPoint ответил 200 кодом в течение 10 секунд, то сервис считается рабочим. Между этими 30 секундами состояние EndPoint не проверяется.
Если EndPoint не ответил или код не 200, или ответил после 10 секунд, то сама endpoint считается неработоспособной. Как только 1 endpoint был признан не работоспособным, будет еще 3 попытки проверить статус с интервалом 5 секунд (суммарно 4 попытки), до того, как endpoint будет показан как неработоспособный. Если из этих 3 раз хотя бы 1 раз сервис ответил кодом 200 в заданный интервал, EndPoint считается рабочим, и счетчик попыток сбрасывается. Если же EndPoint продолжает не отвечать, то он продолжает проверяться, но уже отмечен как неработоспособный, и нагрузка на него подаваться не будет.
Трафик все еще может остаточно приходить на EndPoint, т.к. в DNS может быть еще закэширована запись. Как только TTL (Time To Live) истекает, трафик полностью прекращает идти на Endpoint. Это не Traffic Manager такой глупый, что продолжает какой-то период времени подавать нагрузку на сбойный узел, а устройство и оптимизация нагрузки на DNS.
В документации от MSFT можно прочесть даже советы, как проверять работоспособность сервиса, используя dns-lookup, не забыть при этом сбросить dns кэш, через команду flushdns.
Режимы работы балансировщика
Есть всего 3 режима работы балансировщика:
- Performance. В этом случае для клиента будет определяться ближайший сервер, и он будет работать именно с ним.
- Failover — это не балансировка, я бы даже сказал. Допустим, у вас есть 4 узла, один из них основной, а остальные – это Replica Set с него. Все узлы (кроме основного) — это резерв. Вся нагрузка будет на основной узел, пока он живой. Как только он будет недоступен, будет выбран следующий в очереди по приоритету сервер, и вся нагрузка уйдет на него, до восстановления сервера.
- Round Robin — запросы в соответствии с заданными весами распределяются между EndPoint
Traffic Manager не DNS
Если зайти на голосовалку за фичи в Azure, то на первой странице можно найти много запросов про «дайте нам DNS в облаке, дайте возможность задавать кастомные доменные имена, а не *.cloudapp.net» и таких на первой-же странице 3 разных запроса: 1,2,3.
Надо отдавать себе отчет, что Traffic Manager — это не DNS. Его внешний адрес будет именно MyProfileName.trafficmanager.net, и вы можете выбрать только имя профиля балансировки. А уже в своем dns надо будет прописать, что MyProfileName.trafficmanager.net это mydomain.com
Я не знаю, почему до сих пор не сделали dns as a service, но уже года 2 просят.
Логирование изменений в profile
Поскольку балансировка нагрузки — это точка входа в ваше приложение, то любые изменения его конфигурации должны фиксироваться. Именно поэтому все изменения в profile можно просмотреть в истории.
Цены
Деньги в TM платятся за 2 фичи: запросы к DNS и проверка работоспособности узла. При этом сюда, понятно дело, не включен трафик из Azure, т.к. это оплачивается отдельно.
Каждый узел при проверке здоровья оплачивается отдельно, ну и, понятное дело, если узел не в azure, то он в 1.5 раза дороже.
Ссылки
- Стартовая
- Стартовая документации
- Стартовая страница для конфигурации
- Предложить и проголосовать за фичи
P.S. Если Вы хотите помочь улучшить статью- можно предлогать ваши правки через github
Автор: SychevIgor
