Operazioni di gestione in Azure Istanza gestita per Apache Cassandra

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. Questo articolo definisce le operazioni e le funzionalità di gestione fornite dal servizio. Illustra anche la separazione delle responsabilità tra il team supporto tecnico di Azure e i clienti quando si mantengono cluster ibridi.

Compattazione

  • Esistono diversi tipi di compattazione. Attualmente si esegue una compattazione secondaria tramite riparazione (vedere Manutenzione). Questa operazione esegue una compattazione ad albero Merkle, che è un tipo speciale di compattazione.
  • A seconda della strategia di compattazione impostata nella tabella usando CQL (ad esempio WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), Cassandra compatta automaticamente quando la tabella raggiunge una dimensione specifica. È consigliabile selezionare attentamente una strategia di compattazione per il carico di lavoro e non eseguire compattazioni manuali all'esterno della strategia.

Applicazione di patch

  • Le patch a livello di sistema operativo vengono eseguite automaticamente a una frequenza di circa 2 settimane.

  • Le patch a livello di software Apache Cassandra vengono eseguite quando vengono identificate vulnerabilità di sicurezza. La frequenza di applicazione delle patch può variare.

  • Durante l'applicazione di patch, i computer vengono riavviati un rack alla volta. Non è consigliabile riscontrare alcuna riduzione delle prestazioni sul lato applicazione, purché non venga usata l'impostazione QUORUM ALL e il fattore di replica sia 3 o superiore.

  • La versione in Apache Cassandra è nel formato X.Y.Z. È possibile controllare manualmente la distribuzione delle versioni principali (X) e secondarie (Y) tramite gli strumenti di servizio. Mentre le patch Cassandra (Z) che possono essere necessarie per tale combinazione di versione principale/secondaria vengono eseguite automaticamente.

Nota

Il servizio supporta attualmente Le versioni 3.11 e 4.0 di Cassandra. Entrambe le versioni sono disponibili a livello generale. Vedere la guida introduttiva all'interfaccia della riga di comando di Azure (passaggio 5) per specificare la versione di Cassandra durante la distribuzione del cluster.

Gestione

  • Il ripristino nodetool viene eseguito automaticamente dal servizio usando un nuovo modello. Questo strumento viene eseguito una volta alla settimana. È possibile disabilitarla se si usa il proprio servizio per una distribuzione ibrida.

  • Il monitoraggio dell'integrità dei nodi è costituito da:

    • Monitoraggio attivo dell'appartenenza di ogni nodo nell'anello Cassandra.
    • Rilevamento automatico e risoluzione automatica dei problemi di infrastruttura, ad esempio macchine virtuali, rete, archiviazione, Linux e errori software di supporto.
    • Monitoraggio attivo della CPU, del disco, della perdita del quorum e di altri problemi relativi alle risorse.
    • L'attivazione automatica dei nodi non riusciti, laddove possibile, e l'attivazione manuale dei nodi in risposta agli avvisi generati automaticamente.

Supporto

Azure Istanza gestita per Apache Cassandra offre un contratto di servizio per la disponibilità dei data center in un cluster gestito. Se si verificano problemi con l'uso del servizio, inviare una richiesta di supporto nel portale di Azure.

I vantaggi del supporto includono:

  • Singolo punto di contatto per i problemi dell'infrastruttura Cassandra: non è necessario generare casi di supporto con i team IaaS (disco, calcolo, rete) separatamente.
  • Consulenza pro-attiva tramite posta elettronica su colli di bottiglia prestazioni, ridimensionamento e altri problemi relativi ai vincoli di risorse.
  • Copertura del supporto 24x7, inclusi gli eventi imprevisti generati automaticamente per eventuali gravi problemi di interruzione.
  • Supporto delle patch approvate dalla community (vedere Applicazione di patch).
  • Supporto del team di progettazione di Java JDK/JVM interno.
  • Supporto del sistema operativo Linux con la sicurezza della supply chain del software.

Importante

Verranno esaminati e diagnosticati eventuali problemi segnalati tramite un caso di supporto e verranno risolti o mitigati laddove possibile. Tuttavia, si è responsabili di qualsiasi utilizzo del livello di configurazione di Apache Cassandra che causa problemi di CPU, disco o rete.

Esempi di tali problemi includono:

  • Operazioni di query inefficienti.
  • Velocità effettiva che supera la capacità.
  • Inserimento di dati che superano la capacità di archiviazione.
  • Impostazioni di configurazione keyspace non corrette.
  • Modello di dati insufficiente o strategia della chiave di partizione.

Nel caso in cui si esamini un caso di supporto e si scopra che la causa radice del problema è a livello di configurazione di Apache Cassandra (e non gli aspetti sottostanti a livello di piattaforma gestiti), verranno comunque fornite raccomandazioni e indicazioni sulla correzione o la mitigazione (quando possibile), prima di chiudere il caso.

È consigliabile abilitare le metriche e/o acquisire familiarità con l'integrazione di Monitoraggio di Azure per evitare problemi comuni a livello di applicazione/configurazione in Apache Cassandra, ad esempio quelli precedenti.

Avviso

Azure Istanza gestita per Apache Cassandra è anche possibile eseguire nodetool i comandi e sstable per l'amministrazione di routine DBA. Vedere qui l'articolo. Alcuni di questi comandi possono destabilizzare il cluster cassandra e devono essere eseguiti con attenzione e dopo essere stati testati in ambienti non di produzione. Se possibile, è necessario distribuire prima un'opzione --dry-run . Microsoft non può offrire alcun contratto di servizio o supporto per problemi relativi all'esecuzione di comandi che modificano la configurazione e/o le tabelle predefinite del database.

Backup e ripristino

I backup degli snapshot sono abilitati per impostazione predefinita e vengono eseguiti ogni 24 ore. I backup vengono archiviati in un account interno Archiviazione BLOB di Azure e vengono conservati per un massimo di 2 giorni (48 ore). Non sono previsti costi per i backup iniziali di 2. Vengono addebitati backup aggiuntivi. Vedere i prezzi. Per modificare l'intervallo di backup o il periodo di conservazione, è possibile modificare i criteri nel portale:

Screenshot of backup schedule configuration page.

Per eseguire il ripristino da un backup esistente, inviare una richiesta di supporto nel portale di Azure. Quando si invia il caso di supporto, è necessario:

  1. Specificare l'ID di backup dal portale per il backup che si vuole ripristinare. Questo è disponibile nel portale:

    Screenshot of backup schedule configuration page highlighting backup ID.

  2. Se il ripristino dell'intero cluster non è necessario, specificare il keyspace e la tabella (se applicabile) che devono essere ripristinati.

  3. Consigliare se si vuole ripristinare il backup nel cluster esistente o in un nuovo cluster.

  4. Se si vuole eseguire il ripristino in un nuovo cluster, è prima necessario creare il nuovo cluster. Assicurarsi che il cluster di destinazione corrisponda al cluster di origine in termini di numero di data center e che il data center corrispondente abbia lo stesso numero di nodi. È anche possibile decidere se mantenere le credenziali (nome utente/password) nel nuovo cluster di destinazione o consentire il ripristino per eseguire l'override di nome utente/password con ciò che è stato originariamente creato.

  5. È anche possibile decidere se mantenere system_auth il keyspace nel nuovo cluster di destinazione o consentire al ripristino di sovrascriverlo con i dati dal backup. Il system_auth keyspace in Cassandra contiene dati di autorizzazione e autenticazione interna, inclusi ruoli, autorizzazioni del ruolo e password. Si noti che il processo di ripristino predefinito sovrascrive il system_auth keyspace.

Nota

Il tempo necessario per rispondere a una richiesta di ripristino dal backup dipende dalla gravità del caso di supporto generato (e dal contratto di servizio corrispondente per il tempo di risposta) e dalla quantità di dati da ripristinare. Tuttavia, non viene fornito un contratto di servizio per il tempo necessario per completare il ripristino, perché dipende molto dal volume di dati da ripristinare.

Avviso

I backup sono destinati a scenari di eliminazione accidentale e non sono con ridondanza geografica. Non sono pertanto consigliate per l'uso come strategia di ripristino di emergenza in caso di interruzione totale a livello di area. Per evitare interruzioni a livello di area, è consigliabile una distribuzione in più aree. Vedere la guida introduttiva per le distribuzioni in più aree.

Sicurezza

Azure Istanza gestita per Apache Cassandra offre numerosi controlli e funzionalità di sicurezza espliciti predefiniti:

  • Immagini di macchine virtuali Linux con protezione avanzata con una supply chain controllata.
  • Monitoraggio common vulnerability & exposure (CVE) a livello di sistema operativo.
  • Rotazione dei certificati per il software Apache Cassandra e Prometheus ospitato nel Macchine virtuali gestito.
  • Analisi attiva delle vulnerabilità.
  • Analisi virus attiva.
  • Procedure di codifica sicure.

Per altre informazioni sulle funzionalità di sicurezza, vedere l'articolo qui.

Supporto ibrido

Quando viene configurato un cluster ibrido , le operazioni di ripristino automatizzate in esecuzione nel servizio offrono vantaggi per l'intero cluster. Sono inclusi i data center di cui non viene effettuato il provisioning dal servizio. Al di fuori di questo, è responsabilità dell'utente mantenere il data center locale o ospitato esternamente.

Passaggi successivi

Introduzione a una delle guide introduttive: