Migração do Cassandra para o Bigtable com um proxy de gravação dupla

1. Introdução

O Bigtable é um serviço de banco de dados NoSQL de alto desempenho e totalmente gerenciado, projetado para grandes cargas de trabalho analíticas e operacionais. A migração de bancos de dados atuais, como o Apache Cassandra, para o Bigtable geralmente requer planejamento cuidadoso para minimizar o tempo de inatividade e o impacto no aplicativo.

Este codelab demonstra uma estratégia de migração do Cassandra para o Bigtable usando uma combinação de ferramentas de proxy:

1. Proxy do Cassandra-Bigtable:permite que clientes e ferramentas do Cassandra (como cqlsh ou drivers) interajam com o Bigtable usando o protocolo da linguagem de consulta do Cassandra (CQL) ao traduzir consultas.
2. Proxy de migração sem inatividade (ZDM) do Datastax:um proxy de código aberto que fica entre o aplicativo e os serviços de banco de dados (Cassandra de origem e Bigtable de destino pelo proxy Cassandra-Bigtable). Ele orquestra gravações duplas e gerencia o roteamento de tráfego, permitindo a migração com mudanças mínimas no aplicativo e tempo de inatividade.
3. Migrador de dados do Cassandra (CDM): uma ferramenta de código aberto usada para migrar em massa dados históricos do cluster de origem do Cassandra para a instância de destino do Bigtable.

O que você vai aprender

• Como configurar um cluster básico do Cassandra no Compute Engine.
• Como criar uma instância do Bigtable.
• Como implantar e configurar o proxy Cassandra-Bigtable para mapear um esquema do Cassandra para o Bigtable.
• Como implantar e configurar o proxy ZDM do DataStax para gravações duplas.
• Como usar a ferramenta Cassandra Data Migrator para migrar dados em massa.
• O fluxo de trabalho geral para uma migração do Cassandra para o Bigtable baseada em proxy.

O que é necessário

• Ter um projeto do Google Cloud com o faturamento ativado. Novos usuários podem fazer um teste sem custo financeiro.
• Conhecimento básico dos conceitos do Google Cloud, como projetos, Compute Engine, redes VPC e regras de firewall. Conhecimentos básicos das ferramentas de linha de comando do Linux.
• Acesso a uma máquina com a CLI gcloud instalada e configurada ou use o Google Cloud Shell.

Neste codelab, vamos usar principalmente máquinas virtuais (VMs) no Compute Engine na mesma rede VPC e região para simplificar a rede. Recomendamos usar endereços IP internos.

2. Configurar o ambiente

1. Selecionar ou criar um projeto do Google Cloud

Acesse o console do Google Cloud e selecione um projeto atual ou crie um novo. Anote o ID do projeto.

2. Escolher uma região e uma zona

Selecione uma região e uma zona para seus recursos. Vamos usar us-central1 e us-central1-c como exemplos. Defina-as como variáveis de ambiente para facilitar:

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. Ativar APIs obrigatórias

Verifique se as APIs Compute Engine e Bigtable estão ativadas no seu projeto.

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

4. Configurar regras de firewall

Precisamos permitir a comunicação entre as VMs na rede VPC padrão em várias portas:

• Porta CQL do Cassandra/proxies: 9042
• Porta de verificação de integridade do proxy da ZDM: 14001
• SSH: 22

Crie uma regra de firewall para permitir o tráfego interno nessas portas. Vamos usar uma tag cassandra-migration para aplicar facilmente essa regra às VMs relevantes.

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. Implantar cluster do Cassandra (origem)

Neste codelab, vamos configurar um cluster simples do Cassandra de nó único no Compute Engine. Em um cenário real, você se conectaria ao cluster atual.

1. Criar uma VM do GCE para o 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"

Acessar sua instância do Cassandra por SSH

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

2. Instalar o 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. Configurar o Cassandra

É preciso configurar o Cassandra para que ele possa ser acessado na rede privada.

Execute o seguinte comando para acessar o IP particular de cassandra-origin:

hostname -I

Edite a configuração do Cassandra. Não é necessário adicionar novas linhas de configuração, apenas atualizar as que já estão lá:

sudo vim /etc/cassandra/cassandra.yaml

1. Defina seed_provider.parameters.seeds como "CASSANDRA_ORIGIN_PRIVATE_IP:7000"
2. Defina rpc_address como CASSANDRA_ORIGIN_PRIVATE_IP
3. Defina listen_address como CASSANDRA_ORIGIN_PRIVATE_IP

Salve o arquivo.

Por fim, reinicie o Cassandra para carregar as mudanças de configuração:

sudo systemctl restart cassandra

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

4. Criar um keyspace e uma tabela

Vamos usar um exemplo de tabela de funcionários e criar um keyspace chamado "zdmbigtable".

Observação: pode levar um minuto para o Cassandra começar a aceitar conexões.

# Start cqlsh
cqlsh $(hostname -I)

Dentro do 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;

Deixe a sessão SSH aberta ou anote o endereço IP dessa VM (hostname -I).

4. Configurar o Bigtable (destino)

Duração: 0:01

Criar uma instância do Bigtable. Vamos usar zdmbigtable como o ID da instância.

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

A tabela do Bigtable será criada mais tarde pelo script de configuração do proxy Cassandra-Bigtable.

5. Configurar o proxy do Cassandra-Bigtable

1. Criar uma VM do Compute Engine para o proxy do 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"

Conecte-se por SSH à bigtable-proxy-vm:

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

Na bigtable-proxy-vm, execute:

# 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. Iniciar o proxy do Cassandra-Bigtable

Inicie o servidor 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)

O proxy vai iniciar e detectar na porta 9042 conexões CQL recebidas. Mantenha essa sessão de terminal em execução. Anote o endereço IP dessa VM (hostname -I).

3. Criar tabela usando CQL

Conecte o CQLSH ao endereço IP da VM proxy do Cassandra-Bigtable. Para encontrar o endereço IP, execute o seguinte comando localmente:

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

Em uma janela separada, faça SSH na VM cassandra-origin e use cqlsh no bigtable-proxy. Definimos um tempo limite de solicitação maior que o padrão para garantir que o Bigtable tenha tempo suficiente para criar a tabela subjacente. Você vai ver "Connected to cassandra-bigtable-proxy-v0.2.3" ou algo parecido, indicando que você se conectou ao proxy do Bigtable, e não ao servidor 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
);

No CQLSH, verifique se a tabela foi criada executando:

DESC TABLE zdmbigtable.employee;

6. Configurar o proxy do ZDM

Vamos criar uma única instância do proxy do ZDM para este laboratório, mas você vai querer uma configuração de vários nós para uma migração de produção.

1. Criar a VM do proxy do 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

Anote os endereços IP das duas VMs.

2. Preparar o proxy do 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. Configurar o aplicativo e iniciar gravações duplas

Duração: 0:05

Nesta etapa de uma migração real, você reconfiguraria os aplicativos para apontar para o endereço IP da VM do proxy ZDM (por exemplo, :9042) em vez de se conectar diretamente ao Cassandra.

Depois que o aplicativo se conecta ao proxy ZDM: as leituras são veiculadas da origem (Cassandra) por padrão. As gravações são enviadas para a origem (Cassandra) e o destino (Bigtable, via proxy Cassandra-Bigtable). Isso permite que o aplicativo continue funcionando normalmente, garantindo que novos dados sejam gravados nos dois bancos de dados simultaneamente. Teste a conexão usando cqlsh apontado para o proxy da ZDM:

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

Tente inserir alguns dados:

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;

Esses dados precisam ser gravados no Cassandra e no Bigtable. Para confirmar isso no Bigtable, acesse o Console do Google Cloud e abra o editor de consultas do Bigtable para sua instância. Execute uma consulta "SELECT * FROM employee", e os dados inseridos recentemente vão aparecer.

8. Migrar dados históricos usando o Cassandra Data Migrator

Agora que as gravações duplas estão ativas para novos dados, use a ferramenta Cassandra Data Migrator (CDM) para copiar os dados históricos atuais do Cassandra para o Bigtable.

1. Criar uma VM do Compute Engine para o CDM

