VMware VMFS5 e dimensionamento LUN - più piccoli datastore o 1 grande datastore?

Con VMFS5 non ha più il limite di 2 TB per un volume VMFS, sto considerando quale scenario sarebbe complessivamente più vantaggioso: -

• Meno LUN di dimensioni maggiori, o
• Più LUN di dimensioni inferiori.

Nel mio caso, ho un nuovo array di archiviazione da 24 dischi con dischi da 600 GB. Userò RAID10, quindi all'incirca 7,2 TB, e cercherò di decidere se andare con 1 grande archivio dati da 7 TB o più negozi da 1 TB ciascuno.

Quali sono i pro e i contro di ogni approccio?

Aggiornamento : Naturalmente, ho trascurato di includere hot spare nel mio calcolo, quindi sarà poco meno di 7,2 TB, ma l'idea generale è la stessa. :-)

Aggiornamento 2 : ci sono 60 VM e 3 host. Nessuna delle nostre VM è particolarmente intensiva per l'I / O. La maggior parte di essi sono server web / app e anche cose come il monitoraggio (munin / nagios), 2 controller di dominio Windows con carico minimo e così via. I server DB vengono raramente virtualizzati a meno che non dispongano di requisiti di I / O MOLTO bassi. In questo momento penso che l'unico server DB virtuale che abbiamo sia una scatola MSSQL e il DB su quella scatola sia <1 GB.

Aggiornamento 3 : ulteriori informazioni sull'array e la connettività FC. L'array è un IBM DS3524, 2 controller con 2 GB di cache ciascuno. 4 porte FC da 8 Gbit per controller. Ogni host ESXi ha 2 HBA FC da 4 Gbit.

Non hai specificato quante macchine virtuali hai o cosa faranno. Anche senza tali informazioni, eviterei di creare un LUN di grandi dimensioni per motivi di blocco / prestazioni, contesa e flessibilità.

Presumo che stai per virtualizzare i server, non i desktop, va bene? Successivamente supporrò che userete diversi server ESX / ESXi per accedere al vostro archivio e farli gestire da vCenter Server.

Quando si decide la dimensione del LUN e il numero di VMFS, si bilanciano diversi fattori: prestazioni, flessibilità di configurazione e utilizzo delle risorse, mentre sono vincolati dalla massima configurazione supportata della propria infrastruttura.

È possibile ottenere le migliori prestazioni con la mappatura da 1 VM a 1 LUN / VMFS. Non c'è competizione tra macchine sullo stesso VMFS, nessuna contesa di blocco, ogni carico è separato e tutto è a posto. Il problema è che hai intenzione di gestire una quantità empia di LUN, potresti raggiungere limiti massimi supportati, affrontare mal di testa con ridimensionamento e migrazione VMFS, avere risorse sottoutilizzate (si sommano quelli spazio singolo punto percentuale su VMFS) e generalmente creare qualcosa che non è carino da gestire.

L'altro estremo è un grande VMFS designato per ospitare tutto. Otterrai il miglior utilizzo delle risorse in questo modo, non ci saranno problemi a decidere cosa distribuire dove e problemi con VMFS X come hot spot, mentre VMFS Y è inattivo. Il costo sarà la prestazione aggregata. Perché? A causa del blocco. Quando un ESX sta scrivendo su un dato VMFS, altri vengono bloccati per il tempo necessario per completare l'IO e devono riprovare. Questo costa prestazioni. Al di fuori degli ambienti di gioco / test e sviluppo è un approccio errato alla configurazione dello storage.

La pratica accettata è quella di creare archivi di dati sufficientemente grandi da ospitare un numero di VM e dividere lo spazio di archiviazione disponibile in blocchi di dimensioni adeguate. Il numero di macchine virtuali dipende dalle macchine virtuali. Potrebbe essere necessario un singolo o un paio di basi di dati di produzione critici su un VMFS, ma consentire tre o quattro dozzine di macchine di test e sviluppo sullo stesso archivio dati. Il numero di VM per archivio dati dipende anche dall'hardware (dimensioni del disco, rpm, cache dei controller, ecc.) E dai modelli di accesso (per ogni dato livello di prestazioni è possibile ospitare molti più server Web sullo stesso VMFS rispetto ai server di posta).

I datastore più piccoli hanno anche un altro vantaggio: impediscono fisicamente di stipare troppe macchine virtuali per ogni datastore. Nessuna pressione di gestione si adatta a un terabyte aggiuntivo di dischi virtuali su uno spazio di archiviazione di mezzo terabyte (almeno fino a quando non sentiranno parlare di thin provisioning e deduplica).

Ancora una cosa: quando si creano questi archivi di dati standardizzare su una singola dimensione di blocco. Semplifica molte cose in seguito, quando vuoi fare qualcosa attraverso i datastore e vedere brutti errori "non compatibili".

Aggiornamento : DS3k avrà controller attivi / passivi (cioè ogni LUN può essere servito dal controller A o B, l'accesso al LUN attraverso il controller non proprietario comporta una penalità di prestazione), quindi pagherà per avere un numero pari di LUN , distribuito uniformemente tra i controller.

Potrei immaginare di iniziare con 15 VM / LUN con spazio per crescere fino a circa 20.

La risposta breve alla tua domanda è: tutto dipende da quali sono i tuoi schemi di I / O, e questo sarà unico per il tuo ambiente.

Ti suggerisco di dare un'occhiata qui http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ poiché questo può aiutarti a considerare i tuoi IOP previsti e quanti LUN potrebbero essere adatti. Detto questo, se dovessi sbagliare sul versante della cautela, alcune persone consiglierebbero di avere molti LUN (se la mia correzione a una risposta precedente è stata approvata, vedi i miei commenti sulle code LUN IO sul lato array). Tendo ad essere d'accordo, ma andrei oltre per estenderli insieme in un singolo / pochi volumi VMFS (non credere al FUD sulle estensioni e altri limiti VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Ciò avrà il vantaggio di gestire un singolo / pochi archivi di dati all'interno di vSphere e, poiché vSphere bilancia automaticamente le macchine virtuali sulle estensioni disponibili a partire dal primo blocco di ogni misura, il vantaggio in termini di prestazioni distribuendo l'IO su più LUN.

Qualcos'altro da considerare ... Dici che nessuna delle VM è particolarmente intensiva per l'IO. Detto questo, potresti prendere in considerazione una combinazione di RAID5 e RAID10, per ottenere il meglio da entrambi i mondi (spazio e velocità).

Inoltre, se le macchine virtuali sono configurate con più VMDK, con i pattern di I / O del sistema operativo e delle applicazioni distribuiti su quei dischi virtuali (ad esempio OS, Web, DB, registri, ecc. Ciascuno su un VMDK separato), è quindi possibile individuare ciascun VMDK su un archivio dati diverso per abbinare le capacità IO di quel LUN fisico (es. OS su RAID5, Log su RAID10). Si tratta di mantenere insieme schemi IO simili per sfruttare il comportamento meccanico dei dischi sottostanti in modo che, ad esempio, le scritture di log in una macchina virtuale non influiscano sulle velocità di lettura Web in un'altra macchina virtuale.

FYI ... si può con successo virtualizzare i server DB, basta analizzare i tassi di IO Patterns & IOPS e di destinazione che IO ad un idoneo LUN; pur essendo consapevole dei modelli IO e IOPS che quel LUN sta già facendo. Questo è il motivo per cui molti amministratori colpa virtualiseation per scarso rendimento DB ... cos che non ha calcolato attentamente il IO / IOPS che più server genererebbero quando si metterli su un LUN condiviso (es. La colpa gli amministratori, non è colpa di virtualizzazione ).

Ogni volume (LUN) ha la propria profondità di coda, quindi per evitare contese di IO, molte implementazioni usano LUN più piccoli. Detto questo, è possibile creare un LUN di datastore abbastanza facilmente. Lo svantaggio di datastore VMWare più grandi (e meno) è, per quanto ne so, che è possibile imbattersi in alcuni limiti sul numero di VM che potrebbero essere attive contemporaneamente.

Un'altra considerazione riguarda le prestazioni del controller. Non conosco specificamente la tua SAN, ma la maggior parte se non tutte le SAN richiedono che un LUN sia di proprietà di un singolo controller alla volta. Volete avere abbastanza LUN sul sistema in modo da poter bilanciare il carico di lavoro tra i controller.

Ad esempio, se avessi un solo LUN, utilizzeresti solo un controller attivo alla volta. L'altro resterebbe inattivo perché non avrebbe nulla da fare.

Se avessi due LUN, ma uno fosse molto più occupato dell'altro, utilizzeresti entrambi i controller ma non allo stesso modo. Quando si aggiungono più LUN, i controller condividono il carico di lavoro in modo più uniforme.

Consigli specifici per te:

Le VM sono tutte relativamente uguali in termini di requisiti di prestazioni. Creerei due LUN, uno per controller. Iniziare a posizionare le macchine virtuali sul primo LUN e misurare la latenza I / O e la profondità della coda nel tempo man mano che le macchine virtuali si installano. Non utilizzare ancora il secondo LUN. Continuare a riempire LUN 1. Raggiungerai un punto in cui inizierai a vedere gli indicatori di prestazione che il LUN è pieno, oppure avrai migrato metà delle tue VM su quel LUN e avrai comunque mantenuto le prestazioni.

Se riscontri problemi di prestazioni, rimuoverei il 30% delle macchine virtuali da LUN 1 e le sposterei in LUN 2. Quindi iniziare a riempire LUN 2 nello stesso modo. Vai a LUN 3 se necessario ... ha senso? L'idea è quella di raggiungere la massima densità di VM su un determinato LUN insieme a un sovraccarico di circa il 30% per la camera di fudge.

Vorrei anche creare un paio di LUN "ad alte prestazioni" per qualsiasi VM che colpisse pesantemente. Ancora una volta, uno per controller per condividere il carico di lavoro.

Sulla base delle tue spiegazioni sopra, dovresti andare bene con 1 archivio dati. 60 vm su 3 host non è poi così male (20: 1). Tuttavia, consiglierei di aggiornare l'HBA a 8 GB, se finanziariamente possibile su almeno un host, a condizione che lo switch in fibra sia almeno uno da 8 GB.

Detto questo, farei almeno 2 se non 3 archivi di dati sull'array. 1 archivio dati per host, con tutti i server che accedono agli altri per vMotion. Non so molto sull'array IBM; con EMC vorrei creare un singolo gruppo RAID10 con 3 LUN per ciascun archivio dati. Con questa configurazione, l'host con gli HBA da 8 Gb sarebbe perfetto per i tuoi sistemi I / O superiori.

È possibile eseguire 1 archivio dati / server e in alcuni casi lo faccio da solo, ma lo faccio solo con la replica SAN su server speciali. Gestire 87 diversi archivi di dati su 9 server per vMotion diventa confuso quando lo configuri! La maggior parte dei miei VM sono in archivi di dati condivisi con 5-10 server su di essi a seconda di quanto spazio hanno bisogno.

Un'ultima nota. Se si dispone di qualsiasi tipo di server in una coppia / cluster di failover o con bilanciamento del carico, li si desidera in diversi archivi di dati. Non si desidera che il datastore fallisca e che quindi non rimanga senza server. Certo, se perdi l'array, hai perso tutto, ma è per questo che eseguiamo il backup, giusto?