Миграция с 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) Proxy: прокси-сервер с открытым исходным кодом, который находится между вашим приложением и службами баз данных (исходная база данных Cassandra, целевая база данных Bigtable через прокси Cassandra-Bigtable). Он организует двойную запись и управляет маршрутизацией трафика, обеспечивая миграцию с минимальными изменениями в приложении и временем простоя.
3. Cassandra Data Migrator (CDM): инструмент с открытым исходным кодом, используемый для массовой миграции исторических данных из исходного кластера Cassandra в целевой экземпляр Bigtable.

Что вы узнаете

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

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

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

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

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

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

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

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.

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

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"

Подключитесь к вашему экземпляру Cassandra по SSH.

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

2. Установите 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. Настройка Cassandra

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

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

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-адрес этой виртуальной машины (hostname -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"

Подключитесь к виртуальной машине bigtable-proxy по SSH:

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-адрес этой виртуальной машины (hostname -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-proxy. Обратите внимание, что мы установили более длительный, чем по умолчанию, таймаут запроса, чтобы гарантировать, что у Bigtable будет достаточно времени для создания базовой таблицы. Вы должны увидеть сообщение «Подключено к 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 Proxy, но для миграции в рабочую среду вам потребуется многоузловая конфигурация.

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 Proxy (например, :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 и открыв редактор запросов 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).

Подключитесь к виртуальной машине cdm-migrator-vm по SSH:

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. Эта команда указывает Spark запустить JAR-файл CDM, используя ваш файл свойств и указав пространство ключей и таблицу для миграции. Настройте параметры памяти (–driver-memory, –executor-memory) в зависимости от размера вашей виртуальной машины и объема данных.

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

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

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 Proxy переход на новую систему включает в себя перенастройку системы таким образом, чтобы она читала преимущественно из целевого источника (Bigtable), а не из исходного (Cassandra). Обычно это делается через конфигурацию ZDM Proxy, что фактически перенаправляет трафик чтения вашего приложения на Bigtable.

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

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

Подробности переконфигурации ZDM Proxy при переходе на новую систему выходят за рамки этого базового практического занятия, но изложены в документации 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 Codelabs.