VMware baut Tanzu RabbitMQ 1.1 für komplexe Topologien aus

Um Entwicklerinnen und Entwicklern in Cloud-nativen Microservices-Umgebungen eine einfache, automatisierte Möglichkeit zum Bereitstellen und Verwalten von RabbitMQ-Brokern an die Hand zu geben, hat VMware zum Jahresauftakt den Operator Tanzu RabbitMQ for Kubernetes für den Produktiveinsatz freigegeben. Mit dem Update auf Version 1.1 soll die Ereignis- und Nachrichtenverteilung damit auch in komplexeren Topologien erleichtert werden – unter anderem durch konfigurierbare Warnmeldungen und eine Vorschau auf Aktiv-Passiv-Replikation im Disaster-Recovery-Fall.

Kontrolliertes Alarmieren

Nach dem Infrastructure-as-Code-Muster (IaC) erlaubt Tanzu RabbitMQ das Erstellen und Anpassen von komplexen Messaging-Topologien via YAML. Dazu bindet der Kubernetes-Operator die RabbitMQ API in die APIs der Containerorchestrierungsplattform ein. Um etwaige im Betrieb auftretende Probleme im Hinblick auf die Infrastruktur wie auch den Message Broker gezielt nachverfolgen zu können, lassen sich mit Tanzu RabbitMQ 1.1 nun über die in Clustern vorhandenen Prometheus-Endpunkte hinaus auch Alarmdefinitionen nutzen, um den Prometheus Alert Manager (oder vergleichbare Werkzeuge) zu aktivieren. Anwenderinnen und Anwender sollen dadurch Warnungen zeitnah erhalten und anhand ergänzender Informationen die Probleme schneller beheben können.

Nicht spekulieren, sondern kommunizieren

Als Vorsichtsmaßnahme für den Fall, dass Disaster Recovery notwendig wird, behelfen sich laut VMware viele RabbitMQ-Nutzerinnen und -Nutzer mit einem Federated Exchange, bei dem als Backup sämtliche Messages sowohl an einen aktiven Cluster wie auch an einen oder mehrere passive Remote-Cluster gesendet werden. Um dabei ein Überlaufen des Remote-Clusters zu vermeiden, ist eine optimale Time-to-live (TTL) erforderlich, die sich allerdings in der Regel nur anhand von Schätzungen zum Tempo des Nachrichtenkonsums auf der Remote-Seite wählen lässt.

Basierend auf den Funktionen des Schema-Replication-Plug-in will Tanzu RabbitMQ 1.1 nun eine zuverlässigere Datenreplikation gewährleisten, die auch mit unerwarteten Störungen in der Messaging-Kommunikation besser umgehen kann. Der neue Aktiv-Passiv-Ansatz kann Nachrichten auf der Remote-Seite bei Bedarf länger speichern, ohne den Clusterbetrieb zu stören, und teilt der Passiv-Gegenstelle konkret mit, wann die Nachricht gelöscht werden soll. Um dabei das Synchronisieren des Schemas für die Messaging-Topologie und die RBAC-Konfiguration zwischen aktiver und Remote-Seite sicherzustellen, greift Tanzu RabbitMQ allerdings auf ein kommerzielles Plug-in zurück – und die Aktiv-Passiv-Replikationsfunktion bleibt zumindest vorläufig noch eine Preview, die VMware (noch) nicht für den Einsatz in Produktion empfiehlt.

Weitere Details zur Operator-Version 1.1 des AMQP-Message-Brokers (Advanced Message Queuing Protocol) Tanzu RabbitMQ for Kubernetes fasst der Blogbeitrag zusammen.

(map)