Migrace za provozu do služby Azure Managed Instance for Apache Cassandra s využitím proxy serveru se dvěma zápisy

Pokud je to možné, doporučujeme migrovat data z existujícího clusteru do služby Azure Managed Instance for Apache Cassandra konfigurací hybridního clusteru pomocí nativní funkce Apache Cassandra. Tato funkce využívá protokol gossip od Apache Cassandry k bezproblémové replikaci dat ze zdrojového datacentra do nového datacentra spravované instance. V některých scénářích však může být verze zdrojové databáze nekompatibilní nebo nastavení hybridního clusteru není jinak možné.

Tento kurz popisuje, jak za provozu migrovat data do služby Azure Managed Instance for Apache Cassandra pomocí proxy serveru se dvěma zápisy a Apache Sparku. Proxy server se dvěma zápisy slouží k zachytávání živých změn, zatímco historická data se kopírují hromadně pomocí Apache Sparku. Výhody tohoto přístupu:

  • Minimální změny aplikace. Proxy server může přijímat připojení z kódu vaší aplikace s malými nebo žádnými změnami konfigurace. Bude směrovat všechny požadavky do zdrojové databáze a asynchronně směrovat zápisy do sekundárního cíle.
  • Závislost přenosového protokolu klienta. Vzhledem k tomu, že tento přístup nezávisí na back-endových prostředcích nebo interních protokolech, je možné ho použít s jakýmkoli zdrojovým nebo cílovým systémem Cassandra, který implementuje protokol přenosu Apache Cassandra.

Následující obrázek znázorňuje tento přístup.

Animace znázorňující migraci dat do služby Azure Managed Instance for Apache Cassandra za provozu

Požadavky

Zřízení clusteru Spark

Doporučujeme vybrat modul runtime Azure Databricks verze 7.5, který podporuje Spark 3.0.

Snímek obrazovky znázorňující vyhledání verze modulu runtime Azure Databricks

Přidání závislostí Sparku

Abyste se mohli připojit ke koncovým bodům Apache Cassandra kompatibilním s přenosovém protokolem, musíte do clusteru přidat knihovnu konektoru Apache Spark Cassandra. V clusteru vyberte Knihovny>Nainstalovat nový>Maven a pak přidejte com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 souřadnice Mavenu.

Důležité

Pokud máte požadavek na zachování Apache Cassandry writetime pro každý řádek během migrace, doporučujeme použít tuto ukázku. Soubor JAR závislostí v této ukázce obsahuje také konektor Spark, takže byste ho měli nainstalovat místo výše uvedeného sestavení konektoru. Tato ukázka je také užitečná, pokud chcete po dokončení načítání historických dat provést ověření porovnání řádků mezi zdrojem a cílem. Další podrobnosti najdete níže v částech Spuštění načítání historických dat a Ověření zdroje a cíle.

Snímek obrazovky znázorňující hledání balíčků Maven v Azure Databricks

Vyberte Nainstalovat a po dokončení instalace restartujte cluster.

Poznámka

Po instalaci knihovny konektoru Cassandra nezapomeňte restartovat cluster Azure Databricks.

Instalace proxy serveru se dvěma zápisy

Pro zajištění optimálního výkonu při duálním zápisu doporučujeme nainstalovat proxy server na všechny uzly ve zdrojovém clusteru Cassandra.

#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

Spuštění proxy serveru se dvěma zápisy

Doporučujeme nainstalovat proxy server na všechny uzly ve zdrojovém clusteru Cassandra. Spuštěním minimálně následujícího příkazu spusťte proxy server na každém uzlu. Nahraďte <target-server> IP adresou nebo adresou serveru z jednoho z uzlů v cílovém clusteru. Nahraďte <path to JKS file> cestou k místnímu souboru .jks a nahraďte <keystore password> odpovídajícím heslem.

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>

Spuštění proxy serveru tímto způsobem předpokládá, že platí následující:

  • Zdrojový a cílový koncový bod mají stejné uživatelské jméno a heslo.
  • Zdrojové a cílové koncové body implementují protokol SSL (Secure Sockets Layer).

Pokud zdrojový a cílový koncový bod nemůžou tato kritéria splňovat, přečtěte si další možnosti konfigurace.

Konfigurace SSL

V případě protokolu SSL můžete buď implementovat existující úložiště klíčů (například úložiště, které používá váš zdrojový cluster), nebo vytvořit certifikát podepsaný svým držitelem pomocí příkazu keytool:

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

Můžete také zakázat SSL pro zdrojové nebo cílové koncové body, pokud neimplementují SSL. --disable-source-tls Použijte příznaky nebo--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 

Poznámka

Ujistěte se, že vaše klientská aplikace používá stejné úložiště klíčů a heslo jako pro proxy server se dvěma zápisy, když vytváříte připojení SSL k databázi prostřednictvím proxy serveru.

Konfigurace přihlašovacích údajů a portu

