Huawei DMS zu STACKIT: Kafka, RabbitMQ und RocketMQ

Drei Broker als Eingabe

Eine kleine Huawei-Cloud-Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet, mit VPC, Subnetz und Security Group um die Broker. Links Kafka und RabbitMQ, rechts RocketMQ. Das Broker-Passwort ist absichtlich eine Variable ohne Wert.

resource "huaweicloud_dms_kafka_instance" "stream" {
  name               = "orders-stream"
  engine_version     = "2.7"
  flavor_id          = "c6.2u4g.cluster"
  storage_spec_code  = "dms.physical.storage.ultra.v2"
  storage_space      = 600
  broker_num         = 3
  vpc_id             = huaweicloud_vpc.main.id
  network_id         = huaweicloud_vpc_subnet.brokers.id
  security_group_id  = huaweicloud_networking_secgroup.brokers.id
  availability_zones = ["eu-west-101a", "eu-west-101b", "eu-west-101c"]
  ssl_enable         = true
  access_user        = "orders"
  password           = var.broker_password
}

resource "huaweicloud_dms_rabbitmq_instance" "jobs" {
  name               = "jobs-queue"
  engine_version     = "3.8.35"
  flavor_id          = "c6.2u4g.cluster"
  storage_spec_code  = "dms.physical.storage.ultra.v2"
  broker_num         = 3
  vpc_id             = huaweicloud_vpc.main.id
  network_id         = huaweicloud_vpc_subnet.brokers.id
  security_group_id  = huaweicloud_networking_secgroup.brokers.id
  availability_zones = ["eu-west-101a", "eu-west-101b", "eu-west-101c"]
  access_user        = "jobs"
  password           = var.broker_password
}

resource "huaweicloud_dms_rocketmq_instance" "billing" {
  name               = "billing-events"
  engine_version     = "4.8.0"
  storage_space      = 300
  vpc_id             = huaweicloud_vpc.main.id
  subnet_id          = huaweicloud_vpc_subnet.brokers.id
  security_group_id  = huaweicloud_networking_secgroup.brokers.id
  availability_zones = ["eu-west-101a"]
  flavor_id          = "c6.4u8g.cluster"
  storage_spec_code  = "dms.physical.storage.high.v2"
  broker_num         = 1
}

Kafka und RabbitMQ, bewertet

Auszüge aus assessment.json, die Werte genau so, wie der Lauf sie geschrieben hat.

{
  "id": "huaweicloud_dms_kafka_instance.stream",
  "result": {
    "class": "CONTAINERIZE",
    "confidence": "MEDIUM",
    "target": {
      "service": "a self-managed Kafka-compatible broker on SKE",
      "resources": [
        "stackit_ske_cluster"
      ]
    },
    "reason": "STACKIT has no managed Kafka service. The broker runs self-managed on SKE, or the messaging design changes to RabbitMQ."
  }
}

{
  "id": "huaweicloud_dms_rabbitmq_instance.jobs",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT RabbitMQ",
      "resources": [
        "stackit_rabbitmq_instance",
        "stackit_rabbitmq_credential"
      ]
    },
    "reason": "DMS for RabbitMQ becomes STACKIT RabbitMQ. Exchanges, queues and credentials are recreated, and messages in flight are drained before cut-over."
  }
}

• Kafka: CONTAINERIZE

  Das Ziel ist ein Kafka-kompatibler Broker, den Sie auf einem SKE-Cluster betreiben. Der Lauf führt 13 Kafka-Einstellungen für Ihre Architekten auf, darunter engine_version, broker_num, flavor_id, ssl_enable und access_user.

• RabbitMQ: REPLATFORM

  Exchanges, Queues und Zugangsdaten werden neu angelegt, und Nachrichten in Bearbeitung werden vor dem Cutover abgearbeitet. Der Lauf führt 11 Einstellungen auf, darunter engine_version, broker_num und den Benutzer.

• Passwörter gelangen nie in den Bericht

  Das Argument password steht als Einstellung nur namentlich in der Liste; ein Wert erscheint in keiner Datei des Laufs.

RocketMQ und die Reihenfolge des Umzugs

