Cerca nel blog

domenica 23 settembre 2012

“APD Timeout”, come proteggere ESXi in caso di All Paths Down

Lo stato All Paths Down (APD), non impatta solamente sull’I/O delle VM; incide sul numero di thread a supporto del servizio hostd e, nel peggiore dei casi, l’host si disconnette dal proprio vCenter. APD agisce negativamente anche sulle operazioni di I/O relative all’aggiornamento del parametri della VM che vengono aggiornati nel file vmx.
Con vSphere 5.1, è possibile inserire un valore per il time-out in caso di APD. Questo parametro globale è disponibile editando gli advanced setting del software cercando Misc.APDHandlingEnable. Se il valore è impostato a 0, come in vSphere 5.0, ESXi di continuare a riprovare ad interrogare il percorso fallito. Impostando Misc.APDHandlingEnable a 1, la gestione dello stato APD cambia ed ESXi osserva il valore impostato in Misc.APDTimeout (il cui valore di default è 140 secondi).
In caso di ADP, ESXi attende il tempo impostato nel parametro appena citato (di base 140 secondi) dopodiché qualunque ulteriore richiesta di I/O viene chiusa con lo stato No_Connect, evitando che hostd rimanga appeso. Se, invece, un qualsiasi percorso verso il device dovesse essere ripristinato, le richieste di I/O al device verrebbero eseguite normalmente concludendo lo stato APD.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

sabato 22 settembre 2012

APD - All Paths Down e PDL - Permanent Device Loss


La rimozione di uno storage device in uso da ESXi e non gestita dall’host, può determinare la condizione All Paths Down (APD), questo può accadere anche in caso di crash del device. Altri scenari possibili per un ADP sono:
  • crash degli switch in fibra che portano allo storage;
  • caduta degli switch Ethernet per un array iSCSI
Nel corso delle diverse release di vSphere, VMware ha apportato miglioramenti significativi per la gestione della condizione APD, si tratta infatti di una situazione complessa in quanto ESXi non è in grado di determinare se si tratta di uno stato permanente o transitorioIl problema peggiore in merito ad APD è l’effetto su hostd, servizio che è responsabile della gestione di molte operazioni in ESXi. Di fatto se un amministratore lanciasse un rescan sulla SAN, hostd attenderebbe indefinitivamente una risposta I/O dal device in stato APD. Hostd ha un numero finito di threads quindi se tutti fossero impegnati nell’attesa di I/O, il servizio non potrebbe giù gestire altri task come: accendere, spegnere o creare VM. Il tipico sintomo di un host ESXi in presenza di ADP è la disconnessione del vCenter in quanto il processo hostd è appeso.
vSphere 5.0 ha introdotto una nuova condizione nota come Permanent Device Loss (PDL), stato che permette all’host ESXi di intraprendere azioni specifiche quando la perdita del device è permanente. ESXi è in grado di “comprendere” la situazione PDL attraverso dei specifici codici SCSI inviati dall’array.
Con vSphere 5.1 è stata migliorata la gestione degli stati APD e PDL in 3 modi:
  • gestire gli stati ADP in situazioni transitorie complesse, ovvero non permette a hostd di rimanere appeso indefinitivamente quando una periferica viene improvvisamente sottratta a ESXi senza che alcun controllo lato host;
  • permettere a vSphere HA di individuare lo stato PDL e quindi permettergli di riavviare le VM sugli altri host nel cluster che non stiano soffrendo dello stato PDL sul datastore;
  • introdurre un criterio per lo stato PDL su quegli array iSCSI che presentano una LUN per ogni target, questi array sono problematici in quanto dopo che una LUN è persa anche il target è perso e di conseguenza l’host ESXi non ha alcun modo di richiedere alcun SCSI sense code.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

venerdì 14 settembre 2012

VMFS 5: miglioramenti sul file sharing


Con vSphere 5.0, il numero massimo  di host che potevano condividere un file in read-only sulla VMFS era 8. Questo limite rappresentava una blocco alla scalabilità di ambienti VDI basati su VMware View, proprio a causa del tipo di deployment dei desktop che, in alcuni desktop pool, condividono lo stesso disco di base. Questo limite ha impattato anche nel deployment di vCloud Director per le vApp distribuite con il metodo “fast provisioning” che sfrutta il principio delle VM linked clones.
Con vSphere 5.1 questo limite è stato portato a 32, allineandosi al massimo numero di host supportati per cluster. Questo miglioramento si traduce in una maggiore scalabilità sia per View che per vCloud Director.
In merito a View va ricordato che:
  • con View 5.0 il limite degli host è 8 sia indipendentemente che il datastore sia VMFS o NFS;
  • con View 5.1 il limite degli host è stato spostato a 32 ma solo con l’uso di datastore NFS;
  • il prossimo rilascio di View porterà a 32 il numero degli host anche per i datastore VMFS.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

