Szybki start: konfigurowanie klastra hybrydowego przy użyciu usługi Azure Managed Instance dla usługi Apache Cassandra

Azure Managed Instance for Apache Cassandra to w pełni zarządzana usługa dla czystych klastrów Apache Cassandra typu open source. Usługa umożliwia również zastępowanie konfiguracji w zależności od konkretnych potrzeb każdego obciążenia w celu zapewnienia maksymalnej elastyczności i kontroli.

W tym przewodniku Szybki start pokazano, jak skonfigurować klaster hybrydowy za pomocą poleceń interfejsu wiersza polecenia platformy Azure. Jeśli masz istniejące centra danych w środowisku lokalnym lub własnym, możesz użyć usługi Azure Managed Instance for Apache Cassandra, aby dodać inne centra danych do tych klastrów i obsługiwać je.

Wymagania wstępne

• Użyj środowiska powłoki Bash w usłudze Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Get started with Azure Cloud Shell.

  

• Jeśli wolisz uruchamiać polecenia referencyjne interfejsu wiersza polecenia lokalnie, zainstaluj interfejs wiersza polecenia platformy Azure. Jeśli korzystasz z systemu Windows lub macOS, rozważ uruchomienie interfejsu wiersza polecenia platformy Azure w kontenerze Docker. Aby uzyskać więcej informacji, zobacz Jak uruchomić interfejs wiersza polecenia platformy Azure w kontenerze platformy Docker.

  • Jeśli korzystasz z instalacji lokalnej, zaloguj się do interfejsu wiersza polecenia platformy Azure za pomocą polecenia az login. Aby ukończyć proces uwierzytelniania, wykonaj kroki wyświetlane w terminalu. Aby uzyskać inne opcje logowania, zobacz Uwierzytelnianie na platformie Azure przy użyciu interfejsu wiersza polecenia platformy Azure.

  • Po wyświetleniu monitu zainstaluj rozszerzenie interfejsu wiersza polecenia platformy Azure podczas pierwszego użycia. Aby uzyskać więcej informacji na temat rozszerzeń, zobacz Używanie rozszerzeń i zarządzanie nimi za pomocą interfejsu wiersza polecenia platformy Azure.

  • Uruchom polecenie az version, aby znaleźć zainstalowane wersje i biblioteki zależne. Aby uaktualnić do najnowszej wersji, uruchom polecenie az upgrade.

• Ten artykuł wymaga interfejsu wiersza polecenia platformy Azure w wersji 2.30.0 lub nowszej. Jeśli używasz usługi Azure Cloud Shell, najnowsza wersja jest już zainstalowana.
• Użyj sieci wirtualnej platformy Azure z łącznością z własnym środowiskiem lub środowiskiem lokalnym. Aby uzyskać więcej informacji na temat łączenia środowisk lokalnych z platformą Azure, zobacz Łączenie sieci lokalnej z platformą Azure.

Konfigurowanie klastra hybrydowego

1. Zaloguj się do witryny Azure Portal i przejdź do zasobu sieci wirtualnej.

2. Wybierz kartę Podsieci i utwórz nową podsieć. Aby dowiedzieć się więcej o polach w formularzu Dodawanie podsieci , zobacz Dodawanie podsieci.

   

   Wdrożenie usługi Azure Managed Instance dla usługi Apache Cassandra wymaga dostępu do Internetu. Wdrożenie kończy się niepowodzeniem w środowiskach, w których dostęp do Internetu jest ograniczony. Upewnij się, że nie blokujesz dostępu w sieci wirtualnej do następujących ważnych usług platformy Azure, które są niezbędne do prawidłowego działania usługi Azure Managed Instance dla usługi Apache Cassandra. Aby uzyskać listę adresów IP i zależności portów, zobacz Wymagane reguły sieci wychodzącej.

   • Azure Storage
   • Azure Key Vault
   • Zestawy skalowania maszyn wirtualnych Azure
   • Azure Monitor
   • Microsoft Entra ID
   • Microsoft Defender dla Chmury

3. Zastosuj specjalne uprawnienia do sieci wirtualnej i podsieci, które są wymagane przez wystąpienie zarządzane Azure dla Apache Cassandra, korzystając z Azure CLI. Użyj polecenia az role assignment create. Zastąp <subscriptionID>, <resourceGroupName> i <vnetName> odpowiednimi wartościami.

   az role assignment create \
     --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
     --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
     --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
   

   Wartości assignee i role w poprzednim poleceniu są odpowiednio stałymi identyfikatorami jednostki usługi i roli.

4. Konfigurowanie zasobów dla klastra hybrydowego. Ponieważ masz już klaster, nazwa klastra jest zasobem logicznym umożliwiającym zidentyfikowanie nazwy istniejącego klastra. Użyj nazwy istniejącego klastra podczas definiowania zmiennych clusterName i clusterNameOverride w poniższym skrypcie.

   Potrzebne są również co najmniej węzły seed z istniejącego centrum danych oraz certyfikaty gossip wymagane do szyfrowania między węzłami. Usługa Azure Managed Instance dla usługi Apache Cassandra wymaga szyfrowania węzła do węzła na potrzeby komunikacji między centrami danych. Jeśli nie masz szyfrowania węzła do węzła zaimplementowanego w istniejącym klastrze, musisz go zaimplementować. Aby uzyskać więcej informacji, zobacz Szyfrowanie węzła-węzeł. Podaj ścieżkę do lokalizacji certyfikatów. Każdy certyfikat powinien być w formacie PEM (Privacy Enhanced Mail), na przykład -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Ogólnie rzecz biorąc, istnieją dwa sposoby implementowania certyfikatów:

   • Certyfikaty z podpisem własnym. Certyfikaty prywatne i publiczne bez urzędu certyfikacji dla każdego węzła. W takim przypadku potrzebne są wszystkie certyfikaty publiczne.
   • Certyfikaty podpisane przez urząd certyfikacji. Certyfikaty wystawione przez urząd certyfikacji z podpisem własnym lub publiczny urząd certyfikacji. W takim przypadku potrzebny jest certyfikat główny CA oraz wszystkie certyfikaty pośrednie, jeśli ma to zastosowanie. Aby uzyskać więcej informacji, zobacz Prepare Secure Sockets Layer (SSL) certificates for production (Przygotowywanie certyfikatów Secure Sockets Layer (SSL).

   Opcjonalnie, jeśli chcesz zaimplementować uwierzytelnianie certyfikatu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu (TLS), podaj certyfikaty w tym samym formacie co podczas tworzenia klastra hybrydowego. Zobacz przykład interfejsu wiersza polecenia platformy Azure w dalszej części tego artykułu. Certyfikaty są udostępniane w parametrze --client-certificates .

   Takie podejście przesyła i stosuje certyfikaty klienta do magazynu zaufania Twojej usługi Azure Managed Instance w klastrze Apache Cassandra. Nie musisz edytować cassandra.yaml ustawień. Po zastosowaniu certyfikatów klaster wymaga, aby Cassandra zweryfikowała certyfikaty podczas nawiązywania połączenia przez klienta. Aby uzyskać więcej informacji, zobacz także require_client_auth: true w opcjach szyfrowania klienta client_encryption_options Cassandra.

   Wartość zmiennej podanej delegatedManagementSubnetId w tym kodzie jest taka sama jak wartość --scope podana we wcześniejszym poleceniu:

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster-legal-name'
   clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
   location='eastus2'
   delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'
   
   # You can override the cluster name if the original name isn't legal for an Azure resource:
   # overrideClusterName='ClusterNameIllegalForAzureResource'
   # the default cassandra version will be v3.11
   
   az managed-cassandra cluster create \
     --cluster-name $clusterName \
     --resource-group $resourceGroupName \
     --location $location \
     --delegated-management-subnet-id $delegatedManagementSubnetId \
     --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
     --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
     # optional - add your existing datacenter's client-to-node certificates (if implemented):
     # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
   

   Jeśli twój klaster ma już szyfrowanie komunikacji między węzłami oraz między klientem a węzłami, powinieneś wiedzieć, gdzie przechowywane są istniejące certyfikaty TLS/SSL dla klienta i komunikacji plotkarskiej. Jeśli nie masz pewności, uruchom polecenie keytool -list -keystore <keystore-path> -rfc -storepass <password> , aby wydrukować certyfikaty.

5. Po utworzeniu zasobu klastra uruchom następujące polecenie, aby uzyskać szczegóły konfiguracji klastra:

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   
   az managed-cassandra cluster show \
      --cluster-name $clusterName \
      --resource-group $resourceGroupName \
   

6. Poprzednie polecenie zwraca informacje o środowisku wystąpienia zarządzanego. Potrzebne są certyfikaty "gossip", aby móc je zainstalować w repozytorium zaufania dla węzłów w istniejącym centrum danych. Poniższy zrzut ekranu przedstawia dane wyjściowe poprzedniego polecenia i format certyfikatów.

   

   Certyfikaty zwrócone z poprzedniego polecenia zawierają złamania wierszy, które są przedstawione jako tekst. Przykładem jest \r\n. Skopiuj każdy certyfikat do pliku i sformatuj go przed próbą zaimportowania go do istniejącego magazynu zaufania.

   Skopiuj wartość tablicy gossipCertificates pokazaną na zrzucie ekranu do pliku. Użyj następującego skryptu Bash, aby sformatować certyfikaty i utworzyć dla każdego z nich oddzielne pliki PEM. Aby pobrać skrypt Bash, sprawdź Pobieranie jq dla swojej platformy.

   readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
   # iterate through the certs array, format each cert, write to a numbered file.
   num=0
   filename=""
   for item in "${cert_array[@]}"; do
   let num=num+1
   filename="cert$num.pem"
   cert=$(jq '.pem' <<< $item)
   echo -e $cert >> $filename
   sed -e 's/^"//' -e 's/"$//' -i $filename
   done
   

7. Następnie utwórz nowe centrum danych w klastrze hybrydowym. Zastąp wartości zmiennych szczegółami klastra:

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   dataCenterName='dc1'
   dataCenterLocation='eastus2'
   virtualMachineSKU='Standard_D8s_v4'
   noOfDisksPerNode=4
   
   az managed-cassandra datacenter create \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --data-center-name $dataCenterName \
     --data-center-location $dataCenterLocation \
     --delegated-subnet-id $delegatedManagementSubnetId \
     --node-count 9
     --sku $virtualMachineSKU \
     --disk-capacity $noOfDisksPerNode \
     --availability-zone false
   

   Wybierz wartość --sku z następujących dostępnych warstw produktów:

   • Standard_E8s_v4
   • Standard_E16s_v4
   • Standard_E20s_v4
   • Standard_E32s_v4
   • Standardowa_DS13_v2
   • Standardowa_DS14_v2
   • Standard_D8s_v4
   • Standard_D16s_v4
   • Standard_D32s_v4

   Wartość dla --availability-zone jest ustawiona na false. Aby włączyć strefy dostępności, ustaw tę wartość na true. Strefy dostępności zwiększają dostępność umowy dotyczącej poziomu usług (SLA) usługi. Aby uzyskać więcej informacji, zobacz Umowa SLA dla usług online.

   Strefy dostępności nie są obsługiwane we wszystkich regionach. Wdrożenia kończą się niepowodzeniem, jeśli wybierzesz region, w którym strefy dostępności nie są obsługiwane. Aby uzyskać informacje o obsługiwanych regionach, zobacz listę regionów świadczenia usługi Azure.

   Pomyślne wdrożenie stref dostępności podlega również dostępności zasobów obliczeniowych we wszystkich strefach w określonym regionie. Wdrożenia mogą zakończyć się niepowodzeniem, jeśli wybrana warstwa produktu lub pojemność nie jest dostępna we wszystkich strefach.

8. Po utworzeniu nowego centrum danych uruchom datacenter show polecenie , aby wyświetlić jego szczegóły:

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   dataCenterName='dc1'
   
   az managed-cassandra datacenter show \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --data-center-name $dataCenterName
   

   Poprzednie polecenie wyświetla węzły seed nowego centrum danych.

   

9. Dodaj węzły inicjacyjne nowego centrum danych do konfiguracji węzła inicjacji istniejącego centrum danych w pliku cassandra.yaml . Zainstaluj certyfikaty plotek wystąpienia zarządzanego zebrane wcześniej w magazynie zaufania dla każdego węzła w istniejącym klastrze. Użyj polecenia keytool dla każdego certyfikatu.

   keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
   

   Jeśli chcesz dodać więcej centrów danych, powtórz powyższe kroki, ale potrzebujesz tylko węzłów inicjujących.

   Ważne

   Jeśli istniejący klaster Apache Cassandra ma tylko jedno centrum danych, a to centrum danych jest pierwszym dodanym, upewnij się, że endpoint_snitch parametr w cassandra.yaml elemecie ma wartość GossipingPropertyFileSnitch.

   Jeśli istniejący kod aplikacji używa QUORUM w celu zapewnienia spójności, upewnij się, że zanim zmienisz ustawienia replikacji w następnym kroku, istniejący kod aplikacji korzysta z LOCAL_QUORUM do nawiązania połączenia z istniejącym klastrem. W przeciwnym razie aktualizacje na żywo kończą się niepowodzeniem po zmianie ustawień replikacji w następnym kroku. Po zmianie strategii replikacji możesz wrócić do QUORUM , jeśli wolisz.

10. Na koniec użyj następującego zapytania języka zapytań Cassandra, aby zaktualizować strategię replikacji w każdej przestrzeni kluczy, aby uwzględnić wszystkie centra danych w klastrze:

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
    

    Należy również zaktualizować kilka tabel systemowych:

    ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    

    Jeśli centra danych w istniejącym klastrze nie wymuszają szyfrowania klient-węzeł (SSL) i zamierzasz połączyć się bezpośrednio z usługą Azure Managed Instance dla usługi Apache Cassandra, musisz również włączyć protokół TLS/SSL w kodzie aplikacji.

Używanie klastra hybrydowego do migracji w czasie rzeczywistym

Powyższe instrukcje zawierają wskazówki dotyczące konfigurowania klastra hybrydowego. Takie podejście jest również doskonałym sposobem osiągnięcia bezproblemowej migracji bez przestojów. Poniższa procedura pokazuje, jak przeprowadzić migrację lokalnego środowiska Cassandra lub innego, które ma zostać wycofane z użycia, bez przestojów, do Zarządzanego Instance na platformie Azure dla usługi Apache Cassandra.

1. Konfigurowanie klastra hybrydowego. Postępuj zgodnie z poprzednimi instrukcjami.

2. Tymczasowo wyłącz automatyczne naprawy w usłudze Azure Managed Instance dla systemu Apache Cassandra podczas migracji:

   az managed-cassandra cluster update \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName --repair-enabled false
   

3. W Azure CLI użyj następującego polecenia, aby uruchomić nodetool rebuild na każdym węźle w swoim nowym wystąpieniu zarządzanym Azure dla centrum danych Apache Cassandra. Zamień <ip address> adresem IP węzła. Zastąp <sourcedc> nazwą istniejącego centrum danych, z którego migrujesz:

   az managed-cassandra cluster invoke-command \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --host <ip address> \
     --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
   

   Uruchom to polecenie dopiero po wykonaniu wszystkich poprzednich kroków. Takie podejście powinno zapewnić, że wszystkie dane historyczne są replikowane do nowych centrów danych w usłudze Azure Managed Instance dla systemu Apache Cassandra. Można uruchomić rebuild w jednym lub kilku węzłach w tym samym czasie. Uruchom proces na jednym węźle naraz, aby zmniejszyć wpływ na istniejący klaster. Uruchom polecenie na wielu węzłach, gdy klaster może obsługiwać dodatkowe operacje we/wy i ciśnienie sieciowe. W przypadku większości instalacji można uruchomić tylko jeden lub dwa równolegle, aby nie przeciążyć klastra.

   Ostrzeżenie

   Należy określić źródło data center podczas uruchamiania nodetool rebuild polecenia. Jeśli podasz centrum danych niepoprawnie podczas pierwszej próby, zakresy tokenów są kopiowane bez kopiowania danych dla tabel niesystemowych. Kolejne próby kończą się niepowodzeniem, nawet jeśli centrum danych zostanie poprawnie podane. Aby rozwiązać ten problem, usuń wpisy dla każdej przestrzeni kluczy niesystemowej w system.available_ranges przy użyciu cqlsh narzędzia zapytań w docelowym wystąpieniu zarządzanym platformy Azure dla centrum danych Apache Cassandra.

   delete from system.available_ranges where keyspace_name = 'myKeyspace';
   

4. Przełącz kod aplikacji, aby wskazywał węzły początkowe w nowym zarządzanym wystąpieniu platformy Azure dla centrów danych Apache Cassandra.

   Jak wspomniano również w instrukcjach konfiguracji hybrydowej, jeśli centra danych w istniejącym klastrze nie wymuszają szyfrowania klient-węzeł (SSL), włącz tę funkcję w kodzie aplikacji. Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra wymusza to wymaganie.

5. Uruchom ALTER KEYSPACE dla każdej przestrzeni kluczy w taki sam sposób, jak zrobiono wcześniej. Teraz możesz usunąć stare centra danych.

6. Uruchom node tool decommission dla każdego starego węzła centrum danych.

7. Przełącz kod aplikacji z powrotem na QUORUM, jeśli jest to konieczne lub preferowane.

8. Ponowne włączenie automatycznych napraw

   az managed-cassandra cluster update \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName --repair-enabled true
   

Rozwiązywanie problemów

Jeśli wystąpi błąd podczas stosowania uprawnień do sieci wirtualnej przy użyciu interfejsu wiersza polecenia platformy Azure, możesz ręcznie zastosować to samo uprawnienie w witrynie Azure Portal. Przykładem takiego błędu jest "Nie można odnaleźć użytkownika lub jednostki usługi w grafowej bazie danych programu e5007d2c-4b13-4a74-9b6a-605d99f03501." Aby uzyskać więcej informacji, zobacz Dodawanie jednostki usługi Azure Cosmos DB za pomocą witryny Azure Portal.

Przypisanie roli usługi Azure Cosmos DB jest używane tylko do celów wdrażania. Zarządzane wystąpienia Azure dla usługi Apache Cassandra nie mają zależności od zaplecza w usłudze Azure Cosmos DB.

Czyszczenie zasobów

Jeśli nie zamierzasz nadal używać tego klastra wystąpień zarządzanych, wykonaj następujące kroki, aby go usunąć:

1. W menu po lewej stronie witryny Azure Portal wybierz pozycję Grupy zasobów.
2. Z listy wybierz grupę zasobów, którą utworzyłeś dla tego Quickstartu.
3. W okienku Przegląd grupy zasobów wybierz pozycję Usuń grupę zasobów.
4. W następnym okienku wprowadź nazwę grupy zasobów do usunięcia, a następnie wybierz pozycję Usuń.

Następny krok

Zarządzanie wystąpieniem zarządzanym platformy Azure dla zasobów apache Cassandra przy użyciu interfejsu wiersza polecenia platformy Azure