Clustering

Bemærk

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 er endnu ikke blevet afprøvet i et tilstrækkeligt antal produktionsmiljøer, og der kan forekomme fejl.

NetHSM 4.0 og fremefter understøtter klyngedannelse for at synkronisere data direkte mellem flere NetHSM’er. Dette understøtter høj frekvens af nøglegenerationer, realiserer høj tilgængelighed og belastningsbalancering. En NetHSM-klynge er baseret på etcd, som bruger Raft-konsensusalgoritmen til stærk konsistens. Det sikrer, at data (f.eks. nøgler) til enhver tid er korrekte i alle NetHSM’er.

Før du opsætter en NetHSM-klynge, skal du gøre dig bekendt med denne teknologi og dens begrænsninger for at undgå utilsigtede udfald og datatab. Ud over dette dokument kan du også se etcd’s dokumentation.

Operational Redundancy

Vi vil kalde »node« en NetHSM, der forventes at være en del af en klynge. En klynge af N noder vil fortsætte med at fungere, så længe mindst (N/2)+1 noder er sunde og kan nås. Den minimale mængde af sunde, tilgængelige noder kaldes quorum.

På et cluster, der falder under denne tærskel (f.eks. på grund af et netværksproblem), kan der ikke vælges en leder, og den lokale instans af etcd på hver node kan ikke længere udføre læse- og skriveoperationer. Dette medfører følgende scenarier.

Et knudepunkt går ned, og quorum er stadig nået

I en klynge med tre noder vil de to andre noder fortsætte med at arbejde og betjene anmodninger, hvis en node fejler (går ned eller bliver utilgængelig på grund af netværksforhold).

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.

Hvis den aldrig kommer sig, skal den fjernes fra klyngen og enten gennemgå en genoprettelse for at få adgang til dens data (men den vil ikke længere være en del af klyngen), eller blive nulstillet til fabriksindstillingerne og gennemgå tilslutningsprocessen igen fra bunden.

En netværksopdeling sker, og quorum er stadig nået

Dette er blot en generalisering af det foregående scenarie. I en klynge med 5 noder, hvor f.eks. 3 noder befinder sig på en fysisk placering A og 2 noder på en anden placering B, vil et netværksproblem, der isolerer A og B, betyde følgende:

  • De 3 noder på placering A opfylder quorum (3 i dette tilfælde), så de fortsætter med at fungere.

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

  • Hvis netværksproblemet er løst, vil de 2 noder rent faktisk slutte sig til de 3 andre.

Med andre ord vil en netværksopdeling i værste fald (i en klynge med et ulige antal noder) medføre, at den større halvdel af klyngen fungerer normalt, mens den mindre halvdel er ude af drift, indtil opdelingen er løst.

Beslutningsdygtigheden er varigt tabt

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.

Det kan f.eks. ske, hvis en enkelt node fejler i en klynge med 2 noder (hvor quorum er 2). I denne situation kan den fejlslagne node ikke fjernes fra klyngen bagefter, fordi den resterende sunde node allerede er ude af drift, da den har mistet quorum.

Derfor anbefales det altid at have et ulige antal noder i en klynge og at tage backup ofte.

For at gøre det klart, så er det ikke et problem, at midlertidigt mister beslutningsdygtighed (f.eks. hvis du genstarter alle noder i en klynge sammen, eller en midlertidig netværksfejl isolerer noder): Når nok noder er forbundet igen (uden at skulle tilsluttes manuelt) til at nå beslutningsdygtighed, vil klyngen genoptage sin normale drift. Kun permanente fejl som f.eks. netværkspartitioner, fejlkonfigurationer i netværket, autentificeringsproblemer eller hardwarefejl kræver manuel handling.

For mere information, se etcd’s OFTE STILLEDE SPØRGSMÅL.

2-node klynge

En aktiv/passiv klynge med to noder er ikke understøttet endnu og vil blive tilføjet i en fremtidig version. Vi anbefaler at introducere en 3. node, enten en 3. NetHSM eller et etcd-»vidne«, som kan betjenes på en hvilken som helst vært. Se næste afsnit »Vidne«.

Vidne

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.

Men funktionen er designet sådan, at du ikke behøver at tilføje en fuld, ægte NetHSM-enhed til din klynge for at nå et stabilt antal noder. I stedet kan du selv implementere og tilføje en »vidne«-node. En sådan node er bare en instans af etcd, der kører på en maskine efter eget valg (eller i en container) og er forbundet til klyngen. Den vil blive genkendt som en normal node af de rigtige enheder i klyngen og modtage alle data og opdateringer fra enhederne (men du vil selvfølgelig ikke kunne udføre nogen HSM-operationer med den - den gemmer kun data).

Security Considerations

Vidnenoden (eller enhver med adgang til den) har direkte adgang til storage backend for alle noder i klyngen (f.eks. kan du dumpe alle poster og tilhørende værdier med etcdctl get "/" "0").

Men med undtagelse af config-versionen (/config/version, som altid skal være »1«) er alle værdier krypterede (med enten en enhedsnøgle for nodespecifikke værdier eller domænenøgler for andre), hvilket sikrer fortroligheden af følsomme data.

Bemærk dog, at en ondsindet node 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.

Hvad deles mellem noder?

At have en klynge af NetHSM’er betyder, at de fleste data deles mellem dem. Enhver tilføjelse, ændring eller sletning af nøgler, brugere eller namespaces på én node vil i sidste ende blive afspejlet på alle de andre. Generelt vil enhver operation, der ændrer tilstanden, ændre tilstanden for alle noder. Dette omfatter backup restore, som fungerer som normalt.

De følgende afsnit beskriver, hvilke data der er helt lokale, hvilke data der gemmes i det delte etcd lager, men forbliver nodespecifikke, og hvilke data der er helt delte på tværs af noder.

Ikke gemt i etcd

enhedsnøglen for hver node gemmes kun lokalt og deles aldrig på tværs af noder.

Gemt i etcd, men node-specifik

Følgende data er gemt i etcd i forskellige scopes for hver node. Det er derfor tilgængeligt for alle noder, men ikke ensartet på tværs af noder (hver node kan have en forskellig værdi for disse 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

Bemærk, at selvom hver node har sin egen version af den låste domænenøgle (fordi hver node låser den med sin egen enhedsnøgle eller oplåsningspasfrase), så deles den underliggende domænenøgle **** på tværs af noder (for at få adgang til deres fælles HSM-data, f.eks. nøgler).

Gemt i etcd og delt

Alle de følgende data gemmes i etcd i det globale scope, så de er ens på tværs af alle noder i en klynge:

HSM-data:

  • Keys

  • Brugere

  • Navnerum

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

Enhver klynge starter oprindeligt med en enkelt node. Nye noder vil slutte sig til klyngen en efter en.

Preparing Nodes

Netværkstrafikken mellem noderne er krypteret og autentificeret ved hjælp af deres TLS-certifikat.

Alle noder, der forventes at være en del af den samme klynge, skal først installere en fælles Certificate Authority (CA), der gør det muligt for dem at verificere, at andre noder er legitime.

I det følgende antager vi, at alle knudepunkter er nyetablerede og i drift.

Networking

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

Oprettelse og installation af en CA

Brugere bør oprette en CA på deres egen måde og i henhold til deres egne operationelle begrænsninger og sørge for, at den mindst tillader brug af nøglen keyCertSign.

En minimal CA kan f.eks. oprettes 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

Denne CA skal nu installeres på hver node.

For at gøre dette skal du først generere en Certificate Signing Request (CSR) fra noden, som beskrevet i afsnittet TLS-certifikat. Med nitropy sker dette med nitropy nethsm --host $NETHSM_HOST csr --api.

Bemærk

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 skal du bruge indstillingen --san, f.eks. --san "IP:192.168.1.1".

Hvis du ønsker at bruge en offentlig certifikatudsteder til at underskrive dine certifikater, skal dine noder bruge offentlige IP-adresser. Dette skyldes et sikkerhedskrav, der forbyder en offentlig certifikatudsteder at udstede certifikater med en privat IP-adresse i IP-SAN’en.

Med den opnåede CSR (lad os kalde den nethsm.csr) kan vi derefter generere et certifikat til den, som er klar til at blive installeret. For eksempel 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

Installer derefter den hentede new_cert.pem som beskrevet i afsnittet 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.

Argumenter

Argument

Beskrivelse

FILENAME

The path of the CA file

Eksempel

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

Den installerede cluster-CA kan hentes via nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate.

Bemærk

Denne proces skal gentages for hver node.

Ur-synkronisering

Sørg for, at hver node er konfigureret med en nøjagtig systemtid, helst ved hjælp af NTP/NTS i stedet for manuel tidsindstilling. Dette kan gøres via Time og 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 er kommet på niveau, skal noden forfremmes fra elev til fuldgyldigt 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 af et nyt knudepunkt

Hav IP-adressen på den node, der skal deltage, ved hånden. Den fulde URL (også kaldet peer URL i etcd terminologi) for denne node vil være https://<IP_of_node>:2380 (f.eks. https://192.168.1.1:2380). Porten skal være 2380, så sørg for, at en eventuel firewall mellem noderne tillader TCP-trafik på den 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.

Eksempel

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

Optionelle muligheder

Mulighed

Beskrivelse

--url TEXT

Peer-URL’en for den nye node (kan angives flere gange)

Argumenter

Argument

Beskrivelse

JOIN_DATA_PATH

Stien til den fil, hvor sammenføjningsdataene skrives til

Eksempel

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

Kommandoen viser en liste over klyngemedlemmerne og skriver de data, som den nye node skal bruge for at tilslutte sig klyngen (herunder joiner-kittet), til filen. Gem denne fil til det næste trin.

Bemærk

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.

Selvom dette »learner«-koncept indebærer et ekstra trin (opgradering), muliggør det en mere sikker drift af klyngen, da eventuelle problemer med den nye node ikke kan forårsage ustabilitet i hele klyngen, før den er blevet opgraderet.

Gem sammenkoblingsdatafilen til det næste trin (eller svaret, hvis du har brugt REST-API’en).

Joining the Cluster as a Learner

Tilslut dig klyngen på den node, der skal tilsluttes, ved hjælp af oplysningerne fra det sidste trin og sikkerhedskoden for den node, hvor den nye node blev registreret.

Nødvendige indstillinger

Mulighed

Beskrivelse

--backup-passphrase TEXT

Sikkerhedskodeordet for den node, hvor den nye deltager blev registreret

Argumenter

Argument

Beskrivelse

JOIN_DATA_PATH

Stien til sammenføjningsdatafilen fra det sidste trin

Eksempel

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

Advarsel

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.

På dette tidspunkt er den nye node tilknyttet som en node i tilstanden » « ( ): Den synkroniserer med klyngen, men er endnu ikke klar til drift. På den anden side vil eventuelle problemer med noden på dette tidspunkt ikke medføre problemer for klyngen, hvilket gør denne handling sikker.

Det sidste trin for at fuldføre sammenlægningen er at ophøje den nye node til fuldgyldigt medlem.

Promoting the New Learner

Afhængigt af netværks- og klyngebetingelserne kan det tage et stykke tid, før det nye medlem er kommet på niveau med klyngen. Når dette er sket, kan det forfremmes fra lærling til fuldgyldigt medlem.

Advarsel

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 forsøge at forfremme det nye medlem på følgende måde. Medlems-ID’et kan findes ved at få vist en liste over klyngemedlemmerne.

Argumenter

Argument

Beskrivelse

MEMBER_ID

The ID of the learner to be promoted

Eksempel

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

Hvis den lærende endnu ikke har indhentet det forsømte, vil dette mislykkes (HTTP-kode 412 i REST-API’et), og der bør senere gøres et nyt forsøg på at rykke den lærende op.

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 skal bruge et miljø med etcd v3.6 tilgængelig, med en IPv4-adresse (mindst), der kan nås af de andre medlemmer af din klynge. TCP-trafik til og fra port 2380 skal være tilladt.

Opret en tom mappe, hvor etcd skal gemme sine data, og skriv dens sti ned (vi bruger /var/etcd/data). Sørg for, at den bruger, der skal starte processen, har tilladelse til at læse og skrive til mappen.

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.

Derefter skal du oprette et certifikat til vidnet og underskrive det med CA’en, så det kan kommunikere med sine kolleger. Dette kan f.eks. gøres 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

Gem også de resulterende witness.key og witness.pem 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

I modsætning til NetHSM’er, som automatisk vælger et nodenavn til sig selv (ved hjælp af enhedens ID), skal du vælge et navn til hvert vidne, du tilføjer, og sørge for, at navnene er unikke. Vi bruger »witness1« i de følgende eksempler.

Med NetHSM’s svar på registrering af vidnet skal du udarbejde variabler af formularen:

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"

Til sidst skal du oprette en etcd.conf.yml-fil ved at bruge den skabelonfil, der findes i docs/etcd_witness.conf.template:

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

Det burde give dig en fil med formularen:

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 på din foretrukne måde (manuelt, systemd service, container osv.), og peg på den konfigurationsfil, der blev oprettet i det foregående trin:

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

Du bør kunne se, at den starter, tilslutter sig klyngen som »learner« og indhenter dataene.

Promote the Witness

Til sidst, og efter et stykke tid, skal du følge de normale instruktioner fra afsnittet » « under »Promoting the New Learner« for at forfremme vidnet. Hvis dette ikke lykkes, kan du prøve igen senere.

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

etcdctl get /config/version

Denne nøgle skal eksistere og indeholde »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

Sikkerhedskopiering og gendannelse

Backup-operationen fungerer på samme måde som uden en klynge og kan rekvireres fra enhver node i klyngen. Den vil sikkerhedskopiere data for hele klyngen, inklusive nodespecifikke felter (selvom disse vil blive ignoreret, medmindre sikkerhedskopien gendannes på en ikke-provisioneret node).

En backup, der er lavet på en klynge, kan gendannes på den samme klynge, selv om nogle noder er blevet tilføjet eller fjernet siden. Sådanne gendannelser på operationelle klynger vil ikke påvirke konfigurationsværdier (kun nøgler, brugere, navneområder), ligesom enhver anden delvis gendannelse.

Gendannelse af en sikkerhedskopi på en ikke-provisioneret node vil gendanne de nodespecifikke felter (som netværkskonfiguration, certifikater osv.) på den node, der blev brugt til at oprette sikkerhedskopien.

Gendannelse af en stor backup kan overbelaste klyngen i nogen tid, mens den node, der foretager gendannelsen, videresender ændringer til de andre.

Denne handling forbliver kompatibel med sikkerhedskopier, der er lavet på tidligere versioner af NetHSM.

Bemærk

Hvis man på en node A gendanner en backup, der er lavet på en anden node Z med en anden domænenøgle, vil A’s domænenøgle blive omskrevet korrekt som før. Men hvis A var i en klynge med node B, vil B blive ubrugelig, da Z’s domænenøgle ikke vil blive gendannet på B.

Med andre ord skal du kun udføre en gendannelse i en klynge med sikkerhedskopier, der er lavet i samme klynge (selvom der igen kan være fjernet eller tilføjet noder siden). Hvis du vil gendanne en fremmed sikkerhedskopi på en node, skal du først fjerne den sikkert fra dens klynge, derefter fabriksindstille den og gendanne sikkerhedskopien.

Fjernelse af et knudepunkt på en ren måde

Så længe en del af klyngen stadig er beslutningsdygtig, kan ethvert af dens medlemmer bruges til at fjerne en anden node fra klyngen, uanset om denne node allerede er utilgængelig eller forventes at blive 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.

Argumenter

Argument

Beskrivelse

MEMBER_ID

The ID of the node to be removed

Eksempel

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

Bemærk

En node, der er blevet tilføjet til klyngen, men endnu ikke er blevet forfremmet, kan også fjernes sikkert på denne måde.

Recovering a Failed Node

En node, der rapporterer tilstanden » Failed«, vil ikke reagere på de fleste normale kommandoer. Den kan dog stadig lukkes ned, genstartes, nulstilles , diagnosticeres eller isoleres.

Advarsel

-tilstanden, -tilstanden, diagnose og force-new gælder kun for version 5.0 og nyere. I version 4.0 vil en node, der har mistet kvorummet, ophøre med at svare på alle -anmodninger. Den skal nulstilles til fabriksindstillingerne.

Almindelige årsager til, at en node befinder sig i tilstanden » « med fejlen » «, omfatter:

  • Et varigt mistet beslutningsdygtighed.

  • Et midlertidigt tabt beslutningsdygtigt antal (f.eks. når man tilføjer en anden node til klyngen, og den anden node endnu ikke er kommet med).

  • etcd er i øjeblikket ved at genstarte (f.eks. fordi certifikaterne er blevet ændret, eller fordi netværket er blevet omkonfigureret).

  • Klyngen er udsat for en meget stor belastning (f.eks. under gendannelse af en meget stor sikkerhedskopi).

Uanset årsagen vil NetHSM først skifte til tilstanden » Failed« ( ) efter mindst et helt minut med mislykkede forsøg på at kommunikere med databasen. Dette er for at undgå fejlagtige tilstandsskift forårsaget af meget kortvarige ustabiliteter.

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.

Eksempel

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

Bemærk

Hvis og når databasen igen bliver tilgængelig (f.eks. hvis kvorummet genoprettes, fordi netværksproblemet er løst), vil NetHSM automatisk skifte fra tilstanden » Failed« til den tilstand, den befandt sig i før (eller genoptage den normale opstartssekvens, hvis den var i gang med at starte op), uden at der kræves nogen manuel handling. Det vil tage op til et minut, efter at problemet er løst, før klyngen stabiliserer sig, HSM’en registrerer, at problemet er løst, og skifter tilstand.

Hvis du konkluderer, at fejlen er vedvarende (f.eks. tab af kvorum uden udsigt til at løse den underliggende årsag), kan du enten:

  • Nulstil enheden til fabriksindstillingerne ( ) for at slette alle data og gendanne en sikkerhedskopi.

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

Bemærk

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

Advarsel

Efter en opdatering fra en version < 5.0 vil endpointet force-new altid vise status »Unauthorized«, indtil HSM’en er låst op, eller adgangskoden til oplåsning er blevet ændret mindst én gang.

Software Updates in Clusters

Fremtidige opdateringer vil blive markeret som »klyngesikker« (det burde være de fleste) eller »klyngeusikker«.

Klyngesikre opdateringer kan anvendes på noder, der er en del af en klynge, uden at fjerne dem fra klyngen først. Men som med alle andre operationer skal du sørge for at gøre det på én node ad gangen og i en klynge, hvor det at fjerne en node ikke går under quorum (f.eks. hvis opdateringen mislykkes).

Klynge-usikre opdateringer skal anvendes på isolerede noder. Du skal afmontere klyngen (fjerne noder en efter en), fabriksnulstille alle noder undtagen én, anvende opdateringen på alle noder og derefter få alle nulstillede noder til at slutte sig til den resterende node.

Sørg for at tage backup før sådanne operationer.

Rekonfigurering af en eksisterende klynge

Changing the Cluster CA

En eksisterende klynge (med to eller flere noder) kan ikke ændre sin klynge-CA, mens den er i drift. Hvis du har brug for at ændre certifikatet, skal du vælge en node, fjerne alle andre noder, opdatere CA’et og derefter få de andre medlemmer til at tilslutte sig igen.

Changing the Network Configuration of Nodes

Hvis man ændrer en nodes netværkskonfiguration (f.eks. ændrer dens IP), informeres de andre noder automatisk om opdateringen. Du bør dog sikre dig, at du kun udfører sådanne opdateringer på en enkelt node ad gangen og i en klynge, hvor tabet af den pågældende node ikke vil medføre tab af quorum.