OpenStack – Introduzione

OpenStack Cloud Software

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

                                                     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.

Mesosphere e la scalabilità dei Data Center

Mesos(sphere) Data Center scalabili

Mesos(sphere) Data Center scalabili

Mesosphere , per chi ancora non la conoscesse, è una startup con sede a San Francisco che si è concentrata sullo sviluppo di un sistema operativo per garantire la scalabilità di un Data Center attraverso il componente open source Apache Mesos, nato dalle viscere della UC Berkeley e già adottato e riadattato nell’uso da giganti del calibro di Twitter, eBay e Airbnb ed anche Apple, che ha ricostruito il progetto SIRI proprio sulla piattaforma tecnologica di Mesos.

L’obiettivo di Mesosphere è semplice, ossia rendere Mesos e le tecnologie a esso affini adatte all’uso anche nelle piccole enterprise, cioè in tutte quelle realtà che non possono permettersi un esercito di ingegneri pronti a prototipare e mettere in produzione un sistema proprietario. In questo modo, anche le piccole realtà potrebbero godere dei vantaggi di cui gode Google, tanto per citarne uno (a caso), che ha sviluppato la tecnologia proprietaria BORG, ossia un substrato software capace di orchestrare le applicazioni, suddividendone l’esecuzione fra tutte le risorse disponibili nei data center globali dell’azienda.

Per capire meglio come funziona BORG e come funziona Mesosphere, basti pensare a tutti i servizi che Google mette a disposizione della propria utenza, come Google Search, Gmail, Google Maps, YouTube e via discorrendo. Mountain View ha organizzato tutte queste applicazioni in modo che condividessero i workload fra tutte le risorse di tutti i data center della società, evitando di assemblare dei cluster separati di server per ogni servizio. [Elementi fondamentali, i workload, nella progettazione del moderno ambiente IT, infatti un buon design dei workload serve per permettere alle applicazioni di essere eseguite con maggior efficienza].

Cosi come il segreto della scalabilità dei servizi di Google sembra risiedere in BORG, Mesosphere punta alla scalabilita’ dei Data Center e, lavora per offrire un sistema operativo per Data Center anche a chi non ha le opportunità di investimento al pari di Mountain View.

Il nome di questo sistema operativo e’ DCOS, ossia Data Center Operating System, il quale è capace di astrarre CPU, memoria, storage e altre risorse computazionali dai server fisici, per riunirli in una piattaforma di gestione unica e facilmente scalabile. Secondo Mesosphere, questo sistema operativo, attualmente in fase beta, permette agli amministratori IT di scalare i cluster data center aggiungendo fino a 50 mila server.

La base del DCOS è un insieme di strumenti open source di cui molti disponibili via Apache Licenses. Questi tools giacciono su un sistema kernel distribuito, che offre le API necessarie alla gestione e all’organizzazione delle applicazioni distribuite. Fra i componenti del nuovo sistema operativo per il cloud computing ci sono un init system distribuito (Marathon), un pianificatore di attività distribuito (Chronos) e un service discovery (DNS). L’architettura supporta già ed è compatibile con Apache Spark, Apache Cassandra, Kafka, Hadoop, YARN, HDFS e Google Kubernetes.

La flessibilità del nuovo sistema operativo di Mesosphere è comprovatadalla capacità di supportare tutte le versioni Linux più recenti delle distribuzioni CoreOS, CentOS, Ubuntu e Red Hat e, dalla possibilita’ di poter essere eseguito su bare metal o in un ambiente di private cloud virtualizzato su alcuni dei più importanti cloud provider come AWS, Google Compute Engine, Digital Ocean, Microsoft Azure, Rackspace e VMware vCloud Air e, dal supporto ad altri strumenti di gestione data center come OpenStack, Docker, Cloud Stack e VMware vCenter Orchestrator.

La crescita di Mesosphere è garantita da una serie di finanziamenti per startup, di cui l’ultimo ricevuto è pari a 10 milioni di dollari. Il nuovo finanziamento, permetterà quindi a Mesosphere di uscire dalla fase beta e proporre DCOS in due differenti versioni, una a pagamento offerta con supporto tecnico e servizio di consulenza e una gratuita per la community.

 

#MesosilnuvoSystemperDataCeter

Ansible per l’automazione IT ed il Configuration Management

Ansible e l’automazione IT

Ansible e l’automazione IT

Ansible e’ un tool di Configuration Management ed IT Automation che sta riscuotendo un notevole successo tra gli addetti ai lavori in virtu’ della sua immediatezza, della sua semplicita’ di utilizzo e del superamento delle limitazioni della tipica configurazione basata su “server & agent”.

Che cos’e’ Ansible

Ansible quindi e’ un tool di Configuration Management ed IT Automation che rientra nella sfera degli strumenti tipici del metodo DevOps.

DevOps e’ un movimento nato per abbattere il muro di gomma che nel corso degli anni si e’ innalzato tra Developer e Sysadmin. Per usare un’analogia, DevOps e’ una cultura che ha lo scopo di creare una pipeline (in pratica un ponte di comunicazione) tra sviluppatori ed amministratori di sistema.

L’obiettivo e’ uno solo: aumentare costantemente la soddisfazione del cliente producendo ed erogando software allo stato dell’arte con continue release correttive.

Per raggiungere un obiettivo cosi’ ambizioso e’ importante poter contare non solo sulle persone ma anche sugli strumenti. Cosi’ sono nati tool agili ed intuitivi che hanno lo scopo di automatizzare lo sviluppo, il testing e la configurazione di server ed applicazioni. Questa famiglia di tool per il Configuration Management comprende gia diversi nomi blasonati come ad esempio Puppet, Chef, Saltstack e CFEngine.

Configuration Management in breve

Il Configuration Management e’ un processo utilizzato per definire la configurazione delle applicazioni web e dei server in modo consistente, possibilmente sotto controllo di versione. Con il Configuration Management e’ possibile definire a priori come dovra’ essere configurato il server X o l’applicazione Y. Il tutto in linguaggio sorgente o sotto forma di meta-linguaggio.

I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o piu’ server, in modo automatico e prevedibile.

Esempio:

inizio configurazione
1 assicurati che apache2 sia installato
2 assicurati che php5 sia installato
3 assicurati che mysql sia installato
fine configurazione

Un tool di Configuration Management puo’ leggere queste istruzioni ed applicarle su uno o piu’ server. In questo modo l’operatore puo’ replicare la stessa configurazione su decine di server oppure ricostruire la stessa in pochi secondi quando uno o piu’ server vengono messi fuori uso.

Ansible, un po’ di storia

Lanciato nel 2012, Ansible  nasce da un’idea di Michael de Haan, creatore tra l’altro di Cobbler. De Haan un bel giorno sente la necessita’ di scrivere un software che potesse semplificare all’ennesima potenza le attivita’ di Configuration Management ed Automazione IT.

Fino a quel momento il panorama del Configuration Management era dominato da Puppet e Chef (che comunque mantengono e sicuramente manterranno  anche in futuro quote di mercato molto vaste). Ma seppure ottimi, sia Puppet che Chef hanno alcuni punti deboli, che fanno storcere il naso ai Sysadmin piu’ esigenti:

* Puppet e Chef funzionano principalmente in modalita’ server – agent

* Chef richiede anche la conoscenza del linguaggio Ruby

Anche se non si tratta di limitazioni insormontabili ci sono comunque alcuni svantaggi in questo tipo di approccio.

Prima di tutto non sempre e’ possibile installare un agent sul server di destinazione, poiche’ un agent e’ comunque un piccolo software che rimane in esecuzione permanente su uno o piu’ server ed ha lo scopo di attendere comandi e configurazioni impartite dal server master.

Sia Chef che Puppet utilizzano questo approccio che spesso non e’ possibile mettere in pratica.

Pensiamo ad esempio ad ambienti server che per ragioni di conformita’ o sicurezza non possono ospitare agenti o software estranei oppure a quei server con un discreto numero di anni sulle spalle, dove l’installazione di una versione aggiornata di Ruby (richiesta, ad esempio, da Puppet) potrebbe causare effetti imprevedibili.

I vantaggi di Ansible

Perche’ dunque adottare Ansibile ?
Se sei un Sysadmin o un Developer potrai trarre sicuramente grande beneficio dall’uso di questo tool: con Ansible non e’ mai stato cosi’ semplice definire lo stato di un server e delle tue applicazioni web.
Con Ansible quindi il risparmio di tempo e di codice e’ notevole rispetto a Puppet o Chef.

Curva di apprendimento bassa

Dalla lettura della documentazione alla scrittura dei primi Playbooks il passo sara’ breve, ed in pochi minuti vi sara’ possibile iniziare a lavorare con Ansible senza dover penare con configurazioni di server Master e agenti vari.

Non sono richieste capacita’ di coding

Puppet e Chef nascono entrambi da un team di sviluppatori follemente innamorati di Ruby. Per la definizione dello stato dei server e delle configurazioni Puppet adotta un linguaggio simile al codice Ruby mentre per definire lo stato di un server con Chef e’ addirittura essenziale conoscere il linguaggio, invece Ansible supera completamente questa limitazione.

In Ansible ad esempio e’ possibile definire che il server X dovra’ contenere Apache con due righe:
es:

Install Httpd
yum: name=httpd state=latest

Come si puo’ notare, a differenza di Puppet, Chef e Saltstack, Ansible non ha bisogno di nessun agente per applicare le configurazioni su un server. Ansible utilizza di default il trasporto SSH: questo elimina la necessita’ di installare software estraneo sui nodi.

Modulare e Open Source

Ansible e’ composto da numerosi moduli. Per analogia i moduli di Ansible hanno la stessa funzione delle risorse in Puppet. Ogni modulo svolge delle funzioni ben precise e gestisce un singolo aspetto di ogni sistema. Questa architettura consente di espandere Ansible praticamente all’infinito, senza contare che i moduli possono essere scritti in qualsiasi linguaggio di programmazione. Inoltre Ansible e’ Open Source e la comunita’ continua a crescere rapidamente.

Ansible, i concetti chiave

Prima di terminare con questa introduzione su Ansible vediamo quali sono i concetti chiave ed i componenti che ruotano attorno a questo software.

Ansible: l’inventario

L’inventario e’ una lista di server sui quali Ansible applica, a comando, le configurazioni di sistema e le istruzioni di automazione. L’inventario di solito e’ contenuto all’interno del file /etc/ansible/hosts anche se e’ possibile specificare una posizione a piacere.

All’interno dell’inventario l’operatore puo’ specificare la lista dei server “bersaglio”. E’ chiaramente obbligatorio che ogni server abbia una corrispondenza DNS anche se e’ possibile specificare ogni server con il proprio indirizzo IP . Un esempio di inventario:

[webservers]
webserver1.example.com
webserver2.example.com

[dbservers]
dbserver1.example.com
dbserver2.example.com

Ansible ed i Tasks

In Ansible i Tasks sono dei “compiti” ovvero una serie di istruzioni che Ansible esegue in ordine di apparizione. Ogni istruzione contiene la definizione e/o la configurazione che dovra’ essere applicata ad ogni sistema.

Ansible e gli Handlers

Gli Handlers in Ansible sono delle istruzioni che vengono eseguite a seguito di una determinata azione. Ad esempio dopo aver installato httpd un operatore puo’ voler avviare Apache automaticamente. Un esempio di Handler che avvia Apache su CentOS:

name: start httpd
service  : name=httpd state=started enabled=yes

Gli Handlers si basano sul modulo service di Ansible (questo modulo viene utilizzato per gestire i servizi di sistema).

Ansible ed i Playbook

In Ansible i Playbook sono delle collezioni di Tasks. Ogni Playbook puo’ contenere un determinato numero di Tasks e di Handlers. I Playbook devono essere definiti in linguaggio YAML.


Ansible ed i Moduli

Ansible e’ composto da numerosi moduli. Esistono moduli per gestire i servizi di Cloud Computing (EC2 su AWS), Rackspace e Google Compute Engine, esistono moduli per installare pacchetti software su server Linux con apt e yum, moduli per gestire file di configurazione e database e molto altro ancora.

Per una lista completa dei moduli puoi consultare la documentazione ufficiale: Ansible Modules.

#AnsibleConfigurationManagement

GreenSQL ora su AWS

Greensql_AWSbigGreenSQL offerta Database Secutiry su Amazon Web Services (AWS)

9 Luglio 2014, GreenSQL, azienda leader nelle soluzioni di sicurezza dei dati (DB), ha annunciato al mondo la disponibilita’ di una soluzione appositamente pensata per la piattaforma AWS, per l’appunto ” GreenSQL per AWS ” pronta a dare tutta la potenza ed i livelli di sicurezza certificati da GreenSQL sia in locale che ora anche nel Cloud.

Le caratteristiche principali sono le seguenti :

  • Versione del prodotto (ad oggi) 2.6.7
  • Sistema Operativo Linux / Unix, Linux Amazon 2.014,03
  • Architettura64-bit Amazon Macchina Image (AMI)
  • Servizi AWS AmazonEC2, AmazonEBS


Descrizione del prodotto
(alcuni interessanti video si possono trovare sul canale Youtube di GreenSQL)

GreenSQL fornisce soluzioni avanzate di sicurezza per database, proteggendoli da attacchi di SQL injection (ad esempio SSN, numeri di carte di credito, e-mail, password amministrative ecc…), mascherando i dati sensibili e monitorando costantemente la veridicita’ dei dati di accesso degli utenti che dovranno soddisfare vari livelli di conformita’ a normative quali PCI e HIPAA. Una volta installato come front-end delle vostre applicazioni web nel Cloud, GreenSQL sara’ in grado di mimetizzare perfettamente e proteggere le applicazioni, i database ed i dati in essi contenuti, questo poiche’ GreenSQL e in grado di individuare automaticamente e mascherare i dati sensibili memorizzati nel database.

Inoltre e’ in grado di:

– bloccare in tempo reale tutte le SQL injection rilevate;  

–  monitorare le attività sul database eseguite dagli amministratori di sistema e dai DBA

– attuare la separazione delle funzioni creando le regole base per le restrizioni di accesso ai dati filtrando ed accoppiando le utenze ad apposite liste d’indirizzi IP geografici ….

Se quello che avete letto vi incuriosisce e volete saperne di piu’ in merito vi invito a leggere gli articoli precedenti su GreenSQL quali :