Di Ben Slater , Chief Product Officer, Instaclustr.
Spostare una distribuzione live di Apache Cassandra in una nuova posizione? È naturale avere alcune preoccupazioni, ad esempio su come mantenere i cluster Cassandra disponibili al 100% durante tutto il processo. Tuttavia, il fatto è che se l'applicazione è in grado di rimanere online durante le modifiche alle impostazioni di connessione, può rimanere completamente disponibile durante questa transizione. Per maggiore protezione e tranquillità, la tecnica seguente include anche una strategia di ripristino rapido per tornare alla configurazione originale, fino al momento in cui la migrazione non sarà completata.
Ecco un ordine di operazioni consigliato per la migrazione del cluster Cassandra in sette passaggi che eviterà tempi di inattività:
1. Prepara il tuo ambiente esistente.
Prima di tutto, assicurati che la tua applicazione utilizzi una policy di bilanciamento del carico compatibile con i datacenter, oltre a LOCAL_*. Inoltre, controlla che tutti degli spazi delle chiavi che verranno copiati nel nuovo cluster sono impostati per utilizzare NetworkTopologyStrategy come strategia di replica. È inoltre consigliabile che tutti gli spazi delle chiavi utilizzino questa strategia di replica al momento della creazione, poiché modificarla in un secondo momento può diventare complicato.
2. Crea il nuovo cluster.
Ora è il momento di creare il nuovo cluster a cui eseguirai la migrazione. Alcune cose a cui prestare attenzione qui:assicurati che il nuovo cluster e il cluster originale utilizzino la stessa versione di Cassandra e lo stesso nome del cluster. Inoltre, il nuovo nome del centro dati che utilizzi deve essere diverso dal nome del centro dati esistente.
3. Unisciti ai Cluster insieme.
Per fare ciò, innanzitutto apportare le modifiche necessarie alle regole del firewall per consentire l'unione dei cluster, ricordando che potrebbero essere necessarie anche alcune modifiche al cluster di origine. Quindi, modifica i nodi seme del nuovo cluster e avviali. Una volta eseguita questa operazione, il nuovo cluster sarà un secondo data center nel cluster originale.
4. Modifica le impostazioni di replica.
Successivamente, nel cluster esistente, aggiorna le impostazioni di replica per gli spazi delle chiavi che verranno copiati, in modo che i dati vengano ora replicati con il nuovo data center come destinazione.
5. Copia i dati nel nuovo cluster.
Quando i cluster vengono uniti, Cassandra inizierà a replicare le scritture nel nuovo cluster. È ancora necessario, tuttavia, copiare tutti i dati esistenti con la funzione di ricostruzione nodetool. È consigliabile eseguire questa funzione sul nuovo cluster uno o due nodi alla volta, in modo da non sovraccaricare lo streaming del cluster esistente.
6. Cambia i punti di connessione dell'applicazione.
Dopo che tutti gli usi della funzione di ricostruzione sono stati completati, ciascuno dei cluster conterrà una copia completa dei dati migrati, che Cassandra manterrà sincronizzati automaticamente. È giunto il momento di modificare i punti di connessione iniziali della tua applicazione sui nodi nel nuovo cluster. Una volta completato, tutte le letture e le scritture verranno servite dal nuovo cluster e successivamente verranno replicate nel cluster originale. Infine, è intelligente eseguire una funzione di riparazione nel cluster, per garantire che tutti i dati siano stati replicati correttamente dall'originale.
7. Spegni il cluster originale.
Completa il processo con una piccola pulizia post-migrazione, rimuovendo il cluster originale. Innanzitutto, modifica le regole del firewall per disconnettere il cluster originale da quello nuovo. Quindi, aggiorna le impostazioni di replica nel nuovo cluster per interrompere la replica dei dati nel cluster originale. Infine, spegni il cluster originale.
E il gioco è fatto:la tua distribuzione di Apache Cassandra è stata completamente migrata, senza tempi di inattività, a basso rischio e in modo completamente trasparente e trasparente dal punto di vista dei tuoi utenti finali.
Informazioni sull'autore
Ben Slater è Chief Product Officer di Instaclustr, un fornitore di infrastruttura dati open source Apache Cassandra di livello enterprise, in hosting e completamente gestita nel cloud.
