SlideShare ist ein Scribd-Unternehmen logo
1 von 47
Downloaden Sie, um offline zu lesen
Verteilte Monitoring-Umgebungen unter
Verwendung eines Enterprise Service Bus
29.10.2009 – NETWAYS OSMC
Referent: Bernd Erk
KURZVORSTELLUNG
SERVICEORIENTIERTE ARCHITEKTUR
EIN ENTERPRISE SERVICE BUS
FEATURES MULE ESB
MONITORING ENDPOINTS
INTEGRATIONSBEISPIEL
LIVE DEMO
FRAGEN UND ANTWORTEN
FAZIT UND AUSBLICK
EINSATZ VON JAVA
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
ON TIME
3 SLIDES
3 SLIDES
3 SLIDES
4 SLIDES
10 SLIDES
1 SLIDES
5 SLIDES
1 SLIDES
3 SLIDES
2 SLIDES
DESTINATION TIME REMARK
Agenda
KURZVORSTELLUNG
BOARDING
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
Kurzvorstellung NETWAYS
Firmengründung 1995
GmbH seit 2001
Open Source seit 1997
Nagios / Netsaintseit 1999
21 festangestellteMitarbeiter
Spezialisierung in den Bereichen Open Source Systems
Management und Open Source Datacenter Solutions
Aktuelles
www.netways.org
– 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
SERVICEORIENTIERTE
ARCHITEKTUR
BOARDING
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
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
SOA Modell
Enterprise Service Bus
Dienst A Dienst B ... ...
Workflow Workflow ... ...Orchestration
Dienste
Storage Netzwerk Server ...
Monitoring Reporting Ticketing ...Anwendungen
Hardware
Kommunikation
ENTERPRISE SERVICE BUS
BOARDING
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“
Ein Datenbus
FTP RDBMS Applikation
Mail Webservice Monitoring
Enterprise Service Bus
Routing und Transformation
RDBMS
Monitoring
ApplikationFTP
Mail Webservice
Enterprise Service Bus
Map
Textfile
EINSATZ VON JAVA
BOARDING
Vorurteile
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
FEATURES MULE ESB
BOARDING
Community Edition
Axis
EJB
Email
File
FTP
HTTP
HTTPS
EJB
MuleForge.org
Hibernate
SMS-Versand
SFTP
Salesforce
SAP via SJC
IMAP
IMAPS
JDBC
SMTP
SOAP
TCP
UDP
XMPP
Verfügbare Transports (Auswahl)
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
Management und Monitoring
Management und Konfigurationsverteilung via MuleGalaxy
Zentrales Monitoring via JMX
– MX4J
– check_jmx
– check_jmx4perl
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
MONITORINGENDPOINTS
BOARDING
Verteilte Nagios/Icinga Umgebung
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
Optionale Services
Service zur Aggregation und Weitergabe an Drittsysteme
– Reportingdatenbank
– Konsolidierungsebene
Service zur Versendung von SMS Nachrichten
RealtimeSLA-Monitoring
Verarbeitung von Logdaten
usw.
INTEGRATIONSBEISPIEL
BOARDING
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
STATUSDATEN
ON TIME
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
<http:connectorname="statusDataSendConnector" keepAlive="false" enableCookies="false"/>
Versenden der Statusdaten
<!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster -->
<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>
<http:outbound-endpointconnector-ref="statusDataSendConnector" address="${statusDataSend.httpUrl}"
path="${statusDataSend.httpPath}" synchronous="false"/>
</exception-based-router>
</outbound>
</service>
</model>
Empfangen der Statusdaten
<!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile -->
<modelname="statusData">
<servicename="statusDataReceive">
<inbound>
<http:inbound-endpointconnector-ref="statusDataReceiveConnector" 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>
Laden der Statusdaten
<!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile -->
<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>
KOMMANDODATEN
ON TIME
Konfiguration der Connectoren
Connector für Ermittlung der Kommandodaten
<jdbc:connectorname="commandDataReadConnector" pollingFrequency="10000" dataSource-
ref="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]
Ermittlung der Kommandodaten
<!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites -->
<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>
Versenden der Kommandodaten
<!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites -->
<modelname=“commandData">
<servicename="commandDataSendSatellite">
<inbound>
<vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/>
</inbound>
<outbound>
<multicasting-router>
<http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector"
address="${commandDataSendSatelliteConnector.httpUrl1}"
path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/>
</multicasting-router>
</outbound>
</service>
</model>
LIVE DEMO
BOARDING
Live Demo
Let‘s Go
FAZIT & AUSBLICK
BOARDING
Vorteile
Integrierte Überwachung und somit Transparenz
Modularität und Wiederverwendbarkeit
Standardisierte Protokolle
Code-Qualität durch Schema-Vorgaben
Transaktionssicherheit und Stabilität
Einfache Erweiterbarkeit
Vorzug gegenüber Individuallösung
<!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites -->
<modelname=“commandData">
<servicename="commandDataSendSatellite">
<inbound>
<vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/>
</inbound>
<outbound>
<multicasting-router>
<http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector"
address="${commandDataSendSatelliteConnector.httpUrl1}"
path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/>
</multicasting-router>
</outbound>
</service>
</model>
<!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites -->
<modelname=“commandData">
<servicename="commandDataSendSatellite">
<inbound>
<vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/>
</inbound>
<outbound>
<multicasting-router>
<http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector"
address="${commandDataSendSatelliteConnector.httpUrl1}"
path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/>
<http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector"
address="${commandDataSendSatelliteConnector.httpUrl2}"
path="${commandDataSendSatelliteConnector.httpPath2}" synchronous="false"/>
</multicasting-router>
</outbound>
</service>
</model>
Vorzug gegenüber Individuallösung
<!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster -->
<modelname="statusData">
<servicename="statusDataSend">
<inbound>
<vm:inbound-endpointpath="statusDataSendVm"/>
</inbound>
<outbound>
<exception-based-router>
<http:outbound-endpointconnector-ref="statusDataSendConnector" address="${statusDataSend.httpUrl}"
path="${statusDataSend.httpPath}" synchronous="false"/>
</exception-based-router>
</outbound>
</service>
</model>
<!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster -->
<modelname="statusData">
<servicename="statusDataSend">
<inbound>
<vm:inbound-endpointpath="statusDataSendVm"/>
</inbound>
<outbound>
<exception-based-router>
<ftp:endpointuser=“user" password=“password" host=“server.localdomain“ path="/ftp/incoming">
<file:filename-wildcard-filterpattern=“*.perf"/>
</ftp:endpoint>
</exception-based-router>
</outbound>
</service>
</model>
Vorzug gegenüber Individuallösung
<!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile -->
<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>
</model>
<!-- ReceiveStatusData on ftp interface and writeit to thefilesystem/commandfile -->
<modelname="statusData">
<servicename="statusDataRead">
<inbound>
<endpointaddress="ftp://user:password@satellite.localdomain/ftp">
<properties>
<propertyname="binary" value="false"/>
<propertyname="pollingFrequency" value="1000"/>
<propertyname="outputPattern" value="#[header:originalFilename]"/>
</properties>
</endpoint>
</inbound>
<outbound>
<pass-through-router>
<vm:outbound-endpointpath="statusDataLoadVm"/>
</pass-through-router>
</outbound>
</service>
</model>
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
FRAGEN UND ANTWORTEN
BOARDING
Fragen und Antworten
Jetzt und Hier
NETWAYS GmbH
Deutschherrnstrasse 15-19
90429 Nürnberg
bernd.erk@netways.de
netways
www.netways.de
blog.netways.de
www.google.de/search?q=netways
www.google.de/search?q=bernd+erk

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2009 | Verteilte Monitoring-Umgebungen unter Verwendung eines ESBs by Bernd Erk

Creasoft - Windows Azure
Creasoft - Windows AzureCreasoft - Windows Azure
Creasoft - Windows Azure
Creasoft AG
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case Helvetia
Splunk
 

Ähnlich wie OSMC 2009 | Verteilte Monitoring-Umgebungen unter Verwendung eines ESBs by Bernd Erk (20)

2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc
 
Pragmatic SOA - Beschränken auf das Wesentliche
Pragmatic SOA - Beschränken auf das WesentlichePragmatic SOA - Beschränken auf das Wesentliche
Pragmatic SOA - Beschränken auf das Wesentliche
 
On the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a ServiceOn the Portability of Applications in Platform as a Service
On the Portability of Applications in Platform as a Service
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
 
Ein blick in die Zukunft von in-STEP BLUE
Ein blick in die Zukunft von in-STEP BLUEEin blick in die Zukunft von in-STEP BLUE
Ein blick in die Zukunft von in-STEP BLUE
 
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDISchlanke Webarchitekturen nicht nur mit JSF 2 und CDI
Schlanke Webarchitekturen nicht nur mit JSF 2 und CDI
 
Sig Middleware Weblogicserver Cluster
Sig Middleware Weblogicserver ClusterSig Middleware Weblogicserver Cluster
Sig Middleware Weblogicserver Cluster
 
SCA und SDO: Konzepte und Design - OPITZ CONSULTING - Maier - Winterberg
SCA und SDO: Konzepte und Design - OPITZ CONSULTING - Maier - WinterbergSCA und SDO: Konzepte und Design - OPITZ CONSULTING - Maier - Winterberg
SCA und SDO: Konzepte und Design - OPITZ CONSULTING - Maier - Winterberg
 
Enterprise APEX
Enterprise APEXEnterprise APEX
Enterprise APEX
 
Top 10 Internet Trends 2000
Top 10 Internet Trends 2000Top 10 Internet Trends 2000
Top 10 Internet Trends 2000
 
Creasoft - Windows Azure
Creasoft - Windows AzureCreasoft - Windows Azure
Creasoft - Windows Azure
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case Helvetia
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case Helvetia
 
SplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use CaseSplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use Case
 
OpenStack – Automatisiertes Bereitstellen von Instanzen
OpenStack – Automatisiertes Bereitstellen von InstanzenOpenStack – Automatisiertes Bereitstellen von Instanzen
OpenStack – Automatisiertes Bereitstellen von Instanzen
 
Effizienter Hardware LifeCycle auf Oracle SPARC M7 Server
Effizienter Hardware LifeCycle auf Oracle SPARC M7 ServerEffizienter Hardware LifeCycle auf Oracle SPARC M7 Server
Effizienter Hardware LifeCycle auf Oracle SPARC M7 Server
 
Migration oai mediator 11g - doag sig soa 2010 - attermeyer
Migration oai mediator 11g - doag sig soa 2010 - attermeyerMigration oai mediator 11g - doag sig soa 2010 - attermeyer
Migration oai mediator 11g - doag sig soa 2010 - attermeyer
 
BASTA Spring 2022 - Top 10 Best-Practices für YAML-Pipelines in Azure DevOps
BASTA Spring 2022 - Top 10 Best-Practices für YAML-Pipelines in Azure DevOpsBASTA Spring 2022 - Top 10 Best-Practices für YAML-Pipelines in Azure DevOps
BASTA Spring 2022 - Top 10 Best-Practices für YAML-Pipelines in Azure DevOps
 
Vorlesung SOA - DIS AG.pptx
Vorlesung SOA - DIS AG.pptxVorlesung SOA - DIS AG.pptx
Vorlesung SOA - DIS AG.pptx
 
Ajax, Comet & Co.
Ajax, Comet & Co.Ajax, Comet & Co.
Ajax, Comet & Co.
 

OSMC 2009 | Verteilte Monitoring-Umgebungen unter Verwendung eines ESBs by Bernd Erk

  • 1. Verteilte Monitoring-Umgebungen unter Verwendung eines Enterprise Service Bus 29.10.2009 – NETWAYS OSMC Referent: Bernd Erk
  • 2. KURZVORSTELLUNG SERVICEORIENTIERTE ARCHITEKTUR EIN ENTERPRISE SERVICE BUS FEATURES MULE ESB MONITORING ENDPOINTS INTEGRATIONSBEISPIEL LIVE DEMO FRAGEN UND ANTWORTEN FAZIT UND AUSBLICK EINSATZ VON JAVA ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME ON TIME 3 SLIDES 3 SLIDES 3 SLIDES 4 SLIDES 10 SLIDES 1 SLIDES 5 SLIDES 1 SLIDES 3 SLIDES 2 SLIDES DESTINATION TIME REMARK Agenda
  • 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 1999 21 festangestellteMitarbeiter Spezialisierung in den Bereichen Open Source Systems Management und Open Source Datacenter Solutions
  • 6. Aktuelles www.netways.org – 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
  • 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 Enterprise Service Bus Dienst A Dienst B ... ... Workflow Workflow ... ...Orchestration Dienste Storage Netzwerk Server ... Monitoring Reporting Ticketing ...Anwendungen Hardware Kommunikation
  • 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 Mail Webservice Monitoring Enterprise Service Bus
  • 14. Routing und Transformation RDBMS Monitoring ApplikationFTP Mail Webservice Enterprise Service Bus Map Textfile
  • 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
  • 19. Community Edition Axis EJB Email File FTP HTTP HTTPS EJB MuleForge.org Hibernate SMS-Versand SFTP Salesforce SAP via SJC IMAP IMAPS JDBC SMTP SOAP TCP UDP XMPP Verfügbare Transports (Auswahl)
  • 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
  • 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.
  • 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
  • 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 <http:connectorname="statusDataSendConnector" keepAlive="false" enableCookies="false"/>
  • 31. Versenden der Statusdaten <!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster --> <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> <http:outbound-endpointconnector-ref="statusDataSendConnector" address="${statusDataSend.httpUrl}" path="${statusDataSend.httpPath}" synchronous="false"/> </exception-based-router> </outbound> </service> </model>
  • 32. Empfangen der Statusdaten <!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile --> <modelname="statusData"> <servicename="statusDataReceive"> <inbound> <http:inbound-endpointconnector-ref="statusDataReceiveConnector" 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 <!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile --> <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>
  • 35. Konfiguration der Connectoren Connector für Ermittlung der Kommandodaten <jdbc:connectorname="commandDataReadConnector" pollingFrequency="10000" dataSource- ref="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 <!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites --> <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 <!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites --> <modelname=“commandData"> <servicename="commandDataSendSatellite"> <inbound> <vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/> </inbound> <outbound> <multicasting-router> <http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector" address="${commandDataSendSatelliteConnector.httpUrl1}" path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/> </multicasting-router> </outbound> </service> </model>
  • 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 <!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites --> <modelname=“commandData"> <servicename="commandDataSendSatellite"> <inbound> <vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/> </inbound> <outbound> <multicasting-router> <http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector" address="${commandDataSendSatelliteConnector.httpUrl1}" path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/> </multicasting-router> </outbound> </service> </model> <!-- ReadCommandDatafromthe (ndo/ido)database and send it to thesatellites --> <modelname=“commandData"> <servicename="commandDataSendSatellite"> <inbound> <vm:inbound-endpointtransformer-refs="CommandToString" path="commandDataSendSatelliteVm"/> </inbound> <outbound> <multicasting-router> <http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector" address="${commandDataSendSatelliteConnector.httpUrl1}" path="${commandDataSendSatelliteConnector.httpPath1}" synchronous="false"/> <http:outbound-endpointconnector-ref="commandDataSendSatelliteConnector" address="${commandDataSendSatelliteConnector.httpUrl2}" path="${commandDataSendSatelliteConnector.httpPath2}" synchronous="false"/> </multicasting-router> </outbound> </service> </model>
  • 43. Vorzug gegenüber Individuallösung <!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster --> <modelname="statusData"> <servicename="statusDataSend"> <inbound> <vm:inbound-endpointpath="statusDataSendVm"/> </inbound> <outbound> <exception-based-router> <http:outbound-endpointconnector-ref="statusDataSendConnector" address="${statusDataSend.httpUrl}" path="${statusDataSend.httpPath}" synchronous="false"/> </exception-based-router> </outbound> </service> </model> <!-- ReadStatusDatafromfilesystem and send it to themonitoringmaster --> <modelname="statusData"> <servicename="statusDataSend"> <inbound> <vm:inbound-endpointpath="statusDataSendVm"/> </inbound> <outbound> <exception-based-router> <ftp:endpointuser=“user" password=“password" host=“server.localdomain“ path="/ftp/incoming"> <file:filename-wildcard-filterpattern=“*.perf"/> </ftp:endpoint> </exception-based-router> </outbound> </service> </model>
  • 44. Vorzug gegenüber Individuallösung <!-- ReceiveStatusData on http interface and writeit to thefilesystem/commandfile --> <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> </model> <!-- ReceiveStatusData on ftp interface and writeit to thefilesystem/commandfile --> <modelname="statusData"> <servicename="statusDataRead"> <inbound> <endpointaddress="ftp://user:password@satellite.localdomain/ftp"> <properties> <propertyname="binary" value="false"/> <propertyname="pollingFrequency" value="1000"/> <propertyname="outputPattern" value="#[header:originalFilename]"/> </properties> </endpoint> </inbound> <outbound> <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
  • 47. Fragen und Antworten Jetzt und Hier NETWAYS GmbH Deutschherrnstrasse 15-19 90429 Nürnberg bernd.erk@netways.de netways www.netways.de blog.netways.de www.google.de/search?q=netways www.google.de/search?q=bernd+erk