I data center always on rappresentano l’evoluzione del presente e del futuro degli approcci di disaster recovery di un tempo. Un’evoluzione che presuppone un cambio di approccio molto significativo rispetto al passato.
In passato si era soliti prepararsi a far fronte a potenziali emergenze e problemi imprevisti – che riguardassero la connettività, un guasto hardware, e così via – facendo riferimento a specifici documenti di supporto, dai generatori ai router, passando per i data center nel momento in cui la ragione alla base dell’evento critico veniva identificata. Questa era la procedura del cosiddetto failover.
Da quando sono state introdotte le infrastrutture cloud, però, lo scenario è cambiato e i programmi di disaster recovery di un tempo sono stati messi in soffitta proprio per via delle architetture always on e delle architetture natively multihomed. In virtù di questo approccio, i dati vengono distribuiti tra i diversi data center in maniera tale che tutti rimangano costantemente attivi. La capacità viene scalata in automatico in funzione di ciò che succede nelle infrastrutture connesse.
Il problema più importante del failover era che, in realtà, non funzionava nella pratica come ci si attendeva e come si sperava, soprattutto se si doveva passare da un data center ad altri data center. Tali inconvenienti con le architetture always on vengono meno, perché viene mantenuta l’alta disponibilità di risorse con uno sforzo decisamente minimo.
La tendenza a realizzare sistemi nativamente multihomed fa in modo che il carico di lavoro possa essere mosso in maniera adattiva in funzione delle esigenze di una o dell’altra infrastruttura. I sistemi in questione sono in esecuzione costantemente in vari data center e anche in presenza di un blackout molto importante il problema può essere affrontato e risolto in modo assolutamente trasparente.
E la trasparenza è, in effetti, una delle caratteristiche distintive di questo approccio, visto che riguarda anche i blackout programmati e le operazioni di manutenzione. Per i sistemi operativi tutto ciò si traduce in interferenze minime, e quindi facilmente accettabili, a differenza di quel che succedeva in passato, quando occorrevano sforzi straordinari per il trasferimento tra i data center dei sistemi operativi.
Tutti gli approcci che facevano riferimento al failover non avevano la capacità di assicurare l’alta disponibilità, e di conseguenza costavano molto dal punto di vista delle risorse. Risorse che dovevano essere mantenute in stand by in maniera tale che vi si potesse ricorrere in caso di bisogno.
Un altro aspetto interessante dei sistemi multihomed è che essi rappresentano una parte integrante delle infrastrutture in cui sono implementati. Si tratta di una scelta di design ben precisa, che fa venir meno il concetto di failover, in funzione della quale il sistema è costantemente in esecuzione in data center diversi.
Ogni data center processa lavori condivisi in maniera dinamica con le varie strutture, di modo tale che il carico complessivo sia ben bilanciato. Nel momento in cui un data center, per un motivo o per l’altro, rallenta, il sistema sposta in automatico una parte del lavoro a un data center più rapido. Non solo: se c’è un data center che è totalmente irraggiungibile, sono gli altri data center a farsi carico delle sue task.
Ecco perché la procedura di failover sembra essere un ricordo del passato e può dirsi superata. Oggi il coordinamento tra i diversi data center si coniuga con il bilanciamento dinamico dei vari carichi di lavoro per fare sì che tutte le procedure possano essere automatizzate e, quindi, più efficaci.
