Share via

Betrouwbaarheid in Azure Communications Gateway

  • Artikel

Azure Communications Gateway zorgt ervoor dat uw service betrouwbaar is met behulp van Azure-redundantiemechanismen en SIP-specifiek gedrag voor opnieuw proberen. Uw netwerk moet voldoen aan specifieke vereisten om de beschikbaarheid van de service te garanderen.

Redundantiemodel van Azure Communications Gateway

Productieimplementaties van Azure Communications Gateway (ook wel standaardimplementaties genoemd) bestaan uit drie afzonderlijke regio's: een beheerregio en twee serviceregio's. Labimplementaties bestaan uit één beheerregio en één serviceregio.

In dit artikel worden de twee verschillende regiotypen en hun afzonderlijke redundantiemodellen beschreven. Het omvat zowel regionale betrouwbaarheid met beschikbaarheidszones als betrouwbaarheid tussen regio's met herstel na noodgevallen. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Diagram van twee serviceregio's, een beheerregio en twee operatorsites.

Serviceregio's

Serviceregio's bevatten de spraak- en API-infrastructuur die wordt gebruikt voor het verwerken van verkeer tussen uw netwerk en uw gekozen communicatieservices.

Productieimplementaties van Azure Communications Gateway hebben twee serviceregio's die zijn geïmplementeerd in een actief-actief-modus (zoals vereist voor de Operator verbinden en Teams Telefoon Mobile-programma's). Snelle failover tussen de serviceregio's wordt geboden op het niveau van de infrastructuur/IP en op het niveau van de toepassing (SIP/RTP/HTTP).

De serviceregio's bevatten ook de infrastructuur voor de inrichtings-API van Azure Communications Gateway.

Tip

Productie-implementaties moeten altijd twee serviceregio's hebben, zelfs als een van de gekozen serviceregio's zich in een Azure Geografie met één regio bevindt (bijvoorbeeld Qatar). Als u een Azure Geografie met één regio kiest, kiest u een tweede Azure-regio in een andere Azure-geografie.

De serviceregio's zijn identiek in werking en bieden tolerantie voor zowel zone- als regionale fouten. Elke serviceregio kan 100% van het verkeer vervoeren met behulp van het Azure Communications Gateway-exemplaar. Daarom moeten eindgebruikers nog steeds gesprekken kunnen voeren en ontvangen tijdens een zone- of regionale downtime.

Labimplementaties hebben één serviceregio.

Vereisten voor oproeproutering

Azure Communications Gateway biedt een 'geslaagd redial' redundantiemodel: aanroepen die worden verwerkt door mislukte peers, worden beëindigd, maar nieuwe aanroepen worden doorgestuurd naar goede peers. Dit model weerspiegelt het redundantiemodel van Microsoft Teams.

Voor productie-implementaties verwachten we dat uw netwerk twee geografisch redundante sites heeft. Elke site moet worden gekoppeld aan een Azure Communications Gateway-regio. Het redundantiemodel is afhankelijk van crossconnectiviteit tussen uw netwerk- en Azure Communications Gateway-serviceregio's.

Diagram van twee operatorsites en twee serviceregio's. Beide serviceregio's maken verbinding met beide sites, met primaire en secundaire routes.

Labimplementaties moeten verbinding maken met één site in uw netwerk.

Elke Azure Communications Gateway-serviceregio biedt een SRV-record. Deze record bevat alle SIP-peers die SBC-functionaliteit bieden (voor routering van aanroepen naar communicatieservices) binnen de regio. Deze SRV-record kan verwijzen naar elk IP-adres in het /28 IP-bereik dat aan u is verstrekt door uw onboardingteam.

Als uw Azure Communications Gateway Mobile Control Point (MCP) bevat, biedt elke serviceregio een extra SRV-record voor MCP. Elke MCP-record per regio bevat MCP in de regio met de hoogste prioriteit en MCP in de andere regio met een lagere prioriteit.

Elke site in uw netwerk moet:

  • Verzend standaard verkeer naar de lokale Azure Communications Gateway-serviceregio.
  • Zoek Azure Communications Gateway-peers binnen een regio met behulp van DNS SRV, zoals wordt beschreven in RFC 3263.
    • Maak een DNS SRV-zoekactie op de domeinnaam voor de verbinding van de serviceregio met uw netwerk met behulp van _sip._tls.<regional-FQDN-from-portal>. Vervang <regional-FQDN-from-portal> door de FQDN's per regio uit de hostnaamvelden op de pagina Overzicht voor uw resource in Azure Portal. Als uw implementatie bijvoorbeeld domeinnamen gebruikt commsgw.azure.com , zoekt u naar _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com de eerste regio.
    • Als de SRV-zoekopdracht meerdere doelen retourneert, gebruikt u het gewicht en de prioriteit van elk doel om één doel te selecteren.
  • Nieuwe aanroepen verzenden naar beschikbare Azure Communications Gateway-peers.
  • U kunt verkeer ontvangen van elk IP-adres in elk van de IP-bereiken die zijn gekoppeld aan uw Azure Communications Gateway.

Wanneer uw netwerk aanroepen naar sip-peers van Azure Communications Gateway voor de SBC-functie routeert, moet het volgende:

  • Gebruik SIP OPTIONS (of een combinatie van OPTIONS en SIP-verkeer) om de beschikbaarheid van de SIP-peers van de Azure Communications Gateway te bewaken.
  • Probeer INVITEs die 408-antwoorden, 503-antwoorden of 504-antwoorden hebben ontvangen of die geen antwoorden hebben ontvangen, door ze opnieuw te omleiden naar andere beschikbare peers op de lokale site. Opsporen naar de andere serviceregio (gedefinieerd door de SRV-record van de andere regio) alleen als alle peers in de lokale serviceregio zijn mislukt.
  • Probeer nooit opnieuw aanroepen die andere foutmeldingen ontvangen dan 408, 503 en 504.

Als uw Azure Communications Gateway-implementatie geïntegreerde Mobile Control Point (MCP) bevat, moet uw netwerk het volgende doen voor MCP:

  • Detecteer wanneer MCP in een regio niet beschikbaar is, markeer de doelen voor de SRV-record van die regio als niet beschikbaar en probeer het regelmatig opnieuw om te bepalen wanneer de regio opnieuw beschikbaar is. MCP reageert niet op SIP OPTIONS.
  • 5xx-antwoorden van MCP verwerken volgens het beleid van uw organisatie. U kunt bijvoorbeeld de aanvraag opnieuw proberen of u kunt toestaan dat de aanroep wordt voortgezet zonder azure Communications Gateway door te geven en in Microsoft Telefoon Systeem.

De details van dit routeringsgedrag zijn specifiek voor uw netwerk. U moet ze akkoord gaan met uw onboardingteam tijdens uw integratieproject.

Beheerregio's

Beheerregio's bevatten de infrastructuur die wordt gebruikt voor de volgorde, bewaking en facturering van Azure Communications Gateway. Alle infrastructuur binnen deze regio's wordt op een zone-redundante manier geïmplementeerd, wat betekent dat alle gegevens automatisch worden gerepliceerd in elke beschikbaarheidszone binnen de regio. Alle kritieke configuratiegegevens worden ook gerepliceerd naar elk van de serviceregio's om ervoor te zorgen dat de service goed functioneert tijdens een azure-regiofout.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

Zone-down-ervaring voor serviceregio's

Tijdens een zonebrede storing worden aanroepen die door de getroffen zone worden verwerkt, beëindigd, met een kort verlies van capaciteit binnen de regio totdat de zelfherstelde middelen van de service opnieuw worden verdeeld over gezonde zones. Deze zelfherstel is niet afhankelijk van zoneherstel; Naar verwachting compenseert de door Microsoft beheerde service zelfherstelstatus voor een verloren zone, met behulp van capaciteit van andere zones. Verkeer met resources wordt op een zone-redundante manier geïmplementeerd, maar op de laagste schaal kan verkeer worden verwerkt door één resource. In dit geval herverdeelt de failovermechanismen die in dit artikel worden beschreven, al het verkeer naar de andere serviceregio, terwijl de resources die verkeer vervoeren, opnieuw worden geïmplementeerd in een gezonde zone.

Zone-down-ervaring voor de beheerregio

Tijdens een zonebrede storing is er geen actie vereist tijdens zoneherstel. De beheerregio herstelt zichzelf en herbalanceert zichzelf om automatisch te profiteren van de gezonde zone.

Herstel na noodgevallen: terugval naar andere regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

In deze sectie wordt het gedrag van Azure Communications Gateway beschreven tijdens een storing in de hele regio.

Herstel na noodgevallen: failover tussen regio's voor serviceregio's

