Clustering

Piezīme

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.

• Tas vēl nav pierādīts pietiekamā skaitā ražošanas vidē, un tajā var būt kļūdas.

NetHSM 4.0 un jaunākās versijas atbalsta klasterizāciju, lai sinhronizētu datus starp vairākiem NetHSM tieši. Tas nodrošina augstu atslēgu ģenerēšanas biežumu, augstu pieejamību un slodzes līdzsvarošanu. NetHSM klasteris ir balstīts uz etcd, kas izmanto Raft konsensa algoritmu, lai nodrošinātu stingru konsekvenci. Tas nodrošina, ka dati (piemēram, atslēgas) visos NetHSM vienmēr ir pareizi.

Pirms NetHSM klastera izveides iepazīstieties ar šo tehnoloģiju un tās ierobežojumiem, lai izvairītos no nejaušas darbības pārtraukšanas un datu zaudēšanas. Papildus šim dokumentam varat iepazīties arī ar etcd dokumentāciju.

Operational Redundancy

Mēs sauksim „mezglu“ par NetHSM, kas ir paredzēts kā klastera daļa. Klasteris no N mezgliem turpinās darboties, kamēr vismaz (N/2)+1 mezgli ir veseli un sasniedzami. Šo minimālo veselu un sasniedzamu mezglu skaitu sauc par kvorumu.

Klasterī, kurā rādītājs nokrīt zem šīs robežvērtības (piemēram, tīkla problēmu dēļ), nav iespējams ievēlēt līderi, un katra mezgla vietējā „ ` “ etcd` instance vairs nespēj veikt lasīšanas un rakstīšanas darbības. Tas nozīmē šādus scenārijus.

Viens mezgls nedarbojas, bet kvorums joprojām ir sasniegts

Trīs mezglu klasterī, ja viens mezgls nedarbojas (sabojājas vai kļūst nesasniedzams tīkla apstākļu dēļ), pārējie divi mezgli turpina darbu un apkalpo pieprasījumus.

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.

Ja ierīce neatgūst darbspēju, tā ir jāizņem no klastera ` <clustering.html#removing-a-node-cleanly>` __ un vai nu jāveic atjaunošana, lai piekļūtu tās datiem (taču tā vairs nebūs klastera daļa), vai arī jāveic rūpnīcas iestatījumu atjaunošana un no jauna jāiziet pievienošanās process.

Notiek tīkla sadalīšana un kvorums joprojām ir sasniegts

Tas ir tikai iepriekšējā scenārija vispārinājums. 5 mezglu klasterī, kurā, piemēram, 3 mezgli atrodas vienā fiziskā vietā A un 2 mezgli atrodas citā vietā B, tīkla problēma, izolējot A un B, nozīmētu, ka:

• A atrašanās vietas 3 mezgli atbilst kvorumam (šajā gadījumā 3), tāpēc tie turpina darboties.

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

• Ja tīkla problēma ir atrisināta, 2 mezgli tīri tīri pievienosies pārējiem 3 mezgliem.

Citiem vārdiem sakot, sliktākajā gadījumā tīkla sadalīšanās (klasterī ar nepāra skaitu mezglu) atstās lielāko klastera daļu darbspējīgu, bet mazāko daļu nedarbspējīgu, līdz sadalīšanās tiks novērsta.

Kvorums ir ilgstoši zaudēts

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.

Tas var notikt, piemēram, ja 2 mezglu klasterī (kur kvorums ir 2) neizdodas viens mezgls. Šādā situācijā neizdevušos mezglu pēc tam nevar tīri noņemt no kopas, jo atlikušais veselais mezgls jau nedarbojas, jo ir zaudējis kvorumu.

Tāpēc ieteicams klasterī vienmēr izmantot nepāra mezglu skaitu un bieži veikt dublēšanu.

Lai būtu skaidrs, uz laiku kvoruma zaudēšana (piemēram, ja restartējat visus klastera mezglus kopā vai īslaicīga tīkla kļūme izolē mezglus) nav problēma: tiklīdz tiks savienots pietiekams skaits mezglu (bez nepieciešamības manuāli atkārtoti pieslēgties), lai sasniegtu kvorumu, klasteris atsāks normālu darbību. Tikai pastāvīgu kļūmju gadījumā, piemēram, tīkla sadalīšanas, tīkla nepareizas konfigurācijas, autentifikācijas problēmu vai aparatūras kļūmju gadījumā būs nepieciešama manuāla rīcība.

Lai iegūtu vairāk informācijas, skatiet etcd BIEŽĀK UZDOTIE JAUTĀJUMI.

2 mezglu klasteris

Divu mezglu aktīvā/pasīvā klastera darbība vēl nav atbalstīta, un tā tiks pievienota kādā no nākamajām versijām. Mēs iesakām ieviest trešo mezglu - vai nu trešo NetHSM, vai etcd „liecinieku“, ko var izmantot jebkurā datorā. Skatiet nākamo sadaļu „Liecinieks“.

Liecinieks

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.

Tomēr funkcija ir izstrādāta tā, ka klasterim nav nepieciešams pievienot pilnu, īstu NetHSM ierīci, lai sasniegtu stabilu mezglu skaitu. Tā vietā varat izvietot un pievienot „liecinieka“ mezglu pats. Šāds mezgls ir tikai etcd gadījums, kas darbojas jūsu izvēlētajā datorā (vai konteinerā) un ir savienots ar klasteri. Tas tiks atpazīts kā parasts mezgls no reālajām klastera ierīcēm un saņems visus datus un atjauninājumus no ierīcēm (bet, protams, ar to nevarēsiet veikt nekādas HSM operācijas - tas tikai glabā datus).

Security Considerations

Liecinieka mezglam (vai jebkurai citai personai, kam ir piekļuve šim mezglam) ir tieša piekļuve visu klastera mezglu datu glabāšanas sistēmai (piemēram, jūs varat izrakstīt visus ierakstus un atbilstošās vērtības, izmantojot etcdctl get "/" "0").

Tomēr, izņemot konfigurācijas versiju (/config/version, kurai vienmēr jābūt „1“), stingri visas vērtības ir šifrētas (vai nu ar ierīces atslēgu mezglam specifiskām vērtībām, vai ar domēna atslēgām citām vērtībām), tādējādi nodrošinot sensitīvu datu konfidencialitāti.

Tomēr ņemiet vērā, ka ļaunprātīgs mezgls var:

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

Koplietošanas informācija starp mezgliem

NetHSM klasteris nozīmē, ka lielākā daļa datu ir koplietojama starp tiem. Jebkura atslēgu, lietotāju vai nosaukumu telpu pievienošana, modificēšana vai dzēšana vienā mezglā galu galā tiek atspoguļota visos pārējos mezglos. Kopumā jebkura darbība, kas maina stāvokli, maina stāvokli katrā mezglā. Tas attiecas arī uz rezerves kopijas atjaunošanas operāciju, kas darbojas kā parasti.

Turpmākajās sadaļās ir sīkāk aprakstīts, kuri dati ir pilnībā lokāli, kuri dati tiek glabāti koplietojamajā etcd krātuvē, bet paliek specifiski mezglam, un kuri dati ir pilnībā koplietojami visiem mezgliem.

Nav saglabāts etcd

Katra mezgla ierīces atslēga tiek saglabāta tikai lokāli un nekad netiek kopīgota starp mezgliem.

Uzglabāts etcd, bet specifisks mezglam

Turpmāk norādītie dati tiek glabāti etcd katrā mezglā dažādās darbības jomās. Tādējādi tie ir pieejami katram mezglam, bet nav vienādi visos mezglos (katram mezglam var būt atšķirīga šo datu vērtība).

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

Ņemiet vērā, ka, lai gan katram mezglam ir sava bloķētās domēna atslēgas versija (jo katrs mezgls to bloķē ar savu ierīces atslēgu vai atbloķēšanas paroli), pamatā esošā domēna atslēga ir koplietojama starp mezgliem (lai piekļūtu koplietojamiem HSM datiem, piemēram, atslēgām).

