Cerca nel blog

giovedì 27 gennaio 2011

MSCS e vCenter Server

Il funzionamento del cluster Microsoft (MSCS) in ambiente ESX non lascia perplessità in relazione al supporto da parte del vendor che, nella KB 1004617, rimanda alle guide per la configurazione suddivise in base alla versione di ESX

L’utilizzo del cluster Microsoft quale strumento per la protezione di vCenter NON e' Certificato da VMware.

La KB 1024051 sul sito del produttore spiega la situazione. Leggendo si comprende che VMware non certifica le soluzioni di terze parti, deduco che non essendo VMware produttrice del software il vendor non è in grado di validarne la bontà, ma VMware fornisce supporto per qualsiasi problema che possa emergere in un ambiente che usa queste soluzioni in relazione al downtime di vCenter Server. La nota prosegue dicendo che se il problema è considerato di pertinenza del software di clustering di terze parti allora VMware farà riferimento ad una specifica policy di supporto per le soluzioni di terze parti.

Anche altri blog hanno dato la loro interpretazione come nel caso dell’articolo pubblicato su www.yellow-bricks.com.

Per maggiori informazioni è possibile consultare la KB 1024051

mercoledì 26 gennaio 2011

Alta affidabilità per vCenter Server

vCenter Server nella suite VMware vSphere è il prodotto che permette, tra le altre funzionalità, di controllare e gestire interamente gli host ESX/ESXi con le relative VM. Grazie a vCenter Server è possibile creare cluster per proteggere le VM e/o per bilanciarle tra gli host appartenenti al cluster stesso.

Il vCenter Server, se non protetto, può diventare il "single point of failure” dell’infrastruttura e se la sua assenza può non causare problemi alle VM esistenti ed in esecuzione, limita le attività di gestione, manutenzione e monitoraggio dell’intero ambiente. Se l’ambiente vSphere è inoltre arricchito da ulteriori add-on che fanno leva sui dati di consumo delle risorse, raccolti nel database di vCenter Server, un suo default potrebbe avere impatti più significativi.

La protezione di vCenter Server è strettamente legata a due fattori:
  • alla tipologia di server, fisico o virtuale, che ospita il servizio;
  • downtime massimo tollerato o al tempo di reazione necessario al riavvio del servizio.

Se vCenter è stato installato su una macchina fisica è possibile ricorrere a soluzioni VMware o soluzione di terze parti.

Rimanendo in casa VMware è possibile proteggere vCenter attraverso il prodotto VMware vCenter Server Heartbeat, che oltre al servizio può proteggere tutte le sue componenti: dal database agli add-on come VMware vCenter Update Manager e VMware View Composer. VMware vCenter Server Heartbeat non discrimina sulla natura della macchina da proteggere, è quindi possibile proteggere in vCenter fisico con uno virtuale, oppure con entrambe i nodi fisici, oppure ancora con entrambe i nodi virtuali.

Una ulteriore soluzione che sfrutta strumenti VMware, anche se artigianale, è quella di avere una VM in stand-by pronta ad essere eseguita in caso di fallimento del vCenter principale. La VM in questione potrebbe essere il frutto di una periodica attività di conversione eseguita con VMware vCenter Converter. In questo scenario è necessario tener presente che il failover non è automatico e, soprattutto, che la macchina avviata sarà allineata con i dati dell’ultima conversione avvenuta.

Scegliendo soluzioni di terze parti è possibile utilizzare tecniche di clustering tra le quali MSCS (Microsoft Cluster Services noto anche come Failover Clustering) o VCS (Veritas Cluster Services). In questi casi oltre ai requisiti minimi di sistema necessari al vCenter è necessario utilizzare sistemi operativi qualificati dai produttori del software di clustering. Sull’effettivo supporto di queste soluzioni scriverò un articolo ad hoc, nel mentre vi rimando alla KB 1024051

