Сluster-Neuaufbau
Der Storage-Cluster ist selbstheilend. Wenn ein Knoten oder Laufwerk ausfällt, versucht der Cluster, die verlorenen Daten automatisch wiederherzustellen – also sich neu aufzubauen.
Voraussetzungen für den Neuaufbau
Damit ein Cluster sich selbst neu aufbauen kann, muss er Folgendes haben:
-
So viele intakte Knoten, wie vom Redundanzmodus benötigt werden
Betrachten wir folgendes Beispiel: In einem Cluster, der im 5+2-Lösch-Codierungsmodus arbeitet und sieben Knoten (also das Minimum) aufweist, wird jedes Replikat von Benutzerdaten zur Erreichung der Redundanz auf jeden der 5+2 Knoten verteilt. Wenn ein oder zwei Knoten ausfallen, gehen zwar keine Benutzerdaten verloren, aber der Cluster ist beeinträchtigt und wird sich erst dann wieder neu aufbauen können, wenn erneut mindestens sieben Knoten intakt sind (bis Sie die fehlenden Knoten wieder hinzugefügt haben). Zum Vergleich: bei einem Cluster mit zehn Knoten, der im 5+2 Lösch-Codierungsmodus arbeitet, wird jedes Replikat der Benutzerdaten zufällig auf 5+2 Knoten (von 10) verteilt, um die Belastung der Chunck-Services auszugleichen. Hier können bis zu drei Knoten ausfallen und der Cluster hat noch genügend Knoten, um sich selbst wieder aufbauen zu können.
-
Genügend freier Speicherplatz, um so viele Daten aufzunehmen, wie jeder einzelne Knoten speichern kann
Betrachten wir folgendes Beispiel: In einem Cluster mit zehn 10-TB-Knoten sollten auf jedem Knoten mindestens 1 TB frei bleiben. Wenn hier ein Knoten ausfällt, können dessen Daten (die 9 TB) auf den verbliebenen neun Knoten wieder aufgebaut werden. Wenn ein Cluster jedoch zehn 10-TB-Knoten sowie einen 20-TB-Knoten hat, sollten auf den kleineren Knoten je mindestens 2 TB frei bleiben, falls der größte Knoten einmal ausfällt. Auf dem größten Knoten sollten 1 TB frei bleiben.
Der Neuaufbau-Prozess
Der Neuaufbau-Prozess besteht aus mehreren Schritten. Jeder CS sendet alle 5 Sekunden eine Heartbeat-Benachrichtigung an einen MDS. Wenn die Heartbeat-Benachrichtigung nicht gesendet wird, wird der CS zuerst als inaktiv eingestuft und der MDS informiert alle Cluster-Komponenten, damit aufzuhören, Operationen mit ihren Daten anzufordern. Wenn der CS über 15 Minuten keine Heartbeat-Benachrichtigung sendet, stuft der MDS den CS als offline ein und beginnt mit dem Cluster-Neuaufbau. Bei diesem Prozess ermittelt der MDS solche Chunck-Services (CSs), die über keine Replikate der verlorenen Daten verfügen, und stellt die entsprechenden Daten – ein Replikat nach dem anderen – folgendermaßen wieder her:
- Wenn Replikation verwendet wird, werden die vorhandenen Replikate eines heruntergestuften Chunks gesperrt (damit alle Replikate identisch bleiben) und wird ein Replikat zu dem neuen CS kopiert. Sollte zu diesem Zeitpunkt ein Client einige der Daten lesen müssen, die bisher noch nicht neu aufgebaut wurden, so wird eines der verbliebenen Replikate dieser Daten gelesen.
- Wenn Lösch-Codierung (Englisch: Erasure Coding) verwendet wird, fordert der neue CS alle verbliebenen Datenteilstücke an, um die fehlenden neu aufzubauen. Sollte zu diesem Zeitpunkt ein Client einige der Daten lesen müssen, die bisher noch nicht neu aufgebaut wurden, werden diese Daten außer der Reihe neu aufgebaut und dann gelesen.
Diese Selbstreparatur erfordert mehr Netzwerkverkehr und höhere CPU-Ressourcen, wenn die Replikation verwendet wird. Auf der anderen Seite ist der Neuaufbau mit Lösch-Codierung langsamer.
Wenn ein Knoten oder ein Laufwerk während der Wartung offline geht, wird die Selbstreparatur des Clusters verzögert, um Cluster-Ressourcen zu sparen. Der vorgegebene Verzögerungszeit beträgt 30 Minuten. Sie können den Wert anpassen, indem Sie den Parameter mds.wd.offline_tout_mnt
(in Millisekunden) festlegen – und zwar über den Befehl vstorage -c <cluster_name> set-config
.
Empfehlungen für den Cluster-Neuaufbau
Zwei Empfehlungen, die helfen, Belastungen durch einen Neuaufbau zu vermeiden:
- Um einen möglichen Neuaufbau zu vereinfachen, sollten Sie auf allen Knoten gleich viele Festplatten mit gleicher Kapazität verwenden.
- Ein Neuaufbau-Prozess erhöht die Netzwerklast und die Latenzzeit von Lese- und Schreiboperationen. Je höher die Netzwerkbandbreite eines Clusters ist, desto schneller wird der Neuaufbau abgeschlossen und die Netzwerklast wieder gesenkt.