12 – 16 September discussed document management systems, flexible downtimes, and introduced a distributed computing tool as well as the program to the upcoming OSMC.
Gunnar took a look at distributed computing using ZeroMQ. A C++ library with various messaging functions, ZeroMQ is usesful in scaling applications, by distributing it over multiple systems. One central component breaks down large tasks into smaller component tasks and transmits them to worker processes. It also compiles the results of the worker processes to form a whole again. In contrast to traditional multi-thread applications, no locks are needed as the individual worker processes have no common condition and they can be distributed across machines, making it scalable without bounds. Gunnar gave an example implementation and some tips to avoid common problems such as work units sizes and operating system independent message formats.
From our Managed Services team, Georg trialled document management systems and named Alfresco Community as his top pick. Between Microsoft Sharepoint 2010’s easy installation yet cluttered feature and settings, and Agorum Core Pro’s complicated installation, Alfresco Community won hands down. With easy installation and a good range of features; Alfresco can also be linked to an Active Directory server for larger organisations.
Lennart then explained flexible downtimes. As opposed to fixed downtimes, the start of a flexible downtime begins at the point a host or service changes status. Taking a host in Icinga for example, the start time and end time can be chosen to have a minimum duration of 10 minutes. Within this time frame the host will be restarted, but taking into account the reboot duration, downtime could extend over the 10 minutes set.
Last but not least, Pamela announced the Open Source Monitoring Conference 2011 program. Two tracks of presentations over two days in English and German, should offer plenty for attendees to chat about. For those who want to pack in more, 3 intensive workshops on the conference eve are also on offer. But register quick, as Europe’s leading event on open source monitoring has been known to sell out.
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
