1 / 35

Gestione di Reti

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)

Download Presentation

Gestione di Reti

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gestione di Reti Manager/Agent:architetture software Philippe Macaire

  2. Obiettivi • Dettagliare l’architettura software tipica di un Agent e di un Manager • Esempio: studio dell’architettura di OpenNMS Philippe Macaire

  3. 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 Philippe Macaire

  4. 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. Philippe Macaire

  5. 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 Philippe Macaire

  6. Agent: esempio Java ASN.1 public abstract class SystemGroup { public Object invoke(OID o) { ... } public abstract long getSysUpTime(); } sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory ::= { system 3 } Compilatore Java public class SystemGroupImpl extends SystemGroup { private long upTime_; public void init() { upTime_ = time(NULL); // ... } public long getSysUpTime() { return upTime_; } } Questi si chiamano Stub Philippe Macaire

  7. Stub Stub Stub Stub Skeleton Skeleton Skeleton Skeleton Agent: architettura Resource Manager Persistence Manager Helper facilities (logging, process control) Method Handler SNMP Engine Message encoder/decoder PDU dispatcher SNMP Library Messaggi SNMP Philippe Macaire

  8. 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 Philippe Macaire

  9. 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 Philippe Macaire

  10. 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.) Subagent AgentX Master Agent Manager SNMP Entity AgentX Dispatcher Subagent Subagent Philippe Macaire

  11. Subagent Master IndexAllocate Open Register AddAgentCaps Response Response Response Response Protocollo AgentX (1) Primitive di amministrazione per la registrazione del Subagent Apertura sessione Allocazione indici Registrazione MIB (singole istanze o range di OID) Aggiunta capabilities Philippe Macaire

  12. Subagent Master Protocollo AgentX (2) Primitive per il funzionamento di SNMP: data retrieval Get Il protocollo AgentX mappa il protocollo SNMP. Una singola PDU SNMP può coinvolgere più subagent. Response GetNext Response GetBulk Response Notify Trap Philippe Macaire

  13. Subagent Master Protocollo AgentX (3) Primitive per il funzionamento di SNMP: operazione di set TestSet Il protocollo AgentX è più complesso per la gestione della SetRequest, per poter gestire l’atomicità dell’operazione (o ha successo, o fallisce in toto) Response CommitSet Response UndoSet Response CleaupSet Response Philippe Macaire

  14. Subagent Master Unregister RemoveAgentCaps IndexDeallocate Close Response Response Response Response Protocollo AgentX (4) Primitive di amministrazione per la de-registrazione del Subagent Rimozione Capabilities De-registrazione MIB De-allocazione indici Chiusura sessione Philippe Macaire

  15. Network NMS: contesto reclamo Help Desk Trouble ticket Reporting Assurance Inventory Event handling Device polling Data collection Device config. Topology discovery NetworkRepair Philippe Macaire

  16. NMS: requisiti funzionali • interface with trouble-ticketing system • performance monitoring • user interface (GUI, Web) • workflow management • reporting • administration • logging • network discovery • network inventory • network topology browsing • network monitoring • ricezione/correlazione trap • polling periodico • data collection • alarm tracking • fault root cause analysis • fault resolution Philippe Macaire

  17. 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) Philippe Macaire

  18. User interfaces To/from NMS users GUI Reporting Web UI NMS: architettura (2) Monitoring, administration, control Management logic Discovery management To/from managed devices, and/or distributed agents Polling management Persistent entities and relationships, collected data, assets and inventory, configuration info., provisioning info., administrative info., etc. Users and roles management Configuration and provisioning Event management Inventory/assets management Client to remote agents Data collector Workflow management Events or tickets escalation logic RDBMS Data consolidation and analysis To/from external services Other domain-specific business logic External interfaces Notifications management APIs and extensions Installation-specific custom logic Philippe Macaire

  19. 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 Philippe Macaire

  20. 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) Philippe Macaire

  21. 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) Philippe Macaire

  22. Monitoraggio dei servizi Open 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... Philippe Macaire

  23. Architettura OpenNMS (1) Monitoring, administration, control Management logic discovery pollerd capsd collectd eventd actiond trapd dhcpd rtcd User interfaces PostgreSQL RDBMS Perl GUI threshd Reporting JSP Web UI outaged External interfaces notifd APIs and plugins Servlet-based application logic Philippe Macaire

  24. 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 Philippe Macaire

  25. Network Network Network Architettura OpenNMS (3) OpenNMS Distributed poller Distributed poller Distributed poller Philippe Macaire

  26. 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) Philippe Macaire

  27. 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 Philippe Macaire

  28. 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; } } } Philippe Macaire

  29. 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 Philippe Macaire

  30. OpenNMS Screenshot (1) Philippe Macaire

  31. OpenNMS Screenshot (2) Philippe Macaire

  32. OpenNMS Screenshot (3) Philippe Macaire

  33. OpenNMS Screenshot (4) Philippe Macaire

  34. 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/ Philippe Macaire

  35. 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). Philippe Macaire

More Related