Использование служб балансировки нагрузки в Azure

Введение

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

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

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

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

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

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

• Шлюз приложений предоставляет контроллер доставки приложений (ADC) как услугу, предлагая для приложения разные функции балансировки нагрузки уровня 7. Таким образом пользователи могут оптимизировать производительность веб-фермы за счет разгрузки ресурсоемких операций завершения сеансов SSL-запросов на шлюз приложений. Кроме того, пользователи получают другие возможности маршрутизации уровня 7, включая циклическое распределение входящего трафика, соответствие сеансу на основе файлов cookie, маршрутизацию на основе URL-путей и возможность размещения нескольких веб-сайтов за одним шлюзом приложений. Шлюз приложений можно настроить как шлюз с доступом в Интернет, внутренний шлюз или же как сочетание этих вариантов. Шлюз приложений полностью управляется Azure. Он является масштабируемым и обладает высоким уровнем доступности. Для более эффективного управления предоставляется широкий набор возможностей ведения журнала и диагностики.

• Балансировщик нагрузки — это неотъемлемая часть стека SDN Azure, которая обеспечивает высокую производительность и балансировку нагрузки уровня 4 с низкой задержкой для всех протоколов UDP и TCP. Она управляет и входящими, и исходящими подключениями. Вы можете настроить общедоступные и внутренние конечные точки с балансировкой нагрузки, а также определить правила для сопоставления входящих подключений к узлам серверной части, используя параметры проверки состояний по TCP и HTTP, чтобы управлять доступностью служб.

Сценарий

