Clustering¶
Muista
Tämä ominaisuus on tällä hetkellä tekninen esikatselu, jossa on seuraavat väliaikaiset rajoitukset:
Jos klusteri katoaa (khorum katoaa), ainoa keino palautukseen on tehdasasetusten palautus + palautus. Varmista, että varmuuskopioidaan usein. Tulevat versiot sisältävät keinoja levyllä olevien tietojen palauttamiseen.
Aktiivinen/passiivinen asennus kahden solmun klustereiden tukemiseksi joko etcd Learnerin tai Mirrorin avulla ei ole vielä käytettävissä.
Solmujen välinen järjestelmäaika on toistaiseksi synkronoitava manuaalisesti. Tuleva versio sisältää automaattisen kellonajan synkronoinnin.
NetHSM 4.0:sta alkaen tukee klusterointia, jonka avulla tietoja voidaan synkronoida suoraan useiden NetHSM:ien välillä. Tämä tukee suurta avainten tuottamistiheyttä, toteuttaa korkean käytettävyyden ja kuorman tasapainottamisen. NetHSM-klusteri perustuu etcd:hen, joka käyttää Raft-konsensusalgoritmia vahvaan yhdenmukaisuuteen. Näin varmistetaan, että tiedot (esim. avaimet) ovat aina oikein kaikissa NetHSM:issä.
Ennen NetHSM-klusterin perustamista tutustu tähän tekniikkaan ja sen rajoituksiin, jotta vältät vahingossa tapahtuvan käyttökatkoksen ja tietojen menetyksen. Tämän asiakirjan lisäksi kannattaa tutustua myös etcd:n dokumentaatioon.
Operational Redundancy¶
Kutsumme solmuksi NetHSM:ää, jonka odotetaan olevan osa klusteria. **** ` N` -solmujen muodostama klusteri jatkaa toimintaansa niin kauan kuin vähintään (N/2)+1 -solmut ovat terveitä ja tavoitettavissa. Tätä terveiden ja tavoitettavissa olevien solmujen vähimmäismäärää kutsutaan koorumiksi.
Tämä merkitsee seuraavia skenaarioita.
Yksi solmu kaatuu ja päätösvaltaisuus saavutetaan silti¶
Kolmen solmun klusterissa, jos yksi solmu epäonnistuu (kaatuu tai ei ole tavoitettavissa verkko-olosuhteiden vuoksi), kaksi muuta solmua jatkavat toimintaansa ja palvelevat pyyntöjä.
Jos vikaantunut solmu on edelleen terve (esim. kyse oli vain verkko-ongelmasta), se on eristettynä toimintakyvytön (ei edes lukukäyttöön).
Jos solmu kuitenkin toipuu, se synkronoituu puhtaasti uudelleen klusterin muiden solmujen kanssa ja tulee jälleen toimintakuntoiseksi menettämättä tietoja.
Jos se ei koskaan toivu, se on poistettava klusterista (ks. seuraava jakso), palautettava tehdasasetukset ja aloitettava liittymisprosessi alusta.
Verkon jakaminen tapahtuu ja päätösvaltaisuus saavutetaan silti.¶
Tämä on vain edellisen skenaarion yleistys. Viiden solmun klusterissa, jossa esimerkiksi kolme solmua on yhdessä fyysisessä paikassa A ja kaksi solmua toisessa paikassa B, verkko-ongelma, joka eristää A:n ja B:n, tarkoittaisi seuraavaa:
Sijainnin A kolme solmua täyttävät päätösvaltaisuuden (tässä tapauksessa kolme), joten ne jatkavat toimintaansa.
Sijainnissa B olevat 2 solmua ovat **** eivät täytä päätösvaltaisuutta (edelleen 3), joten ne lopettavat toimintansa (jopa vain lukutoiminnolla).
Jos verkko-ongelma on ratkaistu, 2 solmua yhdistyy puhtaasti takaisin 3 muuhun solmuun.
Päätösvalta on pysyvästi menetetty¶
Vika, joka aiheuttaa sen, että kaikki klusterin osajoukot menettävät koorumin, johtaa klusterin ja sen tietojen täydelliseen katoamiseen, ellei vikaa korjata. Tällöin solmut on nollattava tehtaalla ja varmuuskopio on palautettava.
Näin voi tapahtua esimerkiksi, jos yksi solmu vikaantuu kahden solmun klusterissa (jossa päätösvaltaisuus on 2). Tässä tilanteessa vikaantunutta solmua ei voida jälkikäteen poistaa klusterista, koska jäljelle jäävä terve solmu on jo toimintakyvytön, koska se on menettänyt kvorumin.
Siksi on suositeltavaa, että klusterissa on aina pariton määrä solmuja ja että varmuuskopioita tehdään usein.
Selvyyden vuoksi mainittakoon, että tilapäinen khorumin menettäminen (esimerkiksi jos käynnistät kaikki klusterin solmut uudelleen yhdessä tai jos väliaikainen verkkovika eristää solmut) ei ole ongelma: kun tarpeeksi monta solmua on yhdistetty uudelleen (ilman manuaalista uudelleenliittämistä) khorumin saavuttamiseksi, klusteri jatkaa normaalia toimintaansa. Ainoastaan pysyvät viat, kuten verkon osiot, verkon virheelliset konfiguraatiot, todennusongelmat tai laitteistoviat, vaativat manuaalisia toimenpiteitä.
Lisätietoja on osoitteessa etcd:n FAQ-osiossa.
2 solmun klusteri¶
Kahden solmun aktiivinen/passiivinen klusteri ei ole vielä tuettu, ja se lisätään tulevassa versiossa. Suosittelemme, että otamme käyttöön kolmannen solmun, joko kolmannen NetHSM:n tai etcd:n ”todistajan”, jota voidaan käyttää millä tahansa isännällä. Katso seuraava jakso ”Todistaja”.
Todistaja¶
Klusterointi on sitä luotettavampaa, mitä enemmän solmuja klusterissa on. etcd. Kuten kohdassa Operational Redundancy selitetään, klustereissa olisi mieluiten oltava vähintään kolme solmua, jotta niissä olisi tilaa epäonnistua, sillä kahden solmun klusteri epäonnistuu kokonaan, jos vain yksi solmu epäonnistuu.
Ominaisuus on kuitenkin suunniteltu niin, että sinun ei tarvitse lisätä klusteriin kokonaista, oikeaa NetHSM-laitetta, jotta saavutetaan vakaa solmujen määrä. Sen sijaan voit itse ottaa käyttöön ja lisätä ”todistaja”-solmun. Tällainen solmu on vain etcd -ohjelman instanssi, joka toimii valitsemallasi koneella (tai kontissa) ja on liitetty klusteriin. Klusterin oikeat laitteet tunnistavat sen tavalliseksi solmuksi, ja se vastaanottaa kaikki tiedot ja päivitykset laitteilta (mutta et tietenkään voi suorittaa sillä mitään HSM-operaatioita - se vain tallentaa tietoja).
Security Considerations¶
Todistajasolmulla (tai kenellä tahansa, jolla on pääsy siihen) on suora pääsy klusterin kaikkien solmujen tallennustietoihin (voit esimerkiksi tyhjentää kaikki merkinnät ja vastaavat arvot komennolla etcdctl get "/" "0").
Lukuun ottamatta konfigurointiversiota (/config/version, jonka pitäisi aina olla ”1”), kaikki arvot on kuitenkin salattu (joko laiteavaimella solmukohtaisten arvojen osalta tai toimialueen avaimilla muiden arvojen osalta), mikä takaa arkaluonteisten tietojen luottamuksellisuuden.
Huomaa kuitenkin, että haitallinen solmu voi:
kirjoittaa roskaa minkä tahansa tallennuksen arvoksi, mikä aiheuttaa sen, että solmut eivät onnistu purkamaan sitä (mikä voi johtaa joidenkin järjestelmämerkintöjen kaatumisiin).
luettelon merkintöjen nimet, kuten käyttäjät, nimiavaruudet ja avaimet, joita voit pitää arkaluonteisina.
Creating a Cluster¶
Jokainen klusteri alkaa aluksi yhdestä solmusta. Uudet solmut liittyvät klusteriin yksi kerrallaan.
Preparing Nodes¶
Solmujen välinen verkkoliikenne salataan ja todennetaan niiden TLS-varmenteella.
Kaikkien solmujen, joiden odotetaan olevan osa samaa klusteria, on ensin asennettava yhteinen varmentaja, jonka avulla ne voivat tarkistaa, että muut solmut ovat laillisia.
Seuraavassa oletetaan, että kaikki solmut ovat juuri käyttöönotettuja ja toiminnassa.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
CA:n luominen ja asentaminen¶
Käyttäjien on luotava varmentaja omilla keinoillaan ja omien toimintarajoitustensa mukaisesti varmistaen, että se sallii vähintään keyCertSign avaimen käytön.
Minimaalinen CA voidaan luoda esimerkiksi komennolla 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
Tämä CA on nyt asennettava jokaiseen solmuun.
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).
Muista
Jotta solmut voidaan todentaa asianmukaisesti, klusteroinnin taustajärjestelmä (etcd) odottaa, että jokaisella solmulla on varmenne, jonka SAN-kenttä (Subject Alt Names) on täytetty oikein. Erityisesti solmujen, joiden odotetaan olevan tavoitettavissa vain IP-osoitteensa kautta, on oltava varmenteessa asianmukainen IP-SAN-kenttä. IP SAN:t voidaan pyytää CSR:ää varten lisäämällä nimiin ”IP:”, kuten osoitteessa openssl:
"subjectAltNames": [ "normalname.org", "IP:192.168.1.1" ]
Saadun CSR:n (kutsutaan sitä nethsm.csr) perusteella voimme luoda sille varmenteen, joka on valmis asennettavaksi. Esimerkiksi 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).
Lopuksi CA (CA.pem) voidaan nyt asentaa /config/tls/cluster-ca.pem -päätepisteen avulla (katso API-asiakirjat). Tämä on mahdollista vasta, kun asennettu TLS-varmenne on sen allekirjoittama. Muussa tapauksessa toimenpide hylätään.
Muista
Tämä prosessi on toistettava jokaisen solmun kohdalla.
Kellon synkronointi¶
Varmista, että jokaiselle solmulle on määritetty tarkka järjestelmäaika. Jos näin ei ole, säädä niiden kelloja /config/time -päätteellä.
Adding a New Node¶
Solmun lisääminen klusteriin tapahtuu kahdessa vaiheessa:
rekisteröidä lisäys klusteriin (minkä tahansa sen jäsenen kautta).
kerro uudelle solmulle liittymisestä
Configure a Backup Passphrase¶
Varmista ensin, että varasalasana on määritetty solmuun, jota käytetään uuden liittyjän rekisteröintiin (katso /config/backup-passphrase -päätepisteen API-dokumentaatio).
Uuden solmun rekisteröinti¶
Varoitus
Solmun rekisteröiminen tuo välittömästi uuden solmun klusteriin ja muuttaa päätösvaltaisuuskynnystä, vaikka solmu ei olisikaan vielä liittynyt. Tämä voi tehdä olemassa olevista solmuista toimintakyvyttömiä, kunnes uusi solmu on todella liittynyt. Katso API-asiakirjat ja Operational Redundancy tämän asiakirjan osassa.
Pidä käsillä sen solmun IP-osoite, joka liittyy. Kyseisen solmun täydellinen URL-osoite (kutsutaan myös vertaisverkko-osoitteeksi terminologiassa etcd) on https://<IP_of_node>:2380 (esim. https://192.168.1.1:2380). Portin on oltava 2380, joten varmista, että solmujen välinen palomuuri sallii TCP-liikenteen kyseiseen porttiin.
Voit tarkistaa, että URL-osoite on oikea, kutsumalla GET /cluster/members solmuun, johon odotetaan liittymistä. Tämän pitäisi listata vain yksi jäsen: itsensä.
Rekisteröi sitten odotettu URL-osoite mihin tahansa olemassa olevaan klusterin solmuun (jos sinulla ei vielä ole klusteria, tee tämä NetHSM:ssä, joka toimii klusterin ensimmäisenä solmuna). Tämä tehdään käyttämällä POST /cluster/members -päätepistettä (katso API-dokumentaatio) ja antamalla sille URL-osoitteen sisältävä JSON-runko.
Jos tämä onnistuu, se palauttaa lomakkeen JSON-rungon:
{
"members": [
{
"name": "",
"urls": [
"https://172.22.1.3:2380"
]
},
{
"name": "9ZVNM2MNWP",
"urls": [
"https://172.22.1.2:2380"
]
}
],
"joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}
joka sisältää tiedot, joita uusi solmu tarvitsee liittyäkseen klusteriin. Siinä luetellaan erityisesti kaikki klusterin jäsenet (jossa jäsen, jonka nimi on tyhjä, on uusi liittyjä). Se sisältää myös toimialueen avaimen, joka on salattu sekä avaus- että varmuuslausekkeella - joten varmuuslauseke on määritettävä aiemmin.
Säilytä vastaus seuraavaa vaihetta varten.
Varsinainen liittyminen klusteriin¶
Ota viimeisen vaiheen vastaus ja liitä siihen backupPassphrase -kenttä, joka sisältää sen solmun varmuuskopiointisalasanan, johon uusi liittyjä on rekisteröity, ja siirrä nämä tiedot kutsuun POST /cluster/join (katso API-asiakirjat) solmussa, johon liittyjän odotetaan liittyvän.
Olettaen, että sekä klusteri että solmu voivat tavoittaa toisensa, tämä toteuttaa varsinaisen liittymisen, pyyhkii uuden liittyjän tiedot ja synkronoi sen sijaan sen tilan klusterin tilan kanssa.
Verkko- ja klusteriolosuhteista riippuen tämä toimenpide voi kestää muutamia kymmeniä sekunteja. Jos operaatio epäonnistuu välittömästi (esim. klusteria ei saavuteta tai todennus epäonnistuu), solmun tilaa ei pyyhitä ja liittyminen peruutetaan. Kuitenkin heti kun ensimmäinen liittyminen onnistuu, tämä operaatio on lopullinen, ja se voidaan peruuttaa vain tehdasasetusten palauttamisella.
Jos liittyminen onnistuu, solmu päätyy tilaan Locked, ja sen lukitus on avattava rekisteröinnissä käytetyn solmun avaussalasanalla. Tämän jälkeen avaussalasana voidaan vaihtaa (avaussalasanat ovat solmukohtaisia, eikä niitä jaeta solmujen kesken).
Muista
Jos klusterin tietokanta on suuri tai klusteri on kiireinen, uuden liittyjän tilan täydellinen synkronointi voi kestää jonkin aikaa, vaikka liittyminen olisi onnistunut. Tuona aikana kaikki solmut (erityisesti uusi liittyjä) saattavat olla vähemmän tai ei ollenkaan reagoivia. Erityisesti uusi liittyjä voi aluksi palauttaa virheitä esimerkiksi yrittäessään avata lukitusta. Anna tällöin aikaa ja yritä uudelleen.
Adding a Witness Node¶
Prepare a Witness¶
Tarvitset ympäristön, jossa on saatavilla etcd v3.6 ja jossa on IPv4-osoite (vähintään), johon klusterin muut jäsenet voivat päästä. TCP-liikenne porttiin 2380 ja portista 2380 on sallittava.
Luo tyhjä hakemisto, johon etcd tallentaa tietonsa, ja kirjoita sen polku (me käytämme /var/etcd/data). Varmista, että prosessin käynnistävällä käyttäjällä on oikeudet lukea ja kirjoittaa hakemistoon.
Siirrä koneelle CA-varmenne, jota käytetään klusterin solmujen todennukseen. Sinun olisi pitänyt luoda sellainen kohdassa CA:n luominen ja asentaminen. Säilytämme sen osoitteessa /var/etcd/CA.pem.
Tämän jälkeen sinun on luotava todistajaa varten varmenne ja allekirjoitettava se varmentajan kanssa, jotta se voi kommunikoida vertaistensa kanssa. Tämä voidaan tehdä esimerkiksi osoitteessa 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
Tallenna tuloksena saadut witness.key ja witness.pem myös osoitteeseen /var/etcd.
Register Witness to Cluster¶
Noudata tavallisia ohjeita osiosta Registering a New Node (Uuden solmun rekisteröinti) antaaksesi olemassa olevalle klusterille signaalin uuden jäsenen lisäämisestä annetulla URL-osoitteella (URL-osoitteilla).
Kirjoita klusterin vastaus muistiin: sen pitäisi sisältää luettelo klusterin jäsenistä ja liitännäispaketti (et tarvitse tätä osaa).
Configure etcd¶
Toisin kuin NetHSM:t, jotka valitsevat solmun nimen itselleen automaattisesti (laitteen tunnuksen avulla), sinun on valittava nimi jokaiselle lisäämäsi todistajalle, varmistaen, että nimet ovat yksilöllisiä. Käytämme seuraavissa esimerkeissä nimeä ”witness1”.
Valmistele NetHSM:n vastauksen kanssa todistajan rekisteröintiä varten lomakkeen muuttujat:
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,..."
Jos oletetaan, että NetHSM-vastaus on tallennettu tiedostoon response.json, voit luoda nämä kaksi viimeistä muuttujaa automaattisesti seuraavilla jq lausekkeilla:
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)
Esimerkiksi kohdassa Registering a New Node annetun esimerkkivastauksen avulla saat seuraavanlaisen vastauksen:
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"
Luo lopuksi etcd.conf.yml-tiedosto käyttämällä docs/etcd_witness.conf.template-tiedostossa annettua mallitiedostoa:
$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml
Tämän pitäisi antaa tiedosto lomakkeesta:
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äynnistä etcd haluamallasi tavalla (manuaalisesti, systemd palveluna, säiliönä jne.) osoittamalla se edellisessä vaiheessa luotuun konfiguraatiotiedostoon:
$ cd /var/etcd
$ etcd --config-file witness.conf.yml
Sen pitäisi käynnistyä, liittyä klusteriin ja saada tiedot kiinni. Jonkin ajan kuluttua sinun pitäisi pystyä tarkistamaan, että se on kunnossa etcdctl -asiakasohjelmalla:
etcdctl get /config/version
Tämän avaimen on oltava olemassa ja sen on sisällettävä ”1”.
Varmista, että tämä prosessi on käynnissä, sillä se on nyt klusterin oikea jäsen. Jos sinun on poistettava se käytöstä, poista se ensin kunnolla klusterista (ks. oma osio). Jos sen tavoitettavissa oleva IP-osoite muuttuu, päivitä sen URL-osoite klusterista.
Operating a Cluster¶
Varmuuskopiointi ja palautus¶
Varmuuskopiointi toimii samalla tavalla kuin ilman klusteria, ja sitä voidaan pyytää mistä tahansa klusterin solmusta. Se varmuuskopioi koko klusterin tiedot, mukaan lukien solmukohtaiset kentät (vaikka niitä ei oteta huomioon, ellei varmuuskopiointia palauteta varaamattomaan solmuun).
Klusterissa tehty varmuuskopio voidaan palauttaa samassa klusterissa, vaikka joitakin solmuja olisi lisätty tai poistettu sen jälkeen. Tällaiset toiminnassa oleviin klustereihin tehdyt palautukset eivät vaikuta konfiguraatioarvoihin (vain avaimiin, käyttäjiin ja nimiavaruuksiin), kuten muutkaan osittaiset palautukset.
Varmuuskopion palauttaminen käyttöönottamattomaan solmuun palauttaa sen solmun solmukohtaiset kentät (kuten verkkokokoonpanon, varmenteet jne.), jota käytettiin varmuuskopion luomiseen.
Suuren varmuuskopion palauttaminen voi kuormittaa klusteria jonkin aikaa, kun palautusta suorittava solmu välittää muutoksia muille.
Tämä toiminto on yhteensopiva aiemmilla NetHSM-versioilla tehtyjen varmuuskopioiden kanssa.
Muista
Kun palautat solmuun A varmuuskopion, joka on tehty toisessa solmussa Z eri toimialueavaimella, A:n toimialueavain kirjoitetaan oikein uudelleen, kuten aiemmin. Jos A oli kuitenkin klusterissa solmun B kanssa, B:stä tulee toimintakyvytön, koska Z:n toimialueavainta ei palauteta B:hen.
Suorita palautus siis vain klusterissa, jonka varmuuskopiot on tehty samassa klusterissa (vaikka solmuja on saatettu poistaa tai lisätä sen jälkeen). Jos haluat palauttaa solmun vieraan varmuuskopion, poista se ensin turvallisesti klusterista, palauta se sitten tehdasasetuksiin ja palauta varmuuskopio.
Solmun poistaminen siististi¶
Niin kauan kuin jokin osa klusterista on vielä päätösvaltainen, mitä tahansa sen jäsentä voidaan käyttää toisen solmun poistamiseen klusterista, olipa tämä solmu jo saavuttamattomissa tai odotettavissa.
Sinun on ensin tiedettävä poistettavan solmun ID, listaamalla kaikki solmut osoitteessa GET /cluster/members ja etsimällä oikea solmu.
Sen jälkeen se voidaan poistaa kutsumalla DELETE /cluster/members/<id>. Jos kyseinen solmu oli vielä terve, tämä eristää sen muusta klusterista ja tekee siitä toimintakelvottoman.
Software Updates in Clusters¶
Tulevat päivitykset merkitään ”klusteriturvallisiksi” (tämän pitäisi olla suurin osa) tai ”klusteriturvattomiksi”.
Cluster-turvallisia päivityksiä voidaan soveltaa klusteriin kuuluviin solmuihin poistamatta niitä ensin klusterista. Kuten kaikkien muidenkin toimintojen kohdalla, sinun on kuitenkin varmistettava, että tämä tehdään yhdelle solmulle kerrallaan ja sellaisessa klusterissa, jossa solmun poistaminen ei alita päätösvaltaisuutta (esim. jos päivitys epäonnistuu).
Klusterin epävarmat päivitykset on tehtävä eristettyihin solmuihin. Sinun on purettava klusteri (poistamalla solmut yksi kerrallaan), palautettava kaikki solmut yhtä lukuun ottamatta tehdasasetuksiin, sovellettava päivitystä jokaiseen solmuun ja saatettava kaikki palautetut solmut liittymään jäljelle jääneeseen solmuun.
Varmista varmuuskopiointi ennen tällaisia toimintoja.
Olemassa olevan klusterin uudelleenkonfigurointi¶
Changing the Cluster CA¶
Olemassa oleva klusteri (jossa on kaksi tai useampi solmu) **** ei voi muuttaa klusterin CA:ta käytön aikana. Jos haluat muuttaa varmenteen: valitse yksi solmu, poista kaikki muut solmut, päivitä varmenteen varmentaja ja pyydä sitten muita jäseniä liittymään uudelleen.
Changing the Network Configuration of Nodes¶
Solmun verkkokonfiguraation muuttaminen (esim. sen IP-osoitteen muuttaminen) ilmoittaa päivityksestä automaattisesti muille solmuille. Sinun on kuitenkin varmistettava, että teet tällaisia päivityksiä vain yhdelle solmulle kerrallaan ja klusterissa, jossa solmun menettäminen ei aiheuta päätösvaltaisuuden menetystä.