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.

  • Ještě nebylo ověřeno v dostatečném počtu produkčních nasazení a mohou se v něm vyskytovat chyby.

NetHSM od verze 4.0 podporuje clustering pro přímou synchronizaci dat mezi několika NetHSM. To podporuje vysokou frekvenci generování klíčů, realizuje vysokou dostupnost a vyrovnávání zátěže. Cluster NetHSM je založen na etcd, který používá konsensuální algoritmus Raft pro silnou konzistenci. Tím je zajištěno, že data (např. klíče) jsou ve všech NetHSM vždy správná.

Před nastavením clusteru NetHSM se seznamte s touto technologií a jejími omezeními, abyste předešli náhodnému výpadku a ztrátě dat. Kromě tohoto dokumentu se můžete podívat také do dokumentace etcd.

Operational Redundancy

„Uzlem“ budeme nazývat NetHSM, který má být součástí clusteru. Klastr N uzlů bude fungovat tak dlouho, dokud budou alespoň (N/2)+1 uzly zdravé a dosažitelné. Toto minimální množství zdravých a dosažitelných uzlů se nazývá kvorum.

V clusteru, který klesne pod tuto prahovou hodnotu (např. kvůli síťovému problému), nelze zvolit žádného vůdce a místní instance etcd na každém uzlu přestane být schopna provádět čtení a zápis. Z toho vyplývají následující scénáře.

Výpadek jednoho uzlu a dosažení kvora

Pokud v clusteru se třemi uzly dojde k selhání jednoho uzlu (havárii nebo nedostupnosti v důsledku síťových podmínek), ostatní dva uzly budou nadále pracovat a obsluhovat požadavky.

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.

Pokud se zařízení nikdy neobnoví, je nutné jej odstranit z klastru a buď provést obnovu, aby bylo možné přistupovat k jeho datům (zařízení však již nebude součástí klastru), nebo provést obnovení továrního nastavení a znovu projít procesem připojení od začátku.

Dojde k rozdělení sítě a kvorum je stále dosaženo

Jedná se pouze o zobecnění předchozího scénáře. V clusteru s 5 uzly, kde jsou např. 3 uzly v jednom fyzickém umístění A a 2 uzly v jiném umístění B, by síťový problém izolující A a B znamenal následující:

  • Tři uzly v lokalitě A splňují kvorum (v tomto případě 3), takže pokračují v provozu.

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

  • Pokud je problém se sítí vyřešen, 2 uzly se čistě připojí zpět k ostatním 3 uzlům.

Jinými slovy, v nejhorším případě dojde k rozdělení sítě (v clusteru s lichým počtem uzlů) tak, že větší polovina clusteru zůstane funkční, zatímco menší polovina bude nefunkční, dokud nebude rozdělení odstraněno.

Kvorum je trvale ztraceno

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.

K tomu může dojít například při selhání jednoho uzlu v clusteru se dvěma uzly (kde je kvorum 2). V této situaci nelze selhávající uzel z clusteru dodatečně čistě odstranit, protože zbývající zdravý uzel je již nefunkční, protože ztratil kvorum.

Proto se doporučuje mít v clusteru vždy lichý počet uzlů a často zálohovat.

Aby bylo jasno, dočasně ztráta kvora (například pokud restartujete všechny uzly clusteru společně nebo pokud dojde k dočasnému selhání sítě, které uzly izoluje) není problém: jakmile se znovu připojí dostatečný počet uzlů (aniž by se musely ručně znovu připojovat), aby bylo dosaženo kvora, cluster bude pokračovat v normálním provozu. Pouze trvalé poruchy, jako je rozdělení sítě, chybná konfigurace sítě, problémy s ověřováním nebo selhání hardwaru, budou vyžadovat ruční zásah.

Další informace naleznete na adrese etcd v sekci ČASTO KLADENÉ DOTAZY.

Cluster se 2 uzly

Aktivní/pasivní cluster se dvěma uzly zatím není podporován a bude přidán v některé z budoucích verzí. Doporučujeme zavést třetí uzel, buď třetí NetHSM, nebo „svědka“ etcd, který by mohl být provozován na libovolném hostiteli. Viz další část „Svědek“.

Svědek

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.

Funkce je však navržena tak, že k dosažení stabilního počtu uzlů není nutné přidávat do clusteru plné, skutečné zařízení NetHSM. Místo toho můžete sami nasadit a přidat „svědecký“ uzel. Takovým uzlem je pouze instance etcd běžící na vámi zvoleném počítači (nebo v kontejneru) a připojená ke clusteru. Bude rozpoznán jako normální uzel od skutečných zařízení v clusteru a bude přijímat všechna data a aktualizace ze zařízení (ale samozřejmě s ním nebudete moci provádět žádné operace HSM - pouze ukládá data).

Security Considerations

Svědecký uzel (nebo kdokoli s přístupem k němu) má přímý přístup k úložišti všech uzlů v clusteru (např. můžete vypsat všechny záznamy a odpovídající hodnoty pomocí etcdctl get "/" "0").

S výjimkou verze konfigurace (/config/version, která by měla být vždy „1“) jsou však striktně všechny hodnoty šifrovány (buď klíčem zařízení pro hodnoty specifické pro uzel, nebo klíči domény pro ostatní hodnoty), což zajišťuje důvěrnost citlivých dat.

Všimněte si však, že škodlivý uzel 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.

Co je sdíleno mezi uzly

Existence shluku NetHSM znamená, že většina dat je mezi nimi sdílena. Jakékoli přidání, změna nebo odstranění klíčů, uživatelů nebo jmenných prostorů v jednom uzlu se nakonec projeví ve všech ostatních. Obecně platí, že každá operace, která mění stav, změní stav každého uzlu. To se týká i operace zálohování obnovení, která funguje normálně.

V následujících částech je podrobně popsáno, která data jsou plně lokální, která data jsou uložena ve sdíleném úložišti etcd, ale zůstávají specifická pro uzel, a která data jsou plně sdílená mezi uzly.

Není uloženo v etcd

Klíč zařízení **** každého uzlu zůstává uložen pouze lokálně a není nikdy sdílen mezi uzly.

Uloženo v etcd, ale specifické pro uzel

Následující data jsou uložena na etcd v různých oborech pro každý uzel. Jsou tedy přístupná každému uzlu, ale nejsou jednotná napříč uzly (každý uzel může mít pro tato data jinou hodnotu).

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šimněte si, že zatímco každý uzel má svou vlastní verzi uzamčeného klíče domény (protože každý uzel jej uzamyká svým vlastním klíčem zařízení nebo odemykací frází), základní klíč domény je sdílený mezi uzly (pro přístup k jejich sdíleným datům HSM, jako jsou klíče).

Uloženo v etcd a sdíleno

Všechna následující data jsou uložena na adrese etcd v globálním rozsahu, takže jsou jednotná pro všechny uzly clusteru:

Údaje HSM:

  • Keys

  • Uživatelé

  • Prostory názvů

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ý cluster bude zpočátku spuštěn z jediného uzlu. Nové uzly se ke clusteru připojují jeden po druhém.

Preparing Nodes

Síťový provoz mezi uzly je šifrován a ověřován pomocí jejich certifikátu TLS.

Všechny uzly, které mají být součástí stejného clusteru, musí nejprve nainstalovat společnou certifikační autoritu, která jim umožní ověřit, zda jsou ostatní uzly legitimní.

V následujícím textu předpokládáme, že všechny uzly jsou čerstvě zajištěny a funkční.

Networking

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

Vytvoření a instalace certifikační autority

Uživatelé by si měli vytvořit certifikační autoritu vlastními prostředky a podle vlastních provozních omezení a ujistit se, že umožňuje alespoň použití klíče keyCertSign.

Minimální certifikační autoritu lze například vytvořit pomocí adresy 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

Tato certifikační autorita musí být nyní nainstalována v každém uzlu.

