Uno shared grid per muoversi verso il cloud

Un’infrastruttura centralizzata e condivisa che, sotto forma di private cloud, diventi anche lo strumento attraverso il quale erogare, in modalità self service, Iaas e, in futuro, anche Saas. Un progetto complesso quello di Ugis, la Global Ict Company di UniCredit, che Frank Schmidt (nella foto), Head of Sales & Research di Global Markets & Treasury Department, racconta a ZeroUno sottolineando anche le sfide organizzative e le strategie di change management adottate.

Pubblicato il 18 Apr 2011

p45-schmidt

UniCredit opera in 22 paesi europei con circa 162.000 dipendenti e 9.617 filiali.
Ugis è la Global Ict Company di UniCredit che fornisce servizi Ict a tutte le aziende del Gruppo attraverso 19 sedi presenti in 8 paesi, oltre 4.200 persone e 3 Global Data Center.
Sin dal 2007 l’Ict di UniCredit è stata caratterizzata da un intenso programma di integrazione di processi e di sistemi, ottenuto principalmente grazie alla fusione delle principali società informatiche di Gruppo in Ugis. Questo ha consentito la razionalizzazione dei costi informatici e il consolidamento del ruolo centrale di Ugis nella gestione delle tematiche Ict del Gruppo. Una parte del business, nello specifico quella relativa alle aree Global Derivatives Trading & Risk Management, Global Equity Trading & Risk Management, Market Risk e Virtual Destktops, era basata su di un numero eterogeneo di sistemi separati, sistemi che nel 2009, funzionavano grazie a più di 3.500 blade server con oltre 16.000 core che, da soli, consumavano circa un terzo dell’energia elettrica dei Data Center.
“Oggi le infrastrutture di grid computing appositamente create per le aree di business prima citate sono dislocate nei data center di Verona e Monaco e supportano i loro specifici prodotti e servizi – spiega Frank Schmidt, Head of Sales & Research all’interno del Global Markets & Treasury Department di Ugis -. In tali aree abbiamo predisposto, diversi ambienti: di sviluppo, di pre-produzione e di produzione (quest’ultimo replicato su due differenti siti per ragioni di disaster recovery e business continuity). Tenendo conto delle aree di business prima citate, arriviamo a circa 15 ambienti dedicati e segregati che prima del progetto di ‘shared grid’ che ci porta verso il cloud computing, presentavano un grado di utilizzo mediamente basso, ma con picchi che raggiungevano l’80%”.
La situazione di partenza, infatti, quella che di fatto ha spinto UniCredit a ragionare su uno shared grid, vedeva la continua crescita di Cpu, da conciliare però con power & space limitati.
Questo a causa del funzionamento delle applicazioni secondo un andamento molto variabile, con picchi di orari e periodi. “Sulla base delle richieste del business – osserva Schmidt – che andavano dalla riduzione dei costi ad esigenze più legate alla garanzia di disponibilità delle soluzioni e dei servizi, alla riduzione del time-to-service, fino a performance/latency, scalabilità e garanzia di sicurezza a tutti i livelli, abbiamo ipotizzato la realizzazione di uno shared grid, tecnologicamente la risposta più concreta a quella che può essere la nostra visione del cloud computing”.

Una architettura basata sulla service orientation
Il grid computing iniziale aveva alcuni limiti: problemi organizzativi, di processo ma anche tecnologici legati al maintenance & support; un singolo sistema operativo per ogni “grid”; singole librerie per ogni “grid”; multi Api ed “n” locations.
L’idea iniziale era quella di disegnare una infrastruttura che permettesse:
– una gestione centralizzata di infrastrutture eterogenee;
– un capacity planning and management centralizzato;
– di liberare i singoli application server (sui quali giravano applicazioni cosiddette Cpu intensive);
– di disaccoppiare i task computazionali dall’application setup;
– di avere librerie condivise e centralizzate su una piattaforma fisica comune con diversi sistemi operativi installati;
– di definire ed evolvere una Service Oriented Architecture;
– di identificare le infrastrutture sottoutilizzate;
– l’aggiunta dinamica e agile di virtual machine infrastructures (VMs), calendar & workload driven.
Un’architettura, insomma, che fosse basata sul concetto di “service orientation” e che nella nostra “visione cloud” significava avere una piattaforma “single-shared service”, con un’unica unità di servizio centralizzata e gestita per “performance reasons”, cioè in funzione delle esigenze e delle priorità del business. “Dal punto di vista tecnologico – precisa Schmidt – vuol dire avere un singolo Api, un ‘grid’ che ospita più sistemi operativi e più librerie e un unico punto di gestione.
In altre parole abbiamo creato una vera e propria private cloud con una struttura di High Performance Computing e una piattaforma di gestione dell’ambiente cloud che consente di automatizzare e semplificare i processi (anche in modalità self service) legati ad “assemblaggio e runtime” di infrastrutture as a service”.

Le criticità: quelle non mancano mai!
“Durante l’intero processo di disegno, selezione e implementazione della nuova infrastruttura grid/cloud abbiamo dovuto affrontare sfide diverse, da quelle tecnologiche a quelle finanziarie, di governance e organizzative legate anche agli skill”, racconta Schmidt. “Implementare un ambiente condiviso con l’obiettivo di ottimizzare l’intera infrastruttura IT è da considerarsi prima di tutto come un progetto di impatto organizzativo, dove struttura, ruoli e responsabilità sono sotto i riflettori.
Soprattutto in una società come la nostra dove ciò che facciamo ha un impatto diretto sulle performance e sul successo finanziario del gruppo bancario, la condivisione delle risorse rischierebbe di diventare addirittura controproducente”.
La ragione è semplice: le risorse dedicate sono configurate esattamente per uno specifico compito/obiettivo, mentre quelle condivise devono prendere in considerazione una moltitudine di requirement e in un’ottica business potrebbe non essere la condizione ottimale (ragionando su prestazioni e performance). Inoltre, centralizzare e condividere risorse significa implicitamente centralizzare e condividere gli skill (si indeboliscono le posizioni di sviluppatori e amministratori che vengono spostati dai loro ambienti originari).
Dato che stiamo parlando di un progetto piuttosto impattante anche sul piano tecnologico, abbiamo chiesto a Schmidt di chiarire anche le eventuali criticità riscontrare in quest’area.
“Una delle cose che abbiamo ‘scoperto’ proprio nella fase di gestione e nel monitoraggio dell’evoluzione dell’infrastruttura – racconta Schmidt – è stato il numero delle risorse necessarie a governare e rendere pratico il progetto, oltre alla profonda conoscenza/competenza necessaria su tematiche di change management, di business process management, di demand management. La sfida principale sul piano tecnologico è stata, oltre alla centralizzazione e alla condivisione delle infrastrutture, la gestione del cambiamento: prima di questo cambio di rotta, infatti, ogni business unit aveva una propria infrastruttura di riferimento con un responsabile per ogni singolo ambiente. Oggi, invece, l’ambiente di riferimento è uno solo, di carattere puramente IT e gestito da Ugis”.
Un nuovo ambiente come questo richiede competenze nuove o riqualificate nonché appropriati passaggi perché l’evoluzione possa avvenire progressivamente e senza criticità aggiuntive.

A stretto contatto con la struttura di governance
“Ugis ha affrontato questo percorso lavorando a stretto contatto con la struttura di governance di UniCredit – spiega Schmidt -. Nella fase di setup abbiamo pianificato e ‘aperto’ un Global Competence Center per identificare e formare correttamente gli esperti e le figure responsabili designate a condividere e trasferire la conoscenza oltre ad avere compiti di “problem solving”. Questo ci ha permesso di condividere con queste persone tutte le fasi del progetto e ci ha assicurato il ‘trasferimento’ della conoscenza a tutti i livelli di impresa coinvolti”.
“Da un punto di vista puramente tecnologico, gli step futuri – conclude Schmidt – ci vedranno impegnati nell’ulteriore virtualizzazione, sia lato server sia lato client, nella software standardization (necessaria per sfruttare il private cloud anche come infrastruttura di erogazione di software as a service) e, in generale, nel consolidamento IT per eliminare le ridondanze, sia hardware sia software, per migliorare ulteriormente i risultati, comunque già molto positivi, raggiunti: siamo passati da 3.500 a 1.100 server con un numero di cores passato da 16.000 a 9.000; il consumo energetico è diminuito grazie alla minor potenza richiesta per il funzionamento e il cooling dei Data Center che è scesa da 1.353 kW a 400 kW”.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 5