Condividi tramite

Avvio rapido: Creare un Istanza gestita di Azure per un cluster Apache Cassandra usando l'interfaccia della riga di comando di Azure

  • Articolo

Istanza gestita di Azure per Apache Cassandra è un servizio completamente gestito per cluster Apache Cassandra open source puri. Il servizio consente anche di eseguire l'override delle configurazioni, a seconda delle esigenze specifiche di ogni carico di lavoro, consentendo la massima flessibilità e controllo dove necessario.

Questa guida introduttiva illustra come usare i comandi dell'interfaccia della riga di comando di Azure per creare un cluster con Azure Istanza gestita per Apache Cassandra. Viene inoltre illustrato come creare un data center e aumentare o ridurre i nodi all'interno del data center.

Prerequisiti

Importante

Questo articolo richiede l'interfaccia della riga di comando di Azure versione 2.30.0 o successiva. Se si usa Azure Cloud Shell, la versione più recente è già installata.

Creare un cluster di Istanza gestita

  1. Accedere al portale di Azure

  2. Impostare l'ID sottoscrizione nell'interfaccia della riga di comando di Azure:

    az account set -s <Subscription_ID>

  3. Creare quindi un Rete virtuale con una subnet dedicata nel gruppo di risorse:

    az network vnet create -n <VNet_Name> -l eastus2 -g <Resource_Group_Name> --subnet-name <Subnet Name>

    Nota

    La distribuzione di un'Istanza gestita di Azure per Apache Cassandra richiede l'accesso a Internet. La distribuzione ha esito negativo negli ambienti in cui l'accesso a Internet è limitato. Assicurarsi di non bloccare l'accesso all'interno della rete virtuale ai servizi di Azure fondamentali seguenti necessari per il corretto funzionamento di Cassandra gestito:

    • Archiviazione di Azure
    • Azure Key Vault
    • Set di scalabilità delle macchine virtuali di Azure
    • Monitoraggio di Azure
    • Microsoft Entra ID
    • Sicurezza di Azure

  4. Applicare alcune autorizzazioni speciali al Rete virtuale, richieste dall'istanza gestita. Usare il az role assignment create comando , sostituendo <subscriptionID>, <resourceGroupName>e <vnetName> con i valori appropriati:

    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>

    Nota

    I assignee valori e role nel comando precedente sono valori fissi, immettere questi valori esattamente come indicato nel comando. In caso contrario, si verificano errori durante la creazione del cluster. Se si verificano errori durante l'esecuzione di questo comando, è possibile che non si disponga delle autorizzazioni per eseguirlo, contattare l'amministratore per ottenere le autorizzazioni.

  5. Creare quindi il cluster nel Rete virtuale appena creato usando il comando az managed-cassandra cluster create. Eseguire il comando seguente il valore della delegatedManagementSubnetId variabile:

    Nota

    Il valore della delegatedManagementSubnetId variabile che verrà fornito di seguito corrisponde esattamente al valore di --scope specificato nel comando precedente:

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster_Name>'
location='eastus2'
delegatedManagementSubnetId='/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualNetworks/<VNet name>/subnets/<subnet name>'
initialCassandraAdminPassword='myPassword'
cassandraVersion='3.11' # set to 4.0 for a Cassandra 4.0 cluster

az managed-cassandra cluster create \
  --cluster-name $clusterName \
  --resource-group $resourceGroupName \
  --location $location \
  --delegated-management-subnet-id $delegatedManagementSubnetId \
  --initial-cassandra-admin-password $initialCassandraAdminPassword \
  --cassandra-version $cassandraVersion \
  --debug

  6. Infine, creare un data center per il cluster, con tre nodi, SKU di vm D8s v4 Standard, con 4 dischi P30 collegati per ogni nodo, usando il comando az managed-cassandra datacenter create :

    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 3 \
  --sku $virtualMachineSKU \
  --disk-capacity $noOfDisksPerNode \
  --availability-zone false

    Nota

    Il valore per --sku può essere scelto dagli SKU disponibili seguenti:

    • 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

    Notare anche che --availability-zone è impostata su false. Per abilitare le zone di disponibilità, impostare su true. Le zone di disponibilità aumentano il contratto di servizio per la disponibilità del servizio. Per altri dettagli, vedere i dettagli completi del contratto di servizio qui.

    Avviso

    Le zone di disponibilità non sono supportate in tutte le aree. Le distribuzioni avranno esito negativo se si seleziona un'area in cui le zone di disponibilità non sono supportate. Vedere qui per le aree supportate. La corretta distribuzione delle zone di disponibilità è soggetta anche alla disponibilità delle risorse di calcolo in tutte le zone dell'area specificata. Le distribuzioni potrebbero non riuscire se la capacità o lo SKU selezionato non è disponibile in tutte le zone.

  7. Dopo aver creato il data center, se si vuole aumentare o ridurre i nodi nel data center, eseguire il comando az managed-cassandra datacenter update . Modificare il valore del node-count parametro impostando il valore desiderato:

    resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'
dataCenterName='dc1'
dataCenterLocation='eastus2'

az managed-cassandra datacenter update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName \
  --node-count 9

Connettersi al cluster

Azure Istanza gestita per Apache Cassandra non crea nodi con indirizzi IP pubblici. Per connettersi al cluster Cassandra appena creato, è necessario creare un'altra risorsa all'interno della rete virtuale. Questa risorsa può essere un'applicazione o una macchina virtuale con lo strumento di query open source di Apache installato CQLSH . È possibile usare un modello di Resource Manager per distribuire una macchina virtuale Ubuntu.

Connessione da CQLSH

Dopo la distribuzione della macchina virtuale, usare SSH per connettersi al computer e installare CQLSH, come illustrato nei comandi seguenti:

# 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

Connessione da un'applicazione

Come per CQLSH, per la connessione da un'applicazione usando uno dei driver client Apache Cassandra supportati è necessario che la crittografia SSL sia abilitata e che la verifica del certificato sia disabilitata. Vedere gli esempi per la connessione a Istanza gestita di Azure per Apache Cassandra con Java, .NET, Node.js e Python.

La disabilitazione della verifica del certificato è consigliata, perché comunque non funzionerà a meno che non si esegua il mapping degli indirizzi IP dei nodi del cluster al dominio appropriato. Se è disponibile un criterio interno che impone di eseguire la verifica del certificato SSL per qualsiasi applicazione, è possibile eseguire questa operazione aggiungendo voci come 10.0.1.5 host1.managedcassandra.cosmos.azure.com nel file hosts per ogni nodo. Se si adotta questo approccio, è anche necessario aggiungere nuove voci ogni volta che si aumentano i nodi.

Per Java, è anche consigliabile abilitare criteri di esecuzione speculativa in cui le applicazioni sono sensibili alla latenza della coda. Una demo che illustra il funzionamento e come abilitare i criteri è disponibile qui.

Nota

Nella maggior parte dei casi non è necessario configurare o installare certificati (rootCA, nodo o client, truststore e così via) per connettersi a Istanza gestita di Azure per Apache Cassandra. La crittografia SSL può essere abilitata usando il truststore predefinito e la password del runtime usato dal client (vedere gli esempi Java, .NET, Node.js e Python), perché i certificati di Istanza gestita di Azure per Apache Cassandra saranno considerati attendibili da tale ambiente. In rari casi, se il certificato non viene considerato attendibile, può essere necessario aggiungerlo al truststore.

Configurazione dei certificati client (facoltativo)

La configurazione dei certificati client è facoltativa. Un'applicazione client può connettersi a Istanza gestita di Azure per Apache Cassandra, purché siano stati eseguiti i passaggi precedenti. Tuttavia, se si preferisce, è anche possibile creare e configurare i certificati client per l'autenticazione. In generale, esistono due modi per creare i certificati:

  • Certificati autofirmati. Questo vuol dire un certificato privato e uno pubblico (non CA) per ogni nodo. In questo caso sono necessari tutti i certificati pubblici.
  • Certificati firmati da una CA. Può trattarsi di un certificato CA autofirmato o anche pubblico. In questo caso occorrono il certificato CA radice (vedere le istruzioni sulla preparazione dei certificati SSL per la produzione) e tutti gli intermediari (se applicabile).

Se si vuole implementare l'autenticazione del certificato da client a nodo o mTLS (Mutual Transport Layer Security), è necessario fornire i certificati tramite l'interfaccia della riga di comando di Azure. Il comando seguente caricherà e applicherà i certificati client nel truststore per il cluster dell'istanza gestita di Cassandra(quindi non è necessario modificare le impostazioni di cassandra.yaml). Dopo l'applicazione, il cluster richiederà a Cassandra di verificare i certificati quando un client si connette (vedere require_client_auth: true in 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

Risoluzione dei problemi

Se durante l'applicazione delle autorizzazioni alla rete virtuale tramite l'interfaccia della riga di comando di Azure si verifica un errore simile a Non è possibile trovare l'utente o l'entità servizio nel database a grafo per 'e5007d2c-4b13-4a74-9b6a-605d99f03501', si può applicare manualmente la stessa autorizzazione dal portale di Azure. Le informazioni sulla procedura sono disponibili qui.

Nota

L'assegnazione di ruolo di Azure Cosmos DB viene usata solo ai fini della distribuzione. Istanza gestita di Azure per Apache Cassandra non ha dipendenze back-end da Azure Cosmos DB.

Pulire le risorse

Quando non è più necessario, è possibile usare il az group delete comando per rimuovere il gruppo di risorse, l'istanza gestita e tutte le risorse correlate:

az group delete --name <Resource_Group_Name>

Passaggi successivi

In questa guida introduttiva si è appreso come creare un Istanza gestita di Azure per il cluster Apache Cassandra usando l'interfaccia della riga di comando di Azure. A questo punto è possibile iniziare a usare il cluster:

Distribuire un cluster Apache Spark gestito con Azure Databricks