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 a client e strumenti Cassandra (come cqlsh o i driver) di interagire con Bigtable utilizzando il protocollo Cassandra Query Language (CQL) tramite la traduzione delle 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). Coordina le scritture doppie e gestisce il routing del traffico, consentendo la migrazione con modifiche e tempi di inattività minimi dell'applicazione.
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 hanno diritto a 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 Linux.
• Accesso a una macchina con la CLI 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 VPC e regione per semplificare il networking. È consigliabile 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. Scegli una regione e una zona

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

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. 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

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:7000,tcp:14001 \
--source-ranges=10.0.0.0/8 \
--target-tags=cassandra-migration

3. Esegui il deployment del cluster Cassandra (origine)

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-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB \
--scopes=cloud-platform \
--zone="$ZONE"

Accedi alla tua istanza di Cassandra tramite SSH

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

2. Installare 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. Configurare Cassandra

Dobbiamo configurare Cassandra in modo che sia accessibile all'interno della rete privata.

Recupera l'IP privato di cassandra-origin eseguendo:

hostname -I

Modifica la configurazione di Cassandra. Non dovresti dover aggiungere nuove righe di configurazione, ma solo aggiornare quelle già presenti:

sudo vim /etc/cassandra/cassandra.yaml

1. Imposta seed_provider.parameters.seeds su "CASSANDRA_ORIGIN_PRIVATE_IP:7000"
2. Imposta rpc_address su CASSANDRA_ORIGIN_PRIVATE_IP
3. Imposta listen_address su CASSANDRA_ORIGIN_PRIVATE_IP

Salva il file.

Infine, riavvia Cassandra per caricare le modifiche alla configurazione:

sudo systemctl restart cassandra

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

4. Crea uno spazio delle chiavi e una tabella

Utilizzeremo un esempio di tabella dei dipendenti e creeremo uno spazio delle chiavi denominato "zdmbigtable".

Nota: potrebbe essere necessario un minuto prima che Cassandra inizi ad accettare le connessioni.

# Start cqlsh
cqlsh $(hostname -I)

All'interno di 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 annota l'indirizzo IP di questa VM (hostname -I).

4. Configura Bigtable (destinazione)

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

5. Configurare il proxy Cassandra-Bigtable

1. Crea una VM di Compute Engine per il 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"

Accedi tramite SSH a bigtable-proxy-vm:

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

Sulla VM bigtable-proxy-vm esegui:

# 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. Avvia il proxy Cassandra-Bigtable

Avvia il server 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)

Il proxy verrà avviato e rimarrà in ascolto sulla porta 9042 per le connessioni CQL in entrata. Mantieni in esecuzione questa sessione del terminale. Prendi nota dell'indirizzo IP di questa VM (hostname -I)

3. Crea tabella tramite CQL

Connetti CQLSH all'indirizzo IP della VM proxy Cassandra-Bigtable. Puoi trovare l'indirizzo IP eseguendo questo comando localmente:

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

In una finestra separata, esegui SSH sulla VM cassandra-origin e utilizza cqlsh per bigtable-proxy. Tieni presente che abbiamo impostato un timeout della richiesta più lungo di quello predefinito per garantire che Bigtable abbia tempo sufficiente per creare la tabella sottostante. Dovresti visualizzare "Connected to cassandra-bigtable-proxy-v0.2.3" o un messaggio simile, che indica che ti sei connesso al proxy Bigtable e non al server Cassandra locale.

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

In CQLSH, verifica che la tabella sia stata creata eseguendo:

DESC TABLE zdmbigtable.employee;

6. Configurare il proxy ZDM

Per questo lab creeremo una singola istanza del proxy ZDM, ma per una migrazione di produzione ti consigliamo una configurazione multi-nodo.

1. Crea 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

Prendi nota degli indirizzi IP di entrambe le VM.

2. Prepara il 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. Configura l'applicazione e avvia la doppia scrittura

Durata 0:05

