Affidabilità in Servizio Azure SignalR

Servizio Azure SignalR è un servizio completamente gestito che consente la comunicazione bidirezionale in tempo reale nelle applicazioni Web e per dispositivi mobili. Asttrae il meccanismo di trasporto sottostante. Quando sono disponibili WebSocket, il servizio li usa. Quando non lo sono, si ricorre agli eventi Server-Sent o al long polling. Questa astrazione significa che il codice client e server può comunicare in tempo reale senza essere associato a un protocollo di trasporto specifico.

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 Servizio Azure SignalR resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni dell'area e manutenzione del servizio. Vengono inoltre evidenziate informazioni chiave sul contratto di servizio Servizio Azure SignalR.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per i carichi di lavoro di produzione, è consigliabile:

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 Servizio SignalR. 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 Servizio Azure SignalR.For more information, see Performance guide for Servizio Azure SignalR.

Servizio Azure SignalR supporta due modalità service. In modalità predefinita, i server app si connettono alla risorsa Servizio Azure SignalR e contengono la logica dell'hub. In modalità serverless, il servizio si integra con Funzioni di Azure e Funzioni funge da gestori di messaggi basati su eventi, in modo da non gestire direttamente i server app. Per altre informazioni, vedere Modalità di servizio nel Servizio Azure SignalR.

Una risorsa Servizio SignalR ha un endpoint univoco globale simile a contoso.service.signalr.net. I client stabiliscono connessioni a questo endpoint. I server applicazioni si connettono allo stesso endpoint per inviare messaggi e ricevere eventi dai client.

Architettura fisica

Servizio Azure SignalR gestisce lo stato della connessione 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.

Servizio Azure SignalR usa connessioni di lunga durata tra client, server app e servizio. Queste connessioni possono essere eliminate a causa di errori temporanei, ad esempio instabilità della rete, riconfigurazioni del servizio di bilanciamento del carico o sospensioni delle schede del browser. Progetta le applicazioni client e i server delle applicazioni per gestire le interruzioni di connessione e riconnettersi automaticamente.

Gli SDK Servizio Azure SignalR includono la gestione della riconnessione predefinita per le connessioni server al servizio. La riconnessione lato client dipende dalla libreria client usata. ASP.NET Core i client SignalR supportano la riconnessione con stato, che consente a un client di riprendere la connessione precedente senza perdere lo stato se si riconnette rapidamente usando lo stesso ID connessione. Se la riconnessione genera un nuovo ID connessione, ad esempio dopo un'interruzione più lunga, il servizio considera il client come nuova connessione. In questo caso, il client deve ricongiuscrirsi a tutti i gruppi in cui si trovava in precedenza e ripristinare qualsiasi stato della sessione.

Per indicazioni dettagliate sulla progettazione dell'applicazione per gestire le disconnessioni e le riconnessioni client, vedere Informazioni su disconnessioni e riconnessioni client in Servizio Azure SignalR.

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.

Servizio Azure SignalR supporta le distribuzioni con ridondanza geografica nel livello Premium. Quando si crea o si esegue l'aggiornamento a una risorsa di livello Premium in un'area che supporta le zone di disponibilità, Servizio Azure SignalR distribuisce automaticamente la capacità di calcolo in tutte le zone di disponibilità nell'area. Se una zona di disponibilità ha esito negativo, Servizio Azure SignalR instrada le nuove connessioni alle istanze nelle zone integre rimanenti.

Requisiti

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

  • Servizio Azure SignalR è 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 Servizio Azure SignalR.

• 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 tariffe di Servizio Azure SignalR.

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:

• Crea una nuova risorsa Servizio SignalR con ridondanza zonale. Selezionare uno SKU di livello Premium quando si crea la risorsa. Per ulteriori informazioni, vedere gli avvi rapidi, ad esempio Avvio rapido: Creare una chat room usando Servizio SignalR.

• 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 Modificare il piano di Servizio Azure SignalR.

Comportamento quando tutte le zone sono integre

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

• Operazione cross-zone: Servizio Azure SignalR gestisce automaticamente il modo in cui le connessioni e le operazioni vengono distribuite 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.

• Replica di dati tra zone: Servizio Azure SignalR non rende persistenti i dati dei clienti, quindi non ci sono dati da replicare tra le zone. Lo stato della connessione è temporaneo ed è associato a ogni connessione attiva.

Comportamento durante un errore di zona

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

• Rilevamento e risposta: La piattaforma Servizio Azure SignalR è responsabile del rilevamento di un errore 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 attive ai nodi nella zona 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.

• Perdita di dati specificata: Servizio Azure SignalR non rende persistenti i messaggi, quindi non è previsto un errore di zona che causa la perdita di dati all'interno del Azure SignalR service. 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.

• 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: Servizio Azure SignalR 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, Servizio Azure SignalR reintegrarla 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

Servizio Azure SignalR gestisce automaticamente il routing del traffico, il failover e il ripristino della zona per le risorse del livello Premium con ridondanza della zona. 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

Servizio Azure SignalR è un servizio a singola area. Se l'area non è più disponibile, anche la risorsa Servizio SignalR 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 di multiregione personalizzata distribuendo più risorse Servizio SignalR in aree diverse.

Geo-replication

La replica geografica consente di aggiungere replicas della risorsa Servizio SignalR in altre aree Azure. Gestione traffico di Azure usa il routing basato su DNS per indirizzare ogni client alla replica regionale più vicina. 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 Servizio Azure SignalR è denominata area primary e la relativa replica è la replica primary. Il piano control della risorsa primaria gestisce la configurazione della risorsa Servizio Azure SignalR.

Requisiti

• Region support: È possibile aggiungere repliche in qualsiasi area in cui è disponibile Servizio Azure SignalR.
• Livello: È necessario usare il livello Premium per abilitare la replica geografica.
• Replica limit: Ogni risorsa Servizio SignalR primaria supporta fino a otto repliche.

Considerazioni

• 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, si può consultare Geo-replication in Servizio Azure SignalR.

• Configuration changes: Il piano di controllo primario, nell'area primaria, elabora le modifiche di configurazione alla risorsa Servizio SignalR. 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. Le tariffe in uscita tra aree si applicano quando i messaggi vengono trasferiti tra repliche e recapitati a client o server in un'altra area. Per ulteriori informazioni, vedere i prezzi di Servizio Azure SignalR.

Configurare la replica geografica

Per aggiungere o rimuovere una replica da una risorsa di Servizio SignalR, vedere Geo-replicazione in Servizio Azure SignalR.

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 Autoscaling in Servizio Azure SignalR.

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 Servizio Azure SignalR per la replica geografica e tutte le repliche 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. Servizio SignalR 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.

  Servizio Azure SignalR non rende persistenti i messaggi. Solo il recapito attivo viene sincronizzato tra le repliche.

Comportamento durante un errore di area

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

• Rilevamento e risposta: Servizio SignalR è responsabile del rilevamento di un errore in un'area geografica 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 Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

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

• Possibile perdita di dati: Servizio Azure SignalR non conserva 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 Servizio SignalR o alle relative repliche. Tuttavia, le connessioni continuano a funzionare nelle repliche sane.

• 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 personalizzate in più aree per la resilienza

Se è necessaria la resilienza tra aree, ma non si usa la replica geografica, è possibile distribuire e gestire risorse Servizio SignalR 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, i modelli di failover e le linee guida per i test, vedere Resiliency e ripristino di emergenza in Servizio Azure SignalR.

Backup e ripristino

Servizio Azure SignalR è un servizio di messaggistica senza stato. Non rende persistenti i messaggi dei clienti e non dispone di funzionalità di backup o ripristino.

Per proteggere la configurazione delle risorse, definisci le risorse del servizio SignalR utilizzando l'infrastruttura come codice (ad esempio Bicep o modelli di Resource Manager) e salva 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.

Durante la manutenzione pianificata, Servizio Azure SignalR usa una strategia di arresto normale per ridurre l'impatto sui client connessi. Le connessioni vengono disconnesse gradualmente in un intervallo di tempo impostato, consentendo ai client di riconnettersi progressivamente anziché contemporaneamente. Per altre informazioni, vedere Disconnessione durante la manutenzione del servizio.

Gli eventi di manutenzione vengono visualizzati ai client man mano che la connessione diminuisce. Assicurarsi che le applicazioni client implementino la logica di riconnessione in modo che possano eseguire il ripristino da disconnessioni correlate alla manutenzione senza interruzioni visibili dall'utente.

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

• Affidabilità in Azure
• Panoramica di Servizio Azure SignalR
• Replicazione geografica nel servizio Azure SignalR
• Resilienza e ripristino di emergenza nel Servizio Azure SignalR
• Comprendere le disconnessioni e le riconnessioni dei client in Servizio Azure SignalR