Continuità aziendale e ripristino di emergenza per App per la logica di Azure

Per ridurre l'impatto e gli effetti che gli eventi imprevedibili hanno sull'azienda e sui clienti, assicurarsi di disporre di una soluzione di ripristino di emergenza (DR) in modo che sia possibile proteggere i dati, ripristinare rapidamente le risorse che supportano funzioni aziendali critiche e mantenere le operazioni in esecuzione per mantenere la continuità aziendale (BC). Ad esempio, le interruzioni possono includere interruzioni, perdite nell'infrastruttura o nei componenti sottostanti, ad esempio archiviazione, rete o risorse di calcolo, errori irreversibili delle applicazioni o persino una perdita completa del data center. Grazie a una soluzione di continuità aziendale e ripristino di emergenza (BCDR) pronta, l'organizzazione o l'organizzazione può rispondere più rapidamente alle interruzioni, alle pianificazioni o non pianificate e a ridurre i tempi di inattività per i clienti.

Questo articolo fornisce linee guida e strategie BCDR che è possibile applicare quando si creano flussi di lavoro automatizzati usando App per la logica di Azure. 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 bcdr, assicurarsi di considerare non solo le app per la logica, ma anche queste risorse di Azure usate con le app per la logica:

• Connessioni create dai flussi di lavoro delle 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 che sono risorse di Azure create e usate nelle app per la logica per accedere ai dati nei sistemi locali. Ogni risorsa gateway rappresenta un'installazione separata del gateway dati in 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 (B2B) business-to-business. Ad esempio, è possibile configurare il ripristino di emergenza tra aree per gli account di integrazione.

• Ambienti del servizio di integrazione (ISE) in cui si creano app per la logica eseguite in un'istanza di runtime di App per la logica isolata all'interno di una rete virtuale di Azure. Queste app per la logica possono quindi accedere alle risorse protette dietro un firewall in tale rete virtuale.

Posizioni primarie e secondarie

Ogni app per la logica deve specificare il percorso da usare per la distribuzione. Questa località è un'area pubblica in Azure multi-tenant globale, ad esempio "Stati Uniti occidentali" o un ambiente del servizio di integrazione (ISE) creato e distribuito in precedenza in una rete virtuale di Azure. L'esecuzione di app per la logica in un ambiente ISE è simile all'esecuzione di app per la logica in un'area di Azure globale, il che significa che la strategia di ripristino di emergenza può essere applicata a entrambi gli scenari. Tuttavia, gli ISE hanno altre considerazioni, ad esempio la configurazione dell'accesso alle risorse disponibili solo per gli ISE.

Nota

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

Questa strategia di ripristino di emergenza è incentrata sulla configurazione dell'app per la logica primaria per il failover in un'app per la logica di standby o di backup in un percorso alternativo 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 richiede che l'app per la logica secondaria e le risorse dipendenti siano già distribuite e pronte nel percorso alternativo.

Se si seguono le procedure DevOps consigliate, si usano già modelli di Azure Resource Manager per definire e distribuire le app per la logica e le relative risorse dipendenti. I modelli di 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 o ISE diverse, che supportano strategie di ripristino di emergenza che usano aree abbinate.

Per la strategia di failover, 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 Azure multi-tenant globale oppure entrambe le istanze vengono distribuite negli ISE, che consentono alle app per la logica di accedere direttamente alle risorse in una rete virtuale di Azure. Per le procedure consigliate e altre informazioni sulle aree abbinate per BCDR, vedere Replica tra aree in Azure: Continuità aziendale e ripristino di emergenza.

  Ad esempio, sia le posizioni primarie che secondarie devono essere ISE quando l'app per la logica primaria viene eseguita in un ISE e usa connettori con controllo delle versioni ISE, azioni HTTP per chiamare le risorse nella rete virtuale di Azure o entrambe. In questo scenario, l'app per la logica secondaria deve avere anche una configurazione simile nella posizione secondaria come app per la logica primaria.

  Nota

  Per scenari più avanzati, è possibile combinare sia Azure multi-tenant che un ISE come località. Tuttavia, assicurarsi di prendere in considerazione e comprendere le differenze tra il modo in cui le app per la logica vengono eseguite in un ambiente ISE rispetto ad Azure multi-tenant.

• Se si usano ise, assicurarsi che vengano ridimensionati o che abbiano una capacità sufficiente per gestire il carico.

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 per questo scenario. 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:

Esempio: Ambiente del servizio di integrazione

Questo esempio mostra le istanze precedenti dell'app per la logica primaria e secondaria, ma distribuite in ise separati. Un singolo modello di Resource Manager definisce entrambe le istanze dell'app per la logica, le risorse dipendenti richieste da tali app per la logica e gli ISE come percorsi di distribuzione. I file di parametri separati definiscono i valori di configurazione da usare per la distribuzione in ogni posizione:

Connessioni alle risorse

App per la logica di Azure fornisce molte centinaia di operazioni del connettore che il flusso di lavoro dell'app per la logica può usare per usare altre app, servizi, sistemi e altre risorse, ad esempio account di 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 che esiste in una posizione specifica e non può essere usata dalle risorse in altre posizioni.

Per la strategia di ripristino di emergenza, 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 esistono 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 una connessione specifica.

• Sia l'istanza primaria che le risorse dipendenti esistono 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 insieme a una connessione separata al database.

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 nella 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 ripristino di emergenza 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.

Nota

Se l'app per la logica viene eseguita in un ambiente del servizio di integrazione (ISE) e usa solo i connettori con controllo delle versioni ISE per le origini dati locali, non è necessario il gateway dati perché i connettori ISE forniscono accesso diretto alla risorsa locale.

Se non è disponibile alcun connettore con versione ISE per la risorsa locale desiderata, l'app per la logica può comunque creare la connessione usando un connettore non ISE, che viene eseguito in Azure multi-tenant globale, non l'ISE. Tuttavia, questa connessione richiede il gateway dati locale.

Ruoli attivo-attivo e attivo-passivo

È 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 Azure Gestione API. 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 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 e 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 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.

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 di 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 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 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 è trasferiscibile 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 lista di distribuzione 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 bus di servizio di Azure code o argomenti. 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 - Lista di distribuzione.

  Questo esempio mostra un modello di lista di distribuzione in cui ogni app per la logica rappresenta una fase e usa una coda bus di servizio per comunicare con l'app per la logica successiva nel processo.

  

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

• Modello di Gestione 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 al trigger di ogni istanza e alla cronologia delle esecuzioni 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 nella strategia di ripristino di emergenza. Ecco i tipi di trigger disponibili che è possibile usare nelle app per la logica:

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

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 attivi-passivi e ruoli attivi passivi. 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:

• Nella posizione primaria configurare i ruoli attivi-passivi 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 passivo-attivo 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 isRead colonna impostata su FALSE. Ogni volta che il trigger legge una riga, l'app per la logica aggiorna tale riga modificando la isRead colonna da FALSE a TRUE.

  Questo approccio lato server funziona in modo analogo per bus di servizio code o argomenti 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 attivi-attivi in cui funzionano come consumer concorrenti o ruoli attivi-passivi 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 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 di bus di servizio, è possibile usare il modello consumer concorrente, ma solo se combinato con le sessioni di bus di servizio, noto anche come modello di convoglio sequenziale. In caso contrario, è necessario configurare le istanze dell'app per la logica con i ruoli attivo-passivo.

Trigger di richiesta

Il trigger Richiesta 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 Richiesta 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 di richiesta è un ricevitore 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 Azure Gestione API come proxy per le app per la logica che usano trigger di richiesta. Gestione API offre resilienza cross-regional predefinita e la possibilità di instradare il traffico tra più 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 della strategia di ripristino di emergenza, la soluzione necessita di modi per eseguire queste attività:

• Controllare la disponibilità dell'istanza primaria
• Monitorare l'integrità 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 generale dell'oggetto visivo per questa soluzione:

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 dell'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 Richiesta.

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 health-check, 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.

Ridondanza della zona con zone di disponibilità

In ogni area di Azure le zone di disponibilità sono posizioni fisicamente separate a tolleranza agli errori locali. Tali errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. Queste zone raggiungono la tolleranza attraverso la ridondanza e l'isolamento logico dei servizi di Azure.

Per garantire resilienza e disponibilità distribuita, esistono almeno tre zone di disponibilità separate in qualsiasi area di Azure che supporta e abilita la ridondanza della zona. La piattaforma App per la logica di Azure distribuisce queste zone e i carichi di lavoro delle app per la logica in queste zone. Questa funzionalità è un requisito fondamentale per l'abilitazione di architetture resilienti e la disponibilità elevata in caso di errori del data center in un'area.

Questa funzionalità è attualmente disponibile in anteprima e disponibile per le nuove app per la logica a consumo in aree specifiche. Per altre informazioni, consultare la documentazione seguente:

• Proteggere le app per la logica a consumo da errori di area con ridondanza della zona e zone di disponibilità
• Aree e zone di disponibilità di Azure

Raccogliere dati di diagnostica

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

• Se si vogliono usare questi dati con Azure Log Analytics, è 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 i dati di diagnostica per App per la logica di Azure.

• Se si desidera inviare i dati a Archiviazione di Azure o 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:

  • Archiviazione BLOB di Azure il ripristino di emergenza e il failover dell'account
  • 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
• Ripristino da un'interruzione del servizio a livello di area
• Contratti di servizio Microsoft per i servizi di Azure