Condividi tramite

Distribuzioni in più aree per il ripristino di emergenza in App per la logica di Azure

  • Articolo

Questo articolo fornisce indicazioni e strategie per configurare una distribuzione in più aree per i flussi di lavoro dell'app per la logica 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:

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 nell'app per la logica secondaria in un'altra area in cui è disponibile anche App per la logica di Azure. In questo modo, se il primario subisce perdite, interruzioni o errori, il database secondario può assumere il 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.

Nota

Se l'app per la logica funziona anche con elementi B2B, ad esempio partner commerciali, accordi, schemi, mappe e certificati, archiviati in un account di integrazione, sia l'account di integrazione che le app per la logica devono usare la stessa posizione.

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 nelle aree in app per la logica di Azure multi-tenant globale o in aree in App per la logica di Azure a tenant singolo. 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 dell'app per la logica primaria e secondaria, distribuite in aree separate in Azure multi-tenant globale. 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:

Istanze di app per la logica primaria e secondaria in posizioni separate

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, creare connessioni che autenticano l'accesso a queste 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 in più aree, prendere in considerazione le posizioni in cui esistono risorse dipendenti rispetto alle istanze dell'app per la logica:

  • L'istanza primaria e le risorse dipendenti sono disponibili in posizioni 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 posizione primaria non è più disponibile, le connessioni secondarie non sono interessate.

    Si supponga, ad esempio, che l'app per la logica primaria si connetta a un servizio esterno, ad esempio Salesforce. In genere, la disponibilità e la posizione del servizio esterno sono indipendenti dalla disponibilità dell'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 gateway dati è associata a una località o a un'area di Azure, proprio come la risorsa dell'app per la logica. Nella strategia di ridondanza in più aree assicurarsi che il gateway dati rimanga disponibile per l'uso dell'app per la logica. È possibile abilitare la disponibilità elevata per il gateway quando sono presenti più installazioni di gateway.

Ruoli active-active-active e passivi

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

Ruolo primario/secondario Descrizione
Attivo/attivo Le istanze dell'app per la logica primaria e secondaria in entrambe le posizioni gestiscono attivamente le richieste seguendo uno di questi modelli:

- Bilanciamento del carico: è possibile avere entrambe le istanze in ascolto di un endpoint e bilanciare il carico del traffico per ogni istanza in base alle esigenze.

- Consumer concorrenti: è possibile avere entrambe le istanze come consumer concorrenti in modo che le istanze competono per i messaggi di una coda. Se un'istanza ha esito negativo, l'altra istanza assume il carico di lavoro.
Attivo-passivo L'istanza dell'app per la logica primaria gestisce attivamente l'intero carico di lavoro, mentre l'istanza secondaria è passiva (disabilitata o inattiva). Il database secondario attende un segnale che il database primario non è disponibile o non funziona a causa di interruzioni o errori e assume il carico di lavoro come istanza attiva.
Combinazione Alcune app per la logica svolgono un ruolo attivo-attivo, mentre altre app per la logica svolgono un ruolo attivo-passivo.

Esempi attivi-attivi

Questi esempi mostrano la configurazione attiva-attiva in cui entrambe le istanze dell'app per la logica 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 servizio di bilanciamento del carico "fisico", ad esempio un componente 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:

    Configurazione

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

    Configurazione

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 si verifica un'interruzione o un errore principale, è possibile che un operatore esegua uno script che attivi il database secondario da assumere nel carico di lavoro.

Configurazione

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.

  • Nella posizione primaria un'app per la logica attiva è in ascolto di una coda del Bus di servizio di Azure per i messaggi, mentre un'altra app per la logica attiva controlla la presenza di messaggi di posta elettronica usando 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.

Combinazione

Stato e cronologia dell'app per la logica

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 SLIP di routing 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 di SLIP di routing in cui ogni app per la logica rappresenta una fase e usa una coda del Bus di servizio per comunicare con l'app per la logica successiva nel processo.

    Suddividere un processo aziendale in fasi rappresentate dalle app per la logica, che comunicano tra loro usando le code del Bus di servizio di Azure

    Se entrambe le istanze dell'app per la logica primaria e secondaria seguono lo stesso modello di SLIP di routing nelle rispettive posizioni, è possibile implementare il modello consumer concorrenti configurando ruoli attivo-attivo per tali istanze.

  • Modello di responsabile processi (broker)

  • Visualizza blocco senza modello di timeout

Accesso alla cronologia di trigger ed 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 esaminare l'integrità e la cronologia tra app per la logica eseguite in più posizioni.

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 Recurrence

Il trigger Ricorrenza è indipendente da qualsiasi servizio o endpoint specifico e genera esclusivamente una pianificazione specificata e 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 l'app per la logica inizia con un trigger Ricorrenza, è necessario configurare le istanze dell'app per la logica primaria e secondaria 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 in posizioni diverse.

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:

Combinazione

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

    • Per l'app per la logica abilitata attiva, impostare il trigger Ricorrenza per iniziare nella parte superiore dell'ora e ripetere ogni 20 minuti, ad esempio 9:00, 9:20 e così via.

    • Per l'app per la logica disabilitata passiva, impostare il trigger Ricorrenza sulla stessa pianificazione, ma iniziare da 10 minuti oltre l'ora e ripetere ogni 20 minuti, ad esempio 9:10, 9:30 e così via.

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

    • Per l'app per la logica disabilitata passiva, impostare il trigger Ricorrenza sulla stessa pianificazione dell'app per la logica attiva nella posizione primaria, che si trova nella parte superiore dell'ora e ripetere ogni 20 minuti, ad esempio 9:00 AM, 9:10 e così via.

    • Per l'app per la logica abilitata attiva, impostare il trigger Ricorrenza sulla stessa pianificazione dell'app per la logica passiva nella posizione primaria, che deve iniziare a partire da 10 minuti oltre l'ora e ripetere ogni 20 minuti, ad esempio 9:10, 9:20 AM 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 quando arriva il messaggio successivo non letto.

  • Le app per la logica che usano lo stato lato server, servizio o sistema usano valori o impostazioni delle proprietà presenti sul lato server, servizio o 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 per le code o gli argomenti del Bus di servizio con semantica di accodamento in cui un trigger può leggere e bloccare un messaggio mentre l'app per la logica elabora il messaggio. Al termine dell'elaborazione dell'app per la logica, il trigger elimina il messaggio dalla coda o dall'argomento.

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 funziona con lo stato lato client, assicurarsi 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 dell'app per la logica nel percorso alternativo sia inattiva o disabilitata fino al failover dell'istanza primaria nel percorso alternativo.

    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 funziona con lo stato lato server, è possibile configurare le istanze dell'app per la logica in modo da svolgere ruoli attivo-attivo in cui funzionano come consumer concorrenti o attivo-passivo in cui l'istanza alternativa attende fino al failover dell'istanza primaria nel percorso alternativo.

    Ad esempio, la lettura da una coda di messaggi, ad esempio una coda del Bus di servizio di Azure, usa lo stato lato server perché il servizio di accodamento mantiene i 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.

Trigger di 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à:

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

    Ad esempio, usare il trigger Richiedi per avviare l'app per la logica in modo che altre app per la logica possano chiamare il trigger usando l'azione Chiama flusso di lavoro - App per la logica.

  • 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 Richiedi è un destinatario passivo perché l'app per la logica non esegue alcuna operazione e attende fino a quando un altro servizio o sistema chiama in modo esplicito 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 Gestione API di Azure come proxy per le app per la logica che usano trigger Richiedi. Gestione API offre resilienza tra aree predefinita e la possibilità di instradare il traffico tra diversi endpoint.

Trigger webhook

Un trigger webhook consente all'app per la logica di sottoscrivere un servizio passando un URL di callback a tale 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 chiama il trigger webhook usando l'URL di callback, che esegue quindi l'app per la logica. Se abilitato, il trigger webhook sottoscrive il 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.

Valutare l'integrità dell'istanza primaria

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

Questa sezione descrive una soluzione che è possibile usare in modo definitivo o come base per la propria progettazione. Ecco una panoramica generale dell'oggetto visivo per questa soluzione:

Creare un'app per la logica watchdog che monitora un'app per la logica di controllo dell'integrità nella posizione primaria

Controllare la disponibilità dell'istanza primaria

Per determinare se l'istanza primaria è disponibile, in esecuzione e in grado di funzionare, è possibile creare un'app per la logica "controllo integrità" che si trova nella stessa posizione dell'istanza primaria. È quindi possibile chiamare questa app di controllo integrità da una posizione alternativa. Se l'app di controllo integrità risponde correttamente, l'infrastruttura sottostante per il servizio App per la logica di Azure in tale area è disponibile e funzionante. Se l'app di controllo integrità non risponde, è possibile presupporre che la posizione non sia più integra.

Per questa attività, creare un'app per la logica di controllo dell'integrità di base che esegue queste attività:

  1. Riceve una chiamata dall'app watchdog usando il trigger Richiedi.

  2. Rispondere con uno stato che indica se l'app per la logica selezionata funziona ancora usando 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 determinare ulteriormente se la posizione primaria è integra, è possibile tenere conto dell'integrità di qualsiasi altro servizio che interagisce con l'app per la logica di destinazione in questa posizione. È sufficiente espandere l'app per la logica di controllo dell'integrità per valutare anche l'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 del controllo integrità, creare un'app per la logica "watchdog" in un percorso alternativo. Ad esempio, è possibile configurare l'app per la logica watchdog in modo che, se la chiamata alla logica di controllo dell'integrità non riesce, il watchdog può inviare un avviso al team operativo in modo che possa analizzare l'errore e perché l'istanza primaria non risponde.

Importante

Assicurarsi che l'app per la logica watchdog si trova in una posizione diversa da quella primaria. Se App per la logica di Azure nella posizione primaria riscontra problemi, il flusso di lavoro dell'app per la logica watchdog potrebbe non essere eseguito.

Per questa attività, nella posizione secondaria creare un'app per la logica watchdog che esegue queste attività:

  1. Viene eseguito in base a una Ricorrenza fissa o pianificata usando 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 watchdog più sofisticata, che dopo alcuni errori chiama un'altra app per la logica che gestisce automaticamente il passaggio alla posizione secondaria quando il database primario ha esito negativo.

Attivare l'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 chiamare questa app per la logica di attivazione dopo 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 Azure Log Analytics per un'ulteriore gestione e elaborazione.

Passaggi successivi