Migrer de Cassandra vers Bigtable avec un proxy à double écriture

1. Introduction

Bigtable est un service de base de données NoSQL entièrement géré et hautes performances, conçu pour les charges de travail analytiques et opérationnelles volumineuses. La migration depuis des bases de données existantes comme Apache Cassandra vers Bigtable nécessite souvent une planification minutieuse pour minimiser les temps d'arrêt et l'impact sur les applications.

Cet atelier de programmation présente une stratégie de migration de Cassandra vers Bigtable à l'aide d'une combinaison d'outils proxy :

1. Proxy Cassandra-Bigtable : permet aux clients et outils Cassandra (comme cqlsh ou les pilotes) d'interagir avec Bigtable à l'aide du protocole Cassandra Query Language (CQL) en traduisant les requêtes.
2. Proxy Datastax Zero Downtime Migration (ZDM) : proxy Open Source qui se situe entre votre application et vos services de base de données (Cassandra d'origine et Bigtable cible via le proxy Cassandra-Bigtable). Il orchestre les doubles écritures et gère le routage du trafic, ce qui permet la migration avec un minimum de modifications et de temps d'arrêt de l'application.
3. Cassandra Data Migrator (CDM) : outil Open Source utilisé pour migrer en masse les données historiques du cluster Cassandra source vers l'instance Bigtable cible.

Points abordés

• Configurer un cluster Cassandra de base sur Compute Engine
• Découvrez comment créer une instance Bigtable.
• Découvrez comment déployer et configurer le proxy Cassandra-Bigtable pour mapper un schéma Cassandra à Bigtable.
• Découvrez comment déployer et configurer le proxy ZDM Datastax pour les doubles écritures.
• Découvrez comment utiliser l'outil Cassandra Data Migrator pour migrer des données existantes de manière groupée.
• Workflow global pour une migration de Cassandra vers Bigtable basée sur un proxy.

Prérequis

• Un projet Google Cloud avec facturation activée. Les nouveaux utilisateurs peuvent bénéficier d'un essai sans frais.
• Connaissances de base des concepts Google Cloud tels que les projets, Compute Engine, les réseaux VPC et les règles de pare-feu Connaissance de base des outils de ligne de commande Linux
• Accès à une machine sur laquelle la CLI gcloud est installée et configurée, ou utilisation de Google Cloud Shell.

Pour cet atelier de programmation, nous utiliserons principalement des machines virtuelles (VM) sur Compute Engine au sein du même réseau VPC et de la même région afin de simplifier la mise en réseau. Il est recommandé d'utiliser des adresses IP internes.

2. Configurer votre environnement

1. Sélectionner ou créer un projet Google Cloud

Accédez à la console Google Cloud, puis sélectionnez un projet existant ou créez-en un. Notez l'ID de votre projet.

2. Choisir une région et une zone

Sélectionnez une région et une zone pour vos ressources. Nous utiliserons us-central1 et us-central1-c comme exemples. Pour plus de commodité, définissez ces éléments comme variables d'environnement :

export PROJECT_ID="<your-project-id>"
export REGION="us-central1"
export ZONE="us-central1-c"

gcloud config set project $PROJECT_ID
gcloud config set compute/region $REGION
gcloud config set compute/zone $ZONE

3. Activer les API requises

Assurez-vous que les API Compute Engine et Bigtable sont activées pour votre projet.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com

4. Configurer des règles de pare-feu

Nous devons autoriser la communication entre nos VM au sein du réseau VPC par défaut sur plusieurs ports :

• Port CQL Cassandra/Proxies : 9042
• Port de vérification de l'état du proxy ZDM : 14001
• SSH : 22

Créez une règle de pare-feu pour autoriser le trafic interne sur ces ports. Nous utiliserons le tag cassandra-migration pour appliquer facilement cette règle aux VM concernées.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:7000,tcp:14001 \
--source-ranges=10.0.0.0/8 \
--target-tags=cassandra-migration

3. Déployer un cluster Cassandra (Origin)

Pour cet atelier de programmation, nous allons configurer un simple cluster Cassandra à nœud unique sur Compute Engine. Dans un scénario réel, vous vous connecteriez à votre cluster existant.

1. Créer une VM GCE pour Cassandra

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--scopes=cloud-platform \
--zone="$ZONE"

Se connecter en SSH à votre instance Cassandra

gcloud compute ssh --zone="$ZONE" "cassandra-origin"

2. Installer Cassandra

# Install Java (Cassandra dependency)
sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless

# Add Cassandra repository
echo "deb https://debian.cassandra.apache.org 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -

# Install Cassandra
sudo apt update
sudo apt install -y cassandra

# (Optional) Verify Cassandra is running
sudo systemctl status cassandra

3. Configurer Cassandra

Nous devons configurer Cassandra pour qu'il soit accessible au sein du réseau privé.

Récupérez l'adresse IP privée de cassandra-origin en exécutant la commande suivante :

hostname -I

Modifiez la configuration de Cassandra. Vous ne devriez pas avoir à ajouter de nouvelles lignes de configuration. Il vous suffit de mettre à jour celles qui existent déjà :

sudo vim /etc/cassandra/cassandra.yaml

1. Définissez seed_provider.parameters.seeds sur "CASSANDRA_ORIGIN_PRIVATE_IP:7000"
2. Définissez rpc_address sur CASSANDRA_ORIGIN_PRIVATE_IP
3. Définissez listen_address sur CASSANDRA_ORIGIN_PRIVATE_IP

Enregistrez le fichier.

Enfin, redémarrez Cassandra pour charger les modifications de configuration :

sudo systemctl restart cassandra

# (Optional) Verify Cassandra is running
sudo systemctl status cassandra

4. Créer un espace de clés et une table

Nous allons utiliser un exemple de tableau d'employés et créer un espace de clés appelé "zdmbigtable".

Remarque : Cassandra peut mettre une minute à accepter les connexions.

# Start cqlsh
cqlsh $(hostname -I)

Dans cqlsh :

-- Create keyspace (adjust replication for production)
CREATE KEYSPACE zdmbigtable WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};

