RabbitMQ-Architektur

STACKIT RabbitMQ basiert auf einer verwalteten RabbitMQ-Plattform und bietet eine robuste und skalierbare Message-Broker-Lösung für Ihre Anwendungen.

Kernkomponenten

RabbitMQ Message Broker

RabbitMQ dient als zentraler Message Broker und ermöglicht die asynchrone Kommunikation zwischen Anwendungen und Diensten. Er unterstützt mehrere Messaging-Protokolle und -Muster, einschließlich Publish/Subscribe, Request/Reply und Point-to-Point-Messaging. Der Broker übernimmt das Message-Routing, die Warteschlangenverwaltung (Queuing) und die Zustellung, wodurch eine zuverlässige Nachrichtenverarbeitung in verteilten Systemen gewährleistet wird.

Management-Schnittstelle

Die RabbitMQ-Management-Schnittstelle bietet eine webbasierte Benutzeroberfläche für das Monitoring und die Verwaltung Ihres Message Brokers. Sie ermöglicht es Ihnen, Queues, Exchanges, Bindings und Nachrichtenraten einzusehen sowie Benutzer und Berechtigungen zu verwalten.

Plugin-System

RabbitMQ unterstützt verschiedene Plugins, die seine Funktionalität erweitern, darunter Plugins für Federation, Shovel, MQTT, STOMP und Consistent-Hash-Exchange. Diese können basierend auf Ihren spezifischen Anforderungen an den Anwendungsfall aktiviert und konfiguriert werden.

Infrastruktur-Architektur

Isolation der Service-Instanzen

Jede RabbitMQ-Service-Instanz läuft auf dedizierten virtuellen Maschinen in der STACKIT Compute Engine. Dies gewährleistet die Isolation von anderen Diensten und schützt vor Ressourcenkonflikten (Bad-Neighborhood-Schutz).

Trennung des Deployments

RabbitMQ-Dienste, die über STACKIT Cloud Foundry erstellt wurden, und solche, die über das STACKIT Portal oder die STACKIT CLI erstellt wurden, sind vollständig voneinander getrennt. Dienste, die in einer Umgebung erstellt wurden, müssen in derselben Umgebung verwaltet und gelöscht werden – eine umgebungsübergreifende Verwaltung wird aus technischen Gründen nicht unterstützt.

Dienste müssen immer in der Umgebung verwaltet werden, in der sie erstellt wurden.

• Dienste, die im STACKIT Portal oder über die CLI erstellt wurden, müssen auch im STACKIT Portal oder über die CLI verwaltet/gelöscht werden. Im STACKIT Portal werden möglicherweise einige (nicht alle) Dienste angezeigt, die mit Cloud Foundry erstellt wurden (insbesondere die Flex-Datenbanken).
• Dienste, die mit Cloud Foundry erstellt wurden, müssen mit Cloud Foundry verwaltet/gelöscht werden.

Dienste, die in Cloud Foundry als Teil einer Organisation mit dem Präfix stackit_portal_prod_ angezeigt werden, wurden über das STACKIT Portal oder die CLI erstellt und müssen von dort aus verwaltet werden, selbst wenn Verwaltungsoptionen in Cloud Foundry angezeigt werden. Aus technischen Gründen ist es nicht möglich, einen Dienst in Cloud Foundry zu erstellen und ihn über das STACKIT Portal oder die CLI zu löschen oder umgekehrt.

Single Node vs. Cluster

Single Node

• Läuft auf einem einzelnen Knoten
• Geeignet für Entwicklung und Tests
• Nicht für den Produktionseinsatz empfohlen

Cluster (Replica Set)

• Besteht aus 3 Knoten, die über mehrere Verfügbarkeitszonen verteilt sind
• Bietet Hochverfügbarkeit und Fehlertoleranz
• Empfohlen für Produktions-Workloads
• Gewährleistet die Dienstkontinuität, selbst wenn ein Knoten oder eine Verfügbarkeitszone ausfällt
• Automatische Wiederherstellung im Falle von Hardware- oder Rechenzentrumsausfällen

Netzwerkzugriff

RabbitMQ-Instanzen sind über Public IP-Adressen erreichbar, was die Integration ermöglicht mit:

• Cloud Foundry-Anwendungen
• Kubernetes-Workloads
• Virtuellen Maschinen
• Externen Systemen

Der Zugriff wird durch Zugriffssteuerungslisten (ACLs) und Authentifizierung auf Instanzebene gesichert. Alle Verbindungen unterstützen eine SSL/TLS-Verschlüsselung mit aktuellem TLS v1.3 für erhöhte Sicherheit.

Datenmanagement

Backup-System

Der integrierte Backup-Manager erstellt automatisch alle 4 Stunden vollständige Sicherungen und bewahrt diese für 14 Tage auf. Sie können auch manuelle Sicherungen auslösen und über das Service-Dashboard Wiederherstellungen aus vorhandenen Sicherungen durchführen.

Skalierbarkeit

RabbitMQ nutzt ein T-Shirt-Größenmodell mit vordefinierten Service-Plans. Wenn Ihr Workload wächst, können Sie auf einen größeren Plan mit mehr Ressourcen (vCPU, RAM, Speicherplatz) herabstufen oder heraufstufen. Alle Instanzen nutzen Hochleistungs-SSD-Speicher für optimale Performance.

Monitoring und Observability

Jeder bestellte Dienst kann über einen Observability-Dienst überwacht werden. Um das Monitoring für Ihre RabbitMQ-Instanz zu aktivieren, müssen Sie bei der Bereitstellung oder über ein Update Ihre Observability-Instanz-ID (monitoring_instance_id) angeben und den Parameter enable_monitoring auf true setzen.

Stellen Sie sicher, dass Sie einen unterstützten Plan verwenden: Ihre STACKIT Observability-Instanz muss über einen Plan mit ausreichender Kapazität zum Speichern von Metriken verfügen. Für eine detaillierte Liste der unterstützten Pläne prüfen Sie die RabbitMQ-FAQ und klappen Sie die Frage „Welcher STACKIT Observability-Plan ist für die RabbitMQ-Integration erforderlich?” auf.

Nach der Anwendung verwendet der Service Broker die Observability-API, um die Instanz zu registrieren. Der Wrapper erstellt technische Zugangsdaten (sichtbar als Service Key mit einem monitoring_-Präfix), die ausschließlich von Observability für das Monitoring verwendet werden. Die Verbindungs-URL wird sicher an die Observability-Instanz übertragen.

Aufseiten von Observability verwendet Telegraf diese Zugangsdaten, um sicher auf Ihre Datenbank zuzugreifen und die Metriken abzurufen. Sie können dann Metriken mit dem Präfix des entsprechenden Dienstes aus Ihrer Thanos-Quelle direkt im Grafana-Dashboard Ihrer Observability-Instanz einsehen.