Microsoft Azure Traffic Manager - контроль за трафиком сервисов и виртуальных машин в облаке

 

В этой заметке о Microsoft Azure Traffic Manager посмотрим на то, что это за сервис, на основы его работы, и посмотрим на примере, как можно вручную настроить балансировку нагрузки между двумя сайтами с Wordpress, расположенных в разных датацентрах и регионах и использующих одну базу данных MySQL как сервис.

• Что такое Traffic Manager?

• Microsoft Azure Traffic Manager - механизм слежения за распределения трафика между двумя и более сервисами (веб-сайтами) или виртуальными машинами в облаке Microsoft Azure, которые расположены и доступны за единым URL, но в разных датацентрах Microsoft Azure. По своей сути Microsoft Azure Traffic Manager - это распределенный DNS-сервис, который знает о том, какие сервисы и экземпляры ВМ расположены, и какой из трех подходов распределения трафика нужно применять:

• • Failover: весь трафик идет на один сервис. Сервис выходит из строя - трафик перенаправляется на его Failover-реплику. Подробнее можно прочитать тут: https://msdn.microsoft.com/en-us/library/windowsazure/hh744833.aspx#BKMK_FLB

 

• • Performance: весь трафик идет на сервис, расположенный ближе всего в терминах маршрутизации к клиенту - клиентов из США - в датацентр в США, и так далее. В этом случае Microsoft Azure Traffic Manager будет использовать сетку доступных IP-адресов для того, чтобы определить, какой датацентр является наиболее близким географически. Если же точка доступа и экземпляр, наиболее близкий географически, не отвечают, то запрос будет переводиться на другой экземпляр и точку доступа. Соответственно, возникающий вопрос латентности необходимо обрабатывать путем увеличения времени таймаута внутри самого сервиса. Подробнее можно прочитать тут: https://msdn.microsoft.com/en-us/library/windowsazure/hh744833.aspx#BKMK_PLB

• • Round-robin: трафик распределяется поровну между экземплярами сервиса. Подробнее: https://msdn.microsoft.com/en-us/library/windowsazure/hh744833.aspx#BKMK_PLB

• Практика

• Рассмотрим на примере. Пример простой - у нас есть веб-сайт, экземпляры которого разнесены для целей масштабирования и отказоустойчивости по нескольким датацентрам (помните сайт Олимпиады в Сочи? О чем и речь). Как сделать так, чтобы внешние клиенты заходили на сайт и попадали на тот экземпляр, который ближе к ним географически? Давайте посмотрим.

• В нашем случае есть два сайта, и оба они представляют собой развернутый из шаблона Wordpress, и оба сайта используют одну базу данных MySQL как сервис. Обратите внимание на режим "Стандартный" - это обязательное условие для использования Microsoft Azure Traffic Manager.

• Создадим профиль Microsoft Azure Traffic Manager. Метод - производительность.

• После создания профиля необходимо добавить точки доступа. Если повторять это демо, то нужно предварительно настроить Wordpress, иначе будет происходить редирект (ответ 302) на страницу настройки, что приведет к неработоспособности Microsoft Azure Traffic Manager.

• Важнейшим моментом Microsoft Azure Traffic Manager является наличие возможности использовать смешанный режим веб-сайтов и Cloud Services - можно оперативно переключиться с веб-сайта на веб-роль.

• Теперь можно протестировать точку доступа Microsoft Azure Traffic Manager. Если говорить о концепции работы Microsoft Azure Traffic Manager, то стоит уточнить, что все сконфигурированные веб-сайты добавляются в раздел доменных имен нашего сервиса, и это можно легко проверить с помощью nslookup.

• Теперь, если зайти на адрес нашего сервиса Microsoft Azure Traffic Manager, то я попаду на экземпляр моего блога, расположенный наиболее близко ко мне географически. При этом систему можно строить сколь бы то ни было большой и распределенной - единую базу данных, которая используется в нашем случае, можно также сделать распределенной и расположить, например, внутри фермы серверов, и балансировка нагрузки от обоих экземпляров блога будет равномерно распределяться по серверам внутри фермы.

• Разумеется, что можно присвоить и собственное доменное имя - с помощью записи CNAME у своего регистратора DNS, направив его на адрес [name].trafficmanager.net.

• Подобную процедуру можно легко повторить с Cloud Service. Вынесенное же в заголовок упоминание виртуальных машин понятно в этом же контексте - все виртуальные машины Microsoft Azure автоматически располагаются в Cloud Service и могут быть таким образом сгруппированы, поэтому принципиальной разницы между балансировкой нагрузки с помощью Microsoft Azure Traffic Manager простого Cloud Service и виртуальной машины нет.

• Давайте подытожим

• Microsoft Azure Traffic Manager - сервис, который можно использовать для того, чтобы на базе автоматизированнной инфраструктуры Microsoft Azure и Microsoft Azure Traffic Manager строить распределенные по всему миру сервисы и балансировать нагрузку таким образом, каким это выглядит наиболее приемлимо с позиции разработчика. При этом полезно понимать, что использование Microsoft Azure Traffic Manager может быть необязательным в случае распределенного сервиса внутри одного региона и датацентра - в этом случае проще возложить обязанности по балансировке на плечи автоматически работающих сервисов платформы.

• Также важно понимать ограничения Microsoft Azure Traffic Manager:

• • восприятие только 200 HTTP-ответа в качестве положительного
  • отсутствие возможности работы с UDP
  • Microsoft Azure Traffic Manager может быть использован только с сервисами в Production (для виртуальных машин Staging нет, они создаются сразу в Production, так что это требование актуально только для Cloud Services)

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