-- Use the keyspace
USE zdmbigtable;

-- Create the employee table
CREATE TABLE employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

-- Exit cqlsh
EXIT;

Laissez la session SSH ouverte ou notez l'adresse IP de cette VM (hostname -I).

4. Configurer Bigtable (cible)

Durée : 0:01

Créer une instance Bigtable Nous utiliserons zdmbigtable comme ID d'instance.

gcloud bigtable instances create zdmbigtable \
--display-name="ZDM Bigtable Target" \
--cluster="bigtable-c1" \
--cluster-zone="$ZONE" \
--cluster-num-nodes=1 # Use 1 node for dev/testing; scale as needed

La table Bigtable elle-même sera créée ultérieurement par le script de configuration du proxy Cassandra-Bigtable.

5. Configurer le proxy Cassandra-Bigtable

1. Créer une VM Compute Engine pour le proxy Cassandra-Bigtable

gcloud iam service-accounts create bigtable-proxy-sa \
    --description="Service account for Bigtable Proxy access" \
    --display-name="Bigtable Proxy Access SA"

export BIGTABLE_PROXY_SA_EMAIL=$(gcloud iam service-accounts list --filter="displayName='Bigtable Proxy Access SA'" --format="value(email)")

gcloud bigtable instances add-iam-policy-binding zdmbigtable \
  --member="serviceAccount:$BIGTABLE_PROXY_SA_EMAIL" \
  --role="roles/bigtable.admin"

gcloud compute instances create bigtable-proxy-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--zone=$ZONE \
--scopes=cloud-platform \
--service-account="$BIGTABLE_PROXY_SA_EMAIL"

Connectez-vous en SSH à bigtable-proxy-vm :

gcloud compute ssh --zone="$ZONE" "bigtable-proxy-vm"

Sur la VM bigtable-proxy-vm, exécutez la commande suivante :

# Install Git and Go
sudo apt-get update
sudo apt-get install -y git

wget https://go.dev/dl/go1.23.6.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.23.6.linux-amd64.tar.gz

