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, che consente la 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

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 i dettagli seguenti:

   • Sottoscrizione : nell'elenco a discesa selezionare la sottoscrizione di Azure.
   • 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.
   • Nome del cluster: immettere un nome per il cluster.
   • Percorso : percorso per distribuire il cluster.
   • Versione di Cassandra : versione di Apache Cassandra da distribuire.
   • Extention : estensioni da aggiungere, incluso l'indice Cassandra Lucene.
   • 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 in uscita oppure crearne una nuova.
   • Assegnare 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 stati distribuiti in precedenza i cluster Cassandra di Istanza gestita di SQL di Azure, deselezionare questa opzione.

   

   Suggerimento

   Se si usa la VPN, non è necessario aprire un'altra connessione.

   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 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
   • Set di scalabilità delle macchine virtuali di Azure
   • Monitoraggio di Azure
   • Microsoft Entra ID
   • Sicurezza di Azure
   • Replica automatica. Scegliere il formato di autoreplicazione da usare. Per altre informazioni, vedere Replicazione chiavi in mano.
   • Pianificare la strategia degli eventi. 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 indica solo il nodo di arresto in un determinato rack per un determinato evento pianificato. Ad esempio, se vengono pianificati diversi eventi per i nodi in rack diversi contemporaneamente, solo i nodi in un unico rack vengono interrotti. Altri nodi in altri rack sono in ritardo.

5. Selezionare quindi la scheda Data center.

6. Immetti i dettagli seguenti:

   • Nome del data center. Digitare un nome del data center nel campo di testo.
   • Zona di disponibilità. Selezionare questa casella se si vuole abilitare le zone di disponibilità.
   • Dimensioni SKU. Scegliere tra le dimensioni disponibili dello SKU della macchina virtuale.

   

   Nota

   Abbiamo introdotto il caching write-through (anteprima pubblica) utilizzando gli 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, che garantiscono un aumento enorme delle operazioni di I/O al secondo per le operazioni di lettura e una riduzione della latenza della coda.

   Importante

   La memorizzazione nella cache write-through è disponibile in anteprima pubblica. Questa funzionalità viene fornita senza un contratto di servizio. Non è consigliabile usarlo per 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 da distribuire in questo data center.

   

   Avviso

   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 Elenco di aree di Azure.

   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. Selezionare quindi Rivedi e crea>Crea.

   Nota

   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

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

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, selezionare Ridimensiona.

Scalabilità verticale

Per aumentare o ridurre le dimensioni dello SKU per i nodi, selezionare da SKU Size. Al termine, selezionare Ridimensiona.

Nota

Il tempo necessario per un'operazione di ridimensionamento dipende da diversi fattori. L'operazione potrebbe richiedere diversi 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 visualizzano lo stato integro e lo stato del data center ha avuto esito positivo.

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, selezionare il pulsante Aggiungi nel riquadro Data Center :

   

   Avviso

   Se si aggiunge un data center in un'area diversa, è necessario selezionare una rete virtuale diversa. È anche necessario 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 data center all'interno del cluster di istanza gestita. Per altre informazioni, vedere Connettere reti virtuali tramite il peering di rete virtuale.

   È anche necessario assicurarsi di applicare il ruolo appropriato alla rete virtuale prima di tentare di distribuire un cluster di istanza gestita usando il comando dell'interfaccia della riga di comando seguente.

   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 del data center. Nell'elenco a discesa selezionare la sottoscrizione di Azure.
   • Zona di disponibilità. Selezionare se si vuole abilitare le zone di disponibilità in questo data center.
   • Posizione. Posizione in cui viene 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 da distribuire in questo data center.
   • Rete virtuale. Selezionare una rete virtuale e una subnet in uscita.

   

   Avviso

   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 in merito nel riquadro Data center:

   

4. 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 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 in cui sono già presenti dati, eseguire rebuild per replicare i dati cronologici. Nell'interfaccia della riga di comando di Azure, usare il seguente comando nodetool rebuild su ogni nodo del nuovo data center. Questa azione sostituisce <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 si deve permettere ai client dell'applicazione di scrivere nel nuovo data center fino a quando non si applicano le modifiche alla replica del keyspace. In caso contrario, la ricompilazione non funziona ed è 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 gli aggiornamenti alla configurazione YAML di Cassandra in un data center usando il portale di Azure o i comandi dell'interfaccia della riga di comando. Per aggiornare le impostazioni nel portale:

