Clustering

Märkus

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.

• Seda ei ole veel piisavas arvus tootmiskeskkondades katsetatud ning selles võivad esineda vead.

NetHSM alates versioonist 4.0 toetab klasterdamist, et sünkroonida andmeid otse mitme NetHSMi vahel. See toetab võtmete suure sagedusega genereerimist, tagab suure kättesaadavuse ja koormuse tasakaalustamise. NetHSM klastri aluseks on etcd, mis kasutab Raft konsensusalgoritmi tugeva järjepidevuse tagamiseks. See tagab, et andmed (nt võtmed) on kõikides NetHSMides alati õiged.

Enne NetHSM-klastri loomist tutvuge selle tehnoloogiaga ja selle piirangutega, et vältida juhuslikku katkestust ja andmekaotust. Lisaks käesolevale dokumendile võite tutvuda ka etcd dokumentatsiooniga.

Operational Redundancy

Nimetame „sõlme“ NetHSMi, mis peaks olema osa klastrist. Klaster, mis koosneb N sõlmedest, jätkab tööd seni, kuni vähemalt (N/2)+1 sõlmed on terved ja juurdepääsetavad. Seda minimaalset arvu terveid ja juurdepääsetavaid sõlmi nimetatakse kvoorumiks.

Klastris, mis langeb alla selle künnise (nt võrguprobleemi tõttu), ei ole võimalik valida liidrit ning iga sõlme kohalik instants etcd ei suuda enam lugemis- ega kirjutamistoiminguid teostada. See toob kaasa järgmised stsenaariumid.

Üks sõlm läheb maha ja kvoorum on siiski saavutatud

Kui kolme sõlme klastris üks sõlm ei tööta (jookseb kokku või muutub võrgu tõttu kättesaamatuks), jätkavad kaks ülejäänud sõlme tööd ja teenindavad päringuid.

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.

Kui seade ei taastu kunagi, tuleb see klastrist eemaldada ning kas läbi viia taastamine, et pääseda ligi selle andmetele (kuid see ei kuulu enam klastrisse), või teha seadmel tehasevaikimisi taastamine ja läbida liitumisprotsess uuesti algusest peale.

Võrgustiku jagunemine toimub ja kvoorum on siiski saavutatud

See on lihtsalt eelmise stsenaariumi üldistus. Viie sõlme klastris, kus näiteks 3 sõlme on ühes füüsilises asukohas A ja 2 sõlme teises asukohas B, tähendaks A ja B isoleeriv võrguprobleem järgmist:

• Asukohas A asuvad 3 sõlme täidavad kvoorumi (antud juhul 3), seega jätkavad nad tegevust.

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

• Kui võrguprobleem on lahendatud, ühendavad 2 sõlme puhtalt tagasi 3 ülejäänud sõlme.

Teisisõnu, halvimal juhul tekkiva võrgupartitsiooni korral (klastris, kus on paaritu arv sõlmi) jääb klastri suurem pool töökorras, kuid väiksem pool ei tööta, kuni partitsioon on lahendatud.

Kvoorum on püsivalt kadunud

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.

See võib juhtuda näiteks siis, kui 2-sõlmelises klastris (kus kvoorum on 2) üks sõlme ebaõnnestub. Sellises olukorras ei saa ebaõnnestunud sõlme pärast seda klastrist puhtalt eemaldada, sest allesjäänud terve sõlme on juba töökõlbmatu, kuna see on kaotanud kvoorumi.

Seetõttu on soovitatav, et klastris oleks alati paaritu arv sõlmi ja et varundataks sageli.

Selgituseks: ajutiselt kvoorumi kaotamine (näiteks kui te taaskäivitate kõik klastri sõlmed koos või kui ajutine võrgurike isoleerib sõlmed) ei ole probleem: kui piisavalt palju sõlmi on uuesti ühendatud (ilma käsitsi uuesti liitumata), et saavutada kvoorum, jätkab klastri normaalset tööd. Ainult püsivad tõrked, näiteks võrgu jagunemine, võrgu valesti konfigureerimine, autentimisprobleemid või riistvararikked, nõuavad käsitsi tegutsemist.

Lisateavet leiate etcd’s KKK.

2-sõlme klastri

Kahe sõlme aktiivne/passiivne klaster ei ole veel toetatud ja see lisatakse tulevases versioonis. Soovitame kasutusele võtta kolmanda sõlme, kas kolmanda NetHSMi või etcd „tunnistaja“, mida võib kasutada ükskõik millisel hostil. Vt järgmist jaotist „Tunnistaja“.

Tunnistaja

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.

Funktsiooni ülesehitus on aga selline, et te ei pea oma klastrisse lisama täielikku, tõelist NetHSM-seadet, et saavutada stabiilne sõlmede arv. Selle asemel võite ise juurutada ja lisada „tunnistaja“ sõlme. Selline sõlme on lihtsalt etcd instants, mis töötab teie valitud masinas (või konteineris) ja on ühendatud klastriga. Seda tunnustatakse klastri reaalsete seadmete poolt tavalise sõlmena ja see saab kõik andmed ja uuendused seadmetelt (kuid loomulikult ei saa te sellega teha mingeid HSM-operatsioone - ta ainult salvestab andmeid).

Security Considerations

Tunnistussõlm (või igaüks, kellel on sellele juurdepääs) omab otsest ligipääsu kõigi klastri sõlmede salvestussüsteemile (nt saab kõiki kirjeid ja vastavaid väärtusi välja lasta, kasutades etcdctl get "/" "0").

Siiski, välja arvatud konfiguratsiooniversioon (/config/version, mis peaks alati olema „1“), on rangelt kõik väärtused krüpteeritud (kas seadme võtmega sõlme-spetsiifiliste väärtuste puhul või domeeni võtmetega teiste puhul), mis tagab tundlike andmete konfidentsiaalsuse.

Pange aga tähele, et pahatahtlik sõlm võib:

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

Mida jagatakse sõlmede vahel

NetHSMide klastri olemasolu tähendab, et enamik andmeid jagatakse nende vahel. Iga võtmete, kasutajate või nimeruumide lisamine, muutmine või kustutamine ühes sõlmes kajastub lõpuks kõigis teistes sõlmedes. Üldiselt muudab iga toiming, mis muudab olekut, iga sõlme olekut. See hõlmab ka varundamist taastamist, mis toimib tavapäraselt.

Järgmistes jaotistes kirjeldatakse üksikasjalikult, millised andmed on täielikult lokaalsed, millised andmed on salvestatud jagatud etcd salvestusse, kuid jäävad sõlmede kaupa, ja millised andmed on täielikult jagatud sõlmede vahel.

Ei ole salvestatud etcd-sse

Iga sõlme seadme võti säilitatakse ainult kohalikul tasandil ja seda ei jagata kunagi sõlmede vahel.

Salvestatud etcd-s, kuid sõlme-spetsiifiline

Järgmised andmed on salvestatud aadressil etcd iga sõlme jaoks erinevas ulatuses. Seega on need kättesaadavad igale sõlmpunktile, kuid ei ole ühtsed kõigis sõlmedes (igal sõlmpunktil võib olla erinev väärtus nendele andmetele).

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

Pange tähele, et kuigi igal sõlmel on oma versioon lukustatud domeeni võtmest (sest iga sõlm lukustab selle oma seadme võtme või avamisfraasiga), on aluseks olev domeeni võti , mida jagavad kõik sõlmed (et pääseda ligi nende ühistele HSM-andmetele, näiteks võtmetele).

Salvestatud etcd-s ja jagatud

Kõik järgmised andmed on salvestatud aadressil etcd globaalses ulatuses, nii et need on ühtsed kõigis klastri sõlmedes:

HSM andmed:

• Keys

• Kasutajad

• Nimeruumid

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

Iga klaster algab algselt ühest sõlmest. Uued sõlmed liituvad klastriga ükshaaval.

Preparing Nodes

Võrguliiklus sõlmede vahel on krüpteeritud ja autenditud nende TLS-sertifikaadi abil.

Kõik sõlmed, mis peaksid kuuluma samasse klastrisse, peavad esmalt paigaldama ühise sertifitseerimisasutuse (CA), mis võimaldab neil kontrollida, et teised sõlmed on seaduslikud.

Järgnevalt eeldame, et kõik sõlmed on äsja kasutusele võetud ja töökorras.

Networking

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

CA loomine ja paigaldamine

Kasutajad peaksid looma CA oma vahenditega ja vastavalt oma tegevuspiirangutele, tagades, et see võimaldab vähemalt keyCertSign võtme kasutamist.

Näiteks saab minimaalse CA luua aadressiga 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

See CA tuleb nüüd paigaldada igasse sõlme.

Selleks tuleb kõigepealt luua sõlmest sertifikaadi allkirjastamise taotlus (CSR), nagu on kirjeldatud jaotises „ TLS Certificate“. Kasutades nitroopia, tehakse seda käsuga nitropy nethsm --host $NETHSM_HOST csr --api.

Märkus

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

Kui kasutate „ ” nitroopia, kasutage valikut --san, nt --san "IP:192.168.1.1".

Kui soovite oma sertifikaatide allkirjastamiseks kasutada avalikku sertifitseerimisasutust, peavad teie sõlmed kasutama avalikke IP-aadresse. See tuleneb turvanõudest, mis keelab avalikul sertifitseerimisasutusel väljastada sertifikaate, mille IP-SAN-is on märgitud eraviisiline IP-aadress.

Arvestades saadud CSR-i (nimetame seda nethsm.csr), saame seejärel genereerida selle jaoks sertifikaadi, mis on valmis paigaldamiseks. Näiteks 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

Seejärel installige saadud new_cert.pem vastavalt jaotises „ ” kirjeldatule TLS-sertifikaat (koos 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

Argumendid

Argument	Kirjeldus
FILENAME<x>	The path of the CA file

näide

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

Paigaldatud klastri sertifikaadi väljastaja (CA) saab välja otsida käsuga ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Märkus

Seda protsessi tuleb korrata iga sõlme puhul.

Kellasünkroonimine

Veenduge, et igale sõlme on määratud õige süsteemiaeg, soovitavalt NTP/NTS-i abil, mitte käsitsi seadistamise teel. Seda saab teha järgmiste seadistuste abil: Time ja NTS/NTP.

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. Kui ta on teistele järele jõudnud, edutage sõlme õppijast täisliikmeks

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.

Uue sõlme registreerimine

Hoidke käepärast liituva sõlme IP-aadress. Selle sõlme täielik URL (ka peer URL ` etcd` terminoloogias) on https://<IP_of_node>:2380 (nt https://192.168.1.1:2380). Port peab olema 2380, seega tuleb tagada, et sõlmede vaheline tulemüür lubab TCP-liiklust sellel pordil.

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

näide

$ 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

Võimalikud valikud

Valik	Kirjeldus
--url TEXT	Uue sõlme peer-URL (võib määrata mitu korda)

Argumendid

Argument	Kirjeldus
JOIN_DATA_PATH	Kataloog, kuhu ühendatud andmed salvestatakse

näide

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

Käsk kuvab klastri liikmed ja salvestab faili andmed, mida uus sõlm vajab klastriga ühinemiseks (sealhulgas ühinemiskomplekti). Säilita see fail järgmise sammu jaoks.

Märkus

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.

Kuigi see „õppija” kontseptsioon lisab ühe täiendava etapi (edutamine), võimaldab see klastri turvalisemat töötamist, kuna uue sõlme mis tahes probleem ei saa enne selle edutamist põhjustada kogu klastri ebastabiilsust.

Säilita ühendusandmete fail järgmise sammu jaoks (või vastus, kui kasutasid REST-API-d).

Joining the Cluster as a Learner

Liituge klastriga selles sõlmes, mis peaks klastriga ühinema, kasutades eelmises etapis saadud andmeid ja selle sõlme varusalasanat, milles uus liituja registreeriti.

nitropyREST API

Vajalikud valikud

Valik	Kirjeldus
--backup-passphrase TEXT	Selle sõlme varupassifraas, millele uus liituja registreeriti

Argumendid

Argument	Kirjeldus
JOIN_DATA_PATH	Eelmises etapis kasutatud ühendusandmefaili asukoht

näide

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

Hoiatus

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.

Praeguses etapis on uus sõlm liitunud klastriga „ “ õppiva sõlmena: see sünkroniseerib end klastriga, kuid ei ole veel töökorras. Teisalt ei põhjusta sõlmega seotud mis tahes probleemid selles etapis klastrile raskusi, mistõttu on see toiming ohutu.

Liitumise lõpetamiseks tuleb viimase sammuna uus sõlm tõsta täisliikme staatusesse.

Promoting the New Learner

Sõltuvalt võrgu- ja klastrioludest võib uue liikme klastriga ühinemine võtta veidi aega. Kui see on toimunud, saab ta edutada õppijast täisliikmeks.

Hoiatus

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.

Võite proovida uut liiget edendada järgmiselt. Liikme ID leiate klastri liikmete loetelu abil.

nitropyREST API

Argumendid

Argument	Kirjeldus
MEMBER_ID	The ID of the learner to be promoted

näide

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

Kui õppija ei ole veel järele jõudnud, siis see ebaõnnestub (HTTP-kood 412 REST-API-s) ja edutamist tuleks hiljem uuesti proovida.

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

Teil on vaja keskkonda, kus on olemas etcd v3.6, mille IPv4-aadress on (vähemalt) teie klastri teiste liikmete poolt kättesaadav. TCP-liiklus pordile 2380 ja sealt peab olema lubatud.

Looge tühi kataloog, kus etcd hakkab oma andmeid hoidma, ja kirjutage üles selle tee (me kasutame /var/etcd/data). Veenduge, et kasutajal, kes protsessi käivitab, on õigus lugeda ja kirjutada kataloogi.

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.

Seejärel peate looma tunnistaja jaoks sertifikaadi ja allkirjastama selle CAga, et ta saaks suhelda oma eakaaslastega. Seda saab teha näiteks veebilehe openssl kaudu:

# 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

Salvesta saadud witness.key ja witness.pem ka /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

Erinevalt NetHSMist, mis valivad endale automaatselt sõlme nime (kasutades seadme ID-d), peate te valima nime igale lisatavale tunnistajale, tagades, et nimed on unikaalsed. Järgnevates näidetes kasutame „witness1“.

Koos NetHSM-i vastusega tunnistajaks registreerimisele koostage vormimuutujad:

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"

Lõpuks looge etcd.conf.yml fail, kasutades docs/etcd_witness.conf.template esitatud mallifaili:

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

See peaks andma teile vormi faili:

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

Käivitage etcd oma eelistatud viisil (käsitsi, systemd teenus, konteiner jne), osutades sellele eelmises etapis loodud konfiguratsioonifaili:

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

Sa peaksid nägema, kuidas see käivitub, liituma klastriga õppijana ja jõudma andmetega sammu.

Promote the Witness

Lõpuks, mõne aja möödudes, järgige tunnistaja edutamiseks tavalisi juhiseid, mis on toodud veebilehel jaotises „Uue õppija edutamine“. Kui see ei õnnestu, proovige hiljem uuesti.

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

etcdctl get /config/version

See võti peaks olema olemas ja sisaldama „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

Varundamine ja taastamine

Varundamine toimib samamoodi nagu ilma klastrita ja seda saab taotleda klastri mis tahes sõlme kaudu. See varundab kogu klastri andmed, kaasa arvatud sõlme-spetsiifilised väljad (kuigi neid ignoreeritakse, kui varukoopia taastamine ei toimu mitteproviseeritud sõlmes).

Klastris tehtud varukoopia saab taastada samas klastris, isegi kui mõned sõlmed on vahepeal lisatud või eemaldatud. Sellised taastamised, mis on tehtud toimivates klastrites, ei mõjuta konfiguratsiooniväärtusi (ainult võtmed, kasutajad, nimeruumid), nagu mis tahes muu osaline taastamine.

Varukoopia taastamine mitteproviseeritud sõlmes taastab selle sõlme spetsiifilised väljad (nt võrgukonfiguratsioon, sertifikaadid jne), mida kasutati varukoopia loomiseks.

Suure varukoopia taastamine võib klastri mõneks ajaks üle koormata, samal ajal kui taastamist rakendav sõlme edastab muudatused teistele.

See toiming ühildub NetHSMi varasemate versioonidega tehtud varundustega.

Märkus

Teises sõlmes Z tehtud varukoopia taastamine sõlmes A erineva domeeni võtmega kirjutab A domeeni võtme korrektselt ümber, nagu varemgi. Kui aga A oli klastris koos sõlme Bga, muutub B töökõlbmatuks, sest Z domeeni võtit ei taastata Bs.

Teisisõnu, tehke taastamist ainult klastris, mille varukoopiad on tehtud samas klastris (kuigi jälle võivad sõlmed olla vahepeal eemaldatud või lisatud). Kui soovite taastada võõrast varukoopiat mõnes sõlmes, eemaldage see kõigepealt ohutult oma klastrist, seejärel tehke tehaseparandused ja taastage varukoopia.

Sõlme eemaldamine puhtalt

Niikaua kui klastri mingi osa vastab veel kvoorumile, saab mis tahes selle liikme abil eemaldada klastrist teise sõlme, olenemata sellest, kas see sõlm on juba kättesaamatu või eeldatavalt kättesaamatu.

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

Argumendid

Argument	Kirjeldus
MEMBER_ID	The ID of the node to be removed

näide

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

Märkus

Ka klastriga ühinenud, kuid veel edutamata sõlme saab sel viisil ohutult eemaldada.

Recovering a Failed Node

Sõlm, mis teatab seisundist „ Failed“ ( ebaõnnestus), keeldub vastamast enamikule tavapärastele operatsioonidele. Seda on siiski võimalik sulgeda, taaskäivitada, lähtestada , diagnoosida või isoleerida.

Hoiatus

Operatsioonid „ ”, „Failed ”, „ ` ”, „diagnose` ”, „ ` ” ja „force-new` ” kehtivad ainult versioonist 5.0 alates. Versioonis 4.0 lõpetab kvoorumi kaotanud sõlm vastamise kõikidele ja päringutele. See peab taastama tehase seaded.

Tavapärased põhjused, miks sõlm võib olla seisundis „ Failed“ ( ), on järgmised:

• Püsivalt kadunud kvoorum.

• Ajutine kvoorumi kaotus (nt kui klastrisse lisatakse teine sõlm, kuid see teine sõlm pole veel klastriga ühinenud).

• etcd on hetkel taaskäivitumas (nt seetõttu, et sertifikaadid on muutunud või võrk on ümber konfigureeritud).

• Klaster on väga suure koormuse all (nt väga suure varukoopia taastamise ajal).

Sõltumata põhjusest läheb NetHSM üle seisundisse „ Failed“ alles siis, kui andmebaasiga suhtlemise katsed on ebaõnnestunud vähemalt terve minuti jooksul. Selle eesmärk on vältida väga lühiajaliste ebastabiilsuste põhjustatud valesid üleminekuid.

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

näide

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

Märkus

Kui andmebaas muutub taas kättesaadavaks (nt kui kvoorum taastub võrguprobleemi lahendamise tõttu), läheb NetHSM automaatselt seisundist „ Failed” üle varasemasse seisundisse (või jätkab tavapärast käivitumisjärjekorda, kui ta oli just käivitumas), ilma et oleks vaja mingeid käsitsi toiminguid. Pärast probleemi lahendamist kulub kuni minut, enne kui klaster stabiliseerub, HSM tuvastab probleemi lahendamise ja vahetab seisundit.

Kui jõuate järeldusele, et tõrge on püsiv (nt kvoorumi kaotus, mille põhjustanud olukorra lahendamine ei ole võimalik), võite kas:

• Taasta seadme tehasevaikimisi seaded ( ) ja seejärel taasta varukoopia.

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

Märkus

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

Hoiatus

Pärast versioonist < 5.0 uuendamist on force-new lõpppunkt alati „Unauthorized” (autoriseerimata), kuni HSM on avatud või avamissalasanat on vähemalt üks kord muudetud.

Software Updates in Clusters

Tulevased uuendused märgistatakse kui „cluster-safe“ (see peaks olema enamus) või „cluster-unsafe“.

Klasterkindlaid uuendusi saab rakendada klastrisse kuuluvatele sõlmedele, ilma neid eelnevalt klastrist eemaldamata. Kuid nagu kõigi operatsioonide puhul, peaksite tagama, et seda tehakse ühe sõlme kohta korraga ja klastris, kus sõlme eemaldamine ei lähe alla kvoorumi (nt kui uuendamine ebaõnnestub).

Klastrisse mittekuuluvaid uuendusi tuleb rakendada isoleeritud sõlmedele. Te peaksite klastri laiali lammutama (eemaldades sõlmed ükshaaval), lähtestama kõik sõlmed peale ühe, rakendama uuenduse igale sõlmpunktile, seejärel panema kõik lähtestatud sõlmed liituma allesjäänud sõlmedega.

Enne selliseid toiminguid tehke kindlasti varukoopia.

Olemasoleva klastri ümberkonfigureerimine

Changing the Cluster CA

Olemasolev klastri (kahe või enama sõlme) ei saa muuta oma klastri CA-d töö ajal. Kui teil on vaja seda sertifikaati muuta: valige üks sõlme, eemaldage kõik teised sõlmed, uuendage CA ja laske siis teistel liikmetel uuesti liituda.

Changing the Network Configuration of Nodes

Võrgukonfiguratsiooni muutmine (nt IP-aadressi muutmine) teavitab teisi sõlmi automaatselt uuendusest. Te peaksite siiski tagama, et te teete selliseid uuendusi korraga ainult ühes sõlmes ja klastris, kus selle sõlme kaotamine ei põhjusta kvoorumi kadumist.