Migrazione da Cassandra a Bigtable con un proxy di scrittura doppia

1. Introduzione

Bigtable è un servizio di database NoSQL ad alte prestazioni e completamente gestito progettato per carichi di lavoro analitici e operativi di grandi dimensioni. La migrazione da database esistenti come Apache Cassandra a Bigtable spesso richiede un'attenta pianificazione per ridurre al minimo i tempi di inattività e l'impatto sulle applicazioni.

Questo codelab mostra una strategia di migrazione da Cassandra a Bigtable utilizzando una combinazione di strumenti proxy:

1. Proxy Cassandra-Bigtable:consente ai client e agli strumenti Cassandra (come cqlsh o i driver) di interagire con Bigtable utilizzando il protocollo Cassandra Query Language (CQL) traducendo le query.
2. Proxy DataStax Zero Downtime Migration (ZDM):un proxy open source che si trova tra l'applicazione e i servizi di database (Cassandra di origine e Bigtable di destinazione tramite il proxy Cassandra-Bigtable). Orchestra le scritture doppie e gestisce il routing del traffico, consentendo la migrazione con modifiche minime all'applicazione e tempi di inattività ridotti.
3. Cassandra Data Migrator (CDM): uno strumento open source utilizzato per la migrazione collettiva dei dati storici dal cluster Cassandra di origine all'istanza Bigtable di destinazione.

Obiettivi didattici

• Come configurare un cluster Cassandra di base su Compute Engine.
• Come creare un'istanza Bigtable.
• Come eseguire il deployment e configurare il proxy Cassandra-Bigtable per mappare uno schema Cassandra a Bigtable.
• Come eseguire il deployment e configurare il proxy ZDM di Datastax per le scritture doppie.
• Come utilizzare lo strumento Cassandra Data Migrator per eseguire la migrazione collettiva dei dati esistenti.
• Il flusso di lavoro complessivo per una migrazione da Cassandra a Bigtable basata su proxy.

Che cosa ti serve

• Un progetto Google Cloud con la fatturazione abilitata. I nuovi utenti possono usufruire di una prova senza costi.
• Familiarità di base con i concetti di Google Cloud come progetti, Compute Engine, reti VPC e regole firewall. Familiarità di base con gli strumenti a riga di comando di Linux.
• Accedi a una macchina con l'interfaccia a riga di comando gcloud installata e configurata oppure utilizza Google Cloud Shell.

Per questo codelab, utilizzeremo principalmente macchine virtuali (VM) su Compute Engine all'interno della stessa rete e regione VPC per semplificare la rete. Ti consigliamo di utilizzare indirizzi IP interni.

2. Configura l'ambiente

1. Seleziona o crea un progetto Google Cloud

Vai alla console Google Cloud e seleziona un progetto esistente o creane uno nuovo. Prendi nota dell'ID progetto.

2. Abilita le API richieste

Assicurati che l'API Compute Engine e l'API Bigtable siano abilitate per il tuo progetto.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>

Sostituisci con l'ID progetto effettivo.

3. Scegli una regione e una zona

Seleziona una regione e una zona per le risorse. Utilizzeremo us-central1 e us-central1-c come esempi. Per comodità, definiscili come variabili di ambiente:

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

4. Configurazione delle regole del firewall

Dobbiamo consentire la comunicazione tra le nostre VM all'interno della rete VPC predefinita su diverse porte:

• Porta CQL di Cassandra/proxy: 9042
• Porta del controllo di integrità del proxy ZDM: 14001
• SSH: 22

Crea una regola firewall per consentire il traffico interno su queste porte. Utilizzeremo un tag cassandra-migration per applicare facilmente questa regola alle VM pertinenti.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:14001 \
--source-ranges=10.128.0.0/9 # Adjust if using a custom VPC/IP range \
--target-tags=cassandra-migration

3. Esegui il deployment del cluster Cassandra (Origin)

Per questo codelab, configureremo un semplice cluster Cassandra a un solo nodo su Compute Engine. In uno scenario reale, ti connetteresti al tuo cluster esistente.

1. Crea una VM GCE per Cassandra

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

2. Installa 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](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](https://downloads.apache.org/cassandra/KEYS) | sudo apt-key add -

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

3. Crea uno spazio chiavi e una tabella

Utilizzeremo un esempio di tabella degli impiegati e creeremo uno spazio chiavi denominato "zdmbigtable".

cd ~/apache-cassandra
bin/cqlsh <your-localhost-ip? 9042  #starts the cql shell

In 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;

Lascia aperta la sessione SSH o prendi nota dell'indirizzo IP di questa VM (nome host -I).

4. Configura Bigtable (target)

Durata 0:01

Crea un'istanza Bigtable. Utilizzeremo zdmbigtable come ID istanza.

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 tabella Bigtable stessa verrà creata in un secondo momento dallo script di configurazione del proxy Cassandra-Bigtable.

5. Configurare il proxy Cassandra-Bigtable

1. Crea una VM Compute Engine per il proxy Cassandra-Bigtable

gcloud compute instances create bigtable-proxy-vm \ 
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

Accedi tramite SSH a bigtable-proxy-vm:

gcloud compute ssh bigtable-proxy-vm

All'interno della VM:

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

# Clone the proxy repository
# Replace with the actual repository URL if different
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cassandra-to-bigtable-proxy/

# Set Go environment variables
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

2. Configura il proxy

nano config.yaml

Aggiorna le seguenti variabili. Per una configurazione più avanzata, utilizza questo esempio fornito su GitHub.

#!/bin/bash
cassandraToBigtableConfigs:
  # Global default GCP Project ID
  projectId: <your-project-id>

listeners:
- name: cluster1
  port: 9042
  bigtable:
    #If you want to use multiple instances then pass the instance names by comma seperated
    #Instance name should not contain any special characters except underscore(_)
    instanceIds: zdmbigtable

    # Number of grpc channels to be used for Bigtable session.
    Session:
      grpcChannels: 4

otel:
  # Set enabled to true or false for OTEL metrics/traces/logs.
  enabled: False

  # Name of the collector service to be setup as a sidecar
  serviceName: cassandra-to-bigtable-otel-service

  healthcheck:
    # Enable the health check in this proxy application config only if the
    # "health_check" extension is added to the OTEL collector service configuration.
    #
    # Recommendation:
    # Enable the OTEL health check if you need to verify the collector's availability
    # at the start of the application. For development or testing environments, it can
    # be safely disabled to reduce complexity.

    # Enable/Disable Health Check for OTEL, Default 'False'.
    enabled: False
    # Health check endpoint for the OTEL collector service
    endpoint: localhost:13133
  metrics:
    # Collector service endpoint
    endpoint: localhost:4317

  traces:
    # Collector service endpoint
    endpoint: localhost:4317
    #Sampling ratio should be between 0 and 1. Here 0.05 means 5/100 Sampling ratio.
    samplingRatio: 1

loggerConfig:
  # Specifies the type of output, here it is set to 'file' indicating logs will be written to a file.
  # Value of `outputType` should be `file` for file type or `stdout` for standard output.
  # Default value is `stdout`.
  outputType: stdout
  # Set this only if the outputType is set to `file`.
  # The path and name of the log file where logs will be stored. For example, output.log, Required Key.
  # Default `/var/log/cassandra-to-spanner-proxy/output.log`.
  fileName: output/output.log
  # Set this only if the outputType is set to `file`.
  # The maximum size of the log file in megabytes before it is rotated. For example, 500 for 500 MB.
  maxSize: 10
  # Set this only if the outputType is set to `file`.
  # The maximum number of backup log files to keep. Once this limit is reached, the oldest log file will be deleted.
  maxBackups: 2
  # Set this only if the outputType is set to `file`.
  # The maximum age in days for a log file to be retained. Logs older than this will be deleted. Required Key.
  # Default 3 days
  maxAge: 1

  # Set this only if the outputType is set to `file`.
  # Default value is set to 'False'. Change the value to 'True', if log files are required to be compressed.
  compress: True

Salva e chiudi il file (Ctrl+X, Y e Invio in nano).

3. Avvia il proxy Cassandra-Bigtable

Avvia il server proxy.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go

Il proxy verrà avviato e ascolterà sulla porta 9042 le connessioni CQL in arrivo. Mantieni in esecuzione questa sessione del terminale. Prendi nota dell'indirizzo IP di questa VM (nome host -I)

4. Crea tabella tramite CQL

Connetti cqlsh all'indirizzo IP della VM proxy Cassandra-Bigtable.

In cqlsh, esegui il seguente comando

-- 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
);

