Par Ben Slater , chef de produit, Instaclustr.
Déplacer un déploiement Apache Cassandra en direct vers un nouvel emplacement ? Il est naturel d'avoir des inquiétudes, comme la façon dont vous pouvez garder les clusters Cassandra 100 % disponibles tout au long du processus. Mais, le fait est que si votre application est capable de rester en ligne tout au long des changements de paramètres de connexion, elle peut rester entièrement disponible pendant cette transition. Pour plus de protection et de tranquillité d'esprit, la technique suivante comprend également une stratégie de restauration rapide pour revenir à votre configuration d'origine, jusqu'au moment où la migration est terminée.
Voici un ordre des opérations de migration de cluster Cassandra recommandé en sept étapes qui évitera tout temps d'arrêt :
1. Préparez votre environnement existant.
Tout d'abord, assurez-vous que votre application utilise une politique d'équilibrage de charge adaptée au centre de données, ainsi que LOCAL_*. Vérifiez également que tous des espaces de clés qui seront copiés sur le nouveau cluster sont configurés pour utiliser NetworkTopologyStrategy comme stratégie de réplication. Il est également recommandé que tous les espaces de clés utilisent cette stratégie de réplication lors de leur création, car sa modification ultérieure peut devenir compliquée.
2. Créez le nouveau cluster.
Il est maintenant temps de créer le nouveau cluster vers lequel vous allez migrer. Quelques éléments à prendre en compte ici :assurez-vous que le nouveau cluster et le cluster d'origine utilisent la même version de Cassandra et le même nom de cluster. De plus, le nouveau nom du centre de données que vous utilisez doit être différent du nom du centre de données existant.
3. Rejoignez les clusters ensemble.
Pour ce faire, apportez d'abord les modifications nécessaires aux règles de pare-feu pour permettre aux clusters d'être joints, en vous rappelant que certaines modifications du cluster source peuvent également être nécessaires. Ensuite, modifiez les nœuds de départ du nouveau cluster et démarrez-les. Une fois cela fait, le nouveau cluster sera un deuxième centre de données dans le cluster d'origine.
4. Modifiez les paramètres de réplication.
Ensuite, dans le cluster existant, mettez à jour les paramètres de réplication pour les espaces de clés qui seront copiés, afin que les données soient désormais répliquées avec le nouveau centre de données comme destination.
5. Copiez les données dans le nouveau cluster.
Lorsque les clusters sont réunis, Cassandra commence à répliquer les écritures sur le nouveau cluster. Cependant, il est toujours nécessaire de copier toutes les données existantes avec la fonction de reconstruction de nodetool. Il est recommandé d'effectuer cette fonction sur le nouveau cluster, un ou deux nœuds à la fois, afin de ne pas placer une charge de streaming écrasante sur le cluster existant.
6. Changer les points de connexion de l'application.
Une fois toutes les utilisations de la fonction de reconstruction terminées, chacun des clusters contiendra une copie complète des données en cours de migration, que Cassandra conservera automatiquement synchronisée. Il est maintenant temps de changer les points de connexion initiaux de votre application sur les nœuds du nouveau cluster. Une fois cette opération terminée, toutes les lectures et écritures seront servies par le nouveau cluster, puis seront répliquées dans le cluster d'origine. Enfin, il est judicieux d'exécuter une fonction de réparation sur l'ensemble du cluster, pour s'assurer que toutes les données ont été répliquées avec succès à partir de l'original.
7. Arrêtez le cluster d'origine.
Terminez le processus avec un petit nettoyage post-migration, en supprimant le cluster d'origine. Tout d'abord, modifiez les règles du pare-feu pour déconnecter le cluster d'origine du nouveau. Ensuite, mettez à jour les paramètres de réplication dans le nouveau cluster pour arrêter la réplication des données vers le cluster d'origine. Enfin, arrêtez le cluster d'origine.
Et voilà :votre déploiement Apache Cassandra a été entièrement migré, sans aucun temps d'arrêt, à faible risque, et de manière totalement transparente et transparente du point de vue de vos utilisateurs finaux.
À propos de l'auteur
Ben Slater est Chief Product Officer chez Instaclustr, un fournisseur d'infrastructure de données open source Apache Cassandra de niveau entreprise, hébergée et entièrement gérée dans le cloud.
