Elastic Snapshots versus Cross Cluster Replication

Oftmals fällt es Elastic Nutzern schwer, sich zwischen Elastic Snapshots und Cross Cluster Replication zu entscheiden. Diese Entscheidung fällt in der Regel während der Business Continuity Planung. Schauen wir uns kurz an, was beide leisten, welche Vor- und Nachteile sie haben und was man wann verwenden sollte.

Snapshots

Snapshots sind der Sicherungsmechanismus von Elastic. Sie führen geplante (inkrementelle oder vollständige) Backups wie Indices, data-streams et cetera durch. Diese Backups können dann bei einer Katastrophe wie einem Hardwareausfall oder bei menschlichem Versagen (versehentliches Löschen wichtiger Daten) verwendet werden, um die Daten wieder herzustellen. Sie sind auch während eines Elastic Upgrades nützlich: für ein Rollback, falls das Upgrade fehlschlägt. Zudem gibt es auch weitere Funktionen wie Searchable Snapshots. 

Snapshots können beispielsweise in folgenden Systemen gespeichert werden:

• Cloud storages (AWS, GCS, Azure)
• Shared file system 
• HDFS

Cross Cluster Replication

Mit Cross Cluster Replication (CCR) werden Indizes von einem Elastic Cluster auf ein oder mehrere andere Elastic Cluster repliziert. Das „andere“ Elastic Cluster könnte sich hier in einem anderen Datencenter befinden. Wenn das primäre Rechenzentrum ausfällt (ein typisches DR-Szenario), liefert die Suche aus dem replizierten Cluster (dem sogenannten „Follower“) weiterhin Suchergebnisse und bietet somit Hochverfügbarkeit.

Snapshots vs. CCR

Snapshots und CCR sind tiefgreifende Themen, weshalb wir hier nicht auf ihre vollen Funktionen eingehen werden. Unser Ziel hier ist ein anderes. Wir erörtern hier, welche Lösung Sie verwenden sollten, um die Ausfallsicherheit Ihrer Daten zu gewährleisten.

Je nachdem, wie der Snapshot und das Snapshot Lifecycle Management (SLM) konzipiert sind, bieten sie Hochverfügbarkeit. Die verzögerten Backups können und werden aber höchstwahrscheinlich zu Datenverlusten führen, da die Backups nicht in Realtime erfolgen. Die Minimierung solcher potenziellen Datenverluste während der Datenwiederherstellung ist eine Frage des SLM-Designs. 

Auf der anderen Seite bietet CCR nahezu eine Echtzeit-Synchronisation zwischen Leader-Index und Follower(n), was eine effektive Hochverfügbarkeit und vollständige Datenwiederherstellung ermöglicht. Der Nachteil dabei ist, dass das Leader-Cluster nun durch zusätzliche Leseoperationen fast genauso stark belastet wird wie durch die eigentlichen Schreiboperationen. Das liegt daran, dass jedes neue Schreiben/Aktualisieren/Löschen auf dem Leader Cluster mit den Follower(n) synchronisiert wird.

Fazit:

Als Gewinner kann natürlich keines der Features ermittelt werden; oder beide, je nachdem, wie man die Dinge sieht. Der richtige Weg sollte sein, das Beste aus beiden Welten zu verwenden, indem man die Dinge aus einer neuen Perspektive sieht und dabei die folgenden Aspekte berücksichtigt:

Das Design der Elastic Replication (Shard-Replica) bildet die erste Verteidigungslinie. Ein gutes Design sollte den Ausfall eines oder mehrerer Elastic Nodes tolerieren.

CCR wäre die zweite Verteidigungslinie. Sie dient neben der Gewährleistung der Ausfallsicherheit zusätzlichen Zwecken, wie der Bereitstellung von Suchergebnissen aus dem nächstgelegenen Elastic Cluster des Datencenters, wodurch die Netzwerklatenz verringert wird.

Snapshots sind die letzte Verteidigungslinie. Sie dienen auch zusätzlichen Zwecken, wie der einzigen Möglichkeit, ein fehlgeschlagenes Elastic-Upgrade zurückzurollen.

Elastic is a trademark of Elasticsearch BV.