Condividi tramite

Avvio rapido: Configurare un cluster ibrido con Azure Istanza gestita per Apache Cassandra

  • 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 configurare un cluster ibrido. Se si hanno data center esistenti in un ambiente locale o self-hosted, è possibile usare Azure Istanza gestita per Apache Cassandra per aggiungere altri data center a tale cluster e gestirli.

Prerequisiti

  • 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.

  • Azure Rete virtuale con connettività all'ambiente self-hosted o locale. Per altre informazioni sulla connessione di ambienti locali ad Azure, vedere l'articolo Connettere una rete locale ad Azure .

Configurare un cluster ibrido

  1. Accedere al portale di Azure e passare alla risorsa Rete virtuale.

  2. Aprire la scheda Subnet e creare una nuova subnet. Per altre informazioni sui campi nel modulo Aggiungi subnet, vedere l'articolo Rete virtuale:

    Aggiungere una nuova subnet al Rete virtuale.

    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 essenziali indicati di seguito, necessari per il corretto funzionamento del cluster Cassandra gestito. È anche possibile trovare un elenco completo di indirizzi IP e dipendenze delle porte qui.

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

  3. Ora verranno applicate alcune autorizzazioni speciali alla rete virtuale e alla subnet necessarie per Cassandra Istanza gestita, usando l'interfaccia della riga di comando di Azure. 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 rispettivamente l'entità servizio fissa e gli identificatori di ruolo.

  4. Verranno quindi configurate le risorse per il cluster ibrido. Poiché si dispone già di un cluster, il nome del cluster sarà solo una risorsa logica per identificare il nome del cluster esistente. Assicurarsi di usare il nome del cluster esistente durante la definizione clusterName e clusterNameOverride le variabili nello script seguente.

    Sono necessari anche, almeno, i nodi di inizializzazione dal data center esistente e i certificati gossip necessari per la crittografia da nodo a nodo. Azure Istanza gestita per Apache Cassandra richiede la crittografia da nodo a nodo per la comunicazione tra data center. Se non è implementata la crittografia da nodo a nodo nel cluster esistente, è necessario implementarla. Vedere la documentazione qui. È necessario specificare il percorso dei certificati. Ogni certificato deve essere in formato PEM, ad esempio -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----. In generale, esistono due modi per implementare i certificati:

    1. 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.

    2. 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).

    Facoltativamente, se si vuole implementare anche l'autenticazione del certificato da client a nodo o mTLS (Transport Layer Security), è necessario fornire i certificati nello stesso formato di quando si crea il cluster ibrido. Vedere l'esempio dell'interfaccia della riga di comando di Azure seguente: i certificati vengono forniti nel --client-certificates parametro . Verranno caricati e applicati i certificati client all'archivio attendibilità per il cluster cassandra Istanza gestita ( ad esempio, 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).

    Nota

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

    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

    Nota

    Se il cluster dispone già di crittografia da nodo a nodo e da client a nodo, è necessario sapere dove vengono conservati i certificati SSL esistenti e/o gossip. In caso di dubbi, dovrebbe essere possibile eseguire per stampare keytool -list -keystore <keystore-path> -rfc -storepass <password> i certificati.

  5. Dopo aver creato la risorsa cluster, eseguire il comando seguente per ottenere i dettagli dell'installazione del cluster:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'

az managed-cassandra cluster show \
   --cluster-name $clusterName \
   --resource-group $resourceGroupName \

  6. Il comando precedente restituisce informazioni sull'ambiente dell'istanza gestita. Saranno necessari i certificati gossip in modo che sia possibile installarli nell'archivio trust per i nodi nel data center esistente. Lo screenshot seguente mostra l'output del comando precedente e il formato dei certificati:

    Ottenere i dettagli del certificato dal cluster.

    Nota

    I certificati restituiti dal comando precedente contengono interruzioni di riga rappresentate come testo, ad esempio \r\n. È necessario copiare ogni certificato in un file e formattarlo prima di tentare di importarlo nell'archivio attendibilità del data center esistente.

    Suggerimento

    Copiare il gossipCertificates valore della matrice mostrato nella schermata precedente in un file e usare lo script bash seguente (è necessario scaricare e installare jq per la piattaforma) per formattare i certificati e creare file pem separati per ognuno.

    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

  7. Creare quindi un nuovo data center nel cluster ibrido. Assicurarsi di sostituire i valori delle variabili con i dettagli del cluster:

    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

    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.

  8. Dopo aver creato il nuovo data center, eseguire il comando show datacenter per visualizzarne i dettagli:

    resourceGroupName='MyResourceGroup'
clusterName='cassandra-hybrid-cluster'
dataCenterName='dc1'

