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

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

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

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

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

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

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

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

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

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

Подсказка

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

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

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

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

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

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

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

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

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

Если шлюз коммуникаций 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> на полные доменные имена регионов из полей Hostname на странице Обзор для вашего ресурса в портале Azure. Например, если развертывание использует commsgw.azure.com доменные имена, найдите _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com для первого региона.
    • Если поиск SRV возвращает несколько целевых объектов, используйте вес и приоритет каждого целевого объекта, чтобы выбрать один целевой объект.
  • Отправьте новые вызовы доступным одноранговым узлам шлюза коммуникации Azure.
  • Вы можете получать трафик из любого IP-адреса в каждом из диапазонов IP-адресов, связанных с шлюзом коммуникаций Azure.

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

  • Используйте SIP OPTIONS (или их комбинацию с SIP трафиком) для мониторинга доступности одноранговых узлов SIP в шлюзе связи Azure.
  • Повторите действия INVITEs, которые получили 408 ответов, 503 или 504 ответа или не получили ответы, перенаправляя их на другие доступные одноранговые узлы на локальном сайте. Перенаправление в другой регион службы (определяемый записью SRV другого региона) происходит только в случае отказа всех одноранговых узлов в локальном регионе службы.
  • Никогда не повторяйте вызовы, которые получают ответы об ошибке, отличные от 408, 503 и 504.

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

  • Определите, когда MCP в регионе недоступен, помечайте целевые объекты для записи SRV этого региона как недоступные и периодически повторяйте проверку, чтобы определить, когда регион доступен снова. MCP не отвечает на ПАРАМЕТРЫ SIP.
  • Обрабатывайте ответы 5xx от MCP в соответствии с политикой вашей организации. Например, можно повторить запрос или разрешить звонок продолжаться без передачи через шлюз коммуникации 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, чтобы уменьшить латентность.
  • Предпочитайте региональные пары , чтобы свести к минимуму время восстановления, если происходит сбой в нескольких регионах.

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

  • East US
  • центрально-западная часть США
  • West Europe
  • UK South
  • Центральная Индия
  • Canada Central
  • Australia East

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

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

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

Дальнейшие шаги

  • Last updated on