Distribuzioni multi-area per il ripristino di emergenza in App per la logica di Azure

Questo articolo fornisce indicazioni e strategie su come configurare una distribuzione in più aree geografiche per i flussi di lavoro di Logic Apps in App per la logica di Azure. Una distribuzione in più aree consente di proteggere i dati, eseguire rapidamente il ripristino da situazioni di emergenza e altri eventi di interruzione, ripristinare le risorse richieste dalle funzioni aziendali critiche e mantenere la continuità aziendale.

Per altre informazioni sulle funzionalità di affidabilità in App per la logica di Azure, inclusa la resilienza all'interno dell'area tramite zone di disponibilità, vedere Affidabilità in App per la logica di Azure.

Considerazioni

I flussi di lavoro delle app per la logica consentono di integrare e orchestrare più facilmente i dati tra app, servizi cloud e sistemi locali riducendo la quantità di codice da scrivere. Quando si pianifica la ridondanza in più aree, assicurarsi di considerare non solo le app per la logica, ma anche queste risorse di Azure usate con le app per la logica:

• Connessioni che si creano dai flussi di lavoro dell'app per la logica ad altre app, servizi e sistemi. Per altre informazioni, vedere Connessioni alle risorse più avanti in questo argomento.

• Gateway dati locali, ovvero risorse di Azure che vengono create e usate nelle App per la logica per accedere ai dati nei sistemi locali. Ogni risorsa gateway rappresenta un'installazione separata di un gateway dati su un computer locale. Per altre informazioni, vedere Gateway dati locali più avanti in questo argomento.

• Account di integrazione in cui si definiscono e archiviano gli artefatti usati dalle app per la logica per scenari di integrazione aziendale business-to-business (B2B). Ad esempio, è possibile configurare il ripristino di emergenza tra aree per gli account di integrazione.

Per altre informazioni sull'affidabilità in App per la logica di Azure, inclusa la resilienza all'interno dell'area tramite zone di disponibilità e distribuzioni in più aree, vedere Affidabilità in App per la logica di Azure.

Distribuzione primaria e secondaria

Una distribuzione in più aree è costituita da un'app per la logica primaria e secondaria. L'app per la logica primaria è configurata per eseguire il failover all'app per la logica secondaria in un'altra area in cui è disponibile anche App per la logica di Azure. In questo modo, se il database primario subisce perdite, interruzioni o guasti, il database secondario può subentrare nel lavoro. Questa strategia di distribuzione richiede che l'app per la logica secondaria e le risorse dipendenti siano già distribuite e pronte nell'area secondaria.

Se si seguono le procedure DevOps consigliate, si usano già modelli di Bicep o Azure Resource Manager per definire e distribuire le app per la logica e le relative risorse dipendenti. I modelli Bicep e Resource Manager offrono la possibilità di usare una singola definizione di distribuzione e quindi usare i file di parametri per fornire i valori di configurazione da usare per ogni destinazione di distribuzione. Questa funzionalità significa che è possibile distribuire la stessa app per la logica in ambienti diversi, ad esempio sviluppo, test e produzione. È anche possibile distribuire la stessa app per la logica in aree di Azure diverse, che supportano distribuzioni in più aree, ad esempio per le strategie di ripristino di emergenza.

Affinché il failover abbia esito positivo, le app per la logica e le posizioni devono soddisfare questi requisiti:

• L'istanza dell'app per la logica secondaria ha accesso alle stesse app, servizi e sistemi dell'istanza dell'app per la logica primaria.

• Entrambe le istanze dell'app per la logica hanno lo stesso tipo di host. Entrambe le istanze vengono quindi distribuite in regioni di App per la logica di Azure multitenant globale oppure in regioni di App per la logica di Azure single-tenant. Per le procedure consigliate e altre informazioni sull'uso di più aree per la continuità aziendale e il ripristino di emergenza (BC/DR), vedere Replica tra aree in Azure: Continuità aziendale e ripristino di emergenza.

Esempio: Azure multi-tenant

Questo esempio mostra le istanze primarie e secondarie dell'app per la logica, distribuite in aree geografiche separate nell'ambiente multi-tenant globale di Azure. Un singolo modello di Resource Manager definisce sia le istanze dell'app per la logica che le risorse dipendenti richieste da tali app per la logica. I file di parametri separati specificano i valori di configurazione da usare per ogni percorso di distribuzione:

Connessioni alle risorse

App per la logica di Azure fornisce operazioni per oltre 1.000 connettori che il flusso di lavoro dell'app per la logica può usare per lavorare con altre app, servizi, sistemi e altre risorse, ad esempio account Archiviazione di Azure, database di SQL Server, account di posta elettronica aziendali o dell'istituto di istruzione e così via. Se l'app per la logica deve accedere a queste risorse, si creano connessioni che autenticano l'accesso a tali risorse. Ogni connessione è una risorsa di Azure separata presente in una posizione specifica e non può essere usata dalle risorse in altre posizioni.

Per la strategia di ridondanza multiregione, considera le località in cui si trovano le risorse dipendenti rispetto alle istanze di App per la logica:

• L'istanza primaria e le risorse dipendenti si trovano in località diverse. In questo caso, l'istanza secondaria può connettersi alle stesse risorse o endpoint dipendenti. Tuttavia, è necessario creare connessioni specifiche per l'istanza secondaria. In questo modo, se la sede primaria non è più disponibile, le connessioni della sede secondaria non vengono compromesse.

  Si supponga, ad esempio, che l'app per la logica primaria si connetta a un servizio esterno, ad esempio Salesforce. Di solito, la disponibilità e l'ubicazione del servizio esterno sono indipendenti dalla disponibilità della tua app per la logica. In questo caso, l'istanza secondaria può connettersi allo stesso servizio, ma deve avere la propria connessione nell'area secondaria.

• Sia l'istanza primaria che le risorse dipendenti sono presenti nella stessa posizione. In questo caso, le risorse dipendenti devono avere backup o versioni replicate in un percorso diverso in modo che l'istanza secondaria possa comunque accedere a tali risorse.

  Si supponga, ad esempio, che l'app per la logica primaria si connetta a un servizio che si trova nella stessa località o nella stessa area, ad esempio database SQL di Azure. Se l'intera area non è più disponibile, è probabile che anche il servizio database SQL di Azure in tale area non sia disponibile. In questo caso, si vuole che l'istanza secondaria usi un database replicato o di backup nell'area secondaria, insieme a una connessione separata a tale database che si trova anche nell'area secondaria.

Gateway dati locali

Se l'app per la logica viene eseguita in Azure multi-tenant e deve accedere a risorse locali come i database di SQL Server, è necessario installare il gateway dati locale in un computer locale. È quindi possibile creare una risorsa gateway dati nel portale di Azure in modo che l'app per la logica possa usare il gateway quando si crea una connessione alla risorsa.

La risorsa del gateway dati è associata a una località geografica o a una regione di Azure, proprio come la risorsa dell'app per la logica. Nella strategia di ridondanza multi-area, assicurarsi che il gateway dati rimanga disponibile affinché l'app per la logica possa usarlo. È possibile abilitare la disponibilità elevata per il gateway quando sono presenti più installazioni di gateway.

Ruoli active-active e active-passive

È possibile configurare le posizioni primarie e secondarie in modo che le istanze dell'app per la logica in queste posizioni possano svolgere questi ruoli:

Esempi di cluster attivo-attivo.

Questi esempi mostrano la configurazione active-active, in cui entrambe le istanze della Logic App gestiscono attivamente le richieste o i messaggi. Alcuni altri sistemi o servizi distribuiscono le richieste o i messaggi tra istanze, ad esempio una di queste opzioni:

• Un bilanciatore del carico "fisico", ad esempio un dispositivo hardware che instrada il traffico

• Un servizio di bilanciamento del carico "soft", ad esempio Azure Load Balancer o Gestione API di Azure. Con Gestione API è possibile specificare criteri che determinano come bilanciare il carico del traffico in ingresso. In alternativa, è possibile usare un servizio che supporta il rilevamento dello stato, ad esempio il Bus di servizio di Azure.

  Anche se questo esempio mostra principalmente Azure Load Balancer, è possibile usare l'opzione più adatta alle esigenze dello scenario:

  

• Ogni istanza dell'app per la logica funge da consumer ed entrambe le istanze sono in competizione per i messaggi provenienti da una coda:

  

Esempi attivi-passivi

Questo esempio mostra la configurazione attiva-passiva in cui l'istanza dell'app per la logica primaria è attiva in un'unica posizione, mentre l'istanza secondaria rimane inattiva in un'altra posizione. Se l'istanza primaria subisce un'interruzione o un guasto, puoi far eseguire a un operatore uno script che attivi l'istanza secondaria affinché assuma il carico di lavoro.

Combinazione con attivo-attivo e attivo-passivo

Questo esempio mostra una configurazione combinata in cui la posizione primaria ha entrambe le istanze dell'app per la logica attiva, mentre la posizione secondaria ha istanze dell'app per la logica attiva-passiva. Se la posizione primaria subisce un'interruzione o un errore, l'app per la logica attiva nella posizione secondaria, che gestisce già un carico di lavoro parziale, può assumere il controllo dell'intero carico di lavoro.

• Nell'area primaria, un'app per la logica attiva è in ascolto di una coda di bus di servizio di Azure per i messaggi in arrivo, mentre un'altra app per la logica attiva verifica la presenza di messaggi di posta elettronica tramite un trigger di polling di Office 365 Outlook.

• Nella posizione secondaria, un'app per la logica attiva funziona con l'app per la logica nella posizione primaria ascoltando e competere per i messaggi dalla stessa coda del Bus di servizio. Nel frattempo, un'app per la logica passiva inattiva attende in standby per verificare la presenza di messaggi di posta elettronica quando la posizione primaria diventa non disponibile, ma è disabilitata per evitare la rilettura dei messaggi di posta elettronica.

Stato e cronologia della Logic App

Quando l'app per la logica viene attivata e avviata l'esecuzione, lo stato dell'app viene archiviato nella stessa posizione in cui l'app è stata avviata e non è trasferibile in un'altra posizione. Se si verifica un errore o un'interruzione, tutte le istanze del flusso di lavoro in corso vengono abbandonate. Quando sono configurate posizioni primarie e secondarie, le nuove istanze del flusso di lavoro iniziano a essere eseguite nella posizione secondaria.

Ridurre le istanze in corso abbandonate

Per ridurre al minimo il numero di istanze del flusso di lavoro in corso abbandonate, è possibile scegliere tra vari modelli di messaggio che è possibile implementare, ad esempio:

• Modello di routing slip fisso

  Questo modello di messaggio aziendale che suddivide un processo aziendale in fasi più piccole. Per ogni fase, si configura un'app per la logica che gestisce il carico di lavoro per tale fase. Per comunicare tra loro, le app per la logica usano un protocollo di messaggistica asincrono, ad esempio code o argomenti del Bus di servizio di Azure. Quando si divide un processo in fasi più piccole, si riduce il numero di processi aziendali che potrebbero rimanere bloccati in un'istanza dell'app per la logica non riuscita. Per informazioni più generali su questo modello, vedere Modelli di integrazione aziendale - SLIP routing.

  Questo esempio mostra un modello routing slip in cui ogni Logic App rappresenta una fase e usa una coda di bus di servizio per comunicare con la Logic App successiva nel processo.

  

  Se sia le istanze primarie che quelle secondarie di App per la logica seguono lo stesso modello routing slip nelle rispettive aree, è possibile implementare il modello dei consumer concorrenti configurando ruoli attivo-attivo per tali istanze.

• Modello di responsabile processi (broker)

• Visualizza blocco senza modello di timeout

Accesso alla cronologia dei trigger e delle esecuzioni

Per ottenere altre informazioni sulle esecuzioni precedenti del flusso di lavoro dell'app per la logica, è possibile esaminare la cronologia dei trigger e delle esecuzioni dell'app. La cronologia di esecuzione di un'app per la logica viene archiviata nella stessa posizione o nella stessa area in cui è stata eseguita l'app per la logica, il che significa che non è possibile eseguire la migrazione di questa cronologia a una posizione diversa. Se l'istanza primaria esegue il failover in un'istanza secondaria, è possibile accedere solo alla cronologia dei trigger e delle esecuzioni di ogni istanza nelle rispettive posizioni in cui tali istanze sono state eseguite. Tuttavia, è possibile ottenere informazioni indipendenti dalla posizione sulla cronologia dell'app per la logica configurando le app per la logica per inviare eventi di diagnostica a un'area di lavoro Log Analytics di Azure. È quindi possibile visualizzare lo stato e la cronologia nelle app per la logica distribuite in più aree geografiche.

Indicazioni sui tipi di trigger

Il tipo di trigger usato nelle app per la logica determina le opzioni disponibili per configurare le app per la logica in più posizioni in una strategia di ripristino di emergenza. Ecco i tipi di trigger disponibili che è possibile usare nei flussi di lavoro dell'app per la logica:

• Trigger di ricorrenza
• Attivatore di polling
• Trigger di richiesta
• Trigger webhook

Trigger di ricorrenza

Il trigger Ricorrenza è indipendente da qualsiasi servizio o endpoint specifici e si attiva esclusivamente in base a una pianificazione specificata e a nessun altro criterio, ad esempio:

• Frequenza fissa e intervallo, ad esempio ogni 10 minuti
• Una pianificazione più avanzata, ad esempio l'ultimo lunedì di ogni mese alle 17:00

Quando la tua app per la logica si avvia con un trigger di ricorrenza, devi configurare le istanze primaria e secondaria della tua app per la logica con i ruoli attivo-passivo. Per ridurre l'obiettivo del tempo di ripristino (RTO),che fa riferimento alla durata di destinazione per il ripristino di un processo aziendale dopo un'interruzione o un'emergenza, è possibile configurare le istanze dell'app per la logica con una combinazione di ruoli attivo-passivo e passivo-attivo. In questa configurazione, la pianificazione viene suddivisa tra le sedi.

Si supponga, ad esempio, di avere un'app per la logica che deve essere eseguita ogni 10 minuti. È possibile configurare le app per la logica e le posizioni in modo che, se la posizione primaria diventa non disponibile, la posizione secondaria può assumere il controllo del lavoro:

• Nella posizione primaria configurare i ruoli attivo-passivo per queste app per la logica:

  • Per l'app per la logica abilitata attiva, imposta il trigger Ricorrenza in modo che inizi all'inizio dell'ora e si ripeta ogni 20 minuti, ad esempio alle 9:00 AM, 9:20 AM e così via.

  • Per l'app per la logica passiva disabilitata, imposta il trigger di ricorrenza sulla stessa pianificazione, ma con inizio a 10 minuti dopo l'ora e ripetizione ogni 20 minuti, ad esempio alle 9:10, alle 9:30 e così via.

