Verteilte Monitoring-Umgebungen unter Verwendung eines Enterprise Service Bus

Transkript

1 Verteilte Monitoring-Umgebungen unter Verwendung eines Enterprise Service Bus NETWAYS OSMC Referent: Bernd Erk

2 Agenda DESTINATION TIME REMARK KURZVORSTELLUNG SERVICEORIENTIERTE ARCHITEKTUR EIN ENTERPRISE SERVICE BUS EINSATZ VON JAVA FEATURES MULE ESB MONITORING ENDPOINTS INTEGRATIONSBEISPIEL LIVE DEMO FAZIT UND AUSBLICK FRAGEN UND ANTWORTEN 3 SLIDES 3 SLIDES 3 SLIDES 2 SLIDES 4 SLIDES 3 SLIDES 10 SLIDES 1 SLIDES 5 SLIDES 1 SLIDES ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME

3 BOARDING KURZVORSTELLUNG

4 Kurzvorstellung BERND ERK 32 Jahre seit 2007 bei der NETWAYS GmbH zuvor 8 Jahre im Bereich der IT-Architektur, Oracle und J2EE Datenbankoptimierung und Hochverfügbarkeit High Performance Architekturen im SOA-Umfeld Icinga Team Member Abhängigkeiten Parents: Yes RefersTo: Yes Child: Yes

5 Kurzvorstellung NETWAYS Firmengründung 1995 GmbH seit 2001 Open Source seit 1997 Nagios / Netsaintseit festangestelltemitarbeiter Spezialisierung in den Bereichen Open Source Systems Management und Open Source Datacenter Solutions

6 Aktuelles NETWAYS Addons NETWAYS Plugins LConf LDAP basierte Nagios/Icinga Konfiguration Reporting auf Basis von Jasper IcingaDevelopment RelaunchMonitoringExchange Auf Basis von Catalot (catalot.org) Plugin/AddonCommunity Plattform

7 BOARDING SERVICEORIENTIERTE ARCHITEKTUR

8 SOA im Überblick SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird Kriterien Ein Service ist autonom und ist als solches verwendbar Ein Service ist in einem Netzwerk erreichbar Ein Service hat mind. eine veröffentlichte Schnittstelle Ein Service ist unabhängig von Plattform und Sprache Ein Service ist in einem Verzeichnis gelistet Ein Service ist lose gekoppelt

9 Vor- und Nachteile einer SOA Architektur Vorteile Hohe Agilität und Qualität durch fachliche Abgrenzung Möglichkeit der Widerverwendbarkeit langfristig geringere IT-Kosten Höheres Verständnis für Geschäftsprozess Nachteile Der Begriff SOA wird aus vertrieblichen Aspekten oft missbraucht Höhere Integrations- und Testaufwände durch verteilte Dienste Komplexere Analyseszenarien erhöhen Entwicklungsaufwände Von Entwickler in der Regel mehr Know-how erforderlich Initialer Mehraufwand verbunden mit langfristiger Flexibilität und Kostenersparnis

10 SOA Modell Orchestration Workflow Workflow Dienste Dienst A Dienst B Kommunikation Enterprise Service Bus Anwendungen Monitoring Reporting Ticketing... Hardware Storage Netzwerk Server...

11 BOARDING ENTERPRISE SERVICE BUS

12 Merkmale ESB Datenbus zur gesicherten Übertragung von Informationen zwischen verschiedenen Endpunkten Adapter zur Kopplung diverser Dienstanbieter und Dienstnutzer Bereitstellung von Funktionen zur Integration verteilter Dienste und deren Daten Routingdienste Transformationsdienste Monitoringdienste

13 Ein Datenbus FTP RDBMS Applikation Enterprise Service Bus Mail Webservice Monitoring

14 Routing und Transformation FTP RDBMS Applikation Map Enterprise Service Bus Textfile Mail Webservice Monitoring

15 BOARDING EINSATZ VON JAVA

16 Vorurteile

17 Java im heterogenen-umfeld Betrachtung von Java unter drei Kriterien Laufzeitperformance Startperformance Speicherbedarf Integrationsvorteil durch Plattformunabhängigkeit Alle gängigen ESB System basieren auf Java Entwicklungsumgebung und Standards für Management

18 BOARDING FEATURES MULE ESB

19 Verfügbare Transports (Auswahl) Community Edition Axis IMAP EJB IMAPS JDBC File SMTP FTP SOAP HTTP TCP HTTPS UDP EJB XMPP MuleForge.org Hibernate SMS-Versand SFTP Salesforce SAP via SJC

20 Verfügbare Router (Auswahl) Pass-Through-Router: direktes Routing einer Nachricht Filtering-Router: inhaltliche Prüfung der Nachricht und abhängige Weiterverarbeitung Exception-Based-Router: alternative Nachrichtenübermittlung bei fehlerhaften Transports CollectionAggregator: gruppiert eingehende Nachrichten und ermöglicht deren Verarbeitung im Batch-Betrieb Wiretap-Router: ermöglicht die zusätzliche Umleitung bestimmter Nachrichten zu alternativen Zielen

21 Management und Monitoring Management und Konfigurationsverteilung via MuleGalaxy Zentrales Monitoring via JMX MX4J check_jmx check_jmx4perl

22 Sonstige Features Deployment Szenarien Standalone: Java WrapperBinary Java-App: ServletEngine oder StandaloneApp MuleNetBoot: Verteilungskonzept mit Hilfe von Galaxy Integrierter JMX-Agent JMX-WebConsole MX4J EclipsePlugin Transaktionsmanagement Diverse Security-Adapter

23 BOARDING MONITORINGENDPOINTS

24 Verteilte Nagios/Icinga Umgebung

25 Benötigte Services Service zur Verteilung der Konfiguration Server: Lesen aus Filesystem und Senden an Satellit(en) Satellit(en): Empfangen und Speicherung in Filesystem Service zur Verarbeitung der Status- und Performancedaten Satellit(en): Lesen aus Filesystem und Senden an Server Server: Empfangen der Daten und Laden in externes Kommandofile Service zur Verarbeitung von Kommandos Server: Lesen der ausgeführten Kommandos aus NDO/IDO-DB Server: Prüfung des Inhalts auf dezentrale Kommandos Server: Senden der Kommandos an betroffene Satellit(en) Satellit(en): Empfangen der Daten und Laden in externes Kommandofile

26 Optionale Services Service zur Aggregation und Weitergabe an Drittsysteme Reportingdatenbank Konsolidierungsebene Service zur Versendung von SMS Nachrichten RealtimeSLA-Monitoring Verarbeitung von Logdaten usw.

27 BOARDING INTEGRATIONSBEISPIEL

28 Konfiguration des Mule ESB Definition von Models und Services in mule-config.xml Konfiguration von Attributen in XML oder Property-Dateien Eclipse IDE unterstützt bei Konfigurationsprozess Syntaxvervollständigung Test und Debugging Nutzung von Features durch Inkludierung der Namespaces

29 ON TIME STATUSDATEN

30 Konfiguration der Connectoren Connector für Verarbeitung der Status- und Performancedaten <file:connectorname="statusdatareadconnector" fileage="10000" autodelete="false" pollingfrequency="10000"/> Connector für Versendung der Status- und Performancedaten < keepalive="false" enablecookies="false"/>

31 Versenden der Statusdaten  <modelname="statusdata"> <servicename="statusdataread"> <inbound> <file:inbound-endpointconnector-ref="statusdatareadconnector" path="${statusdataread.readurl}" transformer-refs="filetobyte" movetodirectory="${statusdataread.doneurl}"> <file:filename-wildcard-filterpattern="${statusdataread.pattern}"/> </file:inbound-endpoint> </inbound> <outbound> <pass-through-router> <vm:outbound-endpointpath="statusdatasendvm"/> </pass-through-router> </outbound> </service> <servicename="statusdatasend"> <inbound> <vm:inbound-endpointpath="statusdatasendvm"/> </inbound> <outbound> <exception-based-router> < address="${statusdatasend.httpurl}" path="${statusdatasend.httppath}" synchronous="false"/> </exception-based-router> </outbound> </service>

32 Empfangen der Statusdaten  <modelname="statusdata"> <servicename="statusdatareceive"> <inbound> < address="${statusdatareceive.httpurl}" path= ${statusdatareceive.httppath}" transformer-refs="httptobytearray" synchronous="true"/> </inbound> <outbound> <pass-through-router> <vm:outbound-endpointpath="statusdatastorevm"/> </pass-through-router> </outbound> </service> <servicename="statusdatastore"> <inbound> <vm:inbound-endpointpath="statusdatastorevm"/> </inbound> <outbound> <pass-through-router> <file:outbound-endpointconnector-ref="statusdatastoreconnector" path="${statusdatastore.fileurl}" outputpattern="#[header:originalfilename]"/> </pass-through-router> </outbound> </service> </model>

33 Laden der Statusdaten  <modelname="statusdata"> <servicename="statusdataread"> <inbound> <file:inbound-endpointconnector-ref="statusdatareadconnector" path="${statusdataread.readurl}" movetodirectory="${statusdataread.doneurl}"/> </inbound> <outbound> <pass-through-router> <vm:outbound-endpointpath="statusdataloadvm"/> </pass-through-router> </outbound> </service> <servicename="statusdataload"> <inbound> <vm:inbound-endpointpath="statusdataloadvm"/> </inbound> <outbound> <pass-through-router> <file:outbound-endpointconnector-ref="statusdataloadconnector" path="${statusdataload.writepath}" outputpattern="${statusdataload.writefile}"/> </pass-through-router> </outbound> </service> </model>

34 ON TIME KOMMANDODATEN

35 Konfiguration der Connectoren Connector für Ermittlung der Kommandodaten <jdbc:connectorname="commanddatareadconnector" pollingfrequency="10000" datasourceref="commanddatasource"> <jdbc:querykey="selectcommands value="${commanddataread.jdbcselect}"/> <jdbc:querykey="selectcommands.ack value="${commanddataread.jdbcselectupdate}"/> </jdbc:connector> SQL Statements zur Ermittlung der Kommandodaten selectinstance_id, externalcommand_id, command_type, command_name, command_argsfromnagios_externalcommandswhereinstance_id = 1 order byentry_timedesclimit 0,25 update nagios_externalcommandssetinstance_id = #[map-payload:instance_id]00 whereexternalcommand_id = #[map-payload:externalcommand_id]

36 Ermittlung der Kommandodaten  <modelname= commanddata"> <servicename="commanddataread"> <inbound> <jdbc:inbound-endpointquerykey="selectcommands" transformer-refs="listtocommand"/> </inbound> <outbound> <filtering-router> <vm:outbound-endpointpath="commanddatasendsatellitevm"/> <custom-filterclass="org.netways.mule.icinga.filter.commandfilter"> <spring:propertyname="recipient" value="s"/> </custom-filter> </filtering-router> <filtering-router> <vm:outbound-endpointpath="commanddatasendmastervm"/> <custom-filterclass="org.netways.mule.icinga.filter.commandfilter"> <spring:propertyname="recipient" value="m"/> </custom-filter> </filtering-router> </outbound> </service> </model>

37 Versenden der Kommandodaten  <modelname= commanddata"> <servicename="commanddatasendsatellite"> <inbound> <vm:inbound-endpointtransformer-refs="commandtostring" path="commanddatasendsatellitevm"/> </inbound> <outbound> <multicasting-router> < address="${commanddatasendsatelliteconnector.httpurl1}" path="${commanddatasendsatelliteconnector.httppath1}" synchronous="false"/> </multicasting-router> </outbound> </service> </model>

38 BOARDING LIVE DEMO

39 Live Demo Let s Go

40 BOARDING FAZIT & AUSBLICK

41 Vorteile Integrierte Überwachung und somit Transparenz Modularität und Wiederverwendbarkeit Standardisierte Protokolle Code-Qualität durch Schema-Vorgaben Transaktionssicherheit und Stabilität Einfache Erweiterbarkeit

42 Vorzug gegenüber Individuallösung  <modelname= commanddata"> <servicename="commanddatasendsatellite"> <inbound> <vm:inbound-endpointtransformer-refs="commandtostring" path="commanddatasendsatellitevm"/> </inbound> <outbound> <multicasting-router> < address="${commanddatasendsatelliteconnector.httpurl1}" path="${commanddatasendsatelliteconnector.httppath1}" synchronous="false"/> </multicasting-router> < </outbound> address="${commanddatasendsatelliteconnector.httpurl2}" </service> path="${commanddatasendsatelliteconnector.httppath2}" synchronous="false"/> </model> </multicasting-router> </outbound> </service> </model>

43 Vorzug gegenüber Individuallösung  <modelname="statusdata"> <servicename="statusdatasend"> <inbound> <vm:inbound-endpointpath="statusdatasendvm"/> </inbound> <outbound> <exception-based-router> <ftp:endpointuser= user" < password= password" host= server.localdomain address="${statusdatasend.httpurl}" path="/ftp/incoming"> <file:filename-wildcard-filterpattern= *.perf"/> path="${statusdatasend.httppath}" synchronous="false"/> </ftp:endpoint> </exception-based-router> </exception-based-router> </outbound> </outbound> </service> </service> </model> </model>

44 Vorzug gegenüber Individuallösung  --> <modelname="statusdata"> <servicename="statusdataread"> <inbound> <file:inbound-endpointconnector-ref="statusdatareadconnector" path="${statusdataread.readurl}" movetodirectory="${statusdataread.doneurl}"/> <properties> </inbound> <propertyname="binary" value="false"/> <outbound> <propertyname="pollingfrequency" value="1000"/> <pass-through-router> <propertyname="outputpattern" value="#[header:originalfilename]"/> <vm:outbound-endpointpath="statusdataloadvm"/> </properties> </pass-through-router> </endpoint> </outbound> </inbound> </service> <outbound> </model> <pass-through-router> <vm:outbound-endpointpath="statusdataloadvm"/> </pass-through-router> </outbound> </service> </model>

45 Roadmap Implementierung auf MonitoringExchange.org und netways.org Adapter für Nagios und Icinga auf MuleForge.org Nagios/IcingaPlugin für Mule ESB Hot Deployment in Mule Release 3 konkrete Implementierungen in diesem Jahr

46 BOARDING FRAGEN UND ANTWORTEN

47 Fragen und Antworten Jetzt und Hier NETWAYS GmbH Deutschherrnstrasse Nürnberg netways blog.netways.de