1. Trovare Cassandra Configuration nelle impostazioni. Evidenziare il data center di cui si vuole modificare la configurazione e 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 Cassandra Configuration riquadro:

   

   Nota

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

   Importante

   Assicurarsi che le impostazioni yaml di Cassandra specificate siano appropriate per la versione di Cassandra distribuita. Per le impostazioni di Cassandra v3.11 per Cassandra v3.11 e Cassandra v4.0 per v4.0, vedere Cassandra v3.11 . Non è possibile aggiornare le impostazioni YAML seguenti:

   • cluster_name
   • fornitore di semi
   • initial_token
   • autobootstrap
   • opzioni_di_crittografia_client
   • opzioni_di_crittografia_del_server
   • opzioni di crittografia dati trasparenti
   • opzioni_di_registrazione_verifica
   • Autenticatore
   • autorizzatore
   • role_manager
   • porta di archiviazione
   • porta_archiviazione_ssl
   • porta_di_trasporto_nativa
   • native_transport_port_ssl
   • listen_address
   • listen_interface
   • indirizzo di broadcast
   • hints_directory
   • data_file_directories
   • commitlog_directory
   • cdc_raw_directory
   • saved_caches_directory
   • endpoint_snitch
   • Partizionatore
   • 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 fornite senza un contratto di servizio. Queste funzionalità 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 in loco direttamente dal portale o tramite Az CLI, Terraform o modelli ARM.

1. Trovare il Update pannello nella scheda Panoramica.

   

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

   Avviso

   Non saltare le versioni. È consigliabile eseguire l'aggiornamento solo da una versione a un altro esempio da 3.11 a 4.0, da 4.0 a 4.1.

   

3. 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. Se si usano funzionalità di replica chiavi in mano, la configurazione e la gestione di cluster in più aree diventano più accessibili, consentendo un'integrazione e un funzionamento più uniformi in ambienti distribuiti.

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

Suggerimento

• None: la replica automatica è impostata su nessuna.
• SystemKeyspaces: consente di eseguire la replica automatica di tutti i keyspace di sistema (system_auth, system_traces, system_auth).
• AllKeyspaces: replicare automaticamente tutti gli spazi chiave e monitorare se vengono creati nuovi keyspace e quindi applicare automaticamente le impostazioni di autoreplicazione.

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 la rimozione automatica dello specifico data center dai keyspace.

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

Avviso

Se si imposta la replica automatica su AllKeyspaces, la replica keyspaces viene modificata in modo da includere:

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

Se questa topologia non è quella che desideri, usa SystemKeyspaces, modificalo tu stesso ed esegui nodetool rebuild direttamente nel cluster di Istanza gestita di Azure per Apache Cassandra.

Deallocare il cluster

Per gli ambienti non di produzione, è possibile sospendere o deallocare le risorse nel cluster per evitare addebiti. L'addebito per l'archiviazione continua. Modificare per prima cosa il tipo di cluster in NonProduction, quindi deallocate.

Suggerimento

Il tipo di cluster deve essere usato solo come "Non produzione" 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 ha garanzie di contratto di servizio applicate.
• Non eseguire operazioni di scrittura o dei schemi durante la deallocazione. Questa azione può causare la perdita di dati e in rari casi il danneggiamento dello schema richiede l'intervento manuale del team di supporto.

Risoluzione dei problemi

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

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

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 esempi per la connessione a Istanza gestita di Azure per Apache Cassandra con Java, .NET, Node.jse Python.

È consigliabile disabilitare la verifica del certificato perché la verifica del certificato non funziona a meno che non si esegua il mapping degli indirizzi IP 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 configurazione 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 nuovi elementi 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. Per una demo che illustra il funzionamento di questo approccio, vedere come abilitare la politica Demo: implementazione dell'esecuzione speculativa.

Nota

Nella maggior parte dei casi , non deve essere necessario configurare o installare certificati (ad esempio rootCA, node o client, truststore) 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 utilizzato dal client, perché i certificati di Apache Cassandra sono considerati attendibili dall'Istanza gestita di Azure in tale ambiente. In rari casi, se il certificato non è attendibile, potrebbe essere necessario aggiungerlo all'archivio di fiducia. Vedere Java, .NET, Node.jse Python.

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é vengano completati 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. Certificato privato e pubblico (nessuna CA) per ogni nodo. In questo caso, sono necessari tutti i certificati pubblici.
• Certificati firmati da una CA. Questo certificato può essere una CA autofirmata o anche una CA pubblica. In questo caso, è necessario il certificato della radice CA e tutti i certificati intermedi (se applicabile). Per altre informazioni, vedere Preparazione dei certificati SSL per la produzione.

Se si vuole implementare l'autenticazione del certificato da client a nodo o mTLS (Transport Layer Security), fornire i certificati usando l'interfaccia della riga di comando di Azure. Il comando seguente carica e applica i certificati client all'archivio trust 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. Consulta require_client_auth: true nelle opzioni client_encryption_options di Cassandra.

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:

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.

Passo successivo

Distribuire un cluster Apache Spark gestito con Azure Databricks