Dopo aver introdotto OpenStack ed aver effettuato tutte le configurazioni per lanciare la prima istanza in quest’ultimo articolo verrà descritta l’installazione della dashboard, la creazione di istanze personalizzate e l’analisi di alcune problematiche frequenti.

Installazione della dashboard

OpenStack dashboard rappresenta un metodo di accesso alle funzionalità del sistema mediante interfaccia web. L’installazione viene effettuata sulla macchina controller, con due semplici comandi:

root@controller:~# apt-get install memcached libapache2-mod-wsgi openstack-dashboard
root@controller:~# apt-get purge openstack-dashboard-ubuntu-theme

A questo punto l’interfaccia di accesso sarà disponibile all’indirizzo http://controller/horizon:

Da qui sarà possibile amministrare tutte le componenti del sistema:

Le credenziali d’accesso saranno quelle definite nello scorso articolo per l’utente admin.

Creazione e caricamento delle chiavi di accesso

Nello scorso articolo l’unica istanza caricata all’interno del sistema è stata quella relativa a CirrOS, un sistema minimale a cui era possibile accedere mediante credenziali predefinite, ma è chiaramente auspicabile aver la possibilità di utilizzare sistemi più completi e più mirati ad esigenze computazionali complesse.

Prima di lavorare alla creazione di questo tipo di istanze sarà essenziale definire la modalità di accesso ad esse ed a tutte quelle che seguiranno. Tipicamente l’accesso verrà effettuato tramite il servizio ssh, senza conoscere la password dell’utente, ma gestendo un accesso mediante chiave.
Pertanto il primo passo sarà generare una coppia di chiavi adatta a tale scopo:

root@controller:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
7e:c0:60:29:5f:69:a0:9f:39:21:b0:b6:f4:6f:74:8c root@controller
The key's randomart image is:
+--[ RSA 2048]----+
|  .   .          |
|   o . o .       |
|  + + = +        |
| o o * @         |
|  . . E S        |
|     o + .       |
|      o . .      |
|     .   .       |
|                 |
+-----------------+

Generate le chiavi sulla macchina controller queste andranno inserite in nova, in questo modo:

root@controller:~# cd .ssh
root@controller:~/.ssh# nova keypair-add --pub_key id_rsa.pub rasca

Da questo momento in poi la coppia di chiavi farà parte dell’archivio OpenStack:

root@controller:~/.ssh# nova keypair-list
+-------+-------------------------------------------------+
| Name  | Fingerprint                                     |
+-------+-------------------------------------------------+
| rasca | 7e:c0:60:29:5f:69:a0:9f:39:21:b0:b6:f4:6f:74:8c |
+-------+-------------------------------------------------+

Gestione delle istanze

Istanze Ubuntu pre generate

Esistono delle immagini orientate al cloud fornite da Ubuntu e disponibili all’indirizzo http://cloud-images.ubuntu.com/precise/. Scaricando una qualsiasi di queste Ubuntu daily builds la si potrà caricare nell’archivio Glance di OpenStack:

root@controller:~# glance image-create --name=precise --disk-format=raw --container-format=bare --is-public=true --file=images/precise-server-cloudimg-amd64-disk1.img 
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | 9e85c87b51237e65cbe738c4cbfe46ec     |
| container_format | bare                                 |
| created_at       | 2014-11-14T10:13:12                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | raw                                  |
| id               | 988d13ab-61c3-48fb-8d12-5d481daba47a |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | precise                              |
| owner            | 2a039dd0fd424036a9657c971f6d13bf     |
| protected        | False                                |
| size             | 261947904                            |
| status           | active                               |
| updated_at       | 2014-11-14T10:13:14                  |
+------------------+--------------------------------------+

Preparare la propria immagine

L’utilizzo di una istanza general purpose come le Ubuntu Cloud Image ha senso nel momento in cui il suo scopo preliminare non è stato ancora definito, ma quando si ha la necessità di avere istanze mirate e dirette a determinati utilizzi allora può valer la pena generare in autonomia un’immagine.
Lo scopo delle operazioni che seguiranno è quindi quello di creare un’immagine che sia accessibile via ssh e che abbia di default un webserver installato ed abilitato all’avvio (quindi in ascolto sulla porta 80).
Il presupposto è l’utilizzo di uno strumento per la virtualizzazione, in questo caso è stato usato Virtualbox, per installare una Ubuntu Precise (con i pacchetti ssh e apache2) per ottenere un file con estensione vdi contenente la virtual machine.
La ISO con cui il sistema verrà installato è di tipo minimal (questo il link per lo scaricamento), per preservare il più possibile l’occupazione dello spazio. Va infatti ricordato come sia essenziale rendere il più possibile leggere le istanze per favorire la velocità di deploy.
A titolo precauzionale è bene non usare LVM come storage base, non definire swap e non utilizzare nell’installazione schemi di partizionamento particolari: la semplicità aiuta (in tutto). Quindi l’ideale è una sola partizione con un solo disco.
Terminata l’installazione con i presupposti descritti, una volta quindi in possesso del file con estensione vdi, questo andrà copiato sulla macchina controller e convertito in un formato supportato, come qcow2:

root@controller:~# apt-get install libguestfs-tools guestmount
root@controller:~/images# qemu-img convert -f vdi -O qcow2 ubuntu-server-12.4.vdi ubuntu-server-12.4.qcow2

Per ottimizzare l’occupazione dello spazio si configura il disco in modalità sparse:

root@controller:~/images# virt-sparsify ubuntu-server-12.4.qcow2 ubuntu-server-12.4-sparse.qcow2
Create overlay file to protect source disk ...
Examine source disk ...
 100% [###################################################################################################################################] --:--
Fill free space in /dev/vda1 with zero ...
 100% [###################################################################################################################################] --:--
Copy to destination and make sparse ...

Sparsify operation completed with no errors.  Before deleting the old 
disk, carefully check that the target disk boots and works correctly.
root@controller:~/images# mv ubuntu-server-12.4-sparse.qcow2 ubuntu-server-12.4.qcow2

A questo punto il file immagine può essere preparato per l’esecuzione automatica in OpenStack, con questo comando:

root@controller:~/images# virt-sysprep -a ubuntu-server-12.4.qcow2
W: kvm binary is deprecated, please use qemu-system-x86_64 instead
W: kvm binary is deprecated, please use qemu-system-x86_64 instead

La ragione di questo step è quella di rimuovere file che non permettano la personalizzazione della macchina dinamica (regole udev, file temporanei, impostazioni personalizzate e via dicendo). Il disco dell’immagine potrà essere così montato:

root@controller:~/images# modprobe nbd max_part=63
root@controller:~/images# qemu-nbd -c /dev/nbd0 ubuntu-server-12.4.qcow2 
root@controller:~/images# mount /dev/nbd0 /mnt
nbd0    nbd0p1  nbd0p2  
root@controller:~/images# mount /dev/nbd0p2 /mnt
root@controller:~/images# ls /mnt/
bin  boot  dev  etc  home  initrd.img  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var  vmlinuz

In modo da poter controllare che non esistano file udev specifici:

root@controller:~/images# ls -la /mnt/etc/udev/rules.d/
totale 16
drwxr-xr-x 2 root root 4096 nov 17 16:29 .
drwxr-xr-x 3 root root 4096 nov 17 15:55 ..
-rw-r--r-- 1 root root  832 nov 17 15:27 70-persistent-cd.rules
-rw-r--r-- 1 root root 1157 ott 11  2012 README

E che la rete abbia le impostazioni dinamiche:

root@controller:~/images# cat /mnt/etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

L’immagine può infine essere caricata in Glance:

root@controller:~/images# glance image-create --name=precise-web --disk-format=qcow2 --container-format=bare --is-public=true --file=ubuntu-server-12.4.qcow2 
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | 6a3a315b0798a122f077519c503e5339     |
| container_format | bare                                 |
| created_at       | 2014-11-17T17:01:42                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 0498bb06-b544-41ba-b488-dd10cde34d53 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | precise-web                          |
| owner            | 2a039dd0fd424036a9657c971f6d13bf     |
| protected        | False                                |
| size             | 1096679424                           |
| status           | active                               |
| updated_at       | 2014-11-17T17:01:50                  |
+------------------+--------------------------------------+
root@controller:~/images# nova image-list
+--------------------------------------+-------------+--------+--------+
| ID                                   | Name        | Status | Server |
+--------------------------------------+-------------+--------+--------+
| c5b27268-f703-4180-bf19-b24b0d662156 | cirros      | ACTIVE |        |
| 0498bb06-b544-41ba-b488-dd10cde34d53 | precise-web | ACTIVE |        |
+--------------------------------------+-------------+--------+--------+

E quindi avviata:

root@controller:~/images# nova boot --flavor 2 --key_name rasca --image 6272a832-8690-4a67-8199-7c137cb76af4 --security_group default Precise-web-1
+--------------------------------------+--------------------------------------+
| Property                             | Value                                |
+--------------------------------------+--------------------------------------+
| OS-EXT-STS:task_state                | scheduling                           |
| image                                | precise-web                          |
| OS-EXT-STS:vm_state                  | building                             |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000024                    |
| OS-SRV-USG:launched_at               | None                                 |
| flavor                               | m1.small                             |
| id                                   | bdfa24b7-0159-4f48-a893-609beae0bd3a |
| security_groups                      | [{u'name': u'default'}]              |
| user_id                              | 7387de194bf64179bd65fb7e88f1b3f8     |
| OS-DCF:diskConfig                    | MANUAL                               |
| accessIPv4                           |                                      |
| accessIPv6                           |                                      |
| progress                             | 0                                    |
| OS-EXT-STS:power_state               | 0                                    |
| OS-EXT-AZ:availability_zone          | nova                                 |
| config_drive                         |                                      |
| status                               | BUILD                                |
| updated                              | 2014-11-17T21:47:58Z                 |
| hostId                               |                                      |
| OS-EXT-SRV-ATTR:host                 | None                                 |
| OS-SRV-USG:terminated_at             | None                                 |
| key_name                             | rasca                                |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | None                                 |
| name                                 | Precise-web-1                        |
| adminPass                            | WZgrr53su4RF                         |
| tenant_id                            | 2a039dd0fd424036a9657c971f6d13bf     |
| created                              | 2014-11-17T21:47:58Z                 |
| os-extended-volumes:volumes_attached | []                                   |
| metadata                             | {}                                   |
+--------------------------------------+--------------------------------------+

Seguendo poi sul nodo compute lo sviluppo dell’istanza:

root@compute1:~# grep bdfa24b7-0159-4f48-a893-609beae0bd3a /var/log/nova/nova-compute.log
2014-11-17 22:48:00.623 1461 AUDIT nova.compute.manager [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Starting instance...
2014-11-17 22:48:00.987 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Attempting claim: memory 2048 MB, disk 20 GB, VCPUs 1
2014-11-17 22:48:00.988 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Total Memory: 7896 MB, used: 3072.00 MB
2014-11-17 22:48:00.988 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Memory limit: 11844.00 MB, free: 8772.00 MB
2014-11-17 22:48:00.989 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Total Disk: 908 GB, used: 21.00 GB
2014-11-17 22:48:00.989 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Disk limit not specified, defaulting to unlimited
2014-11-17 22:48:00.989 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Total CPU: 4 VCPUs, used: 2.00 VCPUs
2014-11-17 22:48:00.990 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] CPU limit not specified, defaulting to unlimited
2014-11-17 22:48:00.990 1461 AUDIT nova.compute.claims [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Claim successful
2014-11-17 22:48:01.791 1461 INFO nova.virt.libvirt.driver [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Creating image
2014-11-17 22:50:19.728 1461 INFO nova.virt.libvirt.driver [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Injecting key into image 6272a832-8690-4a67-8199-7c137cb76af4
2014-11-17 22:50:21.447 1461 INFO nova.virt.libvirt.firewall [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Called setup_basic_filtering in nwfilter
2014-11-17 22:50:21.448 1461 INFO nova.virt.libvirt.firewall [req-a3a6ae3e-4cef-4d9a-8a8e-851a7db8912a 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Ensuring static filters
2014-11-17 22:50:22.804 1461 INFO nova.compute.manager [-] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] During sync_power_state the instance has a pending task. Skip.
2014-11-17 22:50:22.829 1461 INFO nova.compute.manager [-] Lifecycle event 0 on VM bdfa24b7-0159-4f48-a893-609beae0bd3a
2014-11-17 22:50:22.876 1461 INFO nova.virt.libvirt.driver [-] [instance: bdfa24b7-0159-4f48-a893-609beae0bd3a] Instance spawned successfully.

In questo caso l’istanza è stata caricata, sono state caricate le chiavi dichiarate in precedenza (Injecting key into image 6272a832-8690-4a67-8199-7c137cb76af4) e sarà quindi infine possibile loggarsi:

root@controller:~# ssh root@10.0.0.2
Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.5.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
Last login: Mon Nov 17 22:52:25 2014 from 10.0.0.51

Per controllare che i servizi definiti siano attivi e raggiungibili:

root@ubuntu:~# netstat -ntlp
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      666/apache2     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      585/sshd        
tcp6       0      0 :::22                   :::*                    LISTEN      585/sshd    

Chiaramente la porta 80 non sarà accessibile finché non verrà esplicitamente abilitata mediante la componente di rete nova:

root@controller:~# nova secgroup-add-rule default tcp 80 80 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 80        | 80      | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+

Da questo momento in poi, il webserver diverrà accessibile:

root@controller:~# nc -v 10.0.0.2 80
Connection to 10.0.0.2 80 port [tcp/http] succeeded!

Deploy massivo di istanze

A questo punto l’ideale per dimostrare la valenza di quanto creato sarà quella di mettere a ferro e fuoco le componenti. Nella simulazione descritta è stato aggiunto un nuovo nodo compute, seguendo le specifiche illustrate nell’articolo precedente, mediante il quale verranno sviluppate in massa le istanze, partendo dal nodo controller, con questo comando:

root@controller:~# for i in `seq 1 8`; do nova boot --flavor 2 --key_name rasca --image 0cbb400d-d7f7-4c7d-8236-b7cfd7b0ed2f --security_group default Precise-web-$i; done

Il comando descritto effettua il deploy di 8 istanze, suddivise nei 2 nodi compute. Seguendo lo sviluppo delle istanze questo passerà da None a spawning…

root@controller:~# nova list
+--------------------------------------+---------------+--------+------------+-------------+----------------+
| ID                                   | Name          | Status | Task State | Power State | Networks       |
+--------------------------------------+---------------+--------+------------+-------------+----------------+
| 65fb6514-8165-48f4-a8fb-0db6e4adfb10 | Precise-web-1 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.2 |
| b54c2eaa-175d-4a7c-a582-cfe112a7973e | Precise-web-2 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.3 |
| a905069d-21ba-45e8-9c7f-9401fb210ff7 | Precise-web-3 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.4 |
| 3da64d37-617c-465e-a819-b5e377124769 | Precise-web-4 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.5 |
| 4c5b49df-8d6a-487a-a1eb-e9a3c936eeef | Precise-web-5 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.6 |
| 2bc699d3-2d58-478c-8493-efcf48922a16 | Precise-web-6 | BUILD  | spawning   | NOSTATE     | vmnet=10.0.0.7 |
| 3f2129bf-1362-4670-a5ca-2c37c6b69bd6 | Precise-web-7 | BUILD  | spawning   | NOSTATE     |                |
| 18176d98-3af5-44f1-b102-22b2d823db76 | Precise-web-8 | BUILD  | None       | NOSTATE     |                |
+--------------------------------------+---------------+--------+------------+-------------+----------------+

A running:

root@controller:~# nova list
+--------------------------------------+---------------+--------+------------+-------------+----------------+
| ID                                   | Name          | Status | Task State | Power State | Networks       |
+--------------------------------------+---------------+--------+------------+-------------+----------------+
| 65fb6514-8165-48f4-a8fb-0db6e4adfb10 | Precise-web-1 | ACTIVE | None       | Running     | vmnet=10.0.0.2 |
| b54c2eaa-175d-4a7c-a582-cfe112a7973e | Precise-web-2 | ACTIVE | None       | Running     | vmnet=10.0.0.3 |
| a905069d-21ba-45e8-9c7f-9401fb210ff7 | Precise-web-3 | ACTIVE | None       | Running     | vmnet=10.0.0.4 |
| 3da64d37-617c-465e-a819-b5e377124769 | Precise-web-4 | ACTIVE | None       | Running     | vmnet=10.0.0.5 |
| 4c5b49df-8d6a-487a-a1eb-e9a3c936eeef | Precise-web-5 | ACTIVE | None       | Running     | vmnet=10.0.0.6 |
| 2bc699d3-2d58-478c-8493-efcf48922a16 | Precise-web-6 | ACTIVE | None       | Running     | vmnet=10.0.0.7 |
| 3f2129bf-1362-4670-a5ca-2c37c6b69bd6 | Precise-web-7 | ACTIVE | None       | Running     | vmnet=10.0.0.8 |
| 18176d98-3af5-44f1-b102-22b2d823db76 | Precise-web-8 | ACTIVE | None       | Running     | vmnet=10.0.0.9 |
+--------------------------------------+---------------+--------+------------+-------------+----------------+

Il deploy è quindi terminato. Per capire se l’operazione ha avuto successo due condizioni dovranno essere rispettate:

1) che si possa accedere alle istanze via ssh:

root@controller:~# for hostn in `seq 2 9`; do ssh root@10.0.0.$hostn uptime; done
 18:46:14 up 4 min,  0 users,  load average: 0.00, 0.01, 0.01
 18:46:15 up 4 min,  0 users,  load average: 0.01, 0.06, 0.04
 18:46:14 up 3 min,  0 users,  load average: 0.01, 0.06, 0.04
 18:46:16 up 3 min,  0 users,  load average: 0.01, 0.06, 0.04
 18:46:16 up 3 min,  0 users,  load average: 0.08, 0.03, 0.01
 18:46:15 up 3 min,  0 users,  load average: 0.02, 0.07, 0.05
 18:46:16 up 3 min,  0 users,  load average: 0.01, 0.04, 0.03
 18:46:15 up 3 min,  0 users,  load average: 0.00, 0.01, 0.01

2) che il servizio http sia accessibile:

root@controller:~# for hostn in `seq 2 9`; do nc -v -w1 10.0.0.$hostn 80; done
Connection to 10.0.0.2 80 port [tcp/http] succeeded!
Connection to 10.0.0.3 80 port [tcp/http] succeeded!
Connection to 10.0.0.4 80 port [tcp/http] succeeded!
Connection to 10.0.0.5 80 port [tcp/http] succeeded!
Connection to 10.0.0.6 80 port [tcp/http] succeeded!
Connection to 10.0.0.7 80 port [tcp/http] succeeded!
Connection to 10.0.0.8 80 port [tcp/http] succeeded!
Connection to 10.0.0.9 80 port [tcp/http] succeeded!

Visto che entrambe le condizioni sono rispettate, la missione può dirsi compiuta. A cose fatte quindi le istanze potranno essere rimosse:

root@controller:~# nova list | tail -n +4 | awk '{print $2}' | head -n -1 | while read instance; do nova delete $instance; done

Ciò che non rende l’idea di quanto scritto sono i tempi. I sistemi sono dei semplici Intel I3 con 8 GigaByte di RAM e dal lancio del comando all’operatività effettiva (quindi il momento in cui la porta 80 delle istanze diventa accessibile) passano tra i 20 e i 30 secondi.

Problemi ricorrenti

Nel caso di problemi con la riuscita delle varie fasi vale la regola di sempre: consultare i log. Considerato il numero delle componenti impiegate la possibilità di errore è molto alta ed è solo dai log che si possono ottenere le informazioni utili alla soluzione delle problematiche.

Se la chiave generata non funziona

Al termine di ogni deploy nova cerca di caricare le chiavi all’interno del file /root/.ssh/authorized_keys della macchina virtuale, se questo non funziona all’interno del file /var/log/nova/nova-compute.log si potranno trovare errori di questo tipo:

2014-02-14 11:19:08.037 1456 WARNING nova.virt.disk.api [req-4d15bb42-dfc6-4bcc-bd60-078dff05dc35 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] Ignoring error injecting data into image (Error mounting /var/lib/nova/instances/8bfb118a-ac1c-4634-9ec6-a6388693b4ba/disk with libguestfs (external command failed, see earlier error messages))

In questo caso può essere che si sistemi non siano presenti i pacchetti relativi a libguestfs (ossia libguestfs0), oppure che per qualche ragioni le chiavi non siano accessibili, perciò andrà ripetuto il processo di caricamento.

Se il deploy di un’istanza fallisce con error

Se al termine del deploy l’istanza è in questo stato:

+--------------------------------------+-----------+---------+------------+-------------+----------------+
| ID                                   | Name      | Status  | Task State | Power State | Networks       |
+--------------------------------------+-----------+---------+------------+-------------+----------------+
| 59f12b43-edd2-4958-b4cf-4a6fed4a506c | Precise-1 | ERROR   | None       | NOSTATE     | vmnet=10.0.0.3 |
+--------------------------------------+-----------+---------+------------+-------------+----------------+

E’ possibile controllare nei log del compute node cosa è andato storto:

2014-02-14 11:13:43.427 1456 ERROR nova.compute.manager [req-c848d346-8ad6-4653-a99a-ff25ac1a0447 7387de194bf64179bd65fb7e88f1b3f8 2a039dd0fd424036a9657c971f6d13bf] [instance: 59f12b43-edd2-4958-b4cf-4a6fed4a506c] Error: Instance type's disk is too small for requested image.

In questo caso quindi il flavor selezionato per l’immagine è troppo piccolo rispetto a quanto necessario dall’immagine.

Oppure

2014-11-23 17:35:11.097 1466 TRACE nova.compute.manager [instance: be1c09b7-3712-4336-a45e-1a022297ea37] Timeout: Timeout while waiting on RPC response - topic: "network.compute1", RPC method: "allocate_for_instance" info: ""

in questo caso invece è verosimile che sia necessario riavviare l’hypervisor.

Se le istanze non utilizzano le estensioni hardware per la virtualizzazione

E’ possibile che host con supporto nativo alle estensioni di virtualizzazione eroghino in realtà macchine che emulano il processore. Ci si accorge di questo aspetto andando a visualizzare i dettagli della macchina virtuale sui nodi compute, partendo dall’elenco:

root@compute1:~# virsh list
 Id    Nome                           Stato
----------------------------------------------------
 16    instance-00000078              in esecuzione
 17    instance-0000007a              in esecuzione
 18    instance-0000007c              in esecuzione
 19    instance-0000007e              in esecuzione

E visualizzando i dettagli di un’istanza:

root@compute1:~# virsh dumpxml instance-00000078 | grep "domain type"

Se il nodo compute non sta usando l’accellerazione hardware fornita da KVM le istanze lanciate avranno:

Anziché:

Per ovviare al problema sarà necessario inserire all’interno del file /etc/nova/nova.conf dei nodi compute la riga:

libvirt_type=kvm.

Conclusioni

Si conclude così questa serie di articoli introduttivi ad OpenStack. Lungi dall’essere esaustiva, questa serie si pone come obiettivo quello di offrire spunti da cui far partire i propri studi ed i propri progetti. La fortuna di seguire progetti come OpenStack è quella di avere a disposizione un’enorme panorama di strumenti (e relativa documentazione), il cui limite è unicamente il tempo che vi si può dedicare.

La serie

Ecco tutti gli articoli della serie “OpenStack, appunti di viaggio“:

• Parte prima: introduzione
• Parte seconda: configurazione ambiente operativo
• Parte terza: dashboard e deploy massivo di istanze personalizzate