Verifica nella console Google Cloud che la tabella dei dipendenti e la tabella dei metadati esistano nell'istanza Bigtable.

6. Configurare il proxy ZDM

Il proxy ZDM richiede almeno due macchine: uno o più nodi proxy che gestiscono il traffico e un "jumphost" utilizzato per il deployment e l'orchestrazione tramite Ansible.

1. Creare VM Compute Engine per il proxy ZDM

Abbiamo bisogno di due VM: zdm-proxy-jumphost e zdm-proxy-node-1

# Jumphost VM 
gcloud compute instances create zdm-jumphost \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

# Proxy Node VM 
gcloud compute instances create zdm-proxy-node-1 \
--machine-type=e2-standard-8 \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

Prendi nota degli indirizzi IP di entrambe le VM.

2. Prepara il jumphost

Accedi tramite SSH a zdm-jumphost

gcloud compute ssh zdm-jumphost

# Install Git and Ansible

sudo apt-get update
sudo apt-get install -y git ansible

All'interno del jumphost

git clone https:\/\/github.com/datastax/zdm-proxy-automation.git 

cd zdm-proxy-automation/ansible/

Modifica il file di configurazione principale vars/zdm_proxy_cluster_config.yml:

Aggiorna origin_contact_points e target_contact_points con gli indirizzi IP interni della VM Cassandra e della VM proxy Cassandra-Bigtable, rispettivamente. Lascia l'autenticazione commentata perché non l'abbiamo configurata.

##############################
#### ORIGIN CONFIGURATION ####
##############################
## Origin credentials (leave commented if no auth)
# origin_username: ...
# origin_password: ...

## Set the following two parameters only if Origin is a self-managed, non-Astra cluster
origin_contact_points: <Your-Cassandra-VM-Internal-IP> # Replace!
origin_port: 9042

##############################
#### TARGET CONFIGURATION ####
##############################
## Target credentials (leave commented if no auth)
# target_username: ...
# target_password: ...

## Set the following two parameters only if Target is a self-managed, non-Astra cluster
target_contact_points: <Your-Bigtable-Proxy-VM-Internal-IP> # Replace!
target_port: 9042

# --- Other ZDM Proxy settings can be configured below ---
# ... (keep defaults for this codelab)

Salva e chiudi il file.

3. Esegui il deployment del proxy ZDM utilizzando Ansible

Esegui il playbook Ansible dalla directory ansible sul jumphost:

ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory

Questo comando installerà il software necessario (come Docker) sul nodo proxy (zdm-proxy-node-1), estrarrà l'immagine Docker del proxy ZDM e avvierà il contenitore proxy con la configurazione che hai fornito.

4. Verificare l'integrità del proxy ZDM

Controlla l'endpoint di idoneità del proxy ZDM in esecuzione su zdm-proxy-node-1 (porta 14001) dal jumphost:

# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl -G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness

Dovresti visualizzare un output simile a questo, che indica che sia l'origine (Cassandra) sia la destinazione (proxy Cassandra-Bigtable) sono UP:

{
  "OriginStatus": {
    "Addr": "<Your-Cassandra-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "TargetStatus": {
    "Addr": "<Your-Bigtable-Proxy-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "Status": "UP"
}

7. Configura l'applicazione e avvia le scritture doppie

Durata 0:05

In questa fase di una migrazione reale, devi riconfigurare le applicazioni in modo che rimandino all'indirizzo IP del nodo proxy ZDM (ad es. :9042) anziché connettersi direttamente a Cassandra.

Una volta che l'applicazione si connette al proxy ZDM: le letture vengono eseguite dall'origine (Cassandra) per impostazione predefinita. Le scritture vengono inviate sia all'origine (Cassandra) sia alla destinazione (Bigtable tramite il proxy Cassandra-Bigtable). In questo modo, l'applicazione può continuare a funzionare normalmente, garantendo al contempo la scrittura dei nuovi dati in entrambi i database contemporaneamente. Puoi testare la connessione utilizzando cqlsh indirizzato al proxy ZDM dal jumphost o da un'altra VM nella rete:

Cqlsh <zdm-proxy-node-1-ip-address> 9042

Prova a inserire alcuni dati:

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
SELECT * FROM employee WHERE name = 'Alice';

Questi dati devono essere scritti sia in Cassandra che in Bigtable. Puoi confermarlo in Bigtable, accedendo alla console Google Cloud e aprendo Bigtable Query Editor per la tua istanza. Esegui una query "SELECT * FROM employee" e i dati inseriti di recente dovrebbero essere visibili.

8. Esegui la migrazione dei dati storici utilizzando Cassandra Data Migrator

Ora che le scritture doppie sono attive per i nuovi dati, utilizza lo strumento Cassandra Data Migrator (CDM) per copiare i dati storici esistenti da Cassandra a Bigtable.

1. Crea una VM Compute Engine per CDM

Questa VM ha bisogno di memoria sufficiente per Spark.

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

2. Installa i prerequisiti (Java 11, Spark)

Accedi tramite SSH alla VM cdm-migrator:

gcloud compute ssh cdm-migrator-vm

All'interno della 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](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
 
export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13 
export PATH=$PATH:$SPARK_HOME/bin

3. Scarica Cassandra Data Migrator

Scarica il file jar dello strumento CDM. Controlla la pagina delle release di GitHub di Cassandra Data Migrator per trovare l'URL corretto della versione che ti interessa.

# Example using version 5.2.2 - replace URL if needed
wget https://github.com/datastax/cassandra-data-migrator/releases/download/v5.2.2/cassandra-data-migrator-5.2.2.jar)

4. Configurare CDM

Crea un file di proprietà denominato cdm.properties

Nano cdm.properties

Incolla la seguente configurazione, sostituendo gli indirizzi IP e disattivando le funzionalità TTL/Writetime perché non sono supportate direttamente da Bigtable nello stesso modo. Lascia la verifica dell'autenticazione commentata.

# Origin Cassandra Connection 
spark.cdm.connect.origin.host <Your-Cassandra-VM-IP-Address> # Replace!
spark.cdm.connect.origin.port 9042
spark.cdm.connect.origin.username cassandra # Leave default, or set if auth is enabled # 
spark.cdm.connect.origin.password cassandra # Leave default, or set if auth is enabled #

# Target Bigtable (via Cassandra-Bigtable Proxy)
Connection spark.cdm.connect.target.host <Your-Bigtable-Proxy-VM-IP-Address> # Replace! 
spark.cdm.connect.target.port 9042
spark.cdm.connect.target.username cassandra # Leave default, or set if auth is enabled #
spark.cdm.connect.target.password cassandra # Leave default, or set if auth is enabled #

# Disable TTL/Writetime features (Important for Bigtable compatibility via Proxy)
spark.cdm.feature.origin.ttl.automatic false 
spark.cdm.feature.origin.writetime.automatic false 
spark.cdm.feature.target.ttl.automatic false 
spark.cdm.feature.target.writetime.automatic false

Salva e chiudi il file.

5. Esegui il job di migrazione

Esegui la migrazione utilizzando spark-submit. Questo comando indica a Spark di eseguire il file jar del CDM utilizzando il file di proprietà e specificando lo spazio chiavi e la tabella di cui eseguire la migrazione. Modifica le impostazioni della memoria (-driver-memory, -executor-memory) in base alle dimensioni della VM e al volume di dati.

Assicurati di trovarti nella directory contenente il file jar e il file delle proprietà CDM. Sostituisci "cassandra-data-migrator-5.2.2.jar" se hai scaricato una versione diversa.

./spark-3.5.3-bin-hadoop3-scala2.13/bin/spark-submit \ --properties-file cdm.properties \ --master "local[*]" \ --driver-memory 4G \ --executor-memory 4G \ --class com.datastax.cdm.job.Migrate \ cassandra-data-migrator-5.2.2.jar &> cdm_migration_$(date +%Y%m%d_%H%M).log

La migrazione verrà eseguita in background e i log verranno scritti in cdm_migration_… .log. Monitora il file di log per verificare l'avanzamento ed eventuali errori:

tail -f cdm_migration_*.log

6. Verificare la migrazione dei dati

Una volta completato il job CDM, verifica che i dati storici esistano in Bigtable. Poiché il proxy Cassandra-Bigtable consente le letture CQL, puoi utilizzare di nuovo cqlsh connesso al proxy ZDM (che instrada le letture alla destinazione dopo la migrazione o può essere configurato in questo modo) o direttamente al proxy Cassandra-Bigtable per eseguire query sui dati. Connettiti tramite il proxy ZDM:

cqlsh <zdm-proxy-node-1-ip-address> 9042

In cqlsh:

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

In alternativa, utilizza lo strumento cbt (se installato sulla VM CDM o su Cloud Shell) per cercare i dati direttamente in Bigtable:

# First, install cbt if needed
# gcloud components update
# gcloud components install cbt

# Then lookup a specific row (replace 'some_employee_name' with an actual primary key)
cbt -project $PROJECT_ID -instance zdmbigtable lookup employee some_employee_name

9. Cutover (concettuale)

Dopo aver verificato attentamente la coerenza dei dati tra Cassandra e Bigtable, puoi procedere con il passaggio finale.

Con il proxy ZDM, il passaggio comporta la riconfigurazione in modo che le letture vengano eseguite principalmente dalla destinazione (Bigtable) anziché dall'origine (Cassandra). In genere, questo viene eseguito tramite la configurazione di ZDM Proxy, spostando efficacemente il traffico di lettura dell'applicazione su Bigtable.

Una volta che hai la certezza che Bigtable gestisce correttamente tutto il traffico, puoi:

• Interrompi le doppie scritture riconfigurando il proxy ZDM.
• Esegui il ritiro del cluster Cassandra originale.
• Rimuovi il proxy ZDM e fai in modo che l'applicazione si connetta direttamente al proxy Cassandra-Bigtable o utilizza il client CQL Bigtable nativo per Java.

Le specifiche della riconfigurazione del proxy ZDM per il passaggio non rientrano in questo codelab di base, ma sono descritte in dettaglio nella documentazione di Datastax ZDM.

10. Esegui la pulizia

Per evitare addebiti, elimina le risorse create durante questo codelab.

1. Eliminare le VM di Compute Engine

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

2. Eliminare un'istanza Bigtable

gcloud bigtable instances delete zdmbigtable

3. Elimina le regole firewall

gcloud compute firewall-rules delete allow-migration-internal

4. Elimina il database Cassandra (se installato localmente o persistente)

Se hai installato Cassandra al di fuori di una VM Compute Engine creata qui, segui i passaggi appropriati per rimuovere i dati o disinstallare Cassandra.

11. Complimenti!

Hai completato la procedura di configurazione di un percorso di migrazione basato su proxy da Apache Cassandra a Bigtable.

Hai imparato a:

Esegui il deployment di Cassandra e Bigtable.

• Configura il proxy Cassandra-Bigtable per la compatibilità con CQL.
• Esegui il deployment di Datastax ZDM Proxy per gestire le doppie scritture e il traffico.
• Utilizza Cassandra Data Migrator per spostare i dati storici.

Questo approccio consente migrazioni con tempi di inattività minimi e senza modifiche al codice sfruttando il livello proxy.

Passaggi successivi

• Esplora la documentazione di Bigtable
• Consulta la documentazione di Datastax ZDM Proxy per configurazioni avanzate e procedure di passaggio.
• Per ulteriori dettagli, consulta il repository Cassandra-Bigtable Proxy.
• Controlla il repository di Cassandra Data Migrator per l'utilizzo avanzato.
• Prova altri codelab Google Cloud