Meccanismi di High Availability per infrastrutture di cloud computing basate su OpenStack

Transcript

1 Elaborato finale in Sistemi Operativi Meccanismi di High Availability per infrastrutture di cloud computing basate su OpenStack Anno Accademico 2013/2014 Candidato: Alessandro Siervo matr. N

2 Il software è come il sesso: è migliore quando è libero e gratuito. Linus Torvalds

3 Indice Capitolo 1. Panoramica di OpenStack Cloud Computing OpenStack Perchè OpenStack? Architettura OpenStack Identity Service ( Keystone) OpenStack Compute ( Nova ) OpenStack Object Storage ( Swift ) OpenStack Block Storage ( Cinder ) OpenStack Image ( Glance ) OpenStack Networking ( Neutron ) 10 Capitolo 2. High Availability in OpenStack Configurazioni di High Availability Configurazione Attivo-Passivo Configurazione Attivo-Attivo Progettazione di una infrastruttura OpenStack High Availability Software di supporto per l' high availability Compute Node HA Controller Node HA API services State database Messages queues ( RabbitMQ ) Object storage, Swift Neutron HA DHCP agent L3 agent L2 agent Neutron server Neutron scheduler Load balancer HA 37 Conclusioni 38 Bibliografia 39 III

4 Capitolo 1 Panoramica di OpenStack Con l' avvento e la diffusione del cloud computing è nata una vera e propria competizione tra i vari provider che forniscono tale servizio. In questo elaborato si parlerà dell' High Availability e dei meccanismi che OpenStack utilizza per garantirla. 1.1 Cloud Computing Con il termine cloud computing si indica un insieme di tecnologie che permettono, sotto forma di un servizio offerto da un provider, di memorizzare e elaborare dati grazie all'utilizzo di risorse hardware/software distribuite e virtualizzate in rete [1]. Il National Institute of Standards and Technology (NIST) ha elaborato una definizione universalmente accettata dagli esperti nel settore. In particolare, essa definisce 3 modelli di servizi fondamentali per un cloud computing [2]: SaaS ( Software as a service ): in questo modello sono erogati come servizi i software. Un esempio di modello SaaS sono i servizi di posta elettronica come Gmail, introdotto nel 2004 da Google. PaaS ( Platform as a service ) : ad essere erogate sono le infrastrutture necessarie che permettono di sviluppare, testare e distribuire un' applicazione. Esso si posiziona ad un livello di astrazione più alto di IaaS. IaaS ( Infrastructure as a service ) : in questo modello è erogata l' intera infrastruttura. Il cliente può acquistare anche intere macchine virtuali, così da poter erogare autonomamente i propri servizi e le proprie applicazioni. 4

5 1.2 OpenStack Illustrazione 1: Logo di OpenStack E' stato lanciato per la prima volta il 19 luglio 2010, OpenStack è un progetto tramite il quale è possibile costruire una Infrastructure as a Service ( IaaS ). Ritenuto il secondo successo dell'open source dopo Linux, le sue radici risalgono all'interno della NASA e della RackSpace, nata da una loro collaborazione. Oggi è supportato da molteplici aziende come HP,IBM,Cisco e Dell. Il progetto è rilasciato sotto i termini della licenza Apache License e viene attualmente gestito dalla OpenStack Foundation, un' entità no profit fondata nel settembre del Tutto il software è sviluppato in Python seguendo un' architettura di tipo modulare. Noi ci occuperemo di Havana, ultima release di OpenStack che risale al 17 Ottobre 2013 ( a dicembre è venuto un bugfix di tale versione ). 5

6 1.3 Perché OpenStack? Con OpenStack si ha a disposizione una numerosa rete di strumenti per amministrare un servizio IaaS cloud su hardware standard che possa fornire applicativi web, server e servizi di archiviazione dati all utente finale senza difficoltà. Esso è completamente open source ed è reputato il più grande successo dopo Linux. E' fornito di ottima documentazione ed è costantemente aggiornato. Inoltre, la proposta di nuove release ogni 6 mesi, con l introduzione costante di nuove funzioni, lo rende un prodotto competitivo e ricco di innovazioni. Gode di una vasta compatibilità per i formati immagine, storage e di tutti i protocolli dei sistemi principali come Amazon e Vmware. Da non trascurare è anche il supporto di aziende importanti, come Cisco, Red Hat, NASA, RackSpace, Dell, che hanno sicuramente inciso nella pubblicizzazione del progetto. Giuseppe Paternò ha presentato un' interessante comparazione tra OpenStack, vmware e Ganeti descrivendo per ognuno di essi pro e contro e dando, infine, un consiglio su quale sistema utilizzare in base al contesto. Per ulteriori informazioni consultare la bibliografia [4]. 1.4 Architettura Come suddetto, OpenStack utilizza un' architettura modulare in cui ogni componente è un software indipendente e copre un servizio di cloud computing per un' infrastruttura IaaS. Tutti i componenti di OpenStack sono concepiti per la realizzazione di un software: Component based architecture: basato sui componenti per velocizzare l' eventuale aggiunta degli stessi fornendo una scalabilità orizzontale ( scale out ). Highly available: garanzia di continuità del servizio. Fault- Tolerance: capacità di non subire fallimenti anche in presenza di guasti. Recoverable: i fallimenti dovrebbero essere semplici da diagnosticare e correggere 6

7 API Compatibility: si sforza nel rendersi API- compatibile con i sistemi principali. L' Architettura di OpenStack è message-based. E' stata scelta in modo tale che i vari componenti possano essere eseguiti in server differenti ( server distribuiti ) per migliorare la Fault-Tolerance e l' High availability. I moduli sono: Compute ( Nova ), Object Storage ( Swift ), Image Service ( Glance ), Identity Service ( Keystone ), Dashboard ( Horizon), Netowking Service ( Neutron ) e Block Storage ( Cinder ). La figura sottostante mostra come tali componenti comunicano [3]: Illustrazione 2: Schema concettuale di OpenStack 7

8 1.4.1 OpenStack Identity ( Keystone ) E' il progetto che si occupa di gestire un elenco centralizzato degli utenti e dei privilegi che essi hanno sull'intera infrastruttura supportando diverse tecniche di autenticazione. L' organizzazione e l' assegnazione dei privilegi viene gestita utilizzando tre strutture chiamate users, tenants e roles. La prima struttura mantiene l' elenco delle utenze, la seconda serve a raggruppare gli utenti e i servizi in un contesto comune, associando ruoli a tali gruppi. Keystone fornisce 4 tipi di servizi: Indentity Service, per la convalida delle credenziali; Policy Service, che fornisce un motore di autorizzazione basato su regole; Token Service, che gestice e convalida i token; Catalog Service, che fornisce un endpoint registry per il discovery degli stessi OpenStack Compute ( Nova ) E' il componente principale di OpenStack. Permette di eseguire istanze multiple di macchine virtuali su tutti gli host che eseguono tale servizio. Gli utenti/organizzazioni possono utilizzare il servizio Nova per ospitare e gestire i propri sistemi di cloud computing. Si occupa di allocare e di tener traccia delle risorse utilizzate e disponibili su tutta l' infrastruttura, indipendentemente dall'hypervisor che è in esecuzione al livello sottostante. Supporta molti tipi di hypervisor, come Xen, KVM, Hyper-V e ESXi. E' formato da nova-api, per la gestione dei comandi e l' interazione con Nova e novacompute, il componente principale dove viene eseguito l' hypervisor e allocate le istanze delle Vms. 8

9 1.4.3 OpenStack Object Storage ( Swift ) Il servizio swift permette la memorizzazione e il recupero di file fornendo una piattaforma di storage completamente distribuita, accessibile tramite API, affidabile e scalabile orizzontalmente. E' un object storage quindi rappresenta ogni singolo file come un oggetto, astraendo il filesystem e nascondendo la complessità architetturale del sistema. Per ogni oggetto essi sono descritti dai loro metadati tramite l' attributo xattr; per questo motivo c'è bisogno di filesystem opportuni come ext3 o ext4 o xfs OpenStack Block Storage ( Cinder ) Cinder è la componente che sviluppa uno storage block-based per OpenStack fornendo volumi che possono essere connessi alle istanze di VMs. Gestisce la creazione e la dis-/connessione dei volumi dalle istanze con supporto a diversi protocolli come iscsi, RBD, FC. Supporta inoltre numerose piattaforme di storage come Ceph, NetApp, Zadara e NFS. E' possibile eseguire snapshot per il backup dei dati memorizzati nei volumi che possono essere ripristinati o utilizzati per creare un nuovo volume OpenStack Image Service ( Glance ) E' il componente che gestisce i servizi di discovery, registrazione e recupero delle immagini delle VMs; tramite delle API RESTful, glance permette sia di interrogare i metadati delle immagini, sia il recupero delle stesse. Supporta numerosi metodi di memorizzazione di immagini su diversi sistemi di storage, dal filesystem all'object storage ( Swift ). Supporta molteplici formati di immagini, come raw, AMI, vhd, VMDK, per la compatibilità con gli hypervisor. Per ogni immagine, glance assegna un codice univoco, chiamato uuid e 9

10 associa uno stato a seconda dell' azione che sta eseguendo ( queued, saving, active, killed, deleted, pending_delete ) OpenStack Networking Service ( Neutron ) Il servizio di OpenStack Networking fornisce le astrazioni di rete, sottorete e porti, e permette ad ogni tenant di poter gestire più sottoreti e i relativi blocchi di indirizzi IP, indipendentemente dalle richieste degli altri tenants ( Multitenancy ). E' un componente che fornisce network connectivity as a service. Supporta vari plug-in per il layer 2, come Open vswitch, Cisco, Linux Bridge, Ncira NVP, Ryu. I componenti principali di Neutron sono: Neutron Server, che fornisce le API e inoltra la richiesta allo specifico nodo; Agents, che forniscono i servizi di DHCP e Layer 3; plug-in, che vengono installati in ogni nodo e hanno il compito di collegare le istanze al network; Database, utilizzato per memorizzare lo stato e la configurazione della rete. 10

11 Capitolo 2 High availability in OpenStack I cluster High Availability, o Cluster HA, sono una tipologia di cluster disegnata per garantire continuità dei servizi informatici erogati. I sistemi HA cercano di ridurre al minimo [5]: System downtime, inattività del sistema. Si verifica quando un servizio user-facing, rivolto all'utente, non è disponibile oltre un limite di tempo specificato. Data loss, Distruzione o perdita accidentale dei dati. La maggior parte dei cluster high availability garantiscono una protezione contro i downtime di sistema e la perdita dei dati solo in caso di guasto singolo ( single failure ). Tuttavia, essi sono tenuti a proteggersi anche dai guasti a cascata. Un aspetto cruciale dell' high availability è l'eliminazione dei singoli punti di fallimento ( Single Point of Failure ). Un SPOF è un singolo componente hardware o software che, se si guastasse, causerebbe downtime o perdita dei dati. Al fine di eliminare gli SPOFs è importante l' ultilizzo di meccanismi di ridondanza per i seguenti componenti: Componenti di rete; applicazioni e un servizio automatico di migrazione; componenti di archiviazione; servizi di facility come l' energia, l' aria condizionata e la protezione antincendio. 11

12 Genericamente, i sistemi HA raggiungono un uptime, cioè un tempo attivo del sistema, del 99,99% o più, che equivale a meno di un'ora di inattività cumulata in un anno. OpenStack attualmente soddisfa tali requisiti di disponibilità per i propri servizi. Un servizio può essere: Stateless : servizio che non mantiene lo stato, cioè fornisce una risposta data una richiesta e il risultato dipende solo dall' ultima richiesta. Esempi di servizi stateless sono tutti gli API services. Stateful : servizio che mantiene lo stato, la risposta che fornisce non dipende solo dalla richiesta corrente ma anche dallo stato in cui il servizio si trova. 2.1 Configurazioni di High Availability Il meccanismo più importante per garantire l' high availability di un sistema è quello della ridondanza dei componenti con eventuale sincronizzazione degli stessi, qualora fossero stateful. Il requisito minimo per una ridondanza è avere un cluster di almeno due nodi ( il cluster è un insieme di componenti omogenei tra loro ). Esistono vari tipi di modelli, quelli utilizzati da OpenStack sono due: Attivo-Attivo e Attivo-Passivo. 12

13 2.1.1 Configurazione Attivo-Passivo Illustrazione 3: Configurazione attivo-passivo di un cluster di storage E' una configurazione in cui un solo componente è attivo per l' elaborazione delle richieste mentre gli altri sono passivi. Quando avviene un guasto al nodo attivo, il compito di elaborare le richieste sarà passato ad un altro componente. In genere, i servizi sono disponibili utilizzando indirizzi IP virtuali e affidando il compito di reindirizzare le richieste al nodo attivo ad un software aggiuntivo per il cluster come Pacemaker o Keepalived. Nel caso di servizi stateful c'è bisogno di un meccanismo per la sincronizzazione delle repliche in modo da mantenere il medesimo stato. 13

14 2.1.2 Configurazione Attivo-Attivo E' conosciuta anche come configurazione simmetrica. E' una configurazione in cui tutti i componenti sono attivi. Quando avviene un guasto ad uno dei nodi attivi, si elimina l' associazione tra indirizzo IP virtuale del cluster e quello del nodo guasto, cosicché le richieste non saranno più inoltrate a tale componente. I servizi sono disponibili utilizzando indirizzi IP virtuali e un load balancer, per esempio HAProxy, per il bilanciamento del carico. Per servizi stateful, oltre all'utilizzo di un load balancer e di un indirizzo IP virtuale, c' è bisogno di un meccanismo affinché le varie repliche si sincronizzino in modo da mantenere lo stesso stato. Nella figura seguente si può notare, nell'ambito di database multi-master, la differenza tra le due configurazioni: Illustrazione 4: Configurazione MySQL multi-master sia in attivo-attivo che in attivopassivo 14

15 2.2 Progettazione di una infrastruttura OpenStack High Availability Progettare un' infrastruttura OpenStack HA non è un compito banale. Bisogna scegliere quale soluzione utilizzare per ogni servizio in base a ciò che si ha a disposizione e in base alle competenze che si hanno a riguardo. Il primo passo nella progettazione di un' infrastruttura OpenStack HA è di individuare quelli che sono i nodi principali della stessa suddividendoli in: Compute Node: è la componente principale di OpenStack. Contiene il novacompute che, come spiegato nel paragrafo Nova, ha il compito di gestire le istanze VM comunicando con l' hypervisor. Controller Node: contiene tutti i servizi API ( nova-api, glance-api, cinder-api ecc.. ), servizi di autenticazione ( Keystone ), di storage ( tipicamente MySQL ) e MQ. Network Node: contiene tutti gli agenti preposti per fornire servizi DCHP e layer 3 ( DHCP e L3 agent ), ad esempio l' assegnazione del floating IP e il servizio NAT. Tali nodi, in un ambiente distribuito, devono poter comunicare tra loro garantendo un isolamento del traffico gestionale da quello relativo alle istanze delle VMs, e quindi, bisogna costruire una rete adeguata per il collegamento dei componenti. Per fare ciò esistono 3 tipi di reti principali: Management network: fornisce una connettività tra i vari nodi del cluster per la gestione dell' infrastruttura OpenStack. Data ( private ) network: fornisce connettività tra le varie istanze VM. Per ogni tenant, un gruppo di istanze relative ad un progetto/organizzazione, è possibile creare una sottorete, Tenant Network, in modo che altre istanze non possono accedere se non fanno parte del progetto ( isolamento ), Multi-Tenancy. External ( public ) network: fornisce visibilità pubblica alle istanze VMs assegnando alle stesse un floating IP, servizio del L3 agent. 15

16 Illustrazione 5: Architettura distribuita di OpenStack Con questa suddivisione dei componenti è possibile avere una prima distribuzione dell'infrastruttura, in cui ogni nodo può essere eseguito su macchine fisiche diverse. In ambiente di testing è possibile comunque eseguire tutto in una sola macchina, installando il nodo come un server virtuale. Tuttavia, un ambiente distribuito aumenta la tolleranza ai guasti contro le machine failure ( guasti relativi alle macchine ). La progettazione di un' infrastruttura high availability dipende da: Vincoli che si hanno da una human perspective, per esempio che livelli di automazione deve raggiungere l' infrastruttura per quanto riguarda il restore/backup / failover; livello di esperienza per ogni componente dell' infrastruttura, per esempio le soluzioni di cluster DB o le soluzioni riguardo alle Message Queues; budget a disposizione; quanto hardware si ha a disposizione; come deve essere geo-distribuita l' infrastruttura. 16

17 Di seguito si andranno ad approfondire i metodi risolutivi di OpenStack per l' high availability dei singoli componenti Software di supporto per l' high availability Come suddetto, la ridondanza è il meccanismo principale per garantire l' high availability, ma ha bisogno di software che possano controllare il cluster rilevando e gestendo automaticamente i guasti. A tal proposito, OpenStack utilizza Pacemaker, Corosync, HAProxy e Keepalived [6][7]. Pacemaker è un software open source per la gestione delle risorse in high availability, adatto a piccoli e grandi cluster. Le caratteristiche sono: Rilevamento e recupero dei guasti macchina ed a livello di applicazione; supporta praticamente qualsiasi configurazione di ridondanza; supporta entrambi i cluster quorate e resource-driven; strategie configurabili per affrontare la perdita di quorum; supporta applicazioni che devono / non devono eseguire sulla stessa macchina; supporta applicazioni che devono essere attive su più macchine; supporta applicazioni con più modalità (es. master / slave e multi-master). Pacemaker si basa sul livello di messaggistica Corosync/ Heartbeat per le comunicazioni del cluster garantendo affidabilità, scalabilità e prestazioni. HAProxy è un open source TCP/HTTP load balancer, comunemente utilizzato per il bilanciamento del carico. È scritto in C ed ha una reputazione di essere veloce, efficiente e stabile. E' importante rendere affidabile anche il load balancer, altrimenti si avrebbe un singolo punto di fallimento ( SPOF ). Nel paragrafo Load Balancer HA saranno spiegati i metodi risolutivi. Keepalived è un software di routing scritto in C. L'obiettivo principale di questo progetto è quello di fornire servizi semplici e robusti per l' high availability per sistemi Linux o infrastrutture basate su Linux (OpenStack). Tutto è gestito tramite il protocollo VRRP. Il Virtual Router Redundancy Protocol (VRRP) è un protocollo di rete di calcolatori che prevede l'assegnazione automatica dell'ip virtuale agli host partecipanti. 17

18 2.2.2 Compute Node HA I nodi di calcolo sono i componenti fondamentali di un'infrastruttura essendo i server sui quali gli users possono creare le proprie VMs o ospitare le proprie applicazioni. Attualmente, OpenStack non ha implementato meccanismi di high availability per questo componente; ogni nodo compute gestisce le proprie istanze localmente in una directory dedicata, per esempio /var/lib/nova/istances; se un nodo si guastasse, fallirebbero tutte le istanze delle VMs associate ad esso, incluse le directory dedicate. Questo problema causa una perdita di dati ( data loss ) e una discontinuità del servizio ( downtime ). Tuttavia, sono state implementate delle soluzioni per questo problema con il metodo live migration [8]: la migrazione delle istanze da un hypervisor ad un altro nel minor tempo possibile ( zero downtime ). Attualmente, solo gli hypervisor KVM, XenServer, Hyper-v e QEMU lo supportano. Esistono due tipi di live migration: Block live migration ( non shared storage ) Shared storage based live migration Il primo metodo non richiede l'archiviazione condivisa tra i nodi compute: ogni nodo di calcolo si occuperà di gestire localmente le proprie istanze. In caso di guasto si utilizza la rete (TCP) per copiare il disco della VM dall'host sorgente all'host di destinazione. 18

19 Il secondo metodo, quello più comunemente utilizzato in OpenStack, si basa sulla condivisione delle istanze delle VMs in un filesystem o block storage condiviso, come GlusterFS o NFS. I nodi di calcolo comunicheranno con esso tramite i protocolli SAN ( storage area network ) come iscsi o FC. La figura seguente ne mostra un esempio: 19

20 Vantaggi: Block live migration Il diretto accesso all' I/O aumenta le prestazioni delle istanze. L' uso eccessivo di I/O di determinate istanze non influenzano le istanze degli altri nodi di calcolo. Basso costo di Hardware. Shared storage based live migration Separazione tra ciò che è stateless ( nodo compute ) e ciò che è stateful ( storage ) per una ottimizzazione delle risorse. Se un nodo di calcolo si guastasse esso sarebbe facilmente recuperabile. Una migrazione più veloce. Migliore scalabilità orizzontale per l' aggiunta di eventuali dischi. Svantaggi: Block live migration Difficile scalabilità orizzontale dei dischi. La progettazione di un nodo compute limita il numero di dischi che possono essere usati. Migrazione complicata. In caso di guasto, si degradano le prestazioni del nodo ospitante durante la migrazione. Shared storage based live migration Maggior costo per l' hardware. Prestazioni delle istanze inferiori: per utilizzare lo storage i nodi compute devono accedere tramite rete. L' uso eccessivo di I/O di determinate istanze da parte di un nodo possono influenzare istanze di altri nodi. 20

21 Attualmente, OpenStack non ha alcun meccanismo per rilevare il guasto di un nodo o di una istanza di VM, né di un meccanismo automatico per il recupero o la migrazione. Bisognerà aspettare le prossime release per una soluzione a questo problema. Un interessante progetto è OpenStack-Neat, un' estensione per il consolidamento dinamico delle virtual machines tramite il metodo live migration: l' obiettivo principale è quello di ottimizzare l' utilizzazione delle risorse fisiche riducendo il consumo energetico con la migrazione delle VMs. Tale problema può essere diviso in 4 sotto-problemi [10]: 1. Decidere quando un host è considerato underloaded, in modo che tutte le macchine virtuali dovrebbero essere migrate da esso e l'host deve essere commutato in una modalità a bassa potenza, come la modalità sleep. 2. Decidere quando un host è considerato overloaded, in modo che alcune VMs dovrebbero essere migrate in altri host per evitare il degrado delle prestazioni. 3. Selezione delle VMs che devono migrare da un host overloaded. 4. Posizionamento delle macchine virtuali selezionate per la migrazione verso altri host attivi o ri-attivati. 21

22 2.2.3 Controller Node HA Come descritto precedentemente un nodo controllore è composto dai servizi API, keystone, state database e message queues ( RabbitMQ ). Separare questi servizi in server fisici differenti è una buona idea, soprattutto per l' high availability; nel caso della separazione di uno storage, è possibile dedicargli server fisici differenti, aventi hardware ottimizzati per quel determinato compito ( non dobbiamo preoccuparci di avere una elevata CPU e RAM ), inoltre rende più semplice l' aggiunta di un nuovo disco nel cluster storage ( aumento di scale-out ); lo stesso discorso vale anche per gli altri servizi. D' altronde la separazione implica un aumento di costo dell' hardware e gestione dello stesso, che non è sempre possibile ottenere. Genericamente si preferisce, hardware e budget permettendo, separare i vari componenti, soprattutto per quanto riguarda lo storage e i message queues essendo componenti critici per un' infrastruttura API services Rappresentano tutti i servizi api dei componenti OpenStack, quindi nova-api, glance-api, cinder-api, keystone-api. E' un servizio stateless e, perciò, non è difficile attuare meccanismi per l' high availability. Tipicamente, la community di OpenStack, incluso Cisco, RackSpace e SUSE, consiglia di avere almeno tre repliche di questi servizi ( quindi 3 controller node ). Possono essere configurati in modalità attivo-passivo e attivo-attivo. 22

23 Per la realizzazione della prima configurazione bisogna eseguire i seguenti passi per ognuno dei servizi: Selezionare e assegnare un indirizzo IP virtuale al servizio API; configurare il servizio per l' ascolto all' indirizzo VIP ( virtuale ); aggiungere la risorsa ( il servizio API ) al cluster Pacemaker; gestione del demone API con Pacemaker; configurazione dei servizi api per utilizzare questo indirizzo IP. Terminata questa procedura si creerà una risorsa, per esempio nel caso del cinder-api, p_cinder-api per gestire il servizio. In modalità attivo-attivo, la configurazione più comune è scalare orizzontalmente questi servizi su almeno due nodi e utilizzare il bilanciamento del carico e IP virtuale per distribuirlo equamente tramite HAProxy. Dopo aver installato le repliche di un servizio e assegnatogli un indirizzo virtuale, nel file di configurazione di HAProxy si dovrà includere: E' la modalità più utilizzata dalla community poiché diminuisce la probabilità dell'evento bottleneck ( collo di bottiglia causato da un intenso traffico ) e una più veloce procedura di failover ( questo vale in generale per qualsiasi servizio configurato in modalità attivo-attivo rispetto a quello attivo-passivo ). 23

24 State Database Il database è fondamentale per molti componenti di OpenStack. Viene utilizzato come repository per molti dati su cui opera l' infrastruttura, perciò il suo fallimento può causare perdita dei dati; quindi è un singolo punto di fallimento (SPOF) e bisogna utilizzare meccanismi per l' high availability. Il database più utilizzato dalla community di OpenStack, MySQL, non ha meccanismi per l' high availability, ma esistono dei rami dello stesso, come il Percona, Galera o attraverso DRBD, che forniscono: High availability; stabilità dei dati; prestazione; monitoring; gestione. In configurazione attivo-passivo le linee guida di OpenStack utilizzano DRBD per la sincronizzazione delle repliche e Pacemaker, per la gestione del cluster. DRBD (Distributed Replicated Block Device) è un sistema per l'archiviazione replicata e distribuita per la piattaforma Linux, viene normalmente utilizzato per l' high availability dei clusters. 24

25 I passi da eseguire sono: Configurare DRBD per l' utilizzo con MySQL; creare un filsystem per MySQL ( tipicamente xfs,ext3 o ext4 ); selezionare e assegnare un VIP; configurare MySQL ad ascoltare questo indirizzo IP; aggiungere tutte le risorse, compreso il demone MySQL al cluster Pacemaker; La figura seguente mostra tale configurazione [11]: Illustrazione 7: Configurazione attivopassivo di MySQL con DRBD e Pacemaker 25

26 Per la configurazione attivo-attivo le linee guida di OpenStack danno come soluzione l' utilizzo di MySQL Galera, un plug-in per la replicazione sincrona e multi-master per InnoDB ( quindi limitato solo a MySQL InnoDB ). Per interfacciarsi con Galera sono state definite le API per la replicazione nel progetto wsrep API. Per il bilanciamento del carico si utilizza HAProxy. Le caratteristiche di Galera sono: Replica sincrona; topologia multi-master attivo-attivo; leggere e scrivere su qualsiasi nodo del cluster; controllo automatico di appartenenza, dei nodi falliti dal cluster; joining automatico di un nodo nel cluster; replica parallela. Illustrazione 8: MySQL Galera multimaster in modalità attivo-attivo 26

27 Messages Queues ( RabbitMQ ) HA AMQP è la tecnologia di messagistica scelta da OpenStack per far comunicare l' intero cloud. Le linee guida consigliano l' utilizzo di RabbitMQ ma esistono altre tecnologie che implementano il protocollo AMQP come Qpid di Red Hat e ZeroMQ. Se il broker RabbitMQ consistesse in un singolo nodo si avrebbe un singolo punto di fallimento ( SPOF ). Inoltre, anche se si avessero più nodi non sincronizzati e uno di questi si guastasse, si perderebbero le code e i messaggi al loro interno; per questo è considerato un servizio stateful e necessita di una sincronizzazione con le repliche per garantire l' high availability. Come meccanismo per garantire l' high availability di RabbitMQ,OpenStack raccomanda l' utilizzo della configurazione attivo-passivo, accompagnata da DRBD, per la sincronizzazione delle code con il nodo passivo, e Pacemaker, per la gestione del cluster, ovviamente insieme a Corosync. 27

28 Secondo il sito di rabbitmq [12] tale configurazione garantisce l' high availability e il recupero del nodo guasto, ma il nodo passivo potrebbe richiedere molto tempo per avviarsi o potrebbe anche non farlo. Esiste un altro approccio, conosciuto come active-active mirrored queues che, invece, è raccomandato dagli sviluppatori di rabbitmq. Questa configurazione consente di avere più nodi attivi e permette alle code il mirroring, cioè la replicazione delle stesse in altri nodi che fanno parte del cluster di RabbitMQ. Il risultato è che quando un nodo del cluster fallisce la coda può passare automaticamente ad uno dei mirrors e continuare ad operare, senza indisponibilità del servizio ( zero downtime ). Questa soluzione però non è raccomandata per l'uso in una rete WAN; inoltre è stato testato dalla community di OpenStack che l' approccio active-active mirrored mostra minore consistenza e affidabilità della configurazione attivo-passivo nel cluster di OpenStack; ecco perché la community di OpenStack raccomanda ancora l' utilizzo della modalità attivo-passivo e si spera, quando risulterà essere più matura, di poter utilizzare l' altra. 28

29 Object storage, Swift Il servizio swift permette la memorizzazione e il recupero di file, che rappresenta come oggetti. Swift offre meccanismi per l' high availability tramite i ring, le partizioni e le zone. Un ring è una struttura logica che si occupa di mappare i singoli oggetti alla loro posizione fisica; rappresenta lo spazio di tutti i valori hash calcolati divisi in parti equivalenti, le partizioni. Il concetto di partizione serve ad assicurare una equa distribuzione dei dati in quanto ognuna di esse sarà distribuita a tutti i dispositivi. Ogni partizione viene replicata, per default, 3 volte e risiederanno in zone differenti, dove la zona può rappresentare un disco, un server o anche un datacenter. L' unico componente di swift che non supporta meccanismi per l' high availability è il Proxy server, colui che gestisce tutto il componente swift e fornisce i servizi API. A tal proposito esistono, come per qualsiasi servizio API, due configurazioni: attivo-attivo e attivo-passivo. Il primo si implementa utilizzando Pacemaker e Corosync, e il secondo utilizzando 29

30 2.2.4 Neutron HA La componente di OpenStack che gestisce il networking è Neutron. Fino alla release Folsom il compito era affidato a nova-network, un componente di Nova. Il cambiamento è avvenuto per alleggerire il componente Nova diminuendo così la sua complessità ( modularità ). Inoltre, Neutron è un API-based network connectivity as a service, che dà la possibilità agli users di poter creare e gestire le proprie reti garantendo l' isolamento tramite VLAN o GRE segmentation. Nova-network, rispetto a Neutron, è un componente più complesso da configurare e gestire, essendo un unico processo monolitico, mentre Neutron ha vari componenti che rendono la gestione più semplice e l' implementazione dell' high availability può essere risolta singolarmente. Tuttavia, in ambito di high availability, il passaggio da nova-network a Neutron ( prima chiamato Quantum ) non è stato così semplice e ancora ora alcune organizzazioni continuano ad utilizzare nova-network. I motivi principali sono stati: Neutron ( Quantum ) non implementava il mulsti-hosting; non c'era uno scheduler per poter gestire piu agenti attivi; anche se più semplice e user-facing, non offriva meccanismi per l' high availability; 30

31 Dalla release Grizzly, OpenStack ha aggiunto un nuovo componente creato per la schedulazione delle richieste sui vari agenti attivi nell'infrastruttura: Quantum scheduler. Con esso è stato possibile iniziare ad implementare un multi-hosting in cui ogni componente aveva il compito di informare al quantum server, attraverso dei messaggi periodici, la propria salute. Inizialmente ci sono stati dei problemi, soprattutto per quanto riguarda i messaggi periodici. Dalla release Havana la maggior parte dei problemi sono stati risolti e, come attesta launchpad.net, nova-network può essere considerato deprecato. La figura seguente mostra il blueprint di launchpad: Illustrazione 11: Blueprint di Launchpad.net: +spec/deprecate-nova-network L' ultimo problema da risolvere del tutto, come annuncia launchpad, è l' high availability e in particolare l' implementazione di meccanismi per fornire una migrazione automatica dei singoli componenti di Neutron. Tuttavia, è da precisare che tale articolo è stato pubblicato nell'aprile del 2013, prima che Havana venisse rilasciata. Ad oggi sono state fornite soluzioni a tali problemi per ogni componente di Neutron. 31

32 DHCP agent OpenStack fornisce due soluzioni per l' high availability: attivo-passivo e attivo-attivo. La prima consiste nell' avere un solo DHCP agent attivo ( single-hosting ) per tutta l' infrastruttura OpenStack inserito nel network node. Le restanti repliche saranno passive e tramite Pacemaker e Corosync, si gestirà il cluster garantendo l' high availability. La seconda configurazione permette di avere più dhcp attivi che forniscono i servizi in maniera del tutto affidabile, scalabile e automatico ( multi-hosting high available ). E' possibile testare questa configurazione tramite l' interfaccia a linea di comando e eseguire una procedura di testing per l' HA di seguito riportata. Esempi di comandi per la gestione della rete: Tabella 1: Comando per mostrare la lista degli agenti in tutta l' infrastruttura: Tabella 2: Comando per mostrare la lista dei DHCP agents in una determinata network: Tabella 3: Comando per aggiungere un DHCP agent in una determinata network: 32

33 La procedura per testare l' high availability è la seguente: 1. Creare una rete e aggiungere ad essa due DHCP agent: uno relativo ad un Host A e l' altro ad un Host B. Creare una VM nella net creata; 2. accedere alla VM ed eseguire udhcpc, dhclient o qualsiasi altro client DHCP; 3. arrestare l' agente DHCP HostA; 4. eseguire un client DHCP in VM per vedere se è possibile ottenere ancora l'ip; 5. arrestare l' agente DHCP HostB; 6. eseguire udhcpc nella VM : non può ottenere l'ip; 7. attiva l' agente DHCP HostB. La VM ottiene nuovamente l' IP; L3 agent E' il componente che fornisce i servizi del livello 3 del modello OSI. Attualmente, è possibile utilizzare solo la configurazione attivo-passivo ( single-hosting ) per l' high availability, in cui un solo agente ha il compito di gestire tutta la rete dell' infrastruttura. Come per il DHCP, tale configurazione è ottenibile aggiungendo il cluster l3 agents a Pacemaker e Corosync per la sua gestione. Tuttavia è comunque possibile avere più agenti L3 attivi. Ad un agente L3 si possono assegnare più router virtuali, ma ognuno è gestito da un solo agente. Questo comporta che ognuno di loro è un singolo punto di fallimento. Attualmente questa configurazione non offre meccanismi per l' high availability. 33

34 OpenStack foundation ha sollevato questo problema introducendo una prima soluzione ad esso, come è possibile leggere nella documentazione di OpenStack: Neutron/L3 High availability VRRP [13]. Tuttavia, tale soluzione è solo in fase di analisi e quindi bisognerà aspettare nelle prossime release una sua effettiva implementazione. In principio, si basa sull' high availability dei router virtuali: ogni router virtuale è assegnato ad uno e un solo agente L3. In caso di guasto di un agente, tutti i router virtuali associati ad esso falliranno e, quindi, tutte le macchine virtuali connesse a questi saranno isolate. Panoramica generale Lo scopo principale è quello di risolvere il problema aggiungendo un nuovo tipo di router, che sarà generato due volte su due diversi agenti. Un agente sarà responsabile della versione master di questo router e un altro agente L3 sarà responsabile del router slave. Due nuove interfacce saranno aggiunte a ciascun router virtuale per consentire scambi di traffico amministrativi, come lo stato di salute dei router o sessioni TCP. Le interfacce originali, interne ed esterne, saranno trasformate come interfacce VIP. Keepalived verrà utilizzato per gestire le interfacce VIP mentre Conntrackd verrà utilizzato per mantenere le sessioni TCP. Quando un router virtuale fallisce, il driver VIP invierà una notifica al controllore, che provvederà a migrare la copia fallita in un altro agente L3 ponendolo in modalità slave, mentre l' altra copia, che era in modalità slave, diventerà master. 34

35 L2 agent Il componente Neutron introduce due componenti: il plug-in e L2 agent. Il primo è caricato in fase di esecuzione da parte del servizio Neutron, elabora tutte le chiamate API e memorizza il conseguente modello logico dei dati in un database back-end. Il secondo viene eseguito su ogni nodo di calcolo. Questo agente raccoglie la configurazione dal database centrale e comunica direttamente con l'istanza locale del plug-in per implementare il modello logico dei dati. Un plug-in può utilizzare una varietà di tecnologie per attuare le richieste API logiche. Alcuni plug-in di rete possono utilizzare Linux VLANs, mentre altri possono utilizzare tecnologie più avanzate, come L2-in-L3 tunneling o OpenFlow. Nella versione Havana, OpenStack Networking fornisce Layer Modular 2 ( ML2 ) plug-in che può contemporaneamente utilizzare più tecnologie di rete del layer 2; attualmente collabora con Open vswicth, Linux bridge e Hyper-V. Il quadro ML2 semplifica l'aggiunta del supporto per le nuove tecnologie L2 e riduce lo sforzo che è necessario per aggiungerle e gestirle. Con l' introduzione della versione Havana, Open vswicth e Linux Bridge risultano obsoleti e nella versione icehouse saranno rimpiazzati da ML2 plug-in. Un agente L2 viene eseguito su ogni nodo e controlla le sue interfacce virtuali. Ecco perché non può essere distribuito e quindi non ha meccanismi per l' high availability Neutron Server E' il componente che gestisce l' architettura di Neutron. Fornisce i servizi API. Accetta le richieste e le inoltra al plug-in corretto. Utilizzare un solo server comporterebbe un singolo punto di fallimento quindi occorrono meccanismi per l' high availability. Esistono due configurazioni: attivo-passivo e attivo-attivo. La prima può essere gestita tramite Pacemaker e Corosync; la seconda, invece, tramite HAProxy per un bilanciamento del carico ottimizzato. 35

36 Neutron scheduler Neutron scheduler determina quali agenti saranno responsabili della creazione e della gestione dei tenants networks. 36