Partager via

Fiabilité dans Azure Communications Gateway

Azure Communications Gateway garantit que votre service est fiable à l’aide de mécanismes de redondance Azure et du comportement de nouvelle tentative spécifique à SIP. Votre réseau doit répondre à des exigences spécifiques pour garantir la disponibilité du service.

Modèle de redondance d’Azure Communications Gateway

Les déploiements azure Communications Gateway de production (également appelés déploiements standard) se composent de trois régions distinctes : une région de gestion et deux régions de service. Les déploiements de laboratoires se composent d’une région de gestion et d’une région de service.

Cet article décrit les deux types de région différents et leurs modèles de redondance distincts. Il couvre à la fois la fiabilité régionale avec les zones de disponibilité et la fiabilité interrégion avec la reprise d’activité après sinistre. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.

Diagramme de deux régions de service, d’une région de gestion et de deux sites d’opérateur.

Régions de service

Les régions de service contiennent l’infrastructure de voix et d’API utilisée pour gérer le trafic entre votre réseau et vos services de communication choisis.

Les déploiements Azure Communications Gateway de production comportent deux régions de service déployées en mode actif-actif (comme requis par les programmes Operator Connect et Teams Phone Mobile). Le basculement rapide entre les régions de service est fourni au niveau de l’infrastructure/IP et au niveau de l’application (SIP/RTP/HTTP).

Les régions de service contiennent également l’infrastructure de l’API d’approvisionnement d’Azure Communications Gateway.

Conseil / Astuce

Les déploiements de production doivent toujours avoir deux régions de service, même si l’une des régions de service choisies se trouve dans une zone géographique Azure à une seule région (par exemple, Qatar). Si vous choisissez une Géographie Azure à une seule région, choisissez une deuxième région Azure dans une autre Géographie Azure.

Les régions de service sont identiques en fonctionnement et fournissent une résilience aux défaillances zone et régionale. Chaque région de service peut transporter 100% du trafic à l’aide de l’instance Azure Communications Gateway. Par conséquent, les utilisateurs finaux doivent toujours être en mesure d’effectuer et de recevoir des appels correctement pendant tout temps d’arrêt de zone ou régional.

Les déploiements de laboratoire ont une région de service.

Configuration requise pour le routage des appels

Azure Communications Gateway offre un modèle de redondance « redial » réussi : les appels gérés par des homologues défaillants sont arrêtés, mais de nouveaux appels sont routés vers des homologues intègres. Ce modèle met en miroir le modèle de redondance fourni par Microsoft Teams.

Pour les déploiements de production, nous prévoyons que votre réseau dispose de deux sites géographiquement redondants. Chaque site doit être associé à une région Azure Communications Gateway. Le modèle de redondance s’appuie sur la connectivité croisée entre votre réseau et les régions de service Azure Communications Gateway.

Diagramme de deux sites d’opérateur et de deux régions de service. Les deux régions de service se connectent aux deux sites, avec des itinéraires principaux et secondaires.

Les déploiements de laboratoire doivent se connecter à un site de votre réseau.

Chaque région de service Azure Communications Gateway fournit un enregistrement SRV. Cet enregistrement contient tous les homologues SIP fournissant des fonctionnalités SBC (pour le routage des appels aux services de communication) au sein de la région. Cet enregistrement SRV peut pointer vers n’importe quelle adresse IP dans la plage d’adresses IP /28 fournie par votre équipe d’intégration.

Si votre passerelle de communication Azure inclut le point de contrôle mobile (MCP), chaque région de service fournit un enregistrement SRV supplémentaire pour MCP. Chaque enregistrement MCP par région contient MCP dans la région avec la plus haute priorité et MCP dans l’autre région avec une priorité plus faible.

