Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
doPDF - это бесплатный PDF конвертер. С помощью этой программы, можно создавать PDF файлы, выбрав команду "Печать" из пр...
WinHotel Pro программа для учета бронирования заявок в гостинице, отеле, базе отдыха, пансионате, мотеле. Позволяет вест...
Программа для учета работы сервисного центра (ремонтной мастерской). Она позволяет вести журнал заказов по приему техник...
Программа WinTour Pro - предназначена для учета работы туристического агентства. Основные функции системы: регистрация д...
EF StartUp Manager - программа для слежением за программами, которые запускаются вместе с загрузкой операционной системы...
OSzone.net Microsoft ИТ-инфраструктура Облако Microsoft Azure Traffic Manager - контроль за трафиком сервисов и виртуальных машин в облаке RSS

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

Текущий рейтинг: 0 (проголосовало 0)
 Посетителей: 304 | Просмотров: 370 (сегодня 0)  Шрифт: - +

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

Что такое Traffic Manager?

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

*

  • Performance: весь трафик идет на сервис, расположенный ближе всего в терминах маршрутизации к клиенту - клиентов из США - в датацентр в США, и так далее. В этом случае Microsoft Azure Traffic Manager будет использовать сетку доступных IP-адресов для того, чтобы определить, какой датацентр является наиболее близким географически. Если же точка доступа и экземпляр, наиболее близкий географически, не отвечают, то запрос будет переводиться на другой экземпляр и точку доступа. Соответственно, возникающий вопрос латентности необходимо обрабатывать путем увеличения времени таймаута внутри самого сервиса. Подробнее можно прочитать тут:  http://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)

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

Иcточник: MSDN  •  Опубликована: 28.07.2014
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER
Теги:  


Оценить статью:
Вверх
Комментарии посетителей RSS

Чтобы оставить комментарий, зарегистрируйтесь или войдите с учетной записью социальной сети.