Operazioni di gestione in Istanza gestita di Azure per Apache Cassandra

Articolo
10/16/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, consentendo la massima flessibilità e controllo dove necessario. Questo articolo definisce le operazioni e le funzionalità di gestione fornite dal servizio. Fornisce anche informazioni sulla separazione delle responsabilità tra il team supporto tecnico di Azure e i clienti nella manutenzione di cluster ibridi.

Compattazione

Esistono diversi tipi di compattazione. Attualmente eseguiamo una compattazione secondaria tramite riparazione (vedere Manutenzione). Questa operazione esegue un tipo speciale di compattazione chiamata compattazione ad albero Merkle.
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 appropriata al 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 il sistema individua 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 l’avvio rapido all'interfaccia della riga di comando di Azure (passaggio 5) per specificare la versione di Cassandra durante la distribuzione del cluster.

Gestione

La riparazione nodetool viene eseguita 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 dello stato dei nodi è costituito da:
- Monitoraggio attivo dell'adesione 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 disk, 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 tecnico

L’Istanza gestita di Azure 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, invia una richiesta di supporto nel portale di Azure.

I vantaggi del supporto includono:

Singolo punto di contatto per i problemi dell'infrastruttura Cassandra: non serve generare casi di supporto con i team IaaS (disk, calcolo, rete) separatamente.
Consulenza pro-attiva tramite posta elettronica su colli di bottiglia prestazionali, ridimensionamento e altri problemi relativi ai vincoli delle 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 catena di approvvigionamento del software.

Importante

Verranno esaminati e diagnosticati eventuali problemi segnalati tramite un caso di supporto e verranno risolti o mitigati laddove possibile. Tuttavia, l'utente è responsabile in ultima istanza di qualsiasi utilizzo a livello di configurazione di Apache Cassandra che causi problemi di CPU, disk o rete.

Esempi di questo tipo 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 dovuta ad 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

L’Istanza gestita di Azure per Apache Cassandra è anche possibile eseguire nodetool i comandi e sstable per l'amministrazione di routine DBA. Vedi qui l'articolo. Alcuni di questi comandi possono destabilizzare il cluster cassandra, quindi devono essere eseguiti con attenzione e solo 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 primi 2 backup. Invece i backup aggiuntivi hanno un costo. Vedere i prezzi. Per modificare l'intervallo di backup o il periodo di conservazione, è possibile modificare i criteri nel portale:

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

Specificare l'ID di backup dal portale per il backup che si vuole ripristinare. L’ID può essere trovato nel portale:
Segnalare se il data center di origine è stato eliminato. Questo sarà importante per identificare l'account di backup corretto da cui eseguire il ripristino.
Se il ripristino dell'intero cluster non è necessario, specificare il keyspace e la tabella (se applicabile) che devono essere ripristinati.
Specificare se si vuole ripristinare il backup nel cluster esistente o in un nuovo cluster.
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.
È anche possibile decidere se mantenere il keyspace system_auth nel nuovo cluster di destinazione o consentire al ripristino di sovrascriverlo con i dati dal backup. Il keyspace system_auth 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 keyspace system_auth.

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 forniamo un contratto di servizio per il tempo necessario a completare il ripristino, perché dipende dal volume di dati da ripristinare.

Avviso

I backup sono destinati a scenari di cancellazione accidentale e non hanno una ridondanza geografica. Pertanto non sono consigliate 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

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

Immagini di macchine virtuali Linux con protezione avanzata con una catena di approvvigionamento controllata.
Monitoraggio delle vulnerabilità e delle esposizioni comuni (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 delle vulnerabilità attiva.
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

Inizia oggi stesso con una delle nostre guide di avvio rapido.

Condividi tramite