Parlando invece di una macchina virtuale ci si può affidare a VMware HA per la protezione del vCenter Server, sempre che un minimo di downtime sia tollerato e che, oltre al servizio vCenter (vpxd), sia protetto il relativo DB, elemento indispensabile al servizio. E’ invece escluso VMware Fault Tolerance in quanto i requisiti minimi per vCenter prevedono 2 CPU, requisito che squalifica il prodotto.

Per maggiori informazioni consultare la documentazione relativa a:

giovedì 20 gennaio 2011

Cambiamenti al processo di consolidamento delle snapshot

L’uso delle snapshot per le VM è molto comodo, molti software di backup si avvalgono di questa funzionalità per eseguire il salvataggio a caldo delle macchine. Le snapshot comunque possono generare qualche problema, uno dei quali è il consumo di molto spazio sul datastore. Ogni snapshot, di fatto, può crescere tanti quanto il disco padre.


Se è intuibile che il consumo dello spazio del datastore avviene in presenza di una snapshot, è importante comprendere che, anche il consolidamento dei dati (commit della snapshot) può comportare un imprevisto consumo di spazio, fino ad arrivare nel caso peggiore all’errore per esaurimento dello spazio disco.

Il comportamento descritto nel passo precedente è stato corretto a partire da vSphere 4.0 Update 2 e versioni successive. In questo articolo, attraverso un esempio, si parla dei cambiamenti nella metodologia di consolidamento delle sanpshot usate per le macchine virtuali.

Partiamo con una VM che risiede si un datastore da 600 GB e dispone di un disco da 500 GB. Alla presente VM sono state applicate 8 successive snapshot in tempi diverse, ogni snapshot ha una dimensione come riportato dalla seguente immagine:

Scanario di partenza

A questo stadio il datastore è scritto per 564 GB (disco di base più la somma delle snapshot), quindi siamo prossimi all’esaurimento dello spazio sul datastore. In questa condizione per liberare spazio è possibile consolidare le snapshot attraverso lo snapshot manager e, supponendo che la VM lavori nell’ultima snapshot è possibile premere il pulsante “Delete All”.

Prima di VMware vSphere 4.0 U2

Dall’immagine sotto riportata si deduce che, la commit dei dati inizia dall’ultima snapshot (quella pià recente) su quella precedente risalendo tutta la catena fino al disco di base.

Consolidamento delle snapshot prima di VMware vSphere 4.0 U2


Questa strada oltre a non liberare spazio risulta essere un processo lento.

A partire dalla versione di VMware vSphere 4.0 U2 e versioni successive.

Le operazioni per il consolidamento sono cambiate, il processo inizia dalla snapshot più vecchia e la consolida al disco di base e ad attività terminata elimina il file della snapshot proseguendo il ciclo con l’ultima snapshot ora presente. Con questo metodo si ottengono 2 risultati:
  • si libera più velocemente lo spazio a livello di datastore;
  • il processo di commit è più performante.


Consolidamento delle snapshot a partire da VMware vSphere 4.0 U2



Per maggiori informazio si rimanda a:

lunedì 10 gennaio 2011

Tutto quello che avreste voluto sapere...

... sulla funzionalità "HotPlug" di CPU & RAM di vSphere ma che non avete mai osato chiedere!

  • HotPlug non è abilitato per default: occorre attivarla nel pannello di configurazione di ogni VM.

EnableHotPlug.jpg

  • La possibilità di abilitare "HotPlug" dipende dal sistema operativo installato all'interno della VM, e necessita di hardware version 7.
  • Se "HotPlug" non è attivato, per attivarlo occorrerà un reboot della VM.
  • "HotPlug" vi consente di aggiungere RAM "a caldo", ma non è detto che il sistema operativo guest la rilevi immediatamente: potrebbe essere necessario un reboot.
  • La buona riuscita delle operazioni di aggiunta "a caldo" di RAM&CPU dipende dal sistema operativo installato nellq VM, come dimostra questo schema (l'asterisco indica che è richiesto un reboot):

HotAddSchema.jpg

  • "HotPlug" non è compatibile con l'opzione "Fault Tolerance".
  • "HotPlug" è attivabile solo con particolari versioni di vSphere 4: Advanced, Enterprise e Enterprise Plus.
  • I sistemi operativi Linux supportano l'aggiunta a caldo di RAM ma non di CPU: sembra che questa possibilità verrà aggiunta nella prossima versione di Red Hat ES & Suse ES.

lunedì 3 gennaio 2011

Aggiungere un driver personalizzato all'esx4i

Recentemente mi sono capitati sottomano 2 server Dell PowerEdge 2950, che, premetto subito, non rientrano nell’HCL di vmware.

Però, dato che i server erano abbastanza ben carrozzati (2 Quadcore con 32 Gb RAM con una scheda in Fibra Qlogic QLE220), sembrava un vero peccato dismetterli. Decido quindi di installare l'ESXi4.

Installo l’ESXi4 senza alcun problema apparente.

Al riavvio però mi accorgo che non viene rilevata la scheda in fibra Qlogic QLE220.

Dopo un paio di ricerche tramite google, trovo sul sito vmware un package-bundle da applicare all’ESXi4, con dei driver aggiornati per le schede Qlogic. Il pacchetto viene fornito in formato iso e va caricato tramite sull'ESXi4 tramite l’utility vihostupdate presente sulla Vma, o tramite powerCLI.

Il pacchetto si chiama vmware-esx-drivers-scsi-qla2xxx_400.841.k1.16.2-1vmw.2.17.00000.340223.iso

Scaricato il pacchetto, monto l’iso sulla VMA, mi collego via ssh e lancio il seguente comando:

#vihostupdate --server ipofqdn.mio.serverESXi4 --install --bundle /media/offline-bundle/841.k1.16.2-1vmw-offline_bundle-340223.zip

Se non si sono verificati errori, la VMWA vi risponderà che tutto è andato a buon fine e di fare il reboot del server ESXi4.

Eseguito il reboot, la scheda però non viene ancora riconosciuta dall’ESXi4.

Tra le varie cose che la procedura di cui sopra esegue, una è quella di aggiungere un file (qla2xxx.xml) nella directory /etc/vmware/pciid; il file, qla2xxx.xml ,è quello che ci consentirà di far vedere all’ESXi4 le schede in fibra.

Collegarsi nuovamente all’esx4i e seguire la seguente procedura:

cd /tmp/

mkdir -p pippo/etc/vmware

mkdir -p pippo/etc/vmware/pciid

cd pippo/etc/vmware

cp /etc/vmware/simple.map simple.map

cp /etc/vmware/pci.ids pci.ids

cp /etc/vmware/pciid/qla2xxx.xml pciid/qla2xxx.xm

Editare il file simple.map ed inserire la seguente stringa (circa a metà pagina ne troverete altre simili):

1077:5432 0000:0000 storage qla2xxx

Salvare il file.

Editare il file pci.ids e verificare che sia presente una voce simile a questa:

5432 QLE220


Editare il file qla2xxx.xml e aggingere in qualsiasi punto (purchè all'interno dei tag pcitable ) le seguenti stringhe:

<device id="5432">

<vmware label="fc">

<driver>qla2xxx</driver>

</vmware>

<name>QLE220</name>

<table file="pcitable" module="ignore" />

<table file="pcitable.Linux" module="qla2xxx" />

</device>

Terminate queste operazioni non ci resta altro che creare un pacchetto tgz opportuno e copiarlo nella posizione corretta:

cd /tmp/pippo

tar -cvzf oem.tgz etc

cp oem.tgz /bootbank/oem.tgz

Attenzione: il .tgz deve chiamarsi obbligatoriamente oem.tgz


Eseguire in ultimo il reboot dell'ESXi4:

Riavviato l’ESXi4 troveremo la nostra scheda correttamente rilevata dall’ESXi4 sotto la voce “Storage Adapter”.

La procedura descritta sopra NON è in alcun modo supportata da Vmware, quindi prendetela per così com’è se volete fare delle prove o utilizzare dei server che magari non fanno parte dell’HCL vmware per il vostro Laboratoio. Inoltre la procedura di cui sopra può essere utilizzata per anche per caricare altri tipi di periferiche; google sarà vostro amico :)