Le migliori scelte di filesystem per NFS che memorizzano le immagini del disco VMware

Attualmente utilizziamo una SAN iSCSI come memoria per diversi server VMware ESXi. Sto studiando l'uso di un target NFS su un server Linux per macchine virtuali aggiuntive. Sono anche aperto all'idea di utilizzare un sistema operativo alternativo (come OpenSolaris) se fornirà vantaggi significativi.

Quale filesystem basato su Linux privilegia file contigui di dimensioni molto grandi (come le immagini del disco di VMware)? In alternativa, in che modo le persone hanno trovato ZFS su OpenSolaris per questo tipo di carico di lavoro?

(Questa domanda è stata originariamente posta su SuperUser ; sentiti libero di migrare le risposte qui se sai come fare).

Consiglio vivamente di dare un'occhiata a ZFS, ma per ottenere prestazioni decenti, dovrai prendere un dispositivo dedicato come ZFS Intent Log (ZIL). Fondamentalmente questo è un piccolo dispositivo (pochi GB) in grado di scrivere in modo estremamente veloce (20-100 K IOPS) che consente a ZFS di confermare immediatamente che le scritture sono state sincronizzate con l'archiviazione, ma attendere fino a 30 secondi per impegnare effettivamente le scritture sui dischi rigidi in la tua piscina. In caso di crash / interruzioni, qualsiasi transazione non impegnata nella ZIL viene riprodotta al momento del mount. Di conseguenza, oltre a un UPS, è possibile che si desideri un'unità con un alimentatore interno / supercondensatore, in modo tale che eventuali IO in sospeso possano essere archiviati in modo permanente in caso di interruzione dell'alimentazione. Se si opta per un dispositivo ZIL dedicato, le scritture possono avere un'elevata latenza che porta a tutti i tipi di problemi. Supponendo che non ti interessi a Sun "

• DDRDrive X1 - 4 GB DDR2 + 4 GB SLC Flash in una scheda PCIe x1 progettata esplicitamente per l'uso ZIL. Le scritture vanno su RAM; in caso di perdita di potenza, sincronizza la RAM su NAND in <60sec alimentato da un supercondensatore. (IOPS 50k-300k; $ 2000 Direct, $ 1500 per .edu)
• SSD Intel X25-E da 32 pollici da 2,5 pollici (SLC, ma senza supercap, IOPS da 3300 in scrittura); [$ 390 @ Amazon] [11]
• OCZ Vertex 2 Pro 40 GB SSD da 2,5 pollici (supercap, ma MLC, 20k-50k scrivere IOPS); $ 435 @ Amazon .

Dopo aver installato OpenSolaris / Nexenta + ZFS, ci sono molti modi per spostare i blocchi tra OpenSolaris ed ESX boxen; ciò che è giusto per te dipende fortemente dalla tua infrastruttura esistente (switch L3, schede Fibre) e dalle tue priorità (ridondanza, latenza, velocità, costo). Ma poiché non hai bisogno di licenze specializzate per sbloccare la funzionalità iSCSI / FC / NFS, puoi valutare tutto ciò che hai l'hardware e scegliere il tuo preferito:

• Target iSCSI (sovraccarico della CPU; nessun supporto TOE in OpenSolaris)
• Target Fibre Channel (le schede Fibre non sono economiche)
• NFS (VMWare + NFS può essere pignolo, limitato a 32 supporti)

Se non puoi spendere $ 500 per la valutazione, prova con e senza ZIL disabilitato per vedere se ZIL è un collo di bottiglia. (Probabilmente lo è). Non farlo in produzione . Non scherzare con la deduplicazione ZFS ancora a meno che tu non abbia anche un sacco di RAM e un SSD per L2ARC. È sicuramente bello una volta che lo hai installato, ma provi sicuramente a fare un po 'di tuning NFS prima di giocare con il dedup. Una volta ottenuto saturando i collegamenti da 1-2 Gb, ci sono opportunità di crescita in 8 GB FC, 10 GB e Infiniband, ma ognuno richiede un investimento significativo anche per la valutazione.

Non farei esattamente questo. Nella mia esperienza, Linux (in particolare CentOS 3/4/5) è una scelta generalmente scarsa per un server NFS. Ne ho avuti diversi e ho scoperto che sotto carico, latenza e capacità produttiva tendono a calare per motivi che non potremmo mai farci capire.

Nei nostri casi, abbiamo confrontato le prestazioni back-to-back di Linux con Solaris (su Ultra-SPARC) e NetApp; entrambi restituirono risultati in termini di prestazioni da mela a mela e in termini nebulosi di "ingegneri che non si lamentavano quasi altrettanto della latenza quando il server era sotto carico". Ci sono stati diversi tentativi di ottimizzare il server NFS Linux; entrambi i sistemi NetApps e Solaris sono stati eseguiti immediatamente. E poiché entrambi i sistemi Solaris e NetApp coinvolti erano più vecchi, si poteva sostenere che i server Linux avevano tutti i vantaggi e non riuscivano ancora a essere convincenti.

Se hai tempo, varrebbe la pena sperimentare la configurazione dello stesso hardware con OpenSolaris (ora che Solaris è effettivamente troppo costoso da usare), Linux e forse una o due varianti di BSD, e gareggiarle. Se riesci a trovare alcune metriche delle prestazioni (ad esempio i conteggi di I / O su disco in una macchina virtuale ospitata fuori dallo store), potresti creare un white paper o un articolo Internet interessanti. (Se hai tempo.)

Per quanto riguarda NFS in generale, le persone di NetApp mi hanno detto più volte che i loro benchmark hanno mostrato che NFS aveva un costo compreso tra il 5 e il 10% in termini di prestazioni per le VM - e se la tua applicazione era abbastanza sensibile da costituire un problema, non dovresti virtualizzare in primo luogo.

Ma devo confessare che dopo tutto quel tempo e tutte le lacrime, i nostri negozi di VM di produzione non locali sono tutti alimentati da iSCSI, principalmente da NetApp.

Stiamo usando OpenSolaris 2009/06 con una configurazione RAID 10 ZFS per fornire NFS al nostro server VMWare ESXi. Finora funziona abbastanza bene per le nostre esigenze. Stiamo utilizzando unità di tipo SATA Raid (unità Seagate ES.2 da 1 TB). Abbiamo ancora qualche ottimizzazione da fare comunque.

Sono un grande fan dei datastore NFS per VMware, NetApp ha un'implementazione eccellente.

TR-3808 confronta il ridimensionamento dei datastore condivisi connessi NetApp FC, iSCSI e NFS, che è una lettura eccellente.

Potresti prendere in considerazione il bug di 3+ ​​anni con ZFS ARC che persiste ancora prima di saltare troppo in profondità con ZFS ...

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017

(Questo è cattivo in quanto andrà oltre i limiti della VM di un hypervisor!)