Gestione di RetiPhilippe Macaire Gestione di Reti Manager/Agent: architetture software

Gestione di Reti Philippe Macaire

Gestione di Reti

Manager/Agent:architetture software


Obiettivi

• Dettagliare l’architettura software tipica di un Agent e di un Manager

• Esempio: studio dell’architettura di OpenNMS


Agent: requisiti funzionali

• realizzazione protocollo SNMP (engine)

• definizione interfaccia di gestione (MIB)

• mapping tra MIB e risorse gestite (e.g. accesso alle risorse, adattamento di protocollo -- proxy)

• persistenza di alcuni dati (se serve)

• controllo sugli accessi (ACL)

• controllo processo (start, stop, restart, test, reload)

• logging


Agent: implementazione MIB

• Problematica principale nella realizzazione di un Agent

• La soluzione più pregiata è quella del compilatore di MIB (MIB Compiler):– il punto di partenza è la definizione in ASN.1 della struttura

dell’informazione gestita

– la compilazione può produrre dei sorgenti (in C, in C++, in Java) da completare poi compilare per ottenere un oggetto eseguibile

– la compilazione può anche produrre altre informazioni utili, come una documentazione HTML della MIB, dei test script per testare l’agent, un simulatore di agent per testare il manager, ecc.


Agent: compilazione MIB

• Problema della generazione del codice: va specificato il modo in cui si interagisce con le risorse, quindi intervenire nei sorgenti prodotti dalla compilazione dell’ASN.1

• Una buona soluzione è offerta della tecnologia OO: produrre delle classi astratte che vengono estese per fornire la funzionalità un file viene generato, per l’altro viene opzionalmente prodotto un template che viene completato

• Tutta la logica SNMP (parsing messaggi, interpretazione operazioni e OID) rimane all’interno della libreria di engine


Agent: esempio

ASN.1

sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory::= { system 3 } Compilator

e

Javapublic abstract class SystemGroup{ public Object invoke(OID o) { ... }

public abstract long getSysUpTime();}

