ApsaraMQ for RocketMQ:Migrer un cluster RocketMQ auto-géré vers ApsaraMQ for RocketMQ

La figure suivante illustre le processus de migration d'un cluster RocketMQ open source vers ApsaraMQ for RocketMQ.

Avant la migration, effectuez une évaluation technique et définissez le périmètre de migration en fonction de vos besoins métier. Cela vous permettra de réaliser la migration vers le cloud par lots.

• Évaluation technique : Elle vous aide à déterminer si le client et l'environnement de votre cluster RocketMQ auto-géré répondent aux exigences de migration et clarifie la prise en charge des fonctionnalités avant et après la migration.

• Confirmation du périmètre de migration : Nous recommandons d'effectuer la migration par lots, en fonction de la priorité métier et du couplage des applications. Une fois qu'un lot est stable, vous pouvez élargir le périmètre de migration et achever progressivement l'intégralité de la tâche de migration.

Évaluation technique

• Assurez-vous que votre cluster RocketMQ auto-géré source répond aux exigences suivantes. Si ce n'est pas le cas, soumettez un ticket pour obtenir une solution.

  Exigence	Description
  Version de déploiement	Les versions de serveur Apache RocketMQ 5.x et 4.x sont prises en charge.
  Exigences réseau	Le cluster source doit être déployé dans un environnement VPC Alibaba Cloud. S'il est déployé dans un centre de données sur site, il doit être accessible depuis une adresse privée VPC.
  Régions prises en charge	La fonctionnalité Migration to Cloud est disponible uniquement dans les régions suivantes : Chine (Hangzhou), Chine (Shanghai), Chine (Pékin), Chine (Shenzhen), Chine (Zhangjiakou), Chine (Hong Kong), États-Unis (Silicon Valley), Singapour et Japon (Tokyo).
  Contraintes de paramètres	Taille des messages : Maximum : 4 Mo. Durée de conservation des messages : Minimum : 24 heures. Maximum : 720 heures. Délai maximal pour les messages planifiés : Les instances Standard Edition en abonnement et paiement à l'utilisation, ainsi que les instances Serverless Standard et Professional Edition, prennent en charge un délai maximal de 7 jours. Les instances Professional Edition et Platinum Edition en abonnement et paiement à l'utilisation prennent en charge un délai maximal de 40 jours. Pour plus d'informations sur les contraintes de paramètres, consultez les quotas et limites.

• Exigences relatives à la version du SDK : La solution de migration est conçue pour minimiser les modifications. Dans la plupart des cas, vous pouvez directement mettre à niveau la version du SDK client. Étant donné qu'un changement de version majeure inclut généralement de nouvelles fonctionnalités et des optimisations de stabilité, nous vous recommandons de mettre à niveau la version du SDK lors de la migration.

  SDK	Langage	Version	Mise à niveau nécessaire ?
  Apache RocketMQ Remoting SDK Le code suivant fournit un exemple de dépendance Maven pour le SDK Java : <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>{version}</version> </dependency> L'endpoint est configuré au format suivant : producer.setNamesrvAddr("xxx:9876"); consumer.setNamesrvAddr("xxx:9876");	Java	SDK 5.x	Compatible par défaut. Aucune mise à niveau n'est nécessaire.
  	Java, C++	SDK 4.x	Si votre cluster source utilise l'interface PullConsumer, DefaultLitePullConsumer ou DefaultPullConsumer, vous devez effectuer une mise à niveau vers un SDK de la série 5.x. Pour plus d'informations, consultez la présentation de la référence SDK.

  Remarque

  Si vous utilisez le connecteur Flink pour RocketMQ afin d'envoyer et de recevoir des messages, nous vous recommandons de compiler et d'utiliser la dernière version du SDK pour la migration. Pour plus d'informations, consultez rocketmq-flink.

Périmètre de migration

ApsaraMQ for RocketMQ prend en charge la migration au niveau des topics, ce qui permet des déploiements progressifs et canaris avec des capacités de rollback. Cette approche réduit efficacement les risques liés aux modifications à grande échelle.

Notes d'utilisation

• Avec le principe du moindre privilège, l'outil de migration d'ApsaraMQ for RocketMQ accède uniquement aux informations suivantes du cluster auto-géré source :

  • Configurations des métadonnées des topics

  • Configurations des métadonnées des groupes

  • Informations d'enregistrement des routes dynamiques des topics

  • Informations de connexion des consommateurs et statut de l'accumulation des messages

  L'outil de migration n'accède à aucune autre information du cluster source et n'effectue aucune opération d'écriture sur ses configurations. Cela garantit que l'outil de migration n'affecte pas le fonctionnement de votre cluster auto-géré source.

• Après avoir configuré les informations réseau, vérifiez attentivement leur exactitude avant de continuer. Une fois que vous avez poursuivi, vous ne pouvez plus modifier les paramètres réseau. Pour apporter des modifications, vous devez créer une nouvelle tâche.