• Nella posizione secondaria, configurare passiva-attiva per queste app per la logica:

  • Per l'app per la logica passiva disabilitata, impostare il trigger Ricorrenza sulla stessa pianificazione dell'app per la logica attiva nella località primaria, ovvero allo scoccare dell'ora e con ripetizione ogni 20 minuti, ad esempio alle 9:00 AM, 9:10 AM e così via.

  • Per l'app per la logica attiva abilitata, imposta il trigger Ricorrenza sulla stessa pianificazione dell'app per la logica passiva nell'area primaria, che inizia 10 minuti dopo l'ora e si ripete ogni 20 minuti, ad esempio alle 9:10, 9:30 e così via.

A questo punto, se si verifica un evento di interruzione nella posizione primaria, attivare l'app per la logica passiva nella posizione alternativa. In questo modo, se l'individuazione dell'errore richiede tempo, questa configurazione limita il numero di ricorrenze perse durante tale ritardo.

Trigger di polling

Per verificare regolarmente se i nuovi dati per l'elaborazione sono disponibili da un servizio o un endpoint specifico, l'app per la logica può usare un trigger di polling che chiama ripetutamente il servizio o l'endpoint in base a una pianificazione di ricorrenza fissa. I dati forniti dal servizio o dall'endpoint possono avere uno di questi tipi:

• Dati statici, che descrivono i dati sempre disponibili per la lettura
• Dati volatili, che descrivono i dati non più disponibili dopo la lettura

Per evitare di leggere ripetutamente gli stessi dati, l'app per la logica deve ricordare quali dati sono stati letti in precedenza mantenendo lo stato sul lato client o sul lato server, servizio o sistema.

• Le app per la logica che funzionano con lo stato lato client usano trigger che possono mantenere lo stato.

  Ad esempio, un trigger che legge un nuovo messaggio da una posta in arrivo di posta elettronica richiede che il trigger possa ricordare il messaggio di lettura più recente. In questo modo, il trigger avvia l'app per la logica solo all'arrivo del successivo messaggio non letto.

• Le app per la logica che funzionano con uno stato sul lato server, del servizio o del sistema usano valori di proprietà o impostazioni presenti sul lato server, del servizio o del sistema.

  Ad esempio, un trigger basato su query che legge una riga da un database richiede che la riga abbia una colonna isRead impostata su FALSE. Ogni volta che il trigger legge una riga, l'app per la logica aggiorna tale riga modificando la colonna isRead da FALSE a TRUE.

  Questo approccio lato server funziona in modo analogo anche per le code o i topic di bus di servizio che usano la semantica di accodamento, in cui un trigger può leggere e bloccare un messaggio mentre l'app per la logica elabora il messaggio. Quando l'app per la logica termina l'elaborazione, il trigger elimina il messaggio dalla coda o dal topic.

Dal punto di vista del ripristino di emergenza, quando si configurano le istanze primarie e secondarie dell'app per la logica, assicurarsi di tenere conto di questi comportamenti in base al fatto che l'app per la logica tenga traccia dello stato sul lato client o sul lato server:

• Per un'app per la logica che usa lo stato lato client, assicurati che l'app per la logica non legga lo stesso messaggio più di una volta. Una sola posizione può avere un'istanza dell'app per la logica attiva in qualsiasi momento specifico. Assicurarsi che l'istanza di Logic App nell'area alternativa sia inattiva o disabilitata finché l'istanza primaria non esegue il failover verso l'area alternativa.

  Ad esempio, il trigger di Office 365 Outlook mantiene lo stato sul lato client e tiene traccia del timestamp del messaggio di posta elettronica letto più di recente per evitare di leggere un duplicato.

• Per un'app per la logica che usa uno stato lato server, è possibile configurare le istanze dell'app per la logica in modo che assumano ruoli attivo-attivo, in cui operano come consumer in competizione, oppure ruoli attivo-passivo, in cui l'istanza alternativa attende finché l'istanza primaria non esegue il failover verso la località alternativa.

  Ad esempio, la lettura da una coda di messaggi, ad esempio una coda di bus di servizio di Azure, utilizza uno stato lato server perché il servizio di accodamento mantiene blocchi sui messaggi per impedire ad altri client di leggere gli stessi messaggi.

  Nota

  Se l'app per la logica deve leggere i messaggi in un ordine specifico, ad esempio da una coda del Bus di servizio, è possibile usare il modello consumer concorrente, ma solo se combinato con le sessioni del Bus di servizio, noto anche come modello di serie sequenziale. In caso contrario, è necessario configurare le istanze dell'app per la logica con i ruoli attivo-passivo.

