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.

• Még nem bizonyult be elegendő számú termelési környezetben, és előfordulhatnak hibák.

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 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ú:

The nature of clustering with etcd makes it more reliable the more nodes there are in the cluster. As explained in the Operational Redundancy section, clusters should ideally have at least 3 nodes to have room to fail, since a 2-node cluster will entirely fail if only one fails.

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.

Mit osztanak meg a csomópontok között

A NetHSM-ek csoportja azt jelenti, hogy az adatok nagy része közös használatban van közöttük. A kulcsok, felhasználók vagy névterek bármelyik csomóponton történő hozzáadása, módosítása vagy törlése végül az összes többi csomóponton is megjelenik. Általában minden olyan művelet, amely módosítja az állapotot, minden csomópont állapotát módosítja. Ez magában foglalja a visszaállítás műveletet is, amely a szokásos módon működik.

A következő szakaszok részletezik, hogy mely adatok teljesen helyi adatok, mely adatok tárolódnak a megosztott etcd tárolóban, de csomópont-specifikusak maradnak, és mely adatok vannak teljesen megosztva a csomópontok között.

Nem az etcd-ben tárolt

Az egyes csomópontok eszközkulcsa csak helyben tárolódik, és soha nem kerül megosztásra a csomópontok között.

Az etcd-ben tárolva, de csomópontspecifikusan

A következő adatokat a etcd tárolja, minden egyes csomópont esetében más-más hatókörben. Ezért minden csomópont számára elérhető, de nem egységes a csomópontok között (minden csomópontnak más-más értéke lehet ezeknek az adatoknak).

Configuration:

• TLS certificates

• Clock configuration

• Network configuration

• Logging configuration

• Unattended boot configuration

• Unlock salt (so each node has its own unlock passphrase)

• Locked domain key

Vegye figyelembe, hogy bár minden csomópont rendelkezik a zárolt tartományi kulcs saját verziójával (mivel minden csomópont a saját eszközkulcsával vagy feloldási jelszavával zárolja azt), az alapul szolgáló tartományi kulcs a címen érhető el, amelyet a csomópontok a címen osztanak meg (a közös HSM-adatok, például a kulcsok eléréséhez).

etcd-ben tárolva és megosztva

Az összes alábbi adat a etcd címen tárolódik a globális hatókörben, így a fürt minden csomópontjában egységes:

HSM adatok:

• Keys

• Felhasználók

• Névterek

Configuration:

• Config/domain store version

• Cluster CA (used to authenticate nodes across cluster)

• Backup passphrase and backup salt

Note that for now the config/domain store version can only be version 1 (if your software version supports clustering, then that is what you have). Refer to the Software Updates in Clusters section for more details on the safety of installing software updates within a cluster.

Creating a Cluster

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 as described in the section Network.

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.

Ehhez először hozzon létre egy tanúsítvány-aláírási kérést (CSR) a csomópontról, a „ ” TLS-tanúsítvány című szakaszban leírtak szerint. A nitropia esetében ez a következő paranccsal történik: nitropy nethsm --host $NETHSM_HOST csr --api.

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" ]

esetén a nitropia használatakor az --san opciót kell alkalmazni, pl.: --san "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

Ezután telepítse a kapott new_cert.pem fájlt a TLS-tanúsítvány című szakaszban leírtak szerint (a nitropia: nitropy nethsm --host $NETHSM_HOST set-certificate --api new_cert.pem fájlokkal együtt).

Finally, the CA (CA.pem) can now be installed. This is only possible once the installed TLS certificate is signed by it. Otherwise, the operation will be rejected.

nitropyREST API

érvek

Érv	Leírás
FILENAME	The path of the CA file

Példa

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

A telepített klaszter-hitelesítő hatóság a következő paranccsal érhető el: ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

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:

1. Register the addition to the cluster (through any one of its members)

2. Tell the new node to join

3. Miután felzárkózott, emelje a csomópontot tanuló státuszból teljes jogú taggá

Configure a Backup Passphrase

First make sure a backup passphrase is configured on the node that will be used to register a new joiner as described in the section Backup.

Ú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.

You can double-check the URL is correct by listing the cluster members on the node that is expected to join. This should list just one member: itself.

nitropyREST API

Példa

$ nitropy nethsm --host $NETHSM_HOST list-cluster-members

Then register that expected URL on any existing node of the cluster (if you don’t have a cluster yet, do this on the NetHSM that will serve as the initial node of the cluster).

nitropyREST API

választható opciók

Opció	Leírás
--url TEXT	Az új csomópont peer-URL-je (többször is beállítható)

érvek

Érv	Leírás
JOIN_DATA_PATH	Az a fájl elérési útja, amelybe az egyesített adatok kerülnek írásra

Példa

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

A parancs felsorolja a klaszter tagjait, és a fájlba írja azokat az adatokat, amelyekre az új csomópontnak szüksége van a klaszterhez való csatlakozáshoz (beleértve a csatlakozási csomagot is). Őrizze meg ezt a fájlt a következő lépéshez.

Megjegyzés

Notice in the list of members (learner: True in the nitropy output, "learner": true in the REST API response) that the new joiner is a „learner”: it can now connect to the cluster and receive data from it, but cannot participate until it is promoted, which will be covered below.

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 az összekapcsolási adatfájlt a következő lépéshez (vagy a választ, ha a REST API-t használta).

Joining the Cluster as a Learner

Csatlakozzon a klaszterhez azon a csomóponton, amely várhatóan csatlakozni fog, az előző lépésben kapott adatok és annak a csomópontnak a biztonsági jelszava segítségével, amelyen az új csatlakozót regisztrálták.

nitropyREST API

Szükséges opciók

Opció	Leírás
--backup-passphrase TEXT	Az új csatlakozó regisztrációjának helyszínéül szolgáló csomópont biztonsági jelszava

érvek

Érv	Leírás
JOIN_DATA_PATH	Az előző lépésben létrehozott csatlakozási adatfájl elérési útja

Példa

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

Figyelem

The join call (nitropy nethsm join-cluster or POST /cluster/join) will hang until the new node is manually promoted (see below). This is normal. When the call returns successfully, it indicates that join and promotion have been successful. Don’t cancel this join call.

Assuming both the cluster and the node can reach each other, this will enact the actual join, wiping the data on the new joiner to instead synchronize its state with that of the cluster. If this operation fails immediately (e.g. the cluster was not reachable or authentication failed), this node’s state will not be wiped and the join will be reverted. However as soon as a first join is successful, this operation is final and can only be reverted by a factory reset.

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

Promoting a node increases the cluster’s quorum threshold (refer to the API documentation and the Operational Redundancy section of this document). Ensure this new node has a stable connection to the cluster before promoting it.

Az új tagot a következőképpen próbálhatja meg előléptetni. A tag azonosítója a klaszter tagjainak felsorolásával deríthető ki.

nitropyREST API

érvek

Érv	Leírás
MEMBER_ID	The ID of the learner to be promoted

Példa

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

Ha a tanuló még nem érte utol a csoportot, akkor a művelet sikertelen lesz (412-es HTTP-kód a REST API-ban), és az áthelyezést később újra meg 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).

Keep the join data file written by nitropy nethsm add-cluster-member (or the response from the cluster, if you used the REST API): it contains the list of cluster members and a joiner kit (you won’t need this part).

Configure etcd

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,..."

Assuming the join data file written by nitropy (or the NetHSM REST API response) is stored in a response.json file, you can generate these last two variables automatically with the following jq expressions:

export ETCD_INITIAL_CLUSTER=$(jq --raw-output '[.members[] | ["\(if .name == "" then "witness1" else .name end)=\(.urls[])"]] | flatten | join(",")' < response.json)
export ETCD_INITIAL_ADVERTISE_PEER_URLS=$(jq --raw-output '.members[] | select(.name=="") | .urls | join(",")' < response.json)

For example with the example response provided in the Registering a New Node section, you will have:

ETCD_NAME="witness1"
ETCD_DATA_DIR="/var/etcd/data"
ETCD_INITIAL_CLUSTER="witness1=https://172.22.1.3:2380,9ZVNM2MNWP=https://172.22.1.2:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.22.1.3:2380"

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.

You first have to know the ID of the node you want to remove, by listing all nodes and looking for the right one. Then it can be removed. If the node in question was still healthy, this will isolate it from the rest of the cluster and transition it to the Failed state.

nitropyREST API

érvek

Érv	Leírás
MEMBER_ID	The ID of the node to be removed

Példa

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

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.

To help you understand which case your node is in, the diagnose function remains available and returns information about the current status of etcd and its database, including logs.

nitropyREST API

Példa

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

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.

• Isolate the node with nitropy nethsm force-new-cluster (REST API: POST /cluster/force-new), which will irreversibly forget all other cluster members, recover the etcd data present on disk and reboot. If the underlying failure was cluster-related, the node will follow the normal boot sequence and end up in either the Locked or Operational state depending on the unattended boot setting.

Megjegyzés

If a node is isolated with force-new, it will desynchronized with the cluster: any new writes on it or the cluster cannot be reconciled. The node can still rejoin the cluster but will lose all its local modifications.

The force-new operation, which is only available in the Failed state, requires authentication as it is potentially destructive. However since HSM users and roles are not available in that state, the endpoint expects HTTPS clients to always authenticate with the unlock fake user, and the latest known unlock passphrase as the password. With nitropy, pass them as --username unlock --password $UNLOCK_PASSPHRASE:

$ nitropy nethsm --host $NETHSM_HOST --username unlock --password $UNLOCK_PASSPHRASE force-new-cluster

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.