Szybki start: tworzenie wystąpienia zarządzanego platformy Azure dla klastra Apache Cassandra w witrynie Azure Portal

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 przewodniku quickstart pokazano, jak za pomocą portalu Azure utworzyć Azure Managed Instance dla klastra Apache Cassandra.

Warunek wstępny

Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

Utwórz klaster wystąpień zarządzanych

1. Zaloguj się w witrynie Azure Portal.

2. Na pasku wyszukiwania wyszukaj ciąg Managed Instance dla usługi Apache Cassandra i wybierz wynik.

   

3. Wybierz pozycję Utwórz wystąpienie zarządzane dla klastra Apache Cassandra.

   

4. W okienku Tworzenie wystąpienia zarządzanego dla usługi Apache Cassandra wprowadź następujące informacje:

   • Subskrypcja: z listy rozwijanej wybierz subskrypcję platformy Azure.

   • Grupa zasobów: określ, czy chcesz utworzyć nową grupę zasobów, czy użyć istniejącej. Grupa zasobów to kontener, który przechowuje powiązane zasoby dla rozwiązania platformy Azure.

   • Nazwa klastra: wprowadź nazwę klastra.

   • Lokalizacja: wybierz lokalizację do wdrożenia klastra.

   • Wersja rozwiązania Cassandra: wybierz wersję systemu Apache Cassandra do wdrożenia.

   • Rozszerzenie: wybierz rozszerzenia do dodania, w tym cassandra Lucene Index. Dotyczy to tylko bazy danych Cassandra w wersji 3.11.

   • Początkowe hasło administratora rozwiązania Cassandra: wprowadź hasło używane do utworzenia klastra.

   • Potwierdź hasło administratora rozwiązania Cassandra: wprowadź ponownie hasło.

   • Sieć wirtualna: wybierz istniejącą sieć wirtualną i podsieć lub utwórz nową. Zanotuj reguły sieci lub możesz użyć konfiguracji opartej na sieci VPN.

   • Przypisywanie ról: Sieci wirtualne wymagają specjalnych uprawnień, aby umożliwić wdrażanie zarządzanych klastrów Cassandra. Zachowaj to pole wyboru, jeśli tworzysz nową sieć wirtualną lub używasz istniejącej sieci wirtualnej bez zastosowanych uprawnień. Jeśli używasz sieci wirtualnej, w której wcześniej wdrożono klastry Cassandra usługi Azure SQL Managed Instance, wyczyść tę opcję.

     

   Jeśli używasz wirtualnej sieci prywatnej, nie musisz otwierać innego połączenia.

   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ć więcej informacji, zobacz Wymagane reguły sieci dla ruchu wychodzącego.

   • Azure Storage

   • Azure Key Vault

   • Zestawy skalowania maszyn wirtualnych Azure

   • Azure Monitor

   • Microsoft Entra ID

   • Microsoft Defender dla Chmury

   • Automatyczna replikacja: wybierz formę autoreplicacji do użycia. Aby uzyskać więcej informacji, zobacz Turnkey replication (Replikacja pod kluczem).

   • Strategia zaplanowanych zdarzeń: strategia używana przez klaster dla zaplanowanych zdarzeń.

   Napiwek

   • StopANY oznacza zatrzymanie dowolnego węzła, gdy dla węzła zaplanowane jest zdarzenie.
   • StopByRack oznacza zatrzymanie węzłów tylko w określonym stojaku w związku z konkretnym zdarzeniem. Jeśli na przykład kilka zdarzeń jest zaplanowanych dla węzłów w różnych stojakach w tym samym czasie, węzły w tylko jednym stojaku się zatrzymują. Inne węzły w innych stojakach są opóźnione.

5. Wybierz kartę Centrum danych .

6. Wprowadź następujące informacje:

   • Nazwa centrum danych: wprowadź nazwę centrum danych w polu tekstowym.

   • Strefa dostępności: zaznacz to pole wyboru, jeśli chcesz włączyć strefy dostępności.

   • Rozmiar jednostki SKU: wybierz spośród dostępnych rozmiarów warstw produktów maszyny wirtualnej.

     

   Wprowadziliśmy buforowanie zapisu (publiczna wersja zapoznawcza) przy użyciu warstw produktów maszyn wirtualnych serii L. Ta implementacja ma na celu zminimalizowanie opóźnień końcowych i zwiększenie wydajności odczytu, szczególnie w przypadku obciążeń intensywnie korzystających z odczytu. Te konkretne warstwy produktów są wyposażone w dyski dołączone lokalnie, co zapewnia zwiększoną liczbę operacji we/wy na sekundę na potrzeby operacji odczytu i mniejsze opóźnienie końcowe.

   Buforowanie typu write-through jest dostępne bez umowy dotyczącej poziomu usług (SLA). Nie zalecamy obsługi obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

   • Nie. dysków: wybierz liczbę dysków p30 do dołączenia do każdego węzła Cassandra.

   • Nie. węzłów: wybierz liczbę węzłów cassandra do wdrożenia w tym centrum danych.

     

   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ć więcej informacji, 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 określonym regionie. Wdrożenia mogą zakończyć się niepowodzeniem, jeśli wybrana warstwa produktu lub pojemność nie jest dostępna we wszystkich strefach.

7. Wybierz Przejrzyj i utwórz>Utwórz.

   Utworzenie klastra może potrwać do 15 minut.

   

8. Po zakończeniu wdrażania sprawdź grupę zasobów, aby wyświetlić nowo utworzony klaster wystąpienia zarządzanego.

   

9. Aby przeglądać węzły klastra, przejdź do zasobu klastra i otwórz okienko Centrum danych .

   

Skalowanie centrum danych

Po wdrożeniu klastra z jednym centrum danych można skalować w poziomie lub w pionie. Wyróżnij centrum danych, a następnie wybierz pozycję Skaluj.

Skalowanie w poziomie

Aby rozbudować lub zmniejszyć liczbę węzłów, przesuń suwak na żądaną liczbę. Możesz również edytować wartość. Po zakończeniu wybierz Skaluj.

Skala pionowa

Aby zwiększyć lub zmniejszyć rozmiar warstwy produktu dla węzłów, wybierz opcje z menu rozwijanego Rozmiar SKU. Po zakończeniu wybierz Skaluj.

Czas potrzebny na operację skalowania zależy od różnych czynników. Operacja może potrwać kilka minut. Gdy platforma Azure powiadomi Cię o zakończeniu operacji skalowania, nie oznacza to, że wszystkie węzły dołączyły do pierścienia Cassandra. Węzły są w pełni uruchomione, gdy wszystkie mają stan Zdrowe, a stan centrum danych to Udało się.

Skalowanie jest operacją online i działa w taki sam sposób, jak opisano w przypadku stosowania poprawek. Aby uzyskać więcej informacji, zobacz Stosowanie poprawek.

Dodawanie centrum danych

1. Aby dodać kolejne centrum danych, w okienku Centrum danych wybierz pozycję Dodaj.

   

   Jeśli dodasz centrum danych w innym regionie, musisz wybrać inną sieć wirtualną. Upewnij się, że ta sieć wirtualna ma łączność z siecią wirtualną regionu podstawowego, która została utworzona wcześniej. Upewnij się również, że wszystkie inne sieci wirtualne, na których znajdują się centra danych, są zawarte w klastrze zarządzanych instancji. Aby uzyskać więcej informacji, zobacz Łączenie sieci wirtualnych za pomocą komunikacji równorzędnej sieci wirtualnych.

   Upewnij się, że przypisałeś odpowiednią rolę swojej sieci wirtualnej, zanim spróbujesz wdrożyć klaster wystąpienia zarządzanego. Użyj następującego polecenia Azure CLI:

      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>
   

