Freigeben über

Zuverlässigkeit im Azure Communications Gateway

Azure Communications Gateway stellt sicher, dass Ihr Dienst zuverlässig ist, indem Azure-Redundanzmechanismen und SIP-spezifisches Wiederholungsverhalten verwendet werden. Ihr Netzwerk muss bestimmte Anforderungen erfüllen, um die Dienstverfügbarkeit sicherzustellen.

Redundanzmodell des Azure Communications Gateway

Die Bereitstellungen des Azure Communications-Gateways für die Produktion (auch als Standardbereitstellungen bezeichnet) bestehen aus drei separaten Regionen: einer Verwaltungsregion und zwei Dienstregionen. Laborbereitstellungen bestehen aus einer Verwaltungsregion und einer Dienstregion.

In diesem Artikel werden die beiden verschiedenen Regionstypen und ihre unterschiedlichen Redundanzmodelle beschrieben. Sie deckt sowohl regionale Zuverlässigkeit mit Verfügbarkeitszonen als auch regionsübergreifende Zuverlässigkeit mit Notfallwiederherstellung ab. Eine ausführlichere Übersicht über die Zuverlässigkeit in Azure finden Sie unter Azure-Zuverlässigkeit.

Diagramm von zwei Dienstregionen, einer Verwaltungsregion und zwei Operatorstandorten.

Dienstbereiche

Dienstregionen enthalten die VoIP- und API-Infrastruktur, die für die Verarbeitung von Datenverkehr zwischen Ihrem Netzwerk und den ausgewählten Kommunikationsdiensten verwendet wird.

Bereitstellungen des Azure Communications Gateways für die Produktionsumgebung verfügen über zwei Dienstregionen, die im aktiv-aktiv-Modus bereitgestellt werden (gemäß den Operator Connect- und Teams Phone Mobile-Programmen). Schnelles Failover zwischen den Dienstregionen wird auf Infrastruktur-/IP-Ebene und auf Anwendungsebene (SIP/RTP/HTTP) bereitgestellt.

Die Dienstregionen enthalten auch die Infrastruktur für die Bereitstellungs-API des Azure Communications Gateways.

Tipp

Produktionsbereitstellungen müssen immer über zwei Dienstregionen verfügen, auch wenn sich eine der ausgewählten Dienstregionen in einem Azure-Geografiebereich mit nur einer Region (z. B. Katar) befindet. Wenn Sie eine einzelne Region in einer Azure-Geografie auswählen, wählen Sie eine zweite Azure-Region in einer anderen Azure-Geografie aus.

Die Dienstregionen sind im Betrieb identisch und bieten Resilienz sowohl für Zonen- als auch für regionale Fehler. Jede Dienstregion kann 100% des Datenverkehrs mit der Azure Communications Gateway-Instanz übertragen. Endbenutzer sollten daher weiterhin in der Lage sein, während einer Zone oder Regionalen Ausfallzeit erfolgreich Anrufe zu tätigen und zu empfangen.

Lab-Bereitstellungen verfügen über eine Dienstregion.

Anforderungen für die Anrufweiterleitung

Das Azure Communications Gateway bietet ein Redundanzmodell mit erfolgreicher Wiedereinwahl: Anrufe, die von ausfallenden Peers bearbeitet werden, werden beendet, aber neue Anrufe werden an funktionierende Peers weitergeleitet. Dieses Modell spiegelt das Redundanzmodell von Microsoft Teams wieder.

Für Produktionsbereitstellungen erwarten wir, dass Ihr Netzwerk über zwei geografisch redundante Standorte verfügt. Jeder Standort sollte mit einer Azure Communications Gateway-Region gekoppelt werden. Das Redundanzmodell basiert auf der Konnektivität zwischen Ihrem Netzwerk und den Azure Communications Gateway-Dienstregionen.

Diagramm von zwei Operatorstandorten und zwei Dienstbereichen. Beide Dienstregionen stellen eine Verbindung mit beiden Standorten her, wobei primäre und sekundäre Routen vorhanden sind.

Laboreinrichtungen müssen eine Verbindung zu einem Standort in Ihrem Netzwerk herstellen.

