Clustering¶
Poznámka
Táto funkcia je v súčasnosti technickým náhľadom s nasledujúcimi dočasnými obmedzeniami:
Ak dôjde k strate klastra (stratí sa kvorum), jediným spôsobom obnovy je továrenské obnovenie + obnovenie. Nezabudnite často zálohovať. Budúce verzie budú obsahovať prostriedky na obnovu údajov na disku.
Aktívne/pasívne nastavenie na podporu clustrov s dvoma uzlami, buď pomocou etcd Learner alebo Mirror, zatiaľ nie je k dispozícii.
Systémový čas medzi uzlami sa musí zatiaľ synchronizovať ručne. Budúca verzia bude obsahovať automatickú synchronizáciu hodín.
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.
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.
Ak je zlyhaný uzol stále zdravý (napr. išlo len o problém so sieťou), bude počas izolácie nefunkčný (dokonca ani len na čítanie).
Ak sa však uzol zotaví, čisto sa resynchronizuje so zvyškom klastra a stane sa opäť funkčným bez straty údajov.
Ak sa neobnoví, je potrebné ho odstrániť z klastra (pozri nasledujúcu časť), obnoviť 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.
Dva uzly v lokalite B sú nie spĺňať kvórum (stále 3), takže prestanú pracovať (aj len na čítanie).
Ak je problém so sieťou vyriešený, 2 uzly sa čisto spoja s ostatnými 3 uzlami.
Kvórum je trvalo stratené¶
Zlyhanie, ktoré spôsobí stratu kvóra všetkých podmnožín klastra, spôsobí úplnú stratu klastra a jeho údajov, pokiaľ sa zlyhanie nevyrieši. V takom prípade sa musia uzly obnoviť z výroby a musí sa obnoviť záloha.
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:
zapísať odpad ako hodnotu pre ľubovoľnú položku v úložisku, čo spôsobí, že uzly zlyhajú pri jej dešifrovaní (čo môže viesť k pádu niektorých systémových položiek).
názvy položiek zoznamu, ako sú používatelia, priestory názvov a kľúče, ktoré môžete považovať za citlivé.
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
Na správne overenie uzlov backend klastra (etcd) očakáva, že každý uzol má certifikát so správne vyplneným poľom Subject Alt Names (SAN). Najmä uzly, od ktorých sa očakáva, že budú prístupné len prostredníctvom svojej IP, musia mať vo svojom certifikáte správne vyplnenú IP SAN. IP SAN je možné vyžiadať pre CSR tak, že sa k menám pridá prefix „IP:“, ako je to v openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
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 každý uzol bol vybavený presným systémovým časom. Ak nie, nastavte ich hodiny pomocou koncového bodu /config/time.
Adding a New Node¶
Pridanie uzla do klastra sa vykonáva v dvoch krokoch:
zaregistrovať prírastok do klastra (prostredníctvom niektorého z jeho členov).
oznámiť novému uzlu, aby sa pripojil
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¶
Varovanie
Registráciou uzla sa do klastra okamžite zavedie nový uzol, čím sa zmení prahová hodnota kvora, aj keď sa uzol v skutočnosti ešte nepripojil. To môže spôsobiť nefunkčnosť existujúcich uzlov, kým sa nový uzol skutočne nepripojí. Pozrite si dokumentáciu API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __ a časť Prevádzková redundancia tohto dokumentu.
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"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"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.
Túto odpoveď si nechajte na ďalší krok.
Skutočné pripojenie ku klastru¶
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ť.
Za predpokladu, že sa klaster aj uzol môžu navzájom spojiť, sa vykoná skutočné pripojenie, pričom sa vymažú údaje nového pripojeného uzla, aby sa namiesto toho synchronizoval jeho stav so stavom klastra.
V závislosti od podmienok siete a klastra môže táto operácia trvať niekoľko desiatok sekúnd. Ak táto operácia zlyhá okamžite (napr. cluster nebol dosiahnuteľný alebo zlyhalo overovanie), stav tohto uzla sa nevymaže a pripojenie sa vráti späť. Avšak hneď ako je prvé pripojenie úspešné, táto operácia je konečná a môže byť vrátená späť iba obnovením továrenského nastavenia.
Ak je toto pripojenie úspešné, uzol sa dostane do stavu Locked a musí byť odomknutý pomocou odomykacej frázy uzla, ktorý bol použitý na registráciu. Potom je možné odomykaciu prístupovú frázu zmeniť (odomykacie prístupové frázy zostávajú špecifické pre uzol a nie sú zdieľané medzi uzlami).
Poznámka
Aj po úspešnom pripojení, ak je databáza clustera veľká alebo ak je cluster zaneprázdnený, môže trvať určitý čas, kým nový pripojený subjekt úplne zosynchronizuje svoj stav. Počas tohto času môžu všetky uzly (vrátane najmä nového pripojeného uzla) reagovať menej alebo nereagovať. Najmä nový spojovateľ môže spočiatku vracať chyby napríklad pri pokuse o odomknutie. V takom prípade mu dajte nejaký čas a skúste to znova.
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.
Preneste do počítača certifikát certifikačnej autority, ktorý sa používa na overovanie uzlov v klastri. Mali ste si ho vytvoriť v časti Vytvorenie a inštalácia certifikačnej autority. Uložíme ho do adresára /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¶
Postupujte podľa bežných pokynov z časti Registrácia nového uzla, aby ste signalizovali existujúcemu klastru pridanie nového člena s danou(-ými) adresou(-ami) URL.
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)
Napríklad s príkladom odpovede uvedeným v časti Registrácia nového uzla budete mať:
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ť, že sa spustí, pripojí sa ku klastru a dobehne dáta. Po nejakom čase by ste mali byť schopní skontrolovať, či je zdravý pomocou klienta etcdctl:
etcdctl get /config/version
Tento kľúč by mal existovať a obsahovať hodnotu „1“.
Uistite sa, že tento proces beží ďalej, pretože je teraz riadnym členom vášho klastra. Ak ho potrebujete vyradiť z prevádzky, najprv ho riadne odstráňte z klastra (pozri časť venovanú tomuto procesu). Ak sa zmení jeho dosiahnuteľná IP adresa, aktualizujte jeho adresu URL z klastra.
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.
Potom ho možno odstrániť volaním DELETE /cluster/members/<id>. Ak bol príslušný uzol ešte zdravý, izoluje sa tým od zvyšku klastra a znefunkční sa.
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.