L’approfondimento di oggi è dedicato al corretto utilizzo del cloud computing, una tecnologia alla quale ci si affida generalmente per avere a disposizione un adeguato livello di scalabilità ma alla quale si guarda anche come soluzione di emergenza per fronteggiare eventuali interruzioni di servizio (guasti interni all’infrastruttura proprietaria). La seconda modalità di impiego non rappresenta un utilizzo sbagliato del cloud ma, come vedremo più avanti, improprio.
L’approccio ideale sarebbe infatti quello di salvaguardare l’azienda da qualsiasi interruzione di servizio provvedendo all’opportuna ridondanza dell’hardware, predisponendo copie di applicazioni o servizi web presenti nel cloud pronte ad entrare in azione in caso di inconvenienti. Per capire meglio quale sia la differenza tra i due approcci inzieremo con il delineare le caratteristiche di un’infrastruttura pensata per garantire l’elevata disponibilità delle risorse.
Architettura ad alta disponibilità
Note anche come HAA (High Availability Architectures) sono adoperate in ambito enterprise per assicurare il risolvimento di qualsiasi inconveniente riscontrato nel percorso dati, obiettivo ottenibile mediante particolari accorgimenti:
- a livello hardware con configurazioni RAID per lo storage, circuiti di alimentazione doppi, sistemi di refrigerazione doppi etc.;
- a livello di rete (network) con la ridondanza di vari elementi, dai firewall fino agli switch ed ai router. In caso di guasti ciascun elemento deve essere immediatamente sostituito dal “duplicato”, il che richiede solitamente apposite configurazioni e supporto per IP condivisi distribuiti tra tutti gli elementi ridondanti, al fine di avviare un corretto reindirizzamento dei dati in occasione di interruzioni nel percorso predefinito;
- a livello di server ed applicazione, ambito nel quale il concetto di indirizzo condiviso è ugualmente applicato ma gestito al livello del load balancer – nel quale gli indirizzi IP virtuali diventano istanze virtuali dell’applicazione. A ciascun nodo primario è assegnato quindi un corrispettivo nodo secondario (un’istanza di backup che rimane in stato di attesa) pronto a sostituire il principale nel caso in cui quest’ultimo vado offline per qualsiasi problema (hardware, software, rete).
La continuità del servizio è assicurata proprio dal servizio di load balancing (che gestisce tutte le sessioni esistenti al posto del server) mentre l’eventuale indisponibilità di un qualsiasi elemento di rete è neutralizzata dal mirroring delle stesse sessioni tra elementi attivi ed in standby.
Load Balancing – schema esempio
Scalabilità ed elasticità
La maggior parte degli ambienti cloud si discosta dal modello appena descritto puntando invece sulla scalabilità ed elasticità delle risorse – con la fornitura immediata di queste ultime in base alle richieste degli utenti. In un’architettura ad alta scalabilità, pur non potendo contare sulla ridondanza, l’istanza di load balancing è richiesta e funziona in modo molto simile a quello visto nelle HAA. Il servizio di load balancing si comporta come un’applicazione virtuale con almeno un’istanza dietro ad esso. Al fine di garantire le prestazioni in occasione di elevati picchi di domanda, nuove istanze sono rese disponibili ed aggiunte al servizio. All’occorrenza, il processo può essere eseguito anche in maniera inversa: l’eliminazione preventiva di istanze in previsione di una contrazione della richiesta, è quel che definisce perfettamente il concetto di elasticità.
Nel caso in cui l’unica istanza disponibile cada, ed è questo il punto cruciale per apprendere la differenza tra i due approcci, non è previsto alcun rimpiazzo immediato per quest’ultima: il lancio di una nuova istanza richiede infatti del tempo perchè l’architettura non è stata pensata per garantire alta disponibilità, bensì scalabilità. In maniera analoga se su venti istanze presenti due si rendono indisponibili (per qualsiasi problema descritto in precedenza), le prestazioni e la disponibilità di alcuni client risentiranno inevitabilmente della loro “caduta”.
E’ allora chiaro che l’architettura ad alta scalabilità non può offrire le stesse garanzie di un’architettura ad alta disponibilità perchè la prima è stata pensata per un’altro obiettivo, come già sottolineato, ovvero il rispondere prontamente ai cambiamenti di domanda delle risorse, caratteristica che distingue da sempre i servizi cloud.
In conclusione
Ciascuna delle architetture descritte risponde ad un determinato problema ed adotta di conseguenza specifiche soluzioni progettuali. Scalabilità ed alta disponibilità non sono intercambiabili: un’architettura ideata per garantire la prima non potrà assicurare anche la seconda e viceversa. Nel caso in cui si stia pensando alla realizzazione di un’architettura ex novo, è invece possibile combinare i due approcci in modo da ottenere un’architettura ad alta disponibilità e scalabile in cui la prima caratteristica sia garantità dalla ridondanza mentre la seconda dall’elasticità – che ridue il tempo di approvvigionamento e dei costi grazie all’implementazione di un modello di risorse flessibile e virtuale.
Quando si pensa allora ad una eventuale soluzione cloud da affiancare magari alla propria infrastruttura è bene tenere a mente le differenze appena evidenziate perchè, nella maggior parte dei casi, un servizio cloud potrà garantire unicamente la scalabilità. La resistenza ad eventuali guasti/interruzioni dovrà essere invece implementata nell’infrastruttura dall’azienda stessa tramite intervento manuale o via script, pianificazione di failover o scelta di cloud provider che garantiscano una e/o l’altra caratteristica – diversificare i propri fornitori potrebbe essere un’altra buona idea per fronteggiare situazioni difficili.
Al prossimo approfondimento.
