550 likes | 642 Vues
JavaBased Network Management. (1) „Warum JAVA-based network management ?“ (Frank Rechenberger) (2) JAVA-Extensions (Robert Nickel) (3) Zwei Ansätze (Daniel Scheibler) (4) Protokollmapping (Falk Hamann). Gliederung. Kurze Wiederholung: Netzwerkmanagement
E N D
JavaBased Network Management (1) „Warum JAVA-based network management ?“ (Frank Rechenberger) (2) JAVA-Extensions (Robert Nickel) (3) Zwei Ansätze (Daniel Scheibler) (4) Protokollmapping (Falk Hamann)
Gliederung • Kurze Wiederholung: Netzwerkmanagement • Anforderungen und Probleme • Aktuelle Situation • Entwicklungen • Ziele • Warum Java ? • Überleitung ...
User Interface Manager SNMP Agent Agent Agent MIB MIB MIB
Agenten • Lesen der Informationen aus der MIB • Weitergabe von Änderungen an die MIB • Konvertierung nach den „BER-Encoding Rules“ • keine Vorverarbeitung der Daten, nur bei RMON • Lebenslauf: Start, dann Dauerbetrieb
Agenten - Anforderungen • Stabilität • Geringe CPU-Belastung • Sicherheit (authentification, encryption) • Erweiterbarkeit • Wartbarkeit • Erreichbarkeit
MIB • Agentenseite • Menge der MOs • Strukturvorgabe durch Internet-MIB • ASN.1
Manager • Visualisierung der Netzstruktur • Abfrage der Information • Datensammlung und Haltung (DB) • Setzen von Managementparametern • Kommunikationszyklen 30s ...1h • Pooling trotz Traps
Manager - Anforderungen • Erweiterbarkeit • Personalextensiv • Intelligente Vorinterpretation und Aufbereitung der Daten • Automatismen (Trouble Tickets, Ereignissteuerung) • Umfassend Konfigurierbar
SNMP - Probleme • schlechte Sicherheitsmechanismen in SNMPv1, SNMPv2 • SNMPv3 kein Sicherung vor: DOS, Verkehrsanalyse • BER-encoding ineffizient • SNMP varbind lists relativ groß • bei hohe Datenaustauschraten SNMP ineffizient
Heutige Situation im NM • Homogene Netzwerkstrukturen • Agenten und Manager vom Hardwareanbieter mit Minimal-_funktionalität und -sicherheit • Agenten nicht erweiterbar , Development-Kits • Manager-Funktionalität oft nur erweiterbar über Manager-APIs
Entwicklungen • Größe und Komplexität steigen explosionsartig • Sicherheitsanforderungen steigen • Homogene Netzwerkstrukturen sind nicht mehr haltbar • Heterogene Netzwerke sind unter heutigen Bedingungen teuer • Lebenszyklen der Systeme und Standards werden kürzer • Personalkosten bleiben hoch • Fremdmanagement durch Serviceanbieter
Ziel • Portabilität • Stabilität • Erweiterbarkeit • Effizienz • Geringe Entwicklungskosten • Automatische Managementfunktionen • Manager-Manager Kommunikation
Warum ist Java die beste Lösung? Java ist Plattform- und Hardwareunabhängig, Java bietet ein umfassendes OO-Konzept Modularität, Vererbung, Wiederverwendbarkeit Java bietet von Haus aus und der Geburt an Netzwerk- und NM Unterstützung Java unterstützt alle nützlichen Protokolle Java bietet ein ausgeprägtes Sicherheitskonzept
JavaBased Network Management Java-Features Robert Nickel
java.net • Umfassende leicht verständliche Netzwerkfunktionalität • TCP (URL, Socket, ServerSocket) • UDP (Datagram, Multicast) Wozu ??? Leicht implementierbare Kommunikation zwischen Agents und Managern
Reflection API • Analyse von Java-Klassen (Attribute/Methoden) • Dynamisches Laden Wozu ??? Versenden von ausführbarem Code
Java Native Interface • Nutzen von Nicht-Java-Code • Zugriff auf Systemspezifische Funktionalität Wozu ??? Zugriff des Agenten auf die Attribute des MO
Security (I) JCE : • Verschlüsselung (symmetrisch, asymmetrisch, block cipher, stream cipher) • Message-Authentication-Algorithmen (MAC)
Security (II) JAAS: • Algorithmen zur Authentisierung/Authorisierung • Nutzer-, Gruppen- und Rollen-basierte Zugriffskontrollmechanismen
Security (III) JSSE: • Unterstützung für SSL und TSL bei bel. Protokoll (HTTP, Telnet, NNTP, FTP, TCP/IP)
Security (IV) Wozu ??? • Sicherer, d.h. vor Manipulation geschützter Informationsaustausch • Authentisierung der Agents=> Schutz vor Fremdlingen
JDBC • Umfangreiche Datenbankfunktionalität Wozu ??? • Strukturierte Speicherung von umfangreichen MIBs • Agenten verfügen über Liste zuständiger Manager=> Suchfunktion • Archivierung zu Statistikzwecken auf Managerseite
JNDI (I) • Strukturierung und Identifizierung von Entitäten mit menschenverständlichen Namen / Adressen • SPI bietet Zugang zu anderen Verzeichnisdiensten wie DNS, LDAP, DAP, NDS, NIS
JNDI (III) Wozu ??? • Intuitive Strukturierung der MOs • Bildung von Hierarchien, die sich im Name-to-Adress-Mapping wiederspiegeln
RMI / RMI-IIOP • Aufruf von Funktionen auf entfernten Entitäten • Neu: Jetzt auch CORBA-basiert Wozu ??? • Alternative zu Sockets
IDL • CORBA-Feature: IDLSprachneutrale Schnittstellendefinition • Java-IDL = IDL-Mapping für Java
RMI / IDL Wozu ??? • Remote-Steuerung der MOs • Einbinden fremder Agents die über RMI gesteuert werden • Management von CORBA-Agents
Java Beans (I) • Wiederverwertbare Softwarekomponenten • Einfacher Entwurf • Hierarchische Strukturierung in Kontexten • Service-Funktionalität
Java Beans (II) Wozu ??? • Entwurf wiederverwertbarer modularer Agents / Manager • Nutzen der geg. Funktionalität zum Anbieten von Services • JMX basiert auf Bean-Technologie
JMX • Instruction-Level (einfaches Management aller Java-basierten Objekte) • Agent-Level (rudimentäre Agent-Container, die mit Funktionalität / Resourcen erweitert werden können) • Manager-Level (Management-Komponenten, die sowohl als Agent als auch Manager operieren können) • Zusätzliche Protokoll-APIs (SNMP, WBEM, TMN...)
JavaBased NetworkManagement Zwei Ansätze Daniel Scheibler
Inhalt • Einleitung • Ansatz der Arizona State University, USA • Ansatz der University of Essex, UK • Vergleich • Literatur
Arizona – Manager Kommunikation Manager - Agent • Auslesen der Parameter aus der GUI • Generierung des OID strings • Generierung einer Java Klasse mit OID string • Compilierung der Klasse in Bytecode • Versand des Bytecode an den Agent • Ausführen der enthaltenen Methode beim Agent und auswerten des gelesenen OID strings
Arizona – Agent Hauptfunktionen des Agenten • Anfragen vom Manager bearbeiten • MIB tree parsen • Ereignismeldungen an den Manager schicken
Eigenschaften CMU-SNMP Java/Web Transport protocol UDP TCP Deamon SNMPd Agent MIB type ASN.1 ASN.1 Encoding BER Bytecode Message passing SNMP PDU Class Extensible Agent difficult easy Security low level good Auto. configuration not defined defined Arizona – CMU - Vergleich
Arizona – future work • Agenten mittels Broadcast automatisch auffinden • Mehrere Agenten mit einem Manager verwalten • MIB Struktur expandieren und reduzieren • Mobile Agenten unterstützen
Essex – Manager • Browser-basierte GUI • Kommunikation: Socket-basiert • TCP & UDP unterstützt • Authentifiktion von Managern • Datenverschlüsselung bei Agenten • weitere Möglichkeiten • Navigation durch MIB • Automatisches Ausführen von Network Discovery
Essex - Agent • Hintergrundprozess horcht an einem bekannten TCP oder UDP port • pro eingehender Anfrage wird ein thread gestartet • Multi-Managerfähigikeit
Object name mib-2 System ifType Syntax Integer Access Read-only Status ... Mandatory Description Parent node Mgmt mib-2 ifEntry Identifier 1 1 3 Record Index 0 1 23 Essex – MIB Parser • Aufbau eines Random Access File
Essex - Sicherheitsaspekte • Manager signiert Anfragen • Agenten verschlüsselt Antworten • Verschlüsselungsverfahren: RSA
Essex – future work • Optimierung des Codes von Manager und Agent, um die Antwortzeit zu verringern • Konstruktion einer erweiter- und reduzierbaren Repräsentation der MIB im Manager • Unterstützung von mobilen Agenten
JavaBased Network Management Protokollmapping Falk Hamann
Protokollmapping • Zwei Möglichkeiten um möglichst viele Clients anzubinden • homogen = alle Sprechen selbe Sprache (Java) • Protokollmapping
Wo liegt das Problem ? • Viele Clients, alle mit unterschiedlichen Protokollen anzusprechen • Manager soll relativ unabhängig davon sein • Manager untereinander könnten über RMI kommunizieren, oder eine andere modere „Sprache“
Was ist die Idee ? • Wie in der Softwaretechnik vorgehen: • Verwendung von Entwurfsmustern • Qualitätsziele: Wiederverwendbarkeit, Anpassbarkeit, Erreichbarkeit • Kapselung von Daten und Funktionalität