2. Wypełnij odpowiednie pola:

   • Nazwa centrum danych: z listy rozwijanej wybierz subskrypcję platformy Azure.

   • Strefa dostępności: wybierz, czy chcesz włączyć strefy dostępności w tym centrum danych.

   • Lokalizacja: lokalizacja, w której wdrożono centrum danych.

   • Rozmiar jednostki SKU: wybierz spośród dostępnych rozmiarów warstw produktów maszyny wirtualnej.

   • Nie. dysków: wybierz liczbę dysków p30 do dołączenia do każdego węzła Cassandra.

   • Nie. węzłów: wybierz liczbę węzłów cassandra do wdrożenia w tym centrum danych.

   • Sieć wirtualna: wybierz istniejącą sieć wirtualną i podsieć.

     

   Witryna Azure Portal nie zezwala na tworzenie nowej sieci wirtualnej podczas dodawania centrum danych. Musisz wybrać istniejącą sieć wirtualną i upewnić się, że istnieje łączność między podsieciami docelowymi, w których są wdrażane centra danych. Należy również zastosować odpowiednią rolę do sieci wirtualnej, aby umożliwić wdrażanie zgodnie z wcześniejszym opisem.

3. Po wdrożeniu centrum danych powinno być możliwe wyświetlenie wszystkich informacji centrum danych w okienku Centrum danych .

   

4. Aby zapewnić replikację między centrami danych, połącz się z powłoką języka zapytań Cassandra (CQLSH) i użyj następującego zapytania CQL, aby zaktualizować strategię replikacji w każdej przestrzeni kluczy, aby uwzględnić wszystkie centra danych w klastrze. Tabele systemowe są aktualizowane automatycznie.

   ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
   

5. Jeśli dodasz centrum danych do klastra, który ma już dane, uruchom polecenie rebuild , aby replikować dane historyczne. W interfejsie wiersza polecenia platformy Azure użyj następującego polecenia i uruchom polecenie nodetool rebuild w każdym węźle nowego centrum danych. Ta akcja zastępuje <new dc ip address> na adres IP węzła i zastępuje <olddc> nazwą istniejącego centrum danych.

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

Nie zezwalaj klientom aplikacji na zapisywanie w nowym centrum danych do momentu zastosowania zmian replikacji przestrzeni kluczy. W przeciwnym razie ponowne kompilowanie nie działa i musisz utworzyć wniosek o pomoc techniczną , aby nasz zespół mógł uruchomić repair dla Ciebie.

Aktualizowanie konfiguracji bazy danych Cassandra

Możesz użyć Azure portal lub poleceń CLI, aby zaktualizować konfigurację YAML Cassandry w centrum danych. Aby zaktualizować ustawienia w portalu:

1. W obszarze Ustawienia wybierz pozycję Konfiguracja bazy danych Cassandra. Wyróżnij centrum danych, którego konfiguracja chcesz zmienić, a następnie wybierz pozycję Aktualizuj.

   

2. W wyświetlonym oknie wprowadź nazwy pól w formacie YAML, jak pokazano tutaj. Następnie wybierz pozycję Aktualizuj.

   

3. Po zakończeniu aktualizacji nadpisane wartości pojawiają się w okienku Konfiguracja Cassandra.

   

   W portalu Azure wyświetlane są tylko zastąpione wartości konfiguracyjne Cassandra.

   Upewnij się, że podane ustawienia YAML bazy danych Cassandra są odpowiednie dla wdrożonej wersji bazy danych Cassandra. Aby uzyskać więcej informacji, zobacz [Cassandra v5.0] (https://github.com/apache/cassandra/blob/cassandra-5.0/conf/cassandra.yaml) i Cassandra v4.0 for v4.0 and Cassandra v3.11 for Cassandra v3.11 settings (Ustawienia cassandra w wersji 3.11). Nie można zaktualizować następujących ustawień YAML:

   • cluster_name
   • seed_provider
   • initial_token
   • autobootstrap
   • client_encryption_options
   • server_encryption_options
   • transparent_data_encryption_options
   • audit_logging_options
   • authenticator
   • authorizer
   • role_manager
   • storage_port
   • ssl_storage_port
   • native_transport_port
   • native_transport_port_ssl
   • listen_address
   • listen_interface
   • broadcast_address
   • hints_directory
   • data_file_directories
   • commitlog_directory
   • cdc_raw_directory
   • saved_caches_directory
   • endpoint_snitch
   • partitioner
   • rpc_address
   • rpc_interface

Aktualizowanie wersji bazy danych Cassandra

Aktualizacje wersji Cassandra 5.0 i Turnkey są dostępne w publicznej wersji zapoznawczej. Te funkcje są udostępniane bez umowy SLA. Nie zalecamy tych funkcji dla obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

Uaktualnienia wersji głównej można przeprowadzić bezpośrednio z poziomu portalu lub za pomocą interfejsu wiersza polecenia platformy Azure, programu Terraform lub szablonów usługi Azure Resource Manager.

1. Na karcie Przegląd wybierz pozycję Aktualizuj.

   

2. Wybierz wersję Cassandry z listy rozwijanej.

   Nie pomijaj wersji. Zalecamy zaktualizowanie tylko jednej wersji do innej. Na przykład zaktualizuj 3.11 do wersji 4.0 lub 4.0 do 4.1 lub 4.1 do 5.0.

   

3. Wybierz pozycję Aktualizuj , aby zapisać.

Replikacja pod kluczem

System Cassandra 5.0 wprowadza usprawnione podejście do wdrażania klastrów z wieloma regionami, które oferują lepszą wygodę i wydajność. Jeśli używasz funkcji replikacji typu 'pod klucz', konfiguracja i zarządzanie klastrami w wielu regionach jest prostsze. Zapewniasz bezproblemową integrację i działanie w środowiskach rozproszonych.

Ta aktualizacja zmniejsza złożoność, które są skojarzone z wdrażaniem i konserwowaniem wielu konfiguracji regionów. Użytkownicy mogą używać możliwości rozwiązania Cassandra z większą łatwością i skutecznością.

• Brak: opcja Automatyczne replikowanie jest ustawiona na Wartość Brak.
• Przestrzenie kluczy systemowych: autoreplicuj wszystkie przestrzenie kluczy systemowych (system_auth, system_traces, i system_auth).
• Wszystkie przestrzenie na klucze: Autoreplikować wszystkie przestrzenie na klucze, monitorować, czy są tworzone nowe przestrzenie na klucze, a następnie automatycznie zastosować ustawienia autoreplikacji.

Scenariusze autoreplicacji

Po dodaniu nowego centrum danych funkcja autoreplicate w systemie Cassandra bezproblemowo działa nodetool rebuild w celu zapewnienia pomyślnej replikacji danych w dodanym centrum danych. Usunięcie centrum danych powoduje automatyczne usunięcie określonego centrum danych z przestrzeni kluczowych.

W przypadku zewnętrznych centrów danych, takich jak te hostowane lokalnie, użyj zewnętrznej właściwości centrum danych, aby uwzględnić je w przestrzeniach kluczy. Takie podejście umożliwia systemowi Cassandra uwzględnienie tych zewnętrznych centrów danych jako źródeł procesu odbudowy.

Jeśli ustawisz Auto Replicate na Wszystkie przestrzenie kluczy, replikacja przestrzeni kluczy zmieni się, aby obejmować:

WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }

Jeśli ta topologia nie jest odpowiednia, użyj usługi SystemKeyspaces, dostosuj je samodzielnie i uruchom nodetool rebuild ręcznie w wystąpieniu zarządzanym platformy Azure dla klastra Apache Cassandra.

Dealokacja klastra

W przypadku środowisk nieprodukcyjnych można wstrzymać lub cofnąć przydział zasobów w klastrze, aby uniknąć naliczania opłat za nie. Nadal są naliczane opłaty za magazyn. Najpierw zmień typ klastra na NonProduction, a następnie wybierz Dealokacja.

Użyj typu klastra NonProduction tylko w celu zaoszczędzenia kosztów programowania. Ten typ klastra może zawierać mniejsze warstwy produktów. Nie używaj go do uruchamiania obciążeń produkcyjnych.

• Typy klastrów zdefiniowane jako nieprodukcyjne nie mają zastosowanych gwarancji SLA.
• Nie uruchamiaj żadnych operacji schematu ani zapisu podczas dealokacji. Ta akcja może prowadzić do utraty danych. W rzadkich przypadkach może wystąpić uszkodzenie schematu, co wymaga ręcznej interwencji zespołu pomocy technicznej.

Rozwiązywanie problemów

Jeśli wystąpi błąd podczas stosowania uprawnień do sieci wirtualnej podczas korzystania z 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.

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 nowo utworzonym klastrem Cassandra, utwórz kolejny zasób w sieci wirtualnej. Ten zasób może być aplikacją lub maszyną wirtualną z zainstalowanym narzędziem zapytań typu open source platformy Apache CQLSH . Aby wdrożyć maszynę wirtualną z systemem Ubuntu, możesz użyć szablonu .

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ą. Aby 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

# 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, 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 używane do nawiązywania połączenia z usługą Azure Managed Instance for Apache Cassandra można znaleźć w temacie 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ę.

Dla języka Java zalecamy włączenie polityki wykonywania spekulacyjnego w sytuacjach, gdy aplikacje są wrażliwe na opóźnienia końcowe. Aby zapoznać się z pokazem, który ilustruje działanie tego podejścia i zobaczyć, jak włączyć politykę, zobacz Demo: Implement speculative execution (Pokaz: wykonanie spekulatywne).

W większości przypadków nie należy konfigurować ani instalować 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. Aby włączyć szyfrowanie TLS/SSL, użyj domyślnego magazynu zaufania i hasła środowiska uruchomieniowego używanego przez klienta. To środowisko ufa Zarządzanej Instancji Azure w zakresie certyfikatów Apache Cassandra. W rzadkich przypadkach, jeśli certyfikat nie jest zaufany, może być konieczne dodanie go do magazynu zaufania. Aby uzyskać przykładowy kod, zobacz Java, .NET, Node.jsi Python.

Konfigurowanie certyfikatów klienta (opcjonalnie)

Konfigurowanie certyfikatów klienta jest opcjonalne. Jeśli powyższe kroki zostaną zakończone, aplikacja kliencka może nawiązać połączenie z usługą Azure Managed Instance dla systemu Apache Cassandra. 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 potrzebne 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 takim przypadku potrzebny jest certyfikat główny CA oraz wszystkie certyfikaty pośrednie, jeśli ma to zastosowanie. Aby uzyskać więcej informacji, zobacz Przygotowywanie certyfikatów SSL do produkcji.

Jeśli chcesz zaimplementować uwierzytelnianie certyfikatu typu klient-węzeł lub wzajemne zabezpieczenia warstwy transportu (mTLS), użyj interfejsu wiersza polecenia platformy Azure, aby dostarczyć certyfikaty. Następujące polecenie przesyła i stosuje certyfikaty klienta do magazynu zaufania klastra zarządzanego. Nie musisz edytować cassandra.yaml ustawień. Po zastosowaniu polecenia klaster wymaga, aby Cassandra weryfikowała certyfikaty, gdy klient nawiązuje połączenie. 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

Czyszczenie zasobów

Jeśli nie zamierzasz nadal używać tego klastra wystąpień zarządzanych, wykonaj następujące kroki, aby go usunąć:

1. W menu po lewej stronie witryny Azure Portal wybierz pozycję Grupy zasobów.
2. Z listy wybierz grupę zasobów, którą utworzyłeś dla tego Quickstartu.
3. W okienku Przegląd grupy zasobów wybierz pozycję Usuń grupę zasobów.
4. W następnym okienku wprowadź nazwę grupy zasobów do usunięcia, a następnie wybierz pozycję Usuń.

Następny krok

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