Snabbstart: Skapa ett Azure Managed Instance för Apache Cassandra-kluster från Azure Portal

2025-08-21

Azure Managed Instance för Apache Cassandra är en fullständigt hanterad tjänst för rena Apache Cassandra-kluster med öppen källkod. Tjänsten tillåter också att konfigurationer åsidosätts, beroende på de specifika behoven för varje arbetsbelastning, för maximal flexibilitet och kontroll.

Den här snabbstarten visar hur du använder Azure Portal för att skapa ett Azure Managed Instance för Apache Cassandra-kluster.

Förutsättning

Om du inte har någon Azure-prenumeration skapar du ett kostnadsfritt konto innan du börjar.

Skapa ett hanterat instanskluster

Logga in på Azure-portalen.
I sökfältet söker du efter Hanterad instans för Apache Cassandra och väljer sedan det resultatet.
Välj Skapa hanterad instans för Apache Cassandra-kluster.
I fönstret Skapa hanterad instans för Apache Cassandra anger du följande information:
- Prenumeration: Välj din Azure-prenumeration i listrutan.
- Resursgrupp: Ange om du vill skapa en ny resursgrupp eller använda en befintlig. En resursgrupp är en container som innehåller relaterade resurser för en Azure-lösning.
- Klusternamn: Ange ett namn för klustret.
- Plats: Välj den plats där klustret ska distribueras.
- Cassandra-version: Välj den version av Apache Cassandra som ska distribueras.
- Tillägg: Välj tillägg att lägga till, inklusive Cassandra Lucene Index. Detta är endast relevant för Cassandra v3.11.
- Initialt Cassandra-administratörslösenord: Ange det lösenord som används för att skapa klustret.
- Bekräfta Cassandra-administratörslösenordet: Ange lösenordet igen.
- Virtuellt nätverk: Välj ett befintligt virtuellt nätverk och undernät eller skapa ett nytt. Anteckna nätverksregler eller så kan du använda VPN-baserad konfiguration.
- Tilldela roller: Virtuella nätverk kräver särskilda behörigheter för att tillåta att hanterade Cassandra-kluster distribueras. Behåll den här rutan markerad om du skapar ett nytt virtuellt nätverk eller använder ett befintligt virtuellt nätverk utan att behörigheter har tillämpats. Om du använder ett virtuellt nätverk där du tidigare distribuerade Azure SQL Managed Instance Cassandra-kluster avmarkerar du det här alternativet.
Om du använder ett virtuellt privat nätverk behöver du inte öppna en annan anslutning.

Distributionen av Azure Managed Instance för Apache Cassandra kräver internetåtkomst. Distributionen misslyckas i miljöer där Internetåtkomst är begränsad. Kontrollera att du inte blockerar åtkomsten i ditt virtuella nätverk till följande viktiga Azure-tjänster som krävs för att Managed Cassandra ska fungera korrekt. Mer information finns i Obligatoriska regler för utgående nätverk.
- Azure Storage
- Azure 密钥保管库
- Azure Virtuella Maskin Skalsatser
- Azure Monitor
- Microsoft Entra ID
- Microsoft Defender för molnet
- Automatisk replikering: Välj den form av autoreplikering som ska användas. Mer information finns i Nyckelfärdig replikering.
- Strategi för schemaläggning av händelser: Den strategi som klustret använder för schemalagda händelser.
Tips
- StopANY innebär att stoppa alla noder när det finns en schemalagd händelse för noden.
- StopByRack innebär att stoppa noder endast i ett specifikt rack för en specifik schemalagd händelse. Om till exempel flera händelser schemaläggs för noder i olika rack samtidigt, stoppas noder i endast ett rack. Andra noder i andra rack fördröjs.
Välj fliken Datacenter .
Ange följande information:
- Datacenternamn: Ange ett datacenternamn i textfältet.
- Tillgänglighetszon: Markera den här kryssrutan om du vill aktivera tillgänglighetszoner.
- SKU-storlek: Välj mellan de tillgängliga produktnivåstorlekarna för den virtuella datorn (VM).
Vi introducerade write-through cache (offentlig förhandsversion) genom att använda L-serien VM-produktnivåer. Den här implementeringen syftar till att minimera svarstider och förbättra läsprestanda, särskilt för läsintensiva arbetsbelastningar. Dessa specifika produktnivåer är utrustade med lokalt anslutna diskar, vilket säkerställer ökad IOPS för läsåtgärder och minskad svarstid.

Cachelagring via skrivning tillhandahålls utan ett serviceavtal (SLA). Vi rekommenderar det inte för produktionsarbetsbelastningar. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.
- Nej. av diskar: Välj antalet p30-diskar som ska kopplas till varje Cassandra-nod.
- Nej. av noder: Välj antalet Cassandra-noder som ska distribueras till det här datacentret.
Tillgänglighetszoner stöds inte i alla regioner. Distributioner misslyckas om du väljer en region där tillgänglighetszoner inte stöds. Mer information finns i listan över Azure-regioner.

Den lyckade distributionen av tillgänglighetszoner är också beroende av tillgängligheten för beräkningsresurser i alla zoner i den specifika regionen. Distributioner kan misslyckas om den produktnivå som du har valt, eller kapaciteten, inte är tillgänglig i alla zoner.
Välj Skapa + granska>Skapa.

Det kan ta upp till 15 minuter att skapa ett kluster.
När distributionen är klar kontrollerar du resursgruppen för att se det nyligen skapade klustret av hanterade instanser.
Om du vill bläddra igenom klusternoderna går du till klusterresursen och öppnar fönstret Datacenter .

Skala ett datacenter

När du har distribuerat ett kluster med ett enda datacenter kan du skala vågrätt eller lodrätt. Markera datacentret och välj sedan Skala.

Horisontell skalning

Om du vill skala ut eller skala in på noder flyttar du skjutreglaget till önskat tal. Du kan också redigera värdet. När du är klar väljer du Skala.

Lodrät skala

Om du vill skala upp eller skala ned produktnivåstorleken för dina noder väljer du alternativ i listrutan SKU-storlek . När du är klar väljer du Skala.

Hur lång tid det tar för en skalningsåtgärd beror på olika faktorer. Åtgärden kan ta flera minuter. När Azure meddelar dig att skalningsåtgärden är klar betyder det inte att alla dina noder är anslutna till Cassandra-ringen. Noder installeras fullt ut när de alla visar statusen Frisk och datacenterstatusen läser Uppnådd.

Skalning är en onlineåtgärd och fungerar på samma sätt som beskrivs för korrigering. För mer information, se Patchning.

Lägga till ett datacenter

Om du vill lägga till ett annat datacenter går du till fönstret Datacenter och väljer Lägg till.

Om du lägger till ett datacenter i en annan region måste du välja ett annat virtuellt nätverk. Kontrollera att det här virtuella nätverket har anslutning till den primära regionens virtuella nätverk som skapades tidigare. Kontrollera också att alla andra virtuella nätverk som är värdar för datacenter finns i det hanterade instansklustret. För mer information, se Anslut virtuella nätverk med nätverkspeering.

Kontrollera att du har tillämpat rätt roll på ditt virtuella nätverk innan du försöker distribuera ett kluster av hanterade instanser. Använd följande Azure CLI-kommando:
```
   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>
```
Fyll i lämpliga fält:
- Datacenternamn: I listrutan väljer du din Azure-prenumeration.
- Tillgänglighetszon: Välj om du vill aktivera tillgänglighetszoner i det här datacentret.
- Plats: Plats där ditt datacenter distribueras.
- SKU-storlek: Välj mellan tillgängliga vm-produktnivåstorlekar.
- Nej. av diskar: Välj antalet p30-diskar som ska kopplas till varje Cassandra-nod.
- Nej. av noder: Välj antalet Cassandra-noder som ska distribueras till det här datacentret.
- Virtuellt nätverk: Välj ett befintligt virtuellt nätverk och undernät.
Azure-portalen tillåter inte att ett nytt virtuellt nätverk skapas när du lägger till ett datacenter. Du måste välja ett befintligt virtuellt nätverk och du måste se till att det finns en anslutning mellan målundernäten där datacenter distribueras. Du måste också använda lämplig roll för det virtuella nätverket för att tillåta distribution, enligt beskrivningen tidigare.
När datacentret har distribuerats bör du kunna visa all datacenterinformation i fönstret Datacenter .
För att säkerställa replikering mellan datacenter ansluter du till Cassandra Query Language Shell (CQLSH) och använder följande CQL-fråga för att uppdatera replikeringsstrategin i varje nyckelområde för att inkludera alla datacenter i klustret. Systemtabeller uppdateras automatiskt.
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
Om du lägger till ett datacenter i ett kluster som redan har data kör du rebuild för att replikera historiska data. I Azure CLI använder du följande kommando och kör nodetool rebuild på varje nod i det nya datacentret. Den här åtgärden ersätter med nodens <new dc ip address> IP-adress och ersätter <olddc> med namnet på ditt befintliga datacenter:
```
 az managed-cassandra cluster invoke-command \
   --resource-group $resourceGroupName \
   --cluster-name $clusterName \
   --host <new dc ip address> \
   --command-name nodetool --arguments rebuild="" "<olddc>"=""
```

Tillåt inte att programklienter skriver till det nya datacentret förrän du har tillämpat ändringar i nyckelområdesreplikeringen. Annars fungerar inte återskapande och du måste skapa en supportbegäran så att vårt team kan köra repair åt dig.

Uppdatera Cassandra-konfiguration

Du kan använda Azure-portalen eller CLI-kommandon för att uppdatera Cassandra YAML-konfigurationen i ett datacenter. Så här uppdaterar du inställningarna i portalen:

Under Inställningar väljer du Cassandra-konfiguration. Markera det datacenter vars konfiguration du vill ändra och välj sedan Uppdatera.
I fönstret som öppnas anger du fältnamnen i YAML-format, som du ser här. Välj sedan Uppdatera.
När uppdateringen är klar visas de åsidosatta värdena i fönstret Cassandra-konfiguration .

Endast åsidosatta Cassandra-konfigurationsvärden visas i Azure-portalen.

Kontrollera att de Cassandra YAML-inställningar som du anger är lämpliga för den version av Cassandra som du har distribuerat. Mer information finns i [Cassandra v5.0] (https://github.com/apache/cassandra/blob/cassandra-5.0/conf/cassandra.yaml) och Cassandra v4.0 för v4.0 och Cassandra v3.11 för Cassandra v3.11-inställningar. Du kan inte uppdatera följande YAML-inställningar:
- 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

Uppdatera Cassandra-versionen

Cassandra 5.0 och uppdateringar av Turnkey-versionen är tillgängliga i offentlig förhandsgranskning. Dessa funktioner tillhandahålls utan serviceavtal. Vi rekommenderar inte dessa funktioner för produktionsarbetsbelastningar. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Du kan utföra huvudversionsuppgraderingar på plats direkt från portalen eller via Azure CLI-, Terraform- eller Azure Resource Manager-mallarna.

På fliken Översikt väljer du Uppdatera.
Välj Cassandra-versionen i listrutan.

Hoppa inte över versioner. Vi rekommenderar att du bara uppdaterar från en version till en annan. Uppdatera till exempel 3.11 till 4.0 eller 4.0 till 4.1 eller 4.1 till 5.0.
Välj Uppdatera för att spara.

Nyckelfärdig replikering

Cassandra 5.0 introducerar en effektiv metod för att distribuera kluster i flera regioner, vilket ger bättre bekvämlighet och effektivitet. Om du använder nyckelfärdiga replikeringsfunktioner är det mer tillgängligt att konfigurera och hantera kluster i flera regioner. Du får smidigare integrering och drift i distribuerade miljöer.

Den här uppdateringen minskar de komplexiteter som är associerade med att distribuera och underhålla flera regionkonfigurationer. Användare kan använda Cassandras funktioner med större enkelhet och effektivitet.

Ingen: Alternativet För automatisk replikering är inställt på Ingen.
Systemnyckelutrymmen: Återskapa alla systemnyckelutrymmen automatiskt (system_auth, system_tracesoch system_auth).
Alla nyckelutrymmen: Kopiera alla nyckelutrymmen automatiskt, övervaka om nya nyckelutrymmen skapas och tillämpa automatiskt nya inställningar.

Scenarier för automatisk replikering

När du lägger till ett nytt datacenter körs nodetool rebuild funktionen autoreplicera i Cassandra sömlöst för att säkerställa lyckad replikering av data i det tillagda datacentret. Om du tar bort ett datacenter utlöses en automatisk borttagning av det specifika datacentret från nyckelrymderna.

För externa datacenter, till exempel de som finns lokalt, använder du egenskapen externt datacenter för att inkludera dem i nyckelrymderna. Den här metoden gör det möjligt för Cassandra att införliva dessa externa datacenter som källor för återuppbyggnadsprocessen.

Om du anger Automatisk replikering till Alla nyckelutrymmen ändras replikeringen att inkludera:

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

Om den här topologin inte är vad du vill använda använder du SystemKeyspaces, justerar dem själv och kör nodetool rebuild dem manuellt i Azure Managed Instance för Apache Cassandra-klustret.

Deallokera ett kluster

För icke-produktionsmiljöer kan du pausa eller frigöra resurser i klustret för att undvika att debiteras för dem. Du fortsätter att debiteras för lagring. Ändra först klustertyp till Icke-produktion och välj sedan Frigör.

Använd endast klustertypen NonProduction för att spara utvecklingskostnader. Den här klustertypen kan komma med mindre produktnivåer. Använd den inte för att köra produktionsbelastningar.

Klustertyper som definieras som Icke-produktion har inte SLA-garantier som tillämpas på dem.
Kör inga schema- eller skrivåtgärder under avallokering. Den här åtgärden kan leda till dataförlust. I sällsynta fall kan det uppstå schemafel, vilket kräver manuella åtgärder från supportteamet.

Felsökning

Om du får ett fel när du tillämpar behörigheter på ditt virtuella nätverk när du använder Azure CLI kan du använda samma behörighet manuellt från Azure-portalen. Ett exempel på ett sådant fel är "Det går inte att hitta användaren eller tjänstens huvudnamn i grafdatabasen för e5007d2c-4b13-4a74-9b6a-605d99f03501" Mer information finns i Använda Azure-portalen för att lägga till Tjänstens huvudnamn för Azure Cosmos DB.

Rolltilldelningen i Azure Cosmos DB används endast i distributionssyfte. Azure Managed Instanced för Apache Cassandra har inga serverdelsberoenden i Azure Cosmos DB.

Ansluta till klustret

Azure Managed Instance för Apache Cassandra skapar inte noder med offentliga IP-adresser. Om du vill ansluta till det nyligen skapade Cassandra-klustret skapar du en annan resurs i det virtuella nätverket. Den här resursen kan vara ett program eller en virtuell dator med Apaches frågeverktyg med öppen källkod CQLSH installerat. Du kan använda en mall för att distribuera en virtuell Ubuntu-dator.

Ansluta från CQLSH

När den virtuella datorn har distribuerats använder du Secure Shell för att ansluta till datorn. Om du vill installera CQLSH använder du följande kommandon:

# 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

Ansluta från ett program

Precis som med CQLSH måste TLS/SSL-kryptering (Transport Layer Security/Secure Sockets Layer) aktiveras när du använder någon av apache Cassandra-klientdrivrutinerna som stöds för att ansluta från ett program. Certifikatverifiering måste inaktiveras. Exempel som används för att ansluta till Azure Managed Instance för Apache Cassandra finns i Java, .NET, Node.jsoch Python.

Vi rekommenderar att du inaktiverar certifikatverifiering eftersom det inte fungerar om du inte mappar IP-adresser för dina klusternoder till rätt domän. Om en intern princip kräver att du utför TLS/SSL-certifikatverifiering för alla program lägger du till poster som 10.0.1.5 host1.managedcassandra.cosmos.azure.com i värdfilen för varje nod för att underlätta den här installationen. Om du använder den här metoden måste du också lägga till nya poster när du skalar upp noder.

För Java rekommenderar vi att du aktiverar policyn för spekulativ exekvering där applikationer är känsliga för sluttidslatens. En demo som illustrerar hur den här metoden fungerar och hur du aktiverar principen finns i Demo: Implement spekulativ körning.

I de flesta fall bör det inte vara nödvändigt att konfigurera eller installera certifikat (till exempel rootCA, node, clienteller truststore) för att ansluta till Azure Managed Instance för Apache Cassandra. Om du vill aktivera TLS/SSL-kryptering använder du standard tillitsdatabasen och lösenordet för den körmiljö som klienten använder. Den miljön litar på Azure Managed Instance för Apache Cassandra-certifikat. Om certifikatet i sällsynta fall inte är betrott kan du behöva lägga till det i certifikatarkivet. Exempelkod finns i Java, .NET, Node.jsoch Python.

Konfigurera klientcertifikat (valfritt)

Det är valfritt att konfigurera klientcertifikat. Ett klientprogram kan ansluta till Azure Managed Instance för Apache Cassandra om föregående steg har slutförts. Om du vill kan du också skapa och konfigurera klientcertifikat för autentisering. I allmänhet finns det två sätt att skapa certifikat:

Självsignerade certifikat: Privata och offentliga certifikat utan certifikatutfärdare (CA) för varje nod. I det här fallet behöver du alla offentliga certifikat.
Certifikat som signerats av en certifikatutfärdare: Certifikat som utfärdats av en självsignerad certifikatutfärdare eller en offentlig certifikatutfärdare. I det här fallet behöver du rotcertifikatet och alla intermediära certifikat, om tillämpligt. Mer information finns i Förbereda SSL-certifikat för produktion.

Om du vill implementera certifikatautentisering från klient till nod eller ömsesidig transportnivåsäkerhet (mTLS) använder du Azure CLI för att tillhandahålla certifikaten. Följande kommando laddar upp och tillämpar dina klientcertifikat till certifikatlagret för den hanterade instansklustern. Du behöver inte redigera cassandra.yaml inställningar. När du har tillämpat kommandot kräver klustret att Cassandra verifierar certifikaten när en klient ansluter. Mer information require_client_auth: true finns i Cassandra client_encryption_options.

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

Rensa resurser

Om du inte kommer att fortsätta att använda det här hanterade instansklustret följer du de här stegen för att ta bort det:

Välj Resursgrupper på den vänstra menyn på Azure-portalen.
I listan väljer du den resursgrupp som du skapade för den här snabbstarten.
I fönstret Översikt över resursgrupp väljer du Ta bort resursgrupp.
I nästa fönster anger du namnet på resursgruppen som ska tas bort och väljer sedan Ta bort.

Nästa steg

Distribuera ett hanterat Apache Spark-kluster med Azure Databricks

Feedback

Var den här sidan till hjälp?