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

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

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

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

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

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

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

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

Корпорация Contoso разработала новый партнерский портал. 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) настройте запись CNAME в DNS, которая указывает на contoso.trafficmanager.net.

Важно!

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

Примечание

При использовании личного домена с диспетчером трафика Azure необходимо использовать запись 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 и установить подключение:

1. Клиент отправляет запрос DNS рекурсивной службе DNS для разрешения имени partners.contoso.com. (Рекурсивная (локальная) служба 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 отправляет этим серверам запрос на запись DNS для имени contoso.trafficmanager.net.

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

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

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, используя данные из кэша, а не результаты запросов к другим серверам доменных имен. Длительность хранения записей DNS в кэше определяется свойством time-to-live (срок жизни, TTL). Чем меньше это значение, тем быстрее запись в кэше будет считаться истекшей, следовательно, сервера доменных имен, используемые диспетчером трафика, будут получать больше запросов. Более высокие значения приведут к тому, что при сбое конечной точки потребуется больше времени, чтобы переключить трафик на другие конечные точки. Диспетчер трафика позволяет настраивать срок жизни, используемый в ответах службы доменных имен (DNS) диспетчера трафика, в диапазоне от 0 до 2 147 483 647 секунд (максимальный диапазон в соответствии с RFC-1035), позволяя вам выбрать значение, которое лучше всего соответствует требованиям приложения.

Часто задаваемые вопросы

• Какой IP-адрес использует диспетчер трафика?

• Какого типа трафик можно маршрутизировать с помощью диспетчера трафика?

• Поддерживает ли Диспетчер трафика прикрепленные сеансы?

• Почему при использовании диспетчера трафика отображается HTTP-ошибка?

• Как устранить проблему 500 (внутренняя ошибка сервера) при использовании диспетчера трафика?

• Как сказывается на производительности использование диспетчера трафика?

• Какие протоколы приложения пригодны для использования с диспетчером трафика?

• Можно ли использовать Диспетчер трафика с доменным именем без префикса?

• Учитывает ли диспетчер трафика адрес подсети клиента при обработке запросов DNS?

• Что такое срок жизни DNS и как он влияет на пользователей?

• Каковы минимальный и максимальный сроки жизни, которые можно задать для ответов диспетчера трафика?

• Что подразумевается под объемом запросов, поступающих в мой профиль?

Дальнейшие действия

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

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