martedì 17 febbraio 2015

VPX operational dashboard

Nel vSphere web client, cliccando HOME > LOG BROWSER abbiamo uno strumento che ci permette di visualizzare i logs di VCenter e degli host ESXi.


Esiste anche un altro tool per visualizzare atri log esistenti a livello di VCenter: il VPX Operational Dashboard (VOD). Per accedere a questo tool, puntiamo a https://<VC_hostname>/vod/index.html.

Tra le varie informzioni disponibili, cliccando HOST STATUS possiamo visulaizzare il MOID di ogni host

lunedì 12 gennaio 2015

vSphere Virtual Flash Resource

Due sono le features presenti in vSphere 5.5 che utilizzano su dispositivi di memoria FLASH o  SSD:
Virtual Flash Host Swap Cache for VMware vSphere Hypervisor
Virtual Flash Read Cache for virtual machines

Il cosidetto vSphere Flash Read Cache framework è basto su due componenti:
 vSphere Flash Read Cache infrastructure
 vSphere Flash Read Cache software
Attraverso esse, potremo raggruppare (pooling) diversi devices  Flash (installati localmente su ogni host) in un singolo oggetto chiamatoVirtual Flash Resource.
Per crearla su ogni host:


La fetaure Virtual Flash Host Swap Cache for VMware vSphere Hypervisor, permette agli host di utilizzare parte della Virtual Flash Resource per una cache utilizzate dalle VM in stato di VMKernel swapping, il massimo di risorse consumabili a questo scopo è 4 TB e la quantità di risorsa selezionata viene 'riservata' per questa feature: NON può essere utilizzata per la Flash Read Cache.
Per abilitarla su ogni host:



La feature Virtual Flash Read Cache for virtual machines è una cache in lettura (write-through) utilizzata dalle VM le cui performances aumentano notevolmente senza impatti sulla possibilità di utilizzare fetaures quali vMotion, HA, DRS.
Questa cache può essere abilitata per singolo VMDK (via web client con HW version 10), viene considerata come una RESERVATION con le relative regole di admission control.
Per abilitarla sui VMDK:
Premendo il tast advanced possiamo anche scegliere il blocksize in base alle richieste dei guest OS / applicazioni (con il tool vscsistats possiamo scoprire il blocksize utilizzato dalle VM).








martedì 4 novembre 2014

horizon mirage bandwidth limit

Dalla versione 5.1 di Horizon Mirage, è stata introdotta la possibilità di impostare un limite di banda in upload/download per i client che si trovano in alcune subnet o in alcuni domini.
Chiaramente è una funzionalità molto utile per far si che i clients che si trovano in uffici remoti non consumino tutta la banda con le attività mirage.
Per impostare il limite, nella mirage console, clicchiamo col tasto destro su system configuration e selezioniamo SETTINGS. Ora ci spostiamo sul tab BANDWITH LIMITING


Come vedete, per default non c'è nessun limite impostato. Ora, per impostare i limiti desiderati, creiamo un file csv contenente le regole nel formato:   SubnetMaskV4,Site,Download limit,Upload limit.



Nell'esempio, impostiamo un limite di 500KB/s in upload e di 350KB/s in download per tutti i clients della subnet 172.16.0.0/16.
Impostiamo un limite di 300KB/s in entrambe le direzioni per il client 172.16.0.11
Impostiamo un limite di 200 e 100 KB/s per i cliient del dominio sitoA ed un limite di 2048 1024 per i client del dominio sitoB. Importando il file otteniamo:



La regola di precedenza è la più restrittiva. Se ,ad esempio, un client appartiene al sitoA, alla subnet 172.16.0.0  ed il suo indirizzo è 172.16.0.111, i suoi limiti saranno 200 KB/s in upload e 100 KB/s in download. Vince questa regola, NON perchè è stata inserita per ultima ma perchè è la più restrittiva. 

Impostare la banda in upload e in download per una intera subnet (o dominio) , significa che se all'interno della subnet ci sono attività parallele di download ed upload, la banda massima utilizzabile sarà la sommo dei due limiti.




venerdì 26 settembre 2014

vSphere storage polcies nel web client

L'utilizzo delle sorage policies e degli storage profiles con il vSphere web client è meno articolato rispetto all'utilizzo delle stesse features nel client tradizionale.

Come in passato, se abbiamo dello storage che attraverso le API VASA, è in grado di comunicare al vCenter le caratteristiche delle LUN, avremo già nel sistema alcune storage capabilities e quando da HOME > VM STORAGE POLICIES andremo a creare una nuova policy, ci verranno elencate le STORAGE CAPABILITIES esistenti con cui potremo creare un set di regole che descriveranno la nostra policies (installando la VSAN vengono create 5 capabilities).
.
Se invece vogliamo lavorare con le USER DEFINED STORAGE CAPABILITIES, nel web client dobbiamo affidarci ai TAG: ogni datastore potrà essere descritto con diversi TAG (dall'inventario datastores/manage/tags) e quando andremo a creare una nuova storage policy potremo utilizzare i TAG assegnati ai DATASTORES per creare il set di regole desiserato.
Per visualizzare tutti i TAG creati, è possibile cliccare TAGS dalla web client HOME.


Ogni TAG deve appartenere ad una CATEGORY ed ogni categoria verrà associata ad uno o più tipi di oggetti (entità) del nostro vcenter (datastore, host, vm, network ecc.)



giovedì 25 settembre 2014

PernixData FVP nel Partner Verified and Supported Products (PVSP) di VMware

In un post precedente, si diceva che il software PernixData FVP viene installato a livello di hypervisor, quindi si tratta di un estensione, di un modulo che estende le funzionalità del vmkernel.
Alcuni clienti mi hanno chiesto se un modulo di terze parti installato a livello di vmkernel, potrebbe provocare 'problemi' di supporto da parte di VMware ad eventuali problemi aperti. La risposta è che da marzo 2014 FVP è stato aggiunto al VMware Partner Verified and Supported Product Program, ed è quindi riconosciuto da VMware come prodotto ufficialmente pronto per essere installato nella piattaforma vSphere. Maggiori informazione le potete trovare in una press release di PernixData, nell'elenco dei Partner Verified and Supported Products (PVSP) sul sito VMware e nella VMware  KB 2073257.
 

giovedì 24 luglio 2014

Pernixdata FVP: accellerare con semplicità

Pernixdata FVP permette di accellerare gli I/O di qualsiasi VM ututilizzando schede flash (SSD o PCIe) presenti nelgli host ESXi. Il prodotto  è stato pensato per essere semplice e ridurre al minimo le possibilità di scelta:
Innanzi tutto possiamo scegliere se accellerare una VM o un DATASTORE. 
Una VM viene accellerata nella sua interezza, non c’è necessità/possibiltà di scegliere uno specifico VMDK, è sicuramente MEGLIO accellerare tutti gli I/O generati da una VM piuttosto che un sottoinsieme di I/O.
Basta selezionare la VM e scegliere la policy di accellerazione: questa può essere write-through o write-back, con quest’ultima devo specificare il livello di ridondanza (numero di repliche) e nient’altro. Appunto MOLTO SEMPLICE.



Da qui in poi, tutti gli I/O generati dalla VM vengono accellerati. Non c’è necessità di spostare la VM in un datastore più performante, o altre attività complesse.

Accellerare un DATASTORE permette di creare una policy d’accellerazione per quel datastore, seguendo la stessa metodologia usata per le singole VM: selezionare ADD DATASTORE nel flash cluster, selezionate il datastore e scegliete la write policy desiderata, la policy verrà assegnata a tutte le VM presenti in quel datastore.Di nuovo MOLTO SEMPLICE.



Pernixdata FVP lo si installa semplicemente (è un VIB da importare con update manager), non richiede reboot degli host, dopo l’installazione basta aggiungere le VM (o I datastore ) al FLASH CLUSTER ed iniziare a beneficiare dell’aumento di performances.

mercoledì 9 luglio 2014

Horizon Daas Architecture

Il prodotto Horizon Daas, permette la fornitura di desktop windows (e linux) come servizio cloud.  In questo articolo approfondiamone l’architettura:


Come vedete nella grafica, l’ambiente è composto da macchine fisiche, appliances virtuali e reti.

MACCHINE FISICHE:
VIRTUAL DESKTOP HOSTS: macchine ESXi che ospitano le VM desktop (windows) di un singolo tenant.
SHARED DESKTOP HOSTS:  macchine ESXi che ospitano le VM (linux o windows 2008 Terminal server per RDSH) di diversi tenant.
NAS STORAGE: Storage utilizzato per ospitare le VM. E‘ richiesta una NAS NFS e non una SAN in quanto il prodotto daas può gestire direttamente gli hosts senza passare da vCenter, in questo caso si occupa direttamente della clonazione delle VM accedendo al file system del datastore voa NFS.
HORIZON  MANAGEMENT HOSTS:  alcune macchine ESXi cshe ospitano diverse copie delle Horizon Daas management virtual appliances .

APPLIANCES  VIRTUALI (Horizon DaaS Management Appliances) :
SERVICE PROVIDER APPLIANCE: è la prima appliance installata nel Data Center, è la console utilizzata dal Service Provider per amministrare l’intero ambiente  e, tra l’altro si occupa di fare il deploy delle altre appliances.
RESOURCE MANAGER APPLIANCE: si occupa di collezzionare ed astrarre le risorse fisiche e di metterle a disposizione die diversi tenants.
TENANT APPLIANCE: appliance amministrativa del Tenant, e connection broker del singolo tenant.
dRAM APPLIANCE: permette agli utenti che si trovano fuori dalla rete del tenant, di accedere ai virtual desktop senza dover utilizzare una VPN
Tutte le appliances sono macchine Linux, molto leggere, e con un DB propietario, hanno un meccanismo di alta affidabilità implicito.

SERVIZI DI RETE:
DNS, DHCP, NTP ed Active Directory  sono componenti fondamentali, e richieste, da Horizon Daas. Possono essere implementate internamente nella rete del Tenant o accessibili attraverso un’estensione (VPN/MPLS) della rete del Tenant verso il Data Center del Tenant stesso.
La rete deve supportare il VLAN TAgging ed il VRF per poter separare i diversi Tenant.
Le reti visibili nella grafica sono:
SERVICE PROVIDER NETWORK: Rete principale del service provider, mette in comunicazione le diverse service provider appliances e deve avere accesso alla MANAGEMENT NETWORK per poter gestire gli hosts e lo storage.
BACKBONE LINK LOCAL NETWORK: rete non rutabile, che connette le appliances die tenant con le appliances del service provider. E‘ gestita dal service provider.

TENANT NETWORK: trattasi di un VLAN separata da tutte le altre reti, viene gestita direttamente dal tenant, non è accessibile dal Service Provider.