Affidabilità nel servizio Azure Web PubSub

Azure Web PubSub Service è un servizio di messaggistica in tempo reale completamente gestito che consente la comunicazione bidirezionale tra server e client tramite il protocollo WebSocket. Una singola risorsa Web PubSub può essere ridimensionata a un milione di connessioni WebSocket simultanee. Il servizio supporta diversi modelli di messaggistica, tra cui trasmissione da server a client, messaggistica a gruppi denominati, pub/sub client e streaming di token di intelligenza artificiale.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere resiliente Azure Web PubSub Service a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, errori della zona di disponibilità e errori a livello di area. Descrive anche in che modo il servizio gestisce la manutenzione ed evidenzia le informazioni chiave sul contratto di servizio Azure Web PubSub.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per i carichi di lavoro di produzione, seguire queste raccomandazioni:

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

La risorsa creata è una risorsa PubSub Web. Si configura una risorsa con un numero di unità, che rappresenta la capacità della risorsa, incluso il numero massimo di connessioni simultanee. Per altre informazioni, vedere Performance guide for Azure Web PubSub Service.For more information, see Performance guide for Azure Web PubSub Service.

Una risorsa Web PubSub ha un endpoint univoco globale simile a contoso.webpubsub.azure.com. I client stabiliscono connessioni WebSocket a questo endpoint. I server applicazioni si connettono allo stesso endpoint per inviare messaggi e ricevere eventi dai client.

Per altre informazioni, vedere interni del servizio Azure Web PubSub.

Architettura fisica

Azure Web PubSub gestisce lo stato della connessione WebSocket e il routing dei messaggi in un set di risorse di calcolo. Microsoft gestisce l'infrastruttura sottostante. Non è possibile visualizzare o interagire direttamente con singole macchine virtuali usate dal servizio o con altri componenti dell'infrastruttura.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

WebSocket è un protocollo di connessione di lunga durata. Gli eventi di rete temporanei, i riavvii dell'infrastruttura back-end e le operazioni di manutenzione del servizio possono eliminare una connessione attiva. Una riconnessione di base ripristina la connessione, ma senza ulteriore logica il client perde i messaggi in transito o accodati durante l'interruzione.

Azure Web PubSub Servizio risolve questo problema tramite sottoprotocolli affidabili che si trovano sopra la connessione WebSocket grezza. Il sottoprotocolo tiene traccia della sequenza di messaggi e dello stato di connessione in modo che, quando una connessione viene interrotta, il client rinegozia con il servizio e riprende da dove è stato interrotto.

In genere non si verifica alcuna perdita di messaggi dopo che una connessione viene interrotta e ristabilita. Tuttavia, esistono alcune situazioni in cui potrebbe verificarsi una perdita di messaggi. Ad esempio, se il client si disconnette per più di un minuto e quindi si riconnette con lo stesso ID connessione, l'operazione di riconnessione mostra uno stato di errore per indicare che la perdita di messaggi può verificarsi.

Per sfruttare i vantaggi dei sottoprotocoli affidabili, seguire queste indicazioni:

• Se possibile, usare un SDK client Azure Web PubSub. L'SDK implementa automaticamente il sottoprotocolo affidabile. Non è necessaria alcuna configurazione aggiuntiva. Per altre informazioni, vedere:

  • Web PubSub SDK sul lato client per JavaScript
  • libreria di client .NET per Azure Web PubSub
  • Azure Web PubSub libreria client per Python
  • Azure libreria client WebPubSub per Java

• Se non è possibile usare l'SDK, implementare uno dei sottoprotocoli affidabili direttamente nel codice client WebSocket. Per istruzioni complete su specifiche e implementazioni, vedere Creare client WebSocket affidabili.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Azure Web PubSub Servizio supporta le distribuzioni con ridondanza tra zone quando si usa il livello Premium. Quando si crea o si aggiorna una risorsa PubSub Web di livello Premium in un'area che supporta le zone di disponibilità, la ridondanza della zona viene abilitata automaticamente. Il servizio distribuisce l'infrastruttura in più zone di disponibilità nell'area. Se una zona ha esito negativo, il servizio instrada il traffico all'infrastruttura in una zona integra.

Requisiti

• Supporto per l'area: La ridondanza della zona è supportata nella maggior parte delle aree in cui si applicano entrambe le condizioni seguenti:

  • Azure Web PubSub Service è disponibile. Per un elenco delle aree in cui è disponibile il servizio, vedere Disponibilità del prodotto per area.
  • La regione supporta le zone di disponibilità. Per un elenco di aree con zone di disponibilità, vedere elenco delle regioni di Azure.

  Tuttavia, Il Giappone occidentale attualmente non supporta la ridondanza della zona per Azure Web PubSub.

• Livello: La ridondanza della zona è disponibile nel livello Premium.

Costo

La ridondanza della zona non comporta costi aggiuntivi e si paga la tariffa standard del livello Premium. Per altre informazioni, vedere prezzi del servizio Azure Web PubSub.

Configurare il supporto delle zone di disponibilità

La ridondanza della zona non richiede alcuna configurazione oltre alla selezione del livello Premium. Viene abilitato automaticamente in entrambi questi casi:

• Creare una nuova risorsa Web PubSub ridondante a livello di zona. Selezionare uno SKU di livello Premium quando si crea la risorsa. Per altre informazioni, vedere Creare una risorsa Azure Web PubSub.

• Aggiornare una risorsa esistente al livello Premium. La ridondanza della zona viene abilitata automaticamente quando si aggiorna una risorsa esistente a uno SKU di livello Premium. L'aggiornamento da Standard a Premium non causa tempi di inattività del servizio. Per altre informazioni, vedere Scale an Azure Web PubSub Service instance.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando si configura una risorsa Azure Web PubSub per la ridondanza della zona e tutte le zone di disponibilità sono operative.

• Operazione cross-zone: Il servizio Azure Web PubSub gestisce automaticamente la distribuzione delle connessioni e delle operazioni tra le zone di disponibilità. L'infrastruttura in zone multiple elabora il traffico in un modello attivo-attivo. Non è necessario configurare alcun elemento per sfruttare questo comportamento. Il servizio instrada automaticamente i messaggi tra istanze tra zone, quindi un messaggio inviato da un client in una zona viene recapitato ai client connessi in qualsiasi altra zona.

• Replicazione dei dati tra zone: Il servizio Azure Web PubSub non memorizza i dati dei clienti in modo permanente. Il servizio gestisce i metadati della sessione, ad esempio lo stato della connessione e le informazioni sulla sequenza di messaggi per le connessioni attive. Questi metadati vengono replicati in modo sincrono tra le zone di disponibilità.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si configura una risorsa Azure Web PubSub per la ridondanza della zona e si verifica un'interruzione in una delle zone di disponibilità.

• Rilevamento e risposta: La piattaforma del servizio Azure Web PubSub è responsabile del rilevamento di errori in una zona di disponibilità. Non è necessario eseguire alcuna azione per avviare un failover di zona.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali problemi. È anche possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare i problemi.

• Richieste attive: Durante un errore di zona, le connessioni WebSocket attive all'infrastruttura nell'area interessata vengono eliminate. Se i client gestiscono correttamente gli errori temporanei , ad esempio riconnessione dopo un breve periodo di tempo, in genere evitano un impatto significativo.

• Spected data loss: Azure Web PubSub Service non rende persistenti i messaggi, quindi non è previsto che un errore di zona causi perdita di dati all'interno del servizio Azure Web PubSub. Tuttavia, tutte le connessioni attive vengono eliminate durante un evento di arresto della zona e pertanto tutti i dati che vengono trasmessi attivamente potrebbero essere persi.

  Se gli editori usano un SDK client di Azure Web PubSub o implementano i sottoprotocoli affidabili, i messaggi vengono riconosciuti dal servizio dopo che il servizio li riceve. Quando viene riconosciuto un messaggio, viene replicato in tutte le zone di disponibilità, quindi l'errore della zona dell'editore non causa la perdita del messaggio. Tuttavia, se un sottoscrittore non riceve il messaggio prima che venga eliminato, potrebbe non ricevere il messaggio.

