Clustering¶
Bemerkung
This feature is currently a technical preview with the following temporary limitation:
Active/passive setup to support two-node clusters, either by utilizing etcd Learner or Mirror, is not yet available. Use a Witness node instead.
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.
In einem Cluster, der diesen Schwellenwert unterschreitet (z. B. aufgrund eines Netzwerkproblems), kann kein Leader gewählt werden, und die lokale Instanz von etcd auf jedem Knoten kann keine Lese- und Schreibvorgänge mehr ausführen. Daraus ergeben sich 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.
If the failed node is still healthy (e.g. it was just a network problem), it will be in the Failed state while isolated, refusing normal operations (not even read-only).
However if the node recovers, it will cleanly resynchronize with the rest of the cluster and exit the Failed state, resuming normal operation without losing data.
Sollte es sich nicht wieder erholen, muss es aus dem Cluster entfernt werden und entweder einer Wiederherstellung unterzogen werden, um auf seine Daten zugreifen zu können (es ist dann jedoch nicht mehr Teil des Clusters), oder auf die Werkseinstellungen zurückgesetzt und der Beitrittsprozess von Grund auf neu durchlaufen werden.
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.
The 2 nodes in location B are not meeting the quorum (still 3), so they will enter the Failed state and stop operating (even read-only).
Wenn das Netzwerkproblem behoben ist, werden die 2 Knoten wieder mit den 3 anderen verbunden.
Mit anderen Worten: Im schlimmsten Fall einer Netzwerkpartition (in einem Cluster mit einer ungeraden Anzahl von Knoten) bleibt die größere Hälfte des Clusters funktionsfähig, während die kleinere Hälfte so lange nicht einsatzfähig ist, bis die Partition behoben ist.
Das Quorum ist auf Dauer verloren¶
A failure causing all subsets of the cluster to lose quorum will render the cluster completely inoperable (all remaining nodes will be in the Failed state), unless the failure is resolved. In this case, manual recovery <clustering.html#recovering-a-failed-node> must be performed.
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:
Write garbage as the value for any entry in the store, which will cause nodes to fail decrypting it (which may lead to crashes for some system entries).
List entry names such as users, namespaces and keys, which you may consider sensitive.
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
To properly authenticate nodes, the clustering backend (etcd) expects that each node has a certificate with a properly filled Subject Alt Names (SAN) field.
Nodes are expected to be reached only via their IP and need to have a proper IP SAN in their certificate.
IP SANs can be requested for the CSR by prefixing „IP:“ to the names, as in openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Wenn Sie eine öffentliche Zertifizierungsstelle (CA) zum Signieren Ihrer Zertifikate verwenden möchten, müssen Ihre Knoten öffentliche IP-Adressen verwenden. Dies ist auf eine Sicherheitsanforderung zurückzuführen, die es einer öffentlichen Zertifizierungsstelle untersagt, Zertifikate auszustellen, deren IP-SAN eine private IP-Adresse enthält.
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 auf jedem Knoten eine korrekte Systemzeit eingerichtet wurde, idealerweise mithilfe von NTP/NTS anstelle einer manuellen Zeiteinstellung. Dies kann über die Konfiguration unter Time sowie NTS/NTP erfolgen.
Adding a New Node¶
Adding a node to a cluster is done in three steps:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
Sobald er aufgeholt hat, befördere den Knoten vom Lernenden zum vollwertigen Mitglied.
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¶
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"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"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.
Bemerkung
Beachten Sie in der obigen Antwort, dass der neue Teilnehmer ein „Lerner“ ist: Er kann nun eine Verbindung zum Cluster herstellen und Daten von diesem empfangen, kann jedoch erst dann aktiv mitwirken, wenn er befördert wurde – darauf wird im Folgenden eingegangen.
Zwar bedeutet dieses Konzept des „Learners“ einen zusätzlichen Schritt (die Beförderung), doch ermöglicht es einen sichereren Betrieb des Clusters, da etwaige Probleme mit dem neuen Knoten vor seiner Beförderung keine Instabilität im gesamten Cluster verursachen können.
Behalten Sie diese Antwort für den nächsten Schritt.
Joining the Cluster as a Learner¶
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.
Warnung
Der Aufruf von ` `` POST /cluster/join` bleibt hängen, bis der neue Knoten manuell befördert wird (siehe unten). Dies ist normal. Wenn der Aufruf erfolgreich zurückkehrt, bedeutet dies, dass der Beitritt und die Beförderung erfolgreich waren.
Assuming both the cluster and the node can reach each other, this will enact the actual join, wiping the data on the new joiner to instead synchronize its state with that of the cluster. If this operation fails immediately (e.g. the cluster was not reachable or authentication failed), this node’s state will not be wiped and the join will be reverted. However as soon as a first join is successful, this operation is final and can only be reverted by a factory reset.
Zu diesem Zeitpunkt ist der neue Knoten als „ -Lerner“ ( ) dem Cluster beigetreten: Er synchronisiert sich gerade mit dem Cluster, ist jedoch noch nicht betriebsbereit. Andererseits würde ein eventuelles Problem mit dem Knoten in dieser Phase keine Auswirkungen auf den Cluster haben, sodass dieser Vorgang sicher ist.
Der letzte Schritt zum Abschluss des Beitritts besteht darin, den neuen Knoten zum vollwertigen Mitglied zu ernennen.
Promoting the New Learner¶
Je nach Netzwerk- und Clusterbedingungen kann es eine Weile dauern, bis das neue Mitglied den Rückstand zum Cluster aufgeholt hat. Sobald dies geschehen ist, kann es vom Lernmitglied zum Vollmitglied befördert werden.
Warnung
Durch die Heraufstufung eines Knotens wird die Quorum-Schwelle des Clusters erhöht (siehe die API-Dokumentation zu „ “ unter sowie den Abschnitt „ : Operational Redundancy“ unter in diesem Dokument). Stellen Sie sicher, dass dieser neue Knoten über eine stabile Verbindung zum Cluster verfügt, bevor Sie ihn heraufstufen.
Sie können versuchen, das neue Mitglied mit einem Aufruf an POST /cluster/members/{MemberID}/promote zu befördern (siehe die API-Dokumentation zu „ “ unter). Falls der Lernende noch nicht auf den aktuellen Stand gebracht wurde, schlägt dieser Vorgang mit dem HTTP-Code 412 fehl, und die Beförderung sollte später erneut versucht werden.
If this promotion is successful, the node will now have fully joined the cluster and the earlier call to /cluster/join will have returned. The node ends up in a Locked state and has to be unlocked with the unlock passphrase of the node that was used for registration. Afterwards the unlock passphrase can be changed (unlock passphrases remain node-specific and are not shared across nodes).
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.
Transfer to the machine the CA certificate that is being used to authenticate
nodes in the cluster. You should have created one in the
Creating and Installing a CA section. We’ll
store it in /var/etcd/CA.pem.
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¶
Follow the normal instructions from the Registering a New Node section to signal the existing cluster the addition of a new member with the given URL(s).
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)
For example with the example response provided in the Registering a New Node section, you will have:
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 es startet, sich dem Cluster als „Lerner“ anschließt und die Daten nachholt.
Promote the Witness¶
Befolgen Sie schließlich nach einiger Zeit die üblichen Anweisungen aus dem Abschnitt „ : Beförderung des neuen Lernenden“, um den Zeugen zu befördern. Sollte dies nicht funktionieren, versuchen Sie es später erneut.
After a successful promotion, you should be able to check that it is healthy with the etcdctl client:
etcdctl get /config/version
Dieser Schlüssel muss vorhanden sein und eine „1“ enthalten.
Make sure this process keeps running, as it is now a proper member of your cluster. If you need to decommission it, first properly remove it from the cluster. If its reachable IP changes, update its URL from the 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.
Then it can be removed by calling DELETE /cluster/members/<id>. If the node in question was still healthy, this will isolate it from the rest of the cluster and transition it to the Failed state.
Bemerkung
Ein Knoten, der dem Cluster beigetreten ist, aber noch nicht befördert wurde, kann auf diese Weise ebenfalls sicher entfernt werden.
Recovering a Failed Node¶
Ein Knoten, der den Status „ “ („Fehler: “) meldet, reagiert auf die meisten normalen Befehle nicht mehr. Er kann dennoch heruntergefahren, neu gestartet, zurückgesetzt , diagnostiziert oder isoliert werden.
Warnung
Die folgenden Operationen – „ “, „Failed “, „ ` “, „diagnose` “ und „ ` “ sowie „force-new` “ – gelten nur für Version 5.0 und höher. In Version 4.0 reagiert ein Knoten mit verlorenem Quorum nicht mehr auf alle Anfragen. Er muss auf die Werkseinstellungen zurückgesetzt werden.
Zu den häufigen Ursachen dafür, dass sich ein Knoten im Status „ Failed“ befindet, gehören:
Ein dauerhaft fehlendes Quorum.
Ein vorübergehender Verlust der Beschlussfähigkeit (z. B. beim Hinzufügen eines zweiten Knotens zum Cluster, wenn dieser noch nicht dem Cluster beigetreten ist).
etcdwird derzeit neu gestartet (z. B. weil sich die Zertifikate geändert haben oder das Netzwerk neu konfiguriert wurde).Der Cluster ist einer sehr hohen Auslastung ausgesetzt (z. B. während der Wiederherstellung eines sehr umfangreichen Backups).
Unabhängig vom Grund wechselt der NetHSM erst dann in den Status „ Failed“, nachdem mindestens eine volle Minute lang erfolglose Versuche unternommen wurden, mit seiner Datenbank zu kommunizieren. Damit sollen unerwünschte Statuswechsel vermieden werden, die durch sehr kurze Instabilitäten verursacht werden.
Damit Sie besser nachvollziehen können, in welchem Zustand sich Ihr Knoten befindet, steht der Endpunkt „ ` “ (GET /health/diagnose`) weiterhin zur Verfügung und liefert Informationen zum aktuellen Status von „ ` “ (etcd`) und dessen Datenbank, einschließlich der Protokolle (siehe API-Dokumentation).
Bemerkung
Sobald die Datenbank wieder verfügbar ist (z. B. wenn das Quorum wiederhergestellt ist, weil das Netzwerkproblem behoben wurde), wechselt das NetHSM automatisch aus dem Status „ Failed“ in den vorherigen Status (oder setzt die normale Startsequenz fort, falls es gerade gestartet wurde), ohne dass manuelle Maßnahmen erforderlich sind. Es dauert bis zu einer Minute nach Behebung des Problems, bis sich der Cluster stabilisiert hat, das HSM die Behebung erkennt und den Zustand wechselt.
Wenn Sie zu dem Schluss kommen, dass der Fehler dauerhaft ist (z. B. Verlust des Quorums ohne Aussicht auf Behebung der zugrunde liegenden Ursache), haben Sie folgende Möglichkeiten:
Setzen Sie den Knoten auf die Werkseinstellungen zurück, wodurch alle Daten gelöscht werden, und stellen Sie ein Backup wieder her.
Isolieren Sie den Knoten mit dem Endpunkt „ ` “ POST /cluster/force-new`. Dadurch werden alle anderen Clustermitglieder unwiderruflich vergessen, die auf der Festplatte vorhandenen Daten unter „ ` “ etcd` wiederhergestellt und der Knoten neu gestartet. Wenn der zugrunde liegende Fehler clusterbezogen war, durchläuft der Knoten die normale Startsequenz und gelangt je nach Einstellung für den unbeaufsichtigten Start entweder in den Zustand „ “ (gesperrt) oder „ “ (betriebsbereit).
Bemerkung
Wenn ein Knoten mit dem Befehl „ ` “ force-new` isoliert wird, ist er fortan nicht mehr mit dem Cluster synchronisiert: Neue Schreibvorgänge auf diesem Knoten oder im Cluster können nicht mehr abgeglichen werden. Der Knoten kann sich zwar weiterhin dem Cluster anschließen, verliert dabei jedoch alle lokalen Änderungen.
Der Endpunkt „ ` “ POST /cluster/force-new`, der nur im Status „ Failed“ verfügbar ist, erfordert eine Authentifizierung, da er potenziell destruktiv ist. Da jedoch in diesem Status keine HSM-Benutzer und -Rollen verfügbar sind, erwartet der Endpunkt, dass sich HTTPS-Clients stets mit dem fiktiven Benutzer unlock und der zuletzt bekannten Entsperrpassphrase als Passwort authentifizieren.
Warnung
Nach einem Update von einer Version < 5.0 wird der Endpunkt „ ` “ force-new` immer den Status „Unauthorized“ anzeigen, bis das HSM entsperrt oder die Entsperr-Passphrase mindestens einmal geändert wurde.
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.