Экспорт (0) Печать
Развернуть все

Обзор диспетчера трафика

Обновлено: Июль 2014 г.

Диспетчер трафика Azure позволяет управлять распределением пользовательского трафика для заданных конечных точек, то есть облачных служб Azure, веб-сайтов и других конечных точек. Диспетчер трафика работает, применяя интеллектуальную систему политик к запросам DNS, относящимся к доменным именам ваших интернет-ресурсов. Ваши облачные службы или веб-сайты Azure могут работать в разных центрах обработки данных во всем мире.

Диспетчер трафика позволяет выполнить следующее.

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

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

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

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

В разделе Figure 1 показано, как диспетчер трафика направляет пользователей на одну конечную точку из набора конечных точек. Числа на рис. 1 соответствуют пронумерованным описаниям внизу.

DNS-последовательность

Рис. 1

  1. Пользовательский трафик к домену компании. Клиент запрашивает сведения с помощью имени домена компании. Целью является преобразование DNS-имени в IP-адрес. Домены компании должны быть зарезервированы с использованием нормальной регистрации имен доменов Интернета. Их обслуживание выполняется вне диспетчера трафика. На рисунке 1 домен компании — www.contoso.com.

  2. Домен компании к домену диспетчера трафика. Запись ресурса DNS для домена компании указывает на домен диспетчера трафика, обслуживаемый в диспетчере трафика Azure. Это достигается с помощью записи ресурса CNAME, сопоставляющей доменное имя компании и доменное имя диспетчера трафика. В примере доменное имя диспетчера трафика — contoso.trafficmanager.net.

  3. Домен и профиль диспетчера трафика. Домен диспетчера трафика входит в состав профиля диспетчера трафика. DNS-сервер пользователя отправляет новый запрос DNS для домена диспетчера трафика (в нашем примере это contoso.trafficmanager.net), который принимается DNS-серверами диспетчера трафика.

  4. Обработка правил профиля диспетчера трафика. Диспетчер трафика использует указанный метод балансировки нагрузки и данные мониторинга, чтобы определить, какая конечная точка Azure или другая конечная точка должна обработать запрос.

  5. Доменное имя конечной точки, отправляемое пользователю. Диспетчер трафика возвращает запись CNAME, которая сопоставляет домен диспетчер трафика с доменом конечной точки. DNS-сервер пользователя разрешает доменное имя конечной точки в ее IP-адрес и отправляет его пользователю.

  6. Пользователь вызывает конечную точку. Пользователь вызывает возвращенную конечную точку напрямую, используя ее IP-адрес. Поскольку домен компании и разрешенный IP-адрес кэшируются на клиентском компьютере, пользователь продолжает взаимодействовать с выбранной конечной точкой, пока не истечет срок действия локального кэша. Важно отметить, что DNS-клиент кэширует записи узла DNS в течение их срока жизни (TTL). Извлечение записей узлов из кэша DNS-клиента не затрагивает профиль диспетчера трафика, что может привести к задержке подключения, если конечная точка станет недоступна до истечения TTL. Если TTL DNS-записи узла в кэше клиента истекает и клиентскому компьютеру снова требуется разрешить доменное имя компании, он отправляет новый запрос DNS.

Процесс повторяется, когда истекает срок действия записи в кэше DNS клиента и клиентский компьютер должен разрешить доменное имя еще раз. Пользователь может получить IP-адрес другой конечной точки в зависимости от метода балансировки нагрузки, примененного к политике, и состояния исправности конечной точки во время запроса.

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

Главная страница Traffic Manager

