Affidabilità nel gateway di comunicazione di Azure

  • Articolo

Il gateway di comunicazione di Azure garantisce che il servizio sia affidabile usando i meccanismi di ridondanza di Azure e il comportamento di ripetizione dei tentativi specifico di SIP. La rete deve soddisfare requisiti specifici per garantire la disponibilità del servizio.

Modello di ridondanza di Gateway di comunicazione di Azure

Le distribuzioni di Gateway di comunicazione di Azure di produzione (dette anche distribuzioni standard) sono costituite da tre aree separate: un'area di gestione e due aree del servizio. Le distribuzioni del lab sono costituite da un'area di gestione e da un'area del servizio.

Questo articolo descrive i due diversi tipi di area e i relativi modelli di ridondanza distinti. Copre sia l'affidabilità a livello di area con le zone di disponibilità che l'affidabilità tra aree con il ripristino di emergenza. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.

Diagramma di due aree del servizio, un'area di gestione e due siti di operatore.

Aree del servizio

Le aree del servizio contengono l'infrastruttura vocale e API usata per gestire il traffico tra la rete e i servizi di comunicazione scelti.

Le distribuzioni di Gateway di comunicazione di Azure di produzione hanno due aree di servizio distribuite in modalità attiva-attiva( come richiesto dai programmi Connessione con operatore e Teams Telefono Per dispositivi mobili). Il failover rapido tra le aree del servizio viene fornito a livello di infrastruttura/IP e a livello di applicazione (SIP/RTP/HTTP).

Le aree del servizio contengono anche l'infrastruttura per l'API di provisioning del gateway di comunicazione di Azure.

Suggerimento

Le distribuzioni di produzione devono avere sempre due aree di servizio, anche se una delle aree del servizio scelta si trova in un'area geografica di Azure a singola area(ad esempio, Qatar). Se si sceglie un'area geografica di Azure a singola area, scegliere una seconda area di Azure in un'area geografica di Azure diversa.

Le aree del servizio sono identiche nel funzionamento e offrono resilienza sia agli errori di zona che a livello di area. Ogni area del servizio può trasportare il 100% del traffico usando l'istanza del gateway di comunicazione di Azure. Di conseguenza, gli utenti finali devono comunque essere in grado di effettuare e ricevere chiamate correttamente durante qualsiasi tempo di inattività della zona o dell'area.

Le distribuzioni del lab hanno un'area del servizio.

Requisiti di routing delle chiamate

Il gateway di comunicazione di Azure offre un modello di ridondanza di successo: le chiamate gestite da peer con errori vengono terminate, ma le nuove chiamate vengono instradate a peer integri. Questo modello rispecchia il modello di ridondanza fornito da Microsoft Teams.

Per le distribuzioni di produzione, si prevede che la rete disponga di due siti con ridondanza geografica. Ogni sito deve essere associato a un'area del gateway di comunicazione di Azure. Il modello di ridondanza si basa sulla connettività incrociata tra le aree del servizio Gateway di comunicazione di Azure e di rete.

Diagramma di due siti operatore e due aree di servizio. Entrambe le aree del servizio si connettono a entrambi i siti, con route primarie e secondarie.

Le distribuzioni del lab devono connettersi a un sito nella rete.

Ogni area del servizio Gateway di comunicazione di Azure fornisce un record SRV. Questo record contiene tutti i peer SIP che forniscono la funzionalità SBC (per il routing delle chiamate ai servizi di comunicazione) all'interno dell'area. Questo record SRV può puntare a qualsiasi indirizzo IP nell'intervallo IP /28 fornito dal team di onboarding.

Se il gateway di comunicazione di Azure include il punto di controllo mobile (MCP), ogni area del servizio fornisce un record SRV aggiuntivo per MCP. Ogni record MCP per area contiene MCP all'interno dell'area con priorità superiore e MCP nell'altra area con priorità inferiore.

