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

  • Artykuł

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 tego klastra i obsługiwać je.

Wymagania wstępne

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

  • 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 artykuł Połą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 Dodawanie podsieci , zobacz artykuł Sieć wirtualna :

    Add a new subnet to your Virtual Network.

    Uwaga

    Wdrożenie wystąpienia zarządzanego platformy Azure 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. Możesz również znaleźć obszerną listę adresów IP i zależności portów tutaj.

    • Azure Storage
    • Azure KeyVault
    • Azure Virtual Machine Scale Sets
    • Monitorowanie platformy Azure
    • Identyfikator Microsoft Entra
    • Zabezpieczenia platformy Azure

  3. Teraz zastosujemy pewne specjalne uprawnienia do sieci wirtualnej i podsieci, której wymaga wystąpienie zarządzane Cassandra przy użyciu 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łej jednostki usługi i identyfikatorów roli.

  4. Następnie skonfigurujemy zasoby dla naszego klastra hybrydowego. Ponieważ masz już klaster, nazwa klastra w tym miejscu będzie tylko 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, musisz go zaimplementować — zapoznaj się z dokumentacją tutaj. Należy podać ścieżkę do lokalizacji certyfikatów. Każdy certyfikat powinien mieć format PEM, np. -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. Ogólnie rzecz biorąc, istnieją dwa sposoby implementowania certyfikatów:

    1. Certyfikaty z podpisem własnym. Oznacza to, że certyfikat prywatny i publiczny (bez urzędu certyfikacji) dla każdego węzła — w tym przypadku potrzebujemy wszystkich certyfikatów publicznych.

    2. Certyfikaty podpisane przez urząd certyfikacji. Może to być urząd certyfikacji z podpisem własnym, a nawet publiczny. W takim przypadku potrzebujemy certyfikatu głównego urzędu certyfikacji (zapoznaj się z instrukcjami dotyczącymi przygotowywania certyfikatów SSL do produkcji) i wszystkich pośredników (jeśli ma to zastosowanie).

    Opcjonalnie, jeśli chcesz zaimplementować uwierzytelnianie certyfikatu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu (mTLS), musisz podać certyfikaty w tym samym formacie co podczas tworzenia klastra hybrydowego. Zobacz przykład interfejsu wiersza polecenia platformy Azure poniżej — certyfikaty są udostępniane w parametrze --client-certificates . Spowoduje to przekazanie i zastosowanie certyfikatów klienta do magazynu zaufania dla klastra wystąpienia zarządzanego Cassandra (tj. nie trzeba edytować ustawień cassandra.yaml). Po zastosowaniu klaster będzie wymagać rozwiązania Cassandra zweryfikowania certyfikatów podczas nawiązywania połączenia przez klienta (zobacz require_client_auth: true w client_encryption_options Cassandra).

    Uwaga

    Wartość podanej delegatedManagementSubnetId poniżej zmiennej jest dokładnie taka sama jak wartość --scope podana w powyższym 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 is not 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, możesz uruchomić 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 będą certyfikaty plotek, aby można je było zainstalować w magazynie zaufania dla węzłów w istniejącym centrum danych. Poniższy zrzut ekranu przedstawia dane wyjściowe poprzedniego polecenia i format certyfikatów:

    Get the certificate details from the cluster.

    Uwaga

    Certyfikaty zwrócone z powyższego 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 centrum danych.

    Napiwek

    gossipCertificates Skopiuj wartość tablicy pokazaną na powyższym zrzucie ekranu do pliku i użyj następującego skryptu powłoki bash (musisz pobrać i zainstalować plik jq dla danej platformy), aby sformatować certyfikaty i utworzyć oddzielne pliki pem dla każdej z nich.

    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. Pamiętaj, aby zastąpić 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

    Należy również pamiętać, że --availability-zone ustawiono wartość false. Aby włączyć strefy dostępności, ustaw tę opcję na true. Strefy dostępności zwiększają dostępność umowy SLA usługi. Aby uzyskać więcej informacji, zapoznaj się z pełnymi szczegółami umowy SLA tutaj.

    Ostrzeżenie

    Strefy dostępności nie są obsługiwane we wszystkich regionach. Wdrożenia nie powiedzą się, jeśli wybierzesz region, w którym strefy dostępności nie są obsługiwane. Zobacz tutaj, aby zapoznać się z obsługiwanymi regionami. 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 zwraca węzły inicjatora nowego centrum danych:

    Screenshot of how to get datacenter details.

  10. Teraz dodaj węzły inicjacyjne nowego centrum danych do konfiguracji węzła inicjacji istniejącego centrum danych w pliku cassandra.yaml. Zainstaluj również certyfikaty plotek wystąpienia zarządzanego zebrane wcześniej w magazynie zaufania dla każdego węzła w istniejącym klastrze przy użyciu keytool polecenia 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 potrzebujesz tylko węzłów inicjujących.

    Ważne

    Jeśli istniejący klaster Apache Cassandra ma tylko jedno centrum danych i jest to pierwsze dodanie centrum danych, 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, przed zmianą ustawień replikacji w poniższym kroku istniejący kod aplikacji używa LOCAL_QUORUM do łączenia się z istniejącym klastrem (w przeciwnym razie aktualizacje na żywo nie powiedzą się po zmianie ustawień replikacji w poniższym kroku). Po zmianie strategii replikacji można przywrócić wartość 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 klient-węzeł (SSL) i zamierzasz, aby kod aplikacji łączył się bezpośrednio z wystąpieniem zarządzanym 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. Jest to jednak również doskonały sposób na bezproblemową migrację bez przestojów. Jeśli masz lokalne lub inne środowisko Cassandra, które chcesz zlikwidować z zerowym przestojem, na rzecz uruchamiania obciążenia w usłudze Azure Managed Instance dla systemu Apache Cassandra należy wykonać następujące kroki w następującej kolejności:

  1. Konfigurowanie klastra hybrydowego — postępuj zgodnie z powyższymi instrukcjami.

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

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

  3. W interfejsie wiersza polecenia platformy Azure uruchom poniższe polecenie, aby wykonać polecenie nodetool rebuild na każdym węźle w nowym wystąpieniu zarządzanym platformy Azure dla centrum danych Apache Cassandra, zastępując <ip address> element adresem IP węzła i <sourcedc> nazwą istniejącego centrum danych (z którego przeprowadzasz migrację):

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

    Należy to uruchomić dopiero po wykonaniu wszystkich poprzednich kroków. Powinno to zapewnić, że wszystkie dane historyczne są replikowane do nowych centrów danych w usłudze Azure Managed Instance for 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

    Podczas uruchamiania nodetool rebuildprogramu należy określić źródłowe centrum danych. 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 zakończy się niepowodzeniem, nawet jeśli centrum danych zostanie poprawnie podane. Aby rozwiązać ten problem, usuń wpisy dla każdej przestrzeni kluczy niesystemowej za system.available_ranges pomocą cqlsh narzędzia zapytania w docelowym centrum danych programu Cassandra MI:

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

  4. Przecięcie kodu aplikacji w celu wskazania węzłów inicjacji w nowym wystąpieniu zarządzanym 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), należy włączyć to w kodzie aplikacji, ponieważ wystąpienie zarządzane Cassandra wymusza to.

  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 likwiduj narzędzie NodeTool dla każdego starego węzła centrum danych.

  7. Przełącz kod aplikacji z powrotem na kworum (jeśli jest to wymagane/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, na przykład Nie można odnaleźć użytkownika lub jednostki usługi w bazie danych programu Graph dla elementu "e5007d2c-4b13-4a74-9b6a-605d99f03501", możesz zastosować to samo uprawnienie ręcznie w witrynie Azure Portal. Dowiedz się, jak to zrobić tutaj.

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ępne kroki

W tym przewodniku Szybki start przedstawiono sposób tworzenia klastra hybrydowego przy użyciu interfejsu wiersza polecenia platformy Azure i wystąpienia zarządzanego platformy Azure dla usługi Apache Cassandra. Teraz możesz rozpocząć pracę z klastrem.

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