VMware vShield e Sophos antivirus

sophosNel mondo della virtualizzazione è abbastanza ovvio che dover installare un agente antivirus per ogni VMs è del tutto anacronistico. Gli ambienti guest sono concentrati in pochi hosts, i dati solo archiviati su storage centralizzati e, così come molti aspetti della server farm vengono gestiti centralmente, anche altre esigenze di protezione possono essere ulteriormente razionalizzate e centralizzate.

Nel passato (neanche tanto lontano) gli agenti antivirus venivano installati sui server da proteggere, oggi molti produttori di software antivirus mettono a disposizione soluzioni da integrare con l’ambiente di virtualizzazione per semplificare il provisioning degli agenti antivirus e per migliorare l’efficienza delle scansioni stesse.

Negli ambienti VMware vSphere esiste una soluzione nata per centralizzare le esigenze di sicurezza e protezione degli ambiente: VMware vShield. Grazie alla collaborazione di VMware ed i produttori di software antivirus oggi possiamo far lavorare assieme la componente VMware vShield Endpoint e le appliance antiviris di molti brand.

Personalmente ne ho viste un po’ all’opera e, senza nulla togliere alle diverse soluzioni che ho provato tra cui la sempre eccellente Symantec, sono approdato su Sophos verso la quale faccio una menzione d’onore dopo aver visto un paio di scelte molto azzeccate dalla software house che rendono il sistema molto efficiente e di limitatissimo impatto a livello di performance (comunicazione a livello hypervisor, caching, gestione intelligente delle schedulazioni evitando sovrapposizioni).

La questione delle performance è un tema caldo nel mondo delle scansioni antivirus, tema che si è complicato con l’impiego della virtualizzazione in quanto la condivisione delle risorse fisiche, se gestita in modo poco opportuno, rischia di allungare i tempi di scansione per banale overload di CPU e Disk I/O sulle macchine sulle quali risiede l’agente antivirus. Lavorare a livello hypervisor riduce sensibilmente tale impiego di risorse grazie ai vantaggi intrinseci della tecnologia, dovrebbe quindi essere naturale il passaggio a VMware vShield Endpoint per chi lavora in ambiente VMware (opzione disponibile già dalla versione Essentials Plus).

sophos-prestazioniSophos espone dati interessanti sulle prestazioni; allego qua a fianco uno delle immagini che pubblicano sul sito. Dalle prove che ho fatto devo dire che i dati raccolti sembrano dar ragione ai grafici propagandistici ed uno dei principali motivi è sicuramente la gestione intelligente delle schedulazioni. Il sistema di gestione delle scansioni fa in modo che il numero di eventi di scansione simultanei sia limitato così da evitare consumi di risorse concentrati nello stesso momento. Un piano di questo tipo è possibile anche su altri prodotti ma bisogna agire manualmente impostando orari di scansioni differenti per differenti gruppi di VMs… se ci pensa il software in autonomia è più comodo.

E’ ovvio che in un ambiente virtualizzato è preferibile avere un sistema che “spalma” il carico generato dalle scansioni antivirus nel tempo. Questo approccio riduce sensibilmente i picchi di carico a livello I/O e CPU e di conseguenza riduce l’impatto che questo carico può avere a livello infrastrutturale  (vMotion, Storage vMotion, CPU ready time elevato, ecc).

Approfondirò meglio i prodotti Sophos nel prossimo periodo, non solo a livello di protezione antivirus.

Scale Computing: una black-box per la virtualizzazione

Scale_LogoRecentemente ho avuto il piacere di essere invitato ad una presentazione, organizzata dagli amici di Achab s.r.l., dei nuovi prodotti di Scale Computing (http://www.scalecomputing.com/), in particolare della serie HC3: un prodotto ingegnerizzato per semplificare il Private Cloud delle aziende che si rivolgono alla virtualizzazione per consolidare i propri sistemi informativi.

Il prodotto ha una mission chiara: semplificare l’implementazione e la gestione della propria Virtual Server Farm. Per raggiungere questo obbiettivo gli ingegneri di Scale hanno realizzato una vera e propria black-box che mette a disposizione il set di funzionalità tipico delle infrastrutture di virtualizzazione ma con un’interfaccia molto semplice da usare, con poche ed essenziali possibilità di configurazione dell’infrastruttura. Anche a livello di startup dell’impianto ci sono poche semplici azioni da eseguire per trovarsi con una server farm pronta all’uso in pochi minuti (letteralmente in pochi minuti). Tutti temi che hanno sicuramente risvolti positivi come il risparmio di tempo sia in implementazione che in gestione, ma che vanno messi a confronto con le altre soluzioni sul mercato (es: VMware).

Cenni sull’architettura e le funzionalità
Il prodotto Scale ingloba le tre componenti base degli impianti di virtualizzazione in un’unica soluzione grazie all’impiego di componenti software integrate tra loro. Gli hypervisor sono basati su KVM, clustering e networking sono gestiti a livello software, così come la componente storage è di tipo software grazie ad una sorta di File System distribuito sui nodi del cluster (anche questo un software ideato e scritto da Scale).

cluster

La base di partenza di un cluster richiede l’acquisto di tre hosts che, una volta avviati, garantiscono le funzionalità di clustering (con massimo un failover host), live migration delle VMs, gestione delle virtual network, gestione degli snapshot a livello VMs.

L’interfaccia di gestione, interamente web based, risiede sugli stessi hosts ed è di conseguenza ridondata. Non esiste un sistema centralizzato di gestione (in stile VMware vCenter Server), tutti gli hosts metto a disposizione l’interfaccia di gestione ed i dati sono allineati real-time.

Per evitare problemi di compatibilità tra il software e le diverse famiglie di server e loro componenti, Scale fornisce sia il software che le macchine in tre diverse classi di potenza. Questo permette di ottenere una soluzione che difficilmente darà sorprese una volta implementata.

SCALE-price

Il prodotto mette, inoltre, a disposizione un sistema di Disaster Recovery molto semplice. E’ sufficiente avere a disposizione due cluster Scale in comunicazione a livello IP ed abilitare la replica tra i due siti.

Nel suo complesso la soluzione è estremamente agile e semplice da utilizzare, il rovescio della medaglia è una certa carenza sul piano delle funzionalità messe a disposizione in confronto ai Big del mercato della virtualizzazione.

Cosa manca
Sul piano delle funzionalità ci sono alcuni grandi assenti:

  • non esiste un automatismo di bilanciamento del carico
  • non esiste uno strumento di backup, ne a livello VM ne a livello Storage
  • non esiste un’entità logica per la gestione delle reti (es: i Virtual Switch di VMware)

A questo è da aggiungere una grave – a parer mio – mancanza architetturale ereditata dalla soluzione di software storage utilizzata da Scale: in caso di fail di un host il sistema necessità di un certo periodo di tempo per “riorganizzare” i dati a livello software e tornare in una situazione di integrità. Questa necessità fa si che il cluster sia in grado di sopportare il failt di un host alla volta. Tale vincolo è forse accettabile in infrastrutture “modeste”, ma a livello enterprise è impensabile avere un cluster con decine di hosts la cui disponibilità è garantita solo se si rompono uno per volta.

Ma quanto costa?
Al momento sono disponibili, sul sito del produttore, i prezzi di listino delle soluzioni a tre nodi e gli eventuali nodi aggiuntivi. Invito gli interessati a fare un esercizio molto banale, ovvero di mettere a paragone i prezzi esposti da Scale con i costi di una classica soluzione VMware vSphere Standard o  Essential Plus con le componenti hardware con cui siete abituati a lavorare (personalmente lavoro molto con Dell ed IBM).

In base alla mia esperienza ed alle soluzioni che ho trattato negli ultimi anni non ho visto particolari vantaggi economici nella soluzione di Scale. Mi spiego meglio: il prodotto mi sembra valido ma se paragonato a livello di funzionalità con i vari competitor ed ai loro costi non evinco una reale competitività di Scale. C’è da dire che la semplicità di implementazione e gestione della soluzione Scale abbatte sicuramente i costi di startup e maintenance di un cluster, ma la sensazione è stata comunque quella di una soluzione costosetta rispetto al mercato.

In questo post non voglio mettere un’ultima parola, resto in attesa di scoprire lo sconto sulla base listino Scale. Potrebbe rivelarsi una vera sorpresa nel caso in cui gli sconti rendano la soluzione aggressiva, a livello di prezzo, sul mercato.

DaaS, VDI e simili

vdi-logoNei mesi scorsi ho avuto modo di discutere con diversi IT Manager (poi diventati clienti) il tema della Desktop Virtualizzation e, più in generale, il Desktop a Servizio: DaaS.

La mia predilezione per i prodotti made in VMware è nota, ma è doveroso portare all’attenzione il fatto che nel mercato delle PMI italiane la proposta VMware Horizon View potrebbe risultare troppo impegnativa economicamente. Per questo target di clienti ho trovato “conforto” nella soluzione che propone Microsoft: Remote Desktop Services (RDS) in salsa Windows Server 2012 R2.

I punti di forza che mi hanno permesso di discutere, proporre ed infine implementare questa soluzione anche quando il budget a disposizione era limitato sono essenzialmente tre:

  • la semplicità di integrazione con ambienti Microsoft spesso già presenti nelle aziende
  • l’efficienza dei costi anche in scenari con poche decine di postazioni
  • la possibilità di lavorare sia con sessioni Desktop che con Virtual Machine dedicate

Il III punto è fondamentale: è evidente che mettere in piedi un cluster VMware vSphere per pochi Virtual Desktop potrebbe non essere efficiente a livello di costi, disporre invece di un’infrastruttura che eroga sessioni di un Desktop create su una macchina shared (fisica o virtuale che sia) è efficiente anche in scenari di modeste dimensioni. Inoltre esiste il tema delle RemoteApp, ovvero la possibilità di eseguire lo streaming di un’applicazione in esecuzione all’interno della RDS Farm.

Di fatto alcune di queste funzionalità mancano completamente nella soluzione enterprise di VMware che, non a caso, con la versione 6 di Horizon View integra proprio facendo lavorare assieme una RDS Farm ed un VDI Cluster basato di vSphere. In questo documento VMware illustra i vantaggi di questo interessante binomio. In soldoni si tratta di avere a disposizione tutte le potenzialità della Desktop Virtualizzazioni di VMware sommate alle funzionalità messe a disposizione dalla SessionMode e da RDS di Microsoft Windows 2012. Il tutto centralmente gestito da Horizon View grazie ad un apposito agent da installare sui server RDS.

Ovviamente avere tutto ciò ha un costo che deve essere giustificato dalle esigenze del cliente. Questo scenario è sicuramente utile a chi deve gestire centinaia di postazioni anche con esigenze diverse. Ma visto il grado di integrazione raggiunto nulla ci vieta di partire, in piccolo, con una o l’altra soluzione per poi integrarle nel caso vi sia una crescita nella quantità delle workstation da consolidare.

Cloud? Perché no. Che si basi su una o l’altra soluzione i provider possono pensare (e c’è chi lo fa da diversi mesi) di mettere a disposizione queste tecnologie tramite servizio a canone (per sessione o per desktop), così da consentire alle aziende di avere a disposizione desktop sempre aggiornati, prestanti, gestiti e disponibili da qualsiasi sede e da qualsiasi device.

Tema marginale? Assolutamente no. Ho personalmente lavorato in tal senso con diversi clienti i quali hanno espresso assoluto apprezzamento per queste funzionalità che di fatto consentono di:

  • utilizzare in streaming qualsiasi applicazione del proprio ambiente desktop, anche da remoto e su device mobile
  • utilizzare lo stesso desktop da diverse postazioni in azienda
  • ottimizzare la gestione del parco macchine grazie all’uso dei Thin Client
  • dar seguito alle policy di patching ed upgrading degli ambienti desktop in modo estremamente rapido
  • fruire di un servizio granulare che consente di pagare solo per i desktop in uso

Moltissime potenzialità. Tema ancora poco noto e da diffondere.

VMware Certification: VCA-DCV

Qualche minuto fa ho provato l’esamino che permette di conseguire questa simpatica certificazione creata apposta per chi si affaccia al mondo della virtualizzazione di VMware. Ovviamente il mio scopo era più didattico che formativo (ho conseguito già la VCP, la VCA è tecnicamente “inferiore”) e una delle cose che volevo fare era proprio scriverne su queste pagine.

L’esame si compone di 50 domande a cui rispondere in 90 minuti (ne ho impiegati circa 40). Le domande sono decisamente di carattere generale in rifermento alle funzionalità dei prodotti vSphere, in definitiva si tratta di avere cognizione di causa sul vasto set di prodotti e funzionalità (es: cosa fa HA, cosa fa DRS, cosa fa Storage DRS, ecc.) e di avere un minimo di dimestichezza con le infrastruttura di virtualizzazione tale da interpretare correttamente gli scenari proposti e rispondere a domande anche specifiche su un’ipotetica architettura vSphere.

Per la preparazione all’esame e sicuramente sufficiente leggere la documentazione proposta all’interno del BluePrint rilasciato da VMware. Ritengo sia inoltre utile approcciare un minimo i prodotti vSphere, non a livello di installazione e configurazione ma a livello di “banale” utilizzo in modo da rendersi conto delle potenzialità delle diverse funzionalità.

Di seguito i temi sicuramente da prendere in considerazione per affrontare l’esame:

  • vSphere HA, DRS, FT
  • vSphere cluster: requisiti e funzionalità
  • vSphere vSwitch (standard e distribuited): funzionalità
  • Tipologie di storage e protocolli supportati
  • vSphere Operation Manager: funzionalità
  • vSphere Data Protection: funzionalità
  • vSphere Replication
  • Site Recovery Manager
  • vSphere Storage Appliance

Buono studio!

VMware Data Protection

VDP, come lo si chiama abitualmente, è una comoda soluzione di backup per le macchine virtuali VMware che, in modo molto semplice ed efficacie, mette a disposizione un interessante set di funzionalità per protegge volumi anche interessanti di dati. In questo post vorrei sottolineare, nel bene e nel male, alcune caratteristiche del prodotto.

Come prima nota è indispensabile prendere atto del fatto che si tratta di una soluzione di backup “su disco”, ovvero il dato protetto è a sua volta posizionato in un’area di storage di tipo disco (i Virtual Disk dell’appliance VDP stessa). Questo comporta costi di infrastruttura maggiori rispetto ad una soluzione in grado di utilizzare i supporti LTO. Inoltre, soprattutto negli ambienti medio-piccoli, è abbastanza probabile che lo Storage su cui risiede l’appliance VDP sia lo stesso delle VMs protette, in tal caso dovremmo tener conto del fatto che un fault sul sistema storage comprometterebbe parimenti i sistemi di produzione come i dati dei backups.

La facilità di installazione e di utilizzo del prodotto sono, ritengo, uno dei punti di forza della soluzione. Il deploy dell’appliance richiede pochi click e la configurazione dei parametri base si esegue in pochi minuti. Allo stesso modo l’interfaccia grafica di amministrazione, completamente integrata in vSphere Web Client, è molto semplice da utilizzare.

VDP esegue backup completi ed incrementali della macchine virtuali ed è in grado di eseguire deduplica dei dati. Queste funzionalità permetto di ottenere un elevato risparmio di spazio soprattutto in infrastrutture che, per diversi motivi, presentano VMs che contengono dati simili o identici. Un esempio classico è un’infrastruttura con molte VMs create tutte dallo stesso template, in questo caso il set base di dati comune a tutte le VMs (il template appunto) sara completamente sottoposto a deduplica.

Molto comoda anche la possibilità di eseguire il backup contemporaneo di un massimo di otto VMs per volta. Questa peculiarità è comoda soprattutto negli scenari in cui si desidera avere il backup coerente, a livello di linea temporale, di più VMs che cooperano tra loro e che si trovano ad avere dati correlati.

Ultima nota, il costo: VDP è disponibile sin dalla licenza Standard di vSphere (http://www.vmware.com/it/products/vsphere/compare.html).

Personalmente consiglio la soluzione a chi deve gestire piccole infrastrutture ed ha bisogno di un sistema di backup semplice da usare a discapito di alcune debolezze intrinseche dell’architettura che i vari scenari di implementazione propongono. Il prodotto è inoltre da tenere in considerazione anche come potenziale supporto ad un piano di DR in quanto è relativamente semplice – e sicuramente comodo – effettuare una procedura di recovery di un’infrastruttura di virtualizzazione laddove si sia in possesso di un’immagine recente di tutte le VMs da ripristinare.

OwnCloud: cloud storage facile e “sicuro”

OwnCloud è una interessante piattaforma per la realizzazione di servizi di condivisione dati. Veloce da implementare, facile da usare… sembra essere un’ottima soluzione da sfruttare in diversi contesti e con la possibilità di valutare modelli di cloud differenti a seconda dell’esigenza (private, public).

L’interfaccia utente è leggera e pulita, accessibile via browser da la possibilità di caricare/scaricare/condividere contenuti di diverso tipo. Non stiamo parlando di un prodotto rivoluzionario, di fatto espone funzionalità che molti servizi hanno da anni (Google Drive, DropBox, ecc), ma essendo un prodotto prima che un servizio non vincola l’utenza ad un unico provider.

Nulla vieta infatti di acquistare un tipico IaaS dal cloud provider che preferiamo ed installarci (o farci installare) OwnCloud. In questo modo il costo da sostenere è quello relativo alle risorse che decidiamo di attribuire al nostro sistema.

In alternativa ci si può rivolgere ad uno dei tanti provider che offrono la soluzione in modalità SaaS, cosa che permette al cliente di non aver oneri di gestione del servizio. In questo caso i costi saranno caratterizzati dalla quantità di spazio o dal numero di utenti.

In ogni caso la versatilità del prodotto permette di farsi “due conti” e scegliere poi la soluzione più adatta alle proprie esigenza.

Due parole sulla sicurezza. La soluzione integra un sistema di cifratura dei dati al fine da salvaguardare eventuali fughe di informazioni. Inoltre, avendo alla sua base la più classica delle architetture di pubblicazione web (LAMP/WAMP/ecc) è possibile incrementare il livello di sicurezza utilizzando sistemi di cifratura anche a livello O.S. o File System.

Ho personalmente lavorato sul prodotto grazie ad un progetto di startup che il provider per cui lavoro ha portato avanti e devo dire che la soluzione è davvero ben fatta, molto intuitiva, semplice da configurare (per i SysAdmin) e semplice da usare (per gli Utenti) anche grazie alla disponibilità di client di sincronizzazione dati per le principali piattaforme Desktop e Mobile.

Maggiori dettagli sul prodotto sono ovviamente disponibili sul sito ufficiale (http://owncloud.org/). Per chi fosse interessato ad un servizio basato su OwnCloud o a demo per provare la soluzione sono, come sempre, disponibile ai miei recapiti.

VMware vCPU optimizing

La virtualizzazione ci porta a considerare la CPU non più come un componente del server ma come uno “pozzo” di cicli macchina da cui le Virtual Machines possono attingere all’occorrenza, rispettando la “coda” e la “priorità” che il sistema impone.

All’interno del Virtual Datacenter parliamo quindi di vCPU, ovvero di entità logiche che rappresentano un certo quantitativo di MHz eguale alla massima frequenza di lavoro della CPU o del CORE fisico del server host. Si ottiene quindi che se il nostro server fisico, su cui abbiamo installato l’hypervisor, è un bi-processore quad-core da 2.6 GHz, si potranno assegnare alle VMs vCPU da 2,6 GHz.

Evidentemente una vCPU non corrisponde alla CPU o CORE fisico del server host, si tratta semplicemente di una certa quantità di risorse computazionali che gli hypervisor mettono a disposizione delle VMs. I processi che girano all’interno dei sistemi operativi guest effettuato delle richieste “di calcolo” alle vCPU che possiamo leggere anche come una formale richiesta al server host di utilizzare un po’ del tempo di elaborazione di uno o più CPU/CORE del sistema fisico. A livello di hypervisor non è quindi necessaria una corrispondenza del tipo “1 vCPU” -> “1 CPU”, anzi avviene l’esatto opposto in quanto più vCPU possono richiedere tempo di elaborazione ad una stessa CPU (o CORE) con l’opportuna gestione da parte dell’intermediario di queste richieste, il software hypervisor.

Grazie a questo meccanismo la virtualizzazione permette di assegnare più vCPU a prescindere dal numero di CPU/CORE fisici che sono installati nel server host. Una sorta di “over booking” (il termine tecnicamente corretto è over entitlement) di tempo computazionale in quanto, teoricamente, ogni vCPU potrebbe chiedere tutto il tempo macchina di una CPU. Naturalmente se questo accadesse e qualora vi fossero vCPU in maggionr numero rispetto alle CPU/CORE, ci troveremmo di fronte ad un bel problema in quanto, a parità di priorità, nessuna guest si troverebbe ad aver a disposizione le risorse che richiede e l’intero sistema di virtualizzazione ci apparirebbe incredibilmente lento ed appesantito.

Come trovare quindi il giusto equilibrio tra consolidamento delle risorse e rispetto delle esigenze di tempo computazionale degli ambienti guest di un Virtual Datacenter?

Non esiste purtroppo una regola unica che sia sempre valida. Gli scenari sono molti e richiedono specifiche analisi per trovare il miglior compromesso. Esistono però delle best practice che ci aiutano a trovare la via giusta. Da tener presenta anche l’importante presenza di specialisti nel campo della virtualizzazione (in Italia abbiamo la fortuna di avere ben otto vExpert compreso il sottoscritto) e di aziende che lavorano molto sulla salute dei Virtual Datacenter (si pensi ai Service Provider che ne fanno largo uso).

Nulla vieta di studiare, capire ed applicare. Il documento messo a disposizione da VMware è senza dubbio illuminante, in questo post vorrei porre l’accento solo su alcuni controversi temi, ovvero su quelle pratiche errate che noto essere tra le più frequenti e, talvolta, molto dannose in quanto si tratta, nei casi migliori, di scelte tecniche atte a migliorare le performance dei propri sistemi ma che portano ad un paradossale peggioramento della situazione (nei casi peggiori si tratta di scelte che sfiorano la stregoneria, in questo caso è sicuramente opportuno consultare chi conosce il tema).

Il primo tema è senza dubbio relativo alla fatidica domanda “quante vCPU assegno ad una nuova VM?”. La risposta, volendo seguire il consiglio di VMware stessa, è semplice e lineare: alla creazione di una nuova VM si assegna il minor numero di vCPU possibile nel rispetto dei requisiti di sistema espressi dai produttori di software. Questo significa che nella stragrande maggioranza dei casi possiamo avviare la nostra VM con 1 vCPU. Ovviamente, laddove le esigenze di carico siano superiori (fatto facilmente verificabile consultando i grafici che riportano l’andamento della vCPU) è opportuno aggiungere le vCPU necessarie alla VM.

Perché è bene assegnare le vCPU secondo reale necessità? Assegnare con troppa generosità vCPU porta uno sgradevole effetto collaterale nei sistemi di virtualizzazione. La concentrazione di vCPU per CPU/CORE aumenta e con essa aumenta il rischio/probabilità che si verifichino delle contese di risorse. Tale situazione risulta inoltre difficile da diagnosticare in quanto le VMs sembrano perdere in prestazioni nonostante non raggiungano praticamente mai il saturo della propria vCPU. Questa catena di aventi spesso confonde il personale tecnico che si trova a cercare di capire come mai le VMs non utilizzano appieno le risorse anche quando sono sotto sforzo, con relativo evidente calo di performance.

In questa casistica è possibile osservare come il Ready Time (il parametro che misura in millisecondi quanto tempo una richiesta alla CPU resta in attesa) tende ad aumentare notevolmente. E’ la prova dell’esistenza di una contesa di risorse a cui il sistema host sta facendo fronte erogando equamente le risorse a chi le richiede. Il fenomeno in questione si presenta con minore incidenza se l’assegnazione delle vCPU avviene secondo un criterio di reale necessità.

Affiancato a questo scenario, dove abbiamo di fatto affrontato uno dei problemi derivanti dall’elevato consolidation ratio, vi è il tema della priorità con cui il sistema host risponde alle richieste della macchina guest. E’ evidente che se tutti hanno pari diritto di richiedere risorse alle CPU si genera un meccanismo tale per cui “tutti resteranno un po’ delusi”. E’ comunque vero che in un Virtual Datacenter esistono VMs meno importanti di altre le cui prestazioni possono essere temporaneamente inficiate per dar modo ad altre VMs, considerate critiche, di attingere alla riserva di risorse nei momenti di elevato carico.

La priorità con cui una VM può chiedere risorse all’ambiente è identificata da una delle proprietà della VM stessa ed ha valenza relativa al resouce pool in cui si trova la VM (si noti che esiste anche un resouce pool “base” chiamato root resouce pool). Ciò significa che ogni VM può contendersi risorse solo con le VMs dello stesso resouce pool o con resouce pool al suo stesso livello. Per dare più priorità ad una VM è necessario aumentarne la quota di “share” all’interno del resouce pool in modo da privilegiarla in caso si verifichi una contesa di risorse. In questo caso il sistema assegnerà le risorse alle VMs mantenendo le proporzioni espresse dai parametri di share delle VMs all’interno del resouce pool.

L’ultimo scenario che affrontiamo in questo post è di più ampia visione. Non guardiamo più alle vCPU in proporzione alle CPU ne ai parametri di share delle VMs, il punto di vista è il Cluster. All’interno di questo macro contenitore di risorse possiamo trovare diverse centinaia di macchine virtuali con workload anche molto differenti. Chi gestisce cluster importanti in termini di dimensioni e con molte VMs difficilmente riesce ad ottenere buoni risultati di omogenea ripartizione del carico senza l’ausilio del Dynamic Resource Scheduler (DRS). Questo arcinoto strumento permette di automatizzare la migration delle VMs tra i nodi del cluster a fronte di una necessità di bilanciamento del carico in termini di CPU e RAM.

DRS di per se lavora già molto bene in quanto, se vengono mantenuti i parametri di default, ogni 300 secondi verifica se il cluster può beneficiare di eventuali spostamenti di VMs. Nel caso in cui chi amministra l’infrastruttura abbia anche contezza dei workload delle VMs o di gruppi di queste è possibile mettere in campo un’altra funzionalità di VMware: le affinity/anti-affinity rules. Queste regole permettono di interferire con le scelte del DRS in relazione alla volontà di mantenere separate o unite delle specifiche VMs a livello di host. Diventa così possibile evitare che due VMs che presentano workload molto simili si trovino su uno stesso host del cluster.

Il tema non si esaurisce certo in queste mille parole, sono comunque abbastanza certo del fatto che questo articolo trova applicazione, almeno in alcune sue parti, in buona parte dei cluster VMware attivi in Italia (per non dire in Europa). Nonostante i concetti siano relativamente semplici – infondo basta studiare – la loro corretta applicazione non è così scontata… quindi in bocca al lupo e nel caso sapete dove trovarmi ;-)

Open Virtualization Format

Open Virtualization Format (OVF) è un magico formato che aiuta il mondo della virtualizzazione e dei virtualizzati. Qualche anno fa un gruppo di aziende protagoniste nel campo della virtualizzazione ebbe la sana pensata di proporre un formato standard per la distribuzione di Virtual Appliace e macchine virtuali in generale.

Il concetto è molto semplice: tutti i brand/prodotti che supportano questo formato permettono di estrarre/esportare una qualsiasi macchina virtuale dal proprio Virtual Datacenter in un set di files che contengono tutti i dati base del sistema guest, dalla configurazione della macchina virtuale ai dischi virtuali della stessa. La macchina virtuale, in questo formato, può essere facilmente importata su un differente sistema di virtualizzazione se anche questo supporta il formato OVF.

L’introduzione di questo formato agevola molte attività nell’ambito dei Virtual Datacenter. La prima è sicuramente la distribuzione: chi crea prodotti da distribuire sotto forma di Virtual Appliance non poteva sperare cosa migliore di un formato comune ai principali brand di mercato. Molti prodotti vengono infatti distribuiti in un comodo OVF che contiene la guest già configurata e con a bordo l’applicazione.

Altra agevolazione è la movimentazione di VMs tra diversi Virtual Datacenter non comunicanti a livello dati. Il più classico degli esempi è la migrazione da un Private Cloud ad un Public Cloud, nulla è più comodo di esportare le VMs in formato OVF ed importarle nella loro interezza all’interno del nuovo Virtual Datacenter.

Nell’uso di questo strumento è bene prestare un minimo di attenzione a ciò che si esporta: vCDROM con ISO mounted, riferimenti a hardware specifico e configurazioni specifiche della guest sono da pulire prima che la VM venga esportata in modo da scongiurare errori in fase di importazione (banalmente nel nuovo Virtual Datacenter il path per la ISO non sarà disponibile). Al di la di queste cautele tecniche è evidente come lo strumento sia semplice da usare e di reale supporto alla gestione del proprio Virtual Datacenter.

Chiuso il capitolo accademico riporto la mia esperienza. Personalmente, oltre che per gli scopi indicati, utilizzo il formato OVF anche per l’archiviazione off-line di veri e proprio template di VMs, mentre i template di uso frequente è bene che stiamo in un’area dello storage sempre disponibile al Virtual Datacenter.

In definitiva è uno strumento da non dimenticare nella gestione del proprio ambiente virtuale, semplice, pratico e disponibile in molti software di virtualizzazione.

VMware virtual memory: ballooning

Da recenti esperienze lavorative noto che il funzionamento del meccanismo che permette ad una virtual machine di utilizzare o meno la memoria del proprio host non è ben chiaro nemmeno a chi gestisce Virtual Datacenter di una certa dimensione. In ambito virtualizzazione la gestione della memoria è un tema estremamente importante essendo una delle risorse che impattano direttamente le prestazioni dell’ambiente guest.

In questo articolo, il primo di una piccola serie che vorrei proporre, ci concentreremo sul ballooning. Tramite questo sistema gli host ESXi sono titolati a reclamare memoria allocata dalle virtual machine ma non utilizzata al momento. Ciò è possibile grazie ad un apposito pseudo-device driver che serve a “gonfiare un palloncino” di memoria allocata all’interno della virtual machine stessa in modo da liberare una porzione della memoria fisica dell’host facendo credere alla virtual machine di avere questa porzione di RAM in uso.

Lo scopo di questa meccanica è restituire memoria all’host quando questo si trova in carenza di questa risorsa. L’effetto collaterale inevitabile è un potenziale deterioramento delle prestazioni della virtual machine qualora il sistema operativo guest dovesse aver bisogno di ulteriore virtual memory al momento non disponibile. In questo caso il sistema operativo saturerebbe la vRAM restante fino ad arrivare ad utilizzare la propria partizione di swap o il page file con relativo calo delle prestazioni del sistema.

Questo comportamento è tipico delle infrastrutture che, per diverse ragioni, si trovano ad avere una situazione di saturo della memoria RAM a livello host. E’ quindi inevitabile la ricerca di un compromesso che abbia come fine la razionalizzazione della risorsa RAM all’interno di un cluster VMware vSphere.

E’ evidente come il ballooning sia un sistema a tutela dell’infrastruttura più che della virtual machine, in tal senso il cluster vSphere deve essere opportunamente configurato a livello di resource pool e share di risorse tra i pool e le virtual machine stesse.

Ovviamente evitare il ballooning è possibile laddove non lo si desideri affatto (come nei cluster di produzione di cui ho seguito progettazione ed implementazione) al fine avere a disposizione un’infrastruttura che tenda a garantire le risorse alle virtual machine. Senza prendere in esame casi limite di over commitment, si pensi semplicemente al banale caso in cui una virtual machine si trovi improvvisamente a dover sostenere un picco di carico che la porti ad allocare molta vRAM. Se il cluster è molto utilizzato è plausibile un saturo a livello host tale da generare il fenomeno del ballooning, ma se il cluster è configurato in modo da bilanciare il carico tramite DRS tale fenomeno sarà facilmente evitabile ed il livello prestazionale delle virtual machine sarà garantito.

Qualora volessimo accertarci che la nostra virtual machine non sia soggetta a ballooning possiamo eventualmente agire a livello di configurazione della virtual machine stessa tramite la seguente configurazione nel file .vmx (rif. KB 1002586):

sched.mem.maxmemctl = “0”

Non è cloud

Parlare di cloud oggi mi ricorda i monologhi sul web 2.0 del ’06. Tutto era, o doveva essere, web 2.0. Oggi tutto è, o vorremmo che fosse, cloud.

In tutto ciò vi è una meravigliosa ironia da cogliere. Buona parte dei servizi che riportano l’etichetta “cloud” non lo sono affatto, e inoltre, buona parte delle richieste di servizi cloud che mi passano per le mani si rivelano, di fatto, servizi abbastanza distanti dal concetto di cloud.

Ed ecco che abbiamo distrutto un altro termine che ha avuto senso compiuto per i dieci minuti in cui solo gli addetti ai lavori del mondo ICT lo utilizzavano. Ma quindi di cosa stanno parlando tutti? (notare che con “tutti” mi riferisco sia ai provider che ai consumer)

Sfruttando alcune occasioni di incontro/scontro tecnico con alcuni filosofi e tecnici dell’ICT, ho discusso il tema e messo a confronto le diverse idee ed esperienze. Ne emerge un quadro interessante fatto di distorsioni, incomprensioni e marketing.

Visto che le idee chiare sul concetto di base non le ha praticamente nessuno, distorcere è estremamente facile. È così che il servizio remoto erogato da un provider diventa “cloud” anche se non ha nessuna logica di self-provisioning, non ha meccanismi di scalabilità automatici, non è accompagnato da una formula contrattuale “a consumo” (pago solo quello che uso e quando lo uso). Di fatto capita che il servizio erogato/richiesto non è molto distante da quello che erano i Virtual Private Servers (VPS), ma con l’etichetta “cloud”.

Di fondo non esiste un vero problema se non che l’evoluzione tecnologica di questo genere di servizi viene alterata da chi utilizza l’etichetta per attrarre il cliente. La cosa genera solo tanta confusione e getta un po’ di fumo negli occhi ad un mercato che trarrebbe davvero beneficio da questa filosofia di servizio.

C’è da dire che è il cliente stesso che talvolta utilizza il termine cloud per identificare un servizio che cloud non lo è per nulla. Un esempio è voler disporre di uno IaaS e contemporaneamente voler demandare al provider tutte le attività di manutenzione ordinaria dei sistemi, dal patching alla verifica del buon funzionamento delle applicazioni. Richiesta legittima, ma sicuramente non siamo nell’ambito dello IaaS.

Probabilmente, in Italia, stiamo ancora osservando un adattamento del mercato ad esigenze dei clienti ancora non ben definite a cui i provider rispondono, per varie ragioni, con servizi ancora troppo custom per poterli definire orientati verso il cloud in senso stretto.

Volendo estremizzare potremmo comunque dire che il provider sta svolgendo un buon lavoro se da al proprio cliente quello che gli serve. Il tal senso la tipologia di servizio è abbastanza arbitraria e si rende necessario lavorare sull’integrazione di diversi sistemi e servizi. Non è un caso vedere come sempre più provider mettano in campo un proprio System Integrator, o lo diventino loro stessi, per soddisfare le esigenze ibride dei propri clienti.

Con questo post non voglio dire che in Italia il cloud non esiste, ma è evidente quanto il termine sia inflazionato tanto da creare un effetto collaterale indicativo: una sensazione di sgradevolezza verso chi propone un servizio che, con molte forzature viene definito “cloud”. Indicativi sono anche i volti di chi conosce il tema (tecnici ed IT Manager) quando annusano che la proposta cloud è l’ennesimo servizio tradizionale con qualche miglioria e con la solita etichetta lucente.

Provo a concludere dando una morale. I VPS e l’outsourcing di servizio non sono servizi vecchi o da rimpiazzare a tutti i costi, sono esigenze che i “consumatori di IT” hanno parallelamente alle nuove esigenze di IaaS e SaaS. L’IT Manager deve capire cosa gli serve davvero (ed in questo caso entrano in gioco i System Integrator o i consulenti “di livello”) e scegliere di conseguenza valutando bene i PRO e i CONTRO dei diversi paradigmi di servizio.