Partager via

Fiabilité dans la passerelle Azure Communications

  • Article

Azure Communications Gateway garantit la fiabilité de votre service à l’aide de mécanismes de redondance Azure et du comportement de nouvelle tentative propre à 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éploiement 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 lab 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 des zones de disponibilité et la fiabilité inter-région avec récupération d’urgence. 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 les services de communication de votre choix.

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

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

Conseil

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

Ces régions de service sont identiques en terme de fonctionnement, et offrent une résilience aux défaillances zonales et régionales. 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 pendant un temps d’arrêt zonal ou régional.

Les déploiements lab ont une seule région de service.

Configuration requise pour le routage des appels

Azure Communications Gateway offre un modèle de redondance de type « recomposition avec succès » : 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 reflète le modèle de redondance fourni par Microsoft Teams.

Pour les déploiements de production, votre réseau doit avoir 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 routes primaires et secondaires.

Les déploiements lab 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 qui vous est fournie par votre équipe d’intégration.

Si votre instance Azure Communications Gateway inclut un 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 le MCP de la région au niveau de priorité le plus élevé, et le MCP de l’autre région à une priorité inférieure.

Chaque site de votre réseau doit :

  • Envoyer le trafic à sa région de service Azure Communications Gateway locale par défaut.
  • Localiser les homologues Azure Communications Gateway au sein d’une région à l’aide de l’enregistrement SRV DNS, comme indiqué dans la RFC 3263.
    • Effectuez une recherche DNS SRV sur le nom de domaine de la connexion de la région de service à votre réseau, à l’aide de _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 Vue d’ensemble de votre ressource dans le portail Azure. Par exemple, si votre déploiement utilise commsgw.azure.com noms de domaine, recherchez _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com pour la première région.
    • Si la recherche d’enregistrement SRV retourne plusieurs cibles, utilisez la pondération et la priorité de chaque cible pour sélectionner une cible unique.
  • Envoyer les nouveaux appels aux homologues Azure Communications Gateway disponibles.
  • Soyez en mesure de recevoir du trafic à partir de toute adresse IP dans chacune des plages d’adresses IP associées à votre passerelle Azure Communications Gateway.

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

  • Utiliser SIP OPTIONS (ou une combinaison de trafic SIP et OPTIONS) pour superviser la disponibilité des homologues SIP Azure Communications Gateway.
  • Réessayer les INVITEs ayant reçu des réponses 408, 503 ou 504 ou n’ayant pas reçu de réponse, en les reroutant vers d’autres homologues disponibles dans le site local. Effectuer une chasse vers l’autre région de service (définie par l’enregistrement SRV de l’autre région) uniquement si tous les homologues de la région de service local ont échoué.
  • Ne jamais effectuer de nouvelles tentatives pour les appels qui reçoivent des réponses d’erreur autres que 408, 503 et 504.

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

  • Détecter quand MCP dans une région n’est pas disponible, marquer les cibles de l’enregistrement SRV de cette région comme non disponibles, puis réessayer régulièrement afin de déterminer quand la région est à nouveau disponible. MCP ne répond pas à SIP OPTIONS.
  • Gérer les réponses 5xx de MCP conformément à la stratégie de votre organisation. Par exemple, vous pourriez réessayer la requête ou autoriser la poursuite de l’appel sans passer par Azure Communications Gateway et le système téléphonique Microsoft.

Les détails de ce comportement de routage sont propres à votre réseau. Vous devez convenir de ces détails avec votre équipe d’intégration pendant 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 avec redondance interzone, ce qui signifie que toutes les données sont automatiquement répliquées sur 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, afin de 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é Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

Expérience en cas de défaillance de zone 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 arrêtés, avec une brève perte de capacité dans la région jusqu’à ce que l’autoréparation de la région rééquilibre les ressources sous-jacentes dans des zones saines. Cette autoréparation ne dépend pas de la restauration de zone ; on s’attend à ce que l’état de l’autoréparation du service managé par Microsoft compense une zone perdue, en se servant de la capacité des autres zones. Les ressources porteuses de trafic sont déployées avec une redondance interzone, mais à l’échelle la plus petite le trafic peut être géré par une ressource unique. 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 en cas de défaillance 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 répare automatiquement et se rééquilibre afin de tirer parti automatiquement de la zone saine.

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

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte 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 à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent 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 conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

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 interrégion 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, maintenant ainsi 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 toute migration.

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

Les clients d’API d’approvisionnement contactent Azure Communications Gateway à l’aide du 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 subit une défaillance, Azure met à jour l’enregistrement DNS pour qu’il fasse 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 l’expiration du délai ou une réponse 5xx.

Conseil

Les déploiements lab ne proposent pas de basculement interrégionaux (car ils ont 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 par le biais du Portail de gestion des numéros ne sont pas affectés par les 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 devront peut-être se reconnecter.

Les services de monitoring 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 migrerons les ressources affectées vers une autre région disponible.

Choix des régions de service et de gestion

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 au sein de la même zone géographique (par exemple, Amérique du Nord). Ce modèle garantit que la latence des appels vocaux reste dans les limites requises par les programmes Operator Connect et Teams Phone Mobile.

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

  • Effectuez votre sélection parmi la liste des régions Azure disponibles. Vous pouvez consulter les régions Azure pouvant ê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 localisations de Peering entre votre réseau et Microsoft, afin de réduire la latence des appels.
  • Privilégiez les paires régionales afin de réduire le temps de récupération si une panne multirégion se produit.

Choisissez une région de gestion parmi celles-ci :

  • USA Est
  • Centre-USA Ouest
  • Europe Ouest
  • Sud du Royaume-Uni
  • Inde Centre
  • Centre du Canada
  • Australie Est

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.

Remarque

Si vous activez Azure Operator Call Protection (préversion), la région de service sélectionnée peut ne pas être la région Azure dans laquelle les ressources de prise en charge sont déployées. Consultez produits Azure par région pour obtenir la liste des régions de service Azure Operator Call Protection actuellement prises en charge et discutez avec votre équipe d’intégration si vous avez des questions sur la région sélectionnée.

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 (SLA) Azure Communications Gateway, consultez le contrat SLA Azure Communications Gateway.

Étapes suivantes