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 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 <clustering.html#recovering-a-failed-node> 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¶
Povaha shlukování pomocí etcd je tím spolehlivější, čím více uzlů je ve shluku. Jak je vysvětleno v části Provozní redundance, clustery by měly mít v ideálním případě alespoň 3 uzly, aby měly prostor pro selhání, protože cluster se 2 uzly zcela selže, pokud selže pouze jeden.
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.
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 using the /config/network endpoint (refer to the API documentation).
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.
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" ]
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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
Nakonec lze nyní nainstalovat certifikační autoritu (CA.pem) pomocí koncového bodu /config/tls/cluster-ca.pem (viz dokumentace API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). To je možné až po podepsání nainstalovaného certifikátu TLS. V opačném případě bude operace odmítnuta.
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:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
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¶
Nejprve se ujistěte, že je v uzlu, který bude použit k registraci nového joineru, nakonfigurována záložní přístupová fráze (viz dokumentace API koncového bodu /config/backup-passphrase).
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.
Správnost adresy URL můžete překontrolovat zavoláním adresy GET /cluster/members na uzlu, který se má připojit. To by mělo vypsat pouze jeden člen: sebe sama.
Poté zaregistrujte očekávanou adresu URL v libovolném existujícím uzlu clusteru (pokud ještě nemáte cluster, proveďte to v zařízení NetHSM, které bude sloužit jako počáteční uzel clusteru). To se provádí pomocí koncového bodu POST /cluster/members (viz dokumentace API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), kterému předáte tělo JSON obsahující adresu URL.
V případě úspěchu se vrátí tělo JSON formuláře:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
který obsahuje informace nezbytné pro připojení nového uzlu ke clusteru. Zejména obsahuje seznam všech členů clusteru (kde člen s prázdným jménem je nový člen). Obsahuje také doménový klíč zašifrovaný odemykací i záložní přístupovou frází - záložní přístupová fráze tedy musela být nakonfigurována dříve.
Poznámka
Všimněte si ve výše uvedené odpovědi, že nově připojený uzel je „učící se uzel“: nyní se může připojit ke klastru a přijímat z něj data, ale nemůže se účastnit, dokud nebude povýšen, což bude popsáno níže.
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.
Tuto odpověď si ponechte pro další krok.
Joining the Cluster as a Learner¶
Vezměte odpověď z posledního kroku a připojte k ní pole backupPassphrase obsahující záložní přístupovou frázi uzlu, na kterém byl nový spojovatel zaregistrován, a předejte tato data volání POST /cluster/join (viz dokumentace rozhraní API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) na uzlu, který se má připojit.
Varování
Volání funkce POST /cluster/join bude čekat, dokud nebude nový uzel ručně povýšen (viz níže). To je normální. Úspěšný návrat volání znamená, že připojení i povýšení proběhly úspěšně.
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í
Povýšením uzlu se zvýší prahová hodnota kvorum clusteru (viz dokumentace k API „ “ a část „ : Operational Redundancy“ v tomto dokumentu). Před povýšením se ujistěte, že má tento nový uzel stabilní připojení k clusteru.
Můžete se pokusit povýšit nového člena voláním funkce ` `` na adrese POST /cluster/members/{MemberID}/promote` (viz dokumentace k API služby ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Pokud účastník kurzu ještě nedohnal zpoždění, operace selže s HTTP kódem 412 a o povýšení 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).
Zapište si odpověď od clusteru: měla by obsahovat seznam členů clusteru a sadu pro připojení (tuto část nebudete potřebovat).
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,..."
Za předpokladu, že je odpověď NetHSM uložena v souboru response.json, můžete tyto dvě poslední proměnné generovat automaticky pomocí následujících výrazů jq:
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.
Nejprve musíte znát ID uzlu, který chcete odstranit, a to tak, že si vylistujete všechny uzly přes GET /cluster/members a vyhledáte ten správný.
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
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).
etcdse 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.
Abychom vám usnadnili orientaci v tom, v jakém stavu se váš uzel nachází, zůstává k dispozici koncový bod GET /health/diagnose, který vrací informace o aktuálním stavu etcd a jeho databáze, včetně protokolů (viz dokumentace k API).
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.
U izolovaného uzlu s koncovým bodem
POST /cluster/force-newdojde k nevratnému odstranění všech ostatních členů clusteru, obnovení datetcduložených na disku a restartu systému. Pokud byla příčinou selhání porucha související s clusterem, uzel projde běžnou spouštěcí sekvencí a v závislosti na nastavení automatického spouštění se dostane buď do stavu Locked, nebo Operational.
Poznámka
Pokud je uzel izolován příkazem „ ` “ force-new`, dojde k jeho desynchronizaci s clusterem: jakékoli nové zápisy na tomto uzlu nebo v clusteru již nebude možné sladit. Uzel se může do clusteru znovu připojit, ztratí však všechny své lokální změny.
Koncový bod POST /cluster/force-new, který je k dispozici pouze ve stavu „ Failed“ ( selhal), vyžaduje ověření, protože může způsobit ztrátu dat. Jelikož však v tomto stavu nejsou k dispozici uživatelé ani role HSM, koncový bod očekává, že se klienti HTTPS budou vždy ověřovat pomocí fiktivního uživatele unlock a jako heslo zadají poslední známou odemykací frázi.
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.