Il più grande errore da evitare quando virtualizzi

07 Aprile 2015
La virtualizzazione "tradizionale" 3-2-1: perchè è un errore
 
Gli americani la chiamano "la piramide invertita di doom", ma forse è più semplice chiamarla architettura 3-2-1.
Parlo del metodo tradizionale di costruire infrastrutture di virtualizzazione.
Al livello più alto ci sono gli host (3) collegati a degli switch ridondati (2) i quali si agganciano a una SAN o un NAS (1).

Ebbene se lo storage è basato su un unico pezzo (quindi un solo storage), tutta l’architettura ha un single point of failure, lo storage appunto. Perché una rottura o un down dello storage significa fermare tutte le macchine virtuali in esecuzione e tutti i servizi. E non pensare solo ai crash, pensa anche a interventi di manutenzione sullo storage.
 
Quindi l’errore più grande che devi evitare quando crei un’infrastruttura virtualizzata è mettere in piedi un sistema che è basato su un singolo oggetto (un solo storage in questo caso).
Non importa se l’oggetto ha componenti ridondate (doppio alimentatore, doppia scheda di rete…): è l’oggetto stesso che è uno.
Se quell’unico oggetto non è disponibile, l’intero castello che hai costruito crolla.
 
Quando crei un’infrastruttura virtuale, devi stare attento ai single point of failure
 
Per ovviare a questo inconveniente è possibile mettere nel tuo progetto delle SAN che non abbiano single point of failure, ma sono davvero molto costose.
 
Oppure ancora è possibile affiancare un secondo storage in modo che gli storage siano due e siano quindi fault tolerant.
Ma gestire una configurazione di questo tipo non è cosa semplice.
Giusto per avere un’idea basta che guardi l’architettura di massima di un sistema senza single point of failure per capire la complessità che comporta.
 

 
I pro
 
Generalmente questo tipo di architetture vedono la luce utilizzando hypervisor come VMware o Hyper-V installati su server di produttori blasonati (Dell, HP,IBM…) che funzionano da host e SAN o NAS di alto livello (EMC VNXe, Dell Equallogic, HP Lefthand, NetApp…) collegate fra loro per fornire un completo sistema in alta affidabilità senza single point of failure.
Questa architettura è solida e fornisce vera ridondanza.
 
I contro
 
L’aspetto negativo di questo approccio è legato alla complessità di mettere in piedi e manutenere un sistema di questo tipo.
Infatti ogni livello (host, rete, SAN, virtualizzazione) richiede una gestione separata dal resto e spesso e volentieri un supporto tecnico separato dal resto.

Hai presente? Il software di virtualizzazione ha un supporto e un tool di gestione separati dal resto.
Lo storage ha un altro supporto e un suo tool di gestione, i sistemi per monitorare se la rete sta in piedi hanno i loro strumenti e il loro supporto…
E, quando avrai qualche problema (perché i problemi sono solo una questione statistica, non di sfortuna), questo porta a enormi perdite di tempo e scaricabarile fra i diversi responsabili del supporto.
E talvolta verranno fuori dei problemi di compatibilità fra i diversi pezzi di hardware e software che sono stati messi insieme per creare l’ambiente virtualizzato.
 
In un’azienda enorme dove ci sono specialisti per ogni settore, lo specialista della virtualizzazione, lo specialista del network, lo specialista applicativo, lo specialista di storage, questo approccio può anche andare bene.
Ma nel mercato delle piccole e medie imprese è quasi impossibile trovare tante figure specializzate in tante nicchie differenti.

Quello che spesso succede è che i tecnici sono solo uno o due (in qualche caso tre) e si devono occupare di tutto.
E naturalmente un piccolo gruppo di tecnici non si può occupare in maniera professionale di tutto, semplicemente perché nell’IT di oggi è impossibile essere tuttologi.
 
Esistono sistemi che ti garantiscono la vera affidabilità, ma sono costosi e complessi da gestire; se sei da solo a seguire l’IT non puoi essere un tuttologo… serve una soluzione.

E le Virtual Storage Appliance (VSA)?

Benché questo meccanismo di gestione dello storage abbia diversi sostenitori non è la soluzione ai problemi visti prima.
In questa configurazione una macchina virtuale presenta un file system distribuito come se fosse un semplice appliance che fornisce risorse disco.
 
Lo schema di questa architettura lo puoi vedere nella figura qui sotto.
 

 
Lo vedi anche tu che virtualizzare una SAN e presentarla come una VSA non cambia di molto i problemi di gestione della SAN stessa.
E questo perché l’architettura stessa non cambia, non vien modificata di una virgola, è l’architettura che è complessa.
Quello che succede è che una porzione di ciò che normalmente sta dentro una SAN fisica viene presentata come una macchina virtuale, collegata in iSCSI o NFS allo storage condiviso dai dischi locali dei singoli host.
 
Il vero vantaggio dell’utilizzo di una VSA è che è possibile utilizzare lo storage locale di un host e allo stesso tempo fornire alta affidabilità alle tue macchine virtuali.
Se utilizzata con VMware una VSA consente di utilizzare funzioni come il vMotion (Live migration) ossia la migrazione a caldo senza disporre di uno storage esterno.
 
Sintesi: la VSA (Virtual Storage Appliance) o virtual SAN porta a livello di macchina virtuale quello che normalmente farebbe una SAN. Ma non per questo la gestione dello storage diventa più semplice.
 
Diciamo che comprime l’intera architettura in una sola “scatola” facendo quindi risparmiare un po’ di cablaggio all’infrastruttura virtuale. Ma la VSA o virtual SAN mantiene gli stessi problemi e le stesse sfide di una normale SAN messa in un’architettura 3-2-1.

La soluzione

I cluster HC3 di Scale Computing creano un singolo pool di storage distribuito e “spalmato” su tutti i nodi del cluster, ma che l’hypervisor e le macchine virtuali vedono sempre come disco locale.
 
Questa architettura elimina i protocolli di storage come iSCSI, NSF o SMB, rendendo l’amministrazione dell’intera infrastruttura virtuale semplice come gestire un singolo server. Perché i protocolli di gestione dello storage non ci sono più.
 
Se guardi la figura qui sotto capisci subito la semplicità del sistema e dell’architettura.
Che è pensata per le imprese che non possono permettersi di avere tanti tecnici specializzati in tanti settori diversi (storage, network, applicazioni, virtualizzazione) e non hanno il tempo di seguire i ticket aperti su fornitori diversi.
 
 

 
In questa “visione” tutta l’infrastruttura è vista come un blocco unico.
Gli aggiornamenti di sistema sono stati sviluppati in modo tale che un eventuale fallimento non impatti sui servizi che girano sulle macchine virtuali.
 
Gli aggiornamenti di sistemi virtualizzati a strati, come i sistemi di virtualizzazione tradizionali, possono avere problemi durante gli aggiornamenti perché le componenti dell’infrastruttura sono effettivamente separate e un problema in un aggiornamento può causare un fermo dell’intera infrastruttura.
Come chi utilizza VMware sa bene.
 
Con i cluster HC3 di Scale Computing quando ci sono aggiornamenti disponibili, è possibile eseguire l’installazione con la certezza che il nuovo software non causerà mai un fermo dell’intera infrastruttura.

Conclusione

  1. Architetture “tradizionali” 3-2-1: manca la vera alta affidabilità:
  • hanno un single point of storage se implementate (come succede spesso) con storage monolitici;
  • per risolvere il problema si può utilizzare storage senza single point of failure ma è costoso e complesso.
  1. Architetture tradizionali: complesse da costruire e manutenere:
  • sono basate su protocolli di storage tradizionali (iSCSI, NFS, SMB);
  • richiedono elevate competenze di storage;
  • hanno interfacce diverse per ogni operazione: virtualizzazione, server, storage, Network;
  • ogni componente e versione deve essere verificata sulla lista di compatibilità (HCL);
  • gli aggiornamenti sono gestiti separatamente per ogni livello dell'infrastruttura;
  • il supporto gestito da differenti vendor allunga i tempi di soluzione e spesso porta a conflitti e scaricabarile fra i vendor stessi.
  1. VSA (Virtual Storage Appliance): non sono “architetturalmente” differenti da una SAN fisica e richiedono gestione
La soluzione: i cluster di Scale Computing sono facili, ad alta affidabilità (vera) e scalabili.
Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)
Iscriviti
Notificami
guest
0 Commenti
Inline Feedbacks
Guarda tutti i commenti