В этом примере мы используем простой веб-сайт, который предоставляет содержимое двух типов: изображения и динамически отображаемые веб-страницы. Этот веб-сайт должен быть географически избыточным. Он будет обслуживать пользователей из ближайших расположений (с наименьшей задержкой). Разработчик приложения решил, что все URL-адреса, которые соответствуют шаблону /images/*, должны обслуживаться выделенным пулом виртуальных машин, отделенных от остальной части веб-фермы.

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

Используя Диспетчер трафика, Шлюз приложений и Load Balancer, вы можете включить этот веб-сайт для достижения следующих целей проектирования:

• Высокая геоизбыточность. Когда один регион выходит из строя, диспетчер трафика незамедлительно перенаправляет трафик в следующий ближайший регион без каких-либо действий со стороны владельца приложения.
• Снижение задержки. Так как диспетчер трафика автоматически направляет пользователя в ближайший регион, гарантируется низкая задержка при запросе содержимого веб-страницы.
• Независимое масштабирование. Так как рабочие нагрузки веб-приложения разделены по типам содержимого, владелец приложения может масштабировать эти рабочие нагрузки независимо друг от друга. Шлюз приложений гарантирует, что трафик будет направлен в правильный пул в соответствии с установленными правилами и с учетом состояния работоспособности приложения.
• Внутренний балансировщик нагрузки. Если разместить балансировщик нагрузки перед высокодоступным кластером, приложение гарантированно будет обращаться только к работоспособным и активным конечным точкам базы данных. Кроме того, администратор базы данных может оптимизировать рабочую нагрузку, размещая в кластере активные и пассивные реплики независимо от приложения переднего плана. Балансировщик нагрузки обеспечивает подключение к высокодоступному кластеру, гарантируя, что запросы на подключение будут получать только работоспособные базы данных.

На следующей схеме показана архитектура этой системы.

Примечание.

Этот пример демонстрирует лишь одну из многих возможных конфигураций, которые можно реализовать с использованием служб Azure для балансировки нагрузки. Диспетчер трафика, шлюз приложений и балансировщик нагрузки можно использовать совместно в зависимости от ваших потребностей. Например, если вам не требуется разгрузка TLS или обработка уровня 7, то вместо Шлюза приложений можно применить Load Balancer.

Настройка стека балансировки нагрузки

Шаг 1. Создание профиля диспетчера трафика

1. На портале Azure выберите Создать ресурс>Сети>Профиль диспетчера трафика>Создать.

2. Введите следующие основные сведения.

   • Имя: присвойте профилю диспетчера трафика уникальное имя префикса DNS.
   • Метод маршрутизации: выберите метод маршрутизации трафика. Дополнительные сведения о методах маршрутизации трафика см. в статье Методы маршрутизации трафика диспетчером трафика.
   • Подписка: выберите подписку, которая содержит профиль.
   • Группа ресурсов: выберите нужную группу ресурсов, которая содержит профиль. Это может быть новая или уже существующая группа ресурсов.
   • Расположение группы ресурсов: служба диспетчера трафика является глобальной и не привязана к расположению. Тем не менее необходимо указать регион для группы, где расположены метаданные, связанные c профилем диспетчера трафика. Это расположение никак не влияет на доступность профиля.

3. Щелкните Создать, чтобы создать профиль диспетчера трафика.

   

Шаг 2. Создание шлюзов приложений

1. На портале Azure в области слева щелкните Создать ресурс>Сеть>Шлюз приложений.

2. Введите следующие данные о шлюзе приложений.

   • Имя: имя шлюза приложений.
   • Размер SKU: размер шлюза приложений, доступные значения: "Мелкий", "Средний" и "Крупный".
   • Число экземпляров: количество экземпляров (от 2 до 10).
   • Группа ресурсов: группа ресурсов, которая содержит шлюз приложений. Это может быть новая или уже существующая группа ресурсов.
   • Расположение: регион для шлюза приложений, в котором располагается группа ресурсов. Это расположение важно, так как виртуальная сеть и общедоступный IP адрес должны находиться в том же расположении, что и шлюз.

3. Щелкните OK.

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

Примечание.

Если вы используете ПРОТОКОЛ HTTPS, выберите HTTPS рядом с протоколом на вкладке прослушивателя . Параметр по умолчанию — HTTP. Необходимо также создать и назначить SSL-сертификат. Дополнительные сведения см. в руководстве по Шлюз приложений ssl.

Настройка маршрутизации URL-адресов для шлюзов приложений

Шлюз приложений, для которого настроено правило указания на основе пути, при выборе пула серверной части использует не только циклический перебор, но и формат URL-адреса в конкретном запросе. В этом сценарии мы добавляем правило на основе пути, чтобы направить любой URL-адрес с помощью "/images/*" в пул серверов образов. Дополнительные сведения о настройке маршрутизации на основе URL-адресов для шлюза приложений см. в статье "Создание правила на основе пути" для шлюза приложений.

1. Перейдите к группе ресурсов и найдите экземпляр шлюза приложений, созданный в предыдущем разделе.

2. В разделе Параметры выберите Серверные пулы, а затем щелкните Добавить, чтобы добавить виртуальные машины, которые вы хотите связать с серверными пулами веб-уровня.

3. Введите имя внутреннего пула и IP-адреса всех виртуальных машин, включенных в этот пул. В этом сценарии мы подключаем два внутренних пула серверов виртуальных машин.

   

4. В разделе Параметры для шлюза приложений выберите Правила и нажмите кнопку Path based (На основе пути), чтобы добавить новое правило.

   

5. Настройте правило, указав следующие сведения.

   Основные параметры:

   • Имя: понятное пользователю имя правила, которое отображается на портале.
   • Прослушиватель: прослушиватель, который используется для этого правила.
   • Default backend pool (Серверный пул по умолчанию): серверный пул, который будет использоваться для правила по умолчанию.
   • Default HTTP settings (Параметры HTTP по умолчанию): параметры HTTP, которые будут использоваться для правила по умолчанию.

   Правила на основе пути.

   • Имя: понятное пользователю имя правила на основе пути.
   • Пути: правило на основе пути для направления трафика.
   • Серверный пул: серверный пул, который будет использоваться с этим правилом.
   • Параметры HTTP: параметры HTTP, которые будут использоваться для этого правила.

   Внимание

   Пути: допустимые пути должны начинаться с символа /. Использование подстановочного знака "*" допускается только в конце. Примеры допустимых значений: /xyz, /xyz*, или /xyz/*.

   

Шаг 3. Добавление шлюзов приложений для конечных точек диспетчера трафика

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

1. Откройте профиль диспетчера трафика. Для этого поищите профиль диспетчера трафика в группе ресурсов или найдите его имя в разделе Все ресурсы.

2. В области слева выберите Конечные точки, а затем щелкните Добавить, чтобы добавить конечную точку.

   

3. Создайте конечную точку, указав следующие сведения.

   • Тип: выберите тип конечной точки для балансировки нагрузки. В этом сценарии выберите конечную точку Azure, так как мы подключаем ее к экземплярам шлюза приложений, настроенным ранее.
   • Имя: введите имя конечной точки.
   • Тип целевого ресурса: выберите Общедоступный IP-адрес, а затем для параметра Целевой ресурс выберите ранее настроенный общедоступный IP-адрес шлюза приложения.

   

4. Теперь вы можете протестировать настройку, перейдя к ней с помощью DNS профиля Диспетчер трафика (в этом примере: TrafficManagerScenario.trafficmanager.net). Вы можете повторно отправить запросы, создать виртуальные машины или перенести виртуальные машины и веб-серверы, созданные в разных регионах. Вы также можете изменять и тестировать различные параметры профиля Диспетчер трафика.

Шаг 4. Создание балансировщика нагрузки

В нашем примере балансировщик нагрузки распределяет подключения, направляемые от веб-уровня к базам данных, размещенным в высокодоступном кластере.

Если кластер базы данных с высоким уровнем доступности использует SQL Server AlwaysOn, ознакомьтесь с пошаговой инструкцией по настройке одного или нескольких прослушивателей группы доступности AlwaysOn.

Дополнительные сведения о настройке внутреннего балансировщика нагрузки см. в статье Создание балансировщика нагрузки на портале Azure.

1. На портале Azure в области слева щелкните Создать ресурс>Сеть>Подсистема балансировки нагрузки.
2. Выберите имя подсистемы балансировки нагрузки.
3. Для параметра Тип укажите значение Внутренний и выберите соответствующие виртуальную сеть и подсеть, в которых будет размещен балансировщик нагрузки.
4. В разделе Назначение IP-адресов выберите вариант Динамическое или Статическое.
5. В разделе Группа ресурсов выберите группу ресурсов для балансировщика нагрузки.
6. В разделе Расположение выберите подходящий регион для балансировщика нагрузки.
7. Щелкните Создать, чтобы создать балансировщик нагрузки.

Подключение уровня внутренней базы данных к балансировщику нагрузки

1. В группе ресурсов найдите балансировщик нагрузки, который уже был создан ранее.

2. В разделе Параметры выберите Серверные пулы, а затем щелкните Добавить, чтобы добавить серверный пул.

   

3. Укажите имя внутреннего пула.

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

Настройка проверки

1. В разделе Параметры для балансировщика нагрузки выберите Пробы, а затем щелкните Добавить, чтобы добавить пробу.

   

2. Введите имя пробы.

3. Выберите протокол для проверки. Для базы данных вам больше подойдет проба TCP, а не HTTP. Дополнительные сведения о пробах подсистемы балансировки нагрузки см. в статье "Общие сведения о пробах подсистемы балансировки нагрузки".

4. Укажите порт базы данных, который будет использоваться для доступа к пробе.

5. В разделе Интервал укажите частоту проверки приложения.

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

7. Нажмите кнопку ОК, чтобы создать пробу.

Настройка правил балансировки нагрузки

1. В разделе Параметры балансировщика нагрузки выберите Правила балансировки нагрузки, а затем щелкните Добавить, чтобы создать правило.
2. Введите имя правила балансировки нагрузки.
3. Укажите внешний IP-адрес балансировщика нагрузки, а затем — протокол и порт.
4. В разделе Внутренний порт укажите порт, который будет использоваться в серверном пуле.
5. Выберите серверный пул и пробу, которые вы создали ранее и к которым будет применяться правило.
6. В разделе Сохранение сеанса выберите способ сохранения сеансов.
7. В разделе Время ожидания простоя укажите время ожидания (в минутах) до перехода в режим простоя.
8. В разделе Плавающий IP-адрес выберите Отключен или Включен.
9. Нажмите кнопку ОК, чтобы создать правило.

Шаг 5. Подключение виртуальных машин веб-уровня к балансировщику нагрузки

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

Следующие шаги

• Обзор диспетчера трафика
• Обзор шлюза приложений
• Обзор Azure Load Balancer