Seite wählen

NETWAYS Blog

Distributed Computing mit ZeroMQ

ZeroMQ ist eine in C++ geschriebene Library, die verschiedene Messaging-Funktionen anbietet, darunter z.B. Verteilung von Meldungen an mehrere Clients mit Loadbalancing (analog zu Anycast bei IP). Dies kann verwendet werden, um Anwendungen auf mehrere Systeme zu verteilen und so zu skalieren. Dabei wird die Anwendung grundsätzlich in zwei Komponenten getrennt:

  • Eine zentral laufende Komponente ist dafür zuständig, eine größere Aufgabe in kleinere Arbeitseinheiten aufzuteilen und diese an Worker-Prozesse zu vermitteln. Am Ende muss diese Komponente die gesammelten Resultate der Workerprozesse zu einem Gesamtergebnis zusammenzufassen.
  • Die zweite Komponente sind die Worker-Prozesse, von denen es beliebig viele geben kann. Ihre Aufgabe ist es, Arbeitseinheiten zu berechnen und das Ergebnis an die zentrale Komponente zurückzuliefern.

Der Vorteil dieses Konzepts gegenüber traditionellen Multi-Thread-Anwendungen ist, dass keinerlei Locks notwendig sind, da die einzelnen Worker-Prozesse keinen gemeinsamen Zustand besitzen. Außerdem können Worker-Prozesse auch über Rechnergrenzen hinweg verteilt werden und die Anwendung so theoretisch beliebig skaliert werden.
In der Beispielanwendung (die einen Teil des Mandelbrot-Sets berechnet) werden zwei ZeroMQ-Sockets verwendet: einer zum Verteilen der Aufgaben und ein weiterer zum Einsammeln der Ergebnisse. Die „render“-Anwendung zerteilt dabei ein 12800×12800 Pixel großes Bild in Segmente zu jeweils 320×320 Pixeln, die dann an einen oder mehrere „render-worker“-Prozesse zum Rendern verteilt werden. Im Anschluss werden die Ergebnis-Segmente zusammengefügt und das fertig gerenderte Bild als PNM-Datei ausgegeben.
Die Berechnungen skalieren dabei fast linear mit der Anzahl der verwendeten CPU-Cores:

In der Praxis gibt es jedoch einige Stolperfallen, die vor der Implementation eines solchen Systems bedacht werden müssen:

  • Größe der Arbeitseinheiten: sind sie zu klein, gibt es Overhead durch die Vielzahl an Messages (Netzwerkbandbreite, CPU-Zeit); wenn sie zu groß sind, geht evtl. viel Arbeit verloren, wenn eines der Systeme sein Ergebnis aus irgendeinem Grund nicht abliefern kann
  • bleibt für eine Arbeitseinheit das Ergebnis aus, muss sie evtl. an ein anderes System erneut verteilt werden
  • Das Zusammenfassen der Arbeitseinheiten läuft in einem einzelnen Thread ab und skaliert daher nicht
  • Das Format der Messages sollte betriebssystemunabhängig sein; zu beachten ist hier Little Endian vs. Big Endian und Unterschiede zwischen Compilern (z.B. wie structs im Speicher angeordet werden); idealerweise wird hier auf ein Standard-Format wie z.B. JSON zurückgegriffen

Systems Management Bus auf Basis von Mule ESB

Ein halbes Jahr nach der letzten Open Source Monitoring Conference steht nun endlich die erste Version unseres Systems Management Bus zur Verfügung. Seit der Vorstellung des Themas unter dem Namen „Verteilte Umgebungen unter Verwendung eines ESBs“ ist viel Zeit vergangen und unsere Implementierung konnte in vielen Projekten erfolgreich eingesetzt werden. Dabei konnten wir einige offene Fragen lösen, welche sich im Rahmen der Implementierungen ergeben hatten.
Bereits vor einigen Wochen hatten wir über eine Implementierung in einer verteilten Umgebung berichtet, welche global verteilte Nagios-Instanzen verbindet. Auf netways.org gibt es neben der aktuellen Version bestehend aus Bibliotheken, Javadoc und Mule-Configs auch eine ausführliche Installationsanleitung. In der ersten Version können sowohl Status- und Performancedaten von einem oder mehreren verteilten Systemen an den Master gesendet oder auch Kommandos an die angebundenen Satelliten übermittelt werden. Darüber hinaus ist nun auch ein Failover-Service implementiert, der die vollständige Übermittlung nach einem Ausfall sicherstellt.
Auf der Website von Mule finden sich neben der aktuell implementierten HTTP-Übertragung auch andere Wege zur Übertragung, was Mule zu einer mächtigen und flexiblen Lösungsplattform macht.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

OSMC Ticker: Verwendung eines ESB zum verteilten Monitoring

