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

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

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

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

Примечание.

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

Необходимые компоненты

• Чтобы использовать зоны доступности с Load Balancer, необходимо создать подсистему балансировки нагрузки в регионе, поддерживающем зоны доступности. Сведения о том, какие регионы поддерживают зоны доступности, см. в списке поддерживаемых регионов.

• Используйте стандартный номер SKU для подсистемы балансировки нагрузки и общедоступного IP-адреса для поддержки зон доступности.

• Базовый тип SKU не поддерживается.

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

Ограничения

• После создания ресурса нельзя изменить его зоны или добавить для него другие зоны,
• а также изменить его тип с "Зональный" на "Избыточный между зонами".

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

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

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

Примечание.

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

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

Зональный балансировщик нагрузки

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

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

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

При использовании интерфейса внутренней подсистемы балансировки нагрузки добавьте параметр zones в интерфейсную IP-конфигурацию внутренней подсистемы балансировки нагрузки. Зональный интерфейс гарантирует IP-адрес в подсети для конкретной зоны.

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

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

Примечание.

Все общедоступные IP-адреса, обновляемые с номера SKU уровня "Базовый" до номера SKU "Стандартный", будут иметь тип "no-zone". Узнайте, как обновить общедоступный IP-адрес в портал Azure.

Улучшения обслуживания

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

Создание ресурса с включенной зоной доступности

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

Примечание.

• После создания ресурса нельзя изменить его зоны или добавить для него другие зоны,
• а также изменить его тип с "Зональный" на "Избыточный между зонами".

Отказоустойчивость

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

Дополнительные сведения см. в процессах восстановления сайта.

Взаимодействие с зонами вниз

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

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

Просмотрите статью Конструктивные шаблоны облачных решений, чтобы повысить устойчивость приложения к сценариям сбоя.

Несколько внешних интерфейсов

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

Методы безопасного развертывания

Просмотрите статью Конструктивные шаблоны облачных решений, чтобы повысить устойчивость приложения к сценариям сбоя.

Поддержка перехода на зоны доступности

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

Глобальное аварийное восстановление и непрерывность бизнес-процессов

Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.

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

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

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

Интерфейсная IP-конфигурация глобальной подсистемы балансировки нагрузки является статической и объявленной в большинстве регионов Azure.

Примечание.

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

Аварийное восстановление в географическом регионе с несколькими регионами

Региональная избыточность

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

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

Проверка работоспособности глобальной подсистемы балансировки нагрузки собирает сведения о доступности каждой региональной подсистемы балансировки нагрузки каждые 5 секунд. Если одна региональная подсистема балансировки нагрузки снижает доступность до 0, глобальная подсистема балансировки нагрузки обнаруживает сбой. Затем региональная подсистема балансировки нагрузки извлекается из обращения.

Сверхнизкая задержка

Алгоритм балансировки нагрузки с использованием географического расположения основан на географическом расположении ваших пользователей и ваших региональных развертываний.

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

Например, у вас есть глобальная подсистема балансировки нагрузки со стандартными подсистемами балансировки нагрузки в регионах Azure:

• западная часть США
• Северная Европа

Если поток исходит из Сиэтла, трафик переходит в западную часть США. Этот регион является ближайшим к Сиэтлу участвующим регионом. Трафик направляется в ближайшую подсистему балансировки нагрузки, которая находится в западной части США.

Глобальная подсистема балансировки нагрузки Azure использует алгоритм балансировки нагрузки географического взаимодействия для решения о маршрутизации.

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

Дополнительные сведения см. в разделе Настройка режима распределения для Azure Load Balancer.

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

Возможность вертикального увеличения масштаба за одной конечной точкой

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

Статический глобальный IP-адрес с произвольной адресацией

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

Сохранение клиентского IP-адреса

Глобальная подсистема балансировки нагрузки — это сквозная сетевая подсистема балансировки нагрузки уровня 4. При такой сквозной балансировке исходный IP-адрес пакета сохраняется. Исходный IP-адрес доступен для кода, выполняющегося на виртуальной машине. Такое сохранение позволяет применять логику, направленную на IP-адрес.

Плавающий IP-адрес

Плавающий IP-адрес можно настроить как на глобальном уровне, так и на уровне регионального IP-адреса. Дополнительные сведения см. в разделе "Несколько интерфейсов" для Azure Load Balancer

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

Пробы работоспособности

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

Создание глобального решения в существующей Подсистеме балансировки нагрузки Azure

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

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

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

Домашние регионы

• Центральная часть США
• Восточная Азия
• Восточная часть США 2
• Северная Европа
• Юго-Восточная Азия
• южная часть Соединенного Королевства
• US Gov (Вирджиния)
• Западная Европа
• западная часть США

Примечание.

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

В регионе-участнике объявляется глобальный общедоступный IP-адрес подсистемы балансировки нагрузки.

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

Глобальная подсистема балансировки нагрузки направляет трафик в соответствующую региональную подсистему балансировки нагрузки.

Участвующие регионы

• Восточная Австралия
• Юго-Восточная часть Австралии
• Центральная Индия
• Центральная часть США
• Восточная Азия
• Восточная часть США
• Восточная часть США 2
• Восточная Япония
• Центрально-северная часть США
• Северная Европа
• Центрально-южная часть США
• Юго-Восточная Азия
• южная часть Соединенного Королевства
• Центральный регион US DoD
• Восточный регион US DoD
• US Gov (Аризона)
• US Gov (Техас)
• US Gov (Вирджиния)
• центрально-западная часть США
• Западная Европа
• западная часть США
• Западная часть США 2

Примечание.

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

Ограничения

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

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

• Перевод NAT64 в настоящее время не поддерживается. Интерфейсные и внутренние IP-адреса должны иметь одинаковый тип (версия 4 или v6).

• Трафик UDP не поддерживается в глобальной подсистеме балансировки нагрузки для IPv6.

• Трафик UDP через порт 3 не поддерживается в глобальной подсистеме балансировки нагрузки

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

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

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

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

• Надежность в Azure
• См. руководство. Создание глобальной подсистемы балансировки нагрузки с помощью портал Azure для создания глобальной подсистемы балансировки нагрузки.
• Дополнительные сведения о глобальной подсистеме балансировки нагрузки см. в этом видео.
• Дополнительные сведения об Azure Load Balancer.