Procédure

1. Connectez-vous à la console ApsaraMQ for RocketMQ.

2. Dans la barre de navigation supérieure, sélectionnez la région où se trouvent le cluster source et l'instance ApsaraMQ for RocketMQ de destination. Dans le volet de navigation de gauche, choisissez RocketMQ Copilot > Migration to Cloud.

3. Sur la page Migration to Cloud, cliquez sur Create Task.

4. Dans le panneau Create Migration Task, configurez les paramètres et cliquez sur OK.

   Pour plus d'informations sur les paramètres, consultez les Paramètres réseau du cluster source.

5. Sur la page Network Settings de l'assistant Migration to Cloud, saisissez les informations réseau du cluster RocketMQ auto-géré source et cliquez sur Configure Network.

   Pour plus d'informations sur les paramètres, consultez les Paramètres réseau du cluster source.

6. Attendez la fin de la configuration. Lorsque la page indique que la configuration est terminée, cliquez sur Next.

Paramètres

Remarques sur l'utilisation

• Lors de la migration des métadonnées, l'outil de migration ApsaraMQ for RocketMQ lit et affiche dynamiquement tous les topics et groupes du cluster auto-géré source. Sélectionnez uniquement les topics et les groupes pertinents pour la tâche de migration actuelle.

• Cette étape est irréversible. Assurez-vous d'avoir migré tous les topics et groupes inclus dans le périmètre de migration actuel avant de passer à l'étape suivante. Dans le cas contraire, vous devrez ajouter manuellement les topics manquants ultérieurement.

Procédure

1. Sur la page Metadata Migration de l'assistant de migration, cliquez sur l'onglet Topic Metadata.

2. Dans la liste des topics, sélectionnez ceux que vous souhaitez migrer, choisissez le type de message correspondant dans la liste déroulante Message Type, puis cliquez sur Confirm and Import dans la colonne Actions.

   Vous pouvez également sélectionner plusieurs topics et cliquer sur Batch Import.

   Important

   Apache RocketMQ open source 4.x ne prend pas en charge la notion de types de messages. ApsaraMQ for RocketMQ valide la cohérence entre le type de message configuré pour un topic et le type de message réel. Par conséquent, lors de la migration des métadonnées, vous devez saisir manuellement le type de message du topic en fonction de votre scénario métier.

   Si vous sélectionnez un type de message incorrect, la production et la consommation de messages échoueront après la migration. Si vous n'êtes pas certain du type de message du topic ou si un topic est utilisé pour des types de messages mixtes, soumettez un ticket pour obtenir de l'aide.

3. Cliquez sur l'onglet Group Metadata. Dans la liste des groupes, sélectionnez ceux que vous souhaitez migrer, choisissez l'ordre de livraison pour la consommation des messages dans la liste déroulante Consumption Order, puis cliquez sur Confirm and Import dans la colonne Actions.

   Vous pouvez également sélectionner plusieurs groupes et cliquer sur Batch Import.

   Important

   Dans les SDK Apache RocketMQ open source de la série 4.x, l'ordre de consommation des messages est configuré côté client. Dans les instances ApsaraMQ for RocketMQ 5.x, l'ordre de consommation d'un groupe est contrôlé côté serveur. Par conséquent, lors de la migration des métadonnées, vous devez saisir manuellement le type d'ordre de consommation du groupe en fonction de votre scénario métier.

   Si vous sélectionnez un type d'ordre de consommation incorrect, l'ordre de consommation des messages risque d'être erroné après la migration. Si vous n'êtes pas certain de l'ordre de consommation du groupe, soumettez un ticket pour obtenir de l'aide.

4. Après avoir confirmé que tous les topics et groupes de cette tâche de migration ont été importés, cliquez sur Next.

Remarques sur l'utilisation

• Après avoir modifié l'endpoint, redémarrez les applications productrices et consommatrices. Bien que cette étape connecte les applications de messagerie à l'instance ApsaraMQ for RocketMQ de destination, le backend de l'outil de migration continue de router le trafic du topic vers le cluster auto-géré source. Par conséquent, les liens de messagerie restent inchangés à ce stade. Vous pouvez basculer les applications de messagerie dans n'importe quel ordre.

• Assurez-vous que toutes les applications productrices et consommatrices impliquées dans cette migration ont modifié leurs endpoints avant de passer à l'étape suivante.

Exemple de modifications d'endpoint

Pour le SDK utilisant le protocole Apache RocketMQ Remoting, effectuez les configurations suivantes en fonction de la version du SDK :

• Avant la modification :

  producer.setNamesrvAddr("192.168.XX.XX:9876");
    
  consumer.setNamesrvAddr("192.168.XX.XX:9876");

