Clustering¶
Megjegyzés
Ez a funkció jelenleg technikai előzetes, a következő ideiglenes korlátozásokkal:
Ha egy fürt elveszik (a quorum elveszik), a helyreállítás egyetlen módja a gyári visszaállítás + visszaállítás. Győződjön meg róla, hogy gyakran készít biztonsági mentést. A jövőbeli kiadások tartalmazni fognak eszközöket a lemezen lévő adatok helyreállítására.
A két csomópontos fürtök támogatására szolgáló aktív/passzív beállítás, akár az etcd Learner, akár a Mirror használatával, még nem érhető el.
A csomópontok közötti rendszeridőt egyelőre kézzel kell szinkronizálni. Egy jövőbeli kiadásban automatikus óra szinkronizálás is lesz.
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.
Ez a következő forgatókönyveket feltételezi.
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.
Ha a meghibásodott csomópont még mindig egészséges (pl. csak hálózati probléma volt), akkor az izolált állapotában működésképtelen lesz (még olvasásra sem).
Ha azonban a csomópont helyreáll, tisztán újraszinkronizálódik a fürt többi részével, és újra működőképessé válik, adatvesztés nélkül.
Ha nem áll helyre, akkor el kell távolítani a fürtből (lásd a következő szakaszt), vissza kell állítani a gyári állapotot, és újra kell kezdeni a csatlakozási folyamatot a nulláról.
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.
A B helyen lévő 2 csomópont nem a határozatképességnek (még mindig 3), így leállnak (még olvasásra is).
Ha a hálózati probléma megoldódik, a 2 csomópont tisztán visszacsatlakozik a 3 másikhoz.
A határozatképesség tartósan elveszett¶
Ha a fürt összes részhalmazának meghibásodása miatt a fürt és adatai teljesen elvesznek, kivéve, ha a hiba elhárításra kerül. Ebben az esetben a csomópontokat gyárilag vissza kell állítani, és vissza kell állítani a biztonsági másolatot.
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:
a tároló bármelyik bejegyzésének értékeként szemetet ír, ami a csomópontok számára sikertelen lesz a dekódolás (ami egyes rendszerbejegyzések esetében összeomláshoz vezethet).
listázza az olyan bejegyzések neveit, mint például a felhasználók, névterek és kulcsok, amelyeket érzékenynek tekinthet.
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
A csomópontok megfelelő hitelesítéséhez a fürtözési háttértár (etcd) elvárja, hogy minden csomópont rendelkezzen egy tanúsítvánnyal, amelynek megfelelően kitöltött SAN (Subject Alt Names) mezője van. Különösen azoknak a csomópontoknak, amelyek várhatóan csak az IP-címükön keresztül lesznek elérhetők, megfelelő IP SAN-t kell tartalmazniuk a tanúsítványukban. Az IP SAN-okat a CSR-hez úgy lehet kérni, hogy a nevekhez az „IP:” előtagot kell csatolni, mint a openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
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 róla, hogy minden csomópontot pontos rendszeridővel láttak el. Ha nem, állítsa be az óráikat a /config/time végponttal.
Adding a New Node¶
Egy csomópont hozzáadása egy fürthöz két lépésben történik:
regisztrálja a kiegészítést a fürtbe (bármelyik tagon keresztül)
mondja meg az új csomópontnak, hogy csatlakozzon
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¶
Figyelem
Egy csomópont regisztrálása azonnal új csomópontot hoz a fürtbe, módosítva a kvórum küszöbértékét, még akkor is, ha a csomópont még nem csatlakozott. Ez a meglévő csomópontokat működésképtelenné teheti, amíg az új csomópont ténylegesen csatlakozik. Lásd a API dokumentáció és a Operational Redundancy szakaszát.
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"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"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.
Tartsa meg ezt a választ a következő lépésre.
A klaszterhez való tényleges csatlakozás¶
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.
Feltételezve, hogy mind a fürt, mind a csomópont el tudja érni egymást, ez végrehajtja a tényleges csatlakozást, törölve az új csatlakozó adatait, hogy helyette szinkronizálja az állapotát a fürt állapotával.
A hálózat és a fürt körülményeitől függően ez a művelet néhány tucat másodpercet is igénybe vehet. Ha ez a művelet azonnal meghiúsul (pl. a fürt nem volt elérhető, vagy a hitelesítés sikertelen volt), a csomópont állapota nem törlődik, és a csatlakozás visszaáll. Amint azonban az első csatlakozás sikeres, ez a művelet végleges, és csak gyári visszaállítással lehet visszaállítani.
Ha ez a csatlakozás sikeres, a csomópont a Locked állapotba kerül, és a regisztrációhoz használt csomópont feloldási jelszavával kell feloldani. Ezt követően a feloldási jelszó megváltoztatható (a feloldási jelszavak csomópont-specifikusak maradnak, és nem oszthatók meg a csomópontok között).
Megjegyzés
Még a sikeres csatlakozás után is, ha a fürt adatbázisa nagy, vagy ha a fürt elfoglalt, az új csatlakozónak időbe telhet, amíg az állapotát teljesen szinkronizálja. Ez alatt az idő alatt az összes csomópont (beleértve különösen az új csatlakozót) kevésbé vagy egyáltalán nem reagálhat. Különösen az új csatlakozó kezdetben hibákat adhat vissza, amikor például megpróbálja feloldani a feloldást. Ebben az esetben adjon egy kis időt, és próbálja meg újra.
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.
Adja át a gépnek a fürt csomópontjainak hitelesítésére használt hitelesítésszolgáltatói tanúsítványt. Ezt a CA létrehozása és telepítése szakaszban kellett volna létrehoznia. Ezt a /var/etcd/CA.pem helyen fogjuk tárolni.
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¶
Kövesse a Új csomópont regisztrálása szakasz szokásos utasításait, hogy jelezze a meglévő fürtnek, hogy a megadott URL-cím(ek)kel új tagot vett fel.
Í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)
Például a Egy új csomópont regisztrálása szakaszban megadott példaválasz esetén a következő lesz:
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átnia kell, hogy elindul, csatlakozik a fürthöz és felzárkózik az adatokhoz. Egy idő után a etcdctl klienssel ellenőrizheted, hogy egészséges-e:
etcdctl get /config/version
Ennek a kulcsnak léteznie kell, és „1”-et kell tartalmaznia.
Győződjön meg róla, hogy ez a folyamat tovább fut, mivel most már a fürt megfelelő tagja. Ha le kell állítania, először megfelelően távolítsa el a fürtből (lásd a dedikált részt). Ha az elérhető IP címe megváltozik, frissítse az URL-címét a fürtből.
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.
Ezután a DELETE /cluster/members/<id> meghívásával távolítható el. Ha a kérdéses csomópont még egészséges volt, ez elszigeteli a fürt többi részétől, és működésképtelenné teszi.
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.