Hyper Converged Infrastructure, per gli amici detto anche "HCI"!!!

riprendiamo con le pillole 2018, sempre sperando di essere d’aiuto e cercando sempre di non scendere troppo sul tecnico e prendendola alla larga e senza pretese.

Sempre benvenuti commenti, critiche, e liberi di richiedere temi specifici, se ne ho competenza proverò a darvi soddisfazione.

Grazie.

Siamo di nuovo in un Data Center, dove abbiamo visto che ci sono dei pezzi di “ferro” che sono i server per la capacità di calcolo, gli storage dove vengono salvate le informazioni, le reti per mettere tutti i pezzi in comunicazione tra di loro e l’esterno.

Il Data Center che si sono realizzati fino a pochi anni or sono avevano server di vari fornitori così come gli storage e, a volte, le relative reti di comunicazioni. Gestire un Data Center di questo genere voleva dire avere a che fare con svariati software di gestione e diverse interfacce, questo per forza di cose porta a richiedere uno sforzo maggiore e tempi più lunghi rispetto a una soluzione con una singola interfaccia, inoltre si hanno dei “silos” verticali per quello che riguarda la gestione delle stesse risorse, cioè un gruppo di gestione dei server, un gruppo di gestione degli storage e un gruppo di gestione della rete; in questa maniera creare una singola Virtual Machine richiede l’intervento dei tre enti, con i loro tempi e problemi che posso richiedere giorni dall’ordine alla consegna al Cliente.

Altro problema sorge nel momento in cui il Cliente avrà la necessità di modificare e/o espandere il proprio ambiente: saremo costretti a modificare tutto, spostare risorse virtuali e, a volte, fisiche, riconfigurare la rete e ancor peggio se accade che necessitiamo di espandere le risorse del DC, sarà una vera tragedia che porterà ad inevitabili down-time con sgraditi impatti sui Clienti.

Quello che dovrebbe permettere una soluzione HCI sarebbe che un unico software interfacciandosi direttamente con server, storage e apparati di rete, possa fare automaticamente tutto il necessario per creare e rendere fruibile al Cliente la Virtual Machine di cui sopra in pochi minuti, se non addirittura in alcune decine di secondi.

Tuttavia qui le scelte si complicano, perché se ci affidiamo a un unico fornitore ci si aspetta che l’integrazione tra le varie entità sia semplice (anche se non sempre è così); volendo invece mantenere una certa indipendenza dai fornitori, allora dovremo spendere parecchio tempo e denaro nell’integrazione. Ovviamente la seconda opzione ci renderà indipendenti anche da versioni diverse dello stesso fornitore che potrebbero essere non compatibili tra loro per la gestione del fornitore ma potrebbero invece funzionare con integrazione di terzi.

Ma ci sono altri aspetti importanti di cui tenere conto per rendere efficiente una soluzione HCI, ad esempio la gestione dei dati da parte degli storage. Infatti, data la mole dei dati che si manipolano oggi giorno, si ricorre sempre più spesso alla de-duplicazione (de-duplication) dato cioè gli storage, che sono dei veri e propri server ben carrozzati, provvedono a dividere in blocchi i dati di scrittura e, dove si hanno blocchi identici, ne scrivono uno solo sostituendo gli altri con dei “puntatori” (pointers), che in pratica sono dei link simbolici. Questa metodologia permette di ottimizzare spazi e tempi di scrittura, ma bisogna fare attenzione per quanto riguarda backup e copie su altri DC.

Infatti è buona norma effettuare un backup e avere una replica in un sito remoto di Disaster Recovery che possa garantire la Business Continuity in caso di calamità o down completo del DC primario, ma bisogna fare attenzione a non fare l’errore di trasferire i dati “interi”, infatti se andiamo a estrarre da uno storage i dati normalmente per trasferirli, lo storage di cui sopra che ha svolto l’attività di de-duplicazione svolgerà l’attività di re-idratazione (re-hydration), cioè dove troverà i link simbolici in uscita sostituirà con il blocco completo, ovviamente con dispendio di tempo ed energia. Come possiamo ovviare? Avendo cura di de-duplicare i dati in entrata dai servers/VMs e re-idratarli quando vengono richiesti da servers/VMs, ma fornirli “disidratati” per il backup e la replica, risparmiando tempo, banda per il trasferimento e, ovviamente, soldi!

Avendo il dato salvato in locale, con un backup e una replica nel DC di Disaster Recovery, diventa superfluo avere negli storage qualsiasi tipo di ridondanza dei dischi, quindi conviene mantenere in RAID i dischi di sistema dello storage e mettere in singolo i dischi dove vengono salvati i dati, con un considerevole risparmio di denaro e tempo.

Ritornando a tutta l’infrastruttura completa, quando ci troveremo nella necessità di modificare e/o espandere l’ambiente del Cliente sarà questione di pochi click, addirittura potremmo gestire dinamicamente e automaticamente le risorse, così come sarà semplice aggiungere risorse di calcolo, di storage, di rete senza impatti sulla operatività e avendo immediatamente le nuove risorse disponibili e integrate.