giovedì 13 settembre 2012

vSphere Data Protection


vSphere Data Protection (VDP) è la nuova soluzione per il backup introdotta da VMware con vSphere 5.1; questo prodotto sostituisce vSphere Data Recovery (VDR) presente nelle precedenti versioni. VDP è basato su EMC Avamar e fornisce numerose funzionalità e molte ottimizzazioni per il backup ed il recovery di VM.
vSphere Data Protection viene distribuito come virtual appliance costituito da 4 vCPU e 4 GB di RAM. Rispetto al predecessore nel quale era necessario aggiungere lo storage quale destinazione dei job di backup, vSphere Data Protection è disponibile in 3 configurazioni in base alla dimensione di spazio utilizzabile per il backup:
  • 500 GB;
  • 1 TB;
  • 2 TB
La pianificazione iniziale è essenziale in quanto non è possibile aggiungere ulteriore storage dopo il deployment dell’appliance. Ovviamente i requisiti di spazio per il backup si basano su diversi indicatori quali: il numero di VM che si desidera proteggere, la quantità di dati, il periodo di retention o conservazione del dato e la percentuale di cambiamento dei dati.
La creazione dei job di backup è una operazione fattibile attraverso il vSphere Web Client dalla scheda Backup di VDP. Nel job è possibile selezionare singole VM o contenitori di VM quali datacenter, cluster, host, resource pool e cartelle. Scegliendo un contenitore tutte le VM in esso contenute verranno protette, di conseguenza le nuove VM verranno aggiunte automaticamente al backup, quelle rimosse non verranno più protette. I backup possono essere pianificati giornalmente, settimanalmente o mensilmente.
Il prodotto prevede diverse metodologie di restore:
  • Full image restore
  • CDP restore
  • File Level Restore (FLR)
Quando è richiesto il ripristino completo di una VM, vSphere Data Protection valuta automaticamente quale metodo utilizzare per l’operazione di restore optando per quello più rapido. Quando viene utilizzata la tecnologia Change Block Tracking per il processo di restore delle VM, il software determina, grazie alle “vSphere API for Data Protection”, quale blocco è stato modificato rispetto all’ultimo restore point e rispristina solo quei blocchi.
Per evitare di sovrascrivere VM esistenti è possibile assegnare alla VM un nuovo nome e datastore di destinazione, in questo ultimo caso il restore sarà di tipo “full image”.
Oltre al restore completo è possibile recuperare singoli file o cartelle contenute nelle VM, cosiddetto File Level Restore, attraverso un tool web-based chiamato vSphere Data Protection Restore Client. Questo sistema permette agli utenti di recuperare in autonomia i propri file.
Per quanto riguarda la reportistica, VDP permette all’amministratore di configurare il sistema per inviare via mail i rapporti contenenti i dettagli dell’appliance, dei job di backup e delle VM che sono state salvate. I rapporti possono essere schedulati ad una specifica ora, per qualsiasi giorno o tutti i giorni della settimana.
VDP dispone anche di un meccanismo di “checkpoint e rollback”. Il checkpoint è un backup del sistema che assiste nel caso ci fosse una corruzione dei dati, ad esempio in caso di crash dell’appliance VDP eseguirà il rollback all’ultimo checkpoint valido. Qualsiasi backup eseguito dopo il checkpoint sarà perso ma si eviteranno dati corrotti.
Per maggiori informazioni è possibile:

Space-Efficient Sparse Virtual Disks


I dischi thin indirizzano una delle maggiori cause di inefficienza nell’uso dello spazio, allocando blocchi di storage al file system delle guest OS solo quando questi sono necessari, piuttosto che preallocarli all’atto della creazione della VM. Questo meccanismo, tuttavia, risolve una parte del problema in quanto se lo spazio viene allocato in scrittura non viene rilasciato quando i dati vengono eliminati nel file system della VM; questo comporta un graduale aumento dello storage vanificando il beneficio del disco thin.
Con il rilascio di vSphere 5.1, VMware ha introdotto una nuova tipologia di virtual disk, il “space-efficient sparse virtual disk (SE sparse disk)”. Una delle maggiori features consiste nell’abilità di recuperare lo spazio precedentemente allocato nel guest OS. Un secondo beneficio sta nella capacità di impostare una dimensione del blocco del disco virtuale in base ai requisiti dell’applicazione. Alcune applicazioni in esecuzione delle VM lavorano meglio con una dimensione grande del blocco, altre invece con blocchi piccoli; in passato questa impostazione non era regolabile.
Come avviene il recupero dello spazio? Il recupero dello spazio precedentemente occupato è suddiviso in 2 fasi:
  • l’eliminazione profonda, wipe operations, che libera un’area contigua di spazio nel VMDK della VM;
  • la riduzione (shrink), che scollega (unmap) l’area liberata dal VMDK e consente allo spazio di ritornare libero.
La fase di wipe è inizializzata dalle VMware Tools che eseguono una scansione del file system del guest OS e marca i blocchi inutilizzati come liberi. Successivamente viene lanciato, sempre nella VM, il comando SCSI UNMAP che comunica nel layer SCSI virtuale nel VMkernel di marcare i blocchi storage come liberi.
La fase di Shrink è differenziata in base al tipo di storage:
  • per gli storage con accesso a blocchi il VMkernel lancia il comando SCSI UNMAP verso lo storage array;
  • per gli storage NFS, ESX esegue una RPC call per troncare il file
Nell’esecuzione di questi task il VMkernel si preoccupa anche di spostare i blocchi alla fine del VMDK all’inizio, per evitare che il troncamento venga operato in una zona contenete dei dati.
Per poter beneficiare di questa funzionalità è richiesto che le VM abbiano il virtual Hardware versione 9, le precedenti edizioni non supportano questo formato disco.
Inizialmente, con vSphere 5.1, l’uso del formato SE sparse è limitato a VMware View. View Composer è in grado di creare VM linked clone durante la distribuzione di VM. Le VM linked clones usano snapshot, aperte in lettura e scrittura, che puntano ad un disco padre. View beneficerà immediatamente sia della funzionalità di crescita granulare del blocco del disco indirizzando problemi legati all’allineamento sperimentati su alcuni storage, sia del recupero dello spazio eliminato.
Per maggiori informazioni è possibile consultare il white paper “What’s New in VMware vSphere 5.1 – Storage”.

martedì 11 settembre 2012

Supporto per VM con 64 vCPU


vSphere 5.1 raddoppia la capacità elaborativa delle VM, consentendo di allocare fino a 64 vCPU, disponendo dell’edizione Enterprise Plus. Con l’edizione Enterprise è invece possibile allocare fino a 32 vCPU, per tutte le altre il limite è 8 vCPU.
Questo miglioramento, insieme alla possibilità di assegnare alla singola VM fino ad 1 TB di RAM, dimostra da un lato la capacità dell’hypervisor di poter sostenere VM con enormi carichi di lavoro in grado di soddisfare la maggior parte delle applicazioni aziendali ora in commercio, dall'altro la facoltà della piattaforma di poter proteggere e spostare “VM mostruose” all’interno del datacenter virtuale.
L’allocazione delle 64 vCPU è fattibile creando VM con il nuovo virtual HW, arrivato con vSphere 5.1 alla versione 9; le precedenti versione 8, 7, e 4 sono ancora supportate dalla nuova piattaforma.

Il Nuovo vSphere Web Client


La vSphere Web Client è stata introdotta con vCenter 5 e permette di utilizzare un web browser per interfacciarsi con il sistema di gestione di vSphere.
La proliferazione dei prodotti e delle tecnologie collegate alla virtualizzazione ed al cloud ha determinato la necessità di uno strumento di gestione che lato client potesse:
  • avere la capacità di essere fruibile da ambienti eterogenei;
  • uno strumento estensibile ed aperto alle personalizzazioni;
  • capacità di gestire un grande numero di oggetti presenti nei datacenter distribuiti anche geograficamente
Con vSphere 5.1 il client via web diventa la GUI di riferimento, sorpassando le funzionalità offerte dal tradizionale vSphere Client che si installa su sistemi Windows. Tra le funzionalità chiave:
  • Inventory Lists: permettono di sfogliare rapidamente un inventario composto da molti oggetti, sfruttando la logica di mettere in relazione l’oggetto selezionato con tutti gli altri elementi che interagiscono con lui. Il vantaggio principale è quello di evitare di spostarsi tra i diversi inventari  per avere un’informazione dettagliata di un oggetto;
  • Personalizzazione della GUI: non tutti gli utenti usano le interfacce grafiche per le stesse ragioni, in questa ottica il vSphere Client rappresenta un problema a causa della sua rigida GUI, al contrario il vSphere Web Client consente all’utente di personalizzare il proprio ambiente spostando o eleminando gli elementi;
  • Common Action: questa funzionalità viene risolve il problema dei task ripetitivi che vengono svolti cercando di eliminare il tempo e la frustrazione che deriva, il vSphere Web Client fornisce menù con comandi contestuali per eseguire rapidamente i task comuni;
  • Work-in-Progress Workflows: questa funzionalità permette di mettere in pausa dei task indirizzando il problema nell’eseguire i task in modo seriale. Grazie a questo miglioramento è possibile dare più priorità anche ai comandi lanciati in un secondo momento;
  • Advanced Search: le ricerche avanzate permetto di trovare più facilmente gli oggetti all’interno del datacenter, soprattutto quando gli ambienti scalano oppure quando si è in presenza di ambienti cloud;
  • Estensibilità: il nuovo client via Web offre la possibilità a terze parti di integrare le proprie funzionalità, evitando quindi di dover passare da più interfacce per eseguire task che convergono sulla infrastruttura virtuale.
L’architettura del vSphere Web Client è composta da tre layer:
  • il client applicazione multipiattaforma che viene eseguita in un browser web in grado di supportare Adobe Flex
  • l’application server, servizio basato su Virgo e tc Server. SI tratta di una applicazione Java progettata e sviluppata con Spring
  • vCenter e i servizi associati ad esso. vCenter è il servizio principale che fornisce i dati all’application server
Per utilizzare il vSphere Web Client è necessario installare il vSphere Web Client server, quale applicazione su un sistema Windows oppure avviando il servizio già presente sul vCenter Server Appliance.
Per maggiori informazioni è possibile consultare il documento sulle novità introdotte da vCenter Server 5.1

domenica 9 settembre 2012

VMware vSphere Storage Appliance 5.1


Con l’annuncio di vSphere 5.1 VMware ha aggiornato anche la VMware vSphere Storage Appliance, più semplicemente VSA.
Questo prodotto, disponibile per tutte le edizioni di vSphere tranne l’Essentials Kit, permette di trasformare lo storage locale degli host ESX (fino ad un massimo di 3 host per cluster) in storage condiviso, quale datastore NFS, e protetto attraverso il meccanismo di replica offerto dalla VSA stessa.
L’obiettivo di questo prodotto è di poter sfruttare tutte le funzionalità di vSphere che richiedono uno storage condiviso, pur non disponendone di uno fisicamente, essendo una soluzione 100% software che semplifica molto le tematiche legate allo storage. Gli storage fisici, infatti, spesso richiedono specifiche competenze non solo sull'apparato principale ma su tutte le periferiche di connessione quali, switch (in fibra e non) HBA e cablaggio. Un ulteriore beneficio è dato dalla gestione centralizzata, integrata in vCenter, che non richiede l’utilizzo altri strumenti per l’attività di amministrazione e manutenzione dello storage.
Come anticipato grazie alla VSA è possibile sfruttare tutte le funzionalità di vSphere, in particolar modo va evidenziato HA. Al verificarsi di un crash del server, le VM residenti su di esso cadono così come lo storage locale al server stesso, in questo scenario la replica nativa offerta dalla VSA rende disponibili i contenuti del datastore replicato su uno degli altri host e vSphere HA riavvia le VM su uno degli host superstiti.
VSA è il prodotto ideale per le piccole realtà che non dispongono di budget per uno storage condiviso, ma anche per le grandi aziende che intendono gestire gli uffici periferici con un investimento minimo.
Rispetto alla versione precedente queste sono le migliorie apportate al prodotto:
  • possibilità di usare più di 8 dischi per host;
  • possibilità di scegliere quanto spazio locale dedicare alla VSA quale storage condiviso;
  • possibilità di estendere dinamicamente lo spazio utilizzato dalla VSA;
  • possibilità di usare un unico vCenter per gestire più istanze VSA;
  • possibilità di installare ed utilizzare la VSA anche in ambienti già in uso, questo enhancement supera il limite della versione precedente che imponeva l’installazione della VSA in un ambiente “fresh insall”;
  • è stata eliminato il requisito di avere l’istanza vCenter e gli host ESX nella stessa subnet;
Per maggiori informazioni è possibile consultare: