Migracja z Cassandra do Bigtable z wykorzystaniem proxy z podwójnym zapisem

1. Wprowadzenie

Bigtable to w pełni zarządzana, wydajna usługa baz danych NoSQL zaprojektowana do obsługi dużych obciążeń związanych z analizami i operacjami. Migracja z dotychczasowych baz danych, takich jak Apache Cassandra, do Bigtable często wymaga starannego planowania, aby zminimalizować przestoje i wpływ na aplikację.

Te ćwiczenia z programowania pokazują strategię migracji z Cassandry do Bigtable przy użyciu kombinacji narzędzi proxy:

1. Proxy Cassandra-Bigtable: umożliwia klientom i narzędziom Cassandra (np. cqlsh lub sterownikom) interakcję z Bigtable za pomocą protokołu Cassandra Query Language (CQL) przez tłumaczenie zapytań.
2. Serwer proxy Datastax Zero Downtime Migration (ZDM): serwer proxy typu open source, który znajduje się między aplikacją a usługami baz danych (źródłową bazą danych Cassandra i docelową bazą danych Bigtable za pomocą serwera proxy Cassandra-Bigtable). Orkiestruje zapisywanie w dwóch miejscach i zarządza routingiem ruchu, umożliwiając migrację przy minimalnych zmianach w aplikacji i minimalnym czasie przestoju.
3. Cassandra Data Migrator (CDM): narzędzie open source służące do zbiorczej migracji danych historycznych z źródłowego klastra Cassandra do docelowej instancji Bigtable.

Czego się nauczysz

• Jak skonfigurować podstawowy klaster Cassandra w Compute Engine.
• Jak utworzyć instancję Bigtable.
• Jak wdrożyć i skonfigurować serwer proxy Cassandra-Bigtable, aby mapować schemat Cassandra na Bigtable.
• Jak wdrożyć i skonfigurować serwer proxy Datastax ZDM do podwójnego zapisu.
• Jak używać narzędzia Cassandra Data Migrator do migracji zbiorczej istniejących danych.
• Ogólny proces migracji z Cassandra do Bigtable opartej na serwerze proxy.

Czego potrzebujesz

• Projekt Google Cloud z włączonymi płatnościami. Nowi użytkownicy mogą skorzystać z bezpłatnego okresu próbnego.
• Podstawowa znajomość pojęć związanych z Google Cloud, takich jak projekty, Compute Engine, sieci VPC i reguły zapory sieciowej. Podstawowa znajomość narzędzi wiersza poleceń w systemie Linux.
• Dostęp do maszyny z zainstalowanym i skonfigurowanym interfejsem gcloud lub użyj Google Cloud Shell.

W tym laboratorium będziemy używać głównie maszyn wirtualnych w Compute Engine w tej samej sieci VPC i regionie, aby uprościć obsługę sieci. Zalecamy używanie wewnętrznych adresów IP.

2. Konfigurowanie środowiska

1. Wybieranie lub tworzenie projektu Google Cloud

Otwórz konsolę Google Cloud i wybierz istniejący projekt lub utwórz nowy. Zanotuj identyfikator projektu.

2. Wybieranie regionu i strefy

Wybierz region i strefę zasobów. Jako przykładów użyjemy regionu us-central1 i strefy us-central1-c. Aby ułatwić sobie pracę, zdefiniuj je jako zmienne środowiskowe:

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. Włącz wymagane interfejsy API

Sprawdź, czy w projekcie są włączone interfejsy Compute Engine API i Bigtable API.

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

4. Konfigurowanie reguł zapory sieciowej

Musimy zezwolić na komunikację między naszymi maszynami wirtualnymi w domyślnej sieci VPC na kilku portach:

• Port CQL Cassandra/serwery proxy: 9042
• Port kontroli stanu serwera proxy ZDM: 14001
• SSH: 22

Utwórz regułę zapory sieciowej, która zezwala na ruch wewnętrzny na tych portach. Użyjemy tagu cassandra-migration, aby łatwo zastosować tę regułę do odpowiednich maszyn wirtualnych.

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. Wdrażanie klastra Cassandra (źródło)

W tych ćwiczeniach z programowania skonfigurujemy prosty, jednowęzłowy klaster Cassandra w Compute Engine. W rzeczywistym scenariuszu połączysz się z istniejącym klastrem.

1. Tworzenie maszyny wirtualnej GCE na potrzeby 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"

Łączenie się z instancją Cassandra przez SSH

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

2. Instalowanie systemu 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. Konfigurowanie Cassandra

Musimy skonfigurować Cassandrę tak, aby była dostępna w sieci prywatnej.

Pobierz prywatny adres IP cassandra-origin, uruchamiając to polecenie:

hostname -I

Edytuj konfigurację Cassandry. Nie musisz dodawać żadnych nowych wierszy konfiguracji – wystarczy zaktualizować te, które już istnieją:

sudo vim /etc/cassandra/cassandra.yaml