Jede Azure Communications Gateway-Dienstregion stellt einen SRV-Eintrag bereit. Dieser Eintrag enthält alle SIP-Peers, die SBC-Funktionen (zum Weiterleiten von Anrufen an Kommunikationsdienste) innerhalb der Region bereitstellen. Dieser SRV-Eintrag kann auf jede IP-Adresse im /28-IP-Bereich verweisen, die Ihnen von Ihrem Onboarding-Team zur Verfügung gestellt wird.

Wenn Ihr Azure Communications Gateway mobile Control Point (MCP) enthält, stellt jede Dienstregion einen zusätzlichen SRV-Eintrag für MCP bereit. Jeder MCP-Eintrag pro Region beinhaltet MCP mit höchster Priorität innerhalb der Region und MCP mit niedrigerer Priorität in der anderen Region.

Jeder Standort in Ihrem Netzwerk muss:

  • Senden des Datenverkehrs standardmäßig an seine lokale Azure Communications Gateway-Dienstregion.
  • Suchen Sie Azure Communications Gateway-Peers in einer Region mithilfe von DNS SRV, wie in RFC 3263 beschrieben.
    • Erstellen Sie mithilfe von _sip._tls.<regional-FQDN-from-portal> ein DNS SRV-Lookup für den Domänennamen, um die Verbindung der Dienstregion zu Ihrem Netzwerk herzustellen. Ersetzen Sie <regional-FQDN-from-portal> durch die FQDNs pro Region aus den Feldern "Hostname " auf der Seite "Übersicht" für Ihre Ressource im Azure-Portal. Wenn Ihre Bereitstellung beispielsweise Domänennamen commsgw.azure.com verwendet, suchen Sie _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com nach der ersten Region.
    • Wenn die SRV-Suche mehrere Ziele zurückgibt, verwenden Sie die Gewichtung und Priorität jedes Ziels, um ein einzelnes Ziel auszuwählen.
  • Senden neuer Anrufe an verfügbare Azure Communications Gateway-Peers.
  • Sie können Datenverkehr von jeder IP-Adresse in jedem der IP-Bereiche empfangen, die Ihrem Azure Communications Gateway zugeordnet sind.

Wenn Ihr Netzwerk Anrufe an die SIP-Peers des Azure Communications Gateways für die SBC-Funktion weiter leitet, muss folgendes erfolgen:

  • Verwenden Sie SIP-OPTIONEN (oder eine Kombination aus OPTIONEN und SIP-Datenverkehr), um die Verfügbarkeit der SIP-Peers des Azure Communications Gateways zu überwachen.
  • Wiederholen Sie INVITEs, die 408 Antworten, 503 Antworten oder 504 Antworten erhalten oder keine Antworten erhalten haben, indem Sie sie an andere verfügbare Peers auf der lokalen Website umleiten. Die Suche nach der anderen Dienstregion (definiert durch den SRV-Eintrag der anderen Region) nur, wenn alle Peers in der lokalen Dienstregion fehlgeschlagen sind.
  • Wiederholen Sie niemals Anrufe, die andere Fehlerantworten als 408, 503 und 504 erhalten.

Wenn Ihre Azure Communications Gateway-Bereitstellung integrierte Mobile Control Point (MCP) enthält, muss Ihr Netzwerk für MCP wie folgt vorgehen:

  • Erkennen, wenn MCP in einer Region nicht verfügbar ist, markieren Sie die Ziele für den SRV-Eintrag dieser Region als nicht verfügbar, und versuchen Sie es regelmäßig erneut, um zu ermitteln, wann die Region erneut verfügbar ist. MCP reagiert nicht auf SIP-OPTIONEN.
  • Behandeln Sie 5xx-Antworten von MCP gemäß den Richtlinien Ihrer Organisation. Beispielsweise könnten Sie die Anforderung wiederholen oder zulassen, dass der Anruf fortgesetzt wird, ohne das Azure Communications Gateway zu durchlaufen und in das Microsoft-Telefonsystem zu gelangen.

Die Details dieses Routingverhaltens sind spezifisch für Ihr Netzwerk. Sie müssen sie während Ihres Integrationsprojekts mit Ihrem Onboarding-Team vereinbaren.

Verwaltungsregionen

Verwaltungsregionen enthalten die Infrastruktur, die für die Bestellung, Überwachung und Rechnungsstellung des Azure Communications Gateway verwendet wird. Alle Infrastruktur innerhalb dieser Regionen wird auf zonal redundante Weise bereitgestellt, was bedeutet, dass alle Daten automatisch in jeder Verfügbarkeitszone innerhalb der Region repliziert werden. Alle kritischen Konfigurationsdaten werden auch in jede der Dienstregionen repliziert, um das ordnungsgemäße Funktionieren des Diensts während eines Azure-Regionsfehlers sicherzustellen.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Erfahrung der Dienstreduzierung für Serviceregionen

Während eines zonenweiten Ausfalls werden Anrufe, die von der betroffenen Zone verarbeitet werden, beendet. Dabei kommt es zu einem kurzen Kapazitätsverlust innerhalb der Region, bis eine selbstheilende Neuausrichtung die zugrunde liegenden Ressourcen in funktionierende Zonen neu ausgleicht. Diese Selbstheilung ist nicht von der Zonenwiederherstellung abhängig; Es wird erwartet, dass der self-healing-Zustand des von Microsoft verwalteten Diensts eine verloren gegangene Zone mit Kapazität aus anderen Zonen ausgleicht. Ressourcen für den Datenverkehr werden auf zonenredundante Weise bereitgestellt, jedoch kann bei geringstem Datenaufkommen der Datenverkehr von einer einzigen Ressource verarbeitet werden. In diesem Fall werden die in diesem Artikel beschriebenen Failovermechanismen den gesamten Datenverkehr in die andere Dienstregion neu ausgleichen, während die Ressourcen, die Datenverkehr übertragen, in einer fehlerfreien Zone erneut bereitgestellt werden.

Zonenreduzierungs-Erfahrung für die Verwaltungsregion

Während eines zonenweiten Ausfalls ist während der Zonenwiederherstellung keine Aktion erforderlich. Die Managementregion regeneriert sich selbst und balanciert sich neu, um die Vorteile der gesunden Zone automatisch zu nutzen.

Notfallwiederherstellung: Fallback in andere Regionen

Notfallwiederherstellung (DR) bezieht sich auf Methoden, die Organisationen zum Wiederherstellen von Ereignissen mit hohem Einfluss verwenden, z. B. Naturkatastrophen oder fehlerhafte Bereitstellungen, die zu Ausfallzeiten und Datenverlusten führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, finden Sie Unter "Empfehlungen für das Entwerfen einer Notfallwiederherstellungsstrategie".

Für DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In diesem Modell stellt Microsoft sicher, dass die Basisinfrastruktur und Plattformdienste verfügbar sind. Viele Azure-Dienste replizieren jedoch nicht automatisch Daten oder greifen von einer fehlgeschlagenen Region zurück, um sie in eine andere aktivierte Region zu replizieren. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die im Rahmen von Azure-PaaS-Angeboten (Plattform-as-a-Service) ausgeführt werden, bieten Features und Anleitungen zur Unterstützung der Notfallwiederherstellung. Sie können dienstspezifische Features verwenden, um die schnelle Wiederherstellung zu unterstützen, um Ihren DR-Plan zu entwickeln.

In diesem Abschnitt wird das Verhalten des Azure Communications Gateways während eines regionsweiten Ausfalls beschrieben.

Notfallwiederherstellung: regionsübergreifendes Failover für Dienstregionen

Während eines regionsweiten Ausfalls gleichen die in diesem Artikel beschriebenen Failover-Mechanismen (OPTIONS polling und SIP retry on failure) den gesamten Anrufverkehr neu aus und leiten ihn in die andere Dienstregion um, um die Verfügbarkeit aufrechtzuerhalten. Wir beginnen mit der Wiederherstellung regionaler Redundanz. Für die Wiederherstellung regionaler Redundanzen während erweiterter Ausfallzeiten kann die Verwendung anderer Azure-Regionen erforderlich sein. Wenn wir eine fehlgeschlagene Region zu einer anderen Region migrieren müssen, beraten wir Sie vor dem Starten von Migrationen.