Chaque site de votre réseau doit :

  • Envoyez le trafic à sa région de service Azure Communications Gateway locale par défaut.
  • Recherchez des homologues Azure Communications Gateway au sein d’une région à l’aide du DNS SRV, comme indiqué dans la RFC 3263.
    • Effectuez une recherche DNS SRV sur le nom de domaine pour la connexion de la région de service à votre réseau, en utilisant _sip._tls.<regional-FQDN-from-portal>. Remplacez <regional-FQDN-from-portal> par les noms de domaine complets par région à partir des champs Nom d’hôte dans la page Vue d’ensemble de votre ressource dans le portail Azure. Par exemple, si votre déploiement utilise commsgw.azure.com des noms de domaine, recherchez dans _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com la première région.
    • Si la recherche SRV retourne plusieurs cibles, utilisez la pondération et la priorité de chaque cible pour sélectionner une cible unique.
  • Envoyez de nouveaux appels vers les pairs disponibles de l'Azure Communications Gateway.
  • Être en mesure de recevoir le trafic à partir de n’importe quelle adresse IP dans chacune des plages d’adresses IP associées à votre passerelle de communication Azure.

Lorsque votre réseau achemine les appels vers les homologues SIP d’Azure Communications Gateway pour la fonction SBC, il doit :

  • Utilisez LES OPTIONS SIP (ou une combinaison d’OPTIONS et de trafic SIP) pour surveiller la disponibilité des homologues SIP de la passerelle de communication Azure.
  • Réessayez les INVITEs qui ont reçu 408 réponses, 503 réponses ou 504 réponses ou n’ont pas reçu de réponses, en les réacheminant vers d’autres homologues disponibles dans le site local. Passez à l'autre région de service (définie par l'enregistrement SRV de l'autre région) uniquement si tous les pairs de la région de service locale ont échoué.
  • N’effectuez jamais de nouvelles tentatives d’appels qui reçoivent des réponses d’erreur autres que 408, 503 et 504.

Si votre déploiement Azure Communications Gateway inclut le point de contrôle mobile intégré (MCP), votre réseau doit effectuer les opérations suivantes pour MCP :

  • Détectez quand MCP dans une région n’est pas disponible, marquez les cibles de l’enregistrement SRV de cette région comme non disponible, puis réessayez régulièrement pour déterminer quand la région est à nouveau disponible. MCP ne répond pas aux OPTIONS SIP.
  • Gérez les réponses 5xx de MCP en fonction de la stratégie de votre organisation. Par exemple, vous pouvez réessayer la demande ou autoriser l’appel à continuer sans passer par Azure Communications Gateway et dans le système téléphonique Microsoft.

Les détails de ce comportement de routage sont spécifiques à votre réseau. Vous devez les convenir avec votre équipe d'intégration dans votre projet d’intégration.

Régions de gestion

Les régions de gestion contiennent l’infrastructure utilisée pour la commande, la surveillance et la facturation d’Azure Communications Gateway. Toutes les infrastructures de ces régions sont déployées de manière redondante au niveau de la zone, ce qui signifie que toutes les données sont automatiquement répliquées dans chaque zone de disponibilité au sein de la région. Toutes les données de configuration critiques sont également répliquées dans chacune des régions de service pour garantir le bon fonctionnement du service lors d’une défaillance de région Azure.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Expérience de réduction de service pour les régions de service

Pendant une panne à l’échelle de la zone, les appels gérés par la zone concernée sont terminés, avec une brève perte de capacité dans la région jusqu'à ce que le mécanisme d'autoréparation du service rééquilibre les ressources sous-jacentes vers des zones en bonne santé. Cette auto-guérison ne dépend pas de la restauration de zone ; on s’attend à ce que l’état de réparation automatique du service géré par Microsoft compense une zone perdue, à l’aide de la capacité d’autres zones. Le trafic transportant des ressources est déployé dans une configuration redondante interzone, mais à la plus petite échelle, le trafic peut être géré par une seule ressource. Dans ce cas, les mécanismes de basculement décrits dans cet article rééquilibrent tout le trafic vers l’autre région de service, tandis que les ressources qui transportent le trafic sont redéployées dans une zone saine.

Expérience de réduction de zone pour la région de gestion

Lors d’une panne à l’échelle de la zone, aucune action n’est requise lors de la récupération de zone. La région de gestion se guérit et se rééquilibrée pour tirer parti automatiquement de la zone saine.

Récupération d’urgence : basculement vers d’autres régions

La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.

Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.

Cette section décrit le comportement d’Azure Communications Gateway lors d’une panne à l’échelle de la région.

Récupération d’urgence : basculement entre régions pour les régions de service

Pendant une panne à l’échelle de la région, les mécanismes de basculement décrits dans cet article (interrogation OPTIONS et nouvelle tentative SIP en cas d’échec) rééquilibrent tout le trafic d’appel vers l’autre région de service, en conservant la disponibilité. Nous allons commencer à restaurer la redondance régionale. La restauration de la redondance régionale pendant les temps d’arrêt étendus peut nécessiter l’utilisation d’autres régions Azure. Si nous devons migrer une région ayant échoué vers une autre région, nous vous consulterons avant de commencer les migrations.

La fonction SBC dans Azure Communications Gateway fournit l’interrogation « OPTIONS » pour permettre à votre réseau de déterminer la disponibilité des homologues. Pour MCP, votre réseau doit être en mesure de détecter quand MCP n’est pas disponible et réessayer régulièrement pour déterminer quand MCP est à nouveau disponible. MCP ne répond pas aux OPTIONS SIP.

Les clients de l'API de provisionnement contactent Azure Communications Gateway en utilisant le nom de domaine de base de votre déploiement. L’enregistrement DNS pour ce domaine a une durée de vie (TTL) de 60 secondes. Lorsqu’une région échoue, Azure met à jour l’enregistrement DNS pour faire référence à une autre région, afin que les clients effectuant une nouvelle recherche DNS reçoivent les détails de la nouvelle région. Nous vous recommandons de veiller à ce que les clients puissent effectuer une nouvelle recherche DNS et réessayer une requête 60 secondes après un délai d’expiration ou une réponse 5xx.

Conseil / Astuce

Les déploiements de laboratoires ne proposent pas de basculement entre régions (car ils n’ont qu’une seule région de service).

Récupération d’urgence : basculement interrégion pour les régions de gestion

Le trafic vocal et l’approvisionnement via le portail de gestion des numéros ne sont pas affectés par des défaillances dans la région de gestion, car les ressources Azure correspondantes sont hébergées dans les régions de service. Les utilisateurs du portail de gestion des numéros peuvent avoir besoin de se reconnecter.

Les services de surveillance peuvent être temporairement indisponibles tant que le service n’a pas été restauré. Si la région de gestion subit un temps d’arrêt prolongé, nous allons migrer les ressources affectées vers une autre région disponible.

Choix de la gestion et des régions de service

Un déploiement unique d’Azure Communications Gateway est conçu pour gérer votre trafic au sein d’une zone géographique. Déployez les deux régions de service dans un déploiement de production dans la même zone géographique (par exemple en Amérique du Nord). Ce modèle garantit que la latence des appels vocaux reste dans les limites requises par les programmes Opérateur Connect et Teams Phone Mobile.

Tenez compte des points suivants lorsque vous choisissez vos emplacements de région de service :

  • Sélectionnez dans la liste des régions Azure disponibles. Vous pouvez voir les régions Azure qui peuvent être sélectionnées en tant que régions de service dans la page Produits par région .
  • Choisissez des régions proches de vos propres locaux et des emplacements de peering entre votre réseau et Microsoft pour réduire la latence des appels.
  • Préférez les paires régionales pour réduire le temps de récupération si une panne multirégion se produit.

Choisissez une région de gestion dans la liste suivante :

  • East US
  • Ouest du centre des États-Unis
  • Europe Ouest
  • UK South
  • Inde Centre
  • Canada Central
  • Australia East

Les régions de gestion peuvent être colocalisées avec des régions de service. Nous vous recommandons de choisir la région de gestion la plus proche de vos régions de service.

Contrats de niveau de service

La conception de fiabilité décrite dans ce document est implémentée par Microsoft et n’est pas configurable. Pour plus d’informations sur les contrats de niveau de service Azure Communications Gateway (SLA), consultez le contrat SLA Azure Communications Gateway.

Étapes suivantes

  • Last updated on