Essa VM precisa de memória suficiente para o 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. Instalar pré-requisitos (Java 11, Spark)

Conecte-se por SSH à cdm-migrator-vm:

gcloud compute ssh cdm-migrator-vm

Na 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. Baixar o Cassandra Data Migrator

No navegador, abra a página de pacotes do CDM e copie o link .jar do painel "Assets". Se a versão 5.4.0 não estiver disponível, escolha a mais próxima. Cole o link no comando abaixo e execute-o na instância cdm-migrator-vm, preservando as aspas simples ao redor do URL.

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

Verifique se o arquivo JAR foi baixado corretamente. Para isso, faça uma verificação com a ferramenta jar. Uma longa lista de arquivos ".class" vai aparecer.

jar tf cassandra-data-migrator.jar 

4. Adicionar alguns dados

Precisamos adicionar alguns dados para migrar gravando diretamente no cassandra-origin (não no 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. Executar o job de migração

Execute a migração usando o spark-submit. Esse comando instrui o Spark a executar o jar do CDM usando o arquivo de propriedades e especificando o keyspace e a tabela a serem migrados. Ajuste as configurações de memória (–driver-memory, –executor-memory) com base no tamanho da VM e no volume de dados.

Verifique se você está no diretório que contém o arquivo JAR e o arquivo de propriedades do CDM.

Dica: para conferir o IP interno das VMs do Cassandra e do proxy, execute estes comandos na máquina local:

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. Verificar a migração de dados

Depois que o job do CDM for concluído, verifique se os dados históricos estão no Bigtable.

cqlsh <bigtable-proxy-vm-ip>

Dentro do cqlsh:

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

9. Substituição (conceitual)

Depois de verificar completamente a consistência dos dados entre o Cassandra e o Bigtable, você pode prosseguir com a transição final.

Com o proxy ZDM, a migração envolve a reconfiguração para ler principalmente do destino (Bigtable) em vez da origem (Cassandra). Isso geralmente é feito pela configuração do proxy ZDM, transferindo efetivamente o tráfego de leitura do aplicativo para o Bigtable.

Quando tiver certeza de que o Bigtable está atendendo a todo o tráfego corretamente, você poderá:

• Reconfigure o proxy do ZDM para interromper as gravações duplas.
• Desative o cluster original do Cassandra.
• Remova o proxy do ZDM e faça com que o aplicativo se conecte diretamente ao proxy do Cassandra-Bigtable ou use o cliente CQL nativo do Bigtable para Java.

Os detalhes da reconfiguração do proxy da ZDM para a migração estão além deste codelab básico, mas são detalhados na documentação da ZDM da Datastax.

10. Limpar

Para evitar cobranças, exclua os recursos criados durante este codelab.

1. Excluir VMs do Compute Engine

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

2. Excluir instância do Bigtable

gcloud bigtable instances delete zdmbigtable

3. Excluir regras de firewall

gcloud compute firewall-rules delete allow-migration-internal

4. Excluir o banco de dados do Cassandra (se instalado localmente ou persistido)

Se você instalou o Cassandra fora de uma VM do Compute Engine criada aqui, siga as etapas adequadas para remover os dados ou desinstalar o Cassandra.

11. Parabéns!

Você concluiu o processo de configuração de um caminho de migração baseado em proxy do Apache Cassandra para o Bigtable.

Você aprendeu a:

Implante o Cassandra e o Bigtable.

• Configure o proxy Cassandra-Bigtable para compatibilidade com CQL.
• Implante o proxy ZDM do DataStax para gerenciar gravações duplas e tráfego.
• Use o Cassandra Data Migrator para mover dados históricos.

Essa abordagem permite migrações com tempo de inatividade mínimo e sem mudanças no código usando a camada de proxy.

Próximas etapas

• Conheça a documentação do Bigtable
• Consulte a documentação do proxy ZDM da Datastax para configurações avançadas e procedimentos de migração.
• Consulte o repositório do proxy Cassandra-Bigtable para mais detalhes.
• Confira o repositório do Cassandra Data Migrator para uso avançado.
• Teste outros codelabs do Google Cloud