Clustering

Poznámka

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.

• Toto riešenie zatiaľ nebolo overené v dostatočnom počte produkčných nasadení a môžu sa v ňom vyskytovať chyby.

NetHSM od verzie 4.0 podporuje zoskupenie na priamu synchronizáciu údajov medzi viacerými NetHSM. To podporuje vysokú frekvenciu generovania kľúčov, realizuje vysokú dostupnosť a vyrovnávanie záťaže. Klaster NetHSM je založený na etcd, ktorý používa Raft konsenzuálny algoritmus pre silnú konzistenciu. Tým sa zabezpečí, že údaje (napr. kľúče) sú vo všetkých NetHSM vždy správne.

Pred nastavením klastra NetHSM sa oboznámte s touto technológiou a jej obmedzeniami, aby ste predišli náhodnému výpadku a strate údajov. Okrem tohto dokumentu si môžete pozrieť aj dokumentáciu etcd.

Operational Redundancy

Uzol budeme nazývať NetHSM, ktorý má byť súčasťou klastra. Klaster N uzlov bude fungovať dovtedy, kým budú aspoň (N/2)+1 uzly zdravé a dosiahnuteľné. Toto minimálne množstvo zdravých a dosiahnuteľných uzlov sa nazýva kvorum.

V klastri, ktorý klesne pod túto hranicu (napr. kvôli sieťovému problému), nie je možné zvoliť žiadneho lídra a lokálna inštancia etcd na každom uzle nebude schopná vykonávať operácie čítania a zápisu. Z toho vyplývajú nasledujúce scenáre.

Jeden uzol vypadne a kvórum je stále dosiahnuté

Ak v klastri s tromi uzlami jeden uzol zlyhá (zlyhá alebo sa stane nedostupným v dôsledku sieťových podmienok), ostatné dva uzly budú pokračovať v práci a obsluhovať požiadavky.

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.

Ak sa už nikdy neobnoví, musí byť odstránené z klastra a buď prejsť obnovou, aby bolo možné získať prístup k jeho dátam (v tom prípade však už nebude súčasťou klastra), alebo musí byť obnovené na továrenské nastavenia a prejsť procesom pripojenia od začiatku.

Nastane rozdelenie siete a kvórum je stále dosiahnuté

Toto je len zovšeobecnenie predchádzajúceho scenára. V 5 uzlovom klastri, kde sú napr. 3 uzly na jednom fyzickom mieste A a 2 uzly na inom mieste B, by sieťový problém izolujúci A a B znamenal nasledovné:

• 3 uzly v lokalite A spĺňajú kvórum (v tomto prípade 3), takže pokračujú v prevádzke.

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

• Ak je problém so sieťou vyriešený, 2 uzly sa čisto spoja s ostatnými 3 uzlami.

Inými slovami, v najhoršom prípade sieťového rozdelenia (v klastri s nepárnym počtom uzlov) zostane väčšia polovica klastra funkčná, zatiaľ čo menšia polovica bude nefunkčná, kým sa rozdelenie nevyrieši.

Kvórum je trvalo stratené

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 sa môže stať napríklad v prípade, že v klastri s dvoma uzlami (kde je kvorum 2) zlyhá jeden uzol. V takejto situácii nie je možné zlyhaný uzol z klastra dodatočne čisto odstrániť, pretože zostávajúci zdravý uzol je už nefunkčný, keďže stratil kvorum.

Preto sa odporúča mať v klastri vždy nepárny počet uzlov a často zálohovať.

Aby bolo jasné, dočasne strata kvóra (napríklad ak reštartujete všetky uzly klastra spoločne alebo ak dočasná porucha siete izoluje uzly) nie je problém: akonáhle sa znovu pripojí dostatočný počet uzlov (bez toho, aby sa museli ručne znovu pripojiť) na dosiahnutie kvóra, klaster obnoví svoju normálnu prevádzku. Ručný zásah si vyžadujú len trvalé zlyhania, ako napríklad rozdelenie siete, nesprávna konfigurácia siete, problémy s overovaním alebo zlyhanie hardvéru.

Viac informácií nájdete na stránke etcd v ČASTO KLADENÝCH OTÁZKACH.

Klaster s 2 uzlami

Aktívny/pasívny klaster s dvoma uzlami zatiaľ nie je podporovaný a bude pridaný v niektorej z budúcich verzií. Odporúčame zaviesť tretí uzol, buď tretí NetHSM, alebo „svedka“ etcd, ktorý by mohol byť prevádzkovaný na ľubovoľnom hostiteľovi. Pozrite si nasledujúcu časť „Svedok“.

