Compartir a través de

Confiabilidad en Azure Communications Gateway

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 que se usa para controlar el tráfico entre la red y los servicios de comunicaciones elegidos.

Las implementaciones de producción de Azure Communications Gateway tienen dos regiones de servicio que se implementan en modo activo-activo, tal como lo requieren los programas Operator Connect y Teams Phone Mobile. El cambio rápido entre las regiones de servicio se proporciona a nivel de infraestructura/IP y a nivel de aplicación (SIP/RTP/HTTP).

Las regiones de servicio también contienen la infraestructura de 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 región única de Azure Geography, elija una segunda región de Azure en otra ubicación geográfica de Azure.

Las regiones de servicio son idénticas en funcionamiento y proporcionan resistencia a errores regionales y de zona. Cada región de servicio puede llevar 100% del tráfico mediante la instancia de Azure Communications Gateway. Por lo tanto, los usuarios finales todavía deben poder realizar y recibir llamadas correctamente durante cualquier tiempo de inactividad de zona o regional.

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

Requisitos de enrutamiento de llamadas

Azure Communications Gateway ofrece un modelo de redundancia por reintento exitoso: las llamadas gestionadas por pares con errores son terminadas, pero las nuevas llamadas se enrutan a pares operativos. Este modelo refleja el modelo de redundancia proporcionado por Microsoft Teams.

En el caso de 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 su 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 rango /28 proporcionado por el equipo de integració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 el MCP dentro de la región con la máxima prioridad y el 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 pares de Azure Communications Gateway dentro de una región mediante DNS SRV, como se describe en RFC 3263.
    • Realice una búsqueda DNS SRV en el nombre de dominio para la conexión de la región de servicio a su red mediante _sip._tls.<regional-FQDN-from-portal>. Reemplace por <regional-FQDN-from-portal> 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 commsgw.azure.com nombres de dominio, busque en _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com 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 pares disponibles de Azure Communications Gateway.
  • 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 pares 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 pares SIP de Azure Communications Gateway.
  • Vuelva a intentar las invites que recibieron 408 respuestas, 503 o 504 o que no recibieron respuestas, reenviéndolos a otros elementos del mismo nivel disponibles en el sitio local. Busque en la otra región de servicio (definida por el registro SRV de la otra región) solo si han fallado todos los pares en 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 integrado (MCP), la red debe hacer lo siguiente para MCP:

  • Detecte cuándo MCP de una región no está disponible, marque los destinos del registro SRV de esa región como no disponibles y vuelva a intentarlo periódicamente para determinar cuándo la región está disponible nuevamente. MCP no responde a las opciones SIP.
  • Gestione las respuestas 5xx de MCP según la directiva de su organización. Por ejemplo, podría volver a intentar la solicitud, o bien podría permitir que la llamada continúe sin pasar a través de Azure Communications Gateway y al sistema telefónico de Microsoft.

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

Regiones de administración

Las regiones de administración contienen la infraestructura que se usa 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.

Soporte para zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de cada región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

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

Durante una interrupción en toda la zona, se finalizan las llamadas gestionadas por la zona afectada, con una breve pérdida de capacidad dentro de la región hasta que el equilibrio automático del servicio reequilibra los recursos subyacentes en zonas saludables. 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 compense una zona perdida, mediante la capacidad de otras zonas. Los recursos que transportan tráfico se implementan de manera redundante en zonas, pero, al menor nivel, el tráfico podría ser manejado por un único recurso. En este caso, los mecanismos de conmutación 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 saludable.

Experiencia de reducción de zona en la región de gestió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 auto-recupera y se reequilibra automáticamente para aprovechar la zona saludable.

Recuperación de desastres: respaldo a otras regiones

La recuperación ante desastres (DR) hace referencia a las prácticas que las organizaciones usan para recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores que producen 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 crear el plan de recuperación ante desastres, consulte Recomendaciones para diseñar una estrategia de recuperación ante desastres.

Para la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En este modelo, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Sin embargo, muchos servicios de Azure no replican automáticamente datos ni se revierten de una región con errores para realizar la replicación cruzada en otra región habilitada. En esos servicios, es responsable de configurar un plan de recuperación ante desastres válido para su 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. Puede usar características específicas del servicio para admitir la recuperación rápida con el fin de contribuir al desarrollo del 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, tal como se explican en este artículo (sondeo de opciones y reintento de SIP en caso de fallo), restablecen el equilibrio de todo el tráfico de llamadas hacia 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 que ha fallado a otra región, le consultaremos antes de iniciar cualquier migración.

La función SBC de Azure Communications Gateway proporciona sondeo OPTIONS para permitir que su red determine la disponibilidad del nodo par. 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 OPCIONES SIP.

Los clientes de API de aprovisionamiento se conectan a Azure Communications Gateway utilizando el 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. Se recomienda asegurarse de 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 la conmutación por error entre regiones, ya que solo disponen de una única 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 de Azure correspondientes se hospedan en regiones de servicio. Es posible que los usuarios del Portal de Gestión de Números deban 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 asegura que la latencia en las llamadas de voz se mantenga dentro de los límites requeridos por los programas Operator Connect y Teléfono Móvil de Teams.

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 la 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 lista siguiente:

  • East US
  • Centro-oeste de EE. UU.
  • West Europe
  • UK South
  • India central
  • Canada Central
  • Australia East

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.

Contratos de nivel de servicio

Microsoft implementa el diseño de confiabilidad descrito en este documento 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

  • Last updated on