🥇Migration sans tracas de RabbitMQ vers Kubernetes

RabbitMQ est un broker de messages écrit en Erlang, qui permet d'organiser un cluster tolérant aux pannes avec réplication complète des données sur plusieurs nœuds, où chaque nœud peut traiter des requêtes de lecture et d'écriture. Avec de nombreux clusters Kubernetes en production, nous gérons un grand nombre d'installations de RabbitMQ et avons rencontré le besoin de migrer des données d'un cluster à un autre sans temps d'arrêt.

Cette opération était nécessaire dans au moins deux cas :

Transférer des données d'un cluster RabbitMQ ne fonctionnant pas sous Kubernetes vers un nouveau cluster déjà 'kubernetisé' (c'est-à-dire fonctionnant dans des pods K8s).
Migrer RabbitMQ au sein de Kubernetes d'un namespace à un autre (par exemple, si les contours sont délimités par des espaces de noms, pour transférer l'infrastructure d'un contour à un autre).

La recette proposée dans cet article est axée sur des situations (mais ne s'y limite pas) où il existe un ancien cluster RabbitMQ (par exemple, avec 3 nœuds), qui est soit déjà dans K8s, soit sur d'anciens serveurs. Il est utilisé par une application hébergée dans Kubernetes (déjà là ou en perspective) :

… et nous devons le migrer vers un nouvel environnement de production dans Kubernetes.

Nous allons d'abord décrire l'approche générale pour la migration, suivie des détails techniques pour sa mise en œuvre.

L'algorithme de migration

La première étape, préliminaire, avant toute action, consiste à vérifier que l'ancien déploiement de RabbitMQ a le mode haute disponibilité activé (HA). La raison est évidente : nous ne voulons pas perdre de données. Pour effectuer cette vérification, vous pouvez accéder à l'interface d'administration de RabbitMQ et, sous l'onglet Admin → Policies, vous assurer que la valeur est définie sur ha-mode: all:

L'étape suivante consiste à déployer un nouveau cluster RabbitMQ dans des pods Kubernetes (dans notre cas, par exemple, composé de 3 nœuds, mais leur nombre peut être différent).

Après cela, nous fusionnons l'ancien et le nouveau cluster RabbitMQ, formant un seul cluster (composé de 6 nœuds) :

Le processus de synchronisation des données entre l'ancien et le nouveau cluster RabbitMQ est lancé. Une fois que toutes les données sont synchronisées entre tous les nœuds du cluster, nous pouvons rediriger l'application vers le nouveau cluster :

Après ces opérations, il suffit de sortir les anciens nœuds du cluster RabbitMQ, et le déménagement peut être considéré comme terminé :

Nous avons plusieurs fois appliqué ce schéma dans notre production. Cependant, pour notre propre commodité, nous l'avons réalisé au sein d'un système spécialisé qui distribue des configurations types de RMQ sur de nombreux clusters Kubernetes. (pour ceux qui sont curieux : il s'agit de addon-operator, dont nous récemment, nous avons parlé). Ci-dessous, des instructions spécifiques seront présentées que chacun peut appliquer sur ses installations pour essayer la solution proposée en action.

Essayons en pratique

Exigences

Les prérequis sont très simples :

Un cluster Kubernetes (minikube conviendra aussi);
Un cluster RabbitMQ (il peut être déployé sur du matériel nu ou créé comme un cluster normal dans Kubernetes à partir du Helm chart officiel).

Pour l'exemple décrit ci-dessous, j'ai déployé RMQ dans Kubernetes et l'ai nommé rmq-old.

Préparation de l'environnement

1. Téléchargeons le Helm chart et modifions-le légèrement :

helm fetch --untar stable/rabbitmq-ha

Pour notre commodité, définissons un mot de passe, ErlangCookie et établissons la politique ha-all, afin que par défaut, les files d'attente soient synchronisées entre tous les nœuds du cluster RMQ :

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "\/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. Installons le chart :

helm install . --name rmq-old --namespace rmq-old

3. Connectons-nous à l'interface d'administration de RabbitMQ, créons une nouvelle file d'attente et ajoutons quelques messages. Ils seront nécessaires pour nous assurer qu'après la migration, toutes les données sont conservées et que rien n'est perdu :

L'environnement de test est prêt : nous avons un RabbitMQ « ancien » avec des données à transférer.

Migration du cluster RabbitMQ

1. Tout d'abord, déployons un nouveau RabbitMQ dans un autre un espace de noms avec les mêmes ErlangCookie et mot de passe pour l'utilisateur. Pour cela, exécutons les opérations décrites ci-dessus, en modifiant la commande finale d'installation de RMQ comme suit :

helm install . --name rmq-new --namespace rmq-new

2. Maintenant, il faut joindre le nouveau cluster à l'ancien. Pour cela, nous entrons dans chacun des pod’ de du nouveau RabbitMQ et exécutons les commandes :

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

Dans la variable OLD_RMQ indique l'adresse d'un des nœuds de l'ancien cluster RMQ.

Ces commandes arrêteront le nœud actuel du nouveau du cluster RMQ, l'ajouteront à l'ancien cluster et le redémarreront.

3. Le cluster RMQ composé de 6 nœuds est prêt :

Vous devez attendre que les messages soient synchronisés entre tous les nœuds. Il est facile de deviner que le temps de synchronisation des messages dépend de la puissance du matériel sur lequel le cluster est déployé et du nombre de messages. Dans le scénario décrit, il n'y en a que 10, donc les données se sont synchronisées instantanément, mais avec un nombre de messages suffisamment élevé, la synchronisation peut durer des heures.

Alors, le statut de synchronisation :

Ici +5 signifie que les messages se trouvent déjà encore sur 5 nœuds (en plus de celui indiqué dans le champ Nœud). Ainsi, la synchronisation a réussi.

4. Il ne reste plus qu'à changer l'adresse RMQ dans l'application pour le nouveau cluster (les actions spécifiques ici dépendent de la pile technologique que vous utilisez et d'autres spécificités de l'application), après quoi vous pouvez faire vos adieux au précédent.

Pour la dernière opération (c'est-à-dire le après changement d'application vers le nouveau cluster), connectez-vous à chaque nœud de l'ancien du cluster et exécutez les commandes :

rabbitmqctl stop_app
rabbitmqctl reset

Le cluster a « oublié » les anciens nœuds : vous pouvez supprimer l'ancien RMQ, ce qui conclura le déménagement.

Remarque: Si vous utilisez RMQ avec des certificats, rien ne change fondamentalement — le processus de déménagement se fera exactement de la même manière.

Conclusions

Le schéma décrit convient pratiquement à tous les cas où nous devons transférer RabbitMQ ou simplement déménager vers un nouveau cluster.

Dans notre cas, des difficultés n'ont surgi qu'une fois, lorsque RMQ était consulté depuis de nombreux endroits, et nous n'avions pas la possibilité de changer l'adresse RMQ sur chacun d'eux. Alors, nous avons lancé un nouveau RMQ dans le même espace de noms avec les mêmes étiquettes, afin qu'il s'intègre aux services et Ingress existants, et en lançant le pod manuellement, nous avons manipulé les étiquettes, en les supprimant d'abord pour que les requêtes n'atteignent pas le RMQ vide, puis en les ajoutant à nouveau après la synchronisation des messages.

Nous avons appliqué la même stratégie lors de la mise à jour de RabbitMQ vers une nouvelle version avec une configuration modifiée — tout a fonctionné comme sur des roulettes.

P.S.

Comme suite logique à ce matériau, nous préparons des articles sur MongoDB (migration d'un serveur physique vers Kubernetes) et MySQL (comment nous préparons ce SGBD dans Kubernetes). Ils seront publiés dans les mois à venir.

P.P.S.

Lisez aussi dans notre blog :

Source : habr.com