Share via

Confiabilidad en Azure Communications Gateway

  • Artículo

Azure Communications Gateway garantiza que el servicio sea confiable mediante mecanismos de redundancia de Azure y el comportamiento de reintento específico de SIP. La red debe cumplir requisitos específicos para garantizar la disponibilidad del servicio.

Modelo de redundancia de Azure Communications Gateway

Las implementaciones de Azure Communications Gateway de producción (también denominadas implementaciones estándar) constan de tres regiones independientes: una región de administración y dos regiones de servicio. Las implementaciones de laboratorio constan de una región de administración y una región de servicio.

En este artículo se describen los dos tipos de región diferentes y sus distintos modelos de redundancia. Abarca la confiabilidad regional con zonas de disponibilidad y confiabilidad entre regiones con recuperación ante desastres. Para obtener información general más detallada sobre la confiabilidad de Azure, consulte Confiabilidad de Azure.

Diagrama de dos regiones de servicio, una región de administración y dos sitios de operador.

Regiones de servicio

Las regiones de servicio contienen la infraestructura de voz y API utilizada para manejar el tráfico entre su red y los servicios de comunicaciones elegidos.

Las implementaciones de Azure Communications Gateway de producción tienen dos regiones de servicio que se implementan en modo activo-activo (tal como exigen los programas Operator Connect y Teams Phone Mobile). La conmutación por error rápida entre las regiones de servicio se proporciona en el nivel de infraestructura/IP y en el nivel de aplicación (SIP/RTP/HTTP).

Las regiones de servicio también contienen la infraestructura para la API de aprovisionamiento de Azure Communications Gateway.

Sugerencia

Las implementaciones de producción siempre deben tener dos regiones de servicio, incluso si una de las regiones de servicio elegidas está en una región única de Azure Geography (por ejemplo, Qatar). Si elige una Geografía Azure de una sola región, elija una segunda región Azure en una Geografía Azure diferente.

Las regiones de servicio son idénticas en funcionamiento y proporcionan resistencia a errores de zona y regionales. Cada región de servicio puede llevar el 100 % del tráfico mediante la instancia de Azure Communications Gateway. De este modo, los usuarios finales deberían poder seguir realizando y recibiendo llamadas correctamente durante cualquier tiempo de inactividad de la zona o región.

Las implementaciones de laboratorio tienen una región de servicio.

Requisitos de enrutamiento de llamadas

Azure Communications Gateway ofrece un modelo de redundancia de "rellamada correcta": las llamadas controladas por nodos del mismo nivel que fallan se terminan, pero las nuevas llamadas se enrutan a nodos del mismo nivel correctos. Este modelo refleja el modelo de redundancia proporcionado por Microsoft Teams.

Para las implementaciones de producción, esperamos que la red tenga dos sitios con redundancia geográfica. Cada sitio debe emparejarse con una región de Azure Communications Gateway. El modelo de redundancia se basa en la conectividad cruzada entre la red y las regiones del servicio Azure Communications Gateway.

Diagrama de dos sitios de operador y dos regiones de servicio. Ambas regiones de servicio se conectan a ambos sitios, con rutas primarias y secundarias.

Las implementaciones de laboratorio deben conectarse a un sitio de la red.

Cada región del servicio Azure Communications Gateway proporciona un registro SRV. Este registro contiene todos los elementos del mismo nivel SIP que proporcionan la funcionalidad SBC (para enrutar llamadas a servicios de comunicaciones) dentro de la región. Este registro SRV puede apuntar a cualquier dirección IP del intervalo IP /28 proporcionado por el equipo de incorporación.

Si la puerta de enlace de comunicaciones de Azure incluye el punto de control móvil (MCP), cada región de servicio proporciona un registro SRV adicional para MCP. Cada registro MCP por región contiene MCP dentro de la región en la prioridad superior y MCP en la otra región con una prioridad menor.

Cada sitio de la red debe:

  • Envíe tráfico a su región de servicio local de Azure Communications Gateway de forma predeterminada.
  • Localice los nodos del mismo nivel de Azure Communications Gateway dentro de una región mediante DNS SRV, como se indica en RFC 3263.
    • Realice una búsqueda de SRV de DNS en el nombre de dominio de la conexión de la región de servicio a la red mediante _sip._tls.<regional-FQDN-from-portal>. Reemplace <regional-FQDN-from-portal> por los FQDN por región de los campos Nombre de host de la página Información general del recurso en Azure Portal. Por ejemplo, si la implementación usa nombres de dominio commsgw.azure.com, busque _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com para la primera región.
    • Si la búsqueda SRV devuelve varios destinos, use el peso y la prioridad de cada destino para seleccionar un único destino.
  • Envíe nuevas llamadas a los elementos del mismo nivel de Azure Communications Gateway disponibles.
  • Puede recibir tráfico de cualquier dirección IP en cada uno de los intervalos IP asociados a la puerta de enlace de comunicaciones de Azure.

Cuando la red enruta las llamadas a los nodos SIP de Azure Communications Gateway para la función SBC, debe:

  • Use SIP OPTIONS (o una combinación de OPCIONES y tráfico SIP) para supervisar la disponibilidad de los nodos del mismo nivel SIP de Azure Communications Gateway.
  • Vuelva a intentar INVITEs que recibieron respuestas 408, respuestas 503 o 504 respuestas o no recibieron respuestas, redirigiéndolos a otros nodos del mismo nivel disponibles en el sitio local. Buscar en la otra región de servicio (definida por el registro SRV de la otra región) solo si se ha producido un error en todos los nodos del mismo nivel de la región de servicio local.
  • Nunca vuelva a intentar llamadas que reciban respuestas de error distintas de 408, 503 y 504.

Si la implementación de Azure Communications Gateway incluye el punto de control móvil (MCP) integrado, la red debe hacer lo siguiente para MCP:

  • Detectar cuándo el MCP de una región no está disponible, marcar los destinos del registro SRV de esa región como no disponibles y reintentar periódicamente para determinar cuándo la región vuelve a estar disponible. MCP no responde a SIP OPTIONS.
  • Maneje las respuestas 5xx de MCP de acuerdo con la política de su organización. Por ejemplo, podría reintentar la solicitud o permitir que la llamada continúe sin pasar por Azure Communications Gateway y llegar a Microsoft Phone System.

Los detalles de este comportamiento de enrutamiento son específicos de la red. Debe estar de acuerdo con el equipo de incorporación durante el proyecto de integración.

Regiones de administración

Las regiones de administración contienen la infraestructura utilizada para la ordenación, supervisión y facturación de Azure Communications Gateway. Toda la infraestructura dentro de estas regiones se implementa de forma con redundancia zonal, lo que significa que todos los datos se replican automáticamente en cada zona de disponibilidad dentro de la región. Todos los datos de configuración críticos también se replican en cada una de las regiones de servicio para garantizar el correcto funcionamiento del servicio durante un error en la región de Azure.

Compatibilidad de zonas de disponibilidad

Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.

Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.

Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Experiencia de reducción de zona para las regiones de servicio

Durante una interrupción en toda la zona, las llamadas gestionadas por la zona afectada se interrumpen, con una breve pérdida de capacidad dentro de la región hasta que la autorecuperación del servicio reequilibra los recursos subyacentes a las zonas sanas. Esta recuperación automática no depende de la restauración de zonas; se espera que el estado de recuperación automática del servicio administrado por Microsoft compensa una zona perdida, mediante la capacidad de otras zonas. El tráfico que lleva recursos se implementa de forma con redundancia de zona, pero un único recurso podría controlar el tráfico a menor escala. En este caso, los mecanismos de conmutación por error descritos en este artículo vuelven a equilibrar todo el tráfico a la otra región de servicio mientras los recursos que transportan el tráfico se vuelven a implementar en una zona correcta.

Experiencia de reducción de zona para la región de administración

Durante una interrupción de toda la zona, no se requiere ninguna acción con fines de recuperación de zona. La región de administración se recupera automáticamente y se reequilibrada para aprovechar automáticamente la zona correcta.

Recuperación ante desastres: reserva en otras regiones

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

En esta sección se describe el comportamiento de Azure Communications Gateway durante una interrupción en toda la región.

Recuperación ante desastres: conmutación por error entre regiones para las regiones de servicio

Durante una interrupción en toda la región, los mecanismos de conmutación por error descritos en este artículo (sondeo OPTIONS y reintento SIP en caso de error) reequilibran todo el tráfico de llamadas a la otra región del servicio, manteniendo la disponibilidad. Empezaremos a restaurar la redundancia regional. La restauración de la redundancia regional durante un tiempo de inactividad prolongado podría requerir el uso de otras regiones de Azure. Si necesitamos migrar una región con errores a otra región, le consultaremos antes de iniciar las migraciones.

La función SBC de Azure Communications Gateway proporciona sondeo OPTIONS para permitir que su red determine la disponibilidad de nodo del mismo nivel. Para MCP, la red debe ser capaz de detectar cuándo MCP no está disponible y reintentar periódicamente para determinar cuándo MCP está disponible de nuevo. MCP no responde a SIP OPTIONS.

Los clientes de la API de aprovisionamiento se ponen en contacto con Azure Communications Gateway utilizando el nombre de dominio base de su implementación. El registro DNS de este dominio tiene un período de vida (TTL) de 60 segundos. Cuando se produce un error en una región, Azure actualiza el registro DNS para hacer referencia a otra región, por lo que los clientes que realizan una nueva búsqueda DNS reciben los detalles de la nueva región. Recomendamos garantizar que los clientes puedan realizar una nueva búsqueda DNS y reintentar una solicitud 60 segundos después de un tiempo de espera o una respuesta 5xx.

Sugerencia

Las implementaciones de laboratorio no ofrecen conmutación por error entre regiones (porque solo tienen una región de servicio).

Recuperación ante desastres: conmutación por error entre regiones para regiones de administración

El tráfico de voz y el aprovisionamiento a través del portal de administración de números no se ven afectados por errores en la región de administración, ya que los recursos Azure correspondientes se hospedan en regiones de servicio. Es posible que los usuarios del Portal de administración de números deba iniciar sesión de nuevo.

Es posible que los servicios de supervisión no estén disponibles temporalmente hasta que se restaure el servicio. Si la región de administración experimenta un tiempo de inactividad prolongado, migraremos los recursos afectados a otra región disponible.

Elección de las regiones de administración y servicio

Una sola implementación de Azure Communications Gateway está diseñada para controlar el tráfico dentro de un área geográfica. Implemente ambas regiones de servicio en una implementación de producción dentro del mismo área geográfica (por ejemplo, Norteamérica). Este modelo garantiza que la latencia de las llamadas de voz se mantenga dentro de los límites exigidos por los programas Operator Connect y Teams Phone Mobile.

Tenga en cuenta los siguientes puntos al elegir las ubicaciones de la región de servicio:

  • Seleccione en la lista de regiones de Azure disponibles. Puede ver las regiones de Azure que se pueden seleccionar como regiones de servicio en la página Productos por región.
  • Elija regiones cercanas a sus propias instalaciones y las ubicaciones de emparejamiento entre su red y Microsoft para reducir la latencia de las llamadas.
  • Se prefieren pares regionales para minimizar el tiempo de recuperación si se produce una interrupción en varias regiones.

Elija una región de administración en la siguiente lista:

  • Este de EE. UU.
  • Centro-Oeste de EE. UU.
  • Oeste de Europa
  • Sur de Reino Unido
  • India central
  • Centro de Canadá
  • Este de Australia

Las regiones de administración se pueden colocar con regiones de servicio. Se recomienda elegir la región de administración más cercana a las regiones de servicio.

Nota:

Si habilita la versión preliminar de Protección de llamadas de operador de Azure, es posible que la región de servicio que seleccione no sea la región de Azure donde se implementan los recursos auxiliares. Consulte Productos de Azure por región para obtener la lista de regiones del servicio Protección de llamadas de operador de Azure compatibles actualmente y hable con el equipo de incorporación si tiene alguna pregunta sobre qué región está seleccionada.

Contratos de nivel de servicio

El diseño de confiabilidad descrito en este documento es implementado por Microsoft y no es configurable. Para más información sobre los acuerdos de nivel de servicio (SLA) de Azure Communications Gateway, consulte el Acuerdo de Nivel de Servicio de Azure Communications Gateway.

Pasos siguientes