Molte volte durante l’implementazione di strategie per l’implementazione di alta disponibilità su sistemi, ci imbattiamo nella gestione del database, infatti se l’obiettivo è quello di implementare un infrastruttura ad High Availability ha poco senso preoccuparsi di mantenere sempre raggiungibile l’applicazione, se poi non applichiamo la stessa cura al database, un’applicazione infatti senza il relativo database è quali sempre inservibile.
Esistono varie strategia implementative per gestire il database in un ambito HA, ma alcune di esse purtroppo non sono affatto trasparenti al livello applicativo e richiedono l’esecuzione di modifiche al codice dell’applicazione per implementare varia controlli, questo non sempre è possibile o sostenibile, potremo infatti trovarci in una situazione in cui non è praticabile questa via poiché comporterebbe costi o tempistiche inaccettabili.
Tali modifiche consistono principalmente nell’implementare all’interno dell’app la possibilità di connettersi a più database a cascata in caso di errori nella connessione con il primo
try
{
//connessione al database primario
}
catch (Exception $e)
{
//connessione al database secondario
}queste aggiunte molto spesso rendono il codice sporco e lento.
Un altro problema che si evidenzia con un sistema di questo tipo è la necessità di tenere sincronizzati manualmente i due database, operazione non sempre facile o possibile.
Per fortuna esiste una soluzione, utilizzando Microsoft Azure questa soluzione si chiama Gruppo di Failover.
Il Gruppo di Failover
Implementare un Gruppo di Failover consiste nel creare un gruppo di Server Database ad esempio SQL Server che saranno raggiungibili attraverso un unica stringa di connessione, il Gruppo di Failover convoglierà automaticamente le richieste ricevute al database impostato come primario.
Impostando successivamente l’intervallo di tolleranza per il controllo della disponibilità dei database il sistema sceglie quale database sarà il primario e quale sarà il secondario.
Quando il sistema riconoscerà il database primario come non raggiungibile cambierà automaticamente il database primario con il secondario.
Configurazione
La configurazione di un gruppo di Failover è particolarmente importante, saranno infatti, le scelte faremo in questa fase che definiranno la disponibilità del database, è molto importante ad esempio inserire nello stesso Gruppo di Failover due Server di database dislocati in region diverse (magari addirittura in continenti diversi), così da aumentare la resilienza in caso di problemi geografici come calamità naturali, conflitti armati, attentati, ecc.
Una riflessione molto accurata va fatta anche riguardo il criterio (intervallo di tolleranza) per il cambio del database (switch tra primario e secondario), da questi infatti deriva il momento esatto in cui il sistema deciderà che un database ha un problema ed eseguirà lo switch con un altro.
Da menzionare anche la possibilità nel Gruppo di Failover di scambiare manualmente i database, attraverso un comodo pulsante nella console di Microsoft Azure.
Di seguito il codice come riportato nella documentazione di Terraform per la creazione di un Gruppo di Failover per Microsoft Azure
resource "azurerm_mssql_failover_group" "example" {
name = "example"
server_id = azurerm_mssql_server.primary.id
databases = [
azurerm_mssql_database.example.id
]
partner_server {
id = azurerm_mssql_server.secondary.id
}
read_write_endpoint_failover_policy {
mode = "Automatic"
grace_minutes = 80
}
tags = {
environment = "prod"
database = "example"
}
}Sincronizzazione
Un altro enorme vantaggio nell’implementazione del Grippo di Failover è la gestione automatica della sincronizzazione tra i database, in particolare il primario sarà l’unico database con possibilità di lettura e scrittura, e sincronizzerà i dati in modo automatico, con il database secondario, che sarà disponibile in sola lettura fino alla sua eventuale promozione a database primario.
Per concludere possiamo affermare che seppur con i suoi limiti il Gruppo di Failover è una soluzione molto semplice e relativamente facile da implementare che permette di rendere ad Alta disponibilità la componente database di un’infrastruttura, senza particolari complicazioni, senza richiedere modifiche al codice applicativo e senza preoccuparsi della sincronizzazione dei database.
E tu hai mai usato questa soluzione? che ne pensi?
