Livemigration von Daten aus Apache Cassandra in Azure Cosmos DB for Apache Cassandra mithilfe eines Proxys für duales Schreiben und von Apache Spark

API für Cassandra in Azure Cosmos DB ist eine großartige Wahl für Enterprise-Workloads, die aus verschiedenen Gründen auf Apache Cassandra ausgeführt werden:

• Kein Aufwand für die Verwaltung und Überwachung: Dadurch wird der Aufwand für die Verwaltung und Überwachung einer Vielzahl von Einstellungen auf allen Betriebssystemen, virtuellen Java-Computern und Yaml-Dateien und deren Interaktionen beseitigt.
• Erhebliche Kosteneinsparungen: Sie können Kosten mit Azure Cosmos DB sparen, einschließlich der Kosten für virtuelle Computer, Bandbreite und alle anwendbaren Lizenzen. Sie müssen die Rechenzentren, Server, SSD-Speicher, Netzwerk- und Stromkosten nicht verwalten.
• Möglichkeit zur Verwendung von vorhandenem Code und vorhandenen Tools: Azure Cosmos DB bietet auf der Verbindungsprotokollebene Kompatibilität mit bestehenden Cassandra-SDKs und -Tools. Durch diese Kompatibilität ist sichergestellt, dass Sie die vorhandene Codebasis mit Azure Cosmos DB for Apache Cassandra mit nur geringfügigen Änderungen verwenden können.

Azure Cosmos DB unterstützt nicht das native Apache Cassandra Gossip-Protokoll für die Replikation. Wenn keine Ausfallzeiten für die Migration erforderlich sind, ist ein anderer Ansatz erforderlich. In diesem Tutorial wird beschrieben, wie Sie Daten live mithilfe eines Proxys für duales Schreiben und von Apache Spark aus einem nativen Apache Cassandra-Cluster in Azure Cosmos DB for Apache Cassandra migrieren.

Die Vorgehensweise ist in der folgenden Abbildung dargestellt. Der Dual-Write-Proxy wird verwendet, um Liveänderungen zu erfassen. Historische Daten werden mithilfe von Apache Spark in Massen kopiert. Damit der Proxy Verbindungen von Ihrem Anwendungscode akzeptiert, sind wenig bis keine Konfigurationsänderungen nötig. Sie leitet alle Anforderungen an Ihre Quelldatenbank weiter und leitet Schreibvorgänge asynchron an die API für Cassandra weiter, während der Massenkopiervorgang läuft.

Voraussetzungen

• Stellen Sie ein Azure Cosmos DB for Apache Cassandra-Konto bereit.
• Überprüfen Sie die Grundlagen der Verbindung mit Azure Cosmos DB for Apache Cassandra.
• Überprüfen Sie die in Azure Cosmos DB for Apache Cassandra unterstützten Features, um die Kompatibilität sicherzustellen.
• Verwenden Sie cqlsh für die Überprüfung.
• Stellen Sie sicher, dass Netzwerkkonnektivität zwischen Ihrem Quellcluster und dem API für Cassandra-Zielendpunkt besteht.
• Stellen Sie sicher, dass Sie zuvor das Keyspace-/Tabellenschema aus Ihrer Cassandra-Quelldatenbank zu Ihrer Ziel-API für Ihr Cassandra-Konto migriert haben.

with cosmosdb_cell_level_timestamp=true and cosmosdb_cell_level_timestamp_tombstones=true and cosmosdb_cell_level_timetolive=true

CREATE KEYSPACE IF NOT EXISTS migrationkeyspace WITH REPLICATION= {'class': 'org.apache.> cassandra.locator.SimpleStrategy', 'replication_factor' : '1'};

CREATE TABLE IF NOT EXISTS migrationkeyspace.users (
 name text,
 userID int,
 address text,
 phone int,
 PRIMARY KEY ((name), userID)) with cosmosdb_cell_level_timestamp=true and > cosmosdb_cell_level_timestamp_tombstones=true and cosmosdb_cell_level_timetolive=true;

Bereitstellen eines Spark-Clusters

Es wird empfohlen, Azure Databricks zu verwenden. Verwenden Sie eine Laufzeit, die Spark 3.0 oder höher unterstützt.

Hinzufügen von Spark-Abhängigkeiten

Fügen Sie dem Cluster die Apache Spark-Cassandra-Connectorbibliothek hinzu, um eine Verbindung mit nativen und Azure Cosmos DB-Cassandra-Endpunkten herzustellen. Wählen Sie in Ihrem Cluster Bibliotheken>Neue>Maveninstallieren und fügen Sie dann com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 in Maven-Koordinaten hinzu.

Wählen Sie Installieren aus, und starten Sie den Cluster nach Abschluss der Installation neu.

Installieren Sie den Proxy für duales Schreiben.

Für eine optimale Leistung bei dualen Schreibvorgängen empfehlen wir, den Proxy auf allen Knoten in Ihrem Quell-Cassandra-Cluster zu installieren.

#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

Starten eines Proxys für duales Schreiben

Es wird empfohlen, den Proxy auf allen Knoten in Ihrem Cassandra-Quellcluster zu installieren. Führen Sie mindestens den folgenden Befehl aus, um den Proxy auf allen Knoten zu starten. Ersetzen Sie <target-server> durch eine IP- oder Serveradresse eines der Knoten im Zielcluster. Ersetzen Sie <path to JKS file> durch den Pfad zu einer lokalen .jks-Datei und <keystore password> durch das entsprechende Kennwort.

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>

Wenn Sie den Proxy auf diese Weise starten, muss Folgendes zutreffen:

• Quell- und Zielendpunkte besitzen denselben Benutzernamen und dasselbe Kennwort.
• Quell- und Zielendpunkte implementieren Secure Sockets Layer (SSL).

Wenn Ihre Quell- und Zielendpunkte diese Kriterien nicht erfüllen können, finden Sie nachfolgend weitere Konfigurationsoptionen.

Konfigurieren von SSL

Bei SSL können Sie entweder einen vorhandenen Schlüsselspeicher verwenden, z. B. den von Ihrem Quellcluster verwendeten, oder ein selbstsigniertes Zertifikat mithilfe von keytool erstellen.

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

Wenn die Quell- oder Zielendpunkte SSL nicht implementieren, können Sie dieses auch deaktivieren. Verwenden Sie hierzu die Flags --disable-source-tls oder --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 

Konfigurieren der Anmeldeinformationen und des Ports

Standardmäßig übergibt Ihre Client-App die Quellanmeldeinformationen. Der Proxy verwendet die Anmeldeinformationen, um Verbindungen mit den Quell- und Zielclustern herzustellen. Wie bereits erwähnt, wird bei diesem Prozess davon ausgegangen, dass die Quell- und Zielanmeldeinformationen identisch sind. Sie müssen beim Starten des Proxys für die Ziel-API des Cassandra-Endpunkts einen anderen Benutzernamen und ein anderes Kennwort getrennt angeben.

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>

Der voreingestellte Wert für die Quell- und Zielports, wenn nicht angegeben, ist 9042. In diesem Fall wird DIE API für Cassandra auf Port 10350ausgeführt. Verwenden Sie --source-port oder --target-port, um Portnummern anzugeben.

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>

Remote-Bereitstellung des Proxymoduls

Es kann Situationen geben, in denen Sie den Proxy nicht selbst auf den Clusterknoten installieren möchten. Möglicherweise möchten Sie es auf einem separaten Computer installieren. Geben Sie in diesem Szenario die IP-Adresse von <source-server>:

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

Keine Änderungen am Anwendungscode zulassen

Der Proxy lauscht standardmäßig an Port 29042. Ändern Sie den Anwendungscode so, dass er auf diesen Port verweist. Sie können stattdessen den Port ändern, auf den der Proxy lauscht. Sie können diese Änderung vornehmen, wenn Sie Codeänderungen auf Anwendungsebene beseitigen möchten, indem Sie:

• Das Ausführen des Cassandra-Quellservers auf einem anderen Port.
• den Proxy auf dem Cassandra-Standardport 9042 ausführen.

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

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

Erzwingen von Protokollen

Der Proxy kann Protokolle erzwingen, die möglicherweise erforderlich sind, wenn der Quellendpunkt moderner ist als der Zielendpunkt, oder wenn der Quellendpunkt anderweitig nicht unterstützt wird. In diesem Fall können Sie --protocol-version und --cql-version festlegen, um die Übereinstimmung des Protokolls mit dem Zielendpunkt zu erzwingen:

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

Nachdem der Dual-Write-Proxy ausgeführt wurde, müssen Sie den Port auf dem Anwendungsclient ändern und neu starten. Oder ändern Sie den Cassandra-Port, und starten Sie den Cluster neu, wenn Sie diesen Ansatz auswählen. Der Proxy startet die Weiterleitung von Schreibvorgängen an den Zielendpunkt. Weitere Informationen finden Sie unter Überwachung und Metriken.

Starten Sie den Verlaufsdaten-Ladevorgang

Erstellen Sie zum Laden der Daten ein Scala-Notebook in Ihrem Azure Databricks-Konto. Ersetzen Sie Ihre Quell- und Zielkonfigurationen für Cassandra durch die entsprechenden Anmeldeinformationen sowie die Quell-und Zielkeyspaces und -tabellen. Fügen Sie im folgenden Beispiel nach Bedarf für jede Tabelle weitere Variablen hinzu, und führen Sie den Code anschließend aus. Nachdem Ihre Anwendung mit dem Senden von Anfragen an den Proxy für duales Schreiben begonnen hat, können Sie die historischen Daten migrieren.

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" -> "10350",
    "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

Überprüfen der Quelle und des Ziels

Nachdem die historische Datenladung abgeschlossen ist, sollten Ihre Datenbanken synchronisiert und bereit für den Umstieg sein. Vor der endgültigen Übernahme wird eine Überprüfung der Quelle und des Ziels empfohlen, um sicherzustellen, dass beide übereinstimmen.

Nächster Schritt