Svedok

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.

Táto funkcia je však navrhnutá tak, že na dosiahnutie stabilného počtu uzlov nemusíte do svojho klastra pridávať celé skutočné zariadenie NetHSM. Namiesto toho môžete sami nasadiť a pridať „svedecký“ uzol. Takýto uzol je len inštancia etcd bežiaca na vami vybranom počítači (alebo v kontajneri) a pripojená ku klastru. Bude rozpoznaný ako normálny uzol zo skutočných zariadení v klastri a bude prijímať všetky údaje a aktualizácie zo zariadení (ale samozrejme s ním nebudete môcť vykonávať žiadne operácie HSM - iba ukladá údaje).

Security Considerations

Svedecký uzol (alebo ktokoľvek, kto k nemu má prístup) má priamy prístup k úložnému backendu všetkých uzlov v klastri (napr. môžete vypisovať všetky záznamy a zodpovedajúce hodnoty pomocou etcdctl get "/" "0").

S výnimkou verzie konfigurácie (/config/version, ktorá by mala byť vždy „1“) sú však prísne všetky hodnoty zašifrované (buď kľúčom zariadenia pre hodnoty špecifické pre uzol, alebo doménovými kľúčmi pre ostatné hodnoty), čím sa zabezpečí dôvernosť citlivých údajov.

Všimnite si však, že škodlivý uzol môž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.

Čo sa zdieľa medzi uzlami

Zoskupenie NetHSM znamená, že väčšina údajov je medzi nimi zdieľaná. Akékoľvek pridanie, zmena alebo vymazanie kľúčov, používateľov alebo priestorov názvov v jednom uzle sa nakoniec premietne do všetkých ostatných. Vo všeobecnosti platí, že každá operácia, ktorá mení stav, zmení stav každého uzla. Patrí sem aj operácia zálohovania restore, ktorá funguje normálne.

V nasledujúcich častiach je podrobne opísané, ktoré údaje sú plne lokálne, ktoré údaje sú uložené v zdieľanom úložisku etcd, ale zostávajú špecifické pre uzol, a ktoré údaje sú plne zdieľané medzi uzlami.

Nie je uložený v etcd

Kľúč zariadenia **** každého uzla zostáva uložený len lokálne a nikdy sa nezdieľa medzi uzlami.

Uložené v etcd, ale špecifické pre uzol

Nasledujúce údaje sú uložené na etcd v rôznych oblastiach pre každý uzol. Je teda prístupný každému uzlu, ale nie je jednotný pre všetky uzly (každý uzol môže mať inú hodnotu týchto údajov).

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

Všimnite si, že hoci každý uzol má vlastnú verziu uzamknutého doménového kľúča (pretože každý uzol ho uzamkne vlastným kľúčom zariadenia alebo odomykacou frázou), základný doménový kľúč je zdieľaný medzi uzlami (na prístup k ich zdieľaným údajom HSM, ako sú napríklad kľúče).

Uložené v etcd a zdieľané

Všetky nasledujúce údaje sú uložené na etcd v globálnom rozsahu, takže sú jednotné pre všetky uzly klastra:

Údaje HSM:

• Keys

• Používatelia

• Priestory názvov

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

Každý klaster sa na začiatku spustí z jedného uzla. Nové uzly sa budú pripájať do klastra jeden po druhom.

Preparing Nodes

Sieťová prevádzka medzi uzlami je šifrovaná a overovaná pomocou ich certifikátu TLS.

Všetky uzly, ktoré majú byť súčasťou toho istého klastra, musia najprv nainštalovať spoločnú certifikačnú autoritu (CA), ktorá im umožní overiť, či sú ostatné uzly legitímne.

V nasledujúcom texte predpokladáme, že všetky uzly sú čerstvo zabezpečené a funkčné.

Networking

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

Vytvorenie a inštalácia certifikačnej autority

Používatelia by si mali vytvoriť certifikačnú autoritu vlastnými prostriedkami a podľa vlastných prevádzkových obmedzení, pričom by sa mali uistiť, že umožňuje aspoň použitie kľúča keyCertSign.

Minimálnu CA možno vytvoriť napríklad pomocou 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

Táto certifikačná autorita musí byť teraz nainštalovaná v každom uzle.

Na tento účel najprv vygenerujte žiadosť o podpísanie certifikátu (CSR) z uzla, ako je popísané v časti TLS Certificate. V prípade nitropy sa to vykonáva pomocou nitropy nethsm --host $NETHSM_HOST csr --api.

