Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Проба работоспособности Azure Load Balancer — это функция, которая обнаруживает состояние работоспособности экземпляров приложения. Он отправляет запрос экземплярам, чтобы проверить, доступны ли они и отвечают на запросы. Проба работоспособности может быть настроена для использования различных протоколов, таких как TCP, HTTP или HTTPS. Это важная функция, так как она помогает обнаруживать сбои приложений, управлять нагрузкой и планировать простой.
Для правил Azure Load Balancer требуется проверка работоспособности для определения состояния конечной точки. Конфигурация проверки работоспособности и ответов на неё определяет, какие экземпляры серверного пула получают новые подключения. Используйте пробы работоспособности для обнаружения сбоя приложения. Создайте пользовательский ответ для пробы работоспособности. Используйте пробу работоспособности для управления потоком, чтобы управлять нагрузкой или плановым простоем. При сбое пробы работоспособности подсистема балансировки нагрузки останавливает отправку новых подключений в соответствующий неработоспособный экземпляр. Исходящие подключения не затрагиваются. Затрагиваются только входящие.
Протоколы проверки
Пробы работоспособности поддерживают множественные протоколы. Доступность определенного протокола проверки работоспособности зависит от SKU балансировщика нагрузки. Кроме того, поведение службы зависит от номера SKU Load Balancer, как показано в таблице ниже.
| Номер SKU | Протокол пробы | Реакция на сбой пробы |
|---|---|---|
| Стандартный | TCP, HTTP, HTTPS | При сбое всех проб работоспособности потоки TCP продолжаются. |
| Базовый | TCP, HTTP | При сбое всех проб срок действия потоков TCP истекает. |
Свойства пробы
Пробы работоспособности имеют следующие свойства:
| Имя свойства проверки работоспособности | Сведения |
|---|---|
| Имя. | Название проверки работоспособности. Это имя, которое вы задаёте для проверки работоспособности. |
| Протокол | Протокол пробы работоспособности. Это тип протокола, который должна использовать проверка работоспособности. Параметры: TCP, HTTP, HTTPS |
| Порт | Порт проверки работоспособности. Конечный порт, который вы хотите использовать пробу работоспособности при подключении к виртуальной машине для проверки работоспособности. |
| Интервал (в секундах) | Интервал пробы работоспособности. Время (в секундах) между отдельными проверками в двух последовательных попытках проверки работоспособности виртуальной машины |
| Порог | Пороговое значение пробы работоспособности. Количество успешных или неудачных попыток проверки работоспособности, чтобы разрешить или запретить доставку трафика на виртуальную машину. |
| Где используется | Список правил подсистемы балансировки нагрузки с помощью этой пробы работоспособности. Чтобы проверка работоспособности была эффективной, необходимо иметь хотя бы одно правило, использующее проверку работоспособности. |
Конфигурация пробы
Конфигурация пробы работоспособности состоит из следующих элементов:
| Конфигурация пробы работоспособности | Сведения |
|---|---|
| Протокол | Протокол пробы работоспособности. Это тип протокола, который должна использовать проверка работоспособности. Доступны следующие варианты: TCP, HTTP, HTTPS |
| Порт | Порт проверки работоспособности. Целевой порт, который вы хотите использовать пробу работоспособности при подключении к виртуальной машине, чтобы проверить состояние работоспособности виртуальной машины. Необходимо убедиться, что виртуальная машина также прослушивает этот порт (т. е. открытый порт). |
| Интервал | Интервал пробы работоспособности. Время (в секундах) между последовательными попытками проверки работоспособности виртуальной машины |
Протокол зондирования
Протокол, используемый пробой работоспособности, можно настроить на один из следующих вариантов: TCP, HTTP, HTTPS.
| Сценарий | Проба TCP | Проба HTTP/HTTPS |
|---|---|---|
| Обзор | Проверки TCP инициализируют подключение, выполняя трехстороннее подтверждение по открытому TCP-протоколу на определенном порту. TCP-пробы завершают соединение с помощью четырёхэтапного закрытия TCP-соединения. | HTTP и HTTPS выполняют HTTP-запрос GET по указанному пути. Обе пробы поддерживают относительные пути для HTTP GET. Пробы HTTPS аналогичны пробам HTTP, но к ним добавлен протокол TLS. С помощью проб HTTP/HTTPS удобно реализовать собственную логику для удаления экземпляров из подсистемы балансировки нагрузки, если порт для пробы также является прослушивателем службы. |
| Поведение при отказе датчика | Проверка TCP завершается ошибкой, когда: 1. Прослушиватель TCP на экземпляре вообще не отвечает в течение периода ожидания. Проба помечается как недоступная в зависимости от количества запросов проверки, на которые не был получен ответ в течение заданного времени; это количество настраивается как порог перед переводом пробы в состояние недоступности. 2. Проба получает сброс TCP-соединения от экземпляра. |
Проба HTTP/HTTPS завершается ошибкой, если: 1. Конечная точка пробы возвращает код ответа HTTP, отличный от 200 (например, 403, 404 или 500). 2. Конечная точка пробы вообще не реагирует на запросы в течение минимального интервала пробы и 30-секундного периода ожидания. Несколько запросов проверки могут оставаться без ответа, прежде чем проверка будет помечена как не выполняющаяся и истечёт суммарное время всех интервалов ожидания. 3. Конечная точка пробы закрывает подключение путем сброса TCP-соединения. |
| Поведение при успешной проверке | Пробы работоспособности TCP считаются работоспособными и помечают серверную конечную точку как работоспособную, если: 1. Проба работоспособности выполнена успешно уже после загрузки виртуальной машины. 2. Любая серверная конечная точка в работоспособном состоянии может получать новые потоки. |
Проверка работоспособности помечается как успешная, если экземпляр возвращает код состояния HTTP 200 до истечения времени ожидания. Пробы работоспособности HTTP/HTTPS считаются работоспособными и помечают серверную конечную точку как работоспособную, если: 1. Проба работоспособности выполнена успешно уже после загрузки виртуальной машины. 2. Любая серверная конечная точка в работоспособном состоянии может получать новые потоки. |
Примечание.
Проба HTTPS требует использования сертификатов на основе минимального хэша сигнатуры SHA256 во всей цепочке.
Реакция на сбой пробы
| Сценарий | TCP-подключения | Датаграммы UDP |
|---|---|---|
| Пробы одного экземпляра вниз | Новые TCP-подключения успешно остаются работоспособными серверной конечной точкой. Установленные TCP-подключения к этой серверной конечной точке продолжаются. | Существующие потоки UDP перемещаются в другой здоровый экземпляр в серверном пуле. |
| Проверка всех экземпляров вниз | Новые потоки не отправляются в серверный пул. Load Balancer категории «Стандартный» позволяет уже установленным TCP-потокам продолжать работу при условии, что внутренний пул содержит более одного внутреннего экземпляра. Базовый балансировщик нагрузки (выведенный из эксплуатации) завершает все существующие потоки TCP к серверному пулу. | Все существующие потоки UDP завершаются. |
Интервал пробы и время ожидания
Значение интервала определяет, как часто зонд работоспособности проверяет наличие ответа от экземпляров серверного пула. Если проверка работоспособности завершается сбоем, балансировщик нагрузки немедленно помечает экземпляры внутреннего пула как неработоспособные. Если при следующей проверке проверка работоспособности проходит успешно, Azure Load Balancer помечает экземпляры внутреннего пула как работоспособные. Зонд здоровья по умолчанию пытается проверять настроенный порт зонда здоровья каждые 5 секунд в портале Azure, но вы можете установить другое значение. При развертывании через ARM-шаблоны, REST API, Azure CLI или PowerShell, интервал по умолчанию составляет 15 секунд (минимум 5 секунд).
Чтобы обеспечить своевременное получение ответа, пробы работоспособности HTTP/S имеют встроенные тайм-ауты. Ниже приведены сроки ожидания для проб TCP и HTTP/S:
- Длительность времени ожидания tcp-пробы: N/A (пробы завершаются сбоем после прохождения настроенного интервала пробы и отправки следующей пробы).
- Длительность времени ожидания пробы HTTP/S: 30 секунд
Для проб HTTP/S, если настроенный интервал превышает указанный выше период времени ожидания, время ожидания пробы работоспособности истекает и завершается ошибкой, если ответ не получен в течение периода ожидания. Например, если проба работоспособности HTTP настроена с интервалом пробы в 120 секунд (каждые 2 минуты), а ответ пробы не получен в течение первых 30 секунд, проба достигает времени ожидания и завершается сбоем. Если настроенный интервал меньше указанного периода времени ожидания, проба работоспособности завершится ошибкой, если ответ не получен до завершения заданного периода интервала, и следующая проба будет отправлена немедленно.
Пороговое значение пробы
Пороговое значение пробы — это число случаев, когда проба работоспособности должна последовательно завершиться успешно или сбоем, чтобы отметить экземпляр серверной части как работоспособный или неработоспособный соответственно.
Для tcp-проб, если порог пробы настроено на 2, проба должна получить 2 последовательных ответов, прежде чем серверный экземпляр начнет получать трафик. Аналогичным образом, как только бэкенд-экземпляр считается работоспособным, 2 последовательных сбоя или тайм-аута необходимы, чтобы экземпляр считался неработоспособным, и он перестаёт получать новый трафик.
Для тестирования HTTP явные ответы немедленно определяют статус пробы как работающий или неработающий для ответов с кодом 200 и других кодов, что приводит к эффективной перезагрузке порогового значения. Это означает, что пороговое значение применяется только к пробам HTTP, если проверка завершилась из-за отсутствия ответа.
Руководство по проектированию
Когда вы разрабатываете модель работоспособности для своего приложения, проверьте порт на серверной конечной точке, который отражает работоспособность этого экземпляра и службы приложения. Порт приложения и порт пробы не должны обязательно совпадать. В некоторых сценариях порт пробы может отличаться от порта, используемого приложением, но, как правило, рекомендуется использовать один и тот же порт.
Может быть полезно, если ваше приложение создаст ответ для пробы работоспособности и отправит сигнал подсистеме балансировки нагрузки о том, следует ли вашему экземпляру принимать новые подключения. Вы можете изменять ответ на проверку работоспособности, чтобы ограничить поступление новых подключений к экземпляру, заставив проверку работоспособности завершаться сбоем. Вы можете подготовить приложение к обслуживанию и инициировать постепенное закрытие подключений к нему. Сигнал о недоступности пробы всегда позволяет TCP-потокам оставаться активными до истечения времени ожидания простоя или закрытия соединения в стандартном балансировщике нагрузки.
Для приложения с балансировкой нагрузки UDP создайте настраиваемый сигнал пробы работоспособности из серверной конечной точки. Используйте TCP, HTTP или HTTPS для пробы работоспособности с учетом соответствующего прослушивателя.
Правила балансировки нагрузки для портов с высоким уровнем доступности с Load Balancer (цен. категория «Стандартный»). На всех портах выполняется балансировка нагрузки, а в одном ответе пробы работоспособности должно отражаться состояние всего экземпляра.
Не транслируйте и не проксируйте пробу работоспособности через экземпляр, который получает эту пробу, на другой экземпляр в вашей виртуальной сети. Эта конфигурация может привести к сбоям в вашем сценарии. Например: набор сторонних устройств развертывается в серверном пуле балансировщика нагрузки для масштабирования и обеспечения отказоустойчивости этих устройств. Проба работоспособности настроена на проверку порта, трафик которого стороннее устройство проксирует или перенаправляет на другие виртуальные машины, находящиеся за этим устройством. Если проверять тот же порт, который используется для перенаправления или проксирования запросов к другим виртуальным машинам за устройством, любой ответ на пробу от одной виртуальной машины приведёт к пометке устройства как недоступного. Такая конфигурация может привести к каскадному сбою приложения. Причиной может быть периодический сбой проверки работоспособности, из-за которого балансировщик нагрузки помечает экземпляр устройства как недоступный. Это действие может отключить приложение. Проверьте работоспособность самого модуля. Выбор пробы для определения сигнала работоспособности является важным аспектом для сценариев виртуальных сетевых модулей (NVA). Чтобы определить соответствующий сигнал работоспособности для таких сценариев, обратитесь к своему поставщику приложения.
Если на вашей виртуальной машине настроено несколько интерфейсов, нужно ответить на пробу в том интерфейсе, на который она поступила. Вам может потребоваться настроить трансляцию исходного сетевого адреса для этого адреса на виртуальной машине отдельно для каждого интерфейса.
Определение пробы не является обязательным или проверяется при использовании Azure PowerShell, Azure CLI, шаблонов или API. Тесты проверки проб выполняются только при использовании портал Azure.
Если проверка работоспособности колеблется, балансировщик нагрузки ждёт дольше, прежде чем снова пометить конечную точку серверной части как работоспособную. Это дополнительное время ожидания защищает пользователя и инфраструктуру и преднамеренно заложено в политику.
Убедитесь, что экземпляры виртуальных машин запущены. Для каждого запущенного экземпляра в серверном пуле проверка работоспособности проверяет доступность. Если экземпляр остановлен, он не будет проверяться до тех пор, пока он не будет запущен снова.
Не настраивайте свою виртуальную сеть с диапазоном IP-адресов, принадлежащим корпорации Майкрософт, который содержит адрес 168.63.129.16. Конфигурация конфликтует с IP-адресом проверки работоспособности, и из-за этого сценарий может завершиться с ошибкой.
Чтобы протестировать сбой проверки работоспособности или пометить отдельный экземпляр как недоступный, используйте группу безопасности сети, чтобы явно заблокировать проверку работоспособности. Создайте правило NSG для блокировки порта назначения или IP-адреса источника, чтобы смоделировать сбой проверки.
В отличие от правил балансировки нагрузки, правила NAT для входящего трафика не нуждаются в пробе работоспособности, подключенной к ней.
Не рекомендуется блокировать IP-адрес пробы работоспособности или порта Azure Load Balancer с помощью правил NSG. Это неподдерживаемый сценарий, который может привести к тому, что правила NSG будут применяться с задержкой, из-за чего проверки работоспособности будут неточно отражать доступность экземпляров серверной части.
Наблюдение
Load Balancer уровня "Стандартный" предоставляет в Azure Monitor сведения о состоянии проверки работоспособности для каждой конечной точки и каждой внутренней конечной точки. Другие службы Azure или партнерские приложения могут использовать эти метрики. Логи Azure Monitor не поддерживаются для Basic Load Balancer (отключён).
IP-адрес источника пробы
Чтобы проверка работоспособности Azure Load Balancer считала ваш экземпляр работоспособным, необходимо разрешить IP-адрес 168.63.129.16 в любых Azure группах безопасности сети и в политиках локального брандмауэра. Тег AzureLoadBalancer службы определяет этот исходный IP-адрес в группах безопасности сети и разрешает трафик пробы работоспособности по умолчанию. Более подробную информацию об IP-адресе можно найти здесь.
Если вы не разрешаете исходный IP-адрес пробы в политиках брандмауэра, проба работоспособности завершается ошибкой, так как не удается связаться с экземпляром. В свою очередь, Azure Load Balancer помечает ваш экземпляр как недоступный из-за сбоя проверки работоспособности. Эта неверная конфигурация может привести к сбою сценария приложения с балансировкой нагрузки. Все пробы работоспособности Подсистемы балансировки нагрузки IPv4 исходят из IP-адреса 168.63.129.16 в качестве источника. Пробы IPv6 используют локальный адрес ссылки (fe80::1234:5678:9abc) в качестве источника. Для azure Load Balancer с двумя стеками необходимо настроить группу безопасности сети для проверки работоспособности IPv6.
Ограничения
Пробы HTTPS не поддерживают взаимную проверку подлинности с помощью сертификата клиента.
HTTP-пробы не поддерживают использование имён хостов для внутренних серверов проб.
Включение меток времени TCP может привести к регулированию или другим проблемам с производительностью, что может привести к истечении времени ожидания проб работоспособности.
Датчики здоровья для Basic Load Balancer (сняты с эксплуатации) не поддерживаются с набором масштабов виртуальной машины.
Из соображений безопасности HTTP-пробы не поддерживают проверку на следующих портах: 19, 21, 25, 70, 110, 119, 143, 220, 993.