VMengine Business Blog

Abbiamo partecipato a questo doveroso evento nel bellissimo Hotel Sheraton Golf2 di Roma. Riportiamo di seguito l’agenda:

• 9.30 Registrazione dei partecipanti

• 10.00 Benvenuto e apertura dei lavori
  Luigi Marcocchia, Softway

• 10.10 Come sfruttare la potenza della virtualizzazione per trasformare i Data Center in infrastrutture di cloud computing semplificate, in grado di erogare servizi evoluti, affidabili, flessibili e sicuri Oggi le aziende dipendono in misura crescente dai servizi IT e le opportunità offerte dalle tecnologie della virtualizzazione declinate nell’ambito Data Center offrono a tutte le imprese (dalla grande azienda alla PMI) evidenti vantaggi da vari punti di vista. Infatti, la possibilità di astrarre le applicazioni e i dati dell’infrastruttura sottostante, per creare un’infrastruttura cloud interna, consente non solo di aumentare l’efficienza di erogazione dei servizi IT esistenti, riducendo notevolmente i costi e la complessità associati alla gestione e manutenzione dell’infrastruttura, ma riduce in maniera drastica i tempi di implementazione di nuovi servizi. In questo modo, i responsabili IT sono messi al riparo dalla complessità di server, storage e infrastruttura di rete, permettendo loro di concentrarsi sulla realizzazione del valore per l’azienda. Quali sono gli aspetti architetturali della nuova soluzione vSphere per l’infrastruttura virtualizzata? Quale in concreto l’impatto sul business delle imprese? Sergio Cimino, VMware

• 10.50 Verso lo Unified Computing System: la nuova architettura per il Data Center del futuro Le possibilità offerte dalle tecnologie di virtualizzazione di unire le accresciute capacità di elaborazione dei sistemi IT, con le nuove performance della rete e con l’accesso rapido alle risorse di storage, hanno gettato le basi per definire le evoluzioni del Data Center del futuro verso una visione di Unified Computing System. Quali sono le principali componenti di questa nuova architettura e come si integrano fra loro? Come cambiano le esigenze relative all’infrastruttura fisica di rete e quali sono i benefici dell’innovativo approccio Unified Fabric, Fabric Ethernet per IP & Fibre Channel? Come evolve il tradizionale ruolo dello switch in un ambiente virtualizzato? Quali le novità tecnologiche in atto? Come disporre degli stessi benefici in termini di semplicità di configurazione e operatività dei servizi di rete tradizionali disponibili negli switch “fisici”, applicandoli alle nuove virtual machine? Come implementare un processo di consolidamento dello storage e come valutarne in maniera corretta l’impatto in termini di costi/benefici? Roberto Missana, Cisco Italia e Vice Chairman SNIA Italia

• 11.30 Coffee break

• 11.50 Lo storage in un’architettura virtualizzata Per poter usufruire di tutti i vantaggi legati alla virtualizzazione, è indispensabile iniziare a pensare non più a singole implementazioni, ma a un disegno complessivo di Virtual Data Center. Nell’intervento verranno illustrate nuove tipologie di soluzioni e nuovi modelli di offerta per l’archiviazione e la gestione dei dati e delle informazioni aziendali fra cui, per evidenziare le principali, lo storage multi protocollo, le virtual tape library, la deduplica, lo snapshot, il thin provisioning. Roberto Patano, NetApp

• 12.30 Domande e risposte

• 13.10 Chiusura dei lavori

• 13.20 Lunch

VMWare

L’intervento di Sergio Cimino di VMware si è focalizzato sulle novità della nuova piattaforma vSphere 4 (Cloud OS) e sulle performance documentate da benchmarks super partes. Di particolare nota sono queste nuove features.

vCompute

Il nuovo hypervisor ESX 4.0 consente VM fino ad 8 VCPU, 256 GB RAM, 20 Gb/s di network ed oltre 200.000 IOPS con una latenza inferiore ai 20 microsecondi. L’ESX può scalare su un hardware fino a 64 core ed 1TB di RAM.

Considerando il seguente schema:

Vediamo che sono poche le applicazioni che riuscirebbero a sfruttare la potenza dei server moderni, pertanto lo strato di virtualizzazione, l’hypervisor, diverrà quasi essenziale nell’immediato futuro. Un esempio di benchmark eseguito con SPECweb2005 su una macchina HP Proliant DL585G5 con 16 Core con l’hypervisor ESX3.5 ha fornito un risultato di 44.000, cioè in grado di supportare 3 miliardi di pagine visitate al giorno, cioè 3 volte il traffico di ebay su un sol server. Una nuova feature DPM (Distributed Power Management) dona all’infrastruttura una veste molto più GreenIT in quanto il DRS (Distribuited Resource Scheduling) può spegnere all’occasione i server fisici sottoutilizzati per poi riaccenderli all’occasione. Fondamentale inoltre la possibilità di poter variare a caldo il numero di VCPU e VRAM di ogni singola VM, ovviamente se il sistema operativo virtuale lo consente, altrimenti il blu/purple screen sono d’obbligo.

vStorage

Per quanto riguarda la situazione storage c’è una ottimizzazione notevole dello spazio, si occupa solo cio’ che viene realmente utilizzato e l’estensione del disco può essere fatta a caldo.

vNetwork

Sul networking ci sono grosse novità, grazie alla collaborazione di cisco, la rete diventa virtuale a livello di datacenter non solo a livello di macchina fisica, ciò evita notevoli riconfigurazioni, o copie di configurazioni tra tutti gli ESX server della farm.

Automatismi e controllo

Queste nuove features sono accompagnate dalla possibilità di essere controllate mediante automatismi programmati mediante workflow

Qui c’è anche la possibilità che abbiamo citato in passato della fault tolerance delle VM

Feature sicuramente molto utile nei casi di una rigorosa business continuity, però occupa il doppio delle risorse di una singola VM.

vApp & IT as a service

La possibilità di poter definire delle applicazioni (insiemi di VM connesse secondo logiche di architettura) in grado di autodescriversi consente di poter pubblicare/migrare la vApp tra Cloud infrastructure

Continue Reading »

La piattaforma Cloud Computing di Microsoft, che è del tipo Application/Platform (Saas/PaaS), ha una interessante servizio, SQL Data Service (SDS), rappresenta un database relazionale cloud-based sviluppato con la tecnologia dell’ SQL Server 2008 di cui consiglio di vedere la presentazione in silverlight.

Mediante l’ SDS è possibile facilmente usare un database relazionale RDBMS (quale SQL Server) approfittando dei vantaggi della distribuzione globale dei datacenter di Microsoft destinati allo sviluppo del progetto Azure , pertanto availability, scalability e security.

SQL Data Service Features

• Creating, accessing and manipulating tables, views, indexes, roles, stored procedures, triggers and functions
• Insert,Update, and Delete
• Constraints
• Transactions
• Temp tables
• Query support
• Basic functions (aggregates, math, string, date/time)
• A subset of the existing SQL built-in stored procedures and system views
• Ado.Net
• ODBC
• PHP
• Support for running SQL configuration scripts via SQLCMD and SQL Query Analyzer from within SQL Server Management Studio
• Support for Visual Studio and SQL Server Management Studio
• Support for SQL Server Management Studio, SQL Server PowerShell and programmatic access via SQL Server Management Objects (SMO)
• Support for friction free provisioning of Logical Servers and Databases through the SQL Data Services account portal
• SDS supports the SQL authentication modelRedundant copies of user database
• User authenticated by standard SQL logins
• Login map to user inside the database
• Current SQL USER and ROLE mechanisms continue to work with the database. GRANT/DENY/REVOKE permissions of SQL objects to USER/ROLE
• Redundant copies of user databases for fast failover and high availability in case of failure
• Automatic load balancing for optimal resource utilization and performance
• Scale out with multiple databases and partition-aware application
• Automatic system backup for data protection
• A subset of existing SQL manageability facilities will be available

Come si è potuto notare dall’elenco delle features, è come avere installato un proprio server di rete database SQL Server ed amministrarlo con i soliti strumenti di sempre (Management Server, SQL Analyzer,Visual Studio) usare tutte le feature classiche di un SQL Server (functions, views, stored procedures, tables, indexes. transactions,etc), ma con la potenza e l’affidabilità di una infrastruttura scalabile di una Cloud Computing.

Ovviamente non è pensabile di usare questo servizio senza appoggiare le nostre interfacce SW agli altri servizi di Windows Azure come il .NET Services perchè le lantenze di internet farebbero perdere i vantaggi di usare un RDBMS Cloud Based, mentre stando negli stessi datacenter con connettività dedicata, si  ha il massimo vantaggio in performance.

Per ora il servizio è limitato per ogni utente ad un database di massimo 10GB, che non è poco, il modello di pagamento è quello classico a consumo.

E’ sicuramente un servizio molto professionale e si pone all’avanguardia tra gli attuali servizi database in Cloud, sarebbe da testare per grossi portali con molto traffico.

La NASA lancia in beta la sua piattaforma di cloud computing chiamata NEBULA, una piattaforma che integra un set di componenti open-source in una unica piattaforma self-service.

Dal diagramma della architettura si notano elementi database come MySQL Cluster, soluzione di storage network clustering quali il Lustre File System, elementi del sistema di cloud Eucalyptus, Trac, SubVersion, il sistema di messagging queue RabbitMQ, linguaggi come Python, Java, il sistema di indicizzazione e ricerca SOLR ed altri.

La piattaforma destinata alla ricerca scientifica, è in beta limited e cercano beta tester “Computonauti” tra scienziati, per raffinare algoritmi o fare analisi, il tutto per supportare la serendipità, cioè quel neologismo indicante la sensazione di una improvvisa scoperta quando la ricerca cerca tutt’altro.

Occorre sottolineare che questo primo datacenter è sito all’ Ames Research Center, nell’ Ames Internet Exchange (AIX), uno dei nodi originali di internet

Nonostante la definizione in bozza del NIST, National Institute of Standards and Technology si continua a parlare di Cloud Computing come se fosse la tecnologia capace di fare tutto.

Una di queste feature tanto nominata è la presunta scalabilità innata della tecnologia, pertanto partiamo innanzitutto da una corretta comprensione della scalabilità:

Possiamo definirla come la capacità di un sistema di crescere in base al numero di richieste esterne al sistema stesso. Generalmente si intende la crescita in orizzontale, cioè su “commodity hardware”, che si riassume aggiungendo server economici per aumentare la potenza del sistema e naturalmente bilanciarne il carico. Effettivamente sembra calzare con il Cloud Computing che per definizione sarebbe una infrastruttura scalabile semplicemente, basata su “commodity hardware” e capace di erogare potenza su richiesta all’utente finale. Molti dei solution architects si ricorderanno benissimo le complessità affrontate nel riuscire a far scalare le applicazioni dei clienti, ed inoltre consideriamo che la maggior parte dei più grossi portali e social network hanno sviluppato proprie logiche per scalare, logiche nate dalla tipologia della applicazione.

Quando nel 2007 ci imbattemmo nei servizi di Amazon AWS, fu leggendo il sito per eccellenza dedicato alla scalabilità highscalability.com dove era pubblicato un articolo che ipotizzava l’uso dei webservices di Amazon per lo sviluppo dei social network, allora non era ancora stato coniato il termine Cloud Computing. Come ormai noto il Cloud Computing, si basa sulla virtualizzazione dei server , dei servizi di storage e di network, pertanto fino a non molto tempo fa i più esperti giudicavano male l’uso della virtualizzazione in quanto le singole macchine virtuali non potevano avere le stesse prestazioni di una eguale configurazione senza strato hypervisor, ancora oggi se ne possono trovare di architetti contrari. Non è sbagliata come obiezione, ma il ragionamento che porta a preferire il Cloud all’approccio generico è l’enorme risparmio economico e la semplicità e velocità di approvvigionamento delle risorse, rispetto la messa in opera di nuovo hardware che comporta anche personale qualificato per le configurazioni. Se poi pensiamo che Amazon, il più grosso e-commerce al mondo funziona con una infrastruttura eguale ai servizi AWS che eroga ai clienti, ci fa riflettere anche sulle prestazioni di una corretta implementazione in Cloud. Amazon ha maturato nel tempo e sviluppato in house quelle che sono le elastiche logiche del Cloud che vende ai clienti di AWS, come è possibile vedere in questo video dove Jeff Bezos, fondatore di Amazon.com descrive Amazon Web Services che è un prodotto nato dai laboratori di Amazon per gestire la loro infrastruttura:

Come noto il Cloud Computing può erogare servizi in tre modalità :

1. SaaS
2. PaaS
3. IaaS

Nel primo caso Saas (Software as a Service) c’è una applicazione già sviluppata e quindi già pensata per scalare nella infrastruttura sottostante. In questo caso non è detto che sotto ci sia una Cloud; è per esempio il caso di gmail, google documents, SalesForce.

Nel secondo caso PaaS (Platform as a service) c’è una piattaforma capace di ospitare applicazioni fatte da altri, ma queste applicazioni devono soddisfare i ristretti requisiti richiesti; è questo il caso ad esempio di google app engine che consente di pubblicare applicazioni in java e non preoccuparsi se il traffico su queste applicazioni cresce a dismisura. Anche in questo caso non è sempre vero che il substrato sia una Cloud.

L’ultimo è l’ IaaS (Infrastructure as a services), che rappresenta una serie di interfacce software (API , webservices) usabili mediante autenticazione, con le quali è possibile programmare le risorse computazionali che ci occorrono per far andare la nostra applicazione. Pertanto questo livello non è scalabile naturalmente, ma dovremmo noi essere capaci di programmarlo per scalare la nostra applicazione; l’esempio più chiaro è più noto di IaaS è AWS (Amazon WebServices).

Soluzioni

Molte realtà stanno nascendo e stanno cercando di affermarsi nel mercato della scalabilità in Cloud. Tutte queste realtà sono software sviluppati sullo strato più basso, software capaci più o meno di rispondere agli eventi di sovraccarico bilanciandone il carico su nuove risorse richieste al sistema automaticamente. La maggior parte di questi software si posizionano tra il PaaS e l’ IaaS perchè devono consentire un minimo di programmabilità/configurazione all’utilizzatore che non può essere pertanto uno digiuno della materia; uno dei casi più rappresentativi è RightScale, che però oltre ad essere complesso è anche costoso.

RightScale crea uno strato più semplice della programmazione bruta dei comandi API di AWS, mediante vari casi già sviluppati ci si può far guidare nella creazione della nostra infrastruttura virtuale in Cloud, scalabile secondo le logiche che noi andremo a definire.

E’ di oggi l’uscita in beta della (da noi tanto attesa, in quanto c’era stata anticipata) soluzione di scalabilità propria di AWS. Amazon lancia in beta oggi i seguenti webservices:

• CloudWatch
• ElasticLoadBalacing
• AutoScaling

Questi tre servizi che, come noto si utilizzano mediante scripting, consentono di monitorare le AMI (amazon machine image), di programmare un load balancer per la nostra applicazione e definire dei gruppi e dei trigger per far intervenire in automatico nuove risorse a sostenere le richieste di performance della nostra applicazione.

L’offerta sembra ottima, solo il CloudWatch ci sembra eccessivo in costi, monitorare 10 AMI costerebbe più del costo di una AMI sulla quale noi possiamo installare un sistema di monitoring che ne puo’ monitorare molte di più.

Tornando al problema della scalabilità, esistono quindi soluzioni in Cloud per garantirci uno sviluppo senza preoccupazioni, ma, solo dei buoni architetti possono sollevare le giuste eccezioni, come scaliamo un database?

DB Scalability

Ed è qui che possiamo dire che il Cloud Computing non consente naturalmente di scalare ma occorre adottare una complessa serie di accorgimenti che devono essere valutati caso per caso. Ormai è noto ai più esperti che scalare un database relazionale di un social network, cioè con un bilanciamento R/W circa al 50% non è cosa semplice e prevede tutta una serie di approcci di distribuzione delle richieste dividendo il database in tanti pezzi (sharding), modifiche alla applicazione ed inserimenti di inMemoryDatabase (es . memcached) per conservare memoria della posizione dei pezzi.

I piu’ smaliziati potrebbero dire che si potrebbe passare alla moderne soluzioni di inMemoryDataGrid, cioè una sorta di Cloud di risorse RAM sulle quali spalmiamo il nostro database. Beh sicuramente le prestazioni ne risulterebbero molto premiate, ma il costo di una risorsa RAM rispetto la risorsa HD è superiore dello stesso ordine di grandezza di quanto più performante è la RAM Vs HD, inoltre oltre ad essere antieconomico è anche sovrabbondante in quanto non tutti i dati della nostra applicazione è necessario tenere sempre online, perchè magari non richiesti da nessuno.

Altra moda molto commerciale, ma poco funzionale è la Cloud privata capace di scalare nella Cloud Pubblica (Hybrid Cloud). Innazittuto siamo ancora senza uno standard, pertanto dovrebbe essere sviluppata ad hoc per ogni cliente, secondo torniamo al problema precedente, se la nostra esigenza è la scalabilità del database, come lo scaliamo dalla Privata alla Pubblica? Considerando che generalmente la banda utile ad unire un CED privato con un datacenter dove risiede una Cloud è dell’ordine delle decine di Mbits in download e meno ancora in upload. Occorrerebbe attivare delle repliche che potrebbero facilmente disincronizzarsi.

Reali esigenze del cliente

Il cliente generalmente richiede semplicità, richiede di passare alla Cloud senza alcun impatto per il suo normale sviluppo, senza sconvolgere l’applicazione, senza abbandonare le logiche relazionali del suo database, perchè costituirebbero costi grossi, addirittura sostituzioni del personale in quanto non qualificato o non adatto a riscrivere l’applicazione per crescere in Cloud.

VMEngine sta rilasciando la sua prima release basata su un semplice approccio alla scalabilità, all’auto-scaling di tutta l’applicazione anche database server, ed intanto fa ricerca per rendere sempre più automatizzata la scalabilità e sempre più trasparente al cliente che puo’ tornare a sviluppare senza dover sconvolgere il know-how dei propri sviluppatori

Un pò di tempo fà nell’analisi approfondità delle performance degli hypervisors ci trovammo di fronte ad un problema nativo del virtual Simmetric MultiProcessing (vSMP) che sarebbe un metodologia del Simmetric MultiProcessing (SMP), grazie alla quale possiamo assegnare ad una virtual machine più di una virtual CPU (vCPU).

Questa feature consentirebbe di dare maggior potenza di calcolo alla virtual machine, ma purtroppo non è sempre vero e dipende dalla natura della applicazione se usa o meno logiche multi-threading, come nella illustrazione qui sotto per intenderci:

Per meglio risponderci alla domanda sottoponemmo una questione nel social network professionale linkedin . La “question” che ponemmo è la seguente:

Multi-vCPU virtual machine cycles scheduling

I need one who explain me, with details, the differences between kernel hypervisors (ESX,XEN,HYPER-V,KVM) about the real performance when we define a Virtual Machine with more than 1 vCPU. I think when a generic application, installed on the VM with 2 vCPU, places a request for CPU cycles, cuncurrently to the two vCPU. These requests goes into a queue for the Host to process. I think the Host wait until there are two Cores with concurrent idle cycles.
If the Host have more VMs not in idle, the our VM multi-CPU lost in performance.
Is right for you? Have you experience about it? Can explain me the differences between kernels ? Which hypervisor is the best for this events?
Thanks and good new year

Le migliori risposte che abbiamo ricevuto sono le seguenti:

Da Mindaugas Kiznis-IT Professional, IT Infrastructure Solution Architect at CSC.

This presentation is maybe more from the VMware side, because it was made by a VMware guy, but shortly it shows and compares major things about different virtualization principles and products:
http://www.virtualization-symposia2008.lv/files/File/4_vmware_virtualization_symposia_latvia_thuber.ppt

Maybe these docs will explain about CPU scheduling in virtualization:
http://cs.gmu.edu/~hfoxwell/cs671projects/southern_v12n.pdf
http://www.cs.ucsd.edu/~dgupta/papers/per07-3sched-xen.pdf

Here is a good feature comparison:
http://www.it20.info/misc/virtualizationscomparison.htm

If you still will have some specific questions about virtualization, feel free to write me and I will try to answer you.

I link che riporta Mindaugas sono un fantastico materiale di studio e di approfondimento ed anche di paragone tra i vari hypervisors, vi invito a leggerveli.

Da Manlio I.A. Frizzi-Information Technology and Services Consultant and Contractor at Brain Force. Virtualization Evangelist.

hello Fabio, and, first of all, happy new year!
what you are saying is completely right: the rule of thumb for multi vCPU VMs is creating it only if you know that the application(s) you’re going to install/execute are compiled to use multi-threaded execution.
If not, do it 1-vCPU: the performance will be better.

Moreover there are some cases in which multi cpu will degrade the performances: Virtual Machines with Citrix TS installed on them must be 1-vCPU: this because Citrix TS will do a lot of context switches and ESX will do other context switches multiplying the overhead.

Another thing to take into count is having the right multiprocessor kernel installed: a lot of OS detect multi CPU and install the right kernel for the number of (v)CPU that have beeen detected: if you need SMP enabled kernel remember that, used on a 1-(v)CPU environment, it will perform very bad.

For the “best hypervisor” question… I have my ideas… in your list of hypervisor only one can be used in production environment…

hope to help
Manlio
http://virtualaleph.blogspot.com

La risposta di Manlio conferma i nostri dubbi relativamente alle performance di una VM multi vCPU se non accuratamente valutato il software che deve girarci sopra.

Ora vogliamo riportare un benchmark non ufficiale ma non di parte eseguito da Rick Vanover-MCITP, MCTS, MCSA, system administrator for Safelite AutoGlass. A 12-year IT veteran and online columnist for Virtualization Review.

L’articolo completo è pubblicato al seguente link Lab Experiment Hypervisors

Le piattaforme comparate sono:

VMware ESX 3.5
Microsoft Hyper-V
Citrix XenServer 5

Le specifiche hardware e delle virtual machine sono:

Guest Requirements

* Support Windows Server 2003 R2 with Service Pack 2 (x86 edition) as a guest operating system
* Permit the provisioning of guest virtual machines in one of two configurations:
* Memory at 1024MB, 10GB local drive space
* Memory at 2048MB, 20GB local drive space
* No CPU limits in place

Host Requirements

* Support an installation on the three parallel systems of identical configuration: Dell PowerEdge 2950 2×2 @ 3.0GHz, 16GB RAM, 360GB local storage on one single array (RAID 5)
* Permit use of local array for guest virtual machines

I test eseguiti sono riassunti nella seguente immagine:

Ed i risultati sono tutti nella seguente immagine:

Il test ha mostrato che a livello Hypervisor, ESX è ottimizzato per un numero minore di intensive workload. Per intensive workload che non può essere ottimizzata per memory overcommit, Hyper-V e XenServer dovrebbero essere considerati come i più indicati. Occorre però ricordare che questo test è un test specifico su SQL Server 2005 su una macchina virtuale Windows 2003 a 32 bit.