Javapublic class SystemGroupImpl extends SystemGroup{ private long upTime_; public void init() { upTime_ = time(NULL); // ... } public long getSysUpTime() { return upTime_; }}

Questisi chiamano

Stub


Agent: architettura

SNMP Engine

Messaggi SNMP

Messageencoder/decoder

PDUdispatcher

SNMPLibrary

Method Handler

Helperfacilities(logging,processcontrol)

Skeleton

Stub

Skeleton

Stub

Skeleton

Stub

Skeleton

Stub

ResourceManager

PersistenceManager


Agent monolitico

• Singolo processo che contiene l’engine SNMP e la strumentazione (implementazione degli stub)

• I moduli di MIB supportati sono definiti al momento della compilazione

• Può essere molto efficiente, in particolare perché l’accesso alla strumentazione si fa per chiamata interna al processo (poi tutto dipende dalla qualità della strumentazione)

• Possibilità di implementare a livello di engine politiche di ottimizzazione, parallelizzazione e caching


Estensible Agents

• Spingendo ancora di più l’architettura è possibile separare la “macchina” SNMP dalla strumentazione dei moduli di MIB implementati

• La macchina SNMP viene chiamata Master Agent

• I moduli di MIB strumentati vengono chiamati Subagents

• Master e subagent comunicano attraverso un protocollo ad hoc

• Diventa possibile intervenire sui moduli di MIB supportati in maniera separata, nonché aggiungere/togliere moduli a runtime

• E’ del tutto trasparente alle applicazioni di gestione


AgentX

• La RFC 2257 definisce il protocollo AgentX per la realizzazione di agent estendibili

• Il Master Agent possono essere processi separati e comunicare via IPC (e.g. TCP su porta 705, ma anche Unix-domain sockets, ecc.)

Manager

AgentX Master Agent

Subagent

Subagent

Subagent

SNMPEntity

AgentXDispatcher


Protocollo AgentX (1)Primitive di amministrazione per la registrazione del Subagent

Master Subagent

Response

Open

Response

IndexAllocate

Response

Register

Response

AddAgentCaps

Apertura sessione

Allocazione indici

Registrazione MIB (singoleistanze o range di OID)

Aggiunta capabilities


Protocollo AgentX (2)Primitive per il funzionamento di SNMP: data retrieval

Master Subagent

Response

Get

Response

GetNext

Response

GetBulk

NotifyTrap

Il protocollo AgentX mappa il protocollo SNMP.

Una singola PDU SNMP può coinvolgere più subagent.


Protocollo AgentX (3)Primitive per il funzionamento di SNMP: operazione di set

Master Subagent

Response

TestSet

Response

CommitSet

Response

UndoSet

Response

Il protocollo AgentX è più complesso per la gestione della SetRequest, per poter gestire l’atomicità dell’operazione (o ha successo, o fallisce in toto)

CleaupSet


Protocollo AgentX (4)Primitive di amministrazione per la de-registrazione del Subagent

Master Subagent

Response

RemoveAgentCaps

Response

Unregister

Response

IndexDeallocate

Response

Close

Rimozione Capabilities

De-registrazione MIB

De-allocazione indici

Chiusura sessione


NMS: contesto

NetworkRepair

Help Desk

Assurance

Network

Inventory

reclamo

Trouble ticket

Devicepolling

Eventhandling

Datacollection

Reporting

Deviceconfig.Topology

discovery


NMS: requisiti funzionali• network discovery

• network inventory

• network topology browsing

• network monitoring– ricezione/correlazione trap

– polling periodico

– data collection

• alarm tracking

• fault root cause analysis

• fault resolution

• interface with trouble-ticketing system

• performance monitoring

• user interface (GUI, Web)

• workflow management

• reporting

• administration

• logging


NMS: architettura (1)• Un’architettura tipica consiste nella separazione di tre

livelli fondamentali:– persistenza dei dati (database -- RDBMS)

– logica di gestione (a volte anche chiamata business logic)

– interfaccia con il mondo esterno (utenti, sistemi, apparati)

• Idealmente questi aspetti sono ortogonali, in quanto possono evolvere indipendentemente

• Vengono rappresentati a strati logici chiamati tiers:– persistence tier (back-end)

– business logic tier

– front tier (presentation, interfaces)


NMS: architettura (2)

RDBMS

Persistent entitiesand relationships,

collected data,assets and inventory,configuration info.,provisioning info.,

administrative info.,etc.

Users and rolesmanagement

Inventory/assetsmanagement

Workflowmanagement

Events or ticketsescalation logic

Data consolidationand analysis

Other domain-specificbusiness logic

Installation-specificcustom logic

Management logic

External interfaces

Notificationsmanagement

APIs andextensions

To/fromexternalservices

User interfaces

GUI

Reporting

To/fromNMSusers

Web UI

Monitoring, administration, control

Discoverymanagement

Polling management

To/frommanageddevices,and/or

distributedagents

Configurationand provisioning

Event management

Client to remoteagents

Datacollector


Il modello dati

• Il database contiene delle strutture dati (tabelle) che devono poter catturare realtà molto diverse:– apparati con funzioni e caratteristiche diverse

– linee e collegamenti

– entità fisiche e logiche

• Per poter gestire una realtà eterogenea è necessario avere un modello generico (ma non troppo), in grado di rappresentare tutte le entità da gestire

• Un modello non è mai congelato, e può evolvere o essere esteso continuamente


Qualità architetturali richieste

• Estendibilità (possibilità di aggiungere funzionalità)

• Flessibilità (possibilità di estendere il dominio gestito)

• Robustezza (capacità a resistere agli imprevisti)

• Scalabilità (capacità a reggere l’aumento del numero di oggetti da gestire e il carico)


Soluzione OpenNMS

• Open Source -- free (http://www.opennms.org)

• Nato nel 1999

• A primavera del 2002, versione 1.0

• Presto uscirà la versione 1.2

• Orientato non solo alle risorse di rete, ma anche ai servizi di rete (DNS, DHCP, pagine web, accesso database)

• IP-centric

• Supporto multi-piattaforma (Java)


Monitoraggio dei serviziOpen Socket to port 25 Receive "220" banner

Send "HELO" Receive "250 pleased to meet you"Send "QUIT" and Exit Gracefully

Protocolli supportati:FTP, HTTP, SMTP, DNS, ICMP, TCP, SNMP...


Architettura OpenNMS (1)

PostgreSQLRDBMS

Servlet-basedapplication logic

Management logic

External interfaces

APIs andplugins

User interfaces

Perl GUI

Reporting

JSP Web UI

Monitoring, administration, control

notifd

discovery

capsd

dhcpd

pollerd

trapd

collectd eventd

actiond

rtcd

threshd

outaged


Architettura OpenNMS (2)• Tecnologie usate:

– RDBMS: PostgreSQL (open source)

– JSP/Servlet: Apache Jakarta Tomcat (disponibili anche Perl-script)

– Scritto in Java, processi concorrenti

– JMS (Java Message Service) con JBossMQ

– Alcune utilities scritte in Unix shell e Perl

• Daemons: processi concorrenti per i task di gestione (monitoring, control, data collections)

• File di configurazione in XML

• Estendibile tramite plug-in

• generazione reports in PDF con SVG e XSLT


Architettura OpenNMS (3)

Network Network Network

Distributedpoller

Distributedpoller

Distributedpoller

OpenNMS


Demoni OpenNMS

• discovery: discovery continuo dei nuovi nodi• capsd: capability check sui nodi (verifica sulle porte conosciute)• pollerd: polling sui nodi per determinare lo stato dei nodi• trapd: gestione trap SNMP• threshd: monitoraggio nodi e servizi basati sul raggiungimento di soglie• collectd: data collection daemon• eventd: salvataggio nel DB gli eventi generati dagli altri demoni• outaged: gestione della perdità di raggiungibilità dei nodi e servizi• actiond: workflow; esecuzione di attività automatiche su eventi• notifd: gestione di notifiche verso gli utenti (e.g. via e-mail)


Estendibilità OpenNMS

• E’ possibile estendere OpenNMS tramite plug-in

• Solitamente un plug-in è una classe Java che implementa una interfaccia ben definita per fornire una funzionalità nuova

• Il nome della classe viene scritto in un file di configurazione, con i parametri associati al plug-in

• Il sistema carica dinamicamente la classe Java (Class.forName(…)) ed è in grado di attivarla/chiamarla su richiesta


Esempio di plug-in

public class MyPlugin

implements org.opennms.netmgt.capsd.Plugin

{

public String getProtocolName() { return “SMTP”; }

public boolean isProtocolSupported(InetAddress address) {

try {

// open socket on port 25

// …

return true;

} catch (Exception e) {

return false;

}

}

}


Limitazioni OpenNMS

• Java non supporta ICMP (ping), quindi la misura richiede l’attivazione di un programma esterno tempi misurati troppo elevati

• Mancano alcuni tool amministrativi (configurazione utenti, sistema) grafici

• Non c’è una rappresentazione grafica delle reti e degli apparati

• Impossibilità di fare report sull’aggregazione di dati raccolti da più NMS

• Ancora alcuni bachi, non critici


OpenNMS Screenshot (1)








SNMP: soluzioni free

• CMU:– http://www.net.cmu.edu/groups/netdev/software.html

• NET-SNMP:– http://net-snmp.sourceforge.net/

• Scotty:– http://wwwhome.cs.utwente.nl/~schoenw/scotty/

• OpenNMS:– http://www.opennms.org/

• Advent:– http://www.adventnet.com/

• JMX:– http://java.sun.com/products/JavaManagement/


SNMP: soluzioni commerciali

• HP OpenView– Market leader, many third providers from management applications.

• IBM/Tivoli– Derived from HP OpenView, with many improvements and error

corrections.

• Cabletron Spectrum– Innovative technology (Inductive Modelling Technique).

• Sun Solstice Enterprise Manager– Follow-up version of the quite successful Sun Net Manager (partially

Java based).

• Computer Associates Unicenter TNG– Huge, graphical management console (too complex, made up of

several untighten applications).

Documents

Gestione di RetiPhilippe Macaire Gestione di Reti Manager/Agent: architetture software