Рис. 2

  1. Развертывание облачных служб Azure, веб-сайтов Azure и других конечных точек в производственной среде. При создании профиля диспетчера трафика его необходимо связать с подпиской. Затем можно добавить конечные точки для облачных служб и веб-сайтов уровня Standard, входящих в ту же подписку, в рабочей среде. Если конечная точка находится в промежуточной, а не в рабочей среде Azure или в другой подписке, она не будет доступна для добавления. Дополнительные сведения об облачных службах см. в разделе Облачные службы. Дополнительные сведения о веб-сайтах см. в разделе Веб-сайты.

  2. Выберите метод балансировки нагрузки, который будет использоваться. Доступны три различных метода балансировки нагрузки. Найдите время и разберитесь, какой метод лучше всего соответствует вашим требованиям. Если потребуется изменить метод позже, то это можно сделать в любое время. Обратите внимание, что все методы требуют немного разных шагов конфигурации. Сведения о методах балансировки нагрузки см. в разделе О методах балансировки нагрузки диспетчера трафика.

  3. Выберите настройку наблюдения, которая будет использоваться. Диспетчер трафика наблюдает за конечными точками для гарантии того, что они доступны, какой бы метод балансировки нагрузки ни применялся. После задания параметров мониторинга диспетчер трафика не передает трафик конечным точкам, которые находятся в автономном режиме согласно системе мониторинга, если он не обнаружит, что все точки находятся в режиме «не в сети», или не сможет определить состояние какой-либо точки в профиле. Дополнительные сведения о мониторинге см. в разделе О мониторинге диспетчера трафика.

  4. Выберите имя для своего домена диспетчера трафика. Рассмотрите возможность задать имя для своего домена с уникальным префиксом. Последняя часть имени домена (trafficmanager.net) остается постоянной. Дополнительные сведения см. в Рекомендации.

  5. Создайте профиль и настройте параметры. Для создания профиля диспетчера трафика и настройки параметров можно использовать либо API REST, либо портал управления. Следующие шаги предполагают, что использован пункт Быстрое создание на портале.

  6. Проверьте свой профиль диспетчера трафика. Проверьте, работают ли ваши профиль и домен в соответствии с ожиданиями. Дополнительные сведения о том, как это сделать, см. в разделе Проверка параметров диспетчера трафика.

  7. Направьте запись ресурса DNS доменного имени вашей компании на профиль, чтобы сделать его активным.Дополнительные сведения см. в разделе Направление интернет-домена компании на домен диспетчера трафика.

    В примере на рисунке 1 необходимо изменить запись ресурса DNS на серверах на следующее значение, чтобы направить доменное имя компании на доменное имя диспетчера трафика:

    www.contoso.com IN CNAME contoso.trafficmanager.net

Настройки работы диспетчера трафика можно задать на портале управления, с помощью API-интерфейсов REST или командлетов Windows PowerShell.

Хотя на портале управления отображаются не все элементы API-интерфейсов REST, многие настройки можно задать с помощью обоих этих методов. Дополнительные сведения об использовании API REST см. в разделе Операции, относящиеся к диспетчеру трафика (справочник по API-интерфейсу REST).

Дополнительные сведения о командлетах Windows PowerShell для диспетчера трафика см. в разделе Командлеты для диспетчера трафика Azure.

noteПримечание
  • Настройка внешних конечных точек (тип = «Любые») на портале управления не поддерживается. При использовании таких конечных точек с методом балансировки нагрузки «Производительность» необходимо указать расположение, а этот параметр недоступен на портале управления.

  • В текущий момент настройка весов для метода балансировки нагрузки с циклическим перебором на портале управления не поддерживается. Необходимо использовать REST (см. раздел Создание определения) или Windows PowerShell (см. раздел New-AzureTrafficManagerProfile).

На портале управления с помощью функции быстрого создания можно создать собственный профиль диспетчера трафика. Функция быстрого создания позволяет создать базовый профиль. После создания профиля можно задать дополнительные настройки либо изменить настройки, которые были заданы ранее. Дополнительные сведения о создании профиля диспетчера трафика с помощью функции быстрого создания см. в разделе Создание профиля диспетчера трафика с помощью «Быстрого создания».

На портале управления можно задать следующие настройки:

  • Префикс DNS. Уникальный префикс, который вы создаете. Профили отображаются на портале управления по префиксам.

  • Срок жизни (TTL) DNS. Значение TTL DNS управляет тем, как часто сервер доменных имен локального кэширования клиента будет запрашивать систему DNS диспетчера трафика Azure для обнаружения обновленных DNS-записей.

  • Подписка. Выберите подписку, к которой будет относиться этот профиль. Обратите внимание, что этот параметр отображается только в том случае, если у вас несколько подписок.

  • Метод балансировки нагрузки. Способ, посредством которого диспетчер трафика будет балансировать нагрузку.

  • Порядок отработки отказа — при использовании метода балансировки нагрузки с отработкой отказа это порядок конечных точек.

  • Мониторинг — параметры мониторинга включают протокол (HTTP или HTTPS), порт, относительный путь и имя файла.

Создать и настроить профиль диспетчера трафика можно с помощью API-интерфейсов REST. Дополнительные сведения см. в разделе Операции, относящиеся к диспетчеру трафика (справочник по API-интерфейсу REST).

  • Профиль, который содержит префикс создаваемого доменного имени. Каждый профиль соответствует подписке. Можно создать несколько профилей для одной подписки. Имя профиля отображается на портале управления. Создаваемое имя, указанное в профиле, называется доменом диспетчера трафика.

  • Определение содержит параметры политики и мониторов. Определение соответствует профилю. Для профиля может существовать только одно определение. Само определение не отображается на портале управления, хотя многие из параметров в определении видны и могут быть настроены на портале.

  • Параметры DNS — в каждом определении есть параметры DNS. Здесь настраивается параметр DNS TTL (время жизни запроса).

  • Мониторы. В каждом определении содержатся параметры монитора. Здесь настраиваются протокол, порт, имя файла и относительный путь. Параметры мониторов отображаются и могут быть изменены на портале управления. Дополнительные сведения см. в О мониторинге диспетчера трафика.

  • Политика. Параметры политики содержатся в каждом определении. В политике задаются методы и конечные точки балансировки нагрузки. Сама политика не отображается на портале управления, хотя многие из параметров политики видны и могут быть настроены на портале. Дополнительные сведения см. в О методах балансировки нагрузки диспетчера трафика.

Создать и настроить профиль диспетчера трафика можно с помощью Windows PowerShell. Дополнительные сведения см. в статье Командлеты для диспетчера трафика Azure.

  • Сделайте свои префиксы уникальными и легкими для понимания — DNS-имя профиля диспетчера трафика должно быть уникальным. Можно изменять только первую часть имени DNS. Доменное имя диспетчера трафика используется только для идентификации и направления клиентских запросов. Клиентские компьютеры никогда не отображают эти имена конечным пользователям. Однако это доменное имя определяет профили, поэтому важно, чтобы его можно было быстро отличить от других доменных имен, перечисленных в интерфейсе портала управления.

  • Используйте точки для обеспечения уникальности или облегчения чтения доменных имен — также точки можно использовать для разделения частей префикса доменного имени. Если вы планируете создать несколько политик в диспетчере трафика, используйте согласованную иерархию, чтобы различать службы. Например, в Contoso присутствуют глобальные службы для работы в Интернете, выставления счетов и управления программами. Можно было бы использовать три политики: web.contoso.trafficmanager.net, bill.contoso.trafficmanager.net и util.contoso.trafficmanager.net. При настройке облачных служб и веб-сайтов используйте имена, которые указывают на физическое местоположение. Например, web-us-contoso.cloudapp.net и web-asia-contoso.cloudapp.net. Ограничения накладываются системой DNS. Предположим, что имя домена - это последовательность меток, разделенная точками (метка.метка.метка.метка. и т. д.). На момент написания этой документации в диспетчере трафика существовали следующие ограничения для имен доменов.

    • Длина каждой метки не может превышать 63 символов.

    • Нельзя иметь более 40 меток. Две метки заняты trafficmanager.net, поэтому для префикса остается 38.

    • Длина всего доменного имени не может превышать 253 символов. Не забывайте, что trafficmanager.net занимает 19 из этих символов.

  • Срок жизни (TTL) DNS. Значение TTL DNS управляет тем, как часто сервер доменных имен локального кэширования клиента будет запрашивать систему DNS диспетчера трафика Azure для обнаружения обновленных DNS-записей. Для любого изменения, происходящего в пределах диспетчера трафика, например изменения профиля или изменения доступности конечной точки, потребуется этот промежуток времени, чтобы оно распространилось по глобальной системе DNS-серверов. Рекомендуется оставить для этого параметра значение по умолчанию - 300 секунд (5 минут). При задании более высокого числа увеличивается время хранения ответов DNS диспетчера трафика в кэше разрешителями и DNS-клиентами, благодаря чему общая задержка запросов DNS уменьшается. Однако если требуется быстрая отработка отказа, то лучше задать более низкое значение.

  • Конечные точки должны находиться в одной подписке — все конечные точки должны быть в той подписке, в которой создается профиль. Можно добавить конечные точки из разных подписок в профиль как внешние конечные точки, но Azure не удалит их автоматически, если отключить или удалить связанную службу. В результате внешние конечные точки сохранятся в профиле диспетчера трафика, и за них будет взиматься плата, если их вручную не удалить.

  • Только службы рабочей среды — доступны только конечные точки в рабочей среде. Нельзя направлять трафик на конечные точки, работающие в промежуточной среде. Обратите внимание, что если переключить VIP, когда профиль направляет трафик, трафик будет использовать конечную точку, только что введенную в рабочую среду.

  • Назовите конечные точки так, чтобы потом их можно было легко идентифицировать — учитывайте префикс DNS. DNS-имя используется, поскольку его уникальность гарантируется в пределах подписки. Имя облачной службы или веб-сайта этого не гарантирует. Во избежание путаницы присваивайте облачным службам и веб-сайтам одинаковые или схожие имена и DNS-префиксы. При наличии более 20 облачных служб и веб-сайтов плохой метод именования затрудняет поиск нужных конечных точек. Кроме того, плохо названные конечные точки затрудняют обслуживание профилей.

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

  • Все облачные службы в профиле должны использовать одни и те же параметры мониторинга. Можно выбрать только один путь и файл для отслеживания всех конечных точек в заданном определении. Можно ввести «/» в поле Относительный путь и имя файла, чтобы мониторинг попытался получить доступ к пути и имени файла по умолчанию.

  • Отключите конечные точки для внесения временных изменений, а не меняйте конфигурацию - во многих случаях может потребоваться перевести конечную точку в режим «не в сети». Вместо удаления конечной точки из профиля просто отключите отдельную конечную точку конечных точек в профиле. Эта операция оставляет конечную точку в рамках профиля, но при этом профиль действует так, как если бы конечная точка не была в него включена. Это полезно, если нужно временно удалить конечную точку, которая находится в режиме обслуживания или повторно развертывается. После повторного запуска конечной точки ее можно включить. Дополнительные сведения см. в Отключение или включение конечной точки.

  • Отключите профиль для внесения временных изменений, а не удаляйте его. Может потребоваться перевести в режим «не в сети» весь профиль, а не только отдельные конечные точки, указанные в нем. Для этого отключите профиль. При отключении профиля все параметры остаются доступными для редактирования на портале управления. При этом можно быстро перевести профиль в режим «в сети». Дополнительные сведения см. в Включение, отключение и удаление профиля.

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

  • SQL Azure — аналогично проектированию хранилища необходимо выполнить проектирование и анализ состояния и требований к данным для приложения при расширении конечной точки до нескольких географических регионов.

См. также

Показ:
© 2014 Microsoft