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.

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

Charakter zhlukovania s etcd je tým spoľahlivejší, čím viac uzlov je v zhluku. Ako je vysvetlené v časti Prevádzková redundancia, klastre by mali mať v ideálnom prípade aspoň 3 uzly, aby mali priestor na zlyhanie, pretože 2-uzlový klaster úplne zlyhá, ak zlyhá len jeden.

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

Všimnite si, že verzia konfigurácie/úložiska domény môže byť zatiaľ len verzia 1 (ak vaša verzia softvéru podporuje zoskupovanie, potom ju máte). Viac informácií o bezpečnosti inštalácie aktualizácií softvéru v rámci klastra nájdete v časti Software Updates in Clusters (Aktualizácie softvéru v klastroch).

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

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.

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

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

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

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

Nakoniec je teraz možné nainštalovať CA (CA.pem) pomocou koncového bodu /config/tls/cluster-ca.pem (pozri dokumentáciu API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). To je možné až po podpísaní nainštalovaného certifikátu TLS. V opačnom prípade bude operácia zamietnutá.

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

Najprv sa uistite, že je v uzle, ktorý sa použije na registráciu nového joineru, nakonfigurovaná záložná prístupová fráza (pozri dokumentáciu API koncového bodu /config/backup-passphrase).

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.

Správnosť adresy URL môžete dvakrát overiť zavolaním adresy GET /cluster/members na uzle, ku ktorému sa má pripojiť. To by malo vypísať len jeden člen: seba samého.

Potom zaregistrujte očakávanú adresu URL v ktoromkoľvek existujúcom uzle klastra (ak ešte nemáte klaster, urobte to v zariadení NetHSM, ktoré bude slúžiť ako počiatočný uzol klastra). Toto sa vykonáva pomocou koncového bodu POST /cluster/members (pozrite si dokumentáciu API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), pričom mu odovzdáte telo JSON obsahujúce adresu URL.

V prípade úspechu sa vráti telo JSON formulá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=="
}

ktorý obsahuje informácie potrebné na pripojenie nového uzla ku klastru. Konkrétne obsahuje zoznam všetkých členov klastra (pričom člen s prázdnym menom je nový člen). Obsahuje aj doménový kľúč zašifrovaný odomykacou aj záložnou prístupovou frázou - záložná prístupová fráza teda musela byť nakonfigurovaná skôr.

Poznámka

Všimnite si v uvedenej odpovedi, že nový člen je „učniak“: teraz sa síce môže pripojiť ku klastru a prijímať z neho údaje, ale nemôže sa aktívne podieľať na činnosti, kým nebude povýšený, čo si rozoberieme nižšie.

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.

Túto odpoveď si nechajte na ďalší krok.

Joining the Cluster as a Learner

Vezmite odpoveď z posledného kroku a pridajte k nej pole backupPassphrase obsahujúce záložnú prístupovú frázu uzla, na ktorom bol zaregistrovaný nový joiner, a odovzdajte tieto údaje volaniu POST /cluster/join (pozrite si dokumentáciu API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) na uzle, ktorý sa má pripojiť.

Varovanie

Volanie funkcie POST /cluster/join zostane zavesené, kým nebude nový uzol ručne povýšený (pozri nižšie). Ide o normálny jav. Ak sa volanie úspešne vráti, znamená to, že pripojenie a povýšenie prebehli úspešne.

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

Povýšením uzla sa zvýši prah kvorum v klastri (pozri dokumentáciu k rozhraniu API „ “ a časť „ Operational Redundancy“ v tomto dokumente). Pred povýšením nového uzla sa uistite, že má stabilné pripojenie ku klastru.

Môžete sa pokúsiť povýšiť nového člena pomocou volania na POST /cluster/members/{MemberID}/promote (pozrite si dokumentáciu k API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Ak sa študent ešte nedostal na požadovanú úroveň, operácia zlyhá s HTTP kódom 412 a povýšenie by sa malo neskôr zopakovať.

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

Zapíšte si odpoveď od klastra: mala by obsahovať zoznam členov klastra a súpravu na pripojenie (túto časť nebudete potrebovať).

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

Za predpokladu, že odpoveď NetHSM je uložená v súbore response.json, môžete tieto dve posledné premenné generovať automaticky pomocou nasledujúcich jq výrazov:

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.

Najskôr musíte poznať ID uzla, ktorý chcete odstrániť, a to tak, že vypíšete všetky uzly cez GET /cluster/members a vyhľadáte ten správny.

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.

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.

Aby ste mohli zistiť, v akom stave sa váš uzol nachádza, je naďalej k dispozícii koncový bod GET /health/diagnose, ktorý poskytuje informácie o aktuálnom stave etcd a jeho databázy, vrátane protokolov (pozrite si dokumentáciu k API).

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.

  • Izolujte uzol s koncovým bodom POST /cluster/force-new, ktorý nezvratne zabudne na všetkých ostatných členov klastra, obnoví etcd údaje nachádzajúce sa na disku a reštartuje sa. Ak bola príčinou zlyhania porucha súvisiaca s klastrom, uzol bude postupovať podľa bežného postupu spúšťania a v závislosti od nastavenia automatického spúšťania sa dostane buď do stavu Locked, alebo Operational.

Poznámka

Ak je uzol izolovaný pomocou príkazu „ ` “ force-new`, dôjde k jeho desynchronizácii s klastrom: akékoľvek nové zápisy na ňom alebo v klastri nebude možné zosúladiť. Uzol sa môže naďalej pripojiť ku klastru, avšak stratí všetky svoje lokálne úpravy.

Koncový bod POST /cluster/force-new, ktorý je k dispozícii iba v stave „ Failed“ ( zlyhal), vyžaduje overenie, pretože môže spôsobiť poškodenie. Keďže však v tomto stave nie sú k dispozícii používatelia ani role HSM, koncový bod očakáva, že klienti HTTPS sa budú vždy overovať pomocou fiktívneho používateľa unlock a ako heslo uvedú najnovšiu známu odomykaciu frázu.

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.