Clustering

Note

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.

  • Cela n’a pas encore été validé dans un nombre suffisant de déploiements en production, et il peut y avoir des bogues.

Le NetHSM 4.0 et les versions ultérieures prennent en charge la mise en grappe pour synchroniser directement les données entre plusieurs NetHSM. Cela permet une fréquence élevée de génération de clés, une haute disponibilité et un équilibrage de la charge. Un cluster NetHSM est basé sur etcd qui utilise l’algorithme de consensus Raft pour une cohérence forte. Cela garantit que les données (par exemple les clés) sont correctes dans tous les NetHSM à tout moment.

Avant de mettre en place un cluster NetHSM familiarisez-vous avec cette technologie et ses contraintes afin d’éviter les pannes accidentelles et les pertes de données. En complément de ce document, vous pouvez consulter la documentation de etcd.

Operational Redundancy

Nous appellerons « nœud » un NetHSM censé faire partie d’une grappe. Une grappe de nœuds N continuera à fonctionner tant qu’au moins (N/2)+1 nœuds sont sains et accessibles. Ce nombre minimal de nœuds sains et joignables est appelé quorum.

Sur un cluster dont la disponibilité passe en dessous de ce seuil (par exemple en raison d’un problème réseau), aucun leader ne peut être élu et l’instance locale de etcd sur chaque nœud devient incapable d’effectuer des opérations de lecture et d’écriture. Cela implique les scénarios suivants.

Un nœud tombe en panne et le quorum est toujours atteint

Dans un cluster à trois nœuds, si un nœud tombe en panne (ou devient inaccessible en raison des conditions du réseau), les deux autres nœuds continueront à fonctionner et à répondre aux demandes.

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.

S’il ne se rétablit jamais, il devra être supprimé ` <clustering.html#removing-a-node-cleanly>` __ du cluster et soit faire l’objet d’une restauration ` <clustering.html#recovering-a-failed-node>` __ pour pouvoir accéder à ses données (mais il ne fera alors plus partie du cluster), soit être réinitialisé aux paramètres d’usine et recommencer le processus d’intégration depuis le début.

Une partition du réseau se produit et le quorum est toujours atteint

Il s’agit d’une généralisation du scénario précédent. Dans une grappe de 5 nœuds où, par exemple, 3 nœuds se trouvent à un emplacement physique A et 2 nœuds à un autre emplacement B, un problème de réseau isolant A et B se traduirait par ce qui suit :

  • Les 3 nœuds de l’emplacement A atteignent le quorum (3 dans ce cas), ils continuent donc à fonctionner.

  • 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).

  • Si le problème de réseau est résolu, les 2 nœuds rejoindront proprement les 3 autres.

En d’autres termes, dans le pire des cas, une partition du réseau (dans un cluster comportant un nombre impair de nœuds) laissera la moitié la plus importante du cluster opérationnelle, tandis que la moitié la plus petite restera hors service jusqu’à ce que la partition soit résolue.

Le quorum est durablement perdu

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 must be performed.

Cela peut se produire, par exemple, si un seul nœud tombe en panne dans un cluster à 2 nœuds (où le quorum est de 2). Dans ce cas, le nœud défaillant ne peut pas être supprimé proprement de la grappe après coup, car le nœud sain restant est déjà inopérant puisqu’il a perdu le quorum.

Il est donc conseillé de toujours avoir un nombre impair de nœuds dans une grappe et de faire des sauvegardes fréquentes.

Pour être clair, temporairement perdre le quorum (par exemple, si vous redémarrez tous les nœuds d’un cluster ensemble, ou si une panne de réseau temporaire isole les nœuds) n’est pas un problème : une fois que suffisamment de nœuds sont reconnectés (sans avoir à se reconnecter manuellement) pour atteindre le quorum, le cluster reprendra son fonctionnement normal. Seules les pannes permanentes, telles que les partitions de réseau, les mauvaises configurations de réseau, les problèmes d’authentification ou les pannes matérielles, nécessiteront une action manuelle.

Pour plus d’informations, voir la FAQ de etcd.

Grappe à 2 nœuds

Un cluster actif/passif à deux nœuds n’est pas encore supporté et sera ajouté dans une prochaine version. Nous recommandons d’introduire un troisième nœud, soit un troisième NetHSM, soit un « témoin » etcd qui pourrait être exploité sur n’importe quel hôte. Voir la section suivante « Témoin ».

