IBM Scholar Program : [Modulo 3] © Copyright IBM Corp., 2008. All rights reserved. Versione...

IBM Scholar Program : [Modulo 3]

© Copyright IBM Corp., 2008. All rights reserved.

Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008Page 3.3.1

3.3 : La Selezione della Piattaforma Informatica e l’ottimizzazione della Infrastruttura.

IBM Scholar Program [Modulo3]

© Copyright IBM Corp., 2008. All rights reserved. Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008Page 3.3.2

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



Versione Italiana a cura di Angelo Barbarino per IBM Scholar Program – GIU 2008.3.3

3.3.0 : Introduzione - Definizioni.



Definizione : Piattaforma Informatica

Definiamo ‘Piattaforma Informatica l’insieme ordinato di :

•Sistema Operativo•Architettura Hardware

X86

Linux

Architettura Hardware

SistemaOperativo

Piattaforma Linux-X86

zArchitecture

Linux

Piattaforma Linux-zArchitecture

zArchitecture

z/OS

Piattaforma z/OS-zArchitecture



Alcune Riflessioni sulle Piattaforme Informatiche• Sono Architetture Hardware:

• x86 (Intel + AMD)• Apple• z/Architecture• PA-RISC• Sun-Sparc• Power IBM• ........

• Sono Sistemi Operativi• 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).



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’.



Portabilita’ delle applicazioni : il ruolo del Middleware

Piattaforma Informatica A

Piattaforma Informatica B

Applicazione Informatica per A

Compilazione

Applicazione Informatica per B

Processo di ‘Porting’

Piattaforma Informatica A

Piattaforma Informatica B

Middleware per A

Copia

Middleware per B

ApplicazioneInformatica

ApplicazioneInformatica



Portabilita’ delle applicazioni : il ruolo degli Standard

Operating Environment

Open & Industry StandardsOpen & Industry Standards


Open & Industry Standards

Business Applications



Open & Industry StandardsOpen & Industry Standards



Business Applications


• 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.




3.3.1 : La Selezione della Piattaforma Informatica - Platform Selection



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.



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.



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.



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.



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



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.



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:• Quali sono gli elementi NON FUNZIONALI piu’ importanti?

• Un modello rigoroso di analisi dei dati forniti dalla metodologia• Quanto vale ogni elemento NON FUNZIONALE ?

• Un processo accurato di confronto delle caratteristiche non funzionali tra le varie piattaforme Informatiche.• 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.• Quali e quante macchine ?

• Una serie di Criteri per valutare tutto cio’ che non e’ immediatamente quantificabile (Best Practice)• Quante persone occorrono per gestire la piattaforma INformatica?




3.3.2 : L’ Infrastruttura Informatica



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.



Infrastruttura Informatica

NetworkNetwork

Ac

ce

ss P

oin

tA

cc

ess P

oin

t

Local Network

Internal Network

Front End

Se

cu

rity

Dati

Internal Network

Core Systems

NetworkNetwork

Ac

ce

ss P

oin

tA

cc

ess P

oin

tA

cc

ess P

oin

tA

cc

ess P

oin

t

Local Network

Internal Network

Front End

Se

cu

rityS

ec

urity

Dati

Internal Network

Core Systems



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.



L’infrastruttura diventa sempre piu’ complessa

Eeterogenea e Distribuita




3.3.3 : Ottimizzazione della Infrastruttura Informatica [ ITRO ]



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).



I Drivers per ITRO

• Maggiore Efficienza

• Migliore Gestibilita’

• Riduzione dei Costi

• Migliore resilienza o Continuita’ di Servizio

• Minori Consumi



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



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




3.3.4 : Server Consolidation



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:• Accentramento• Consolidamento Fisico• Consolidamento Logico

• Le Tecniche di Virtualizzazione sono un elemento ‘abilitante’ per la Server Consolidation in quanto:• Ottimizzano l’uso delle macchine• Consentono di diminuirne il Numero



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.



Server Consolidation : Riepilogo dei Concetti di base

Servente Fisico

zSeries or zSystem

PR/SM

LPAR1 LPAR2 LPAR4LPAR3

z/VM z/VM

z/OS Linuxz/OS Linux

z/VM

Linux Linux z/OSLinuxz/OS

Servente Logico

Servente Logico Virtualizzato



Server Consolidation : Livelli di Consolidamento Vista Applicativa

Accentramento

Paris

London

Rome Rome

ConsolidamentoFisico

ConsolidamentoLogico



Server Consolidation : Livelli di Consolidamento Vista Infrastrutturale

Virtulizzazione Consolidamento Applicazioni

Sist. Op

Appl A

Sist. Op

Appl B

Sist. Op

Appl C

Sist. Op

Appl A

Sist. Op

Appl B

Sist. Op

Appl C

Sist. Op

Appl A

Appl B

Appl C



Server Consolidation - Uso di Linux



Server Consolidation - Semplificazione Layers Applicativi



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.




3.3.5: Un approccio quantitativo basato sui Costi - [ TCO ]



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



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.



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



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)



Il Metodo TCO – Calcolo del TCO

Definizione di ‘Total Cost of Ownership’ (TCO)

TCOp = Total Cost of Operations

•Manutenzione HW & SW

•SW MLC

•Personale per amministrazione dei Serventi

•Costi ambientali (Elettricità, raffreddamento , Spazio)

•Costo gestione rete

TCA = Total Cost of Acquisition

•Hardware (incluso Leasing)

•Servizi di Migrazione

•Software a canone unico (OTC)

•Servizi di installazione

•Ammortamento anticipato

TCO = TCOp1 + TCOp2 + ...... + TCOpn + TCA

La somma è estesa ad un dato intervallo di tempo



Il Metodo TCO : Componenti

TCO = TCOp1 + TCOp2 + .. TCOpk + TCA

TCOp dipende dal tempo

TCA non dipende dal tempo

TCO dipende dal tempo

La valutazione del TCO

DEVE SEMPRE

Essere riferita ad un intervallo temporale

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

Quindi

TCOp = TCOp1 + TCOp2 + TCOp3 + … TCOpk

Allora



Metodo TCO : Confronto tra due Soluzioni Informatiche

Stato Corrente

Elenco dei Server

Elenco delle Appliczioni

Costi Totali annui

Stato Futuro

Nuovo Elenco Server

Nuova realizzazione Applicazioni

Nuovi Costi Totali annui

•Passi di Migrazione

•Sforzo di Migrazione

•Ritorno dell’investimento

•Ammontare dell’investimento

Migrazione

Sol A Sol B



Metodo TCO : Uso

k k

Σ (TCOpOLD) i + TCAOLD > Σ (TCOpNEW) i + TCANEW i=1 i=1

TCOOLD > TCONEW

Quindi

E datosi che possiamo assumere TCAOLD = 0

k k

TCANEW < Σ (TCOpOLD) i - Σ (TCOpNEW) i i=1 i=1

Deve essere

Questo e’ il caso in cui un Percorso di Migrazione da OLD verso NEW risulta conveniente

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 :



Metodo TCO : Rappresentazione del TCO

Running Costs x Year

0

500.000

1.000.000

1.500.000

2.000.000

2.500.000

3.000.000

3.500.000

Current Intel Ph Intel Lg UNIX Z

Sw

Maint

Fac

Staff

one time investment to transform

0

500.000

1.000.000

1.500.000

2.000.000

2.500.000

3.000.000


Hw

SW

3 Years SpendingOTC + MLC

0

1.000.000

2.000.000

3.000.000

4.000.000

5.000.000

6.000.000

7.000.000

8.000.000

9.000.000

10.000.000


Tot 3 Y



Metodo TCO : Calcolo del Ritorno dell’Investimento

Cumulative Costs Picture

0

200.000

400.000

600.000

800.000

1.000.000

1.200.000

0 5 10 15 20 25 30 35 40

Months

Co

sts

in E

uro

Cum D

Cum V

Cum R



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 :• 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




3.3.6: Il Dimensionamento dei Sistemi su diverse piattaforme Informatiche



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.



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:• Architetture rivolte al calcolo intensivo• Architetture rivolte alle elaborazioni di dati• Architetture rivolte ai processi commerciali/transazionali• Architetture rivolte 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’



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 * Kn = Um * m * ωm * Km

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.



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)


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



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)


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)



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)




3.3.7: Esempi di Applicazione del Metodo



Il Metodo TCO – Esempi

1. Uso del TCO per giustificare un consolidamento LINUX su Sistema Centrale

2. Valutazione di una ipotesi di re-hosting



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 Serventi2.Applicazione JAVA (AS) 10 serventi3.Data Base Oracle© 4 Serventi4.Altre Funzioni Infrastrutturali (Firewall, DNS,

Authentication, PDC etc ) 16 Server.

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 .

OTHER

NetworkNetwork

FW

AS

16 ServerDNS

HTTP

DB

20 Server

10 Server 4 Server

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)

Calcolo del TCOp•HW = 50.000€•SW = 5.000€•People=250.000€•P&C 39.420€•Space 6.250€

•Totale 350.670€ / Anno

•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:• Spazio: 0,0625mqx50x2x 2000€ = 6.250 €• 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 = 4.166 €•Perdita Annua = 1.520.590€




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




OTHER

Esempio #1 : Ipotesi di Soluzione

NetworkNetwork

AS

16 Server

HTTP

DB

20 Server

10 Server 4 Server

FW

DNS

OTHERFWDNS HTTP HTTPAS DBAS

NetworkNetwork




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 Serventi2.Applicazione JAVA (AS) 2 serventi3.Data Base Oracle© 1 Servente4.Altre Funzioni Infrastrutturali (Firewall,

DNS, Authentication, PDC etc ) 3 Server.

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 .


NetworkNetwork


NetworkNetwork




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:• 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%)




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) + TCADove la somma e’ estesa al periodo di tempo considerato (36 Mesi) mentre

TCA non dipende dal tempo.

ovvero:Σ(TCOp old) - Σ(TCOp new) > TCAGenera una operazione economicamente conveniente.

Nel Nostro Caso : TCOp old x 3 = 1.070.010 €; TCOp new x 3 = 675.072 € TCA < 394.938 € (non considerando il valore dei Fermi Macchina)

TCA < (3.043.371€ + 394.938€) = 3.438.309€ (considerando la riduzione dei

Fermi dovuta alla nuova Infrastruttura).




Esempio #1 : Rappresentazione del TCOp

TCO Picture

0

50.000

100.000

150.000

200.000

250.000

300.000

350.000

400.000

Distributed Virtualized

Solution

Co

st x

yea

r

Space

Power

People

Software

Hardware




Esempio #1: Figura dei Costi Complessivi TCOp + TCA

Costs Picture

0

10.000

20.000

30.000

40.000

50.000

60.000

70.000

80.000

0 12 24 36

Months

Co

sts

in E

uro Distr

Virt

Real

Investment




Esempio #1 : Curva della Spesa – Ritorno dell’ investimento

Cumulative Costs Picture

0

200.000

400.000

600.000

800.000

1.000.000

1.200.000

0 5 10 15 20 25 30 35 40

Months

Co

sts

in E

uro

Cum D

Cum V

Cum R




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

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



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:• Scenario Corrente• Re-hosting della applicazione esistente• Riscrittura migliorativa sulla stessa Piattaforma informatica




• Opzione di Trasformazione 1 : re-hosting

Transformation Option 1 – Infrastructure

UNIX μPart

Front End Front End

Appl Appl

DB2 Batch Dev

Service

Front End Front End

Appl Appl

DB2 Batch Dev

Service1

24 CPU = 157.594 RPE/OLTP

Transformation Option 1 – Infrastructure

UNIX μPart

Front End Front End

Appl Appl

DB2 Batch Dev

Service

Front End Front End

Appl Appl

DB2 Batch Dev

Service1

24 CPU = 157.594 RPE/OLTP

DB Server UNIX

DB Server UNIX

Server UNIX

Batch Server UNIX

Appl Server UNIX

Transformatio Option 1

z/OS System

COBOL-CICS

ApplicationAS

COBOL Batch

Managemet

DB2

Data

J2EE

COBOL Batch

Managemet

DB2/Udb

Data

Migration

Re-Hosting

New Products

Migration

Format Conv

DB Server UNIX

DB Server UNIX

Server UNIX

Batch Server UNIX

Appl Server UNIX

Transformatio Option 1

z/OS System

COBOL-CICS

ApplicationAS

COBOL Batch

Managemet

DB2

Data

J2EE

COBOL Batch

Managemet

DB2/Udb

Data

Migration

Re-Hosting

New Products

Migration

Format Conv





• Opzione di trasformazione 2 : Riscrittura

z/OS-NALC

z/OS SystemTransformation Option 2

z/OS System

COBOL-CICS

ApplicationAS

COBOL Batch

Management

DB2

Data

J2EE

COBOL Batch

Management

DB2

DATA

Porting

Unchanged

Unchanged

Unchanged

Unchanged

z/OS-NALC

z/OS SystemTransformation Option 2

z/OS System

COBOL-CICS

ApplicationAS

COBOL Batch

Management

DB2

Data

J2EE

COBOL Batch

Management

DB2

DATA

Porting

Unchanged

Unchanged

Unchanged

Unchanged

Transformation Option 2 - Infrastructure

2

2737 MIPS ( 3 CPU + 3 zAAP + 1 zIIP )

PR/SM

z/OSBatch

z/OSDB2 + WAS

NALC

PR/SM

z/OSBatch

z/OSDB2 + WAS

NALC

Transformation Option 2 - Infrastructure

2

2737 MIPS ( 3 CPU + 3 zAAP + 1 zIIP )

PR/SM

z/OSBatch

z/OSDB2 + WAS

NALC

PR/SM

z/OSBatch

z/OSDB2 + WAS

NALC





• Calcolo del TCO

Total Cost of Ownership

TCO 3 Yrs

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

Current UNIX zNalc

Miroglio

kE

UR

O

OPEX x 3 CAPEX

Industrial Customer

Total Cost of Ownership

TCO 3 Yrs

0

2.000

4.000

6.000

8.000

10.000

12.000

14.000

Current UNIX zNalc

Miroglio

kE

UR

O

OPEX x 3 CAPEX

Industrial Customer





• Calcolo del ROI

Spese Cumulate per Trimestre

ROI

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

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

K€

Current Unix zNALC





3.3.8: Conclusioni



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




3.3 : La Selezione della Piattaforma Informatica e l’ottimizzazione della Infrastruttura.

IBM Scholar Program : [Modulo 3] © Copyright IBM Corp., 2008. All rights reserved. Versione...

Documents

Transcript of IBM Scholar Program : [Modulo 3] © Copyright IBM Corp., 2008. All rights reserved. Versione...