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, co pozwala na maksymalną elastyczność i kontrolę w razie potrzeby

W tym przewodniku Szybki start pokazano, jak za pomocą witryny Azure Portal utworzyć wystąpienie zarządzane platformy Azure dla klastra Apache Cassandra.

Wymagania wstępne

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

Tworzenie klastra wystąpienia zarządzanego

1. Zaloguj się w witrynie Azure Portal.

2. Na pasku wyszukiwania wyszukaj ciąg Managed Instance dla bazy danych Apache Cassandra i wybierz wynik.

   

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

   

4. W okienku Create Managed Instance for Apache Cassandra (Tworzenie wystąpienia zarządzanego dla usługi Apache Cassandra ) wprowadź następujące szczegóły:

   • 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. Aby uzyskać więcej informacji, zobacz artykuł Omówienie grupy zasobów platformy Azure.
   • Nazwa klastra — wprowadź nazwę klastra.
   • Lokalizacja — lokalizacja , w której zostanie wdrożony klaster.
   • Wersja rozwiązania Cassandra — wersja systemu Apache Cassandra, która zostanie wdrożona.
   • Extention — rozszerzenia, które zostaną dodane, w tym cassandra Lucene Index.
   • Początkowe hasło administratora bazy danych Cassandra — hasło używane do tworzenia klastra.
   • Potwierdź hasło administratora rozwiązania Cassandra — wprowadź ponownie hasło.
   • Sieć wirtualna — wybierz wychodzącą sieć wirtualną i podsieć lub utwórz nową.
   • 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 wdrożono już klastry Cassandra usługi Azure SQL Managed Instance, usuń zaznaczenie tej opcji.

   

   Napiwek

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

   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. Aby uzyskać bardziej szczegółowe informacje, zobacz Wymagane reguły sieci wychodzącej.

   • Azure Storage
   • Azure KeyVault
   • Azure Virtual Machine Scale Sets
   • Monitorowanie platformy Azure
   • Identyfikator Microsoft Entra
   • Zabezpieczenia platformy Azure
   • Automatyczne replikowanie — wybierz formę automatycznej replikacji, która ma być używana. Dowiedz się więcej
   • Planowanie strategii zdarzeń — strategia, która ma być używana przez klaster na potrzeby zaplanowanych zdarzeń.

   Napiwek

   • StopANY oznacza zatrzymanie dowolnego węzła, gdy istnieje zaplanowany nawet dla węzła.
   • StopByRack oznacza tylko zatrzymanie węzła w danym stojaku dla danego zaplanowanego zdarzenia, np. jeśli co najmniej dwa zdarzenia są zaplanowane dla węzłów w różnych stojakach w tym samym czasie, tylko węzły w jednym stojaku zostaną zatrzymane, podczas gdy pozostałe węzły w innych stojakach są opóźnione.

5. Następnie wybierz kartę Centrum danych.

6. Wprowadź następujące informacje:

   • Nazwa centrum danych — wpisz nazwę centrum danych w polu tekstowym.
   • Strefa dostępności — zaznacz to pole, jeśli chcesz włączyć strefy dostępności.
   • Rozmiar jednostki SKU — wybierz spośród dostępnych rozmiarów jednostek SKU maszyny wirtualnej.

   

   Uwaga

   Wprowadziliśmy buforowanie zapisu (publiczna wersja zapoznawcza) przy użyciu jednostek SKU 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 jednostki SKU są wyposażone w dyski dołączone lokalnie, zapewniając znacznie większą liczbę operacji we/wy na sekundę na potrzeby operacji odczytu i mniejsze opóźnienie ogona.

   Ważne

   Buforowanie zapisu odbywa się w publicznej wersji zapoznawczej. Ta funkcja jest udostępniana bez umowy dotyczącej poziomu usług i nie jest zalecana w przypadku obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

   • L.p. dysków - Wybierz liczbę dysków p30 do dołączenia do każdego węzła Cassandra.
   • L.p. węzłów — Wybierz liczbę węzłów cassandra, które zostaną wdrożone w tym centrum danych.

   

   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.

7. Następnie wybierz pozycję Przeglądanie i tworzenie>

   Uwaga

   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, aby je wyświetlić:

   

Skalowanie centrum danych

Po wdrożeniu klastra z jednym centrum danych możesz skalować w poziomie lub w pionie, wyróżniając centrum danych i wybierając Scale przycisk:

Skalowanie w poziomie

Aby skalować w poziomie w węzłach, przesuń suwak do żądanej liczby lub po prostu edytuj wartość. Po zakończeniu naciśnij pozycję Scale.

Skalowanie w pionie

Aby skalować w górę do bardziej zaawansowanego rozmiaru jednostki SKU dla węzłów, wybierz z listy rozwijanej Sku Size . Po zakończeniu naciśnij pozycję Scale.

Uwaga

Czas potrzebny na operację skalowania zależy od różnych czynników. Może to 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 zostaną w pełni zlecone, gdy wszystkie będą wyświetlać stan "w dobrej kondycji", a stan centrum danych będzie mieć stan "powodzenie".

Dodawanie centrum danych

1. Aby dodać kolejne centrum danych, kliknij przycisk Dodaj w okienku Centrum danych:

   

   Ostrzeżenie

   Jeśli dodajesz centrum danych w innym regionie, musisz wybrać inną sieć wirtualną. Należy również upewnić się, że ta sieć wirtualna ma łączność z utworzoną powyżej siecią wirtualną regionu podstawowego (oraz innymi sieciami wirtualnymi hostującym centra danych w klastrze wystąpienia zarządzanego). Zapoznaj się z tym artykułem, aby dowiedzieć się, jak połączyć równorzędne sieci wirtualne przy użyciu witryny Azure Portal. Przed podjęciem próby wdrożenia klastra wystąpienia zarządzanego należy również upewnić się, że zastosowano odpowiednią rolę do sieci wirtualnej przy użyciu poniższego polecenia interfejsu wiersza polecenia.

       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 — zaznacz to pole wyboru, aby strefy dostępności mogły być włączone w tym centrum danych.
   • Lokalizacja — lokalizacja, w której zostanie wdrożone centrum danych.
   • Rozmiar jednostki SKU — wybierz spośród dostępnych rozmiarów jednostek SKU maszyny wirtualnej.
   • L.p. dysków - Wybierz liczbę dysków p30 do dołączenia do każdego węzła Cassandra.
   • L.p. węzłów — Wybierz liczbę węzłów cassandra, które zostaną wdrożone w tym centrum danych.
   • Sieć wirtualna — wybierz wychodzącą sieć wirtualną i podsieć.

   

   Ostrzeżenie

   Zauważ, że nie zezwalamy na tworzenie nowej sieci wirtualnej podczas dodawania centrum danych. Musisz wybrać istniejącą sieć wirtualną, a jak wspomniano powyżej, musisz upewnić się, że istnieje łączność między podsieciami docelowymi, w których zostaną wdrożone centra danych. Należy również zastosować odpowiednią rolę do sieci wirtualnej, aby zezwolić na wdrażanie (zobacz powyżej).

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 narzędziem 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 zostaną zaktualizowane automatycznie):

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

5. Jeśli dodasz centrum danych do klastra, w którym znajdują się już dane, musisz uruchomić polecenie rebuild , aby zreplikować dane historyczne. W interfejsie wiersza polecenia platformy Azure uruchom poniższe polecenie, aby wykonać polecenie nodetool rebuild w każdym węźle nowego centrum danych, zastępując <new dc ip address> ciąg adresem IP węzła i <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>"=""
   

   Ostrzeżenie

   Nie należy zezwalać klientom aplikacji na zapisywanie w nowym centrum danych do momentu zastosowania zmian replikacji przestrzeni kluczy. W przeciwnym razie ponowne kompilowanie nie będzie działać i musisz utworzyć wniosek o pomoc techniczną, aby nasz zespół mógł działać repair w Twoim imieniu.

Aktualizowanie konfiguracji bazy danych Cassandra

Usługa umożliwia aktualizację konfiguracji YAML bazy danych Cassandra w centrum danych za pośrednictwem portalu lub za pomocą poleceń interfejsu wiersza polecenia. Aby zaktualizować ustawienia w portalu:

1. Znajdź Cassandra Configuration w obszarze ustawień. Wyróżnij centrum danych, którego konfiguracja chcesz zmienić, a następnie kliknij przycisk Aktualizuj:

   

2. W wyświetlonym oknie wprowadź nazwy pól w formacie YAML, jak pokazano poniżej. Następnie kliknij przycisk aktualizuj.

   

3. Po zakończeniu aktualizacji przesłonięte wartości będą wyświetlane w okienku Cassandra Configuration :

   

   Uwaga

   W portalu są wyświetlane tylko zastąpione wartości konfiguracji bazy danych Cassandra.

   Ważne

   Upewnij się, że podane ustawienia yaml systemu Cassandra są odpowiednie dla wdrożonej wersji bazy danych Cassandra. Zobacz tutaj, aby zapoznać się z ustawieniami bazy danych Cassandra w wersji 3.11 i tutaj dla wersji 4.0. Następujące ustawienia YAML nie mogą być aktualizowane:

   • cluster_name
   • seed_provider
   • initial_token
   • autobootstrap
   • client_encryption_options
   • server_encryption_options
   • transparent_data_encryption_options
   • audit_logging_options
   • Wystawca uwierzytelnienia
   • autoryzator
   • 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
   • Partycjonowania
   • rpc_address
   • rpc_interface

Aktualizowanie wersji bazy danych Cassandra

Ważne

Oprogramowanie Cassandra 4.1, 5.0 i turnkey Version Aktualizacje są w publicznej wersji zapoznawczej. Te funkcje są udostępniane bez umowy dotyczącej poziomu usług i nie są zalecane w przypadku obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Uzupełniające warunki korzystania z wersji zapoznawczych platformy Microsoft Azure.

Istnieje możliwość przeprowadzania uaktualnień wersji głównych bezpośrednio z portalu lub za pośrednictwem interfejsu wiersza polecenia Az, programu Terraform lub szablonów usługi ARM.

1. Znajdź panel na Update karcie Przegląd

   

2. Wybierz wersję bazy danych Cassandra z listy rozwijanej.

   Ostrzeżenie

   Nie pomijaj wersji. Zalecamy zaktualizowanie tylko z jednej wersji do innej przykładowej wersji 3.11 do 4.0, od 4.0 do wersji 4.1.

   

3. Wybierz pozycję przy aktualizacji, aby zapisać.

Replikacja pod kluczem

System Cassandra 5.0 wprowadza usprawnione podejście do wdrażania klastrów w wielu regionach, oferując lepszą wygodę i wydajność. Korzystanie z funkcji replikacji gotowej do użycia, konfigurowanie klastrów z wieloma regionami i zarządzanie nimi stało się bardziej dostępne, co pozwala na bezproblemową integrację i działanie w środowiskach rozproszonych. Ta aktualizacja znacznie zmniejsza złożoność tradycyjnie związaną z wdrażaniem i konserwowaniem konfiguracji w wielu regionach, dzięki czemu użytkownicy mogą korzystać z możliwości rozwiązania Cassandra z większą łatwością i skutecznością.

Napiwek

• Brak: automatyczna replikacja jest ustawiona na brak.
• SystemKeyspaces: automatyczne replikowanie wszystkich przestrzeni kluczy systemowych (system_auth, system_traces, system_auth)
• AllKeyspaces: Automatycznie replikuj wszystkie przestrzenie kluczy i monitoruj, czy są tworzone nowe przestrzenie kluczy, a następnie automatycznie zastosuj ustawienia automatycznego replikowania.

Scenariusze automatycznej replikacji

• Podczas dodawania nowego centrum danych funkcja automatycznego replikowania w systemie Cassandra będzie bezproblemowo wykonywana 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 kluczy.

W przypadku zewnętrznych centrów danych, takich jak te hostowane lokalnie, można je uwzględnić w przestrzeniach kluczy za pośrednictwem wykorzystania zewnętrznej właściwości centrum danych. Dzięki temu system Cassandra może uwzględnić te zewnętrzne centra danych jako źródła procesu odbudowy.

Ostrzeżenie

Ustawienie automatycznej replikacji na wartość AllKeyspaces spowoduje zmianę replikacji przestrzeni kluczy w celu uwzględnienia WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Jeśli nie jest to topologia, musisz użyć usługi SystemKeyspaces, dostosować je samodzielnie i uruchomić nodetool rebuild ręcznie w klastrze usługi Azure Managed Instance for Apache Cassandra.

Co wyrejestruj klaster

1. W przypadku środowisk nieprodukcyjnych można wstrzymać/usunąć przydzielenie zasobów w klastrze, aby uniknąć naliczania opłat za nie (nadal będą naliczane opłaty za magazyn). Najpierw zmień typ klastra na NonProduction, a następnie deallocate.

Ostrzeżenie

Nie wykonuj żadnych operacji schematu ani zapisu podczas delokowania — może to prowadzić do utraty danych i w rzadkich przypadkach uszkodzenia schematu wymagającego ręcznej interwencji zespołu pomocy technicznej.

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.

Połączenie do klastra

Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra nie tworzy węzłów z publicznymi adresami IP, dlatego aby nawiązać połączenie z nowo utworzonym klastrem Cassandra, należy utworzyć inny zasób wewnątrz sieci wirtualnej. Może to być aplikacja lub maszyna wirtualna z zainstalowanym narzędziem zapytań typu open source platformy Apache CQLSH . Szablonu można użyć do wdrożenia maszyny wirtualnej z systemem Ubuntu.

Połączenie z języka CQLSH

Po wdrożeniu maszyny wirtualnej użyj protokołu SSH, aby nawiązać połączenie z maszyną, a następnie zainstaluj protokół CQLSH przy użyciu poniższych 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

Połączenie 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

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 wystąpienia zarządzanego platformy Azure dla klastra Apache Cassandra przy użyciu witryny Azure Portal. Teraz możesz rozpocząć pracę z klastrem:

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