Témoin

The nature of clustering with etcd makes it more reliable the more nodes there are in the cluster. As explained in the Operational Redundancy section, clusters should ideally have at least 3 nodes to have room to fail, since a 2-node cluster will entirely fail if only one fails.

Cependant, la conception de cette fonctionnalité est telle que vous n’avez pas besoin d’ajouter un véritable dispositif NetHSM à votre cluster pour atteindre un nombre stable de nœuds. Au lieu de cela, vous pouvez déployer et ajouter vous-même un nœud « témoin ». Un tel noeud est juste une instance de etcd tournant sur la machine de votre choix (ou dans un conteneur), et connecté au cluster. Il sera reconnu comme un nœud normal par les appareils réels du cluster, et recevra toutes les données et mises à jour des appareils (mais bien sûr vous ne pourrez pas effectuer d’opérations HSM avec lui - il ne fait que stocker des données).

Security Considerations

Le nœud témoin (ou toute personne y ayant accès) a un accès direct au backend de stockage de tous les nœuds de la grappe (par exemple, vous pouvez vider toutes les entrées et les valeurs correspondantes avec etcdctl get "/" "0").

Cependant, à l’exception de la version de configuration (/config/version, qui devrait toujours être « 1 »), toutes les valeurs sont strictement cryptées (avec une clé de périphérique pour les valeurs spécifiques au nœud ou les clés de domaine pour les autres), ce qui garantit la confidentialité des données sensibles.

Notez toutefois qu’un nœud malveillant peut :

  • 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.

Ce qui est partagé entre les nœuds

Le fait de disposer d’une grappe de NetHSM signifie que la plupart des données sont partagées entre eux. Tout ajout, modification ou suppression de clés, d’utilisateurs ou d’espaces de noms sur un nœud est finalement répercuté sur tous les autres. En général, toute opération qui modifie l’état modifiera l’état de chaque nœud. Cela inclut l’opération de sauvegarde restore qui fonctionne normalement.

Les sections suivantes détaillent les données qui sont entièrement locales, celles qui sont stockées dans le magasin partagé etcd mais qui restent spécifiques au nœud, et celles qui sont entièrement partagées entre les nœuds.

Non stocké dans etcd

La clé **** de chaque nœud n’est stockée que localement et n’est jamais partagée entre les nœuds.

Stocké dans etcd mais spécifique au nœud

Les données suivantes sont stockées dans etcd dans des portées différentes pour chaque nœud. Elles sont donc accessibles à chaque nœud, mais ne sont pas uniformes entre les nœuds (chaque nœud peut avoir une valeur différente pour ces données).

Configuration:

  • TLS certificates

  • Clock configuration

  • Network configuration

  • Logging configuration

  • Unattended boot configuration

  • Unlock salt (so each node has its own unlock passphrase)

  • Locked domain key

Notez que si chaque nœud possède sa propre version de la clé de domaine verrouillée (parce que chaque nœud la verrouille avec sa propre clé de dispositif ou phrase de passe de déverrouillage), la clé de domaine sous-jacente est partagée entre les nœuds (pour accéder à leurs données HSM partagées, telles que les clés).

Stocké dans etcd et partagé

Toutes les données suivantes sont stockées dans etcd dans la portée globale, de sorte qu’elles sont uniformes sur tous les nœuds d’un cluster :

Données HSM :

  • Keys

  • Utilisateurs

  • Espaces de noms

Configuration:

  • Config/domain store version

  • Cluster CA (used to authenticate nodes across cluster)

  • Backup passphrase and backup salt

Note that for now the config/domain store version can only be version 1 (if your software version supports clustering, then that is what you have). Refer to the Software Updates in Clusters section for more details on the safety of installing software updates within a cluster.

Creating a Cluster

Toute grappe démarre initialement avec un seul nœud. Les nouveaux nœuds rejoindront la grappe un par un.

Preparing Nodes

Le trafic réseau entre les nœuds est crypté et authentifié à l’aide de leur certificat TLS.

Tous les nœuds devant faire partie du même cluster doivent d’abord installer une autorité de certification (CA) commune qui leur permettra de vérifier que les autres nœuds sont légitimes.

Dans ce qui suit, nous supposons que tous les nœuds sont fraîchement approvisionnés et opérationnels.

Networking

Nodes must first be reconfigured with their expected final network configuration as described in the section Network.

Création et installation d’une AC

Les utilisateurs doivent créer une AC par leurs propres moyens et selon leurs propres contraintes opérationnelles, en s’assurant qu’elle autorise au moins l’utilisation de la clé keyCertSign.

Par exemple, une autorité de certification minimale peut être créée avec openssl :

$ 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

Cette autorité de certification doit maintenant être installée sur chaque nœud.

Pour ce faire, commencez par générer une demande de signature de certificat (CSR) à partir du nœud, comme décrit dans la section TLS Certificate. Avec nitropy, cette opération s’effectue à l’aide de la commande nitropy nethsm --host $NETHSM_HOST csr --api.

Note

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" ]

Avec nitropy, utilisez l’option --san, par exemple --san "IP:192.168.1.1".

Si vous souhaitez utiliser une autorité de certification publique pour signer vos certificats, vos nœuds doivent disposer d’adresses IP publiques. Cela est dû à une exigence de sécurité qui interdit à une autorité de certification publique de délivrer des certificats comportant une adresse IP privée dans le champ SAN « IP ».

Étant donné le CSR obtenu (appelons-le nethsm.csr), nous pouvons alors générer un certificat pour lui, prêt à être installé. Par exemple avec 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

Installez ensuite le fichier obtenu new_cert.pem comme décrit dans la section TLS Certificate (avec nitropy: nitropy nethsm --host $NETHSM_HOST set-certificate --api new_cert.pem).

Finally, the CA (CA.pem) can now be installed. This is only possible once the installed TLS certificate is signed by it. Otherwise, the operation will be rejected.

Arguments

Arguments

Description

FILENAME

The path of the CA file

Exemple

$ nitropy nethsm --host $NETHSM_HOST set-cluster-ca-certificate CA.pem

L’autorité de certification (CA) du cluster installée peut être consultée à l’adresse nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Note

Ce processus doit être répété pour chaque nœud.

Synchronisation de l’horloge

Assurez-vous que chaque nœud dispose d’une heure système exacte, de préférence en utilisant NTP/NTS plutôt qu’un réglage manuel. Cela peut être effectué via Time et NTS/NTP.

Adding a New Node

Adding a node to a cluster is done in three steps:

  1. Register the addition to the cluster (through any one of its members)

  2. Tell the new node to join

  3. Une fois qu’il a rattrapé son retard, faites passer le nœud du statut d’apprenant à celui de membre à part entière.

Configure a Backup Passphrase

First make sure a backup passphrase is configured on the node that will be used to register a new joiner as described in the section Backup.

Enregistrement d’un nouveau nœud

Ayez à portée de main l’adresse IP du nœud qui vous rejoindra. L’URL complète ** (également appelée peer URL dans la terminologie etcd) de ce nœud sera https://<IP_of_node>:2380 (par exemple https://192.168.1.1:2380). Le port doit être 2380, assurez-vous donc que tout pare-feu entre les nœuds autorise le trafic TCP sur ce port.

You can double-check the URL is correct by listing the cluster members on the node that is expected to join. This should list just one member: itself.

Exemple

$ nitropy nethsm --host $NETHSM_HOST list-cluster-members

Then register that expected URL on any existing node of the cluster (if you don’t have a cluster yet, do this on the NetHSM that will serve as the initial node of the cluster).

Options facultatives

Option

Description

--url TEXT

L’URL de pair du nouveau nœud (peut être définie plusieurs fois)

Arguments

Arguments

Description

JOIN_DATA_PATH

Le chemin d’accès au fichier dans lequel les données de jointure sont enregistrées

Exemple

$ nitropy nethsm --host $NETHSM_HOST add-cluster-member --url https://192.168.1.1:2380 join-data.json

Cette commande répertorie les membres du cluster et enregistre dans le fichier les données nécessaires au nouveau nœud pour rejoindre le cluster (y compris le kit d’intégration). Conservez ce fichier pour l’étape suivante.

Note

Notice in the list of members (learner: True in the nitropy output, "learner": true in the REST API response) that the new joiner is a « learner »: it can now connect to the cluster and receive data from it, but cannot participate until it is promoted, which will be covered below.

Bien que ce concept d”« apprenant » ajoute une étape supplémentaire (la promotion), il permet un fonctionnement plus sûr du cluster, car tout problème affectant le nouveau nœud ne peut pas entraîner d’instabilité au niveau de l’ensemble du cluster avant sa promotion.

