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.
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 <clustering.html#recovering-a-failed-node> 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¶
La nature du clustering avec etcd le rend d’autant plus fiable qu’il y a de nœuds dans le cluster. Comme expliqué dans la section Operational Redundancy, les clusters devraient idéalement avoir au moins 3 noeuds pour avoir la possibilité de tomber en panne, puisqu’un cluster à 2 noeuds tombera entièrement en panne si un seul tombe en panne.
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.
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 using the /config/network endpoint (refer to the API documentation).
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.
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).
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" ]
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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Enfin, l’autorité de certification (CA.pem) peut maintenant être installée à l’aide du point de terminaison /config/tls/cluster-ca.pem (voir la documentation de l’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Cela n’est possible que lorsque le certificat TLS installé est signé par l’AC. Sinon, l’opération sera rejetée.
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:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
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¶
Assurez-vous d’abord qu’une phrase de passe de sauvegarde est configurée sur le nœud qui sera utilisé pour enregistrer un nouveau joiner (voir la documentation API du point de terminaison /config/backup-passphrase).
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.
Vous pouvez vérifier que l’URL est correcte en appelant GET /cluster/members sur le nœud qui est censé se joindre. La liste ne devrait contenir qu’un seul membre : lui-même.
Enregistrez ensuite l’URL attendue sur n’importe quel nœud existant du cluster (si vous n’avez pas encore de cluster, faites-le sur le NetHSM qui servira de nœud initial du cluster). Cela se fait en utilisant le point de terminaison POST /cluster/members (voir la documentation de l’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), en lui transmettant un corps JSON contenant l’URL.
En cas de succès, il renvoie un corps JSON du formulaire :
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
qui contient les informations nécessaires pour que le nouveau nœud rejoigne la grappe. En particulier, il dresse la liste de tous les membres de la grappe (le membre dont le nom est vide étant le nouveau membre). Il contient également la clé de domaine cryptée par les phrases de déverrouillage et de sauvegarde - une phrase de sauvegarde doit donc avoir été configurée auparavant.
Note
Notez dans la réponse ci-dessus que le nouvel élément ajouté est un « apprenant » : il peut désormais se connecter au cluster et recevoir des données de celui-ci, mais ne peut pas y participer tant qu’il n’a pas été promu, ce qui sera abordé ci-dessous.
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 cette réponse pour l’étape suivante.
Joining the Cluster as a Learner¶
Prenez la réponse de la dernière étape et ajoutez-y un champ backupPassphrase contenant la phrase de passe de sauvegarde du nœud sur lequel le nouveau membre a été enregistré, et passez ces données à un appel à POST /cluster/join (reportez-vous à la documentation de l’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) sur le nœud qui est censé rejoindre.
Avertissement
L’appel à la méthode ` `` POST /cluster/join` restera en attente jusqu’à ce que le nouveau nœud soit promu manuellement (voir ci-dessous). Ceci est normal. Lorsque l’appel renvoie un résultat positif, cela indique que l’ajout et la promotion ont abouti.
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
La promotion d’un nœud augmente le seuil de quorum du cluster (voir la documentation de l’API « » et la section « Redondance opérationnelle » de « » du présent document). Assurez-vous que ce nouveau nœud dispose d’une connexion stable au cluster avant de le promouvoir.
Vous pouvez essayer de promouvoir le nouveau membre en appelant la méthode POST /cluster/members/{MemberID}/promote (voir la documentation de l’API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Si l’apprenant n’a pas encore rattrapé son retard, l’opération échouera avec le code HTTP 412 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).
Notez la réponse du cluster : elle doit contenir la liste des membres du cluster et un kit de l’adhérent (vous n’aurez pas besoin de cette partie).
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,..."
En supposant que la réponse du NetHSM soit stockée dans un fichier response.json, vous pouvez générer ces deux dernières variables automatiquement avec les expressions suivantes jq :
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.
Vous devez d’abord connaître l’ID du nœud que vous voulez supprimer, en listant tous les nœuds via GET /cluster/members et en cherchant le bon.
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.
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).
etcdest 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.
Pour vous aider à déterminer dans quel état se trouve votre nœud, le point de terminaison GET /health/diagnose reste disponible et renvoie des informations sur l’état actuel de etcd et de sa base de données, y compris les journaux (voir la documentation de l’API).
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.
Isolez le nœud à l’aide du point de terminaison
POST /cluster/force-new, ce qui entraînera l’oubli irréversible de tous les autres membres du cluster, la récupération des donnéesetcdprésentes sur le disque et le redémarrage du système. Si la défaillance sous-jacente était liée au cluster, le nœud suivra la séquence de démarrage normale et se retrouvera soit dans l’état Locked, soit dans l’état Operational, en fonction du paramètre de démarrage sans surveillance.
Note
Si un nœud est isolé à l’aide de la commande force-new, il sera désormais désynchronisé par rapport au cluster : toute nouvelle écriture effectuée sur ce nœud ou sur le cluster ne pourra pas être synchronisée. Le nœud pourra toujours rejoindre le cluster, mais perdra toutes ses modifications locales.
Le point de terminaison « ` » `POST /cluster/force-new``, qui n’est disponible que lorsque l’état du système est « Failed » (Échec), nécessite une authentification car il est potentiellement destructeur. Cependant, étant donné que les utilisateurs et les rôles HSM ne sont pas disponibles dans cet état, le point de terminaison s’attend à ce que les clients HTTPS s’authentifient systématiquement avec l’utilisateur fictif « ` » unlock` et en utilisant comme mot de passe la dernière phrase de déverrouillage connue.
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.