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, co pozwala na maksymalną elastyczność i kontrolę w razie potrzeby.
W tym przewodniku Szybki start pokazano, jak za pomocą poleceń interfejsu wiersza polecenia platformy Azure utworzyć klaster za pomocą wystąpienia zarządzanego platformy Azure dla usługi 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 środowiska powłoki Bash w usłudze Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Szybki start dotyczący powłoki Bash w usłudze 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 Logowanie się 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 Korzystanie z rozszerzeń w interfejsie 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.
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ł Łączenie sieci lokalnej z platformą Azure .
Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.
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
Zaloguj się do witryny Azure Portal.
Ustaw identyfikator subskrypcji w interfejsie wiersza polecenia platformy Azure:
az account set -s <Subscription_ID>Następnie utwórz sieć wirtualną z dedykowaną podsiecią w grupie zasobów:
az network vnet create -n <VNet_Name> -l eastus2 -g <Resource_Group_Name> --subnet-name <Subnet Name>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:
- Azure Storage
- Azure KeyVault
- Azure Virtual Machine Scale Sets
- Monitorowanie platformy Azure
- Identyfikator Microsoft Entra
- Zabezpieczenia platformy Azure
Zastosuj pewne specjalne uprawnienia do sieci wirtualnej, które są wymagane przez wystąpienie zarządzane.
az role assignment createUż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
assigneeirolew poprzednim poleceniu są stałymi wartościami, wprowadź te wartości dokładnie tak, jak wspomniano w poleceniu. Nie spowoduje to wystąpienia błędów podczas tworzenia klastra. Jeśli podczas wykonywania tego polecenia wystąpią błędy, być może nie masz uprawnień do jego uruchomienia, skontaktuj się z administratorem, aby uzyskać uprawnienia.Następnie utwórz klaster w nowo utworzonej sieci wirtualnej przy użyciu polecenia az managed-cassandra cluster create . Uruchom następujące polecenie, aby uruchomić wartość zmiennej
delegatedManagementSubnetId:Uwaga
Wartość podanej
delegatedManagementSubnetIdponiżej zmiennej jest dokładnie taka sama jak wartość--scopepodana w powyższym poleceniu: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='3.11' # 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 \ --debugNa koniec utwórz centrum danych dla klastra z trzema węzłami, standardową jednostkę SKU maszyny wirtualnej D8s w wersji 4 z dołączonymi dyskami P30 dla każdego węzła przy użyciu 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 falseUwaga
Wartość dla
--skuprogramu 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-zoneustawiono wartośćfalse. Aby włączyć strefy dostępności, ustaw tę opcję natrue. 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.
Po utworzeniu centrum danych, jeśli chcesz skalować w górę lub skalować węzły w dół w centrum danych, uruchom polecenie az managed-cassandra datacenter update . Zmień wartość parametru
node-countna żądaną 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
Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra nie tworzy węzłów z publicznymi adresami IP. Aby nawiązać połączenie z nowo utworzonym klastrem Cassandra, należy utworzyć inny zasób w sieci wirtualnej. Ten zasób może być aplikacją lub maszyną wirtualną z zainstalowanym narzędziem zapytań open source platformy Apache CQLSH . Aby wdrożyć maszynę wirtualną z systemem Ubuntu, możesz użyć szablonu usługi Resource Manager.
Nawiązywanie połączenia z protokołu CQLSH
Po wdrożeniu maszyny wirtualnej użyj protokołu SSH, aby nawiązać połączenie z maszyną i zainstalować protokół CQLSH, jak pokazano w następujących poleceniach:
# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre
# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra
# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false
# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl
Nawiązywanie połączenia z aplikacji
Podobnie jak w przypadku protokołu CQLSH, nawiązywanie połączenia z aplikacji przy użyciu jednego z obsługiwanych sterowników klienta apache Cassandra wymaga włączenia szyfrowania SSL i wyłączenia weryfikacji certyfikacji. Zobacz przykłady nawiązywania połączenia z usługą Azure Managed Instance dla systemu Apache Cassandra przy użyciu języków Java, .NET, Node.js i Python.
Wyłączenie weryfikacji certyfikatu jest zalecane, ponieważ weryfikacja certyfikatu nie będzie działać, chyba że zamapujesz adresy I.P węzłów klastra na odpowiednią domenę. Jeśli masz zasady wewnętrzne, które wymagają weryfikacji certyfikatu SSL dla dowolnej aplikacji, możesz to ułatwić, dodając wpisy, takie jak 10.0.1.5 host1.managedcassandra.cosmos.azure.com w pliku hosts dla każdego węzła. W przypadku tego podejścia należy również dodać nowe wpisy przy każdym skalowaniu węzłów w górę.
W przypadku języka Java zdecydowanie zalecamy również włączenie zasad wykonywania spekulacyjnego, w których aplikacje są wrażliwe na opóźnienia końcowe. Pokaz ilustrujący sposób działania i sposób włączania zasad można znaleźć tutaj.
Uwaga
W większości przypadków nie należy konfigurować ani instalować certyfikatów (rootCA, node lub client, truststores itp.), aby nawiązać połączenie z usługą Azure Managed Instance dla usługi Apache Cassandra. Szyfrowanie SSL można włączyć przy użyciu domyślnego magazynu zaufania i hasła środowiska uruchomieniowego używanego przez klienta (zobacz Java, .NET, Node.js i Python ), ponieważ certyfikaty usługi Azure Managed Instance dla usługi Apache Cassandra będą zaufane przez to środowisko. W rzadkich przypadkach, jeśli certyfikat nie jest zaufany, może być konieczne dodanie go 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 dla usługi Apache Cassandra, o ile zostały wykonane powyższe kroki. Jednak jeśli jest to preferowane, możesz również dodatkowo utworzyć i skonfigurować certyfikaty klienta na potrzeby uwierzytelniania. Ogólnie rzecz biorąc, istnieją dwa sposoby tworzenia certyfikatów:
- 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.
- 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).
Jeśli chcesz zaimplementować uwierzytelnianie certyfikatu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu (mTLS), musisz podać certyfikaty za pośrednictwem interfejsu wiersza polecenia platformy Azure. Poniższe polecenie przekaże i zastosuje certyfikaty klienta do magazynu zaufania dla klastra wystąpienia zarządzanego Cassandra (tj. nie trzeba edytować cassandra.yaml ustawień). 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).
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, 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
Gdy grupa zasobów, wystąpienie zarządzane i wszystkie powiązane zasoby nie będą już potrzebne, możesz użyć az group delete polecenia :
az group delete --name <Resource_Group_Name>
Następne kroki
W tym przewodniku Szybki start przedstawiono sposób tworzenia wystąpienia zarządzanego platformy Azure dla klastra Apache Cassandra przy użyciu interfejsu wiersza polecenia platformy Azure. Teraz możesz rozpocząć pracę z klastrem: