Clustering¶
Märkus
See funktsioon on praegu tehniline eelvaade, millel on järgmised ajutised piirangud:
Kui klastri kaotatakse (kvoorum on kadunud), on ainus taastamise vahend tehase lähtestamine + taastamine. Tehke kindlasti sageli varukoopiaid. Tulevased versioonid sisaldavad vahendeid plaadil olevate andmete taastamiseks.
Aktiivne/passiivne häälestus kahe sõlme klastrite toetamiseks, kas kasutades etcd Learnerit või Mirrorit, ei ole veel saadaval.
Süsteemiaeg sõlmede vahel tuleb esialgu käsitsi sünkroniseerida. Tulevane versioon sisaldab automaatset kellade sünkroniseerimist.
NetHSM alates versioonist 4.0 toetab klasterdamist, et sünkroonida andmeid otse mitme NetHSMi vahel. See toetab võtmete suure sagedusega genereerimist, tagab suure kättesaadavuse ja koormuse tasakaalustamise. NetHSM klastri aluseks on etcd, mis kasutab Raft konsensusalgoritmi tugeva järjepidevuse tagamiseks. See tagab, et andmed (nt võtmed) on kõikides NetHSMides alati õiged.
Enne NetHSM-klastri loomist tutvuge selle tehnoloogiaga ja selle piirangutega, et vältida juhuslikku katkestust ja andmekaotust. Lisaks käesolevale dokumendile võite tutvuda ka etcd dokumentatsiooniga.
Operational Redundancy¶
Nimetame „sõlme“ NetHSMi, mis peaks olema osa klastrist. Klaster, mis koosneb N sõlmedest, jätkab tööd seni, kuni vähemalt (N/2)+1 sõlmed on terved ja juurdepääsetavad. Seda minimaalset arvu terveid ja juurdepääsetavaid sõlmi nimetatakse kvoorumiks.
See eeldab järgmisi stsenaariume.
Üks sõlm läheb maha ja kvoorum on siiski saavutatud¶
Kui kolme sõlme klastris üks sõlm ei tööta (jookseb kokku või muutub võrgu tõttu kättesaamatuks), jätkavad kaks ülejäänud sõlme tööd ja teenindavad päringuid.
Kui rikutud sõlm on endiselt terve (nt oli tegemist lihtsalt võrguprobleemiga), on see isoleeritud olekus (isegi mitte ainult lugemiseks) kasutamiskõlbmatu.
Kui sõlmpunkt taastub, sünkroniseeritakse see puhtalt uuesti ülejäänud klastriga ja muutub taas töökõlblikuks, ilma et see kaotaks andmeid.
Kui see ei taastu kunagi, tuleb see klastrist eemaldada (vt järgmine punkt), tehasepuhastus teha ja läbida liitumisprotsess uuesti algusest peale.
Võrgustiku jagunemine toimub ja kvoorum on siiski saavutatud¶
See on lihtsalt eelmise stsenaariumi üldistus. Viie sõlme klastris, kus näiteks 3 sõlme on ühes füüsilises asukohas A ja 2 sõlme teises asukohas B, tähendaks A ja B isoleeriv võrguprobleem järgmist:
Asukohas A asuvad 3 sõlme täidavad kvoorumi (antud juhul 3), seega jätkavad nad tegevust.
Asukohas B asuvad 2 sõlme on mitte kvoorumi (ikka veel 3), seega lõpetavad nad tegevuse (isegi ainult lugemisega).
Kui võrguprobleem on lahendatud, ühendavad 2 sõlme puhtalt tagasi 3 ülejäänud sõlme.
Kvoorum on püsivalt kadunud¶
Rike, mille tõttu kõik klastri alamkogumid kaotavad kvoorumi, muudab klastri ja selle andmed täielikult kadunuks, kui rike ei ole kõrvaldatud. Sellisel juhul tuleb sõlmed tehases lähtestada ja taastada varukoopia.
See võib juhtuda näiteks siis, kui 2-sõlmelises klastris (kus kvoorum on 2) üks sõlme ebaõnnestub. Sellises olukorras ei saa ebaõnnestunud sõlme pärast seda klastrist puhtalt eemaldada, sest allesjäänud terve sõlme on juba töökõlbmatu, kuna see on kaotanud kvoorumi.
Seetõttu on soovitatav, et klastris oleks alati paaritu arv sõlmi ja et varundataks sageli.
Selgituseks: ajutiselt kvoorumi kaotamine (näiteks kui te taaskäivitate kõik klastri sõlmed koos või kui ajutine võrgurike isoleerib sõlmed) ei ole probleem: kui piisavalt palju sõlmi on uuesti ühendatud (ilma käsitsi uuesti liitumata), et saavutada kvoorum, jätkab klastri normaalset tööd. Ainult püsivad tõrked, näiteks võrgu jagunemine, võrgu valesti konfigureerimine, autentimisprobleemid või riistvararikked, nõuavad käsitsi tegutsemist.
Lisateavet leiate etcd’s KKK.
2-sõlme klastri¶
Kahe sõlme aktiivne/passiivne klaster ei ole veel toetatud ja see lisatakse tulevases versioonis. Soovitame kasutusele võtta kolmanda sõlme, kas kolmanda NetHSMi või etcd „tunnistaja“, mida võib kasutada ükskõik millisel hostil. Vt järgmist jaotist „Tunnistaja“.
Tunnistaja¶
Klasterdamise olemus koos etcd muudab selle usaldusväärsemaks, mida rohkem sõlmi on klastris. Nagu on selgitatud peatükis Operational Redundancy, peaks klastrites ideaalis olema vähemalt 3 sõlme, et oleks ruumi tõrgeteks, sest 2-sõlmeline klastri puhul läheb täielikult katki, kui ainult üks neist välja kukub.
Funktsiooni ülesehitus on aga selline, et te ei pea oma klastrisse lisama täielikku, tõelist NetHSM-seadet, et saavutada stabiilne sõlmede arv. Selle asemel võite ise juurutada ja lisada „tunnistaja“ sõlme. Selline sõlme on lihtsalt etcd instants, mis töötab teie valitud masinas (või konteineris) ja on ühendatud klastriga. Seda tunnustatakse klastri reaalsete seadmete poolt tavalise sõlmena ja see saab kõik andmed ja uuendused seadmetelt (kuid loomulikult ei saa te sellega teha mingeid HSM-operatsioone - ta ainult salvestab andmeid).
Security Considerations¶
Tunnistussõlm (või igaüks, kellel on sellele juurdepääs) omab otsest ligipääsu kõigi klastri sõlmede salvestussüsteemile (nt saab kõiki kirjeid ja vastavaid väärtusi välja lasta, kasutades etcdctl get "/" "0").
Siiski, välja arvatud konfiguratsiooniversioon (/config/version, mis peaks alati olema „1“), on rangelt kõik väärtused krüpteeritud (kas seadme võtmega sõlme-spetsiifiliste väärtuste puhul või domeeni võtmetega teiste puhul), mis tagab tundlike andmete konfidentsiaalsuse.
Pange aga tähele, et pahatahtlik sõlm võib:
kirjutada prügikasti mis tahes kirje väärtuseks poes, mis põhjustab sõlmedes selle dekrüpteerimise ebaõnnestumist (mis võib põhjustada mõne süsteemikande krahhi).
nimekirjakannete nimed, nagu kasutajad, nimeruumid ja võtmed, mida võite pidada tundlikuks.
Creating a Cluster¶
Iga klaster algab algselt ühest sõlmest. Uued sõlmed liituvad klastriga ükshaaval.
Preparing Nodes¶
Võrguliiklus sõlmede vahel on krüpteeritud ja autenditud nende TLS-sertifikaadi abil.
Kõik sõlmed, mis peaksid kuuluma samasse klastrisse, peavad esmalt paigaldama ühise sertifitseerimisasutuse (CA), mis võimaldab neil kontrollida, et teised sõlmed on seaduslikud.
Järgnevalt eeldame, et kõik sõlmed on äsja kasutusele võetud ja töökorras.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
CA loomine ja paigaldamine¶
Kasutajad peaksid looma CA oma vahenditega ja vastavalt oma tegevuspiirangutele, tagades, et see võimaldab vähemalt keyCertSign võtme kasutamist.
Näiteks saab minimaalse CA luua aadressiga 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
See CA tuleb nüüd paigaldada igasse sõlme.
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).
Märkus
Sõlmede nõuetekohaseks autentimiseks eeldab klastri taustsüsteem (etcd), et igal sõlmel on sertifikaat, mille SAN-väli (Subject Alt Names) on nõuetekohaselt täidetud. Eelkõige peavad sõlmede puhul, kuhu eeldatavasti jõutakse ainult nende IP-koodi kaudu, olema sertifikaadis nõuetekohane IP SAN. IP SANi saab CSRi jaoks taotleda, lisades nimedele eesliite „IP:“, nagu näiteks openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Arvestades saadud CSR-i (nimetame seda nethsm.csr), saame seejärel genereerida selle jaoks sertifikaadi, mis on valmis paigaldamiseks. Näiteks 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).
Lõpuks saab CA (CA.pem) nüüd paigaldada koos /config/tls/cluster-ca.pem lõpp-punktiga (vt API dokumentatsiooni). See on võimalik alles siis, kui paigaldatud TLS-sertifikaat on selle poolt allkirjastatud. Vastasel juhul lükatakse toiming tagasi.
Märkus
Seda protsessi tuleb korrata iga sõlme puhul.
Kellasünkroonimine¶
Veenduge, et igale sõlmpunktile on määratud täpne süsteemiaeg. Kui see pole nii, reguleerige nende kella kellad /config/time lõpp-punkti abil.
Adding a New Node¶
Sõlme lisamine klastrisse toimub kahes etapis:
registreerida lisamine klastrisse (ükskõik millise liikme kaudu)
ütle uuele sõlmpunktile, et ta liituks
Configure a Backup Passphrase¶
Kõigepealt veenduge, et sõlmes, mida kasutatakse uue liituja registreerimiseks, on konfigureeritud varusõnum (vt API dokumentatsiooni /config/backup-passphrase lõpp-punktis).
Uue sõlme registreerimine¶
Hoiatus
Sõlme registreerimine lisab kohe uue sõlme klastrisse, muutes kvoorumi künnist, isegi kui sõlme ei ole veel tegelikult liitunud. See võib muuta olemasolevad sõlmed kasutuskõlbmatuks, kuni uus sõlme on tegelikult liitunud. Vt API dokumentatsiooni ja käesoleva dokumendi jaotist Operational Redundancy.
Hoidke käepärast liituva sõlme IP-aadress. Selle sõlme täielik URL (ka peer URL ` etcd` terminoloogias) on https://<IP_of_node>:2380 (nt https://192.168.1.1:2380). Port peab olema 2380, seega tuleb tagada, et sõlmede vaheline tulemüür lubab TCP-liiklust sellel pordil.
Saate kontrollida, et URL on õige, kui kutsute GET /cluster/members sõlme, millega oodatakse liitumist. See peaks loetlema ainult ühe liikme: iseennast.
Seejärel registreerige see oodatav URL-koht klastri mis tahes olemasolevas sõlmes (kui teil ei ole veel klastrit, tehke seda NetHSM-is, mis on klastri algne sõlmpunkt). Selleks kasutatakse POST /cluster/members lõpp-punkti (vt API dokumentatsiooni), edastades sellele URL-i sisaldava JSON-korpuse.
Kui see õnnestub, tagastab see JSON-vormi:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
mis sisaldab teavet, mis on vajalik uue sõlme liitumiseks klastriga. Eelkõige loetletakse selles kõik klastri liikmed (kus tühja nimega liige on uus liituja). Samuti sisaldab see domeeni võtit, mis on krüpteeritud nii avamis- kui ka varusõnaga - seega peab varusõna olema eelnevalt konfigureeritud.
Hoidke see vastus järgmise sammu jaoks.
Tegelik liitumine klastriga¶
Võtke viimase sammu vastus ja lisage sellele backupPassphrase väli, mis sisaldab selle sõlme varupassi, kus uus liituja on registreeritud, ning edastage need andmed eeldatavalt liituva sõlme POST /cluster/join (vt API dokumentatsiooni) kutsele.
Eeldades, et nii klastri kui ka sõlme vahel on võimalik ühendust saavutada, toimub tegelik liitumine, kustutades uue liituja andmed, et sünkroniseerida tema olek klastri olekuga.
Sõltuvalt võrgu- ja klastritingimustest võib see toiming võtta aega mõnikümmend sekundit. Kui see operatsioon ebaõnnestub kohe (nt klastrile ei olnud võimalik ligi pääseda või autentimine ebaõnnestus), ei kustutata selle sõlme olekut ja liitumine tühistatakse. Kui aga esimene liitumine õnnestub, on see operatsioon lõplik ja seda saab tagasi võtta ainult tehasepuhastusega.
Kui see liitumine on edukas, satub sõlmpunkt olekusse Locked ja tuleb avada selle sõlmpunkti lukustussõnaga, mida kasutati registreerimiseks. Pärast seda saab avamisfraasi muuta (avamisfraasid jäävad sõlmede kaupa ja neid ei jagata sõlmede vahel).
Märkus
Kui klastri andmebaas on suur või kui klastris on palju tööd, võib uue liituja täieliku sünkroniseerimise jaoks kuluda aega, isegi kui liitumine on õnnestunud, kuid kui klastri andmebaas on suur või kui klastris on palju tööd, võib uue liituja täieliku sünkroniseerimise jaoks kuluda aega. Selle aja jooksul võivad kõik sõlmed (sealhulgas eelkõige uus liituja) olla vähem reageerivad või reageerimata. Eriti uus liituja võib alguses anda tagasi vigu, kui ta näiteks üritab seda lahti lukustada. Sellisel juhul andke sellele veidi aega ja proovige uuesti.
Adding a Witness Node¶
Prepare a Witness¶
Teil on vaja keskkonda, kus on olemas etcd v3.6, mille IPv4-aadress on (vähemalt) teie klastri teiste liikmete poolt kättesaadav. TCP-liiklus pordile 2380 ja sealt peab olema lubatud.
Looge tühi kataloog, kus etcd hakkab oma andmeid hoidma, ja kirjutage üles selle tee (me kasutame /var/etcd/data). Veenduge, et kasutajal, kes protsessi käivitab, on õigus lugeda ja kirjutada kataloogi.
Edastage masinale CA-sertifikaat, mida kasutatakse klastri sõlmede autentimiseks. Te peaksite olema selle loonud peatükis Creating and Installing a CA. Hoiustame selle aadressil /var/etcd/CA.pem.
Seejärel peate looma tunnistaja jaoks sertifikaadi ja allkirjastama selle CAga, et ta saaks suhelda oma eakaaslastega. Seda saab teha näiteks veebilehe openssl kaudu:
# 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
Salvesta saadud witness.key ja witness.pem ka /var/etcd.
Register Witness to Cluster¶
Järgige tavalisi juhiseid jaotisest Uue sõlme registreerimine, et anda olemasolevale klastrile märku uue liikme lisamisest antud URL-i(de)ga.
Kirjutage klastri vastus üles: see peaks sisaldama klastri liikmete nimekirja ja liitujate komplekti (seda osa ei ole vaja).
Configure etcd¶
Erinevalt NetHSMist, mis valivad endale automaatselt sõlme nime (kasutades seadme ID-d), peate te valima nime igale lisatavale tunnistajale, tagades, et nimed on unikaalsed. Järgnevates näidetes kasutame „witness1“.
Koos NetHSM-i vastusega tunnistajaks registreerimisele koostage vormimuutujad:
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,..."
Eeldades, et NetHSM-i vastus on salvestatud response.json failis, saate need kaks viimast muutujat automaatselt genereerida järgmiste jq väljenditega:
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)
Näiteks `jaotises „Uue sõlme registreerimine“ esitatud näidisvastus on järgmine:
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"
Lõpuks looge etcd.conf.yml fail, kasutades docs/etcd_witness.conf.template esitatud mallifaili:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
See peaks andma teile vormi faili:
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¶
Käivitage etcd oma eelistatud viisil (käsitsi, systemd teenus, konteiner jne), osutades sellele eelmises etapis loodud konfiguratsioonifaili:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Sa peaksid nägema, kuidas see käivitub, liitub klastriga ja jõuab andmetega järele. Mõne aja pärast peaksite saama kontrollida, et see on terve, kasutades klienti etcdctl:
etcdctl get /config/version
See võti peaks olema olemas ja sisaldama „1“.
Veenduge, et see protsess jätkab tööd, sest see on nüüd teie klastri korralik liige. Kui teil on vaja see välja lülitada, eemaldage see kõigepealt korralikult klastrist (vt spetsiaalset jaotist). Kui selle juurdepääsetav IP muutub, ajakohastage selle URL-aadressi klastrist.
Operating a Cluster¶
Varundamine ja taastamine¶
Varundamine toimib samamoodi nagu ilma klastrita ja seda saab taotleda klastri mis tahes sõlme kaudu. See varundab kogu klastri andmed, kaasa arvatud sõlme-spetsiifilised väljad (kuigi neid ignoreeritakse, kui varukoopia taastamine ei toimu mitteproviseeritud sõlmes).
Klastris tehtud varukoopia saab taastada samas klastris, isegi kui mõned sõlmed on vahepeal lisatud või eemaldatud. Sellised taastamised, mis on tehtud toimivates klastrites, ei mõjuta konfiguratsiooniväärtusi (ainult võtmed, kasutajad, nimeruumid), nagu mis tahes muu osaline taastamine.
Varukoopia taastamine mitteproviseeritud sõlmes taastab selle sõlme spetsiifilised väljad (nt võrgukonfiguratsioon, sertifikaadid jne), mida kasutati varukoopia loomiseks.
Suure varukoopia taastamine võib klastri mõneks ajaks üle koormata, samal ajal kui taastamist rakendav sõlme edastab muudatused teistele.
See toiming ühildub NetHSMi varasemate versioonidega tehtud varundustega.
Märkus
Teises sõlmes Z tehtud varukoopia taastamine sõlmes A erineva domeeni võtmega kirjutab A domeeni võtme korrektselt ümber, nagu varemgi. Kui aga A oli klastris koos sõlme Bga, muutub B töökõlbmatuks, sest Z domeeni võtit ei taastata Bs.
Teisisõnu, tehke taastamist ainult klastris, mille varukoopiad on tehtud samas klastris (kuigi jälle võivad sõlmed olla vahepeal eemaldatud või lisatud). Kui soovite taastada võõrast varukoopiat mõnes sõlmes, eemaldage see kõigepealt ohutult oma klastrist, seejärel tehke tehaseparandused ja taastage varukoopia.
Sõlme eemaldamine puhtalt¶
Niikaua kui klastri mingi osa vastab veel kvoorumile, saab mis tahes selle liikme abil eemaldada klastrist teise sõlme, olenemata sellest, kas see sõlm on juba kättesaamatu või eeldatavalt kättesaamatu.
Kõigepealt tuleb teada eemaldada soovitud sõlme ID, loetledes kõik sõlmed läbi GET /cluster/members ja otsides õige sõlme.
Seejärel saab selle eemaldada, kutsudes DELETE /cluster/members/<id>. Kui kõnealune sõlme oli veel terve, isoleerib see selle ülejäänud klastrist ja muudab selle töökõlbmatuks.
Software Updates in Clusters¶
Tulevased uuendused märgistatakse kui „cluster-safe“ (see peaks olema enamus) või „cluster-unsafe“.
Klasterkindlaid uuendusi saab rakendada klastrisse kuuluvatele sõlmedele, ilma neid eelnevalt klastrist eemaldamata. Kuid nagu kõigi operatsioonide puhul, peaksite tagama, et seda tehakse ühe sõlme kohta korraga ja klastris, kus sõlme eemaldamine ei lähe alla kvoorumi (nt kui uuendamine ebaõnnestub).
Klastrisse mittekuuluvaid uuendusi tuleb rakendada isoleeritud sõlmedele. Te peaksite klastri laiali lammutama (eemaldades sõlmed ükshaaval), lähtestama kõik sõlmed peale ühe, rakendama uuenduse igale sõlmpunktile, seejärel panema kõik lähtestatud sõlmed liituma allesjäänud sõlmedega.
Enne selliseid toiminguid tehke kindlasti varukoopia.
Olemasoleva klastri ümberkonfigureerimine¶
Changing the Cluster CA¶
Olemasolev klastri (kahe või enama sõlme) ei saa muuta oma klastri CA-d töö ajal. Kui teil on vaja seda sertifikaati muuta: valige üks sõlme, eemaldage kõik teised sõlmed, uuendage CA ja laske siis teistel liikmetel uuesti liituda.
Changing the Network Configuration of Nodes¶
Võrgukonfiguratsiooni muutmine (nt IP-aadressi muutmine) teavitab teisi sõlmi automaatselt uuendusest. Te peaksite siiski tagama, et te teete selliseid uuendusi korraga ainult ühes sõlmes ja klastris, kus selle sõlme kaotamine ei põhjusta kvoorumi kadumist.