Clustering

Opomba

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.

• To še ni bilo dokazano v zadostnem številu produkcijskih namestitev, zato so mogoče prisotne napake.

NetHSM od različice 4.0 naprej podpira grozdenje za neposredno sinhronizacijo podatkov med več NetHSM. To omogoča visoko pogostost generiranja ključev, visoko razpoložljivost in izravnavo obremenitve. Grozd NetHSM temelji na etcd, ki uporablja algoritem soglasja Raft za močno skladnost. To zagotavlja, da so podatki (npr. ključi) v vseh enotah NetHSM vedno pravilni.

Pred vzpostavitvijo gruče NetHSM se seznanite s to tehnologijo in njenimi omejitvami, da se izognete naključnemu izpadu in izgubi podatkov. Poleg tega dokumenta si lahko ogledate tudi dokumentacijo etcd.

Operational Redundancy

Vozlišče bomo imenovali NetHSM, za katerega se pričakuje, da bo del gruče. Grozd vozlišč N bo deloval, dokler bodo vsaj (N/2)+1 vozlišča zdrava in dosegljiva. To minimalno število zdravih in dosegljivih vozlišč se imenuje kvorum.

V grozdu, ki pade pod to mejno vrednost (npr. zaradi težav z omrežjem), ni mogoče izvoliti vodje, zato lokalna instanca etcd na vsakem vozlišču ne more več izvajati branja in pisanja. To pomeni naslednje scenarije.

Eno vozlišče je v okvari, kvorum pa je še vedno dosežen

Če v gruči s tremi vozlišči eno vozlišče odpove (odpove ali postane nedosegljivo zaradi omrežnih razmer), ostali dve vozlišči nadaljujeta z delom in servisirata zahteve.

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.

Če se naprava nikoli ne bo obnovila, jo je treba odstraniti iz gruče in jo bodisi podvreči obnovitvi, da bo mogoče dostopati do njenih podatkov (vendar ne bo več del gruče), bodisi ponastaviti na tovarniške nastavitve in ponovno izvesti postopek priključitve od začetka.

Zgodi se delitev omrežja in kvorum je še vedno dosežen

To je le posplošitev prejšnjega scenarija. V gruči s petimi vozlišči, kjer so npr. 3 vozlišča na fizični lokaciji A in 2 vozlišči na drugi lokaciji B, bi omrežni problem, ki bi izoliral vozlišči A in B, pomenil naslednje:

• Tri vozlišča na lokaciji A izpolnjujejo kvorum (v tem primeru 3), zato še naprej delujejo.

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

• Če je težava z omrežjem odpravljena, se bosta dve vozlišči brez težav pridružili ostalim trem vozliščem.

Z drugimi besedami, v najslabšem primeru razdelitve omrežja (v gruči s liho številom vozlišč) bo večja polovica gruče delovala normalno, manjša polovica pa ne bo delovala, dokler se razdelitev ne odpravi.

Kvorum je trajno izgubljen

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.

To se lahko zgodi na primer, če v gruči z dvema vozliščema (kjer je kvorum 2) odpove eno vozlišče. V tem primeru odpovedanega vozlišča ni mogoče naknadno odstraniti iz gruče, saj preostalo zdravo vozlišče že ne deluje, ker je izgubilo kvorum.

Zato je priporočljivo, da je v gruči vedno liho število vozlišč in da pogosto izdelujete varnostne kopije.

Da bi bilo jasno, začasno izgubi kvorum (na primer, če ponovno zaženete vsa vozlišča v gruči skupaj ali če so vozlišča izolirana zaradi začasne okvare omrežja), ni težava: ko se ponovno poveže dovolj vozlišč (brez ročnega ponovnega povezovanja), da se doseže kvorum, bo gruča nadaljevala z običajnim delovanjem. Ročno ukrepanje bo potrebno le pri trajnih okvarah, kot so omrežne razdelitve, napačna konfiguracija omrežja, težave z avtentikacijo ali okvare strojne opreme.

Za več informacij si oglejte POGOSTA VPRAŠANJA in odgovore etcd.

Grozd z dvema vozliščema

Aktivna/pasivna gruča z dvema vozliščema še ni podprta in bo dodana v prihodnji različici. Priporočamo uvedbo tretjega vozlišča, bodisi tretjega NetHSM bodisi „priče“ etcd, ki bi lahko delovala v katerem koli gostitelju. Glejte naslednji razdelek „Priča“.

Priča

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.

Vendar je funkcija zasnovana tako, da vam za doseganje stabilnega števila vozlišč v gručo ni treba dodati celotne prave naprave NetHSM. Namesto tega lahko sami namestite in dodate vozlišče „priče“. Takšno vozlišče je samo primerek etcd, ki teče na izbranem računalniku (ali v vsebniku) in je povezan s skupnostjo. Prave naprave v gruči ga bodo prepoznale kot navadno vozlišče in bo prejemalo vse podatke in posodobitve iz naprav (seveda pa z njim ne boste mogli izvajati nobenih operacij HSM - samo shranjuje podatke).

Security Considerations

Vozlišče priče (ali kdor koli z dostopom do njega) ima neposreden dostop do zaledja za shranjevanje vseh vozlišč v gruči (npr. vse vnose in ustrezne vrednosti lahko izpišete s etcdctl get "/" "0").

Z izjemo različice konfiguracije (/config/version, ki mora biti vedno „1“) so vse vrednosti šifrirane (s ključem naprave za vrednosti, specifične za vozlišče, ali ključi domene za druge vrednosti), kar zagotavlja zaupnost občutljivih podatkov.

Vendar upoštevajte, da lahko zlonamerno vozlišče:

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

Kaj je v skupni rabi med vozlišči

Če je v gruči NetHSM, to pomeni, da se večina podatkov deli med njimi. Vsako dodajanje, spreminjanje ali brisanje ključev, uporabnikov ali prostorov imen na enem vozlišču se sčasoma odrazi na vseh drugih vozliščih. Na splošno vsaka operacija, ki spreminja stanje, spremeni stanje za vsako vozlišče. To vključuje operacijo varnostnega kopiranja obnovitve, ki deluje kot običajno.

V naslednjih razdelkih je podrobno opisano, kateri podatki so v celoti lokalni, kateri podatki so shranjeni v skupni shrambi etcd, vendar ostajajo specifični za vozlišče, in kateri podatki so v celoti v skupni rabi med vozlišči.

Ni shranjeno v etcd

Ključ naprave **** vsakega vozlišča je shranjen samo lokalno in se nikoli ne deli med vozlišči.

Shranjeno v etcd, vendar specifično za vozlišče

Naslednji podatki so shranjeni v etcd v različnih obsegih za vsako vozlišče. Zato je dostopen vsakemu vozlišču, ni pa enoten med vozlišči (vsako vozlišče ima lahko drugačno vrednost teh podatkov).

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

Upoštevajte, da ima sicer vsako vozlišče svojo različico zaklenjenega domenskega ključa (ker ga vsako vozlišče zaklene s svojim ključem naprave ali geslom za odklepanje), vendar je osnovni domenski ključ v skupni rabi med vozlišči (za dostop do skupnih podatkov HSM, kot so ključi).

Shranjeno v etcd in v skupni rabi

Vsi naslednji podatki so shranjeni v etcd v globalnem obsegu, zato so enotni za vsa vozlišča v gruči:

Podatki HSM:

• Keys

• Uporabniki

• Prostori imen

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

Vsaka gruča se na začetku začne z enim vozliščem. Nova vozlišča se grozdu pridružijo eno za drugim.

Preparing Nodes

Omrežni promet med vozlišči je šifriran in overjen z njihovim potrdilom TLS.

Vsa vozlišča, ki naj bi bila del iste gruče, morajo najprej namestiti skupno overitelja potrdil (CA), ki jim bo omogočal preverjanje, ali so druga vozlišča legitimna.

V nadaljevanju predpostavljamo, da so vsa vozlišča sveže zagotovljena in delujejo.

Networking

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

Ustvarjanje in namestitev CA

Uporabniki naj CA ustvarijo na lasten način in v skladu s svojimi operativnimi omejitvami ter se prepričajo, da omogoča vsaj uporabo ključa keyCertSign.

Minimalni CA lahko na primer ustvarite s 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

Ta CA mora biti zdaj nameščen v vsakem vozlišču.

Za to najprej ustvarite zahtevek za podpis certifikata (CSR) iz vozlišča, kot je opisano v poglavju » « TLS Certificate. Pri nitropija se to opravi s nitropy nethsm --host $NETHSM_HOST csr --api.

Opomba

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

Pri uporabi nitropija uporabite možnost --san, npr. --san "IP:192.168.1.1".

Če želite za podpisovanje certifikatov uporabiti javno certifikacijsko agencijo, morajo vaši vozli uporabljati javne IP-naslove. To je posledica varnostne zahteve, ki javni certifikacijski agenciji prepoveduje izdajanje certifikatov z zasebnim IP-naslovom v polju IP SAN.

Glede na pridobljeni CSR (imenujmo ga nethsm.csr) lahko zanj ustvarimo potrdilo, ki je pripravljeno za namestitev. Na primer z 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

Nato namestite pridobljeni new_cert.pem, kot je opisano v poglavju TLS Certificate (z nitropija: 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

Argumenti

Argument	Opis
FILENAME	The path of the CA file

Primer

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

Podatke o nameščenem skupinskem certifikacijskem organu (CA) lahko pridobite s pomočjo ukaza ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Opomba

Ta postopek je treba ponoviti za vsako vozlišče.

Sinhronizacija ure

Prepričajte se, da je na vsakem vozlišču nastavljen točen sistemski čas, po možnosti z uporabo protokolov NTP/NTS namesto ročne nastavitve časa. To lahko storite s konfiguracijo Time in 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. Ko bo nadoknadil zaostanek, napredujte vozlišče iz statusa učenca v polnopravnega člana

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.

Registracija novega vozlišča

Pri roki imejte naslov IP vozlišča, ki se bo pridružilo. Polni URL (v terminologiji etcd imenovan tudi peer URL ) tega vozlišča bo https://<IP_of_node>:2380 (npr. https://192.168.1.1:2380). Vrata morajo biti 2380, zato se prepričajte, da požarni zid med vozlišči dovoljuje promet TCP na teh vratih.

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

Primer

$ 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

Volitivne možnosti

Možnost	Opis
--url TEXT	URL vrstnika novega vozlišča (ga je mogoče nastaviti večkrat)

Argumenti

Argument	Opis
JOIN_DATA_PATH	Pot do datoteke, v katero se zapišejo združeni podatki

Primer

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

Ukaz prikaže seznam članov grozda in v datoteko zapiše podatke, ki jih novo vozlišče potrebuje za priključitev na grozd (vključno s paketom za priključitev). To datoteko shranite za naslednji korak.

Opomba

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.

Čeprav ta pojem »učenca« vključuje dodatni korak (napredovanje), omogoča varnejše delovanje grozda, saj morebitne težave z novim vozliščem pred njegovim napredovanjem ne morejo povzročiti nestabilnosti celotnega grozda.

Shranite datoteko s podatki o povezavi za naslednji korak (ali odgovor, če ste uporabili REST API).

Joining the Cluster as a Learner

Pridružite se grozdu na vozlišču, ki naj bi se pridružilo, pri čemer uporabite podatke iz zadnjega koraka in rezervno geslo vozlišča, na katerem je bil registriran novi član.

nitropyREST API

Potrebne možnosti

Možnost	Opis
--backup-passphrase TEXT	Varnostna gesla za varnostno kopijo vozlišča, na katerem je bil registriran novi član

Argumenti

Argument	Opis
JOIN_DATA_PATH	Pot do datoteke s podatki za združevanje iz zadnjega koraka

Primer

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

Opozorilo

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.

V tej fazi se je novo vozlišče pridružilo kot vozlišče v fazi » « ( ): sinhronizira se s klastrom, vendar še ni operativno. Po drugi strani pa morebitne težave z vozliščem v tej fazi ne bodo povzročile težav v klastru, zaradi česar je ta postopek varen.

Zadnji korak za dokončanje priključitve je povišanje novega vozlišča v polnopravnega člana.

Promoting the New Learner

Glede na razmere v omrežju in v grozdu lahko traja nekaj časa, preden novi član uskladi svoje stanje z grozdom. Ko se to zgodi, se lahko iz statusa učenca povzdigne v polnopravnega člana.

Opozorilo

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.

Novega člana lahko poskusite napredovati na naslednji način. ID člana lahko poiščete s prikazom seznama članov grozda.

nitropyREST API

Argumenti

Argument	Opis
MEMBER_ID	The ID of the learner to be promoted

Primer

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

Če se učenec še ni uspel uskladiti, bo postopek neuspešen (HTTP-koda 412 v REST API) in je treba poskusiti s ponovnim napredovanjem kasneje.

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

Potrebovali boste okolje, v katerem je na voljo etcd v3.6, z naslovom IPv4 (vsaj), ki je dosegljiv drugim članom vaše gruče. Dovoljen mora biti promet TCP na vrata 2380 in z njih.

Ustvarite prazen imenik, v katerem bo etcd hranil svoje podatke, in zapišite njegovo pot (mi bomo uporabili /var/etcd/data). Zagotovite, da ima uporabnik, ki bo zagnal proces, dovoljenje za branje in pisanje v imenik.

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.

Nato boste morali ustvariti potrdilo za pričo in ga podpisati s CA, da bo lahko komunicirala s svojimi vrstniki. To lahko storite na primer prek 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

Dobljene witness.key in witness.pem shranite tudi v /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

Za razliko od naprav NetHSM, ki samodejno izberejo ime vozlišča (z uporabo ID naprave), morate izbrati ime za vsako dodano pričo, pri tem pa poskrbite, da so imena edinstvena. V naslednjih primerih bomo uporabili ime „witness1“.

Z odgovorom NetHSM za registracijo priče pripravite spremenljivke obrazca:

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"

Na koncu ustvarite datoteko etcd.conf.yml z uporabo datoteke s predlogo, ki je na voljo v datoteki docs/etcd_witness.conf.template:

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

Tako boste dobili datoteko z obrazcem:

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

Zagon etcd na želeni način (ročno, systemd storitev, vsebnik itd.) in ga usmerite na konfiguracijsko datoteko, ustvarjeno v prejšnjem koraku:

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

Najprej bi morali videti, kako se sistem zažene, nato se pridružite grozdu kot udeleženec in nadoknadite zamujene podatke.

Promote the Witness

Nazadnje, po nekaj časa, upoštevajte običajna navodila iz spletne strani v razdelku »Promoting the New Learner«, da napredujete pričo. Če to ne uspe, poskusite kasneje.

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

etcdctl get /config/version

Ta ključ mora obstajati in vsebovati vrednost „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

Varnostno kopiranje in obnavljanje

Varnostno kopiranje deluje enako kot brez gruče in ga lahko zahtevate iz katerega koli vozlišča gruče. Varnostna kopija bo ustvarila podatke za celotno gručo, vključno s polji za posamezna vozlišča (čeprav bodo ta prezrta, razen če se varnostna kopija obnovi v vozlišču, ki ni bilo dodeljeno).

Varnostno kopijo, izdelano v gruči, je mogoče obnoviti v isti gruči, tudi če so bila od takrat dodana ali odstranjena nekatera vozlišča. Takšne obnovitve, opravljene v delujočih gručah, ne bodo vplivale na konfiguracijske vrednosti (samo na ključe, uporabnike, prostore imen), tako kot vsaka druga delna obnovitev.

Obnovitev varnostne kopije v vozlišču, ki ni bilo dodeljeno, bo obnovila polja, značilna za vozlišče (kot so omrežna konfiguracija, certifikati itd.) vozlišča, ki je bilo uporabljeno za ustvarjanje varnostne kopije.

Obnovitev velike varnostne kopije lahko za nekaj časa preobremeni gručo, medtem ko vozlišče, ki izvaja obnovitev, posreduje spremembe drugim vozliščem.

Ta operacija ostaja združljiva z varnostnimi kopijami, narejenimi v prejšnjih različicah NetHSM.

Opomba

Obnovitev varnostne kopije, izdelane v drugem vozlišču Z z drugačnim domenskim ključem, v vozlišču A bo pravilno prepisala domenski ključ vozlišča A kot prej. Če pa je bil A v gruči z vozliščem B, bo vozlišče B postalo neuporabno, saj se domenski ključ Z ne bo obnovil na vozlišču B.

Z drugimi besedami, obnovitev izvajajte le v gruči, katere varnostne kopije so bile izdelane v isti gruči (čeprav so bila vozlišča od takrat morda odstranjena ali dodana). Če želite obnoviti tujo varnostno kopijo v vozlišču, ga najprej varno odstranite iz gruče, nato ga tovarniško ponastavite in obnovite varnostno kopijo.

Čisto odstranjevanje vozlišča

Dokler del gruče še vedno izpolnjuje kvorum, je mogoče katerega koli njenega člana uporabiti za odstranitev drugega vozlišča iz gruče, ne glede na to, ali je to vozlišče že nedosegljivo ali pa se pričakuje, da bo.

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

Argumenti

Argument	Opis
MEMBER_ID	The ID of the node to be removed

Primer

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

Opomba

Tudi vozlišče, ki se je pridružilo grozdu, a še ni bilo povišano, se lahko na ta način varno odstrani.

Recovering a Failed Node

Vozlišče, ki poroča o stanju » Failed« ( ni uspelo), ne bo odgovarjalo na večino običajnih ukazov. Kljub temu ga je mogoče izklopiti, ponovno zagnati, ponastaviti, diagnosticirati ali izolirati.

Opozorilo

Obstoj stanja » « (neuspešno), » «, operacije » ` «, »diagnose` « in » ` « ter »force-new` « velja le za različico 5.0 in novejše. V različici 4.0 se vozlišče z izgubljenim kvorumom preneha odzivati na vse zahteve. ga je treba ponastaviti na tovarniške nastavitve.

Med pogoste vzroke za stanje vozlišča » « (Napaka) spadajo:

• Trajno izgubljeno kvorum.

• Začasna izguba kvoruma (npr. ob dodajanju drugega vozlišča v grozd, ko se to vozlišče še ni priključilo).

• etcd se trenutno ponovno zaganjata (npr. zaradi spremembe certifikatov ali ponovne konfiguracije omrežja).

• Skupina je izpostavljena zelo visoki obremenitvi (npr. med obnovitvijo zelo obsežne varnostne kopije).

Ne glede na vzrok bo NetHSM prešel v stanje » Failed« ( ) šele po najmanj eni minuti neuspešnih poskusov vzpostavitve povezave z lastno bazo podatkov. S tem se želi preprečiti napačne prehode, ki jih povzročajo zelo kratkotrajne nestabilnosti.

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

Primer

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

Opomba

Če in ko bo baza podatkov spet na voljo (npr. ko bo kvorum ponovno vzpostavljen zaradi odprave omrežne napake), bo NetHSM samodejno prešel iz stanja » Failed« ( ) v stanje, v katerem je bil prej (ali pa bo nadaljeval z običajnim zagonskim postopkom, če se je ravno zaganjal), brez potrebe po kakršnem koli ročnem posegu. Potrebno bo do ene minute po odpravi težave, da se grozd stabilizira, da HSM zazna odpravo težave in spremeni stanje.

Če ugotovite, da je napaka trajna (npr. izguba kvoruma brez upanja na rešitev vzroka), lahko:

• V vozlišču izvedite ponastavitev na tovarniške nastavitve ( ), s čimer se bodo izbrisali vsi podatki, nato pa obnovite varnostno kopijo.

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

Opomba

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

Opozorilo

Po posodobitvi iz različice < 5.0 bo končna točka force-new vedno prikazovala napako »Unauthorized«, dokler se HSM ne odklene ali se geslo za odklepanje vsaj enkrat ne spremeni.

Software Updates in Clusters

Prihodnje posodobitve bodo označene kot „varne za gruče“ (to naj bi bila večina) ali „nevarne za gruče“.

Posodobitve, ki so varne za gruče, lahko uporabite za vozlišča, ki so del gruče, ne da bi jih prej odstranili iz gruče. Vendar morate tako kot pri vseh operacijah zagotoviti, da to storite na enem vozlišču hkrati in v gruči, kjer odstranitev vozlišča ne zmanjša kvoruma (npr. če posodobitev ne uspe).

Posodobitve, ki niso varne za gručo, je treba uporabiti v izoliranih vozliščih. Skupino morate razstaviti (vozlišča odstraniti eno za drugim), tovarniško ponastaviti vsa vozlišča razen enega, posodobitev uporabiti v vsakem vozlišču, nato pa vsa ponastavljena vozlišča združiti s preostalim vozliščem.

Pred takimi operacijami naredite varnostno kopijo.

Ponovno konfiguriranje obstoječe gruče

Changing the Cluster CA

Obstoječa gruča (z dvema ali več vozlišči) med delovanjem ne more spremeniti svojega CA gruče. Če morate to potrdilo spremeniti: izberite vozlišče, odstranite vsa druga vozlišča, posodobite CA, nato pa naj se drugi člani ponovno pridružijo.

Changing the Network Configuration of Nodes

Če spremenite omrežno konfiguracijo vozlišča (npr. spremenite njegov IP), bodo druga vozlišča samodejno obveščena o posodobitvi. Vendar morate zagotoviti, da take posodobitve izvajate le na enem vozlišču naenkrat in v gruči, v kateri izguba tega vozlišča ne bi povzročila izgube kvoruma.