Se si guarda all’evoluzione delle tecnologie informatiche per individuarne una linea di sviluppo unitaria, si vede subito che questa non può che essere identificata nel crescente livello di astrazione che separa le risorse di memorizzazione e di elaborazione dei dati dall’uso che di queste stesse risorse si fa ai fini del servizio che se ne vuole trarre. In una parola, dall’interfaccia tra l’uomo e la macchina. Questa evoluzione, volta a fare del data center un ambiente dove persone dotate di normali capacità di programmazione possano creare soluzioni in grado di soddisfare efficacemente i bisogni del business anche senza un’approfondita conoscenza dell’hardware, ha avuto due tappe fondamentali con l’avvento prima delle macchine virtuali e dei sistemi operativi multi-utente nei sistemi centralizzati e poi dei computer industry-standard (x86) e delle reti Ethernet e Internet, che hanno spinto lo sviluppo dei sistemi distribuiti sui quali oggi si basa la quasi totalità dell’It delle imprese.
Le crescenti esigenze del business e la continua ricerca di nuove soluzioni in grado di spingerne la competitività hanno però creato una spirale di complessità che in pratica vanifica i vantaggi dati dall’attuale elevato livello di astrazione uomo-macchina e contro la quale i Cio e i responsabili delle infrastrutture e delle operazioni di data center conducono una battaglia quotidiana. Oggi però si prospetta un concetto di architettura infrastrutturale che può cambiare la situazione e che Forrester, in una sua recente analisi dedicata al tema e della quale ci siamo serviti per queste note, chiama ‘Software Defined Data Center’ (Sddc), definendolo come “un livello di astrazione integrato che descrive un completo data center tramite strati di software che presentano i sistemi del data center stesso come pool di risorse fisiche e virtuali componibili in servizi arbitrariamente definiti dall’utente”.
Il concetto di Sddc risale in realtà ai primi anni 2000 e ha un punto di svolta sul piano della sua realizzazione con l’implementazione di server di classe enterprise su piattaforme di virtualizzazione ‘commodity’ (VMware prima, poi Microsoft e altri), seguita da analoghe avanzate virtualizzazioni dei sistemi storage e dei tool di management. Dopo il 2006 la comparsa d’infrastrutture fornite come servizi cloud (IaaS) e delle soluzioni di provisioning automatizzato hanno permesso di slegare dalle risorse infrastrutturali interne il deployment di servizi It di classe enterprise in modo flessibile, economico e scalabile.
Oggi si può dire che la ‘Converged Infrastructure’ di Hp e la ‘Pure Application System’ di Ibm siano le realizzazioni più vicine al concetto di Sddc, per quanto, secondo Forrester, non lo rappresentino ancora nel senso più pieno. Due sono, infatti, gli aspetti che vanno perfezionati. Uno è il networking, che a causa di difficoltà tecniche resta difficile da virtualizzare in modo realmente completo, oltre cioè i livelli di virtualizzazione parziale realizzati da Cisco, VMware e qualche altro vendor specializzato. Il secondo è dato dalla presenza di molte applicazioni legacy che non sono facilmente eseguibili in ambienti virtuali o i cui produttori impongono l’uso di risorse fisiche dedicate. Il risultato è che nei data center aziendali i mondi fisici e virtuali devono in larga parte convivere, con uno sdoppiamento di risorse, architetture e strumenti di gestione.
Architettura e risorse
L’architettura generale di un Software-defined Data Center comprende vari livelli funzionali che poggiano sulle esistenti capacità di virtualizzazione (figura 1).
- Pool delle risorse fisiche e virtuali – La capacità di individuare e importare risorse diverse nell’infrastruttura del Sddc e di creare e gestire gruppi di tali risorse è ovviamente una dote primaria.
- Service Design – Essendo lo scopo del Sddc il rapido sviluppo dei servizi It in risposta ai bisogni del business, è indispensabile uno strato funzionale che specifici i carichi di lavoro dei servizi stessi. L’effettiva realizzazione di questo strato sarà compito dei vendor e, secondo Forrester, dovrà comprendere sia interfacce utenti grafiche sia interfacce basate su script e applicazioni (Api). Occorrerà anche un'interfaccia role-based per il deployment, il management, il billing e la gestione del ciclo di vita del catalogo dei servizi.
- Deployment e runtime – Il successo di un Software-defined Data Center dipende dalla flessibilità nell’allocare le risorse e nel rispondere al volo ai cambiamenti dei carichi di lavoro. Bisogna quindi che il runtime sia gestito in modo che il legame alle risorse (‘binding’) si possa fare all’ultimo momento e senza che ciò interferisca con l’esecuzione del servizio in atto. Per funzionare bene questa capacità deve far parte degli odierni componenti standard runtime, compresi i sistemi storage e di rete. Oggi ciò avviene nell’offerta d’infrastruttura dei grandi vendor, ma c’è un gap architetturale tra queste soluzioni e l’ambiente di gestione delle macchine virtuali, e la capacità d’integrare e gestire i componenti fisici con le capacità funzionali sarà vitale per il successo del Sddc.
- Enterprise management gateway – essere in grado di presentare e sfruttare informazioni dagli stack di enterprise management esistenti è necessario in quanto questi devono poter incorporare i dati forniti dal Sddc, così come gli strumenti di monitoraggio legacy ne devono almeno vedere i componenti. A tal fine il Sddc dovrà disporre di Api che permettano di integrarvi anche apparati infrastrutturali particolari, come gli Exadata di Oracle o le varie appliance basate su macchine virtuali di Hp, Ibm e Dell.
Figura 1 – Software Defined Data Center ArchitectureFonte – Forrester Reserch
I servizi It, che sono lo scopo e il lavoro di uno Sddc, sono archiviati in un catalogo e possono essere dispiegati sia in modo programmato sia tramite un portale role-based.
Tutti sono composti da una o più delle seguenti risorse:
- Risorse server – Le macchine virtuali sono il cuore del pool delle risorse di elaborazione, ma queste ultime comprendono, e comprenderanno per molti anni ancora, anche risorse non incapsulate in Vm. Per poter far parte di uno Sddc queste dovranno quindi essere limitate a server particolari, come ad esempio i Cisco Ucs, gli Hp c-Class Blade System e gli Ibm PureSystem, dotati di soluzioni di virtualizzazione via software che ne consentono l’inserimento in pool gestiti.
- Risorse storage – Queste si presentano come un pool di oggetti-storage che comprende unità logiche convenzionali, dischi virtuali e sistemi storage specifici per determinate applicazioni. I servizi storage di base come il backup, la deduplicazione, gli snapshot, il thin-provisioning e così via, si devono poter applicare sia agli oggetti-storage virtuali sia alle risorse fisiche sottostanti.
- Risorse network – Il problema maggiore di un’offerta Sddc sarà il realizzare l’astrazione di un network virtuale allacciandolo ai componenti fisici delle reti. Tutti i vendor in area networking vi stanno lavorando e molti hanno già pronte proprie versioni di Sdn (Software Defined Network). Spetterà ai fornitori di Sddc decidere quale scegliere in quanto, a parte le funzioni di base, queste versioni non sono tra loro compatibili. Secondo Forrester ciascuno avrà il proprio livello di Sdn, con un’interoperabilità molto limitata.
I trend anticipatori
Il concetto di Sddc è naturalmente complementare ed integrativo di altre due tendenze attualmente in atto nello sviluppo delle infrastrutture. L’una è quella dell’architettura workload-centrica, l’altra dell’infrastruttura convergente. Un’infrastruttura workload-centrica è quella la cui architettura è ottimizzata per un tipo di lavoro specifico, e secondo Forrester è oggi un trend rilevante. Il Software Defined Data Center si può quindi vedere come uno strumento omnicomprensivo per definire, entro porzioni del dominio di risorse disponibili, una o più architetture workload-centriche. Queste lavoreranno simultaneamente, ciascuna con le sue risorse e isolata dalle altre, assieme ad architetture di uso più generale.
Quanto all’attuale offerta d’infrastrutture convergenti (Ci) da parte di Hp, Ibm e Cisco, questa può influenzare lo sviluppo dello Sddc secondo due prospettive (figura 2). La prima sta nel fatto che, com’è intuibile, un Centro software-defined potrà incorporare prodotti di Ci come risorse, dato che tali prodotti includono soluzioni per virtualizzare le interfacce utente più critiche che possono essere facilmente integrate nel framework del Sddc.
La seconda ragione sta nel fatto che gli attuali fornitori di Ci ne faranno quasi certamente la base di sviluppo per un’offerta iniziale di Sddc. Per realizzare un tale sviluppo sarà però necessario che i vendor si interfaccino con gli stack di virtualizzazione di VMware e Microsoft. Di conseguenza i responsabili I&O (Infrastruttura e Operazioni) delle imprese utenti dovranno decidere quale scegliere, dato che l’esperienza ha provato che, al di là delle capacità dei fornitori terze parti, gli strumenti di gestione degli hypervisor nativi restano quasi sempre indispensabili.
Figura 2 – Relazioni tra SDDC e Converged InfrastructureFonte – Forrester Reserch