echo 'export GOPATH=$HOME/go' >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile

# Clone the proxy repository
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cloud-bigtable-ecosystem/cassandra-bigtable-migration-tools/cassandra-bigtable-proxy/

2. Démarrer le proxy Cassandra-Bigtable

Démarrez le serveur proxy.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go --project-id="$(gcloud config get-value project)" --instance-id=zdmbigtable --keyspace-id=zdmbigtable --rpc-address=$(hostname -I)

Le proxy démarre et écoute les connexions CQL entrantes sur le port 9042. Laissez cette session de terminal s'exécuter. Notez l'adresse IP de cette VM (hostname -I).

3. Créer une table avec CQL

Connectez CQLSH à l'adresse IP de la VM proxy Cassandra-Bigtable. Vous pouvez trouver l'adresse IP en exécutant la commande suivante en local :

gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)'

Dans une fenêtre distincte, connectez-vous en SSH à votre VM cassandra-origin et utilisez cqlsh pour le bigtable-proxy. Notez que nous avons défini un délai avant expiration de la requête plus long que celui par défaut pour nous assurer que Bigtable dispose de suffisamment de temps pour créer la table sous-jacente. Le message "Connected to cassandra-bigtable-proxy-v0.2.3" (Connecté à cassandra-bigtable-proxy-v0.2.3) ou un message semblable doit s'afficher. Il indique que vous vous êtes connecté au proxy Bigtable, et non au serveur Cassandra local.

# Replace <your-bigtable-proxy-vm-ip> with the ip from the above command
export BIGTABLE_PROXY_IP=<your-bigtable-proxy-vm-ip>
cqlsh --request-timeout=60 $BIGTABLE_PROXY_IP

-- Create the employee table
CREATE TABLE zdmbigtable.employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

Dans CQLSH, vérifiez que votre table a été créée en exécutant la commande suivante :

DESC TABLE zdmbigtable.employee;

6. Configurer le proxy ZDM

Pour cet atelier, nous allons créer une seule instance du proxy ZDM, mais vous aurez besoin d'une configuration à plusieurs nœuds pour une migration en production.

1. Créer la VM proxy ZDM

gcloud compute instances create zdm-proxy-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--scopes=cloud-platform \
--zone=$ZONE

Notez les adresses IP des deux VM.

2. Préparer le proxy ZDM

gcloud compute ssh --zone="$ZONE" zdm-proxy-vm

export ZDM_VERSION="2.3.4"
wget "https://github.com/datastax/zdm-proxy/releases/download/v$ZDM_VERSION/zdm-proxy-linux-amd64-v$ZDM_VERSION.tgz"
tar -xvzf "zdm-proxy-linux-amd64-v$ZDM_VERSION.tgz"

# replace YOUR_ZONE
gcloud config set compute/zone "YOUR_ZONE"
export ZDM_ORIGIN_CONTACT_POINTS=$(gcloud compute instances describe cassandra-origin --format='get(networkInterfaces[0].networkIP)') 
export ZDM_TARGET_CONTACT_POINTS=$(gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)')
export ZDM_ORIGIN_USERNAME=""
export ZDM_ORIGIN_PASSWORD=""
export ZDM_TARGET_USERNAME=""
export ZDM_TARGET_PASSWORD=""
export ZDM_PROXY_LISTEN_ADDRESS=0.0.0.0
export ZDM_PROXY_LISTEN_PORT=9042
./zdm-proxy-v${ZDM_VERSION}

7. Configurer l'application et démarrer la double écriture

Durée : 0:05

À ce stade d'une véritable migration, vous reconfigurerez vos applications pour qu'elles pointent vers l'adresse IP de la VM du proxy ZDM (par exemple, :9042) au lieu de se connecter directement à Cassandra.

Une fois l'application connectée au proxy ZDM : les lectures sont effectuées à partir de l'origine (Cassandra) par défaut. Les écritures sont envoyées à la fois à l'origine (Cassandra) et à la cible (Bigtable, via le proxy Cassandra-Bigtable). Cela permet à votre application de continuer à fonctionner normalement tout en veillant à ce que les nouvelles données soient écrites simultanément dans les deux bases de données. Vous pouvez tester la connexion à l'aide de cqlsh pointant vers le proxy ZDM :