Uzglabā etcd un koplietošanas

Visi turpmāk minētie dati tiek glabāti etcd globālajā darbības jomā, tāpēc tie ir vienādi visos klastera mezglos:

HSM dati:

• Keys

• Lietotāji

• Nosaukumu telpas

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

Jebkurš klasteris sākotnēji tiks sākts ar vienu mezglu. Jauni mezgli klasterim pievienosies viens pēc otra.

Preparing Nodes

Tīkla datplūsma starp mezgliem tiek šifrēta un autentificēta, izmantojot to TLS sertifikātu.

Visiem mezgliem, kuriem paredzēts būt vienas kopas daļai, vispirms jāuzstāda kopīga sertifikātu iestāde (CA), kas ļaus tiem pārbaudīt, vai citi mezgli ir likumīgi.

Turpmāk mēs pieņemam, ka visi mezgli ir tikko nodrošināti un darbojas.

Networking

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

CA izveide un instalēšana

Lietotājiem pašiem jāizveido CA, izmantojot savus līdzekļus un atbilstoši saviem darbības ierobežojumiem, pārliecinoties, ka tā ļauj izmantot vismaz keyCertSign atslēgu.

Piemēram, minimālo CA var izveidot, izmantojot 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

Tagad šī CA ir jāuzstāda katrā mezglā.

Lai to izdarītu, vispirms no mezgla jāizveido sertifikāta parakstīšanas pieprasījums (CSR), kā aprakstīts sadaļā „ ” TLS Certificate. Izmantojot nitropija, to var izdarīt ar komandu nitropy nethsm --host $NETHSM_HOST csr --api.

Piezīme

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

Izmantojot „ ” nitropiju, izmantojiet opciju --san, piemēram, --san "IP:192.168.1.1".

Ja vēlaties izmantot publisko sertifikātu izsniedzēju (CA) savu sertifikātu parakstīšanai, jūsu mezgliem jāizmanto publiskās IP adreses. Tas ir saistīts ar drošības prasību, kas aizliedz publiskajam CA izsniegt sertifikātus, kuru IP SAN laukā ir norādīta privātā IP adrese.

Ņemot vērā iegūto CSR (nosauksim to par nethsm.csr), mēs varam tam ģenerēt sertifikātu, kas ir gatavs instalēšanai. Piemēram, izmantojot 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

Tad instalējiet iegūto new_cert.pem, kā aprakstīts sadaļā „ ” TLS sertifikāts (ar 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

Arguments	Apraksts
FILENAME`	The path of the CA file

Piemērs

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

Uzstādīto klastera CA var atrast, izmantojot komandu ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Piezīme

Šis process ir jāatkārto katram mezglam.

Pulksteņa sinhronizācija

Pārliecinieties, ka katram mezglam ir iestatīts precīzs sistēmas laiks, vēlams izmantojot NTP/NTS, nevis manuālu laika iestatīšanu. To var izdarīt, konfigurējot Time un 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. Kad tas būs panācis pārējos, paaugstiniet mezglu no mācību posma uz pilntiesīga locekļa statusu

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.

Jauna mezgla reģistrēšana

Turiet līdzi pievienojamā mezgla IP. Šī mezgla pilnais URL ( vienādranga URL terminoloģijā etcd) būs https://<IP_of_node>:2380 (piemēram, https://192.168.1.1:2380). Portam jābūt 2380, tāpēc pārliecinieties, vai ugunsmūris starp mezgliem atļauj TCP datplūsmu šajā 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.

nitropyREST API

Piemērs

$ 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

Vienreizējas opcijas

Iespēja	Apraksts
--url TEXT	Jaunā mezgla vienaudža URL (var iestatīt vairākas reizes)

Argumenti

Arguments	Apraksts
JOIN_DATA_PATH	Celiņš, kurā tiek ierakstīti apvienotie dati

Piemērs

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

Šī komanda parāda klastera dalībnieku sarakstu un failā ieraksta datus, kas nepieciešami jaunajam mezglam, lai pievienotos klasterim (ieskaitot pievienošanās komplektu). Saglabājiet šo failu nākamajam solim.

Piezīme

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.

Lai gan šis „mācībnieka” jēdziens paredz papildu posmu (paaugstināšanu), tas nodrošina drošāku klastera darbību, jo jebkāda problēma ar jauno mezglu nevar izraisīt nestabilitāti visā klasterī, pirms tas ir paaugstināts.

Saglabājiet datu apvienošanas failu nākamajam solim (vai atbildi, ja izmantojāt REST API).

Joining the Cluster as a Learner

Pievienojieties klasterim tajā mezglā, kuram ir paredzēts pievienoties, izmantojot pēdējā soļa datus un rezerves paroli no tā mezgla, kurā tika reģistrēts jaunais dalībnieks.

nitropyREST API

Nepieciešamās opcijas

Iespēja	Apraksts
--backup-passphrase TEXT	Tā mezgla rezerves paroles frāze, kurā tika reģistrēts jaunais dalībnieks

Argumenti

Arguments	Apraksts
JOIN_DATA_PATH	Datu apvienošanas faila ceļš no iepriekšējā soļa

Piemērs

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

Brīdinājums

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.

Šajā posmā jaunais mezgls ir pievienojies kā „ ” mācīšanās mezgls: tas sinhronizējas ar klasteri, bet vēl nedarbojas. No otras puses, jebkādas problēmas ar šo mezglu šajā posmā neradīs grūtības klasterim, tādējādi padarot šo darbību drošu.

Pēdējais solis, lai pabeigtu pievienošanos, ir piešķirt jaunajam mezglam pilntiesīga locekļa statusu.

Promoting the New Learner

Atkarībā no tīkla un klastera apstākļiem jaunajam dalībniekam var paiet kāds laiks, līdz tas panāk pārējos klastera dalībniekus. Kad tas ir izdarīts, to var paaugstināt no mācību dalībnieka statusa līdz pilntiesīgam dalībniekam.

Brīdinājums

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.

Jūs varat mēģināt paaugstināt jauno dalībnieku šādi. Dalībnieka ID var atrast, izvadot klāstera dalībnieku sarakstu.

nitropyREST API

Argumenti

Arguments	Apraksts
MEMBER_ID	The ID of the learner to be promoted

Piemērs

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

Ja mācībnieks vēl nav panācis pārējos, tad šī darbība neizdosies (HTTP kods 412 REST API) un pārcelšana uz nākamo līmeni būtu jāmēģina vēlāk.

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

Jums būs nepieciešama vide, kurā ir pieejama etcd v3.6 versija ar IPv4 adresi (vismaz), kas ir sasniedzama citiem klastera dalībniekiem. Ir jāatļauj TCP datplūsma uz un no 2380 porta.

Izveidojiet tukšu direktoriju, kurā etcd glabās datus, un ierakstiet tās ceļu (mēs izmantosim /var/etcd/data). Pārliecinieties, ka lietotājam, kas palaidīs procesu, ir tiesības lasīt un rakstīt šajā direktorijā.

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.

Pēc tam lieciniekam būs jāizveido sertifikāts un jāparaksta tas ar CA, lai tas varētu sazināties ar saviem kolēģiem. To var izdarīt, piemēram, izmantojot 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

Iegūtos witness.key un witness.pem saglabājiet arī /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

Atšķirībā no NetHSM, kas automātiski izvēlas sev mezgla nosaukumu (izmantojot ierīces ID), jums ir jāizvēlas nosaukums katram pievienotajam lieciniekam, pārliecinoties, ka nosaukumi ir unikāli. Turpmākajos piemēros mēs izmantosim „witness1“.

Kopā ar NetHSM atbildi par liecinieka reģistrāciju sagatavojiet veidlapas mainīgos:

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"

Visbeidzot, izveidojiet etcd.conf.yml failu, izmantojot docs/etcd_witness.conf.template šablona failu:

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

Pēc tam tiks iegūts veidlapas fails:

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

Palaidiet etcd vēlamajā veidā (manuāli, systemd servisu, konteineru utt.), norādot uz iepriekšējā solī izveidoto konfigurācijas failu:

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

Jums vajadzētu redzēt, kā tas sāk darboties, pievienoties klasterim kā mācību sistēma un panākt datu apjomu.

Promote the Witness

Beidzot, pēc kāda laika, ievērojiet parastās instrukcijas, kas sniegtas sadaļā „ ” („Veicinot jauno apmācāmo”), lai veicinātu liecinieka darbību. Ja tas neizdodas, mēģiniet vēlāk.

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

etcdctl get /config/version

Šai atslēgai ir jābūt un tajā jābūt „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

Rezerves kopēšana un atjaunošana

Rezerves kopēšana darbojas tāpat kā bez klastera, un to var pieprasīt no jebkura klastera mezgla. Tā dublēs datus par visu klasteri, ieskaitot mezglam raksturīgos laukus (tomēr tie tiks ignorēti, ja vien dublējums netiks atjaunots neaizpildītā mezglā).

Kopas dublējumu var atjaunot tajā pašā kopā, pat ja kopš tā laika ir pievienoti vai noņemti daži mezgli. Šādi darbības klasteros veikti atjaunošanas darbi neietekmēs konfigurācijas vērtības (tikai atslēgas, lietotājus, nosaukumu telpas), tāpat kā jebkura cita daļēja atjaunošana.

Atjaunojot dublējumu neprovizētā mezglā, tiks atjaunoti mezglam raksturīgie lauki (piemēram, tīkla konfigurācija, sertifikāti u. c.) mezglā, kas tika izmantots dublējuma izveidei.

Lielas dublējuma kopijas atjaunošana uz kādu laiku var pārslogot kopu, kamēr mezgls, kas veic atjaunošanu, pārsūta izmaiņas pārējiem mezgliem.

Šī darbība ir saderīga ar iepriekšējās NetHSM versijās veiktajām dublējuma kopijām.

Piezīme

Atjaunojot mezglā A dublējumu, kas izveidots citā mezglā Z ar citu domēna atslēgu, A domēna atslēga tiks pareizi pārrakstīta kā iepriekš. Tomēr, ja A ir bijis klasterī ar mezglu B, B nedarbosies, jo B netiks atjaunota Z domēna atslēga.

Citiem vārdiem sakot, atjaunošanu veiciet tikai tajā klasterī, kura dublējumi veikti tajā pašā klasterī (lai gan arī šajā klasterī mezgli var būt noņemti vai pievienoti). Ja vēlaties atjaunot ārējo dublējumu kādā mezglā, vispirms droši noņemiet to no klastera, pēc tam atjaunojiet tā rūpnīcas iestatījumus un atjaunojiet dublējumu.

Tīra mezgla noņemšana

Kamēr kāda klastera daļa joprojām atbilst kvorumam, jebkuru tās locekli var izmantot, lai no klastera izslēgtu citu mezglu neatkarīgi no tā, vai šis mezgls jau nav sasniedzams, vai arī paredzams, ka tas būs.

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

Arguments	Apraksts
MEMBER_ID	The ID of the node to be removed

Piemērs

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

Piezīme

Arī mezglu, kas ir pievienojies klasterim, bet vēl nav paaugstināts, šādā veidā var droši noņemt.

Recovering a Failed Node

Meitasmezgls, kas ziņo par stāvokli „ Failed“ ( neizdevās), atteiksies atbildēt uz lielāko daļu parasto darbību. To joprojām var izslēgt, pārstartēt, atiestatīt , diagnosticēt vai izolēt.

Brīdinājums

Operācijas „ ”, „Failed ”, „ ` ”, „diagnose` ” un „ ` ” („force-new` ”) ir pieejamas tikai sākot ar 5.0. versiju. 4.0. versijā mezgls, kuram ir zaudēts kvorums, pārtrauks atbildēt uz visiem „ ” un „ ” pieprasījumiem. Tam „ ” ir jāveic „ ” rūpnīcas iestatījumu atjaunošana.

Biežākie iemesli, kāpēc mezgls atrodas stāvoklī „ ” („ ” kļūda”), ir šādi:

• Ilgstoši zaudēts kvorums.

• Pagaidu kvoruma trūkums (piemēram, pievienojot klasterim otro mezglu, ja šis mezgls vēl nav pievienojies).

• etcd pašlaik tiek pārstartēts (piemēram, tāpēc, ka ir mainīti sertifikāti vai pārkonfigurēts tīkls).

• Klasterim ir ļoti liela slodze (piemēram, atjaunojot ļoti lielu dublējumu).

Neatkarīgi no iemesla, NetHSM pāries uz stāvokli „ Failed“ ( ) tikai pēc tam, kad vismaz vienu pilnu minūti būs veikti nesekmīgi mēģinājumi sazināties ar tā datu bāzi. Tas ir nepieciešams, lai izvairītos no nepamatotām pārejām, ko izraisa ļoti īslaicīgas nestabilitātes.

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

Piemērs

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

Piezīme

Ja un kad datu bāze atkal kļūs pieejama (piemēram, kvorums tiks atjaunots, jo tīkla problēma ir atrisināta), NetHSM automātiski pāries no stāvokļa „ Failed” uz stāvokli, kādā tas atradās iepriekš (vai atsāks parasto sākšanas secību, ja tas bija sākšanas procesā), bez nepieciešamības veikt jebkādas manuālas darbības. Līdz brīdim, kad klasteris stabilizēsies, HSM atpazīs problēmas atrisinājumu un mainīs stāvokli, var paiet līdz pat vienai minūtei pēc problēmas novēršanas.

Ja secināt, ka darbības traucējums ir ilgstošs (piemēram, kvoruma zaudēšana, ja nav cerību atrisināt pamatcēloni), varat:

• Veiciet mezgla rūpnīcas iestatījumu atjaunošanu ( ), kas izdzēsīs visus datus, un atjaunojiet dublējumu.

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

Piezīme

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

Brīdinājums

Pēc atjaunināšanas no versijas, kas ir zemāka par 5.0, galapunkts „ ` “ force-new` vienmēr rādīs statusu „Unauthorized“, kamēr HSM netiks atbloķēts vai atbloķēšanas parole vismaz reizi netiks mainīta.

Software Updates in Clusters

Turpmākie atjauninājumi tiks atzīmēti kā „cluster-safe“ (tam vajadzētu būt vairākumam) vai „cluster-unsafe“.

Kopas drošus atjauninājumus var piemērot mezgliem, kas ir kopas daļa, pirms tam nenoņemot tos no kopas. Tomēr, tāpat kā visu citu darbību gadījumā, jums jānodrošina, ka tas tiek darīts pa vienam mezglam un klasterī, no kura noņemot mezglu, netiek samazināts kvorums (piemēram, ja atjauninājums neizdodas).

Kopas nedrošie atjauninājumi jāpiemēro izolētiem mezgliem. Jums ir jāizjauc klasteris (noņemot mezglus pa vienam), jāatjauno visi mezgli, izņemot vienu, jāpiemēro atjauninājums katram mezglam, pēc tam visiem atjauninātajiem mezgliem jāpievienojas atlikušajam mezglam.

Pirms šādu darbību veikšanas izveidojiet dublējuma kopiju.

Esoša klastera pārkonfigurēšana

Changing the Cluster CA

Esoša kopa (ar diviem vai vairāk mezgliem) nevar mainīt savu kopas CA darbības laikā. Ja nepieciešams mainīt šo sertifikātu: izvēlieties mezglu, noņemiet visus pārējos mezglus, atjauniniet CA un pēc tam palūdziet pārējiem dalībniekiem atkal pievienoties.

Changing the Network Configuration of Nodes

Mainot mezgla tīkla konfigurāciju (piemēram, mainot tā IP), par atjauninājumu automātiski tiek automātiski informēti pārējie mezgli. Tomēr jums jānodrošina, ka šādus atjauninājumus vienlaikus veicat tikai vienā mezglā un klasterī, kurā, zaudējot šo mezglu, netiks zaudēts kvorums.