• Tempo di inattività previsto: La riconnessione delle connessioni attive interrotte richiede in genere alcuni secondi. I client che implementano la logica di riconnessione riscontrano un'interruzione minima.

• Redistribution: Azure Web PubSub Service rileva la perdita della zona e ridistribuisce automaticamente il traffico tra le zone integre. Non è necessario eseguire alcuna azione.

Ripristino della zona

Quando una zona di disponibilità viene ripristinata, Azure Web PubSub servizio la reintegra automaticamente nella topologia del servizio attiva. Non è necessario eseguire alcuna azione per il ripristino della zona.

Dopo il ripristino di una zona, le nuove connessioni potrebbero essere indirizzate all'infrastruttura nella zona ripristinata. Le connessioni esistenti non verranno spostate o ribilanciate nella zona di recupero, ma saranno gradualmente ribilanciate man mano che si disconnettono e si riconnettono nel tempo. Lo squilibrio della connessione tra le zone non ha alcun impatto sul carico di lavoro.

Verifica dei guasti di zona

Azure Web PubSub Service gestisce automaticamente il routing del traffico, il failover e il ripristino della zona per le risorse del livello Premium con ridondanza zonale. Non è necessario avviare nulla. Poiché la ridondanza della zona è completamente gestita, non è necessario convalidare i processi di errore della zona di disponibilità.

Resilienza agli errori a livello di area

Il Servizio Azure Web PubSub è un servizio a regione singola. Se l'area non è più disponibile, anche la risorsa Web PubSub non è disponibile.

Per proteggere l'applicazione da un errore a livello di area, è possibile usare la replica geografica, disponibile nel livello Premium. In alternativa, è possibile creare una soluzione multiregione personalizzata distribuendo più risorse PubSub Web in aree diverse.

Geo-replication

La replica geografica consente di aggiungere replicas della risorsa Web PubSub in altre aree Azure. Tutte le repliche condividono un singolo endpoint (contoso.webpubsub.azure.com). Dietro questo endpoint, Gestione traffico di Azure usa il routing basato su DNS per indirizzare ogni client alla replica regionale più vicina integra. Se una regione ha un guasto, il Traffic Manager rileva l'errore tramite i controlli dello stato di integrità e arresta l'indirizzamento dei client a tale replica. Le nuove connessioni client vengono indirizzate automaticamente alla replica funzionante più vicina.

L'area in cui è stata creata la risorsa Web PubSub è chiamata area primaria, e la sua replica è la replica primaria. Il piano di controllo della risorsa primaria gestisce la configurazione della risorsa Web PubSub.

Requisiti

• Region support: È possibile aggiungere repliche in qualsiasi regione in cui è disponibile il Servizio Azure Web PubSub.
• Livello: È necessario usare il livello Premium per abilitare la replica geografica.
• Limite di replica: Ogni risorsa Web PubSub primaria supporta fino a otto repliche.

Considerations

• Ereditarietà della configurazione: Le repliche ereditano la maggior parte delle impostazioni di configurazione dalla risorsa primaria. Alcune impostazioni devono essere configurate separatamente in ogni replica. Per l'elenco completo delle impostazioni non ereditate, vedere Geo-replication in Azure Web PubSub.

• Modifiche alla configurazione: Il piano di controllo primario, nell'area primaria, elabora tutte le modifiche di configurazione alla risorsa PubSub Web. Se il piano di controllo primario non è disponibile, non sarà possibile aggiornare la configurazione delle risorse, anche se le repliche esistenti continueranno a elaborare il traffico dei dati senza interruzioni.

