Virtualizzazione, ipervisori e applicazioni

Come già detto non sono un grande fan della virtualizzazione. Spesso noi abbiamo a che fare con sistemi complessi e la virtualizzazione in questi sistemi non risulta per nulla trasparente provocando cali di efficienza o, peggio, veri e propri malfunzionamenti. Mi è persino capitato di trovare casi in cui alcuni fornitori hanno consigliato al cliente l’acquisto di prodotti di virtualizzazione per scoprire poi che il loro stesso software non girava sulla virtualizzazione da loro stessi proposta! E comunque a volte proprio non serve visto che la piattaforma applicativa stessa fornisce le caratteristiche per cui la virtualizzazione viene scelta.

Però poco tempo fa BEA ha annunciato una nuova versione del loro application server WebLogic in grado di girare nell’ipervisore senza richiedere il sistema operativo. Per un application server J2EE questo ha molto senso visto che l’ambiente Java stesso maschera il sistema operativo sottostante: fornire quindi un ambiente minimale necessario alla JVM può essere efficiente. Quindi a maggior ragione si può eliminare il sistema operativo completo sostituendolo con uno strato molto meno complesso che fornisce le funzioni di base. E’ un modello molto interessante e che dimostra ancora una volta di più cosa si intende per piattaforma quando si parla di Java. In effetti noi utilizziamo spesso lo stack Java di IBM (WebSphere in parole povere) dove quasi sempre il resto (e soprattutto il sistema operativo) è irrilevante.

Tra parentesi di solito il cliente medio sceglie come sistema operativo Windows perchè non ha né voglia né tempo di gestire sistemi operativi alternativi. Questo fatto è stata uno delle motivazioni che mi ha convinto qualche anno fa a riproporre Windows in modo pesante nonostante la nostra grande esperienza su altri sistemi.

Tornando al discorso della virtualizzazione sarà interessante vedere come questa si inquadrerà in una architettura Windows.

Attualmente molte applicazioni Microsoft fanno uso di alcuni servizi comuni come Active Directory e SQL Server. AD è il cuore di una rete Windows ed è bene avere almento due server in azienda. Io penso che, per questioni di ridondanza e resistenza e sicurezza, è bene averli su macchine fisiche separate. Se si utilizza molto SQL Server, allora anche questo è bene averlo ridondato su macchine fisiche: in fondo un SQL Server è in grado di sfruttare memoria e thread in modo efficiente da solo. Con una organizzazione di questo tipo è possibile ospitare applicazioni IIS (che utilizzano la struttura SQL Server per i dati) su vari server: bilanciamento e ridondanza sono offerti dall’IIS stesso. I server di posta evoluti sono sistemi spesso critici e che oggi hanno un  bisogno di elevato I/O. Al momento attuale non ho esperienza di virtualizzazione di grossi sistemi questo tipo in quanto tutti i clienti li preferiscono su macchine dedicate (in cluster tra loro). I sistemi di messaggistica integrata con funzionalità VOIP richiedono molta CPU, molta banda, schede di rete veloci e poco disco. Anche questi probabilmente funzionano meglio su macchine fisiche. Aggiungo, poi, che il supporto al framework .NET è e sarà sempre più embeddato nel sistema operativo (in pratica “application server” .NET e Windows saranno sempre più la stessa cosa). A tutti questi fattori vanno aggiunti i cali dei costi delle SAN che permettono di centralizzare facilmente lo storage “fisico” delle varie macchine e la disponibilità di dispostivi blade. E, se proprio si vuole, esiste un Microsoft Virtual Server che permette di gestire bene e facilmente macchine virtuali per altri scenari.

E’ però vero che sul mercato oggi si trovano processori quadricore a prezzo basso e, pare, anche chipset e motherboard in grado di sfruttare queste caratteristiche in modo più efficiente. Potrebbe non essere lontano il momento in cui alcune delle applicazioni descritte potrebbero girare meglio su sistemi virtualizzati. Microsoft, oltre ai classici strumenti già esistenti per gestire sistemi e aggiornamenti, avrà Windows Server 2008 che è assai più modulare delle versioni precedenti, uscirà con un ipervisore incorporato nel server e ha oggi un sistema di management per i sistemi virtualizzati. E quindi sicuramente ben posizionata per sfruttare queste funzionalità.

