Надежность шлюза коммуникаций Azure

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

Модель избыточности шлюза коммуникаций Azure

Развертывания шлюза коммуникаций Azure (также называемые стандартными развертываниями) состоят из трех отдельных регионов: региона управления и двух регионов службы. Развертывания лабораторий состоят из одного региона управления и одного региона службы.

В этой статье описываются два различных типа регионов и их различные модели избыточности. Она охватывает как региональную надежность с зонами доступности, так и надежностью между регионами при аварийном восстановлении. Более подробный обзор надежности в Azure см. в статье "Надежность Azure".

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

Регионы служб

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

В рабочих развертываниях шлюза коммуникаций Azure есть два региона службы, которые развертываются в активном-активном режиме (в соответствии с требованиями программы Operator Connect и Teams Phone Mobile). Быстрое переключение на резервный ресурс между регионами службы предоставляется на уровне инфраструктуры/IP и на уровне приложения (SIP/RTP/HTTP).

Регионы обслуживания также содержат инфраструктуру для API управления шлюзом коммуникаций Azure.

Совет

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

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

Развертывания лабораторий имеют всего один регион обслуживания.

Требования к маршрутизации вызовов

Шлюз коммуникаций Azure предлагает модель избыточности "успешного повторного набора": вызовы, обрабатываемые одноранговыми узлами в случае сбоя, завершаются, но новые вызовы переносатся на исправно работающие одноранговые узлы. Эта модель отражает модель избыточности, предоставляемую Microsoft Teams.

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

Схема двух сайтов операторов (сайт оператора A и сайт оператора B) и два региона службы (регион службы А и регион службы B). Сайт оператора A имеет основной маршрут к региону обслуживания А и вторичный маршрут к региону обслуживания B. Сайт оператора B имеет основной маршрут к региону обслуживания B и вторичному маршруту в регион обслуживания A.

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

Каждый регион службы шлюза коммуникации Azure предоставляет запись SRV. Эта запись содержит все одноранговые узлы SIP, предоставляющие функции SBC (для маршрутизации вызовов служб коммуникации) в регионе. Эта запись SRV может указывать на любой IP-адрес в диапазоне IP-адресов /28, предоставленном командой по внедрению.

Если шлюз коммуникаций Azure включает в себя мобильную точку управления (MCP), каждый регион службы предоставляет дополнительную запись SRV для MCP. Каждая запись MCP в каждом регионе содержит MCP в регионе с высоким приоритетом и MCP в другом регионе с более низким приоритетом.

Каждый сайт в сети должен:

• По умолчанию отправьте трафик в локальный регион службы шлюза коммуникации Azure.
• Найдите одноранговые узлы шлюза коммуникации Azure в регионе с помощью DNS SRV, как описано в RFC 3263.
  • Выполните поиск DNS SRV в доменном имени для подключения региона службы к сети с помощью _sip._tls.<regional-FQDN-from-portal>. Замените <regional-FQDN-from-portal> на FQDN для каждого региона из полей имени узла на странице обзора вашего ресурса в портале Azure. Например, если развертывание использует commsgw.azure.com доменные имена, найдите _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com для первого региона.
  • Если поиск SRV возвращает несколько целевых объектов, используйте вес и приоритет каждого целевого объекта, чтобы выбрать один целевой объект.
• Отправьте новые вызовы доступным одноранговым узлам шлюза коммуникации Azure.
• Вы можете получать трафик из любого IP-адреса в каждом из диапазонов IP-адресов, связанных с шлюзом коммуникаций Azure.

Когда ваша сеть маршрутизирует вызовы к одноранговым узлам SIP коммуникационного шлюза Azure для функции SBC, они должны:

• Используйте ПАРАМЕТРЫ SIP (или сочетание ПАРАМЕТРОВ и ТРАФИКА SIP) для мониторинга доступности SIP-пиров шлюза связи Azure.
• Повторите запросы INVITEs, которые получили 408 ответов, 503 или 504 ответов или не получили ответов, путем перенаправления на другие доступные одноранговые узлы на локальном сайте. Перенаправление на другой регион службы (определенный записью SRV другого региона) только если все одноранговые узлы в локальном регионе службы вышли из строя.
• Никогда не повторяйте вызовы, которые получают ответы об ошибке, отличные от 408, 503 и 504.

Если развертывание шлюза коммуникации Azure включает интегрированную мобильную точку управления (MCP), сеть должна выполнять следующие действия для MCP:

• Обнаружьте, когда MCP в регионе недоступен, отмечайте целевые объекты для записи SRV этого региона как недоступные и периодически повторяйте, чтобы определить, когда регион снова доступен. MCP не отвечает на ПАРАМЕТРЫ SIP.
• Обрабатывайте ответы 5xx от MCP в соответствии с политикой вашей организации. Например, можно повторить запрос или разрешить вызов продолжаться без передачи через шлюз коммуникации Azure и в систему Телефон (Майкрософт).

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

Регионы управления

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

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

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

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

Опыт работы в режиме снижения для регионов обслуживания

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

Снижение уровня функциональности для региона управления

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

Аварийное восстановление: возврат к другим регионам

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

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

В этом разделе описывается поведение шлюза коммуникаций Azure во время сбоя на уровне региона.

Аварийное восстановление: переключение на резервный регион для регионов услуг

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

Функция SBC в шлюзе коммуникаций Azure предоставляет опрос OPTIONS, который позволяет вашей сети определять доступность узлов-партнёров. Для MCP ваша сеть должна иметь возможность обнаруживать, когда MCP недоступна, и периодически пытаться определить, когда MCP будет доступна снова. MCP не отвечает на ПАРАМЕТРЫ SIP.

Клиенты API обращаются к шлюзу коммуникаций Azure, используя базовое доменное имя вашего развертывания. Запись DNS для этого домена имеет время жизни (TTL) в 60 секунд. Когда в регионе происходит сбой, Azure обновляет запись DNS, чтобы ориентировать на другой регион, таким образом, клиенты, выполняющие новый запрос DNS, получают сведения о новом регионе. Мы рекомендуем убедиться, что клиенты могут выполнять новый поиск DNS и повторить запрос через 60 секунд после истечения времени ожидания или ответа 5xxx.

Совет

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

Аварийное восстановление: переключение между регионами для управляемых регионов

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

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

Выбор регионов управления и служб

Единое развертывание шлюза коммуникации Azure предназначено для обработки трафика в географической области. Разверните оба региона службы в рабочей среде в одной географической области (например, Северная Америка). Эта модель гарантирует, что задержка в голосовых звонках остается в пределах ограничений, необходимых программам Оператора Connect и Teams Phone Mobile.

При выборе расположений региона службы следует учитывать следующие моменты:

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

Выберите регион управления из следующего списка:

• Восточная часть США
• центрально-западная часть США
• Западная Европа
• южная часть Соединенного Королевства
• Центральная Индия
• Центральная Канада
• Восточная Австралия

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

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

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

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

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