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

  • Articolo

Azure Istanza gestita 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 lo SKU selezionato o la capacità 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, la connessione da un'applicazione tramite uno dei driver client Apache Cassandra supportati richiede l'abilitazione della crittografia SSL e la verifica della certificazione deve essere disabilitata. Vedere esempi per la connessione ad Azure Istanza gestita per Apache Cassandra con Java, .NET, Node.js e Python.

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

Per Java, è anche consigliabile abilitare criteri di esecuzione speculativi in cui le applicazioni sono sensibili alla latenza della coda. È possibile trovare una demo che illustra come funziona e come abilitare i criteri qui.

Nota

Nella maggior parte dei casi non è necessario configurare o installare certificati (rootCA, node o client, truststore e così via) per connettersi ad Azure Istanza gestita per Apache Cassandra. La crittografia SSL può essere abilitata usando l'archivio trust predefinito e la password del runtime usato dal client (vedere esempi Java, .NET, Node.js e Python), perché Azure Istanza gestita per i certificati Apache Cassandra sarà considerato attendibile da tale ambiente. In rari casi, se il certificato non è attendibile, potrebbe essere necessario aggiungerlo all'archivio trust.

Configurazione dei certificati client (facoltativo)

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

  • Certificati autofirmato. Ciò significa un certificato privato e pubblico (nessuna CA) per ogni nodo, in questo caso sono necessari tutti i certificati pubblici.
  • Certificati firmati da una CA. Può trattarsi di un'autorità di certificazione autofirmato o anche di un'autorità di certificazione pubblica. In questo caso è necessario 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 (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 all'archivio attendibilità per il cluster cassandra Istanza gestita (ad esempio, non è necessario modificare cassandra.yaml le impostazioni). 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 si verifica un errore durante l'applicazione delle autorizzazioni al Rete virtuale tramite l'interfaccia della riga di comando di Azure, ad esempio Impossibile trovare l'utente o l'entità servizio nel database a grafo per 'e5007d2c-4b13-4a74-9b6a-605d99f03501', è possibile applicare manualmente la stessa autorizzazione dal portale di Azure. Informazioni su come eseguire questa operazione qui.

Nota

L'assegnazione di ruolo di Azure Cosmos DB viene usata solo a scopo di distribuzione. Azure Istanza gestita d per Apache Cassandra non ha dipendenze back-end in 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. È ora possibile iniziare a usare il cluster:

Distribuire un cluster Apache Spark gestito con Azure Databricks