Scelta di una tecnologia SAN per centinaia di server Web VM

Il problema

Abbiamo un problema con le prestazioni su una piattaforma esistente, quindi mi rivolgo alla mente dell'alveare per una seconda opinione su questo. Il problema delle prestazioni finora riguarda gli IOPS piuttosto che il throughput.

Lo scenario

Un centro blade di 16 host, ciascuno con 64 GB di RAM. (È un Dell M1000e con M610, ma probabilmente non è rilevante) 500 VM, tutti i server Web (o tecnologie web associate come MySQL, bilanciamento del carico, ecc.), Circa il 90% sono Linux e il resto Windows. Hypervisor è VMWare vSphere. Dobbiamo fornire l'HA host, quindi l'archiviazione locale è esaurita. Pertanto, gli host hanno solo una scheda SD per l'avvio.

Un po 'di pensiero di fondo

Al momento siamo fino a 6 host (il centro blade sarà a piena capacità tra un anno alla crescita attuale) e stiamo eseguendo iSCSI su un Dell MD3220i con MD1220 per l'espansione.

Possibili opzioni che abbiamo considerato e pensieri immediati insieme a loro:

• Diffondere le macchine virtuali su datastore NFS ed eseguire l'archiviazione NFS che soddisfa i requisiti di prestazione per un determinato numero di macchine virtuali. NFS sembra più economico da ridimensionare, oltre ad essere stato estratto un po 'di più rispetto allo storage a livello di blocco in modo da poterlo spostare in base alle esigenze.
• Aggiunta di più controller / destinazioni MD3220i. Siamo preoccupati, tuttavia, che ciò possa avere un effetto negativo in qualche modo sul modo in cui VMWare gestisce molti obiettivi.
• Scambio di tutti i dischi da Nearline SAS a SSD. Questo dovrebbe risolvere interamente il problema IOPS, ma ha l'ovvio effetto collaterale di ridurre la nostra capacità di archiviazione. Inoltre è ancora molto costoso.
• vSphere 5 ha un'appliance di archiviazione. Non abbiamo studiato così tanto, ma deve funzionare bene?

La domanda

Quale tipo di archiviazione eseguiresti al di sotto di tutto ciò? Non avrebbe bisogno di scalare su un altro centro blade, dovrebbe solo fornire prestazioni relativamente buone per tutte quelle macchine virtuali.

Non sto cercando le risposte "Acquista SAN x perché è la migliore". Sto cercando pensieri sulle varie tecnologie SAN (iSCSI, FC, FCoE, InfiniBand, NFS, ecc.), Diversi tipi di archiviazione (SATA, SAS, SSD) e metodologie per la gestione dell'archiviazione per centinaia di VM (consolidamento, separazione , Sharding, ecc.).

Assolutamente tutti i pensieri, i collegamenti, le guide, i puntatori ecc. Sono ben accetti su questo. Mi piacerebbe anche sentire pensieri sulle opzioni di cui sopra che avevamo già considerato.

Molte grazie in anticipo per qualsiasi input!

Aggiornamento 5 marzo '12

Finora alcune risposte fantastiche, grazie mille a tutti!

Seguendo le risposte a questa domanda finora, sto cominciando a pensare che il seguente percorso sia il modo:

• Livellare lo spazio di archiviazione disponibile nel cluster VMWare e collocare i dischi VM in uno spazio di archiviazione adeguato per i loro carichi di lavoro.
• Potenzialmente utilizzare una SAN in grado di gestire automaticamente il posizionamento dei dati su una memoria adatta.
• Infiniband sembra essere il più conveniente per ottenere la larghezza di banda richiesta con gli host a piena capacità.

Sembra sicuramente che varrebbe la pena avvalersi dei servizi di pre-vendita di un importante fornitore di SAN per farsi un'idea dello scenario.

Continuerò a considerare questo problema per un po '. Nel frattempo altri consigli ricevuti con gratitudine!

La chiave per una buona piattaforma di archiviazione VMWare è capire quale tipo di carico genera VMWare.

• Innanzitutto, poiché si ospitano molti server, il carico di lavoro è in genere casuale. Esistono molti flussi IO in esecuzione contemporaneamente e non molti di essi possono essere pre-memorizzati nella cache.
• Secondo, è variabile. Durante le normali operazioni, potresti vedere letture casuali del 70%, tuttavia nell'istante in cui decidi di spostare una VM in un nuovo archivio dati o qualcosa del genere, vedrai una scrittura sequenziale di 60 GB. Se non stai attento all'architettura, questo può paralizzare la capacità del tuo archivio di gestire un IO normale.
• In terzo luogo, una piccola parte dell'ambiente genererà in genere una grande porzione del carico di lavoro di archiviazione.

Il modo migliore per avvicinarsi alla creazione di storage per una piattaforma VMWare è partire dai fondamenti.

• È necessaria la capacità di gestire un carico di lavoro di lettura casuale di grandi dimensioni, il che significa unità più piccole e veloci, nonché eventualmente SSD. I più moderni sistemi di archiviazione consentono di spostare i dati automaticamente in base alla modalità di accesso. Se hai intenzione di utilizzare SSD, assicurati che sia così che lo usi. Dovrebbe essere lì come un modo per ridurre gradualmente i punti caldi. Indipendentemente dal fatto che si usi SSD o meno, è utile poter eseguire tutto il lavoro su tutte le unità, quindi sarebbe utile qualcosa con un tipo di pool di archiviazione.
• È necessaria la capacità di gestire scritture di grandi dimensioni intermittenti, che non si preoccupano tanto della velocità del mandrino delle unità sottostanti, ma si preoccupano dell'efficienza dello stack del controller e della dimensione della cache. Se hai il caching con mirroring (che non è facoltativo a meno che tu non sia disposto a tornare ai backup ogni volta che si verifica un errore del controller), la larghezza di banda tra le due cache utilizzate per il mirroring sarà il collo di bottiglia per le scritture sequenziali di grandi dimensioni, in genere. Assicurati che tutto ciò che ottieni abbia un'interconnessione controller (o cluster) ad alta velocità per la memorizzazione nella cache di scrittura. Fai del tuo meglio per ottenere una rete front-end ad alta velocità con tutte le porte che puoi ottenere rimanendo realistica sul prezzo. La chiave per buone prestazioni del front-end è di caricare il tuo storage su quante più risorse front-end possibile.
• Puoi ridurre seriamente i costi disponendo di un livello per l'archiviazione a bassa priorità e il thin provisioning. Se il tuo sistema non sta migrando automaticamente i singoli blocchi su unità grandi / lente a basso costo (come SAS o SATA nearline con 7200 RPM e 2 TB + dimensioni), prova a farlo manualmente. Le unità lente di grandi dimensioni sono obiettivi eccellenti per archivi, backup, alcuni file system e persino server a basso utilizzo.
• Insistere sul fatto che l'archiviazione sia integrata VAAI in modo che VMWare possa disallocare parti inutilizzate delle macchine virtuali e gli archivi dati.

Le mie grandi implementazioni VMWare sono NFS e iSCSI su 10GbE. Ciò significa HBA 10GbE a doppia porta nei server, nonché la testa di archiviazione. Per questo sono un fan dello storage basato su ZFS. Nel mio caso è avvolto attorno al NexentaStor commerciale , ma alcuni scelgono di fare il proprio.

Le caratteristiche principali dell'archiviazione basata su ZFS in questo contesto sarebbero la funzionalità di memorizzazione nella cache ARC / L2ARC, che consente di eseguire l'archiviazione su più livelli. I dati più attivi si farebbero strada nella memoria RAM e SSD come secondo livello. Sarebbe anche utile eseguire il pool di archiviazione principale su unità SAS da 10k o 15k.

Questo è un altro caso di profilazione e comprensione del carico di lavoro. Collabora con qualcuno che può analizzare i tuoi schemi di archiviazione e aiutarti a pianificare. Sul lato ZFS / NexentaStor, mi piace PogoStorage . Senza questo tipo di approfondimento, il metodo di trasporto (FC, FCoE, iSCSI, NFS) potrebbe non avere importanza. Hai qualche monitoraggio della tua infrastruttura esistente? Come si presenta l'attività I / O adesso?

La domanda chiave è: "dov'è il collo di bottiglia?" Citi IOPS, ma ciò significa che hai identificato positivamente i dischi stessi come colli di bottiglia, o semplicemente che le porte SAN non sono in esecuzione a capacità, o che le macchine virtuali sono molto più in ritardo di quanto desideri?

Se hai definitivamente identificato che i dischi sono il fattore limitante, passa a NFS o infiniband o qualsiasi altra cosa non farà squat per le tue prestazioni - hai bisogno di SSD (o almeno archiviazione a più livelli con SSD nel mix) o un intero fascio di più mandrini (una soluzione che è diventata molto più costosa di recente da quando la produzione mondiale di motori passo-passo è stata lavata nell'oceano).

Se non sei sicuro al 100% di dove si trovi effettivamente il collo di bottiglia, devi prima scoprirlo: scambiare parti dell'infrastruttura di archiviazione più o meno a caso in base alle ipotesi di altre persone qui non sarà molto efficace (soprattutto considerando quanto costosi saranno i cambiamenti da implementare).

Se vuoi iscsi o nfs allora minimamente avrai bisogno di poche porte da 10 / 40gb o infiniband che è di gran lunga l'opzione più economica ma le soluzioni di archiviazione native per infiniband sembrano essere limitate. Il problema sarà il modulo per il bladecenter quali sono le sue opzioni, di solito 8 gb fc o 10 \ 1 gbe e forse infiniband. Si noti che infiniband può essere utilizzato con nfs e nulla viene chiuso ad esso in termini di prestazioni \ prezzo. se il centro della lama supporta qdr infiniband lo farei con un host Linux di qualche tipo con un qdr infiniband tca tramite nfs. Ecco un buon link che descrive questo http://www.zfsbuild.com/2010/04/15/why-we-chose-infiniband-instead-of-10gige

ma se il bladecenter può supportare qdr infiniband e puoi permetterti l'infinito nativo, allora questa è la soluzione che dovresti scegliere.

Attualmente è possibile ottenere interruttori da 40 gb molto più economici (questo è un pensiero strano) quindi interruttori da 10 gbe ma dubito che il centro della lama lo sosterrà.

La memoria locale è esaurita? Sono abbastanza contento del throughput di scrittura sul mio RAID 5s locale - eseguito il mirroring con DRBD8 sul partner cluster della mia macchina XEN ... (ma questo "non è supportato", ovviamente).

A parte questo, sono abbastanza sicuro che mySQL sia il tuo problema di prestazioni (non ho mai visto un DB peggiore). Prova a rimuoverlo e / o prova a mettere l'intero DB nella cache del filesystem (per l'accesso in lettura) ...