Clustering

Observera

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.

• Det har ännu inte testats i tillräckligt många produktionsmiljöer, och det kan förekomma buggar.

NetHSM 4.0 och framåt stöder klustring för att synkronisera data direkt mellan flera NetHSM. Detta stödjer hög frekvens av nyckelgenereringar, hög tillgänglighet och lastbalansering. Ett NetHSM-kluster är baserat på etcd som använder Raft konsensusalgoritm för stark konsistens. Detta säkerställer att data (t.ex. nycklar) är korrekta i alla NetHSM:er vid alla tidpunkter.

Innan du sätter upp ett NetHSM-kluster bör du bekanta dig med denna teknik och dess begränsningar för att undvika oavsiktliga avbrott och dataförlust. Förutom det här dokumentet kan du även läsa etcd:s dokumentation.

Operational Redundancy

Vi kallar ”nod” för en NetHSM som förväntas ingå i ett kluster. Ett kluster med N noder fortsätter att fungera så länge som minst (N/2)+1 noder är friska och nåbara. Den minimala mängden friska, nåbara noder kallas quorum.

I ett kluster som hamnar under denna tröskel (t.ex. på grund av ett nätverksproblem) kan ingen ledare väljas, och den lokala instansen av etcd på varje nod kan inte längre utföra läs- och skrivoperationer. Detta innebär följande scenarier.

En nod går ner och Quorum uppnås ändå

I ett kluster med tre noder fortsätter de två andra noderna att fungera och hantera förfrågningar om en nod misslyckas (kraschar eller blir oåtkomlig på grund av nätverksförhållanden).

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.

Om den aldrig återhämtar sig måste den tas bort från klustret och antingen genomgå återställning för att man ska kunna komma åt dess data (men den kommer då inte längre att ingå i klustret), eller återställas till fabriksinställningarna och genomgå anslutningsprocessen på nytt från början.

En nätverksdelning inträffar och kvorum uppnås fortfarande

Detta är bara en generalisering av det föregående scenariot. I ett kluster med 5 noder där t.ex. 3 noder befinner sig på en fysisk plats A och 2 noder på en annan plats B, skulle ett nätverksproblem som isolerar A och B innebära följande:

• De 3 noderna på plats A uppfyller kravet på kvorum (3 i det här fallet), så de fortsätter att fungera.

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

• Om nätverksproblemet är löst kommer de två noderna att ansluta sig till de tre andra noderna.

Med andra ord kommer en nätverksuppdelning i värsta fall (i ett kluster med ett udda antal noder) att leda till att den större halvan av klustret förblir funktionsduglig, medan den mindre halvan blir ur funktion tills uppdelningen har åtgärdats.

Quorum är varaktigt förlorat

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.

Detta kan t.ex. hända om en enda nod går sönder i ett kluster med 2 noder (där kvorum är 2). I den här situationen kan den felande noden inte tas bort från klustret i efterhand, eftersom den kvarvarande friska noden redan är ur funktion eftersom den har förlorat kvorum.

Därför rekommenderas det att alltid ha ett udda antal noder i ett kluster och att säkerhetskopiera ofta.

För att förtydliga är ** tillfälligt förlorat kvorum (t.ex. om du startar om alla noder i ett kluster tillsammans, eller om ett tillfälligt nätverksfel isolerar noder) inte ett problem: när tillräckligt många noder har återanslutits (utan att behöva återanslutas manuellt) för att nå kvorum kommer klustret att återuppta sin normala drift. Endast permanenta fel, t.ex. nätverksdelningar, felkonfigurationer i nätverket, autentiseringsproblem eller maskinvarufel, kräver manuell åtgärd.

Mer information finns i etcd:s VANLIGA FRÅGOR.

Kluster med 2 noder

Ett aktivt/passivt kluster med två noder stöds inte ännu, men kommer att läggas till i en framtida version. Vi rekommenderar att du inför en tredje nod, antingen en tredje NetHSM eller ett etcd-”vittne” som kan användas på vilken värd som helst. Se nästa avsnitt ”Vittne”.

Vittne

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.

Funktionen är dock utformad så att du inte behöver lägga till en fullständig, riktig NetHSM-enhet i ditt kluster för att nå ett stabilt antal noder. Istället kan du själv distribuera och lägga till en ”vittnes”-nod. En sådan nod är bara en instans av etcd som körs på den maskin du väljer (eller i en container) och är ansluten till klustret. Den kommer att identifieras som en normal nod av de riktiga enheterna i klustret och ta emot alla data och uppdateringar från enheterna (men du kommer naturligtvis inte att kunna utföra några HSM-operationer med den - den lagrar bara data).

Security Considerations

Vittnesnoden (eller någon med tillgång till den) har direkt tillgång till lagringsbackend för alla noder i klustret (t.ex. kan du dumpa alla poster och motsvarande värden med etcdctl get "/" "0").

Med undantag för konfigurationsversionen (/config/version, som alltid ska vara ”1”) är dock alla värden krypterade (med antingen en enhetsnyckel för nodspecifika värden eller domännycklar för andra), vilket säkerställer sekretessen för känsliga data.

Observera dock att en illasinnad nod kan:

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

Vad som delas mellan noderna

Att ha ett kluster av NetHSM:er innebär att de flesta data delas mellan dem. Alla tillägg, ändringar eller borttagningar av nycklar, användare eller namnrymder på en nod återspeglas så småningom på alla de andra. I allmänhet kommer alla operationer som ändrar tillstånd att ändra tillstånd för alla noder. Detta inkluderar åtgärden backup restore som fungerar som vanligt.

I följande avsnitt beskrivs vilka data som är helt lokala, vilka data som lagras i det delade etcd-lagret men som förblir nodspecifika och vilka data som är helt delade mellan noderna.

Inte lagrad i etcd

enhetsnyckel för varje nod lagras endast lokalt och delas aldrig mellan noderna.

Lagrad i etcd men Node-specifik

Följande data lagras i etcd i olika scopes för varje nod. Den är därför tillgänglig för varje nod men inte enhetlig mellan noderna (varje nod kan ha ett annat värde för denna data).

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

Observera att även om varje nod har sin egen version av den låsta domännyckeln (eftersom varje nod låser den med sin egen enhetsnyckel eller upplåsningspassfras), delas den underliggande domännyckeln **** mellan noderna (för åtkomst till deras delade HSM-data, t.ex. nycklar).

Lagrad i etcd och delad

Alla följande data lagras i etcd i det globala omfånget, så att de är enhetliga över alla noder i ett kluster:

HSM-data:

• Keys

• Användare

• Namnområden

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

Varje kluster startar från början med en enda nod. Nya noder kommer att ansluta sig till klustret en efter en.

Preparing Nodes

Nätverkstrafiken mellan noderna krypteras och autentiseras med hjälp av deras TLS-certifikat.

Alla noder som förväntas ingå i samma kluster måste först installera en gemensam certifikatutfärdare (CA) som gör det möjligt för dem att verifiera att andra noder är legitima.

I det följande utgår vi från att alla noder är nyligen provisionerade och i drift.

Networking

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

Skapa och installera en certifikatutfärdare

Användare bör skapa en CA på sina egna sätt och enligt sina egna operativa begränsningar, och se till att den tillåter åtminstone keyCertSign nyckelanvändning.

En minimal CA kan t.ex. skapas med 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

Denna CA måste nu installeras på varje nod.

För att göra detta ska du först skapa en certifikatsigneringsbegäran (CSR) från noden enligt beskrivningen i avsnittet TLS-certifikat. Med nitropy görs detta med nitropy nethsm --host $NETHSM_HOST csr --api.

Observera

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

Med nitropy använder du alternativet --san, t.ex. --san "IP:192.168.1.1".

Om du vill använda en offentlig certifikatutfärdare (CA) för att signera dina certifikat måste dina noder använda offentliga IP-adresser. Detta beror på ett säkerhetskrav som förbjuder en offentlig certifikatutfärdare att utfärda certifikat med en privat IP-adress i IP-SAN.

Med den erhållna CSR:n (låt oss kalla den nethsm.csr) kan vi sedan generera ett certifikat för den, klart att installeras. Till exempel med 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

Installera sedan den hämtade filen new_cert.pem enligt beskrivningen i avsnittet TLS-certifikat (med 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.

nitropyREST API

Argument

Argument	Beskrivning
FILENAME	The path of the CA file

Exempel

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

Det installerade kluster-CA:t kan hämtas med nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Observera

Denna process måste upprepas för varje nod.

Klocksynkronisering

Se till att varje nod har konfigurerats med en korrekt systemtid, helst med hjälp av NTP/NTS istället för manuell tidsinställning. Detta kan göras genom Time och NTS/NTP konfiguration.

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. När den har hunnit ikapp ska noden befordras från lärling till fullvärdig medlem

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.

Registrering av en ny nod

Ha till hands IP-adressen för den nod som ska ansluta sig. Den fullständiga URL (även kallad peer URL i etcd terminologi) för den noden kommer att vara https://<IP_of_node>:2380 (t.ex. https://192.168.1.1:2380). Porten måste vara 2380, så se till att alla brandväggar mellan noderna tillåter TCP-trafik på den porten.

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

Exempel

$ 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

Valfria alternativ

Alternativ	Beskrivning
--url TEXT	Den nya nodens peer-URL (kan anges flera gånger)

Argument

Argument	Beskrivning
JOIN_DATA_PATH	Sökvägen till den fil där sammanfogningsdata skrivs

Exempel

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

Kommandot visar en lista över klustermedlemmarna och skriver den information som den nya noden behöver för att ansluta sig till klustret (inklusive anslutningspaketet) till filen. Spara den här filen till nästa steg.

Observera

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.

Även om detta begrepp ”learner” innebär ett extra steg (uppgradering), möjliggör det en säkrare drift av klustret, eftersom eventuella problem med den nya noden inte kan orsaka instabilitet i hela klustret innan den uppgraderas.

Spara sammanfogningsfilen till nästa steg (eller svaret, om du använde REST-API:et).

Joining the Cluster as a Learner

Anslut till klustret på den nod som ska anslutas, med hjälp av uppgifterna från det senaste steget och säkerhetslösenordet för den nod där den nya noden registrerades.

nitropyREST API

Obligatoriska alternativ

Alternativ	Beskrivning
--backup-passphrase TEXT	Säkerhetslösenordet för den nod där den nya deltagaren registrerades

Argument

Argument	Beskrivning
JOIN_DATA_PATH	Sökvägen till sammanfogningsdatafilen från förra steget

Exempel

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

Varning

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.

I detta skede har den nya noden anslutit sig som en ” ”-nod ( ): den synkroniserar med klustret men är ännu inte driftsklar. Å andra sidan kommer eventuella problem med noden i detta skede inte att orsaka problem för klustret, vilket gör denna åtgärd säker.

Det sista steget för att slutföra anslutningen är att uppgradera den nya noden till fullvärdig medlem.

Promoting the New Learner

Beroende på nätverks- och klusterförhållandena kan det ta en stund innan den nya medlemmen hinner ikapp klustret. När detta är klart kan den befordras från lärling till fullvärdig medlem.

Varning

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.

Du kan försöka befordra den nya medlemmen på följande sätt. Medlems-ID:t hittar du genom att visa en lista över klustermedlemmarna.

nitropyREST API

Argument

Argument	Beskrivning
MEMBER_ID	The ID of the learner to be promoted

Exempel

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

Om eleven ännu inte har hunnit ikapp kommer detta att misslyckas (HTTP-kod 412 i REST-API:et) och man bör försöka med uppflyttningen igen senare.

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

Du behöver en miljö med etcd v3.6 tillgänglig, med en IPv4-adress (minst) som kan nås av de andra medlemmarna i ditt kluster. TCP-trafik till och från port 2380 måste vara tillåten.

Skapa en tom katalog där etcd kommer att lagra sina data och skriv ner sökvägen (vi använder /var/etcd/data). Se till att den användare som ska starta processen har behörighet att läsa och skriva till katalogen.

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.

Du måste sedan skapa ett certifikat för vittnet och signera det med certifikatutfärdaren så att det kan kommunicera med sina kollegor. Detta kan till exempel göras genom 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

Lagra de resulterande witness.key och witness.pem även i /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

Till skillnad från NetHSM som automatiskt väljer ett nodnamn för sig själva (med hjälp av enhets-ID), måste du välja ett namn för varje vittne du lägger till, och se till att namnen är unika. Vi kommer att använda ”witness1” i följande exempel.

Med NetHSM:s svar på registrering av vittnet, förbered variabler av formuläret:

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"

Slutligen skapar du en etcd.conf.yml-fil med hjälp av den mallfil som finns i docs/etcd_witness.conf.template:

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

Detta bör ge dig en fil av formuläret:

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

Starta etcd på önskat sätt (manuellt, systemd tjänst, container, etc.) och peka på den konfigurationsfil som skapades i föregående steg:

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

Du bör se när det startar, ansluta dig till klustret som ”lärare” och hämta in data.

Promote the Witness

Till sist, och efter en stund, följ de vanliga anvisningarna i avsnittet ” ” (Främja den nya eleven) för att befordra vittnet. Om detta inte fungerar, försök igen senare.

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

etcdctl get /config/version

Denna nyckel ska finnas och innehålla ”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

Säkerhetskopiering och återställning

Säkerhetskopieringen fungerar på samma sätt som utan ett kluster och kan begäras från vilken nod som helst i klustret. Den säkerhetskopierar data för hela klustret, inklusive nodspecifika fält (dessa ignoreras dock om du inte återställer säkerhetskopian på en icke-provisionerad nod).

En säkerhetskopia som har gjorts på ett kluster kan återställas på samma kluster, även om vissa noder har lagts till eller tagits bort sedan dess. Sådana återställningar som görs på operativa kluster påverkar inte konfigurationsvärden (endast nycklar, användare, namnområden), precis som alla andra partiella återställningar.

Om du återställer en säkerhetskopia på en icke-provisionerad nod återställs de nodspecifika fälten (t.ex. nätverkskonfiguration, certifikat osv.) för den nod som användes för att skapa säkerhetskopian.

Återställning av en stor säkerhetskopia kan överbelasta klustret under en tid, medan den nod som utför återställningen vidarebefordrar ändringar till de andra.

Denna åtgärd är fortfarande kompatibel med säkerhetskopior som gjorts på tidigare versioner av NetHSM.

Observera

Om man på en nod A återställer en säkerhetskopia som gjorts på en annan nod Z med en annan domännyckel kommer A:s domännyckel att skrivas om korrekt, precis som tidigare. Men om A var i ett kluster med noden B kommer B att bli obrukbar eftersom Z:s domännyckel inte återställs på B.

Med andra ord ska du bara utföra en återställning i ett kluster med säkerhetskopior som har gjorts i samma kluster (även om noder kan ha tagits bort eller lagts till sedan dess). Om du vill återställa en utländsk säkerhetskopia på en nod måste du först ta bort den från klustret på ett säkert sätt, sedan fabriksåterställa den och återställa säkerhetskopian.

Ta bort en nod på ett rent sätt

Så länge någon del av klustret fortfarande är beslutsmässigt kan vilken som helst av dess medlemmar användas för att ta bort en annan nod från klustret, oavsett om denna nod redan är onåbar eller förväntas bli det.

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

Argument

Argument	Beskrivning
MEMBER_ID	The ID of the node to be removed

Exempel

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

Observera

En nod som har anslutits till klustret men som ännu inte har uppgraderats kan också tas bort på detta sätt utan problem.

Recovering a Failed Node

En nod som rapporterar tillståndet ” Failed” ( ) kommer att vägra att svara på de flesta normala kommandon. Den kan fortfarande stängas av, startas om, återställas ( ), diagnostiseras ( ) eller isoleras ( ) ().

Varning

Funktionerna ” ”, ”Failed ”, ” ` ”, diagnose` och ” ` ”, force-new` gäller endast från och med version 5.0. I version 4.0 slutar en nod som förlorat kvorumet att svara på alla förfrågningar. Den måste återställas till fabriksinställningarna.

Vanliga orsaker till att en nod befinner sig i tillståndet ” ” ( ) är bland annat:

• En varaktigt förlorad beslutsförhet.

• Ett tillfälligt förlorat beslutförhet (t.ex. när en andra nod läggs till i klustret och den andra noden ännu inte har anslutit sig).

• etcd håller just nu på att startas om (t.ex. på grund av att certifikaten har ändrats eller att nätverket har konfigurerats om).

• Klustret utsätts för en mycket hög belastning (t.ex. vid återställning av en mycket stor säkerhetskopia).

Oavsett orsaken kommer NetHSM endast att övergå till tillståndet ” Failed” ( ) efter minst en hel minut av misslyckade försök att kommunicera med databasen. Detta för att undvika felaktiga övergångar orsakade av mycket kortvariga instabiliteter.

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

Exempel

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

Observera

Om och när databasen åter blir tillgänglig (t.ex. om kvorumet återställs eftersom nätverksproblemet har lösts) kommer NetHSM automatiskt att övergå från tillståndet ” Failed ” till det tillstånd den befann sig i tidigare (eller återuppta den normala startsekvensen om den höll på att starta upp), utan att någon manuell åtgärd behövs. Det tar upp till en minut efter att problemet har lösts innan klustret har stabiliserats, HSM:en har upptäckt att problemet är löst och byter tillstånd.

Om du kommer fram till att felet är bestående (t.ex. förlorat kvorum utan utsikter att lösa det underliggande problemet) kan du antingen:

• Återställ enheten till fabriksinställning era noden, vilket raderar all data, och återställ sedan från en säkerhetskopia.

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

Observera

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

Varning

Efter en uppdatering från en version < 5.0 kommer slutpunkten force-new alltid att visa ”Unauthorized” tills HSM-enheten har låsts upp eller upplåsningslösenordet har ändrats minst en gång.

Software Updates in Clusters

Framtida uppdateringar kommer att markeras som ”klustersäkra” (detta bör vara majoriteten) eller ”klusterosäkra”.

Klustersäkra uppdateringar kan tillämpas på noder som ingår i ett kluster utan att de först tas bort från klustret. Men som med alla åtgärder bör du se till att göra detta på en nod i taget och i ett kluster där borttagandet av en nod inte går under kvorumet (t.ex. om uppdateringen misslyckas).

Uppdateringar som inte är säkra i kluster måste tillämpas på isolerade noder. Du bör demontera klustret (ta bort noderna en efter en), fabriksåterställa alla noder utom en, tillämpa uppdateringen på alla noder och sedan få alla återställda noder att ansluta sig till den återstående noden.

Se till att göra en säkerhetskopia före sådana operationer.

Omkonfigurering av ett befintligt kluster

Changing the Cluster CA

Ett befintligt kluster (med två eller fler noder) kan inte ändra sin klustercertifikatutfärdare medan det är i drift. Om du behöver ändra detta certifikat: välj en nod, ta bort alla andra noder, uppdatera certifikatutfärdaren och låt sedan de andra medlemmarna ansluta sig igen.

Changing the Network Configuration of Nodes

Om du ändrar nätverkskonfigurationen för en nod (t.ex. ändrar dess IP) kommer de andra noderna automatiskt att informeras om uppdateringen. Du bör dock se till att du bara utför sådana uppdateringar på en enda nod i taget och i ett kluster där kvorum inte förloras om den noden försvinner.