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

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

Общие сведения об архитектуре надежности в Azure см. в статье "Надежность Azure".

Рекомендации по надежности

В этом разделе содержатся рекомендации по обеспечению устойчивости и доступности. Каждая рекомендация входит в одну из двух категорий:

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

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

Матрица приоритетов рекомендаций по надежности

Каждая рекомендация помечается в соответствии со следующей матрицей приоритетов:

Изображения	Приоритет	Описание
	Высокая	Необходимо немедленное исправление.
	Средняя	Исправление в течение 3–6 месяцев.
	Низкая	Необходимо проверить.

Сводка рекомендаций по надежности

Категория	Приоритет	Рекомендация
Доступность		Убедитесь, что Load Balancer (цен. категория является избыточной между зонами
		Убедитесь, что серверный пул содержит по крайней мере два экземпляра
Эффективность системы		Использование шлюза NAT вместо правил исходящего трафика для рабочих нагрузок
		Использование номера SKU Load Balancer (цен. категория

Доступность

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

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

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

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

Разверните Load Balancer по крайней мере с двумя экземплярами в серверной части. Один экземпляр может привести к возникновению единой точки отказа. Чтобы выполнить сборку для масштабирования, может потребоваться связать подсистему балансировки нагрузки с Масштабируемые наборы виртуальных машин.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Эффективность системы

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

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

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Использование номера SKU Load Balancer (цен. категория

Load Balancer уровня "Стандартный" поддерживает зоны доступности и устойчивость зоны, а номер SKU "Базовый" не поддерживается. При снижении зоны Load Balancer (цен. категория , избыточной между зонами, не будет влиять и развертывания могут противостоять сбоям зоны в пределах региона. Кроме того, Load Balancer (цен. категория поддерживает балансировку нагрузки между регионами, чтобы гарантировать, что приложение не влияет на сбои регионов.

Примечание.

Базовые подсистемы балансировки нагрузки не имеют соглашения об уровне обслуживания (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

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

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

Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".

Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.

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 не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе 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 в кросс-регионе Load Balancer, работает независимо от плавающих IP-конфигураций на внутренних региональных подсистемах балансировки нагрузки. Если плавающий IP-адрес включен в подсистеме балансировки нагрузки между регионами, необходимо добавить соответствующий интерфейс обратного цикла на внутренние виртуальные машины.

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

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

Создание решения в разных регионах на существующих Azure Load Balancer

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

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

Домашний регион — это место, где развернута подсистема балансировки нагрузки между регионами или находится общедоступный 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.