Procedure consigliate per la disponibilità elevata e il ripristino di emergenza

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.

Apache Cassandra è un'ottima scelta per la creazione di applicazioni altamente resilienti a causa della natura distribuita e dell'architettura masterless. Qualsiasi nodo del database può fornire esattamente la stessa funzionalità di qualsiasi altro nodo, contribuendo alla robustezza e alla resilienza di Cassandra. Questo articolo fornisce suggerimenti su come ottimizzare la disponibilità elevata e su come affrontare il ripristino di emergenza.

RPO e RTO

RPO (obiettivo del punto di ripristino) e RTO (obiettivo del tempo di ripristino), in genere saranno bassi (quasi zero) per Apache Cassandra, purché siano disponibili:

• Una distribuzione in più aree con replica tra aree e un fattore di replica pari a 3.
• Zone di disponibilità abilitate (selezionare l'opzione quando si crea un cluster nel portale o tramite l'interfaccia della riga di comando di Azure).
• Failover a livello di applicazione configurato usando i criteri di bilanciamento del carico nel driver client e/o nel failover a livello di bilanciamento del carico tramite Gestione traffico/Frontdoor di Azure.

L'obiettivo RTO ("per quanto tempo si è inattivi in un'interruzione") sarà basso perché il cluster sarà resiliente in entrambe le zone e nelle aree e perché Apache Cassandra è un sistema a tolleranza di errore elevato e senza master (tutti i nodi possono scrivere) per impostazione predefinita. L'RPO ("la quantità di dati che è possibile perdere in un'interruzione") sarà bassa perché i dati verranno sincronizzati tra tutti i nodi e i data center, quindi la perdita di dati in un'interruzione sarebbe minima.

Nota

Non è teoricamente possibile ottenere sia RTO=0 che RPO=0 per teorema cap. Sarà necessario valutare il compromesso tra coerenza e disponibilità/prestazioni ottimali. Questo aspetto sarà diverso per ogni applicazione. Ad esempio, se l'applicazione è in lettura pesante, potrebbe essere preferibile gestire una maggiore latenza delle scritture tra aree per evitare la perdita di dati (favorendo la coerenza). Se la replica delle app è pesante per la scrittura e per un budget di latenza ristretto, il rischio di perdere alcune delle scritture più recenti in un'interruzione principale a livello di area potrebbe essere accettabile (favorendo la disponibilità).

Zone di disponibilità

L'architettura masterless di Cassandra offre la tolleranza di errore fin dall'inizio e Azure Istanza gestita for Apache Cassandra offre il supporto per le zone di disponibilità nelle aree selezionate per migliorare la resilienza a livello di infrastruttura. Dato un fattore di replica pari a 3, il supporto della zona di disponibilità garantisce che ogni replica si trova in una zona di disponibilità diversa, impedendo così un'interruzione di zona che influisca sul database o sull'applicazione. È consigliabile abilitare le zone di disponibilità laddove possibile.

Ridondanza in più aree

L'architettura di Cassandra, abbinata al supporto delle zone di disponibilità di Azure, offre un certo livello di tolleranza di errore e resilienza. È tuttavia importante considerare l'impatto delle interruzioni a livello di area per le applicazioni. È consigliabile distribuire cluster in più aree per proteggersi dalle interruzioni a livello di area. Anche se sono rari, l'impatto potenziale è grave.

Per la continuità aziendale, non è sufficiente solo rendere il database in più aree. Anche altre parti dell'applicazione devono essere distribuite nello stesso modo tramite la distribuzione o con meccanismi adeguati per il failover. Se gli utenti sono distribuiti in molte posizioni geografiche, una distribuzione di data center in più aree per il database offre il vantaggio aggiuntivo di ridurre la latenza, poiché tutti i nodi in tutti i data center nel cluster possono quindi servire sia letture che scritture dall'area più vicina. Tuttavia, se l'applicazione è configurata per essere "attiva-attiva", è importante considerare il modo in cui il teorema CAP si applica alla coerenza dei dati tra repliche (nodi) e i compromessi necessari per fornire disponibilità elevata.

In termini di teorema CAP, Cassandra è per impostazione predefinita un sistema di database AP (partizione a tolleranza di partizione disponibile), con coerenza altamente ottimizzabile. Per la maggior parte dei casi d'uso, è consigliabile usare local_quorum per le letture.

• In attivo-passivo per le scritture esiste un compromesso tra affidabilità e prestazioni: per l'affidabilità è consigliabile QUORUM_EACH, ma per la maggior parte degli utenti LOCAL_QUORUM o QUORUM è un buon compromesso. Si noti tuttavia che, in caso di interruzione a livello di area, alcune scritture potrebbero andarsi perse in LOCAL_QUORUM.
• Nel caso di un'applicazione in esecuzione in parallelo QUORUM_EACH le scritture sono preferibili per la maggior parte dei casi per garantire la coerenza tra i due data center.
• Se l'obiettivo è quello di favorire la coerenza (RPO inferiore) anziché la latenza o la disponibilità (RTO inferiore), deve essere riflessa nelle impostazioni di coerenza e nel fattore di replica. Come regola generale, il numero di nodi quorum necessari per una lettura più il numero di nodi quorum necessari per una scrittura deve essere maggiore del fattore di replica. Ad esempio, se si ha un fattore di replica pari a 3 e quorum_one in letture (un nodo), è necessario eseguire quorum_all nelle scritture (tre nodi), in modo che il totale di 4 sia maggiore del fattore di replica di 3.

Replica

È consigliabile keyspaces controllare e le relative impostazioni di replica di volta in volta per assicurarsi che sia stata configurata la replica necessaria tra data center. Nelle prime fasi di sviluppo, è consigliabile testare che tutto funzioni come previsto eseguendo test semplici usando cqlsh. Ad esempio, inserendo un valore durante la connessione a un data center e leggendolo dall'altro.

In particolare, quando si configura un secondo data center in cui un data center esistente dispone già di dati, è importante determinare che tutti i dati sono stati replicati e il sistema è pronto. È consigliabile monitorare lo stato di avanzamento della replica tramite i comandi dell'amministratore di database con nodetool netstats. Un approccio alternativo consiste nel contare le righe in ogni tabella, ma tenere presente che con le dimensioni dei Big Data, a causa della natura distribuita di Cassandra, questo può dare solo una stima approssimativa.

Bilanciamento del costo del ripristino di emergenza

Se l'applicazione è "attivo-passivo", è comunque consigliabile distribuire la stessa capacità in ogni area in modo che l'applicazione possa eseguire immediatamente il failover in un data center "hot standby" in un'area secondaria. In questo modo non si verifica alcuna riduzione delle prestazioni in caso di interruzione a livello di area. La maggior parte dei driver client Cassandra offre opzioni per avviare il failover a livello di applicazione. Per impostazione predefinita, presuppongono un'interruzione a livello di area significa che anche l'applicazione è inattiva, nel qual caso il failover dovrebbe verificarsi a livello di servizio di bilanciamento del carico.

Tuttavia, per ridurre il costo del provisioning di un secondo data center, è preferibile distribuire uno SKU più piccolo e un minor numero di nodi nell'area secondaria. Quando si verifica un'interruzione, la scalabilità verticale e orizzontale è resa più semplice in Azure Istanza gestita per Apache Cassandra. Durante il failover delle applicazioni nell'area secondaria, è possibile aumentare manualmentele prestazioni e aumentare le prestazioni dei nodi nel data center secondario. In questo caso, il data center secondario funge da warm standby a costi inferiori. L'esecuzione di questo approccio dovrebbe essere bilanciata rispetto al tempo necessario per ripristinare la capacità completa del sistema in caso di interruzione. È importante testare e praticare ciò che accade quando un'area viene persa.

Nota

Il ridimensionamento dei nodi è molto più veloce rispetto all'aumento del numero di istanze. Tenere presente questo aspetto quando si valuta il bilanciamento tra la scala verticale e orizzontale e il numero di nodi da distribuire nel cluster.

Pianificazioni di backup

I backup sono automatici in Azure Istanza gestita per Apache Cassandra, ma è possibile scegliere una pianificazione personalizzata per i backup giornalieri. È consigliabile scegliere i tempi con meno carico. Anche se i backup sono configurati per l'utilizzo solo della CPU inattiva, possono in alcune circostanze attivare le compattazioni in Cassandra, il che può causare un aumento dell'utilizzo della CPU. Le compattazioni possono verificarsi in qualsiasi momento con Cassandra e dipendono dal carico di lavoro e dalla strategia di compattazione scelta.

Importante

L'intenzione dei backup è esclusivamente ridurre la perdita accidentale dei dati o il danneggiamento dei dati. Non è consigliabile eseguire i backup come strategia di ripristino di emergenza. I backup non sono con ridondanza geografica e, anche in caso affermativo, il ripristino di un database da backup può richiedere molto tempo. È quindi consigliabile implementare distribuzioni in più aree, insieme all'abilitazione delle zone di disponibilità, ove possibile, per attenuare gli scenari di emergenza e per poter eseguire il ripristino in modo efficace da tali distribuzioni. Ciò è particolarmente importante negli scenari rari in cui non è possibile coprire l'area non riuscita, in cui senza la replica in più aree, è possibile che tutti i dati vadano persi.

Passaggi successivi

In questo articolo sono state illustrate alcune procedure consigliate per la creazione di applicazioni resilienti con Cassandra.

Creare un cluster usando il portale di Azure