IL BLOG DEGLI RHCE ITALIANI

Nova, la virtualizzazione secondo OpenStack / 2

Fabrizio Soppelsa

OpenStack

Dopo aver introdotto Nova nel precedente articolo, permettetemi di scrivere un articolo teorico.

Infatti, se creare un’istanza in Nova è un gioco da ragazzi, clic clic clic in Horizon, oppure nova boot, non sono in molti con le idee così chiare da potervi spiegare come funziona OpenStack internamente quando deve effettuare un’operazione che dal punto di vista dell’amministratore è quotidiana e banale come il provisioning di una VM. Supponiamo di aver installato un cluster operativo e di cliccare su Launch Instance. Cosa succede dietro le quinte?

Per prima cosa, Horizon incapsula i dati del form in una POST. Poi verifica se il token di autenticazione dell’utente è valido. Se è scaduto, ne richiede uno nuovo a Keystone. A meno di avere una PKI con i token firmati in Keystone, Keystone interviene ogni volta che un programma è invocato a fare qualcosa, per occuparsi dell’autenticazione: verifica i permessi. Se l’utente è autorizzato ad eseguire l’operazione nel determinato tenant per il determinato servizio, allora Keystone restituisce via HTTP un token che contiene l’ID dell’utente, i suoi ruoli nei tenant, e gli endpoint ai servizi per i quali l’utente è autorizzato. Con token valido in mano, l’utente può invocare le API dei servizi. Nel nostro esempio l’utente invoca le API di Nova sul controller per inizializzare un’istanza, con una GET. Le API di Nova sono RESTful e compatibili con quelle di EC2 e, ovviamente, l’endpoint di Nova nel caso di deployment in HA è un virtual IP (VIP).

Nova sa che ha ricevuto l’ordine da qualcuno di creare una VM, e per prima cosa interagisce con Keystone per validare il token. Se tutto è in ordine, inizia ad elaborare la richiesta verificandola sintatticamente. Se ci sono errori, solleva un’eccezione. Altrimenti, crea un record nel suo Nova database, scrivendo che ha creato una VM. Aperta parentesi: teoricamente, il database dei programmi di OpenStack può essere qualsiasi RDBMS, ma la scelta più popolare nei cluster in HA è quella di usare un MySQL multimaster o Galera. Chiusa parentesi, a questo punto Nova inserisce nel Queue Management System le azioni successive.

Prima cosa, mette in coda una richiesta al Nova scheduler: “Devo allocare risorse per una VM”. Lo scheduler è un servizio di Nova che si occupa, mediante algoritmi, di trovare l’hypervisor più adatto per ospitare la VM. Lo scheduler pesca dalla coda e sa che deve cercare un nodo compute. Legge nel database le caratteristiche della VM che bisogna istanziare e, se disponibile, sceglie un hypervisor. Poi mette questa informazione (l’ID dell’hypervisor) nella coda: “Bisogna fare provisioning dell’istanza X sul nodo Y”.

A questo punto, l’azione passa sul nodo di compute. Nova compute, sul nodo di compute appunto, legge dalla coda che deve allocare le risorse per un’istanza, e tramite un altro pezzo di Nova che si chiama Nova conductor, ottiene le informazioni dettagliate sull’istanza da creare dal Nova database.

Nova compute ora invoca Neutron, il servizio di network-as-a-service sui nodi Neutron server per allocare le reti. Neutron server crea i record nel Neutron Database relativi alle configurazioni dei dettagli a L2, assegna gli IP, imposta i gateway, i DNS.

A questo punto, Nova compute sul nodo di compute invoca Cinder, il servizio di storage, sui nodi Cinder, per iniziare ad allocare spazio per il block storage qualora uno storage persistente sia necessario, creando un volume. Cinder riceve la richiesta, crea un record nel Cinder Database sul volume/i che deve creare, e fisicamente li crea.

A questo punto, Nova compute invoca Glance, per ottenere l’immagine. Se tutto è regolare, Glance restituisce l’immagine stessa, che tipicamente si trova in Swift. Adesso, Nova compute fa fisicamente download dell’immagine direttamente da Swift (oppure da Glance se qualche meccanismo di caching è stato configurato).

A questo punto, infine, Nova compute passa tutti i dati raccolti (storage, rete e immagine) al driver dell’hypervisor. Se il driver usato è KVM, Nova crea un comando da impartire a libvirtd e il file XML che descrive l’istanza, e la lancia.

Ora che la nostra istanza è creata, Nova compute mette nella coda per il Nova conductor l’informazione: “Aggiorna lo status nel database per questa istanza ad ATTIVO”. Il conductor legge la richiesta e aggiorna il database. Infine, Horizon, via poll, visualizza che l’istanza è attiva e POWER ON.

OpenStack è un progetto opensource grande e complesso. Visto? Avere il quadro di insieme di un cluster in produzione non è compito facile, e questo era solo un piccolo esempio. Nel prossimo articolo ci occuperemo ancora di Nova ma stavolta affronteremo l’argomento degli scheduler. Stay tuned!

Info about author

Fabrizio Soppelsa

Prenota subito il tuo corso ufficiale Red Hat

GUARDA I CORSI