Attivatore della richiesta

Il trigger Richiedi rende l'app per la logica chiamabile da altre app, servizi e sistemi e viene in genere usata per fornire queste funzionalità:

• Un'API REST diretta per l'app per la logica che altri possono chiamare

  Ad esempio, usa il trigger Request per avviare la tua app per la logica, in modo che altre app per la logica possano richiamare il trigger tramite l'azione Chiama flusso di lavoro - Logic Apps.

• Un webhook o un meccanismo di callback per l'app per la logica

• Un modo per eseguire manualmente routine o operazioni utente per chiamare l'app per la logica, ad esempio usando uno script di PowerShell che esegue un'attività specifica

Dal punto di vista del ripristino di emergenza, il trigger Request è un ricevitore passivo perché l'app per la logica non esegue alcuna azione e rimane in attesa finché un altro servizio o sistema non richiama esplicitamente il trigger. Come endpoint passivo, è possibile configurare le istanze primarie e secondarie in questi modi:

• Attivo-attivo: entrambe le istanze gestiscono attivamente le richieste o le chiamate. Il chiamante o il router bilancia o distribuisce il traffico tra tali istanze.

• Attivo-passivo: solo l'istanza primaria è attiva e gestisce tutto il lavoro, mentre l'istanza secondaria attende fino all'interruzione o all'errore dell'istanza primaria. Il chiamante o il router determina quando chiamare l'istanza secondaria.

Come architettura consigliata, è possibile usare API Management di Azure come proxy delle App per la logica che usano trigger Richiesta. API Management offre resilienza integrata tra più aree geografiche e la possibilità di instradare il traffico su più endpoint.

Trigger webhook

Un trigger webhook consente alla tua app per la logica di sottoscriversi a un servizio passando un URL di callback al servizio. L'app per la logica può quindi rimanere in ascolto e attendere che si verifichi un evento specifico in tale endpoint di servizio. Quando si verifica l'evento, il servizio richiama il trigger webhook tramite l'URL di callback, che a sua volta esegue l'app per la logica. Se abilitato, il trigger webhook si iscrive al servizio. Se disabilitato, il trigger annulla la sottoscrizione al servizio.

Dal punto di vista del ripristino di emergenza, configurare istanze primarie e secondarie che usano trigger webhook per svolgere ruoli attivi-passivi perché solo un'istanza deve ricevere eventi o messaggi dall'endpoint sottoscritto.

Verificare lo stato dell'istanza primaria

Per il corretto funzionamento di una strategia di failover in più aree, la soluzione richiede modi per eseguire queste attività:

• Controllare la disponibilità dell'istanza primaria
• Monitorare lo stato di salute dell'istanza primaria
• Attivare l'istanza secondaria

Questa sezione descrive una soluzione che è possibile usare in modo definitivo o come base per la propria progettazione. Ecco una panoramica visiva di alto livello di questa soluzione:

Controllare la disponibilità dell'istanza primaria

Per determinare se l'istanza primaria è disponibile, in esecuzione e operativa, è possibile creare un'app per la logica di "controllo di integrità" nella stessa area dell'istanza primaria. È quindi possibile richiamare questa app per il controllo dell'integrità da un'altra posizione. Se l'app per il controllo dell'integrità risponde correttamente, l'infrastruttura sottostante del servizio App per la logica di Azure in quell'area è disponibile e funzionante. Se l'app di verifica dello stato di integrità non risponde, puoi presumere che la località non sia più in uno stato di integrità.

