Qualche settimana fa all’interno del nostro blog abbiamo dedicato un articolo dal titolo Cloud Computing o infrastrutture tradizionali? Erano rimaste in sospeso due domande fondamentali da rivolgere al nostro Head of Infrastructure, Ettore Simone, che continuerà a guidarci nel mondo di OpenStack.

Riprendiamole:

La soluzione Fluctus di E4 si basa sulla versione stabile prodotta dalla community. Ma quanto è etico da parte di una azienda come E4 cercare di far soldi su un prodotto creato liberamente e gratis da una community?

Inoltre, perché scegliere E4, un’azienda così piccola? E soprattutto, in caso di bisogno di supporto, chi risponde?

Ettore Simone: OpenStack è un framework molto ampio, composto da moltissimi componenti specializzati, ciascuno orientato alla risoluzione di un particolare aspetto del Data Center. Il modello di sviluppo su cui si basa – più unico che raro! – prevede che le API di interazione tra questi moduli sia specificata prima ancora dell’implementazione stessa del componente. Da questo deriva che la matrice di composizione dei vari moduli, e le relative interazioni, possa essere alquanto complessa e, al contempo, incredibilmente elastica.

Dato che questi componenti vanno poi inseriti all’interno di realtà aziendali e infrastrutturali, che hanno delle esigenze specifiche, E4 entra in gioco grazie alle sue competenze. Esperienze derivate da anni in cui implementa soluzioni OpenStack nelle infrastrutture industriali complesse. Sappiamo, dunque, benissimo cosa fare per far funzionare questo oggetto nel modo più efficace in ambienti produttivi e mission-critical.

Questo si traduce nel fatto che l’industrializzazione di Fluctus è molto orientata ad essere una soluzione ready-to-use dal giorno 1 e già testata in ambienti controllati. Il nostro OpenStack viene proposto in una configurazione già testata e garantita.

La parte etica sta nel fatto che, gli sforzi di E4 nel rendere OpenStack un prodotto aderente alle esigenze di enti ed industrie, si traduce in una contribuzione verso la community dei miglioramenti ottenuti. Nonostante le licenze BSD e Apache su cui si basa OpenStack non obbligano il rilascio del codice modificato come nel caso della licenza GPL, E4 si impegna a pubblicare ogni miglioramento e bug fix come contributo alla Open Infrastructure Foundation (successore della OpenStack Foundation).

Il concetto di Open Source è molto simile al concetto di libera comunicazione e interscambio delle scoperte scientifiche. Tutte le soluzioni software Open Source mirano a risolvere un problema specifico e fanno sì che tutta la comunità ne benefici, garantendo un circolo virtuoso che permette di rilasciare continui miglioramenti delle soluzioni e, soprattutto, accessibili a tutti.

A questo punto la domanda è: con questi rilasci migliorati alla community, non si rischia di “far beneficenza” e avvantaggiare anche i concorrenti?

Ettore Simone: Questo rischio c’è. L’obiettivo dell’Open Source è quello di far migliorare l’intera comunità mondiale. Non è raro trovare similitudini anche in altri settori. Prendiamo l’edilizia: molte tecniche di costruzione si sono diffuse nella storia trasversalmente a tutti i costruttori, che hanno permesso uno stile di vita sempre più comodo e sano. Nei casi specifici poi la differenza la fa il costruttore stesso, con la sua personale interpretazione delle tecniche ed il suo particolare estro creativo.

Grazie. Chiaro. Per quanto riguarda l’hardware cosa bisognerebbe usare?

Ettore Simone: Queste soluzioni possono funzionare su hardware commodity. Quindi su piattaforme x86. Ma senza problemi si estendono anche al mondo Power o ARM, ad esempio. E4 ha delle versioni ottimizzate delle sue soluzioni dove al software è abbinato anche l’ hardware più corretto, testato, e allineato all’erogazione dei servizi richiesti dal cliente.

Nelle soluzioni proposte da E4 anche l’hardware viene ottimizzato per lo scopo: quanta memoria, quanto storage, quale processore, quale network, quanti nodi. Sono soluzioni che E4 fornisce in pochissimo tempo, anziché far spendere al cliente mesi di analisi per capire quale sia l’hardware da adottare o il disegno architetturale più adeguato. Possiamo così soddisfare efficacemente le più disparate esigenze: dai piccoli sistemi Iper-Convergenti orientati all’Edge o alle piccole e medie imprese, ai sistemi distribuiti e scalati su centinaia, se non migliaia, di nodi.

Bene. Passando ad altri temi: ci sono dei vantaggi sicuramente nell’uniformare e centralizzare l’orchestrazione, ma a livello di security, avere questa centralizzazione non è un rischio? Non c’è troppa democratizzazione?

Ettore Simone: Il lavoro che si fa in un ambiente di Private Cloud o in una infrastruttura tradizionale non è diverso. La differenza sta nel fatto che, ad esempio, il tecnico che è adibito alla gestione del networking ha davanti una semplificazione nella gestione dei suoi apparati e una visione complessiva di tutto quello che è lo strato della rete, indipendentemente da cosa sia composta. In una infrastruttura più tradizionale, invece, i tecnici di rete hanno più specializzazioni e si occupano di parti diverse della tecnologia, con il rischio di avere gap di comunicazione.

Il mondo Cloud offre un filo conduttore che permette di inanellare i vari componenti ed esporre una visione strutturata dell’ambiente complessivo, permettendo a meno persone di poter gestire infrastrutture più complesse.

Il pericolo di far danni esiste, ma solo se l’infrastruttura non è configurata correttamente, alla stregua di qualsiasi ambiente informatico. Gli strumenti per una corretta e sicura gestione dell’infrastruttura in un Private Cloud sono molti di più rispetto a quelli di un’infrastruttura tradizionale (solitamente affidati alle persone o a documenti scritti).

Nelle Infastructure-as-a-Service, invece, è possibile avere più granularità sui permessi, oltre che offrire la possibilità di “dichiarare” con specifici linguaggi la forma dell’infrastruttura ed avvalersi finalmente di metodologie DevOps e Infrastructure as Code per garantire ciò che ancora oggi per molti sistemisti è utopia: la riproducibilità delle infrastrutture e la supervisione del processo di definizione delle stesse.

E4, con Fluctus, ridimensiona enormemente il gradino da salire per accedere a questo mondo. Le configurazioni iniziali, il design infrastrutturale, le interazioni tra i vari componenti, sono già presenti. I nostri esperti studiano continuamente le esigenze dei clienti, i quali vengono aiutati a trovare la soluzione che meglio risponde alle loro esigenze. Infine Il team di E4 forma il cliente e trasferisce le conoscenze necessarie per essere autonomo.

Un’infrastruttura così vasta è sicuramente mission-critical. Come posso proteggermi dai problemi di funzionamento. Posso fare un backup? Come ripristino il suo funzionamento?  

Ettore Simone: Questa domanda spalanca un’argomento molto vasto. Proverò ad accennare un paio di metodi con cui viene affrontato il problema:

• Resilienza
• Riproducibilità

In ottica di resilienza, ossia la capacità di un sistema di “assorbire” shock e di sopravvivere ad essi, le infrastrutture di Private Cloud offrono arsenali molto efficaci e modulari, che ci permettono di affrontare il problema da varie angolature.

Possiamo, ad esempio, scomporre l’intera infrastruttura in sottosistemi più piccoli. Autonomi magari in termini di storage e power supply, ma comunque connessi allo stesso back-plane di controllo e networking, in modo tale da risultare comunque parte di un unico sistema; quello che spesso viene identificato con il termine region in molti Cloud Provider.

Il vantaggio ti tale scomposizione è quello di permettere la distribuzione di sistemi in HA, i cui nodi possono insistere su regioni indipendenti, permettendo un eventuale fail-over anche in caso di totale down in una particolare area. Otterremo quello che può essere definito una Business Continuity.

Con lo stesso modello possiamo facilmente riprodurre nella seconda regione i workload presenti nella prima. Sia in modalità preventiva (sistemi in stand-by con basso RTO), ovvero capaci di prendere servizio in breve tempo dopo aver premuto il “pulsante rosso”; sia in modalità reattiva (ad esempio con procedure di disaster-recovery con RTO maggiore del precedente) dove i workload sono riprodotti con qualche forma di automazione.

É possibile la distribuzione anche geografica di tali regioni, ma non vorrei dilungarmi troppo sull’argomento.

La riproducibilità dell’infrastruttura è garantita dagli stessi meccanismi con cui essa viene messa in opera.

Il back-up completo dell’infrastruttura (ed è qui doveroso precisare che non parliamo di ciò che contiene (VM, virtual appliance, volumi storage persistenti, etc.), può paradossalmente essere contenuta in un solo floppy disk. Pochi “K” sono sufficienti per ricostruire totalmente l’ambiente in caso di disastro. É un tipico vantaggio delle infrastrutture software defined.

Il back-up del contenuto, ovvero le virtual machine, lo storage con i dati persistenti, e via discorrendo, è ottenibile attraverso molteplici meccanismi. Anche quelli più tradizionali.

La somma dei due livelli di back-up può garantire qualsiasi livello di RTO/RPO necessario. Livelli più o meno stringenti di Point o Time richiederanno naturalmente sistemi di storage più o meno veloci per ottenerlo.

La cosa interessante da questo punto di vista è proprio una possibile semplificazione di questi meccanismi dati proprio dalla struttura “cloud native” delle soluzioni di Infrastructure-as-a-Service. Cosa ne dite di fare back-up della Region A sull’Object Store della Region B che è distante 15K dalla prima? Perché non sfruttare le caratteristiche di replica “sincrona” dei volumi persistenti di OpenStack (Cinder) in regioni remote in modo da avere lo stand-by già presente in ottica di minimizzare i tempi di ripartenza del servizio?

La nostra intervista si conclude qui, per saperne di più, visitate la pagina dedicata alla nostra Open Source Cloud Platform FLUCTUS, o contattateci!