1. Un po' di storia: Il sistema Osi nasce per un’esigenza delle grandi compagnie di telecomunicazioni nazionali



Scaricare 25.96 Kb.
28.03.2019
Dimensione del file25.96 Kb.

SGR-D

Luca Deri, mailto:deri@ntop.org

Web : http://luca.ntop.org/

Mailing List: mailto:sgr@ntop.org

1° Settimana:

Introduzione


1. Un po' di storia:
Il sistema Osi nasce per un’esigenza delle grandi compagnie di telecomunicazioni nazionali. Queste dovevano gestire i loro apparati di rete, usati prevalentemente per il traffico voce, e, per questo, necessitavano di uno standard, per poter dare uno stesso servizio a tutto uno stato(-> uniformità di protocollo). In USA, invece, la politica della standardizzazione non è stata perseguita, almeno non all’inizio, per cui le varie aziende che fornivano servizi di telecomunicazione potevano usare tecnologie e metodi anche totalmente diversi.

Come la telefonia negli USA, anche Internet si è sviluppato in maniera libera( spesso, infatti, si facevano i programmi e poi si producevano i documenti che li formalizzavano), poiché era necessario trasferire dei dati e bastava che una cosa funzionasse, non che fosse ben teorizzata.

TMN nasce sfruttando standard già esistenti( prevalentemente Osi), per gestire traffici dati e voce.

ISM si forma per gestire reti eterogenee, in maniera integrata, specialmente quelle distribuite, anche in diverse parti del territorio.

DIM

CD integra standard e cose di moda come CORBA


2. Perché nasce l’esigenza di gestire le reti:


  1. Il traffico sulle reti non è prevedibile;

  1. Sulle reti passano molti protocolli differenti;

  1. Spesso è necessario conoscere la locazione di certe informazioni che viaggiano sulla rete, se qualcuno vi ha avuto accesso senza autorizzazione, il loro stato;

  1. Spesso i sistemi informatici sono distribuiti su un territorio più o meno grande, quindi per far funzionare tutto deve funzionare perfettamente la rete che collega le loro parti;

  1. Gli strumenti che compongono o che fanno funzionare le reti sono, col passare del tempo, sono sempre più complessi ed è sempre più difficile individuare dove e quando si è verificato un problema, e soprattutto quale problema e a quale componente;

  1. Gli utenti vogliono un servizio costante, che prescinda dallo stato dei componenti della rete

  1. Le aziende non vogliono spendere troppi soldi per rinnovare i loro strumenti informatici, quindi si deve essere in grado di adattare la rete ai loro strumenti, e non il contrario.

3. Un inconveniente:


Per amministrare le reti servono dei tools, sia hardware (es: i probe) che software (es: nslookup), ma spesso chi compra gli strumenti non è chi amministra la rete, quindi può capitare di doversi adattare ad usare strumenti che non si conoscono o, che è peggio, che non si ritengono neppure idonei.

4. Livelli di gestione delle reti:


La gestione delle reti può essere vista in tre dimensioni:

  1. In base alle funzioni;

  1. In base alle dimensioni dell’oggetto;

  1. In base al tempo:

 Orizzonte a breve termine: Gestione automatizzata o manuale, ma istantanea;

 Orizzonte a medio termine: Un operatore risolve il problema nel tempo di qualche ora;

 Orizzonte a lungo termine: Funzionalità strategiche da fornire nell’arco di anni.

5. Cosa deve garantire la gestione di rete:




  1. funzionalità e miglioramento, per migliorare le prestazioni;

  1. mantenimento dei servizi, prevenzione di errori umani, reazione ad anomalie (in modo automatico o semiautomatico), ridondanza a fini di sicurezza e efficienza;

  1. cambiamenti dinamici, in base alle tecnologie nuove o alle esigenze geografiche e topografiche;

  1. rappresentazione delle informazioni rilevanti, riguardo allo stato della rete;

  1. amministrazione delle configurazioni;

  1. centralizzazione del controllo, anche in caso di sistemi distribuiti (in remoto).

6. Situazione corrente:


Gestire gli allarmi manualmente costa troppo, in termini di tempo, quindi è necessaria un'automatizzazione del rilevamento e della documentazione dell'errore insorto; le "sintomatologie" devono essere facilmente isolabili e riconoscibili; i Network Management Systems devono poter collegare degli errori, magari diversi e occorsi in diversi nodi della rete, per individuare il vero problema che li ha causati.

Il NMS deve poter correlare le statistiche per poter valutare l'efficienza della rete nel suo insieme; questa valutazione è tutt’altro che semplice poiché spesso non ci sono riferimenti metriche assolute per la funzionalità della rete, ma si deve valutare in base alle condizioni in cui la rete sta lavorando e a tanti altri fattori variabili.

Terminologia
1. Managed Object:
Il managed object è un'astrazione dell'entità da gestire, cioè un oggetto logico, una vista astratta di una risorsa, delle sue proprietà e dei suoi comportamenti (ISO 7498).

E' simile alla definizione di Oggetto, nell'Object Oriented, ma ha più caratteristiche:



  1. attributi;

  1. operazioni;

  1. comportamenti;

  1. Notifiche.

1.1 Attributi:

Stato attuale dell'entità da astrarre, almeno per quanto riguarda gli aspetti rilevamenti per il NMS. Può cambiare il loro valore, in seguito a mutamenti di stato, e anche il loro numero, con l'aumentare delle caratteristiche rilevanti dell'entità. Gli unici cambiamenti ammissibili degli attributi di un MO sono quelli derivati da operazioni di NM, gli altri sono da considerarsi anomalie.

1.2 Operazioni:

Permettono al NMS l'accesso al MO;

1.3 Comportamento:

Indica le cose che il MO deve fare durante la vita dell'entità che astrae;

1.4 Notifiche:

Sono i dati che il MO comunica al NMS in caso di cambiamento di stato dell'entità da modellare, nel caso in cui il suddetto cambiamento non sia previsto o lecito.


Alcune parti del MO sono visibili all'utente, nella fattispecie l'amministratore di rete, altre sono nascoste e fanno parte dell'implementazione. Le diversità con gli Oggetti rendono i MO delle astrazioni "vive", cioè che seguono l'evoluzione naturale dell'entità che astraggono, che dipendono anche da fattori esterni, relativi alla realtà, al tempo e agli stimoli in generale.
2. Patterns:
Con il termine pattern si indica una descrizione di oggetti che comunicano fra loro, fatta per risolvere un problema di disegno generale, in un contesto particolare. Un pattern, cioè, permette il riutilizzo di componenti di un progetto, in altri contesti con situazioni simili, o riconducibili ad esserlo.

  1. Adapter/Wrapper: Permette di far comunicare interfacce eterogenee;

  1. Bridge: Separa l'astrazione dall'implementazione;

  1. Façade: Fornisce un'interfaccia unificata di alto livello che prescinde dalle scelte sottostanti;

  1. Layers: Divide un problema in più sottoproblemi, su diversi piani di astrazione (es. OSI, TCP/IP);

  1. Mediator: Media la connessione di due oggetti che non hanno referenze fra loro;

  1. Proxy.

3. Management Information Base:


La MIB è l'unione di tutti i MO che astraggono una determinata entità complessa da amministrare e deve essere nota sia all'implementatore che al manager. I MO di un sistema, spesso, appartengono a più di una MIB, quindi risulta comodo dividere il sistema da amministrare in più moduli (Modularità), in base alle MIB cui appartengono i MO. Poiché moduli diversi possono essere definiti da team diversi, risulta molto importante la formalizzazione fatta fino ad ora, così che sia chiaro dove dover intervenire, in caso di management; la modularità, inoltre, permette di aggiornare, modificare ed estendere le funzionalità del sistema e le caratteristiche delle entità da gestire, senza dover fare rivoluzioni o grandi cambiamenti.

Le MIB sono definite usando un linguaggio di specifica, possono essere proprietarie e multiversione, quindi è importante, per il management, sapere tutto della MIB alla quale ci si riferisce, perché le cose possono cambiare da versione a versione, o da produttore a produttore.


Il paradigma Manager/Agent:
Nel NM è l'equivalente del Client/Server dei sistemi operativi o delle applicazioni internet.
1. Agent:
Esegue le azioni sul MO, per conto dei Manager, e implementa quest'ultimo e le MIB accedendo alle risorse reali; dopo aver ricevuto una richiesta, l'agent esegue l'operazione e invia una risposta al Manager che gliel'ha commissionata, ma anche verso terze parti, se è previsto che queste vengano informate dell'accaduto. L'Agent, inoltre, informa il NMS dei cambiamenti di stato dell'entità, almeno nel caso in cui questi siano rilevanti per quest'ultimo(attributi del MO). Infine, l'Agent protegge il MO da accessi imprevisti o non autorizzati, causati da manomissioni dall'esterno, da malfunzionamenti o operazioni non consentite, anche in base al momento storico in cui si verificano.
2. Manager:
Esercita il controllo; avvia le operazioni di management tramite un Management Protocol. Questo compito è assegnato al Manager per non appesantire l'Agent, il quale deve essere semplice e veloce e deve seguire esclusivamente operazioni atomiche, così da poter essere usato da più manager che, magari, fanno cose diverse e usano protocolli eterogenei o di altro livello.

Il manager riceve messaggi dall'Agent e, eventuelmente, li gira alle applicazioni o agli utenti; inoltre, il manager può filtrare i messaggi che riceve per individuare errori o malfunzionamenti, così da non inviare, alle applicazioni o agli amministratori, una serie lunghissime di notifiche di errore dovute a un unico problema.

Infine, i Manager possono essere inseriti all'interno di una gerarchia, e quindi non necessariamente a contatto con l'utente finale.
3. Protocollo di Management:
Un MP fa comunicare Agent e Manager eterogenei, anche disposti lontano uno dall'altro( spesso il Manager e il MO sono posti in luoghi diversi e lontani); tramite questi protocolli, così, si ha l'effetto di avere una certa portabilità degli strumenti di amministrazione, indipendentemente da quali siano i produttori delle entità da amministrare o da quali scelte di realizzazione questi rappresentino.
4. Aree Funzionali (FCAPS):
Identificano le aree funzionali di interesse per il sistema.


  1. Fault Management: Individuazione, isolamento e riparazione degli errori.

  1. Configuration Management: Produrre ed amministrare le informazioni sulla configurazione del sistema, assicurarsi che questa non cambi, nel ciclo di vita del sistema, in modo imprevisto o scorretto.

  1. Account Management: Gestire le risorse per vedere quanto queste vengono consumate e come (ad esempio per stilare statistiche o far pagare le bollette).

  1. Performance Management: Collezionare dati statistici, di perfomance, di possibili cambiamenti e delle conseguenze, in termini di efficienza, che questi possono avere.

  1. Security Management: Generare e distribuire account e password, produrre e verificare le politiche di sicurezza, fare dei tracciati dei rilevamenti inerenti la sicurezza.

Le FCAPS non sono tra loro mutuamente indipendenti e usano dei limiti di soglia (treshold) superiori e inferiori.
5. Architetture di Management:
La struttura delle informazioni di management definisce i ruoli delle descrizioni dei MO.

  1. Struttura:

  1. Identificazione e disegno dei MO;

  1. Definizione dei tipi di dati, della struttura e della sintassi che descrivono il MO;

  1. Composizione di MO;

  1. Possibili Comportamenti.




  1. Protocolli e Servizi:

L'interazione fra Manager e MO coinvolge più di un protocollo, ad esempio tra Manager e Agent si usa un protocollo diverso da quello fra Agent e MO. Le primitive dei servizi e le operazioni del protocollo influenzano l'efficienza del protocollo stesso.



  1. Modello Organizzativo: Definisce come distribuire i ruoli all'interno dell'architettura, creando dei domini di management ( Management Domains).

  1. Modello funzionale: Definisce la distribuzione dei ruoli, sempre all'interno dell'architettura, ma questa volta in base alle funzioni e no all'organizzazione.








Condividi con i tuoi amici:


©astratto.info 2019
invia messaggio

    Pagina principale