Clustering¶
Megjegyzés
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.
A NetHSM 4.0-tól kezdődően támogatja a klaszterezést az adatok több NetHSM közötti közvetlen szinkronizálásához. Ez támogatja a kulcsgenerációk nagy gyakoriságát, megvalósítja a nagy rendelkezésre állást és a terheléselosztást. A NetHSM klaszter a etcd alapú, amely a Raft konszenzus algoritmust használja az erős konzisztencia érdekében. Ez biztosítja, hogy az adatok (pl. kulcsok) minden NetHSM-ben mindig helyesek legyenek.
A NetHSM fürt felállítása előtt ismerkedjen meg ezzel a technológiával és annak korlátaival a véletlen kiesés és adatvesztés elkerülése érdekében. Ezen a dokumentumon kívül érdemes a etcd dokumentációját is megnézni:.
Operational Redundancy¶
„Csomópontnak” nevezzük azt a NetHSM-et, amely várhatóan egy fürt része lesz. A N csomópontokból álló fürt addig működik, amíg legalább a (N/2)+1 csomópontok egészségesek és elérhetőek. Az egészséges, elérhető csomópontok minimális számát kvórumnak nevezzük.
Egy olyan klaszteren, amely ezt a küszöbértéket alulmúlja (pl. hálózati probléma miatt), nem választható meg vezető, és az egyes csomópontokon található etcd helyi példánya nem képes többé olvasási és írási műveleteket végrehajtani. Ez a következő eseteket vonja maga után.
Egy csomópont leáll, de a kvórum még mindig elérhető¶
Egy 3 csomópontos fürtben, ha az egyik csomópont meghibásodik (összeomlik vagy hálózati körülmények miatt elérhetetlenné válik), a másik két csomópont tovább működik és kiszolgálja a kéréseket.
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.
Ha soha nem áll helyre, akkor azt el kell távolítani a klaszterből, és vagy helyreállítási eljáráson kell átesnie az adatok eléréséhez (de ekkor már nem lesz a klaszter része), vagy gyári beállításokra kell visszaállítani, és a csatlakozási folyamatot elölről kell végigcsinálni.
Hálózati felosztás történik, de a kvórum még mindig elérhető¶
Ez csak az előző forgatókönyv általánosítása. Egy 5 csomópontos fürtben, ahol például 3 csomópont egy A fizikai helyen, 2 csomópont pedig egy másik B helyen van, az A és B elszigetelésével kapcsolatos hálózati probléma a következőket jelentené:
Az A helyen lévő 3 csomópont megfelel a határozatképességnek (ebben az esetben 3), így továbbra is működnek.
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).
Ha a hálózati probléma megoldódik, a 2 csomópont tisztán visszacsatlakozik a 3 másikhoz.
Más szavakkal: a legrosszabb esetben bekövetkező hálózati elválasztás (páratlan számú csomóponttal rendelkező fürtben) esetén a fürt nagyobb fele továbbra is működőképes marad, míg a kisebb fele a probléma megoldásáig nem lesz üzemképes.
A határozatképesség tartósan elveszett¶
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.
Ez például akkor fordulhat elő, ha egy 2 csomópontos fürtben (ahol a kvórum 2) egyetlen csomópont is meghibásodik. Ebben a helyzetben a meghibásodott csomópontot utólag nem lehet tisztán eltávolítani a fürtből, mivel a megmaradt egészséges csomópont már működésképtelen, mivel elvesztette a kvórumot.
Ezért ajánlatos, hogy mindig páratlan számú csomópont legyen a fürtben, és gyakran készítsen biztonsági mentést.
Hogy egyértelmű legyen, a ** a kvórum elvesztése (például ha a fürt összes csomópontját együtt indítja újra, vagy ha egy átmeneti hálózati hiba elszigeteli a csomópontokat) nem jelent problémát: amint elegendő csomópont csatlakozik újra (anélkül, hogy manuálisan újra csatlakoznia kellene) a kvórum eléréséhez, a fürt folytatja a normál működését. Csak az olyan tartós hibák, mint például a hálózati partíciók, a hálózati félrekonfigurációk, a hitelesítési problémák vagy a hardverhibák igényelnek manuális beavatkozást.
További információért lásd etcd’s GYIK.
2 csomópontos klaszter¶
A két csomópontos aktív/passzív fürt még nem támogatott, és egy későbbi verzióban hozzáadjuk. Javasoljuk egy 3. csomópont bevezetését, akár egy 3. NetHSM-et, akár egy etcd „tanút”, amely bármelyik hoston üzemeltethető. Lásd a következő, „Tanú” című szakaszt.
Tanú:¶
A etcd klaszterezés jellegéből adódóan annál megbízhatóbb, minél több csomópont van a klaszterben. Amint azt a Operational Redundancy szakaszban kifejtettük, a fürtöknek ideális esetben legalább 3 csomópontot kell tartalmazniuk, hogy legyen hely a meghibásodásra, mivel egy 2 csomópontos fürt teljesen meghibásodik, ha csak az egyik meghibásodik.
A funkció kialakítása azonban olyan, hogy nem kell egy teljes, valódi NetHSM eszközt hozzáadni a fürthöz ahhoz, hogy stabil csomópontszámot érjen el. Ehelyett maga is telepíthet és hozzáadhat egy „tanú” csomópontot. Egy ilyen csomópont nem más, mint a etcd egy példánya, amely az Ön által választott gépen (vagy konténerben) fut, és csatlakozik a fürthöz. A fürtben lévő valódi eszközök normál csomópontként fogják felismerni, és minden adatot és frissítést megkap az eszközöktől (de természetesen semmilyen HSM műveletet nem fog tudni végrehajtani vele - csak adatokat tárol).
Security Considerations¶
A tanú csomópont (vagy bárki, akinek hozzáférése van hozzá) közvetlen hozzáféréssel rendelkezik a fürt összes csomópontjának tárolási háttértárához (pl. a etcdctl get "/" "0" segítségével ki tudja tölteni az összes bejegyzést és a hozzájuk tartozó értékeket).
A konfigurációs verzió kivételével (/config/version, amelynek mindig „1”-nek kell lennie) azonban szigorúan minden érték titkosítva van (vagy egy eszközkulccsal a csomópont-specifikus értékek esetében, vagy a tartománykulcsokkal a többi érték esetében), biztosítva az érzékeny adatok titkosságát.
Megjegyzendő azonban, hogy egy rosszindulatú csomópont:
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¶
Minden fürt kezdetben egyetlen csomóponttal indul. Az új csomópontok egyesével csatlakoznak a fürthöz.
Preparing Nodes¶
A csomópontok közötti hálózati forgalom titkosított és hitelesített a TLS-tanúsítványuk segítségével.
Minden olyan csomópontnak, amely várhatóan ugyanannak a fürtnek a része lesz, először telepítenie kell egy közös hitelesítésszolgáltatót (CA), amely lehetővé teszi számukra, hogy ellenőrizzék a többi csomópont legitimitását.
A következőkben feltételezzük, hogy minden csomópont frissen telepített és működőképes.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
CA létrehozása és telepítése¶
A felhasználóknak saját eszközeikkel és saját működési korlátaiknak megfelelően kell létrehozniuk a hitelesítésszolgáltatót, ügyelve arra, hogy az legalább a keyCertSign kulcs használatát lehetővé tegye.
Például egy minimális hitelesítésszolgáltató létrehozható a openssl címmel:
$ 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
Ezt a hitelesítésszolgáltatót mostantól minden csomópontra telepíteni kell.
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).
Megjegyzés
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" ]
Ha nyilvános tanúsítóhatóságot szeretne használni a tanúsítványok aláírásához, akkor a csomópontjainak nyilvános IP-címeket kell használniuk. Ennek oka egy biztonsági követelmény, amely megtiltja a nyilvános tanúsítóhatóságoknak, hogy olyan tanúsítványokat állítsanak ki, amelyek IP SAN-jében magán IP-cím szerepel.
A kapott CSR (nevezzük nethsm.csr) alapján létrehozhatunk egy tanúsítványt, amelyet telepíthetünk. Például a openssl segítségével:
$ 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).
Végül a hitelesítésszolgáltató (CA.pem) mostantól telepíthető a /config/tls/cluster-ca.pem végponttal (lásd a API dokumentáció). Ez csak akkor lehetséges, ha a telepített TLS tanúsítványt aláírta. Ellenkező esetben a művelet elutasításra kerül.
Megjegyzés
Ezt a folyamatot minden csomópont esetében meg kell ismételni.
Óra szinkronizálás¶
Győződjön meg arról, hogy minden csomópont pontos rendszeridővel rendelkezik; ideális esetben az NTP/NTS használatával, a kézi időbeállítás helyett. Ez a Time és a NTS/NTP konfigurációk segítségével valósítható meg.
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
Miután felzárkózott, emelje a csomópontot tanuló státuszból teljes jogú taggá
Configure a Backup Passphrase¶
Először is győződjön meg róla, hogy a csomóponton, amelyet az új csatlakozó regisztrálásához használnak, be van állítva egy biztonsági jelszó (lásd a /config/backup-passphrase végpont API dokumentációját).
Új csomópont regisztrálása¶
Legyen kéznél a csatlakozó csomópont IP címe. A csomópont teljes URL címe (más néven peer URL a etcd terminológiában) https://<IP_of_node>:2380 (pl. https://192.168.1.1:2380). A portnak 2380-nak kell lennie, ezért a csomópontok közötti tűzfalnak engedélyeznie kell a TCP-forgalmat ezen a porton.
Az URL helyes voltát a GET /cluster/members meghívásával ellenőrizheti a csatlakozni kívánt csomóponton. Ennek csak egy tagot kell felsorolnia: saját magát.
Ezután regisztrálja a várt URL-t a fürt bármely meglévő csomópontján (ha még nincs fürtje, akkor ezt azon a NetHSM-en végezze el, amely a fürt kezdeti csomópontjaként fog szolgálni). Ezt a POST /cluster/members végpont segítségével lehet megtenni (lásd a API dokumentáció), átadva neki egy JSON testet, amely tartalmazza az URL-t.
Siker esetén az űrlap JSON testét adja vissza:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
],
"learner": true
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
],
"learner": false
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
amely tartalmazza az új csomópont fürthöz való csatlakozásához szükséges információkat. Különösen felsorolja a fürt összes tagját (ahol az üres névvel rendelkező tag az új csatlakozó). Tartalmazza továbbá a feloldási és a biztonsági jelszavakkal titkosított tartománykulcsot is - tehát a biztonsági jelszót korábban be kell állítani.
Megjegyzés
Figyeljük meg a fenti válaszban, hogy az újonnan csatlakozó csomópont „tanuló” státuszú: már csatlakozhat a klaszterhez és adatokat is fogadhat tőle, de addig nem vehet részt a működésben, amíg el nem éri a magasabb státuszt; erről az alábbiakban lesz szó.
Bár ez a „tanuló” koncepció egy további lépéssel (előléptetéssel) jár, lehetővé teszi a klaszter biztonságosabb működését, mivel az új csomóponttal kapcsolatos bármilyen probléma nem okozhat instabilitást az egész klaszterben az előléptetése előtt.
Tartsa meg ezt a választ a következő lépésre.
Joining the Cluster as a Learner¶
Vegyük az utolsó lépés válaszát, és csatoljunk hozzá egy backupPassphrase mezőt, amely tartalmazza annak a csomópontnak a biztonsági jelszavát, amelyen az új csatlakozót regisztrálták, és adjuk át ezt az adatot a POST /cluster/join hívásához (lásd a API dokumentációját) azon a csomóponton, amelyhez várhatóan csatlakozni fog.
Figyelem
A ` POST /cluster/join ` hívás addig felfüggesztett állapotban marad, amíg az új csomópontot manuálisan nem léptetik elő (lásd alább). Ez normális jelenség. Ha a hívás sikeresen visszatér, az azt jelzi, hogy a csatlakozás és az előléptetés sikeresen lezajlott.
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.
Jelenleg az új csomópont „ ” tanuló csomópontként csatlakozott: éppen szinkronizálódik a klaszterrel, de még nem működőképes. Ugyanakkor, ha ebben a szakaszban bármilyen probléma merül fel a csomóponttal, az nem okoz gondot a klaszter számára, így ez a művelet biztonságos.
Az összevonás befejezésének utolsó lépése az, hogy az új csomópontot teljes jogú taggá emeljék.
Promoting the New Learner¶
A hálózati és a klaszterbeli körülményektől függően eltarthat egy ideig, amíg az új tag felzárkózik a klaszterhez. Amint ez megtörténik, a tag „tanuló” státuszából „teljes jogú tag” státuszba léphet.
Figyelem
Egy csomópont feljogosítása növeli a klaszter kvórumküszöbét (lásd az „ ” API dokumentációt, valamint a jelen dokumentum „ Operational Redundancy” című szakaszát). A feljogosítás előtt győződjön meg arról, hogy az új csomópont stabil kapcsolattal rendelkezik a klaszterhez.
Megpróbálhatja az új tagot előléptetni a ` `` POST /cluster/members/{MemberID}/promote` hívással (lásd a „ ” API dokumentációját:). Ha a tanuló még nem érte utol a többieket, akkor a művelet 412-es HTTP-hibakóddal fog végződni, és az előléptetést később újra kell próbálni.
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¶
Szükséged lesz egy olyan környezetre, ahol a etcd v3.6 elérhető, és amelynek IPv4 címe (legalább) elérhető a fürt többi tagja számára. A 2380-as portra és portról induló TCP forgalmat engedélyezni kell.
Hozzon létre egy üres könyvtárat, ahol a etcd tárolja majd az adatait, és írja le az elérési útját (mi a /var/etcd/data címet fogjuk használni). Győződjünk meg arról, hogy a folyamatot indító felhasználónak olvasási és írási joga van a könyvtárba.
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.
Ezután létre kell hoznia egy tanúsítványt a tanú számára, és alá kell írnia a hitelesítésszolgáltatóval, hogy kommunikálni tudjon a társaival. Ezt például a openssl címen keresztül lehet megtenni:
# 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
Az így kapott witness.key és witness.pem adatokat tárolja a /var/etcd oldalon is.
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).
Írja le a klaszter válaszát: ennek tartalmaznia kell a klasztertagok listáját és egy csatlakozó készletet (erre a részre nem lesz szüksége).
Configure etcd¶
A NetHSM-ekkel ellentétben, amelyek automatikusan választanak maguknak egy csomópontnevet (az eszköz azonosítójával), minden egyes hozzáadott tanúnak nevet kell választania, ügyelve arra, hogy a nevek egyediek legyenek. A következő példákban a „witness1” nevet fogjuk használni.
A NetHSM válaszával a tanú nyilvántartásba vételére, készítse el a nyomtatvány változásait:
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,..."
Feltételezve, hogy a NetHSM válasz egy response.json fájlban van tárolva, a két utolsó változót automatikusan generálhatja a következő jq kifejezésekkel:
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"
Végül hozzon létre egy etcd.conf.yml fájlt a docs/etcd_witness.conf.template sablonfájl segítségével:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Ezáltal megkapja a formanyomtatvány fájlját:
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¶
Indítsd el a etcd az általad választott módon (manuálisan, systemd szolgáltatással, konténerrel stb.), és mutass rá az előző lépésben létrehozott konfigurációs fájlra:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Látnod kellene, ahogy elindul, csatlakozik a klaszterhez tanulóként, és felzárkózik az adatokhoz.
Promote the Witness¶
Végül, egy kis idő elteltével kövesse az „ ” (A tanuló előléptetése) című dokumentum „ <clustering.html#promoting-the-new-learner> ” (A tanuló előléptetése) című szakaszában található szokásos utasításokat a tanú előléptetéséhez. Ha ez nem sikerül, próbálja meg később újra.
After a successful promotion, you should be able to check that it is healthy with the etcdctl client:
etcdctl get /config/version
Ennek a kulcsnak léteznie kell, és „1”-et kell tartalmaznia.
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¶
Biztonsági mentés és visszaállítás¶
A biztonsági mentés ugyanúgy működik, mint fürt nélkül, és a fürt bármelyik csomópontjáról kérhető. A művelet az egész fürt adatainak biztonsági mentését végzi, beleértve a csomópont-specifikus mezőket is (bár ezeket figyelmen kívül hagyja, kivéve, ha a biztonsági mentést egy nem rendelkezésre bocsátott csomóponton állítja vissza).
Egy fürtön készített biztonsági mentés ugyanezen a fürtön visszaállítható, még akkor is, ha azóta néhány csomópontot hozzáadtak vagy eltávolítottak. A működő fürtökön végzett ilyen visszaállítások nem érintik a konfigurációs értékeket (csak a kulcsokat, felhasználókat, névtereket), mint bármely más részleges visszaállítás.
A biztonsági mentés visszaállítása egy nem rendelkezésre bocsátott csomóponton visszaállítja a biztonsági mentés létrehozásához használt csomópont csomópont-specifikus mezőit (például a hálózati konfigurációt, tanúsítványokat stb.).
Egy nagyméretű biztonsági mentés visszaállítása egy időre túlterhelheti a fürtöt, amíg a visszaállítást végző csomópont továbbítja a változásokat a többieknek.
Ez a művelet továbbra is kompatibilis a NetHSM korábbi verzióival készített biztonsági mentésekkel.
Megjegyzés
Ha egy A csomóponton visszaállít egy másik Z csomóponton más tartománykulccsal készített biztonsági másolatot, akkor az A csomópont tartománykulcsát helyesen írja át, ahogy korábban is. Ha azonban A a B csomóponttal egy fürtben volt, a B csomópont működésképtelenné válik, mivel Z tartománykulcsa nem lesz visszaállítva a B csomóponton.
Más szóval, csak olyan fürtben végezzen visszaállítást, amelynek biztonsági mentései ugyanabban a fürtben készültek (bár azóta csomópontok is eltávolításra vagy hozzáadásra kerülhettek). Ha egy idegen biztonsági másolatot szeretne visszaállítani egy csomóponton, először biztonságosan távolítsa el azt a fürtjéből, majd állítsa vissza gyári állapotba, és állítsa vissza a biztonsági másolatot.
Csomópontok tiszta eltávolítása¶
Amíg a fürt valamelyik része még megfelel a határozatképességnek, addig bármelyik tagja felhasználható egy másik csomópont eltávolítására a fürtből, függetlenül attól, hogy ez a csomópont már elérhetetlen vagy várhatóan az lesz.
Először is meg kell tudnod az eltávolítani kívánt csomópont azonosítóját, ehhez a GET /cluster/members oldalon keresztül listázd ki az összes csomópontot, és keresd meg a megfelelőt.
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.
Megjegyzés
Az a csomópont, amely csatlakozott a klaszterhez, de még nem lett előléptetve, szintén biztonságosan eltávolítható ezzel a módszerrel.
Recovering a Failed Node¶
Az a csomópont, amely a „ Failed” ( meghiúsult) állapotot jelenti, a legtöbb szokásos műveletre nem fog válaszolni. A rendszert azonban továbbra is le lehet állítani, újraindítani, visszaállítani, diagnosztizálni vagy elszigetelni.
Figyelem
A „ ” hibajelentés, a „ ” állapot, valamint a diagnose és a force-new műveletek csak az 5.0-s verziótól kezdve érvényesek. A 4.0-s verzióban a kvórumát elvesztett csomópont nem válaszol többé a all kérésekre. Ezt a csomópontot gyári beállításokra kell visszaállítani.
A „ Failed” állapotba kerülő csomópontok leggyakoribb okai a következők:
A tartósan elvesztett határozatképesség.
A határozatképesség átmeneti elvesztése (pl. amikor egy második csomópontot adnak hozzá a klaszterhez, és a második csomópont még nem csatlakozott).
A `etcd` jelenleg újraindul (például azért, mert megváltoztak a tanúsítványok, vagy újrakonfigurálták a hálózatot).
A klaszter rendkívül nagy terhelés alatt áll (pl. egy nagyon nagy biztonsági másolat visszaállítása közben).
Bármilyen okból is történjen, a NetHSM csak akkor vált át a „ Failed” ( ) állapotba, ha legalább egy teljes percig sikertelenül próbálta elérni az adatbázisát. Ezzel elkerülhetők a nagyon rövid ideig tartó instabilitások által okozott téves állapotváltások.
Annak érdekében, hogy könnyebben meg tudd állapítani, melyik állapotban van a csomópontod, a GET /health/diagnose végpont továbbra is elérhető, és információkat ad vissza a etcd jelenlegi állapotáról, valamint az ahhoz tartozó adatbázisról, beleértve a naplókat is (lásd az API-dokumentációt).
Megjegyzés
Amennyiben és amikor az adatbázis ismét elérhetővé válik (pl. a kvórum helyreáll, mert a hálózati probléma megoldódott), a NetHSM automatikusan átlép a „ Failed” ( ) állapotból az előző állapotába (vagy folytatja a normál indítási sorrendet, ha éppen indítás közben volt), anélkül, hogy bármilyen kézi beavatkozásra lenne szükség. A probléma megoldását követően legfeljebb egy percbe telik, amíg a klaszter stabilizálódik, a HSM észleli a hiba elhárítását, és állapotot vált.
Ha arra a következtetésre jutsz, hogy a hiba tartós (pl. a kvórum elvesztése, és nincs remény az alapvető probléma megoldására), akkor a következőket teheted:
Állítsa vissza a csomópontot gyári beállításokra ( ), ami az összes adat törlését jelenti, majd állítsa vissza a biztonsági másolatot.
**** parancs segítségével izolálja azt a csomópontot, amely a ` ` végponttal rendelkezik; ez a művelet visszafordíthatatlanul eltávolítja az összes többi klasztertagot a rendszerből, helyreállítja a lemezen található ` ` adatokat, majd újraindítja a rendszert. Ha az alapul szolgáló hiba a klaszterrel kapcsolatos volt, a csomópont a szokásos indítási sorrendet követi, és az automatikus indítási beállítástól függően vagy a Locked , vagy a Operational állapotba kerül. POST /cluster/force-new etcd ** **
Megjegyzés
Ha egy csomópontot a ` `` force-new` parancsokkal izolálnak, akkor az a klaszterrel szinkronizálatlan állapotba kerül: a csomóponton vagy a klaszteren végzett új írási műveletek nem egyeztethetők össze. A csomópont továbbra is visszacsatlakozhat a klaszterhez, de minden helyi módosítását elveszíti.
A POST /cluster/force-new végpont – amely kizárólag a „ Failed” ( sikertelen) állapotban elérhető – hitelesítést igényel, mivel potenciálisan káros hatással járhat. Mivel azonban ebben az állapotban a HSM-felhasználók és -szerepkörök nem érhetők el, a végpont elvárja, hogy a HTTPS-ügyfelek mindig a unlock álfelhasználóval, valamint a legutóbb ismert feloldási jelszóval hitelesítsék magukat.
Figyelem
A 5.0-nál korábbi verzióról történő frissítés után az force-new végpont hozzáférése mindig „Unauthorized” (Jogosulatlan) állapotban lesz, amíg a HSM-et fel nem oldják, vagy a feloldási jelszót legalább egyszer meg nem változtatják.
Software Updates in Clusters¶
A jövőbeni frissítések „cluster-safe” (ez lesz a többség) vagy „cluster-unsafe” jelzéssel lesznek ellátva.
A fürtbiztos frissítések alkalmazhatók a fürt részét képező csomópontokra anélkül, hogy előbb eltávolítanák őket a fürtből. Azonban mint minden műveletnél, itt is ügyelni kell arra, hogy ezt egyszerre csak egy csomóponton végezze el, és olyan fürtben, ahol egy csomópont eltávolítása nem megy a kvórum alá (pl. ha a frissítés sikertelen).
A klaszter-biztos frissítéseket elszigetelt csomópontokra kell alkalmazni. A fürtöt szét kell bontani (a csomópontokat egyenként eltávolítva), egy kivételével az összes csomópontot gyári alaphelyzetbe kell állítani, a frissítést minden csomópontra alkalmazni, majd az összes alaphelyzetbe állított csomópontot a megmaradt csomóponthoz kell csatlakoztatni.
Az ilyen műveletek előtt mindenképpen készítsen biztonsági mentést.
Meglévő klaszter átkonfigurálása¶
Changing the Cluster CA¶
Egy meglévő (két vagy több csomóponttal rendelkező) fürt **** nem változtathatja meg a fürt CA-ját működés közben. Ha meg kell változtatnia ezt a tanúsítványt: válasszon ki egy csomópontot, távolítsa el az összes többi csomópontot, frissítse a hitelesítésszolgáltatót, majd a többi tag csatlakozzon újra.
Changing the Network Configuration of Nodes¶
Egy csomópont hálózati konfigurációjának módosítása (pl. az IP-cím megváltoztatása) automatikusan értesíti a többi csomópontot a frissítésről. Ügyelni kell azonban arra, hogy az ilyen frissítéseket egyszerre csak egyetlen csomóponton hajtsa végre, és olyan fürtben, ahol a csomópont elvesztése nem vezet a kvórum elvesztéséhez.