VCAP-DCD, Obbiettivo 1: vSphere Conceptual Design

Creato il 27 aprile 2013 da Roccosicilia @roccosicilia

Il primo gruppo di obbiettivi – cognitivi – per la certificazione VCAP-DCD è relativo alla capacità di definire un “progetto di concetto” dell’infrastruttura che si vuole realizzare.

Il primo, forse banale, passo è conoscere il committente ed i membri che hanno ruoli decisionali in modo da poterli interpellare durante le diverse fasi di analisi. E’ opportuno programmare un meeting di inizio progetto a cui invitare tutti gli interessati e comprendere i diversi ruoli all’interno dell’azienda committente.

A questo primo incontro è bene invitare il management tecnico, i C-level ed una rappresentanza degli utilizzatori finali dell’infrastruttura che si sta progettando. Questi saranno coloro che verranno contattati per discutere i dettagli di progettazione durante le successive fasi di analisi.

Il meeting è indubbiamente un’occasione in cui discutere, più ad ampio spettro, degli obbiettivi di progetto, è quindi necessario preparare una serie di domande da sottoporre ai presenti al fine di iniziare a registrare le informazioni di base. La seconda fase di analisi è infatti l’analisi dello stato attuale ove si dovranno raccogliere tutti i dati relativi all’infrastruttura attualmente esistente.

L’analisi dell’infrastruttura esistente è fondamentale per comprendere come dimensionare il nuovo ambiente vSphere, è infatti possibile utilizzare appositi tools per registrare i dati operativi dei server attivi come i picchi di carico ed il workload medio del sistema. E’ inoltre necessario aver contezza delle applicazioni che risiedono su ogni singolo sistema in quanto esistono software che hanno requisiti ben precisi.

Il risultato di questa analisi è un quadro completo dell’infrastruttura ICT del committente (inventory) che ci stiamo accingendo a revisionare profondamente e dei relativi workload in termini di media di carico e picco di carico. I dati raccolti permetteranno, in fase di progettazione, di dimensionare il Virtual Datacenter nel modo corretto, di scegliere il giusto livello di funzionalità da attivare sul cluster vSphere e di comprendere quali sistemi sono candidabili per la virtualizzazione e quali no.

Il terzo step di progettazione è interamente dedicato al training del committente: è opportuno aiutare il nostro interlocutore a conoscere il prodotto al fine di fargli saggiare le potenzialità in corso di analisi e dar così la possibilità di rivedere alcune scelte prima che l’infrastruttura sia implementata.

Si arriva finalmente alla sessione di analisi vera e propria, il momento in cui il VMware Guru riflette e decide come strutturare il nuovo Virtual Datacenter. Le decisioni da prendere dipendono ovviamente dai dati sino ad ora raccolti, ma non è tutto. E’ necessario interpellare nuovamente i key users del committente affinché si possano definire i reali obbiettivi dell’azienda, sia economici che funzionali, i requisiti che dovrà presentare la nuova infrastruttura ed i vincoli per realizzarla. Inoltre, sulla base di quanto definito, è necessario dichiarare i rischi delle scelte maturate (es: se un vincolo di budget porta ad un s.p.o.f. è necessario declinare al cliente la possibilità di un disservizio generale o parziale a seconda del problema).

La mole di dati, di solito, è importante e tutto va infine rapportato alle best practice di VMware. La prima best practice da attuare è che non tutte le best practice sono necessarie, è sicuramente importante fare tutto al meglio e quindi cercare di rispettarle il più possibile, ma dovendo fare i conti con obbiettivi e vincoli datici dal committente sarà necessario fare dei compromessi e può capitare che una best practice sia inapplicabile perché andrebbe contro gli obbiettivi di progetto. E’ necessario bilanciare i benefici delle best practice e le esigenze del committente per arrivare ad una situazione di equilibrio e soddisfazione reciproca.

L’ultimo step di progettazione si concretizza nella realizzazione di uno o più documenti a seconda del tipo di progetto. E’ ovviamente necessario esporre, tra le varie informazioni, il costo del progetto e la durata dello stesso. Esistono differenti tipologie di documenti da rilasciare a termine analisi, i principali sono i seguenti:

  • Capacity-analysis report: un report relativo al TCO ed al ROI di progetto
  • Design blueprint: un documento tecnico che racchiude il conceptual, logical e phisical design e relative informazioni di implementazione
  • Design verification: un documento che illustra come provare le funzionalità della nuove infrastruttura e sottolinea in che modo si sono raggiunti gli obbiettivi e rispettati i vincoli.

Prossimo tema: Logical Design from an Existing Conceptual Design.


Potrebbero interessarti anche :

Possono interessarti anche questi articoli :