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.

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 <clustering.html#recovering-a-failed-node> 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

Klasterizācijas ar etcd raksturs padara to uzticamāku, jo vairāk mezglu ir klasterī. Kā paskaidrots `sadaļā par darbības dublēšanu `_, ideālā gadījumā klasteros jābūt vismaz 3 mezgliem, lai būtu vieta atteicei, jo 2 mezglu klasteris pilnībā sabojājas, ja sabojājas tikai viens.

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

Ņemiet vērā, ka pagaidām konfigurācijas/domēna krātuves versija var būt tikai 1. versija (ja jūsu programmatūras versija atbalsta klasterizāciju, tad jums ir šī versija). Sīkāku informāciju par programmatūras atjauninājumu instalēšanas drošību klasterī skatiet sadaļā Programmatūras atjauninājumi klasteros.

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 using the /config/network endpoint (refer to the API documentation).

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

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

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

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

Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).

Visbeidzot, CA (CA.pem) tagad var instalēt ar /config/tls/cluster-ca.pem galapunktu (skatiet API dokumentāciju). Tas ir iespējams tikai tad, kad instalētais TLS sertifikāts ir parakstīts. Pretējā gadījumā operācija tiks noraidīta.

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

Vispirms pārliecinieties, ka mezglā, kas tiks izmantots, lai reģistrētu jaunu savienotāju, ir konfigurēta rezerves parole (skatiet API dokumentāciju par /config/backup-passphrase galapunktu).

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

Jūs varat vēlreiz pārbaudīt, vai URL ir pareizs, izsaucot GET /cluster/members uz mezgla, kuram paredzēts pievienoties. Šajā sarakstā jānorāda tikai viens loceklis: viņš pats.

Pēc tam reģistrējiet šo gaidīto URL jebkurā esošajā kopas mezglā (ja kopas vēl nav, veiciet to NetHSM, kas kalpos kā sākotnējais kopas mezgls). To veic, izmantojot POST /cluster/members galapunktu (skat. API dokumentāciju), nododot tam JSON ķermeni, kas satur URL.

Ja tas izdodas, tiek atgriezta veidlapas JSON struktūra:

{
  "members": [
    {
      "name": "",
      "urls": [
        "https://172.22.1.3:2380"
      ],
      "learner": true
    },
    {
      "name": "9ZVNM2MNWP",
      "urls": [
        "https://172.22.1.2:2380"
      ],
      "learner": false
    }
  ],
  "joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}

kurā ir informācija, kas nepieciešama, lai jaunais mezgls varētu pievienoties klasterim. Jo īpaši tajā ir uzskaitīti visi kopas locekļi (kur loceklis ar tukšu nosaukumu ir jaunais pievienošanās mezgls). Tajā ir arī domēna atslēga, kas šifrēta gan ar atbloķēšanas, gan dublēšanas paroli - tāpēc pirms tam jākonfigurē dublēšanas parole.

Piezīme

Ievērojiet iepriekš minētajā atbildē, ka jaunais dalībnieks ir „mācībnieks”: tagad tas var izveidot savienojumu ar klasteri un saņemt no tā datus, taču nevar piedalīties, kamēr netiks paaugstināts statusā, par ko tiks runāts tālāk.

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 šo atbildi nākamajam solim.

Joining the Cluster as a Learner

Paņemiet pēdējā soļa atbildi un pievienojiet tai backupPassphrase lauku, kas satur tā mezgla rezerves paroli, kurā reģistrēts jaunais pievienotājs, un nododiet šos datus izsaukumam uz POST /cluster/join (skatiet API dokumentāciju) mezglā, kuram paredzēts pievienoties.

Brīdinājums

`` izsaukums POST /cluster/join` paliks bloķēts, līdz jaunais mezgls tiks manuāli paaugstināts (skatīt zemāk). Tas ir normāli. Ja izsaukums veiksmīgi atgriežas, tas norāda, ka pievienošanās un paaugstināšana ir noritējusi veiksmīgi.

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

Meitasmezgla paaugstināšana palielina klastera kvoruma slieksni (skatiet „ ” API dokumentāciju un šā dokumenta sadaļu „ ” par darbības rezerves sistēmu). Pirms meitasmezgla paaugstināšanas pārliecinieties, ka tam ir stabils savienojums ar klasteri.

Jūs varat mēģināt paaugstināt jaunā dalībnieka statusu, izsaucot POST /cluster/members/{MemberID}/promote (skatiet „ ” API dokumentāciju). Ja mācībnieks vēl nav panācis pārējos, šī darbība beigsies ar kļūdu un HTTP kodu 412, un statusa paaugstināšanu vajadzētu mēģināt 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).

Pierakstiet klastera atbildi: tajā jāietver klastera dalībnieku saraksts un savienotāju komplekts (šī daļa jums nebūs nepieciešama).

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,..."

Pieņemot, ka NetHSM atbilde ir saglabāta response.json failā, šos divus pēdējos mainīgos var ģenerēt automātiski, izmantojot šādas jq izteiksmes:

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.

Vispirms ir jāzina tā mezgla ID, kuru vēlaties noņemt, uzskaitot visus mezglus, izmantojot GET /cluster/members, un meklējot pareizo mezglu.

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.

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.

Lai palīdzētu jums saprast, kādā stāvoklī atrodas jūsu mezgls, joprojām ir pieejams galapunkts GET /health/diagnose, kas atgriež informāciju par pašreizējo stāvokli etcd un tā datu bāzi, ieskaitot žurnālus (skatiet API dokumentāciju).

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.

  • Izolējiet mezglu ar galapunktu POST /cluster/force-new, kas neatgriezeniski aizmirsīs visus pārējos klastera dalībniekus, atjaunos diskā esošos datus etcd un veiks sistēmas pārstartēšanu. Ja pamatcēlonis bija saistīts ar klasteri, mezgls izpildīs parasto sākšanas secību un nonāks vai nu stāvoklī Locked, vai Operational, atkarībā no iestatījumiem attiecībā uz automātisko sākšanu.

Piezīme

Ja mezgls tiek izolēts ar komandu ` `` force-new`, tas tagad vairs nebūs sinhronizēts ar klasteri: jebkādas jaunas ierakstīšanas darbības šajā mezglā vai klasterī vairs nevarēs saskaņot. Mezgls joprojām var atkal pievienoties klasterim, taču zaudēs visas savas lokālās izmaiņas.

POST /cluster/force-new galapunkts, kas ir pieejams tikai stāvoklī „ Failed” ( nav izdevies), prasa autentifikāciju, jo tas var radīt datu zudumu. Tomēr, tā kā šajā stāvoklī HSM lietotāji un lomas nav pieejami, galapunkts paredz, ka HTTPS klienti vienmēr autentificējas, izmantojot viltus lietotāju unlock un kā paroli — pēdējo zināmo atbloķēšanas paroli.

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.