WHITE PAPER SULLE BEST PRACTICE. Come utilizzare al meglio un database di gestione delle configurazioni (CMDB)?

Transcript

1 WHITE PAPER SULLE BEST PRACTICE Come utilizzare al meglio un database di gestione delle configurazioni (CMDB)?

2 Indice generale ExEcutive summary... 1 Perché un CMDB... 2 Importanza della gestione delle configurazioni Ruolo essenziale dei dati... 3 Evoluzione del CMDB... 3 Approccio raccomandato al CMDB... 6 Contenuto di un CMDB ITIL... 6 Quadro generale... 8 Funzione del CMDB Federazione di dati Modello di dati flessibile Partizionamento delle configurazioni...11 Riconciliazione delle configurazioni...11 Accesso aperto ai dati Conclusioni Glossario... 14

3 Executive summary L uso di un database di gestione delle configurazioni (CMDB) può essere necessario, ma occorre capire perché e soprattutto sapere come affrontare questo argomento. Nel presente white paper elaborato da BMC Software viene dimostrata l importanza della gestione della configurazione e dell uso di un CMDB, in particolare, in relazione agli obiettivi di una IT Infrastructure Library (ITIL ). Vengono definiti i diversi tipi di dati solitamente contenuti in un CMDB, dagli elementi di configurazione (CI, Configuration Item) alle relazioni con i dati associati, ad esempio, le richieste di modifica e un modello di impatto dei servizi. Dopo una breve analisi degli approcci al CMDB già tentati, quali l integrazione di data store o l inserimento di tutti i dati in un unico database centrale, il presente documento illustra il nostro approccio al CMDB: un modello federato che funge da fonte di record per gli elementi di configurazione, ma protegge l investimento attuale nei data store esistenti. Vengono esaminate le caratteristiche richieste da un CMDB, comprendenti un modello di dati flessibile, il partizionamento delle configurazioni, la riconciliazione delle configurazioni e l accesso aperto ai dati. Viene spiegato in che modo ciascuna di queste caratteristiche contribuisce a creare una soluzione di configurazione generale che consente alle organizzazioni IT di fornire un servizio della più alta qualità possibile. PA G I N A >

4 Perché un CMDB In considerazione del crescente interesse registrato nell adozione delle best practice tra reparti IT diversi, soprattutto in base a standard quali ITIL, molte organizzazioni hanno ora deciso di implementare un database di gestione delle configurazioni (CMDB). Si sono accorte del valore business derivante dall uso di un unica fonte di record capace di fornire un modello logico di infrastruttura IT con cui identificare, gestire e verificare tutti gli elementi di configurazione (CI, Configuration Item) nell ambiente operativo. Importanza della gestione della configurazione Il compito svolto dai reparti IT per fornire servizi affidabili per il conseguimento degli obiettivi business di un azienda è alquanto impegnativo. Per riuscire a superare gran parte delle difficoltà, è richiesta una strategia di gestione delle configurazioni efficace: senza conoscere i componenti del proprio ambiente, è impensabile sperare di controllarlo, mantenerlo o migliorarlo. Obiettivi Come indicato nel manuale Service Support di ITIL, gli obiettivi per la gestione delle configurazioni devono includere i seguenti: >..Rispondere di tutti gli asset e le configurazioni IT all interno dell organizzazione e dei relativi servizi >..Fornire informazioni precise sulle configurazioni e la relativa documentazione a supporto di tutti gli altri processi di gestione dei servizi >..Fornire una solida base per la gestione di incidenti, problemi, cambiamenti e release >..Verificare i record delle configurazioni rispetto all infrastruttura e correggere eventuali eccezioni Vantaggi La realizzazione di questi obiettivi può risultare vantaggiosa per l organizzazione sotto vari aspetti importanti e quantificabili di controllo, integrazione e supporto decisionale. Controllo La verifica e la correzione dei record delle configurazioni fornisce un livello più ampio di controllo dell infrastruttura. Ad esempio, attraverso il controllo delle versioni degli elementi di configurazione, è possibile ridurre la complessità dell ambiente e quindi dei costi per il supporto del desktop. In tal modo, è possibile notare gli elementi che compaiono o scompaiono senza contropartita ed eseguire un controllo degli asset senza incorrere in problemi di natura legale. Un maggiore controllo dell ambiente determina inoltre un maggiore livello di sicurezza complessiva. Integrazione I processi per la gestione di incidenti, problemi, cambiamenti e release basati su un record corrente della configurazione utilizzata possono essere integrati, in modo da ridurre i costi di amministrazione e il rischio di errori. Ad esempio, è possibile integrare i processi di gestione degli incidenti e dei cambiamenti in due modi: >.Se la risoluzione di un incidente richiede una modifica, l applicazione per la gestione degli incidenti può creare automaticamente la richiesta di modifica. >.Un applicazione per la gestione di incidenti o problemi può servirsi di un modello di servizio con cui individuare le modifiche precedenti che possono avere causato un errore. L integrazione di tutti i processi IT legati alle configurazioni può portare alla riduzione del personale addetto all amministrazione dell ambiente, con conseguente risparmio economico. Supporto decisionale L abbinamento di queste informazioni di configurazione aggiornate ai processi di gestione dei servizi aziendali si rivela vantaggiosa per i manager IT. È più facile prendere decisioni quando si dispone di dati completi e precisi; viene inoltre migliorata la valutazione delle risorse e delle prestazioni. È possibile contare con maggiore tranquillità sui livelli dei servizi e migliorare la gestione dei rischi, con la conseguente riduzione del downtime non pianificato. 1. Office of Government Commerce, Best Practice for Service Support. (London: The Stationery Office, 2000). PA G I N A >

