Clustering

Notitie

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.

• Het is nog niet in een voldoende aantal productieomgevingen getest, en er kunnen fouten in zitten.

Vanaf NetHSM 4.0 wordt clustering ondersteund om gegevens tussen verschillende NetHSM’s direct te synchroniseren. Dit ondersteunt een hoge frequentie van sleutelgeneraties, realiseert hoge beschikbaarheid en load balancing. Een NetHSM cluster is gebaseerd op etcd die het Raft consensus algoritme gebruikt voor sterke consistentie. Dit zorgt ervoor dat de gegevens (bijv. sleutels) altijd correct zijn in alle NetHSM’s.

Maak jezelf vertrouwd met deze technologie en de beperkingen ervan voordat je een NetHSM cluster opzet om onbedoelde uitval en gegevensverlies te voorkomen. In aanvulling op dit document kun je ook etcd’s documentatie raadplegen.

Operational Redundancy

We noemen een “knooppunt” een NetHSM waarvan verwacht wordt dat het deel uitmaakt van een cluster. Een cluster van N nodes zal blijven werken zolang tenminste (N/2)+1 nodes gezond en bereikbaar zijn. Dat minimale aantal gezonde, bereikbare knooppunten wordt het quorum genoemd.

Op een cluster dat onder deze drempelwaarde komt (bijvoorbeeld vanwege een netwerkprobleem), kan er geen leider worden gekozen en kan de lokale instantie van etcd op elk knooppunt geen lees- en schrijfbewerkingen meer uitvoeren. Dit leidt tot de volgende scenario’s.

Eén node valt uit en het quorum is nog steeds bereikt

In een cluster met 3 knooppunten zullen, als er één knooppunt uitvalt (crasht of onbereikbaar wordt door netwerkomstandigheden), de twee andere knooppunten blijven werken en verzoeken bedienen.

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.

Als het apparaat zich niet herstelt, moet het uit het cluster worden verwijderd en ofwel een herstelprocedure ondergaan ` <clustering.html#recovering-a-failed-node>` __ om toegang te krijgen tot de gegevens (maar het zal dan geen deel meer uitmaken van het cluster), ofwel worden teruggezet naar de fabrieksinstellingen en het toetredingsproces helemaal opnieuw doorlopen.

Er vindt een netwerkscheiding plaats en het quorum is nog steeds bereikt

Dit is slechts een veralgemening van het vorige scenario. In een cluster van 5 knooppunten waar zich bijvoorbeeld 3 knooppunten op een fysieke locatie A bevinden en 2 knooppunten op een andere locatie B, zou een netwerkprobleem dat A en B isoleert het volgende betekenen:

• De 3 knooppunten op locatie A voldoen aan het quorum (3 in dit geval), dus ze blijven werken.

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

• Als het netwerkprobleem is opgelost, zullen de 2 knooppunten netjes terug aansluiten bij de 3 anderen.

Met andere woorden: bij een netwerkpartitie in het ergste geval (in een cluster met een oneven aantal knooppunten) blijft de grotere helft van het cluster intact, terwijl de kleinere helft buiten werking blijft totdat de partitie is verholpen.

Het Quorum is duurzaam 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 must be performed.

Dit kan bijvoorbeeld gebeuren als een enkel knooppunt faalt in een cluster met 2 knooppunten (waar het quorum 2 is). In deze situatie kan het defecte knooppunt achteraf niet netjes uit het cluster verwijderd worden, omdat het overgebleven gezonde knooppunt al onbruikbaar is omdat het quorum verloren is gegaan.

Daarom wordt geadviseerd om altijd een oneven aantal nodes in een cluster te hebben en om vaak een back-up te maken.

Om duidelijk te zijn, tijdelijk quorum verliezen (bijvoorbeeld als je alle nodes van een cluster samen herstart, of een tijdelijke netwerkstoring nodes isoleert) is geen probleem: zodra genoeg nodes opnieuw verbonden zijn (zonder handmatig opnieuw te moeten verbinden) om quorum te bereiken, zal het cluster zijn normale werking hervatten. Alleen permanente storingen zoals netwerkpartities, netwerkfoutconfiguraties, authenticatieproblemen of hardwarestoringen vereisen handmatige actie.

Zie voor meer informatie etcd’s FAQ.

2-node cluster

Een actief/passief cluster met twee knooppunten wordt nog niet ondersteund en zal in een toekomstige versie worden toegevoegd. We raden aan om een 3de node te introduceren, ofwel een 3de NetHSM of een etcd “getuige” die op elke host kan draaien. Zie de volgende sectie “Getuige”.

Getuige

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.

