NNMi 9, iSPIsund NA – vom Netzwerkmonitoringzum ... iSPIPerformance Kombiniertes Fehler-und Performance-Management Gemeinsames Polling mit NNMi Überwachung von Perf.-Schwellwerten

NNMi 9, iSPIs und NA –

vom Netzwerkmonitoring zum

integrierten Netzwerkmanagement

15. September 201015. September 2010

Nils Baresel, IT unlimited AG

Agenda

� Vorstellung der Produkte die an einer integrierten

Netzwerkmanagement Lösung beteiligt sind

� Tipps und Tricks zu NNM 9 und NA 7.6

� Anwendungsbeispiele aus dem kombinierten Einsatz

20.09.2010 IT unlimited AG 2

� Anwendungsbeispiele aus dem kombinierten Einsatz

mehrerer Produkte

� Fragen

Integriertes Netzwerkmanagement Produkte

� NNMi 9

� iSPI‘s – Quality Assurance, Traffic und Metric SPI (früher Performance SPI)

� Network Automation


NNM iSPI Performance

� Kombiniertes Fehler- und Performance-Management

� Gemeinsames Pollingmit NNMi

� Überwachung von Perf.-Schwellwerten

� Interaktive, kontext-sensitive Navigation sensitive Navigation

� Vordefinierte Reports

� KPIs von Netzwerk-geräten

� Interface-Statistiken

� Visualisierung von Netz-werkpfaden auf Layer 2und Layer 3


NNM iSPI Performance für Traffic

� Sammlung und Darstellung von NetFlow und sFlow Traffic-Informationen

� Analyse und Reporting

� Mapping zwischen Traffic-Flows und Applikationen

� Nahtlose Navigation zwischen Daten aus dem Metrik und Traffic SPIs

� Verteilte, hoch-skalierbare Architektur zur Daten-sammlung und Analyse


NNM iSPI für Traffic

� Traffic Map in NNMi

NNM iSPI für QA

� Discovery und Monitoring von IP SLA Tests� Reporting von IP SLA Tests

HP Network AutomationSystemüberblick

Provisioning &ConfigurationManagement

ProcessAutomation &

Control

Real-timePolicy

Enforcement

Compliance & Security

Management

Reporting(compliance, change, visibility)


Telnet/SSH Proxy

Management Engine

APIGUI

(compliance, change, visibility)

Load Balancers Switches Routers Firewalls

Network Infrastructure Automated

Tipps und Tricks zu NNM 9 und NA 7.6

� Vereinfachungen im Bereich Custom Poller� Nützliche Erweiterungen im Bereich der Incident

Configuration� Topology Aware Configuration

Vereinfachungen für den Custom Poller

� Mit NNM 8.x war das Finden einer passenden MIB Filter Variable oft eine Herausforderung


� Durch den neuen MIB Browser und die MIB Table View ist dies nun kein Problem mehr


� Exportieren von via Custom Poller abgefragten MIB Werten – mit NNM 9 kein Problem

Incident Individualisieren – sinnvolle Management Events

� Jeder Custom Poller Event wird genau gleich angezeigt und nicht unbedingt mit einem sinnvollen Message Text.

� Durch Incident Enrichments kann dies geändert werden

Incident Individualisieren

� Beispiel: Bei einer USV wird per Custom Poller der verbleibende Batterieladestand gemessen werden.� Für den Operator soll eine sinnvolle und verständliche Meldung

ausgegeben werden.Eine Default Meldung durch den Custom Poller hätte z.B. folgendes Format: $cia.custompoller.policy/$cia.custompoller.collection for variable $cia.custompoller.variable.description($cia.custompoller.variable.expression) is in the $cia.custompoller.state state.

� Stattdessen soll für die USV Meldungen eine Meldung wie z.B. „Verbleibende Batterieleistung unter 30 Minuten“ ausgegeben werden. Andere Custom Poller Meldungen sollen auf dem Default Wert bleiben

Incident individualisieren

Topology Aware Configuration

� Die Stärke von NA ist die Konfiguration und der Policy Check von Netzwerkgeräten. NA weiß aber nichts von der Netzwerktopology.

� Die Stärke von NNM ist die Topologie- und Fehlererkennung

� Beide Produkte kombiniert bieten eine „Topology Aware Configuration“Configuration“

� Anwendungsfall: Es besteht die Anforderung, dass in der Interface Description jeweils der 1 Hop Neighbor Node inkl. Port gelistet ist. Dies soll durch eine Policy in NA geprüft und geg. angepasst werden.


� Umsetzung� NNM kennt die Topologie und somit die L2 Connections

� Die Layer 2 Connection zu jedem Interface wird ausgelesen


� Umsetzung� Einlesen der aus NNM exportierten L2 Neighbor Informationen

in NA. Hierzu müssen sog. Custom Attributes angelegt und dann z.B. via Perl Script mit den Daten für das jeweilige Interface befüllt werden.


� Umsetzung� Über eine Policy kann nun geprüft werden, ob die Interface

Description dem Custom Attribute Wert entspricht und wenn nicht dies z.B. automatisiert korrigieren oder eine Meldung an NNM ausgeben (Policy Violation)

Anwendungsbeispiele durch den kombinierten Einsatz mehrere Produkte

� Workflow – Integriertes Netzwerkmanagement, mehr als nur eine Tool Konsolidierung

� Langsame Applikation – Traffic Analyse� Erkennung und Beseitigung von hohen Fehlerraten

Integriertes Netzwerkmanagement –mehr als nur eine Tool Konsolidierung

� Beispiel: Ein neues Netzwerkgerät wird aufgebaut

� Typische Tätigkeiten die dies zur Folge hat� Switch/Router wird aufgebaut und evtl. von externem Personal

konfiguriert� Anlage des Switches im Konfigurationswerkzeug z.B.

CiscoWorks (LMS…), CiscoWorks (LMS…), � Anlage des Switches in einem Reporting Tool z.B. MRTG� Anlage des Switches in einem Monitoring Tool z.B. NNM

� Nachfolgende Tätigkeiten� Kontrolle in allen Tools ob der Switch korrekt aufgenommen

und verwaltet wird� Bei Änderungen z.B. Access Credentials, muss diese

Information in allen Tools nachgepflegt werden.

Integriertes Netzwerkmanagement –mehr als nur eine Tool Konsolidierung

Node wird automatisch in NA angelegt

NNMi discoveredNode

Change wird an Node durchgeführt

Node wird automatisch in iSPI

Node Groups angelegt

Fallbeispiel 1: Langsame Applikation

� Anwender beschweren sich beim Helpdesk über langsame Reaktionszeiten einer Applikation – „Das Netzwerk ist langsam, meine Applikation xy reagiert kaum“

� Helpdesk eröffnet ein Troubleticket das dem Netzwerk Operating zugestellt wird.

� Vorgehen ohne integriertes Netzwerkmanagement� Vorgehen ohne integriertes Netzwerkmanagement� Operator/Network Engineer versucht z.B. über Traceroute

herauszubekommen welche Komponenten am Datenverkehr für die betroffene Applikation beteiligt sind (Server-to-Server Communication).

� Routing Tabellen werden analysiert um herauszufinden über welche Interface der Datenverkehr läuft

� Network Engineer schaltet sich auf alle Geräte um die Konfiguration und Auslastung zu prüfen

� Mit sniffern wird versucht herauszufinden welche Daten zu der hohen Auslastung führen

� Rerouting/ACL Anpassungen werden durchgeführt um das Problem zu beheben.


� Vorgehen mit Integriertem Fault, Performance und Konfigurationsmanagement� Durch den Einsatz vom Metric SPI wird die Interface

Performance von wichtigen Interfacen überwacht. In der Konsole erscheint daher eine Meldung dass eine hohe Interface Utilization von einem betroffenen Node vorliegt.


� Um herauszufinden welcher Datenverkehr für die hohe Utilization verantwortlich ist wird der Traffic SPI gestartet.

� Zusätzlich zeigt ein IPSLA Test zwischen den beteiligten Routern noch einen Paket Verlust an.


� Nachdem nun klar ist was die hohe Auslastung verursacht (z.B. ein Backup Lauf der auf die falsche Uhrzeit konfiguriert ist oder ein Internet Download oder anderer unerwünschter Datenverkehr) kann über NA eine Konfigurationsanpassung vorgenommen werden um die ACL‘s oder Routing Daten anzupassen.

� In der NNM Console wird nach der Konfigurationsänderung der Incident automatisch geschlossen da das Problem behoben ist.

Fallbeispiel 2: Hohe Fehlerraten auf einem Interface – Duplex Missmatch

� Durch den Einsatz des Metric SPI werden auf wichtigen Interfacen Performance Werte überwacht, so auch auf CRC Fehler.

� Über einen Cross Launch in die NA GUI kann nun geprüft � Über einen Cross Launch in die NA GUI kann nun geprüft werden ob bei diesem Interface Konfigurationsänderungen durchgeführt wurden

Fallbeispiel 2: Hohe Fehlerraten auf einem Interface

� Durch die ständigen Konfigurationssicherungen die NA durchführt kann direkt die Änderung zum vorherigen Stand angezeigt werden und somit auch in diesem Fall die Ursache für den Fehler ermittelt werden.

� Durch ein „Deploy to running configuration“ kann diefehlerfreie Konfiguration direkt wieder hergestellt werden.

� Der Incident in NNMi wird automatisch geschlossen wenn das Problem behoben ist.

Tipp zum Fallbeispiel 2

� Sollen z.B. Interface auf Access Switchen auf Fehler und somit mögliche defekte Netzwerkkarten der PC‘s oder falsche Duplexeinstellungen geprüft werden, so kann dies einfach über das Monitoring erfolgen.

� Umsetzung� 1. Über eine Interface Group werden die Access Interface

identifiziert� 2. Für die erstellt Interface Group wird ein spezielles Interface

Monitoring aufgesetzt das nur Performance Werte prüft und kein Fault Polling durchführt (Alarme durch einen PC Rebootsollen vermieden werden)

� 3. Durch den Performance SPI for Metrics können einfach die Fehlerraten auf den Interfacen geprüft werden.

Tipp zum Fallbeispiel 2

Fault Polling ist nicht aktiv

Performance Polling ist aktiv

PC‘s sind nicht in DB – daher sind Ports

unconnected

Documents

NNMi 9, iSPIsund NA – vom Netzwerkmonitoringzum ... iSPIPerformance Kombiniertes Fehler-und Performance-Management Gemeinsames Polling mit NNMi Überwachung von Perf.-Schwellwerten