IBM Scholar Program : [Modulo 3]
3.3 : La Selezione della Piattaforma Informatica e
l’ottimizzazione della Infrastruttura.
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.1
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Contenuti del Modulo 3.3
•
•
•
•
•
•
•
•
•
Introduzione
La Platform Selection
L’ infrastruttura Informatica
I/T Resource Optimization [ ITRO ]
Server Consolidation [ SCON ]
Approccio Quantitativo basato sui Costi [ TCO ]
Il Tema del ‘cross platforms sizing’
Esempi di applicazione del Metodo
Conclusioni
Page 3.3.2
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.0 : Introduzione - Definizioni.
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.3
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Definizione : Piattaforma Informatica
Definiamo ‘Piattaforma Informatica l’insieme ordinato di :
•Sistema Operativo
•Architettura Hardware
Sistema
Operativo
Architettura
Hardware
Linux
Linux
z/OS
X86
zArchitecture
zArchitecture
Piattaforma Linux-X86
Page 3.3.4
Piattaforma z/OS-zArchitecture
Piattaforma Linux-zArchitecture
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Alcune Riflessioni sulle Piattaforme Informatiche
•
Sono Architetture Hardware:
•
Sono Sistemi Operativi
•
•
•
•
•
•
•
•
•
•
x86 (Intel + AMD)
Apple
z/Architecture
PA-RISC
Sun-Sparc
Power IBM
........
•
•
•
•
•
•
•
Windows
Linux
z/OS
HP/UX
Solaris
IBM/AIX
........
Sulla medesima architettura hardware possono girare diversi sistemi operativi
(es: Linux funziona su x86 ,z/Architecture, Power)
Alcuni Sistemi operativi possono essere attivati su una sola architettura
Hardware (es: Windows solo su x86, z/OS solo su z/Architecture)
Non tutte le combinazioni di un Sistema Operativo + una Architettura Hardware
danno luogo ad una Piattaforma Informatica possibile (ad esempio la
piattaforma informatica Windows + z/Architecture NON ESISTE).
Page 3.3.5
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Le Piattaforme Informatiche e le Applicazioni Informatiche
Le applicazioni informatiche (Programmi Applicativi) possono essere:
•Tipiche o Caratteristiche di una sola Piattaforma Informatica
•In questo caso vengono dette ‘Legate’ (o legacy)
•In grado di funzionare su diverse piattaforme informatiche
•In questo caso vengono dette ‘Portabili’ (open)
La portabilita’ di una Applicazione Informatica attraverso diverse
piattaforme Informatiche puo’ essere data:
•Dal linguaggio di programmazione previsto ed identico su tutte le
Piattaforme Informatiche (es : Java):
•Si parla in questo caso di compatibilita’ a livello Sorgente
•Dal MIddleware presente su tutte le piattaforme Informatiche
•Si parla in questo caso di portabilita’ a livello di codice
eseguibile o ‘oggetto’.
Page 3.3.6
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Portabilita’ delle applicazioni : il ruolo del Middleware
Processo di ‘Porting’
Applicazione
Informatica per A
Piattaforma
Informatica A
Applicazione
Informatica
Page 3.3.7
Compilazione
Copia
Applicazione
Informatica per B
Piattaforma
Informatica B
Applicazione
Informatica
Middleware per A
Middleware per B
Piattaforma
Informatica A
Piattaforma
Informatica B
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Portabilita’ delle applicazioni : il ruolo degli Standard
Business
Applications
Open & Industry Standards
Open & Industry
Standards
Open
& Industry Standards
Open & Industry Standards
Operating
Environment
Operating
Environment
• Alcuni Standard di nome o di fatto , come ad esempio TCP/IP, XML, Java,
J2EE ed i relativi Middleware , come ad esempio WebSphere, TomCat, Apache
abilitano e facilitano la possibilita’ di eseguire (deploy) la stessa applicazione su
piattaforme informatiche diverse con lo stesso risultato funzionale e senza
alcuna modifica al codice.
Page 3.3.8
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.1 : La Selezione della Piattaforma Informatica Platform Selection
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.9
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
La Platform Selection
• Il processo per selezionare la migliore piattaforma
informatica in grado di eseguire una data Applicazione
Informatica prende il nome di ‘Platform Selection’.
• La Platform Selection e’ possibile grazie alla presenza degli
Standard e dei Middleware , essi rendono concreta la
‘portabilita’ della applicazione informatica attraverso diverse
piattaforme Informatiche.
• Non sempre l’applicazione Informatica risulta ‘portabile’
attraverso diverse piattaforme informatiche: a volte essa
presenta ‘legami’ stretti con la piattaforma informatica sulla
quale era stata progettata e realizzata : in questo caso
l’applicazione informatica e’ detta ‘legacy’.
• Se l’applicazione e’ portabile il processo di Platform Selection
e’ possibile e si basa su alcuni criteri specifici.
Page 3.3.10
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Platform Selection : Caratteristiche Funzionali
• Criteri Funzionali :
• Rappresentano le caratteristiche di funzionamento di una
applicazione , ovvero il fatto che l’applicazione faccia cio’ per
cui e’ stata progettata/realizzata.
• Usualmente i criteri funzionali sono un prerequisito, tutte
le Piattaforme Informatiche per i quali essi non sono
realizzati devono essere escluse dal processo di selezione
• Non ha senso scegliere piattaforme informatiche sulle quali
l’applicazione non puo’ funzionare.
Page 3.3.11
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Platform Selection : Caratteristiche NON Funzionali
• Criteri Non Funzionali :
• Rappresentano le caratteristiche di una applicazione che non
hanno a che fare col suo funzionamento ma possono
migliorarlo o renderlo piu’ performante o piu’ conveniente:
• Sono Caratteristiche NON FUNZIONALI:
•
•
•
•
•
•
Rapporto costo/prestazioni
Costo di Gestione / esercizio
Sicurezza
Gestibilita’
Capacita’ di Disater Recovery
Continuita’ di Servizio
• Le caratteristiche NON FUNZIONALI sono la base per il
processo di platform Selection.
Page 3.3.12
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Platform Selection : Altre Caratteristiche
• Altri Criteri :
• Puo’ accadere che la Platform Selection, premessi i requisiti
funzionali, tenga conto di altri criteri di diversa natura
• Ad Esempio una Azienda/Ente potra’ decidere di eseguire
(deploy) una Applicazione Informatica portabile su una data
piattaforma informatica indipendentemente dai criteri NON
FUNZIONALI ed invece basandosi sulla presenza di molte
altre applicazioni sulla stessa piattaforma presso la stessa
Azienda/Ente e cio’ allo scopo di ridurre il numero di
piattaforme informatiche presenti in Azienda/Ente.
• La Platform Selection e’ quindi un processo che deve essere
mediato dalle Strategie Complessive della Organizzazione.
Page 3.3.13
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Caratteristiche non Funzionali determinanti
• Gli elementi NON Funzionali che sono usualmente
determinanti al fine della Platform Selection sono:
• Il Costo di Esercizio della Applicazione Informatica su quella
Piattaforma Informatica.
• L’Ambiente Operativo (Operating Environment) tipico della
Piattaforma Informatica
• La presenza presso l’Azienda/Ente di personale con
esperienza specifica (Skill) su quella data piattaforma
informatica
• Le prestazioni specifiche della Applicazione sulla piattaforma
Informatica
• I Costi di Acquisizione
Page 3.3.14
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Re – hosting
• Il Processo di Platform Selection puo’ riguardare una
Applicazione Informatica gia’ esistente e portabile ovvero
una nuova applicazione informatica non esistente e quindi
ancora da realizzare.
• Se il processo di Platform Selection e’ relativo ad una
Applicazione Informatica esistente ,funzionante e portabile
ed e’ volto ad eseguirla su una differente piattaforma
informatica sulla base di criteri NON FUNZIONALI , esso
prende il nome di ‘re-hosting’ .
• Il re-hosting puo’ comprendere o non comprendere
modifiche al codice della applicazione secondo il grado di
portabilita’ e la presenza di Middleware.
Page 3.3.15
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Criteri Quantitativi
•
Allo scopo di definire in maniera rigorosa il processo di Platform
Selection si rendono necessari alcuni elementi:
•
Una Metodologia di Analisi che fornisca Parametri in base ai quali
valutare i criteri non funzionali:
•
•
Un modello rigoroso di analisi dei dati forniti dalla metodologia
•
•
Quali e quante macchine ?
Una serie di Criteri per valutare tutto cio’ che non e’
immediatamente quantificabile (Best Practice)
•
Page 3.3.16
Valgono di piu’ le migliori prestazioni o la migliore affidabilita’ ?
Un criterio oggettivo e preciso per stimare le potenze delle
macchine (Calcolatori, Serventi o altro) tipiche delle diverse
piattaforme informatiche.
•
•
Quanto vale ogni elemento NON FUNZIONALE ?
Un processo accurato di confronto delle caratteristiche non
funzionali tra le varie piattaforme Informatiche.
•
•
Quali sono gli elementi NON FUNZIONALI piu’ importanti?
Quante persone occorrono per gestire la piattaforma INformatica?
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.2 : L’ Infrastruttura Informatica
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.17
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
L’ Infrastruttura Informatica
Definiamo Infrastruttura Informatica l’insieme degli Apparati Hardware
e del Software necessari al funzionamento di una o piu’ applicazioni
Informatiche.
Fanno parte della Infrastruttura informatica:
•I Serventi (Calcolatori) col loro Software
•Gli apparati di memorizzazione a Disco e Nastro (Storage)
•Gli apparati di rete e di comunicazione
•I Terminali video o i Personal Computers
•Il Personale di Gestione dei Serventi, Storage e Rete
•Altri Apparati come stampanti ed altre unita’ hardware
•Tutti i programmi applicativi in uso
•I dati
Ogni Infrastruttura informatica puo’ basarsi su una o piu’ Piattaforme
Informatiche e puo’ eseguire una o piu’ Applicazioni Informatiche.
Page 3.3.18
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Infrastruttura Informatica
Front End
Access Point
Access Point
Network
Network
Security
Local Network
Dati
Core Systems
Internal Network
Page 3.3.19
Internal Network
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
I Problemi della Infrastruttura Informatica
•
SERVER PROLIFERATION: il Modello Client Server ha creato una
proliferazione incontrollata di Serventi che sono oggi in gran numero e di
difficile Gestione.
•
UNDER UTILIZATION : lo stesso modello ha definito anche il paradigma: Un
servente = Una Funzione, poichè i Serventi sono macchine sempre piu’ potenti
essi finiscono con l’essere poco utilizzati, poichè per disegno architetturale le
funzioni devono risiedere su macchine diverse o al minimo su istanze di
Sistema Operativo separate e quindi è molto difficile diminuirne il numero.
•
COST of MANAGEMENT : Il Costo di una infrastruttura generalmente cresce
col crescere del numero di macchine installate.
•
QUALITY of SERVICE : La grande proliferazione di macchine crea anche la
necessita’ di connessioni molteplici ed aumenta il rischio di interruzioni di
Servizio
•
ENVIRONMENTAL’S Constrains: La grande proliferazione di Serventi
aumenta i costi di Spazio, Energia Elettrica e Sistemi di Raffreddamento
•
MA : molte funzioni di servente sono portabili e quindi facilmente eseguibili su
diverse piattaforme informatiche.
Page 3.3.20
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
L’infrastruttura diventa sempre piu’ complessa
Eeterogenea e Distribuita
Page 3.3.21
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.3 : Ottimizzazione della Infrastruttura
Informatica [ ITRO ]
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.22
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Ottimizzazione della Infrastruttura Informatica
• L’insieme dei processi volti a semplificare / ottimizzare la
Infrastruttura Informatica con l’obiettivo di renderla piu’
semplice da gestire, piu’ efficiente e meno costosa prende il
nome di Ottimizzazione della Infrastruttura Informatica (I/T
Resource Optimization – abbreviato in ITRO).
• Il processo di ITRO puo’ avvenire intervenendo su piu’ fattori
detti ‘drivers’.
• In generale il processo di ITRO e’ lungo e complesso e
generalmente e’ costituito da diversi ‘passi’ detti Steps.
• Il processo di ITRO puo’ essere facilitato dalla tecnologia
mediante accorgimenti detti ‘enablers’ (abilitatori).
Page 3.3.23
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
I Drivers per ITRO
• Maggiore Efficienza
• Migliore Gestibilita’
• Riduzione dei Costi
• Migliore resilienza o Continuita’ di Servizio
• Minori Consumi
Page 3.3.24
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Esempi di operazioni volte alla ottimizzazione
• Diminuire il Numero di Serventi / Dischi Fisici
• Diminuire il Numero di Istanze di Sistema Operativo
(Serventi Logici).
• Virtualizzare i Sistemi
• Virtualizzare le reti
• Usare Sistemi Operativi meno costosi per funzioni poco
importanti
Page 3.3.25
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Gli ‘ abilitatori ‘ per ITRO
• La tecnologia puo’ fornire elementi che facilitano (abilitano)
il processo di ITRO.
• La Virtualizzazione e’ certamente un elemento abilitante per
l’ottimizzazione in quanto consente di ridurre il numero di
serventi fisici e spesso anche quelli logici.
• Il Sistema Operativo LINUX potrebbe essere un altro
elemento abilitante.
• L’uso di grandi Sistemi Virtualizzati e’ un altro elemento
Page 3.3.26
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.4 : Server Consolidation
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.27
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Server Consolidation : Definizione
•
Si definisce ‘Server Consolidation’ il processo volto a diminuire
(consolidare) il numero di Serventi Fisici o Logici componenti l’infrastruttura
Informatica con interventi piccoli tendenzialmente nulli sulle Applicazioni
Informatiche che su di essa insistono.
•
La Server Consolidation puo’ essere uno dei Drivers e certamente
rappresenta un elemento importante in un processo di ITRO.
IL Processo di Ottimizzazione del Numero di Serventi Logici e o Fisici
prende il nome di Consolidamento dei Serventi (Server Consolidation).
•
•
Esistono vari tipi (livelli ) di Consolidamento:
•
•
•
•
Le Tecniche di Virtualizzazione sono un elemento ‘abilitante’ per la Server
Consolidation in quanto:
•
•
Page 3.3.28
Accentramento
Consolidamento Fisico
Consolidamento Logico
Ottimizzano l’uso delle macchine
Consentono di diminuirne il Numero
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation : Riepilogo dei Concetti di base
•
Servente Fisico o Sistema Fisico e’ un calcolatore fisicamente
indipendente cio’ dotato di alimentazione elettrica indipendente e
costituito da componenti elettricamente isolate ed indipendenti da
quelle degli altri Sistemi.
•
Servente Logico o Immagine di Sistema e’ una Istanza di Sistema
Operativo indipendente (cioe attivabile o disattivabile
separatamente da altri) in maniera non correlata alla sua
collocazione su un calcolatore.
•
Un Servente si dice Virtualizzato quando una Immagine di Sistema
e’ avviata su un Calcolatore (Sistema Fisico) sotto il controllo di un
dispositivo Hardware o Software in grado di Virtualizzare
(Condividere) le risorse. La porzione di risorse gestita da un
Servente Virtualizzato si dice Macchina Virtuale o Sistema Virtuale .
Un Servente Virtualizzato e’ sempre Logico.
•
Su un Servente Fisico possono essere attivate piu’ immagini di
Sistema Virtualizzate o a sua volta un Sofware in grado di
virtualizzarlo.
Page 3.3.29
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation : Riepilogo dei Concetti di base
Servente Logico
Servente Logico Virtualizzato
z/OS Linux
z/OS Linux
Linux Linux z/OS
z/OS
Linux
z/VM
z/VM
LPAR1
z/VM
LPAR2 LPAR3
LPAR4
PR/SM
zSeries or zSystem
Servente Fisico
Page 3.3.30
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation : Livelli di Consolidamento
Vista Applicativa
Accentramento
Consolidamento
Fisico
Consolidamento
Logico
Paris
London
Rome
Page 3.3.31
Rome
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation : Livelli di Consolidamento
Vista Infrastrutturale
Virtulizzazione
Consolidamento Applicazioni
Sist. Op
Sist. Op
Appl A
Appl A
Sist. Op
Appl A
Page 3.3.32
Sist. Op
Sist. Op
Appl B
Appl B
Appl B
Sist. Op
Sist. Op
Appl C
Appl C
Appl C
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation - Uso di Linux
Page 3.3.33
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation - Semplificazione Layers Applicativi
Page 3.3.34
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Server Consolidation - Conclusioni
• Il Consolidamento dei Serventi (Server Consolidation) puo’
essere il primo e decisivo passo per un processo di ITRO
• Come nel caso della Platform Selection si pone la necessita’
di disporre di criteri quantitativi a supporto del processo di
Server Consolidation in modo da poter valutare se e quando
esso abbia senso e in quali tempi possa restituire dei
vantaggi economici
• Il Consolidamento dei Serventi e’ oggi una necessita’, stante
la complessita’ raggiunta dalle infrastrutture Informatiche.
Page 3.3.35
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.5: Un approccio quantitativo basato sui Costi [ TCO ]
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.36
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Approccio Quantitativo
• I processi di Platform Selection,ITRO e Server
Consolidation richiedono una metodologia
quantitativa in grado di:
•
•
•
•
Valutare l’efficacia dei processi ‘a priori’
Fornire criteri a supporto delle decisioni
Dare indicazioni sul ritorno degli investimenti
Valutare i risultati di un processo ‘a posteriori’
• Una buona tecnica puo’ essere quella di basare tale
criterio sui costi
Page 3.3.37
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Il Metodo TCO – Definizioni
• La metodologia denominata Total Cost of Ownership
(abbreviata con la sigla TCO) e’ stata introdotta da alcuni
consulenti indipendenti alla fine degli anni ’90
• Essa si pone l’obiettivo di confrontare due ‘soluzioni’ dal
punto di vista dei costi fornendo un modello ‘assoluto’ ed
indipendente il piu’ possibile da valutazioni soggettive.
• Si basa sulla definizione di una grandezza denominata TCO :
il TCO viene valutato e confrontato per tutte le soluzioni
oggetto della analisi che poi vengono raffrontate.
Page 3.3.38
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Cosa rappresenta il TCO ?
• Il TCO e’ un concetto ‘intuitivo’ :
• ad Esempio se avete un motorino avremo:
•
Costi Ricorrenti
»
»
»
»
•
Costo Garage per un anno
Costo Manutenzione per un anno
Costo Benzina per un anno
Lubrificanti
Costi Una Tantum
»
»
»
Costo del motorino
Costo del casco
Costo accessori
• IL Costo di ‘possesso’ del motorino per tre anni e’ dato da
tre volte la somma dei costi annuali ricorrenti piu’ i costi di
acquisizione
Page 3.3.39
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Il Metodo TCO – Costi Operativi e Costi di Acquisizione
• Il TCO è sempre costituito da due componenti:
• Costi operativi ricorrenti (Che diremo TCOp) in generale dipendenti dal tempo ,
che risalgono al capitolo delle spese operative (OpEx)
• Costi ‘una tantum’ (Che diremo TCA) in generale non dipendenti dal tempo , che
risalgono al capitolo degli ‘investimenti di capitale’ (CapEx)
• Poichè il TCO è la somma di una componente dipendente dal
tempo (TCOp) ed una non dipendente dal tempo (TCA) esso
ha un valore dipendente dal tempo e quindi va sempre
riferito ad un intervallo di tempo prefissato (per esempio 3
anni)
Page 3.3.40
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Il Metodo TCO – Calcolo del TCO
TCOp = Total Cost of Operations
TCA = Total Cost of Acquisition
•Manutenzione HW & SW
•Hardware (incluso Leasing)
•SW MLC
•Servizi di Migrazione
•Personale per amministrazione
dei Serventi
•Software a canone unico (OTC)
•Costi ambientali (Elettricità,
raffreddamento , Spazio)
•Servizi di installazione
•Ammortamento anticipato
•Costo gestione rete
Definizione di ‘Total Cost of Ownership’ (TCO)
TCO = TCOp1 + TCOp2 + ...... + TCOpn + TCA
La somma è estesa ad un dato intervallo di tempo
Page 3.3.41
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Il Metodo TCO : Componenti
TCOp dipende dal tempo
TCA non dipende dal tempo
TCO dipende dal tempo
Allora
La valutazione del TCO
Quindi
DEVE SEMPRE
Essere riferita ad un intervallo temporale
TCOp = TCOp1 + TCOp2 + TCOp3 + … TCOpk
Dove ciascun membro TCOpn e’ il valore dei costi operatvi riferiti ad un intervallo di tempo
elementare nel quale si assume costante e la somma e’ estesa ai k intervalli elementari
che compongono l’intervallo considerato.
Risulta
Page 3.3.42
TCO = TCOp1 + TCOp2 + .. TCOpk
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
+ TCA
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Metodo TCO : Confronto tra due Soluzioni Informatiche
Sol A
Sol B
Stato Corrente
Migrazione
Stato Futuro
 Elenco dei Server
 Nuovo Elenco Server
 Elenco delle Appliczioni
 Nuova realizzazione Applicazioni
 Costi Totali annui
 Nuovi Costi Totali annui
•Passi di Migrazione
•Sforzo di Migrazione
•Ritorno dell’investimento
•Ammontare
dell’investimento
Page 3.3.43
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Metodo TCO : Uso
Il metodo TCO puo’ essere usato per il confronto di diverse piattaforme informatiche , di diverse
infrastrutture Informatiche o di diverse Soluzioni : in questo caso chiameremo :TCOOLD I costi
correnti della infrastruttura, piattaforma o soluzione attuale e TCONEW i costi della alternativa che
vogliamo confrontare . L’operazione di passaggio verso la nuova piattaforma, soluzione o
Infrastruttura risulter’a conveniente quando si verifica che :
TCOOLD > TCONEW
k
Quindi
k
Σ
(TCOpOLD) i
i=1
+ TCAOLD
> Σ (TCOp ) i
i=1
NEW
+ TCANEW
E datosi che possiamo assumere TCAOLD = 0
Deve
essere
k
TCANEW
k
< Σi=1 (TCOpOLD) i - Σ
(TCOpNEW) i
i=1
Questo e’ il caso in cui un Percorso di Migrazione da OLD verso NEW risulta conveniente
Page 3.3.44
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Metodo TCO : Rappresentazione del TCO
Page 3.3.45
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Metodo TCO : Calcolo del Ritorno dell’Investimento
Cumulative Costs Picture
1.200.000
Costs in Euro
1.000.000
800.000
Cum D
600.000
Cum V
Cum R
400.000
200.000
0
0
5
10
15
20
25
30
35
40
Months
Page 3.3.46
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Metodo TCO : Conclusioni
• Spesso le stesse funzioni possono essere eseguite su
Infrastrutture o Piattaforme Informatiche differenti.
• Si pone quindi la necessita’ di operare un confronto per
determinare una scelta (Platform Selection).
• Il Metodo TCO puo’ essere utilizzato :
•
•
•
•
•
Page 3.3.47
Per Confrontare due o piu’ Piattaforme Informatiche
Per valutare processi di re-hosting
Per Giustificare l’uso di LINUX su Sistemi di Grandi Dimensioni
Per giustificare un Processo di Server Consolidation
In generale in ogni processo di ITRO
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.6: Il Dimensionamento dei Sistemi su diverse
piattaforme Informatiche
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.48
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Cross Platform Sizing
• Il processo che consente di determinare il confronto tra la
potenze elaborative di due Sistemi di diversa Piattaforma
Informatica prende il nome di ‘Cross Platform sizing’.
(dimensionamento multipiattaforma).
• In generale il problema si riconduce a stabilire metriche
equivalenti o universali in grado di valutare le capacita’
indipendentemente dalle Architetture Hardware e dal
Sistema operativo, cioe indipendenti dalla Piattaforma
Informatica.
Page 3.3.49
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Le prestazioni dipendono dalla Piattaforma Informatica
•
Piattaforme Informatiche diverse possono avere caratteristiche
prestazionali diverse , in quanto le diverse architetture Hardware o
i diversi Sistemi Operativi privilegiano ovvero sono specializzati in
alcune componenti del processo elaborativo:
•
•
•
•
•
•
•
Page 3.3.50
Architetture
Architetture
Architetture
Architetture
rivolte
rivolte
rivolte
rivolte
al calcolo intensivo
alle elaborazioni di dati
ai processi commerciali/transazionali
alla grafica.
Nell’effettuare il confronto sara’ bene quindi precisare anche il tipo
di elaborazione (Workload) a cui il confronto si riferisce
Il mercato mette a disposizione dei casi tipici detti ‘benchmark’
relativi allo stesso lavoro che puo’ essere eseguito e misurato su
diverse piattaforme informatiche e quindi confrontato sotto forma
di valore numerico.
Piattaforme diverse possono usare metriche diverse che devono
essere ‘normalizzate’
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Un indicatore ‘semplice’ la frequenza di clock
•
•
•
Abbiamo definito il ciclo base del processore il tempo minimo per eseguire
una istruzione elementare.
L’inverso del ciclo base (misurato in Hertz) si dice frequenza di clock del
processore.
Un semplice approccio per confrontare due Sistemi di diversa piattaforma
informatica costituiti rispettivamente da m ed n processori di frequenza ωn
ed ωm , ed utilizzati rispettivamente Un ed Um in un intervallo di tempo
prefissato e’ dato dalla semplice relazione:
Un * n * ω n * K n = Um * m * ω m * K m
Dove Kn e Km sono valori che tengono conto delle differenze
architetturali tra la due piattafome informatiche considerate.
In generale tali valori sono variabili e dipendono dall’utilizzo U dei
processori . In intervalli predefinitri di utilizzo tali valori possono essere
assunti come costanti. In questo caso indichiamo: WLFnm = Kn / Km
Tale valore e’ detto Workload factor tra le piattaforme informatiche
considerate nell’intervallo in esame. WLF dipende dal tipo di lavoro.
Page 3.3.51
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Esempio: Sistema equivalente
• Come Calcolare il Sistema centrale Linux (n) equivalente ad un
Sistema x86 dato per un lavoro noto con WLF=2.
• Sistema X86:
• Frequenza di Clock = 2.0 Gigahertz (ωm ).
• Numero processori = 2 (m)
• Utilizzo = 20% (Um)
• Sistema Centrale:
• Frequenza di clock = 4.3 Gigahertz (ωn )
• Utilizzo Ipotizzato (System Saturation Point) = 90% (Un)
Un * n * ω n * K n = Um * m * ω m * K m
n = (Um * m * ωm * Km ) / (Kn * ωn * Un )
n = (Um * m * ωm) / (WLF * ωn * Un )
n = (0.2 * 2 * 2.0) / (2 * 4.3 * 0.9 ) = 0.8/ 7.74 = 0,10 IFL
Page 3.3.52
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Esempio: Sistema equivalente
• Come Calcolare il Sistema centrale Linux (N) necessario per
consolidare 100 Sistemi x86 uguali per un lavoro noto con WLF=2.
• Sistemi x86:
• Frequenza di Clock = 2.0 Gigahertz (ωm ).
• Numero processori = 2 (m)
• Utilizzo = 20% (Um)
• Sistema Centrale:
• Frequenza di clock = 4.3 Gigahertz (ωn )
• Utilizzo Ipotizzato (System Saturation Point) = 90% (Un)
Un * n * ω n * K n = Um * m * ω m * K m
n = (Um * m * ωm * Km ) / (Kn * ωn * Un )
n = (Um * m * ωm) / (WLF * ωn * Un )
n = (0.2 * 2 * 2.0) / (2 * 4.3 * 0.9 ) = 0.8/ 7.74 = 0,10
N = 100 n = 100 * (0.2 * 2 * 2.0) / (2 * 4.3 * 0.9 ) =
100 * (0.8/ 7.74) = 10 Processori (IFL)
Page 3.3.53
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Cross Platform Sizing
• Il metodo qui utilizzato e’ semplice e per questo poco
accurato.
• Si presta abbastanza bene per calcolare Consolidamenti su
LINUX ma non e’ adatto a calcoli che coinvolgano z/OS.
• I valori WLF sono misurati in laboratorio e variano da 4 a 0,1
a seconda del tipo di lavoro.
• Esistono metodi piu’ accurati basati su benchmark di
mercato (ad esempio IDEAS.com)
Page 3.3.54
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.7: Esempi di Applicazione del Metodo
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.55
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Il Metodo TCO – Esempi
1. Uso del TCO per giustificare un consolidamento LINUX su
Sistema Centrale
2. Valutazione di una ipotesi di re-hosting
Page 3.3.56
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : I dati del Problema
• Supponiamo di disporre di una infrastruttura
costituita da 50 Serventi Uguali con Sistema
Operativo Windows® che gestiscono una
applicazione di Commercio Elettronico basata su
quattro componenti:
1.Http (web) server 20 Serventi
2.Applicazione JAVA (AS) 10 serventi
3.Data Base Oracle© 4 Serventi
4.Altre Funzioni Infrastrutturali (Firewall, DNS,
Authentication, PDC etc ) 16 Server.
Network
OTHER
Data la particolare applicazione supponiamo
che essa determini per la nostra azienda un
ricavo medio giornaliero di 100.000 € e che la
disponibilita’ media della attuale infrastruttura
sia tale che al massimo essa comporti il fermo di
60 Minuti al giorno .
Page 3.3.57
FW
DNS
20 Server
HTTP
AS
DB
10 Server
4 Server
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
16 Server
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Calcolo del Costo Attuale
• Dati di Partenza :
• Costo Manutenzione SW per servente
= 100 €/Anno
• Costo di Manutenzione HW per
servente = 1000 €/Anno
• Personale necessario a gestire 50
Servers = 5 Persone dal costo medio
annuo di 50.000 € (compresi oneri
previdenziali)
• Consumo di energia elettrica di un
Servente = 300 Watt
• Spazio Occupato da un Servente 625
Cmq (25cm * 25cm)
• Calcoli:
• Costo Manutenzione SW Annuo :
•
100€ x 50 = 5.000 €
• Costo Manutenzione HW annuo
•
1000€ x 50 = 50.000€
• Costo del Personale di Gestione:
•
50.000€ x 5 = 250.000€
• Costo della struttura:
•
•
Page 3.3.58
Spazio: 0,0625mqx50x2x 2000€ = 6.250 €
Power&Cooling= 50x0,3x24x365x0,20x1,5=
39.420€
-
Calcolo del TCOp
•
•
•
•
•
HW =
50.000€
SW =
5.000€
People=250.000€
P&C
39.420€
Space
6.250€
• Totale 350.670€ / Anno
Costo dei Fermi
• Ricavo Orario =
100.000€/24=4.166€/ora
• Perdita di ricavo giornaliera
dovuta a fermi = 4.166 €
• Perdita Annua = 1.520.590€
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : La Tecnologia Abilitante = Virtualizzazione
• Ottimizza le Risorse
• Diminuisce la potenza necessaria .
• Massimizza il Rendimento
• Ottimizza la struttura.
• Diminuisce i Fermi
• Guida verso una Complessiva Semplificazione.
In Complesso Riduce il TCO
Migliora la disponibilta.
Permette l’espansione con l’aggiunta di nuovi Serventi.
Migliora la sicurezza Complessiva
Page 3.3.59
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Ipotesi di Soluzione
Network
Network
FW
OTHER
DNS
16 Server
AS
DB
DNS
FW
OTHER
HTTP
HTTP
20 Server
HTTP
AS
DB
10 Server
4 Server
Page 3.3.60
AS
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Soluzione
• La nuova Infrastruttura risulta costituita da
8 Serventi Virtualizzati con Sistema
Operativo Linux che gestiscono la stessa
Applicazione : essi sono diminuiti come
numero grazie alla scalabilita’ verticale della
nuova piattaforma, la quale concede piu’
potenza alla Singola macchina Virtuale :
1.Http (web) server 2 Serventi
2.Applicazione JAVA (AS) 2 serventi
3.Data Base Oracle© 1 Servente
4.Altre Funzioni Infrastrutturali (Firewall,
DNS, Authentication, PDC etc ) 3 Server.
Network
Network
AS
AS
DB
DNS
FW
OTHER
HTTP
HTTP
Supponiamo che grazie alla caratteristiche
della z/Architecture la nuova infrastruttura
comporti un fermo di 20 Minuti al giorno,
dovuti a cause Software non eliminabili .
Page 3.3.61
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio#1 : Nuovo Calcolo del TCOp • Nuovi Dati di Partenza :
• Costo Manut SW = 30.000 €/Anno
• Costo di Manut HW per tutta la
infrastuttura = 70.000 €/Anno
• Personale necessario a gestire 8
Servers = 2 Persone dal costo
medio annuo di 50.000 €
• Consumo di energia elettrica del
Sistema = 8.5 KWatt
• Spazio Occupato dal Sistema 1 Mq
Calcolo del TCOp
•
•
•
•
•
HW =
70.000€
SW =
30.000€
People= 100.000€
P&C
21.024€
Space
4.000€
• Totale 225.024€ / Anno (36%)
• Calcoli:
• Costo Manutenzione SW Annuo :
•
30.000€ Anno
• Costo Manutenzione HW annuo
•
70.000€
• Costo del Personale di Gestione:
•
50.000€ x 2 = 1000.000€
• Costo della struttura:
•
•
Page 3.3.62
Spazio: 1mqx2x 2000€ = 4.000 €
Power&Cooling= 50x0,3x24x365x0,20x1,5=
39.420€
Costo dei Fermi
• Ricavo Orario =
100.000€/24=4.166€/ora
• Perdita di ricavo giornaliera
dovuta a fermi = 1.387 €
• Perdita Annua = 506.133€ (67%)
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Business Case
• Costo dell’Operazione di Consolidation :
• Definiamo un periodo di tempo consistente con la vita media della Applicazione (ad esempio
3anni = 36 Mesi).
• Calcoliamo il TCOp annuale per la nuova (TCOp new) e vecchia (TCOp old) infrastruttura
• Calcoliamo il TCA (total Cost of Acquisition ) della nuova Infrastruttura dove :
• TCA =
Σ(CostoHw)+Σ(CostoSw)+Σ(CostoMigrazione)
L’operazione risultera’ economicamente conveniente se:
Σ(TCOp old) > Σ(TCOp new) + TCA
Dove la somma e’ estesa al periodo di tempo considerato (36 Mesi) mentre
TCA non dipende dal tempo.
Nel Nostro Caso :
ovvero:
TCOp
old x 3 = 1.070.010 €; TCOp new x 3 = 675.072 €
TCA
< 394.938
considerando
il valore dei Fermi Macchina)
Σ(TCOp
old) -€ (non
Σ(TCOp
new) > TCA
TCA < (3.043.371€ + 394.938€) = 3.438.309€ (considerando la riduzione dei
Genera
una
operazione
economicamente
conveniente.
Fermi
dovuta
alla
nuova Infrastruttura
).
Page 3.3.63
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Rappresentazione del TCOp
TCO Picture
400.000
350.000
300.000
Cost x year
Space
250.000
Power
200.000
People
150.000
Software
Hardware
100.000
50.000
0
Distributed
Virtualized
Solution
Page 3.3.64
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1: Figura dei Costi Complessivi TCOp + TCA
Costs Picture
80.000
70.000
Costs in Euro
60.000
Distr
50.000
Virt
40.000
Real
30.000
Investment
20.000
10.000
0
0
12
24
36
Months
Page 3.3.65
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #1 : Curva della Spesa – Ritorno dell’ investimento
Cumulative Costs Picture
1.200.000
Costs in Euro
1.000.000
800.000
Cum D
600.000
Cum V
Cum R
400.000
200.000
0
0
5
10
15
20
25
30
35
40
Months
Page 3.3.66
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Esempio #1 : La Server Farm in una Scatola
Le Server Farms tradizionali causano costi
crescenti per:
• Manutenzione Hardware
• Spazio, Energia Elettrica, Cooling
• Personale
• Manutenzione SW per CPU/Macchina
• network cabling
• Sistemi di Riserva
• Difficolta’ di Disaster Recovery
Page 3.3.67
z/VM Consolidated Servers favoriscono:
• Condivisione di risorse
• Utilizzo Ottimale dei Siustemi
• Mantenimento Serventi Logici Distinti
• Alta Disponibilita
• Ottima Qualita’ del Servizio
• Facilita’ nel Disaster Recovery
• Connessioni interne ad alta velocita’
• Risparmi in Spazi, Energia, Cooling
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Esempio #2: Valutazione Processo di Re-hosting
• Si vuole valutare l’ipotesi di trasportare le applicazioni in
informatiche in uso su un’altra piattaforma informatica.
• Valuteremo due alternative col metodo TCO:
•
•
•
Page 3.3.68
Scenario Corrente
Re-hosting della applicazione esistente
Riscrittura migliorativa sulla stessa Piattaforma informatica
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #2: Valutazione Processo di Re-hosting
• Opzione di Trasformazione 1 : re-hosting
J2EE
COBOL-CICS
Migration
Appl Server UNIX
Application
AS
COBOL Batch
Front End
Re-Hosting
Managemet
Front End
Batch Server UNIX
COBOL Batch
New Products
Managemet
1
Appl
Service
Appl
Server UNIX
DB2
DB2
Batch
Dev
Migration
DB2/Udb
24 CPU = 157.594 RPE/OLTP
Data
UNIX μPart
Format Conv
z/OS System
Data
Transformatio Option 1
Page 3.3.69
DB Server UNIX
DB Server UNIX
Transformation Option 1 – Infrastructure
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #2: Valutazione Processo di Re-hosting
• Opzione di trasformazione 2 : Riscrittura
COBOL-CICS
Porting
J2EE
Application
AS
COBOL Batch
DB2
Unchanged
z/OS-NALC
z/OS
Batch
2
Management
Unchanged
z/OS
DB2 + WAS
NALC
COBOL Batch
Unchanged
DB2
PR/SM
Management
2737 MIPS ( 3 CPU + 3 zAAP + 1 zIIP )
Data
Unchanged
DATA
z/OS System
Transformation Option 2
Page 3.3.70
z/OS System
Transformation Option 2 - Infrastructure
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #2: Valutazione Processo di Re-hosting
• Calcolo del TCO
TCO 3 Yrs
14.000
12.000
kEURO
10.000
8.000
6.000
4.000
2.000
0
Current
UNIX
zNalc
Miroglio
Industrial
Customer
OPEX x 3
CAPEX
Total Cost of Ownership
Page 3.3.71
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program [Modulo3]
Nota : I dati contenuti sono forniti a titolo di esempio e non rappresentano casi reali
Essi pertanto devono essere considerati rappresentativi del metodo e non del risultato
Esempio #2: Valutazione Processo di Re-hosting
• Calcolo del ROI
ROI
20000
18000
16000
14000
12000
10000
8000
6000
4000
K€
2000
0
1q
2q
3q
4q
5q
6q
7q
8q
9q 10q 11q 12q 13q 14q 15q 16q 17q 18q 19q 20q 21q 22q 23q 24q 25q 26q 27q 28q 29q 30q 31q 32q 33q 34q 35q 36q
Quarters
Current
Unix
zNALC
Spese Cumulate per Trimestre
Page 3.3.72
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3.8: Conclusioni
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.73
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
IBM Scholar Program [Modulo3]
Riflessioni Finali
• La Server Consolidation e’ una esigenza spinta dalla
necessita’ di contenere i Costi di Esercizio aumentando
l’efficienza delle infrastrutture.
• La Tecnologia Abilitante e’ un elemento essenziale per la
soluzione del problema col minimo impatto operativo
• Una Operazione di Consolidamento quindi:
• Non e’ indipendente dalla Tecnologia
• Non e’ sempre vantaggiosa
• La metodologia del TCO e’ uno strumento per:
• Valutare la convenienza di un progetto si Server Consolidation
• Operare una corretta Platform Selection
Page 3.3.74
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008
© Copyright IBM Corp., 2008. All rights reserved.
IBM Scholar Program : [Modulo 3]
3.3 : La Selezione della Piattaforma Informatica e
l’ottimizzazione della Infrastruttura.
© Copyright IBM Corp., 2008. All rights reserved.
Page 3.3.75
Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008