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

Istanza gestita di Azure per Apache Cassandra è un servizio completamente gestito per cluster Apache Cassandra open source puri. Il servizio consente di eseguire l'override delle configurazioni, a seconda delle esigenze di ogni carico di lavoro, che consente la massima flessibilità e controllo dove necessario.

Apache Cassandra è un'ottima scelta per la creazione di applicazioni altamente resilienti grazie alla natura distribuita e all'architettura peer-to-peer. Qualsiasi nodo nel database può fornire la stessa funzionalità di qualsiasi altro nodo. Questa progettazione contribuisce 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.

Obiettivo del punto di ripristino e obiettivo del tempo di ripristino

Purché siano presenti gli elementi seguenti, l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO) sono in genere bassi, vicini a zero:

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

RTO è per quanto tempo si rimane inattivi durante un'interruzione. È basso perché il cluster è resiliente sia nelle zone che nelle aree. Apache Cassandra è anche un sistema peer-to-peer altamente a tolleranza di errore, in cui tutti i nodi possono scrivere per impostazione predefinita.

RPO è la quantità di dati che è possibile perdere in un'interruzione. È bassa perché i dati vengono sincronizzati tra tutti i nodi e i data center. La perdita di dati in un'interruzione sarebbe minima.

Note

Non è possibile ottenere sia RTO=0 che RPO=0 per teorema CAP. Valutare il compromesso tra coerenza e disponibilità o prestazioni ottimali.

Questo equilibrio è 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, che favorisce la coerenza. Se l'applicazione è ad alta intensità di scrittura con requisiti stringenti di latenza, il rischio di perdere alcune delle scritture più recenti in caso di un'importante interruzione regionale potrebbe essere accettabile, il che favorisce la disponibilità.

Zone di disponibilità

L'architettura peer-to-peer di Cassandra porta la tolleranza di errore da zero. Istanza gestita di Azure per Apache Cassandra offre supporto per le zone di disponibilità nelle aree selezionate. Questo supporto migliora la resilienza a livello di infrastruttura. Per 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. Questo approccio impedisce a un'interruzione di zona di influire sul database o sull'applicazione. Dove possibile, è consigliabile abilitare le zone di disponibilità.

Ridondanza in più aree

L'architettura di Cassandra, abbinata al supporto delle zone di disponibilità di Azure, offre un livello di tolleranza di errore e resilienza. Considerare anche l'impatto delle interruzioni a livello di area per le applicazioni. Per evitare interruzioni a livello di area, è consigliabile distribuire più cluster di aree. Anche se sono rari, l'impatto potenziale è grave.

Per la continuità aziendale, non è sufficiente usare un database a più aree. Anche altre parti della vostra applicazione devono essere distribuite, oppure prevedere meccanismi adeguati per il failover. Se gli utenti vengono distribuiti in molte posizioni geografiche, una distribuzione di data center in più aree per il database offre il vantaggio aggiuntivo di ridurre la latenza. Tutti i nodi in tutti i data center nel cluster possono gestire sia letture che scritture dall'area più vicina.

Se l'applicazione è configurata per essere attiva-attiva, considerare come il teorema CAP si applichi alla coerenza dei dati tra repliche (nodi) e i compromessi richiesti per garantire un'elevata disponibilità.

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

• Nella configurazione attivo-passivo per le operazioni di scrittura, esiste un compromesso tra affidabilità e prestazioni. Per garantire l'affidabilità, è consigliabile QUORUM_EACH, ma per la maggior parte degli utenti LOCAL_QUORUM o QUORUM è un buon compromesso. In caso di interruzione a livello di area, alcune scritture potrebbero essere perse in LOCAL_QUORUM.

• Se un'applicazione viene eseguita in parallelo, sono preferibili scritture QUORUM_EACH nella maggior parte dei casi per garantire la coerenza tra i due data center.

• Se l'obiettivo è quello di favorire la coerenza o un VALORE RPO inferiore, anziché la latenza o disponibilità o un valore RTO inferiore, le impostazioni di coerenza e il fattore di replica devono riflettere questo obiettivo.

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

Note

L'operatore del piano di controllo per Istanza gestita di Azure per Apache Cassandra viene distribuito solo in una singola area. L'area è quella selezionata quando si distribuisce il primo data center. In caso di interruzione totale dell'area, si esegue il commit a un tempo di recupero di 3 ore per il failover del piano di controllo in un'altra area.

Poiché i data center devono continuare a funzionare, questo problema non influisce sul contratto di servizio di disponibilità per il servizio. Durante questo periodo, potrebbe non essere possibile apportare modifiche alla configurazione del database dal portale di Azure o dagli strumenti del provider di risorse.

Replica

Si raccomanda di controllare regolarmente keyspaces e le relative impostazioni di replica per assicurarsi che sia configurata la replica necessaria tra i data center. Nelle prime fasi di sviluppo è consigliabile eseguire test semplici usando cqlsh. Ad esempio, inserire un valore durante la connessione a un data center e leggerlo dall'altro.

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

Bilanciamento del costo del ripristino di emergenza

Se l'applicazione è attiva-passiva, è comunque consigliabile distribuire la stessa capacità in ogni area. Questo approccio consente all'applicazione di eseguire immediatamente il failover in un data center hot standby in un'area secondaria. Se si verifica un'interruzione a livello di area, questo approccio non garantisce una riduzione delle prestazioni. La maggior parte dei driver client Cassandra offre opzioni per avviare il failover a livello di applicazione. Per impostazione predefinita, presuppongono che un'interruzione regionale significhi che anche l'applicazione è inattiva, quindi il failover dovrebbe verificarsi a livello di bilanciatore di carico.

Per ridurre il costo del provisioning di un secondo data center, è consigliabile distribuire uno SKU più piccolo e un minor numero di nodi nell'area secondaria. Quando si verifica un'interruzione, la scalabilità verticale e orizzontale chiavi in mano facilita l'aumento in Istanza Gestita di Azure per Apache Cassandra. Durante il failover delle applicazioni nell'area secondaria, è possibile eseguire lo scale out e lo scale up dei nodi nello scenario del data center secondario. Il data center secondario funge da warm standby a basso costo. Prendere questo approccio deve essere bilanciato rispetto al tempo necessario per ripristinare la capacità completa del sistema in caso di interruzione. È importante testare ciò che accade quando un'area viene persa e fare pratica.

Note

Aumentare la scala dei nodi è molto più veloce rispetto a scalare orizzontalmente. Tenete presente questo fatto quando considerate il bilanciamento tra la scala verticale e orizzontale e il numero di nodi da distribuire nel vostro cluster.

Pianificazioni di backup

I backup sono automatici in Istanza gestita di Azure per Apache Cassandra. È possibile scegliere una pianificazione personalizzata per i backup giornalieri. È consigliabile scegliere gli orari meno sovraccaricati. Anche se i backup sono configurati per usare solo la CPU inattiva, in alcune circostanze possono attivare compattazioni in Cassandra, con un conseguente aumento dell'utilizzo della CPU. Le compattazioni possono verificarsi in qualsiasi momento con Cassandra. Dipendono dal carico di lavoro e dalla strategia di compattazione scelta.

Importante

Lo scopo 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 ridondanti a livello geografico. Anche in caso affermativo, il ripristino di un database da backup può richiedere molto tempo. Raccomandiamo vivamente distribuzioni in più regioni, insieme all'abilitazione delle zone di disponibilità, ove possibile, per mitigare gli scenari disastrosi e per essere in grado di riprendersi efficacemente da essi. Questo approccio è particolarmente importante negli scenari rari in cui non è possibile recuperare l'area non riuscita. Senza replica in più aree, tutti i dati potrebbero andarsi persi.

Passo successivo

Creare un cluster con il portale di Azure