Clustering

Muista

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.

• Sitä ei ole vielä testattu riittävän monessa tuotantokäytössä, ja siinä saattaa olla virheitä.

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.

Klusterissa, jossa raja-arvo alittuu (esimerkiksi verkko-ongelman vuoksi), johtajaa ei voida valita, ja kunkin solmun paikallinen instanssi etcd ei enää pysty suorittamaan luku- ja kirjoitustoimintoja. Tämä johtaa seuraaviin tilanteisiin.

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

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.

Jos laite ei palaudu, se on poistettava klusterista ` <clustering.html#removing-a-node-cleanly>` __ ja joko suoritettava palautus tietojen saamiseksi (mutta laite ei enää kuulu klusteriin) tai palautettava tehdasasetuksiin ja liitettävä klusteriin uudelleen alusta alkaen.

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.

• 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).

• Jos verkko-ongelma on ratkaistu, 2 solmua yhdistyy puhtaasti takaisin 3 muuhun solmuun.

Toisin sanoen pahimmassa mahdollisessa verkkojakautumistilanteessa (klusterissa, jossa solmujen lukumäärä on pariton) klusterin suurempi puoli pysyy toimintakunnossa, kun taas pienempi puoli on toimintakyvytön, kunnes jakautuminen on korjattu.

Päätösvalta on pysyvästi menetetty

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.

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

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.

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:

• 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ä jaetaan solmujen välillä

NetHSM-klusteri tarkoittaa, että suurin osa tiedoista on jaettu niiden välillä. Avainten, käyttäjien tai nimiavaruuksien lisääminen, muuttaminen tai poistaminen yhdessä solmussa heijastuu lopulta kaikkiin muihin solmuihin. Yleisesti ottaen mikä tahansa toiminto, joka muuttaa tilaa, muuttaa jokaisen solmun tilaa. Tämä koskee myös varmuuskopiointia palautusta, joka toimii normaalisti.

Seuraavissa jaksoissa kerrotaan yksityiskohtaisesti, mitkä tiedot ovat täysin paikallisia, mitkä tiedot tallennetaan jaettuun etcd -varastoon mutta pysyvät solmukohtaisina ja mitkä tiedot ovat täysin jaettuja solmujen välillä.

Ei tallennettu etcd:hen

Kunkin solmun laiteavain tallennetaan vain paikallisesti eikä sitä koskaan jaeta solmujen kesken.

Tallennettu etcd:hen, mutta solmukohtainen

Seuraavat tiedot on tallennettu osoitteeseen etcd kunkin solmun eri alueille. Se on siis jokaisen solmun käytettävissä mutta ei yhtenäinen solmujen välillä (jokaisella solmulla voi olla eri arvo tälle tiedolle).

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

Huomaa, että vaikka jokaisella solmulla on oma versionsa lukitusta toimialueen avaimesta (koska jokainen solmu lukitsee sen omalla laiteavaimella tai lukituksen avauslauseella), taustalla oleva toimialueen avain on jaettu solmujen kesken (jotta ne voivat käyttää yhteisiä HSM-tietojaan, kuten avaimia).

Tallennettu etcd:hen ja jaettu

Kaikki seuraavat tiedot tallennetaan osoitteeseen etcd globaalissa laajuudessa, joten ne ovat yhdenmukaisia kaikissa klusterin solmuissa:

HSM-tiedot:

• Keys

• Käyttäjät

• Nimiavaruudet

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

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

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.

Tätä varten luo ensin solmusta varmenteen allekirjoituspyyntö (CSR) kohdassa ” ” (TLS-varmenteen luominen) kuvatulla tavalla. Kun käytät nitropia -palvelua, tämä tehdään komennolla nitropy nethsm --host $NETHSM_HOST csr --api.

Muista

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

** ` käytä vaihtoehtoa ` , esim. ` `.–san –san ”IP:192.168.1.1”

Jos haluat käyttää julkista varmentajaa varmenteidesi allekirjoittamiseen, solmujesi on käytettävä julkisia IP-osoitteita. Tämä johtuu turvallisuusvaatimuksesta, joka kieltää julkista varmentajaa myöntämästä varmenteita, joiden IP-SAN-kentässä on yksityinen IP-osoite.

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

Asenna sitten saatu new_cert.pem kohdassa TLS-varmenne kuvatulla tavalla ( nitropia: nitropy nethsm --host $NETHSM_HOST set-certificate --api new_cert.pem).

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

Argumentit

Argumentti	Kuvaus
``FILENAME``FILENAMEFILENAME`	The path of the CA file

Esimerkki

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

Asennettu klusterin varmentaja voidaan hakea komennolla ` `` nitropy nethsm –host $NETHSM_HOST get-cluster-ca-certificate`.

Muista

Tämä prosessi on toistettava jokaisen solmun kohdalla.

Kellon synkronointi

Varmista, että jokaiselle solmulle on määritetty tarkka järjestelmäaika, mieluiten NTP/NTS:n avulla manuaalisen ajan asetuksen sijaan. Tämä voidaan tehdä Time ja NTS/NTP -asetusten avulla.

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. Kun se on saavuttanut muut, nosta solmu oppijasta täysivaltaiseksi jäseneksi

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.

Uuden solmun rekisteröinti

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.

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

Esimerkki

$ 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

Vaihtoehdot

Vaihtoehto	Kuvaus
--url TEXT	Uuden solmun vertais-URL (voidaan määrittää useita kertoja)

Argumentit

Argumentti	Kuvaus
JOIN_DATA_PATH	Tiedoston polku, johon yhdistämistiedot tallennetaan

Esimerkki

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

Komento luettelee klusterin jäsenet ja tallentaa tiedostoon tiedot, joita uusi solmu tarvitsee liittyäkseen klusteriin (mukaan lukien liittymispaketti). Säilytä tämä tiedosto seuraavaa vaihetta varten.

Muista

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.

Vaikka tämä ”oppijan” käsite tuo mukanaan ylimääräisen vaiheen (korottamisen), se mahdollistaa klusterin turvallisemman toiminnan, sillä uuden solmun mahdolliset ongelmat eivät voi aiheuttaa epävakautta koko klusterissa ennen sen korottamista.

Säilytä liitostiedosto seuraavaa vaihetta varten (tai vastaus, jos käytit REST-rajapintaa).

Joining the Cluster as a Learner

Liity klusteriin sillä solmulla, jonka on tarkoitus liittyä klusteriin, käyttäen edellisessä vaiheessa saatuja tietoja sekä sen solmun varasalasanaa, johon uusi liittymissolmu on rekisteröity.

nitropyREST API

Velvoittavat vaihtoehdot

Vaihtoehto	Kuvaus
--backup-passphrase TEXT	Sen solmun varmuuskoodi, johon uusi jäsen on rekisteröity

Argumentit

Argumentti	Kuvaus
JOIN_DATA_PATH	Edellisen vaiheen liitostiedoston polku

Esimerkki

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

Varoitus

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.

Tässä vaiheessa uusi solmu on liittynyt ” ”-oppijana -solmuksi: se synkronoi tietojaan klusterin kanssa, mutta ei ole vielä toimintakunnossa. Toisaalta tässä vaiheessa solmussa mahdollisesti ilmenevät ongelmat eivät aiheuta häiriöitä klusterille, minkä vuoksi tämä toimenpide on turvallinen.

Liittymisen viimeinen vaihe on uuden solmun nostaminen täysivaltaiseksi jäseneksi.

Promoting the New Learner

Verkko- ja klusteriolosuhteista riippuen voi kestää jonkin aikaa, ennen kuin uusi jäsen pääsee klusterin tasolle. Kun tämä on tapahtunut, se voidaan ylentää oppijajäsenestä täysjäseneksi.

Varoitus

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.

Voit yrittää ylentää uuden jäsenen seuraavasti. Jäsenen tunnus löytyy luettelemalla klusterin jäsenet.

nitropyREST API

Argumentit

Argumentti	Kuvaus
MEMBER_ID	The ID of the learner to be promoted

Esimerkki

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

Jos oppija ei ole vielä saavuttanut vaadittua tasoa, tämä epäonnistuu (HTTP-koodi 412 REST-rajapinnassa), ja etenemistä tulisi yrittää uudelleen myöhemmin.

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

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.

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.

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

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

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

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"

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 oppijana ja saada data kiinni.

Promote the Witness

Lopuksi, jonkin ajan kuluttua, noudata tavallisia ohjeita, jotka löytyvät sivustolta kohdasta ”Uuden oppijan ylentäminen”, todistajan ylentämiseksi. Jos tämä ei onnistu, yritä uudelleen myöhemmin.

After a successful promotion, you should be able to check that it is healthy with the etcdctl client:

etcdctl get /config/version

Tämän avaimen on oltava olemassa ja sen on sisällettävä ”1”.

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

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.

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

Argumentit

Argumentti	Kuvaus
MEMBER_ID	The ID of the node to be removed

Esimerkki

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

Muista

Myös solmu, joka on liittynyt klusteriin mutta jota ei ole vielä nostettu ylemmälle tasolle, voidaan poistaa turvallisesti tällä tavalla.

Recovering a Failed Node

Solmu, joka ilmoittaa tilasta ” ” (Vikaantunut), ei vastaa useimpiin normaaleihin toimintoihin. Se voidaan kuitenkin sammuttaa, käynnistää uudelleen, nollata , diagnosoida tai eristää ** .

Varoitus

-tilan (epäonnistunut), diagnose sekä force-new -toiminnot ovat käytettävissä vain versiosta 5.0 alkaen. Versiossa 4.0 solmu, jonka kvorum on menetetty, lakkaa vastaamasta kaikkiin pyyntöihin. Se on palautettava tehdasasetuksiin.

Yleisiä syitä sille, että solmu on tilassa ” ” ja ”Failed”, ovat muun muassa:

• Pysyvästi menetetty päätösvalta.

• Väliaikainen päätösvaltaisuuden menetys (esim. kun klusteriin lisätään toinen solmu, joka ei ole vielä liittynyt klusteriin).

• etcd on parhaillaan käynnistymässä uudelleen (esim. koska varmenteet ovat muuttuneet tai verkko on määritetty uudelleen).

• Klusteri on erittäin kovassa kuormituksessa (esim. kun palautetaan erittäin laaja varmuuskopio).

Syystä riippumatta NetHSM siirtyy tilaan ” Failed” ( ) vasta, kun se on yrittänyt tuloksetta muodostaa yhteyttä tietokantaansa vähintään yhden minuutin ajan. Tällä vältetään hyvin lyhyiden epävakaustilojen aiheuttamat virheelliset siirtymät.

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

Esimerkki

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

Muista

Jos ja kun tietokanta tulee jälleen käytettäväksi (esim. kvorum palautuu verkko-ongelman ratkeamisen seurauksena), NetHSM siirtyy automaattisesti tilasta ” Failed” edelliseen tilaansa (tai jatkaa normaalia käynnistysprosessia, jos se oli käynnistymässä) ilman, että manuaalisia toimia tarvitaan. Kestää enintään minuutin ongelman ratkaisun jälkeen, ennen kuin klusteri vakiintuu, HSM havaitsee ongelman ratkaisun ja vaihtaa tilaa.

Jos päätät, että vika on pysyvä (esim. kvorumin menetys ilman toivoa tilanteen korjaamisesta), voit joko:

• Palauta laite tehdasasetuksi -palvelun kautta, jolloin kaikki tiedot poistetaan, ja palauta varmuuskopio.

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

Muista

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

Varoitus

Kun päivitys tehdään versiosta < 5.0, päätepiste force-new palauttaa aina virheen ”Unauthorized”, ennen kuin HSM on avattu tai avaussalasana on vaihdettu vähintään kerran.

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