1. Ustaw wartość seed_provider.parameters.seeds na "CASSANDRA_ORIGIN_PRIVATE_IP:7000"
2. Ustaw wartość rpc_address na CASSANDRA_ORIGIN_PRIVATE_IP
3. Ustaw wartość listen_address na CASSANDRA_ORIGIN_PRIVATE_IP

Zapisz plik.

Na koniec uruchom ponownie Cassandrę, aby wczytać zmiany konfiguracji:

sudo systemctl restart cassandra

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

4. Tworzenie przestrzeni kluczy i tabeli

Użyjemy przykładowej tabeli pracowników i utworzymy przestrzeń kluczy o nazwie „zdmbigtable”.

Uwaga: zanim Cassandra zacznie akceptować połączenia, może minąć minuta.

# Start cqlsh
cqlsh $(hostname -I)

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

Pozostaw sesję SSH otwartą lub zanotuj adres IP tej maszyny wirtualnej (hostname -I).

4. Konfigurowanie Bigtable (miejsce docelowe)

Czas trwania 0:01

Utwórz instancję Bigtable. Jako identyfikatora instancji użyjemy zdmbigtable.

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

Sama tabela Bigtable zostanie utworzona później przez skrypt konfiguracji serwera proxy Cassandra-Bigtable.

5. Konfigurowanie proxy Cassandra-Bigtable

1. Tworzenie maszyny wirtualnej Compute Engine na potrzeby serwera 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"

Połącz się z maszyną wirtualną bigtable-proxy-vm przez SSH:

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

Na maszynie wirtualnej bigtable-proxy-vm wykonaj te czynności:

# 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. Uruchamianie serwera proxy Cassandra-Bigtable

Uruchom serwer 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)

Serwer proxy uruchomi się i będzie nasłuchiwać na porcie 9042 przychodzących połączeń CQL. Utrzymuj aktywność tej sesji terminala. Zapisz adres IP tej maszyny wirtualnej (hostname -I).

3. Tworzenie tabeli za pomocą CQL

Połącz CQLSH z adresem IP maszyny wirtualnej proxy Cassandra-Bigtable. Adres IP możesz znaleźć, uruchamiając lokalnie to polecenie:

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

W osobnym oknie połącz się przez SSH z maszyną wirtualną cassandra-origin i użyj cqlsh do bigtable-proxy. Pamiętaj, że ustawiamy dłuższy niż domyślny limit czasu żądania, aby Bigtable miał wystarczająco dużo czasu na utworzenie tabeli bazowej. Powinien pojawić się komunikat „Connected to cassandra-bigtable-proxy-v0.2.3” lub podobny, co oznacza, że połączenie zostało nawiązane z serwerem proxy Bigtable, a nie z lokalnym serwerem Cassandra.

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

W CQLSH sprawdź, czy tabela została utworzona, uruchamiając to polecenie:

DESC TABLE zdmbigtable.employee;

6. Konfigurowanie serwera proxy ZDM

Na potrzeby tego modułu utworzymy jedną instancję serwera proxy ZDM, ale w przypadku migracji produkcyjnej będziesz potrzebować konfiguracji wielowęzłowej.

1. Tworzenie maszyny wirtualnej serwera 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

Zapisz adresy IP obu maszyn wirtualnych.

2. Przygotowywanie serwera 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. Konfigurowanie aplikacji i uruchamianie podwójnego zapisu

Czas trwania: 0:05

Na tym etapie rzeczywistej migracji należy ponownie skonfigurować aplikacje, aby wskazywały adres IP maszyny wirtualnej serwera proxy ZDM (np. :9042) zamiast łączyć się bezpośrednio z Cassandrą.

Gdy aplikacja połączy się z serwerem proxy ZDM: odczyty są domyślnie obsługiwane ze źródła (Cassandra). Operacje zapisu są wysyłane zarówno do źródła (Cassandra), jak i do miejsca docelowego (Bigtable za pomocą serwera proxy Cassandra-Bigtable). Dzięki temu aplikacja może nadal działać normalnie, a nowe dane są zapisywane w obu bazach danych jednocześnie. Połączenie możesz przetestować za pomocą narzędzia cqlsh skierowanego na serwer proxy ZDM:

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

Spróbuj wstawić dane:

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;

Te dane powinny być zapisywane zarówno w Cassandrze, jak i w Bigtable. Możesz to sprawdzić w Bigtable. W tym celu otwórz konsolę Google Cloud i edytor zapytań Bigtable dla swojej instancji. Uruchom zapytanie „SELECT * FROM employee”, a ostatnio wstawione dane powinny być widoczne.

8. Migracja danych historycznych za pomocą narzędzia Cassandra Data Migrator

Gdy podwójne zapisywanie nowych danych jest aktywne, użyj narzędzia Cassandra Data Migrator (CDM), aby skopiować istniejące dane historyczne z Cassandry do Bigtable.

1. Tworzenie maszyny wirtualnej Compute Engine na potrzeby CDM

Ta maszyna wirtualna potrzebuje wystarczającej ilości pamięci dla Sparka.

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. Instalowanie wymagań wstępnych (Java 11, Spark)

