Virtualizzazione in produzione

venerdì 8 agosto 2008 alle 08:12 | Pubblicato su Diario, Installation and Configuration | 3 commenti
Tag: ,

Il commento di  Alessandro al mio ultimo post, “Oracle VM Templates“, mi spinge a scrivere questo post in cui voglio mettere tutte le mie riflessioni, alla luce soprattutto della lunga discussione che c’è stata recentemente sul newsgroup it.lavoro.informatica, intitolata appunto “VMWare Server in produzione“. La domanda di Alessandro (ed il link segnalato) è stata in un certo senso la goccia che ha fatto traboccare il vaso. Stavo cominciando a rispondere quando mi sono reso conto che era meglio dedicassi un’intero post, così da avere anche una maggior visibilità e spero ulteriori testimonianze e “feedback”.

Fino ad uno o forse due anni fa credo che l’idea di utilizzare la tecnologia di virtualizzazione in sistemi di produzione passase per la testa di pochi visionari. Lo testimonia il fatto ad esempio che solo con le ultime versioni dei sistemi operativi “enterprise” (ad esempio SUSE Enterprise Linux 10 o Red Hat 5) è stato incluso XEN. Per quel che ho visto di XEN su Oracle Enterprise Linux 5 posso dire che mancano tutte le caratteristiche per utilizzarlo in un sistema di produzione, si tratta di una alternativa a VMWare Server.

Secondo me, e penso di averlo gia detto, non vi sono validi motivi per utilizzare un sistema basato su VMWare Server o XEN (come è fatto su Oracle Enterprise Linux 5 prima realease, quella che ho provato) in produzione. Comprare macchine più potenti per farci sopra due o più macchine virtuali non è economicamente conveniente ne sicuro, perchè un singolo guasto hardware bloccherebbe non uno ma più sistemi. Il costo delle macchine mi sembra cresca in modo non dico esponenziale, ma certo non lineare con la loro potenza, da qui la considerazione che non sia economicamente conveniente una simile soluzione.  L’amministrazione non si semplifica, perchè le macchine (seppur virtuali) da amministrare sono sempre le stesse, in più c’è un’ulteriore strato, il software di virtualizzazione da amministrare.

In realtà come spiegato da alcuni nella discussione del newsgroup di cui ho parlato sopra, e accennato anche nell’articolo segnalato da Alessandro, i sistemi di virtualizzazione (leggi VMWare, perchè non ci sono altre testimonianze) supportano anche interessanti archittetture per garantire un certo livello di “affidabilità” (HA). A me i concetti sembrano tutti simili a quelli descritti da Oracle per illustrare le caratteristiche di Oracle RAC. Fail Over ecc. ecc.

Non ho avuto modo di approfondire, però in sostanza con VMware ESX  e delle componenti aggiuntive (Vmotion, ecc.) è possibile implementare una  cluster di server, con uno storage condiviso su cui poi si possono creare macchine virtuali, le cui immagini stanno sullo storage condiviso, l’infrastruttura poi è in grado di spostare (a caldo?) le macchine virtuali da un nodo all’altro e per bilanciare il carico e per rispondere ad un guasto hardware su uno dei nodi fisici. A differenza di RAC, mi pare manchi il supporto per l'”attivo-attivo” ovvero più nodi fisici che contemporaneamente servono una macchina virtuale, allo scopo di supportare la scalabilità. Mi sembra una cosa di difficile realizzazione.

Recentemente VMware ha annunciato che anche la versione ESXi del proprio prodotto sarà gratuita (Punto Informatico, 24 Luglio). Questa versione per quel che ho capito è molto diversa dalla versione Server, gia gratuita da un po’, si tratta di un hypervisor,  quindi un prodotto simile a Oracle VM (cioè linux + XEN), cioè un piccolo sistema operativo, con la parte di virtualizzazione.

Su “ili” vengono descritte anche soluzioni meno sofisticate per ottenere un certo livello di HA anche senza infrastrutture harware/software troppo sofisticate.

Oracle e la virtualizzazione

Il documento segnalato da Alessandro, “Oracle Software Runs Best on VMware” è interessante ed a parte i dettagli sulle prestazioni che non sono in grado di verificare mi sembra riporti informazioni corrette. Attenzione però, dipende dall’archittettura che si vuole implementare, da quello si fa con i database Oracle. L’affermazione ” A well-tuned Oracle database will not make excessive demands on I/O and storage” va presa con le pinze, nei miei database, quelli con molti utenti, questo non è vero. Mi ricorda una discussione avuta non molto tempo con un consulente Oracle, che affermava che se l’applicazione provocava molte letture su disco era “mal fatta”. L’affermazione era azzardata secondo me. Un call-center che fa outbound non è che chiama tutti i giorni le stesse persone per parlare tutti i giorni degli stessi ordini. Se poi il cliente ha determinate esigenze la cosa si complica, quindi se ho un database da 200 GB  o ho quei 200/300 GB di cache oppure, per quanto la cache aiuti, faccio un sacco di I/O su disco.

In ogni caso Oracle non pone in primo piano l’HA (high availability) fra le caratteristiche di RAC. In questo senso credo che il discorso fatto d VMware sia basato su un presupposto sbagliato. Certo, RAC in una certa misura offre anche l’HA, ma non è la caratteristica principale. Ad esempio noi lo adottiamo principalmente come soluzione di scalabilità, soprattutto con la versione Standard Edition che permette di mantenere costi decenti. Sul reale vantaggio c’è incertezza, come spiegato da Moans Nogood (visto che lo scrive lui così il suo nome nel suo blog, mi permetto di fare altrettanto per semplificarmi la vita) in un suo post di qualche tempo fa. Qui vi è anche un’altro interessante documento al riguardo. Anche Kevin Closson ne ha parlato: “RAC Adoption …“, andando a vedere i risultati del sondaggio con stupore vedo che il maggior motivo di adozione di RAC è l’HA… ma!?.

Ripeto, il costo delle licenze Oracle RAC Enterprise Edition è notevole e Chen Shapira alcuni mesi fa spiegava come l’opzione DataGuard possa essere più vantaggiosa.

Conclusione

VMware lo ricorda che Oracle ha una precisa politica riguardo il supporto alla virtualizzazione e riporta il numero della nota metalink  (article 249212.1 on Oracle MetaLink). Dipende ovviamente dalle situazioni, ma ritengo che un sistema che ha deciso di basarsi su Oracle e non su alternative più economiche lo fa precisi motivi: assistenza, affidabilità e scalabilità.

Assistenza:

Il vincolo posto da Oracle al supporto dei proprio prodotti in ambiente virtualizzato credo che in alcuni casi sia inaccettabile. Ricordo che in sintesi la nota dice che Oracle fornisce il supporto solo se il problema avuto in ambiente virtuale si riproduce anche in ambiente fisico.

Affidabilità e Scalabilità

Se nonostante tutto si hanno molti piccoli database, in uno stesso “datacenter” (o CED)  piuttosto che fare tante piccole macchine virtuali, forse conviene usare un’unico database. Solitamente non lo si può fare perchè ogni database appartiene a applicazioni diverse ed indipendenti che possono soffrire di problemi di prestazioni. Onde evitare che la causa dei problemi di prestazioni venga scaricata vicendevolmente dai vari fornitori di applicazioni verso gli altri si preferisce mantenere macchine fisiche separate. Lo stesso secondo me vale se si usa un’infrastruttura virtuale, il fornitore dell’applicazione può scaricare la responsabilità sull’infrastruttura e per dimostrare il contrario non bastano le parole di VMware.

3 commenti »

RSS feed for comments on this post. TrackBack URI

  1. In sostanza…
    – ORACLE UFFICIALMENTE NON SUPPORTA VMWARE;
    – ORACLE DICE CHE SE HO UN PROBLEMA DEVO DIMOSTRARE CHE QUESTO ESISTE ANCHE AL
    DI FUORI DELL’AMBIENTE VIRTUALE;
    – ORACLE SUPPORTA NELLA SOLUZIONE SE SI TRATTA DI UN PROBLEMA CONOSCIUTO.

    La cosa poi assolutamente “particolare” è che leggendo la nota 417770.1 “Unbreakable Linux Support Policies For Virtualization And Emulation” si evince che “Operating system supportfor RHEL3 and higher, OEL4 and higher under the Unbreakable Linux Support Program on VMWare” ovvero: c’è il supporto x il SO “marchiato” Oracle e non il DBMS?
    Ciò ha anche un punto di vista logico: siccome Oracle dice che tutto quello che vale per RHEL vale anche per OEL, se RedHat dice che RHEL e’ supported under VMWare, ALLORA anche OEL e’ supported under VMWare…mentre per tutto quello che e’ DBMS o comunque prodotto Oracle la posizione è “VMWare is unsupported” (mentre “incidentalmente” Oracle VM supporta piu’ o meno tutti i prodotti Oracle).
    Forse è tutto più semplice😉 ovvero…Oracle distribuisce una propria soluzione di VM che si chiama OracleVM e spinge su quella.

    Oracle però NON può ( e a mio avviso non dovrebbe) ignorare la tendenza del mercato!

  2. Quello che dici, Sandro, mi sembra giusto. Il fatto è che la mia impressione è che a spingere verso certe decisioni, non è tanto la richiesta del mercato quanto l’offerta della concorrenza. Quindi se la concorrenza comincia a fare pressione anche Oracle si adegua.

  3. un link sull’argomento:

    http://blogs.oracle.com/virtualization/2009/05/oracle_vm_blog_basics_of_oracl.html

    Ciao
    Alessandro


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: