Dieci sono i miliardi di dollari che Sam Palmisano, chairman e Ceo di Ibm, ha puntato sulla visione che va sotto il nome di ‘computing on demand’. Una scommessa che sembrerebbe preannunciare una nuova era dell’It, motivata dalla convinzione che in futuro le aziende avranno sempre più necessità di accedere a potenza di calcolo, capacità di storage e utilizzo di applicazioni, come se queste fossero delle ‘utility’ al pari di acqua, elettricità o connettività telefonica, di cui disporre in funzione del bisogno.
Questa ‘nuova era’ dell’It potrebbe anche essere interpretata come una risposta all’evoluzione dell’ambiente nel quale le aziende già operano e sempre più spesso si troveranno ad operare: mercati la cui prevedibilità continua a diminuire e contesti economici non sempre favorevoli. Una situazione difficile da gestire anche da parte delle direzioni It, che per supportare adeguatamente le esigenze dell’azienda a fronte di qualsiasi evenienza, dovrebbero poter disporre di risorse sovradimensionate rispetto a quelle effettivamente necessarie se le condizioni di mercato fossero meno volatili. Una strategia evidentemente troppo costosa.
E questo senza considerare un insieme di necessità, altrettanto irrinunciabili, che devono comunque essere tenute presenti dall’It aziendale: garantire la ‘business continuity’, mantenere l’efficienza dei sistemi al più elevato livello possibile, migliorarne la flessibilità operativa, riuscire a gestirne la crescente complessità. Una complessità la cui gestione andrà affrontata utilizzando sistemi ancora più sofisticati, che al loro interno incorporeranno l’ulteriore complessità, sia hardware che software, richiesta affinché possano svolgere il loro compito.
Ma di quale tipo di ambiente informatico bisogna disporre per poter fare del vero ‘computing on demand’, e quali progressi sono stati compiuti verso il raggiungimento di questo obiettivo? Difficile dirlo: Irving Wladawsky-Berger, cui è stata affidata ba Ibm la responsabilità della cosiddetta ‘On-Demand Initiative’, e in particolare dei settori riguardanti sia l’autonomic sia il grid computing (entrambi considerati da Big Blue due possibili fonti di business a scadenza non troppo lontana), avrebbe detto: «Sappiamo da dove siamo partiti e anche dove vogliamo arrivare, ma sappiamo anche che la strada è estremamente complessa. Qualcuno ha paragonato la nostra visione a quella che, quarant’anni fa, ha portato l’uomo sulla luna…».
‘Sense & Respond’, nuovo modello di riferimento
Di ‘computing on demand’ abbiamo avuto l’opportunità di parlare con Fulvio Capogrosso, Distinguished engineer del Server Group Emea South Region di Ibm, uno dei maggiori esperti europei in questo campo.
Fulvio Capogrosso
Distinguished engineer
del Server Group Emea South Region
di Ibm
«Le motivazioni che hanno portato Ibm a formulare la strategia dell’on-demand – spiega Capogrosso – non sono solo di tipo tecnologico, ma tengono conto dei cambiamenti in corso nei mercati e nell’economia mondiale, che stanno profondamente trasformando il modo di fare business. È nata così l’esigenza di sviluppare un nuovo modello di riferimento, che è stato messo a punto dal nostro Advanced Business Institute, e che abbiano chiamato ‘Sense & Respond’. Un modello dove la visione ‘as-planned’, tipica del passato e basata su un’attenta pianificazione degli eventi nel breve come nel lungo termine, è stata sostituita dalla visione on-demand, per tener conto di un ambiente i cui cambiamenti sono difficili da prevedere e dove l’unica strategia che abbia senso per l’azienda è quella di sviluppare la capacità di adattarsi nel modo più rapido ed efficiente possibile alle fluttuazioni dell’ambiente stesso».
Ma la caratteristica più interessante di tale visione è quella di trovare diretta applicazione anche nel mondo tecnologico. «In effetti – aggiunge Capogrosso – è proprio questa la novità di un concetto che altrimenti potrebbe sembrare banale, perchè in definitiva mette in primo piano la necessità di tenere continuamente sotto controllo gli ambienti che interessano in modo da essere sempre in grado di rispondere adeguatamente ai loro mutamenti».
è appunto questo il concetto alla base di quello che Ibm chiama ‘autonomic computing’: un approccio tecnologico che si propone, con l’inserimento nei diversi componenti delle infrastrutture informatiche di capacità di tipo ‘sense & respond’, di metterle in condizioni di ‘badare a sé stesse’, rendendole sempre meno dipendenti dall’intervento umano. Uno degli obiettivi dell’autonomic computing è, ad esempio, quello di fare in modo che la maggior parte delle attività di system management avvenga all’interno dei sistemi stessi, sia per semplificare la gestione di infrastrutture che stanno diventando sempre più complesse, sia per facilitarne la ‘problem determination’ in caso di malfunzionamenti.
Ottimizzare le infrastrutture: un problema di standard
Allo stato attuale del suo sviluppo, l’autonomic computing più che una strada tracciata individua soprattutto una direzione da seguire, un punto di arrivo per raggiungere il quale c’è ancora parecchio lavoro da fare. Si tratta infatti innanzitutto di procedere all’ottimizzazione dei processi di business, il che vuol dire reingegnerizzare, o almeno integrare, quelli esistenti. Poi è necessario consolidare le infrastrutture It per poter in seguito realizzare un livello più elevato di virtualizzazione delle risorse informatiche, sia server sia storage; che è poi l’obiettivo che si pone il grid computing, l’altra pietra miliare sul cammino che porterà all’It ‘on demand’.
«Mentre l’ottimizzazione dei processi di business – osserva Capogrosso – riguarda il mondo della consulenza, l’ottimizzazione delle infrastrutture It è invece prevalentemente un problema di standardizzazione. Ed è una delle direzioni lungo le quali si sta muovendo Ibm, che ha deciso di sviluppare una serie di standard per quelle che sono state identificate essere le ‘core enabling capabilities’ dell’autonomic computing: la problem determination, l’amministrazione dei sistemi, la loro gestione basata su regole definite dall’utente, il monitoraggio delle risorse, l’installazione del software e il workload management. Lo scopo è che tutte le svariate piattaforme tecnologiche riescano a comunicare tra loro e con l’esterno utilizzando questi standard comuni. Infatti, per quanto possa sembrare strano, finora ogni piattaforma ha affrontato questa problematica in modo assolutamente non standard. E poiché non è possibile andare a modificare direttamente tutte le piattaforme esistenti, la soluzione scelta è stata quella di aggiungere uno strato di software specializzato. Un ‘layer’ di standardizzazione che viene usato da ogni piattaforma quando deve comunicare con l’esterno, in qualunque modo ciò avvenga».
La possibilità di gestire infrastrutture eterogenee utilizzando un insieme di modalità standard è dunque considerata in Ibm prioritaria al fine di aprire la strada all’autonomic computing. Queste ‘capabilities’ verranno via via rilasciate nel corso del 2004 (anche se non saranno rese disponibili singolarmente, ma incorporate di preferenza nei prodotti che ne faranno specifico uso) e riguarderanno l’intera infrastruttura di tipo autonomico.
Le funzionalità per l’autonomic computing
L’altra attività in corso in Ibm riguarda invece lo sviluppo delle funzionalità di tipo autonomico: non delle semplici ‘capabilities’, ma vere e proprie soluzioni applicative. Tre sono le aree prese attualmente in considerazione, corrispondenti ad altrettanti modi di realizzare un’infrastruttura autonomica. Ma poiché si tratta di approcci complementari è molto probabile che questi diversi sviluppi finiranno in futuro per convergere. Primo si sta dunque lavorando attorno a un Business Workload Management; secondo: sono state lanciate svariate attività facenti capo ad un cosiddetto ‘Progetto Symphony’ (vedi più avanti) e, terzo, si stanno anche mettendo a punto alcune applicazioni in ambito WebSphere.
«L’obiettivo fondamentale dell’autonomic computing – ricorda Capogrosso – è quello di garantire la Quality of Service di un’infrastruttura informatica eterogenea (vedi figura 1), comunque complessa e distribuita, che deve servire flussi di transazioni le cui caratteristiche non sono note in anticipo».
L’infrastruttura It per l’e-business fonte: Ibm
Per risolvere il problema, l’approccio proposto dal Business Workload Management (vedi figura2) consiste nel riprodurre, a livello dell’infrastruttura nel suo complesso, il concetto di ‘piattaforma gestita’, tipico dei mainframe Ibm (che da questo punto di vista erano stati progettati con criteri straordinariamente avanzati). In particolare si tratta di creare all’interno di ogni server, e quindi in ogni ‘nodo’ dell’infrastruttura, un ambiente in grado di gestirne la Quality of Service con modalità simili a quelle di cui sono capaci i mainframe.
Il business Workload Management fonte: Ibm
«Affinché questo sia possibile – continua Capogrosso – tutti i server privi delle necessarie capacità devono essere innanzi tutto dotati di dispositivi (si parla di ‘platform instrumentation’) che consentano loro di operare nel modo più evoluto richiesto dal sistema. In ogni server viene poi caricato un Local Workload Manager (LeWlm, vedi ancora figura 2) che ha il compito di monitorare le attività che in esso si svolgono. Questo software, in caso di necessità e in base a policy predefinite, può intervenire su alcuni aspetti riguardanti le modalità di funzionamento del server che controlla: aumentare la memoria a sua disposizione, variare la banda di input-output che può utilizzare, modificare le ‘dispatching priority’ dei lavori in corso. Inoltre, qualora il server non sia in grado di garantire la qualità di servizio che gli è stata assegnata, il suo Local Workload Manager passa questa informazione a un Global Workload Manager (GeWlm) che potrà eventualmente andare in suo aiuto».
Due sono gli interventi che il GeWlm è attualmente in grado di fare: chiedere al Network Load Balancer del sistema, vale a dire alla funzione che regola il flusso delle transazioni, di bloccare l’invio di ulteriore carico di lavoro al nodo in crisi, oppure, in alternativa, emettere una richiesta di ‘provisioning’ di risorse sul nodo stesso. La richiesta del GeWlm viene trasmessa all’esterno sotto forma di servizio Ogsa (Open Grid Services Architecture), lo standard ‘grid’ che è di fatto un’estensione dei Web services, in modo che possa essere presa in carico da un operatore in grado di effettuarli (qualora gli interventi richiesti debbano avvenire attraverso una mediazione umana), o da un ‘motore di provisioning’ capace invece di evadere la richiesta in modo automatico. Un prototipo del Business Workload Manager, indirizzato agli sviluppatori, è già stato rilasciato sotto forma di ‘developer work’, mentre sono in corso di realizzazione le prime versioni del Local Workload Manager per le piattaforme Aix, z/OS, Os/400, Windows, Solaris, Linux e Hp-Ux, secondo un piano che verrà completato entro il 2004.
L’acquisizione di una piccola software house canadese di nome ThinkDynamics, perfezionata nel maggio del 2003, ha però dato all’Ibm la possibilità di accelerare la sua marcia di avvicinamento all’on demand computing.
Il Progetto Symphony
In effetti, già lo scorso ottobre, con il logo Tivoli, è stato rilasciato un primo prodotto basato sulla tecnologia ThinkDynamics: si tratta di Tivoli Intelligent Orchestrator (vedi figura 3), un software che consente, in un Data center dove siano installati particolari tipi di server, di riallocare dinamicamente le risorse disponibili immettendo o rimuovendo in modo automatico potenza elaborativa in funzione delle esigenze delle applicazioni. Ma l’Intelligent Orchestrator di Tivoli rappresenta solo il primo passo di una strategia di prodotto più vasta alla quale è stato dato il nome di ‘Project Symphony’.
L’architettura Tivoli Intelligent Orchestrator fonte: Ibm
«A differenza del Business Workload Manager – spiega Capogrosso – la soluzione di resource management automatizzata che abbiamo acquisito da ThinkDynamics è esterna all’infrastruttura che va tenuta sotto controllo. In questo caso non si procede tanto ad una ‘platform’ quanto ad un ‘environment’ instrumentation. Un approccio software che richiede la messa a punto di un sistema di monitoraggio basato su ‘agenti’, detti Data Acquisition Engine (Dae), il cui compito è appunto quello di estrarre alcuni tipi di dati dall’ambiente sotto osservazione, eseguire su di essi un primo livello di analisi, che potremmo definire di ‘sense’, ed inviare i risultati a un Global Resource Manager (Grm, vedi ancora figura 3) dove risiede l’intelligenza della soluzione. A sua volta il Grm, se da una valutazione più approfondita delle informazioni che gli giungono dai Dae rileva l’esistenza di scostamenti rispetto alle specifiche di Quality of Service previste, può far partire una funzione di ‘respond’ consistente in un provisioning di capacità elaborativa a livello di server». Poiché il software ThinkDynamics è ‘application specific’, per la sua attivazione è necessario elaborare specifiche regole di monitoraggio per ogni ambiente presente nel data center considerato e per tutte le applicazioni che possono girare al suo interno. Ne segue che per ogni accoppiata applicazione-ambiente si devono sviluppare i Dae destinati a raccogliere le informazioni richieste. Si tratta di una modalità molto simile a quella delle soluzioni Tivoli di system management. Ed è questa la ragione per cui a Tivoli sono stati affidati gli sviluppi futuri della tecnologia ThinkDynamics che prevedono la realizzazione di un sofisticato sistema di provisioning dinamico, al quale è stato dato il nome di Orchestrated Environment, dove server, dispositivi per lo storage e infrastrutture di rete opereranno in armonia al fine di realizzare un effettivo ambiente on-demand.
Potenza a richiesta per il Web
Nell’ambito del Progetto Symphony , oltre al già citato Intelligent Orchestrator e al Provisioning Manager, è stato rilasciato anche un Web Infrastructure Orchestration. Si tratta di una soluzione che, combinando quattro diverse tecnologie (eServer BladeCenter, FastT900 Storage Server, WebSphere e Db2), consente di realizzare dei front-end Web in grado di modificare automaticamente la loro capacità elaborativa al variare del traffico proveniente dalla Rete.
«Questa soluzione è caratterizzata dal fatto di impiegare componenti omogenei. Una situazione ideale – osserva Capogrosso – perchè fare del provisioning in ambienti eterogenei è oggi molto più complicato. In questi casi, infatti, se all’interno di un’infrastruttura nasce la richiesta di ulteriore potenza elaborativa, a meno di non operare in contesti ad alto livello di virtualizzazione, non si può far altro che allocare risorse di tipo ben definito: potenza Risc se la richiesta proviene da un ambiente Risc, potenza mainframe se l’ambiente è invece mainframe. Per cui se nell’infrastruttura considerata sono presenti molte piattaforme diverse, la sua ‘orchestrazione’ può diventare estremamente costosa. Da qui la necessità di procedere, innanzi tutto, ad una server consolidation che consenta di razionalizzare l’intera infrastruttura».
Con Linux, è più facile
In un passato ancora recente, l’installazione di piattaforme eterogenee a supporto di nuove soluzioni applicative non sembrava una scelta particolarmente problematica. All’aumentare tuttavia della complessità delle infrastrutture informatiche (anche come conseguenza di questa pratica), i responsabili It aziendali hanno incominciato a rendersi conto del costo derivante dal dover gestire più tipi di piattaforme. Da qui l’inizio del riflusso, il diffondersi del consolidamento dei server e del crescente interesse nei confronti di Linux per tutti quei componenti di uso generale e privi di particolari esigenze: dai file ai print server, dai mail ai proxy server, dai firewall ai Web server. Linux, per sua natura, è infatti un sistema operativo multiplatform e quindi ogni applicazione scritta per Linux può girare su ogni tipo di piattaforma hardware.
«Un’infrastruttura basata completamente su Linux, anche se costituita da server di tipo diverso, – conclude Capogrosso – faciliterebbe in effetti molto la realizzazione di una soluzione autonomica. Fare del provisioning dinamico significa infatti prendere un server da un pool fisico (o generarlo da un pool virtuale), caricarvi il sistema operativo (Linux), il necessario middleware (supportato da Linux), l’applicazione interessata (scritta per Linux) e chiedere al ‘load balancer’ di collegare gli utenti e far partire il tutto. In questo modo il responsabile di una grande infrastruttura che si trova ad affrontare il problema del provisioning dinamico non è costretto ad attivarlo in un solo colpo. Può cominciare dall’ambiente Linux, proseguire con i Web server, con lo storage, e poi ampliarlo man mano che vengono rese disponibili le soluzioni in grado di supportare gli altri ambienti».
