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

Articolo
08/15/2024

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, offrendo massima flessibilità e controllo dove necessario

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

Prerequisiti

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

Creare un cluster di Istanza gestita

Accedere al portale di Azure.
Nella barra di ricerca cercare Istanza gestita per Apache Cassandra e selezionare il risultato.
Selezionare il pulsante Crea cluster di Istanza gestita per Apache Cassandra.
Nel riquadro Crea Istanza gestita per Apache Cassandra immettere i dettagli seguenti:
- Sottoscrizione: selezionare la sottoscrizione di Azure nell'elenco a discesa.
- Gruppo di risorse: specificare se si desidera creare un nuovo gruppo di risorse o usarne uno esistente. Un gruppo di risorse è un contenitore con risorse correlate per una soluzione di Azure. Per altre informazioni, vedere Panoramica di Gestione risorse di Microsoft Azure.
- Nome del cluster: immettere un nome per il cluster.
- Posizione: posizione in cui verrà distribuito il cluster.
- Versione di Cassandra: versione di Apache Cassandra che verrà distribuita.
- Estensione: estensioni che verranno aggiunte, tra cui Cassandra Lucene Index.
- Password amministratore iniziale di Cassandra: password usata per creare il cluster.
- Conferma password amministratore di Cassandra: immettere nuovamente la password.
- Rete virtuale: selezionare una rete virtuale e una subnet esistenti oppure crearne una nuova.
- Assegna ruoli: le reti virtuali richiedono autorizzazioni speciali per consentire la distribuzione dei cluster Cassandra gestiti. Mantenere questa casella selezionata 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 già stati distribuiti cluster di Istanza gestita di SQL Azure per Apache Cassandra, deselezionare questa opzione.
Suggerimento

Se si usa una VPN, non è necessario aprire altre connessioni.
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. Per informazioni più dettagliate, vedere Regole di rete in uscita necessarie.
- Archiviazione di Azure
- Azure Key Vault
- Set di scalabilità delle macchine virtuali di Azure
- Monitoraggio di Azure
- Microsoft Entra ID
- Sicurezza di Azure
- Replica automatica: scegliere la forma di replica automatica da usare. Ulteriori informazioni
- Strategia eventi pianificati: strategia usata dal cluster per gli eventi pianificati.
Suggerimento
- StopANY significa arrestare qualsiasi nodo quando è presente un evento pianificato per il nodo.
- StopByRack significa arrestare solo il nodo in un determinato rack per un determinato evento pianificato. Ad esempio se sono pianificati due o più eventi simultanei per nodi in rack diversi, verranno arrestati solo i nodi in un rack, mentre gli altri nodi in altri rack saranno ritardati.
Selezionare quindi la scheda Data center.
Immetti i dettagli seguenti:
- Nome data center: digitare un nome per il data center nel campo di testo.
- Zona di disponibilità: selezionare questa casella se si vogliono abilitare le zone di disponibilità.
- Dimensioni SKU: scegliere tra le dimensioni disponibili dello SKU della macchina virtuale.
Nota

Abbiamo introdotto la cache write-through (anteprima pubblica) tramite l'utilizzo degli SKU delle macchine virtuali 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 che richiedono un numero elevato di operazioni di lettura. Questi SKU specifici sono dotati di dischi collegati in locale, garantendo un aumento enorme delle operazioni di I/O al secondo per le operazioni di lettura e una riduzione della latenza della coda.

Importante

La cache write-through è in anteprima pubblica. Questa funzionalità viene messa a disposizione senza contratto di servizio e non è consigliata per i carichi di lavoro di produzione. Per altre informazioni, vedere le Condizioni supplementari per l'uso 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 che verranno distribuiti in questo data center.
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.
Selezionare quindi Rivedi e crea>Crea

Nota

La creazione del cluster può richiedere fino a 15 minuti.
Al termine della distribuzione, controllare il gruppo di risorse per visualizzare il cluster dell'istanza gestita appena creato:
Per esplorare i nodi del cluster, passare alla risorsa cluster e aprire il riquadro Data center per visualizzarli:

Ridimensionare un data center

Ora che è stato distribuito un cluster con un singolo data center, è possibile ridimensionarlo orizzontalmente o verticalmente evidenziando il data center e selezionando il pulsante Scale:

Scalabilità orizzontale

Per aumentare o ridurre il numero di nodi, spostare il dispositivo di scorrimento sul numero desiderato o semplicemente modificare il valore. Al termine, premere Scale.

Scalabilità verticale