Conservez le fichier de données de jointure pour l’étape suivante (ou la réponse, si vous avez utilisé l’API REST).

Joining the Cluster as a Learner

Rejoignez le cluster sur le nœud qui doit s’y intégrer, en utilisant les données de l’étape précédente et la phrase de passe de secours du nœud sur lequel le nouveau nœud a été enregistré.

Options requises

Option

Description

--backup-passphrase TEXT

La phrase de sécurité de sauvegarde du nœud sur lequel le nouvel utilisateur a été enregistré

Arguments

Arguments

Description

JOIN_DATA_PATH

Chemin d’accès au fichier de données de jointure de l’étape précédente

Exemple

$ nitropy nethsm --host $NETHSM_HOST join-cluster --backup-passphrase $BACKUP_PASSPHRASE join-data.json

Avertissement

The join call (nitropy nethsm join-cluster or POST /cluster/join) will hang until the new node is manually promoted (see below). This is normal. When the call returns successfully, it indicates that join and promotion have been successful. Don’t cancel this join call.

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.

À ce stade, le nouveau nœud a rejoint le cluster en tant que nœud « learner » ** : il est en cours de synchronisation avec le cluster, mais n’est pas encore opérationnel. En revanche, tout problème survenant sur ce nœud à ce stade n’aura aucune incidence sur le cluster, ce qui rend cette opération sans risque.

La dernière étape pour finaliser l’adhésion consiste à accorder au nouveau nœud le statut de membre à part entière.

Promoting the New Learner

En fonction des conditions du réseau et du cluster, le nouveau membre peut mettre un certain temps à se synchroniser avec le cluster. Une fois cette synchronisation effectuée, il peut passer du statut d”« apprenant » à celui de membre à part entière.

Avertissement

Promoting a node increases the cluster’s quorum threshold (refer to the API documentation and the Operational Redundancy section of this document). Ensure this new node has a stable connection to the cluster before promoting it.

Vous pouvez essayer de promouvoir le nouveau membre comme suit. L’identifiant du membre peut être obtenu en affichant la liste des membres du cluster.

Arguments

Arguments

Description

MEMBER_ID

The ID of the learner to be promoted

Exemple

$ nitropy nethsm --host $NETHSM_HOST promote-cluster-member $MEMBER_ID

Si l’apprenant n’a pas encore rattrapé son retard, l’opération échouera (code HTTP 412 dans l’API REST) et il faudra réessayer la promotion ultérieurement.

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

Vous aurez besoin d’un environnement avec etcd v3.6 disponible, avec une adresse IPv4 (au moins) accessible par les autres membres de votre cluster. Le trafic TCP vers et depuis le port 2380 doit être autorisé.

Créez un répertoire vide dans lequel etcd stockera ses données, et écrivez son chemin (nous utiliserons /var/etcd/data). Assurez-vous que l’utilisateur qui lancera le processus a le droit de lire et d’écrire dans le répertoire.

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.

Vous devrez ensuite créer un certificat pour le témoin et le signer avec l’autorité de certification afin qu’il puisse communiquer avec ses pairs. Cela peut se faire par exemple via openssl :

# 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

Stockez les résultats witness.key et witness.pem dans /var/etcd également.

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).

Keep the join data file written by nitropy nethsm add-cluster-member (or the response from the cluster, if you used the REST API): it contains the list of cluster members and a joiner kit (you won’t need this part).

Configure etcd

Contrairement aux NetHSM qui choisissent automatiquement un nom de nœud (à l’aide de l’ID de l’appareil), vous devez choisir un nom pour chaque témoin que vous ajoutez, en veillant à ce que les noms soient uniques. Nous utiliserons « witness1 » dans les exemples suivants.

Avec la réponse du NetHSM à l’enregistrement du témoin, préparer les variables du formulaire :

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,..."

Assuming the join data file written by nitropy (or the NetHSM REST API response) is stored in a response.json file, you can generate these last two variables automatically with the following jq expressions:

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"

Enfin, créez un fichier etcd.conf.yml en utilisant le fichier modèle fourni dans docs/etcd_witness.conf.template :

$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml

Vous obtiendrez ainsi un fichier du formulaire :

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

Démarrez etcd de la manière que vous préférez (manuellement, systemd service, conteneur, etc.), en le faisant pointer vers le fichier de configuration créé à l’étape précédente :

$ cd /var/etcd
$ etcd --config-file witness.conf.yml

Vous devriez le voir démarrer, rejoindre le cluster en tant qu”« apprenant » et se mettre à jour avec les données.

Promote the Witness

Enfin, après un certain temps, suivez les instructions habituelles de la rubrique « Promotion des nouveaux apprenants » ( ) pour promouvoir le témoin. Si cela ne fonctionne pas, réessayez plus tard.

After a successful promotion, you should be able to check that it is healthy with the etcdctl client:

etcdctl get /config/version

Cette clé doit exister et contenir « 1 ».

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

Sauvegarde et restauration

L’opération de sauvegarde fonctionne de la même manière qu’en l’absence de cluster et peut être demandée à partir de n’importe quel nœud du cluster. Elle sauvegarde les données de l’ensemble de la grappe, y compris les champs spécifiques aux nœuds (bien que ceux-ci soient ignorés si la sauvegarde n’est pas restaurée sur un nœud non provisionné).

Une sauvegarde effectuée sur un cluster peut être restaurée sur le même cluster, même si certains nœuds ont été ajoutés ou supprimés depuis. De telles restaurations effectuées sur des clusters opérationnels n’affecteront pas les valeurs de configuration (seulement les clés, les utilisateurs, les espaces de noms), comme toute autre restauration partielle.

La restauration d’une sauvegarde sur un nœud non provisionné rétablit les champs spécifiques au nœud (comme la configuration du réseau, les certificats, etc.) du nœud utilisé pour créer la sauvegarde.

La restauration d’une sauvegarde volumineuse peut surcharger le cluster pendant un certain temps, le temps que le nœud appliquant la restauration transmette les modifications aux autres nœuds.

Cette opération reste compatible avec les sauvegardes effectuées sur les versions précédentes du NetHSM.

Note

La restauration sur un nœud A d’une sauvegarde effectuée sur un autre nœud Z avec une clé de domaine différente réécrira correctement la clé de domaine de A, comme auparavant. Cependant, si A était dans un cluster avec le noeud B, B deviendra inopérant car la clé de domaine de Z ne sera pas restaurée sur B.

En d’autres termes, n’effectuez une restauration que dans un cluster dont les sauvegardes ont été effectuées dans le même cluster (bien que des nœuds aient pu être supprimés ou ajoutés depuis). Si vous souhaitez restaurer une sauvegarde étrangère sur un nœud, commencez par le retirer en toute sécurité de son cluster, puis réinitialisez-le et restaurez la sauvegarde.

Supprimer proprement un nœud

Tant qu’une partie de la grappe atteint le quorum, n’importe lequel de ses membres peut être utilisé pour retirer un autre nœud de la grappe, que ce nœud soit déjà inaccessible ou qu’il le devienne.

You first have to know the ID of the node you want to remove, by listing all nodes and looking for the right one. Then it can be removed. 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.

Arguments

Arguments

Description

MEMBER_ID

The ID of the node to be removed

Exemple

$ nitropy nethsm --host $NETHSM_HOST remove-cluster-member $MEMBER_ID

Note

Un nœud qui a rejoint le cluster mais qui n’a pas encore été promu peut également être supprimé en toute sécurité de cette manière.

Recovering a Failed Node

Un nœud signalant un état « Échec de la mise en service » ( ) refusera de répondre à la plupart des opérations normales. Il est toutefois possible de l’éteindre, de le redémarrer, de le réinitialiser, de le diagnostiquer ** ou de l’isoler ** .

Avertissement

L’existence des opérations « », « Failed », « ` », «diagnose` » et « ` » «force-new` » ne s’applique qu’à la version 5.0 et aux versions ultérieures. Dans la version 4.0, un nœud ayant perdu son quorum cessera de répondre à toutes les requêtes « » « ». Il doit être réinitialisé aux paramètres d’usine.

Parmi les causes courantes pouvant expliquer qu’un nœud se trouve dans l’état « Échec de l”» ( Failed ), on peut citer :

  • Un quorum perdu de manière durable ` <clustering.html#the-quorum-is-durably-lost>` __.

  • Une perte temporaire du quorum (par exemple, lors de l’ajout d’un deuxième nœud au cluster, alors que ce dernier n’a pas encore rejoint le cluster).

  • etcd est en cours de redémarrage (par exemple, parce que les certificats ont changé ou que le réseau a été reconfiguré).

  • Le cluster est soumis à une charge très élevée (par exemple, lors de la restauration d’une sauvegarde de très grande taille).