De functie is echter zo ontworpen dat je geen volledig, echt NetHSM-apparaat aan je cluster hoeft toe te voegen om een stabiel aantal knooppunten te bereiken. In plaats daarvan kun je zelf een “getuige” knooppunt implementeren en toevoegen. Zo’n knooppunt is gewoon een instantie van etcd die op een machine naar keuze (of in een container) draait en verbonden is met het cluster. Het wordt herkend als een normaal knooppunt van de echte apparaten in het cluster en ontvangt alle gegevens en updates van apparaten (maar natuurlijk kun je er geen HSM-bewerkingen mee uitvoeren - het slaat alleen gegevens op).

Security Considerations

Het witness knooppunt (of iedereen die daar toegang toe heeft) heeft direct toegang tot de opslag backend van alle knooppunten in het cluster (je kunt bijvoorbeeld alle entries en bijbehorende waarden dumpen met etcdctl get "/" "0").

Echter, met uitzondering van de config versie (/config/version, die altijd “1” moet zijn), worden strikt alle waarden versleuteld (met ofwel een apparaatsleutel voor knooppuntspecifieke waarden of de domeinsleutels voor andere waarden), waardoor de vertrouwelijkheid van gevoelige gegevens wordt gegarandeerd.

Merk echter op dat een kwaadwillende node:

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

Wat wordt gedeeld tussen knooppunten

Een cluster van NetHSM’s betekent dat de meeste gegevens tussen hen gedeeld worden. Elke toevoeging, wijziging of verwijdering van sleutels, gebruikers of naamruimten op één knooppunt wordt uiteindelijk weerspiegeld op alle andere knooppunten. In het algemeen zal elke bewerking die de toestand wijzigt, de toestand op elk knooppunt wijzigen. Dit is inclusief de backup restore operatie die normaal werkt.

De volgende secties laten zien welke gegevens volledig lokaal zijn, welke gegevens zijn opgeslagen in de gedeelde etcd opslag maar node-specifiek blijven en welke gegevens volledig gedeeld worden tussen nodes.

Niet opgeslagen in etcd

De apparaatsleutel van elk knooppunt blijft alleen lokaal opgeslagen en wordt nooit gedeeld tussen knooppunten.

Opgeslagen in etcd maar node-specifiek

De volgende gegevens worden opgeslagen in etcd in verschillende scopes voor elk knooppunt. Het is daarom toegankelijk voor elk knooppunt, maar niet uniform tussen knooppunten (elk knooppunt kan een andere waarde voor deze gegevens hebben).

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

Merk op dat terwijl elk knooppunt zijn eigen versie van de vergrendelde domeinsleutel heeft (omdat elk knooppunt deze vergrendelt met zijn eigen apparaatsleutel of ontgrendelingswachtzin), de onderliggende domeinsleutel gedeeld wordt over knooppunten (om toegang te krijgen tot hun gedeelde HSM-gegevens, zoals sleutels).

Opgeslagen in etcd en gedeeld

Alle volgende gegevens worden opgeslagen in etcd in het globale bereik, zodat ze uniform zijn voor alle knooppunten van een cluster:

HSM-gegevens:

• Keys

• Gebruikers

• Naamruimten

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

Elk cluster zal initieel starten met een enkel knooppunt. Nieuwe knooppunten voegen zich één voor één bij het cluster.

Preparing Nodes

Netwerkverkeer tussen nodes wordt versleuteld en geverifieerd met behulp van hun TLS-certificaat.

Alle nodes waarvan verwacht wordt dat ze deel uitmaken van hetzelfde cluster moeten eerst een gemeenschappelijke Certificate Authority (CA) installeren waarmee ze kunnen verifiëren dat andere nodes legitiem zijn.

In het volgende gaan we ervan uit dat alle knooppunten pas beschikbaar en operationeel zijn.

Networking

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

Een CA aanmaken en installeren

Gebruikers moeten op hun eigen manier en volgens hun eigen operationele beperkingen een CA aanmaken, en ervoor zorgen dat deze op zijn minst het gebruik van de sleutel keyCertSign toestaat.

Een minimale CA kan bijvoorbeeld aangemaakt worden met 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

Deze CA moet nu op elk knooppunt geïnstalleerd worden.

Om dit te doen, moet je eerst een Certificate Signing Request (CSR) genereren vanaf het knooppunt, zoals beschreven in de paragraaf TLS-certificaat. Met nitropie doe je dit met nitropy nethsm --host $NETHSM_HOST csr --api.

Notitie

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

Gebruik bij nitropie de optie --san, bijvoorbeeld --san "IP:192.168.1.1".

Als je een openbare CA wilt gebruiken voor het ondertekenen van je certificaten, moeten je knooppunten openbare IP-adressen gebruiken. Dit komt door een beveiligingsvereiste die een openbare CA verbiedt om certificaten uit te geven met een privé-IP-adres in de IP-SAN.

Gegeven het verkregen CSR (laten we het nethsm.csr noemen), kunnen we er een certificaat voor genereren, klaar om geïnstalleerd te worden. Bijvoorbeeld met 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

Installeer vervolgens het verkregen new_cert.pem zoals beschreven in de paragraaf TLS-certificaat (met nitropie: 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.

nitropyREST API

Argumenten

Argument	Beschrijving
FILENAME	The path of the CA file

Voorbeeld

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

De geïnstalleerde cluster-CA kan worden opgehaald via nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Notitie

Dit proces moet voor elk knooppunt herhaald worden.

Klok Synchronisatie

Zorg ervoor dat elk knooppunt is voorzien van een nauwkeurige systeemtijd, bij voorkeur via NTP/NTS in plaats van handmatige tijdinstelling. Dit kan worden geregeld via Time en NTS/NTP configuratie.

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. Zodra het zijn achterstand heeft ingehaald, promoveer je het knooppunt van leerling tot volwaardig lid

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.

Een nieuwe node registreren

Houd het IP-adres bij de hand van het knooppunt dat zich zal aansluiten. De volledige URL (ook wel peer URL genoemd in etcd terminologie) van dat knooppunt zal https://<IP_of_node>:2380 zijn (bijvoorbeeld https://192.168.1.1:2380).** De poort **moet 2380 zijn, dus zorg ervoor dat een firewall tussen de knooppunten TCP-verkeer op die poort toestaat.

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.

nitropyREST API

Voorbeeld

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

nitropyREST API

Optionele opties

Optie	Beschrijving
--url TEXT	De peer-URL van het nieuwe knooppunt (kan meerdere keren worden ingesteld)

Argumenten

Argument	Beschrijving
JOIN_DATA_PATH	Het pad naar het bestand waarin de samengevoegde gegevens worden opgeslagen

Voorbeeld

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

Het commando geeft een overzicht van de clusterleden en schrijft de gegevens die het nieuwe knooppunt nodig heeft om zich bij het cluster aan te sluiten (inclusief de joiner-kit) naar het bestand. Bewaar dit bestand voor de volgende stap.

Notitie

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.

Hoewel dit concept van „learner“ een extra stap (promotie) met zich meebrengt, zorgt het voor een veiligere werking van het cluster, aangezien een eventueel probleem met het nieuwe knooppunt geen instabiliteit in het hele cluster kan veroorzaken voordat het wordt gepromoveerd.

Bewaar het koppelingsgegevensbestand voor de volgende stap (of het antwoord, als je de REST API hebt gebruikt).

Joining the Cluster as a Learner

Sluit je aan bij het cluster op het knooppunt dat zich naar verwachting zal aansluiten, met behulp van de gegevens uit de vorige stap en de back-up-toegangscode van het knooppunt waarop de nieuwe deelnemer is geregistreerd.

nitropyREST API

Verplichte opties

Optie	Beschrijving
--backup-passphrase TEXT	De back-upwachtzin van het knooppunt waarop de nieuwe deelnemer is geregistreerd

Argumenten

Argument	Beschrijving
JOIN_DATA_PATH	Het pad naar het samenvoegingsgegevensbestand uit de vorige stap

Voorbeeld

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

Waarschuwing

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.

In dit stadium is het nieuwe knooppunt toegevoegd als een ‘ ’ leer- -knooppunt: het is bezig met synchroniseren met het cluster, maar is nog niet operationeel. Aan de andere kant zal een eventueel probleem met het knooppunt in dit stadium geen gevolgen hebben voor het cluster, waardoor deze handeling veilig is.

De laatste stap om de toetreding af te ronden, is het nieuwe lid tot volwaardig lid te benoemen.

Promoting the New Learner

Afhankelijk van de netwerk- en clusteromstandigheden kan het even duren voordat het nieuwe lid de achterstand op het cluster heeft ingehaald. Zodra dit is gebeurd, kan het worden gepromoveerd van leerling tot volwaardig lid.

Waarschuwing

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.

Je kunt het nieuwe lid als volgt promoten. Je kunt het lid-ID vinden door de clusterleden weer te geven.

nitropyREST API

Argumenten

Argument	Beschrijving
MEMBER_ID	The ID of the learner to be promoted

Voorbeeld

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

Als de cursist de achterstand nog niet heeft ingehaald, zal dit mislukken (HTTP-code 412 in de REST API) en moet de overgang later opnieuw worden geprobeerd.

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

Je hebt een omgeving nodig met etcd v3.6 beschikbaar, met (minstens) een IPv4-adres dat bereikbaar is voor de andere leden van je cluster. TCP-verkeer van en naar poort 2380 moet worden toegestaan.

Maak een lege map aan waar etcd zijn gegevens zal opslaan en schrijf het pad op (we gebruiken /var/etcd/data). Zorg ervoor dat de gebruiker die het proces zal starten lees- en schrijfrechten heeft in de map.

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.

Je moet dan een certificaat aanmaken voor de getuige en het ondertekenen met de CA zodat het kan communiceren met zijn peers. Dit kan bijvoorbeeld 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

Sla de resulterende witness.key en witness.pem ook op 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).

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

In tegenstelling tot NetHSM’s die automatisch een knooppuntnaam voor zichzelf kiezen (met behulp van het apparaat-ID), moet je een naam kiezen voor elke getuige die je toevoegt, zorg ervoor dat de namen uniek zijn. We zullen “witness1” gebruiken in de volgende voorbeelden.

Met het antwoord van de NetHSM op de registratie van de getuige, maak je variabelen van het formulier:

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"

Maak tenslotte een etcd.conf.yml bestand aan door het sjabloonbestand te gebruiken dat is geleverd in docs/etcd_witness.conf.template:

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

Dit zou je een bestand van het formulier moeten geven:

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

Start etcd op de gewenste manier (handmatig, systemd service, container, etc.) en wijs het naar het configuratiebestand dat in de vorige stap is gemaakt:

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

Je zou moeten zien dat het opstart, dat je als leerling lid wordt van het cluster en dat je de gegevens inhaalt.

Promote the Witness

Volg ten slotte, na enige tijd, de gebruikelijke instructies uit de sectie „ : Promoting the New Learner” om de getuige te bevorderen. Probeer het later nog eens als dit niet lukt.

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

etcdctl get /config/version

Deze sleutel moet bestaan en “1” bevatten.

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

Back-up en herstel

De back-upbewerking werkt hetzelfde als zonder cluster en kan vanaf elk knooppunt van het cluster worden aangevraagd. Er wordt een back-up gemaakt van gegevens voor het hele cluster, inclusief node-specifieke velden (deze worden echter genegeerd tenzij de back-up op een niet geprovisioneerd knooppunt wordt teruggezet).

Een back-up die op een cluster is gemaakt, kan op hetzelfde cluster worden teruggezet, zelfs als er sindsdien enkele nodes zijn toegevoegd of verwijderd. Zulke terugzettingen op operationele clusters hebben geen invloed op de configuratiewaarden (alleen sleutels, gebruikers, naamruimten), net als alle andere gedeeltelijke terugzettingen.

Als je een back-up herstelt op een knooppunt zonder voorzieningen, worden de knooppuntspecifieke velden (zoals netwerkconfiguratie, certificaten, enzovoort) hersteld van het knooppunt dat werd gebruikt om de back-up te maken.

Het terugzetten van een grote back-up kan het cluster enige tijd overspoelen, terwijl het knooppunt dat de restore uitvoert wijzigingen doorstuurt naar de anderen.

Deze bewerking blijft compatibel met back-ups die op eerdere versies van de NetHSM zijn gemaakt.

Notitie

Het terugzetten op een knooppunt A van een back-up gemaakt op een ander knooppunt Z met een andere domeinsleutel zal de domeinsleutel van A correct herschrijven, zoals voorheen. Maar als A in een cluster met node B zat, zal B onbruikbaar worden omdat de domeinsleutel van Z niet hersteld zal worden op B.

Met andere woorden, voer alleen een restore uit in een cluster met back-ups die in hetzelfde cluster zijn gemaakt (hoewel er sindsdien nodes verwijderd of toegevoegd kunnen zijn). Als je een buitenlandse back-up op een node wilt terugzetten, verwijder deze dan eerst veilig uit zijn cluster, reset hem dan in de fabriek en zet de back-up terug.

Een node netjes verwijderen

Zolang een deel van het cluster nog aan het quorum voldoet, kan elk van zijn leden gebruikt worden om een ander knooppunt uit het cluster te verwijderen, ongeacht of dit knooppunt al onbereikbaar is of naar verwachting zal zijn.

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.

nitropyREST API

Argumenten

Argument	Beschrijving
MEMBER_ID	The ID of the node to be removed

Voorbeeld

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

Notitie

