Принцип работы диспетчера трафика

Диспетчер трафика Azure позволяет управлять распределением трафика между конечными точками приложения. Конечная точка — это любая служба, размещенная в среде Azure или за ее пределами, с доступом в Интернет.

Диспетчер трафика обеспечивает два ключевых преимущества:

Когда клиент пытается подключиться к службе, он должен сначала преобразовать DNS-имя службы в IP-адрес. Затем клиент подключается к тому IP-адресу, чтобы получить доступ к службе.

Наиболее важным моментом является то, что диспетчер трафика работает на уровне DNS, который находится на уровне приложения (уровень-7). Диспетчер трафика использует DNS для перенаправления клиентов к определенным конечным точкам службы на основе правил метода маршрутизации трафика. Клиенты подключаются к выбранной конечной точке напрямую. Диспетчер трафика не является прокси-сервером или шлюзом. Диспетчер трафика не видит передачу трафика между клиентом и службой.

Диспетчер трафика использует профили для управления трафиком в облачные службы или конечные точки веб-сайта. Дополнительные сведения о профилях см. в разделе "Управление профилем диспетчера трафика Azure".

Пример диспетчера трафика

Contoso Corp разработала новый портал партнеров. URL-адрес этого портала https://partners.contoso.com/login.aspx. Приложение выполняется в трех регионах Azure. Чтобы повысить доступность и повысить глобальную производительность, они используют диспетчер трафика для распределения трафика клиента в ближайшую доступную конечную точку.

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

  1. Разверните три экземпляра службы. DNS-имена этих развертываний: "contoso-us.cloudapp.net", "contoso-eu.cloudapp.net" и "contoso-asia.cloudapp.net".
  2. Создайте профиль диспетчера трафика с именем "contoso.trafficmanager.net" и настройте его для использования метода маршрутизации трафика "Производительность" в трех конечных точках.
  3. Настройте их доменное имя "partners.contoso.com", чтобы оно указывало на "contoso.trafficmanager.net", используя запись DNS CNAME.

Important

Только один azure [идентификатор клиента] может принадлежать заданному DNS-имени диспетчера корневого трафика. При попытке использовать имя, которое уже используется, отображается ошибка. В следующем примере корневое DNS-имя — contoso. Кроме того, если профиль создается с помощью разделенного точками имени, например partners.contoso.trafficmanager.net, contoso.trafficmanager.net автоматически зарезервирован.

Снимок экрана: конфигурация DNS диспетчера трафика с сопоставлением записей CNAME из partners.contoso.com в contoso.trafficmanager.net.

Note

При использовании персонализированного домена с Azure Traffic Manager необходимо использовать CNAME, чтобы направить ваше персонализированное доменное имя на доменное имя вашего диспетчера трафика. Стандарты DNS не позволяют создавать CNAME в вершине домена (или корневом каталоге). Таким образом, нельзя создать CNAME для "contoso.com" (иногда называется "голым" доменом). Можно создать только CNAME для домена в разделе "contoso.com", например "www.contoso.com". Чтобы обойти это ограничение, рекомендуется разместить домен DNS в Azure DNS и использовать записи псевдонимов для указания профиля диспетчера трафика. В качестве альтернативы вы можете использовать простое перенаправление HTTP для направления запросов для "contoso.com" на альтернативное имя, например "www.contoso.com".

Как клиенты подключаются с помощью диспетчера трафика

В предыдущем примере, когда клиент запрашивает страницу https://partners.contoso.com/login.aspx, клиент выполняет следующие действия, чтобы устранить DNS-имя и установить подключение:

Снимок экрана, показывающий поток подключения клиента через Диспетчер трафика и шаги разрешения DNS от клиента к рекурсивным DNS-серверам, серверам имен Диспетчера трафика и к конечной точке.

  1. Клиент отправляет DNS-запрос в настроенную рекурсивную службу DNS для разрешения имени "partners.contoso.com". Рекурсивная служба DNS, иногда называемая "локальной службой DNS", не размещает домены DNS напрямую. Клиент перекладывает работу по установлению связи с различными авторитетными службами DNS в Интернете, необходимого для разрешения DNS-имени.

  2. Чтобы устранить DNS-имя, рекурсивная служба DNS находит серверы имен для домена "contoso.com". Затем он связывается с этими серверами имен, чтобы запросить запись DNS partners.contoso.com. Dns-серверы contoso.com возвращают запись CNAME, указывающую на contoso.trafficmanager.net.

  3. Затем рекурсивная служба DNS находит серверы имен для домена "trafficmanager.net", который предоставляется службой Диспетчера трафика Azure. Затем он отправляет запрос на запись DNS contoso.trafficmanager.net на эти DNS-серверы.

  4. Серверы DNS диспетчера трафика получают запрос. Они выбирают конечную точку на основе:

  5. Диспетчер трафика возвращает выбранную конечную точку в качестве другой записи DNS CNAME. В этом случае предположим, что он возвращает contoso-eu.cloudapp.net.

  6. Затем рекурсивная служба DNS находит серверы имен для домена "cloudapp.net". Он обращается к этим серверам имен, чтобы запросить запись DNS contoso-eu.cloudapp.net. DNS-сервер возвращает запись A, содержащую IP-адрес конечной точки службы на основе ЕС.

  7. Рекурсивная служба DNS объединяет результаты и возвращает клиенту один ответ DNS.

  8. Клиент получает результаты DNS и подключается к указанному IP-адресу. Клиент подключается к конечной точке службы приложений напрямую, а не через диспетчер трафика. Так как это конечная точка HTTPS, клиент выполняет необходимое подтверждение SSL/TLS, а затем делает HTTP-запрос GET для страницы "/login.aspx".

Диспетчер трафика и кэш DNS

Рекурсивная служба DNS кэширует полученные ответы DNS. Сопоставитель DNS на клиентском устройстве также кэширует результат. Кэширование позволяет последующим dns-запросам быстрее получать ответы, используя данные из кэша, а не запрашивать другие серверы имен. Свойство "время жизни" (TTL) каждой записи DNS определяет продолжительность хранения в кэше. Более короткие значения приводят к более быстрому истечению срока действия кэша и большему количеству обращений к серверам имён Traffic Manager. Длинные значения означают, что перенаправление трафика от неудачной конечной точки занимает больше времени. Диспетчер трафика позволяет настроить TTL в ответах DNS как минимум 0 секунд и максимальное значение 2 147 483 647 секунд (максимальный диапазон, соответствующий RFC-1035), чтобы выбрать значение, которое лучше всего балансирует потребности приложения.

FAQs

Дальнейшие шаги

См. дополнительные сведения в статье Мониторинг и отработка отказов конечной точки диспетчера трафика.

См. дополнительные сведения в статье Методы маршрутизации трафика диспетчером трафика.

  • Last updated on