Ma per il momento la maggior parte del software, di famosi e meno famosi produttori, a volte non è in grado di lavorare al massimo delle proprie capacità o è addirittura non pienamente supportato su macchine virtuali. E allora io continuo a preferire le macchine fisiche che danno meno problemi. 

6 comments
  1. Diego said:

    La diffusione di server multicore creerà non pochi problemi di prestazioni alle attuali piattaforme applicative perché all’aumentare del numero di cpu è connessa la netta diminuzione della velocità di questi.
    Poiché gli attuali programmi fanno pesantemente leva sui GHz e meno sulla concorrenza, non è infrequente riscontrare prestazioni minori su moderni server quadricore rispetto a “vecchi” sistemi con una sola cpu a 3 GHz. Questo è ancor più evidente quando si tenta la strada della virtualizzazione su processori “lenti”.
    Siamo insomma agli inizi di una nuova rivoluzione pilotata dall’hw a cui il sw dovrà conformarsi trovando nuove, efficenti ed efficaci risposte al vecchio problema del multitasking.

    Diego

  2. Andrea Gumina said:

    Ciao,
    seguo il tuo blog ed è la seconda volta che parli di malfunzionamenti/incompatibilità di software su macchine virtuali. In azienda stiamo sperimentando da un po’ e ne siamo entusiasti: riduzione del numero di server reali necessari (costi, rack, energia elettrica, condizionamento, ecc.), riduzione del tempo di idle, installazione di una macchina che si riduce alla copia di un’immagine già confezionata, in alcuni casi prestazioni confrontabili e così via: puoi immaginare quanto io sia interessato al problema. Tieni conto che non abbiamo mai riscontrato problemi di incompatibilità: virtualizziamo sia Windows che Linux (RedHat, Suse, Ubuntu, Fedora) sia su Windows (2003 server EE SP1), che su Linux che direttamente sulla macchina (hypervisor che gira direttamente sull’hardware). Usiamo concorrenti del software di virtualizzazione che nomini (senza fare pubblicità :-))). Puoi spiegarmi meglio cosa hai riscontrato? Grazie. Ciao.

  3. Max said:

    Dovrei anche io fare pubblicità ma negativa. Comunque abbiamo riscontrato forti problemi di prestazioni e malfunzionamenti generalizzati su alcune applicazioni complesse. Non ultimo è il problema che molti produttori non forniscono assistenza su ambienti virtuali. L’installazione può essere altrettanto veloce utilizzando i sistemi di deploy. Sul risparmio di costi in uno scenario medio sono però scettico (hardware di classe superiore, licenze). Inoltre se tutto funziona senza problemi va bene… ma se cominci ad avere problemi i costi di supporto esplodono.
    Comunque i punti che voglio evidenziare sono due. Il primo è che molte delle cose citate non necessitano di virtualizzazione (può anche essere controproducente). Il secondo è che occorre fare attenzione e non fidarsi troppo. Tieni presente che comunque in azienda abbiamo anche noi virtualizzazione ma solo per alcune applicazioni ben definite e che, quindi, non la escludo a priori. Solo che sotto ho previsto una struttura non virtualizzata (db, app. server, AD, ecc.) su cui insistono molte delle applicazioni virtualizzate.

  4. Capisco il tuo punto di vista: le applicazioni “nevralgiche” su macchine reali, le altre sulle virtualizzate. Concordo sulla necessità di licenze per il software di virtualizzazione (a meno di scendere a patti con l’open source o con le politiche di marketing aggressive che alcuni produttori stanno al momento seguendo). Per hardware più robusto: dipende…
    Non capisco però cosa intendi con “molte delle cose citate non necessitano di virtualizzazione”. Ciao, Andrea.

  5. Max said:

    Ad esempio una struttura in cluster di application server WebSphere non abbisogna di virtualizzazione: le applicazioni J2EE girano su più nodi e l’application server stesso fornisce virtualizzazione delle applicazioni (in senso HTTP soprattutto), scalabilità orizzontale e verticale, bilanciamento e funzioni avanzate di deploy. Idem per le applicazioni .NET su IIS. La stessa cosa si può dire per Domino. SQL Server gestisce multiistanze e ridondanza. E così via.

  6. I’m curious to find out what blog platform you’re utilizing?

    I’m experiencing some minor security issues with my latest website and I would like to find something more secure. Do you have any recommendations?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: