UniTO/anno2/Sem2/GR/GR-Capitolo-1-Appunti.txt

Appunti delle lezioni di
Gestione di Sistemi e Reti
2006-2007
Franco Sirovich
© Franco Sirovich 1

1. Che cosa è un sistema di gestione?
1.1. Quando serve un sistema di gestione?
La cosa inizialmente più difficile da afferrare è il ruolo e lo scopo di un sistema di gestione, in
quanto è un componente di un sistema informatico con il quale, nella esperienza comune di
utilizzatori del sistema, non si viene a contatto. È un componente che viene usato dal personale che si
occupa del corretto funzionamento del sistema, e non dagli utilizzatori finali del sistema. Questa
distinzione fra "utilizzatori" va tenuta ben presente quando si parla di gestione: occorre non
confondere gli utilizzatori del sistema gestito con gli utilizzatori del sistema di gestione.
I sistemi informatici vengono costruiti e messi in campo per rispondere alle esigenze dei loro
utilizzatori. Per essere utili, oltre ad avere funzionalità ben concepite ed essere ben realizzati, devono
"funzionare": un bel sistema che fa cose meravigliose quando funziona ma che è spesso (e soprattutto
quando se ne ha bisogno) malfunzionante ("down"), non risponde alle esigenze degli utilizzatori. Ciò
che è difficile credere, se non si ha esperienza, è che un sistema informatico deve essere gestito se si
vuole che continui a funzionare come da sue specifiche: pare incredibile che lasciato a se stesso
rapidamente diventi inutilizzabile. Per questa ragione si sviluppano sistemi di gestione.
Un Sistema di Gestione deve permettere di
●

monitorare in maniera automatica tutto il sistema informatico,

●

analizzare il guasto,

●

aiutare a individuare la probabile causa,

●

attivare operazioni automatiche di riparazione o di richiesta di intervento umano.

Il Sistema di Gestione non elimina la necessità di personale di gestione, ma permette una gestione
più efficace e possibilmente proattiva, cioè che anticipa i problemi ed evita che essi si verifichino.
Una gestione reattiva invece permette soltanto di reagire ad un problema quando questo si verifica.
Chiaramente abbiamo bisogno sia di una gestione proattiva, che di una gestione reattiva perché una
gestione proattiva non può evitare completamente che si verifichino problemi o guasti. I sistemi
1 Quest'opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Non commerciale-Non opere derivate
2.5 Italia. Per leggere una copia della licenza visita il sito web http://creativecommons.org/licenses/by-nc-nd/2.5/it/ o
spedisci una lettera a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

1 di 17

informatici devono essere gestiti, e per questo si sviluppano sistemi di gestione.
GSR è un corso sulla gestione di sistemi distribuiti, cioè sistemi costituiti da macchine ed
applicazioni connesse in rete. Quando si deve gestire un sistema distribuito di deve anche gestire la
rete che interconnette le macchine. Gli aspetti di comunicazione diventano quindi quelli più
importanti, e quanto più numerosi sono i componenti di un sistema tanto più numerose sono le fonti
di malfunzionamento. Quindi la gestione dei sistemi distribuiti è molto più complessa, ma anche più
necessaria, della gestione di un sistema informatico che non utilizza sistemi di comunicazioni ed è
quindi costituito da componenti che eseguono tutti su un unico sistema di calcolo.
GSR espone la tematica della gestione partendo dal punto di vista del sistema di comunicazione.
Internet ha sviluppato una architettura di gestione (basata su opportuni standard detti, nella
terminologia di Internet, RFC o Request For Comments) che si applica sia agli apparati di rete che
alle macchine ed alle applicazioni. Questa architettura è nota con il termine SNMP: Simple Network
Management Protocol, che letteralmente è il nome del protocollo applicativo usato in questa
architettura; un esempio della figura retorica sineddoche, che consiste nell'usare la parte per indicare
il tutto.
Internet non è stata la prima ad affrontare il problema della gestione. Ovviamente esistono
standard e architetture proprietarie sviluppate dai costruttori che sono interessati a vendere ai clienti
il sistema gestione assieme al sistema informatico da gestire. Le architetture proprietarie sono
sostanzialmente simili a quelli di Internet: conoscere SNMP permette rapidamente di impadronirsi
degli strumenti e delle metodologie di architetture proprietarie. Ma esiste anche una seconda
architettura di gestione aperta e vendor independent, come SNMP, che è stata definita dall'ISO
(International Standard Organisation) nell'ambito della serie di protocolli chiamata OSI (Open
System Interconnect) e viene spesso indicata con il termine OSIMIS (OSI Management Information
System). OSIMIS è stata definita a partire dalle esigenze delle grandi reti di telecomunicazioni,
ancora in uso nelle reti pubbliche geografiche basate su tecnologia SDH (Synchronous Data
Hierarchy), ATM (Asynchronous Transfer Mode) e altre. OSIMIS è molto più complesso di SNMP,
ma SNMP deve molte sue idee a OSI Management e quindi costituisce una buona introduzione a
OSIMIS, che vi tornerà utile se doveste lavorare con OSIMIS.
Perché servono degli standard per gestire i sistemi informatici? Perché se tutti i componenti del
sistema informatico implementano la stessa architettura di gestione, anche se sono realizzati da
diversi produttori, quindi aderiscono ad uno standard aperto e indipendente dal fornitore il cliente
può gestire diversi componenti con la stessa infrastruttura di gestione (vedremo che cosa è) ed è
libero di acquistare i componenti del suo sistema da fornitori diversi, scegliendo l'offerta di volta in
volta più conveniente. Le architetture proprietarie invece vincolano il cliente ad acquistare sempre e
solo componenti dallo stesso fornitore perché gli altri fornitori sono messi in condizione di non avere
le informazioni necessarie per gestire i propri componenti con l'architettura di gestione di un altro
fornitore. Nel caso di sistemi distribuiti il numero e il tipo dei componenti del sistema è molto alto e
quindi l'effetto "prigione" di una architettura proprietaria è ancora maggiore.
Storia di SNMP
SNMP (Simple Network Management Protocol, detto anche SNMPv1) fu definito inizialmente
negli ultimi anni '80, avendo in mente, come dice il nome, uno standard estremamente semplice ed
economico da implementare. L'aspetto economicità e semplicità è particolarmente rilevante per i
sistemi di gestione, perché gli strumenti di gestione sono facilmente considerati un un "sovrappeso",
che si vorrebbe evitare di pagare (almeno, fino al primo grave malfunzionamento del sistema
gestito!).
RMON (Remote Network Monitoring), costruito su SNMP, fu rilasciato nel 1991 e rivisto
(RMON2) nel 1995. RMON permette, come dice il nome, di monitorare (cioè tenere sotto controllo)
da remoto intere reti LAN, piuttosto che ciascuno dei componenti di rete; definisce quindi algoritmi e
database per gestione di LAN.
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

2 di 17

La semplicità di SNMP ne favorì un grande successo commerciale, sia tra i costruttori che
soprattutto fra gli utilizzatori, che ne apprezzarono l'aspetto "aperto" e "multivendor". Ma assieme al
successo commerciale risultarono ben presto evidenti le troppe limitazioni dell'impostazione di
SNMPv1.
Fu quindi preparata una seconda versione dello standard chiamata SNMPv2, che fu standardizzata
nel 1993 e rivisto nel 1995. Questa seconda versione è caratterizzata da
●

Maggiore efficienza nell'uso della infrastruttura di rete

●

Maggiori funzionalità rispetto a SNMPv1

Ma anche SNMPv2 soffre di pesanti limitazioni funzionali e ciò portò alla definizione di SNMPv3
che fu standardizzato nel 1998, e che costituisce un progresso estremamente significativi rispetto a
SNMPv2:
●

Fornisce un quadro complessivo per le presenti e future versioni di SNMP

●

Aggiunge funzionalità di sicurezza a SNMP

Inevitabilmente SNMPv3 risulta molto più complesso e costoso di SNMPv1 e di SNMPv2 e
quindi ha avuto un successo commerciale molto inferiore.
Cercheremo di realizzare esercitazioni, che faranno uso di un sistema di gestione installato nel
Laboratorio e di uso molto comune nelle aziende: HP Open View. Le esercitazioni non saranno
fiscalizzate (anche questo anno): non devono essere "superate" per poter fare l’esame. L'esperienza
con il corso di GSR per la laurea triennale ha mostrato che frequentare assiduamente le esercitazioni
e comprendere bene tutto quello che vi viene presentato nelle esercitazione è molto utile per passare
l'esame senza fare una fatica eccessiva. Se avremo tempo e "risorse umane" offriremo le esercitazioni
anche quest'anno.
●

Lo scopo delle esercitazioni è

●

Fornire strumenti di comprensione

●

Fornire strumenti di validazione dello studio fatto e della comprensione raggiunta

Alla fine del Corso vorremmo che lo Studente fosse capace di
●

Configurare un semplice agente di gestione

●

Analizzare, progettare e realizzare piattaforme di gestione utilizzanti SNMP

●

Compiere una valutazione dello stato di un sistema distribuito basandosi sugli elementi
raccolti dal sistema di gestione.

La maturità e la profondità con cui questi obiettivi sono raggiungibili da uno studente della laurea
magistrale è ovviamente molto maggiore di quella raggiungibile da uno studente della laurea
triennale.
Ma quali sono, con maggior precisione, le funzionalità che deve offrire un sistema di gestione? È
importante definirle perché uno standard di gestione deve essere funzionale a raggiungere questi
obiettivi.

1.2. Requisiti di un Sistema di Gestione
I requisiti di un sistema di gestione sono stati definiti con chiarezza dall'ISO in ambito OSI,
definendo le seguenti aree funzionali che un Sistema di Gestione dovrebbe rendere disponibili:
●

Fault Management

●

Accounting Management

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

3 di 17

●

Configuration Management

●

Performance Management

●

Security Management

Queste aree di intervento sono state riconosciute generalmente valide in quanto "discendono" dai
requisiti degli utenti (amministratori) riguardo ad un sistema di gestione; alcune di queste aree
devono essere supportata da un protocollo applicativo di gestione (quale SNMP), altre da
applicazioni di gestione che vengono sviluppate al di sopra del (utilizzando il) protocollo di gestione.
Quindi il protocollo di gestione deve permettere di costruire applicazioni di gestione, ma non deve
necessariamente realizzare completamente queste funzioni al suo interno.
Notate che anche se il protocollo di gestione è una applicazione in termini di architettura Internet,
non risolve necessariamente tutti i problemi di gestione: deve invece costituire una base su cui
costruire applicazioni di gestione che rispondano alle esigenze degli amministratori del sistema.
Internet ha ripreso queste aree funzionali, ma la sua architettura di gestione non risponde in modo
ugualmente soddisfacente a tutte.
Analizziamo le aree funzionali perché ci permettono di capire i requisiti di utente che un Sistema
di Gestione dovrebbe soddisfare. Riprendiamo il tema della chiara definizione di utente del sistema di
gestione. La prima risposta è che l’Utente è il Gestore del Sistema, che chiameremo genericamente
"amministratore", anche se in molte realtà aziendali l'amministratore ricopre un rango più elevato,
rispetto ai generici "sistemisti". Ma il Gestore del Sistema in realtà risponde alle richieste e alle
proteste degli utilizzatori del Sistema che viene gestito, almeno se è un buon gestore e se l'azienda per
cui lavora ha davvero come obiettivo la soddisfazione dei Clienti!

1.2.1. Fault Management
I guasti vanno ovviamente gestiti: cosa vuol dire? Quando si ha un guasto, occorre nel più breve
tempo possibile:
●

Determinare esattamente dove si è verificato

●

Isolare il resto della rete/sistema dal guasto in modo che possa continuare a funzionare

●

Riconfigurare la rete/sistema in modo da minimizzare l’impatto del componente guasto (è il
cosiddetto workaround)

●

Riparare o rimpiazzare il componente e riportare la rete/sistema al suo stato iniziale normale

Gli utenti finali si aspettano una soluzione immediata o comunque veloce, e si aspettano che le
prestazioni e le funzionalità del sistema gestito siano il più possibili all'altezza del sistema senza il
guasto. Quindi quello che occorre minimizzare è il tempo di mancanza di servizio, o di servizio
ridotto, che costituisce il fattore determinante della Qualità del Servizio (Quality of Service, QOS).
Naturalmente, questa è la misura di una variabile "stocastica", non si presenta in ogni caso con lo
stesso valore; occorre quindi minimizzare in primo luogo la media annuale del tempo di mancanza di
servizio o di servizio ridotto, e in secondo luogo minimizzare la varianza nell'annodi questa misura o
il tempo massimo nell'anno di mancanza di servizio.
La individuazione e la diagnosi del guasto devono essere il più veloci possibile, perché concorrono
a formare il tempo di mancanza di servizio. Un buon Sistema di Gestione minimizza questi tempi,
automatizzando il più possibile queste attività.
È importante capire fino dall'inizio che gli utenti finali possono solo segnalare che qualcosa non
funziona perché il sistema non fornisce il servizio atteso; una segnalazione da parte degli utenti finali
del sistema informatico è già un fallimento del sistema informatico. Le statistiche sul comportamento
degli utenti indicano che solo una piccola percentuale degli utenti segnala il malfunzionamento ai
fornitori del servizio: la maggior parte degli utenti semplicemente prende provvedimenti senza

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

4 di 17

protestare, ma questi "provvedimenti" non sono mai in favore del fornitore del servizio! Quindi
basarsi sugli utenti finali per la segnalazione dei guasti è la peggior pratica che si possa adottare.
Un Sistema di Gestione invece può e deve tenere sotto controllo tutti i componenti del sistema e
accorgersi da solo del loro malfunzionamento, prima che (e senza che) gli utenti finali segnalino il
problema. Per questo una gestione proattiva è molto migliore di una gestione reattiva. Ovviamente, la
riparazione del guasto deve essere effettuata dal personale di gestione, che però se non viene
avvertito non può intervenire. Quindi tutti i meccanismi di segnalazione dei problemi al personale di
gestione, ad es. tramite messaggi SMS, sono parte integrante del Fault Management.
Eseguire Fault Management richiede inevitabilmente interagire con il sistema gestito per
raccogliere dati sul suo funzionamento per verificare il suo corretto funzionamento. Questa
interazione con il sistema gestito non deve abbassare significativamente la prestazione del sistema.

1.2.2. Accounting Management
Per accounting si intende in generale contabilizzazione dei costi o dell’uso delle risorse del
sistema. Anche se il sistema gestito non fornisce servizio a Clienti esterni all’Azienda (come invece
succede nelle aziende che vendono il servizio) l’uso delle risorse del sistema deve (spesso) essere
contabilizzato ed addebitato agli utilizzatori, perché
●

