Installazione di OpenStack Glance

In questo articolo installeremo OpenStack Glance, il componente di OpenStack in grado di interfacciarsi con il pool di server Nova per fornire loro le immagini delle macchine virtuali.

Glance può utilizzare diversi datastore per registrare le immagini delle macchine virtuali, tra cui OpenStack Swift; in questo articolo, però, per semplicità, utilizzeremo semplicemente l’hard disk locale. In successivi articoli spiegheremo come far collaborare al meglio assieme i componenti di OpenStack.

Per l’installazione, e consigliabile utilizzare come distribuzione Ubuntu Linux Server 10.10. E’ possibile utilizzare un server separato e ridondarlo, assumiamo però di utilizzare lo stesso cloud controller dell’esempio precedente (172.16.0.1). E’ semper importante eseguire i comandi come utente root

Download ed installazione di Glance

Iniziamo con aggiungere la repository apt ed installare il pacchetto

add-apt-repository ppa:glance-core/trunk
apt-get update
apt-get install glance

Quindi creiamo la directory con il file di configurazione:

cd /etc
mkdir glance
cd glance

Configurazione dei servizi

Creiamo quindi il file glance.conf con la configurazione:

<strong>/etc/glance/glance.conf</strong>
[DEFAULT]
# Show more verbose log output (sets INFO log level output)
verbose = True

# Show debugging output in logs (sets DEBUG log level output)
debug = False

[app:glance-api]
paste.app_factory = glance.server:app_factory

# Directory that the Filesystem backend store
# writes image data to
filesystem_store_datadir=/var/lib/glance/images/

# Which backend store should Glance use by default is not specified
# in a request to add a new image to Glance? Default: 'file'
# Available choices are 'file', 'swift', and 's3'
default_store = file

# Address to bind the API server
bind_host = 0.0.0.0

# Port the bind the API server to
bind_port = 9292

# Address to find the registry server
registry_host = 0.0.0.0

# Port the registry server is listening on
registry_port = 9191

[app:glance-registry]
paste.app_factory = glance.registry.server:app_factory

# Address to bind the registry server
bind_host = 0.0.0.0

# Port the bind the registry server to
bind_port = 9191
# SQLAlchemy connection string for the reference implementation
# registry server. Any valid SQLAlchemy connection string is fine.
# See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine
sql_connection = sqlite:///glance.sqlite

# Period in seconds after which SQLAlchemy should reestablish its connection
# to the database.
#
# MySQL uses a default `wait_timeout` of 8 hours, after which it will drop
# idle connections. This can result in 'MySQL Gone Away' exceptions. If you
# notice this, you can lower this value to ensure that SQLAlchemy reconnects
# before MySQL can drop the connection.
sql_idle_timeout = 3600

Ora aggiungiamo ad /etc/rc.local il seguente comando per avviare glance automaticamente:

/usr/bin/glance-control all start

Altra modifica da effettuare riguarda il file /etc/nova/nova.conf: bisogna levare i riferimenti a nova-objectsore che non sarà più utilizzato e aggiungere quelli relativi a glance:

/etc/nova/nova.conf

Levare:
--s3_host=172.16.0.1

Aggiungere:
--glance_host=172.16.0.1
--glance_port=9292
--image_service=nova.image.glance.GlanceImageService

Per non sprecare risorse inutili, consiglio di levare il servizio glance-objectstore dall’avvio automatico. A questo punto abbiamo finito con le configurazioni e possiamo procedere a riavviare il nostro server.

Utilizzo di Glance

Per utilizzare il servizio glance, è necessario pubblicare le immagini sul server con il comando glance-upload:

wget http://smoser.brickies.net/ubuntu/ttylinux-uec/ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz
tar zxvf ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz
glance-upload --disk-format=ari --container-format=ari --type=ramdisk ttylinux-uec-amd64-12.1_2.6.35-22_1-initrd ramdisk
glance-upload --disk-format=aki --container-format=aki --type=kernel ttylinux-uec-amd64-12.1_2.6.35-22_1-vmlinuz kernel
glance-upload --disk-format=ami --container-format=ami --type=machine --ramdisk=1 --kernel=2 ttylinux-uec-amd64-12.1_2.6.35-22_1.img

Per controllare le istanze, d’ora in poi utilizzaremo direttamente il comando nova. Ad esempio:

nova flavor-list
nova image-list
nova boot pippo --flavor 2 --image 3

It’s all folks, but stay tuned!

Uso di Terminator

Terminator… bel nome no?

Niente a che vedere con il film cult degli anni ‘80, in questo caso parliamo di un pacchetto per Linux che farà la felicità di chi, come me, fa largo uso dell’applicazione “Terminale”.

Una volta intallato il pacchetto attraverso il proprio Application Manager (aptitude, yum, yast, emerge… a seconda della distribuzione) e lanciato, si presenta in maniera molto simile al terminale classico e di primo acchito si può rimanere spiazzati: ma cosa l’ho installato a fare?

Ora provate a spostare la finestra di Terminator su un pannello vuoto del desktop e ad ingrandirla a tutto schermo. Fatto?

Ora provate a premere la combinazione Ctrl-Shift-O: ohhh! E ora esageriamo: Ctrl-Shift-E! E se non ne abbiamo ancora abbastanza Ctrl-Shift-Up/Down/Left/Right!

Per eseguire dei comandi e avere contemporaneamente sott’occhio cosa accade nei log, non c’è di meglio!

Installazione di OpenStack Nova (2)

In questo secondo HowTo eseguiremo una installazione di un nodo computazionale di OpenStack Nova utilizzando Ubuntu Server 10.10 nella versione a 64 bit e un comodo script di autoinstallzione.
Questo HowTo è liberamente tratto da questo articolo.

Per eseguire questo HowTo ammetteremo di aver già installato il cloud controller seguendo le istruzioni del precedente articolo.

Come nel caso precedente, per eseguire i comandi citati in questo articolo, è necessario essere “root”; visto che Ubuntu non consente l’accesso all’utente root, dopo il login utente è necessario lanciare

sudo su -

Innanzi tutto è necessario installare Ubuntu Server base (senza alcun modulo aggiuntivo) sul server, scegliendo la lingua inglese per una questione di compatibilità con lo script di installazione.
Al termine dell’installazione, aggiorniamo il sistema ed installiamo alcuni pacchetti utili per la gestione del server:

apt-get update
apt-get upgrade
apt-get install ssh ntp mc vlan

Utilizzaremo due interfaccie di rete: una “pubblica” attraverso la quale sarà possibile interfacciarsi con le macchine virtuali (eth0 con IP statico 172.16.0.2) e una seconda attraverso la quale il server comunicherà con Internet in dhcp.

<strong>/etc/network/interfaces</strong>
auto eth0
iface eth0 inet static
    address 172.16.0.2
    netmask 255.255.255.0
auto eth1
iface eth1 inet dhcp

A questo punto riavviamo il server:

reboot

Una volta completato il riavvio procediamo al download dello script di installazione e lanciamolo:

wget --no-check-certificate http://www.hybridclouds.co.uk/OSinstall.sh
bash ./OSinstall.sh -A $(whoami) -T compute -C 172.16.0.1

Come nel precedente esempio aggiungiamo il parametro -N nel caso in cui la rete interna “10.0.0.0” contenga la vostra reale rete.
Al termine dell’operazione di installazione non c’è null’altro da configurare e il nodo è già operativo. Per verificare l’effettiva funzionalità, sul Cloud Controller eseguire i comandi:

mysql -uroot -pnova nova -e 'select * from services;'
nova-manage service list

Dovreste vedere il vostro nuovo host aggiunto come “compute node”. Nel caso in cui non abbiate un dns che risolva il nome host del compute node, aggiugetelo nel file hosts:

<strong>/etc/hosts</strong>
172.16.0.1 nova01

Infine sul nuovo compute node andiamo ad allineare il database delle VM con:

nova-manage db sync

L’installazione del sistema è ultimata. Nel caso in cui vogliate aggiungere nuovi nodi al cloud è sufficiente ripetere i passi qui descritti sul nuovo server.

In qualsiasi caso, bisogna sottolineare che in questa installazioni le immagini delle macchine virtuali sono su una directory locale sul cloud controller (/var/lib/nova/images), pertanto non possono essere eseguite su un secondo compute node se non condividendo la directory tramite NFS. Vedremo in un prossimo articolo come utilizzare OpenStack Swift e OpenStack Glance per creare un datastore condiviso per le immagini delle VM.

233 linee di codice fanno la differenza

In alcuni progetti, 233 linee di codice possono essere molte, se però il progetto in questione è il Kernel Linux, 233 linee sono davvero una bazzeccola. Eppure, questa patch di sole 233 linee di codice riuscirà a rendere il kernel Linux più veloce di circa 60 volte nelle applicazioni desktop!

L’idea di questa patch è in realtà dello stesso Linus Torvalds, un plauso allo sviluppatore Mike Galbraith che l’ha messa in pratica: l’idea è di creare automaticamente dei gruppi di processi in base alle periferiche di Input/Output (tty) utilizzate. Questo ordine, permette di abbassare i valori di latenza dei processi di circa 10 volte in caso di intenso carico, rendendo un sistema desktop Linux circa 60 volte più veloce.

Lo stesso creatore del kernel linux ha manifestato il proprio stupore per i benefici introdotti grazie a questa patch attraverso una email.

In questi video si potrà confrontare la velocità di un kernel 2.6.37 con e senza patch applicata: è impressionate, Linux è già il leader nei sistemi server, con un tale miglioramento delle performance Linux potrebbe diventare una solida realtà anche nell’utilizzo in sistemi client!

Installazione di OpenStack Nova (1)

In questo HowTo eseguiremo una installazione di test di OpenStack Nova utilizzando Ubuntu Server 10.10 nella versione a 64 bit e un comodo script di autoinstallzione. Nell’HowTo installeremo innanzi tutto quello che sarà il cloud controller ma che ora fungerà anche da server di calcolo.
Questo HowTo è liberamente tratto da questo articolo.

Il cloud controller è il server che si occupa di gestire il cloud. Per semplicità useremo un unico server con un indirizzo ip statico “pubblico” (172.16.0.1), anche se è ovvio che nel caso di installazioni di cloud in produzione, anche questo server dovrà essere ridondato adeguatamente.

Per eseguire i comandi citati in questo articolo, è necessario essere “root”; visto che Ubuntu non consente l’accesso all’utente root, dopo il login utente è necessario lanciare

sudo su -

Innanzi tutto è necessario installare Ubuntu Server base (senza alcun modulo aggiuntivo) sul server, scegliendo la lingua inglese per una questione di compatibilità con lo script di installazione.
Al termine dell’installazione, aggiorniamo il sistema ed installiamo alcuni pacchetti utili per la gestione del server:

apt-get update
apt-get upgrade
apt-get install ssh ntp mc

Utilizzaremo due interfaccie di rete: una “pubblica” attraverso la quale sarà possibile interfacciarsi con le macchine virtuali (eth0) e una seconda attraverso la quale il server comunicherà con Internet in dhcp. Come già detto, nell’esempio utilizzeremo l’ip 172.16.0.1 per ‘interfaccia “pubblica”:

<strong>/etc/network/interfaces</strong>
auto eth0
iface eth0 inet static
    address 172.16.0.1
    netmask 255.255.255.0
auto eth1
iface eth1 inet dhcp

A questo punto riavviamo il server:

reboot

Una volta completato il riavvio procediamo al download dello script di installazione e lanciamolo:

wget --no-check-certificate http://www.hybridclouds.co.uk/OSinstall.sh
bash ./OSinstall.sh -A $(whoami)

Attenzione: lo script presuppone di installare una rete “privata” per le VM sulla subnet 10.0.0.0/8. Se la vostra rete internet è all’interno della stessa subnet, è necessario modificare il comando di installazione in:

bash ./OSinstall.sh -A $(whoami) -N 192.168.0.0/16

Al termine del processo di installazione, il sistema è completo, per cui procediamo ad un minimo di configurazione in modo da testare il sistema appena installato.

Nel prossimo passo creeremo un nuovo utente, un nuovo progetto e un nuovo certificato per il progetto: l’autenticazione sui progetti di OpenStack avviene sempre utilizzando certificati e non password.

ADMIN=$(whoami)
sudo nova-manage user admin ${ADMIN}
sudo nova-manage project create myproject ${ADMIN}
sudo nova-manage project zipfile myproject ${ADMIN}
mkdir -p cloud/creds
cd cloud/creds
unzip ~/nova.zip
. novarc
cd
euca-add-keypair openstack > ~/cloud/creds/openstack.pem
chmod 0600 cloud/creds/*

OpenStack crea automaticamente delle regole a livello di iptables in modo da bloccare l’accesso via rete alle VM. Creaiamo quindi le regole necessarie per accedere alle nostre VM in SSH e permettere il comando ping:

euca-authorize default -P tcp -p 22 -s 0.0.0.0/0
euca-authorize default -P icmp -t -1:-1

Ora scarichiamo da internet una immagine di test e pubblichiamola sul server:

image="ttylinux-uec-amd64-12.1_2.6.35-22_1.tar.gz"
wget http://smoser.brickies.net/ubuntu/ttylinux-uec/$image
uec-publish-tarball $image mybucket

L’output di quest’ultimo comando sarà simile al seguente:

Fri Mar 18 09:25:56 CET 2011: ====== extracting image ======
kernel : ttylinux-uec-amd64-12.1_2.6.35-22_1-vmlinuz
ramdisk: ttylinux-uec-amd64-12.1_2.6.35-22_1-initrd
image  : ttylinux-uec-amd64-12.1_2.6.35-22_1.img
Fri Mar 18 09:25:56 CET 2011: ====== bundle/upload kernel ======
Fri Mar 18 09:25:58 CET 2011: ====== bundle/upload ramdisk ======
Fri Mar 18 09:26:00 CET 2011: ====== bundle/upload image ======
Fri Mar 18 09:26:03 CET 2011: ====== done ======
emi="ami-771e27bf"; eri="ari-06ab74e9"; eki="aki-604201bc";

Prestare attenzione all’ultima riga: il valore “emi” (ami-771e27bf nel mio caso) è l’identificativo interno della VM. Per avviare la VM, quindi, lanciamo:

euca-run-instances ami-771e27bf -k openstack -t m1.tiny

Sostituendo il primo parametro con il vostro valore di “emi”.
Dopo qualche secondo, lanciamo il seguente comando:

euca-describe-instances
RESERVATION     r-ordxigwy      myproject       default
INSTANCE        i-00000001      ami-771e27bf    192.168.0.3     192.168.0.3    running  openstack (myproject, nova-cc)  0               m1.tiny 2011-03-18T08:26:57Z    nova

Verificare lo stato (running) e l’indirizzo IP assegnato alla macchina (192.168.0.3). Ora verifichiamo l’effettivo funzionamento della VM entrando in SSH dal server:

ssh -i cloud/creds/openstack.pem root@192.168.0.3

Verificato che tutto funzioni regolarmente, usciamo dalla console ssh con

exit

Una VM che “vive” in OpenStack ma alla quale non è possibile accedere dall’esterno può essere utile solo a scopi particolari, ma nella maggior parte dei casi è necessario assegnarle un secondo indirizzo ip “esterno”. Creiamo quindi una nuova subnet all’interno del nostro sistema cloud:

nova-manage floating create cloud1 172.16.0.0/24

e assegnamo alla nostra VM un indirizzo IP “pubblico”:

euca-associate-address -i i-00000001 172.16.0.3

Ora la nostra VM è accessibile anche dall’esterno:

ssh -i cloud/creds/openstack.pem root@172.16.0.3

Ammettiamo ora di avere un PC client linux collegato all’eth0 del cloud con IP 172.16.0.100, ad esempio il PC con il quale avete configurato il sistema. Copiamo quindi i file di autenticazione del progetto su questo PC:

scp -r user@172.16.0.100:cloud/creds .

Lanaciamo nuovamente l’ultimo ssh, questa volta però dal PC client:

ssh -i cloud/creds/openstack.pem root@172.241.0.3

A testimonanza che l’intero progetto è controllabile dall’esterno, lanciamo sul client Linux i seguenti comandi:

sudo apt-get install euca2ools
. cloud/creds/novarc
euca-describe-instances
euca-terminate-instances i-00000001