Die RocketMQ-Einheit ist REDESIGN mit Konfidenz LOW. Rechts technical-sequencing.md desselben Laufs. Zuerst kommen die Netzwerkeinheiten; die drei Broker teilen sich Welle 3.

{
  "id": "huaweicloud_dms_rocketmq_instance.billing",
  "result": {
    "class": "REDESIGN",
    "confidence": "LOW",
    "target": {
      "service": "STACKIT RabbitMQ",
      "resources": [
        "stackit_rabbitmq_instance",
        "stackit_rabbitmq_credential"
      ]
    },
    "reason": "STACKIT has no RocketMQ service. Ordered and delayed message semantics have to be redesigned for RabbitMQ, or the broker runs self-managed on SKE."
  }
}

## Wave 1 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_networking_secgroup.brokers` | RECONFIGURE / MEDIUM | STACKIT security groups |
| `huaweicloud_vpc.main` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 2 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_vpc_subnet.brokers` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 3 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_dms_kafka_instance.stream` | CONTAINERIZE / MEDIUM | a self-managed Kafka-compatible broker on SKE |
| `huaweicloud_dms_rabbitmq_instance.jobs` | REPLATFORM / MEDIUM | STACKIT RabbitMQ |
| `huaweicloud_dms_rocketmq_instance.billing` | REDESIGN / LOW | STACKIT RabbitMQ |

• Bedingte Machbarkeit

  Der Lauf markiert das RocketMQ-Ziel als bedingt: Der Entwurf übernimmt das Merkmal nicht, und die Verweise auf das Netzwerk stellt eine Person im Redesign wieder her.

• Broker sind keine Dateneinheiten

  Die Datei data-movement des Laufs meldet, dass die Quelle weder Datenbank, Cache, Suchdomäne, Warehouse, Volume, Dateifreigabe noch Object Store enthält; der Stand ist „nicht anwendbar“. Nachrichten in Queues und Topics stehen dort nicht; der Plan zum Abarbeiten oder Replizieren liegt also bei Ihnen.

• Ein Verantwortlicher für die drei Broker

  Die drei Broker bilden ein Arbeitspaket beim Platform Architect; die Netzwerkeinheiten gehen an den Network Architect.

So wird die DMS-Umgebung zugeordnet

Klassen, wie der Lauf sie für sechs Ressourcen in sechs Einheiten entschieden hat. Kafka, RabbitMQ und die Netzwerkeinheiten haben Konfidenz MEDIUM, RocketMQ LOW.

Der Umzug, der Reihe nach

Die Schritte 1 bis 3 sind Vorbereitung, die der Lauf unmittelbar stützt. Die Schritte 4 bis 7 sind allgemeine Praxis je Engine und als solche gekennzeichnet, weil der Lauf keine Nachrichtenübertragung plant.

1. 01

   Variablen liefern und den Lauf wiederholen

   Ohne Wert für broker_password markiert der Lauf die Quelle als VARIABLE_UNRESOLVED (Vollständigkeit PARTIAL) und hält fest, dass unbekannt bleibt, was die Variable liest, bis ein Wert geliefert wird. Geben Sie den Wert in einer Variablendatei mit --var-file an; der Lauf ist dann vollständig.

2. 02

   Ziel je Broker festlegen

   RabbitMQ landet im verwalteten Service. Bei Kafka wählen Sie zwischen Betrieb auf SKE und dem Wechsel zu RabbitMQ. Bei RocketMQ entscheiden Sie zuerst das Redesign, denn es bestimmt, ob RabbitMQ oder SKE das Ziel ist.

3. 03

   Zuerst das Netzwerk

   VPC und Security Group liegen in Welle 1, das Subnetz in Welle 2. Die Broker in Welle 3 brauchen das Netzwerk, an dem sie hängen, und die Clients eine Route dorthin.

4. 04

   RabbitMQ: bauen, dann Definitionen neu anlegen

   Legen Sie die Instanz mit einem Plan an, der Ihrer bisherigen Verfügbarkeit entspricht, setzen Sie die Zugriffsliste, legen Sie Zugangsdaten an und danach Exchanges, Queues und Bindings neu an. RabbitMQ kann Definitionen über seine Management-API exportieren und importieren; das ist allgemeine Praxis. Die STACKIT-Anleitung stellt Queue-Definitionen aus einem Backup einer bestehenden STACKIT-Instanz wieder her und beginnt daher nicht bei DMS.

5. 05

   RabbitMQ: abarbeiten und umstellen

   Stoppen Sie die Producer, lassen Sie die Consumer die Queues leeren und richten Sie dann Producer und Consumer auf den neuen Endpunkt. Die Begründung des Laufs nennt das Abarbeiten der Nachrichten in Bearbeitung vor dem Cutover.

6. 06

   Kafka: aufbauen, replizieren, Consumer umziehen

   Legen Sie den SKE-Cluster an, betreiben Sie den Broker darauf, replizieren Sie die Topics aus DMS (zum Beispiel mit MirrorMaker 2 von Kafka), ziehen Sie die Consumer um, sobald der Lag null ist, danach die Producer. DMS bleibt in Betrieb, bis die letzte Consumer Group umgezogen ist.

7. 07

   RocketMQ: neues Design parallel betreiben

   Ziehen Sie Topic für Topic um, sobald Reihenfolge und Verzögerung im neuen Design geklärt sind, und behalten Sie den alten Broker, bis der letzte Producer umgezogen ist.

Einstellungen, die sich zwischen DMS und STACKIT ändern

Der Lauf benennt die Einstellungen; diese Tabelle gleicht die heiklen davon mit den Seiten der Quellenliste ab.

Quellseite: die Beispieleingabe und die Einstellungen, die der Lauf benennt. Zielseite: die STACKIT-Seiten zu RabbitMQ-Plänen, Lifecycle, Instanzzugriff und Migration aus der Quellenliste.

Die fehlende Variable liefern

Der erste Lauf hatte keinen Wert für broker_password. Der zweite Lauf ergänzte --var-file mit einem Platzhalterwert. Links der erste Lauf, rechts der zweite.

  Source completeness: PARTIAL (source status VARIABLE_UNRESOLVED)

  Source completeness: COMPLETE (source status COMPLETE)

• Anfragen, die den Entwurf blockieren

  Die Zeile „Decisions“ des ersten Laufs meldet 6 offene Anfragen, davon 2 blockierend. Der zweite meldet 5, davon 1 blockierend: Die fehlende Variable zählt nicht mehr; die Frage nach der Region bleibt.

• Warum das zählt

  Eine Quelle mit unaufgelösten Variablen wird als teilweise bewertet. Füllen Sie sie, bevor Sie sich auf Klasse und Einstellungen der Einheiten verlassen, die sie lesen.

Entscheidungen der Architekten

• Kafka: betreiben oder verlassen

  Selbst betrieben auf SKE heißt: Ihr Team betreibt Broker, Speicher und Upgrades. SKE selbst übernimmt die Updates von Kubernetes und Betriebssystem. Bei einfachen Queues kann RabbitMQ die kleinere Designänderung sein.

• STACKIT Intake ist nicht die Kafka-Antwort

  STACKIT Intake nimmt Streaming-Daten über das Apache-Kafka-Protokoll an und schreibt sie in Apache-Iceberg-Tabellen im Dremio-Katalog. Die Übersicht beschreibt weder Topics noch Consumer Groups, aus denen Anwendungen lesen. Intake passt daher zu Datenströmen, die in der Analyse enden, und ist kein Broker, aus dem Services konsumieren.

• RocketMQ-Semantik

  Listen Sie jedes Topic auf, das von Reihenfolge oder Verzögerung abhängt, und entscheiden Sie vor jedem Umzug, was sie ersetzt.

• Nachrichten beim Cutover

  Abarbeiten, replizieren oder den Verlust von Nachrichten in Bearbeitung akzeptieren, je Queue und je Topic.

Fragen von Messaging-Teams

Quellen

• STACKIT-Dokumentation: Service-Pläne von RabbitMQ
• STACKIT-Dokumentation: Lebenszyklus von RabbitMQ
• STACKIT-Dokumentation: RabbitMQ-Instanzen anlegen und verwalten
• STACKIT-Dokumentation: RabbitMQ-Daten in eine neue Instanz migrieren
• STACKIT-Dokumentation: Kubernetes Engine
• STACKIT-Dokumentation: Intake