Avvio rapido: Creare un cluster di Istanza gestita di Azure per Apache Cassandra nel portale di Azure

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, per la massima flessibilità e controllo.

Questo argomento di avvio rapido illustra come usare il portale di Azure per creare un cluster di Istanza gestita di Azure per Apache Cassandra.

Prerequisito

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Creare un cluster di Istanza gestita

1. Accedere al portale di Azure.

2. Nella barra di ricerca cercare Istanza gestita per Apache Cassandra e selezionare il risultato.

   

3. Selezionare Crea istanza gestita per il cluster Apache Cassandra.

   

4. Nel riquadro Crea istanza gestita per Apache Cassandra immettere le informazioni seguenti:

   • Sottoscrizione: nell'elenco a discesa selezionare la sottoscrizione di Azure.

   • Gruppo di risorse: specificare se si vuole creare un nuovo gruppo di risorse o usarne uno esistente. Un gruppo di risorse è un contenitore con risorse correlate per una soluzione Azure.

   • Nome cluster: immettere un nome per il cluster.

   • Percorso: selezionare il percorso per distribuire il cluster.

   • Versione di Cassandra: selezionare la versione di Apache Cassandra da distribuire.

   • Estensione: selezionare le estensioni da aggiungere, incluso Cassandra Lucene Index. È rilevante solo per Cassandra v3.11.

   • Password iniziale dell'amministratore di Cassandra: immettere la password usata per creare il cluster.

   • Confermare la password amministratore di Cassandra: immettere nuovamente la password.

   • Rete virtuale: selezionare una rete virtuale e una subnet esistenti oppure crearne una nuova. Prendere nota delle regole di rete oppure usare la configurazione basata su VPN.

   • Assegnare ruoli: le reti virtuali richiedono autorizzazioni speciali per consentire la distribuzione dei cluster Cassandra gestiti. Mantenere selezionata questa casella se si crea una nuova rete virtuale o si usa una rete virtuale esistente senza autorizzazioni applicate. Se si usa una rete virtuale in cui sono stati distribuiti in precedenza i cluster Cassandra di Istanza gestita di SQL di Azure, deselezionare questa opzione.

     

   Se si usa una rete privata virtuale, non è necessario aprire un'altra connessione.

   La distribuzione di 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 nella rete virtuale ai servizi di Azure essenziali seguenti necessari per il corretto funzionamento di Cassandra gestito. Per altre informazioni, vedere Regole di rete in uscita necessarie.

   • Archiviazione di Azure

   • Azure Key Vault (Archivio chiavi di Azure)

   • Set di scalabilità delle macchine virtuali di Azure

   • Monitoraggio di Azure

   • Microsoft Entra ID

   • Microsoft Defender for Cloud

   • Replica automatica: scegliere la forma di replica automatica da usare. Per altre informazioni, vedere Replica chiavi in mano.

   • Pianificare la strategia degli eventi: la strategia usata dal cluster per gli eventi pianificati.

   Suggerimento

   • StopANY indica l'arresto di qualsiasi nodo quando è presente un evento pianificato per il nodo.
   • StopByRack significa arrestare i nodi solo in un rack specifico per un evento pianificato specifico. Ad esempio, se sono pianificati diversi eventi per i nodi in rack diversi contemporaneamente, i nodi in un solo rack si arrestano. Altri nodi in altri rack sono in ritardo.

5. Selezionare la scheda Data center.

6. Immettere le informazioni seguenti:

   • Nome data center: immettere un nome del data center nel campo di testo.

   • Zona di disponibilità: selezionare questa casella di controllo se si desidera abilitare le zone di disponibilità.

   • Dimensioni SKU: scegliere tra le dimensioni del livello prodotto della macchina virtuale (VM) disponibili.

     

   La cache write-through (anteprima pubblica) è stata introdotta usando i livelli di prodotto della macchina virtuale serie L. Questa implementazione mira a ridurre al minimo le latenze della coda e migliorare le prestazioni di lettura, in particolare per i carichi di lavoro a elevato utilizzo di lettura. Questi livelli di prodotto specifici sono dotati di dischi collegati in locale, che garantiscono un aumento delle operazioni di I/O al secondo per le operazioni di lettura e una riduzione della latenza della coda.

   La cache write-through viene fornita senza un contratto di servizio. Non è consigliabile usarlo per carichi di lavoro di produzione. Per altre informazioni, vedere Condizioni supplementari per l'utilizzo delle anteprime di Microsoft Azure.

   • No. di dischi: scegliere il numero di dischi p30 da collegare a ogni nodo Cassandra.

   • No. di nodi: scegliere il numero di nodi Cassandra da distribuire in questo data center.

     

   Le zone di disponibilità non sono supportate in tutte le aree. Le distribuzioni hanno esito negativo se si seleziona un'area in cui le zone di disponibilità non sono supportate. Per altre informazioni, vedere l'elenco delle aree di Azure.

   La corretta distribuzione delle zone di disponibilità è soggetta anche alla disponibilità delle risorse di calcolo in tutte le zone dell'area specifica. Le distribuzioni potrebbero non riuscire se il livello di prodotto selezionato o la capacità non è disponibile in tutte le zone.

7. Selezionare Rivedi e crea>Crea.

   La creazione di un cluster può richiedere fino a 15 minuti.

   

8. Al termine della distribuzione, controllare il gruppo di risorse per visualizzare il cluster dell'istanza gestita appena creata.

   

9. Per esplorare i nodi del cluster, passare alla risorsa cluster e aprire il riquadro Data Center .

   

Ridimensionare un data center

Dopo aver distribuito un cluster con un singolo data center, è possibile ridimensionare orizzontalmente o verticalmente. Evidenziare il data center e quindi selezionare Ridimensiona.

Scalabilità orizzontale

Per aumentare o ridurre la capacità dei nodi, spostare il dispositivo di scorrimento sul numero desiderato. È anche possibile modificare il valore. Al termine, selezionare Ridimensiona.

Scalabilità verticale

Per aumentare o ridurre la dimensione del livello prodotto per il tuo nodo, selezionare le opzioni dall'elenco a discesa Dimensioni SKU. Al termine, selezionare Ridimensiona.

Il tempo necessario per un'operazione di ridimensionamento dipende da vari fattori. L'operazione potrebbe richiedere alcuni minuti. Quando Azure notifica che l'operazione di scalabilità è stata completata, non significa che tutti i nodi sono stati aggiunti all'anello Cassandra. I nodi vengono completamente commissionati quando tutti mostrano lo stato di Integro e lo stato del data center riporta Riuscito.

Il ridimensionamento è un'operazione online e funziona allo stesso modo descritto per l'applicazione di patch. Per altre informazioni, vedere Applicazione di patch.

Aggiungere un data center

1. Per aggiungere un altro data center, nel riquadro Data Center selezionare Aggiungi.

   

   Se si aggiunge un data center in un'area diversa, è necessario selezionare una rete virtuale diversa. Assicurarsi che questa rete virtuale disponga della connettività alla rete virtuale dell'area primaria creata in precedenza. Assicurarsi inoltre che tutte le altre reti virtuali che ospitano i data center si trovino all'interno del cluster di istanza gestita. Per altre informazioni, vedere Connettere reti virtuali tramite il peering di rete virtuale.

   Assicurarsi di aver applicato il ruolo appropriato alla rete virtuale prima di tentare di distribuire un cluster di istanza gestita. Usare il comando seguente dell'interfaccia della riga di comando di Azure:

      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>
   

2. Compilare i campi appropriati:

   • Nome data center: nell'elenco a discesa selezionare la sottoscrizione di Azure.

   • Zona di disponibilità: selezionare se si desidera abilitare le zone di disponibilità in questo data center.

   • Località: posizione in cui viene distribuito il data center.

   • Dimensioni SKU: scegliere tra le dimensioni del livello prodotto della macchina virtuale disponibile.

   • No. di dischi: scegliere il numero di dischi p30 da collegare a ogni nodo Cassandra.

   • No. di nodi: scegliere il numero di nodi Cassandra da distribuire in questo data center.

   • Rete virtuale: selezionare una rete virtuale e una subnet esistenti.

     

   Il portale di Azure non consente la creazione di una nuova rete virtuale quando si aggiunge un data center. È necessario scegliere una rete virtuale esistente ed è necessario assicurarsi che sia presente la connettività tra le subnet di destinazione in cui vengono distribuiti i data center. È anche necessario applicare il ruolo appropriato alla rete virtuale per consentire la distribuzione, come descritto in precedenza.

3. Quando il data center viene distribuito, dovrebbe essere possibile visualizzare tutte le informazioni sul data center nel riquadro Data Center .

   

4. Per garantire la replica tra data center, connettersi a Cassandra Query Language Shell (CQLSH) e usare la query CQL seguente per aggiornare la strategia di replica in ogni keyspace per includere tutti i data center nel cluster. Le tabelle di sistema vengono aggiornate automaticamente.

   ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
   

5. Se si aggiunge un data center a un cluster che dispone già di dati, eseguire rebuild per replicare i dati cronologici. Nell'interfaccia della riga di comando di Azure usare il comando seguente ed eseguire nodetool rebuild in ogni nodo del nuovo data center. Questa azione sostituisce <new dc ip address> con l'indirizzo IP del nodo e sostituisce <olddc> con il nome del data center esistente:

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

Non consentire ai client dell'applicazione di scrivere nel nuovo data center finché non si applicano modifiche alla replica keyspace. In caso contrario, la ricompilazione non funziona e sarà necessario creare una richiesta di supporto, così che il nostro team possa eseguire repair per te.

Aggiornare la configurazione di Cassandra

È possibile usare il portale di Azure o i comandi dell'interfaccia della riga di comando per aggiornare la configurazione YAML di Cassandra in un data center. Per aggiornare le impostazioni nel portale:

1. In Impostazioni selezionare Configurazione Cassandra. Evidenziare il data center di cui si vuole modificare la configurazione e quindi selezionare Aggiorna.

   

2. Nella finestra visualizzata immettere i nomi dei campi in formato YAML, come illustrato di seguito. Selezionare quindi Aggiorna.

   

3. Al termine dell'aggiornamento, i valori sottoposti a override vengono visualizzati nel riquadro Configurazione Cassandra .

   

   Nel portale di Azure vengono visualizzati solo i valori di configurazione di Cassandra sottoposti a override.

   Assicurarsi che le impostazioni YAML di Cassandra specificate siano appropriate per la versione di Cassandra distribuita. Per altre informazioni, vedere [Cassandra v5.0] (https://github.com/apache/cassandra/blob/cassandra-5.0/conf/cassandra.yaml) e Cassandra v4.0 per le impostazioni v4.0 e Cassandra v3.11 per Cassandra v3.11. Non è possibile aggiornare le impostazioni YAML seguenti:

   • cluster_name
   • seed_provider
   • initial_token
   • autobootstrap
   • client_encryption_options
   • server_encryption_options
   • transparent_data_encryption_options
   • audit_logging_options
   • authenticator
   • authorizer
   • 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
   • partitioner
   • rpc_address
   • rpc_interface

Aggiornare la versione di Cassandra

Gli aggiornamenti delle versioni di Cassandra 5.0 e Turnkey sono disponibili in anteprima pubblica. Queste funzionalità vengono fornite senza contratto di servizio. Queste funzionalità non sono consigliate per i carichi di lavoro di produzione. Per altre informazioni, vedere Condizioni supplementari per l'utilizzo delle anteprime di Microsoft Azure.

È possibile eseguire aggiornamenti delle versioni principali sul posto direttamente dal portale o tramite l'interfaccia della riga di comando di Azure, Terraform o i modelli di Azure Resource Manager.

1. Nella scheda Panoramica selezionare Aggiorna.

   

2. Selezionare la versione di Cassandra nell'elenco a discesa.

   Non ignorare le versioni. È consigliabile eseguire l'aggiornamento da una sola versione a un'altra. Ad esempio, eseguire l’aggiornamento da 3.11 a 4.0 o da 4.0 a 4.1 o da 4.1 a 5.0.

   

3. Selezionare Aggiorna per salvare.

Replica chiavi in mano

Cassandra 5.0 introduce un approccio semplificato per distribuire cluster in più aree, che offrono maggiore praticità ed efficienza. Se si usano funzionalità di replica chiavi in mano, la configurazione e la gestione dei cluster in più aree è più accessibile. È possibile ottenere un'integrazione e un'operazione più fluide in ambienti distribuiti.

Questo aggiornamento riduce le complessità associate alla distribuzione e alla gestione di più configurazioni di area. Gli utenti possono usare le funzionalità di Cassandra con maggiore facilità ed efficacia.

• Nessuno: l'opzione Replica automatica è impostata su Nessuno.
• Keyspaces di sistema: autoreplicare tutti i keyspaces di sistema (system_auth, system_traces e system_auth).
• Tutti i keyspaces: replicare automaticamente tutti i keyspaces, monitorare la creazione di nuovi keyspace e quindi applicare automaticamente le impostazioni di autoreplica.

Scenari di replica automatica

Quando si aggiunge un nuovo data center, la funzionalità di replica automatica in Cassandra viene eseguita nodetool rebuild senza problemi per garantire la corretta replica dei dati nel data center aggiunto. La rimozione di un data center attiva una rimozione automatica del data center specifico dagli spazi chiave.

Per i data center esterni, ad esempio quelli ospitati in locale, usare la proprietà del data center esterno per includerli negli spazi chiave. Questo approccio consente a Cassandra di incorporare questi centri dati esterni come fonti per il processo di ricostruzione.

Se si imposta Replica automatica su Tutti gli spazi delle chiavi, la replica degli spazi delle chiavi cambia in modo da includere:

WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 }

Se questa topologia non è quella desiderata, usa SystemKeyspaces, modificali personalmente ed esegui nodetool rebuild manualmente nel cluster di Istanza Gestita di Azure per Apache Cassandra.

Deallocare un cluster

Per gli ambienti non di produzione, è possibile sospendere o deallocare le risorse nel cluster per evitare di essere addebitate. Continuano a essere applicati addebiti per l'archiviazione. Prima di tutto, modificare Tipo di cluster in NonProduction e quindi selezionare Deallocare.

Usare il tipo di cluster NonProduction solo per risparmiare sui costi di sviluppo. Questo tipo di cluster potrebbe essere dotato di livelli di prodotto più piccoli. Non usarlo per eseguire carichi di lavoro di produzione.

• I tipi di cluster definiti come NonProduction non dispongono di garanzie di contratto di servizio applicate.
• Non eseguire alcuna operazione di scrittura o schema durante la deallocazione. Questa azione può causare la perdita di dati. In rari casi, è possibile che si verifichi un danneggiamento dello schema, che richiede l'intervento manuale del team di supporto.

Risoluzione dei problemi

Se si verifica un errore quando si applicano autorizzazioni alla rete virtuale quando si usa l'interfaccia della riga di comando di Azure, è possibile applicare manualmente la stessa autorizzazione dal portale di Azure. Un esempio di questo errore è "Non è possibile trovare l'utente o l'entità servizio nel database a grafo per e5007d2c-4b13-4a74-9b6a-605d99f03501". Per altre informazioni, vedere Usare il portale di Azure per aggiungere l'entità servizio di Azure Cosmos DB.

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.

Collegati al tuo cluster

Istanza gestita di Azure per Apache Cassandra non crea nodi con indirizzi IP pubblici. Per connettersi al cluster Cassandra appena creato, 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 per distribuire una macchina virtuale Ubuntu.

Connettersi da CQLSH

Dopo aver distribuito la macchina virtuale, usare Secure Shell per connettersi al computer. Per installare CQLSH, usare i 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

Connettersi da un'applicazione

Come per CQLSH, quando si usa uno dei driver client Apache Cassandra supportati per connettersi da un'applicazione, la crittografia Transport Layer Security/Secure Sockets Layer (TLS/SSL) deve essere abilitata e la verifica del certificato deve essere disabilitata. Per esempi usati per connettersi a Istanza gestita di Azure per Apache Cassandra, vedere Java, .NET, Node.jse Python.

È consigliabile disabilitare la verifica del certificato perché non funziona a meno che non si esegua il mapping degli indirizzi IP dei nodi del cluster al dominio appropriato. Se un criterio interno impone di eseguire la verifica del certificato TLS/SSL per qualsiasi applicazione, aggiungere voci come 10.0.1.5 host1.managedcassandra.cosmos.azure.com nel file hosts per ogni nodo per facilitare questa configurazione. Se si usa questo approccio, è anche necessario aggiungere nuove voci ogni volta che si aumentano le prestazioni dei nodi.

Per Java, è consigliabile abilitare i criteri di esecuzione speculativi in cui le applicazioni sono sensibili alla latenza della coda. Per una demo che illustra il funzionamento di questo approccio e per informazioni su come abilitare i criteri, vedere Demo: Implementare l'esecuzione speculativa.

Nella maggior parte dei casi, non deve essere necessario configurare o installare certificati ( ad esempio rootCA, nodeclient, o truststore) per connettersi a Istanza gestita di Azure per Apache Cassandra. Per abilitare la crittografia TLS/SSL, usare l'archivio trust predefinito e la password del runtime usato dal client. Tale ambiente considera attendibile l'istanza gestita di Azure per i certificati Apache Cassandra. In rari casi, se il certificato non è attendibile, potrebbe essere necessario aggiungerlo all'archivio di certificati fidati. Per il codice di esempio, vedere Java, .NET, Node.jse Python.

Configurare i certificati client (facoltativo)

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

• Certificati autofirmato: Certificati privati e pubblici senza autorità di certificazione (CA) per ogni nodo. In questo caso, sono necessari tutti i certificati pubblici.
• Certificati firmati da una CA: Certificati emessi da una CA autofirmato o da una CA pubblica. In questo caso, è necessario il certificato della CA radice e tutti i certificati intermedi, se applicabile. Per altre informazioni, vedere Preparare i certificati SSL per la produzione.

Se si vuole implementare l'autenticazione del certificato da client a nodo o mTLS (Mutual Transport Layer Security), usare l'interfaccia della riga di comando di Azure per fornire i certificati. Il comando seguente carica e applica i certificati del client al deposito di fiducia per il cluster di istanza gestita. Non è necessario modificare cassandra.yaml le impostazioni. Dopo aver applicato il comando, il cluster richiede a Cassandra di verificare i certificati quando un client si connette. Per altre informazioni, 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

Pulire le risorse

Se non si intende continuare a usare questo cluster di istanza gestita, seguire questa procedura per eliminarlo:

1. Nel menu a sinistra del portale di Azure, selezionare Gruppi di risorse.
2. Nell'elenco selezionare il gruppo di risorse creato per questa guida introduttiva.
3. Nel riquadro Panoramica del gruppo di risorse selezionare Elimina gruppo di risorse.
4. Nel riquadro successivo immettere il nome del gruppo di risorse da eliminare e quindi selezionare Elimina.

Passo successivo

Distribuire un cluster Apache Spark gestito con Azure Databricks