Discontinue DMS Queue Manager end of June 2022

Only Distributed Message Service (DMS) Queue Manager will be discontinued/shut down at the end of June 2022.

What does that mean?

Right now, Distributed Message Service supports two options:

1. DMS Queue Manager with API calls based on shared resources on free of charge basis.
2. Kafka Premium as dedicated resource with additional costs.

Only the free of charge basis will be discontinued.

As an alternative, you can use Kafka Premium instances which use physically isolated computing, storage, and bandwidth resources. You can customize partitions and replicas for Kafka topics in the instances, and configure the network bandwidth as required. The instances can be used right out of the box, taking off the deployment and O&M pressure for you so that you can focus on developing your services.

Migration steps for Kafka Premium

Requirements:

1) Before creating a Kafka premium instance, determine the required bandwidth and storage space based on your service expectations, then proceed to deploy a Kafka Premium instance version 2.3.0. In the Open Telekom Cloud service description you can find detailed information about the corresponding price for each bandwidth option. The DMS Kafka Premium documentation will help you to create an instance and prepare your environment.

2) Create a topic corresponding to the common edition on the Kafka exclusive edition. For more information, please follow the DMS Kakfa Premium documentation. If you need to delete a topic, please follow this information here.

3) Adjusted the usage mode of Kafka exclusive edition for original services. (The Kafka exclusive edition is fully compatible with the open-source Kafka client and supports multiple invoking modes, such as Java, Python, and Go.)

The migration steps are as defined in Figure 1:

Step 1)
Check whether the new Kafka Premium instance configuration and network connection are correct. You can use curl or telnet to check the network connectivity. If any fault is detected, stop the migration.

Step 2)
Verify the configuration and environment on the service side, perform producer migration, and check whether production service logs are normal after producer migration. Check whether messages are written to the topic corresponding to the Kafka exclusive edition. The service logs are normal. No new messages are recorded in the original common queue. Messages are written in the Kafka exclusive topic.

Step 3)
After the producer migration is complete, the consumer service migration is temporarily not performed. The consumer service migration is performed only after the consumer service processes data in the original common queue. You can view the monitoring data of the consumer group in the Cloud Monitoring Alarm (CES) service. If the remaining consumption quantity in the consumer group is 0, the data in the common queue has been processed. In this case, you can migrate the consumer. Otherwise, wait until the remaining consumption quantity is 0.

Send us your feedback!

What can we do better? What works well?

Further information can be found in the RDS area of the Help Center.