Von Ben Slater , Chief Product Officer, Instaclustr.
Verschieben einer aktiven Apache Cassandra-Bereitstellung an einen neuen Standort? Es ist natürlich, einige Bedenken zu haben, z. B. wie Sie Cassandra-Cluster während des gesamten Prozesses zu 100 % verfügbar halten können. Tatsache ist jedoch, dass, wenn Ihre Anwendung während der Änderungen der Verbindungseinstellungen online bleiben kann, sie während dieses Übergangs vollständig verfügbar bleiben kann. Für zusätzlichen Schutz und Sicherheit beinhaltet die folgende Technik auch eine schnelle Rollback-Strategie, um zu Ihrer ursprünglichen Konfiguration zurückzukehren, bis die Migration abgeschlossen ist.
Hier ist eine empfohlene siebenstufige Cassandra-Cluster-Migrationsreihenfolge, die Ausfallzeiten vermeidet:
1. Bereiten Sie Ihre vorhandene Umgebung vor.
Stellen Sie zunächst sicher, dass Ihre Anwendung eine Rechenzentrums-fähige Lastenausgleichsrichtlinie sowie LOCAL_* verwendet. Überprüfen Sie auch, dass alle der Schlüsselräume, die in den neuen Cluster kopiert werden, sind auf die Verwendung von NetworkTopologyStrategy als Replikationsstrategie eingestellt. Es wird auch empfohlen, dass alle Schlüsselräume diese Replikationsstrategie verwenden, wenn sie erstellt werden, da eine spätere Änderung kompliziert werden kann.
2. Erstellen Sie den neuen Cluster.
Jetzt ist es an der Zeit, den neuen Cluster zu erstellen, zu dem Sie migrieren werden. Hier sind einige Dinge zu beachten:Stellen Sie sicher, dass der neue Cluster und der ursprüngliche Cluster dieselbe Cassandra-Version und denselben Clusternamen verwenden. Außerdem muss sich der neue Rechenzentrumsname, den Sie verwenden, vom Namen des vorhandenen Rechenzentrums unterscheiden.
3. Schließen Sie sich den Clustern gemeinsam an.
Nehmen Sie dazu zunächst alle erforderlichen Änderungen an den Firewall-Regeln vor, damit die Cluster verbunden werden können, und denken Sie daran, dass möglicherweise auch einige Änderungen am Quellcluster erforderlich sind. Ändern Sie dann die Seed-Knoten des neuen Clusters – und starten Sie sie. Sobald dies erledigt ist, wird der neue Cluster ein zweites Rechenzentrum im ursprünglichen Cluster sein.
4. Ändern Sie die Replikationseinstellungen.
Aktualisieren Sie als Nächstes im vorhandenen Cluster die Replikationseinstellungen für die zu kopierenden Schlüsselräume, sodass die Daten jetzt mit dem neuen Rechenzentrum als Ziel repliziert werden.
5. Kopieren Sie die Daten in den neuen Cluster.
Wenn die Cluster zusammengeführt werden, beginnt Cassandra mit der Replikation von Schreibvorgängen in den neuen Cluster. Es ist jedoch immer noch notwendig, alle vorhandenen Daten mit der Rebuild-Funktion von nodetool zu kopieren. Es hat sich bewährt, diese Funktion auf dem neuen Cluster auf einem oder zwei Knoten gleichzeitig auszuführen, um keine überwältigende Streaming-Last auf den vorhandenen Cluster auszuüben.
6. Ändern Sie die Verbindungspunkte der Anwendung.
Nachdem alle Verwendungen der Rebuild-Funktion abgeschlossen sind, enthält jeder der Cluster eine vollständige Kopie der zu migrierenden Daten, die Cassandra automatisch synchron hält. Jetzt ist es an der Zeit, die anfänglichen Verbindungspunkte Ihrer Anwendung auf die Knoten im neuen Cluster umzustellen. Sobald dies abgeschlossen ist, werden alle Lese- und Schreibvorgänge vom neuen Cluster bereitgestellt und anschließend im ursprünglichen Cluster repliziert. Schließlich ist es sinnvoll, eine Reparaturfunktion im gesamten Cluster auszuführen, um sicherzustellen, dass alle Daten erfolgreich vom Original repliziert wurden.
7. Herunterfahren des ursprünglichen Clusters.
Schließen Sie den Vorgang mit einer kleinen Bereinigung nach der Migration ab, indem Sie den ursprünglichen Cluster entfernen. Ändern Sie zunächst die Firewall-Regeln, um den ursprünglichen Cluster vom neuen zu trennen. Aktualisieren Sie dann die Replikationseinstellungen im neuen Cluster, um die Replikation von Daten in den ursprünglichen Cluster zu beenden. Fahren Sie zuletzt den ursprünglichen Cluster herunter.
Und da haben Sie es:Ihre Apache Cassandra-Bereitstellung wurde vollständig migriert, ohne Ausfallzeiten, mit geringem Risiko und auf eine Weise, die aus Sicht Ihrer Endbenutzer völlig nahtlos und transparent ist.
Über den Autor
Ben Slater ist Chief Product Officer bei Instaclustr, einem Anbieter von gehosteter und vollständig verwalteter Apache Cassandra-Open-Source-Dateninfrastruktur für Unternehmen in der Cloud.
