Udostępnij za pomocą

Szybki start: tworzenie wystąpienia zarządzanego platformy Azure dla klastra Apache Cassandra przy użyciu interfejsu wiersza polecenia platformy Azure

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 samouczku pokazano, jak używać poleceń Azure CLI do tworzenia klastra przy użyciu zarządzanego wystąpienia platformy Azure dla Apache Cassandra. Pokazano również, jak utworzyć centrum danych i skalować węzły w górę lub w dół w centrum danych.

Wymagania wstępne

Ważne

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.

Tworzenie klastra wystąpienia zarządzanego

  1. Zaloguj się do witryny Azure Portal.

  2. Ustaw identyfikator subskrypcji w interfejsie wiersza polecenia platformy Azure:

    az account set --subscription <Subscription_ID>

  3. Utwórz sieć wirtualną z dedykowaną podsiecią w grupie zasobów:

    az network vnet create --name <VNet_Name> --location eastus2 \
  --resource-group <Resource_Group_Name> --subnet-name <Subnet Name>

    Wdrożenie wystąpienia 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 usług platformy Azure wymaganych do prawidłowego działania usługi Azure Managed Instance dla usługi Apache Cassandra:

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

  4. Zastosuj te określone uprawnienia do sieci wirtualnej. Wystąpienie zarządzane wymaga ich. Użyj polecenia az role assignment create, a następnie 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 są stałymi wartościami. Wprowadź te wartości dokładnie tak, jak wspomniano w poleceniu . Niezastosowanie się do tego prowadzi do błędów podczas tworzenia klastra. Jeśli podczas uruchamiania tego polecenia wystąpią jakiekolwiek błędy, być może nie masz uprawnień do jego uruchomienia. Skontaktuj się z administratorem platformy Azure, aby uzyskać uprawnienia.

  5. Utwórz klaster w nowo utworzonej sieci wirtualnej przy użyciu polecenia az managed-cassandra cluster create . Uruchom następujące polecenie z wartością zmiennej delegatedManagementSubnetId . (Wartość delegatedManagementSubnetId to ta sama nazwa sieci wirtualnej, dla której zastosowano uprawnienia).

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster_Name>'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<VNet name>/subnets/<subnet name>'
initialCassandraAdminPassword='myPassword'
cassandraVersion='5.0' # set to 4.0 for a Cassandra 4.0 cluster

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --initial-cassandra-admin-password $initialCassandraAdminPassword \
  --cassandra-version $cassandraVersion \
  --debug

  6. Utwórz centrum danych dla klastra z trzema maszynami wirtualnymi. Użyj następującej konfiguracji:

    • Rozmiar maszyny wirtualnej: Standard E8s v5
    • Dyski danych: 4 dyski P30 dołączone do każdej wdrożonej maszyny wirtualnej

    Po utworzeniu wszystkich informacji użyj polecenia az managed-cassandra datacenter create :

    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 3 \
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

    Wybierz wartość --sku dla następujących dostępnych rozmiarów maszyn wirtualnych:

    • Standard_E8s_v5
    • Standard_E16s_v5
    • Standard_E20s_v5
    • Standard_E32s_v5

    Domyślnie --availability-zone jest ustawiona na wartość false. Aby włączyć strefy dostępności, ustaw ją na true. Strefy dostępności pomagają zwiększyć dostępność usługi. Aby uzyskać więcej informacji, zobacz umowy dotyczące poziomu usług dotyczące usług online.

    Strefy dostępności nie są obsługiwane we wszystkich regionach świadczenia usługi Azure. 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 dostępności zasobów obliczeniowych we wszystkich strefach w wybranym regionie. Wdrożenia kończą się niepowodzeniem, jeśli wybrany rozmiar maszyny wirtualnej nie jest dostępny w wybranym regionie.

  7. Po utworzeniu centrum danych można uruchomić polecenie az managed-cassandra datacenter update , aby skalować w dół lub skalować w górę klastra. Zmień wartość parametru node-count na odpowiednią wartość:

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'
dataCenterName='dc1'
dataCenterLocation='eastus2'

az managed-cassandra datacenter update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --node-count 9

Nawiązywanie połączenia z klastrem

Zarządzane wystąpienie Azure dla Apache Cassandra nie tworzy węzłów z publicznymi adresami IP. Aby nawiązać połączenie z nowym klastrem Cassandra, musisz utworzyć inny zasób w tej samej sieci wirtualnej. Ten zasób może być aplikacją lub maszyną wirtualną z zainstalowaną powłoką języka zapytań Cassandra (CQLSH). CQLSH to narzędzie zapytań typu open source apache.

Aby wdrożyć maszynę wirtualną z systemem Ubuntu, możesz użyć szablonu usługi Azure Resource Manager .

Ze względu na niektóre znane problemy z wersjami języka Python zalecamy użycie obrazu z systemem Ubuntu 22.04 dostarczanego z językiem Python3.10.12 lub środowiskiem wirtualnym języka Python do uruchamiania języka CQLSH.

Nawiązywanie połączenia z poziomu protokołu CQLSH

Po wdrożeniu maszyny wirtualnej użyj protokołu Secure Shell, aby nawiązać połączenie z maszyną i zainstalować protokół CQLSH. Użyj następujących poleceń:

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

Sprawdź, które wersje systemu Cassandra są nadal obsługiwane , i wybierz potrzebną wersję. Zalecamy używanie stabilnej wersji.

Zainstaluj biblioteki Cassandra, aby uzyskać protokół CQLSH. Postępuj zgodnie z oficjalnymi krokami z dokumentacji bazy danych Cassandra.

Nawiązywanie połączenia z aplikacji

Podobnie jak w przypadku protokołu CQLSH, jeśli używasz jednego z obsługiwanych sterowników klienta apache Cassandra do nawiązywania połączenia z aplikacji, szyfrowanie Transport Layer Security/Secure Sockets Layer (TLS/SSL) musi być włączone, a weryfikacja certyfikatu musi być wyłączona. Aby uzyskać przykłady, zobacz Java, .NET, Node.jsi Python.

Zalecamy wyłączenie weryfikacji certyfikatu, ponieważ nie działa, chyba że zamapujesz adresy IP węzłów klastra na odpowiednią domenę. Jeśli zasady wewnętrzne wymagają weryfikacji certyfikatu TLS/SSL dla dowolnej aplikacji, dodaj wpisy, takie jak 10.0.1.5 host1.managedcassandra.cosmos.azure.com w pliku hosts dla każdego węzła, aby ułatwić tę konfigurację. Jeśli to podejście jest stosowane, należy również dodać nowe wpisy przy każdym skalowaniu węzłów w górę.

W przypadku języka Java zalecamy włączenie zasad wykonywania spekulacyjnego , w których aplikacje są wrażliwe na opóźnienia końcowe. Aby zapoznać się z pokazem ilustrującym sposób działania tego podejścia i zobaczyć, jak włączyć politykę, zobacz Implementowanie polityki wykonywania spekulacyjnego.

Zwykle nie trzeba konfigurować certyfikatów (takich jak rootCA, node, clientlub truststore) w celu nawiązania połączenia z wystąpieniem zarządzanym platformy Azure dla usługi Apache Cassandra. Szyfrowanie TLS/SSL używa domyślnego repozytorium zaufania i wybranego hasła czasu działania klienta. Aby uzyskać przykładowy kod, zobacz Java, .NET, Node.jsi Python). Certyfikaty są domyślnie zaufane. Jeśli nie, dodaj je do magazynu zaufania.

Konfigurowanie certyfikatów klienta (opcjonalnie)

Konfigurowanie certyfikatów klienta jest opcjonalne. Aplikacja kliencka może nawiązać połączenie z usługą Azure Managed Instance for Apache Cassandra po wykonaniu powyższych kroków. Jeśli wolisz, możesz również utworzyć i skonfigurować certyfikaty klienta na potrzeby uwierzytelniania. Ogólnie rzecz biorąc, istnieją dwa sposoby tworzenia certyfikatów:

  • Certyfikaty z podpisem własnym: Certyfikaty prywatne i publiczne bez urzędu certyfikacji dla każdego węzła. W takim przypadku wymagane 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 przypadku tej konfiguracji potrzebny jest certyfikat głównego urzędu certyfikacji i wszystkie certyfikaty pośredniczące, jeśli ma to zastosowanie. Aby uzyskać więcej informacji, zobacz Przygotowywanie certyfikatów SSL do produkcji.

Aby zaimplementować uwierzytelnianie certyfikatu typu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu, podaj certyfikaty przy użyciu interfejsu wiersza polecenia platformy Azure. Następujące polecenie przesyła i stosuje certyfikaty klienta do magazynu zaufania dla zarządzanego wystąpienia Azure dla klastra Apache Cassandra. Nie musisz modyfikować cassandra.yaml ustawień. Po zastosowaniu certyfikatów klaster wymaga, aby Cassandra zweryfikowała certyfikaty podczas połączeń z klientami. Aby uzyskać więcej informacji, zobacz także require_client_auth: true w opcjach szyfrowania klienta client_encryption_options Cassandra.

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

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

Gdy zasób nie jest już potrzebny, użyj az group delete polecenia , aby usunąć grupę zasobów, wystąpienie zarządzane i wszystkie powiązane zasoby:

az group delete --name <Resource_Group_Name>

Następny krok

W tym szybkim starcie nauczyłeś się, jak utworzyć zarządzane wystąpienie platformy Azure dla klastra Apache Cassandra przy użyciu Azure CLI. Teraz możesz rozpocząć pracę z klastrem:

Wdrażanie zarządzanego klastra Apache Spark za pomocą usługi Azure Databricks

  • Last updated on