az managed-cassandra datacenter show \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --data-center-name $dataCenterName

  9. Il comando precedente restituisce i nodi di inizializzazione del nuovo data center:

    Screenshot di come ottenere i dettagli del data center.

  10. Aggiungere ora i nodi di inizializzazione del nuovo data center alla configurazione del nodo di inizializzazione del data center esistente all'interno del file cassandra.yaml. Installare i certificati gossip dell'istanza gestita raccolti in precedenza nell'archivio attendibilità per ogni nodo del cluster esistente, usando keytool il comando per ogni certificato:

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass

    Nota

    Se si vogliono aggiungere altri data center, è possibile ripetere i passaggi precedenti, ma sono necessari solo i nodi di inizializzazione.

    Importante

    Se il cluster Apache Cassandra esistente dispone solo di un singolo data center e questa è la prima volta che viene aggiunto un data center, assicurarsi che il endpoint_snitch parametro in cassandra.yaml sia impostato su GossipingPropertyFileSnitch.

    Importante

    Se il codice dell'applicazione esistente usa QUORUM per coerenza, è necessario assicurarsi che prima di modificare le impostazioni di replica nel passaggio seguente, il codice dell'applicazione esistente usa LOCAL_QUORUM per connettersi al cluster esistente. In caso contrario, gli aggiornamenti in tempo reale avranno esito negativo dopo aver modificato le impostazioni di replica nel passaggio seguente. Dopo che la strategia di replica è stata modificata, è possibile ripristinare quorum, se si preferisce.

  11. Usare infine la query CQL seguente per aggiornare la strategia di replica in ogni keyspace per includere tutti i data center nel cluster:

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};

    È anche necessario aggiornare diverse tabelle di sistema:

    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}

    Importante

    Se i data center nel cluster esistente non applicano la crittografia da client a nodo (SSL) e si prevede che il codice dell'applicazione si connetta direttamente a Cassandra Istanza gestita, sarà necessario abilitare SSL anche nel codice dell'applicazione.

Usare un cluster ibrido per la migrazione in tempo reale

Le istruzioni precedenti forniscono indicazioni per la configurazione di un cluster ibrido. Tuttavia, questo è anche un ottimo modo per ottenere una migrazione senza tempi di inattività senza interruzioni. Se si dispone di un ambiente locale o di un altro ambiente Cassandra che si vuole rimuovere senza tempi di inattività, a favore dell'esecuzione del carico di lavoro in Azure Istanza gestita per Apache Cassandra, è necessario completare i passaggi seguenti in questo ordine:

  1. Configurare un cluster ibrido: seguire le istruzioni riportate in precedenza.

  2. Disabilitare temporaneamente le riparazioni automatiche in Azure Istanza gestita per Apache Cassandra per la durata della migrazione:

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

  3. Nell'interfaccia della riga di comando di Azure eseguire il comando seguente per eseguire nodetool rebuild in ogni nodo nel nuovo data center di Azure Istanza gestita per Apache Cassandra, sostituendo <ip address> con l'indirizzo IP del nodo e <sourcedc> con il nome del data center esistente (quello da cui si esegue la migrazione):

    az managed-cassandra cluster invoke-command \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --host <ip address> \
  --command-name nodetool --arguments rebuild="" "<sourcedc>"=""

    È consigliabile eseguire questa operazione solo dopo aver eseguito tutti i passaggi precedenti. In questo modo tutti i dati cronologici vengono replicati nei nuovi data center in Azure Istanza gestita per Apache Cassandra. È possibile eseguire la ricompilazione in uno o più nodi contemporaneamente. Eseguire in un nodo alla volta per ridurre l'impatto sul cluster esistente. Eseguire su più nodi quando il cluster può gestire l'I/O aggiuntivo e la pressione di rete. Per la maggior parte delle installazioni è possibile eseguire solo uno o due in parallelo per non eseguire l'overload del cluster.

    Avviso

    È necessario specificare il data center di origine durante l'esecuzione di nodetool rebuild. Se si specifica il data center in modo non corretto al primo tentativo, questo comporterà la copia degli intervalli di token, senza copiare i dati per le tabelle non di sistema. I tentativi successivi avranno esito negativo anche se si specifica correttamente il data center. È possibile risolvere questo problema eliminando le voci per ogni keyspace non di sistema in system.available_ranges tramite lo cqlsh strumento di query nel data center cassandra MI di destinazione:

    delete from system.available_ranges where keyspace_name = 'myKeyspace';

  4. Tagliare il codice dell'applicazione in modo che punti ai nodi di inizializzazione nel nuovo Istanza gestita di Azure per i data center Apache Cassandra.

    Importante

    Come indicato anche nelle istruzioni di configurazione ibrida, se i data center nel cluster esistente non applicano la crittografia da client a nodo (SSL), sarà necessario abilitarla nel codice dell'applicazione, perché Cassandra Istanza gestita applica questa operazione.

  5. Eseguire ALTER KEYSPACE per ogni keyspace, come fatto in precedenza, ma ora rimuovendo i data center precedenti.

  6. Eseguire la rimozione delle autorizzazioni nodetool per ogni nodo del data center precedente.

  7. Ripristinare il quorum del codice dell'applicazione (se necessario/preferito).

  8. Riabilitare le riparazioni automatiche:

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

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

Se non si intende continuare a usare questo cluster di Istanza gestita, eliminarlo con la procedura seguente:

  1. Nel menu a sinistra del portale di Azure selezionare Gruppi di risorse.
  2. Selezionare nell'elenco il gruppo di risorse creato in questa guida di avvio rapido.
  3. Nel riquadro Panoramica del gruppo di risorse selezionare Elimina gruppo di risorse.
  4. Nella finestra successiva immettere il nome del gruppo di risorse da eliminare e quindi selezionare Elimina.

Passaggi successivi

In questa guida introduttiva si è appreso come creare un cluster ibrido usando l'interfaccia della riga di comando di Azure e Azure Istanza gestita per Apache Cassandra. È ora possibile iniziare a usare il cluster.

Gestire le risorse di Istanza gestita di Azure per Apache Cassandra tramite l'interfaccia della riga di comando di Azure