Un utente o un gruppo di utenti può abusare delle risorse messe a disposizione e condivise

●

Gli utenti possono fare un uso inefficiente delle risorse del sistema

Sempre più spesso l'uso delle risorse del sistema viene addebitato agli utenti interni del sistema
gestito perché questa pratica permette di capire come e dove vengono usate le risorse. Se il gestore
del sistema conosce il livello e il modo di utilizzo delle risorse è in migliori condizioni per pianificare
la crescita del sistema, che è l'attività indispensabile per una gestione proattiva del sistema.
Il gestore del sistema deve essere in grado
●

Di definire il tipo di informazioni di accounting che il sistema di gestione deve raccogliere nei
vari punti del sistema

●

L’intervallo di tempo per la raccolta delle informazioni, e l’invio ai livelli più alti di gestione
dell’informazione

●

Gli algoritmi usati per calcolare la contabilizzazione

●

La frequenza e il formato dei report di accounting

Solo una parte molto limitata di queste funzionalità può essere fornita direttamente dal protocollo
applicativo di gestione: questo è una delle aree in cui è necessaria la maggiore "customizzazione", o
personalizzazione, della gestione di una sistema informatico, anche perché i dati raccolti devono
essere forniti al sistema di contabilizzazione usato all'interno dell'azienda, che è ben lungi da essere
"standard".

1.2.3. Configuration and Name Management
I sistemi moderni sono composti di componenti e sottosistemi logici che possono/devono essere
configurati per effettuare una grande varietà di funzioni in una grandissima varietà di modi. Una volta
deciso il modo di utilizzo del componente, il Sistema di Gestione deve aiutare il gestore a scegliere il
software appropriato e il set dei valori delle variabili di configurazione che sono appropriati per il
software usato e per le funzioni desiderate.
L'area del Configuration Management riguarda anche l’inizializzazione e lo shutdown di una rete,
o di un sistema, o di un suo componente. Spesso è richiesto che operazioni sui componenti siano
compiute automaticamente, ad es. shutdown o startup di una scheda di interfaccia di rete.
Configuration Management deve permettere una facile riconfigurazione della rete, o la
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

5 di 17

configurazione della rete secondo modelli predefiniti e archiviati. Infatti, spesso è necessario tenere
in archivio diverse configurazioni della rete o dei componenti e poter facilmente passare da una
configurazione ad un'altra per rispondere a necessità che si verificano con una certa regolarità.
Un esempio di configurazione? Assegnare l’indirizzo IP ad una interfaccia, impostare il nome di
dominio di una macchina, ecc.

1.2.4. Performance Management
La gestione delle prestazioni è un’area estremamente importante oggi, in quanto l’efficacia delle
applicazioni spesso si basa sulle prestazioni di componenti del sistema che hanno un ruolo critico nel
determinare le prestazioni complessive. Questa area può essere scomposta in monitoring e control.
Nella gestione delle prestazioni, occorre essere in grado di rispondere a domande quali:
●

Quale è il livello di utilizzo della capacità del componente?

●

C’è traffico/carico eccessivo?

●

A che livello è il throughput del componente? È ridotto a livelli eccessivi?

●

Ci sono colli di bottiglia nel sistema?

●

A che livello è il tempo di risposta del sistema o di un suo componente?

L’analisi delle prestazioni, e soprattutto la previsione dell’andamento delle stesse, è impossibile se
non si dispone di un modello del sistema, anche se semplificato. La previsione si basa inevitabilmente
sulla raccolta di statistiche sui dati di prestazione del sistema e dei suoi componenti, che devono
essere raccolte con regolarità, e archiviate in un opportuno database.

1.2.5. Security Management
Riguarda la gestione di meccanismi di protezione e di controllo degli accessi, quali la generazione,
distribuzione e memorizzazione di
●

Chiavi di cifratura

●

Password

●

Informazione di controllo degli accessi

La gestione della sicurezza richiede in primo luogo di monitorare e controllare l’accesso alle reti e
ai sistemi. È quindi essenziale tenere sotto controllo ed analizzare i log di accesso e dei tentativi di
violazione della sicurezza. Un tentativo fallito di accesso al sistema gestito può essere solo causato
dalla digitazione errata delle credenziali di accesso, ma una serie ripetuta e frequenta di tentativi di
accesso falliti è sicuramente segno di un tentativo di accesso fraudolento. È essenziale essere in grado
di rilevare i tentativi di accesso fraudolento per mettere in atto misure di protezioni specifiche contro
l'attaccante.

1.3. L'architettura di un sistema di gestione
L'architettura di un sistema di gestione è descritta (da Stallings) nella prossima figura. La figura è
complessa perché dobbiamo/vogliamo raffigurare non solo i componenti di gestione ma anche quelli
gestiti; inoltre, si ha come sempre la necessità di rappresentare sia gli aspetti "hardware" del sistema
(quante e quali macchine ci sono) ma anche i componenti software che eseguono sulle varie
macchine. Stallings usa il termine Network Management System (NMS) per indicare l'intero sistema
che effettua la gestione, e ovviamente il NMS è costituito da due componenti:
●

Una applicazione, con una interfaccia grafica potente, che permette di eseguire tutti i tipi di
compiti di gestione del sistema che sono necessari e che viene chiamata Network
Management Application (NMA)

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

6 di 17

●

Un insieme di entità che gestiscono i dispositivi, che sono quasi sempre incorporate nei
dispositivi stessi; e che sono chiamate Network Management Entity (NME).

Al di là dei termini, si riconoscono i due tipi di componenti che abbiamo introdotto nel paragrafo
precedente, e cioè Manager e Agent. Ricordiamo che NMA e NME sono "applicazioni" per quanto
riguardo il protocollo di trasporto. La NMA è talmente complessa che sicuramente esegue come una
applicazione del sistema operativo ospite. La NME può in certi casi essere parte del sistema operativo
se deve interagire molto "a basso livello" con le risorse che deve gestire.

La figura permette di fare un certo numero di considerazioni interessanti. Ve diamo che nel
sistema c'è una workstation che è un oggetto gestito, evidentemente perché il suo corretto
funzionamento è considerato importante. Ma la macchina su cui esegue la NMA stessa non è degna
di essere gestita anche lei? Non è di notevole importanza? Se tale macchina non funziona il sistema
di gestione non funziona; quindi anche la macchina che Stallings chiama Network Control Host
(NCH) e che ospita una NMA deve essere gestita. Ma per essere gestita deve avere un componente
NME che permette alla NMA di gestire la stessa macchina su cui esegue. Naturalmente la gestione
avverrà tramite protocollo applicativo, che non ha problemi a funzionare trasparentemente fra
applicazioni che eseguono sulla stessa macchina
Questa figura evidenzia elementi che la figura di Mauro non evidenzia (attenzione alle didascalie
nella figura!), ma non evidenzia il ruolo server/client dei componenti, internet-wise, cioè secondo la
architettura internet di applicazioni distribuite.
• Si noti che in un server, l’applicazione sotto gestione è un importante oggetto da gestire: la NME
(Agent) deve permettere di gestire la applicazione, non solo l’hardware o il SO della macchina.
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

7 di 17

Un NMS aggiunge qualcosa al sistema da gestire; almeno una NMA (Manager), e le NME
(Agent). Spesso le NME sono già contenute nei dispositivi da gestire e al massimo si devono
"configurare". Quindi la gestione di un sistema "costa" qualcosa e introduce componenti
addizionali a quelli del sistema gestito.
Un NMS deve permettere di avere una vista completa di tutto il sistema sottoposto a gestione, in
una architettura unificante, nella quale ogni componente del sistema (applicazione, workstation,
server, router, switch, bridge, link, etc.) è mostrato, etichettato, indicato con il suo indirizzo, etc.

1.3.1. Attività della NME e della NMA
I componenti del sistema di gestione hanno diversi compiti. Finora abbiamo parlato assai più dei
compiti della NMA, ma le NME sono essenziali perché la NMA offra i servizi desiderati agli
amministratori del sistema gestito. Ogni NME (Agent) svolge i seguenti compiti
●

Raccoglie e mantiene informazioni sulle attività del dispositivo (applicazione, host, elemento
di rete,...) che gestisce;

●

Immagazzina queste informazioni localmente, in genere con certi limiti sulla quantità di
informazioni che mantiene;

●

Risponde a comandi da parte della NMA, che gli chiedono di:

●

○

Trasmettere le informazione raccolte;

○

Modificare un parametro della configurazione del dispositivo;

○

Fornire informazioni di stato, ad es. valori di configurazione del dispositivo o stato di suoi
componenti;

○

Generare traffico artificiale per fare dei test;

Invia in modo autonomo alla NMA messaggi di avviso (trap) quando è necessario

La logica applicativa della gestione è implementata nella NMA, che quindi diventa un componente
estremamente critico del sistema gestione, per cui non ci può essere un solo host su cui esegue la
NMA (Manager), perché se tale host ha un guasto il sistema è fuori controllo
Il Network Management Center (NMC) consiste quindi di almeno due Network Control Host
(NCH). NMA e NME comunicano usando un protocollo di gestione. Dato che NMA e NME si
basano sul sistema operativo della macchina ospite e sul software di comunicazione, i venditori di
sistemi operativi spesso offrono NMS che sono proprietari, cioè progettati per essere usati solo sul
software del venditore. Recentemente sono emersi sistemi di gestione standardizzati per poter essere
usati su apparecchiature di venditori diversi

1.3.2. Architettura di una NMA
Come ci si può aspettare la NMA in se stessa ha una architettura complessa. I componenti possono
essere classificati nei seguenti tipi:
●

Software per la presentazione dei dati all’utente

●

Network management software

●

Software di comunicazione e di data base

Una NMA è tipicamente usata in modo interattivo dagli amministratori del sistema e quindi deve
avere del software per l'interazione con gli amministratori. Questi aspetti grafici possono anche essere
molto sofisticati per esempio per mostrare grafici dell'andamento nel tempo di variabili importanti
quali il tempo di risposta del sistema, l'occupazione delle risorse, ecc. La gestione di un sistema
richiede l'esecuzione di elaborazioni specifiche come pure la esecuzione di attività programmate dagli
amministratori; quindi una buona NMA deve fornire un ampio corredo di software specifico per la
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

8 di 17

gestione di sistemi. Infine, i dati relativi ai dispositivi gestiti devono essere reperiti tramite le NME
(usando uno stack di comunicazione) ma anche salvati in un database per archiviazione storica a per
poter pianificare la crescita di potenza del sistema gestito (capacity planning). La prossima figura
tenta di illustrare la architettura interna di una NMA.

La figura ci permette di notare alcuni aspetti importanti di una applicazione di gestione.

1.3.3. Sistema unificato di interazione con l'utente
Una NMA è costituita da numerosi componenti (come vedremo), molti dei quali devono interagire
con l'utilizzatore della NMA; è importante che lo stile di interazione con l'utente sia uniforme sia
nella grafica che nella impostazione dei dialoghi e dei menu tramite i quali si accede alle funzioni dei
singoli componenti. Per questa ragione la figura rappresenta la NMA come racchiusa all'interno di
una Unified user interface che costituisce il "canale di comunicazione" fra utente e NMA.

1.3.4. Presentazione della informazione di gestione
Anche questo è un componente che conviene unificare perché componenti diversi producono gli
stessi tipi di informazione di gestione da mostrare all'utente. Le elaborazioni necessarie per

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

9 di 17

"costruire" i dati da mostrare all'utente devono essere unificate, sia per risparmiare sviluppo di codice
sia per dare uniformità alla interfaccia utente, che deve presentare sempre nello stesso modo dati
della stessa natura.
In questo strato di Presentation of network management information vengono anche implementate
le modalità di dialogo con l'utente che devono essere condotte in modo unificato e coerente. La
uniformità della interfaccia utente nei vari componenti del sistema ha come ulteriori benefici effetto
la riduzione della necessità di formazione del personale e la riduzione degli errori operativi.
La presentazione delle informazioni digestione presenta una addizionale difficoltà nel progetto
della modalità di interazione con l'utente. Poiché le informazioni di gestione sono estremamente
numerose e di grandi dimensioni, vi è il pericolo che il gestore sia inondato di informazione, e perda
di vista le cose importanti nella sua situazione. Occorre quindi fornire strumenti per organizzare,
riassumere e semplificare questa enorme quantità di informazione, con elevate possibilità di
personalizzazione.

1.3.5. Network Management Software
Il software di gestione vero e proprio può avere complessità molto variabile da NMS a NMS, ma
sempre più comunemente è molto complesso perché deve rispondere a requisiti molti diversi e
sofisticati. Nella figura è rappresentato il caso di un software di gestione complesso e ricco di
funzionalità.
1.3.5.1. Applicazioni di gestione
Nel riquadro più interno della figura vengono evidenziate un certo numero di Network
Management Application che sono i componenti che realizzano la logica applicativa della NMA. Le
NMA sono ambienti applicativi estremamente complessi, che vengono sviluppati nell'arco di lunghi
periodi, aggiungendo moduli o programmi che svolgono funzioni specifiche, che devono essere
richiamabili dall'utente in modo unificato.
L'automazione di compiti di gestione tramite applicazioni specifiche sviluppate dagli
amministratori del sistema dovrebbe essere disponibile agli amministratori alla stessa stregua di
applicazioni native della NMA.
1.3.5.2. Application Element
Le applicazioni che forniscono servizi direttamente fruibili dagli amministratori fanno uso di
componenti, chiamati Application Element, il cui ri-uso favorisce la riduzione di costo e la
robustezza (mancanza di errori) dell'intera NMA.
Gli application element costituiscono anche uno strumento di astrazione rispetto ai servizi di più
basso livello su cui è costruito l'ambiente della NMA.
1.3.5.3. Servizio di trasporto di dati di management
Lo strato sottostante viene indicato con questo termine perché questo è in fondo il suo compito:
mettere la NMA in comunicazione con le informazioni di gestione che le sono necessarie. Queste
informazioni possono provenire da varie fonti e per questo è necessario un livello di astrazione. A
questo livello possono anche essere realizzate modalità di accesso ai dati che non sono offerte dai
servizi sottostanti ma che possono essere implementate mediante le funzioni da essi offerti: ad es.
operazioni di aggregazione di dati.
Quali possono essere le fonti di informazioni di gestione?
1.3.5.4. Stack di protocolli di comunicazione
Il sistema gestito è ovviamente la forma primaria e più immediata di informazioni di gestione. Gli
NME mantengono, almeno in parte, la informazione di gestione relativa ai dispositivi che gestiscono
02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

10 di 17