Costo

Ogni replica viene fatturata separatamente in base al proprio numero di unità e al volume dei messaggi in uscita. Se un messaggio viene trasferito tra repliche e quindi recapitato a un client o a un server in un'altra area, viene fatturato come messaggio in uscita. Per altre informazioni, vedere prezzi del servizio Azure Web PubSub.

Configurare la replica geografica

Per aggiungere o rimuovere una replica in una risorsa Web PubSub, vedere Geo-replication in Azure Web PubSub.

Pianificazione e gestione della capacità

Ogni replica gestisce il traffico in modo indipendente. Durante un failover regionale, i client dalla regione non funzionante si riconnettono alla replica funzionante più vicina. Per garantire che le repliche sopravvissute abbiano una capacità sufficiente per assorbire questo carico aggiuntivo, configurare ogni replica con unità in grado di gestire il traffico previsto completo del carico di lavoro, non solo la parte normalmente usata.

In alternativa, abilita la scalabilità automatica su ciascuna replica in modo che le unità possano effettuare automaticamente lo scale out in risposta a un carico maggiore. La scalabilità automatica continua a funzionare quando una replica secondaria non è disponibile, ma la scalabilità automatica non funziona se il piano di controllo primario non è disponibile. Per altre informazioni sulla scalabilità automatica, vedere Scala automaticamente le unità di un servizio Azure Web PubSub.

Per indicazioni generali sull'overprovisioning come strategia, vedere Gestire la capacità tramite overprovisioning.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configura Azure Web PubSub Servizio per la replica geografica e tutte le aree sono operative.

• Operazione tra le regioni: Gestione traffico di Azure instrada ogni client alla replica regionale funzionante più vicina. I client in aree geografiche diverse potrebbero connettersi a repliche diverse. Il servizio Web PubSub sincronizza i messaggi tra repliche in modo che i client connessi a qualsiasi replica possano comunicare tra loro.

• Replica dei dati tra aree: Quando un messaggio viene inviato a una replica, il servizio trasferisce in modo sincrono tale messaggio ad altre repliche in modo che i client connessi altrove possano riceverlo. Il sovraccarico di sincronizzazione è minimo per i modelli di messaggistica più comuni, ad esempio la trasmissione a gruppi di grandi dimensioni o la messaggistica di una singola connessione. La messaggistica a gruppi di piccole dimensioni (meno di 10 membri) potrebbe comportare un sovraccarico di sincronizzazione leggermente superiore.

  Il Servizio Azure Web PubSub non rende persistenti i messaggi; solo la consegna attiva viene sincronizzata tra le repliche.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando si configura Azure Web PubSub Servizio per la replica geografica ed è presente un'interruzione in una delle aree di replica.

• Rilevamento e risposta: Il servizio Web PubSub è responsabile del rilevamento di un errore in un'area e del reindirizzamento automatico del traffico in ingresso a una replica in una delle altre aree configurate.

• Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. Tuttavia:

  • È possibile usare Azure Integrità risorse per monitorare l'integrità di una singola risorsa ed è possibile configurare Integrità risorse avvisi per segnalare eventuali problemi.

  • È possibile usare integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli errori dell'area, ed è possibile configurare Avvii di integrità dei servizi per notificare i problemi.

• Richieste attive: Le connessioni WebSocket attive alla replica nell'area non riuscita vengono eliminate. I client devono riconnettersi dopo il failover della replica.

• Perdita di dati prevista: Azure Web PubSub Service non rende persistenti i messaggi. I messaggi che erano in transito verso i clienti nell'area interessata al momento del guasto potrebbero andare persi. Non è prevista alcuna perdita di dati persistente perché il servizio non archivia i dati dei clienti.

• Expected downtime: Gestione traffico di Azure esegue controlli di integrità su ogni replica. Quando un'interruzione dell'area causa l'esito negativo del controllo di integrità di una replica, Gestione traffico rimuove l'endpoint della replica dai risultati della risoluzione DNS. Dopo aver rimosso l'endpoint, il TTL DNS di 90 secondi deve trascorrere prima che i client vedano i record DNS aggiornati. In totale, la transizione richiede in genere alcuni minuti. I client ben progettati che implementano la logica di riconnessione possono riprendere il normale funzionamento dopo la riconnessione alla replica integra.

  Se il piano di controllo primario non è disponibile, non è possibile apportare modifiche alla configurazione della risorsa Web PubSub o alle relative repliche. Tuttavia, le connessioni WebSocket continuano a funzionare nelle repliche integre.

• Redistribution: Gestione traffico di Azure indirizza le richieste in ingresso a repliche funzionanti. Tuttavia, se un client tenta di riconnettersi prima che Gestione traffico di Azure abbia rilevato il failover della replica e le voci DNS aggiornate siano state propagate al client, il tentativo di riconnessione di un client potrebbe continuare a raggiungere l'area non disponibile e potrebbe non riuscire.

  Dopo la propagazione dell'aggiornamento DNS, i client che si riconnettono vengono instradati automaticamente alla replica funzionante più vicina.

Ripristino della regione

Quando la regione non funzionante viene ripristinata, il controllo integrità del Traffic Manager rileva la replica ripristinata e include nuovamente il suo endpoint nella risoluzione DNS. I client attualmente connessi ad altre repliche non sono interessati e rimangono connessi finché non si disconnettono. Le nuove connessioni vengono nuovamente instradate alla replica della regione ripristinata quando è la replica funzionante più vicina.

Testare gli errori dell'area

Per simulare un failover dell'area e testare il comportamento di riconnessione dell'applicazione client, è possibile disabilitare l'endpoint di una replica. Questa azione fa sì che Gestione traffico interrompa il routing del traffico verso tale replica, che consente di osservare il comportamento dei client quando la replica a cui si connettono diventa non disponibile. Per i passaggi dettagliati, vedere Disabilitare o abilitare l'endpoint di replica.

Soluzioni di multiregione personalizzate per la resilienza

Se è necessaria la resilienza tra aree, ma non si usa la replica geografica, è possibile distribuire e gestire risorse Web PubSub separate in più aree e implementare la logica di failover nel server applicazioni. Questo approccio è più complesso rispetto alla replica geografica e non supporta il passaggio senza interruzioni per la connessione tra client. Per una panoramica dettagliata dell'architettura, le strategie di failover e le linee guida per i test, vedere Resilienza e ripristino di emergenza nel Servizio Azure Web PubSub.

Backup e ripristino

Azure Web PubSub Service è un servizio di messaggistica stateless. Non rende persistenti i messaggi dei clienti e non dispone di funzionalità di backup o ripristino.

Per proteggere la configurazione delle tue risorse, definisci le risorse Web PubSub usando l'infrastruttura come codice (IaC) (ad esempio Bicep o modelli ARM) e archivia tali definizioni nel controllo del codice sorgente. Se è necessario ricreare una risorsa, ridistribuirla dalla configurazione archiviata.

Resilienza alla manutenzione del servizio

Microsoft applica regolarmente gli aggiornamenti del servizio ed esegue altre operazioni di manutenzione. La piattaforma Azure gestisce automaticamente queste attività, garantendo che la manutenzione sia fluida e trasparente per l'utente. Non è previsto alcun tempo di inattività durante gli eventi di manutenzione, a meno che non ti sia stato comunicato tramite la manutenzione pianificata di integrità dei servizi di Azure.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Contenuti correlati

• Che è Azure Web PubSub servizio?
• Georeplicazione in Azure Web PubSub
• Resilienza e ripristino di emergenza nel servizio Azure Web PubSub
• Scala un'istanza del Servizio Web PubSub di Azure
• Unità di scala automatica di un servizio di Azure Web PubSub
• Affidabilità in Azure