30 Mai 2018

RabbitMQ - Message Oriented Middleware (MOM)

Der Message-Broker RabbitMQ erfreut sich im geschäftlichem Umfeld großer Beliebtheit. Von unseren Kunden wird die Software oft eingesetzt, um Brücken zwischen verschiedenen Systemen, Abteilungen oder Datenpools zu schlagen. Ebenso kann ein Message-Broker wie RabbitMQ genutzt werden, um kurzfristige Lastspitzen aufzunehmen und normalisiert an rückwärtige Systeme weiter zu geben. Dabei ist der Betrieb des in Erlang geschriebenen Message-Brokers für die meisten Systemadministratoren unproblematisch bis unauffällig. Tatsächlich arbeitet das System im Normalbetrieb sehr stabil. Bei einigen unserer Kunden sehe ich Systeme, bei denen die Kernkomponente RabbitMQ weitgehend wartungsfrei arbeitet.

Dies ist auch gut so!

Meist ist ein Message-Broker eine sehr zentrale Komponente einer IT-Landschaft, was dazu führt, dass man eine Downtime an einer solchen Komponente ohne Vorplanung um jeden Preis vermeiden möchte. Eine geplante Downtime einer solchen Komponente erfordert oft Abstimmung mit vielen Abteilungen oder Geschäftsbereichen und ist daher nur mit Aufwand realisierbar.

Basierend auf Erlang/OTP bringt RabbitMQ das Rüstzeug mit, langlebig und stabil zu arbeiten. Durch die Erlang/OTP-Basis ist RabbitMQ auch sehr einfach im Clusterbetrieb nutzbar, was die Verfügbarkeit erhöhen kann. Zum Clusteraufbau benötigt man nicht viel mehr als ein gemeinsames Geheimnis („Shared Secret“) in Form des sog. Erlang-Cookies und sinnvoll konfigurierte Namen der einzelnen Knoten. Es lassen sich Systeme zur Service-Discovery nutzen, aber grundlegend reichen per DNS oder auch Hostdatei auflösbare Namen.

RabbitMQ Konzept

In RabbitMQ sprechen die Produzenten direkt mit einer Exchange. An eine Exchange sind eine oder mehrere Queues angebunden, aus denen wiederum Konsumenten Nachrichten lesen. RabbitMQ als Message-Broker sorgt dafür, dass Nachrichten entsprechend den Vorgaben geroutet werden und auf die Queues verteilt werden. Er stellt sicher, dass keine Nachricht aus einer Queue doppelt konsumiert wird oder persistente Nachrichten in seiner Verantwortung verloren gehen.

Hierbei ist es im Cluster-Betrieb unerheblich, ob die Queue wirklich auf dem Knoten liegt, an den der Produzent oder Konsument angedockt ist. Das interne Routing organisiert dies selbstständig.

RabbitMQ Konzept

Queues können persistent auf einen Datenträger gehalten werden oder ausschließlich „In-Memory“ genutzt werden. Letztere werden naturgemäß durch einen Neustart des RabbitMQ gelöscht. Desgleichen gilt für Inhalte in Queues. Auch diese können vom Produzenten „In-Memory“ oder persistent eingeliefert werden.

Weiterhin lassen sich verschiedene Exchange-Typen konfigurieren, Prioritäten und Time-to-Live-Merkmale einstellen, die die Möglichkeiten des RabbitMQ-Einsatzes weiter erhöhen.

Problemzonen im SysAdmin-Alltag

Soweit ein sinnvolles Sizing bei der Auswahl des Systems zum Betrieb eines RabbitMQ-Knotens beachtet wurde – hier vor allem Arbeitsspeicher für den maximalen zu kompensierenden Message-Stau, gibt es im Betrieb von RabbitMQ nur wenig Pflegearbeiten. Möglicherweise hat der Systemadministrator auch mit der Pflege und Verteilung der Queues usw. im RabbitMQ aus organisatorischen Gründen befasst, dies ist aber grundsätzlich eine Aufgabe der Anwendungsadministration und sehr einsatzspezifisch.

Split-Brain vermeiden

Tatsächlich gibt es im Alltagsbetrieb mit RabbitMQ für den System-Admin nur wenig zu bedenken. Zum einen kann es im Cluster-Betrieb passieren, dass man etwa zu Wartungszwecken einzelne Knoten herunter fahren muss oder dass aufgrund eines Ausfalls eines Knotens oder eines Netzwerkteils die Knoten auseinander gelaufen sind. Richtig konfiguriert, sollte letzteres nicht passieren. Der sinnvollen Cluster-Konfiguration werde ich einen gesonderten Artikel widmen. Hier sollte darauf geachtet werden, nicht das Default-Verhalten bei Netzwerkpartitionierung  („Split-Brain„) zu erlauben, sondern eine sinnvolle Alternative zu wählen, etwa „Pause-Minority“, was eine Quorums-basierte Entscheidung der verbleibenden Netzwerkteile ermöglicht. In einer der kommenden Versionen wird es vermutlich auch eine Raft-Implementierung für Cluster geben.

Upgrades können Probleme bereiten

Ein Problem, das im Alltag tatsächlich irgendwann auftreten wird, ist die Frage nach einem Upgrade von einer Major- oder Minor-Version des RabbitMQ auf eine höhere. Dies ist leider nicht so ohne weiteres möglich und erfordert – vor allem im Clusterbetrieb – Vorarbeit und Planung. Dieses Thema plane ich in einem späteren Blogartikel ausführlich zu behandeln.

Wichtig vorab ist: Upgrades eines Clusters sind nur bei Patchlevel-Änderungen möglich, also beispielsweise von Version 3.7.1 auf Version 3.7.3 o. ä.. Allerdings ist auch hier Vorsicht geboten, es gibt auch bei Patchleveln vereinzelte Versionssprünge, die nicht ohne weiteres im Cluster gemischt werden können. Hinweise hierzu findet man in den Release-Notes, die unbedingt vorher konsultiert werden sollten.

Single-Node-Server können meist problemlos im heruntergefahrenen Zustand mit einem Upgrade auf einen aktuelleren Versionsstand gehoben werden. Allerdings sollten hier die Hinweise in allen Release-Notes zu den betroffenen Major-, Minor- und Patch-Levels gelesen werden. Möglicherweise müssen hier Zwischenschritte eingezogen werden.

Bei allen RabbitMQ-Upgrades ist auch immer zu berücksichtigen, dass man neben dem Message Broker auch die zugehörige Erlang/OTP-Plattform ggf. mit anpassen muss. Bei Patchlevel-Änderungen ist dies nicht zu erwarten.

Was können wir für Sie tun?

Gerne beraten wir Sie zum Konzept Ihres Einsatzes von RabbitMQ und unterstützen Sie bei der Auswahl, ob dieses Tool oder vielleicht andere populäre Open-Source-Systeme wie z.B. Apache Kafka für Sie infrage kommen.

Sollte einmal etwas nicht funktionieren oder Sie brauchen Unterstützung beim Betrieb dieser Komponenten, lassen Sie es uns wissen. Wir freuen uns auf Ihren Anruf.

Hilfestellung: RabbitMQ-CheatSheet

Um dem geneigten Systemadministrator die Arbeit leichter zu machen, habe ich ein sogenanntes CheatSheet für RabbitMQ zusammen gestellt. Diese Arbeit wurde durch einen unserer Kunden unterstützt, der uns freundlicherweise die Freigabe zur Veröffentlichung gegeben hat. Daher finden Sie das aktuelle Exemplar hier zum Herunterladen:

RabbitMQ-CheatSheet als PDF-Datei herunterladen.

Weitere Informationen zu RabbitMQ finden Sie auch hier:

Kategorien: HowTos
Tags: Cluster Message-Broker RabbitMQ

PD

über den Autor

Peter Dreuw

Teamleiter

zur Person

Peter Dreuw arbeitet seit 2016 für die credativ GmbH und ist seit 2017 Teamleiter. Im Rahmen von Kundenaufträgen hat er unter anderem einen Adapter für den Icinga-Director zu Microsoft Azure entwickelt, der als Open-Source-Software verfügbar ist. Ferner beschäftigt er sich intensiv mit Softwarearchitektur und der Kombination von zentralen Komponenten durch Messaging-Systeme. Er ist Linux-Nutzer der ersten Stunden und betreibt Linux-Systeme seit Kernel 0.97.

Beiträge ansehen


Beitrag teilen: