Živá migrace dat z Apache Cassandra do služby Azure Cosmos DB pro Apache Cassandra pomocí proxy serveru se dvěma zápisy a Apache Sparku
Rozhraní API pro Cassandra ve službě Azure Cosmos DB se stalo skvělou volbou pro podnikové úlohy běžící na Apache Cassandře z nejrůznějších důvodů, jako jsou:
Bez režijních nákladů na správu a monitorování: Eliminuje režii při správě a monitorování řadu nastavení v souborech OS, JVM a yaml a jejich interakcích.
Výrazné úspory nákladů: Náklady můžete ušetřit pomocí služby Azure Cosmos DB, která zahrnuje náklady na virtuální počítač, šířku pásma a všechny příslušné licence. Kromě toho nemusíte spravovat datacentra, servery, úložiště SSD, sítě a náklady na elektřinu.
Možnost využívat stávající kód a nástroje: Azure Cosmos DB poskytuje kompatibilitu na úrovni přenosového protokolu se stávajícími sadami SDK a nástroji Cassandra. Tato kompatibilita zajišťuje, že můžete použít stávající základ kódu se službou Azure Cosmos DB pro Apache Cassandra s triviálními změnami.
Azure Cosmos DB nepodporuje nativní protokol Gossip Apache Cassandra pro replikaci. V případě, že nulový výpadek je požadavkem na migraci, je proto nutný jiný přístup. Tento kurz popisuje, jak migrovat data do služby Azure Cosmos DB pro Apache Cassandra z nativního clusteru Apache Cassandra pomocí proxy serveru se dvěma zápisy a Apache Sparku.
Následující obrázek znázorňuje vzor. 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. Proxy server může přijímat připojení z kódu aplikace s několika změnami konfigurace nebo bez nich. Během hromadného kopírování bude směrovat všechny požadavky do zdrojové databáze a asynchronně směruje zápisy do rozhraní API pro Cassandru.
Požadavky
Zřízení účtu Služby Azure Cosmos DB pro Apache Cassandra
Projděte si základy připojení ke službě Azure Cosmos DB pro Apache Cassandra.
Projděte si podporované funkce ve službě Azure Cosmos DB pro Apache Cassandra a zajistěte kompatibilitu.
K ověření použijte cqlsh.
Ujistěte se, že máte síťové připojení mezi zdrojovým clusterem a cílovým rozhraním API pro koncový bod Cassandra.
Ujistěte se, že jste už migrovali schéma prostoru klíčů nebo tabulky ze zdrojové databáze Cassandra do cílového rozhraní API pro účet Cassandra.
Důležité
Pokud během migrace potřebujete zachovat Apache Cassandra
writetime, musí se při vytváření tabulek nastavit následující příznaky:with cosmosdb_cell_level_timestamp=true and cosmosdb_cell_level_timestamp_tombstones=true and cosmosdb_cell_level_timetolive=truePříklad:
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;
Zřízení clusteru Spark
Doporučujeme Azure Databricks. Použijte modul runtime, který podporuje Spark 3.0 nebo vyšší.
Důležité
Musíte se ujistit, že váš účet Azure Databricks má síťové připojení ke zdrojovému clusteru Apache Cassandra. To může vyžadovat injektáž virtuální sítě. Další informace najdete v tomto článku.
Přidání závislostí Sparku
Abyste se mohli připojit k nativním koncovým bodům Cassandra služby Azure Cosmos DB, 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.
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é. Při spuštění proxy serveru bude nutné zadat jiné uživatelské jméno a heslo pro cílové rozhraní API pro koncový bod Cassandra samostatně:
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. V tomto případě se rozhraní API pro Cassandra spouští na portu 10350, takže potřebujete použít --source-port nebo --target-port zadat čísla 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 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í
Instalace a spuštění proxy serveru na samostatném počítači (nikoli na všech uzlech ve zdrojovém clusteru Apache Cassandra) ovlivní výkon při migraci za provozu. I když bude fungovat funkčně, klientský ovladač nebude moct otevírat připojení ke všem uzlům v clusteru a bude spoléhat na jeden kodinátorový uzel (kde je nainstalovaný proxy server) k vytvoření připojení.
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.
Důležité
Před migrací dat zvyšte propustnost kontejneru na množství potřebné k rychlé migraci vaší aplikace. Škálování propustnosti před zahájením migrace vám pomůže migrovat data za kratší dobu. Pokud chcete zajistit ochranu před omezováním rychlosti během historického načítání dat, možná budete chtít povolit opakování na straně serveru v rozhraní API pro Cassandra. Další informace a pokyny k povolení služby SSR najdete v tomto článku.
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
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
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro