© Excellent backgrounds/Shutterstock.com
Konsistente Behandlung der Daten im Fall eines Cluster-Splits

Cluster-Handling im Fehlerfall


Sofern alle Nodes in einem Cluster korrekt verbunden sind, werden alle Kopien eines Eintrags konsistent behandelt. Im Fall eines Netzwerkfehlers oder von Ausfällen von Nodes ist dies aber nicht sichergestellt. Entsprechend des CAP-Theorems [1] ist es nicht möglich, gleichzeitig die Verfügbarkeit und die Konsistenz zu gewährleisten. In diesem Artikel stelle ich vor, wie mit dem Partition Handling entschieden werden kann, ob die Konsistenz Vorrang hat, und welche Auswirkungen das auf die Anwendung hat.

In einer produktiven Umgebung ist es wünschenswert, dass Probleme wie Abstürze, Strom- oder Netzwerkausfall und Ressourcenengpässe nicht vorkommen. Allerdings sollte man immer einen Plan B für solche Situationen haben. Mit dem hier vorgestellten Feature ist es möglich, pro Cache festzulegen, ob im Fall unerwarteter Ausfälle einzelner Nodes die Verfügbarkeit des Caches eingeschränkt wird, um die Konsistenz der Daten zu gewährleisten. Allerdings erfordert das unter Umständen Anpassungen in der Anwendung, um auf die dann geworfene Exception zu reagieren.

Verhalten bis Infinispan 6/JDG 6.3

Bis zu diesen Versionen wurden im Fall von Clusterproblemen keine besonderen Aktionen gestartet. Das führte dazu, dass in den Partitionen die Daten unabhängig voneinander geändert werden konnten und bei einem anschließenden Merge dadurch Inkonsistenzen entstanden.

Nach einem Split – auch Split Brain genannt – wurde in jedem einzelnen Teil – auch Partition genannt – der Cache neu organisiert. Bei einem Cache im Mode Distributed wurde der ConsistentHash neu berechnet und entsprechend der Anzahl von Kopien numOwners wurden die Einträge repliziert. Damit sind eventuell einige Einträge in der einen Partition nicht mehr vorhanden, andere sind jetzt in mehreren Partitions unabhängig voneinander gespeichert. Im Fall eines Merge von Partitions wird anhand des dann neu berechneten ConsistentHash ein Eintrag auf allen Nodes gelöscht, wo dieser nicht mehr benötigt wird. Dadurch kommt es vor, dass ein eigentlich aktueller Eintrag entfernt wird oder mehrere inkonsistente Einträge im Cache verbleiben.

Für einen Cache im Mode Replicated wird keine Umverteilung vorgenommen, die Einträge verbleiben so wie vor dem Merge, und damit sind die Einträge, die während des Splits geändert wurden, so lange unterschiedlich, bis sie nochmals geändert oder gelöscht werden. Einträge, die während des Splits gelöscht wurden, können nach dem Merge als verwaiste Einträge auf manchen Knoten verbleiben.

Verhalten ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang