Che cosa sono il failover e il failback?

Questo articolo offre una panoramica generale del funzionamento del failover e del failback in un ambiente cloud. Tuttavia, per comprendere il failover, è necessario comprendere prima la ridondanza e la replica. Per informazioni su questi concetti prima di continuare con questo articolo, vedere Ridondanza, replica e backup.

Un motivo comune per mantenere copie ridondanti di applicazioni e repliche dati consiste nel poter eseguire un failover. Con il failover, è possibile reindirizzare il traffico e le richieste da istanze non integre a quelle integre. Quindi, una volta che le istanze originali diventano integre, è possibile eseguire un failback per tornare alla configurazione originale.

Ruoli dell'istanza attiva e passiva

Nel contesto del failover, un'istanza può essere un singolo componente, ad esempio un database o una raccolta di più componenti che costituiscono una distribuzione del servizio in un'area. In un'intera soluzione, è possibile eseguire il failover di parti diverse di tale soluzione in modi diversi e in situazioni diverse.

Un componente o una raccolta di componenti configurati per il failover e il failback richiedono più istanze. Ognuna di queste istanze assume un ruolo specifico:

• Le istanze primarie o attive funzionano attivamente, ad esempio la gestione delle richieste in ingresso dai client. In genere è presente un'istanza primaria alla volta.
• Le istanze secondarie o passive sono inattive, ma sono pronte per essere cambiate per diventare il database primario, se necessario. Potrebbero essere presenti diverse istanze secondarie.

Esistono diversi modi per configurare le istanze passive. Ogni modo comporta compromessi tra il tempo di ripristino e altri fattori, ad esempio i costi e la complessità operativa:

• Hot standby, progettati per essere sempre pronti ad accettare il traffico di produzione in qualsiasi momento.
• Standby caldi, progettati per essere quasi pronti ad accettare il traffico di produzione, ma che potrebbero richiedere alcune modifiche di configurazione o operazioni di ridimensionamento da completare prima di poter accettare il traffico.
• Standby leggeri pilota, che vengono parzialmente distribuiti in una configurazione minima e richiedono una preparazione significativa da completare prima di poter accettare il traffico di produzione.
• Standby a freddo, che potrebbero non essere distribuiti affatto e si basano su componenti da distribuire prima di poter accettare il traffico di produzione.

Suggerimento

Alcune soluzioni sono create per usare un approccio attivo-attivo , il che significa che tutte le istanze servono tutte le richieste. Un sistema attivo-attivo non richiede il failover, perché tutte le istanze servono attivamente le richieste in qualsiasi momento.

Ambiti di failover

Diverse situazioni richiedono strategie di failover diverse. Per illustrare queste possibili strategie, si consideri una soluzione di esempio costituita da un'applicazione che accede ai dati da un database. Configuri la soluzione per il failover creando copie ridondanti del server delle applicazioni e più repliche del database. Successivamente, si procede alla configurazione di:

• Ridondanza delle zone inserendo copie e repliche in zone di disponibilità diverse all'interno della stessa regione di Azure.
• Ridondanza geografica utilizzando un bilanciamento del carico globale per effettuare il failover tra regioni.

Ecco un diagramma semplificato che illustra l'architettura complessiva nelle normali operazioni:

Diverse situazioni possono attivare eventi di failover diversi in questa soluzione. Ognuno di questi corrisponde a un ambito di failover, che rappresenta la granularità dei componenti di cui viene eseguito il failover:

• È possibile che si verifichi un failover di replica di database quando la replica di database attiva non è più disponibile. La replica passiva viene alzata di livello per diventare la replica attiva. In genere, le applicazioni possono reindirizzare rapidamente le richieste alla nuova replica attiva:

  

• Un failover della zona di disponibilità può verificarsi se si verifica un'interruzione completa della zona di disponibilità. Questo tipo di interruzione richiede che tutto il traffico venga instradato al web server nella zona restante e garantisce anche che la replica del database nella zona rimanente diventi la replica attiva, se non lo è già.

  

• Un failover della regione potrebbe verificarsi in caso di perdita catastrofica dell'intera regione primaria di Azure.

  

Sebbene ognuno di questi ambiti fornisca un tipo di failover, potrebbe avere requisiti e processi di failover distinti. Microsoft potrebbe anche essere responsabile di alcuni ambiti di failover, ad esempio quando si usano servizi con ridondanza della zona, mentre potrebbe essere responsabile del failover in ambiti più ampi, ad esempio il failover tra aree di Azure.

Pianificazione del failover e della continuità aziendale

Una parte della pianificazione della continuità aziendale consiste nel progettare le strategie di failover, inclusi i diversi ambiti in cui è possibile attuare il failover.