cqlsh $(gcloud compute instances describe zdm-proxy-vm --format='get(networkInterfaces[0].networkIP)')

Essayez d'insérer des données :

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Anna', 45, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Albert', 50, false); 
SELECT * FROM zdmbigtable.employee;

Ces données doivent être écrites à la fois dans Cassandra et dans Bigtable. Vous pouvez le vérifier dans Bigtable en accédant à la console Google Cloud et en ouvrant l'éditeur de requête Bigtable pour votre instance. Exécutez une requête "SELECT * FROM employee". Les données récemment insérées devraient être visibles.

8. Migrer les données historiques à l'aide de Cassandra Data Migrator

Maintenant que la double écriture est active pour les nouvelles données, utilisez l'outil Cassandra Data Migrator (CDM) pour copier les données historiques existantes de Cassandra vers Bigtable.

1. Créer une VM Compute Engine pour le CDM

Cette VM a besoin de suffisamment de mémoire pour Spark.

gcloud compute instances create cdm-migrator-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB \
--scopes=cloud-platform \
--zone=$ZONE

2. Installer les prérequis (Java 11, Spark)

Connectez-vous en SSH à cdm-migrator-vm :

gcloud compute ssh cdm-migrator-vm

Dans la VM :

# Install Java 11 
sudo apt-get update 
sudo apt-get install -y openjdk-11-jdk
 
# Verify Java installation 
java -version 

# Download and Extract Spark (Using version 3.5.3 as requested) 
# Check the Apache Spark archives for the correct URL if needed

wget  https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz
tar -xvzf spark-3.5.3-bin-hadoop3-scala2.13.tgz

echo 'export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13' >> ~/.profile
echo 'export PATH=$PATH:$SPARK_HOME/bin' >> ~/.profile
source ~/.profile

3. Télécharger Cassandra Data Migrator

Dans votre navigateur, ouvrez la page des packages CDM et copiez le lien .jar depuis le panneau "Assets" (Éléments). Si la version 5.4.0 n'est pas disponible, choisissez la version la plus proche. Collez le lien dans la commande ci-dessous et exécutez-le sur votre instance cdm-migrator-vm, en conservant les guillemets autour de l'URL.

wget 'JAR_URL_GOES_HERE' -O cassandra-data-migrator.jar

Vérifiez que le fichier jar a été téléchargé correctement en l'analysant avec l'outil jar. Une longue liste de fichiers ".class" devrait s'afficher.

jar tf cassandra-data-migrator.jar 

4. Ajouter des données

Nous devons ajouter des données à migrer en écrivant directement dans cassandra-origin (et non dans zdm-proxy-vm).

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alfred', 67, true); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Bobby', 12, false); 
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Carol', 29, true); 

5. Exécuter le job de migration

Exécutez la migration à l'aide de spark-submit. Cette commande indique à Spark d'exécuter le fichier JAR CDM, en utilisant votre fichier de propriétés et en spécifiant l'espace de clés et la table à migrer. Ajustez les paramètres de mémoire (–driver-memory, –executor-memory) en fonction de la taille de votre VM et du volume de données.

Assurez-vous de vous trouver dans le répertoire contenant le fichier jar et le fichier de propriétés CDM.

Conseil : Vous pouvez obtenir l'adresse IP interne de vos VM Cassandra et de proxy en exécutant les commandes suivantes à partir de votre machine locale :

gcloud compute instances describe cassandra-origin --format='get(networkInterfaces[0].networkIP)'
gcloud compute instances describe bigtable-proxy-vm --format='get(networkInterfaces[0].networkIP)'

export ORIGIN_HOST="<your-cassandra-origin-ip>"
export TARGET_HOST="<your-bigtable-proxy-vm-ip>"
export KEYSPACE_TABLE="zdmbigtable.employee"
spark-submit --verbose --master "local[*]" \
--driver-memory 3G --executor-memory 3G \
--conf spark.cdm.schema.origin.keyspaceTable="$KEYSPACE_TABLE" \
--conf spark.cdm.connect.origin.host="$ORIGIN_HOST" \
--conf spark.cdm.connect.origin.port=9042 \
--conf spark.cdm.connect.target.host="$TARGET_HOST" \
--conf spark.cdm.connect.target.port=9042 \
--conf spark.cdm.feature.origin.ttl.automatic=false \
--conf spark.cdm.feature.origin.writetime.automatic=false \
--conf spark.cdm.feature.target.ttl.automatic=false \
--conf spark.cdm.feature.target.writetime.automatic=false \
--conf spark.cdm.schema.origin.column.ttl.automatic=false \
--conf spark.cdm.schema.ttlwritetime.calc.useCollections=false \
--class com.datastax.cdm.job.Migrate cassandra-data-migrator.jar

6. Vérifier la migration des données

Une fois le job CDM terminé, vérifiez que les données historiques existent dans Bigtable.

cqlsh <bigtable-proxy-vm-ip>

Dans cqlsh :

SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin 
SELECT * FROM zdmbigtable.employee LIMIT 10; -- Check some sample data

9. Bascule (conceptuelle)

Après avoir vérifié minutieusement la cohérence des données entre Cassandra et Bigtable, vous pouvez procéder au basculement final.

Avec le proxy ZDM, la transition consiste à le reconfigurer pour qu'il lise principalement à partir de la cible (Bigtable) au lieu de l'origine (Cassandra). Cela se fait généralement via la configuration du proxy ZDM, ce qui permet de transférer efficacement le trafic de lecture de votre application vers Bigtable.

Une fois que vous êtes sûr que Bigtable diffuse correctement tout le trafic, vous pouvez éventuellement :

• Arrêtez les doubles écritures en reconfigurant le proxy ZDM.
• Mettez hors service le cluster Cassandra d'origine.
• Supprimez le proxy ZDM et connectez l'application directement au proxy Cassandra-Bigtable ou utilisez le client CQL Bigtable natif pour Java.

Les spécificités de la reconfiguration du proxy ZDM pour la transition ne sont pas abordées dans cet atelier de programmation de base, mais sont détaillées dans la documentation Datastax ZDM.

10. Effectuer un nettoyage

Pour éviter que des frais ne vous soient facturés, supprimez les ressources créées au cours de cet atelier de programmation.

1. Supprimer des VM Compute Engine

gcloud compute instances delete cassandra-origin zdm-proxy-vm bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet

2. Supprimer une instance Bigtable

gcloud bigtable instances delete zdmbigtable

3. Supprimer des règles de pare-feu

gcloud compute firewall-rules delete allow-migration-internal

4. Supprimer la base de données Cassandra (si elle est installée localement ou persistante)

Si vous avez installé Cassandra en dehors d'une VM Compute Engine créée ici, suivez les étapes appropriées pour supprimer les données ou désinstaller Cassandra.

11. Félicitations !

Vous avez réussi à configurer un chemin de migration basé sur un proxy depuis Apache Cassandra vers Bigtable.

Vous avez appris à :

Déployez Cassandra et Bigtable.

• Configurez le proxy Cassandra-Bigtable pour la compatibilité CQL.
• Déployez le proxy ZDM Datastax pour gérer les doubles écritures et le trafic.
• Utilisez le migreur de données Cassandra pour transférer les données historiques.

Cette approche permet d'effectuer des migrations avec un temps d'arrêt minimal et sans modification du code en tirant parti de la couche proxy.

Étapes suivantes

• Consulter la documentation Bigtable
• Consultez la documentation sur le proxy ZDM Datastax pour connaître les configurations avancées et les procédures de transition.
• Pour en savoir plus, consultez le dépôt du proxy Cassandra-Bigtable.
• Consultez le dépôt Cassandra Data Migrator pour en savoir plus sur l'utilisation avancée.
• Essayer d'autres ateliers de programmation Google Cloud