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

Artikel
08/15/2024

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 klustret och underhålla dem.

Förutsättningar

Använd Bash-miljön i Azure Cloud Shell. Mer information finns i Snabbstart för Bash i 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 Logga in 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 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.
Azure Virtual Network med anslutning till din lokala eller lokala miljö. Mer information om hur du ansluter lokala miljöer till Azure finns i artikeln Anslut ett lokalt nätverk till Azure .

Konfigurera ett hybridkluster

Logga in på Azure Portal och gå till din virtual network-resurs.
Ö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 artikeln Virtuellt nätverk:
Kommentar

Distributionen av en 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 Managed Cassandra ska fungera korrekt. Du hittar också en omfattande lista över IP-adresser och portberoenden här.
- Azure Storage
- Azure KeyVault
- Azure Virtual Machine Scale Sets
- Azure Monitoring
- Microsoft Entra ID
- Säkerhet i Azure
Nu ska vi tillämpa vissa särskilda behörigheter på 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änstprinciper respektive rollidentifierare.
Därefter konfigurerar vi resurser för vårt hybridkluster. Eftersom du redan har ett kluster är klusternamnet här bara 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-nodkryptering implementerat i ditt befintliga kluster skulle du behöva implementera det – se dokumentationen här. Du bör ange sökvägen till platsen för certifikaten. Varje certifikat ska vara i PEM-format, t.ex. -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. I allmänhet finns det två sätt att implementera certifikat:
1. Självsignerade certifikat. Det innebär ett privat och offentligt certifikat (ingen CA) för varje nod – i det här fallet behöver vi alla offentliga certifikat.
2. Certifikat signerade av en certifikatutfärdare. Det här kan vara en självsignerad ca eller till och med en offentlig. I det här fallet behöver vi rotcertifikatutfärdarcertifikatet (se anvisningar om hur du förbereder SSL-certifikat för produktion) och alla mellanhänder (om tillämpligt).
Om du vill implementera certifikatautentisering från klient till nod eller ömsesidig Transport Layer Security (mTLS) måste du också ange certifikaten i samma format som när du skapar hybridklustret. Se Azure CLI-exemplet nedan – certifikaten finns i parametern --client-certificates . Detta laddar upp och tillämpar dina klientcertifikat på förtroendearkivet för ditt Cassandra Managed Instance-kluster (dvs. du behöver inte redigera cassandra.yaml-inställningar). När det har tillämpats kräver klustret att Cassandra verifierar 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 nedan är exakt samma som värdet --scope för den som du angav i kommandot ovan:
```
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 is not 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 bör du kunna köra 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 förtroendearkivet 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 kommandot ovan 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 datacenters förtroendearkiv.
Dricks

Kopiera matrisvärdet gossipCertificates som visas i skärmbilden ovan till en fil och använd följande bash-skript (du skulle behöva ladda ned och installera jq för din plattform) för att formatera certifikaten och skapa separata pem-filer för var och en.
```
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
Observera också att --availability-zone är inställt på false. Om du vill aktivera tillgänglighetszoner anger du detta till true. Tillgänglighetszoner ökar tjänstens serviceavtal för tillgänglighet. Mer information finns i den fullständiga SLA-informationen här.
Varning

Tillgänglighetszoner stöds inte i alla regioner. Distributioner misslyckas om du väljer en region där tillgänglighetszoner inte stöds. Se här för regioner som stöds. 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 matar ut det nya datacentrets startnoder:
Lägg nu till det nya datacentrets startnoder i det befintliga datacentrets startnodkonfiguration i filen cassandra.yaml . Och installera skvallercertifikaten för den hanterade instansen som du samlade in tidigare till förtroendearkivet för varje nod i ditt befintliga kluster med hjälp av keytool kommandot 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 stegen ovan, men du behöver bara startnoderna.

Viktigt!

Om ditt befintliga Apache Cassandra-kluster bara har ett enda datacenter, och det är första gången ett datacenter 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 bör du se till att innan du ändrar replikeringsinställningarna i steget nedan använder din befintliga programkod LOCAL_QUORUM för att ansluta till ditt befintliga kluster (annars misslyckas liveuppdateringar när du har ändrat replikeringsinställningarna i steget nedan). När replikeringsstrategin har ändrats 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 Cassandra Managed Instance måste du även aktivera SSL i programkoden.

Använda hybridkluster för realtidsmigrering

Anvisningarna ovan ger vägledning för att konfigurera ett hybridkluster. Detta är dock också ett bra sätt att uppnå en sömlös nollavbrottsmigrering. Om du har en lokal eller annan Cassandra-miljö som du vill inaktivera utan stilleståndstid, till förmån för att köra din arbetsbelastning i Azure Managed Instance för Apache Cassandra, måste följande steg utföras i den här ordningen:

Konfigurera hybridkluster – följ anvisningarna ovan.

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

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

Kör kommandot nedan i Azure CLI för att köra nodetool rebuild på varje nod i ditt nya Azure Managed Instance for Apache Cassandra-datacenter, ersätta <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 detta först när alla tidigare steg har vidtagits. Detta 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 kommer detta att resultera i att tokenintervall kopieras, utan att data kopieras för dina tabeller som inte är system. Efterföljande försök misslyckas även om du anger datacentret korrekt. Du kan lösa detta genom att ta bort poster för varje nyckelområde som inte är ett system via system.available_ranges cqlsh 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 din nya Azure Managed Instance för Apache Cassandra-datacenter.

Viktigt!

Om datacenter i ditt befintliga kluster inte framtvingar kryptering från klient till nod (SSL) måste du aktivera detta i programkoden, som Cassandra Managed Instance framtvingar.
Kör ALTER KEYSPACE för varje nyckelområde på samma sätt som tidigare, men ta nu bort dina gamla datacenter.
Kör nodetool-avaktivering för varje gammal datacenternod.
Växla tillbaka programkoden till kvorum (om det behövs/önskas).

Å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 Azure CLI, till exempel Det går inte att hitta användaren eller tjänstens huvudnamn i grafdatabasen för "e5007d2c-4b13-4a74-9b6a-605d99f03501", kan du använda samma behörighet manuellt från Azure Portal. Lär dig hur du gör detta här.

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

I den här snabbstarten har du lärt dig hur du skapar ett hybridkluster med Hjälp av Azure CLI och Azure Managed Instance för Apache Cassandra. Nu kan du börja arbeta med klustret.

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

Dela via