Share via

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

  • Статья

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

Каждый регион службы шлюза коммуникации 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> полное доменное имя для каждого региона из полей имени узла на странице обзора ресурса в портал 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. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.

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

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

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

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

Взаимодействие с зонами вниз для региона управления

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

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

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

Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе 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 предназначено для обработки трафика в географической области. Разверните оба региона службы в рабочей среде в одной географической области (например, Северная Америка). Эта модель гарантирует, что задержка в голосовых звонках остается в пределах ограничений, необходимых операторам Подключение и программам Teams Телефон Mobile.

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

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

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

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

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

Примечание.

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

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

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

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