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

2025-06-11

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, vilket ger maximal flexibilitet och kontroll där det behövs.

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.

Azure CLI version 2.30.0 eller senare. Om du använder Azure Cloud Shell är den senaste versionen redan installerad.
Azure Virtual Network med anslutning till din lokala 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.
Öppna 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.
Kommentar

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. Se till att du inte blockerar åtkomsten i ditt virtuella nätverk till följande viktiga Azure-tjänster som krävs för att Hanterad Cassandra ska fungera korrekt. En lista över IP-adresser och portberoenden finns i Obligatoriska regler för utgående nätverk.
- Azure Storage
- Azure KeyVault
- Skalningsuppsättningar för virtuella Azure-datorer
- Azure Monitoring
- Microsoft Entra ID
- Säkerhet i Azure
Använd vissa särskilda behörigheter för det virtuella nätverket och undernätet som Cassandra Managed Instance kräver med hjälp av Azure CLI. az role assignment create Använd kommandot och 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>
```
Kommentar

Värdena assignee och role i föregående kommando är fasta tjänstens huvudnamn respektive rollidentifierare.
Konfigurera resurser för vårt hybridkluster. Eftersom du redan har ett kluster är klusternamnet en logisk resurs för att identifiera namnet på ditt befintliga kluster. Se till att använda namnet på ditt befintliga kluster när du clusterName definierar och clusterNameOverride variabler i följande skript.

Du behöver också minst startnoderna från ditt befintliga datacenter och de skvallercertifikat 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 implementerar du 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, -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----till exempel . I allmänhet finns det två sätt att implementera certifikat:
- Självsignerade certifikat. Ett privat och offentligt certifikat (ingen CA) för varje nod. I det här fallet behöver du alla offentliga certifikat.
- Certifikat signerade av en certifikatutfärdare. Det här certifikatet kan vara ett självsignerat certifikat eller till och med ett offentligt certifikat. I det här fallet behöver vi rotcertifikatet och alla mellanliggande 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) kan du även ange certifikaten i samma format som när du skapar hybridklustret. Se Azure CLI-exempel 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örtroendearkivet för ditt Cassandra-kluster för hanterade instanser. Det vill säga att du inte behöver redigera cassandra.yaml-inställningar . När klustret har tillämpats måste Cassandra verifiera certifikaten när en klient ansluter. Se require_client_auth: true i Cassandra client_encryption_options.

Kommentar

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
```
Kommentar

Om klustret redan har kryptering från nod till nod och klient-till-nod bör du veta var dina befintliga klient- och/eller skvaller-SSL-certifikat lagras. Om du är osäker, kör du keytool -list -keystore <keystore-path> -rfc -storepass <password> för att visa 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:

Kommentar

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

Kopiera matrisvärdet gossipCertificates som visas i skärmbilden till en fil och 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
```
Kommentar

Värdet för --sku kan väljas från följande tillgängliga SKU: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 för tillgänglighet. Mer information finns i Serviceavtal för onlinetjänster.
Varning

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 angivna regionen. Distributioner kan misslyckas om den SKU som du har valt, eller kapaciteten, inte är tillgänglig i alla zoner.

Nu när det nya datacentret har skapats kör du kommandot show datacenter 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 gossip-certifikaten för den hanterade instansen som du samlade in tidigare till betroendeförrådet för varje nod i ditt befintliga kluster, med hjälp av kommandot keytool för varje certifikat:
```
keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
```
Kommentar

Om du vill lägga till fler datacenter kan du upprepa 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 läggs till kontrollerar du att parametern endpoint_snitch i cassandra.yaml är inställd på GossipingPropertyFileSnitch.

Viktigt!

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

Använd slutligen följande CQL-fråga för att uppdatera replikeringsstrategin i varje nyckelområde för att inkludera 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}

Viktigt!

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 den hanterade Cassandra-instansen måste du även aktivera SSL i programkoden.

Använda hybridkluster för realtidsmigrering

Ovanstående instruktioner innehåller vägledning för att konfigurera ett hybridkluster. Den här metoden är också ett bra sätt att uppnå en sömlös migrering utan driftstopp. Följande procedur är för att migrera en lokal eller annan Cassandra-miljö som du vill inaktivera utan driftstopp till Azure Managed Instance för Apache Cassandra.

Konfigurera 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 din nya Azure Managed Instance for Apache Cassandra-datacenter, ersätter <ip address> med nodens IP-adress och <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>"=""
```
Du bör köra det här kommandot först när alla tidigare steg har vidtagits. Den här metoden bör säkerställa att alla historiska data replikeras till dina nya datacenter i Azure Managed Instance för Apache Cassandra. Du kan köra återskapa på en eller flera noder samtidigt. Kör på en nod i taget för att minska påverkan 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 för att inte överbelasta klustret.
Varning

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

Viktigt!

Om datacenter i ditt befintliga kluster inte framtvingar kryptering från klient till nod (SSL) kan du aktivera den här funktionen i programkoden, eftersom Cassandra-hanterad instans framtvingar detta krav.
Kör ALTER KEYSPACE för varje nyckelområde på samma sätt som tidigare, men ta nu bort dina gamla datacenter.
Kör nodverktygets inaktivering för varje gammal datacenternod.
Växla tillbaka applikationskoden till kvorum om det är nödvändigt eller önskvärt.

Återaktivera 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 Kan inte hitta användaren eller tjänstens huvudnamn i grafdatabasen för "e5007d2c-4b13-4a74-9b6a-605d9f03501". Mer information finns i Använd Azure-portalen för att lägga till tjänstens huvudadministratör för Azure Cosmos DB.

Kommentar

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 klustret för den hanterade instansen tar du bort det med följande steg:

På den vänstra menyn i Azure Portal väljer du Resursgrupper.
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