Połącz się z maszyną wirtualną cdm-migrator-vm przez SSH:

gcloud compute ssh cdm-migrator-vm

W maszynie wirtualnej:

# 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. Pobieranie narzędzia Cassandra Data Migrator

W przeglądarce otwórz stronę pakietów CDM i skopiuj link do pliku .jar z panelu Zasoby. Jeśli wersja 5.4.0 nie jest dostępna, wybierz najbliższą wersję. Wklej link do poniższego polecenia i uruchom je w instancji cdm-migrator-vm, zachowując pojedyncze cudzysłowy wokół adresu URL.

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

Sprawdź, czy plik JAR został prawidłowo pobrany, skanując go za pomocą narzędzia jar. Powinna się wyświetlić długa lista plików „.class”.

jar tf cassandra-data-migrator.jar 

4. Dodawanie danych

Musimy dodać dane do migracji, zapisując je bezpośrednio w cassandra-origin (nie w 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. Uruchamianie zadania migracji

Przeprowadź migrację za pomocą polecenia spark-submit. To polecenie nakazuje Sparkowi uruchomienie pliku JAR CDM z użyciem pliku właściwości i określeniem przestrzeni kluczy oraz tabeli do migracji. Dostosuj ustawienia pamięci (–driver-memory, –executor-memory) do rozmiaru maszyny wirtualnej i ilości danych.

Upewnij się, że jesteś w katalogu zawierającym plik JAR i plik właściwości CDM.

Wskazówka: wewnętrzne adresy IP maszyn wirtualnych Cassandra i proxy możesz uzyskać, uruchamiając te polecenia na komputerze lokalnym:

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. Weryfikowanie migracji danych

Gdy zadanie CDM zostanie ukończone, sprawdź, czy dane historyczne znajdują się w Bigtable.

cqlsh <bigtable-proxy-vm-ip>

W cqlsh:

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

9. Przenoszenie (koncepcyjne)

Po dokładnym sprawdzeniu spójności danych między bazami Cassandra i Bigtable możesz przejść do ostatecznego przełączenia.

W przypadku serwera proxy ZDM przełączenie polega na ponownym skonfigurowaniu go tak, aby odczytywał dane głównie z miejsca docelowego (Bigtable), a nie z miejsca początkowego (Cassandra). Zwykle odbywa się to za pomocą konfiguracji serwera proxy ZDM, co powoduje przeniesienie ruchu odczytu aplikacji do Bigtable.

Gdy będziesz mieć pewność, że Bigtable obsługuje cały ruch prawidłowo, możesz:

• Zatrzymaj podwójne zapisywanie, ponownie konfigurując serwer proxy ZDM.
• Wycofaj pierwotny klaster Cassandra.
• Usuń serwer proxy ZDM i połącz aplikację bezpośrednio z serwerem proxy Cassandra-Bigtable lub użyj natywnego klienta Bigtable CQL dla Javy.

Szczegóły ponownej konfiguracji serwera proxy ZDM na potrzeby przełączenia wykraczają poza zakres tego podstawowego laboratorium, ale są szczegółowo opisane w dokumentacji DataStax ZDM.

10. Czyszczenie danych

Aby uniknąć obciążenia konta opłatami, usuń zasoby utworzone w ramach tego ćwiczenia z programowania.

1. Usuwanie maszyn wirtualnych Compute Engine

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

2. Usuwanie instancji Bigtable

gcloud bigtable instances delete zdmbigtable

3. Usuwanie reguł zapory sieciowej

gcloud compute firewall-rules delete allow-migration-internal

4. Usuń bazę danych Cassandra (jeśli jest zainstalowana lokalnie lub utrwalona).

Jeśli Cassandra została zainstalowana poza maszyną wirtualną Compute Engine utworzoną w tym miejscu, wykonaj odpowiednie czynności, aby usunąć dane lub odinstalować Cassandrę.

11. Gratulacje!

Udało Ci się przejść proces konfigurowania ścieżki migracji opartej na serwerze proxy z Apache Cassandra do Bigtable.

Dowiesz się, jak:

wdrożyć Cassandra i Bigtable;

• Skonfiguruj serwer proxy Cassandra-Bigtable pod kątem zgodności z CQL.
• Wdróż serwer proxy Datastax ZDM, aby zarządzać podwójnymi zapisami i ruchem.
• Do przeniesienia danych historycznych użyj narzędzia Cassandra Data Migrator.

To podejście umożliwia migrację przy minimalnym czasie przestoju i bez zmian w kodzie dzięki wykorzystaniu warstwy proxy.

Dalsze kroki

• Zapoznaj się z dokumentacją Bigtable
• Zaawansowane konfiguracje i procedury przełączania znajdziesz w dokumentacji serwera proxy ZDM Datastax.
• Więcej informacji znajdziesz w repozytorium serwera proxy Cassandra-Bigtable.
• Więcej informacji o zaawansowanym użyciu znajdziesz w repozytorium Cassandra Data Migrator.
• Wypróbuj inne ćwiczenia z programowania Google Cloud