In questa fase di una migrazione reale, riconfigurerai le tue applicazioni in modo che puntino all'indirizzo IP della VM proxy ZDM (ad es. :9042) anziché connettersi direttamente a Cassandra.

Una volta che l'applicazione si connette al proxy ZDM: le letture vengono servite 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, la tua applicazione può continuare a funzionare normalmente, garantendo al contempo che i nuovi dati vengano scritti in entrambi i database contemporaneamente. Puoi testare la connessione utilizzando cqlsh indirizzato al proxy ZDM:

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

Prova a inserire alcuni dati:

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;

Questi dati devono essere scritti sia in Cassandra che in Bigtable. Puoi verificarlo in Bigtable andando alla console Google Cloud e aprendo l'editor di query Bigtable per la tua istanza. Esegui una query "SELECT * FROM employee" e i dati inseriti di recente dovrebbero essere visibili.

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

Ora che le scritture duali 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 di 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-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB \
--scopes=cloud-platform \
--zone=$ZONE

2. Installa i prerequisiti (Java 11, Spark)

Accedi tramite SSH a cdm-migrator-vm:

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
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. Scarica Cassandra Data Migrator

Nel browser, apri la pagina Pacchetti CDM e copia il link .jar dal riquadro Asset. Se la versione 5.4.0 non è disponibile, scegli la versione più vicina. Incolla il link nel comando riportato di seguito ed eseguilo sull'istanza cdm-migrator-vm, mantenendo le virgolette singole intorno all'URL.

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

Verifica che il file JAR sia stato scaricato correttamente eseguendo la scansione con lo strumento jar: dovresti visualizzare un lungo elenco di file ".class".

jar tf cassandra-data-migrator.jar 

4. Aggiungere alcuni dati

Dobbiamo aggiungere alcuni dati da migrare scrivendo direttamente in cassandra-origin (non in 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. Esegui il job di migrazione

Esegui la migrazione utilizzando spark-submit. Questo comando indica a Spark di eseguire il file JAR CDM, utilizzando il file delle proprietà e specificando lo spazio delle chiavi e la tabella da migrare. Modifica le impostazioni di 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.

Suggerimento: puoi ottenere l'IP interno delle VM Cassandra e proxy eseguendo questi comandi dalla tua macchina 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. Verificare la migrazione dei dati

Una volta completato correttamente il job CDM, verifica che i dati storici siano presenti in Bigtable.

cqlsh <bigtable-proxy-vm-ip>

All'interno di cqlsh:

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

9. Cutover (concettuale)

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

Con il proxy ZDM, il cutover prevede la riconfigurazione per la lettura principalmente dalla destinazione (Bigtable) anziché dall'origine (Cassandra). In genere, questa operazione viene eseguita tramite la configurazione del proxy ZDM, spostando di fatto il traffico di lettura dell'applicazione su Bigtable.

Quando hai la certezza che Bigtable gestisca correttamente tutto il traffico, puoi:

• Interrompi la doppia scrittura riconfigurando il proxy ZDM.
• Ritira il 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.

I dettagli della riconfigurazione del proxy ZDM per il cutover non rientrano in questo codelab di base, ma sono descritti in dettaglio nella documentazione di Datastax ZDM.

10. Esegui la pulizia

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

1. Elimina le VM di Compute Engine

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

2. Elimina istanza Bigtable

gcloud bigtable instances delete zdmbigtable

3. Elimina regole firewall

gcloud compute firewall-rules delete allow-migration-internal

4. Elimina il database Cassandra (se installato localmente o reso 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 del proxy ZDM di DataStax per gestire le scritture e il traffico doppi.
• 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 del proxy Datastax ZDM per configurazioni avanzate e procedure di cutover.
• Per ulteriori dettagli, consulta il repository del proxy Cassandra-Bigtable.
• Per un utilizzo avanzato, consulta il repository di Cassandra Data Migrator.
• Prova altri codelab per Google Cloud