Snabbstart: Skapa ett Azure Managed Instance för Apache Cassandra-kluster från Azure Portal
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 Portal för att skapa ett Azure Managed Instance för Apache Cassandra-kluster.
Förutsättningar
Om du inte har någon Azure-prenumeration skapar du ett kostnadsfritt konto innan du börjar.
Skapa ett kluster för hanterad instans
Logga in på Azure-portalen.
I sökfältet söker du efter Hanterad instans efter Apache Cassandra och väljer resultatet.
Välj knappen 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. Mer information finns i artikeln Översikt över Azure-resursgrupp .
- Klusternamn – Ange ett namn för klustret.
- Plats – plats där klustret ska distribueras till.
- Cassandra-version – Version av Apache Cassandra som ska distribueras.
- Extention – tillägg som ska läggas till, inklusive Cassandra Lucene Index.
- Initialt Cassandra-administratörslösenord – 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 avslutande virtuellt nätverk och undernät eller skapa ett nytt.
- 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 redan har distribuerat Azure SQL Managed Instance Cassandra-kluster avmarkerar du det här alternativet.
Dricks
Om du använder VPN behöver du inte öppna någon annan anslutning.
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. Mer detaljerad information finns i Obligatoriska regler för utgående nätverk .
- Azure Storage
- Azure KeyVault
- Azure Virtual Machine Scale Sets
- Azure Monitoring
- Microsoft Entra ID
- Säkerhet i Azure
- Replikera automatiskt – Välj vilken form av automatisk replikering som ska användas. Läs mer
- Schemalägg händelsestrategi – den strategi som ska användas av klustret för schemalagda händelser.
Dricks
- StopANY innebär att stoppa alla noder när det finns en schemalagd även för noden.
- StopByRack innebär att endast stoppa noden i ett visst rack för en viss schemalagd händelse, t.ex. om två eller flera händelser schemaläggs för noder i olika rack samtidigt stoppas endast noder i ett rack medan de andra noderna i andra rack fördröjs.
Välj sedan fliken Datacenter .
Ange följande detaljerad information:
- Datacenternamn – Ange ett datacenternamn i textfältet.
- Tillgänglighetszon – Markera den här kryssrutan om du vill att tillgänglighetszoner ska aktiveras.
- SKU-storlek – Välj mellan tillgängliga SKU-storlekar för virtuella datorer.
Kommentar
Vi har introducerat cachelagring med skrivbehörighet (offentlig förhandsversion) genom användning av SKU:er för virtuella datorer i L-serien. Den här implementeringen syftar till att minimera svarstider och förbättra läsprestanda, särskilt för läsintensiva arbetsbelastningar. Dessa specifika SKU:er är utrustade med lokalt anslutna diskar, vilket säkerställer enormt ökad IOPS för läsåtgärder och minskad svarstid.
Viktigt!
Cachelagring med skrivbehörighet finns i offentlig förhandsversion. Den här funktionen tillhandahålls utan ett serviceavtal och rekommenderas 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.
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.
Välj sedan Granska + skapa>Skapa
Kommentar
Det kan ta upp till 15 minuter innan klustret skapas.
När distributionen är klar kontrollerar du resursgruppen för att se det nyligen skapade klustret för den hanterade instansen:
Om du vill bläddra igenom klusternoderna navigerar du till klusterresursen och öppnar fönstret Datacenter för att visa dem:
Skala ett datacenter
Nu när du har distribuerat ett kluster med ett enda datacenter kan du antingen skala vågrätt eller lodrätt genom att markera datacentret och välja Scale knappen:
Horisontell skalning
Om du vill skala ut eller skala in på noder flyttar du skjutreglaget till önskat tal eller redigerar bara värdet. När du är klar trycker du på Scale.
Lodrät skala
Om du vill skala upp eller skala ned SKU-storleken för dina noder väljer du i Sku Size listrutan. När du är klar trycker du på Scale.
Kommentar
Hur lång tid det tar för en skalningsåtgärd beror på olika faktorer, det kan ta flera minuter. När Azure meddelar dig att skalningsåtgärden har slutförts betyder det inte att alla noder har anslutits till Cassandra-ringen. Noder beställs helt när alla visar statusen "felfri" och datacentrets status lyder "lyckades". Skalning är en onlineåtgärd och fungerar på samma sätt som beskrivs för korrigering i hanteringsåtgärder
Lägga till ett datacenter
Om du vill lägga till ett annat datacenter klickar du på knappen Lägg till i fönstret Datacenter :
Varning
Om du lägger till ett datacenter i en annan region måste du välja ett annat virtuellt nätverk. Du måste också se till att det här virtuella nätverket har anslutning till den primära regionens virtuella nätverk som skapats ovan (och andra virtuella nätverk som är värdar för datacenter i det hanterade instansklustret). Ta en titt på den här artikeln om du vill lära dig hur du peerkopplar virtuella nätverk med hjälp av Azure Portal. Du måste också se till att du har tillämpat rätt roll på ditt virtuella nätverk innan du försöker distribuera ett kluster för hanterad instans med hjälp av CLI-kommandot nedan.
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 – Välj din Azure-prenumeration i listrutan.
- Tillgänglighetszon – Markera den här kryssrutan om du vill att tillgänglighetszoner ska aktiveras i det här datacentret.
- Plats – plats där ditt datacenter ska distribueras till.
- SKU-storlek – Välj mellan tillgängliga SKU-storlekar för virtuella datorer.
- 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 utgående virtuellt nätverk och undernät.
Varning
Observera att vi inte tillåter att ett nytt virtuellt nätverk skapas när ett datacenter läggs till. Du måste välja ett befintligt virtuellt nätverk, och som nämnts ovan måste du se till att det finns en anslutning mellan målundernäten där datacenter ska distribueras. Du måste också använda lämplig roll för det virtuella nätverket för att tillåta distribution (se ovan).
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 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 där det redan finns data måste du köra
rebuildför att replikera historiska data. Kör kommandot nedan i Azure CLI för att köranodetool rebuildpå varje nod i det nya datacentret, ersätta<new dc ip address>med nodens IP-adress och<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>"=""Varning
Du bör inte tillåta 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öras
repairåt dig.
Uppdatera Cassandra-konfiguration
Tjänsten tillåter uppdatering av Cassandra YAML-konfiguration i ett datacenter via portalen eller med hjälp av CLI-kommandon. Så här uppdaterar du inställningarna i portalen:
Sök
Cassandra Configurationunder inställningar. Markera det datacenter vars konfiguration du vill ändra och klicka på Uppdatera:
I fönstret som öppnas anger du fältnamnen i YAML-format, enligt nedan. Klicka sedan på Uppdatera.
När uppdateringen är klar visas de åsidosatta värdena i fönstret
Cassandra Configuration:
Kommentar
Endast åsidosatta Cassandra-konfigurationsvärden visas i portalen.
Viktigt!
Kontrollera att de Cassandra yaml-inställningar som du anger är lämpliga för den version av Cassandra som du har distribuerat. Här finns inställningar för Cassandra v3.11 och här för v4.0. Följande YAML-inställningar får inte uppdateras:
- cluster_name
- seed_provider
- initial_token
- autobootstrap
- client_encryption_options
- server_encryption_options
- transparent_data_encryption_options
- audit_logging_options
- autentiserare
- auktoriserare
- 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
- Partitioneraren
- rpc_address
- rpc_interface
Uppdatera Cassandra-versionen
Viktigt!
Cassandra 5.0 och Nyckelfärdiga versionsuppdateringar finns i offentlig förhandsversion. Dessa funktioner tillhandahålls utan ett serviceavtal och rekommenderas inte 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 Az CLI-, Terraform- eller ARM-mallar.
Hitta panelen
Updatepå fliken Översikt
Välj Cassandra-versionen i listrutan.
Varning
Hoppa inte över versioner. Vi rekommenderar att du endast uppdaterar från en version till ett annat exempel 3.11 till 4.0, 4.0 till 4.1.
Välj vid uppdatering 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. Genom att använda nyckelfärdiga replikeringsfunktioner har det blivit mer tillgängligt att konfigurera och hantera kluster i flera regioner, vilket möjliggör smidigare integrering och drift i distribuerade miljöer. Den här uppdateringen minskar avsevärt de komplexiteter som traditionellt förknippas med att distribuera och underhålla konfigurationer i flera regioner, vilket gör det möjligt för användare att använda Cassandras funktioner med större enkelhet och effektivitet.
Dricks
- Ingen: Automatisk replikering har angetts till ingen.
- SystemKeyspaces: Replikera alla systemnyckelutrymmen automatiskt (system_auth, system_traces, system_auth)
- AllKeyspaces: Replikera alla nyckelytor automatiskt och övervaka om nya nyckelutrymmen skapas och tillämpa automatiskt replikera inställningar automatiskt.
Scenarier för automatisk replikering
- När du lägger till ett nytt datacenter körs
nodetool rebuildfunktionen för automatisk replikering i Cassandra sömlöst för att säkerställa en 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, kan de inkluderas i nyckelutrymmena genom användning av egenskapen externt datacenter. Detta gör det möjligt för Cassandra att införliva dessa externa datacenter som källor för återskapandeprocessen.
Varning
Om du ställer in automatisk replikering till AllKeyspaces ändras replikering av nyckelytor till att inkludera WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Om detta inte är den topologi du vill använda måste du använda SystemKeyspaces, justera dem själv och köra nodetool rebuild dem manuellt på Azure Managed Instance för Apache Cassandra-klustret.
Avallokera kluster
- För icke-produktionsmiljöer kan du pausa/avallokera 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
NonProduction, sedandeallocate.
Dricks
Klustertypen ska endast användas som "Icke-produktion" för att spara utvecklingskostnader. De kan komma med mindre SKU:er och bör INTE användas för att köra produktionsarbetsbelastningar.
Varning
- Klustertypen som definieras som "Icke-produktion" kommer inte att ha SLA-garantier som tillämpas på den.
- Kör inga schema- eller skrivåtgärder under avallokeringen – detta kan leda till dataförlust och i sällsynta fall schemafel som 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 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.
Ansluta till klustret
Azure Managed Instance för Apache Cassandra skapar inte noder med offentliga IP-adresser, så för att ansluta till det nyligen skapade Cassandra-klustret måste du skapa en annan resurs i det virtuella nätverket. Det 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 SSH för att ansluta till datorn och installerar CQLSH med hjälp av kommandona nedan:
# 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 kräver anslutning från ett program med någon av apache Cassandra-klientdrivrutinerna som stöds att SSL-kryptering aktiveras och certifieringsverifiering inaktiveras. Se exempel för att ansluta till Azure Managed Instance för Apache Cassandra med Java, .NET, Node.js och Python.
Inaktivera certifikatverifiering rekommenderas eftersom certifikatverifiering inte fungerar om du inte mappar I.P-adresser för dina klusternoder till rätt domän. Om du har en intern princip som kräver att du utför SSL-certifikatverifiering för alla program kan du underlätta detta genom att lägga till poster som 10.0.1.5 host1.managedcassandra.cosmos.azure.com i din värdfil för varje nod. 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 också starkt att du aktiverar spekulativ körningsprincip där program är känsliga för svarstid. Du hittar en demo som illustrerar hur detta fungerar och hur du aktiverar principen här.
Kommentar
I de allra flesta fall bör det inte vara nödvändigt att konfigurera eller installera certifikat (rootCA, nod eller klient, förtroendearkiv osv.) för att ansluta till Azure Managed Instance för Apache Cassandra. SSL-kryptering kan aktiveras med hjälp av standardförtroendearkivet och lösenordet för den körning som används av klienten (se Java, .NET, Node.js och Python-exempel ), eftersom Azure Managed Instance för Apache Cassandra-certifikat kommer att vara betrodda av den miljön. Om certifikatet i sällsynta fall inte är betrott kan du behöva lägga till det i förtroendearkivet.
Konfigurera klientcertifikat (valfritt)
Det är valfritt att konfigurera klientcertifikat. Ett klientprogram kan ansluta till Azure Managed Instance för Apache Cassandra så länge ovanstående steg har vidtagits. Men om du vill kan du även skapa och konfigurera klientcertifikat för autentisering. I allmänhet finns det två sätt att skapa certifikat:
- 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.
- 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 transportnivåsäkerhet (mTLS) måste du ange certifikaten via Azure CLI. Kommandot nedan 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).
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 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 Azure Managed Instance för Apache Cassandra-kluster med hjälp av Azure Portal. Nu kan du börja arbeta med klustret: