Надежность в Azure Load Balancer

Azure Load Balancer — это служба балансировки нагрузки уровня 4 для протокола TCP и трафика протокола UDP, который распределяет входящие запросы между здоровыми экземплярами служб. Load Balancer обеспечивает высокую доступность и производительность сети с низкой задержкой.

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

В этой статье описывается, как обеспечить устойчивость Load Balancer к различным потенциальным сбоям и проблемам, в том числе временным сбоям, сбоям зоны доступности и сбоям регионов. Он также выделяет ключевые сведения о соглашении об уровне обслуживания Load Balancer (SLA).

Рекомендации по развертыванию в производственной среде

Платформа Azure Well-Architected Framework предоставляет рекомендации по надежности, безопасности, затратам, операциям и производительности. Чтобы узнать, как эти области влияют друг на друга и способствуют надежному решению Load Balancer, ознакомьтесь с рекомендациями по архитектуре для Load Balancer.

Обзор архитектуры надежности

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

Каждая подсистема балансировки нагрузки состоит из нескольких компонентов:

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

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

• Правила балансировки нагрузки , определяющие, как подсистема балансировки нагрузки распределяет трафик из внешнего интерфейса в внутренний пул.

• Пробы работоспособности, отслеживающие доступность серверных экземпляров.

Дополнительные сведения см. в разделе "Компоненты Load Balancer".

Для глобально развернутых решений можно развернуть глобальную подсистему балансировки нагрузки, которая является уникальным типом общедоступной подсистемы балансировки нагрузки для маршрутизации трафика между различными региональными развертываниями решения. Глобальный балансировщик нагрузки предоставляет один anycast IP-адрес и направляет трафик к ближайшему рабочему региональному балансировщику нагрузки на основе близости клиента и региональной работоспособности. Дополнительные сведения см. в разделе "Устойчивость к сбоям на уровне региона".

Устойчивость к временным сбоям

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

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

При использовании Load Balancer рассмотрите следующие рекомендации, чтобы свести к минимуму риск временных сбоев, влияющих на приложение:

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

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

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

Устойчивость к сбоям зоны доступности

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

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

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

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

В регионах без зон доступности Azure создает все подсистемы балансировки нагрузки в незональнойили региональной конфигурации с помощью интерфейсной конфигурации без настройки зоны. Если в регионе возникает сбой, могут возникнуть простои незональных подсистем балансировки нагрузки.

Серверные экземпляры и зоны доступности

Конфигурация зоны доступности внутренних экземпляров работает независимо от конфигурации внешнего IP-адреса подсистемы балансировки нагрузки.

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

Например, при использовании виртуальных машин распространенный подход к проектированию рабочих нагрузок — размещение нескольких зональных виртуальных машин в зонах 1, 2 и 3 для обеспечения устойчивости зоны. Для балансировки нагрузки можно создать подсистему балансировки нагрузки, избыточной между зонами, и настроить эти виртуальные машины в качестве внутренних экземпляров в подсистеме балансировки нагрузки. Проверки работоспособности балансировщика нагрузки автоматически удаляют неработоспособные виртуальные машины из распределения нагрузки, независимо от зоны их размещения.

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

Требования

Поддержка региона: Зонально-избыточные подсистемы балансировки нагрузки можно развернуть в любом регионе, поддерживающем зоны доступности.

Себестоимость

Конфигурация зоны доступности не изменяет способ выставления счетов за подсистему балансировки нагрузки Azure. Azure основывает выставление счетов по количеству настроенных правил и данных, которые он обрабатывает, независимо от конфигурации зоны. Дополнительные сведения см. в статье Цены на Load Balancer.

Настройка поддержки зоны доступности

При использовании Load Balancer вы устанавливаете поддержку зоны доступности в конфигурации внешнего IP-адреса.

• Создайте подсистему балансировки нагрузки с поддержкой зоны доступности.

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

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

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

  1. Создайте новую интерфейсную IP-конфигурацию с требуемой конфигурацией зоны доступности.

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

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

  2. Перенастройьте правила балансировки нагрузки, чтобы использовать новую интерфейсную IP-конфигурацию.

     Это важно

     Эта операция требует перенастройки клиентов для отправки трафика на новый внешний IP-адрес. В зависимости от клиентов процесс может потребовать простоя.

  3. Удалите старую конфигурацию внешнего IP-адреса.

Поведение, когда все зоны работоспособны

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

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

• Репликация данных между зонами: Load Balancer работает как сетевая сквозная служба, которая не хранит или реплицирует данные приложения. Даже если вы настроили сохраняемость сеанса в подсистеме балансировки нагрузки, подсистема балансировки нагрузки не сохраняет состояние. Сохраняемость сеансов настраивает процесс хэширования для маршрутизации запросов в тот же внутренний экземпляр, но подсистема балансировки нагрузки не гарантирует сохраняемость сеансов. Когда серверный пул изменяется, подсистема балансировки нагрузки перекомпьютирует распределение клиентских запросов и не сохраняет или не синхронизирует состояние.

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

Поведение во время сбоя зоны

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

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

• Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

• Активные запросы: При сбое зоны все существующие потоки TCP и UDP в зоне автоматически сбрасываются, и клиенты должны повторно установить эти потоки. Клиенты должны реализовать достаточную временную обработку ошибок, включая автоматизированные повторные попытки.

• Ожидаемая потеря данных: Load Balancer — это сетевая служба без отслеживания состояния, поэтому она не хранит данные приложения и не теряет данные на уровне подсистемы балансировки нагрузки.

• Ожидаемое время простоя: Время простоя не ожидается для зонально избыточных балансировщиков нагрузки, так как балансировщик продолжает работать в здоровых зонах.

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

• Перенаправка трафика: Подсистема балансировки нагрузки продолжает работать из работоспособных зон. Балансировщик нагрузки поддерживает тот же фронтальный IP-адрес во время сбоев зоны. Это означает, что вам не нужно применять обновления системы доменных имен (DNS) или перенастройки клиентов. Платформа Azure устанавливает новые клиентские подключения через оставшиеся здоровые зоны.

Восстановление зоны

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

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

Тестирование на сбои в зоне

Платформа Azure управляет маршрутизацией трафика, ответом на отказ зоны и восстановлением, поэтому вам не нужно запускать или проверять процессы отказа зоны доступности.

Azure Chaos Studio можно использовать для имитации сбоя виртуальной машины в одной зоне. Chaos Studio предоставляет встроенные ошибки для виртуальных машин, включая ошибку, которая завершает работу виртуальной машины. Эти возможности можно использовать для имитации сбоев зоны и тестирования процессов аварийного переключения.

Устойчивость к сбоям на уровне региона

Общедоступные и внутренние подсистемы балансировки нагрузки развертываются в одном регионе Azure. Если регион становится недоступным, подсистемы балансировки нагрузки в этом регионе также становятся недоступными. Load Balancer обеспечивает встроенную поддержку нескольких регионов через глобальную подсистему балансировки нагрузки, которая поддерживает балансировку нагрузки между регионами Azure. Вы также можете развернуть другие службы балансировки нагрузки для маршрутизации и автоматического переключения между регионами Azure.

Глобальные подсистемы балансировки нагрузки

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

При использовании глобальных подсистем балансировки нагрузки вы развертываете несколько общедоступных подсистем балансировки нагрузки в разных регионах, а глобальная подсистема балансировки нагрузки служит глобальным интерфейсом. Если серверы бэкэнда в одном регионе имеют проблему, трафик автоматически переключается на рабочие регионы без изменений DNS, так как IP-адрес anycast остается постоянным и направляет трафик в другой работающий регион.

Дополнительные сведения см. в статье "Глобальная подсистема балансировки нагрузки".

Индивидуальные решения для нескольких регионов для повышения устойчивости

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

Соглашение об уровне обслуживания

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

Соглашение об уровне обслуживания Load Balancer применяется, если у вас есть по крайней мере две работоспособные виртуальные машины, настроенные как внутренние экземпляры. Соглашение об уровне обслуживания исключает простой из-за нехватки портов SNAT или групп безопасности сети (NSG), которые блокируют трафик.

Связанный контент

• Документация по Load Balancer
• Обзор надежности Azure