e quindi la NMA deve certamente poter interagire con il sistema gestito mediante un opportuno stack
di protocolli di comunicazione.
Molto spesso una NMA deve essere sviluppata in modo da poter essere usata con diverse
architetture di gestione, proprietarie o standard, e quindi con diversi stack di protocolli di
comunicazione; inoltre, deve spesso essere disponibile su diversi sistemi operativi e diverse
architetture hardware. Per questa ragione lo stack di protocolli di comunicazione non può essere
interfacciato direttamente agli strati superiori della NMA ed è necessario uno strato di astrazione e di
unificazione dei vari servizi offerti nei vari ambienti in cui la NMA dovrà eseguire, che verrà poi
linkato alle librerie corrette.
1.3.5.5. Modulo di accesso alla MIB (Management Information Base)
La figura evidenzia che questo modulo permette l'accesso ad un database che contiene
informazione di gestione: la Management Information Base. Questo è tipicamente ospitato da un data
base relazionale commerciale oppure open source, a seconda della politica commerciale del fornitore
della NMA.
Le applicazioni di gestione devono operare su dati che descrivono i dispositivi in un certo istante,
ma devono anche archiviare i dati raccolti storicizzandoli, perché interessa il loro andamento nel
tempo. Sui dati storici possono essere effettuate statistiche e analisi di tendenza.
I dati istantanei che riguardano i dispositivi di gestione si ottengono usando lo stack di
comunicazione e contattando le NME, ma la base storica dei dati rilevanti deve essere costruita dalla
NMA contattando periodicamente le NME e memorizzando i dati ottenuti in un data base.
Il modulo ben separato di accesso a database è necessario perché la NMA deve poter essere
venduta pronta per usare database diversi di costruttori diversi, perché una azienda tipicamente ha già
scelto un data base e non vuole acquistare un diverso data base solo per poter fare la gestione del
sistema informatico. I diversi produttori di data base spesso introducono piccole differenze nelle
interfacce di accesso al loro data base per guadagnare vantaggi competitivi rispetto ai concorrenti.
Anche i driver di database "standard" come ODBC presentano spesso sottili differenze da un
database ad un altro.
L'architettura di una NMA mette quindi in rilievo l'importanza di questa base di dati di
informazioni di gestione. Le applicazioni devono poter lavorare con facilità e in modo trasparente sia
sui dati storici che sui dati raccolti in un dato istante dai dispositivi. Per questa ragione il servizio di
trasporto dei dati di management si appoggia da un lato sul DB, e dall’altro sullo stack di
comunicazione: per nascondere agli strati superiori il modo con cui i dati sono ottenuti. I dati
istantanei sono ottenuti contattando l'Agent sul dispositivo, mentre i dati riferiti ad un istante nel
passato sono ottenuti dallo storico sul database. Gli Agent sui dispositivi quindi realizzano al loro
interno la parte istantanea (corrente) della MIB, che il Manager può prelevare mediante il servizio di
trasporto dei dati di management.

1.4. La Management Information Base (MIB)
Come si può apprezzare, il termine MIB viene quindi usato in modo ambiguo per riferirsi a volte
ai dati di gestione memorizzati sul database, e altre volte per riferirsi ai dati di gestione che
concettualmente sono immagazzinati all'interno degli Agent (delle NME), e si dice che "la MIB è
dentro agli Agent". Il protocollo di management offre operazioni di raccolta dei dati della MIB
mantenuta nel dispositivo (come illustrato nella parte bassa della figura precedente).
Dentro alla MIB, i dati devono obbedire ad un particolare schema dei dati, come in tutti i data
base. Lo schema dei dati all'interno del database può essere liberamente definito dai progettisti della
NMA, al fine di ottenere le migliori funzionalità e prestazioni. Invece i dati all'interno degli Agent è
bene che siano standardizzati, in modo che dispositivi della stessa natura siano gestibili nello stesso

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

11 di 17

modo usando lo stesso codice e la stessa logica. Se due dispositivi della stessa natura, ad es. due host,
sono descritti da dati di gestione che hanno uno schema diverso, la NMA deve sviluppare due moduli
diversi per gestire questi due dispositivi anche se sono in realtà "la stessa cosa". Questo è un
problema tipico per ogni applicazione che usa un database: lo schema dei dati deve essere
"conosciuto" dall'applicazione perché essa funzioni come l'hanno progettata gli sviluppatori.
Può non essere sempre facile decidere se due dispositivi sono della stessa natura, ma nella
maggior parte dei casi è facile capire che sono diversi: non ci sono dubbi che un acquario di pesci
(supponendo che volessimo gestirlo perché il suo corretto funzionamento è essenziale per mantenere
alto il morale dei lavoratori e quindi avere successo sul mercato) non può essere gestito usando le
stese informazioni che invece permettono di gestire un router, che necessita a sua volta di
informazioni diverse da quelle necessarie per gestire un database management system. Questa
dipendenza della NMA dallo schema dei dati di gestione spiega anche la proliferazione delle
applicazioni di gestione: quando ho necessità di implementare logiche di gestione sofisticate, è
inevitabile che si debba scrivere codice che è specifico per i dati che specificamente descrivono il
dispositivo. Per mettere in un grafico l'andamento di una misura posso anche non sapere che cosa
significa la misura (ad es., la temperatura dell'acqua dell'acquario, il numero di pacchetti al secondo
in ingresso ad una interfaccia, il numero di transazioni al secondo eseguite dal DBMS) ma se voglio
che la mia NMA esegua azioni e controlli più sofisticati ci sarà il momento in cui la gestione di un
acquario diverge da quella di un router.
Quindi è importante è definire lo schema dei dati istantanei resi disponibili dalle NME (Agent) in
modo che dispositivi della stessa natura, anche se prodotti da costruttori diversi offrano gli stessi dati
con lo stesso significato: cioè offrano lo stesso modello. Invece i costruttori hanno interessi diversi,
soprattutto quando offrono dispositivi complessi che richiedono una opportuna gestione: in questo
caso sono interessati a sviluppare essi stessi un buon sistema di gestione che aumenti il valore dei
loro dispositivi e che però non possa essere usato per gestire dispositivi simili dei concorrenti, che ne
trarrebbero vantaggio senza avere fatto gli investimenti. Inoltre, se la gestione dei componenti del
sistema informatico è proprietaria, il Cliente avrà difficoltà a cambiare fornitore e passare ad un
fornitore concorrente. Quindi i costruttori sono interessati a sviluppare architetture di gestione
proprietarie, anche nel modello dei dati di gestione. L'interesse degli utenti è invece quello che ci
siano buoni standard di gestione aperti e vendor-independent, e che i costruttori adottino questi
standard aperti per i loro dispositivi. Per questa ragione Internet ha sviluppato la "sua" architettura di
gestione aperta, e questa architettura include la definizione dei modelli, cioè del loro schema dei dati,
dei dispositivi più diffusi (non a caso non ha ancora sviluppato lo schema dei dati di gestione degli
acquari per pesci).
Come per tutti gli schemi di DB, deve essere usato un formalismo opportuno per definire lo
schema dei dati; nei database questo formalismo si indica spesso con il termine Data Definition
Language. Se vogliamo definire degli schemi di dati di gestione standard per dispositivi di diversa
natura, occorre che anche il formalismo per esprimere questi schemi e la modalità con cui verranno
definiti siano standardizzati. Il linguaggio e le modalità da adottare per esprimere lo schema delle
MIB dei dispositivi è definito in Internet da uno standard (RFC) chiamato Structure of Management
Information (SMI).
Il protocollo di management offre operazioni di raccolta dei dati della MIB mantenuta nel
dispositivo (vedere la figura precedente). Si può pensare di realizzare un NMS che sia capace di
gestire dispositivi di costruttori diversi solo se le MIB di dispositivi dello stesso tipo sono uguali; e
non potranno essere uguali se la SMI usata per definire la MIB è già essa stessa diversa.

1.5. Gestione "Distribuita"
La concezione del sistema di gestione come basato su un unico NMS centralizzato non è
soddisfacente. Infatti i gestori del sistema devono poter lavorare in sedi diverse, o su LAN diverse

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

12 di 17

della stessa sede, e comunque su macchine diverse. Non è accettabile che gli amministratori debbano
recarsi nella sala macchine dove è situato il server che ospita il NMS e d'altra parte i Management
Server devono essere replicati per ragioni di affidabilità e di continuità del servizio.
Gli amministratori accedono alle applicazioni che costituiscono il NMS tramite terminale remoto
grafico. Le applicazioni di gestione accedono agli Agent sui dispositivi direttamente via protocollo di
gestione, o tramite Element Manager che fanno da mediatori rispetto ai dispositivi. Lo scenario è
quindi assai complesso, come illustrato nella prossima figura.

Gli Element Manager sono componenti che possono essere necessarie per varie ragioni. Una
ragione è che i dispositivi da gestire sia gestiti tramite una architettura di gestione proprietaria diversa
da SNMP; in tal caso gli Element Manager funzionano da gateway applicativi o proxy. Ma gli
Element Manager possono essere necessari quando i dispositivi non possono ospitare una architettura
Internet di gestione a causa della limitazione delle risorse di calcolo: in tal caso gli Element Manager
sono degli Agent che interagiscono con le risorse da gestire mediante interfacce ad hoc, che possono
richiedere o meno dei protocolli di comunicazione.
Abbiamo quindi uno schema di interazione come illustrato nella prossima figura:

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

13 di 17

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

14 di 17

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

15 di 17

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

16 di 17

L'NMA contatta il proxy agent (o proxy manager, nel gergo di Stallings), che traduce la richiesta
del manager in una forma appropriata per il componente di interesse. Le risposte provenienti dal
sistema interessato vengono a loro volta tradotte nello standard di gestione del manager e inviate al
manager. Viene spesso adottato uno schema a RPC (Remote Procedure Call) per la realizzazione di
queste architetture sistemistiche.

02/09/2007:17:05

GSR2006-07-Capitolo-1-Appunti

17 di 17