Ve výchozím nastavení se přihlašovací údaje ke zdroji předávají z vaší klientské aplikace. Proxy server použije přihlašovací údaje pro připojení ke zdrojovému a cílovému clusteru. Jak už bylo zmíněno dříve, tento proces předpokládá, že zdrojové a cílové přihlašovací údaje jsou stejné. V případě potřeby můžete při spuštění proxy serveru zadat pro cílový koncový bod Cassandra samostatně jiné uživatelské jméno a heslo:

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>

Výchozí zdrojový a cílový port, pokud nejsou zadané, bude 9042. Pokud cíl nebo zdrojový koncový bod Cassandra běží na jiném portu, můžete k zadání jiného čísla portu použít --source-port nebo --target-port :

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>

Vzdálené nasazení proxy serveru

Můžou nastat okolnosti, kdy nechcete proxy server instalovat na samotné uzly clusteru a chcete ho nainstalovat na samostatný počítač. V takovém scénáři je potřeba zadat IP adresu :<source-server>

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

Upozornění

Pokud dáváte přednost vzdálenému spuštění proxy serveru na samostatném počítači (místo jeho spouštění na všech uzlech ve zdrojovém clusteru Apache Cassandra), doporučujeme nasadit proxy server na stejný počet počítačů, na který máte uzly v clusteru, a nastavit nahrazení jejich IP adres v system.peers pomocí konfigurace v proxy serveru uvedeném tady. Pokud to neuděláte, může to mít vliv na výkon migrace za provozu, protože ovladač klienta nebude moct otevřít připojení ke všem uzlům v clusteru.

Povolit nulové změny kódu aplikace

Ve výchozím nastavení proxy naslouchá na portu 29042. Kód aplikace musí být změněn tak, aby odkazovat na tento port. Můžete ale změnit port, na který proxy server naslouchá. Můžete to udělat, pokud chcete eliminovat změny kódu na úrovni aplikace:

  • Aby zdrojový server Cassandra běžel na jiném portu.
  • Proxy server běží na standardním portu Cassandra 9042.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042

Poznámka

Instalace proxy serveru na uzly clusteru nevyžaduje restartování uzlů. Pokud však máte mnoho klientů aplikací a dáváte přednost tomu, aby proxy server běžel na standardním portu Cassandra 9042, aby se vyloučily jakékoli změny kódu na úrovni aplikace, musíte změnit výchozí port Apache Cassandra. Pak musíte restartovat uzly v clusteru a nakonfigurovat zdrojový port tak, aby byl novým portem, který jste definovali pro zdrojový cluster Cassandra.

V následujícím příkladu změníme zdrojový cluster Cassandra tak, aby běžel na portu 3074, a spustíme cluster na portu 9042:

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

Vynutit protokoly

Proxy server má funkci, která vynucuje protokoly, což může být nezbytné, pokud je zdrojový koncový bod pokročilejší než cíl nebo je jinak nepodporovaný. V takovém případě můžete zadat --protocol-version a --cql-version vynutit, aby byl protokol v souladu s cílem:

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

Po spuštění proxy serveru se dvěma zápisy budete muset změnit port na aplikačním klientovi a restartovat ho. (Nebo změňte port Cassandra a restartujte cluster, pokud jste zvolili tento přístup.) Proxy server pak začne předávat zápisy do cílového koncového bodu. Informace o monitorování a metrikách dostupných v nástroji proxy najdete.

Spuštění načítání historických dat

Pokud chcete načíst data, vytvořte ve svém účtu Azure Databricks poznámkový blok Scala. Nahraďte zdrojové a cílové konfigurace Cassandra odpovídajícími přihlašovacími údaji a nahraďte zdrojové a cílové prostory klíčů a tabulky. Přidejte další proměnné pro každou tabulku podle potřeby do následující ukázky a pak spusťte příkaz . Jakmile vaše aplikace začne odesílat požadavky na proxy server se dvěma zápisy, jste připraveni migrovat historická data.

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

Poznámka

V předchozí ukázce Scala si všimnete, že timestamp se před čtením všech dat ve zdrojové tabulce nastavuje aktuální čas. writetime Potom se nastavuje na toto backdatované časové razítko. Tím se zajistí, že záznamy zapsané z historických dat načtené do cílového koncového bodu nemůžou přepsat aktualizace, které přicházejí s pozdějším časovým razítkem z proxy serveru se dvěma zápisy, zatímco se historická data čtou.

Důležité

Pokud z nějakého důvodu potřebujete zachovat přesná časová razítka, měli byste použít historický přístup k migraci dat, který zachovává časová razítka, jako je tato ukázka. Soubor JAR závislostí v ukázce obsahuje také konektor Spark, takže nemusíte instalovat sestavení konektoru Sparku uvedené v předchozích požadavcích – obě instalace v clusteru Spark způsobí konflikty.

Ověření zdroje a cíle

Po dokončení načítání historických dat by vaše databáze měly být synchronizované a připravené na přímou migraci. Doporučujeme ale ověřit zdroj a cíl, abyste měli jistotu, že se shodují, než se nakonec přeškrtnou.

Poznámka

Pokud jste k zachování writetimepoužili výše uvedený vzorek migrace cassandra , zahrnuje to možnost ověřit migraciporovnáním řádků ve zdroji a cíli na základě určitých tolerancí.

Další kroky