5 Ruolo essenziale dei dati È possibile iniziare la gestione delle configurazioni con uno dei processi sopra descritti o con molti altri. Tuttavia, a prescindere dai processi di gestione delle configurazioni implementati, l aspetto che li rende efficaci è costituito dai dati utilizzati. La precisione dei dati di configurazione è importante; per questo i dati devono essere aggiornati di frequente. Le configurazioni mutano continuamente, perciò i dati considerati attuali in un determinato momento potrebbero risultare obsoleti dopo una settimana e portare, ad esempio, all acquisto di dieci server quando in realtà ne occorrono soltanto cinque o addirittura all installazione di un patch di sicurezza che causa il blocco del sistema. I dati di configurazione devono inoltre essere disponibili per tutti i processi IT perché anche i dati più aggiornati non servono a nulla se non è possibile accedervi. Ad esempio, se i dati della topologia di rete forniti dall applicazione di discovery non sono accessibili per l applicazione di gestione dei cambiamenti, non è possibile pianificare in maniera intelligente una riprogettazione della rete. Evoluzione del CMDB Il concetto di CMDB si è evoluto nel tempo da semplice raccolta di data store isolati all idea di data store integrati in un singolo database centrale, fino da avvicinarsi sempre più a una soluzione che prevede un unica fonte di record per i dati di configurazione senza gravare sull infrastruttura. Data store isolati Inizialmente, un CMDB era costituito semplicemente da diverse applicazioni in cui venivano archiviati i dati applicativi e spesso da altri database contenenti i dati di configurazione, come illustrato nella Figura 1. Questo approccio era in grado di soddisfare l obiettivo primario di ITIL, il quale consisteva nel rendere conto di tutti gli asset e i servizi IT. L applicazione per la gestione degli asset non era in grado di rilevare i dati di un applicazione di discovery e la gestione dell impatto dei servizi non poteva modificare i contratti di servizio (SLA). La soluzione che consente di preservare l accuratezza. dei dati di configurazione condivisi da più processi IT è. un CMDB. Richieste Elementi di configurazione e rispettive relazioni impatto servizi asset Applicazione di discovery 1 problemi Applicazione di discovery 2 cambiamenti SLA Libreria software definitivo Contratti incidenti Figura 1. Data store isolati PA G I N A >

6 Un altro svantaggio era dato dalla mancanza di un singolo punto di accesso, la quale costringeva gli utenti che richiedevano i dati a sapere dove e come trovarli. Infine, questo approccio non consentiva di memorizzare le informazioni sulle relazioni tra elementi di configurazione. Per maggiori informazioni sulle relazioni, vedere le informazioni riportate in Relazioni tra elementi di configurazione nella sezione Approccio raccomandato. al CMDB di questo documento. Data store integrati Successivamente, le organizzazioni IT hanno cercato anche di creare CMDB mediante l integrazione diretta di varie fonti di dati e applicazioni, collegando ciascun consumer dei dati al provider da cui necessitava informazioni, come illustrato nella Figura 2. Grazie a questo approccio, è stato possibile ottenere la condivisione dei dati tra diversi processi di gestione delle configurazioni, con conseguente notevole miglioramento dell utilità dei CMDB. Tuttavia, erano richieste numerose risorse per creare e gestire le varie integrazioni. Inoltre, analogamente all approccio dei data store isolati, chi non conosceva sufficientemente il sistema non sapeva dove cercare determinati dati. Richieste Elementi di configurazione e rispettive relazioni impatto servizi asset Applicazione di discovery 1 problemi Applicazione di discovery 2 cambiamenti SLA Libreria software definitivo Contratti incidenti Figura 2. Integrazione diretta di data store diversi PA G I N A >

7 Database centralizzato unico Di recente, alcuni fornitori hanno proposto un CMDB singolo onnicomprensivo per i dati di configurazione, accessibile da tutte le applicazioni che necessitano dei dati, come illustrato nella Figura 3. In questo approccio, le applicazioni integrate nel CMDB (sia consumer che provider dei dati) possono accedere a tutti i dati relativi alle configurazioni; pertanto, la condivisione viene portata a un livello superiore rispetto all approccio dei data store integrati. Inoltre, viene offerto un singolo punto di accesso, grazie al quale il CMDB diventa la fonte di record a cui gli utenti possono inviare tutte le richieste. Anche un database onnicomprensivo presenta tuttavia alcuni svantaggi. Richiede una capacità elevata in un unico punto e genera intasamenti perché tutte le richieste di aggiornamenti dei dati devono attraversare lo stesso percorso. È inoltre richiesto un imponente processo di migrazione per trasferire tutti i dati in un singolo database, creando un modello di dati complesso che dovrà essere modificato ad ogni cambiamento di una delle applicazioni integrate nel CMDB. Infine, se tali applicazioni non provengono dallo stesso fornitore del CMDB, tutte le integrazioni rischiano di rivelarsi procedure particolarmente impegnative. Richieste impatto servizi asset Applicazione di discovery 1 Applicazione di discovery 2 cambiamenti CI e relazioni Modello servizio Contratti Asset DSL Problemi Incidenti Richieste cambiamento SLA problemi SLA incidenti Figura 3. Database centralizzato unico PA G I N A >

8 Approccio raccomandato al CMDB BMC Software ritiene che l uso di un CMDB con un modello di dati federato, dotato di un database centralizzato collegato ad altri data store, sia il modo migliore di condividere i dati di configurazione senza dovere sostenere i costi elevati di installazione e manutenzione associati all approccio centralizzato puro. In questa sezione vengono descritti i tipi di dati utilizzati e quindi viene spiegata in dettaglio la separazione dei dati effettuata attraverso il modello federato. Contenuto di un CMDB ITIL ITIL raccomanda di archiviare tipi di dati diversi nel CMDB. In tal modo, è possibile mantenere gli elementi di configurazione e le rispettive interrelazioni per ottenere una configurazione in un dato momento o in determinate condizioni. ITIL informa inoltre che il CMDB può contenere dati correlati agli elementi di configurazione, ad esempio, ticket di help desk o definizioni SLA. Cos è un elemento di configurazione? Gli elementi di configurazione costituiscono la base di un CMDB. Senza una chiara definizione di ciò che può essere considerato un elemento di configurazione, non è possibile valutare con certezza l opportunità di collocare dati di natura diversa nel CMDB. In parole povere, un elemento di configurazione è un istanza di un entità che fa parte dell ambiente e che presenta attributi configurabili specifici di tale istanza. Queste entità possono essere fisiche (ad esempio, un sistema di computer), logiche (ad esempio, un istanza installata di un programma software) o concettuali (ad esempio, un servizio business); tuttavia, devono essere una parte diretta dell ambiente, piuttosto che semplici informazioni su tale parte. Gli esempi seguenti illustrano i concetti appena esposti. Elementi di configurazione Un sistema di computer fa parte dell ambiente e presenta attributi configurabili, quali numero di serie, velocità del processore e indirizzo IP. Un edificio fa parte dell ambiente e presenta attributi configurabili, quali numero di stanze, sistema di condizionamento dell aria e allarme antifurto. Un dipendente fa parte dell ambiente e presenta attributi configurabili, quali capacità, orario di lavoro e reparto. Un istanza di software installata su un sistema di computer fa parte dell ambiente e presenta attributi configurabili, quali numero di serie, livello di patch e metodo di sviluppo. Un servizio business fa parte dell ambiente e presenta attributi configurabili, quali livello di importanza per il business e costo dell interruzione del servizio. Elementi non di configurazione Un ticket di help desk presenta attributi configurabili, ma non fa parte direttamente dell ambiente. Fanno invece parte dell ambiente le informazioni sulle altre entità (ad esempio, un sistema di computer). Un pacchetto software archiviato fa parte dell ambiente e viene in genere conservato nella libreria DSL (Definitive Software Library). Un contratto di servizio (SLA) presenta attributi configurabili, ma non fa parte direttamente dell ambiente. Fanno invece parte dell ambiente le informazioni sulle altre entità (ad esempio, un server Web). Un contratto presenta attributi configurabili, ma non fa parte direttamente dell ambiente. Fanno invece parte dell ambiente le informazioni sulle altre entità (ad esempio, una fotocopiatrice).. Un evento non presenta attributi configurabili e non fa parte dell ambiente. Tabella 1. Cos è un elemento di configurazione? PA G I N A >

9 Naturalmente non tutto ciò che può essere considerato un elemento di configurazione è degno di nota; pertanto, non occorre creare appositi record nel CMDB per tutti i dipendenti dell organizzazione. Relazioni tra elementi di configurazione Gli elementi di configurazione sono collegati tra loro. Un elemento di configurazione può utilizzare altri elementi di configurazione, può essere subordinato ad altri elementi di configurazione, essere un componente di altri elementi di configurazione, attivare altri elementi di configurazione, appartenere a un gruppo di elementi di configurazione o essere contenuto in altri elementi di configurazione, tanto per fornire qualche esempio. La memorizzazione di queste relazioni nel CMDB consente di analizzare le interrelazioni e le interdipendenze tra gli elementi di configurazione. Tali relazioni possono essere semplici, come ad esempio l appartenenza di un unità disco a un sistema di computer in qualità di componente, o più complesse, come quelle illustrate nella Figura 4. Le relazioni non esistono soltanto tra elementi di configurazione fisici, ma anche tra elementi di configurazione logici e concettuali, quali le istanze del software e i servizi indicati nella Figura 4. Tra due elementi di configurazione possono esserci anche più relazioni: ad esempio, un dipendente può essere proprietario di un server e utilizzarlo. I dati delle relazioni fanno del CMDB uno strumento efficace di supporto decisionale. La comprensione delle dipendenze e della altre relazioni che intercorrono tra elementi di configurazione possono indicare, ad esempio, in che modo l aggiornamento del Processore A può migliorare le prestazioni del Server B o quali servizi vengono ridotti in caso di guasto del Router C. Gran parte del downtime viene causato da problemi derivanti dai cambiamenti di configurazione e queste informazioni possono essere utilizzate per evitare che ciò accada. Dati correlati Le informazioni correlate agli elementi di configurazione sono numerose: ticket di help desk, eventi di cambiamento, contratti, contratti di servizio (SLA),. libreria DSL (Definitive Software Library) e molto altro.. Pur non essendo elementi di configurazione, questi dati contengono comunque informazioni sugli elementi di configurazione e rappresentano una parte importante dell infrastruttura IT. Subordinato a Store online (servizio) Subordinato a Subordinato a Database ordini (istanza software) Utilizza Server Web Superiore a Carrello (istanza software) Utilizza Utilizza Unità disco 1 Unità disco 2 Figura 4. Esempi di relazioni PA G I N A >