K tomu nejprve vygenerujte žádost o podepsání certifikátu (CSR) z uzlu, jak je popsáno v části TLS Certificate. S nitropy se to provádí pomocí 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 případě nitropy použijte volbu --san, např. --san "IP:192.168.1.1".

Pokud chcete k podepisování certifikátů použít veřejnou certifikační autoritu, musí vaše uzly používat veřejné IP adresy. Důvodem je bezpečnostní požadavek, který veřejné certifikační autoritě zakazuje vydávat certifikáty s privátní IP adresou v poli IP SAN.

Vzhledem k získanému CSR (nazvěme jej nethsm.csr) pro něj můžeme vygenerovat certifikát, který je připraven k instalaci. Například pomocí 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

Poté nainstalujte získaný soubor new_cert.pem podle pokynů v části 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.

Argumenty

Argument

Popis

FILENAME

The path of the CA file

Příklad

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

Nainstalovanou clusterovou certifikační autoritu lze zjistit pomocí příkazu ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Poznámka

Tento postup je třeba opakovat pro každý uzel.

Synchronizace hodin

Ujistěte se, že každý uzel má nastaven správný systémový čas, ideálně pomocí protokolu NTP/NTS, nikoli ručním nastavením času. To lze provést pomocí konfigurace 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. Jakmile se učící uzel dostane do tempa, povýšte ho z pozice učícího se uzlu na plnohodnotného č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.

Registrace nového uzlu

Mějte po ruce IP adresu uzlu, který se připojí. Úplné URL (v terminologii etcd se také nazývá peer URL ) tohoto uzlu bude https://<IP_of_node>:2380 (např. https://192.168.1.1:2380). Port musí být 2380, takže se ujistěte, že případný firewall mezi uzly povolí provoz TCP na tomto portu.

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.

Pří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).

Volitelné možnosti

Možnost

Popis

--url TEXT

URL peeru nového uzlu (lze nastavit vícekrát)

Argumenty

Argument

Popis

JOIN_DATA_PATH

Cesta k souboru, do kterého se zapisují data ze spojení

Příklad

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

Tento příkaz vypíše členy clusteru a zapíše do souboru údaje potřebné pro připojení nového uzlu k clusteru (včetně instalační sady). Tento soubor si uschovejte pro další 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.

Ačkoli tento pojem „learner“ přidává další krok (povýšení), umožňuje bezpečnější provoz clusteru, protože jakýkoli problém s novým uzlem nemůže před jeho povýšením způsobit nestabilitu celého clusteru.

Uložte si soubor s daty pro propojení pro další krok (nebo odpověď, pokud jste použili rozhraní REST API).

Joining the Cluster as a Learner

Připojte se ke klastru na uzlu, který se má připojit, a to s využitím údajů z předchozího kroku a záložní přístupové fráze uzlu, na kterém byl nový účastník zaregistrován.

Požadované možnosti

Možnost

Popis

--backup-passphrase TEXT

Záložní heslo uzlu, na kterém byl nový účastník zaregistrován

Argumenty

Argument

Popis

JOIN_DATA_PATH

Cesta k datovému souboru pro spojení z předchozího kroku

Příklad

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

Varování

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 této fázi se nový uzel připojil jako uzel typu „ “ ( ): provádí synchronizaci s clusterem, ale zatím není v provozuschopném stavu. Na druhou stranu jakýkoli problém s tímto uzlem v této fázi nezpůsobí žádné potíže clusteru, takže se jedná o bezpečnou operaci.

Posledním krokem k dokončení připojení je povýšení nového uzlu na plnoprávného člena.

Promoting the New Learner

V závislosti na stavu sítě a clusteru může chvíli trvat, než se nový člen synchronizuje s clusterem. Jakmile k tomu dojde, může být povýšen z pozice „učeícího se člena“ na plnoprávného člena.

Varování

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.

Můžete se pokusit povýšit nového člena následujícím způsobem. ID člena zjistíte pomocí výpisu členů clusteru.

Argumenty

Argument

Popis

MEMBER_ID

The ID of the learner to be promoted

Příklad

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

Pokud se žák ještě nedostal na požadovanou úroveň, dojde k selhání (HTTP kód 412 v REST API) a o postup by se mělo zkusit znovu později.

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 potřebovat prostředí s dostupnou verzí etcd v3.6 s adresou IPv4 (alespoň) dosažitelnou pro ostatní členy clusteru. Je třeba povolit provoz TCP na port 2380 a z něj.

Vytvořte prázdný adresář, do kterého se budou ukládat data etcd, a zapište k němu cestu (my použijeme /var/etcd/data). Zajistěte, aby uživatel, který bude proces spouštět, měl oprávnění ke čtení a zápisu do adresáře.

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.

Poté je třeba vytvořit certifikát pro svědka a podepsat jej certifikační autoritou, aby mohl komunikovat se svými protějšky. To lze provést například pomocí 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 také 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 rozdíl od zařízení NetHSM, která si automaticky vybírají název uzlu (pomocí ID zařízení), je nutné zvolit název pro každého přidaného svědka, a ujistit se, že názvy jsou jedinečné. V následujících příkladech budeme používat „witness1“.

S odpovědí NetHSM na registraci svědka připravte proměnné formuláře:

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"

Nakonec vytvořte soubor etcd.conf.yml pomocí šablony souboru uvedené 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 se vám zobrazí soubor formuláře:

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

Spusťte etcd preferovaným způsobem (ručně, systemd služba, kontejner atd.) a nasměrujte jej na konfigurační soubor vytvořený v předchozím kroku:

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

Měli byste vidět, jak se spustí, připojí se ke clusteru jako „learner“ a dožene zpoždění v datech.

Promote the Witness

Nakonec, po uplynutí určité doby, postupujte podle běžných pokynů uvedených v části „ “ (Povýšení nového žáka), abyste svědka povýšili. Pokud se to nepodaří, zkuste to znovu později.

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

etcdctl get /config/version

Tento klíč by měl existovat a obsahovat 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álohování a obnovení

Operace zálohování funguje stejně jako bez clusteru a lze o ni požádat z kteréhokoli uzlu clusteru. Zálohuje data celého clusteru, včetně polí specifických pro uzel (ta však budou ignorována, pokud se záloha neobnovuje na nezálohovaném uzlu).

Zálohu provedenou na clusteru lze obnovit na stejném clusteru, i když byly některé uzly od té doby přidány nebo odebrány. Takové obnovení provedené na provozních clusterech neovlivní hodnoty konfigurace (pouze klíče, uživatele, jmenné prostory), stejně jako jakékoli jiné částečné obnovení.

Obnovení zálohy na neschváleném uzlu obnoví pole specifická pro uzel (jako je konfigurace sítě, certifikáty atd.) uzlu, který byl použit k vytvoření zálohy.

Obnovení rozsáhlé zálohy může na nějakou dobu zahltit cluster, zatímco uzel, který obnovu provádí, předává změny ostatním.

Tato operace zůstává kompatibilní se zálohami provedenými v předchozích verzích NetHSM.

Poznámka

Obnovení zálohy provedené v uzlu A v jiném uzlu Z s jiným klíčem domény správně přepíše klíč domény A jako dříve. Pokud však byl A v clusteru s uzlem B, stane se B nefunkčním, protože doménový klíč Z nebude na B obnoven.

Jinými slovy, obnovu provádějte pouze v clusteru se zálohami provedenými ve stejném clusteru (i když uzly mohly být od té doby odebrány nebo přidány). Pokud chcete obnovit cizí zálohu v uzlu, nejprve jej bezpečně odeberte z jeho clusteru, poté jej obnovte do továrního nastavení a obnovte zálohu.

Čisté odstranění uzlu

Dokud některá část clusteru stále splňuje kvorum, může být kterýkoli z jeho členů použit k odstranění jiného uzlu z clusteru, ať už je tento uzel již nedostupný, nebo se očekává, že bude.

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.

Argumenty

Argument

Popis

MEMBER_ID

The ID of the node to be removed

Příklad

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

Poznámka

Uzel, který se připojil ke clusteru, ale dosud nebyl povýšen, lze tímto způsobem také bezpečně odstranit.

Recovering a Failed Node

Uzel, který hlásí stav „ Failed“ (Selhání aktualizace), nebude reagovat na většinu běžných operací. I tak jej lze vypnout, restartovat, resetovat , diagnostikovat nebo izolovat.

Varování

Existence stavů „ “ („Selhalo“), operací diagnose a force-new se vztahuje pouze na verzi 5.0 a novější. Ve verzi 4.0 přestane uzel, který ztratil kvorum, reagovat na všechny požadavky ** . Je nutné provést obnovení továrního nastavení.

Mezi běžné příčiny, proč se uzel nachází ve stavu „ “ (Selhání), patří:

  • Trvale ztracené kvorum.

  • Dočasná ztráta kvora (např. při přidávání druhého uzlu do clusteru, kdy se tento druhý uzel ještě nepřipojil).

  • etcd se právě restartuje (např. kvůli změně certifikátů nebo nové konfiguraci sítě).

  • Cluster je vystaven velmi vysokému zatížení (např. při obnově velmi rozsáhlé zálohy).

Bez ohledu na příčinu přejde NetHSM do stavu „ Failed“ (Selhání služby ) až po uplynutí nejméně jedné celé minuty neúspěšných pokusů o komunikaci s databází. Tím se má zabránit falešným přechodům způsobeným velmi krátkodobými výkyvy.

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.

Příklad

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

Poznámka

Jakmile bude databáze opět dostupná (např. dojde k obnovení kvora v důsledku vyřešení síťového problému), NetHSM automaticky přejde ze stavu „ Failed“ ( ) do stavu, ve kterém se nacházel předtím (nebo v případě, že se právě spouštěl, obnoví normální spouštěcí sekvenci), aniž by byl nutný jakýkoli ruční zásah. Stabilizace clusteru, detekce vyřešení problému ze strany HSM a změna stavu trvají až jednu minutu po vyřešení problému.

Pokud dojdete k závěru, že selhání je trvalé (např. ztráta kvorum bez naděje na vyřešení příčiny), můžete buď:

  • Obnovte tovární nastavení uzlu, čímž dojde k vymazání všech dat, 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

Varování

Po aktualizaci z verze < 5.0 bude koncový bod force-new vždy vykazovat stav „Unauthorized“, dokud nebude HSM odemčen nebo dokud nebude alespoň jednou změněna odemykací fráze.

Software Updates in Clusters

Budoucí aktualizace budou označeny jako „cluster-safe“ (to by měla být většina) nebo „cluster-unsafe“.

Na uzly, které jsou součástí clusteru, lze aplikovat aktualizace bezpečné pro cluster, aniž by byly z clusteru nejprve odstraněny. Stejně jako u všech operací byste však měli zajistit, aby se tak dělo vždy na jednom uzlu a v clusteru, kde odebráním uzlu nedojde k poklesu kvora (např. pokud se aktualizace nezdaří).

Aktualizace, které nejsou bezpečné pro cluster, musí být aplikovány na izolované uzly. Měli byste cluster rozložit (odebírat uzly jeden po druhém), obnovit tovární nastavení všech uzlů kromě jednoho, aplikovat aktualizaci na každý uzel a poté všechny obnovené uzly připojit ke zbývajícímu uzlu.

Před těmito operacemi nezapomeňte zálohovat.

Rekonfigurace stávajícího clusteru

Changing the Cluster CA

Existující cluster (se dvěma nebo více uzly) nemůže změnit svou certifikační autoritu clusteru za provozu. Pokud potřebujete tento certifikát změnit: vyberte uzel, odstraňte všechny ostatní uzly, aktualizujte certifikační autoritu a poté nechte ostatní členy znovu připojit.

Changing the Network Configuration of Nodes

Změna síťové konfigurace uzlu (např. změna jeho IP) automaticky informuje ostatní uzly o aktualizaci. Měli byste však zajistit, abyste takové aktualizace prováděli vždy pouze v jediném uzlu a v clusteru, jehož ztráta nezpůsobí ztrátu kvora.