Gerade startet unser Kollege Bernd Erk mit seiner Präsentation Verteilte Monitoring-Umgebungen unter Verwendung eines Enterprise Service Bus (ESB). In der Einführung zum Thema stellt er die wichtigsten Konzepte und Definitionen eines ESB vor, wie sich der Bus in eine Service Orientierte Architektur (SOA) einfügt und vor allem welchen Sinn ein solcher Bus in einer Monitoring Architektur machen kann: Aktuell haben viele verteilte Monitoringumgebungen das Problem, dass eine Vielzahl von Daten, beispielsweise Checkresults zwischen verschiedenen Servern verschoben und vielleicht sogar transformiert werden müssen. Dazu kommen in der Regel oft selbstgeschriebene Scripte zu Einsatz, die zwar schnell erstellt werden können, aber langfristig in einem Wildwuchs enden und vor allem schwer zu debuggen sind. So kann man mit NSCA beispielsweise nicht sicherstellen, dass ein abgesendetes Checkresult auch wirklich am Masterserver angekommen ist.
Mit einem ESB, wie beispielsweise Mule lässt sich dieses Problem elegant lösen, den dort existieren bereits fertige Transports, Router und Transformationen, die genau diese Aufgaben zentralisiert in einer Anwendung durchführen. Dennoch ist für den ESB keine komplizierte Java Programmierung notwendig, denn alle Einstellungen lassen sich sehr einfach in XML Definitionen konfigurieren und sogar automatisiert verteilen. Die entsprechenden Konfigurationseinstellungen um External Commands zu verteilen und Performancedaten zurückzusenden, stellt er kurz vor und zeigt die entsprechenden Aktionen anschliessend in einer Live Demo.
Gegenüber selbstgeschriebenen Scripten bietet der ESB eine wesentlich bessere Erweiterbarkeit und vor allem Transaktionssicherheit. Denn alle Aktionen innerhalb des ESB lassen sich überwachen und werden gespoolt, so dass beispielsweise bei unterbrochener Kommunikation alle Nachrichten vom ESB gecacht und später nachgeführt werden. So stellt der ESB sicher, dass keine zu übertragenden Daten verloren gehen. Natürlich lässt sich auch der ESB selbst wieder gut überwachen. Gerade in großen Umgebungen kann der ESB so auch innerhalb des Monitorings oder des Netzwerkmanagements sinnvoll eingesetzt werden.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.

Mule – Enterprise Service Bus

Mule ist ein auf Java basierender Open-Source Enterprise Service Bus, welcher mit Hilfe von verschiedenen Adaptern, den so genannten Transports verschiedene Applikationen mit verschiedenen Formaten miteinander verbinden kann.
Die eigentliche Übertragung der Daten ist für Nutzer des ESB’s vollkommen transparent, egal ob der Zielrechner nebenan oder auf einem andern Kontinent zu finden ist. Mule kümmert sich um das Routing, die Filterung, Transformation und gesicherte Zustellung von Messages.
Im Gegensatz zu klassichen ESB’s ist es bei Mule nicht grundsätzlich erforderlich alle Nachrichten in ein einheitliches Format zu konvertieren, da Mule die Weiterleitung in nahezu allen gängigen Formaten quasi out of the box unterstützt.

Print

Das Beispiel zeigt einen möglichen Workflow von Monitoringdaten, welche über einen HTTP-Transport entgegengenommen und weiterverarbeitet werden. In großen Systemmanagement-Umgebungen eröffnet Mule Möglichkeiten zur Integration und Weiterleitung von Konfigurations-, Kommando-, Event- und Performancedaten oder die Transformation in unstrukturierte Formate wie z.B. Mail.

Die Technik und die Vielzahl an Möglichkeiten machen den Einstieg in diesen Technologieteil etwas schwierig, jedoch eröffnen sich dem Nutzer nach kurzer Zeit viele Potentiale um Daten direkt und heterogen zu verarbeiten.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

OSMB Ticker: Enterprise Service Bus auf OSMB

Ich bin gerade im Vortrag „Integrierte OS-Geschäftsanwendungen via ESB“. Herr Xylander von der Firma ObjectCode GmbH referiert über die Integrationsmöglichkeiten verschiedener Open-Source-Plattformen auf Basis des JBOSS-ESB.

Konkret geht es um die Integration von SugarCRM, Alfresco und Adempiere (einem freien Compiere-Fork) über verschiedene Service-Schnittstellen unter Verwendung eines zentralen Schlüsselverzeichnisses zur eindeutigen Identifizierung von Business-Objects.
Ergebnis der bisherigen Arbeit ist ein Open Source Projekt, welches Interessenten die Möglichkeit zur Mitarbeit und Integration bietet.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.