Миграция с Cassandra на Bigtable с помощью прокси с двойной записью

1. Введение

Bigtable — это полностью управляемая, высокопроизводительная служба NoSQL-базы данных, разработанная для больших аналитических и операционных нагрузок. Миграция с существующих баз данных, таких как Apache Cassandra, на Bigtable часто требует тщательного планирования, чтобы минимизировать время простоя и влияние на работу приложений.

В этой лабораторной работе демонстрируется стратегия миграции с Cassandra на Bigtable с использованием комбинации прокси-инструментов:

1. Cassandra-Bigtable Proxy: позволяет клиентам и инструментам Cassandra (например, cqlsh или драйверам) взаимодействовать с Bigtable, используя протокол языка запросов Cassandra (CQL) путем преобразования запросов.
2. Прокси-сервер Datastax Zero Downtime Migration (ZDM): прокси-сервер с открытым исходным кодом, который располагается между вашим приложением и службами баз данных (исходной Cassandra и целевой Bigtable через прокси-сервер Cassandra-Bigtable). Он организует двойную запись и управляет маршрутизацией трафика, обеспечивая миграцию с минимальными изменениями в приложении и временем простоя.
3. Cassandra Data Migrator (CDM): инструмент с открытым исходным кодом, используемый для массовой миграции исторических данных из исходного кластера Cassandra в целевой экземпляр Bigtable.

Чему вы научитесь

• Как настроить базовый кластер Cassandra на Compute Engine.
• Как создать экземпляр Bigtable.
• Как развернуть и настроить прокси-сервер Cassandra-Bigtable для сопоставления схемы Cassandra с Bigtable.
• Как развернуть и настроить Datastax ZDM Proxy для двойной записи.
• Как использовать инструмент Cassandra Data Migrator для массовой миграции существующих данных.
• Общий рабочий процесс миграции Cassandra-to-Bigtable на основе прокси-сервера.

Что вам понадобится

• Проект Google Cloud с включенной оплатой. Новым пользователям предоставляется бесплатный пробный период .
• Базовое знакомство с концепциями Google Cloud, такими как проекты, Compute Engine, сети VPC и правила брандмауэра. Базовое знакомство с инструментами командной строки Linux.
• Получите доступ к машине с установленным и настроенным gcloud CLI или используйте Google Cloud Shell .

В этой лабораторной работе мы будем в первую очередь использовать виртуальные машины (ВМ) на Compute Engine в той же сети VPC и регионе для упрощения сетевых настроек. Рекомендуется использовать внутренние IP-адреса.

2. Настройте свою среду

1. Выберите или создайте проект Google Cloud.

Перейдите в Google Cloud Console и выберите существующий проект или создайте новый. Запишите идентификатор вашего проекта .

2. Выберите регион и зону

Выберите регион и зону для ваших ресурсов. В качестве примеров мы используем us-central1 и us-central1-c. Для удобства определите их как переменные среды:

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. Включите необходимые API.

Убедитесь, что для вашего проекта включены Compute Engine API и Bigtable API.

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

4. Настройте правила брандмауэра

Нам необходимо разрешить связь между нашими виртуальными машинами в сети VPC по умолчанию через несколько портов:

• Порт CQL Cassandra/Proxies: 9042
• Порт проверки работоспособности прокси-сервера ZDM: 14001
• SSH: 22

Создайте правило брандмауэра, разрешающее внутренний трафик через эти порты. Мы будем использовать тег cassandra-migration для простого применения этого правила к соответствующим виртуальным машинам.

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. Развертывание кластера Cassandra (Origin)

В этой лабораторной работе мы настроим простой кластер Cassandra с одним узлом на платформе Compute Engine. В реальном сценарии вам потребуется подключиться к существующему кластеру.

1. Создайте виртуальную машину GCE для 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"

SSH-подключение к вашему экземпляру Cassandra

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

2. Установите Кассандру

# 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. Настройте Cassandra

Нам необходимо настроить Cassandra для доступа в частной сети.

Получите частный IP-адрес cassandra-origin, выполнив:

hostname -I

Отредактируйте конфигурацию Cassandra. Вам не нужно добавлять никаких новых строк конфигурации — просто обновите те, которые уже есть:

sudo vim /etc/cassandra/cassandra.yaml