Ogni sito nella rete deve:

  • Inviare il traffico all'area del servizio Gateway di comunicazione di Azure locale per impostazione predefinita.
  • Individuare i peer di Gateway di comunicazione di Azure all'interno di un'area usando DNS SRV, come descritto in RFC 3263.
    • Eseguire una ricerca SRV DNS nel nome di dominio per la connessione dell'area del servizio alla rete usando _sip._tls.<regional-FQDN-from-portal>. Sostituire <regional-FQDN-from-portal> con gli FQDN per area dai campi Nome host nella pagina Panoramica della risorsa nel portale di Azure. Ad esempio, se la distribuzione usa commsgw.azure.com nomi di dominio, cercare _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com la prima area.
    • Se la ricerca SRV restituisce più destinazioni, usare il peso e la priorità di ogni destinazione per selezionare una singola destinazione.
  • Inviare nuove chiamate ai peer di Gateway di comunicazione di Azure disponibili.
  • Essere in grado di ricevere traffico da qualsiasi indirizzo IP in ognuno degli intervalli IP associati al gateway di comunicazione di Azure.

Quando la rete instrada le chiamate ai peer SIP del gateway di comunicazione di Azure per la funzione SBC, deve:

  • Usare LE OPZIONI SIP (o una combinazione di OPZIONI e traffico SIP) per monitorare la disponibilità dei peer SIP del gateway di comunicazione di Azure.
  • Riprovare INVITEs che hanno ricevuto 408 risposte, 503 risposte o 504 risposte o non hanno ricevuto risposte, reindirizzandole ad altri peer disponibili nel sito locale. Eseguire la ricerca nell'altra area del servizio (definita dal record SRV dell'altra area) solo se tutti i peer nell'area del servizio locale non sono riusciti.
  • Non ripetere mai le chiamate che ricevono risposte di errore diverse da 408, 503 e 504.

Se la distribuzione di Gateway di comunicazione di Azure include un punto di controllo mobile integrato (MCP), la rete deve eseguire le operazioni seguenti per MCP:

  • Rilevare quando MCP in un'area non è disponibile, contrassegnare le destinazioni per il record SRV dell'area come non disponibile e riprovare periodicamente a determinare quando l'area è nuovamente disponibile. MCP non risponde alle OPZIONI SIP.
  • Gestire le risposte 5xx da MCP in base ai criteri dell'organizzazione. Ad esempio, è possibile ritentare la richiesta oppure consentire alla chiamata di continuare senza passare attraverso il gateway di comunicazione di Azure e in Telefono Microsoft Sistema.

I dettagli di questo comportamento di routing sono specifici della rete. È necessario accettarli con il team di onboarding durante il progetto di integrazione.

Aree di gestione

Le aree di gestione contengono l'infrastruttura usata per l'ordinamento, il monitoraggio e la fatturazione del gateway di comunicazione di Azure. Tutte le infrastrutture all'interno di queste aree vengono distribuite in modo con ridondanza della zona, ovvero tutti i dati vengono replicati automaticamente in ogni zona di disponibilità all'interno dell'area. Tutti i dati di configurazione critici vengono replicati anche in ognuna delle aree del servizio per garantire il corretto funzionamento del servizio durante un errore dell'area di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.

Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.

Esperienza di arresto della zona per le aree del servizio

Durante un'interruzione a livello di zona, le chiamate gestite dalla zona interessata vengono terminate, con una breve perdita di capacità all'interno dell'area fino a quando il servizio non ribilancia le risorse sottostanti in zone integre. Questa riparazione automatica non dipende dal ripristino della zona; è previsto che lo stato di riparazione automatica del servizio gestito da Microsoft compensa una zona persa, usando la capacità di altre zone. Il traffico che trasporta le risorse viene distribuito in modo ridondante della zona, ma il traffico su scala più bassa potrebbe essere gestito da una singola risorsa. In questo caso, i meccanismi di failover descritti in questo articolo ribilanciano tutto il traffico verso l'altra area del servizio, mentre le risorse che trasportano il traffico vengono ridistribuite in una zona integra.

Esperienza di arresto della zona per l'area di gestione

Durante un'interruzione a livello di zona non è necessaria alcuna azione durante il ripristino della zona. L'area di gestione si auto-guarisce e si ribilancia per sfruttare automaticamente la zona sana.

Ripristino di emergenza: fallback in altre aree

Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.

Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.

Questa sezione descrive il comportamento del gateway di comunicazione di Azure durante un'interruzione a livello di area.

Ripristino di emergenza: failover tra aree per le aree del servizio

Durante un'interruzione a livello di area, i meccanismi di failover descritti in questo articolo (polling OPTIONS e tentativi SIP in caso di errore) ribilanciano tutto il traffico delle chiamate verso l'altra area del servizio, mantenendo la disponibilità. Si inizierà a ripristinare la ridondanza a livello di area. Il ripristino della ridondanza a livello di area durante i tempi di inattività estesi potrebbe richiedere l'uso di altre aree di Azure. Se è necessario eseguire la migrazione di un'area non riuscita in un'altra area, è necessario consultare prima di avviare le migrazioni.

La funzione SBC nel gateway di comunicazione di Azure fornisce il polling OPTIONS per consentire alla rete di determinare la disponibilità peer. Per MCP, la rete deve essere in grado di rilevare quando MCP non è disponibile e riprovare periodicamente per determinare quando MCP è nuovamente disponibile. MCP non risponde alle OPZIONI SIP.

I client DELL'API di provisioning contattano Il gateway di comunicazione di Azure usando il nome di dominio di base per la distribuzione. Il record DNS per questo dominio ha una durata (TTL) di 60 secondi. Quando un'area ha esito negativo, Azure aggiorna il record DNS per fare riferimento a un'altra area, in modo che i client che effettuano una nuova ricerca DNS ricevano i dettagli della nuova area. È consigliabile assicurarsi che i client possano effettuare una nuova ricerca DNS e ripetere una richiesta di 60 secondi dopo un timeout o una risposta 5xx.

Suggerimento

Le distribuzioni lab non offrono il failover tra aree (perché hanno una sola area del servizio).

Ripristino di emergenza: failover tra aree per le aree di gestione

Il traffico vocale e il provisioning tramite il portale di gestione dei numeri non sono interessati da errori nell'area di gestione, perché le risorse di Azure corrispondenti sono ospitate nelle aree del servizio. Gli utenti del portale di gestione dei numeri potrebbero dover eseguire di nuovo l'accesso.

I servizi di monitoraggio potrebbero non essere temporaneamente disponibili fino a quando il servizio non è stato ripristinato. Se l'area di gestione riscontra tempi di inattività prolungati, si eseguirà la migrazione delle risorse interessate a un'altra area disponibile.

Scelta delle aree di gestione e servizio

Una singola distribuzione di Gateway di comunicazione di Azure è progettata per gestire il traffico all'interno di un'area geografica. Distribuire entrambe le aree del servizio in una distribuzione di produzione all'interno della stessa area geografica, ad esempio America del Nord. Questo modello garantisce che la latenza nelle chiamate vocali rimanga entro i limiti richiesti dai programmi Connessione con operatore e Teams Telefono Per dispositivi mobili.

Quando si scelgono le località dell'area del servizio, tenere presenti i punti seguenti:

  • Selezionare dall'elenco delle aree di Azure disponibili. È possibile visualizzare le aree di Azure che possono essere selezionate come aree di servizio nella pagina Prodotti per area .
  • Scegliere le aree nelle vicinanze dell'ambiente locale e le posizioni di peering tra la rete e Microsoft per ridurre la latenza delle chiamate.
  • Preferire coppie di aree per ridurre al minimo il tempo di ripristino se si verifica un'interruzione in più aree.

Scegliere un'area di gestione dall'elenco seguente:

  • Stati Uniti orientali
  • Stati Uniti centro-occidentali
  • Europa occidentale
  • Regno Unito meridionale
  • India centrale
  • Canada centrale
  • Australia orientale

Le aree di gestione possono essere collocate in un percorso condiviso con le aree del servizio. È consigliabile scegliere l'area di gestione più vicina alle aree del servizio.

Nota

Se si abilita l'anteprima di Protezione chiamata operatore di Azure, l'area del servizio selezionata potrebbe non essere l'area di Azure in cui vengono distribuite le risorse di supporto. Vedere Prodotti Azure per area per l'elenco delle aree del servizio Protezione chiamate operatore di Azure attualmente supportate e rivolgersi al team di onboarding se si hanno domande su quale area è selezionata.

Contratti di servizio

La progettazione dell'affidabilità descritta in questo documento viene implementata da Microsoft e non è configurabile. Per altre informazioni sui contratti di servizio del gateway di comunicazione di Azure, vedere contratto di servizio del gateway di comunicazione di Azure.

Passaggi successivi