Compartir a través de

Migración en vivo a Azure Managed Instance for Apache Cassandra mediante un proxy de doble escritura

Siempre que sea posible, se recomienda usar la funcionalidad nativa de Apache Cassandra para migrar datos del clúster existente a Azure Managed Instance para Apache Cassandra mediante la configuración de un clúster híbrido. Esta funcionalidad utiliza el protocolo gossip de Apache Cassandra para replicar datos de un centro de datos de origen en un nuevo centro de datos de instancia administrada de forma fluida.

Es posible que haya algunos escenarios en los que la versión de la base de datos de origen no sea compatible o que una configuración de clúster híbrido no sea factible. En este tutorial se describe cómo migrar datos en vivo a Azure Managed Instance for Apache Cassandra mediante un proxy de doble escritura y Apache Spark. El proxy de doble escritura se usa para capturar cambios en directo, mientras que los datos históricos se copian en masa con Apache Spark. Las ventajas de este enfoque son:

  • Cambios mínimos en las aplicaciones. El proxy puede aceptar conexiones desde el código de las aplicaciones con pocos o ningún cambio de configuración. Enrutará todas las solicitudes a la base de datos de origen y, de forma asincrónica, enrutará las operaciones de escritura hacia un destino secundario.
  • Dependencia del protocolo de transferencia del cliente. Dado que este enfoque no depende de recursos back-end o protocolos internos, se puede usar con cualquier sistema Cassandra de origen o destino que implemente el protocolo de conexión de Apache Cassandra.

En la siguiente imagen, se ilustra este enfoque.

Animación que muestra la migración en vivo de datos a Azure Managed Instance for Apache Cassandra.

Requisitos previos

Aprovisionamiento de un clúster de Spark

Se recomienda seleccionar La versión 7.5 del entorno de ejecución de Azure Databricks, que admite Spark 3.0.

Recorte de pantalla que muestra la búsqueda de la versión en tiempo de ejecución de Azure Databricks.

Adición de dependencias de Spark

Debe agregar la biblioteca Apache Spark Cassandra Connector al clúster para conectarse a cualquier punto de conexión de Apache Cassandra compatible con el protocolo de conexión. En el clúster, seleccione Libraries>Install New>Maven (Bibliotecas > Instalar nueva > Maven) y, después, agregue com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 en las coordenadas de Maven.

Importante

Si tiene el requisito de conservar Apache Cassandra writetime para cada fila durante la migración, le recomendamos que utilice esta muestra. El archivo jar de dependencias de este ejemplo también contiene el conector de Spark, por lo que debe instalar esta versión en lugar del ensamblado del conector.

Este ejemplo también es útil si desea realizar una validación de comparación de filas entre el origen y el destino después de completar la carga de datos histórica. Consulte Ejecución de la carga de datos históricos y Validación del origen y el destino.

Recorte de pantalla que muestra la búsqueda de paquetes de Maven en Azure Databricks.

Seleccione Install (Instalar) y asegúrese de reiniciar el clúster cuando se complete la instalación.

Nota:

Asegúrese de reiniciar el clúster de Azure Databricks después de instalar la biblioteca del conector de Cassandra.

Instalación del proxy de doble escritura

Para obtener un rendimiento óptimo durante las escrituras duales, se recomienda instalar el proxy en todos los nodos del clúster de Cassandra de origen.

#assuming you do not have git already installed
sudo apt-get install git 

#assuming you do not have maven already installed
sudo apt install maven

#clone repo for dual-write proxy
git clone https://github.com/Azure-Samples/cassandra-proxy.git

#change directory
cd cassandra-proxy

#compile the proxy
mvn package

Inicio del proxy de doble escritura

Se recomienda instalar el proxy en todos los nodos del clúster de Cassandra de origen. Como mínimo, ejecute el siguiente comando para iniciar el proxy en cada nodo. Reemplace <target-server> por una dirección IP o de servidor de uno de los nodos del clúster de destino. Reemplace por <path to JKS file> la ruta de acceso a un archivo jks local y reemplace por <keystore password> la contraseña correspondiente.

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password>

Al iniciar el proxy de esta manera, se da por hecho que se cumple lo siguiente:

  • Los puntos de conexión de origen y destino tienen el mismo nombre de usuario y la misma contraseña.
  • Los puntos de conexión de origen y destino implementan el protocolo SSL (Capa de sockets seguros).

Si los puntos de conexión de origen y destino no pueden cumplir estos criterios, siga leyendo para conocer más opciones de configuración.

Configuración de SSL

Para SSL, puede implementar un almacén de claves existente, por ejemplo, el que usa el clúster de origen o crear un certificado autofirmado mediante keytool:

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

También puede deshabilitar SSL para los puntos de conexión de origen o destino si no implementan este protocolo. Use las marcas --disable-source-tls o --disable-target-tls:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> \
  --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> \
  --proxy-jks-password <keystore password> --target-username <username> --target-password <password> \
  --disable-source-tls true  --disable-target-tls true

Nota:

Asegúrese de que la aplicación cliente use el mismo almacén de claves y contraseña que los usados para el proxy de doble escritura al establecer conexiones SSL a la base de datos que usan el proxy.

Configuración de las credenciales y el puerto

De forma predeterminada, se pasan las credenciales de origen de la aplicación cliente. El proxy usa las credenciales para realizar conexiones a los clústeres de origen y de destino. Como hemos mencionado anteriormente, en este proceso se da por supuesto que las credenciales del origen y el destino son las mismas. Si es necesario, puede especificar aparte un nombre de usuario y una contraseña diferentes para el punto de conexión de Cassandra de destino al iniciar el proxy:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> \
  --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> \
  --target-username <username> --target-password <password>

Los puertos de origen y destino predeterminados, cuando no se especifican, son 9042. Si el punto de conexión de Cassandra de destino o de origen se ejecuta en un puerto diferente, puede usar --source-port o --target-port para especificar otro número de puerto:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> \
  --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> \
  --proxy-jks-password <keystore password> --target-username <username> --target-password <password>

Implementación del proxy de forma remota

Puede haber circunstancias en las que no quiera instalar el proxy en los nodos del clúster. Quieres instalarlo en una máquina independiente. En ese escenario, especifique la dirección IP de <source-server>:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>

Advertencia

Es posible que quiera ejecutar el proxy de forma remota en una máquina independiente en lugar de ejecutarlo en todos los nodos del clúster de Apache Cassandra de origen. Si es así, recomendamos implementar el proxy en tantas máquinas como nodos en el clúster. Configure una sustitución de sus direcciones IP en system.peers. Utiliza esta configuración en el proxy. Si no usa este enfoque, puede afectar al rendimiento mientras se produce la migración en vivo, ya que el controlador cliente no puede abrir conexiones a todos los nodos del clúster.

Cero cambios en el código de las aplicaciones

De forma predeterminada, el proxy escucha en el puerto 29042. Debe cambiar el código de la aplicación para que apunte a este puerto. Como alternativa, puede cambiar el puerto en el que escucha el proxy. Puede usar este enfoque si desea eliminar los cambios de código de nivel de aplicación mediante:

  • Haciendo que el servidor de Cassandra de origen se ejecute en otro puerto.
  • Haciendo que el proxy se ejecute en el puerto estándar 9042 de Cassandra.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042

Nota:

La instalación del proxy en los nodos del clúster no requiere reiniciar los nodos. Si tiene muchos clientes de aplicación y prefiere ejecutar el proxy en el puerto 9042 estándar de Cassandra para eliminar los cambios de código de nivel de aplicación, cambie el puerto predeterminado de Apache Cassandra. Después, debe reiniciar los nodos del clúster y configurar el puerto de origen para que sea el nuevo puerto que definió para el clúster de Cassandra de origen.

En el ejemplo siguiente, cambiamos el clúster de Cassandra de origen para que se ejecute en el puerto 3074 e iniciamos el clúster en el puerto 9042:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074

Imposición de protocolos

El proxy tiene funcionalidad para imponer protocolos, lo que podría ser necesario si el punto de conexión de origen es más avanzado que el de destino o no se admite por otro motivo. En ese caso, puede especificar --protocol-version y --cql-version para exigir que el protocolo cumpla con el destino:

java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11

Después de ejecutar el proxy de doble escritura, cambie el puerto en el cliente de la aplicación y reinicie. O bien, cambie el puerto de Cassandra y reinicie el clúster si eligió ese enfoque. El proxy inicia el reenvío de escrituras al punto de conexión de destino. Puede obtener información sobre la supervisión y las métricas disponibles en la herramienta de proxy.

Ejecución de la carga de datos históricos

Para cargar los datos, cree un cuaderno de Scala en la cuenta de Azure Databricks. Reemplace las configuraciones de Cassandra de origen y de destino por las credenciales correspondientes, así como los espacios de claves y las tablas de origen y destino. Agregue más variables para cada tabla según sea necesario en el ejemplo siguiente y ejecútelo. Cuando la aplicación empiece a enviar solicitudes al proxy de doble escritura, estará listo para migrar datos históricos.

import com.datastax.spark.connector._
import com.datastax.spark.connector.cql._
import org.apache.spark.SparkContext

// source cassandra configs
val sourceCassandra = Map( 
    "spark.cassandra.connection.host" -> "<Source Cassandra Host>",
    "spark.cassandra.connection.port" -> "9042",
    "spark.cassandra.auth.username" -> "<USERNAME>",
    "spark.cassandra.auth.password" -> "<PASSWORD>",
    "spark.cassandra.connection.ssl.enabled" -> "true",
    "keyspace" -> "<KEYSPACE>",
    "table" -> "<TABLE>"
)

//target cassandra configs
val targetCassandra = Map( 
    "spark.cassandra.connection.host" -> "<Source Cassandra Host>",
    "spark.cassandra.connection.port" -> "9042",
    "spark.cassandra.auth.username" -> "<USERNAME>",
    "spark.cassandra.auth.password" -> "<PASSWORD>",
    "spark.cassandra.connection.ssl.enabled" -> "true",
    "keyspace" -> "<KEYSPACE>",
    "table" -> "<TABLE>",
    //throughput related settings below - tweak these depending on data volumes. 
    "spark.cassandra.output.batch.size.rows"-> "1",
    "spark.cassandra.output.concurrent.writes" -> "1000",
    "spark.cassandra.connection.remoteConnectionsPerExecutor" -> "1",
    "spark.cassandra.concurrent.reads" -> "512",
    "spark.cassandra.output.batch.grouping.buffer.size" -> "1000",
    "spark.cassandra.connection.keep_alive_ms" -> "600000000"
)

//set timestamp to ensure it is before read job starts
val timestamp: Long = System.currentTimeMillis / 1000

//Read from source Cassandra
val DFfromSourceCassandra = sqlContext
  .read
  .format("org.apache.spark.sql.cassandra")
  .options(sourceCassandra)
  .load
  
//Write to target Cassandra
DFfromSourceCassandra
  .write
  .format("org.apache.spark.sql.cassandra")
  .options(targetCassandra)
  .option("writetime", timestamp)
  .mode(SaveMode.Append)
  .save

Nota:

En el ejemplo de Scala anterior, timestamp se establece en la hora actual antes de leer todos los datos de la tabla de origen. Después, writetime se antedata con esta marca de tiempo. Este enfoque garantiza que los registros escritos desde la carga de datos históricos en el punto de conexión de destino no puedan sobrescribir las actualizaciones que se incluyen con una marca de tiempo posterior del proxy de escritura dual mientras se leen los datos históricos.

Importante

Si, por algún motivo, necesita conservar las marcas de tiempo exactas, debe seguir un enfoque de migración de datos históricos que mantenga las marcas de tiempo, como en este ejemplo. El archivo jar de dependencias del ejemplo también contiene el conector de Spark, por lo que no es necesario instalar el ensamblado del conector de Spark mencionado en los requisitos previos anteriores. Tener ambos instalados en el clúster de Spark provoca conflictos.

Validación del origen y el destino

Una vez completada la carga de datos históricos, las bases de datos deben estar sincronizadas y listas para la transición. Se recomienda validar el origen y el destino para asegurarse de que coinciden antes de que finalmente se corten.

Nota:

Si usó el ejemplo de Migrator de Cassandra mencionado anteriormente para conservar writetime, tiene la capacidad de validar la migración mediante comparar filas en origen y destino en función de determinadas tolerancias.

Paso siguiente

Administración de recursos de Azure Managed Instance for Apache Cassandra mediante la CLI de Azure

  • Last updated on