Costruiamo un cloud con OpenStack

Costruiamo un cloud con OpenStack

Introduzione e preparazione dell’ambiente

1# Descrizione di OpenStack e un pò di teoria!

Il progetto OpenStack è una piattaforma di cloud computing open source per tutte le tipologie di cloud, che si propone di essere semplice da implementare, scalabile e ricco di funzionalità. Sviluppatori e tecnici del cloud computing di tutto il mondo contribuiscono allo sviluppo di OpenStack.

Fornisce una soluzione IaaS (Infrastructure-as-a-Service) attraverso una serie di servizi interconnessi. Ogni servizio offre un’interfaccia API che facilita questa integrazione. A seconda delle esigenze, è possibile installare alcuni o tutti i servizi. Comprende diversi servizi chiave installati separatamente. Questi servizi interagiscono in base alle esigenze del cloud e includono i servizi di Compute, Identity, Networking, ImageBlock StorageObject Storage, Telemetria, Orchestrazione e Database. È possibile installare separatamente uno di questi servizi (Nella terminologia di OpenStack sono “progetti”) e configurarli autonomamente o come entità connesse.

Il seguente diagramma mostra le relazioni tra i servizi più importanti di OpenStack:

Ovviamente sembra tutto molto complesso (e un pò lo è in realtà) ma andando piano piano ad entrare nel merito di ogni singolo servizio, ogni pezzo del puzzle andrà al suo posto e il tutto risulterà chiaro e anche piuttosto immediato!

Per progettare, distribuire e configurare OpenStack, abbiamo la necessità prima di tutto di comprendere l’architettura logica. Come mostrato nell’architettura concettuale, OpenStack è costituito da diverse parti indipendenti, chiamate servizi OpenStack. Tutti i servizi si autenticano tramite un servizio di identità comune (Keystone). I singoli servizi interagiscono tra loro tramite API pubbliche, tranne quando sono necessarie delle chiamate che necessitano di privilegi elevati. Internamente, i servizi OpenStack sono composti da diversi processi. Tutti i servizi hanno almeno una componente API, che ascolta le richieste, le pre-processa e le inoltra ad altre parti del servizio. Ad eccezione del servizio di Identity, il lavoro effettivo viene svolto da processi distinti.

Per la comunicazione tra i processi di un servizio, viene utilizzato un broker di messaggi AMQP (RabbitMQ, Apache Kafka, AWS Kinesis, etc.) . Lo stato del servizio è memorizzato in un database (MySQL, MariaDB, SQLite).

Gli utenti possono accedere a OpenStack tramite una comoda interfaccia Web implementata dal servizio “Horizon Dashboard”, ovviamente è possibile interagire con i diversi servizi grazie a una fantastica CLI con cui controllare ogni singola parte del nostro Cloud. Per le applicazioni, sono disponibili diversi SDK. In definitiva, tutti questi metodi di accesso rilasciano chiamate API REST ai vari servizi OpenStack.

Questa guida illustra la distribuzione passo-passo dei principali servizi OpenStack utilizzando un’architettura di esempio funzionale adatta ai nuovi utenti di OpenStack con una ottima esperienza Linux, non è pensata assolutamente per essere utilizzata in installazioni di sistemi di produzione (vorrei ben vedere!) , ma per creare un proof-of-concept minimo allo scopo di conoscere OpenStack.

Quello che alla fine andremo a creare è sostanzialmente questo:

Avremo sostanzialmente 4 server (Che virtualizzeremo con VirtualBox) che gestiranno il nostro cloud:

  • Controller Node
  • Compute Node
  • Block Storage Node
  • Object Storage Node

Per quanto riguarda i requisiti HW sono ovviamente scalabili verso il basso. Il mio consiglio però è quello di dedicare almeno 2GB di RAM per ogni singolo componente. Ma a cosa servono tutti questi nodi? Andiamo un pò più nel dettaglio!

Controller Node:

Il Controller Node esegue il servizio di Identity, il servizio Image, una parte del servizio di Computing, una parte del servizio di Networking, vari Agent di rete e la Dashboard. Include inoltre servizi di supporto come un database SQL, una coda di messaggi e un server NTP. Facoltativamente, il Controller Node esegue una parte dei servizi di Block StorageObject Storage, Orchestrazione e Telemetria.

Compute Node:

Il Compute Node esegue l’hypervisor che gestisce le istanze create sul nostro Cloud. Per impostazione predefinita, utilizza l’hypervisor KVM. Il Compute Node esegue anche alcuni Agent del servizio di Networking necessari a collegare tutte le istanze alle reti virtuali e fornisce servizi di firewalling alle istanze tramite Security Groups.

Block Storage Node:

Il Block Storage Node è facoltativo e contiene i dischi per i servizi di archiviazione a blocchi e per eventuali Filesystem condivisi. Per semplicità, il “traffico di servizio” tra il Compute Node e questo nodo, viene instradato sulla rete di Management. Gli ambienti di produzione dovrebbero implementare una rete di storage separata e dedicata per aumentare le prestazioni e la sicurezza.

Object Storage Node:

Anche l’ Object Storage Node è facoltativo e contiene i dischi utilizzati dal servizio di Object Storage & Data Lake (Servizi come Google Drive, Amazon S3 o Dropbox) . Anche qui valgono le stesse considerazioni riguardanti la rete fatte per il Block Storage Node.

2# Preparazione dell’ambiente

Dopo aver installato il sistema operativo su ciascun nodo (Io ho adottato per lo scopo RHEL7) , è necessario configurare le interfacce di rete. Consiglio di disabilitare qualsiasi strumento di gestione della rete automatizzato e modificare manualmente i file di configurazione per impostare un indirizzamento della rete statico.

Tutti i nodi richiedono l’accesso a Internet per scopi amministrativi come l’installazione di pacchetti, gli aggiornamenti di sicurezza, servizio DNS e NTP. Nella maggior parte dei casi, i nodi dovrebbero ottenere l’accesso a Internet attraverso l’interfaccia di rete di gestione (Utilizziamo quindi l’interfaccia settata in NAT su Virtualbox).

Schematizzando dobbiamo creare una situazione simile a questa:

Configurazione della rete:

Per quanto riguarda la configurazione della rete di ogni singolo nodo, come detto dobbiamo utilizzare 2 NIC come illustrato:

Requisito fondamentale è l’impostazione di IP Statici. Su RHEL potete utilizzare il file “/etc/sysconfig/network-scripts/ifcfg-<interfaccia>” , nel mio caso abbiamo:

Requisito fondamentale è l’impostazione di IP Statici. Su RHEL potete utilizzare il file “/etc/sysconfig/network-scripts/ifcfg-<interfaccia>” , nel mio caso abbiamo:

Modifiche al file hosts:

Per comodità di gestione andiamo anche a registrare nel file hosts di TUTTI i nodi i relativi hostname che compongono la nostra infrastruttura.

Verifica della connettività:

Prima di procedere oltre, andiamo a testare la nostra connettività sia verso Internet, che verso gli altri nodi del nostro cloud. I seguenti test vanno effettuati su TUTTI i nodi.

Se il test fallisce, controllare per prima cosa se il Firewall di sistema è abilitato. nel caso per facilitarvi le cose, disabilitatelo.

3# Network Time Protocol (NTP):

Per sincronizzare correttamente i servizi tra i nodi, è possibile installare Chrony, una nuova implementazione di NTP. Vi consiglio di configurare il Controller Node in modo che faccia riferimento a server più precisi (Lower Stratum) e gli altri nodi che fanno riferimento al Controller Node.

Controller Node:

Andiamo per prima cosa ad installare chrony sul nostro controller:

Successivamente modifichiamo il file /etc/chrony.conf puntando il server NTP di riferimento che vogliamo utilizzare:

Per consentire ad altri nodi di connettersi al demone chrony sul nodo controller, scommentare la direttiva “allow” nel file e inserire la subnet che vogliamo abilitare:

Al termine delle modifiche andiamo a restartare il demone di Chrony

Compute/Block Storage Node:

Per gli altri nodi il discorso NTP è identico a quello visto in precedenza ad eccezione del server da puntare nel file Chrony.conf , che deve essere proprio il nostro Controller Node.

4# OpenStack Package:

Generalmente tutte le distribuzioni rilasciano pacchetti di OpenStack all’interno dei propri repository come parte della distribuzione o utilizzano altri metodi di rilascio. Queste procedure vanno eseguite su tutti i nodi. Vi consiglio di disabilitare eventuali servizi di aggiornamento automatico perché possono influire sul vostro ambiente OpenStack.

Su CentOS (La distro selezionata per questo tutorial), il repository extra fornisce l’RPM che abilita il repository OpenStack. CentOS include il repository extra per impostazione predefinita, quindi puoi semplicemente installare il pacchetto per abilitare il repository OpenStack.

Una volta installati i pacchetti, andiamo ad eseguire un “upgrade”

Se l’upgrade prevede un nuovo kernel, effettuate un reboot dei nodi per utilizzarlo.

Una volta installati tutti gli upgrade andiamo ad installare “openstack-client” e visto che siamo in ambiente RHEL/CentOS e potremmo aver abilitato SELinux il pacchetto “openstack-selinux” gestisce automaticamente le policy di sicurezza per i servizi OpenStack:

5# SQL Database:

La maggior parte dei servizi OpenStack utilizza un database SQL per memorizzare le informazioni. Andiamo quindi ad installare il nostro database sul Controller Node. La procedura in questa guida utilizza MariaDB(Un fork di MySQL). I servizi OpenStack supportano comunque anche altri database SQL tra cui PostgreSQL. Andiamo quindi ad installare i pacchetti necessari:

Al termine dell’installazione creare il file /etc/my.cnf.d/openstack.cnf.

[mysqld] bind-address = 192.168.229.2

default-storage-engine = innodb
innodb_file_per_table = on
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8

fatto ciò startiamo il DB e impostiamo lo start automatico al boot.

Mettiamo in sicurezza il DB eseguendo lo script “mysql_secure_installation“. In particolare, scegliere una password adatta per l’account root del database

6# Message Queue:

OpenStack utilizza una coda di messaggi per coordinare le operazioni e le informazioni sullo stato tra i servizi. OpenStack supporta diversi broker tra cui RabbitMQQpid, Apache Kafka e ZeroMQ. Per questa guida utilizzo RabbitMQ perché è il broker più diffuso sulla maggior parte delle distribuzioni. Se si preferisce implementare un diverso di MQ, consultare la documentazione ad esso associata.

Il broker va installato sul Controller Node.

Installiamo il pacchetto:

startiamo il servizio e impostiamo lo start automatico al boot.

Creiamo l’utente “openstack” e associamoci una password

infine andiamo ad impostare alcuni permessi per l’utente openstack, tra cui configuration, write, and read access

7# Memcached:

Il meccanismo di autenticazione dell’Identity service per i vari servizi utilizza Memcached per memorizzare i token nella cache. Il servizio memcached va installato sul Controller Node.

Andiamo ad installare i package necessari:

Una volta installato il tutto andiamo a modificare il file “/etc/sysconfig/memcached” e modifichiamo la seguente opzione:

OPTIONS=”-l 127.0.0.1,::1,controller”

startiamo il servizio e impostiamo lo start automatico al boot.

8# Etcd:

I servizi OpenStack possono utilizzare Etcd, un archivio di key-value affidabile e distribuito. è utilizzato prevalentemente per la memorizzazione delle configurazione, il monitoraggio della durata del servizio e altri scenari. Il servizio etcd va installato sul Controller Node.

Installiamo i pacchetti:

Modifichiamo il file /etc/etcd/etcd.conf e impostiamo le seguenti direttive:

#[Member]

ETCD_DATA_DIR=”/var/lib/etcd/default.etcd”
ETCD_LISTEN_PEER_URLS=”http://192.168.229.2:2380″
ETCD_LISTEN_CLIENT_URLS=”http://192.168.229.2:2379″
ETCD_NAME=”controller”

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS=”http://192.168.229.2:2380″
ETCD_ADVERTISE_CLIENT_URLS=”http://192.168.229.2:2379″
ETCD_INITIAL_CLUSTER=”controller=http://192.168.229.2:2380″
ETCD_INITIAL_CLUSTER_TOKEN=”etcd-cluster-01″
ETCD_INITIAL_CLUSTER_STATE=”new”

startiamo il servizio e impostiamo lo start automatico al boot.

Con questo abbiamo terminato le prime configurazioni del nostro ambiente. Sul prossimo tutorial andremo a “posare la prima pietra” ossia il nostro Identity Service che sarà fondamentale per il funzionamento di tutto lo stack!

a cura di: Alessio Mario
Security, Authentication and Access Management