Een knooppunt dat zich bij het cluster heeft aangesloten maar nog niet is gepromoveerd, kan op deze manier ook veilig worden verwijderd.

Recovering a Failed Node

Een knooppunt dat de status ‘ ’ of ‘Failed’ meldt, zal niet reageren op de meeste normale bewerkingen. Het kan nog steeds worden uitgeschakeld, opnieuw opgestart, gereset , gediagnosticeerd of geïsoleerd ** .

Waarschuwing

De bewerkingen Failed state, diagnose en force-new zijn alleen van toepassing op versie 5.0 en hoger. In versie 4.0 reageert een knooppunt dat zijn quorum heeft verloren niet meer op alle verzoeken. Het moet worden teruggezet naar de fabrieksinstellingen.

Veelvoorkomende oorzaken waardoor een knooppunt zich in de status „ Failed“ bevindt, zijn onder meer:

• Een blijvend verloren quorum.

• Een tijdelijk ontbrekend quorum (bijvoorbeeld wanneer een tweede knooppunt aan het cluster wordt toegevoegd en het tweede knooppunt nog niet is aangesloten).

• etcd wordt momenteel opnieuw opgestart (bijvoorbeeld omdat de certificaten zijn gewijzigd of omdat het netwerk opnieuw is geconfigureerd).

• Het cluster wordt zwaar belast (bijvoorbeeld tijdens het terugzetten van een zeer grote back-up).

Wat de oorzaak ook moge zijn, de NetHSM zal pas overgaan naar de status „ Failed” na ten minste een volle minuut van mislukte pogingen om verbinding te maken met de database. Dit is om onterechte overgangen als gevolg van zeer kortstondige instabiliteiten te voorkomen.

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.

nitropyREST API

Voorbeeld

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

Notitie

Zodra de database weer beschikbaar is (bijvoorbeeld wanneer het quorum is hersteld omdat het netwerkprobleem is opgelost), zal de NetHSM automatisch vanuit de status ‘ Failed’ overschakelen naar de status waarin hij zich eerder bevond (of de normale opstartvolgorde hervatten als hij aan het opstarten was), zonder dat er handmatige actie nodig is. Het duurt maximaal een minuut nadat het probleem is opgelost voordat het cluster zich heeft gestabiliseerd, de HSM de oplossing heeft gedetecteerd en van status is veranderd.

Als je tot de conclusie komt dat de storing van blijvende aard is (bijvoorbeeld een verloren quorum zonder uitzicht op een oplossing voor de onderliggende oorzaak), kun je het volgende doen:

• Zet het apparaat terug naar de fabrieksinstellingen ( ) en voer een back-up terug.

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

Notitie

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

Waarschuwing

Na een update vanaf een versie < 5.0 zal het eindpunt force-new altijd de status „Unauthorized“ hebben, totdat de HSM is ontgrendeld of de ontgrendelingswachtwoordzin ten minste één keer is gewijzigd.

Software Updates in Clusters

Toekomstige updates zullen gemarkeerd worden als “cluster-veilig” (dit zou de meerderheid moeten zijn) of “cluster-onveilig”.

Cluster-veilige updates kunnen worden toegepast op knooppunten die deel uitmaken van een cluster zonder ze eerst uit het cluster te verwijderen. Maar zoals met alle operaties, moet je ervoor zorgen dat je dit op één node per keer doet, en in een cluster waar het verwijderen van een node het quorum niet onderschrijdt (bijvoorbeeld als de update mislukt).

Cluster-onveilige updates moeten worden toegepast op geïsoleerde nodes. Je moet het cluster ontmantelen (knooppunten één voor één verwijderen), alle knooppunten op één na in de fabriek resetten, de update op elk knooppunt toepassen en vervolgens alle geresette knooppunten laten aansluiten op het overgebleven knooppunt.

Zorg ervoor dat u een back-up maakt voordat u dergelijke bewerkingen uitvoert.

Een bestaand cluster herconfigureren

Changing the Cluster CA

Een bestaand cluster (met twee of meer nodes) kan zijn cluster-CA niet wijzigen terwijl het in werking is. Als je dit certificaat moet wijzigen: kies een knooppunt, verwijder alle andere knooppunten, werk de CA bij en laat de andere leden zich weer aansluiten.

Changing the Network Configuration of Nodes

Het wijzigen van de netwerkconfiguratie van een knooppunt (bijvoorbeeld het wijzigen van het IP-adres) zal automatisch de andere knooppunten informeren over de update. Je moet er echter voor zorgen dat je zulke updates alleen uitvoert op een enkel knooppunt tegelijk en in een cluster waar het verlies van dat knooppunt het quorum niet zou verliezen.