Quelle qu’en soit la cause, le NetHSM ne passera à l’état « Échec de l’ » ( Failed) qu’après au moins une minute complète de tentatives infructueuses d’interaction avec sa base de données. Cette mesure vise à éviter les transitions intempestives causées par des instabilités de très courte durée.

To help you understand which case your node is in, the diagnose function remains available and returns information about the current status of etcd and its database, including logs.

Exemple

$ nitropy nethsm --host $NETHSM_HOST get-cluster-diagnostics

Note

Si et lorsque la base de données redevient disponible (par exemple, lorsque le quorum est rétabli parce que le problème réseau a été résolu), le NetHSM passe automatiquement de l’état « Échec de l”» ( Failed) à l’état dans lequel il se trouvait auparavant (ou reprend la séquence de démarrage normale s’il était en cours de démarrage), sans qu’aucune intervention manuelle ne soit nécessaire. Il faudra compter jusqu’à une minute après la résolution du problème pour que le cluster se stabilise, que le HSM détecte la résolution et change d’état.

Si vous estimez que la défaillance est durable (par exemple, perte du quorum sans espoir de remédier à la situation sous-jacente), vous pouvez soit :

  • Réinitialisez le nœud aux paramètres d’usine: cette opération effacera toutes les données et restaurera une sauvegarde.

  • Isolate the node with nitropy nethsm force-new-cluster (REST API: POST /cluster/force-new), which will irreversibly forget all other cluster members, recover the etcd data present on disk and reboot. If the underlying failure was cluster-related, the node will follow the normal boot sequence and end up in either the Locked or Operational state depending on the unattended boot setting.

Note

If a node is isolated with force-new, it will desynchronized with the cluster: any new writes on it or the cluster cannot be reconciled. The node can still rejoin the cluster but will lose all its local modifications.

The force-new operation, which is only available in the Failed state, requires authentication as it is potentially destructive. However since HSM users and roles are not available in that state, the endpoint expects HTTPS clients to always authenticate with the unlock fake user, and the latest known unlock passphrase as the password. With nitropy, pass them as --username unlock --password $UNLOCK_PASSPHRASE:

$ nitropy nethsm --host $NETHSM_HOST --username unlock --password $UNLOCK_PASSPHRASE force-new-cluster

Avertissement

Après une mise à jour à partir d’une version antérieure à la 5.0, le point de terminaison force-new renverra systématiquement un statut « Non autorisé » tant que le HSM n’aura pas été déverrouillé ou que la phrase de passe de déverrouillage n’aura pas été modifiée au moins une fois.

Software Updates in Clusters

Les futures mises à jour seront marquées comme « cluster-safe » (ce qui devrait être la majorité) ou « cluster-unsafe ».

Les mises à jour sécurisées peuvent être appliquées aux nœuds qui font partie d’une grappe sans les retirer de la grappe au préalable. Toutefois, comme pour toutes les opérations, il convient de veiller à effectuer cette opération sur un seul nœud à la fois, et dans un cluster où la suppression d’un nœud n’entraîne pas une baisse du quorum (par exemple, si la mise à jour échoue).

Les mises à jour non sécurisées pour les clusters doivent être appliquées à des nœuds isolés. Vous devez démanteler le cluster (en supprimant les nœuds un par un), réinitialiser tous les nœuds sauf un, appliquer la mise à jour à chaque nœud, puis faire en sorte que tous les nœuds réinitialisés rejoignent le nœud restant.

Veillez à effectuer une sauvegarde avant de procéder à de telles opérations.

Reconfiguration d’un cluster existant

Changing the Cluster CA

Un cluster existant (avec deux nœuds ou plus) ne peut pas changer l’autorité de certification de son cluster en cours de fonctionnement. Si vous devez modifier ce certificat, choisissez un nœud, supprimez tous les autres nœuds, mettez à jour l’autorité de certification, puis demandez aux autres membres de se joindre à nouveau à la grappe.

Changing the Network Configuration of Nodes

La modification de la configuration réseau d’un nœud (par exemple, le changement de son IP) informera automatiquement les autres nœuds de la mise à jour. Vous devez toutefois veiller à n’effectuer ces mises à jour que sur un seul nœud à la fois, et dans un cluster où la perte de ce nœud n’entraînerait pas la perte du quorum.