- Intesa Sanpaolo ha migrato sistemi critici dell’Area Finanza su Oracle Exadata Cloud@Customer, ottenendo i vantaggi del cloud pubblico ma mantenendo i dati nel proprio data center.
- Il passaggio al cloud ha richiesto l’adattamento a nuove pratiche operative, come la gestione di macchine virtuali e l’attenzione alla crittografia dei dati.
- L’utilizzo del cloud ha permesso una riduzione dei costi operativi IT, richiedendo però un cambio di mentalità nella gestione delle risorse e nel monitoraggio dei consumi.
L’adozione del cloud ha smesso d’essere un azzardo nei progetti di realtà aziendali complesse e regolamentate, come quelle del settore bancario. Lo testimonia l’esperienza di Stefano Passarella, database & middleware engineer della Direzione SI di Intesa Sanpaolo presentata in occasione di un incontro organizzato nelle scorse settimane nella sede Oracle di Milano. Esperienza che ha riguardato la migrazione di due sistemi critici impiegati nell’Area Finanza della Banca su Oracle Exadata Cloud@Customer, un servizio di cloud che ha consentito alla Banca di mantenere l’infrastruttura IT e i dati presso il proprio data center.
Una realizzazione che ha consentito alla Banca di ottenere molti dei vantaggi del cloud pubblico, senza gli oneri di security e di certificazione che uno spostamento di server e dati critici su servizi remoti avrebbero richiesto. Un progetto che è in produzione dall’inizio di quest’anno e che ha consentito al team SI di confrontarsi con le più moderne modalità di gestione, migliorato la flessibilità, ridotto oneri e costi IT per la Banca.
Indice degli argomenti
La scelta di un cloud ibrido, pubblico fino all’hypervisor
Il progetto di migrazione ha riguardato due sistemi Exadata già in esercizio presso l’Area Finanza della Banca, impiegati per il supporto delle attività di sviluppo e collaudo applicativo. “Sistemi di cui volevamo ridurre gli oneri della manutenzione e gestione hardware – spiega Passarella – consolidandoli con il servizio di cloud. Un’operazione che coinvolgeva ben 97 database, 130 applicazioni su due network indipendenti”.
Un obiettivo da realizzare nel modo meno impattante possibile per la security e l’operatività degli utenti. “Per questo abbiamo scelto di adottare Oracle Exadata Cloud@Customer, a metà strada tra l’on-premise e il cloud pubblico, che ci avrebbe liberato dagli oneri di gestione dell’hardware, lasciando software e sistemi all’interno del nostro data center”.
Adottando il cloud con sistemi fisici collocati all’interno della Banca i SI non sarebbero incorsi in complicazioni di rete, di security e alle lungaggini delle certificazioni per l’impiego su siti remoti. “Aspetti che, assieme alla capacità del cloud di soddisfare i requisiti degli utenti, costituivano all’inizio dell’operazione, nel novembre scorso, una fonte di preoccupazioni”, confida Passarella.
Cosa cambia nel passaggio su sistemi gestiti in cloud
Un punto importante del passaggio al cloud è stato, per i SI, familiarizzare con le nuove modalità operative del servizio. “Si è partiti studiando le analogie e le differenze rispetto ai sistemi Exadata in uso, quindi con la ricerca delle soluzioni per gli aspetti che necessitavano cambiamenti” spiega Passarella. “L’Exadata Cloud@Customer ha dimostrato di non comportarsi in modo diverso dagli Exadata stand alone, eccetto l’impiego di virtual machine (VM) con potenza dinamica, dati crittati e l’accesso esterno via HTTPS per la gestione da parte di Oracle”. Con Exadata Cloud@Customer Oracle ha pieno controllo dell’hardware fino all’hypervisor. Ai SI della Banca tutto il resto.
Rispetto all’Exadata stand-alone, il servizio in cloud toglie agli amministratori interni l’uso della console e richiede attenzioni specifiche con i sistemi. “Per esempio, di non fare modifiche sulle VM mentre sono in corso le operazioni remote di gestione o, peggio ancora, di spegnere e riavviare le macchine”. Poiché i dati sono crittati è fondamentale prestare attenzione alle chiavi di cifratura. “Con il nuovo servizio abbiamo dovuto preoccuparci di salvaguardare la chiave da eventuali perdite della VM. Allo stesso modo occorre gestirle per le operazioni di switchover con Dataguard (il sistema per la data protection e il disaster recovery – ndr)”.
Un’altra preoccupazione dei SI di Intesa San Paolo riguardava la capacità del servizio di supportare versioni differenti di database e applicazioni. “Un livello di compatibilità per noi importante (al momento sono in uso versioni dalla 11 alla 19 del DB Oracle – ndr). Benché Oracle sconsigli il caricamento delle versioni software obsolete, noi lo abbiamo sperimentato senza avere problemi”.
La realizzazione e l’esperienza d’uso
La migrazione al cloud dai sistemi Exadata della Banca è iniziata con la creazione e la certificazione di quattro VM da parte dei tecnici Oracle e quindi con la messa a disposizione di queste risorse ai SI. “Sulle quattro VM abbiamo ricreato i due ambienti d’origine, usando due coppie di nodi per lo sviluppo e due per il collaudo. Sono quindi state configurate le reti client e di backup”, spiega Passarella.
A differenza dei sistemi impiegati in precedenza, con il passaggio all’Exadata Cloud@Customer è venuto meno l’utilizzo delle connessioni in fibra Infiniband verso lo storage. “Questo ha significato portare il collegamento ai server ZFS su una delle reti, nel nostro caso abbiamo usato quella di backup, con la conseguente necessità di tenere conto degli effetti del traffico aggiuntivo”.
Mentre, da una parte, l’impiego di un cloud con sistemi residenti non incide sulla security dei dati, dall’altra è comunque richiesta l’abilitazione di un link esterno per la gestione dell’ambiente di cloud da parte del fornitore. “Anche qui abbiamo avuto meno problemi del previsto” precisa il manager. “Ci siamo avvalsi di un proxy esistente, già in uso per l’impiego degli altri servizi fruiti in cloud. Il tutto si è quindi risolto con la creazione di una connessione HTTPS tra una appliance Oracle al proxy e una veloce operazione di vaglio da parte della sicurezza”. Superate riserve e controlli, il servizio è andato rapidamente in produzione dalla fine dello scorso anno.
Fare i conti con il nuovo servizio in cloud
Utilizzare un servizio di cloud senza dover portare applicazioni e dati all’esterno del perimetro aziendale ha evitato complicate problematiche aziendali e permesso ai SI di Intesa Sanpaolo di ottenere una migliore gestione dell’hardware e la contabilizzazione pay-per-use dei servizi utilizzati.
“Avere a che fare con un servizio a consumo anziché con il costo di macchine fisiche richiede un cambiamento di mentalità e l’adozione di nuove pratiche per trarne vantaggio – spiega Passarella -. Serve tenere sotto controllo le CPU, richiedendo i servizi relativi già al momento dell’installazione. A differenza dei sistemi stand-alone, ogni attività dei sistemi, comprese le operazioni di gestione, hanno costi”.
Con il nuovo servizio, Intesa Sanpaolo può oggi ridurre i costi operativi IT spegnendo gli ambienti non in uso. “Come l’ambiente di sviluppo, la domenica, salvo specifiche richieste, per recuperare dei crediti da poter reimpiegare nell’altro ambiente” precisa Passarella. “Una pratica molto utile anche per le funzioni di DDR (Data Disaster Recovery)”. L’ottimizzazione dei costi richiede quindi cambiamenti amministrativi, “senza la condivisione dei crediti, ogni reparto avrebbe continuato ad andare per i fatti suoi”. Usare servizi in cloud richiede l’adozione di nuove modalità di governo sull’IT. In particolare, “serve passare da una logica di governo centrata sulle risorse allocate a quella sulle risorse usate. Per avere minori costi rispetto ai sistemi stand-alone serve spegnere, dove è possibile, tutto ciò che non è in uso, attraverso il controllo da parte dei tecnici dei SI, almeno una volta al mese”.
