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.
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 <clustering.html#recovering-a-failed-node> 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¶
Klyngens natur med etcd gør den mere pålidelig, jo flere noder der er i klyngen. Som forklaret i afsnittet Operational Redundancy bør klynger ideelt set have mindst 3 noder for at have plads til at fejle, da en klynge med 2 noder vil fejle helt, hvis kun den ene fejler.
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.
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 using the /config/network endpoint (refer to the API documentation).
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.
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).
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" ]
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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Endelig kan CA (CA.pem) nu installeres med /config/tls/cluster-ca.pem endpoint (se API-dokumentation). Dette er kun muligt, når det installerede TLS-certifikat er underskrevet af det. Ellers vil operationen blive afvist.
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:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
Når den er kommet på niveau, skal noden forfremmes fra elev til fuldgyldigt medlem
Configure a Backup Passphrase¶
Sørg først for, at der er konfigureret en backup-passphrase på den node, der skal bruges til at registrere en ny snedker (se API-dokumentationen for slutpunktet /config/backup-passphrase).
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.
Du kan dobbelttjekke, at URL’en er korrekt, ved at kalde GET /cluster/members på den node, der forventes at deltage. Dette bør kun vise ét medlem: sig selv.
Registrer derefter den forventede URL på en eksisterende node i klyngen (hvis du ikke har en klynge endnu, skal du gøre det på den NetHSM, der skal fungere som den første node i klyngen). Dette gøres ved hjælp af POST /cluster/members endpoint (se API-dokumentation), hvor du sender en JSON body, der indeholder URL’en.
Hvis det lykkes, returneres en JSON-krop af formularen:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
som indeholder de oplysninger, der er nødvendige for, at den nye node kan slutte sig til klyngen. Den indeholder især en liste over alle medlemmer af klyngen (hvor medlemmet med et tomt navn er den nye deltager). Den indeholder også domænenøglen, der er krypteret med både oplåsnings- og backup-passphrase - så der skal være konfigureret en backup-passphrase før.
Bemærk
Bemærk i svaret ovenfor, at den nye deltager er en »learner«: Den kan nu oprette forbindelse til klyngen og modtage data derfra, men kan ikke deltage, før den bliver forfremmet, hvilket vil blive beskrevet nedenfor.
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 det svar til næste trin.
Joining the Cluster as a Learner¶
Tag svaret fra det sidste trin og tilføj et backupPassphrase-felt, der indeholder backup-passphrasen for den node, hvor den nye deltager blev registreret, og send disse data til et kald til POST /cluster/join (se API-dokumentation) på den node, der forventes at deltage.
Advarsel
Opkaldet til POST /cluster/join vil hænge, indtil den nye node manuelt bliver forfremmet (se nedenfor). Dette er normalt. Når opkaldet returneres med succes, betyder det, at tilslutningen og forfremmelsen er lykkedes.
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
Når en node opgraderes, øges klyngens kvorumtærskel (se API-dokumentationen til » « samt afsnittet » « (Operational Redundancy) i dette dokument). Sørg for, at den nye node har en stabil forbindelse til klyngen, inden den opgraderes.
Du kan forsøge at forfremme det nye medlem ved at kalde POST /cluster/members/{MemberID}/promote (se API-dokumentationen til ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Hvis den lærende endnu ikke har indhentet det forsømte, vil dette mislykkes med HTTP-kode 412, og forfremmelsen bør forsøges igen senere.
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).
Skriv svaret fra klyngen ned: Det bør indeholde en liste over klyngemedlemmer og et joiner-kit (du får ikke brug for denne del).
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,..."
Hvis vi antager, at svaret fra NetHSM er gemt i en response.json fil, kan du generere disse to sidste variabler automatisk med følgende jq udtryk:
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.
Du skal først kende ID’et på den node, du vil fjerne, ved at liste alle noder via GET /cluster/members og lede efter den rigtige.
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.
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).
etcder 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.
For at hjælpe dig med at forstå, hvilken tilstand din node befinder sig i, er endpointet GET /health/diagnose fortsat tilgængeligt og returnerer oplysninger om den aktuelle status for etcd og dens database, herunder logfiler (se API-dokumentationen).
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.
Isoler den node, der har endepunktet
POST /cluster/force-new, hvilket vil medføre, at noden uigenkaldeligt glemmer alle andre klyngemedlemmer, gendanner dataene fraetcd, der findes på disken, og genstarter. Hvis den underliggende fejl var klyngerelateret, vil noden følge den normale opstartssekvens og ende i enten tilstanden Locked eller Operational, afhængigt af indstillingen for uovervåget opstart.
Bemærk
Hvis en node isoleres med kommandoen ` `` force-new`, vil den nu være desynkroniseret med klyngen: eventuelle nye skrivninger på noden eller i klyngen kan ikke afstemmes. Noden kan stadig genindtræde i klyngen, men vil miste alle sine lokale ændringer.
Endpunktet POST /cluster/force-new, som kun er tilgængeligt i tilstanden » Failed« ( ), kræver godkendelse, da det potentielt kan forårsage skade. Da HSM-brugere og -roller imidlertid ikke er tilgængelige i denne tilstand, forventer endpunktet, at HTTPS-klienter altid godkender sig med den fiktive bruger unlock og den seneste kendte adgangskode til oplåsning som adgangskode.
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.