Slides

Cloud Controller: descrizione,
installazione e test
Matteo Manzali
(INFN CNAF - Università degli Studi di Ferrara)
Formazione MCloud WP1 – Ancona 18-19 Marzo 2013
Schema generale
•  Nell’infrastruttura prototipale MCloud
vengono individuati 4 macro componenti:
§ 
§ 
§ 
§ 
Dashboard (Horizon)
Image (Glance)
Identity (Keystone)
Compute (Nova)
•  Oggi ci occuperemo del
macro componente Compute.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
2
I princìpi di OpenStack
•  L’architettura Openstack si basa sui concetti di sharednothing e messaging-based.
•  Tutti i componenti possono essere eseguiti su server distinti
(Cloud Controller, Compute Node, Volume Controller,
Network Controller, Image Server, Identity Service).
•  Per evitare di bloccare ogni componente mentre è in attesa
di una risposta, i componenti di Openstack usano chiamate
asincrone.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
3
Comunicazione tra i vari
componenti OpenStack
•  La comunicazione tra i macro componenti (Compute,
Dashboard, Image, Identity) avviene via HTTP attraverso le
API che i componenti mettono a disposizione.
•  La comunicazione tra i componenti che compongono la
parte Compute avviene via AMQP (Advanced Message
Queue Protocol), ovvero un protocollo per lo scambio di
messaggi attraverso delle code.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
4
I componenti di Nova (1)
•  L’API server riceve le richieste dell’utente e le manda al
Cloud Controller.
•  Il Cloud Controller è il nodo centrale del sistema ed
interagisce con tutti gli altri componenti attraverso code di
messaggi.
•  L’Authorization Manager fornisce servizi di autenticazione
ed autorizzazione, in alternativa può essere usato l’Identity
Service (keystone) come servizio di autenticazione
separato (come nel caso dell’infrastruttura pilota).
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
5
I componenti di Nova (2)
•  Lo Scheduler sceglie il Compute Node su cui lanciare
una istanza.
•  Il Compute Node fornisce risorse di calcolo e permette
l’istanziazione delle macchine virtuali.
•  Il Network Controller permette alle macchine virtuali di
interagire con i Compute Nodes e con la rete esterna.
•  Il Volume Controller fornisce uno storage veloce e
permanente per i Compute Nodes.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
6
I componenti di Nova (3)
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
7
I componenti di Nova (4)
•  Per capire come i componenti appena citati lavorano
essieme, seguiamo il flusso di lavoro causato dalla
richiesta di istanziazione di una macchina virtuale:
§  Il server API riceve il comando di lanciare una nuova istanza
§  Il server API controlla se l’utente è autorizzato (interrogando
l’authorization manager) e manda la richiesta al Cloud Controller (1)
§  Il Cloud Controller manda la richiesta allo Scheduler (2)
§  Lo scheduler designa un Compute Node e gli comunica di avviare una
nuova istanza (3,4)
§  Il Compute Node ha bisogno di un IP per lanciare la nuova istanza, quindi
manda un messaggio al Network Controller (5,6,7,8)
§  Il Compute Node conclude l’istanziazione della nuova macchina virtuale
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
8
I servizi di Nova (1)
•  nova-api: accetta e risponde alle richieste di computazione da parte degli
utenti. Supporta le API Compute di OpenStack, EC2 di Amazon e delle
speciali API Admin per permettere ad utenti privilegiati di effettuare
operazioni di amministrazione.
•  nova-compute: è principalmente un demone che crea e termina le istanze di
macchine virtuali attraverso le API dell’hypervisor (XenAPI per XenServer/
XCP, libvirt per KVM o QEMU, VMwareAPI per VMware, ecc...). Preleva i
task da una coda, esegue i comandi di sistema relativi al task prelevato
(come lanciare una istanza KVM) ed aggiorna nel database lo stato delle
operazioni effettuate.
•  nova-network: questo demone è simile a nova-compute. Preleva da una coda
i task riguardanti la rete ed esegue i comandi di sistema necessari (come
creare un’interfaccia di rete virtuale oppure modificare le regole di iptables).
Queste funzionalità è stata migrata in Quantum, un nuovo componente di
OpenStack.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
9
I servizi di Nova (2)
•  nova-schedule: preleva da una coda una richiesta di creazione di una macchina
virtuale e determina quale hypervisor deve svolgere l’operazione.
•  nova-volume: preleva da una coda le richieste relative ai volumi (creazione,
eliminazione, associazione o deassociazone) ed esegue le operazioni
necessarie.
•  qpid: implementa le code, ovvero fornisce un hub centrale per lo scambio di
messaggi tra i demoni di OpenStack. In alternativa a qpid può essere usato
RabbitMQ o ZeroMQ.
•  MySQL: contiene tutte le informazioni riguardo lo stato attuale dei componenti
OpenStack, ovvero informazioni riguardo le istanze, le reti, i progetti, ecc…
Nova supporta tutti i tipi di database supportati da SQL-Alchemy.
•  Nova inoltre fornisce servizi per permettere all’utente di accedere alla propria
macchina virtuale attraverso un proxy. Questo meccanismo coinvolge diversi
demoni (nova-console, nova-novncproxy e nova-consoleauth).
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
10
Rapporto tra componenti e
servizi
Cloud Controller
Compute Node
Network Controller
Scheduler
Volume Controller
à
à
à
à
à
qpid
nova-compute
nova-network
nova-schedule
nova-volume
•  Come Authorization Manager useremo Keystone, chè è già stato
installato e configurato per Nova.
•  Il database MySQL è comune a tutti i servizi Nova, può esserci un
database condiviso oppure un database per singolo servizio.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
11
Distribuzione dei componenti
•  Come già anticipato, i componenti di OpenStack sono
stati pensati per poter essere installati ciascuno su un
server differente.
•  Questo permette sia un’alta flessibilità e scalabilità.
•  Solitamente i Compute Node vengono posti su server
dedicati, ovvero server il cui unico scopo è quello di
essere degli hypervisors.
•  I restanti componenti possono essere posti su un unico
server oppure distribuiti su più server.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
12
Architettura dell’infrastruttura
per la formazione
•  Avendo a disposizione due server (di cui uno virtuale), i
componenti della parte Compute verranno installati come
segue:
§  Tutti i componenti, eccetto il Compute Node, sul primo server
(dove sono stati installati anche Keystone e Glance)
§  Il Compute Node sul secondo server (che funge solamente da
hypervisor)
§  Come database verrà utilizzato il database mysql installato per
Keystone e già usato anche da Glance
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
13
Iniziamo con l’installazione
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
14
Configurazione del database
•  Collegarsi a MySQL da linea di comando con:
# mysql -u root -p
E digitare la password di root.
•  Creare il DB "nova”:
mysql> CREATE DATABASE nova;
•  Creare l'utente "nova" che ha completo accesso al DB appena creato:
mysql> GRANT ALL ON nova.* TO 'nova'@'%' IDENTIFIED BY
'<YOUR_NOVADB_PASSWORD>';
Dove <YOUR_NOVADB_PASSWORD> è la password scelta
per l'utente "nova" del DB.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
15
Installazione dei servizi
•  Installare il server di messaging queue. Su Fedora, RHEL e
CentOS il server di messaging maggiormente testato è Apache
Qpid:
# yum install openstack-utils memcached qpid-cpp-server
•  Installare i pacchetti di nova e le dipendenze verranno installate
automaticamente:
# yum install openstack-nova
•  Far partire il servizio qpidd e configurarlo affinchè si avvi al
boot del server:
# /etc/init.d/qpidd start
# chkconfig qpidd on
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
16
Disabilitazione servizi e
cambio owner di nova
•  Il servizio openstack-nova-metadata-api va in conflitto con il servizio openstack-novaapi , quindi è conveniente disabilitarlo, inoltre non si vuole che il Cloud
Controller funga da Compute Node, quindi disabilitiamo anche il servizio
openstack-nova-compute .
•  Nei files /etc/init.d/openstack-nova-metadata-api e /etc/init.d/openstack-nova-compute
modificare la funzione start() come segue:
[...]
start() {
echo "This service must be stopped!"
exit
[...]
•  Cambiare il proprietario della cartella nova:
# chown -R nova:nova /etc/nova
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
17
Modifiche file nova.conf (1)
•  Sostituire il contenuto del file /etc/nova/nova.conf con:
[DEFAULT]
logdir = /var/log/nova
state_path = /var/lib/nova
lock_path = /var/lib/nova/tmp
verbose = False
# kvm
compute_driver = libvirt.LibvirtDriver
libvirt_type = kvm
libvirt_nonblocking = True
libvirt_inject_partition = -1
libvirt_xml_template = /usr/share/nova/libvirt.xml.template
# authentication
auth_strategy = keystone
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
18
Modifiche file nova.conf (2)
# network manager
network_manager = nova.network.manager.FlatDHCPManager
force_dhcp_release = False
dhcp_lease_time = 120
dhcpbridge = /usr/bin/nova-dhcpbridge
dhcpbridge_flagfile = /etc/nova/nova.conf
firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
my_ip = <THIS_SERVER_IP>
fixed_range = <PRIVATE_NETWORK>
public_interface = eth0
flat_network_bridge = virbr0
flat_interface = eth0
multi_host = True
auto_assign_floating_ip = False
injected_network_template = /usr/share/nova/interfaces.template
allow_same_net_traffic=true
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
19
Modifiche file nova.conf (3)
# sql
sql_connection = mysql://
nova:<PASSWORD_UTENTE_DB_NOVA>@<DB_SERVER_IP>/nova
# no vnc console
vnc_enabled = True
vncserver_listen = 0.0.0.0
vncserver_proxyclient_address = <THIS_SERVER_IP>
novncproxy_base_url=http://<VNC_SERVER_IP>:6080/vnc_auto.html
xvpvncproxy_base_url=http://<VNC_SERVER_IP>:6081/console
# qpid
qpid_hostname = <QPID_SERVER_IP>
rpc_backend = nova.rpc.impl_qpid
# volumes
volume_group = nova-volumes
iscsi_helper = tgtadm
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
20
Modifiche file nova.conf (4)
# glance
image_service=nova.image.glance.GlanceImageService
glance_api_servers=<GLANCE_SERVER_IP>:9292
cache_images=true
# other
vpn_client_template = /usr/share/nova/client.ovpn.template
credentials_template = /usr/share/nova/novarc.template
rootwrap_config = /etc/nova/rootwrap.conf
remove_unused_base_images = True
# quota
quota_cores=20
quota_instances=20
max_cores=24
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
21
Modifiche file nova.conf (5)
•  Dove:
§  <PASSWORD_UTENTE_DB_NOVA> è la password dell'utente "nova" del DB
"nova" del Cloud Controller
§  <THIS_SERVER_IP> è l'IP del server che si sta configurando
§  <DB_SERVER_IP> è l’IP del server che ospita il database
§  <VNC_SERVER_IP> è l’IP del server che ospita il servizio VNC
§  <QPID_SERVER_IP> è l’IP del server che ospita il servizio qpid
§  <GLANCE_SERVER_IP> è l’IP del server che ospita il servizio Glance
§  <PRIVATE_NETWORK> è la rete i cui IP che possono essere assegnati alle
macchine virtuali (192.168.121.0/24 oppure 192.168.122.0/24, in base al gruppo)
§  nel parametro flat_network_bridge "virbr0" è l'interfaccia di rete virtuale del server
che si sta configurando e si appoggia all'interfaccia fisica eth0 (specificata nel
parametro flat_interface)
§  Nel parametro public_interface “eth0” è l’interfaccia di rete su cui stanno gli IP
pubblici (floating IP)
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
22
Modifiche file api-paste.ini
•  Modificare la parte finale del file /etc/nova/api-paste.ini con:
[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_host = <KEYSTONE_SERVER_IP>
service_port = 5000
auth_host = <KEYSTONE_SERVER_IP>
auth_port = 35357
auth_protocol = http
auth_uri = http://<KEYSTONE_SERVER_IP>:5000/
admin_tenant_name = service
admin_user = nova
admin_password = <NOVA_PASS>
•  Dove:
§  <KEYSTONE_SERVER_IP> è l’IP del server che ospita il servizio Keystone
§  <NOVA_PASS> è la password associata all'utente del servizio Nova in Keystone
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
23
Avvio automatico servizi e
sincronizzazione del DB
•  Impostare l'avvio automatico dei servizi nova, tranne i servizi
appena disabilitati:
# for svc in api console network scheduler cert consoleauth volume \
objectstore xvpvncproxy; do chkconfig openstack-nova-$svc on; done
•  Fermare i servizi nova, sincronizzare il database e far ripartire i
servizi:
# for s in `ls /etc/init.d/openstack-nova-*`; do $s stop ; done
# nova-manage db sync
# for s in `ls /etc/init.d/openstack-nova-*`; do $s start ; done
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
24
Bug fix eliminazione volumi
•  A causa di un bug, quando si prova ad eliminare un volume di
Nova da Dashboard o da CLI, le risorse del sistema vengono
monopolizzate da un singolo processo a causa dell'esecuzione
di un dd sul volume che si intende cancellare.
•  La causa scatenante è la non appartenenza dell'utente nova
(utente con cui viene lanciato il dd) tra gli utenti sudoers.
•  Per risolvere questo problema appendere al file /etc/sudoers la
riga:
nova ALL = (root) NOPASSWD: /bin/dd
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
25
Installazione servizio iscsi
•  Per poter fare l'attach di un volume nova all'instanza di una macchina
virtuale è necessario installare ed avviare il servizio scsi-target-utils
sul Cloud Controller. Controllare quindi che sia installato attraverso il
seguente comando:
# yum install scsi-target-utils
•  Inserire alla fine del file /etc/tgt/targets.conf la riga:
include /var/lib/nova/volumes/*
•  Far partire il servizio:
# service tgtd start
•  Settare l'avvio automatico:
# chkconfig tgtd on
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
26
Test dell’installazione
•  La verifica vera e propria dell’installazione dei componenti
relativi alla parte Compute di OpenStack verrà fatta al termine
dell’installazione del Compute Node.
•  Per il momento si può controllare che i servizi installati nel
Cloud Controller siano running:
# for s in `ls /etc/init.d/openstack-nova-*`; do $s status ; done
# service tgtd start
Verificando l’output di tali comandi.
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
27
Domande?
Formazione MCloud WP1 – Cloud Controller: descrizione, installazione e test
28
Fonti
•  Guida Mcloud: installazione Cloud Controller
https://wiki.italiangrid.it/twiki/bin/view/MarcheCloud/
InstallingAndConfiguringCloudController
•  Guida Ufficiale installazione di OpenStack su RedHat
http://docs.openstack.org/folsom/openstack-compute/
install/yum/content/
Formazione MCloud WP1 – Descrizione dei principali casi d’uso di OpenStack in Mcloud
29