A metà aprile 2011 OpenStack ha rilasciato Cactus, terza release del progetto avviato a luglio 2010 da NASA e Rackspace sotto licenza Apache 2.0. La novità tecnica di peso è la live migration in Nova: una macchina virtuale si sposta da un compute node a un altro senza spegnerla. Il resto è consolidamento, ed è la parte che dice di più a chi vuole capire se regge in un ambiente vero. Scrivo questi appunti a fine mese, quando sono usciti i primi materiali architetturali e operativi su cui si ragiona davvero.

Contesto

Lo spazio Infrastructure-as-a-Service (IaaS) Open Source nel 2011 non è vuoto. Eucalyptus c’è dal 2008, con API compatibili Amazon EC2/S3 e licenza GPL; OpenNebula arriva dal mondo HPC europeo; Cloud.com pubblica CloudStack con un taglio più enterprise. OpenStack si distingue per il modello di rilascio: cadenza semestrale, codice pubblico, più vendor al tavolo — Austin a ottobre 2010, Bexar a febbraio 2011, ora Cactus.

Il problema che spinge verso il cloud privato è concreto. Chi ha vincoli normativi, esigenze di sovranità del dato o semplicemente un parco hardware già pagato non riesce a replicarsi il modello AWS in casa senza scrivere molto codice. OpenStack prova a dare i pezzi: Nova per il compute, Swift per l’object storage, Glance per il registro delle immagini.

Architettura di Nova

Nova è un insieme di demoni Python che dialogano in modo asincrono su una coda di messaggi e condividono lo stato attraverso un database SQL. La struttura, descritta nel dettaglio da Ken Pepple, va capita prima di decidere se adottarlo.

Il punto d’ingresso è nova-api: riceve le richieste REST, applica le policy (le quote, per esempio) e mette in coda le azioni. Lo nova-scheduler prende dalla coda una richiesta di istanza e decide su quale compute host farla girare. Lo nova-compute è il worker che crea e distrugge le VM per davvero, traducendo i messaggi in chiamate all’hypervisor. Accanto a questi ci sono nova-volume, che gestisce i volumi persistenti con un modello vicino ad Amazon EBS, e nova-network, che configura bridge e regole di firewall.

Sotto, due pezzi di infrastruttura: una coda AMQP (Advanced Message Queuing Protocol), oggi su RabbitMQ, e un database SQL che tiene lo stato di build e di runtime, con SQLite3, MySQL e PostgreSQL. I demoni non si parlano in modo diretto: pubblicano azioni sulla coda e leggono lo stato condiviso dal database. È questa scelta a rendere il sistema scalabile in orizzontale, perché posso avviare più nova-compute su nodi diversi senza toccare la topologia di comunicazione.

Sul fronte hypervisor, Cactus aggiunge LXC tramite libvirt e VMware/vSphere ESX/ESXi 4.1, oltre a XenServer e KVM già presenti. Le API REST di Nova ricalcano lo stile di EC2: una scelta deliberata, per togliere attrito a chi arriva da Amazon.

Il punto critico: il networking

La parte più delicata, e secondo me la più facile da sottovalutare, è nova-network. Nella documentazione di questo periodo i modelli sono tre, da scegliere con l’opzione --network_manager.

FlatManager non crea né bridge né VLAN: l’amministratore prepara a mano i bridge indicati alla creazione delle reti con nova-manage, e quel bridge deve esistere su ogni compute host. FlatDHCPManager ci aggiunge la gestione DHCP. VlanManager — il default, se non specifichi nulla — crea una VLAN gestita per progetto, assegna a ciascun progetto la sua subnet e avvia un server DHCP per subnet.

In pratica la scelta del network manager si trascina dietro requisiti sulla rete fisica — supporto VLAN sugli switch, bridge configurati allo stesso modo su tutti i nodi — che vanno verificati prima, non a deployment già acceso. In questa fase la rete vive dentro Nova: non c’è ancora un servizio separato e indipendente che se ne occupi.

Implicazioni

Per chi sta valutando un cloud privato adesso, Cactus guadagna terreno su due fronti concreti. La live migration di Nova rende possibile la manutenzione di un compute host senza fermare i carichi che ci girano sopra, cosa che prima chiedeva una finestra di downtime. Il serving statico aggiunto a Swift serve i contenuti direttamente dall’object storage, con un index.html nelle listing dei container, e nei casi semplici toglie di mezzo un web server davanti.

Sul piano organizzativo, la lista dei membri corporate che hanno aderito — HP, Dell, IBM, Intel, Canonical, Red Hat, SUSE, Cisco, tra gli altri — dice che il modello multi-vendor non è solo dichiarato. Quando scegli una tecnologia infrastrutturale con un orizzonte di anni, l’ampiezza dei contributori pesa quanto le feature: è lì che si gioca la probabilità di ritrovarsi il progetto ancora manutenuto fra qualche anno.

Limiti

Restano nodi aperti, ed è onesto dirli. Manca ancora un servizio di identity unificato: autenticazione e autorizzazione tra i componenti sono frammentate, e la cosa si sente quando vuoi un controllo accessi coerente su Nova, Swift e Glance insieme. Il networking, come detto, sta dentro Nova con i suoi vincoli sull’hardware. La documentazione operativa è disomogenea: parte di quella più utile per un deployment vero arriva da guide di terze parti — come quelle uscite in questi giorni per Ubuntu 11.04 — più che dai manuali ufficiali.

Per portarlo in produzione la domanda non è se OpenStack funzioni — Cactus funziona — ma quanto codice di colla e quanta competenza operativa servano per spostarlo dalla demo al carico reale. A metà 2011 la risposta è ancora “parecchia”, e va messa in conto.

https://wiki.openstack.org/wiki/ReleaseNotes/Cactus https://www.openstack.org/blog/openstack-announces-cactus-release/ https://ken.pepple.info/openstack/2011/04/22/openstack-nova-architecture/ https://cssoss.wordpress.com/2011/04/28/openstack-beginners-guide-for-ubuntu-11-04-network-management/

Immagine di copertina: Container modulare per data center con la scritta “Nebula” al NASA Ames Research Center, sede dell’infrastruttura cloud da cui nacque… — foto di Gretchen Curtis, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:NASA.Nebula.cloud.container.JPG