Snabbstart: Konfigurera ett hybridkluster med Azure Managed Instance för Apache Cassandra

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 CLI-kommandon för att konfigurera ett hybridkluster. Om du har befintliga datacenter i en lokal eller lokalt installerad miljö kan du använda Azure Managed Instance för Apache Cassandra för att lägga till andra datacenter i dessa kluster och underhålla dem.

Förutsättningar

Använd Bash-miljön i Azure Cloud Shell. Mer information finns i Kom igång med Azure Cloud Shell.
Om du föredrar att köra CLI-referenskommandon lokalt installerar du Azure CLI. Om du kör i Windows eller macOS kan du köra Azure CLI i en Docker-container. Mer information finns i Så här kör du Azure CLI i en Docker-container.
- Om du använder en lokal installation loggar du in på Azure CLI med hjälp av kommandot az login. Slutför autentiseringsprocessen genom att följa stegen som visas i terminalen. Andra inloggningsalternativ finns i Autentisera till Azure med Azure CLI.
- När du uppmanas att installera Azure CLI-tillägget vid första användningen. Mer information om tillägg finns i Använda och hantera tillägg med Azure CLI.
- Kör az version om du vill hitta versionen och de beroende bibliotek som är installerade. Om du vill uppgradera till den senaste versionen kör du az upgrade.

Den här artikeln kräver Azure CLI version 2.30.0 eller senare. Om du använder Azure Cloud Shell är den senaste versionen redan installerad.
Använd ett Azure-virtuellt nätverk med anslutning till din självhostade eller lokala miljö. Mer information om hur du ansluter lokala miljöer till Azure finns i Ansluta ett lokalt nätverk till Azure.

Konfigurera ett hybridkluster

Logga in på Azure-portalen och gå till din virtuella nätverksresurs.
Välj fliken Undernät och skapa ett nytt undernät. Mer information om fälten i formuläret Lägg till undernät finns i Lägga till ett undernät.

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 Azure Managed Instance ska fungera korrekt för Apache Cassandra. En lista över IP-adresser och portberoenden finns i Obligatoriska regler för utgående nätverk.
- Azure Storage
- Azure 密钥保管库
- Skalningsuppsättningar för virtuella Azure-datorer
- Azure Monitor
- Microsoft Entra ID
- Microsoft Defender för molnet
Använd vissa särskilda behörigheter för det virtuella nätverket och undernätet, som Azure Managed Instance för Apache Cassandra kräver, med hjälp av Azure CLI. Använd kommandot az role assignment create. Ersätt <subscriptionID>, <resourceGroupName>och <vnetName> med lämpliga värden:
```
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>
```
Värdena assignee och role i föregående kommando är fasta tjänstens huvudnamn respektive rollidentifierare.
Konfigurera resurser för ditt hybridkluster. Eftersom du redan har ett kluster är klusternamnet en logisk resurs för att identifiera namnet på ditt befintliga kluster. Använd namnet på ditt befintliga kluster när du definierar clusterName och clusterNameOverride variabler i följande skript.

Du behöver också minst startnoderna från ditt befintliga datacenter och gossip-certifikaten som krävs för nod-till-nod-kryptering. Azure Managed Instance för Apache Cassandra kräver nod-till-nod-kryptering för kommunikation mellan datacenter. Om du inte har nod-till-nod-kryptering implementerat i ditt befintliga kluster måste du implementera det. Mer information finns i Kryptering från nod till nod. Ange sökvägen till platsen för certifikaten. Varje certifikat ska vara i PEM-format (Privacy Enhanced Mail), till exempel -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. I allmänhet finns det två sätt att implementera 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 signerade av en CA. 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 (Secure Sockets Layer) för produktion.
Om du vill implementera certifikatautentisering från klient till nod eller ömsesidig transportnivåsäkerhet (TLS) kan du ange certifikaten i samma format som när du skapade hybridklustret. Se Azure CLI-exemplet senare i den här artikeln. Certifikaten anges i parametern --client-certificates .

