hypervisor | Tutti per Linux

OPENSTACK – PARTE PRIMA

Si parla molto di OpenStack e delle sue applicazioni. Ma che cos’è davvero, perché è stato sviluppato e quali sono i suoi vantaggi?

Che cos’è?
OpenStack è un sistema operativo per il cloud computing in grado di controllare componenti di storage, networking e computing. È open source e gratuito, di solito è installato sotto forma di soluzione IaaS. OpenStack fornisce un insieme di strumenti che servono a costruire e gestire piattaforme cloud sia pubbliche sia private. Permette agli utenti di installare macchine virtuali e si può accedere al codice sorgente per modificarlo in qualsiasi modo sia utile per gli scopi specifici del progetto.

Chi lo ha sviluppato?
Nel 2010 Rackspace e la NASA hanno collaborato a un progetto congiunto che è poi diventato OpenStack. Il codice iniziale è stato usato per Nebula, la piattaforma cloud della NASA, poi il progetto si è dato l’obiettivo più ampio di aiutare le aziende a far girare software cloud su hardware standard.

Chi lo usa?
Tra i vendor, alcuni dei nomi più importanti che attualmente supportano e distribuiscono OpenStack sono Canonical, Cisco, EMC, HP, Huawei, IBM, Oracle, Google e Red Hat. Tra gli utenti attuali ci sono Bloomberg, Comcast, PayPal e Wells Fargo. Ci sono incontri internazionali periodici su OpenStack – gli OpenStack Summit – in tutto il mondo, che raccolgono programmatori e utenti della piattaforma.

E’ quindi ormai innegabile l’interesse che tutto il mondo IT ha riservato in questi ultimi anni ad OpenStack.

Qual’è la ragione di tutto questo?

L’ormai tradizionale paradigma client-server, in progetti in cui la scalabilità e le finestre di picchi di carico sono variabili essenziali all’interno dell’equazione della produttività, presenta oggi giorno evidenti limiti di gestione dei carichi e della velocita’ di evoluzione dei progetti. Ecco quindi nascere l’esigenza di uno strumento che fosse flessibile ed allo stesso momento affidabile.

Questo concetto spiega quindi le motivazioni che possono spingere ad adottare una piattaforma cloud, ma perché fra tutte le piattaforme esistenti si parla sempre di OpenStack?

OpenStack è un progetto aperto
La sua natura aperta ha fatto sì che tutti i vendor interessati all’introduzione di specifiche funzionalità o determinati ambiti potessero contribuire in maniera attiva e funzionale al progetto, innescando un circolo virtuoso in cui ogni miglioramento apportato per favorire se stessi va a beneficio della comunità.

La sua natura aperta fa sì che chi adotta OpenStack per il proprio ambiente cloud è di fatto esente dal cosiddetto vendor lock-in, ossia l’essere vincolato ad un rivenditore specifico per le proprie tecnologie. Infatti se lo standard OpenStack è garantito, ogni venditore potrà essere valutato in modo paritetico a tutti gli altri, rendendo così il mercato più competitivo e conveniente per il cliente finale.

I presupposti di un progetto OpenStack

Bisogna subito tenere presente che “non tutti i progetti sono adatti al cloud“, nonostante cio che viene erroneamente interpretato leggendo in giro per il web, infatti questo principio sfugge a molti che guardano verso le nuvole vedono unicamente un posto differente da cui erogare i propri servizi. Esistono dei requisiti da tenere presente per capire se un progetto è adatto al cloud.

Un progetto OpenStack quindi deve essere:

** Non persistente: non deve basarsi sulla persistenza dei dati all’interno delle macchine coinvolte. Questo aspetto non va confuso con l’esigenza di avere uno storage solido e sicuro, si tratta invece di non giudicare le istanze che concorrono al progetto come perenni, ma come componenti utili al loro scopo e liberamente sacrificabili;

** Scalabile: deve supportare applicazioni che nativamente siano in grado di scalare. L’applicazione nasce già dallo sviluppo come pensata per il cloud;

** Dinamico: a fronte di un innalzamento delle richieste ricevute il progetto deve essere in grado in maniera autonoma di gestire le nuove componenti. Gli interventi manuali successivi all’implementazione sulle istanze coinvolte devono essere inesistenti;

** Rapido: deve essere passibile di provisioning, favorendo la velocità di creazione (e distruzione) di nuove istanze;

Se il vostro progetto risponde a questi requisiti messi in evidenza qui sopra, allora potete pensare ad integrare OpenStack ed è giunto quindi il momento di capire in cosa consiste.

Le componenti di OpenStack

La parola stack descrive un insieme di entità che concorrono ad uno scopo comune. OpenStack è composto da numerose elementi che devono comunicare fra loro, lo strato di comunicazione passa attraverso due filoni fondamentali: la memorizzazione delle informazioni e la coda delle azioni da svolgere. Queste due azioni sono coperte ciascuna da un elemento specifico:

MySQL

Il database MySQL è necessario per la memorizzazione delle informazioni di configurazione generali del sistema, per la memorizzazione delle informazioni di autenticazione relative a ciascun componente e per il mantenimento dinamico dello stato del sistema.
Ogni azione eseguita all’interno dell’infrastruttura OpenStack è tracciata all’interno del database. L’importanza di questa componente è evidentemente capitale.

RabbitMQ

RabbitMQ è uno scheduler, un software didicato alla gestione delle code ed all’organizzazione delle sequenze di operazioni. Tutti i nodi facenti parte dell’infrastruttura OpenStack comunicano con lo scheduler, ed anche in questo caso è presto spiegato come questa componente ricopra enorme importanza per il regolare funzionamento dell’ambiente.

Determinato quindi il sistema di circolazione e reperimento delle informazioni si può focalizzare l’attenzione sugli elementi peculiari di OpenStack, riassunti in questo diagramma che si trova sul sito ufficiale del progetto:

OpenStack Diagramma Software

Keystone

Keystone è il software che gestisce il sistema di autenticazione di OpenStack. Il principio su cui si fonda è quello classico degli utenti e dei gruppi, ma di fatto si occupa di gestire le tre tipologie di utenti configurabili in OpenStack:

Cloud Provider Admins: ossia gli amministratori del sistema OpenStack;
Tenants: ossia i profili delle compagnie fruitrici dei servizi;
Users: ossia gli utenti delle compagnie fruitrici dei servizi;

Il concetto di “compagnia” si riferisce ad un sotto-ambiente interno alla stessa installazione di OpenStack. Applicato ad un provider esso potrebbe essere rappresentato dai clienti, mentre all’interno di un cloud privato potrebbe essere associato ad un dipartimento interno.

Glance

Glance si occupa del provisioning (ossia di fornire) delle immagini all’interno dell’ambiente. Questa componente fornisce un bacino di istanze gia preconfigurate, disponibili ai fruitori dei servizi, per effettuare il deploy (ossia la messa in produzione) dell’istanza desiderata all’interno del proprio ambiente.
Le immagini sono supportate nei formati KVM qcow, Aws, VMWare purché esista su queste un Master Boot Record.

Nova

Nova è il compute service, un servizio che permette di gestire i sistemi virtuali erogati all’interno dell’ambiente. All’interno della macchina definita controller il servizio nova-api guiderà l’avvio e la terminazione delle istanze comandando la sua controparte nova-compute, attiva su tutte le macchine hypervisor facenti parte della struttura OpenStack.
Le decisioni su dove e come le istanze dovranno essere avviata saranno gestite dal servizio nova-compute-service (basato su libvirt).

Horizon

Horizon è l’interfaccia web dalla quale è possibile controllare agevolmente le istanze in modalità point-and-click oltre che le immagini gestite da Glance. Il software Horizon è basato sul modulo wsgi del webserver Apache.

C’è ancora un’ultimo aspetto da tenere presente, come è deducibile dallo schema, lo storage.
In un setup base le macchine possono essere erogate direttamente dai dischi degli hypervisor, ma in ambienti di larga scala ciò potrebbe non essere auspicabile. In questi casi fare riferimento ad un gestore dello spazio centralizzato permetterebbe di utilizzare gli hypervisor come semplici erogatori, valorizzando la scalabilità generale del progetto, ed ecco dunque venirci in aiuto questo componente per la gestione dei volumi, Cinder.

Cinder

In origine parte del progetto Nova (chiamato nova-volume) e dal 2012 progetto a se stante, Cinder è il servizio che fornisce il block storage per le istanze, uno storage gestito e centralizzato che funziona da dispositivo a blocchi per le virtual machines. Le macchine virtuali risiedono quindi su un device dedicato, definito sulla base di quello che è la modalità con cui l’hypervisor ha accesso allo storage.
Cinder supporta diverse modalità per essere visto dagli hypervisors: è possibile infatti utilizzare dischi locali o sistemi storage esterni, quali NFS, FibreChannel, DRBD o iSCSI.

Swift

A differenza di Cinder, Swift è un servizio di storage online che si occupa di rendere disponibile spazio all’interno dell’ambiente OpenStack mediante la modalità object storage. I dati non vengono registrati direttamente su dispositivi a blocchi, ma preventivamente convertiti in oggetti binari, distribuiti all’interno di più device in modo da garantirne la massima accessibilità oltre che la replica.
Swift è compatibile con il servizio di storage Amazon S3 e funziona con lo stesso principio: fornire uno storage web accessibile e scalabile.

Conclusioni

In questa lunga introduzione sono stati illustrati filosofia, componenti e soprattutto potenzialità di OpenStack, ma sebbene la lettura possa essere apparsa lunga, questa tocca appena la superficie dell’universo relativo a questo grande progetto.
Nel prossimo articolo verrà avviato un piccolo studio di fattibilità vero e proprio con lo scopo di mettere su strada tutti i vari software che lo compongono ed iniziare cosi ad adoperare OpenStack.

Docker costruire i contenitori

Recentemente abbiamo parlato della virtualizzazione tramite Docker (vedi articolo Docker – cosi cambia la virtualizzazione) e, prima di proseguire sara’ meglio rifare una piccola introduzione.

Docker e’ indubbiamente una valida alternativa alla virtualizzazione tradizionale nel mondo Linux. Questo tipo di virtualizzazione, detta a “container” non emula un’ intero hardware come fanno invece gli hypervisor tipo VMware, Virtualbox, Xen o KVM, ma crea invece dei “contenitori” nel sistema operativo dove possono essere messe in esecuzione applicazioni di vario genere in modo del tutto separato una dall’altra.

Dato che con il cloud il ruolo del sistema operativo diventa sempre meno importante perchè si punta più sullo strato applicativo, PaaS, rendendo il tutto più flessibile. A questo punto se dovessimo far girare 1000 clienti su un ambiente condiviso, diventerebbe interessante disporre di una tecnologia di virtualizzazione che riduca al minimo fisiologico gli overhead.

La virtualizzazione classica non è così, perchè per ogni ambiente applicativo, riservato ad un cliente, si dovrebbe lanciare una intera macchina virtuale con dentro l’intero sistema operativo. E allora perchè non condividere lo stesso sistema operativo e invece isolare solo gli ambienti di esecuzione delle applicazioni , tipo application server, DB ecc…

I container sono dunque alla base dei moderni servizi cloud di tipo PaaS (Platform as a service) che usano questo tipo di virtualizzazione per misurare il consumo di risorse ed assegnarne i limiti.

Ad esempio, se su uno stesso server fisico, con una soluzione di virtualizzazione di tipo hypervisor si possono ospitare, supponiamo 50 virtual machines, con la virtualizzazione a container si potra’ arrivare anche a 1000 container. Questo perchè un container di per sè è solo un contenitore di processi, mentre una virtual machine completa contiene tutto un ambiente operativo emulato.

Il container può anche essere portabile, infatti ci basta copiare la directory che contiene il filesystem modificato dall’utente dopo la creazione del container, un piccolo file di configurazione, ed il container diventera’ eseguibile su qualsiasi sistema che supporti LXC.

Il concetto è talmente interessante, che qualcuno ha pensato di fare un sistema operativo Linux interamente basato sui container, in cui non c’è nemmeno un package manager perchè si assume che gli applicativi saranno solo in forma di container. Coreos è nato proprio con il principio di supportare ambienti di esecuzione a container, togliendo dal sistema tutto quello che non è strettamente necessario per farlo funzionare.

INSTALLAZIONE

Abbiamo tre possibili metodi d’installazione :

1) Centos

sudo yum -y install docker-io

2) Debian/Ubuntu

sudo apt-get update 
sudo apt-get install docker.io 
sudo sudo apt-get install lxc-docker

3) Download con Curl

sudo curl -sSL https://get.docker.io/ubuntu/ | sudo sh

* Linkiamo docker alla nostra bash

ln -sf /usr/bin/docker.io /usr/local/bin/docker
sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io

* Rendiamo docker attivo all’avvio

update-rc.d docker.io defaults

P.S.: Ci sono molti contenitori già disponibili nella community docker, che possono essere trovati attraverso una ricerca. Ad esempio con questo comando cerchero’ la parola debian:

# docker search debian

NAME    DESCRIPTION      STARS     OFFICIAL   AUTOMATED
debian  Debianbaseimage  310         [OK]
google/debian            31                     [OK]

….e molte altre che potrete leggere dall’output completo.

** Installiamo e facciamo provisioning con una immagine Centos

# docker pull blalor/centos # GitHub blalor/docker-centos-base image

oppure per chi fosse interessato ad una immagine con gia inserito il tool Ansible (per il Configuration Management ed IT Automation) di cui ho da poco parlato, potra’ scegliere quest’altra immagine.

sudo docker pull ansible/centos7-ansible # GitHub Ansible on Centos7
Pulling repository ansible/centos7-ansible
fff2afd18a57: Download complete

Avviamo un container docker

Attiveremo ora un contenitore centos-base con una shell bash, utilizzando il comando run. Docker eseguira’ questo comando in un nuovo contenitore, -i attribuisce stdin e stdout, -t assegna un terminale.

docker run -i -t centos /bin/bash

Questo è tutto! Adesso stai usando una shell bash all’interno di un contenitore centos.
Per scollegarsi dalla shell la sequenza di escape e’ : Ctrl-p + Ctrl-q.

Diamo un’occhiata ai processi attivi tramite :

# docker ps -a
CONTAINER   ID IMAGE          COMMAND     CREATED
fff2afd18a57     blalor/centos     /bin/bash         About an hour ago

Il Dockerfile
Per automatizzare la procedura di creazione e modifica di un container docker, possiamo utilizzare il Dockerfile, che è una delle parti principali di Docker, infatti attraverso il Dockerfile è possibile non solo fare il deploy istantaneo automatizzato di più istanze e più container, ma è anche possibile eseguire il provisioning di queste istanze, automatizzando task di gestione del sistema, installazione del software e molto altro.

Nel prossimo articolo vedremo un esempio utile, utilizzando ad esempio un’applicazione leggera, che puo’ lavorare molto bene in un contenitore, come NGINX, il noto server web/cached per la gestione di siti web/proxy ad alto carico.

#DockerContainerAvviato