Report Progetto OpenNebula

Report Progetto OpenNebula
Buzzoni M.#1, Dalpasso N.#2, Limone. G.P.#3 Milioli L.#4
Università degli Studi di Bologna - Dipartimento Scienze dell'Informazione - Laurea Magistrale Informatica a.a. 2011/2012
Bologna, Italia
{marco.buzzoni2, nicola.dalpasso, gianpiero.limone, luca.milioli}@studio.unibo.it
Abstract— Con il presente documento si intende illustrare il
lavoro di installazione e configurazione di una cloud tramite il
software OpenNebula e qemu-kvm come driver di
virtualizzazione.
Keywords— cloud, virtualizzazione, opennebula, jboss, kvm
I. Introduzione
Con il termine Cloud Computing si intende un sistema
distribuito di calcolatori elettronici che fornisce servizi
software tramite il modello commerciale definito “Pay As
You Go”. OpenNebula è un software open-source atto a creare
e gestire una cloud di tipo Infrastructure as a Service (IaaS),
garantendo integrità di lavoro anche nel caso di utilizzo di
macchine eterogenee dal punto di vista hardware e software. I
requisiti previsti dai cluster sono il kernel Linux ed il supporto
hardware alla virtualizzazione.
Attraverso il seguente report verrà presentato come sono
stati utilizzati OpenNebula e qemu-kvm al fine di creare una
piccola cloud. Per quanto riguarda l'applicativo utilizzato nelle
macchine virtuali è stata scelto l'Application Server JBoss.
II. Hardware e Software
L'architettura di OpenNebula prevede la seguente
distinzione tra le varie macchine impiegate: una macchina
master, definita frontend, sulla quale è installato il software
OpenNebula, tramite la quale è gestita l'intera cloud, ed un
insieme di macchine host, sulle quali vengono eseguite le
macchine virtuali. Altre tipologie di macchine possono essere
adibite a scopi specifici, quali la fornitura di file system
condiviso, ad esempio Network File System (NFS).
Di seguito sono elencate le caratteristiche hardware e
software delle macchine utilizzate:
Frontend
• CPU: Intel® T2300 @1.66 GHz
• Memoria: 1GB
• Sistema Operativo: Ubuntu 12.04, 32bit, kernel
GNU/Linux 3.2.0
Host #1
• CPU: Intel® T7300 @2.00 GHz
• Memoria: 4GB
• Sistema Operativo: Ubuntu 12.04, 32bit, kernel
GNU/Linux 3.2.0
Host #2
•
•
•
CPU: Intel® T9400 @2.53 GHz
Memoria: 4GB
Sistema Operativo: LinuxMint 12, 64bit, kernel
GNU/Linux 3.2.0
Le macchine sono tra loro collegate tramite una rete LAN
Ethernet utilizzando indirizzi IP statici; tale scelta è dovuta al
fatto che OpenNebula deve essere in grado di risolvere i nomi
degli host, e questa soluzione prevede il non utilizzo di un
Server DNS.
III. Configurazione Frontend e Host
Frontend e host presentano una configuarzione comune di
base, seguita da modifiche specifiche a seconda dello scopo
d'uso.
A. Configurazione Comune
Gli host ed il frontend sono aggiunti all'infrastruttura di
OpenNebula utilizzando gli hostname delle rispettive
macchine, pertanto ognuno deve essere in grado di risolverne i
nomi; questo può essere fatto, ad esempio, tramite DNS. È
stato seguito un approccio semplice, ma meno flessibile,
aggiungendo le associazioni Indirizzo IP-Hostname all'interno
del file /etc/hosts:
192.168.13.1
192.168.13.2
192.168.13.3
192.168.13.4
gothicdream-fisso
biondo
pc-compaq
gothicdream-notebook
È stato creato l'utente oneadmin con gruppo primario
cloud i cui rispettivi UID e GID devono essere gli stessi in
tutte le macchine. Come home directory è stata utilizzata
/var/lib/one. L'utente oneadmin deve utilizzare come
shell predefinita /bin/bash.
Tra le macchine è stato necessario stabilire una sessione
remota cifrata, tramite protocollo Secure Shell (SSH), creando
le chiavi per l'utente oneadmin:
$ ssh-keygen
$ ssh-copy-id oneadmin@localhost
$ ssh-copy-id oneadmin@otherhost
dove otherhost indica gli altri host.
Anche se non strettamente necessario, per motivi di
configurazione di file, abbiamo concesso tutti i permessi
all'utente oneadmin cambiando il file /etc/sudoers:
oneadmin ALL=(ALL) ALL
C. Configurazione Host
B. Configurazione Frontend
In OpenNebula sono possibili due modalità di installazione
per la macchina frontend: System-wide e Self-contained.
Adottando la prima modalità i file eseguibili, di
configurazione e di log vengono installati nelle posizioni
standard di UNIX; con la seconda trovano posto all'interno di
una directory scelta dall'utente. È stata decisa la Selfcontained, in particolare, utilizzando la home di oneadmin
come directory di installazione.
Tramite compilazione dei sorgenti, sulla macchina frontend
è stato installato il software, aggiornato alla versione 3.4.1, di
Opennebula. Per prima cosa sono stati installati i pacchetti
necessari alla sua compilazione:
$ sudo apt-get install g++ libxmlrpc-c3-dev
scons
libsqlite3-dev
libmysqlclient-dev
libxml2-dev libssl-dev ruby (>= 1.8) sqlite3
ruby-sqlite3
Per la compilazione sono stati eseguiti i seguenti comandi
come utente oneadmin:
$ tar xzf opennebula-3.4.1.tar.gz
$ cd opennebula-3.4.1
$ scons
[ … ]
scons: done building targets.
$ ./install.sh -d /var/lib/one
Per garantire i permessi all'utente oneadmin
nell'esecuzione di macchine virtuali tramite KVM è necessario
aggiungerlo ad i gruppi libvirtd e kvm.
Sono state richieste modifiche a tre file di configurazione
all'interno della cartella /etc/libvirt. Di seguito sono
riportate le modifiche per ciascun file rispetto alla
configurazione predefinita:
1) libvirtd.conf
•
•
•
•
•
listen_tls = 0
listen_tcp = 1
unix_sock_group = "cloud"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0777"
2) lxc.conf
•
•
•
•
log_with_libvirtd = 1
export ONE_LOCATION="/var/lib/one"
export
ONE_AUTH="$ONE_LOCATION/.one/one_auth"
export
ONE_XMLRPC='http://localhost:2633/RPC2'
if [ -d "$ONE_LOCATION/bin" ] ;
then PATH="$ONE_LOCATION/bin:$PATH"
fi
export PATH="/var/lib/gems/1.8/bin":$PATH
È dunque possibile avviare OpenNebula tramite il
comando:
user = "oneadmin"
group = "cloud"
dynamic_ownership = 0
Ulteriori modifiche sono anche state apportate al file
/etc/init/libvirt-bin.conf
aggiungendo
l'opzione -l all'istruzione exec /usr/bin/libvirtd
-d -l.
Un ulteriore requisito per le macchine host è la versione di
ruby che deve essere ≥ 1.8 .
>
Tale
file viene utilizzato pure per le successive
autenticazioni dell'utente amministratore.
Il software necessita il settaggio di particolari variabili
d'ambiente; è stato quindi modificato il file ~/.bashrc :
$ one start
mentre per terminarne l'esecuzione:
$ one stop
$ sudo apt-get install qemu-kvm libvirt-bin
ubuntu-vm-builder bridge-utils
3) qemu.conf
dove -d indica la cartella dove verrà installato OpenNebula.
Di default l'utente e il gruppo che sarà abilitato ad eseguire
OpenNebula sono gli stessi dell'utente che esegue lo script.
OpenNebula prevede un proprio sistema interno di utenti e
gruppi. In questa fase è dunque necessario creare l'utente
amministratore di OpenNebula (da non confondere con
l'utente oneadmin). Le credenziali (username:password) di
tale utente sono fornite direttamente a OpenNebula:
$ mkdir .one
$
echo
"oneadmin2:password2"
~/.one/one_auth
$ chmod 600 ~/.one/one_auth
OpenNebula supporta tre sistemi di virtualizzazione: KVM,
Xen e VMware. Sulle macchine host utilizzate è stato scelto
l'utilizzo di KVM; i pacchetti installati a tale scopo sono:
IV. Software Aggiuntivo
A. OpenNebula Sunstone
Esiste un interfaccia grafica chiamata OpenNebula
Sunstone, ovvero un server web installabile sia su frontend
che su una macchina diversa.
Come requisito è stato installato il pacchetto rubygems
ed eseguito il seguente script:
$ ./share/install_gems sunstone
la cui locazione coincide con la cartella d'installazione.
Rispettivamente, il software si avvia e termina tramite i
comandi:
$ sunstone-server start
$ sunstone-server stop
La porta di default utilizzata è la numero 9869.
B. VNC
È possibile collegarsi alle macchine virtuali di OpenNebula
tramite client Virtual Networ Computing (VNC), ad esempio
utilizzando gtkvncviewer. È inoltre disponibile un client
VNC utilizzabile direttamente all'interno dell'interfaccia di
Sunstone. Prima dell'installazione del client occorre installare
curl, procedendo, infine, con il comando:
$ ./install_novnc.sh
Di default la porta utilizzata dal server VNC è
5900+VMID, dove VMID è l'ID della macchina virtuale in
esecuzione, anche se possibile è specificare manualmente la
porta di ascolto in modo manuale.
pagina
di
benvenuto
situata
in
./welcomecontent/index.html, di cui è stato modificato il
contenuto in vista della presentazione. Digitando l'url
http://localhost:8080 con un browser web (nello specifico
ELinks) è possibile visualizzarla. Per terminare JBoss, nel
caso non sia eseguito in background, è possibile utilizzare
CTRL-C; differentemente è possibile eseguire il comando:
$ ./jboss-cli.sh --connect command=:shutdown
dopo essersi spostati nella cartella bin.
C. NFS
Si tratta di un file system condiviso utile per la live
migration ma non essenziale per le altre funzionalità, per le
quali è sufficiente SSH. Quest'ultimo velocizza le operazioni
locali ma impiega sensibilmente più tempo ad effettuare le
operazioni di deployment e shutdown della macchina virtuale.
Per ragioni di comodità il server NFS può essere installato
anche su un host diverso dal frontend; nello specifico è stato
installato tale server sul frontend stesso. Come cartella
condivisa per NFS è stata scelta /var/lib/one.
Lato Server: dopo aver installato il pacchetto nfskernel-server è necessario effettuare le seguenti
modifiche al file /etc/default/nfs-common:
NEED_IDMAPD=yes
NEED_GSSD=no
ed esportare la cartella /var/lib/one.
A tal fine nel file /etc/exports è stata aggiunta la
riga:
/var/lib/one *(rw,async,no_root_squash,
no_subtree_check,anonuid=2000,anongid=2000)
eseguendo successivamente il comando:
$ sudo exportfs -r
per aggiornare la lista dei filesystem esportati da NFS.
Lato Client: dopo aver installato il pacchetto nfscommon è necessario abilitare IDMAPD modificando il file
nfs-common, come spiegato nel paragrafo relativo al server
NFS. Per montare la cartella si esegue:
$
sudo
mount
-t
nfs
frontend:/var/lib/one /var/lib/one
all'avvio dell'host.
V. Virtualizzazione
A. Immagine Utilizzata
Per creare l'immagine virtuale abbiamo utilizzato la GUI
fornita da Virtual Machine Manager che a sua volta si
appoggia a libvirt. Si è installato il sistema operativo Ubuntu
10.04 Alternate 32 bit privo di GUI su un disco fisso virtuale
di 3GB, lasciando la configurazione di default fornita da
Virtual Machine Manager.
Una volta lanciata l'immagine virtuale è stato scaricato
JBoss (v 7.1) e decompresso l'archivio. Per avviare il server
JBoss si ha eseguito lo script standalone.sh situato nella
sottocartella bin della cartella ottenuta dopo l'estrazione
dell'archivio. Una volta avviato è possibile raggiungere la
B. Importazione dell'immagine virtuale in OpenNebula
L'immagine è stata aggiunta ad OpenNebula tramite
Sunstone. È stata decisa la configurazione di default tranne nel
caso del driver utilizzato per la creazione dell'immagine, per il
quale è stato optato raw, scelta predefinita in Virtual Manager.
La seconda ed ultima modifica consiste nell'abilitazione
della modalità persistente, con la quale le macchine virtuali
utilizzano l'immagine stessa invece di lavorare su una copia di
essa generata dinamicamente. Ciò permette di effettuare
modifiche all'immagine avviandola dalle macchine virtuali di
OpenNebula e di risparmiare il tempo necessario all'avvio
della macchina virtuale per la creazione della copia.
C. Preparazione della macchina virtuale tramite Sunstone
Utilizzando Sunstone è stato creato un template per le
macchine virtuali con la seguente configurazione:
• tipo: KVM
• memoria: 512MB
• disco: immagine precedentemente creata contenente
JBoss
Riguardo a VNC sono stati scelti come indirizzo di ascolto
0.0.0.0 e come porta 5900. Sono stati lasciati i valori di default
per le rimanenti opzioni.
VI. Preparazione Cluster
Sono stati aggiunti gli host (utilizzando come nomi i
rispettivi hostname) al cluster di default di OpenNebula
utilizzando Sunstone, specificando KVM per la
virtualizzazione. È stato lasciato il valore di default per le
rimanenti voci. A questo punto risulta possibile avviare una
macchina virtuale istanziando il template precedentemente
creato.
VII. Problemi e considerazioni
Riguardo la configurazione della rete è stato inizialmente
pensato l'utilizzo di una rete wireless Ad-Hoc, ma ciò non è
stato possibile causa il mancato supporto di tale
configurazione hardware di un host. Un router Ethernet ha
sostituito tale tipologia di rete. Grazie a questo è stato
possibile utilizzare contemporaneamente la configurazione di
rete necessaria per OpenNebula e al contempo utilizzare
l'interfaccia wireless per l'accesso ad internet su tutte le
macchine.
Il corretto funzionamento dell'intera infrastruttura è
totalmente dipendente dalle versioni dei software.
Inizialmente gli host montavano:
• libvirt-bin: v 0.8.3
• qemu-kvm: v 0.16.5
• qemu-utils: v 0.12.5
• qemu-common: v 0.12.5
• OpenNebula. v 2.2.1
e ciò comportava problemi durante il deployment e la
migrazione, live e non, delle macchine virtuali.
Tali problemi sono stati risolti utilizzando le versioni
disponibili da repository per Ubuntu 12.04 e Mint 12:
• libvirt-bin: v 0.9.8
• qemu-kvm: v 1.0
• qemu-utils: v 1.0
• qemu-common: v 1.0
• OpenNebula: v 3.4.1
Esclusivamente durante la live migration è stato riscontrato
un errore risolto in seguito modificando nello script
/var/lib/one/lib/sh/scripts_common.sh
il
valore della variabile SCP da scp a scp -R.
Riferimenti
•
•
•
•
Ubuntu Documentation - "KVM" https://help.ubuntu.com/community/KVM/
Ubuntu Documentation - "SettingUpNFSHowTo" https://help.ubuntu.com/community/SettingUpNFSHowT
o
OpenNebula.org - "OpenNebula Documentation" http://opennebula.org/documentation:rel3.4
JBoss Community – "JBoss Application Server 7" http://www.jboss.org/as7