Affidabilità in Hub di notifica di Azure

Hub di notifica di Azure consente di gestire le notifiche push in più sistemi PNS (Platform Notification System), ad esempio Apple Push Notification Service (APN), Firebase Cloud Messaging (FCM) e Windows Push Notification Service (WNS).

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 resilienti hub di notifica a vari potenziali interruzioni e problemi, tra cui errori temporanei, errori della zona di disponibilità, errori a livello di area e manutenzione del servizio. Vengono inoltre descritte le opzioni di backup e ripristino e le informazioni chiave sul contratto di servizio di Hub di notifica.

Raccomandazioni per la distribuzione di produzione

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

Panoramica dell'architettura di affidabilità

Hub di notifica di Azure è organizzato intorno agli spazi dei nomi e agli hub di notifica. Uno spazio dei nomi è un limite di gestione che contiene uno o più hub. Gli hub rappresentano gli endpoint per un'applicazione. I dispositivi si registrano con tali endpoint usando registrazioni o installazioni, che consentono al servizio di inviare notifiche push ai dispositivi. Per altre informazioni, vedere Gestione della registrazione.

Hub di notifica invia notifiche push ai sistemi di notifica della piattaforma (PNS), ad esempio Apple Push Notification Service (APN) e Firebase Cloud Messaging (FCM). Il recapito delle notifiche end-to-end dipende dalla disponibilità di Hub di notifica e dal comportamento dei provider PNS downstream.

Per la pianificazione dell'affidabilità, è importante distinguere tra i tipi di dati seguenti gestiti da Hub di notifica:

• Metadati: Configurazione dello spazio dei nomi e dell'hub, comprese le informazioni di connessione e la configurazione del disaster recovery.
• Dati di registrazione: Registrazioni e installazioni di dispositivi che associano utenti e dispositivi a tag e modelli.

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 ulteriori informazioni, vedi Raccomandazioni per la gestione di errori temporanei.

Hub di notifica gestisce automaticamente gli errori temporanei che si verificano durante la connessione a un PNS. Tuttavia, si è responsabili della gestione degli errori temporanei quando i servizi o i dispositivi degli utenti interagiscono con Hub di notifica. Gli errori temporanei possono verificarsi durante le operazioni di registrazione, le operazioni di invio delle notifiche e le operazioni di gestione. Seguire queste indicazioni:

• Registrazioni e installazioni: Le applicazioni nei dispositivi devono ripetere le operazioni di registrazione e installazione che hanno esito negativo a causa di errori temporanei. Gli SDK forniti da Microsoft gestiscono automaticamente i nuovi tentativi. Se non è possibile usare gli SDK forniti, implementare una logica di ritentativo con backoff esponenziale e jitter e rendere idempotenti, ove possibile, le operazioni di registrazione.

  La creazione o l'aggiornamento di un'installazione è idempotente, quindi è possibile ripetere l'operazione in modo sicuro. Quando possibile, usare installazioni anziché registrazioni.

• Invio di notifiche e operazioni di gestione: Usa un SDK fornito da Microsoft per inviare notifiche push ed eseguire operazioni di gestione. Questi SDK riprovano automaticamente quando si verificano errori temporanei.

  Se non puoi utilizzare gli SDK forniti, implementa una logica di ritentativo con backoff esponenziale e jitter e, ove possibile, rendi idempotenti le operazioni di invio delle notifiche.

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.

Nelle regioni che supportano le zone di disponibilità, i namespace di Notification Hubs supportano una configurazione con ridondanza di zona. Hub di notifica abilita automaticamente la ridondanza della zona per tutti gli spazi dei nomi in alcune aree. Quando la ridondanza della zona è abilitata, Microsoft replica sia i metadati che i dati di registrazione in tutte le zone di disponibilità nell'area.

Requirements

• Supporto per l'area:

  Notification Hubs abilita automaticamente la ridondanza di zona per tutti gli spazi dei nomi nelle regioni seguenti. Non è possibile disabilitare la ridondanza della zona in queste aree:

  Europa	Medio Oriente	Africa	Asia Pacifico
  Francia centrale	Qatar Central	Sudafrica settentrionale	Cina settentrionale 3
  Italy North			Korea Central
  Norway East
  Poland Central
  Svezia centrale
  Svizzera settentrionale

  In altre aree che supportano Hub di notifica e hanno zone di disponibilità, la ridondanza della zona è facoltativa. È possibile abilitarla solo quando si crea uno spazio dei nomi.

• Supporto per i livelli: È possibile usare le zone di disponibilità con tutti i livelli di Hub di notifica.

Cost

La ridondanza di zona comporta un costo aggiuntivo oltre al prezzo del livello. Per altre informazioni, vedere Prezzi di Hub di notifica.

Configurare il supporto delle zone di disponibilità

• Creare un nuovo spazio dei nomi con ridondanza della zona: Il processo per creare un nuovo spazio dei nomi con ridondanza della zona dipende dall'area usata:

  • Nelle aree in cui Hub di notifica abilita automaticamente la ridondanza della zona, non è necessario configurarla.

    Importante

    In queste aree, Notification Hubs crea sempre spazi dei nomi con la ridondanza della zona abilitata, anche se una distribuzione tramite codice, ad esempio un file Bicep o un modello di Azure Resource Manager, specifica che la ridondanza della zona è disabilitata.

    Se non si desidera un namespace con ridondanza di zona, createlo in un'area geografica che supporta la ridondanza di zona opzionale.

  • Nelle regioni in cui la ridondanza della zona è facoltativa, è possibile abilitarla solo al momento della creazione di uno spazio dei nomi. Per informazioni su come configurare un nuovo spazio dei nomi con ridondanza della zona, vedere Creare un hub di notifica Azure nel portale di Azure.

• Rendere ridondante una zona dello spazio dei nomi esistente: Hub di notifica non supporta la migrazione sul posto di uno spazio dei nomi esistente al supporto della zona di disponibilità. È necessario distribuire un nuovo spazio dei nomi e spostare le registrazioni in tale spazio dei nomi. Seguire le indicazioni in Spostare le risorse tra aree di Azure, che si applicano anche se si distribuisce il nuovo spazio dei nomi nella stessa area.

Comportamento quando tutte le zone sono integre

Questa sezione descrive che cosa aspettarsi quando si configura uno spazio dei nomi di Notification Hubs per la ridondanza di zona, quando tutte le zone sono operative.

• Operazione tra zone: Hub di notifica distribuisce e gestisce automaticamente le richieste usando l'infrastruttura in qualsiasi zona dell'area.

• Replica dei dati tra zone: I dati di registrazione e i metadati vengono replicati in modo sincrono in tutte le zone nell'area specificata.

Comportamento durante un errore di zona

Questa sezione descrive che cosa aspettarsi quando si configura uno spazio dei nomi di Notification Hubs per la ridondanza tra zone e si verifica un'interruzione in una delle zone.

• Rilevamento e risposta: Microsoft rileva gli errori della zona e gestisce il failover all'interno dell'area. Non è necessario avviare il failover.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia 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 eventuali problemi.

• Richieste attive: Le operazioni di gestione in corso, le registrazioni dei dispositivi e le nuove richieste di invio di notifiche potrebbero non riuscire durante il failover. Le applicazioni devono ritentare le operazioni non riuscite seguendo le indicazioni sulla gestione degli errori temporanei.

• Perdita di dati prevista: La perdita di dati non è prevista durante un'interruzione a singola zona perché Hub di notifica replica in modo sincrono lo spazio dei nomi e i dati di configurazione e registrazione dell'hub tra zone di disponibilità.

  Questa replica non è un backup. Nel modello di responsabilità condivisa, si è responsabili del backup dei dati di registrazione e installazione. Per altre informazioni, vedere Backup e ripristino.

• Tempo di inattività previsto: È possibile una breve interruzione del servizio mentre Microsoft reindirizza il traffico. Seguire le indicazioni sulla gestione degli errori temporanei per preparare le applicazioni per queste interruzioni.

• Ridistribuzione: Il servizio reindirizza automaticamente le richieste alle zone integre.

Ripristino della zona

Quando la zona interessata viene ripristinata, non è necessario eseguire alcuna azione. Microsoft ripristina e ribilancia l'infrastruttura di Hub di notifica per usare la zona ripristinata.

Verifica dei guasti di zona

Non è possibile attivare direttamente un failover della zona di Hub di notifica. Per verificare il comportamento del carico di lavoro, eseguire test di resilienza per nuovi tentativi, idempotenza e guasti delle dipendenze in ambienti di non produzione. È anche possibile usare Azure Chaos Studio per testare i componenti dell'applicazione circostanti.

Resilienza agli errori a livello di area

Notification Hubs fornisce il ripristino di emergenza dei metadati replicando i metadati dello spazio dei nomi tra aree geografiche, ma non replica i dati di registrazione dei dispositivi. Questa funzionalità richiede un intervento manuale durante un'interruzione dell'area e comporta tempi di inattività per l'hub di notifica.

Se è necessario ridurre i tempi di inattività e l'intervento manuale durante il failover, è consigliabile usare una soluzione multiregione personalizzata.

ripristino di emergenza geografico dei metadati gestiti da Microsoft

Hub di notifica supporta il ripristino di emergenza dei metadati gestiti da Microsoft in un'area di Azure secondaria. Se l'area primaria ha un'area abbinata, è possibile selezionare l'area abbinata. Indipendentemente dallo stato di associazione dell'area primaria, è anche possibile scegliere un'area secondaria da un elenco di aree di ripristino flessibili. Hub di notifica replica quindi i metadati dello spazio dei nomi, ad esempio il nome dello spazio dei nomi, le stringhe di connessione e altre informazioni critiche.

Microsoft è responsabile della dichiarazione di emergenza e dell'avvio del failover. Quando ciò accade, Microsoft crea un nuovo spazio dei nomi nell'area geografica secondaria. Poiché usa i metadati dell'area primaria, le applicazioni possono connettersi a tale spazio dei nomi usando il nome dello spazio dei nomi esistente, stringa di connessione e i nomi dell'hub.

Requirements

• Supporto per l'area: Nelle aree Azure abbinate, lo spazio dei nomi può usare l'area associata Azure come area secondaria.

  Se lo spazio dei nomi si trova in un'area non abbinata o se si desidera replicare i dati in un'area diversa, è possibile selezionare una delle aree di ripristino flessibili seguenti come area secondaria:

  Americas	Europa	Africa	Asia Pacifico
  Brasile meridionale	North Europe	Sudafrica settentrionale	Australia East
  West US 2 (Regione Ovest degli Stati Uniti 2)			Southeast Asia

• Supporto per i livelli: Le opzioni di ripristino di emergenza dei metadati sono disponibili in tutti i livelli di Hub di notifica.

Cost

Notification Hubs non prevede costi aggiuntivi per configurare o usare il ripristino di emergenza geografico dei metadati. Tuttavia, si paga per la larghezza di banda tra aree usate per replicare i metadati. Per informazioni dettagliate sui prezzi, vedere Prezzi della larghezza di banda e Prezzi di Hub di notifica.

Configurare il supporto per più aree

• Abilita il ripristino geografico di emergenza dei metadati per un nuovo spazio dei nomi: Segui la procedura descritta in Creare un hub di notifica di Azure nel portale di Azure. Selezionare la configurazione per il ripristino di emergenza durante la creazione dello spazio dei nomi.

• Abilitare o disabilitare il ripristino di emergenza geografico dei metadati per uno spazio dei nomi esistente: Seguire la procedura descritta in Abilitare il ripristino di emergenza per uno spazio dei nomi Hub di notifica di Azure esistente.

• Eseguire il backup dei dati di registrazione del dispositivo: Vedere Esportare e importare Hub di notifica di Azure registrazioni in blocco.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configura uno spazio dei nomi di Notification Hubs per il ripristino geografico di emergenza dei metadati e quando entrambe le aree primaria e secondaria sono operative.

• Operazione tra aree: L'area primaria gestisce tutte le richieste. L'area secondaria non gestisce le richieste a meno che non si verifichi il failover.

• Replica dei dati tra aree: I metadati, ad esempio il nome dello spazio dei nomi, la configurazione dell'hub, le stringhe di connessione e altre informazioni critiche, vengono replicati in modo asincrono tra aree. I dati di registrazione non vengono replicati. Sei responsabile di esportarlo regolarmente per mantenere una copia di backup.

Comportamento durante un errore di area

Questa sezione descrive cosa accade quando si configura uno spazio dei nomi di Notification Hubs per il ripristino di emergenza geografico dei metadati e si verifica un'interruzione nella regione primaria.

• Rilevamento e risposta: Microsoft è responsabile del rilevamento dell'errore dell'area e della decisione se attivare il failover nell'area secondaria configurata.

• 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 richieste in corso verso il namespace nell'area primaria potrebbero non andare a buon fine quando l'area va offline. I client devono ripetere le operazioni dopo il completamento del failover.

• Perdita di dati prevista: I metadati vengono mantenuti. I dati di registrazione non vengono sottoposti automaticamente a backup, ma è possibile eseguirne il backup manualmente. Per altre informazioni, vedere Esportare e importare in blocco le registrazioni di Hub di notifica di Azure. Se non lo fai, i dati di registrazione non saranno disponibili finché l'area primaria non viene ripristinata.

• Tempo di inattività previsto: Microsoft impiega un po’ di tempo per avviare il failover dei metadati e quindi per completare il failover. Anche se il tempo può variare, in genere richiede diverse ore.

  Al termine del failover, si è responsabili del ripristino di eventuali backup dei dati di registrazione.

• Ridistribuzione: Dopo il failover, le richieste vengono instradate a uno spazio dei nomi nella regione secondaria che utilizza i dati replicati dalla regione primaria. Al termine del failover, i client si connettono automaticamente allo spazio dei nomi nell'area secondaria.