In genere, i piani di continuità aziendale devono includere procedure di failover automatizzate all'interno o tra zone di disponibilità. Questo tipo di failover fa parte della strategia di disponibilità elevata. Ad esempio, se la replica attiva di un database ha esito negativo, un processo automatizzato può alzare di livello una replica passiva per diventare la replica attiva. Quindi, i server Web comunicano con la nuova replica attiva. Analogamente, se una zona di disponibilità ha esito negativo, molte soluzioni vengono compilate per il ripristino automatico usando le zone rimanenti.

Diverse procedure di failover vengono impiegate per scenari di emergenza, ad esempio nell'improbabile caso di un'interruzione totale di una regione. In caso di interruzione dell'area, è possibile cambiare le richieste Web in ingresso per usare la seconda area, nonché attivare un failover del database in una replica nell'area secondaria.

Tenere presente che, incluse le procedure di failover nella pianificazione della continuità aziendale, è necessario eseguire attività di progettazione e test più dettagliate. Per altre informazioni, vedere Che cosa sono la continuità aziendale, la disponibilità elevata e il ripristino di emergenza?.

Failover pianificati e imprevisti

I failover non pianificati sono quelli eseguiti durante un'interruzione di un componente, in modo da poter ripristinare il servizio usando un'altra istanza. I failover non pianificati talvolta comportano tempi di inattività o perdita di dati, a seconda del modo in cui viene progettata una soluzione. I failover non pianificati richiedono un elemento per rilevare l'errore e prendere una decisione su quando attivare il failover.

Al contrario, i failover pianificati sono quelli attivati in modo proattivo. È possibile eseguire questa operazione in previsione di un evento, ad esempio una macchina virtuale che verrà patchata e riavviata. I failover pianificati potrebbero avere una tolleranza inferiore per tempi di inattività e perdita di dati, perché fanno parte delle normali procedure di manutenzione.

Funzionamento del failover

Il failover è in genere costituito dai passaggi seguenti, che possono essere eseguiti manualmente o da un sistema automatizzato. I dettagli specifici per ognuno di questi passaggi dipendono dal sistema specifico.

1. Rilevare un errore (solo failover non pianificati). Un failover automatizzato richiede che un meccanismo rilevi quando un'istanza non è disponibile, in genere basato su una sorta di verifica di integrità. Diversi servizi definiscono il loro stato di salute in modi diversi. Ad esempio, alcuni servizi inviano in modo proattivo eventi heartbeat tra le istanze. Altri richiedono un componente separato per sondare ogni singola istanza a intervalli regolari. Spesso ci vuole tempo prima che i monitor di integrità rilevino che un'istanza è fallita e spesso è importante concedere un periodo di tolleranza nel caso l'istanza sia semplicemente occupata e non possa rispondere.

2. Scegli di eseguire il failover. A un certo punto verrà presa una decisione per eseguire un failover. La decisione può essere presa da uno strumento automatizzato o manualmente. La tolleranza ai rischi dell'organizzazione potrebbe influire sulla rapidità con cui viene presa questa decisione. Se si ha una tolleranza bassa per il rischio, è possibile scegliere di eseguire rapidamente il failover se esiste un'indicazione di un problema. Se si dispone di una tolleranza di rischio più elevata, è possibile scegliere di attendere se il problema può essere risolto prima del failover.

3. Selezionare una nuova istanza primaria. Una delle istanze rimanenti deve diventare la nuova istanza primaria.

   In alcune situazioni, potresti aver predefinito quale istanza dovrebbe diventare la nuova istanza principale, oppure potresti avere solo un'istanza a cui passare.

   In altre situazioni, è presente un processo automatizzato in base al quale il sistema seleziona una nuova istanza primaria. Esistono diversi algoritmi di consenso usati nel calcolo distribuito, tra cui per le elezioni leader. Questi algoritmi vengono implementati all'interno dei servizi pertinenti, ad esempio i database. In alcuni sistemi, è importante che ogni istanza sia consapevole della nuova replica primaria e quindi i risultati della selezione vengono annunciati automaticamente a ogni replica.

4. Reindirizzare le richieste. Configurare l'ambiente in modo che le richieste vengano indirizzate alle istanze sane o alla nuova istanza primaria.

   A tale scopo, potrebbe essere necessario aggiornare altri sistemi in modo che sappiano dove inviare richieste. Ciò potrebbe comportare l'aggiornamento di un sistema di bilanciamento del carico per escludere l'istanza non funzionante. In altre situazioni, il dns (Domain Name System) viene comunemente usato come modo per inviare richieste a un'istanza attiva di un sistema. Come parte del processo di failover, in genere è necessario aggiornare i record DNS in modo che le richieste vengano instradate alla nuova istanza primaria. DNS ha il concetto di 'time-to-live' (TTL), che indica ai client la frequenza con cui devono verificare la presenza di record DNS aggiornati. Se il valore TTL è impostato su un valore elevato, può passare del tempo prima che i client ricevano informazioni sul failover, e potrebbero continuare a inviare richieste al vecchio primario.

Poiché i processi di failover possono includere ritardi, è importante pianificare le procedure di failover per soddisfare i requisiti di tempo di inattività (obiettivo del punto di ripristino o RTO) e perdita di dati (obiettivo del punto di ripristino o RPO). Per altre informazioni, vedere Che cosa sono la continuità aziendale, la disponibilità elevata e il ripristino di emergenza?

Failback

Il failback è il processo di ripristino e reindirizzamento del traffico verso l'istanza primaria originale.

In alcune situazioni, non è necessario eseguire il failback perché ogni istanza è ugualmente in grado di fungere da primaria. Tuttavia, esistono alcune situazioni in cui è importante eseguire il failback, ad esempio quando è necessario eseguire le applicazioni da una determinata area di Azure e aver eseguito temporaneamente il failover in un'altra area durante un'interruzione a livello di area.

In alcuni casi, il failback viene gestito nello stesso modo di un failover. Tuttavia, il failback può anche essere più complesso del failover, per diversi motivi:

• Problemi di sincronizzazione dei dati. Durante e anche dopo, un failover regolare, l'istanza primaria precedente potrebbe aver ancora eseguito alcune operazioni o scritto alcuni dati in un archivio dati. Parte del processo di failback consiste nel garantire la coerenza e l'integrità dei dati nella soluzione, inclusa la gestione di eventuali conflitti o duplicazioni tra le istanze primarie e secondarie.

  È comune che i problemi di sincronizzazione dei dati richiedano un intervento manuale. Se non sono necessari i dati in conflitto, è possibile scegliere di reimpostare il database o altro stato.

• Procedura di correzione. Se sono stati tentati passaggi di correzione nel database primario prima del failover, potrebbero aver lasciato l'istanza primaria in uno stato sconosciuto.

  Se si verifica un rischio che l'istanza primaria si trovi in uno stato incoerente, potrebbe essere necessario eliminare e ridistribuire l'istanza primaria in modo che si trovi a uno stato valido noto prima di eseguire il failback.

• Tempo di inattività aggiuntivo. Il tempo di inattività durante il processo di failback può essere superiore a quello durante un failover a causa di riconfigurazioni necessarie o operazioni per ripristinare la coerenza dei dati.

  È possibile attenuare questo problema eseguendo processi di failback durante una finestra di manutenzione o avvisando gli utenti della modifica in anticipo. Inoltre, è possibile eseguire alcune delle operazioni preliminari mentre il sistema è online e ridurre al minimo i tempi di inattività necessari.

• Tolleranza al rischio. Se il failover si è verificato a causa di un'interruzione, la tolleranza dell'organizzazione per i tempi di inattività o altri rischi durante il failback può essere inferiore.

  Gli stakeholder aziendali devono essere informati della situazione durante il processo e devono essere resi pienamente consapevoli della necessità di failback e delle conseguenze delle procedure di failback. Potrebbe essere possibile negoziare un orario appropriato per apportare le modifiche.

Failover e failback nei servizi di Azure

Anche se è importante comprendere il funzionamento generale del failover, tenere presente che ogni servizio di Azure può affrontare il failover e il failback in modo diverso. Per informazioni sul funzionamento dei servizi di Azure specifici dal punto di vista dell'affidabilità, vedere la guida all'affidabilità di ogni servizio.

Molti servizi di Azure gestiscono automaticamente determinati tipi di failover. Ad esempio, quando si usano i servizi di Azure configurati per la ridondanza della zona, Microsoft esegue automaticamente il failover tra le zone di disponibilità. Per altre informazioni, vedere Che cosa sono le zone di disponibilità? e le guide all'affidabilità dei servizi di Azure.

Se si usano macchine virtuali, Azure Site Recovery replica le macchine virtuali e i relativi dischi tra zone di disponibilità o in un'altra area di Azure e può eseguire automaticamente il failover.

Quando si progetta una soluzione personalizzata che combina più servizi di Azure, i requisiti di failover potrebbero diventare più complessi. Si supponga di progettare una soluzione con un livello applicazione e un database e si vuole creare un'architettura attiva/passiva in più aree. Durante un'interruzione nell'area primaria, è importante che sia l'applicazione che il database eseguano il failover insieme nell'area secondaria. A seconda dei servizi esatti usati, potrebbe essere necessario pianificare un approccio di failover personalizzato per passare tra le distribuzioni in ogni area. Azure offre il routing del traffico globale e il bilanciamento del carico tramite Frontdoor di Azure e Gestione traffico di Azure ed è possibile selezionare la tecnologia che soddisfa i requisiti di failover. Ogni servizio supporta il monitoraggio della salute di ciascuna istanza regionale della tua applicazione e puoi configurarlo per reindirizzare automaticamente il traffico all'istanza funzionante.

Passaggi successivi

• Informazioni sulla responsabilità condivisa per l'affidabilità.
• Informazioni sulle raccomandazioni per la progettazione multi-regionale altamente disponibile nell'Azure Well-Architected Framework.