ApsaraMQ for RabbitMQ vous permet de convertir les instances entre des clusters partagés et dédiés lors des opérations de mise à niveau ou de rétrogradation. Découvrez les conditions et les impacts potentiels de la conversion de cluster.
Instances partagées et dédiées
ApsaraMQ for RabbitMQ propose les architectures de déploiement d'instances suivantes pour chaque série :
|
Série |
Instances partagées |
Instances dédiées |
|
Série par abonnement |
Édition Professionnelle, Édition Entreprise |
Enterprise Platinum Edition |
|
Série Serverless |
Partagé |
Dédié |
Conditions
La conversion d'instances entre différentes séries n'est pas possible. Toutefois, au sein d'une même série, vous pouvez mettre à niveau ou rétrograder les spécifications en toute transparence.
Les anciennes instances par abonnement peuvent rencontrer des erreurs lors de la mise à niveau ou de la rétrogradation. Si vous ne pouvez pas effectuer ces opérations, soumettez un ticket pour obtenir de l'aide.
Seules les instances en cours d'exécution peuvent faire l'objet d'une mise à niveau ou d'une rétrogradation.
Les instances partagées ne permettent pas de modifier directement la méthode d'authentification ni de migrer vers les éditions Dedicated ou Serverless qui utilisent l'authentification open source. Si vous devez utiliser l'authentification open source, achetez une nouvelle instance Dedicated ou Serverless. Créez la nouvelle instance et vérifiez le bon fonctionnement de votre application avant de libérer l'ancienne instance.
Les conversions inter-architectures ne prennent en charge que les mises à niveau ou rétrogradations de spécifications au sein d'une même série. Les conversions directes entre séries ou entre systèmes d'authentification ne sont pas prises en charge.
Procédure de migration
La conversion d'instance implique les types de migration suivants :
Migration de cluster
-
Mise à niveau
Lorsqu'une instance migre d'un cluster partagé vers un cluster dédié, un nouveau cluster est créé et devient le cluster de destination de la migration.
-
Rétrogradation
Lorsqu'une instance migre d'un cluster dédié vers un cluster partagé, le cluster partagé sert directement de cluster de destination de la migration.
Migration du stockage
Phase de double écriture et double lecture : le routage en lecture et en écriture est établi sur le cluster de destination. Les deux clusters sont lisibles et accessibles en écriture.
Phase d'écriture unique et double lecture : le cluster source n'accepte plus les écritures mais reste lisible. Le cluster de destination est lisible et accessible en écriture.
Attente de la fin de la consommation du cluster source : le système attend que tous les messages du cluster source soient consommés. Si le cluster source contient des messages non consommés accumulés ou des messages planifiés non expirés, cette phase prend plus de temps.
Phase d'écriture unique et lecture unique du cluster de destination : une fois tous les messages du cluster source consommés, le cluster source cesse d'accepter les lectures et les écritures. Tout le trafic est acheminé vers le cluster de destination et la migration est terminée.
Migration de connexion
-
Point d'accès VPC / Point d'accès réseau public
-
Migration d'un cluster partagé vers un cluster dédié
Le serveur ne migre pas activement les connexions. Une fois la migration commencée, les nouvelles connexions vont directement vers le cluster de destination, mais les connexions existantes sur le cluster source restent actives. Pour garantir que toutes les connexions utilisent le nouveau cluster, redémarrez votre application pour vous reconnecter.
-
Migration d'un cluster dédié vers un cluster partagé
Étant donné que le cluster dédié doit être mis hors service, le serveur déconnecte activement les connexions existantes sur le cluster source. Si le client prend en charge la reconnexion automatique, il se reconnecte automatiquement au cluster de destination.
-
-
Endpoint PrivateLink
Toutes les connexions utilisant des endpoints PrivateLink subissent des déconnexions durant plusieurs minutes pendant la migration de l'instance.
Impacts de la migration
Lorsqu'un cluster dédié revient à un cluster partagé, les connexions sont activement déconnectées. Effectuez les migrations pendant les heures creuses et assurez-vous que votre client dispose d'un mécanisme de reconnexion robuste. Pour plus de détails, consultez Configurer la reconnexion automatique du client.
Pour les connexions via point d'accès VPC ou réseau public, les connexions existantes migrent vers le cluster de destination uniquement après le redémarrage de l'application ou du serveur (par exemple, lors d'une mise à niveau du cluster source). Les mises à niveau du cluster source ou des actions similaires peuvent provoquer des déconnexions inattendues. Pour basculer complètement vers le cluster de destination, redémarrez votre application pendant les heures creuses.
Pour les connexions via endpoint PrivateLink, des déconnexions durant plusieurs minutes se produisent pendant la migration. Effectuez les migrations pendant les heures creuses et assurez-vous que votre client dispose d'un mécanisme de reconnexion robuste.
Si le cluster source contient des messages non consommés accumulés ou des messages planifiés non expirés, la phase de migration du stockage prend plus de temps.
FAQ
Quels éléments dois-je prendre en compte lors de la mise à niveau d'une instance RabbitMQ de l'Édition Professionnelle vers l'Édition Entreprise ?
Point d'entrée : Vérifiez si le bouton Upgrade est disponible dans le coin supérieur droit de la console de l'instance. Si le bouton est présent, l'instance prend en charge les opérations de mise à niveau.
Moment : Effectuez la mise à niveau pendant les heures creuses.
Stabilité de la connexion : Les mises à niveau ne provoquent généralement pas de déconnexions. Toutefois, implémentez une logique de reconnexion automatique dans le code de votre application à titre de mesure de sécurité supplémentaire. Pour plus d'informations sur la configuration de la reconnexion, consultez Reconnexion automatique.
Conservation de la configuration : La mise à niveau augmente uniquement les limites de ressources. Les configurations existantes telles que les files d'attente, les Vhosts et autres métadonnées restent inchangées, et le point d'accès ne change pas.