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, co pozwala na maksymalną elastyczność i kontrolę w razie potrzeby.

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.

• Interfejs 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.

• Usługa Azure Virtual Network z łącznością ze środowiskiem własnym lub 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. Otwórz kartę Podsieci i utwórz nową podsieć . Aby dowiedzieć się więcej o polach w formularzu Dodano podsieć , zobacz Dodawanie podsieci.

   

   Uwaga

   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 zarządzanej bazy danych Cassandra. Aby uzyskać listę adresów IP i zależności portów, zobacz Wymagane reguły sieci wychodzącej.

   • Azure Storage
   • Azure KeyVault
   • Zestawy skalowania maszyn wirtualnych Azure
   • Monitorowanie platformy Azure
   • Identyfikator Microsoft Entra
   • Zabezpieczenia platformy Azure

3. Zastosuj specjalne uprawnienia do sieci wirtualnej i podsieci, które wymaga instancja zarządzana Cassandra, używając interfejsu wiersza polecenia platformy Azure. az role assignment create Użyj polecenia , zastępując <subscriptionID>wartości , <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>
   

   Uwaga

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

4. Skonfiguruj zasoby dla naszego klastra hybrydowego. Ponieważ masz już klaster, nazwa klastra jest zasobem logicznym umożliwiającym zidentyfikowanie nazwy istniejącego klastra. Pamiętaj, aby użyć nazwy istniejącego klastra podczas definiowania clusterName zmiennych i clusterNameOverride w poniższym skrypecie.

   Potrzebne są również co najmniej węzły inicjacyjne z istniejącego centrum danych oraz certyfikaty plotek wymagane do szyfrowania węzła do węzła. 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, zaimplementuj je. Aby uzyskać więcej informacji, zobacz Szyfrowanie węzła-węzeł. Podaj ścieżkę do lokalizacji certyfikatów. Każdy certyfikat powinien mieć format PEM, 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. Prywatny i publiczny certyfikat (bez CA) dla każdego węzła. W takim przypadku potrzebne są wszystkie certyfikaty publiczne.

   • Certyfikaty podpisane przez urząd certyfikacji. Ten certyfikat może być urzędem certyfikacji z podpisem własnym lub być wydany przez publiczny urząd certyfikacji. W takim przypadku potrzebujemy certyfikatu głównego urzędu certyfikacji i wszystkich pośredników, jeśli ma to zastosowanie. Aby uzyskać więcej informacji, zobacz Przygotowywanie certyfikatów SSL do produkcji.

   Opcjonalnie, jeśli chcesz zaimplementować uwierzytelnianie certyfikatu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu (mTLS), 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 przekazuje i stosuje certyfikaty klienta do magazynu zaufania dla zarządzanego klastra instancji Cassandra. Oznacza to, że nie trzeba edytować ustawień cassandra.yaml . Po zastosowaniu, klaster wymaga, aby Cassandra zweryfikowała certyfikaty, gdy klient się łączy. Sprawdź require_client_auth: true w opcjach_szyfrowania_klienta Cassandra client_encryption_options.

   Uwaga

   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
   

   Uwaga

   Jeśli klaster ma już szyfrowanie typu node-to-node i client-to-node, należy wiedzieć, gdzie są przechowywane istniejące certyfikaty SSL klienta i/lub plotek. 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:

   

   Uwaga

   Certyfikaty zwrócone z poprzedniego polecenia zawierają podziały wierszy reprezentowane jako tekst, na przykład \r\n. Należy skopiować każdy certyfikat do pliku i sformatować go przed próbą zaimportowania go do istniejącego magazynu zaufania.

   Napiwek

   gossipCertificates Skopiuj wartość tablicy pokazaną na zrzucie ekranu do pliku i użyj następującego skryptu powłoki bash, aby sformatować certyfikaty i utworzyć oddzielne pliki pem dla każdego z nich. 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
   

   Uwaga

   Wartość dla --sku programu można wybrać z następujących dostępnych jednostek SKU:

   • 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 SLA usługi. Aby uzyskać więcej informacji, zobacz Umowa SLA dla usług online.

   Ostrzeżenie

   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 platformy Azure.

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

8. Po utworzeniu nowego centrum danych uruchom polecenie show datacenter, 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
   

9. Poprzednie polecenie wyświetla węzły zalążkowe nowego centrum danych.

   

10. Dodaj węzły inicjacyjne nowego centrum danych do konfiguracji węzła inicjacji istniejącego centrum danych w pliku cassandra.yaml . Zainstaluj certyfikaty "gossip" dla zarządzanego wystąpienia, które zostały wcześniej zebrane, do magazynu zaufania dla każdego węzła w istniejącym klastrze, używając polecenia keytool dla każdego certyfikatu.

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

    Uwaga

    Jeśli chcesz dodać więcej centrów danych, możesz powtórzyć powyższe kroki, ale potrzebne są tylko węzły inicjujące.

    Ważne

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

    Ważne

    Jeśli istniejący kod aplikacji używa kwORUM w celu zapewnienia spójności, upewnij się, że przed zmianą ustawień replikacji w następnym kroku istniejący kod aplikacji używa LOCAL_QUORUM do łączenia się 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żna powrócić do QUORUM, jeśli jest to preferowane.

11. Na koniec użyj następującego zapytania CQL, 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}
    

    Ważne

    Jeśli centra danych w istniejącym klastrze nie wymuszają szyfrowania typu klient-węzeł (SSL) i zamierzasz, aby kod aplikacji łączył się bezpośrednio z wystąpieniem zarządzanym usługi Cassandra, należy również włączyć protokół 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 dotyczy migracji środowiska lokalnego lub innego środowiska Cassandra, które planujesz zlikwidować, do wystąpienia zarządzanego na platformie Azure dla systemu Apache Cassandra, bez żadnych przestojów.

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 interfejsie wiersza polecenia platformy Azure użyj następującego polecenia, aby uruchomić nodetool rebuild na każdym węźle w nowym wystąpieniu zarządzanym platformy Azure dla centrum danych Apache Cassandra. Zastąp <ip address> adresem IP węzła, a <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>"=""
   

   To polecenie należy uruchomić 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ć ponowne kompilowanie na co najmniej jednym węźle jednocześnie. Uruchom polecenie w 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 jedną lub dwie równolegle, aby nie przeciążyć klastra.

   Ostrzeżenie

   Należy określić źródłowe centrum danych podczas uruchamiania nodetool rebuild. Jeśli podasz centrum danych niepoprawnie podczas pierwszej próby, spowoduje to skopiowanie zakresów tokenów bez kopiowania danych dla tabel niesystemowych. Kolejne próby kończą się niepowodzeniem, nawet jeśli centrum danych zostanie poprawnie podane. Ten problem można rozwiązać, usuwając wpisy dla każdej przestrzeni kluczy nienależącej do systemu z system.available_ranges, używając narzędzia zapytań cqlsh w docelowym centrum danych Cassandra MI.

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

4. Zmień kod aplikacji, aby wskazać węzły startowe w nowym zarządzanym wystąpieniu platformy Azure dla centrów danych Apache Cassandra.

   Ważne

   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, ponieważ wystąpienie zarządzane cassandra wymusza to wymaganie.

5. Uruchom polecenie ALTER KEYSPACE dla każdej przestrzeni kluczy w taki sam sposób, jak wcześniej, ale teraz usuń stare centra danych.

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

7. Przełącz kod aplikacji z powrotem na model kworum, jeśli jest to wymagane lub preferowane.

8. Ponowne włączanie 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 dla 'e5007d2c-4b13-4a74-9b6a-605d99f03501'. Aby uzyskać więcej informacji, zobacz Jak użyć Portalu Azure do dodania jednostki usługi Azure Cosmos DB.

Uwaga

Przypisanie roli usługi Azure Cosmos DB jest używane tylko do celów wdrażania. Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra nie ma zależności zaplecza w usłudze Azure Cosmos DB.

Czyszczenie zasobów

Jeśli nie zamierzasz nadal używać tego klastra wystąpień zarządzanych, usuń go, wykonując następujące czynności:

1. W menu po lewej stronie witryny Azure Portal wybierz pozycję Grupy zasobów.
2. Z listy wybierz grupę zasobów utworzoną na potrzeby tego przewodnika Szybki start.
3. W okienku Przegląd grupy zasobów wybierz pozycję Usuń grupę zasobów.
4. W następnym oknie 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