О практической работе
1. Введение
Bigtable — это полностью управляемый высокопроизводительный сервис баз данных NoSQL, предназначенный для больших аналитических и операционных нагрузок. Миграция с существующих баз данных, таких как Apache Cassandra, на Bigtable часто требует тщательного планирования, чтобы минимизировать время простоя и влияние на приложение.
В этой кодовой лаборатории демонстрируется стратегия миграции с Cassandra на Bigtable с использованием комбинации прокси-инструментов:
- Прокси-сервер Cassandra-Bigtable: позволяет клиентам и инструментам Cassandra (например,
cqlshили драйверам) взаимодействовать с Bigtable с использованием протокола языка запросов Cassandra (CQL) путем перевода запросов. - Прокси-сервер Datastax Zero Downtime Migration (ZDM): прокси-сервер с открытым исходным кодом, который находится между вашим приложением и службами базы данных (исходный Cassandra и целевой Bigtable через прокси-сервер Cassandra-Bigtable). Он организует двойную запись и управляет маршрутизацией трафика, обеспечивая миграцию с минимальными изменениями приложений и временем простоя.
- 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или используйте Google Cloud Shell .
В этой лаборатории кода мы в основном будем использовать виртуальные машины (ВМ) на Compute Engine в одной сети и регионе VPC, чтобы упростить работу в сети. Рекомендуется использовать внутренние IP-адреса.
2. Настройте свою среду
1. Выберите или создайте проект Google Cloud.
Перейдите в Google Cloud Console и выберите существующий проект или создайте новый. Запишите свой идентификатор проекта .
2. Включите необходимые API.
Убедитесь, что API Compute Engine и API Bigtable включены для вашего проекта.
gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>
Замените фактическим идентификатором проекта.
3. Выберите регион и зону
Выберите регион и зону для ваших ресурсов. В качестве примеров мы будем использовать 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
4. Настройте правила брандмауэра.
Нам нужно разрешить связь между нашими виртуальными машинами в сети VPC по умолчанию на нескольких портах:
- Порт Cassandra/Proxies CQL: 9042
- Порт проверки работоспособности прокси-сервера ZDM: 14001
- СШ: 22
Создайте правило брандмауэра, чтобы разрешить внутренний трафик через эти порты. Мы будем использовать тег cassandra-migration , чтобы легко применить это правило к соответствующим виртуальным машинам.
gcloud compute firewall-rules create allow-migration-internal \ --network=default \ --action=ALLOW \ --rules=tcp:22,tcp:9042,tcp:14001 \ --source-ranges=10.128.0.0/9 # Adjust if using a custom VPC/IP range \ --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-2004-lts \ --image-project=ubuntu-os-cloud \ --tags=cassandra-migration \ --boot-disk-size=20GB
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](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](https://downloads.apache.org/cassandra/KEYS) | sudo apt-key add - # Install Cassandra sudo apt-get update sudo apt-get install -y cassandra
3. Создайте пространство ключей и таблицу.
Мы будем использовать пример таблицы сотрудников и создадим пространство ключей под названием «zdmbigtable».
cd ~/apache-cassandra bin/cqlsh <your-localhost-ip? 9042 #starts the cql shell
Внутри 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 (цель)
Продолжительность 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 compute instances create bigtable-proxy-vm \ --machine-type=e2-medium \ --image-family=ubuntu-2004-lts \ --image-project=ubuntu-os-cloud \ --tags=cassandra-migration \ --boot-disk-size=20GB
SSH в bigtable-proxy-vm:
gcloud compute ssh bigtable-proxy-vm
Внутри виртуальной машины:
# Install Git and Go sudo apt-get update sudo apt-get install -y git golang-go # Clone the proxy repository # Replace with the actual repository URL if different git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git cd cassandra-to-bigtable-proxy/ # Set Go environment variables export GOPATH=$HOME/go export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
2. Настройте прокси
nano config.yaml
Обновите следующие переменные. Для более сложной настройки используйте этот пример, представленный на GitHub.
#!/bin/bash
cassandraToBigtableConfigs:
# Global default GCP Project ID
projectId: <your-project-id>
listeners:
- name: cluster1
port: 9042
bigtable:
#If you want to use multiple instances then pass the instance names by comma seperated
#Instance name should not contain any special characters except underscore(_)
instanceIds: zdmbigtable
# Number of grpc channels to be used for Bigtable session.
Session:
grpcChannels: 4
otel:
# Set enabled to true or false for OTEL metrics/traces/logs.
enabled: False
# Name of the collector service to be setup as a sidecar
serviceName: cassandra-to-bigtable-otel-service
healthcheck:
# Enable the health check in this proxy application config only if the
# "health_check" extension is added to the OTEL collector service configuration.
#
# Recommendation:
# Enable the OTEL health check if you need to verify the collector's availability
# at the start of the application. For development or testing environments, it can
# be safely disabled to reduce complexity.
# Enable/Disable Health Check for OTEL, Default 'False'.
enabled: False
# Health check endpoint for the OTEL collector service
endpoint: localhost:13133
metrics:
# Collector service endpoint
endpoint: localhost:4317
traces:
# Collector service endpoint
endpoint: localhost:4317
#Sampling ratio should be between 0 and 1. Here 0.05 means 5/100 Sampling ratio.
samplingRatio: 1
loggerConfig:
# Specifies the type of output, here it is set to 'file' indicating logs will be written to a file.
# Value of `outputType` should be `file` for file type or `stdout` for standard output.
# Default value is `stdout`.
outputType: stdout
# Set this only if the outputType is set to `file`.
# The path and name of the log file where logs will be stored. For example, output.log, Required Key.
# Default `/var/log/cassandra-to-spanner-proxy/output.log`.
fileName: output/output.log
# Set this only if the outputType is set to `file`.
# The maximum size of the log file in megabytes before it is rotated. For example, 500 for 500 MB.
maxSize: 10
# Set this only if the outputType is set to `file`.
# The maximum number of backup log files to keep. Once this limit is reached, the oldest log file will be deleted.
maxBackups: 2
# Set this only if the outputType is set to `file`.
# The maximum age in days for a log file to be retained. Logs older than this will be deleted. Required Key.
# Default 3 days
maxAge: 1
# Set this only if the outputType is set to `file`.
# Default value is set to 'False'. Change the value to 'True', if log files are required to be compressed.
compress: True
Сохраните и закройте файл (ctrl+X, затем Y, затем Enter в nano).
3. Запустите прокси-сервер Cassandra-Bigtable.
Запустите прокси-сервер.
# At the root of the cassandra-to-bigtable-proxy directory go run proxy.go
Прокси-сервер запустится и прослушивает порт 9042 на предмет входящих соединений CQL. Продолжайте работу этого терминального сеанса. Запишите IP-адрес этой виртуальной машины (имя хоста -I).
4. Создать таблицу через CQL
Подключите cqlsh к IP-адресу виртуальной машины Cassandra-Bigtable Proxy.
В cqlsh выполните следующую команду
-- 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
);
Убедитесь в Google Cloud Console, что таблица сотрудников и таблица метаданных существуют в вашем экземпляре Bigtable.
6. Настройте прокси-сервер ZDM
Для прокси-сервера ZDM требуется как минимум две машины: один или несколько прокси-узлов, которые обрабатывают трафик, и «Jumphost», используемый для развертывания и оркестрации через Ansible.
1. Создайте виртуальные машины Compute Engine для прокси-сервера ZDM.
Нам нужны две виртуальные машины: zdm-proxy-jumphost и zdm-proxy-node-1.
# Jumphost VM gcloud compute instances create zdm-jumphost \ --machine-type=e2-medium \ --image-family=ubuntu-2004-lts \ --image-project=ubuntu-os-cloud \ --tags=cassandra-migration \ --boot-disk-size=20GB # Proxy Node VM gcloud compute instances create zdm-proxy-node-1 \ --machine-type=e2-standard-8 \ --image-family=ubuntu-2004-lts \ --image-project=ubuntu-os-cloud \ --tags=cassandra-migration \ --boot-disk-size=20GB
Запишите IP-адреса обеих виртуальных машин.
2. Подготовьте JumpHost
SSH для подключения к zdm-jumphost
gcloud compute ssh zdm-jumphost
# Install Git and Ansible
sudo apt-get update
sudo apt-get install -y git ansible
Внутри прыжкового хоста
git clone https:\/\/github.com/datastax/zdm-proxy-automation.git
cd zdm-proxy-automation/ansible/
Отредактируйте основной файл конфигурации vars/zdm_proxy_cluster_config.yml:
Обновите origin_contact_points и target_contact_points, указав внутренние IP-адреса вашей виртуальной машины Cassandra и виртуальной машины Cassandra-Bigtable Proxy соответственно. Оставьте аутентификацию закомментированной, так как мы ее не настроили.
##############################
#### ORIGIN CONFIGURATION ####
##############################
## Origin credentials (leave commented if no auth)
# origin_username: ...
# origin_password: ...
## Set the following two parameters only if Origin is a self-managed, non-Astra cluster
origin_contact_points: <Your-Cassandra-VM-Internal-IP> # Replace!
origin_port: 9042
##############################
#### TARGET CONFIGURATION ####
##############################
## Target credentials (leave commented if no auth)
# target_username: ...
# target_password: ...
## Set the following two parameters only if Target is a self-managed, non-Astra cluster
target_contact_points: <Your-Bigtable-Proxy-VM-Internal-IP> # Replace!
target_port: 9042
# --- Other ZDM Proxy settings can be configured below ---
# ... (keep defaults for this codelab)
Сохраните и закройте этот файл.
3. Разверните прокси-сервер ZDM с помощью Ansible.
Запустите плейбук Ansible из каталога ansible на jumphost:
ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory
Эта команда установит необходимое программное обеспечение (например, Docker) на прокси-узле (zdm-proxy-node-1), извлечет образ ZDM Proxy Docker и запустит прокси-контейнер с предоставленной вами конфигурацией.
4. Проверьте работоспособность прокси-сервера ZDM.
Проверьте конечную точку готовности прокси-сервера ZDM, работающего на zdm-proxy-node-1 (порт 14001), с Jumphost:
# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl -G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness
Вы должны увидеть вывод, аналогичный этому, указывающий, что и источник (Cassandra), и цель (Cassandra-Bigtable Proxy) работают:
{
"OriginStatus": {
"Addr": "<Your-Cassandra-VM-Internal-IP>:9042",
"CurrentFailureCount": 0,
"FailureCountThreshold": 1,
"Status": "UP"
},
"TargetStatus": {
"Addr": "<Your-Bigtable-Proxy-VM-Internal-IP>:9042",
"CurrentFailureCount": 0,
"FailureCountThreshold": 1,
"Status": "UP"
},
"Status": "UP"
}
7. Настройте приложение и запустите двойную запись
Продолжительность 0:05
На этом этапе реальной миграции вы должны перенастроить свои приложения, чтобы они указывали на IP-адрес прокси-узла ZDM (например, :9042) вместо прямого подключения к Cassandra.
Как только приложение подключается к прокси-серверу ZDM: операции чтения по умолчанию выполняются из источника (Cassandra). Записи отправляются как в источник (Cassandra), так и в цель (Bigtable, через прокси-сервер Cassandra-Bigtable). Это позволяет вашему приложению продолжать нормально функционировать, обеспечивая одновременную запись новых данных в обе базы данных. Вы можете проверить соединение, используя cqlsh, указанный на прокси-сервере ZDM с Jumphost или другой виртуальной машины в сети:
Cqlsh <zdm-proxy-node-1-ip-address> 9042
Попробуйте вставить некоторые данные:
INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true);
SELECT * FROM employee WHERE name = 'Alice';
Эти данные должны быть записаны как в Cassandra, так и в Bigtable. Вы можете подтвердить это в Bigtable, перейдя в консоль Google Cloud и открыв редактор запросов Bigtable для своего экземпляра. Запустите запрос «SELECT * FROM сотрудника», и недавно вставленные данные должны стать видимыми.
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-2004-lts \ --image-project=ubuntu-os-cloud \ --tags=cassandra-migration \ --boot-disk-size=40GB
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](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
export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13
export PATH=$PATH:$SPARK_HOME/bin
3. Загрузите Cassandra Data Migrator.
Загрузите файл jar инструмента CDM. Проверьте страницу выпуска Cassandra Data Migrator на GitHub, чтобы найти правильный URL-адрес нужной версии.
# Example using version 5.2.2 - replace URL if needed
wget https://github.com/datastax/cassandra-data-migrator/releases/download/v5.2.2/cassandra-data-migrator-5.2.2.jar)
4. Настройте CDM
Создайте файл свойств с именем cdm.properties.
Nano cdm.properties
Вставьте следующую конфигурацию, заменив IP-адреса и отключив функции TTL/Writetime, поскольку они не поддерживаются Bigtable напрямую таким же образом. Оставьте авторизацию закомментированной.
# Origin Cassandra Connection
spark.cdm.connect.origin.host <Your-Cassandra-VM-IP-Address> # Replace!
spark.cdm.connect.origin.port 9042
spark.cdm.connect.origin.username cassandra # Leave default, or set if auth is enabled #
spark.cdm.connect.origin.password cassandra # Leave default, or set if auth is enabled #
# Target Bigtable (via Cassandra-Bigtable Proxy)
Connection spark.cdm.connect.target.host <Your-Bigtable-Proxy-VM-IP-Address> # Replace!
spark.cdm.connect.target.port 9042
spark.cdm.connect.target.username cassandra # Leave default, or set if auth is enabled #
spark.cdm.connect.target.password cassandra # Leave default, or set if auth is enabled #
# Disable TTL/Writetime features (Important for Bigtable compatibility via Proxy)
spark.cdm.feature.origin.ttl.automatic false
spark.cdm.feature.origin.writetime.automatic false
spark.cdm.feature.target.ttl.automatic false
spark.cdm.feature.target.writetime.automatic false
Сохраните и закройте файл.
5. Запустите задание миграции.
Выполните миграцию с помощью искровой отправки. Эта команда сообщает Spark запустить JAR-файл CDM, используя ваш файл свойств и указав пространство ключей и таблицу для миграции. Настройте параметры памяти (–driver-memory, –executor-memory) в зависимости от размера вашей виртуальной машины и объема данных.
Убедитесь, что вы находитесь в каталоге, содержащем jar-файл CDM и файл свойств. Замените «cassandra-data-migrator-5.2.2.jar», если вы загрузили другую версию.
./spark-3.5.3-bin-hadoop3-scala2.13/bin/spark-submit \ --properties-file cdm.properties \ --master "local[*]" \ --driver-memory 4G \ --executor-memory 4G \ --class com.datastax.cdm.job.Migrate \ cassandra-data-migrator-5.2.2.jar &> cdm_migration_$(date +%Y%m%d_%H%M).log
Миграция будет выполняться в фоновом режиме, а журналы будут записываться в cdm_migration_... .log. Отслеживайте файл журнала на предмет прогресса и любых ошибок:
tail -f cdm_migration_*.log
6. Проверка переноса данных
После успешного завершения задания CDM убедитесь, что исторические данные существуют в Bigtable. Поскольку прокси-сервер Cassandra-Bigtable разрешает чтение CQL, вы снова можете использовать cqlsh, подключенный к прокси-серверу ZDM (который направляет чтение в целевой объект после миграции или может быть настроен для этого) или непосредственно к прокси-серверу Cassandra-Bigtable для запроса данных. Подключитесь через ZDM-прокси:
cqlsh <zdm-proxy-node-1-ip-address> 9042
Внутри cqlsh:
SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin SELECT * FROM employee LIMIT 10; -- Check some sample data
Альтернативно можно использовать инструмент cbt (если он установлен на виртуальной машине CDM или Cloud Shell) для поиска данных непосредственно в Bigtable:
# First, install cbt if needed
# gcloud components update
# gcloud components install cbt
# Then lookup a specific row (replace 'some_employee_name' with an actual primary key)
cbt -project $PROJECT_ID -instance zdmbigtable lookup employee some_employee_name
9. Переключение (концептуальное)
После тщательной проверки согласованности данных между Cassandra и Bigtable вы можете приступить к окончательному переключению.
При использовании прокси-сервера ZDM переключение включает его перенастройку для чтения в первую очередь из цели (Bigtable), а не из источника (Cassandra). Обычно это делается с помощью конфигурации ZDM Proxy, эффективно перемещая трафик чтения вашего приложения на Bigtable.
Если вы уверены, что Bigtable корректно обслуживает весь трафик, вы сможете:
- Остановите двойную запись, перенастроив прокси-сервер ZDM.
- Выведите из эксплуатации исходный кластер Cassandra.
- Удалите прокси-сервер ZDM и подключите приложение напрямую к прокси-серверу Cassandra-Bigtable или используйте собственный клиент Bigtable CQL для Java.
Особенности реконфигурации прокси-сервера ZDM для переключения выходят за рамки этой базовой лаборатории, но подробно описаны в документации Datastax ZDM.
10. Очистить
Чтобы избежать дополнительных расходов, удалите ресурсы, созданные во время этой лаборатории.
1. Удалите виртуальные машины Compute Engine.
gcloud compute instances delete cassandra-origin-vm zdm-proxy-jumphost zdm-proxy-node-1 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 для управления двойной записью и трафиком.
- Используйте Cassandra Data Migrator для перемещения исторических данных.
Этот подход позволяет осуществлять миграцию с минимальным временем простоя и без изменений кода за счет использования уровня прокси.
Следующие шаги
- Изучите документацию Bigtable
- Дополнительные сведения о расширенных конфигурациях и процедурах переключения см. в документации Datastax ZDM Proxy.
- Для получения более подробной информации просмотрите репозиторий Cassandra-Bigtable Proxy.
- Проверьте репозиторий Cassandra Data Migrator для расширенного использования.
- Попробуйте другие лаборатории Google Cloud Codelab