Poznámka

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

V prípade nitropy použite voľbu --san, napr. --san "IP:192.168.1.1".

Ak chcete na podpisovanie certifikátov používať verejnú certifikačnú autoritu, vaše uzly musia používať verejné IP adresy. Dôvodom je bezpečnostná požiadavka, ktorá verejnej certifikačnej autorite zakazuje vydávať certifikáty s privátnou IP adresou v poli IP SAN.

Vzhľadom na získaný CSR (nazvime ho nethsm.csr) preň môžeme vygenerovať certifikát, ktorý je pripravený na inštaláciu. Napríklad pomocou 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

Následne nainštalujte získaný súbor new_cert.pem podľa pokynov uvedených v časti TLS Certificate (s 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

Argumenty

Argument	Popis
FILENAME	The path of the CA file

Príklad

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

Nainštalovanú certifikačnú autoritu klastra je možné zistiť pomocou príkazu ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Poznámka

Tento postup sa musí opakovať pre každý uzol.

Synchronizácia hodín

Uistite sa, že na každom uzle je nastavený správny systémový čas, v ideálnom prípade pomocou protokolu NTP/NTS, a nie ručným nastavením času. To je možné vykonať prostredníctvom konfigurácie Time a 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. Akonáhle dobehne ostatných, povýšte uzol zo statusu „učiaceho sa“ na plnoprávneho člena

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.

Registrácia nového uzla

Majte po ruke IP adresu uzla, ktorý sa pripojí. Úplná adresa ** (v terminológii etcd sa nazýva aj peer URL ) tohto uzla bude https://<IP_of_node>:2380 (napr. https://192.168.1.1:2380). Port musí byť 2380, preto sa uistite, že akýkoľvek firewall medzi uzlami povolí prevádzku TCP na tomto porte.

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

Príklad

$ 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

Voliteľné možnosti

Možnosť	Popis
--url TEXT	URL partnera nového uzla (možno nastaviť viackrát)

Argumenty

Argument	Popis
JOIN_DATA_PATH	Cesta k súboru, do ktorého sa zapisujú údaje zo zlučovania

Príklad

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

Tento príkaz vypíše členov klastra a zapíše do súboru údaje potrebné na pripojenie nového uzla ku klastru (vrátane súboru „joiner kit“). Tento súbor si uchovajte pre ďalší krok.

Poznámka

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.

Hoci tento pojem „učiaci sa uzol“ pridáva ďalší krok (povýšenie), umožňuje bezpečnejšiu prevádzku klastra, keďže akýkoľvek problém s novým uzlom nemôže spôsobiť nestabilitu celého klastra pred jeho povýšením.

Súbor s údajmi o prepojení si uchovajte pre nasledujúci krok (alebo odpoveď, ak ste použili rozhranie REST API).

Joining the Cluster as a Learner

Pripojte sa ku klastru na uzle, ktorý sa má pripojiť, pričom použite údaje z predchádzajúceho kroku a záložnú heslovú frázu uzla, na ktorom bol nový účastník zaregistrovaný.

nitropyREST API

Vyžadované možnosti

Možnosť	Popis
--backup-passphrase TEXT	Záložná heslová fráza uzla, na ktorom bol nový účastník zaregistrovaný

Argumenty

Argument	Popis
JOIN_DATA_PATH	Cesta k súboru s údajmi pre spojenie z predchádzajúceho kroku

Príklad

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

Varovanie

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 tejto fáze sa nový uzol pripojil ako uzol typu „ “ ( ): synchronizuje sa s klastrom, ale zatiaľ nie je v prevádzke. Na druhej strane, akýkoľvek problém s uzlom v tejto fáze nespôsobí žiadne ťažkosti klastru, čím je táto operácia bezpečná.

Posledným krokom na dokončenie pripojenia je povýšenie nového uzla na riadneho člena.

Promoting the New Learner

V závislosti od podmienok siete a klastra môže chvíľu trvať, kým sa nový člen synchronizuje s klastrom. Akonáhle sa tak stane, môže byť povýšený z pozície „učiaceho sa“ na riadneho člena.

Varovanie

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.

Nového člena môžete povýšiť nasledovným spôsobom. ID člena nájdete v zozname členov klastra.

nitropyREST API

Argumenty

Argument	Popis
MEMBER_ID	The ID of the learner to be promoted

Príklad

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

Ak sa študent ešte nedohnal, operácia zlyhá (HTTP kód 412 v rozhraní REST API) a o postup by sa malo neskôr pokúsiť znova.

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

Budete potrebovať prostredie s dostupnou verziou etcd v3.6 s adresou IPv4 (aspoň), ktorá je dostupná pre ostatných členov vášho klastra. Je potrebné povoliť prevádzku TCP na port 2380 a z neho.

Vytvorte prázdny adresár, do ktorého sa budú ukladať dáta etcd, a zapíšte cestu k nemu (my použijeme /var/etcd/data). Uistite sa, že používateľ, ktorý bude proces spúšťať, má oprávnenie na čítanie a zápis do adresára.

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.

Potom je potrebné vytvoriť certifikát pre svedka a podpísať ho certifikačnou autoritou, aby mohol komunikovať so svojimi kolegami. To môžete urobiť napríklad prostredníctvom stránky 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

Výsledné witness.key a witness.pem uložte aj do /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

Na rozdiel od zariadení NetHSM, ktoré si automaticky vyberajú názov uzla (pomocou ID zariadenia), musíte vybrať názov pre každého pridaného svedka, uistite sa, že názvy sú jedinečné. V nasledujúcich príkladoch budeme používať názov „witness1“.

S odpoveďou NetHSM na registráciu svedka pripravte premenné formulára:

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"

Nakoniec vytvorte súbor etcd.conf.yml pomocou vzorového súboru uvedeného v docs/etcd_witness.conf.template:

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

Tým by sa vám mal zobraziť súbor s formulárom:

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

Spustite etcd preferovaným spôsobom (ručne, systemd služba, kontajner atď.) a nasmerujte ho na konfiguračný súbor vytvorený v predchádzajúcom kroku:

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

Mali by ste vidieť, ako sa spustí, pripojiť sa ku klastru ako „učiaci sa“ uzol a dobehnúť zameškané údaje.

Promote the Witness

Nakoniec, po uplynutí určitého času, postupujte podľa bežných pokynov uvedených v časti „ “ (Odosielanie žiadostí o povýšenie) v sekcii „Promoting the New Learner“ (Povýšenie nového študenta), aby ste požiadali o povýšenie svedka. Ak sa to nepodarí, skúste to neskôr.

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

etcdctl get /config/version

Tento kľúč by mal existovať a obsahovať hodnotu „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

Zálohovanie a obnovenie

Operácia zálohovania funguje rovnako ako bez klastra a možno ju vyžiadať z ktoréhokoľvek uzla klastra. Zálohuje údaje pre celý klaster vrátane polí špecifických pre uzol (tie sa však budú ignorovať, ak sa záloha neobnovuje na uzle bez rezervácie).

Zálohu vykonanú v clustri možno obnoviť v tom istom clustri, aj keď boli odvtedy pridané alebo odstránené niektoré uzly. Takéto obnovenie vykonané na funkčných klastroch neovplyvní hodnoty konfigurácie (iba kľúče, používateľov, priestory názvov), ako akékoľvek iné čiastočné obnovenie.

Obnovením zálohy na uzle bez oprávnenia sa obnovia polia špecifické pre uzol (napríklad konfigurácia siete, certifikáty atď.) uzla, ktorý bol použitý na vytvorenie zálohy.

Obnovenie veľkej zálohy môže na určitý čas zahltiť cluster, zatiaľ čo uzol, ktorý obnovu vykonáva, posiela zmeny ostatným.

Táto operácia zostáva kompatibilná so zálohami vykonanými v predchádzajúcich verziách NetHSM.

Poznámka

Obnovenie zálohy vykonanej v uzle A v inom uzle Z s iným doménovým kľúčom správne prepíše doménový kľúč uzla A ako predtým. Ak však bol A v clustri s uzlom B, B sa stane nefunkčným, pretože doménový kľúč Z sa na B neobnoví.

Inými slovami, obnovu vykonajte len v klastri so zálohami vykonanými v tom istom klastri (hoci aj tu mohli byť uzly od tej doby odstránené alebo pridané). Ak chcete obnoviť cudziu zálohu v uzle, najprv ho bezpečne odstráňte z jeho klastra, potom ho obnovte do továrenského nastavenia a obnovte zálohu.

Čisté odstránenie uzla

Pokiaľ niektorá časť klastra stále spĺňa kvorum, možno na odstránenie iného uzla z klastra použiť ktoréhokoľvek z jeho členov, či už je tento uzol nedostupný, alebo sa to očakáva.

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

Argumenty

Argument	Popis
MEMBER_ID	The ID of the node to be removed

Príklad

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

Poznámka

Uzol, ktorý sa pripojil ku klastru, ale ešte nebol povýšený, možno týmto spôsobom tiež bezpečne odstrániť.

Recovering a Failed Node

Uzol, ktorý hlási stav „ Failed“ ( zlyhal), nebude reagovať na väčšinu bežných operácií. Stále je však možné ho vypnúť, reštartovať, vynulovať , diagnostikovať alebo izolovať.

Varovanie

Existencia stavov „ “ (Zlyhanie), „ “ (Zlyhanie), „ ` “ (diagnose`) a „ ` “ (force-new`) sa vzťahuje iba na verziu 5.0 a novšie. Vo verzii 4.0 uzol, ktorý stratil kvorum, prestane reagovať na všetky požiadavky typu „ “ a „ “. Musí byť obnovený do továrenských nastavení („ “ a „ “).

Medzi bežné príčiny, prečo sa uzol nachádza v stave „ “ (Zlyhanie pripojenia), patria:

• Trvalá strata kvóra ` <clustering.html#the-quorum-is-durably-lost>` __.

• Dočasná strata kvorum (napr. pri pridávaní druhého uzla do klastra, keď sa tento druhý uzol ešte nepripojil).

• etcd sa práve reštartuje (napr. kvôli zmene certifikátov alebo prekonfigurácii siete).

• Cluster je vystavený veľmi vysokému zaťaženiu (napr. počas obnovy veľmi rozsiahlej zálohy).

Bez ohľadu na príčinu prejde NetHSM do stavu „ Failed“ ( ) až po uplynutí najmenej jednej plnej minúty neúspešných pokusov o komunikáciu s databázou. Cieľom je zabrániť falošným prechodom spôsobeným veľmi krátkodobými výkyvmi.

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

Príklad

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

Poznámka

Ak a keď bude databáza opäť dostupná (napr. keď sa obnoví kvorum v dôsledku vyriešenia sieťového problému), NetHSM automaticky prejde zo stavu „ Failed“ ( ) do stavu, v ktorom sa nachádzal predtým (alebo obnoví bežnú sekvenciu spúšťania, ak sa práve spúšťal), bez toho, aby bolo potrebné akékoľvek ručné zásah. Stabilizácia klastra, detekcia vyriešenia problému zo strany HSM a zmena stavu potrvá až jednu minútu po vyriešení problému.