Den här metoden laddar upp och tillämpar dina klientcertifikat på förtroendelagret för din hanterade instans i Azure för klustret i Apache Cassandra. Du behöver inte redigera cassandra.yaml inställningar. När certifikaten har tillämpats kräver klustret att Cassandra verifierar certifikaten när en klient ansluter. Mer information require_client_auth: true finns i Cassandra client_encryption_options.

Värdet för variabeln delegatedManagementSubnetId som du anger i den här koden är samma som värdet --scope för den som du angav i ett tidigare kommando:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster-legal-name'
clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'

# You can override the cluster name if the original name isn't legal for an Azure resource:
# overrideClusterName='ClusterNameIllegalForAzureResource'
# the default cassandra version will be v3.11

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
  --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
  # optional - add your existing datacenter's client-to-node certificates (if implemented):
  # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
```
Om ditt kluster redan har nod-till-nod- och klient-till-nod-kryptering bör du veta var dina befintliga TLS/SSL-certifikat för klient eller gossip lagras. Om du är osäker, kör keytool -list -keystore <keystore-path> -rfc -storepass <password> för att skriva ut certifikaten.

När klusterresursen har skapats kör du följande kommando för att hämta information om klusterkonfigurationen:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

Föregående kommando returnerar information om den hanterade instansmiljön. Du behöver skvallercertifikaten så att du kan installera dem i certifikatlagret för noder i ditt befintliga datacenter. Följande skärmbild visar utdata från föregående kommando och formatet för certifikat.

Certifikaten som returneras från föregående kommando innehåller radbrytningar som representeras som text. Ett exempel är \r\n. Kopiera varje certifikat till en fil och formatera det innan du försöker importera det till ditt befintliga förtroendearkiv.

Kopiera matrisvärdet gossipCertificates som visas i skärmbilden till en fil. Använd följande Bash-skript för att formatera certifikaten och skapa separata PEM-filer för var och en. Information om hur du laddar ned Bash-skriptet finns i Ladda ned jq för din plattform.
```
readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
# iterate through the certs array, format each cert, write to a numbered file.
num=0
filename=""
for item in "${cert_array[@]}"; do
let num=num+1
filename="cert$num.pem"
cert=$(jq '.pem' <<< $item)
echo -e $cert >> $filename
sed -e 's/^"//' -e 's/"$//' -i $filename
done
```
Skapa sedan ett nytt datacenter i hybridklustret. Ersätt variabelvärdena med klusterinformationen:
```
resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
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 9
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false
```
Välj värdet för --sku från följande tillgängliga produktnivåer:
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
Värdet för --availability-zone är inställt på false. Om du vill aktivera tillgänglighetszoner anger du det här värdet till true. Tillgänglighetszoner ökar tjänstens serviceavtal (SLA) för tillgänglighet. Mer information finns i Serviceavtal för onlinetjänster.

Tillgänglighetszoner stöds inte i alla regioner. Distributioner misslyckas om du väljer en region där tillgänglighetszoner inte stöds. Information om regioner som stöds 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.

Nu när det nya datacentret har skapats kör du datacenter show kommandot för att visa dess information:

resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

Föregående kommando visar det nya datacentrets startnoder.

Lägg till det nya datacentrets startnoder i det befintliga datacentrets startnodkonfiguration i filen cassandra.yaml . Installera de tidigare insamlade gossip-certifikaten för den hanterade instansen till tillitssamlingen för varje nod i ditt befintliga kluster. keytool Använd kommandot för varje certifikat:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Om du vill lägga till fler datacenter upprepar du föregående steg, men du behöver bara startnoderna.

Viktigt!

Om ditt befintliga Apache Cassandra-kluster bara har ett enda datacenter och det här datacentret är det första som har lagts till kontrollerar du att parametern endpoint_snitch i cassandra.yaml är inställd på GossipingPropertyFileSnitch.

Om din befintliga programkod används QUORUM för konsekvens kontrollerar du att innan du ändrar replikeringsinställningarna i nästa steg använderLOCAL_QUORUM din befintliga programkod för att ansluta till ditt befintliga kluster. Annars misslyckas liveuppdateringar när du har ändrat replikeringsinställningarna i följande steg. När du har ändrat replikeringsstrategin kan du återgå till QUORUM om du vill.

Använd slutligen följande Frågespråksfråga för Cassandra för att uppdatera replikeringsstrategin i varje nyckelområde så att den inkluderar alla datacenter i klustret:

ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};

Du måste också uppdatera flera systemtabeller:

ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}

Om datacenter i ditt befintliga kluster inte framtvingar kryptering från klient till nod (SSL) och du tänker att programkoden ska ansluta direkt till Azure Managed Instance för Apache Cassandra, måste du även aktivera TLS/SSL i programkoden.

Använda ett hybridkluster för realtidsmigrering

Föregående instruktioner ger vägledning om hur du konfigurerar ett hybridkluster. Den här metoden är också ett bra sätt att uppnå en sömlös migrering utan driftstopp. Följande procedur visar hur du migrerar en lokal eller annan Cassandra-miljö som du vill inaktivera, utan driftstopp, till Azure Managed Instance för Apache Cassandra.

Konfigurera ett hybridkluster. Följ de föregående anvisningarna.

Inaktivera tillfälligt automatiska reparationer i Azure Managed Instance för Apache Cassandra under migreringen:

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled false

I Azure CLI använder du följande kommando för att köra nodetool rebuild på varje nod i ditt nya Azure Managed Instance för Apache Cassandra-datacenter. Ersätt <ip address> med nodens IP-adress. Ersätt <sourcedc> med namnet på ditt befintliga datacenter, det som du migrerar från:
```
az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
```
Kör det här kommandot först när du har vidtagit alla föregående steg. Den här metoden bör se till att alla historiska data replikeras till dina nya datacenter i Azure Managed Instance för Apache Cassandra. Du kan köra rebuild på en eller flera noder samtidigt. Kör på en nod i taget för att minska effekten på det befintliga klustret. Kör på flera noder när klustret kan hantera det extra I/O- och nätverkstrycket. För de flesta installationer kan du bara köra en eller två parallellt så att du inte överbelastar klustret.
Varning

Du måste ange källan data center när du kör nodetool rebuild. Om du anger datacentret felaktigt vid det första försöket kopieras tokenintervall utan att data kopieras för dina icke-systemtabeller. Efterföljande försök misslyckas även om du anger datacentret korrekt. Lös problemet genom att ta bort poster för varje icke-systemnyckelområde i system.available_ranges med hjälp cqlsh av frågeverktyget i ditt Azure Managed Instance-mål för Apache Cassandra-datacentret:
```
delete from system.available_ranges where keyspace_name = 'myKeyspace';
```
Klipp ut programkoden så att den pekar på startnoderna i dina nya Azure Managed Instance för Apache Cassandra-datacenter.

Om datacentren i ditt befintliga kluster inte framtvingar kryptering från klient till nod (SSL) aktiverar du den här funktionen i programkoden, som också nämns i instruktionerna för hybridkonfiguration. Azure Managed Instance för Apache Cassandra tillämpar det här kravet.
Kör ALTER KEYSPACE för varje nyckelområde på samma sätt som tidigare. Nu kan du ta bort dina gamla datacenter.
Kör nodverktygets inaktivering för varje gammal datacenternod.
Växla tillbaka programkoden till QUORUM, om det behövs eller önskas.

Återaktiverbara automatiska reparationer:

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName --repair-enabled true

Felsökning

Om du får ett fel när du tillämpar behörigheter på ditt virtuella nätverk med hjälp av 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ändarens 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.

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

Hantera Azure Managed Instance för Apache Cassandra-resurser med hjälp av Azure CLI-

Feedback

Var den här sidan till hjälp?

Last updated on 2025-07-15