Freigeben über

Zuverlässigkeit in Azure Communications Gateway

  • Artikel

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

Redundanzmodell von Azure Communications Gateway

Produktionsbereitstellungen von Azure Communications-Gateways (auch als Standardbereitstellungen bezeichnet) bestehen aus drei separaten Regionen: einer Verwaltungsregion und zwei Dienstregionen. Labbereitstellungen bestehen aus einer Verwaltungsregion und einer Dienstregion.

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

Abbildung mit zwei Dienstregionen, einer Verwaltungsregion und zwei Operatorstandorten

Dienstregionen

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

Produktionsbereitstellungen von Azure Communications-Gateways bestehen aus zwei Dienstregionen, die in einem Aktiv/Aktiv-Modus bereitgestellt werden (gemäß den Programmen „Operator Connect“ und „Teams Phone Mobile“). 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 von Azure Communications Gateway.

Tipp

Produktionsbereitstellungen müssen immer über zwei Dienstregionen verfügen, auch wenn sich eine der ausgewählten Dienstregionen in einer Azure-Region (z. B. Katar) befindet. Wenn Sie eine Azure-Region 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 Regionsausfälle. Jede Dienstregion kann 100 % des Datenverkehrs über die Azure Communications Gateway-Instanz übertragen. Endbenutzer sollten daher weiterhin in der Lage sein, während eines Zonen- oder Regionsausfalls erfolgreich Anrufe zu tätigen und zu empfangen.

Labbereitstellungen verfügen über eine Dienstregion.

Anforderungen für die Anrufweiterleitung

Azure Communications Gateway bietet ein Redundanzmodell mit „erfolgreicher Wahlwiederholung“: Anrufe, die von ausgefallenen Peers verarbeitet werden, werden abgebrochen, neue Anrufe werden jedoch an fehlerfreie Peers weitergeleitet. Dieses Modell spiegelt das Redundanzmodell von Microsoft Teams wider.

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

Abbildung mit zwei Operatorstandorten und zwei Dienstregionen. Beide Dienstregionen sind über primäre und sekundäre Routen mit beiden Standorten verbunden.

Labbereitstellungen müssen eine Verbindung mit 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 IP-Adressbereich /28 verweisen, die Ihnen von Ihrem Onboardingteam zur Verfügung gestellt wurde.

Wenn Ihr Azure Communications Gateway einen mobilen Steuerpunkt (Mobile Control Point, MCP) enthält, stellt jede Dienstregion einen zusätzlichen SRV-Eintrag für MCP bereit. Jeder MCP-Eintrag pro Region enthält MCP innerhalb der Region mit oberster Priorität und MCP in der anderen Region mit einer niedrigeren Priorität.

Jeder Standort in Ihrem Netzwerk muss:

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

Wenn Ihr Netzwerk Anrufe an die SIP-Peers von Azure Communications Gateway für die SBC-Funktion weiterleitet, muss/darf es:

  • SIP OPTIONS (oder eine Kombination aus OPTIONS und SIP-Datenverkehr) verwenden, um die Verfügbarkeit der Azure Communications Gateway-SIP-Peers zu überwachen.
  • INVITE-Anforderungen wiederholen, die 408-, 503-, 504-Antworten oder keine Antworten erhalten haben, indem sie an andere verfügbare Peers am lokalen Standort umgeleitet werden. Wechseln Sie nur dann zu einer anderen Dienstregion (definiert durch den SRV-Eintrag der anderen Region), wenn alle Peers in der lokalen Dienstregion ausgefallen sind.
  • Niemals Anrufe wiederholen, die andere Fehlerantworten als 408, 503 und 504 erhalten.

Wenn Ihre Azure Communications Gateway-Bereitstellung einen integrierten mobilen Steuerpunkt (Mobile Control Point, MCP) umfasst, muss Ihr Netzwerk für MCP wie folgt vorgehen:

  • Erkennen, wenn der MCP in einer Region nicht verfügbar ist, die Ziele für den SRV-Eintrag dieser Region als nicht verfügbar markieren und in regelmäßigen Abständen erneut versuchen, zu ermitteln, wann die Region wieder verfügbar ist. MCP antwortet nicht auf SIP OPTIONS.
  • Behandeln von 5xx-Antworten von MCP gemäß den Richtlinien Ihrer Organisation. Sie können z. B. die Anforderung wiederholen oder zulassen, dass der Anruf fortgesetzt wird, ohne Azure Communications Gateway zu Microsoft Phone System zu durchlaufen.

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

Verwaltungsregionen

Verwaltungsregionen enthalten die Infrastruktur, die für Bestellung, Überwachung und Abrechnung von Azure Communications Gateway verwendet wird. Die gesamte Infrastruktur innerhalb dieser Regionen wird zonenweise redundant 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 bei einem Ausfall einer Azure-Region zu gewährleisten.

Unterstützung für Verfügbarkeitszonen

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

Weitere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Was sind Verfügbarkeitszonen?.

Zonenausfall für Dienstregionen

