Udostępnij za pośrednictwem

Szybki start: tworzenie Azure Managed Instance dla klastra Apache Cassandra przy użyciu Azure CLI

Azure Managed Instance dla systemu 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 szybkiego startu pokazano, jak utworzyć klaster przy użyciu poleceń Azure CLI z Azure Managed Instance 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

  • Użyj sieci wirtualnej Azure z łącznością ze środowiskiem własnym lub lokalnym. Aby uzyskać więcej informacji na temat łączenia środowisk lokalnych z Azure, zobacz Łączenie sieci lokalnej z Azure.
  • Jeśli nie masz subskrypcji Azure, przed rozpoczęciem utwórz konto free.

Ważne

Ten artykuł wymaga Azure CLI w wersji 2.30.0 lub nowszej. Jeśli używasz Azure Cloud Shell, najnowsza wersja jest już zainstalowana.

Tworzenie klastra wystąpienia zarządzanego

  1. Zaloguj się do portalu Azure.

  2. Ustaw identyfikator subskrypcji w Azure CLI:

    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 Azure Managed Instance dla systemu 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 Azure, które są wymagane dla Azure Managed Instance, aby usługa Apache Cassandra działała prawidłowo:

    • Azure Storage
    • Azure Key Vault
    • Azure Virtual Machine Scale Sets (Zestawy Szkieletowe 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 Azure w celu uzyskania uprawnień.

  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, podczas obliczania pojemności magazynu zakłada się maksymalne trwałe użycie 50%. Ten bufor odpowiada za grobowce i zużycie dysku przez usługi systemowe. Ponadto kopie zapasowe tymczasowo zużywają miejsce na dysku, zanim dane zostaną zapisane w usłudze Blob storage.

    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 dla usług online.

    Strefy dostępności nie są obsługiwane we wszystkich regionach Azure. Wdrożenia kończą się niepowodzeniem, jeśli wybierzesz region, w którym strefy dostępności nie są obsługiwane. W przypadku obsługiwanych regionów zobacz listę regionów 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

Azure Managed Instance dla usługi 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 Azure Resource Manager

Ze względu na niektóre znane problemy z wersjami Pythona zalecamy użycie obrazu Ubuntu 22.04 dostarczanego z Pythonem 3.10.12 lub środowiska wirtualnego Pythona do uruchomienia protokołu 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. Przykłady można znaleźć w Java, .NET, Node.js i 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 Java zalecamy włączenie polityki speculative execution w sytuacjach, gdy 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ć zasadę, zapoznaj się z Implement spekulacyjne zasady wykonywania.

Zwykle nie trzeba konfigurować certyfikatów (takich jak rootCA, node, client lub truststore), aby nawiązać połączenie z Azure Managed Instance 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.js i 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 Azure Managed Instance dla usługi 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 Azure CLI. Następujące polecenie przesyła i stosuje certyfikaty klienta do magazynu zaufanych certyfikatów dla Azure Managed Instance for 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 Azure CLI, możesz ręcznie zastosować to samo uprawnienie w portalu Azure. 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 Użyj portalu Azure, aby dodać jednostkę usługi Azure Cosmos DB.

Przypisanie roli Azure Cosmos DB jest używane tylko do celów wdrażania. Zarządzana instancja Azure dla systemu Apache Cassandra nie ma zależności wstecznych na 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 przewodniku nauczyłeś się, jak utworzyć zarządzaną instancję Azure dla klastra Apache Cassandra przy użyciu Azure CLI. Teraz możesz rozpocząć pracę z klastrem:

Deployowanie zarządzanego klastra Apache Spark z Azure Databricks

  • Last updated on