Ak dospejete k záveru, že porucha je trvalá (napr. strata kvorum bez nádeje na vyriešenie základnej príčiny), môžete buď:

• Obnovte továrenské nastavenia uzla, čím sa vymažú všetky údaje, a obnovte zálohu.

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

Poznámka

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

Varovanie

Po aktualizácii z verzie < 5.0 bude koncový bod force-new vždy vykazovať stav „Unauthorized“, kým sa HSM neodomkne alebo kým sa heslo na odomknutie aspoň raz nezmení.

Software Updates in Clusters

Budúce aktualizácie budú označené ako „cluster-safe“ (to by mala byť väčšina) alebo „cluster-unsafe“.

Cluster-safe aktualizácie možno použiť na uzly, ktoré sú súčasťou clustra, bez toho, aby ste ich najprv odstránili z clustra. Ako pri všetkých operáciách by ste však mali zabezpečiť, aby sa to robilo vždy na jednom uzle a v klastri, kde odstránením uzla nedôjde k zníženiu kvora (napr. ak aktualizácia zlyhá).

Aktualizácie, ktoré nie sú bezpečné pre cluster, sa musia aplikovať na izolované uzly. Mali by ste rozobrať klaster (odstraňovať uzly jeden po druhom), obnoviť výrobné nastavenia všetkých uzlov okrem jedného, aplikovať aktualizáciu na každý uzol a potom všetky obnovené uzly pripojiť k zostávajúcemu uzlu.

Pred takýmito operáciami nezabudnite zálohovať.

Rekonfigurácia existujúceho klastra

Changing the Cluster CA

Existujúci klaster (s dvoma alebo viacerými uzlami) nemôže zmeniť svoju CA klastra počas prevádzky. Ak potrebujete zmeniť tento certifikát: vyberte uzol, odstráňte všetky ostatné uzly, aktualizujte CA a potom nechajte ostatných členov znovu sa pripojiť.

Changing the Network Configuration of Nodes

Úprava sieťovej konfigurácie uzla (napr. zmena jeho IP) automaticky informuje ostatné uzly o aktualizácii. Mali by ste však zabezpečiť, aby ste takéto aktualizácie vykonávali vždy len v jednom uzle a v klastri, v ktorom by sa stratou tohto uzla nestratilo kvórum.