Microsoft ha recentemente annunciato una nuova funzionalità che consente, per gli Azure storage account geo-ridondati, di effettuare in modo pilotato il failover. Tale caratteristica aumenta le capacità di controllo su questa tipologia di storage account, consentendo di avere una maggiore flessibilità in scenari di Disaster Recovery. In questo articolo viene mostrato il principio di funzionamento e la procedura da seguire per utilizzare questa nuova funzionalità.
Tipologie di storage account
In Azure sono presenti diverse tipologie di storage account con caratteristiche di replica distinte, per ottenere differenti livelli di ridondanza. Nel caso si voglia mantenere il dato presente sugli storage account disponibile anche a fronte di malfunzionamenti di una intera region di Azure è necessario adottare gli storage account di tipologia geo-ridondati, tra i quali se ne distinguono due differenti tipologie:
- Geo-redundant storage (GRS): il dato viene replicato in modo asincrono in due region geografiche di Azure, distanti centinaia di miglia tra di loro.
- Read-access geo-redundant storage (RA-GRS): segue lo stesso principio di replica precedentemente descritto, ma con la caratteristica che l’endpoint secondario può essere acceduto per leggere i dati replicati.
Utilizzando queste tipologie di storage account vengono mantenute tre copie del dato nella region primaria di Azure, selezionata in fase di configurazione, e ulteriori tre copie asincrone del dato in un’altra region di Azure, seguendo il principio delle Azure Paired Regions.
Figura 1 – Normale funzionamento dello storage di tipologia GRS/RA-GRS
Per maggiori informazioni sulle differenti tipologie di storage account e le relative caratteristiche di ridondanza è possibile consultare la documentazione ufficiale Microsoft.
Caratteristiche del processo di failover dello storage account
Grazie a questa nuova funzionalità, l’amministratore ha la possibilità di avviare il processo di account failover deliberatamente, nel momento in cui lo ritiene opportuno. Il processo di failover effettua un aggiornamento del record DNS pubblico dello storage account, in questo modo le richieste vengono indirizzate verso l’endpoint dello storage account presente nella region secondaria.
Figura 2 – Processo di failover per uno storage di tipologia GRS/RA-GRS
Al termine del processo di failover lo storage account è configurato per essere di tipologia Locally redundant storage (LRS) ed è necessario procedere con la relativa configurazione per renderlo nuovamente geo-ridondato.
Un aspetto importante da tenere in considerazione, quando si decide di intraprendere un failover dello storage account, è che tale operazione può comportare una perdita di dati, in quanto la replica tra le due region di Azure avviene in modalità asincrona. A causa di questo aspetto, in caso di indisponibilità della region primaria, potrebbero non essere stati replicate verso la region secondaria tutte le modifiche. Per verificare questa condizione è possibile fare riferimento alla proprietà Last Sync Time che indica il momento nel quale viene garantito che il dato è stato correttamente replicato verso la region secondaria.
Procedura di failover dello storage account dal portale Azure
In seguito, viene riportata la procedura per effettuare il failover di uno storage account direttamente dal portale Azure.
Figura 3 – Avvio del processo di failover dello Storage account
Figura 4 – Conferma del processo di failover dello Storage account
La procedura per avviare il failover di uno storage account può essere svolta non solo dal portale Azure, ma anche tramite PowerShell, Azure CLI, oppure utilizzando le API delle risorse Azure Storage.
Come individuare le problematiche sugli storage account
Microsoft raccomanda che gli applicativi che utilizzano gli storage account siano progettati per sostenere possibili errori in fase di scrittura. In questo modo l’applicativo dovrebbe esporre eventuali fallimenti riscontrati nella scrittura, in modo da essere allertati sulla possibile indisponibilità nell’accedere allo storage in una determinata region. Questo consentirebbe di intraprendere le dovute azioni correttive, come ad esempio il failover dello storage account in modalità GRSRA-GRS.
In modo nativo la piattaforma, tramite il servizio Azure Service Health, fornisce indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti in Azure, compreso lo storage. Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription.
Figura 5 – Creazione Health alert nel servizio Service Health
Figura 6 – Rule di notifica di problemi sullo storage
La notifica avviene tramite Action Groups, in seguito alla quale è possibile valutare la reale esigenza di intraprendere il processo di failover dello storage account.
Conclusioni
Prima del rilascio di questa funzionalità, in presenza di storage account di tipologia GRS/RA-GRS, il failover doveva comunque essere pilotato dal personale Microsoft a fronte di un fault che impattasse lo storage di una intera region Azure. Grazie a questa funzionalità viene fornito all’amministratore la possibilità di pilotare a piacimento il failover, garantendo così un maggiore controllo sugli storage account. Al momento questa funzionalità è disponibile in preview e solamente per gli storage account creati in determinate region Azure. Come accade per diverse funzionalità Azure in preview è bene attendere il rilascio ufficiale prima di utilizzarla per workload in ambiente di produzione.