Per questa attività, creare un'app per la logica di controllo di integrità di base che esegua le attività seguenti:

1. Riceve una chiamata dall'app watchdog tramite il trigger Request.

2. Rispondere con uno stato che indica se l'app per la logica controllata continua a funzionare tramite l'azione Risposta.

   Importante

   L'app per la logica di controllo integrità deve usare un'azione Response in modo che l'app risponda in modo sincrono, non in modo asincrono.

3. Facoltativamente, per verificare con maggiore precisione se la località primaria è in buono stato, è possibile considerare anche lo stato di integrità di qualsiasi altro servizio che interagisce con la Logic App di destinazione in questa località. È sufficiente espandere l'app per la logica di verifica dell'integrità per valutare anche lo stato di integrità di questi altri servizi.

Creare un'app per la logica watchdog

Per monitorare l'integrità dell'istanza primaria e chiamare l'app per la logica di controllo dell'integrità, crea un'app per la logica "watchdog" in un'area alternativa. Ad esempio, è possibile configurare l'app per la logica di watchdog in modo che, se la chiamata alla logica di controllo integrità ha esito negativo, il watchdog invii un avviso al team operativo affinché possa indagare sul problema e sul motivo per cui l'istanza primaria non risponde.

Per questa attività, nella località secondaria, crea un'app per la logica watchdog che esegua le attività seguenti:

1. Eseguire in base a una ricorrenza fissa o pianificata tramite il trigger Ricorrenza.

   È possibile impostare la ricorrenza su un valore inferiore al livello di tolleranza per l'obiettivo del tempo di ripristino (RTO).

2. Chiamare il flusso di lavoro dell'app per la logica di controllo dell'integrità nella posizione primaria usando l'azione HTTP.

È anche possibile creare un'app per la logica di controllo watchdog più sofisticata che, dopo un certo numero di errori, chiama un'altra app per la logica che gestisce automaticamente il passaggio all'area secondaria quando l'area primaria non è disponibile.

Attiva la tua istanza secondaria

Per attivare automaticamente l'istanza secondaria, è possibile creare un'app per la logica che chiama l'API di gestione, ad esempio il connettore di Azure Resource Manager, per attivare le app per la logica appropriate nella posizione secondaria. È possibile espandere l'app watchdog per richiamare questa app di logica di attivazione dopo che si è verificato un numero specifico di errori.

Raccogliere i dati di diagnostica

È possibile configurare la registrazione per le esecuzioni dell'app per la logica e inviare i dati di diagnostica risultanti a servizi come Archiviazione di Azure, Hub eventi di Azure e Log Analytics di Azure per un'ulteriore gestione e elaborazione.

• Se si vogliono usare questi dati con Log Analytics di Azure, è possibile rendere disponibili i dati per le posizioni primarie e secondarie configurando le impostazioni di diagnostica dell'app per la logica e inviando i dati a più aree di lavoro Log Analytics. Per altre informazioni, vedere Configurare i log di Monitoraggio di Azure e raccogliere dati di diagnostica per App per la logica di Azure.

• Se si vogliono inviare i dati ad Archiviazione di Azure o a Hub eventi di Azure, è possibile rendere disponibili i dati per le posizioni primarie e secondarie configurando la ridondanza geografica. Vedi questi articoli per ulteriori informazioni:

  • Ripristino di emergenza e failover dell'account di Archiviazione BLOB di Azure
  • Hub eventi di Azure - Ripristino di emergenza geografico

Passaggi successivi

• Progettare applicazioni Azure affidabili
• Elenco di controllo per la resilienza per servizi di Azure specifici
• Gestione dei dati per la resilienza in Azure
• Backup e ripristino di emergenza per le applicazioni Azure
• Ripristinare da un'interruzione del servizio dell'intera area geografica
• Accordi di servizio (SLA) Microsoft per i servizi di Azure