Ripristino della regione

Se l'area geografica primaria si ripristina, potrebbe essere possibile effettuare il failback nello spazio dei nomi primario dell'area geografica primaria. Lo spazio dei nomi primario manterrà i dati di registrazione prima dell'interruzione. Sarebbe un processo manuale e Microsoft comunicherebbe con l'utente per spiegare come funziona.

Dopo il ripristino dell'area primaria, è necessario:

• Convalida lo stato del namespace e i suoi dati.
• Determinare se sincronizzare le modifiche recenti dei dati di registrazione dall'area secondaria all'area primaria.

Testare gli errori dell'area

Non è possibile avviare un failover geografico. Tuttavia, è necessario testare le procedure di ripristino di emergenza personalizzate. Verificare che sia stato eseguito il backup delle registrazioni e che sia possibile ripristinarle in un nuovo spazio dei nomi.

Soluzioni di multiregione personalizzate per la resilienza

Il ripristino di emergenza geografico dei metadati gestiti da Microsoft replica solo i metadati. La funzionalità può ripristinare i metadati in uno spazio dei nomi secondario, ma si è responsabili dell'importazione delle registrazioni dei dispositivi in tale spazio dei nomi in modo che l'applicazione possa continuare a funzionare. Questo approccio richiede un intervento manuale durante un'emergenza e comporta tempi di inattività.

Se i tuoi obiettivi di ripristino richiedono meno tempo di inattività o meno intervento manuale, puoi implementare una soluzione personalizzata multiregione attiva-attiva. Distribuisci in anticipo un secondo namespace di Hub di notifica in un'altra area di Azure.

• Failover: Poiché il secondo spazio dei nomi è una risorsa funzionante, è possibile implementare la logica per rilevare un errore di area e passare a tale spazio dei nomi.

• Sincronizzazione: Per mantenere sincronizzato un secondo hub di notifica con l'hub di notifica primario, usare una delle opzioni seguenti:

  • Per le installazioni: Usare un back-end dell'app che crea e aggiorna simultaneamente le installazioni in entrambi gli hub di notifica. Le installazioni consentono di specificare un identificatore univoco del dispositivo, che supporta questo scenario di replica. Per ulteriori informazioni, vedi l'esempio RedundantHub.

  • Per le registrazioni: Usare un back-end dell'app che esporta regolarmente le registrazioni dall'hub di notifica primario come backup e le importa in blocco nell'hub di notifica secondario. Per altre informazioni, vedere Esportazione e importazione in blocco delle registrazioni di Hub di notifica di Azure.

  In alternativa, se non si ha un back-end, configurare l'app per creare installazioni in entrambi gli hub all'avvio dell'app nei dispositivi di destinazione. I dispositivi creano nuove registrazioni in entrambi gli hub di notifica. Infine, l'hub di notifica secondario ha tutti i dispositivi attivi registrati.

• Registrazioni e installazioni scadute: L'hub di notifica secondario potrebbe avere registrazioni e installazioni scadute. Quando viene inviato un push a un handle scaduto, Notification Hubs puliscono automaticamente la registrazione associata o il record di installazione nel Notification Hub, in base alla risposta ricevuta dal server PNS. È possibile pulire i record scaduti dalla soluzione di backup preferita aggiungendo logica personalizzata che elabora il feedback da ogni invio e rimuove registrazioni e installazioni scadute.

• App mai aperte: C'è un periodo di tempo durante il quale i dispositivi con app mai aperte non ricevono notifiche.

• Costo: Se si usa il proprio hub secondario per proteggere i dati di registrazione, tale hub comporta costi di servizio normali. Analogamente, se si distribuiscono altre risorse Azure nell'area secondaria per supportare il ripristino, si paga per quelli a tariffe di servizio normali.

Backup e ripristino

Notification Hubs non offre un'unica funzionalità integrata di backup e ripristino per tutti i dati archiviati nello spazio dei nomi. L'utente è responsabile della combinazione degli approcci seguenti:

• Usa l'infrastruttura come codice (IaC), come Bicep, per definire lo spazio dei nomi, l'hub e la configurazione dei criteri. Archiviare tali definizioni nel controllo del codice sorgente in modo che sia possibile ridistribuire le risorse quando necessario.
• Esegui il backup dei dati di registrazione del dispositivo esportando in blocco le registrazioni di Hub di notifica di Azure.

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.

Per gli Hub di notifica, lo SLA di disponibilità si applica agli spazi dei nomi che utilizzano i livelli Basic e Standard.

Contenuti correlati

• Affidabilità in Azure