• Après la modification :

  Version du SDK >= 4.5.1

  producer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
  // The default value of vipChannelEnabled is false. If you have set it to true, you must remove this configuration.
  // producer.setVipChannelEnabled(false);
    
  consumer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
  // The default value of vipChannelEnabled is false. If you have set it to true, you must remove this configuration.
  // consumer.setVipChannelEnabled(false);

  Version du SDK < 4.5.1

  producer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
  // The default value of vipChannelEnabled is true. You must set it to false.
  producer.setVipChannelEnabled(false);
    
  consumer.setNamesrvAddr("rmq-cn-pe334******-vpc.cn-hangzhou.rmq.aliyuncs.com:8080");
  // The default value of vipChannelEnabled is true. You must set it to false.
  consumer.setVipChannelEnabled(false);

Procédure

Remarques sur l'utilisation

• Lorsque vous effectuez une opération de basculement de trafic, surveillez la production et la consommation de messages pour vous assurer qu'elles correspondent aux attentes après chaque changement d'état du topic. Si aucune anomalie n'est détectée, poursuivez avec l'opération de basculement suivante. En cas d'anomalie, vous pouvez immédiatement annuler l'opération. Après avoir identifié et résolu la cause de l'anomalie, vous pouvez reprendre l'opération de basculement de trafic.

• Assurez-vous que le basculement de trafic est terminé pour tous les topics inclus dans le périmètre de la tâche de migration et que l'envoi et la réception de messages sont stables, sans aucune anomalie, avant de finaliser la tâche de migration. Une tâche de migration ne peut pas être modifiée une fois terminée.

Étapes du basculement de trafic

Basculement de trafic

1. Sur la page Message Migration de l'assistant de migration, sélectionnez le topic que vous souhaitez migrer et vérifiez son statut de validation.

   • Si le statut est Check Passed, passez à l'étape suivante.

   • Si le statut n'est pas Check Passed, résolvez le problème. Cliquez sur Re-verify dans la colonne Actions jusqu'à ce que la validation réussisse, puis passez à l'étape suivante.

     Pour connaître les validations effectuées à chaque étape du basculement de trafic, consultez la section Validations.

   • Si le statut n'est pas Check Passed mais que vous confirmez que le résultat de la validation n'est pas bloquant, cliquez sur Ignore Check dans la colonne Actions pour le topic spécifié, puis passez à l'étape suivante.

2. Dans la colonne Actions du topic à basculer, cliquez sur Switch Traffic.

3. Dans la boîte de dialogue qui s'affiche, lisez attentivement l'invite et cliquez sur OK.

   Le processus de basculement de trafic comporte quatre étapes. Vous devez effectuer l'opération de basculement pour chaque étape jusqu'à ce que l'Traffic Switching Stage du topic devienne Read and Write in Destination Cluster.

   Pour plus d'informations sur le statut du trafic en lecture et en écriture du topic à chaque étape du basculement, consultez la section Étapes du basculement de trafic.

4. Après avoir confirmé que le basculement de trafic est terminé pour tous les topics de cette tâche de migration, cliquez sur Migrated en bas de la page.

Opérations connexes

Voici les autres opérations disponibles sur la page de migration des messages durant le basculement de trafic :

• Roll Back

  • Retour à l'étape précédente : si un résultat inattendu se produit lors de la migration, vous pouvez revenir à la dernière étape fonctionnelle normale pour l'étape de basculement de trafic du topic spécifié. Après avoir résolu la cause de l'anomalie, vous pouvez décider des opérations suivantes.

  • Retour à l'étape initiale : cette méthode force directement le retour de l'étape de basculement de trafic à l'état initial, c'est-à-dire l'état de routage avant le début du basculement de trafic. Cette méthode est généralement utilisée pour une atténuation d'urgence.

    Remarque

    Cette méthode implique un changement d'état significatif. Les messages non consommés générés pendant le processus de migration peuvent subir des retards ou rester non traités.

• Create Topic

  Si vous avez omis un topic lors de la migration des métadonnées, vous pouvez l'ajouter durant la tâche de basculement de trafic. Cela implique de créer manuellement un topic dans l'instance ApsaraMQ for RocketMQ 5.x avec le même nom que le topic du cluster source.

• Batch Traffic Switching/Batch Rollback

  Effectuez des opérations de basculement de trafic ou de retour arrière par lots.

  Remarque

  Le basculement par lots et le retour arrière par lots s'appliquent uniquement aux topics qui se trouvent dans la même Traffic Switching Stage.

Validation de l'étape de basculement

Remarques sur l'utilisation

• Avant de finaliser la tâche de migration, assurez-vous que tous les messages planifiés dans le cluster RocketMQ open source auto-géré ont été consommés.

• Vous ne pouvez mettre hors service le cluster RocketMQ open source auto-géré qu'une fois la tâche de migration terminée.

Procédure

1. Sur la page Migration to Cloud dans la colonne Details.

2. Sur la page Actions de la tâche de migration, cliquez sur Details.