Che tipo di archiviazione utilizzano effettivamente le persone per i server VMware ESX?

VMware e molti evangelisti della rete cercano di dirti che sofisticate (= costose) SAN in fibra sono la "sola" opzione di archiviazione per i server VMware ESX ed ESXi. Beh, certo, certo. L'uso di una SAN è veloce, affidabile e rende possibile vMotion. Grande. Ma: tutti gli utenti ESX / ESXi possono davvero permettersi SAN?

La mia teoria è che meno del 20% di tutte le installazioni VMware ESX su questo pianeta in realtà utilizza SAN in fibra o iSCS. La maggior parte di queste installazioni saranno in aziende più grandi che possono permetterselo. Vorrei prevedere che la maggior parte delle installazioni VMware utilizzano "archiviazione collegata" (i vmdks sono archiviati su dischi all'interno del server). La maggior parte di essi funziona nelle PMI e ce ne sono così tante!

Eseguiamo due server ESX 3.5 con memoria collegata e due server ESX 4 con un iSCS san. E la "vera differenza dal vivo" tra i due è appena notevole :-)

Conosci qualche statistica ufficiale per questa domanda? Cosa usi come supporto di memorizzazione?

Faccio molto lavoro di consulenza VMware e direi che le percentuali sono più vicine all'80% della base installata che utilizza lo storage condiviso ad alta disponibilità (FC, iSCSI o NAS di fascia alta) e molti dei miei clienti sono PMI. Il fattore chiave che ho scoperto è se l'azienda considera i suoi tempi di attività del server critici o meno, per la maggior parte delle aziende di oggi lo è.

Puoi certamente eseguire VM ad altissime prestazioni dallo storage direttamente collegato (un HP DL380 G6 con 16 unità interne in un array RAID 10 avrebbe un IO del disco piuttosto veloce) ma se stai costruendo un VMware o qualsiasi altro ambiente virtualizzato per sostituire decine, centinaia , o migliaia di server, allora sei pazzo se non stai impegnando molto (e probabilmente denaro) in una solida architettura di archiviazione.

Non è necessario acquistare una SAN di fascia alta per le funzioni di clustering: è possibile implementarle con un NAS abbastanza economico (o una SAN virtualizzata come HP \ Lefthand's VSA) e utilizzare comunque lo storage certificato. Tuttavia, se si utilizza l'archiviazione condivisa e non ha ridondanza in tutti i punti dell'infrastruttura SAN \ NAS, non è necessario utilizzarlo per molto più che per i test. E la ridondanza è (come minimo) doppia (indipendente) HBA \ NIC di archiviazione nei server, dual fabric indipendenti, controller ridondanti nella SAN, cache con backup della batteria \ destaging della cache, ventole e alimentatori sostituibili a caldo ridondanti, alimentatori ecc., RAID 5 \ 6 \ 10 \ 50 e numero appropriato di hot spare.

La vera differenza reale tra i tuoi sistemi è che se uno dei tuoi sistemi autonomi fallisce catastroficamente, hai molto lavoro da fare per ripristinarlo e subirai tempi di inattività semplicemente mantenendolo patchato. Con i sistemi SAN collegati in cluster, l'applicazione di patch agli hypervisor o l'aggiornamento dell'hardware dell'hypervisor dovrebbe ridurre i tempi di inattività. Un errore irreversibile del server semplicemente interrompe il servizio per il tempo necessario per riavviare la macchina virtuale su un nodo separato (nel peggiore dei casi) o se si dispone di tolleranza d'errore che copre quelle macchine virtuali, non si ha alcun tempo di inattività.

Come azienda abbiamo oltre un migliaio di host, abbiamo iniziato con FC, abbiamo provato iSCSI per un po 'ma ci siamo ritirati a FC a causa di problemi di prestazioni. Stiamo esaminando seriamente NFS ma non abbiamo ancora conclusioni. Oh, e usiamo HP XP / EVA e alcuni NetApp, non abbiamo host desktop / dev della barra di archiviazione locale.

Come puoi vedere, non esiste una dimensione adatta a tutti e non ha una soluzione di archiviazione di classe singola. È possibile disporre di più classi di archiviazione in base alla disponibilità e ai requisiti di prestazione

Per le scritture e le letture ad alte prestazioni, ho trovato FC imbattibile nelle prestazioni, e mentre il prezzo è alto ... Funziona solo ... per aspettative di prestazioni più banali iSCSI ha effettivamente funzionato abbastanza bene, quindi normalmente ho ottenuto il scambiare i file delle cassette postali del server su un sottosistema di dischi FC e le effettive unità di avvio su un disco di interfaccia iSCSI, con i server DNS e le macchine Active Directory anche in esecuzione da iSCSI.

Ho eseguito ESX con SAN, NAS e DAS. Dipende interamente da:

1. bilancio
2. Esperienza
3. data center e / o spazio rack
4. i soldi

Per affidabilità e velocità, non penso che tu possa battere una SAN.

Per affidabilità e costi, andrei con NAS.

E per velocità e costi, DAS.

Non che le singole opzioni non si sovrappongano, ma questi sono i punti di forza a cui ho assistito.

Eseguiamo 4 server ESX 4 e utilizziamo una SAN iSCSI EqualLogic.

Nelle installazioni più piccole, l'archiviazione locale è perfettamente accettabile purché si disponga di dischi decenti, direi unità da 10k RPM + SAS. L'unica volta in cui DEVI utilizzare un disco condiviso (intenzionalmente non ho detto san poiché il disco condiviso può essere spento e la condivisione NFS) è quando è necessario eseguire il clustering: VMWare HA e DRS.

Al momento disponiamo di 3 livelli di archiviazione: SAN FibreChannel, SAN Equalogix di fascia alta e SAN MD3000i di fascia bassa. Gli ultimi due sono iSCSI. Eseguiamo anche alcuni server dalla memoria locale dei server ESX - principalmente server di utilità che non ci interessano se sono inattivi per un'ora o due mentre ripariamo le cose se tutto va a gonfie vele.

Stiamo anche eseguendo il nostro ambiente di test su un NAS costruito in casa utilizzando unità SATA da 7,2k e target aziendale iSCSI (le prestazioni non sono poi così buone, ma ci ottengono).

Molte persone tendono a correre contro le condivisioni NFS anche in ambienti più grandi. Ho voluto giocare con questo per un po ', ma non ho trovato il tempo.

Eseguiamo quattro (bene, quattro live, uno per i test) host ESXi con un tessuto iSCSI costruito da switch di materie prime e una SAN Hitachi di fascia bassa - un SMS-100.

Anche a quel livello, abbiamo due controller gemelli, ognuno con due porte gemelle su un backplane SAS in modo che entrambi i controller possano impadronirsi dei dischi e due schede di rete, che incrociamo con i due switch e con le altre schede negli host ESX.

Ciascuno dei volumi vfs ha quattro percorsi visibili, quindi è ragionevolmente tollerante. Usiamo il powerge switch Dell per il fabric - hanno sicuramente potenziali problemi (per lo meno, nessun alimentatore ridondante) .. ma sono anche abbastanza economici che avere due pezzi di ricambio preconfigurati in una scatola pronti per lo scambio diventa una reale possibilità.

ovviamente, se vuoi più nove, devi spendere più soldi, ma penso che la bellezza di iSCSI, ESXi e il kit ethernet Gigabit di base sia che puoi colpire al di sopra del tuo peso in termini di resilienza e prestazioni.

Tutto ha i suoi pro e contro ... la linea di fondo è SLA, carico dell'applicazione e scala. Quindi, se hai bisogno di storage ad alte prestazioni per una distribuzione di piccole dimensioni (1-5 host), probabilmente potresti farlo con NFS (in realtà una volta ho ottenuto una migliore latenza con NFS che con SAN che utilizzano dischi RAM). Ora prova a ridimensionarlo e scoprirai che il costo di replicare la tua configurazione su scala è molto paragonabile a una bella SAN che rende FC l'unica opzione logica per esaminare ... Il più delle volte, finisco per usare combinazioni per vari servizi (app , DB, backup, archivi) non una singola piattaforma per ottimizzare i costi, a seconda delle esigenze.