Die SBC-Funktion in Azure Communications Gateway bietet OPTIONS-Abrufe, damit Ihr Netzwerk die Peerverfügbarkeit ermitteln kann. Für MCP muss Ihr Netzwerk erkennen können, wann MCP nicht verfügbar ist, und es wird regelmäßig erneut versucht, zu ermitteln, wann MCP wieder verfügbar ist. MCP reagiert nicht auf SIP-OPTIONEN.

Die Bereitstellungs-API-Clients wenden sich an das Azure Communications-Gateway mithilfe des Basisdomänennamens für Ihre Bereitstellung. Der DNS-Eintrag für diese Domäne weist eine TTL (Time-to-Live) von 60 Sekunden auf. Wenn eine Region fehlschlägt, aktualisiert Azure den DNS-Eintrag so, dass er auf eine andere Region verweist, sodass Clients, die eine neue DNS-Suche erstellen, die Details der neuen Region erhalten. Es wird empfohlen, sicherzustellen, dass Clients eine neue DNS-Suche durchführen und eine Anforderung 60 Sekunden nach einem Timeout oder einer 5xx-Antwort wiederholen können.

Tipp

Lab-Bereitstellungen bieten kein regionsübergreifendes Failover (da sie nur eine einzige Service-Region haben).

Notfallwiederherstellung: regionsübergreifendes Failover für Verwaltungsregionen

VoIP-Datenverkehr und Bereitstellung über das Nummernverwaltungsportal sind von Fehlern in der Verwaltungsregion nicht betroffen, da die entsprechenden Azure-Ressourcen in Dienstregionen gehostet werden. Benutzer des Nummernverwaltungsportals müssen sich möglicherweise erneut anmelden.

Überwachungsdienste sind möglicherweise vorübergehend nicht verfügbar, bis der Dienst wiederhergestellt wurde. Wenn die Verwaltungsregion längere Ausfallzeiten erlebt, migrieren wir die betroffenen Ressourcen zu einer anderen verfügbaren Region.

Auswählen von Verwaltungs- und Dienstregionen

Eine einzelne Bereitstellung des Azure Communications Gateways ist für die Verarbeitung Ihres Datenverkehrs innerhalb eines geografischen Gebiets konzipiert. Stellen Sie beide Dienstregionen in einer Produktionsbereitstellung innerhalb desselben geografischen Gebiets (z. B. Nordamerika) bereit. Dieses Modell stellt sicher, dass die Latenz bei Sprachanrufen innerhalb der von den Programmen Operator Connect und Teams Phone Mobile erforderlichen Grenzwerten liegt.

Berücksichtigen Sie die folgenden Punkte, wenn Sie Ihre Standorte für die Dienstregion auswählen:

  • Wählen Sie aus der Liste der verfügbaren Azure-Regionen aus. Sie können die Azure-Regionen anzeigen, die als Dienstregionen auf der Seite " Produkte nach Region " ausgewählt werden können.
  • Wählen Sie Regionen in der Nähe Ihrer eigenen Standorte und der Peeringstandorte zwischen Ihrem Netzwerk und Microsoft aus, um die Anruflatenz zu reduzieren.
  • Bevorzugen Sie regionale Paare , um die Wiederherstellungszeit zu minimieren, wenn ein Ausfall mit mehreren Regionen auftritt.

Wählen Sie in der folgenden Liste eine Verwaltungsregion aus:

  • East US
  • Zentraler Westen der USA
  • West Europe
  • UK South
  • Indien, Mitte
  • Canada Central
  • Australia East

Verwaltungsregionen können mit Dienstregionen zusammengelegt werden. Es wird empfohlen, die Verwaltungsregion auszuwählen, die Ihren Serviceregionen am nächsten ist.

Vereinbarungen zum Service Level

Der in diesem Dokument beschriebene Zuverlässigkeitsentwurf wird von Microsoft implementiert und kann nicht konfiguriert werden. Weitere Informationen zu den Service-Level-Agreements (SLAs) des Azure Communications Gateway finden Sie im SLA des Azure Communications Gateway.

Nächste Schritte

  • Last updated on