Tijdens een storing in de hele regio worden met de failovermechanismen die in dit artikel worden beschreven (OPTIONS polling and SIP retry on failure) alle aanroepverkeer naar de andere serviceregio herverdeeld, waardoor de beschikbaarheid behouden blijft. We beginnen met het herstellen van regionale redundantie. Het herstellen van regionale redundantie tijdens uitgebreide downtime vereist mogelijk het gebruik van andere Azure-regio's. Als we een mislukte regio naar een andere regio moeten migreren, raadpleegt u voordat u een migratie start.

De SBC-functie in Azure Communications Gateway biedt OPTIES-polling waarmee uw netwerk de beschikbaarheid van peers kan bepalen. Voor MCP moet uw netwerk kunnen detecteren wanneer MCP niet beschikbaar is en probeer het regelmatig opnieuw om te bepalen wanneer MCP weer beschikbaar is. MCP reageert niet op SIP OPTIONS.

Het inrichten van API-clients neemt contact op met Azure Communications Gateway met behulp van de basisdomeinnaam voor uw implementatie. De DNS-record voor dit domein heeft een time-to-live (TTL) van 60 seconden. Wanneer een regio mislukt, werkt Azure de DNS-record bij om naar een andere regio te verwijzen, zodat clients die een nieuwe DNS-zoekopdracht maken de details van de nieuwe regio ontvangen. We raden u aan ervoor te zorgen dat clients een nieuwe DNS-zoekopdracht kunnen maken en een aanvraag 60 seconden na een time-out of een 5xx-antwoord opnieuw kunnen proberen.

Tip

Labimplementaties bieden geen failover tussen regio's (omdat ze slechts één serviceregio hebben).

Herstel na noodgevallen: failover tussen regio's voor beheerregio's

Spraakverkeer en inrichting via de portal Nummerbeheer worden niet beïnvloed door fouten in de beheerregio, omdat de bijbehorende Azure-resources worden gehost in serviceregio's. Gebruikers van de Portal nummerbeheer moeten zich mogelijk opnieuw aanmelden.

Bewakingsservices zijn mogelijk tijdelijk niet beschikbaar totdat de service is hersteld. Als de beheerregio uitgebreide downtime ondervindt, migreren we de betrokken resources naar een andere beschikbare regio.

Beheer- en serviceregio's kiezen

Eén implementatie van Azure Communications Gateway is ontworpen om uw verkeer binnen een geografisch gebied te verwerken. Implementeer beide serviceregio's in een productie-implementatie binnen hetzelfde geografische gebied (bijvoorbeeld Noord-Amerika). Dit model zorgt ervoor dat latentie voor spraakoproepen binnen de limieten blijft die vereist zijn voor de Operator verbinden- en Teams Telefoon Mobile-programma's.

Houd rekening met de volgende punten wanneer u de locaties van uw serviceregio kiest:

  • Selecteer in de lijst met beschikbare Azure-regio's. U kunt de Azure-regio's zien die kunnen worden geselecteerd als serviceregio's op de pagina Producten per regio .
  • Kies regio's in de buurt van uw eigen locatie en de peeringlocaties tussen uw netwerk en Microsoft om de latentie van oproepen te verminderen.
  • Geef de voorkeur aan regionale paren om de hersteltijd te minimaliseren als er een storing in meerdere regio's optreedt.

Kies een beheerregio in de volgende lijst:

  • VS - oost
  • VS - west-centraal
  • Europa -west
  • Verenigd Koninkrijk Zuid
  • India - centraal
  • Canada - midden
  • Australië - oost

Beheerregio's kunnen worden gekoppeld aan serviceregio's. U wordt aangeraden de beheerregio te kiezen die zich het dichtst bij uw serviceregio's bevindt.

Notitie

Als u Azure Operator Call Protection Preview inschakelt, is de serviceregio die u selecteert mogelijk niet de Azure-regio waarin ondersteunende resources worden geïmplementeerd. Zie Azure-producten per regio voor de lijst met momenteel ondersteunde Azure Operator Call Protection-serviceregio's en neem contact op met uw onboardingteam als u vragen hebt over welke regio is geselecteerd.

Dienstverleningsovereenkomsten

Het betrouwbaarheidsontwerp dat in dit document wordt beschreven, wordt geïmplementeerd door Microsoft en kan niet worden geconfigureerd. Zie de SLA voor Azure Communications Gateway voor meer informatie over serviceovereenkomsten (SLA's) van Azure Communications Gateway.

Volgende stappen