10 Quadro generale Il CMDB e la relativa infrastruttura devono essere suddivisi in tre layer: il CMDB stesso, i dati correlati collegati in modo bidirezionale al CMDB (dati estesi del CMDB) e le applicazioni che interagiscono con questi due layer (ambiente CMDB), come illustrato nella Figura 5. I layer del CMDB e dei dati estesi del CMDB compongono insieme ciò che ITIL definisce un CMDB. La suddivisione di quest ultimo in altri due layer distingue l approccio federato da quelli descritti in Evoluzione del CMDB nella sezione Perché un CMDB di questo documento. CMDB Il CMDB contiene soltanto gli elementi di configurazione e le rispettive relazioni, ma alcuni degli attributi possono essere collegati ai dati estesi del CMDB. Tuttavia, non è necessario memorizzare nel CMDB tutti gli attributi degli elementi di configurazione disponibili: al contrario, è necessario memorizzare soltanto gli attributi chiave e creare un collegamento a quelli meno importanti conservati nel layer dei dati estesi. Sebbene il CMDB non contenga tutti i dati degli attributi o i dati correlati, funge tuttavia da fonte di record per i dati di configurazione in quanto rappresenta un collegamento ai dati estesi del CMDB. È possibile inoltrare tutte le richieste al CMDB e se i dati necessari non sono contenuti in tale sede, è possibile utilizzare i collegamenti di riferimento alle posizioni di archiviazione dei dati e alle informazioni su come è possibile accedere ai dati. SLA Ambiente CMDB Applicazioni capacità config. software cambiamenti applicazioni Applicazione di discovery 1 impatto servizi asset identità Applicazione di discovery 2 Help Desk incidenti Fornitura problemi Richieste Dati estesi CMDB Informazioni correlate ai CI CMDB esteso Richieste di cambiamento Ticket di help desk Collegamenti tra record Dati CI federati Contratti servizio (SLA) Contratti Altri dati correlati ai CI DSL (Definitive Software Library) CMDB Elementi di configurazione e rispettive relazioni Figura 5. Infrastruttura raccomandata del CMDB con modello di dati federato PA G I N A >

11 Dati estesi del CMDB I dati estesi del CMDB contengono i dati specificati in Dati correlati nella sezione Approccio raccomandato al CMDB del presente documento, oltre agli attributi degli elementi di configurazione la cui memorizzazione nel CMDB viene ritenuta superflua. I dati del layer dei dati estesi del CMDB sono collegati ai dati degli elementi di configurazione nel CMDB. Per definizione, gli attributi federati degli elementi di configurazione sono collegati alle rispettive istanze nel CMDB, in modo da consentire alle richieste al CMDB di raggiungere tali attributi. Per altri tipi di dati estesi, invece, il collegamento può essere in una singola direzione o bidirezionale. Ad esempio, un record di richiesta di cambiamento può avere un collegamento tramite il quale è possibile accedere alle istanze degli elementi di configurazione interessati dal cambiamento e ciascuna istanza di elemento di configurazione può avere un collegamento tramite il quale è possibile accedere alle richieste di cambiamento che lo riguardano. Questa strategia offre diversi vantaggi: > Il CMDB può concentrare la propria funzionalità sugli elementi di configurazione e sulle rispettive relazioni. Tale funzionalità comprende partizioni per più versioni istantanee, riconciliazione di dati da più fonti e dati federati ed è descritta in dettaglio nella sezione Funzione del CMDB del presente documento. > Le risorse impegnate per ottenere questa funzionalità non vengono sprecate per dati che non le necessitano. Ad esempio, l uso di più istantanee di una libreria DSL è superfluo; pertanto, è preferibile non introdurre alcuna libreria DSL come parte del CMDB per non occupare inutilmente spazio di archiviazione prezioso. > Non è necessario modificare il CMDB per contenere i dati correlati. La definizione dei limiti tracciati in corrispondenza degli elementi di configurazione e delle rispettive relazioni risolve già la questione della scelta della posizione di archiviazione di un nuovo tipo di dati nel CMDB. Questi ultimi vengono archiviati invece come parte dei dati estesi del CMDB, in modo da evitare di dover cambiare il modello di dati nel CMDB per rendere possibile l aggiunta del nuovo tipo di dati. Si evitano inoltre i problemi derivanti dalla semplificazione del modello di dati nel caso in cui si decida in un secondo momento di estrarre i dati dal CMDB. > I dati transazionali possono essere memorizzati in database più idonei alla gestione di un elevato volume di richieste, invece che nel CMDB. > I dati vengono forniti con maggiore efficienza. Anziché ottenere tutti i dati dal CMDB, i consumer di dati possono accedervi da singoli data store ottimizzati in maniera tale da fornire il tipo di dati specifico richiesto. > Non occorre effettuare diverse migrazioni di dati e integrazioni di applicazioni per trasferire le richieste di cambiamento, i ticket di help desk e gli altri dati correlati agli elementi di configurazione nel CMDB. Le applicazioni che utilizzano questi dati possono continuare ad accedervi nella posizione in cui i dati vengono attualmente memorizzati. > Il CMDB non diventa un collo di bottiglia che provoca intasamenti. Attraverso la gestione delle richieste di dati correlati individuali da parte di altri database, il CMDB non deve sostenere tale traffico in aggiunta alle richieste correlate agli elementi di configurazione. Il carico può essere distribuito tra più sistemi. Sebbene sia possibile archiviare i dati estesi del CMDB in un unica posizione, questa operazione non è obbligatoria. I diversi tipi di dati di questo layer non sono necessariamente collegati né correlati tra loro. L unico aspetto che devono avere in comune è un collegamento bidirezionale con il CMDB. CMDB esteso Il CMDB e i dati estesi del CMDB costituiscono insieme il CMDB esteso, il quale coincide con il concetto di CMDB utilizzato da ITIL. Ambiente CMDB Se il CMDB esteso contiene dati, l ambiente CMDB viene dedicato alle applicazioni che forniscono e utilizzano tali dati. Queste applicazioni possono accedere al CMDB, al CMDB esteso o a entrambi. Ad esempio, un applicazione di gestione degli asset che consente di visualizzare e modificare le istanze degli elementi di configurazione nel CMDB fa parte dell ambiente CMDB in qualità di consumer, mentre un applicazione di discovery che consente di creare istanze degli elementi di configurazione nel CMDB fa parte dell ambiente CMDB in qualità di provider. Queste applicazioni talvolta archiviano le proprie informazioni in appositi database; tuttavia, tali componenti continuano a essere considerati appartenenti a layer diversi dell infrastruttura del CMDB. Ciascuna applicazione fa parte dell ambiente CMDB, mentre i dati correlati alla rispettiva configurazione fanno parte del CMDB esteso. Naturalmente le applicazioni dell ambiente CMDB possono inoltre accedere ai dati non correlati agli elementi di configurazione. Questi dati non fanno parte del CMDB esteso. PA G I N A >

12 Funzione del CMDB Nella sezione Approccio raccomandato al CMDB è stato descritto come strutturare il CMDB e correlarlo al resto dell infrastruttura. Tuttavia, pur disponendo della struttura adeguata, un CMDB deve essere dotato di diverse caratteristiche per gestire gli elementi di configurazione con efficacia. Tali caratteristiche sono: >..Federazione di dati > Modello di dati flessibile > Partizionamento delle configurazioni > Riconciliazione delle configurazioni > Accesso aperto ai dati Federazione di dati Questo argomento è stato trattato in precedenza nel presente documento, pertanto è noto che una federazione si riferisce a un repository centrale contenente determinati dati e collegamenti ad altri dati. di altre fonti. Può essere opportuno eseguire la federazione di alcuni attributi se si desidera registrarli, senza però registrarli troppo spesso o con particolare impegno come per gli attributi chiave degli elementi di configurazione. Questi attributi secondari sono i primi di due tipi di dati che è possibile federare. Pertanto, ad esempio, il record CMDB di un dipendente potrebbe riportare un attributo Capacità contenente un elenco delle capacità del dipendente e un attributo Reparto contenente il nome del reparto del dipendente. Potrebbe inoltre presentare una relazione con un data store di Risorse umane contenente ulteriori attributi, ad esempio, Salario, non particolarmente importanti dal punto di vista della configurazione. L altro tipo riguarda i dati correlati agli elementi di configurazione, in cui però i dati non sono effettivamente attributi di un elemento di configurazione; si tratta infatti di dati che fanno riferimento a un elemento di configurazione o a cui viene fatto riferimento da un elemento di configurazione per fornire ulteriore contenuto sulla funzionalità estesa, ma non fanno parte dell elemento di configurazione stesso. Ad esempio, i record di elementi di configurazione relativi alle istanze del software possono presentare una relazione di licenza contenente l indirizzo URL di una pagina intranet nella quale è pubblicata la licenza, oppure ciascun record di elementi di configurazione può presentare una relazione Problemi contenente le informazioni necessarie alla ricerca di tutte le questioni relative agli elementi di configurazione in un database di problemi. L uso di dati federati presenta diversi vantaggi: >..Risparmio di risorse impegnate per importare, registrare e riconciliare i dati del CMDB >..Metodo standard per realizzare riferimenti incrociati tra dati correlati >..Possibilità di collocare i dati federati in più posizioni diverse >..Destinazione dell investimento ad altri data store Modello di dati flessibile Sono disponibili diversi tipi di elementi di configurazione, dai sistemi di computer all hardware di rete ai server di software. Senza un modello di dati in grado di riflettere con precisione questi tipi di dati e i tipi di relazioni esistenti tra loro, il CMDB potrebbe contenere attributi non pertinenti ai relativi elementi di configurazione, escludere gli attributi necessari e rendere più complessa la ricerca di gruppi di elementi di configurazione. Questo modello di dati deve essere sia orientato agli oggetti che estendibile. Orientamento agli oggetti Il modello di dati orientato agli oggetti presenta un insieme gerarchico di classi, ciascuna delle quali assume gli attributi della classe di livello superiore nella gerarchia e aggiunge i propri contributi in modo da creare un tipo di oggetto, ovvero una sottoclasse, più specifico. Le sottoclassi possono contenere ulteriori sottoclassi che estendono la gerarchia al livello di dettaglio che si desidera registrare. Ad esempio, la classe SistemaComputer può presentare gli attributi Dominio, TipoProcessore e Produttore.. La classe SistemaComputer può a sua volta contenere sottoclassi, quali ComputerLaptop, ComputerDesktop e ComputerMainframe. Ciascuna di queste sottoclassi presenta i tre attributi della classe superiore, oltre ai propri attributi specifici. Nella Figura 6 viene illustrata una parte del modello di dati del CMDB orientato agli oggetti, compresa una classe superiore e due livelli di sottoclassi. Il modello di dati orientati agli oggetti presenta vantaggi quali l applicazione di attributi comuni tra tipi analoghi di elementi di configurazione e la capacità di eseguire ricerche non solo all interno di una determinata classe di elementi di configurazione, ma anche all interno di un ramo qualsiasi della gerarchia. Se il modello di dati contiene un unica classe di base da cui derivano tutte le sottoclassi, è possibile ricercare tutti gli elementi di configurazione e le rispettive relazioni. PA G I N A > 10

13 Componenti sistema hardware Stampante locale Tastiera Supporti Memoria Monitor Dispositivo puntamento Processore Pacchetto UPS hardware CD ROM Unità disco Unità dischetti Unità nastro Scheda Telaio Rack Figura 6. Parte di modello di dati orientato agli oggetti Estendibilità L infrastruttura e la tecnologia su cui si basa sono in continuo mutamento. Di conseguenza, anche i tipi di elementi di configurazione e le relazioni nel CMDB devono mutare; per questo motivo, è necessario che il modello di dati sia estensibile. Deve essere possibile aggiungere e rimuovere gli attributi delle classi e persino aggiungere e rimuovere le classi stesse. Nonostante l importanza di questa funzione, occorre evitare di farne un uso eccessivo. Il CMDB deve contenere solo gli elementi di configurazione comuni e le rispettive relazioni. L aggiunta di classi e attributi riguardanti elementi di configurazione di importanza minima determina un inutile sovraccarico del CMDB. Inoltre, l eccessiva suddivisione in sottoclassi può comportare la creazione di classi talmente definite da contenere soltanto pochi componenti. È opportuno trovare il giusto equilibrio tra la necessità di classificazione e la necessità di archiviazione congiunta di elementi di configurazione analoghi. Partizionamento delle configurazioni Il partizionamento è la capacità di suddividere i dati di configurazione in componenti denominati set di dati, ciascuno dei quali rappresenta un insieme di dati rilevato in un determinato momento. Questa suddivisione consente l esistenza di istanze dello stesso elemento di configurazione o della stessa relazione in più set di dati. Si tratta di una funzione importante ai fini della verifica e della correzione dei record di configurazione rispetto all infrastruttura. È possibile creare un set di dati con cui rappresentare la configurazione desiderata, quindi usare un applicazione di discovery per creare un altro set di dati che rappresenti la configurazione effettiva e confrontare infine il primo con il secondo. Il partizionamento è uno strumento efficace che può essere usato per numerose finalità. I set di dati possono rappresentare: > Una configurazione obsoleta > Una configurazione futura > Una configurazione standard di base collaudata > Versioni diverse di una configurazione attuale > Sottoinsiemi di una configurazione generale > Dati forniti da diverse applicazioni di discovery > Dati provenienti da configurazioni di client diversi. (multi-proprietà) > Altre finalità desiderate Riconciliazione delle configurazioni Se si dispone di più set di dati contenenti le stesse istanze, la riconciliazione è il processo di identificazione di istanze corrispondenti in tutti i set di dati e quindi il confronto delle diverse versioni di ciascuna istanza con indicazione delle differenze o la fusione dei set di dati in un unico nuovo set di dati. In tal modo, è possibile verificare i cambiamenti nel tempo o determinare una configurazione desiderata quando sono presenti dati provenienti da più fonti di discovery. Identificazione delle istanze Prima di confrontare le diverse versioni di un oggetto, è necessario stabilire se effettivamente queste rappresentano la stessa entità. Questa operazione viene effettuata attraverso l identificazione, con la quale vengono applicate le regole specificate rispetto alle istanze della stessa classe in due o più set di dati diversi. Ad esempio, una regola fissata per l identificazione di istanze di sistemi di computer può specificare che gli indirizzi IP di entrambe le istanze devono essere uguali. Quando la regola trova una corrispondenza, entrambe le istanze vengono contrassegnate con la stessa identità, ovvero con un attributo aggiuntivo con cui viene indicato che ciascuna istanza rappresenta lo stesso elemento nel proprio set di dati. PA G I N A > 11