Устранение неполадок с Azure Load Balancer
Azure Load Balancer работает на транспортном уровне сетевого стека. Load Balancer объявляет один общедоступный IP-адрес, к которому подключаются все клиенты. Затем Load Balancer использует собственные правила маршрутизации и преобразования адресов, чтобы направить входящие запросы TCP на один из исходящих адресов в наборе. Как правило, каждый исходящий адрес связывается с отдельной виртуальной машиной, где выполняется экземпляр приложения.
Load Balancer использует пробу работоспособности для определения доступности каждой виртуальной машины в внутреннем пуле. Load Balancer отправляет запросы только для виртуальных машин, которые сообщают о своей работоспособности.
В примере сценария вы получили оповещения, указывающие, что Load Balancer не может направить запросы на виртуальные машины во внутреннем пуле. Вы подозреваете, что проблема может быть вызвана недавним изменением в конфигурации сети. Но вам нужно понимать, как изменения сети влияют на работу Load Balancer.
К концу этого урока вы сможете:
- описать типичную конфигурацию Load Balancer и компоненты, используемые при маршрутизации запросов на виртуальные машины;
- описать распространенные проблемы, которые могут препятствовать Load Balancer распределять запросы по виртуальным машинам.
Как работает Load Balancer?
Azure Load Balancer включает множество компонентов:
- Внешний IP-адрес
- Внутренний пул адресов виртуальных машин
- Одно или несколько правил маршрутизации
- Проба работоспособности
- Коллекция виртуальных машин, обычно в виртуальной сети
На следующей схеме показано, как различные элементы, используемые Load Balancer, работают вместе.
Внешний IP-адрес и внутренний пул
Load Balancer обеспечивает прозрачное сквозное подключение от клиента до приложения, выполняемого в коллекции виртуальных машин. Load Balancer хранит IP-адреса этих виртуальных машин в репозитории, обычно называемом внутренним пулом. Load Balancer предоставляет клиентам собственные внешние IP-адреса. Когда клиент отправляет запрос на этот адрес, Load Balancer выбирает IP-адрес виртуальной машины из внутреннего пула. Затем Load Balancer направляет запрос по этому внутреннему IP-адресу на виртуальную машину.
Клиент не подозревает о существовании Load Balancer. Клиент видит IP-адрес или DNS-имя и отправляет запросы по этому назначению. Этот процесс аналогичен прямому взаимодействию клиента с виртуальной машиной. При поступлении запроса на виртуальную машину адрес исходного клиента сохраняется.
Кроме того, полезные данные в виде сообщений, отправленных с клиента на виртуальную машину, непрозрачны для Load Balancer. Служба Load Balancer не проверяет содержимое никаких сообщений и не обрабатывает их. Она переадресует сообщения таким образом, чтобы они отправлялись на выбранную виртуальную машину.
Load Balancer выбирает IP-адрес виртуальной машины из внутреннего пула с помощью алгоритма, предназначенного для равномерного распределения запросов. Load Balancer создает хэш, используя следующие сведения:
- Исходный IP-адрес и порт клиента
- Конечный IP-адрес и порт
- Сетевой протокол
Хэшированное значение используется в качестве ключа к таблице, содержащей IP-адреса во внутреннем пуле.
Масштабируемость
Вы можете запускать дополнительные экземпляры виртуальных машин и добавлять ИХ IP-адреса в внутренний пул в любое время. Load Balancer включает эти новые экземпляры при распределении запросов пользователей.
Load Balancer может предоставлять больше одного общедоступного внешнего IP-адреса и иметь несколько внутренних пулов. Эта схема позволяет повторно использовать один и тот же экземпляр Load Balancer для обработки запросов к различным системам.
Правила маршрутизации
С помощью правил балансировки нагрузки можно определить, как запросы, направленные на каждый внешний IP-адрес, сопоставляются с внутренним пулом. Правило балансировки нагрузки также указывает протокол для сопоставления и, при необходимости, исходный (клиент) и конечный порты. Входящие запросы, поступающие на внешний IP-адрес, который не соответствует требованиям к протоколу и порту, отклоняются Load Balancer. Правило балансировки нагрузки также может настроить сохраняемость сеансов, чтобы определенный клиент, скорее всего, перенаправил свои запросы на ту же виртуальную машину, что позволяет приложениям, работающим на виртуальной машине, использовать кэширование для хранения сведений о сеансе.
Зонды работоспособности
Службе Load Balancer необходимо определить, доступна ли каждая виртуальная машина, на которую ссылается серверный пул, для обработки запросов. Доступность определяется путем добавления пробы работоспособности. Проба работоспособности отправляет регулярные сообщения проверки связи на порт, указанный для виртуальных машин во внутреннем пуле. Вы предоставляете службу на виртуальных машинах, которая отвечает на эти сообщения проверки связи сообщением HTTP 200 (ОК).
Если виртуальной машине не удается предоставить ответ после указанного числа попыток, Load Balancer предполагает, что она неработоспособна, и удаляет ее из списка виртуальных машин, которые могут принимать запросы пользователей. Затем рабочая нагрузка распределяется между оставшимися работоспособными виртуальными машинами. Load Balancer продолжает проверку связи с виртуальной машиной, от которой отсутствует ответ. Если виртуальная машина начинает отвечать, она добавляется обратно в список работоспособных виртуальных машин и снова начинает принимать запросы пользователей.
Если проба работоспособности не предоставлена, Load Balancer не знает, является ли виртуальная машина работоспособной. Вместо этого предполагает, что все виртуальные машины отвечают на запросы.
Виртуальная сеть
Виртуальные машины, на которые ссылается внутренний пул, размещаются в подсети виртуальная сеть Azure. Для защиты виртуальных машин в этой сети нужно настроить группу безопасности сети (NSG). NSG реализует правила безопасности для входящего и исходящего трафика, которые могут ограничивать трафик, поступающий в виртуальную сеть и покидающий ее, набором четко заданных конечных точек.
Например, виртуальные машины во внутреннем пуле Load Balancer обычно разрешают входящий трафик через порт 80 (HTTP) и порт 443 (HTTPS), поступающий извне виртуальной сети. Но виртуальные машины могут блокировать трафик, проходящий через другие порты.
Симптомы и причины сбоев для Load Balancer
Проблемы возникают, когда Load Balancer теряет подключение к одной или нескольким виртуальным машинам во внутреннем пуле. К типичным симптомам относятся следующие:
- Приложение недоступно.
- Виртуальные машины, на которых выполняется приложение, недоступны.
- Большое время отклика.
- Истекает время ожидания для запросов пользователей.
У этих сбоев может быть множество причин. Чаще всего связаны с проблемами, касающимися использования пробы и путей к данным.
Проблемы с использованием пробы
Проблемы с использованием пробы возникают, когда одна или несколько виртуальных машин в серверном пуле не отвечают на запросы пробы работоспособности. Эти проблемы могут быть вызваны следующими причинами:
- Неправильная конфигурация пробы, например неверный URL-адрес или порт.
- Виртуальная машина не отвечает на пробу, так как не открыт требуемый порт.
Проблемы с путями к данным
Проблемы с путями данных возникают, когда Load Balancer не удается перенаправить запрос клиента в приложение, выполняющееся на виртуальной машине во внутреннем пуле. Возможные причины:
- Правило NSG или брандмауэр блокируют порты или IP-адреса, используемые приложением.
- Виртуальная машина не работает или не отвечает. Возможно, виртуальная машина отключена или вышла из строя, либо возникла ошибка безопасности, например, истек срок действия сертификата на сервере.
- Приложение не отвечает. Возможно, виртуальные машины перегружены, приложение прослушивает неверный порт или происходит сбой приложения.