Sdílet prostřednictvím


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

Pokud je to možné, doporučujeme použít nativní funkci Apache Cassandra k migraci dat z existujícího clusteru do služby Azure Managed Instance for Apache Cassandra konfigurací hybridního clusteru. Tato funkce využívá protokol Gossip apache Cassandra k replikaci dat ze zdrojového datacentra do nového datacentra spravované instance bezproblémovým způsobem. V některých scénářích ale může dojít k tomu, že vaše verze zdrojové databáze není kompatibilní nebo není možné nastavit hybridní cluster.

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

  • Minimální změny aplikace. Proxy server může přijímat připojení z kódu aplikace s několika změnami konfigurace nebo bez nich. Všechny požadavky budou směrovat do zdrojové databáze a asynchronně směrovat zápisy do sekundárního cíle.
  • Závislost klientského přenosového protokolu Vzhledem k tomu, že tento přístup není závislý 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 wire protocol Apache Cassandra.

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

Animace znázorňující migraci dat za provozu do spravované instance Azure pro Apache Cassandra

Požadavky

  • Zřízení clusteru Azure Managed Instance pro Apache Cassandra pomocí webu Azure Portal nebo Azure CLI Ujistěte se, že se ke clusteru můžete připojit pomocí CQLSH.

  • Zřiďte účet Azure Databricks ve vaší virtuální síti Managed Cassandra. Ujistěte se, že účet má síťový přístup ke zdrojovému clusteru Cassandra. V tomto účtu vytvoříme cluster Spark pro historické načtení dat.

  • Ujistěte se, že jste již migrovali schéma prostoru klíčů nebo tabulky ze zdrojové databáze Cassandra do cílové databáze spravované instance Cassandra.

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 všem koncovým bodům Apache Cassandra kompatibilním s protokolem Apache Cassandra, 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 Cassandra 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 Sparku, takže byste ho měli nainstalovat místo výše uvedeného sestavení konektoru. Tato ukázka je užitečná také v případě, že chcete po dokončení historického načtení dat provést ověření porovnání řádků mezi zdrojem a cílem. Další podrobnosti najdete v částech "Spuštění historického načtení dat" a "ověření zdroje a cíle" níže.

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 cluster Azure Databricks restartovat.

Instalace proxy serveru se dvěma zápisy

Pokud chcete dosáhnout optimálního výkonu při dvou zápisech, 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 na všechny uzly ve zdrojovém clusteru Cassandra. Minimálně spuštěním následujícího příkazu spusťte proxy server na každém uzlu. Nahraďte <target-server> IP adresou nebo serverovou adresou 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 tímto způsobem předpokládá, že platí následující:

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

Pokud vaše zdrojové a cílové koncové body nesplňují tato kritéria, přečtěte si další možnosti konfigurace.

Konfigurace SSL

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

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

Ssl můžete také zakázat pro zdrojové nebo cílové koncové body, pokud neimplementují SSL. Použijte příznaky--disable-source-tls:--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 při vytváření 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 zdrojové přihlašovací údaje předávají z klientské aplikace. Proxy server použije přihlašovací údaje pro vytváření připojení ke zdrojovým a cílovým clusterům. Jak už jsme zmínili 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 jiné uživatelské jméno a heslo pro cílový koncový bod Cassandra:

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 není zadaný, bude 9042. Pokud cíl nebo zdrojový koncový bod Cassandra běží na jiném portu, můžete použít --source-port nebo --target-port zadat jiné číslo portu:

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 situace, kdy nechcete nainstalovat proxy server do samotných uzlů clusteru a raději ho nainstalujete na samostatný počítač. V tomto 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>

Upozorňující

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

Povolit žádné 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 v případě, že chcete eliminovat změny kódu na úrovni aplikace:

  • Zdrojový server Cassandra běží 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 ale máte mnoho klientů aplikací a dáváte přednost tomu, aby proxy server běžel na standardním portu Cassandra 9042, abyste vyloučili všechny 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 cluster spustíme na portu 9042:

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

Vynucení protokolů

Proxy server má funkce vynucení protokolů, které můžou 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 v klientovi aplikace a restartovat ho. (Nebo změňte port Cassandra a restartujte cluster, pokud jste tento přístup zvolili.) Proxy server pak začne předávat zápisy do cílového koncového bodu. Seznamte se s monitorováním a metrikami dostupnými v nástroji proxy.

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 konfigurace zdrojové a cílové 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 spusťte ji. Jakmile vaše aplikace začne odesílat požadavky na proxy s duálním zápisem, 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 je před čtením všech dat ve zdrojové tabulce nastavená na aktuální čas. writetime Pak je nastaveno na toto zastaralé časové razítko. Tím se zajistí, že záznamy zapsané z historického načtení dat do cílového koncového bodu nebudou moct přepsat aktualizace, které přicházejí s pozdějším časovým razítkem z proxy duálního zápisu při čtení historických dat.

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 Sparku, takže není nutné instalovat sestavení konektoru Spark uvedené v předchozích předpokladech – obě instalace v clusteru Spark způsobí konflikty.

Ověření zdroje a cíle

Po dokončení načítání historických dat by se vaše databáze měly synchronizovat a připravené k přímé migraci. Doporučujeme ale ověřit zdroj a cíl, abyste se ujistili, že se shodují před tím, než se nakonec vyříznou.

Poznámka:

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

Další kroky