1. Установите для seed_provider.parameters.seeds значение "CASSANDRA_ORIGIN_PRIVATE_IP:7000"
2. Установите rpc_address на CASSANDRA_ORIGIN_PRIVATE_IP
3. Установите listen_address на CASSANDRA_ORIGIN_PRIVATE_IP

Сохраните файл.

Наконец, перезапустите Cassandra, чтобы загрузить изменения конфигурации:

sudo systemctl restart cassandra

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

4. Создайте пространство ключей и таблицу

Мы будем использовать пример таблицы сотрудников и создадим пространство ключей под названием «zdmbigtable».

Примечание: может потребоваться минута, прежде чем Cassandra начнет принимать подключения.

# Start cqlsh
cqlsh $(hostname -I)

Внутри 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;

Оставьте сеанс SSH открытым или запишите IP-адрес этой виртуальной машины (имя хоста -I).

4. Настройте Bigtable (Target)

Продолжительность 0:01

Создайте экземпляр Bigtable. В качестве идентификатора экземпляра будем использовать 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

Сама таблица Bigtable будет создана позже скриптом настройки Cassandra-Bigtable Proxy.

5. Настройте прокси-сервер Cassandra-Bigtable

1. Создайте виртуальную машину Compute Engine для прокси-сервера 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"

Подключитесь по SSH к bigtable-proxy-vm:

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

На bigtable-proxy-vm запустите:

# 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. Запустите прокси-сервер Cassandra-Bigtable.

Запустите прокси-сервер.

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

Прокси-сервер запустится и будет прослушивать порт 9042 на предмет входящих CQL-подключений. Не закрывайте этот терминальный сеанс. Запишите IP-адрес этой виртуальной машины (имя_хоста -I).

3. Создать таблицу через CQL

Подключите CQLSH к IP-адресу виртуальной машины Cassandra-Bigtable Proxy. Вы можете узнать IP-адрес, выполнив следующую команду локально:

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

В отдельном окне подключитесь по SSH к вашей виртуальной машине Cassandra-Origin и используйте cqlsh для доступа к прокси-серверу BigTable. Обратите внимание, что мы установили более длительное время ожидания запроса, чем по умолчанию, чтобы у BigTable было достаточно времени для создания базовой таблицы. Вы должны увидеть сообщение «Connected to cassandra-bigtable-proxy-v0.2.3» или подобное, что означает, что вы подключились к прокси-серверу BigTable, а не к локальному серверу 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
);

В CQLSH убедитесь, что ваша таблица создана, выполнив:

DESC TABLE zdmbigtable.employee;

6. Настройте прокси-сервер ZDM.

Для этой лабораторной работы мы создадим один экземпляр прокси-сервера ZDM, но для производственной миграции вам понадобится многоузловая конфигурация.

1. Создайте виртуальную машину ZDM Proxy

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

Обратите внимание на IP-адреса обеих виртуальных машин.

2. Подготовьте прокси-сервер 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. Настройте приложение и запустите двойную запись.

Продолжительность 0:05

На этом этапе реальной миграции вам необходимо перенастроить свои приложения так, чтобы они указывали на IP-адрес виртуальной машины прокси-сервера ZDM (например, :9042) вместо прямого подключения к Cassandra.

После подключения приложения к прокси-серверу ZDM: операции чтения по умолчанию выполняются из источника (Cassandra). Записи отправляются как в источник (Cassandra), так и в целевую базу (Bigtable) через прокси-сервер Cassandra-Bigtable. Это позволяет приложению продолжать работу в штатном режиме, обеспечивая одновременную запись новых данных в обе базы данных. Вы можете проверить соединение с помощью команды cqlsh, направленной на прокси-сервер ZDM:

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

Попробуйте ввести некоторые данные:

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;

Эти данные должны быть записаны как в Cassandra, так и в Bigtable. Вы можете убедиться в этом в Bigtable, перейдя в Google Cloud Console и открыв редактор запросов Bigtable для вашего экземпляра. Выполните запрос «SELECT * FROM employee», и недавно добавленные данные должны быть видны.

8. Перенесите исторические данные с помощью Cassandra Data Migrator.

Теперь, когда двойная запись активна для новых данных, используйте инструмент Cassandra Data Migrator (CDM) для копирования существующих исторических данных из Cassandra в Bigtable.

1. Создайте виртуальную машину Compute Engine для CDM

Этой виртуальной машине требуется достаточно памяти для 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. Установите необходимые компоненты (Java 11, Spark)

Подключитесь по SSH к cdm-migrator-vm:

gcloud compute ssh cdm-migrator-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. Загрузите Cassandra Data Migrator.

Откройте в браузере страницу «Пакеты CDM» и скопируйте ссылку на jar-файл из панели «Активы». Если версия 5.4.0 недоступна, выберите ближайшую. Вставьте ссылку в команду ниже и выполните её на экземпляре cdm-migrator-vm, сохранив одинарные кавычки вокруг URL-адреса.

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

Убедитесь, что jar-файл был загружен правильно, просканировав его с помощью инструмента jar : вы должны увидеть длинный список файлов «.class».

jar tf cassandra-data-migrator.jar 

4. Добавьте данные

Нам нужно добавить некоторые данные для миграции, записав их напрямую в cassandra-origin (не в 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. Запустите задание миграции.

Выполните миграцию с помощью spark-submit. Эта команда запустит JAR-файл CDM, используя ваш файл свойств и указав пространство ключей и таблицу для миграции. Настройте параметры памяти (–driver-memory, –executor-memory) в зависимости от размера вашей виртуальной машины и объёма данных.

Убедитесь, что вы находитесь в каталоге, содержащем файл CDM jar и файл свойств.

Совет: вы можете получить внутренний IP-адрес ваших виртуальных машин Cassandra и proxy, выполнив следующие команды с локальной машины:

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. Проверьте миграцию данных

После успешного завершения задания CDM проверьте наличие исторических данных в Bigtable.

cqlsh <bigtable-proxy-vm-ip>

Внутри cqlsh:

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

9. Переход (концептуальный)

После тщательной проверки согласованности данных между Cassandra и Bigtable можно приступать к окончательному переходу.

При использовании ZDM-прокси переключение включает в себя перенастройку на чтение преимущественно из целевого хранилища (Bigtable), а не из исходного хранилища (Cassandra). Обычно это делается через конфигурацию ZDM-прокси, фактически перенаправляя трафик чтения вашего приложения на Bigtable.

Как только вы убедитесь, что Bigtable корректно обслуживает весь трафик, вы сможете:

• Остановите двойную запись, перенастроив прокси-сервер ZDM.
• Вывести из эксплуатации исходный кластер Кассандра.
• Удалите прокси-сервер ZDM и подключите приложение напрямую к прокси-серверу Cassandra-Bigtable или используйте собственный клиент Bigtable CQL для Java.

Особенности перенастройки прокси-сервера ZDM для переключения выходят за рамки этой базовой кодовой лаборатории, но подробно описаны в документации Datastax ZDM.

10. Уборка

Во избежание дополнительных расходов удалите ресурсы, созданные в ходе этой лабораторной работы.

1. Удалить виртуальные машины Compute Engine

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

2. Удалить экземпляр Bigtable

gcloud bigtable instances delete zdmbigtable

3. Удалить правила брандмауэра

gcloud compute firewall-rules delete allow-migration-internal

4. Удалить базу данных Cassandra (если она установлена ​​локально или сохранена)

Если вы установили Cassandra вне созданной здесь виртуальной машины Compute Engine, выполните соответствующие шаги для удаления данных или удаления Cassandra.

11. Поздравляем!

Вы успешно завершили процесс настройки прокси-пути миграции с Apache Cassandra на Bigtable!

Вы узнали, как:

Развертывание Cassandra и Bigtable.

• Настройте прокси-сервер Cassandra-Bigtable для совместимости с CQL.
• Разверните Datastax ZDM Proxy для управления двойными записями и трафиком.
• Используйте Cassandra Data Migrator для перемещения исторических данных.

Такой подход позволяет осуществлять миграцию с минимальным временем простоя и без внесения изменений в код за счет использования прокси-слоя.

Следующие шаги

• Изучите документацию Bigtable
• Дополнительные сведения о настройках и процедурах переключения см. в документации по Datastax ZDM Proxy.
• Более подробную информацию можно найти в репозитории Cassandra-Bigtable Proxy.
• Для расширенного использования посетите репозиторий Cassandra Data Migrator.
• Попробуйте другие лабораторные работы Google Cloud