Clustering¶
Bemerkung
Bei dieser Funktion handelt es sich derzeit um eine technische Vorschau mit den folgenden vorübergehenden Einschränkungen:
Wenn ein Cluster verloren geht (Quorum verloren), ist die einzige Möglichkeit der Wiederherstellung das Zurücksetzen auf Werkseinstellungen + Wiederherstellung. Stellen Sie sicher, dass Sie häufig Sicherungskopien erstellen. Zukünftige Versionen werden Mittel zur Wiederherstellung von Daten auf der Festplatte enthalten.
Eine aktive/passive Einrichtung zur Unterstützung von Zwei-Knoten-Clustern, entweder durch Verwendung von etcd Learner oder Mirror, ist noch nicht verfügbar.
Die Systemzeit zwischen den Knoten muss derzeit noch manuell synchronisiert werden. Eine künftige Version wird eine automatische Synchronisierung der Uhr beinhalten.
NetHSM ab Version 4.0 unterstützt Clustering, um Daten zwischen mehreren NetHSMs direkt zu synchronisieren. Dies unterstützt eine hohe Frequenz der Schlüsselgenerierung, realisiert Hochverfügbarkeit und Lastausgleich. Ein NetHSM-Cluster basiert auf etcd, das den Raft-Konsensalgorithmus für starke Konsistenz verwendet. Dadurch wird sichergestellt, dass die Daten (z. B. Schlüssel) in allen NetHSMs jederzeit korrekt sind.
Machen Sie sich vor dem Einrichten eines NetHSM-Clusters mit dieser Technologie und ihren Einschränkungen vertraut, um versehentliche Ausfälle und Datenverluste zu vermeiden. Zusätzlich zu diesem Dokument können Sie auch die Dokumentation von etcd einsehen.
Operational Redundancy¶
Als „Knoten“ wird ein NetHSM bezeichnet, von dem erwartet wird, dass er Teil eines Clusters ist. Ein Cluster aus N Knoten wird so lange weiterarbeiten, wie mindestens (N/2)+1 Knoten gesund und erreichbar sind. Diese minimale Anzahl von gesunden, erreichbaren Knoten wird als quorum bezeichnet.
Dies impliziert die folgenden Szenarien.
Ein Knoten fällt aus und das Quorum wird trotzdem erreicht¶
Wenn in einem Cluster mit drei Knoten ein Knoten ausfällt (abstürzt oder aufgrund von Netzwerkbedingungen unerreichbar wird), arbeiten die beiden anderen Knoten weiter und bedienen Anfragen.
Wenn der ausgefallene Knoten noch in Ordnung ist (z. B. wenn es sich nur um ein Netzwerkproblem handelt), ist er während der Isolierung nicht funktionsfähig (nicht einmal schreibgeschützt).
Wenn sich der Knoten jedoch erholt, wird er sauber mit dem Rest des Clusters neu synchronisiert und ist wieder betriebsbereit, ohne dass Daten verloren gehen.
Wenn er sich nicht erholt, muss er aus dem Cluster entfernt werden (siehe nächster Abschnitt), auf die Werkseinstellungen zurückgesetzt werden und den Join-Prozess von Grund auf neu durchlaufen.
Es kommt zu einer Netzwerktrennung und das Quorum wird trotzdem erreicht¶
Dies ist nur eine Verallgemeinerung des vorherigen Szenarios. In einem 5-Knoten-Cluster, in dem sich z. B. 3 Knoten an einem physischen Standort A und 2 Knoten an einem anderen Standort B befinden, würde ein Netzwerkproblem, das A und B isoliert, Folgendes bedeuten:
Die 3 Knoten am Standort A erfüllen das Quorum (in diesem Fall 3), so dass sie weiterarbeiten.
Die 2 Knoten an Standort B sind nicht das Quorum (immer noch 3) erreicht, so dass sie den Betrieb einstellen (auch schreibgeschützt).
Wenn das Netzwerkproblem behoben ist, werden die 2 Knoten wieder mit den 3 anderen verbunden.
Das Quorum ist auf Dauer verloren¶
Ein Ausfall, bei dem alle Untergruppen des Clusters das Quorum verlieren, führt zum vollständigen Verlust des Clusters und seiner Daten, sofern der Ausfall nicht behoben wird. In diesem Fall müssen die Knoten werkseitig zurückgesetzt und ein Backup wiederhergestellt werden.
Dies kann zum Beispiel passieren, wenn ein einzelner Knoten in einem Cluster mit 2 Knoten ausfällt (wo das Quorum 2 ist). In diesem Fall kann der ausgefallene Knoten nicht nachträglich sauber aus dem Cluster entfernt werden, da der verbleibende gesunde Knoten bereits nicht mehr funktionsfähig ist, da er das Quorum verloren hat.
Daher ist es ratsam, immer eine ungerade Anzahl von Knoten in einem Cluster zu haben und häufig Backups durchzuführen.
Um das klarzustellen: vorübergehend Verlust des Quorums (z. B. wenn Sie alle Knoten eines Clusters gemeinsam neu starten oder ein vorübergehender Netzwerkausfall die Knoten isoliert) ist kein Problem: Sobald genügend Knoten wieder verbunden sind (ohne dass sie sich manuell neu verbinden müssen), um das Quorum zu erreichen, nimmt der Cluster seinen normalen Betrieb wieder auf. Nur bei dauerhaften Ausfällen, wie z. B. Netzwerkpartitionen, Netzwerkfehlkonfigurationen, Authentifizierungsproblemen oder Hardwareausfällen, sind manuelle Maßnahmen erforderlich.
Weitere Informationen finden Sie unter etcd’s FAQ.
2-Knoten-Cluster¶
Ein aktiver/passiver Cluster mit zwei Knoten wird noch nicht unterstützt und soll in einer zukünftigen Version hinzugefügt werden. Wir empfehlen die Einführung eines dritten Knotens, entweder eines dritten NetHSM oder eines etcd-„Zeugen“, der auf einem beliebigen Host betrieben werden kann. Siehe den nächsten Abschnitt „Witness“.
Zeuge¶
Das Clustering mit etcd ist umso zuverlässiger, je mehr Knoten im Cluster vorhanden sind. Wie im Abschnitt Operational Redundancy erläutert, sollten Cluster idealerweise mindestens 3 Knoten haben, um Raum für Ausfälle zu haben, da ein 2-Knoten-Cluster vollständig ausfällt, wenn nur einer ausfällt.
Die Funktion ist jedoch so konzipiert, dass Sie kein vollständiges, echtes NetHSM-Gerät zu Ihrem Cluster hinzufügen müssen, um eine stabile Anzahl von Knoten zu erreichen. Stattdessen können Sie selbst einen „Zeugen“-Knoten einrichten und hinzufügen. Ein solcher Knoten ist einfach eine Instanz von etcd, die auf einem Rechner Ihrer Wahl (oder in einem Container) läuft und mit dem Cluster verbunden ist. Er wird von den echten Geräten im Cluster als normaler Knoten erkannt und empfängt alle Daten und Aktualisierungen von den Geräten (aber natürlich können Sie mit ihm keine HSM-Operationen durchführen - er speichert nur Daten).
Security Considerations¶
Der Zeugenknoten (oder jeder, der Zugriff auf ihn hat) hat direkten Zugriff auf das Speicher-Backend aller Knoten im Cluster (z.B. können Sie alle Einträge und die entsprechenden Werte mit etcdctl get "/" "0" ausgeben).
Mit Ausnahme der Konfigurationsversion (/config/version, die immer „1“ sein sollte) sind jedoch grundsätzlich alle Werte verschlüsselt (entweder mit einem Geräteschlüssel für knotenspezifische Werte oder den Domänenschlüsseln für andere), wodurch die Vertraulichkeit sensibler Daten gewährleistet ist.
Beachten Sie jedoch, dass ein bösartiger Knoten dies tun kann:
Müll als Wert für einen beliebigen Eintrag in den Speicher zu schreiben, was dazu führt, dass die Knoten ihn nicht entschlüsseln können (was bei einigen Systemeinträgen zu Abstürzen führen kann).
Listeneintragsnamen wie Benutzer, Namensräume und Schlüssel, die Sie als sensibel betrachten.
Creating a Cluster¶
Jeder Cluster beginnt zunächst mit einem einzigen Knoten. Neue Knoten werden dem Cluster nach und nach hinzugefügt.
Preparing Nodes¶
Der Netzwerkverkehr zwischen den Knoten wird verschlüsselt und mit ihrem TLS-Zertifikat authentifiziert.
Alle Knoten, die Teil desselben Clusters sein sollen, müssen zunächst eine gemeinsame Zertifizierungsstelle (CA) installieren, die es ihnen ermöglicht, die Legitimität der anderen Knoten zu überprüfen.
Im Folgenden gehen wir davon aus, dass alle Knoten frisch eingerichtet und betriebsbereit sind.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Erstellen und Installieren einer CA¶
Die Benutzer sollten eine CA mit ihren eigenen Mitteln und nach ihren eigenen betrieblichen Zwängen erstellen und sicherstellen, dass sie mindestens die Verwendung des Schlüssels keyCertSign zulässt.
Eine minimale CA kann zum Beispiel mit openssl erstellt werden:
$ openssl genrsa -out CA.key 2048 # create a key
$ openssl req -x509 -new -nodes -key CA.key -sha256 -days 1825 -out CA.pem -addext keyUsage=critical,keyCertSign
Diese CA muss nun auf jedem Knoten installiert werden.
To do this, first generate a Certificate Signing Request (CSR) from the node with the /config/tls/csr.pem endpoint (refer to the API documentation).
Bemerkung
Um die Knoten ordnungsgemäß zu authentifizieren, erwartet das Clustering-Backend (etcd), dass jeder Knoten ein Zertifikat mit einem korrekt ausgefüllten Subject Alt Names (SAN)-Feld besitzt. Insbesondere Knoten, von denen erwartet wird, dass sie nur über ihre IP erreichbar sind, müssen ein korrektes IP-SAN in ihrem Zertifikat haben. IP-SANs können für die CSR angefordert werden, indem den Namen „IP:“ vorangestellt wird, wie in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Mit der erhaltenen CSR (nennen wir sie nethsm.csr) können wir dann ein Zertifikat für sie erzeugen, das installiert werden kann. Zum Beispiel mit openssl:
$ openssl x509 -req -days 1825 -in nethsm.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out new_cert.pem -set_serial 01 -sha256
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Schließlich kann die CA (CA.pem) nun mit dem Endpunkt /config/tls/cluster-ca.pem installiert werden (siehe API-Dokumentation). Dies ist nur möglich, wenn das installierte TLS-Zertifikat von ihr signiert ist. Andernfalls wird der Vorgang abgelehnt.
Bemerkung
Dieser Vorgang muss für jeden Knoten wiederholt werden.
Taktsynchronisation¶
Stellen Sie sicher, dass jeder Knoten mit einer genauen Systemzeit ausgestattet ist. Falls nicht, stellen Sie die Uhren mit dem Endpunkt /config/time ein.
Adding a New Node¶
Das Hinzufügen eines Knotens zu einem Cluster erfolgt in zwei Schritten:
den Zusatz zum Cluster (über eines seiner Mitglieder) registrieren
dem neuen Knoten mitteilen, dass er beitreten soll
Configure a Backup Passphrase¶
Stellen Sie zunächst sicher, dass eine Backup-Passphrase auf dem Knoten konfiguriert ist, der für die Registrierung eines neuen Joiners verwendet werden soll (siehe die API-Dokumentation des Endpunkts /config/backup-passphrase).
Registrierung eines neuen Knotens¶
Warnung
Die Registrierung eines Knotens führt sofort einen neuen Knoten in den Cluster ein und ändert den Quorum-Schwellenwert, auch wenn der Knoten noch nicht tatsächlich beigetreten ist. Dies kann dazu führen, dass die vorhandenen Knoten nicht mehr funktionsfähig sind, bis der neue Knoten tatsächlich beigetreten ist. Siehe die API-Dokumentation und den Abschnitt Operational Redundancy in diesem Dokument.
Halten Sie die IP des Knotens bereit, der beitreten wird. Die vollständige URL (auch peer URL in etcd Terminologie genannt) dieses Knotens wird https://<IP_of_node>:2380 (z.B. https://192.168.1.1:2380) sein. Der Port muss 2380 sein, also stellen Sie sicher, dass jede Firewall zwischen den Knoten den TCP-Verkehr auf diesem Port zulässt.
Sie können überprüfen, ob die URL korrekt ist, indem Sie GET /cluster/members auf dem Knoten, der beitreten soll, aufrufen. Dies sollte nur ein Mitglied auflisten: sich selbst.
Registrieren Sie dann die erwartete URL auf einem beliebigen bestehenden Knoten des Clusters (wenn Sie noch keinen Cluster haben, tun Sie dies auf dem NetHSM, der als erster Knoten des Clusters dienen wird). Dazu verwenden Sie den Endpunkt POST /cluster/members (siehe API-Dokumentation) und übergeben ihm einen JSON-Body mit der URL.
Bei Erfolg wird ein JSON-Body des Formulars zurückgegeben:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
die Informationen enthält, die der neue Knoten benötigt, um dem Cluster beizutreten. Insbesondere listet er alle Mitglieder des Clusters auf (wobei das Mitglied mit einem leeren Namen der neue Teilnehmer ist). Sie enthält auch den Domänenschlüssel, der sowohl durch die Entsperr- als auch durch die Sicherungspassphrase verschlüsselt ist - eine Sicherungspassphrase muss also zuvor konfiguriert worden sein.
Behalten Sie diese Antwort für den nächsten Schritt.
Tatsächlicher Beitritt zum Cluster¶
Nehmen Sie die Antwort aus dem letzten Schritt und fügen Sie ein backupPassphrase Feld hinzu, das die Backup-Passphrase des Knotens enthält, auf dem der neue Joiner registriert wurde, und übergeben Sie diese Daten an einen Aufruf an POST /cluster/join (siehe die API-Dokumentation) auf dem Knoten, von dem erwartet wird, dass er beitritt.
Unter der Voraussetzung, dass sowohl der Cluster als auch der Knoten einander erreichen können, wird der eigentliche Beitritt vollzogen, wobei die Daten des neuen Teilnehmers gelöscht werden, um stattdessen seinen Status mit dem des Clusters zu synchronisieren.
Je nach den Netzwerk- und Clusterbedingungen kann dieser Vorgang einige Dutzend Sekunden dauern. Wenn dieser Vorgang sofort fehlschlägt (z. B. weil der Cluster nicht erreichbar war oder die Authentifizierung fehlgeschlagen ist), wird der Status dieses Knotens nicht gelöscht und der Beitritt wird rückgängig gemacht. Sobald jedoch ein erster Beitritt erfolgreich war, ist dieser Vorgang endgültig und kann nur durch einen Werksreset rückgängig gemacht werden.
Wenn diese Verbindung erfolgreich ist, befindet sich der Knoten im Zustand Locked und muss mit der Entsperr-Passphrase des Knotens, der für die Registrierung verwendet wurde, entsperrt werden. Danach kann die Entsperr-Passphrase geändert werden (Entsperr-Passphrasen bleiben knotenspezifisch und werden nicht zwischen Knoten ausgetauscht).
Bemerkung
Wenn die Datenbank des Clusters groß oder der Cluster ausgelastet ist, kann es selbst nach erfolgreichem Join einige Zeit dauern, bis der neue Joiner seinen Status vollständig synchronisiert hat. Während dieser Zeit können alle Knoten (insbesondere auch der neue Joiner) weniger oder gar nicht reagieren. Insbesondere der neue Joiner kann anfangs Fehler zurückgeben, wenn er zum Beispiel versucht, die Sperre aufzuheben. In diesem Fall sollten Sie ihm etwas Zeit geben und es erneut versuchen.
Adding a Witness Node¶
Prepare a Witness¶
Sie benötigen eine Umgebung, in der etcd v3.6 verfügbar ist, mit einer IPv4-Adresse (mindestens), die für die anderen Mitglieder Ihres Clusters erreichbar ist. Der TCP-Verkehr von und zu Port 2380 muss zugelassen werden.
Erstellen Sie ein leeres Verzeichnis, in dem etcd seine Daten speichern wird, und notieren Sie den Pfad (wir verwenden /var/etcd/data). Stellen Sie sicher, dass der Benutzer, der den Prozess starten wird, Lese- und Schreibrechte für das Verzeichnis hat.
Übertragen Sie das CA-Zertifikat, das zur Authentifizierung der Knoten im Cluster verwendet wird, auf den Rechner. Sie sollten es im Abschnitt Erstellen und Installieren einer CA erstellt haben. Wir werden es in /var/etcd/CA.pem speichern.
Anschließend müssen Sie ein Zertifikat für den Zeugen erstellen und es mit der Zertifizierungsstelle signieren, damit er mit seinen Kollegen kommunizieren kann. Dies kann zum Beispiel über openssl erfolgen:
# Create a key
$ openssl genrsa -out witness.key 2048
# Create a CSR with a SAN that corresponds to the witness's IP or hostname
$ openssl req -new -sha256 -key own.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=witness" \
-addext "subjectAltName=IP:172.22.1.3" --out witness.csr
# Sign it
$ openssl x509 -req -days 1825 -in witness.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out witness.pem -set_serial 01 -sha256
Speichern Sie die Ergebnisse witness.key und witness.pem auch in /var/etcd.
Register Witness to Cluster¶
Folgen Sie den normalen Anweisungen aus dem Abschnitt Registrierung eines neuen Knotens, um dem bestehenden Cluster das Hinzufügen eines neuen Mitglieds mit der/den angegebenen URL(s) zu signalisieren.
Schreiben Sie die Antwort des Clusters auf: Sie sollte die Liste der Clustermitglieder und ein Joiner-Kit enthalten (diesen Teil werden Sie nicht benötigen).
Configure etcd¶
Im Gegensatz zu NetHSMs, die automatisch einen Knotennamen für sich selbst wählen (unter Verwendung der Geräte-ID), müssen Sie für jeden hinzugefügten Zeugen einen Namen wählen, und sicherstellen, dass die Namen eindeutig sind. In den folgenden Beispielen wird „witness1“ verwendet.
Mit der Antwort des NetHSM auf die Registrierung des Zeugen bereiten Sie die Variablen des Formulars vor:
export ETCD_NAME="witness1"
export ETCD_DATA_DIR="/var/etcd/data"
export ETCD_INITIAL_CLUSTER="peer1=url1,peer1=url2,peer2=url1,peer2=url2,..."
export ETCD_INITIAL_ADVERTISE_PEER_URLS="my_url1,my_url2,..."
Unter der Annahme, dass die NetHSM-Antwort in einer response.json Datei gespeichert ist, können Sie diese beiden letzten Variablen automatisch mit den folgenden jq Ausdrücken erzeugen:
export ETCD_INITIAL_CLUSTER=$(jq --raw-output '[.members[] | ["\(if .name == "" then "witness1" else .name end)=\(.urls[])"]] | flatten | join(",")' < response.json)
export ETCD_INITIAL_ADVERTISE_PEER_URLS=$(jq --raw-output '.members[] | select(.name=="") | .urls | join(",")' < response.json)
Mit der Beispielantwort, die im Abschnitt Registrierung eines neuen Knotens angegeben ist, erhalten Sie zum Beispiel folgende Antwort:
ETCD_NAME="witness1"
ETCD_DATA_DIR="/var/etcd/data"
ETCD_INITIAL_CLUSTER="witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.22.1.3:2380"
Erstellen Sie schließlich eine Datei etcd.conf.yml unter Verwendung der in docs/etcd_witness.conf.template bereitgestellten Vorlagendatei:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Damit sollten Sie eine Datei des Formulars erhalten:
name: witness1
data-dir: /var/etcd/data
log-level: warn
log-format: console
listen-peer-urls: https://0.0.0.0:2380
listen-client-urls: http://localhost:2379
initial-advertise-peer-urls: https://172.22.1.3:2380
advertise-client-urls: http://localhost:2379
initial-cluster: witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380
initial-cluster-state: 'existing'
peer-transport-security:
cert-file: witness.pem
key-file: witness.key
client-cert-auth: true
trusted-ca-file: CA.pem
skip-client-san-verification: true
Start etcd¶
Starten Sie etcd auf die von Ihnen bevorzugte Weise (manuell, systemd Dienst, Container usw.) und verweisen Sie dabei auf die im vorherigen Schritt erstellte Konfigurationsdatei:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Sie sollten sehen, wie er startet, dem Cluster beitritt und die Daten auffängt. Nach einiger Zeit sollten Sie in der Lage sein, mit dem etcdctl-Client zu überprüfen, ob er gesund ist:
etcdctl get /config/version
Dieser Schlüssel muss vorhanden sein und eine „1“ enthalten.
Stellen Sie sicher, dass dieser Prozess weiterläuft, da er nun ein echtes Mitglied Ihres Clusters ist. Wenn Sie ihn außer Betrieb nehmen müssen, entfernen Sie ihn zunächst ordnungsgemäß aus dem Cluster (siehe den entsprechenden Abschnitt). Wenn sich seine erreichbare IP ändert, aktualisieren Sie seine URL aus dem Cluster.
Operating a Cluster¶
Sichern und Wiederherstellen¶
Der Sicherungsvorgang funktioniert genauso wie ohne Cluster und kann von jedem Knoten des Clusters angefordert werden. Es werden die Daten des gesamten Clusters gesichert, einschließlich knotenspezifischer Felder (diese werden jedoch ignoriert, es sei denn, die Sicherung wird auf einem nicht bereitgestellten Knoten wiederhergestellt).
Eine auf einem Cluster erstellte Sicherung kann auf demselben Cluster wiederhergestellt werden, auch wenn seitdem einige Knoten hinzugefügt oder entfernt wurden. Solche Wiederherstellungen auf operativen Clustern wirken sich nicht auf die Konfigurationswerte aus (nur Schlüssel, Benutzer, Namespaces), wie jede andere teilweise Wiederherstellung.
Bei der Wiederherstellung eines Backups auf einem nicht bereitgestellten Knoten werden die knotenspezifischen Felder (wie Netzwerkkonfiguration, Zertifikate usw.) des Knotens wiederhergestellt, der zur Erstellung des Backups verwendet wurde.
Die Wiederherstellung einer umfangreichen Sicherung kann den Cluster für einige Zeit überlasten, während der Knoten, der die Wiederherstellung durchführt, Änderungen an die anderen weiterleitet.
Dieser Vorgang ist mit Sicherungen kompatibel, die mit früheren Versionen von NetHSM erstellt wurden.
Bemerkung
Wird auf einem Knoten A eine Sicherung wiederhergestellt, die auf einem anderen Knoten Z mit einem anderen Domänenschlüssel erstellt wurde, wird der Domänenschlüssel von A wie zuvor korrekt neu geschrieben. Befindet sich A jedoch in einem Cluster mit Knoten B, ist B nicht mehr funktionsfähig, da der Domänenschlüssel von Z auf B nicht wiederhergestellt wird.
Mit anderen Worten: Führen Sie eine Wiederherstellung nur in einem Cluster durch, dessen Sicherungen im selben Cluster erstellt wurden (auch wenn seitdem wieder Knoten entfernt oder hinzugefügt wurden). Wenn Sie eine fremde Sicherung auf einem Knoten wiederherstellen wollen, entfernen Sie ihn zunächst sicher aus seinem Cluster, setzen ihn dann auf Werkseinstellungen zurück und stellen die Sicherung wieder her.
Sauberes Entfernen eines Knotens¶
Solange ein Teil des Clusters noch beschlussfähig ist, kann jedes seiner Mitglieder verwendet werden, um einen anderen Knoten aus dem Cluster zu entfernen, unabhängig davon, ob dieser Knoten bereits unerreichbar ist oder dies erwartet wird.
Sie müssen zunächst die ID des Knotens kennen, den Sie entfernen möchten, indem Sie alle Knoten über GET /cluster/members auflisten und den richtigen suchen.
Dann kann er durch den Aufruf von DELETE /cluster/members/<id> entfernt werden. Wenn der betreffende Knoten noch gesund war, wird er dadurch vom Rest des Clusters isoliert und funktionsunfähig gemacht.
Software Updates in Clusters¶
Zukünftige Aktualisierungen werden als „cluster-safe“ (dies sollte die Mehrheit sein) oder „cluster-unsafe“ gekennzeichnet.
Cluster-sichere Aktualisierungen können auf Knoten angewandt werden, die Teil eines Clusters sind, ohne sie vorher aus dem Cluster zu entfernen. Wie bei allen Vorgängen sollten Sie jedoch sicherstellen, dass Sie dies jeweils auf einem Knoten und in einem Cluster tun, in dem das Entfernen eines Knotens nicht zu einer Unterschreitung des Quorums führt (z. B. wenn die Aktualisierung fehlschlägt).
Cluster-unsichere Updates müssen auf isolierte Knoten angewendet werden. Sie sollten den Cluster auflösen (indem Sie einen Knoten nach dem anderen entfernen), alle Knoten bis auf einen auf Werkseinstellungen zurücksetzen, das Update auf jeden Knoten anwenden und dann alle zurückgesetzten Knoten dem verbleibenden Knoten hinzufügen.
Stellen Sie sicher, dass Sie vor solchen Vorgängen ein Backup erstellen.
Rekonfigurieren eines bestehenden Clusters¶
Changing the Cluster CA¶
Ein bestehender Cluster (mit zwei oder mehr Knoten) kann seine Cluster-CA im laufenden Betrieb nicht ändern. Wenn Sie dieses Zertifikat ändern müssen: Wählen Sie einen Knoten aus, entfernen Sie alle anderen Knoten, aktualisieren Sie die CA, und lassen Sie die anderen Mitglieder wieder beitreten.
Changing the Network Configuration of Nodes¶
Wenn Sie die Netzwerkkonfiguration eines Knotens ändern (z. B. seine IP-Adresse), werden die anderen Knoten automatisch über die Aktualisierung informiert. Sie sollten jedoch sicherstellen, dass Sie solche Aktualisierungen jeweils nur an einem einzigen Knoten vornehmen, und zwar in einem Cluster, in dem der Verlust dieses Knotens nicht zum Verlust des Quorums führen würde.