Konzepte — RabbitMQ
Architektur
RabbitMQ auf Hikube ist ein verwalteter Messaging-Dienst auf Basis des Protokolls AMQP. Jeder in der Hikube-Konsole erstellte Cluster gehört zu einem Projekt und verbraucht die Quotas dieses Projekts (CPU, Arbeitsspeicher, Speicher).
Terminologie
| Begriff | Beschreibung |
|---|---|
| RabbitMQ-Cluster | Verwaltete RabbitMQ-Instanz, die in der Konsole erstellt und verwaltet wird (Menü DB & Messaging → RabbitMQ). |
| AMQP | Advanced Message Queuing Protocol, von RabbitMQ unterstütztes Standard-Messaging-Protokoll. |
| Exchange | Eingangspunkt der Nachrichten. Leitet die Nachrichten über Bindings an die Queues weiter. |
| Queue | Warteschlange, die Nachrichten speichert, bis ein Consumer sie verarbeitet. |
| Binding | Routing-Regel zwischen einem Exchange und einer Queue (auf Basis eines Routing Keys). |
| Quorum Queue | Queue-Typ, der das Protokoll Raft verwendet, um Nachrichten auf mehrere Knoten zu replizieren. |
| Virtual Host (VHost) | Logischer Namensraum, der Exchanges, Queues und Berechtigungen innerhalb eines Clusters voneinander isoliert. |
| Consumer | Anwendung, die Nachrichten aus einer Queue liest und verarbeitet. |
| Preset | Vordefiniertes CPU-/Arbeitsspeicherprofil, das bei der Erstellung des Clusters gewählt wird. |
| Replicas | Anzahl der RabbitMQ-Knoten des Clusters. Bestimmt den Bereitstellungsmodus. |
Bereitstellungsmodi
Das Feld Number of replicas des Assistenten bietet drei Werte an:
| Wert | Bezeichnung in der Konsole | Modus |
|---|---|---|
| 1 | 1 (Standalone) | Ein einzelner Knoten. Das Datenvolume wird auf Ebene des Plattformspeichers repliziert. |
| 3 | 3 (Max High Availability) | Cluster mit 3 Knoten. Die Replikation der Nachrichten übernimmt RabbitMQ (Quorum Queues). |
| 5 | 5 (Ultra High Availability) | Cluster mit 5 Knoten, toleriert den Verlust von zwei Knoten. |
Der Modus (Standalone oder Cluster) und die Anzahl der Replicas können nach der Erstellung nicht mehr geändert werden: Die Konsole zeigt „The mode cannot be changed after creation“ an. Um den Modus zu wechseln, erstellen Sie einen neuen Cluster.
Routing von Nachrichten
RabbitMQ verwendet ein flexibles Routing-Modell auf Basis von Exchanges und Bindings:
Exchange-Typen
| Typ | Routing |
|---|---|
| direct | Exakter Routing Key |
| topic | Musterabgleich mit Wildcards (*, #) |
| fanout | Broadcast an alle gebundenen Queues |
| headers | Routing auf Basis der Header der Nachricht |
Exchanges, Queues und Bindings werden von Ihren Anwendungen mit einem AMQP-Client erstellt, der mit dem gewünschten VHost verbunden ist. Die Konsole verwaltet den Cluster, die VHosts und die Benutzer, nicht die AMQP-Objekte selbst.
Quorum Queues und Hochverfügbarkeit
Quorum Queues verwenden das Protokoll Raft, um Nachrichten zu replizieren:
- Für jede Queue wird ein Knoten zum Leader gewählt
- Nachrichten werden vor der Bestätigung auf die Follower repliziert
- Fällt der Leader aus, wird automatisch ein Follower befördert
Wählen Sie 3 (Max High Availability) oder 5 (Ultra High Availability) Replicas, um das Raft-Quorum zu gewährleisten, und deklarieren Sie Ihre kritischen Queues als Quorum Queues (Argument x-queue-type: quorum auf Client-Seite).
Virtual Hosts
VHosts isolieren Ressourcen innerhalb eines Clusters:
- Jeder VHost hat eigene Exchanges, Queues und Berechtigungen
- Ein Benutzer kann auf jedem VHost ein anderes Recht haben
- Nützlich, um Umgebungen (Produktion, Staging) oder Anwendungen auf demselben Cluster zu trennen
Der Erstellungsassistent verlangt mindestens einen VHost. Weitere VHosts können anschließend auf der Seite des Clusters hinzugefügt werden (Schaltfläche Add a VHost).
Benutzer und Rechte
Jeder RabbitMQ-Benutzer erhält ein von der Plattform generiertes Passwort, das bei der Erstellung (oder nach einer Rotation) nur einmal angezeigt wird. Seine Rechte werden pro VHost festgelegt:
| Recht in der Konsole | Wirkung |
|---|---|
| Administrator | Lesen, Schreiben und Konfigurieren auf dem VHost |
| Read-only | Nur Lesen auf dem VHost |
| No access | Der Benutzer hat keinen Zugriff auf den VHost |
Ein Benutzer kann pro VHost nur ein Recht haben. Die Rechte lassen sich jederzeit über die Aktion Manage Access ändern.
Ressourcen-Presets
Das Preset legt die CPU- und Arbeitsspeicherressourcen jedes Knotens fest. Die Presets entsprechen den Größen der virtuellen Maschinen der Serien u1, s1 und m1: Ein Preset hat dieselben Ressourcen wie die gleichnamige VM. Maßgeblich ist die im Assistenten angezeigte Liste:
| Preset | CPU | Arbeitsspeicher |
|---|---|---|
u1.medium | 1 | 4Gi |
u1.large | 2 | 8Gi |
u1.xlarge | 4 | 16Gi |
u1.2xlarge | 8 | 32Gi |
u1.4xlarge | 16 | 64Gi |
u1.8xlarge | 32 | 128Gi |
s1.small | 1 | 2Gi |
s1.medium | 2 | 4Gi |
s1.large | 4 | 8Gi |
s1.xlarge | 8 | 16Gi |
s1.2xlarge | 16 | 32Gi |
s1.4xlarge | 32 | 64Gi |
m1.large | 2 | 16Gi |
m1.xlarge | 4 | 32Gi |
m1.2xlarge | 8 | 64Gi |
m1.4xlarge | 16 | 128Gi |
m1.8xlarge | 32 | 256Gi |
Das Preset kann nach der Erstellung nicht mehr geändert werden.
Der Assistent wählt kein Preset vor: Wählen Sie eines aus, um fortzufahren. Jede Option zeigt ihre Ressourcen an, zum Beispiel „u1.medium — 1 CPU / 4Gi“. Kann die Liste nicht geladen werden, zeigt der Assistent „The preset list could not be loaded. Try again later or contact support.“ an.
Ein Cluster, der mit einem früheren Preset (nano, micro, small, medium, large, xlarge oder 2xlarge) erstellt wurde, behält es und läuft wie bisher: Das Formular Edit zeigt es unverändert an und speichert es ohne Änderung. Da das Preset nach der Erstellung nicht geändert werden kann, wenden Sie sich für diese Änderung an den Support. Wurden die Ressourcen eines Clusters abweichend von seinem Preset festgelegt, weist das Formular mit dem Vermerk „(override)“ darauf hin.
Limits
| Parameter | Wert |
|---|---|
| Name des Clusters | 3 bis 16 Zeichen: Kleinbuchstaben, Ziffern und Bindestriche; beginnt mit einem Buchstaben, endet mit einem Buchstaben oder einer Ziffer |
| Angebotene Versionen | 4.2, 4.1, 4.0, 3.13; nach der Erstellung nur Versions-Upgrade |
| Replicas | 1, 3 oder 5 (bei der Erstellung festgelegt) |
| Name des VHosts | Kleinbuchstaben, Ziffern und Bindestriche; beginnt mit einem Buchstaben, endet mit einem Buchstaben oder einer Ziffer |
| Benutzername | 3 bis 16 Zeichen: Kleinbuchstaben, Ziffern und Bindestriche; beginnt mit einem Buchstaben, endet mit einem Buchstaben oder einer Ziffer. Einige Namen, etwa admin oder root, sind reserviert |
| Disk-Größe | 1 bis 4096 GB pro Knoten, im Rahmen der Speicher-Quota des Projekts; nur Vergrößerung möglich |
| Externer Zugriff | Bei der Erstellung oder später aktivierbar |
| AMQP-Port | 5672, ohne TLS |
Weiterführende Informationen
- Übersicht: Vorstellung des Dienstes
- Schnellstart: Ihren ersten Cluster erstellen
- VHosts und Benutzer verwalten