Per aumentare o ridurre le dimensioni dello SKU per i nodi, selezionare dall'elenco a discesa Sku Size. Al termine, premere Scale.

Nota

L'intervallo di tempo necessario per un'operazione di ridimensionamento dipende da vari fattori, può richiedere alcuni minuti. Quando Azure notifica che l'operazione di ridimensionamento è stata completata, ciò non significa che tutti i nodi siano stati aggiunti all'anello Cassandra. Il commissioning sarà stato completato quando tutti i nodi mostreranno lo stato "integro" e lo stato del data center sarà "operazione completata". Il ridimensionamento è un'operazione online e funziona allo stesso modo descritto per l'applicazione di patch in Operazioni di gestione

Aggiungere un data center

Per aggiungere un altro data center, fare clic sul pulsante di aggiunta nel riquadro Data center:
Avviso

Se si aggiunge un data center in un'area diversa, sarà necessario selezionare una rete virtuale diversa. È anche necessario assicurarsi che questa rete virtuale disponga di connettività alla rete virtuale dell'area primaria creata in precedenza e a qualsiasi altra rete virtuale che ospita i data center all'interno del cluster dell'istanza gestita. Vedere questo articolo per informazioni su come eseguire il peering di reti virtuali usando il portale di Azure. È anche necessario assicurarsi di aver applicato il ruolo appropriato alla rete virtuale prima di provare a distribuire un cluster di Istanza gestita, usando il comando seguente dell'interfaccia della riga di comando.
```
    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>
```
Compilare i campi appropriati:
- Nome data center: nell'elenco a discesa selezionare la sottoscrizione di Azure.
- Zona di disponibilità: selezionare questa casella se si vogliono abilitare le zone di disponibilità in questo data center.
- Posizione: posizione in cui verrà distribuito il data center.
- Dimensioni SKU: scegliere tra le dimensioni disponibili dello SKU della macchina virtuale.
- No. di dischi - Scegliere il numero di dischi p30 da collegare a ogni nodo Cassandra.
- No. di nodi - Scegliere il numero di nodi Cassandra che verranno distribuiti in questo data center.
- Rete virtuale: selezionare una rete virtuale e una subnet esistenti.
Avviso

Si noti che non è consentita la creazione di una nuova rete virtuale quando si aggiunge un data center. È necessario scegliere una rete virtuale esistente e, come indicato in precedenza, verificare che ci sia connettività tra le subnet di destinazione in cui i data center verranno distribuiti. È anche necessario applicare il ruolo appropriato alla rete virtuale per consentire la distribuzione (vedere sopra).
Quando il data center viene distribuito, dovrebbe essere possibile visualizzare tutte le informazioni in merito nel riquadro Data center:
Per garantire la replica tra data center, connettersi a cqlsh e usare la query CQL seguente per aggiornare la strategia di replica in ogni keyspace in modo da includere tutti i data center nel cluster (le tabelle di sistema verranno aggiornate automaticamente):
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
Se si aggiunge un data center a un cluster in cui sono già presenti dati, è necessario eseguire rebuild per replicare i dati storici. Nell'interfaccia della riga di comando di Azure eseguire il comando seguente per eseguire nodetool rebuild in ogni nodo del nuovo data center, sostituendo <new dc ip address> con l'indirizzo IP del nodo e <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>"=""
```
Avviso

Non è consigliabile consentire ai client applicazioni di scrivere nel nuovo data center finché non sono state applicate modifiche alla replica del keyspace. In caso contrario, la ricompilazione non funzionerà e sarà necessario creare una richiesta di supporto in modo che il team possa eseguire repair per conto dell'utente.

Aggiornare la configurazione di Cassandra

Il servizio consente l'aggiornamento della configurazione YAML di Cassandra in un data center tramite il portale o usando i comandi dell'interfaccia della riga di comando. Per aggiornare le impostazioni nel portale:

Trovare Cassandra Configuration nelle impostazioni. Evidenziare il data center di cui si vuole modificare la configurazione e fare clic su Aggiorna:
Nella finestra visualizzata immettere i nomi dei campi in formato YAML, come illustrato di seguito. Fare quindi clic su Aggiorna.
Al termine dell'aggiornamento, i valori sottoposti a override verranno visualizzati nel riquadro Cassandra Configuration:

Nota

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

Assicurarsi che le impostazioni YAML di Cassandra specificate siano appropriate per la versione di Cassandra distribuita. Vedere qui per le impostazioni di Cassandra v3.11 e qui per la versione v4.0. Non è consentito 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

Importante

Cassandra 5.0 e gli aggiornamenti della versione chiavi in mano sono in anteprima pubblica. Queste funzionalità vengono messe a disposizione senza contratto di servizio e non sono consigliate per i carichi di lavoro di produzione. Per altre informazioni, vedere le Condizioni supplementari per l'uso 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 Az, Terraform o i modelli di ARM.

Trovare il pannello Update nella scheda Panoramica
Selezionare la versione di Cassandra nell'elenco a discesa.

Avviso

Non ignorare versioni. È consigliabile aggiornare solo da una versione alla successiva, ad esempio da 3.11 a 4.0, da 4.0 a 4.1.
Selezionare Aggiorna per salvare.

Replica chiavi in mano

Cassandra 5.0 introduce un approccio semplificato per la distribuzione di cluster in più aree, offrendo maggiore praticità ed efficienza. L'uso della funzionalità di replica chiavi in mano rende la configurazione e la gestione dei cluster in più aree più accessibili, agevolando 'integrazione e il funzionamento negli ambienti distribuiti. Questo aggiornamento riduce significativamente le complessità tradizionalmente associate alla distribuzione e alla gestione delle configurazioni in più aree, consentendo agli utenti di usare le funzionalità di Cassandra con maggiore facilità ed efficacia.

Suggerimento

None: la replica automatica è impostata su nessuna.
SystemKeyspaces: replica automaticamente tutti i keyspace di sistema (system_auth, system_traces, system_auth)
AllKeyspaces: replica automaticamente tutti i keyspace, monitora se vengono creati nuovi keyspace e quindi applica automaticamente le impostazioni di replica automatica.

Scenari di replica automatica

Quando si aggiunge un nuovo data center, la funzionalità di replica automatica in Cassandra eseguirà nodetool rebuild senza problemi per garantire la corretta replica dei dati nel data center aggiunto.
La rimozione di un data center attiva la rimozione automatica dello specifico data center dai keyspace.

Per i data center esterni, ad esempio quelli ospitati in locale, possono essere inclusi nei keyspace mediante l'utilizzo della proprietà del data center esterno. Ciò consente a Cassandra di incorporare questi data center esterni come origini per il processo di ricompilazione.

Avviso

Se si imposta la replica automatica su AllKeyspaces, la replica dei keyspace verrà modificata in modo da includere WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } Se non si tratta della topologia desiderata, sarà necessario usare SystemKeyspaces, modificarli manualmente ed eseguire nodetool rebuild manualmente nel cluster di Istanza gestita di Azure per Apache Cassandra.

Deallocare il cluster

Per gli ambienti non di produzione, è possibile sospendere/deallocare le risorse nel cluster per evitare che vengano addebitate (i costi per l'archiviazione continueranno a essere addebitati). Modificare per prima cosa il tipo di cluster in NonProduction, quindi deallocate.

Suggerimento

Il tipo di cluster deve essere usato solo come "NonProduction" per risparmiare sui costi di sviluppo. Possono essere dotati di SKU più piccoli e non devono essere usati per eseguire carichi di lavoro di produzione.

Avviso

Il tipo di cluster definito come "Nonproduction" non avrà garanzie di contratto di servizio applicate.
Non eseguire alcuna operazione di scrittura o schema durante la deallocazione. Ciò può causare la perdita di dati, e in rari casi, il danneggiamento dello schema, che richiede l'intervento manuale del team di supporto.

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.

Connessione al cluster

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

Connessione da CQLSH

Dopo aver distribuito la macchina virtuale, usare SSH per connettersi al computer e installare CQLSH con 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

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

Pulire le risorse

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

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

Passaggi successivi

In questo argomento di avvio rapido si è appreso come creare un cluster di Istanza gestita di Azure per Apache Cassandra usando il portale di Azure. A questo punto è possibile iniziare a usare il cluster:

Distribuire un cluster Apache Spark gestito con Azure Databricks

Condividi tramite

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

Prerequisiti

Creare un cluster di Istanza gestita

Ridimensionare un data center

Scalabilità orizzontale

Scalabilità verticale

Aggiungere un data center

Aggiornare la configurazione di Cassandra

Aggiornare la versione di Cassandra

Replica chiavi in mano

Scenari di replica automatica

Deallocare il cluster

Risoluzione dei problemi

Connessione al cluster

Connessione da CQLSH

Connessione da un'applicazione

Configurazione dei certificati client (facoltativo)

Pulire le risorse

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive