Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Jeśli to możliwe, zalecamy, abyś korzystał z natywnej funkcjonalności "Apache Cassandra" do migrowania danych z istniejącego klastra do zarządzanego wystąpienia Azure dla "Apache Cassandra", konfigurując klaster hybrydowy. Ta funkcja używa protokołu plotek platformy Apache Cassandra do replikacji danych ze źródłowego centrum danych do nowego centrum danych wystąpienia zarządzanego w bezproblemowy sposób.
W niektórych scenariuszach wersja źródłowej bazy danych nie jest zgodna lub konfiguracja klastra hybrydowego nie jest możliwa. W tym samouczku opisano sposób migrowania danych do usługi Azure Managed Instance for Apache Cassandra w sposób dynamiczny przy użyciu serwera proxy z podwójnym zapisem i platformy Apache Spark. Serwer proxy z podwójnym zapisem służy do przechwytywania zmian na żywo, podczas gdy dane historyczne są kopiowane zbiorczo przy użyciu platformy Apache Spark. Korzyści wynikające z tego podejścia są następujące:
- Minimalne zmiany aplikacji. Serwer proxy może akceptować połączenia z kodu aplikacji z kilkoma zmianami konfiguracji. Kieruje wszystkie żądania do źródłowej bazy danych i asynchronicznie kieruje zapisy do pomocniczego obiektu docelowego.
- Zależność protokołu przewodowego klienta. Ponieważ takie podejście nie jest zależne od zasobów zaplecza ani protokołów wewnętrznych, może być używane z dowolnym źródłowym lub docelowym systemem Cassandra, który implementuje protokół przewodowy Apache Cassandra.
Na poniższej ilustracji przedstawiono podejście.
Wymagania wstępne
Aprowizuj wystąpienie zarządzane platformy Azure dla klastra Apache Cassandra przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Upewnij się, że możesz nawiązać połączenie z klastrem za pomocą protokołu CQLSH.
Aprowizuj konto usługi Azure Databricks w zarządzanej sieci wirtualnej Cassandra. Upewnij się, że konto ma dostęp sieciowy do źródłowego klastra Cassandra. W tym przykładzie tworzony jest klaster Spark na tym koncie na potrzeby ładowania danych historycznych.
Upewnij się, że schemat przestrzeni kluczy/tabeli został już zmigrowany ze źródłowej bazy danych Cassandra do docelowej bazy danych wystąpienia zarządzanego Cassandra.
Aprowizuj klaster Spark
Zalecamy wybranie środowiska uruchomieniowego usługi Azure Databricks w wersji 7.5, która obsługuje platformę Spark 3.0.
Dodawanie zależności platformy Spark
Musisz dodać bibliotekę łącznika Apache Spark Cassandra Connector do klastra, aby nawiązać połączenie z dowolnymi punktami końcowymi apache Cassandra zgodnymi z protokołem przewodowym. W klastrze wybierz pozycję >, a następnie dodaj współrzędne narzędzia Maven.
Ważne
Jeśli wymagana jest ochrona bazy danych Apache Cassandra writetime dla każdego wiersza podczas migracji, zalecamy użycie tego przykładu. Plik jar zależności w tym przykładzie zawiera również łącznik Spark, więc zainstaluj tę wersję zamiast zestawu łącznika.
Ten przykład jest również przydatny, jeśli chcesz przeprowadzić walidację porównania wierszy między źródłem i obiektem docelowym po zakończeniu ładowania danych historycznych. Zobacz Uruchamianie ładowania danych historycznych i Weryfikowanie źródła i miejsca docelowego.
Wybierz pozycję Zainstaluj, a następnie uruchom ponownie klaster po zakończeniu instalacji.
Uwaga
Pamiętaj, aby ponownie uruchomić klaster usługi Azure Databricks po zainstalowaniu biblioteki łącznika Cassandra.
Instalowanie serwera proxy z podwójnym zapisem
Aby uzyskać optymalną wydajność podczas podwójnych zapisów, zalecamy zainstalowanie serwera proxy we wszystkich węzłach w źródłowym klastrze 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
Uruchamianie serwera proxy z podwójnym zapisem
Zalecamy zainstalowanie serwera proxy na wszystkich węzłach w źródłowym klastrze Cassandra. Uruchom co najmniej następujące polecenie, aby uruchomić serwer proxy w każdym węźle. Zastąp <target-server> ciąg adresem IP lub adresem serwera z jednego z węzłów w klastrze docelowym. Zastąp <path to JKS file> ciąg ścieżką do lokalnego pliku jks i zastąp <keystore password> ciąg odpowiednim hasłem.
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>
Uruchomienie serwera proxy w ten sposób zakłada, że spełnione są następujące warunki:
- Źródłowe i docelowe punkty końcowe mają taką samą nazwę użytkownika i hasło.
- Źródłowe i docelowe punkty końcowe implementują protokół SECURE Sockets Layer (SSL).
Jeśli źródłowe i docelowe punkty końcowe nie mogą spełnić tych kryteriów, zapoznaj się z tematem dalsze opcje konfiguracji.
Konfigurowanie protokołu SSL
W przypadku protokołu SSL można zaimplementować istniejący magazyn kluczy, na przykład ten, którego używa klaster źródłowy, lub utworzyć certyfikat z podpisem własnym przy użyciu polecenia keytool:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
Możesz również wyłączyć protokół SSL dla źródłowych lub docelowych punktów końcowych, jeśli nie implementują protokołu SSL.
--disable-source-tls Użyj flag lub--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
Uwaga
Upewnij się, że aplikacja kliencka używa tego samego magazynu kluczy i hasła, co te używane dla serwera proxy z podwójnym zapisem podczas tworzenia połączeń SSL z bazą danych używającą serwera proxy.
Konfigurowanie poświadczeń i portów
Domyślnie poświadczenia źródłowe są przekazywane z aplikacji klienckiej. Serwer proxy używa poświadczeń do nawiązywania połączeń z klastrami źródłowymi i docelowymi. Jak wspomniano wcześniej, ten proces zakłada, że poświadczenia źródłowe i docelowe są takie same. W razie potrzeby możesz oddzielnie określić inną nazwę użytkownika i hasło dla docelowego punktu końcowego cassandra podczas uruchamiania serwera 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>
Domyślne porty źródłowe i docelowe, jeśli nie zostały określone, to 9042. Jeśli docelowy lub źródłowy punkt końcowy Cassandra działa na innym porcie, możesz użyć --source-port polecenia lub --target-port określić inny numer 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>
Zdalne wdrażanie serwera proxy
Mogą wystąpić okoliczności, w których nie chcesz instalować serwera proxy na samych węzłach klastra. Chcesz zainstalować go na oddzielnej maszynie. W tym scenariuszu określ adres IP :<source-server>
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>
Ostrzeżenie
Możesz chcieć uruchomić serwer proxy zdalnie na osobnej maszynie, a nie na wszystkich węzłach w źródłowym klastrze Apache Cassandra. Jeśli tak, zalecamy wdrożenie serwera proxy na tej samej liczbie maszyn, co węzły w klastrze. Skonfiguruj zamienniki dla ich adresów IP w system.peers. Użyj tej konfiguracji na serwerze proxy. Jeśli nie używasz tej metody, może to mieć wpływ na wydajność podczas migracji na żywo, ponieważ sterownik klienta nie może otwierać połączeń ze wszystkimi węzłami w klastrze.
Zezwalaj na zerowe zmiany kodu aplikacji
Domyślnie serwer proxy nasłuchuje na porcie 29042. Musisz zmienić kod aplikacji, aby wskazywał ten port. Alternatywnie możesz zmienić port, na którym nasłuchuje serwer proxy. Możesz użyć tego podejścia, jeśli chcesz wyeliminować zmiany kodu na poziomie aplikacji przez:
- Po uruchomieniu źródłowego serwera Cassandra na innym porcie.
- Uruchomienie serwera proxy na standardowym porcie Cassandra 9042.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042
Uwaga
Zainstalowanie serwera proxy w węzłach klastra nie wymaga ponownego uruchomienia węzłów. Jeśli masz wielu klientów aplikacji i wolisz uruchomić serwer proxy na standardowym porcie Cassandra 9042, aby wyeliminować wszelkie zmiany kodu na poziomie aplikacji, zmień domyślny port apache Cassandra. Następnie należy ponownie uruchomić węzły w klastrze i skonfigurować port źródłowy jako nowy port zdefiniowany dla źródłowego klastra Cassandra.
W poniższym przykładzie zmienimy źródłowy klaster Cassandra na uruchomiony na porcie 3074 i uruchomimy klaster na porcie 9042:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074
Wymuszanie protokołów
Serwer proxy ma funkcje wymuszania protokołów, które mogą być konieczne, jeśli źródłowy punkt końcowy jest bardziej zaawansowany niż docelowy lub w inny sposób nie jest obsługiwany. W takim przypadku można określić --protocol-version i --cql-version wymusić, aby protokół był zgodny z celem:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11
Po uruchomieniu serwera proxy z podwójnym zapisem zmień port na kliencie aplikacji i uruchom ponownie. Możesz też zmienić port Cassandra i ponownie uruchomić klaster, jeśli wybrano to podejście. Serwer proxy uruchamia przekazywanie zapisów do docelowego punktu końcowego. Informacje o monitorowaniu i metrykach dostępnych w narzędziu serwera proxy.
Uruchamianie ładowania danych historycznych
Aby załadować dane, utwórz notes Języka Scala na koncie usługi Azure Databricks. Zastąp źródłowe i docelowe konfiguracje bazy danych Cassandra odpowiednimi poświadczeniami, a następnie zastąp źródłowe i docelowe przestrzenie kluczy i tabele. Dodaj więcej zmiennych dla każdej tabeli zgodnie z wymaganiami do poniższego przykładu, a następnie uruchom polecenie . Gdy aplikacja zacznie wysyłać żądania do serwera proxy z podwójnym zapisem, możesz przystąpić do migracji danych historycznych.
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
Uwaga
W poprzednim przykładzie Scala, timestamp jest ustawiane na bieżący czas przed odczytaniem wszystkich danych w tabeli źródłowej.
writetime Następnie jest ustawiana na tę sygnaturę czasową wsteczną. Takie podejście zapewnia, że rekordy zapisywane z ładowania danych historycznych do docelowego punktu końcowego nie mogą zastąpić aktualizacji, które pochodzą z późniejszą sygnaturą czasową z proxy obsługującego podwójny zapis, podczas gdy dane historyczne są odczytywane.
Ważne
Jeśli musisz zachować dokładne sygnatury czasowe z jakiegokolwiek powodu, należy podjąć podejście do migracji danych historycznych, które zachowuje sygnatury czasowe, takie jak ten przykład. W przykładzie plik jar z zależnościami zawiera również łącznik Spark, więc nie trzeba instalować zestawu łącznika Spark wymienionego w wcześniejszych wymaganiach wstępnych. Po zainstalowaniu obu tych elementów w klastrze Spark występują konflikty.
Weryfikowanie źródła i miejsca docelowego
Po zakończeniu ładowania danych historycznych bazy danych powinny być zsynchronizowane i gotowe do migracji jednorazowej. Zalecamy zweryfikowanie źródła i celu, aby upewnić się, że są one zgodne przed zakończeniem cięcia.
Uwaga
Jeśli użyto próbki migracji Cassandra wymienionej we wcześniejszych sekcjach w celu zachowania writetimewartości , masz możliwość zweryfikowania migracji przez porównanie wierszy w źródle i miejscu docelowym na podstawie pewnych tolerancji.