Clustering¶
Opomba
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 različice 4.0 naprej podpira grozdenje za neposredno sinhronizacijo podatkov med več NetHSM. To omogoča visoko pogostost generiranja ključev, visoko razpoložljivost in izravnavo obremenitve. Grozd NetHSM temelji na etcd, ki uporablja algoritem soglasja Raft za močno skladnost. To zagotavlja, da so podatki (npr. ključi) v vseh enotah NetHSM vedno pravilni.
Pred vzpostavitvijo gruče NetHSM se seznanite s to tehnologijo in njenimi omejitvami, da se izognete naključnemu izpadu in izgubi podatkov. Poleg tega dokumenta si lahko ogledate tudi dokumentacijo etcd.
Operational Redundancy¶
Vozlišče bomo imenovali NetHSM, za katerega se pričakuje, da bo del gruče. Grozd vozlišč N bo deloval, dokler bodo vsaj (N/2)+1 vozlišča zdrava in dosegljiva. To minimalno število zdravih in dosegljivih vozlišč se imenuje kvorum.
V grozdu, ki pade pod to mejno vrednost (npr. zaradi težav z omrežjem), ni mogoče izvoliti vodje, zato lokalna instanca etcd na vsakem vozlišču ne more več izvajati branja in pisanja. To pomeni naslednje scenarije.
Eno vozlišče je v okvari, kvorum pa je še vedno dosežen¶
Če v gruči s tremi vozlišči eno vozlišče odpove (odpove ali postane nedosegljivo zaradi omrežnih razmer), ostali dve vozlišči nadaljujeta z delom in servisirata zahteve.
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.
Če se naprava nikoli ne bo obnovila, jo je treba odstraniti iz gruče in jo bodisi podvreči obnovitvi, da bo mogoče dostopati do njenih podatkov (vendar ne bo več del gruče), bodisi ponastaviti na tovarniške nastavitve in ponovno izvesti postopek priključitve od začetka.
Zgodi se delitev omrežja in kvorum je še vedno dosežen¶
To je le posplošitev prejšnjega scenarija. V gruči s petimi vozlišči, kjer so npr. 3 vozlišča na fizični lokaciji A in 2 vozlišči na drugi lokaciji B, bi omrežni problem, ki bi izoliral vozlišči A in B, pomenil naslednje:
Tri vozlišča na lokaciji A izpolnjujejo kvorum (v tem primeru 3), zato še naprej delujejo.
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).
Če je težava z omrežjem odpravljena, se bosta dve vozlišči brez težav pridružili ostalim trem vozliščem.
Z drugimi besedami, v najslabšem primeru razdelitve omrežja (v gruči s liho številom vozlišč) bo večja polovica gruče delovala normalno, manjša polovica pa ne bo delovala, dokler se razdelitev ne odpravi.
Kvorum je trajno izgubljen¶
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 se lahko zgodi na primer, če v gruči z dvema vozliščema (kjer je kvorum 2) odpove eno vozlišče. V tem primeru odpovedanega vozlišča ni mogoče naknadno odstraniti iz gruče, saj preostalo zdravo vozlišče že ne deluje, ker je izgubilo kvorum.
Zato je priporočljivo, da je v gruči vedno liho število vozlišč in da pogosto izdelujete varnostne kopije.
Da bi bilo jasno, začasno izgubi kvorum (na primer, če ponovno zaženete vsa vozlišča v gruči skupaj ali če so vozlišča izolirana zaradi začasne okvare omrežja), ni težava: ko se ponovno poveže dovolj vozlišč (brez ročnega ponovnega povezovanja), da se doseže kvorum, bo gruča nadaljevala z običajnim delovanjem. Ročno ukrepanje bo potrebno le pri trajnih okvarah, kot so omrežne razdelitve, napačna konfiguracija omrežja, težave z avtentikacijo ali okvare strojne opreme.
Za več informacij si oglejte POGOSTA VPRAŠANJA in odgovore etcd.
Grozd z dvema vozliščema¶
Aktivna/pasivna gruča z dvema vozliščema še ni podprta in bo dodana v prihodnji različici. Priporočamo uvedbo tretjega vozlišča, bodisi tretjega NetHSM bodisi „priče“ etcd, ki bi lahko delovala v katerem koli gostitelju. Glejte naslednji razdelek „Priča“.
Priča¶
Zaradi narave združevanja v gruče s etcd je zanesljivost toliko večja, kolikor več je vozlišč v gruči. Kot je pojasnjeno v razdelku Operativna redundanca, bi bilo najbolje, da bi imele gruče vsaj tri vozlišča, da bi imeli prostor za odpoved, saj bo gruča z dvema vozliščema v celoti odpovedala, če odpove samo eno.
Vendar je funkcija zasnovana tako, da vam za doseganje stabilnega števila vozlišč v gručo ni treba dodati celotne prave naprave NetHSM. Namesto tega lahko sami namestite in dodate vozlišče „priče“. Takšno vozlišče je samo primerek etcd, ki teče na izbranem računalniku (ali v vsebniku) in je povezan s skupnostjo. Prave naprave v gruči ga bodo prepoznale kot navadno vozlišče in bo prejemalo vse podatke in posodobitve iz naprav (seveda pa z njim ne boste mogli izvajati nobenih operacij HSM - samo shranjuje podatke).
Security Considerations¶
Vozlišče priče (ali kdor koli z dostopom do njega) ima neposreden dostop do zaledja za shranjevanje vseh vozlišč v gruči (npr. vse vnose in ustrezne vrednosti lahko izpišete s etcdctl get "/" "0").
Z izjemo različice konfiguracije (/config/version, ki mora biti vedno „1“) so vse vrednosti šifrirane (s ključem naprave za vrednosti, specifične za vozlišče, ali ključi domene za druge vrednosti), kar zagotavlja zaupnost občutljivih podatkov.
Vendar upoštevajte, da lahko zlonamerno vozlišč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¶
Vsaka gruča se na začetku začne z enim vozliščem. Nova vozlišča se grozdu pridružijo eno za drugim.
Preparing Nodes¶
Omrežni promet med vozlišči je šifriran in overjen z njihovim potrdilom TLS.
Vsa vozlišča, ki naj bi bila del iste gruče, morajo najprej namestiti skupno overitelja potrdil (CA), ki jim bo omogočal preverjanje, ali so druga vozlišča legitimna.
V nadaljevanju predpostavljamo, da so vsa vozlišča sveže zagotovljena in delujejo.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Ustvarjanje in namestitev CA¶
Uporabniki naj CA ustvarijo na lasten način in v skladu s svojimi operativnimi omejitvami ter se prepričajo, da omogoča vsaj uporabo ključa keyCertSign.
Minimalni CA lahko na primer ustvarite s 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
Ta CA mora biti zdaj nameščen v vsakem vozlišču.
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).
Opomba
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" ]
Če želite za podpisovanje certifikatov uporabiti javno certifikacijsko agencijo, morajo vaši vozli uporabljati javne IP-naslove. To je posledica varnostne zahteve, ki javni certifikacijski agenciji prepoveduje izdajanje certifikatov z zasebnim IP-naslovom v polju IP SAN.
Glede na pridobljeni CSR (imenujmo ga nethsm.csr) lahko zanj ustvarimo potrdilo, ki je pripravljeno za namestitev. Na primer z 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).
Končno lahko CA (CA.pem) zdaj namestite s končno točko /config/tls/cluster-ca.pem (glejte dokumentacijo API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). To je mogoče šele, ko je nameščeno potrdilo TLS podpisano z njim. V nasprotnem primeru bo operacija zavrnjena.
Opomba
Ta postopek je treba ponoviti za vsako vozlišče.
Sinhronizacija ure¶
Prepričajte se, da je na vsakem vozlišču nastavljen točen sistemski čas, po možnosti z uporabo protokolov NTP/NTS namesto ročne nastavitve časa. To lahko storite s konfiguracijo Time in 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
Ko bo nadoknadil zaostanek, napredujte vozlišče iz statusa učenca v polnopravnega člana
Configure a Backup Passphrase¶
Najprej se prepričajte, da je v vozlišču, ki bo uporabljeno za registracijo novega priključka, konfigurirana rezervna gesla (glejte dokumentacijo API končne točke /config/backup-passphrase).
Registracija novega vozlišča¶
Pri roki imejte naslov IP vozlišča, ki se bo pridružilo. Polni URL (v terminologiji etcd imenovan tudi peer URL ) tega vozlišča bo https://<IP_of_node>:2380 (npr. https://192.168.1.1:2380). Vrata morajo biti 2380, zato se prepričajte, da požarni zid med vozlišči dovoljuje promet TCP na teh vratih.
Pravilnost naslova URL lahko preverite tako, da na vozlišču, ki naj bi se pridružilo, pokličete GET /cluster/members. Ta mora navesti samo enega člana: samega sebe.
Nato registrirajte ta pričakovani naslov URL v katerem koli obstoječem vozlišču gruče (če še nimate gruče, to storite v NetHSM, ki bo služil kot začetno vozlišče gruče). To storite z uporabo končne točke POST /cluster/members (glejte dokumentacijo API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) in ji posredujete telo JSON, ki vsebuje naslov URL.
Če je postopek uspešen, se vrne telo JSON obrazca:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
ki vsebuje informacije, potrebne za pridružitev novega vozlišča k gruči. Zlasti vsebuje seznam vseh članov gruče (pri čemer je član s praznim imenom novi član). Vsebuje tudi ključ domene, ki je šifriran z gesli za odklepanje in rezervno geslo - zato je treba pred tem konfigurirati rezervno geslo.
Opomba
V zgornjem odgovoru opazite, da je novi član »učenc«: zdaj se lahko poveže s klastrom in od njega prejema podatke, vendar ne more sodelovati, dokler ni povišan, kar bomo obravnavali v nadaljevanju.
Čeprav ta pojem »učenca« vključuje dodatni korak (napredovanje), omogoča varnejše delovanje grozda, saj morebitne težave z novim vozliščem pred njegovim napredovanjem ne morejo povzročiti nestabilnosti celotnega grozda.
Odziv shranite za naslednji korak.
Joining the Cluster as a Learner¶
Vzemite odgovor iz zadnjega koraka in mu dodajte polje backupPassphrase, ki vsebuje rezervno geslo vozlišča, na katerem je bil registriran novi član, ter te podatke prenesite v klic POST /cluster/join (glejte dokumentacijo API ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __) v vozlišču, ki naj bi se mu pridružil.
Opozorilo
Klic na POST /cluster/join bo obvisel, dokler novo vozlišče ne bo ročno povišano (glej spodaj). To je normalno. Ko se klic uspešno zaključi, to pomeni, da sta se priključitev in povišanje uspešno izvedli.
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 tej fazi se je novo vozlišče pridružilo kot vozlišče v fazi » « ( ): sinhronizira se s klastrom, vendar še ni operativno. Po drugi strani pa morebitne težave z vozliščem v tej fazi ne bodo povzročile težav v klastru, zaradi česar je ta postopek varen.
Zadnji korak za dokončanje priključitve je povišanje novega vozlišča v polnopravnega člana.
Promoting the New Learner¶
Glede na razmere v omrežju in v grozdu lahko traja nekaj časa, preden novi član uskladi svoje stanje z grozdom. Ko se to zgodi, se lahko iz statusa učenca povzdigne v polnopravnega člana.
Opozorilo
Povišanje statusa vozlišča poveča prag kvoruma v grozdu (glejte dokumentacijo API-ja » « ter poglavje »Operativna redundancija« v dokumentu » «). Preden povišate status novega vozlišča, se prepričajte, da ima stabilno povezavo z grozdom.
Novo članstvo lahko poskusite nadgraditi s klicem na POST /cluster/members/{MemberID}/promote (glejte dokumentacijo API-ja ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Če se udeleženec še ni uskladil, bo ta postopek spodletel s HTTP-kodo 412, zato je treba nadgradnjo poskusiti ponovno kasneje.
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¶
Potrebovali boste okolje, v katerem je na voljo etcd v3.6, z naslovom IPv4 (vsaj), ki je dosegljiv drugim članom vaše gruče. Dovoljen mora biti promet TCP na vrata 2380 in z njih.
Ustvarite prazen imenik, v katerem bo etcd hranil svoje podatke, in zapišite njegovo pot (mi bomo uporabili /var/etcd/data). Zagotovite, da ima uporabnik, ki bo zagnal proces, dovoljenje za branje in pisanje v imenik.
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.
Nato boste morali ustvariti potrdilo za pričo in ga podpisati s CA, da bo lahko komunicirala s svojimi vrstniki. To lahko storite na primer prek 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
Dobljene witness.key in witness.pem shranite tudi v /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šite odgovor grozda: vsebovati mora seznam članov grozda in komplet za pridružitev (tega dela ne boste potrebovali).
Configure etcd¶
Za razliko od naprav NetHSM, ki samodejno izberejo ime vozlišča (z uporabo ID naprave), morate izbrati ime za vsako dodano pričo, pri tem pa poskrbite, da so imena edinstvena. V naslednjih primerih bomo uporabili ime „witness1“.
Z odgovorom NetHSM za registracijo priče pripravite spremenljivke obrazca:
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,..."
Ob predpostavki, da je odgovor NetHSM shranjen v datoteki response.json, lahko zadnji dve spremenljivki ustvarite samodejno z naslednjimi izrazi 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"
Na koncu ustvarite datoteko etcd.conf.yml z uporabo datoteke s predlogo, ki je na voljo v datoteki docs/etcd_witness.conf.template:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Tako boste dobili datoteko z obrazcem:
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¶
Zagon etcd na želeni način (ročno, systemd storitev, vsebnik itd.) in ga usmerite na konfiguracijsko datoteko, ustvarjeno v prejšnjem koraku:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Najprej bi morali videti, kako se sistem zažene, nato se pridružite grozdu kot udeleženec in nadoknadite zamujene podatke.
Promote the Witness¶
Nazadnje, po nekaj časa, upoštevajte običajna navodila iz spletne strani v razdelku »Promoting the New Learner«, da napredujete pričo. Če to ne uspe, poskusite kasneje.
After a successful promotion, you should be able to check that it is healthy with the etcdctl client:
etcdctl get /config/version
Ta ključ mora obstajati in vsebovati vrednost „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¶
Varnostno kopiranje in obnavljanje¶
Varnostno kopiranje deluje enako kot brez gruče in ga lahko zahtevate iz katerega koli vozlišča gruče. Varnostna kopija bo ustvarila podatke za celotno gručo, vključno s polji za posamezna vozlišča (čeprav bodo ta prezrta, razen če se varnostna kopija obnovi v vozlišču, ki ni bilo dodeljeno).
Varnostno kopijo, izdelano v gruči, je mogoče obnoviti v isti gruči, tudi če so bila od takrat dodana ali odstranjena nekatera vozlišča. Takšne obnovitve, opravljene v delujočih gručah, ne bodo vplivale na konfiguracijske vrednosti (samo na ključe, uporabnike, prostore imen), tako kot vsaka druga delna obnovitev.
Obnovitev varnostne kopije v vozlišču, ki ni bilo dodeljeno, bo obnovila polja, značilna za vozlišče (kot so omrežna konfiguracija, certifikati itd.) vozlišča, ki je bilo uporabljeno za ustvarjanje varnostne kopije.
Obnovitev velike varnostne kopije lahko za nekaj časa preobremeni gručo, medtem ko vozlišče, ki izvaja obnovitev, posreduje spremembe drugim vozliščem.
Ta operacija ostaja združljiva z varnostnimi kopijami, narejenimi v prejšnjih različicah NetHSM.
Opomba
Obnovitev varnostne kopije, izdelane v drugem vozlišču Z z drugačnim domenskim ključem, v vozlišču A bo pravilno prepisala domenski ključ vozlišča A kot prej. Če pa je bil A v gruči z vozliščem B, bo vozlišče B postalo neuporabno, saj se domenski ključ Z ne bo obnovil na vozlišču B.
Z drugimi besedami, obnovitev izvajajte le v gruči, katere varnostne kopije so bile izdelane v isti gruči (čeprav so bila vozlišča od takrat morda odstranjena ali dodana). Če želite obnoviti tujo varnostno kopijo v vozlišču, ga najprej varno odstranite iz gruče, nato ga tovarniško ponastavite in obnovite varnostno kopijo.
Čisto odstranjevanje vozlišča¶
Dokler del gruče še vedno izpolnjuje kvorum, je mogoče katerega koli njenega člana uporabiti za odstranitev drugega vozlišča iz gruče, ne glede na to, ali je to vozlišče že nedosegljivo ali pa se pričakuje, da bo.
Najprej morate poznati ID vozlišča, ki ga želite odstraniti, in sicer tako, da na spletni strani GET /cluster/members naštejete vsa vozlišča in poiščete pravo.
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.
Opomba
Tudi vozlišče, ki se je pridružilo grozdu, a še ni bilo povišano, se lahko na ta način varno odstrani.
Recovering a Failed Node¶
Vozlišče, ki poroča o stanju » Failed« ( ni uspelo), ne bo odgovarjalo na večino običajnih ukazov. Kljub temu ga je mogoče izklopiti, ponovno zagnati, ponastaviti, diagnosticirati ali izolirati.
Opozorilo
Obstoj stanja » « (neuspešno), » «, operacije » ` «, »diagnose` « in » ` « ter »force-new` « velja le za različico 5.0 in novejše. V različici 4.0 se vozlišče z izgubljenim kvorumom preneha odzivati na vse zahteve. ga je treba ponastaviti na tovarniške nastavitve.
Med pogoste vzroke za stanje vozlišča » « (Napaka) spadajo:
Trajno izgubljeno kvorum.
Začasna izguba kvoruma (npr. ob dodajanju drugega vozlišča v grozd, ko se to vozlišče še ni priključilo).
etcdse trenutno ponovno zaganjata (npr. zaradi spremembe certifikatov ali ponovne konfiguracije omrežja).Skupina je izpostavljena zelo visoki obremenitvi (npr. med obnovitvijo zelo obsežne varnostne kopije).
Ne glede na vzrok bo NetHSM prešel v stanje » Failed« ( ) šele po najmanj eni minuti neuspešnih poskusov vzpostavitve povezave z lastno bazo podatkov. S tem se želi preprečiti napačne prehode, ki jih povzročajo zelo kratkotrajne nestabilnosti.
Da bi lažje razumeli, v katerem stanju se nahaja vaš vozlišče, je končna točka GET /health/diagnose še naprej na voljo in vrača informacije o trenutnem stanju etcd ter njegove zbirke podatkov, vključno z dnevniki (glejte dokumentacijo API-ja).
Opomba
Če in ko bo baza podatkov spet na voljo (npr. ko bo kvorum ponovno vzpostavljen zaradi odprave omrežne napake), bo NetHSM samodejno prešel iz stanja » Failed« ( ) v stanje, v katerem je bil prej (ali pa bo nadaljeval z običajnim zagonskim postopkom, če se je ravno zaganjal), brez potrebe po kakršnem koli ročnem posegu. Potrebno bo do ene minute po odpravi težave, da se grozd stabilizira, da HSM zazna odpravo težave in spremeni stanje.
Če ugotovite, da je napaka trajna (npr. izguba kvoruma brez upanja na rešitev vzroka), lahko:
V vozlišču izvedite ponastavitev na tovarniške nastavitve ( ), s čimer se bodo izbrisali vsi podatki, nato pa obnovite varnostno kopijo.
Z ukazom ` ` izolirajte vozlišče z končnim točkom ` `` POST /cluster/force-new`, kar bo povzročilo, da bo vozlišče nepovratno pozabilo vse druge člane grozda, obnovilo podatke ` `` etcd`, ki so shranjeni na disku, in se ponovno zagnalo. Če je bila osnovna napaka povezana z grozdom, bo vozlišče sledilo običajnemu zaporedju zagona in se, odvisno od nastavitev samodejnega zagona, znašlo bodisi v stanju ` Locked` bodisi v stanju ` Operational`.
Opomba
Če je vozlišče izolirano z ukazom » force-new«, bo odslej nesinhronizirano s klastrom: morebitnih novih zapisov na njem ali v klastru ni mogoče uskladiti. Vozlišče se lahko še vedno ponovno pridruži klastru, vendar bo izgubilo vse svoje lokalne spremembe.
Končna točka POST /cluster/force-new, ki je na voljo le v stanju » « ( ) z napako » «, zahteva avtentifikacijo, saj je potencialno destruktivna. Ker pa v tem stanju uporabniki in vloge HSM niso na voljo, končna točka pričakuje, da se HTTPS-odjemalci vedno avtentificirajo z lažnim uporabnikom unlock ter z zadnjo znano geslo za odklepanje kot geslom.
Opozorilo
Po posodobitvi iz različice < 5.0 bo končna točka force-new vedno prikazovala napako »Unauthorized«, dokler se HSM ne odklene ali se geslo za odklepanje vsaj enkrat ne spremeni.
Software Updates in Clusters¶
Prihodnje posodobitve bodo označene kot „varne za gruče“ (to naj bi bila večina) ali „nevarne za gruče“.
Posodobitve, ki so varne za gruče, lahko uporabite za vozlišča, ki so del gruče, ne da bi jih prej odstranili iz gruče. Vendar morate tako kot pri vseh operacijah zagotoviti, da to storite na enem vozlišču hkrati in v gruči, kjer odstranitev vozlišča ne zmanjša kvoruma (npr. če posodobitev ne uspe).
Posodobitve, ki niso varne za gručo, je treba uporabiti v izoliranih vozliščih. Skupino morate razstaviti (vozlišča odstraniti eno za drugim), tovarniško ponastaviti vsa vozlišča razen enega, posodobitev uporabiti v vsakem vozlišču, nato pa vsa ponastavljena vozlišča združiti s preostalim vozliščem.
Pred takimi operacijami naredite varnostno kopijo.
Ponovno konfiguriranje obstoječe gruče¶
Changing the Cluster CA¶
Obstoječa gruča (z dvema ali več vozlišči) med delovanjem ne more spremeniti svojega CA gruče. Če morate to potrdilo spremeniti: izberite vozlišče, odstranite vsa druga vozlišča, posodobite CA, nato pa naj se drugi člani ponovno pridružijo.
Changing the Network Configuration of Nodes¶
Če spremenite omrežno konfiguracijo vozlišča (npr. spremenite njegov IP), bodo druga vozlišča samodejno obveščena o posodobitvi. Vendar morate zagotoviti, da take posodobitve izvajate le na enem vozlišču naenkrat in v gruči, v kateri izguba tega vozlišča ne bi povzročila izgube kvoruma.