Während eines zonenweiten Ausfalls werden Anrufe, die von der betroffenen Zone verarbeitet werden, beendet, was zu einem kurzen Kapazitätsverlust innerhalb der Region führt, bis die Selbstreparatur des Diensts die zugrunde liegenden Ressourcen auf fehlerfreie Zonen verteilt. Diese Selbstreparatur ist nicht von der Zonenwiederherstellung abhängig. Es wird erwartet, dass der Selbstreparaturstatus des von Microsoft verwalteten Diensts eine ausgefallene Zone mittels Kapazitäten aus anderen Zonen kompensiert. Die datenverkehrsübertragenden Ressourcen werden zonenredundant bereitgestellt, aber auf der niedrigsten Stufe kann der Verkehr von einer einzigen Ressource verarbeitet werden. In diesem Fall gleichen die in diesem Artikel beschriebenen Failovermechanismen den gesamten Datenverkehr auf die andere Dienstregion aus, während die Ressourcen, die den Datenverkehr übertragen, in einer fehlerfreien Zone neu bereitgestellt werden.

Zonenausfall für die Verwaltungsregion

Während eines zonenweiten Ausfalls ist während der Zonenwiederherstellung keine Aktion erforderlich. Die Verwaltungsregion repariert und gleicht sich selbst wieder aus, um automatisch die fehlerfreie Zone zu nutzen.

Notfallwiederherstellung: Fallback in andere Regionen

Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust 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, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.

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

Notfallwiederherstellung: regionsübergreifendes Failover für Dienstregionen

Während eines regionsweiten Ausfalls werden die in diesem Artikel beschriebenen Failovermechanismen (OPTIONS-Abruf und SIP RETRY bei Ausfall) den gesamten Anrufverkehr auf die andere Dienstregion umleiten und die Verfügbarkeit aufrechterhalten. Wir beginnen mit der Wiederherstellung regionaler Redundanz. Für die Wiederherstellung regionaler Redundanz während längerer Ausfallzeiten kann die Verwendung anderer Azure-Regionen erforderlich sein. Wenn wir eine ausgefallene Region in eine andere Region migrieren müssen, wenden wir uns an Sie, bevor wir mit der Migration beginnen.

Die SBC-Funktion in Azure Communications Gateway bietet OPTIONS-Abrufe, mit denen Ihr Netzwerk die Verfügbarkeit von Peers ermitteln kann. Für MCP muss Ihr Netzwerk erkennen können, wenn MCP nicht verfügbar ist, und versucht regelmäßig erneut zu ermitteln, wann MCP wieder verfügbar ist. MCP antwortet nicht auf SIP OPTIONS.

Bereitstellungs-API-Clients kontaktieren Azure Communications Gateway unter Verwendung des Basisdomänennamens für Ihre Bereitstellung. Der DNS-Eintrag für diese Domäne hat eine Time-to-Live (TTL) von 60 Sekunden. Wenn eine Region ausfällt, aktualisiert Azure den DNS-Eintrag so, dass er auf eine andere Region verweist. Dadurch erhalten Clients, die einen neuen DNS-Lookup durchführen, die Details der neuen Region. Es wird empfohlen, sicherzustellen, dass Clients 60 Sekunden nach einem Timeout oder einer 5xx-Antwort einen neuen DNS-Lookup durchführen und die Anforderung wiederholen können.

Tipp

Labbereitstellungen bieten kein regionsübergreifendes Failover (da sie nur eine Dienstregion haben).

Notfallwiederherstellung: regionsübergreifendes Failover für Verwaltungsregionen

Voice-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änger ausfällt, migrieren wir die betroffenen Ressourcen zu einer anderen verfügbaren Region.

Auswählen von Verwaltungs- und Dienstregionen

Eine einzelne Bereitstellung von Azure Communications Gateway 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 Wartezeit bei Sprachanrufen innerhalb der von den Programmen „Operator Connect“ und „Teams Phone Mobile“ geforderten Grenzwerten liegt.

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

  • Wählen Sie eine Option aus der Liste der verfügbaren Azure-Regionen aus. Sie finden die Azure-Regionen, die als Dienstregionen ausgewählt werden können, auf der Seite Produkte nach Region.
  • Wählen Sie Regionen in der Nähe Ihres eigenen Standorts und der Peeringstandorte zwischen Ihrem Netzwerk und Microsoft, um die Anrufwartezeit zu verringern.
  • Bevorzugen Sie regionale Paare, um die Wiederherstellungszeit zu minimieren, wenn mehrere Regionen ausfallen.

Wählen Sie eine Verwaltungsregion aus der folgenden Liste:

  • USA, Osten
  • USA, Westen-Mitte
  • Europa, Westen
  • UK, Süden
  • Indien, Mitte
  • Kanada, Mitte
  • Australien (Osten)

Verwaltungsregionen können sich in Dienstregionen befinden. Es wird empfohlen, die Verwaltungsregion zu wählen, die Ihren Dienstregionen am nächsten liegt.

Vereinbarungen zum Service Level

Das in diesem Dokument beschriebene Zuverlässigkeitsdesign wird von Microsoft implementiert und ist nicht konfigurierbar. Weitere Informationen zu den Vereinbarungen zum Servicelevel (SLAs) von Azure Communications Gateway finden Sie in der Azure Communications Gateway-SLA.

Nächste Schritte