Guida introduttiva: Creare un Istanza gestita di Azure per cluster Apache Cassandra dal portale di Azure

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 il portale di Azure per creare un Istanza gestita di Azure per il cluster 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 Create Istanza gestita for Apache Cassandra cluster (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 vuole 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 l'articolo Panoramica del gruppo di risorse di Azure.
   • Nome del cluster: immettere un nome per il cluster.
   • Località : posizione in cui verrà distribuito il cluster.
   • Versione di Cassandra: versione di Apache Cassandra che verrà distribuita.
   • Extention : estensioni che verranno aggiunte, incluso l'indice Cassandra Lucene.
   • Password iniziale dell'amministratore di Cassandra: password usata per creare il cluster.
   • Confermare la password amministratore di Cassandra: immettere nuovamente la password.
   • Rete virtuale: selezionare un Rete virtuale di uscita e una subnet oppure crearne uno nuovo.
   • Assegnare ruoli: Rete virtuale richiedono autorizzazioni speciali per consentire la distribuzione dei cluster Cassandra gestiti. Mantenere questa casella selezionata se si crea un nuovo Rete virtuale o si usa un Rete virtuale esistente senza autorizzazioni applicate. Se si usa una rete virtuale in cui è già stata distribuita Istanza gestita di SQL di Azure cluster Cassandra, deselezionare questa opzione.

   

   Suggerimento

   Se si usa 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 seguenti necessari per il corretto funzionamento di 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
   • Pianificazione strategia eventi: strategia da usare dal cluster per gli eventi pianificati.

   Suggerimento

   • StopANY indica l'arresto di qualsiasi nodo quando è presente una pianificazione anche per il nodo.
   • StopByRack indica solo il nodo di arresto in un determinato rack per un determinato evento pianificato, ad esempio se due o più eventi sono pianificati per i nodi in rack diversi contemporaneamente, verranno arrestati solo i nodi in un rack, mentre gli altri nodi in altri rack vengono ritardati.

5. Selezionare quindi la scheda Data center (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

   È stata introdotta la memorizzazione nella 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 a elevato utilizzo 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 memorizzazione nella cache write-through è disponibile in anteprima pubblica. Questa funzionalità viene fornita senza un 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. dei 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 lo SKU selezionato o la capacità non è disponibile in tutte le zone.

7. Selezionare quindi Rivedi e crea crea>

   Nota

   La creazione del 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 per visualizzarli:

   

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 Scale pulsante:

Scalabilità orizzontale

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

Scalabilità verticale

Per aumentare le dimensioni dello SKU per i nodi, selezionare dall'elenco Sku Size a discesa. 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 scalabilità è stata completata, ciò non significa che tutti i nodi abbiano aggiunto l'anello Cassandra. I nodi verranno completamente commissionati quando tutti visualizzano lo stato "integro" e lo stato del data center legge "succeeded".

Aggiungere un data center

1. Per aggiungere un altro data center, fare clic sul pulsante Aggiungi 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 della 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 di istanza gestita. Vedere questo articolo per informazioni su come eseguire il peering di reti virtuali usando portale di Azure. È anche necessario assicurarsi di aver applicato il ruolo appropriato alla rete virtuale prima di tentare di 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>
   

2. Compilare i campi appropriati:

   • Nome del data center: nell'elenco a discesa selezionare la sottoscrizione di Azure.
   • Zona di disponibilità: selezionare questa casella se si vuole abilitare le zone di disponibilità in questo data center.
   • Località : posizione in cui verrà distribuito il data center.
   • Dimensioni SKU: scegliere tra le dimensioni disponibili dello SKU della macchina virtuale.
   • No. dei 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 un Rete virtuale di uscita e una subnet.

   

   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, è necessario assicurarsi che sia presente la connettività tra le subnet di destinazione in cui verranno distribuiti i data center. È anche necessario applicare il ruolo appropriato alla rete virtuale per consentire la distribuzione (vedere sopra).

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 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 verranno 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, è necessario eseguire rebuild per replicare i dati cronologici. 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 dell'applicazione di scrivere nel nuovo data center fino a quando non sono state applicate modifiche alla replica keyspace. In caso contrario, la ricompilazione non funzionerà e sarà necessario creare una richiesta di supporto in modo che il team possa essere eseguito repair per conto dell'utente.

Aggiornare la configurazione di Cassandra

Il servizio consente l'aggiornamento alla 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:

1. Trova Cassandra Configuration in impostazioni. Evidenziare il data center di cui si vuole modificare la configurazione e fare clic su Aggiorna:

   

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

   

3. Al termine dell'aggiornamento, i valori sottoposti a override verranno visualizzati nel Cassandra Configuration riquadro:

   

   Nota

   Nel portale 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. Vedere qui per le impostazioni di Cassandra v3.11 e qui per 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
   • autorizzatore
   • 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 4.1, 5.0 e Turnkey Version Aggiornamenti sono disponibili in anteprima pubblica. Queste funzionalità vengono fornite senza un contratto di servizio e non è consigliabile 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 Resource Manager.

1. Trovare il Update pannello nella scheda Panoramica

   

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

   Avviso

   Non ignorare le versioni. È consigliabile aggiornare 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. L'uso della funzionalità di replica chiavi in mano, la configurazione e la gestione dei cluster in più aree è diventata più accessibile, consentendo un'integrazione e un funzionamento più uniformi in 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

• Nessuno: la replica automatica è impostata su nessuno.
• SystemKeyspaces: replica automaticamente tutti i keyspace di sistema (system_auth, system_traces, system_auth)
• AllKeyspaces: replica automaticamente tutti gli spazi chiave e 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 verrà 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, possono essere inclusi negli spazi chiave tramite 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 keyspaces 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 eseguirli nodetool rebuild manualmente nel cluster Azure Istanza gestita for Apache Cassandra.

Annullare l'allocazione del cluster

1. Per gli ambienti non di produzione, è possibile sospendere/annullare l'allocazione delle risorse nel cluster per evitare che vengano addebitati costi per l'archiviazione( si continuerà a essere addebitati i costi per l'archiviazione). Modificare prima il tipo di cluster in NonProduction, quindi deallocate.

Avviso

Non eseguire alcuna operazione di scrittura o schema durante l'annullamento dell'allocazione. Ciò 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 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.

Connessione al cluster

Azure Istanza gestita per Apache Cassandra non crea nodi con indirizzi IP pubblici, quindi per connettersi al cluster Cassandra appena creato, sarà necessario creare un'altra risorsa all'interno della rete virtuale. Potrebbe trattarsi di un'applicazione o di 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 usando 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, 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

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 di 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 Istanza gestita di Azure per cluster Apache Cassandra usando portale di Azure. È ora possibile iniziare a usare il cluster:

Distribuire un cluster Apache Spark gestito con Azure Databricks