Clustering¶
Piezīme
Pašlaik šī funkcija ir tehniska priekšskatīšana ar šādiem pagaidu ierobežojumiem:
Ja klasteris tiek zaudēts (tiek zaudēts kvorums), vienīgais atjaunošanas veids ir rūpnīcas atiestatīšana + atjaunošana. Pārliecinieties, ka bieži tiek veidotas dublējumkopijas. Nākamajās versijās tiks iekļauti līdzekļi datu atjaunošanai diskā.
Aktīvā/pasīvā konfigurācija divu mezglu klasteru atbalstam, izmantojot etcd Learner vai Mirror, vēl nav pieejama.
Sistēmas laiks starp mezgliem pagaidām jāsinhronizē manuāli. Nākamajā versijā tiks iekļauta automātiskā pulksteņa sinhronizācija.
NetHSM 4.0 un jaunākās versijas atbalsta klasterizāciju, lai sinhronizētu datus starp vairākiem NetHSM tieši. Tas nodrošina augstu atslēgu ģenerēšanas biežumu, augstu pieejamību un slodzes līdzsvarošanu. NetHSM klasteris ir balstīts uz etcd, kas izmanto Raft konsensa algoritmu, lai nodrošinātu stingru konsekvenci. Tas nodrošina, ka dati (piemēram, atslēgas) visos NetHSM vienmēr ir pareizi.
Pirms NetHSM klastera izveides iepazīstieties ar šo tehnoloģiju un tās ierobežojumiem, lai izvairītos no nejaušas darbības pārtraukšanas un datu zaudēšanas. Papildus šim dokumentam varat iepazīties arī ar etcd dokumentāciju.
Operational Redundancy¶
Mēs sauksim „mezglu“ par NetHSM, kas ir paredzēts kā klastera daļa. Klasteris no N mezgliem turpinās darboties, kamēr vismaz (N/2)+1 mezgli ir veseli un sasniedzami. Šo minimālo veselu un sasniedzamu mezglu skaitu sauc par kvorumu.
Tas nozīmē šādus scenārijus.
Viens mezgls nedarbojas, bet kvorums joprojām ir sasniegts¶
Trīs mezglu klasterī, ja viens mezgls nedarbojas (sabojājas vai kļūst nesasniedzams tīkla apstākļu dēļ), pārējie divi mezgli turpina darbu un apkalpo pieprasījumus.
Ja bojātais mezgls joprojām ir vesels (piemēram, tā bija tikai tīkla problēma), izolācijas laikā tas nedarbosies (pat ne tikai lasīšanai).
Tomēr, ja mezgls atgūsties, tas tiks tīri sinhronizēts ar pārējo klasteri un atkal darbosies, nezaudējot datus.
Ja tas neatjaunojas, tas ir jāizņem no klastera (skatīt nākamo sadaļu), jāatjauno rūpnīcas iestatījumi un atkal jāveic pievienošanās process no jauna.
Notiek tīkla sadalīšana un kvorums joprojām ir sasniegts¶
Tas ir tikai iepriekšējā scenārija vispārinājums. 5 mezglu klasterī, kurā, piemēram, 3 mezgli atrodas vienā fiziskā vietā A un 2 mezgli atrodas citā vietā B, tīkla problēma, izolējot A un B, nozīmētu, ka:
A atrašanās vietas 3 mezgli atbilst kvorumam (šajā gadījumā 3), tāpēc tie turpina darboties.
Divi mezgli B vietā neatbilst kvorumam (joprojām ir 3), tāpēc tie pārtrauks darboties (pat tikai lasīšanai).
Ja tīkla problēma ir atrisināta, 2 mezgli tīri tīri pievienosies pārējiem 3 mezgliem.
Kvorums ir ilgstoši zaudēts¶
Ja kļūmes dēļ visas kopas apakškopas zaudē kvorumu, kopa un tās dati tiek pilnībā zaudēti, ja vien kļūme netiek novērsta. Šādā gadījumā mezgli ir jāatjauno no rūpnīcas un jāatjauno rezerves kopija.
Tas var notikt, piemēram, ja 2 mezglu klasterī (kur kvorums ir 2) neizdodas viens mezgls. Šādā situācijā neizdevušos mezglu pēc tam nevar tīri noņemt no kopas, jo atlikušais veselais mezgls jau nedarbojas, jo ir zaudējis kvorumu.
Tāpēc ieteicams klasterī vienmēr izmantot nepāra mezglu skaitu un bieži veikt dublēšanu.
Lai būtu skaidrs, uz laiku kvoruma zaudēšana (piemēram, ja restartējat visus klastera mezglus kopā vai īslaicīga tīkla kļūme izolē mezglus) nav problēma: tiklīdz tiks savienots pietiekams skaits mezglu (bez nepieciešamības manuāli atkārtoti pieslēgties), lai sasniegtu kvorumu, klasteris atsāks normālu darbību. Tikai pastāvīgu kļūmju gadījumā, piemēram, tīkla sadalīšanas, tīkla nepareizas konfigurācijas, autentifikācijas problēmu vai aparatūras kļūmju gadījumā būs nepieciešama manuāla rīcība.
Lai iegūtu vairāk informācijas, skatiet etcd BIEŽĀK UZDOTIE JAUTĀJUMI.
2 mezglu klasteris¶
Divu mezglu aktīvā/pasīvā klastera darbība vēl nav atbalstīta, un tā tiks pievienota kādā no nākamajām versijām. Mēs iesakām ieviest trešo mezglu - vai nu trešo NetHSM, vai etcd „liecinieku“, ko var izmantot jebkurā datorā. Skatiet nākamo sadaļu „Liecinieks“.
Liecinieks¶
Klasterizācijas ar etcd raksturs padara to uzticamāku, jo vairāk mezglu ir klasterī. Kā paskaidrots `sadaļā par darbības dublēšanu `_, ideālā gadījumā klasteros jābūt vismaz 3 mezgliem, lai būtu vieta atteicei, jo 2 mezglu klasteris pilnībā sabojājas, ja sabojājas tikai viens.
Tomēr funkcija ir izstrādāta tā, ka klasterim nav nepieciešams pievienot pilnu, īstu NetHSM ierīci, lai sasniegtu stabilu mezglu skaitu. Tā vietā varat izvietot un pievienot „liecinieka“ mezglu pats. Šāds mezgls ir tikai etcd gadījums, kas darbojas jūsu izvēlētajā datorā (vai konteinerā) un ir savienots ar klasteri. Tas tiks atpazīts kā parasts mezgls no reālajām klastera ierīcēm un saņems visus datus un atjauninājumus no ierīcēm (bet, protams, ar to nevarēsiet veikt nekādas HSM operācijas - tas tikai glabā datus).
Security Considerations¶
Liecinieka mezglam (vai jebkurai citai personai, kam ir piekļuve šim mezglam) ir tieša piekļuve visu klastera mezglu datu glabāšanas sistēmai (piemēram, jūs varat izrakstīt visus ierakstus un atbilstošās vērtības, izmantojot etcdctl get "/" "0").
Tomēr, izņemot konfigurācijas versiju (/config/version, kurai vienmēr jābūt „1“), stingri visas vērtības ir šifrētas (vai nu ar ierīces atslēgu mezglam specifiskām vērtībām, vai ar domēna atslēgām citām vērtībām), tādējādi nodrošinot sensitīvu datu konfidencialitāti.
Tomēr ņemiet vērā, ka ļaunprātīgs mezgls var:
ierakstīt atkritumus kā vērtību jebkuram ierakstam krātuvē, kas izraisīs to, ka mezgliem neizdosies to atšifrēt (kas var izraisīt dažu sistēmas ierakstu avārijas).
saraksta ierakstu nosaukumi, piemēram, lietotāji, vārdu telpas un atslēgas, kurus varat uzskatīt par sensitīviem.
Creating a Cluster¶
Jebkurš klasteris sākotnēji tiks sākts ar vienu mezglu. Jauni mezgli klasterim pievienosies viens pēc otra.
Preparing Nodes¶
Tīkla datplūsma starp mezgliem tiek šifrēta un autentificēta, izmantojot to TLS sertifikātu.
Visiem mezgliem, kuriem paredzēts būt vienas kopas daļai, vispirms jāuzstāda kopīga sertifikātu iestāde (CA), kas ļaus tiem pārbaudīt, vai citi mezgli ir likumīgi.
Turpmāk mēs pieņemam, ka visi mezgli ir tikko nodrošināti un darbojas.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
CA izveide un instalēšana¶
Lietotājiem pašiem jāizveido CA, izmantojot savus līdzekļus un atbilstoši saviem darbības ierobežojumiem, pārliecinoties, ka tā ļauj izmantot vismaz keyCertSign atslēgu.
Piemēram, minimālo CA var izveidot, izmantojot 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
Tagad šī CA ir jāuzstāda katrā mezglā.
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).
Piezīme
Lai pareizi autentificētu mezglus, klasterizācijas backend (etcd) sagaida, ka katram mezglam ir sertifikāts ar pareizi aizpildītu lauku Subject Alt Names (SAN). Jo īpaši mezgliem, kurus paredzēts sasniegt tikai caur to IP, sertifikātā jābūt pareizi norādītam IP SAN. IP SAN var pieprasīt CSR, nosaukumiem pievienojot prefiksu „IP:“, piemēram, openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Ņemot vērā iegūto CSR (nosauksim to par nethsm.csr), mēs varam tam ģenerēt sertifikātu, kas ir gatavs instalēšanai. Piemēram, izmantojot 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).
Visbeidzot, CA (CA.pem) tagad var instalēt ar /config/tls/cluster-ca.pem galapunktu (skatiet API dokumentāciju). Tas ir iespējams tikai tad, kad instalētais TLS sertifikāts ir parakstīts. Pretējā gadījumā operācija tiks noraidīta.
Piezīme
Šis process ir jāatkārto katram mezglam.
Pulksteņa sinhronizācija¶
Pārliecinieties, ka katrā mezglā ir iestatīts precīzs sistēmas laiks. Ja tā nav, noregulējiet to pulksteņus, izmantojot /config/time galapunktu.
Adding a New Node¶
Mezgla pievienošana klasterim notiek divos soļos:
reģistrēt papildinājumu klasterī (ar jebkura tā dalībnieka starpniecību).
paziņot jaunajam mezglam, ka tam jāpievienojas
Configure a Backup Passphrase¶
Vispirms pārliecinieties, ka mezglā, kas tiks izmantots, lai reģistrētu jaunu savienotāju, ir konfigurēta rezerves parole (skatiet API dokumentāciju par /config/backup-passphrase galapunktu).
Jauna mezgla reģistrēšana¶
Brīdinājums
Reģistrējot mezglu, klasterī uzreiz tiek iekļauts jauns mezgls, mainot kvoruma slieksni, pat ja mezgls vēl nav pievienojies. Tādējādi esošie mezgli var nedarboties, līdz jaunais mezgls ir faktiski pievienojies. Skatiet API dokumentāciju un šī dokumenta sadaļu Operational Redundancy.
Turiet līdzi pievienojamā mezgla IP. Šī mezgla pilnais URL ( vienādranga URL terminoloģijā etcd) būs https://<IP_of_node>:2380 (piemēram, https://192.168.1.1:2380). Portam jābūt 2380, tāpēc pārliecinieties, vai ugunsmūris starp mezgliem atļauj TCP datplūsmu šajā portā.
Jūs varat vēlreiz pārbaudīt, vai URL ir pareizs, izsaucot GET /cluster/members uz mezgla, kuram paredzēts pievienoties. Šajā sarakstā jānorāda tikai viens loceklis: viņš pats.
Pēc tam reģistrējiet šo gaidīto URL jebkurā esošajā kopas mezglā (ja kopas vēl nav, veiciet to NetHSM, kas kalpos kā sākotnējais kopas mezgls). To veic, izmantojot POST /cluster/members galapunktu (skat. API dokumentāciju), nododot tam JSON ķermeni, kas satur URL.
Ja tas izdodas, tiek atgriezta veidlapas JSON struktūra:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
kurā ir informācija, kas nepieciešama, lai jaunais mezgls varētu pievienoties klasterim. Jo īpaši tajā ir uzskaitīti visi kopas locekļi (kur loceklis ar tukšu nosaukumu ir jaunais pievienošanās mezgls). Tajā ir arī domēna atslēga, kas šifrēta gan ar atbloķēšanas, gan dublēšanas paroli - tāpēc pirms tam jākonfigurē dublēšanas parole.
Saglabājiet šo atbildi nākamajam solim.
Faktiska pievienošanās klasterim¶
Paņemiet pēdējā soļa atbildi un pievienojiet tai backupPassphrase lauku, kas satur tā mezgla rezerves paroli, kurā reģistrēts jaunais pievienotājs, un nododiet šos datus izsaukumam uz POST /cluster/join (skatiet API dokumentāciju) mezglā, kuram paredzēts pievienoties.
Pieņemot, ka gan klasteris, gan mezgls var viens otru sasniegt, tiks īstenota faktiskā pievienošanās, dzēšot jaunā pievienojamā mezgla datus, lai tā vietā sinhronizētu tā stāvokli ar klastera stāvokli.
Atkarībā no tīkla un klastera apstākļiem šī darbība var aizņemt dažas desmit sekundes. Ja šī operācija neizdodas uzreiz (piemēram, klasteris nebija sasniedzams vai neizdevās autentifikācija), šī mezgla stāvoklis netiks izdzēsts un pievienošanās tiks atcelta. Tomēr, tiklīdz pirmā pievienošanās ir veiksmīga, šī operācija ir galīgā, un to var atcelt tikai ar rūpnīcas atiestatīšanu.
Ja šī savienošana ir veiksmīga, mezgls nonāk Locked stāvoklī, un tas ir jāatbloķē, izmantojot reģistrācijas brīdī izmantotā mezgla atbloķēšanas paroli. Pēc tam atbloķēšanas paroli var mainīt (atbloķēšanas paroles joprojām ir atkarīgas no konkrētā mezgla un netiek koplietotas starp mezgliem).
Piezīme
Pat pēc veiksmīgas pievienošanās, ja kopas datu bāze ir liela vai ja kopa ir aizņemta, var paiet zināms laiks, kamēr jaunais pievienotājs pilnībā sinhronizē savu stāvokli. Šajā laikā visi mezgli (tostarp jo īpaši jaunais pievienotājs) var būt mazāk atsaucīgi vai nereaģēt. Jo īpaši jaunais savienotājs var sākotnēji atgriezt kļūdas, piemēram, mēģinot to atbloķēt. Tādā gadījumā dodiet tam laiku un mēģiniet vēlreiz.
Adding a Witness Node¶
Prepare a Witness¶
Jums būs nepieciešama vide, kurā ir pieejama etcd v3.6 versija ar IPv4 adresi (vismaz), kas ir sasniedzama citiem klastera dalībniekiem. Ir jāatļauj TCP datplūsma uz un no 2380 porta.
Izveidojiet tukšu direktoriju, kurā etcd glabās datus, un ierakstiet tās ceļu (mēs izmantosim /var/etcd/data). Pārliecinieties, ka lietotājam, kas palaidīs procesu, ir tiesības lasīt un rakstīt šajā direktorijā.
Pārsūtiet uz mašīnu CA sertifikātu, kas tiek izmantots klastera mezglu autentifikācijai. Jums tas būtu bijis jāizveido CA izveides un instalēšanas sadaļas Creating and Installing a CA (CA izveidošana un instalēšana) sadaļā. Mēs to saglabāsim /var/etcd/CA.pem.
Pēc tam lieciniekam būs jāizveido sertifikāts un jāparaksta tas ar CA, lai tas varētu sazināties ar saviem kolēģiem. To var izdarīt, piemēram, izmantojot openssl:
# Create a key
$ openssl genrsa -out witness.key 2048
# Create a CSR with a SAN that corresponds to the witness's IP or hostname
$ openssl req -new -sha256 -key own.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=witness" \
-addext "subjectAltName=IP:172.22.1.3" --out witness.csr
# Sign it
$ openssl x509 -req -days 1825 -in witness.csr -CA CA.pem -copy_extensions copy \
-CAkey CA.key -out witness.pem -set_serial 01 -sha256
Iegūtos witness.key un witness.pem saglabājiet arī /var/etcd.
Register Witness to Cluster¶
Lai paziņotu esošajam klasterim par jauna locekļa pievienošanu ar norādīto(-ajiem) URL, izpildiet parastos norādījumus, kas sniegti sadaļā Jauna mezgla reģistrēšana.
Pierakstiet klastera atbildi: tajā jāietver klastera dalībnieku saraksts un savienotāju komplekts (šī daļa jums nebūs nepieciešama).
Configure etcd¶
Atšķirībā no NetHSM, kas automātiski izvēlas sev mezgla nosaukumu (izmantojot ierīces ID), jums ir jāizvēlas nosaukums katram pievienotajam lieciniekam, pārliecinoties, ka nosaukumi ir unikāli. Turpmākajos piemēros mēs izmantosim „witness1“.
Kopā ar NetHSM atbildi par liecinieka reģistrāciju sagatavojiet veidlapas mainīgos:
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,..."
Pieņemot, ka NetHSM atbilde ir saglabāta response.json failā, šos divus pēdējos mainīgos var ģenerēt automātiski, izmantojot šādas jq izteiksmes:
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)
Piemēram, izmantojot atbildes piemēru, kas sniegts Jaunu mezglu reģistrēšana sadaļā, jums būs:
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"
Visbeidzot, izveidojiet etcd.conf.yml failu, izmantojot docs/etcd_witness.conf.template šablona failu:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Pēc tam tiks iegūts veidlapas fails:
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¶
Palaidiet etcd vēlamajā veidā (manuāli, systemd servisu, konteineru utt.), norādot uz iepriekšējā solī izveidoto konfigurācijas failu:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Būtu jāredz, ka tas sāk darboties, pievienojas klasterim un sāk apstrādāt datus. Pēc kāda laika jums vajadzētu būt iespējai pārbaudīt, vai tas ir vesels, izmantojot etcdctl klientu:
etcdctl get /config/version
Šai atslēgai ir jābūt un tajā jābūt „1“.
Pārliecinieties, ka šis process turpina darboties, jo tagad tas ir pienācīgs klastera dalībnieks. Ja nepieciešams to izslēgt no darbības, vispirms to pienācīgi noņemiet no klastera (skatiet tam veltīto sadaļu). Ja mainās tā sasniedzamais IP, atjauniniet tā URL no klastera.
Operating a Cluster¶
Rezerves kopēšana un atjaunošana¶
Rezerves kopēšana darbojas tāpat kā bez klastera, un to var pieprasīt no jebkura klastera mezgla. Tā dublēs datus par visu klasteri, ieskaitot mezglam raksturīgos laukus (tomēr tie tiks ignorēti, ja vien dublējums netiks atjaunots neaizpildītā mezglā).
Kopas dublējumu var atjaunot tajā pašā kopā, pat ja kopš tā laika ir pievienoti vai noņemti daži mezgli. Šādi darbības klasteros veikti atjaunošanas darbi neietekmēs konfigurācijas vērtības (tikai atslēgas, lietotājus, nosaukumu telpas), tāpat kā jebkura cita daļēja atjaunošana.
Atjaunojot dublējumu neprovizētā mezglā, tiks atjaunoti mezglam raksturīgie lauki (piemēram, tīkla konfigurācija, sertifikāti u. c.) mezglā, kas tika izmantots dublējuma izveidei.
Lielas dublējuma kopijas atjaunošana uz kādu laiku var pārslogot kopu, kamēr mezgls, kas veic atjaunošanu, pārsūta izmaiņas pārējiem mezgliem.
Šī darbība ir saderīga ar iepriekšējās NetHSM versijās veiktajām dublējuma kopijām.
Piezīme
Atjaunojot mezglā A dublējumu, kas izveidots citā mezglā Z ar citu domēna atslēgu, A domēna atslēga tiks pareizi pārrakstīta kā iepriekš. Tomēr, ja A ir bijis klasterī ar mezglu B, B nedarbosies, jo B netiks atjaunota Z domēna atslēga.
Citiem vārdiem sakot, atjaunošanu veiciet tikai tajā klasterī, kura dublējumi veikti tajā pašā klasterī (lai gan arī šajā klasterī mezgli var būt noņemti vai pievienoti). Ja vēlaties atjaunot ārējo dublējumu kādā mezglā, vispirms droši noņemiet to no klastera, pēc tam atjaunojiet tā rūpnīcas iestatījumus un atjaunojiet dublējumu.
Tīra mezgla noņemšana¶
Kamēr kāda klastera daļa joprojām atbilst kvorumam, jebkuru tās locekli var izmantot, lai no klastera izslēgtu citu mezglu neatkarīgi no tā, vai šis mezgls jau nav sasniedzams, vai arī paredzams, ka tas būs.
Vispirms ir jāzina tā mezgla ID, kuru vēlaties noņemt, uzskaitot visus mezglus, izmantojot GET /cluster/members, un meklējot pareizo mezglu.
Pēc tam to var noņemt, izsaucot DELETE /cluster/members/<id>. Ja attiecīgais mezgls joprojām bija vesels, tas izolēs to no pārējās kopas un padarīs to nederīgu.
Software Updates in Clusters¶
Turpmākie atjauninājumi tiks atzīmēti kā „cluster-safe“ (tam vajadzētu būt vairākumam) vai „cluster-unsafe“.
Kopas drošus atjauninājumus var piemērot mezgliem, kas ir kopas daļa, pirms tam nenoņemot tos no kopas. Tomēr, tāpat kā visu citu darbību gadījumā, jums jānodrošina, ka tas tiek darīts pa vienam mezglam un klasterī, no kura noņemot mezglu, netiek samazināts kvorums (piemēram, ja atjauninājums neizdodas).
Kopas nedrošie atjauninājumi jāpiemēro izolētiem mezgliem. Jums ir jāizjauc klasteris (noņemot mezglus pa vienam), jāatjauno visi mezgli, izņemot vienu, jāpiemēro atjauninājums katram mezglam, pēc tam visiem atjauninātajiem mezgliem jāpievienojas atlikušajam mezglam.
Pirms šādu darbību veikšanas izveidojiet dublējuma kopiju.
Esoša klastera pārkonfigurēšana¶
Changing the Cluster CA¶
Esoša kopa (ar diviem vai vairāk mezgliem) nevar mainīt savu kopas CA darbības laikā. Ja nepieciešams mainīt šo sertifikātu: izvēlieties mezglu, noņemiet visus pārējos mezglus, atjauniniet CA un pēc tam palūdziet pārējiem dalībniekiem atkal pievienoties.
Changing the Network Configuration of Nodes¶
Mainot mezgla tīkla konfigurāciju (piemēram, mainot tā IP), par atjauninājumu automātiski tiek automātiski informēti pārējie mezgli. Tomēr jums jānodrošina, ka šādus atjauninājumus vienlaikus veicat tikai vienā mezglā un klasterī, kurā, zaudējot šo mezglu, netiks zaudēts kvorums.