Best practice per la virtualizzazione dei server sulla SAN?

Bene, quindi voglio iniziare a sfruttare la mia SAN un po 'più di quanto non abbia mai fatto e, allo stesso tempo, sfruttare ESXi.

Attualmente, ho un array di blade Dell PowerEdge 1955 collegati a un array di storage EMC AX4-5 FC a contenitore singolo. Sto essenzialmente usando la SAN come DAS. Ho dei LUN sulla SAN che puntano a macchine fisiche specifiche e tali macchine utilizzano i LUN per qualsiasi cosa (principalmente database e condivisioni Samba / NFS, a seconda del server di destinazione).

Ho più file server fisici e ognuno ha una configurazione di configurazione samba per servire le condivisioni appropriate. Dal momento che non ho mai fatto funzionare RHCS, solo uno dei file server ha i LUN montati alla volta. Nel caso in cui un file server muoia, lo recinto manualmente (smontando e presentando l'unità, utilizzando l'utilità navisphere o uccidendo la potenza tramite DRAC), quindi utilizzando l'utilità navisphere per richiamare i LUN presentati sul contendente successivo ( dopodiché, avvia apache e gli altri demoni). Tutto a mano, proprio ora.

Mi sento come se Ferris Bueller suonasse il clarinetto. Non ho mai avuto una lezione!

Comunque, sto cercando di migliorare. Quello che voglio fare è installare ESXi sugli host fisici, quindi creare LUN per contenere due immagini del file server (nel caso in cui uno venga corrotto / fubar), uno dei quali sarà attivo, l'altro sarà lo standby. Almeno in questo modo, non migliorerò l'automazione (anche se inizierò a scrivere uno script per cambiare presto il server "attivo"), ma sento che sto aggiungendo flessibilità, inoltre posso usare gli host ESXi per contenere altre macchine virtuali e l'hardware non verrà sprecato, come è ora.

Le mie domande sono:

1) Quanto è stupido il mio piano?

2) Quando si tratta dell'implementazione effettiva, dovrei creare una normale immagine vmdk sul LUN o dovrei darle una partizione "grezza" (se è possibile anche con ESXi?)

3) Esiste un "buon" modo di usare fileserver non cluster?

Il tuo piano non è pazzo. Come al solito, ci sono molti modi per attaccarlo in base a ciò che stai cercando di ottenere e al modo in cui proteggere i tuoi dati.

Innanzitutto, è possibile presentare un LUN non elaborato a una macchina virtuale utilizzando un "Mapping dispositivo non elaborato". Per farlo:

• Presentare il LUN all'host ESXi (o al gruppo host, se si intende utilizzare il clustering / HA)
• Aggiungi un disco alla VM, seleziona Mapping dispositivo non elaborato, punta al LUN
• Eseguire nuovamente la scansione del bus SCSI all'interno della VM
• fdisk, mount e aggiungi a fstab, proprio come un normale disco.

Upside: veloce da configurare, veloce da usare, facile, può rappresentare il disco per l'host fisico se ti trovi nella necessità di V2P in pista

Unico inconveniente: potresti perdere alcune opzioni di snapshot / rollback basate su VMware, a seconda se usi la modalità di compatibilità fisica o virtuale

Un'opzione alternativa è quella di creare VMFS sul LUN per creare un archivio dati, quindi aggiungere un disco VMDK alla VM che si trova su tale archivio dati.

• Upside: è compatibile con Storage vMotion se acquisti una licenza per usarla. Ciò consente la migrazione a caldo dei dischi VMDK tra LUN e persino SAN.

In entrambi i casi, ti trovi in ​​una posizione di rischio simile se VMware o la tua VM mangiano il filesystem durante un errore; uno non è drasticamente migliore dell'altro, anche se le opzioni di recupero disponibili saranno piuttosto diverse.

Non distribuisco RDM a meno che non sia necessario; Ho scoperto che non mi offrono molta flessibilità come VMDK (e sono stato morso da bug che li rendevano poco pratici durante l'esecuzione di altre operazioni di archiviazione (dal momento che risolto - vedi la sezione RDM in quel link))

Per quanto riguarda la VM, la soluzione migliore per la flessibilità è quella di archiviare il disco di avvio del fileserver come VMDK sulla SAN in modo che altri host possano avviarlo in caso di errore dell'host. Utilizzando la funzionalità HA di VMware, l'avvio della VM su un altro host è automatico (la VM si avvierà sul secondo host come se fosse stata estratta la potenza; aspettati di eseguire i soliti fsck e magic per farla apparire come nel caso di un server normale ). Nota, HA è una funzione con licenza.

Per mitigare un errore della VM, è possibile creare un clone leggero del file server, contenente il minimo indispensabile per l'avvio e fare in modo che SAMBA si avvii in uno stato configurato e memorizzarlo sul disco locale di ciascun host, in attesa di aggiungere l'unità dati dal VM non riuscita e accenderla.

Questo può o meno acquistare opzioni extra in caso di guasto della SAN; nel migliore dei casi, l'archiviazione dei dati richiederà un fsck o un'altra riparazione, ma almeno non è necessario correggere, ricostruire o configurare la VM in cima. Nel peggiore dei casi, hai perso i dati e devi tornare al nastro ... ma comunque eri già in quello stato.

Continuerei con le immagini di vmdk, nel caso in cui ti spostassi a utilizzare vmotion in futuro, non sai mai che potresti ottenere un budget per questo.

Se le tue macchine non sono raggruppate, per quanto mi riguarda il modo migliore per gestirle è cercare di distribuire il carico nel modo più uniforme possibile. Ho 3 2950 non cluster in cui il carico dai vms più critici è il più possibile 1/3 su ciascuno. È improbabile che la teoria perda più di una scatola alla volta, quindi almeno i 2/3 saranno in grado di continuare a funzionare senza compromessi.

Da un punto di vista energetico sarebbe probabilmente più efficiente caricare le macchine il più vicino possibile al 100% e avere altre macchine spente, ma sembra che mi metta tutte le uova nello stesso paniere.

Non mi definirei un esperto in questo, è proprio quello che faccio.

Ehi Matt. Esistono molti modi per suddividere una soluzione quando si utilizza una soluzione di virtualizzazione. Prima di tutto ci sono stati molti benchmark che mostrano Raw LUN (RDM) rispetto alle prestazioni di VMDK e la differenza si dimostra in genere trascurabile. Alcune cose da tenere a mente con gli RDM: solo alcune situazioni di clustering richiedono l'utilizzo di RDM (cluster MS). Gli RDM hanno un limite di 2 TB, ma LVM può essere utilizzato per aggirare questo limite. Gli RDM sono "più difficili" da tenere in considerazione rispetto a dare un LUN a ESXi da utilizzare per VMFS e inserendo i vmdk su di esso. I VMDK (come detto) offrono alcuni vantaggi: svMotion, Istantanee (impossibile eseguire lo snapshot di un pRDM).

Se eseguo Free ESXi, ecco come potrei fare per la tua situazione. Prima di tutto, tutti i dati sono nei file vmdk su LUNS VMFS. Installa 2 VM e usa Heartbeat per il failover di IP e servizi. Heartbeat sposta l'IP del servizio su e può gestire gli script per smontare / montare il LUN di dati ove appropriato. È anche possibile creare script per un'interfaccia della riga di comando remota di VMware per garantire che la macchina virtuale "inattiva" venga spenta per la protezione. Con il battito cardiaco che coordina direttamente tra i sistemi il rischio sia di accedere ai dati lun / di eseguire gli stessi servizi dovrebbe essere estremamente basso. La chiave qui è assicurarsi che il montaggio / smontaggio dei dati LUN e l'avvio / arresto dei servizi siano gestiti da Heartbeat, non dai normali meccanismi di init.

Un failover alternativo potrebbe essere realizzato tramite il sistema di monitoraggio. Quando rileva l'host inattivo, potrebbe utilizzare l'interfaccia della riga di comando remota di VMware per emettere uno spegnimento (per sicurezza) e quindi accendere il backup VM. In questa situazione il fallimento è abbastanza manuale.

Nel mio "piccolo" ambiente non ho visto un VMDK corrotto. Quello che ho anche capito è che se hai più di 2 host ESX (i) o una dozzina di VM, vorrai ottenere vCenter per tenere traccia di tutto. Alcuni dei pacchetti Essential / Plus non sono troppo costosi considerando i vantaggi.

Matt, sai che non uso VMware ma ho sempre usato "RAW" con Xen. Con solo alcune macchine virtuali che sono leggermente caricate, dubito che vedrai una grande differenza di prestazioni. Ma quando inizi a entrare sempre più ospiti se tutti questi ospiti si trovano sullo stesso file system, finirai con problemi di profondità della coda. Ciò è particolarmente vero per l'archiviazione supportata da NFS. Non è tanto che il server NFS ha i problemi, ma la maggior parte delle implementazioni client NFS fanno schifo.

Non conosco un buon modo per sincronizzare i vmdks se stai cercando ridondanza (errore di San). Ma se usi i dispositivi a blocchi hai ancora la possibilità di usare DRBD per replicare solo i vms che vuoi / hai bisogno di essere replicati.

Penso che dovresti chiederti "Ho mai intenzione di tornare ai server fisici"

Se la risposta è forse allora forse dovresti attenersi a RDM. ESXi con RDM richiederebbe (credo) di acquistare qualcosa per far funzionare la tua fibra (di nuovo non sicuro al 100% su esxi).

Avevamo diverse macchine che ho appena spostato rapidamente dai server fisici a ESX (4.0) usando RDM. Ho avuto un mix di macchine Linux e Windows (super facile per entrambe le piattaforme). Abbiamo ancora alcuni FreeBSD legacy in esecuzione (6.0 e precedenti) su server fisici per i quali non possiamo usare RDM perché il vecchio kernel FBSD non lo supporta. È stato veloce e mi ha richiesto di fare nient'altro che indicare il mio LUN e quindi installare gli strumenti VMWare. Brain dead easy .. nessun convertitore, nessun problema ...

Un'altra cosa che dovresti chiederti è "Quali funzionalità di VMWare voglio usare?"

A seconda della risposta, potresti non avere altra scelta che VMDK. Se usi la tua SAN per le istantanee e non ti interessa usare vmware per esempio.

Alcuni appunti condivido con te su ciò che abbiamo riscontrato finora. Vmotion funziona ugualmente bene con RDM e VMDK, Storage Vmotion invece funziona correttamente solo con non RDM, e provando a usare l'archiviazione Vmotion per passare da RDM a VMDK fa schifo basta usare il convertitore .. La maggior parte delle distribuzioni Linux hanno un pacchetto di strumenti vmware open source che rende l'installazione degli strumenti un problema. L'applicad di backup funziona davvero bene ed è privo di vmware, ma non fa tutte le cose che vorremmo. Consiglio vivamente di prendere una lezione da VMware. Quella che ho preso è stata una settimana e valeva ogni centesimo Il supporto VMWare è fantastico .. Se ottieni un contratto di supporto e devi chiamare sono i migliori ... Sono frustrato arrivare a qualcuno che mi può aiutare (in molti menu ... ), ma una volta che li ottengo SEMPRE arrivano con un supporto rapido e affidabile.