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

О методах балансировки нагрузки диспетчера трафика

Обновлено: Сентябрь 2014 г.

Диспетчер трафика Windows Azure

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

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

Три метода балансировки нагрузки диспетчера трафика:

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

  • Циклический перебор. Выберите Циклический перебор, если необходимо распределять нагрузку между несколькими конечными точками в одном центре обработки данных или в разных центрах обработки данных. Дополнительные сведения см. в Метод балансировки нагрузки с циклическим перебором.

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

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

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

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

На Figure 1 показан пример метода балансировки нагрузки с отработкой отказа для набора конечных точек.

Балансировка нагрузки отказоустойчивости диспетчера трафика

Рис. 1

Пример отказоустойчивой балансировки нагрузки
Пронумерованные шаги соответствуют числам на рис. 1.

  1. Диспетчер трафика возвращает входящий запрос от клиента через DNS-сервер (это не показано) и находит профиль.

  2. Профиль содержит упорядоченный список конечных точек. Диспетчер трафика проверяет, какая точка является первой в списке. Если конечная точка работает (по данным мониторинга конечных точек), он укажет DNS имя этой конечной точки в DNS-ответе клиенту. Если конечная точка будет недоступна, диспетчер трафика определяет следующую работающую конечную точку в списке. В этом случае HS-A недоступна, но HS-B доступна.

  3. Диспетчер трафика возвращает доменное имя HS-B в DNS-ответе клиенту. Клиент затем разрешает имя HS-B в IP-адрес.

  4. Клиент запускает трафик на HS-B.

Примечания.

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

  • Необходимо указать порядок конечных точек на странице Конфигурация профиля после его создания.

  • Параметр TTL в DNS информирует DNS-клиенты и модули разрешения адресов на DNS-серверах, как долго длится кэширование имен. Клиенты будут продолжать использовать конечную точку при разрешении ее доменного имени, пока его запись в локальном кэше DNS не будет удалена.

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

Метод балансировки нагрузки с циклическим перебором также поддерживает взвешенное распределение сетевого трафика. Однако теперь необходимо настроить веса с помощью REST (см. раздел Создание определения) или Windows PowerShell (см. раздел New-AzureTrafficManagerProfile).

На Figure 2 показан пример метода балансировки нагрузки с циклическим перебором для набора конечных точек.

Балансировка нагрузки циклического перебора диспетчера трафика

Рис. 2

Пример циклической балансировки нагрузки
Пронумерованные шаги соответствуют числам на рис. 2.

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

  2. В профиле содержится список конечных точек. Диспетчер знает, какая точка был передана в последнем запросе. В этом примере это конечная точка HS-B.

  3. Диспетчер трафика возвращает доменное имя конечной точки из списка в DNS-ответе клиенту. В этом примере это конечная точка HS-C.

  4. Диспетчер трафика обновится, чтобы указать, что последний трафик был направлен в HS-C.

  5. Клиент разрешает доменное имя HS-C в IP-адрес и инициирует трафик.

Примечания.

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

На Figure 3 показан пример взвешенного метода балансировки нагрузки с циклическим перебором для набора конечных точек.

Взвешенная балансировка нагрузки с циклическим перебором

Рис. 3

Пример взвешенной балансировки нагрузки с циклическим перебором

Взвешенная балансировка нагрузки с циклическим перебором позволяет распределять нагрузку по различным конечным точкам на основе назначенного «веса» каждой конечной точки. Чем больше вес, тем чаще будет возвращаться конечная точка. Этот метод будет полезен в следующих сценариях:

  • Постепенное обновление приложения: направляйте часть трафика на новую конечную точку и постепенно доведите объем трафика до 100 %.

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

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

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

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

Балансировка нагрузки по производительности находит местоположение клиента и связывает его с ближайшей конечной точкой. «Близость» определяется таблицей сетевой производительности, в которой отражается время от отправки запроса до получения ответа между различными IP-адресами и каждым центром обработки данных Azure. Эта таблица обновляется периодически и не отражает производительность работы через Интернет в реальном времени. Он не учитывает нагрузку на данную службу, хотя диспетчер трафика ведет мониторинг конечных точек на основе выбранного метода и не будет включать их в запросы DNS, если они не работают. Другими словами, балансировка нагрузки по производительности включает также метод отказоустойчивой балансировки нагрузки.

На Figure 4 показан пример метода балансировки нагрузки по производительности для набора конечных точек.

Балансировка нагрузки производительности диспетчера трафика

Рис. 4

Пример балансировки нагрузки по производительности
Пронумерованные шаги соответствуют числам на рис. 4.

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

  2. Диспетчер трафика получает входящий запрос от клиента через DNS-сервер и находит профиль.

  3. Затем он находит строку в таблице производительности для IP-адреса входящего запроса.

  4. Далее он находит центр обработки данных с наименьшим временем среди тех, на которых размещены конечные точки, определенные в профиле. В этом примере это HS-D.

  5. Диспетчер трафика возвращает доменное имя HS-D в DNS-ответе клиенту. Клиент затем разрешает имя HS-D в IP-адрес.

  6. Клиент запускает трафик на HS-D.

Примечания.

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

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

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

  • Параметр TTL в DNS информирует DNS-клиенты и модули разрешения адресов на DNS-серверах, как долго длится кэширование имен. Клиенты будут продолжать использовать конечную точку при разрешении ее доменного имени, пока его запись в локальном кэше DNS не будет удалена.

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

См. также

Показ:
© 2014 Microsoft