Clustering¶

Note

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.
Все още не е доказано чрез достатъчен брой внедрявания в производствена среда и е възможно да има грешки.

NetHSM от версия 4.0 нататък поддържа клъстериране за директно синхронизиране на данни между няколко NetHSM. Това поддържа висока честота на генериране на ключове, реализира висока наличност и балансиране на натоварването. Клъстерът на NetHSM се основава на etcd, който използва консенсусния алгоритъм Raft за силна съгласуваност. Това гарантира, че данните (напр. ключовете) са верни във всички NetHSM по всяко време.

Преди да настроите клъстер NetHSM, се запознайте с тази технология и нейните ограничения, за да избегнете случайно прекъсване и загуба на данни. В допълнение към този документ може да направите справка и с документацията на etcd.

Operational Redundancy¶

Ще наричаме „възел“ NetHSM, който се очаква да бъде част от клъстер. Един клъстер от N възли ще продължи да работи, докато поне (N/2)+1 възли са здрави и достъпни. Този минимален брой здрави и достижими възли се нарича кворум.

В клъстер, който падне под този праг (например поради проблем с мрежата), не може да бъде избран лидер и локалният екземпляр на etcd на всеки възел става неспособен да извършва операции за четене и запис. Това води до следните сценарии.

Един възел не работи, а кворумът все още е достигнат¶

В клъстер с три възела, ако един възел се повреди (срине се или стане недостъпен поради мрежови условия), другите два възела ще продължат да работят и да обслужват заявки.

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.

Ако устройството никога не се възстанови, то трябва да бъде премахнато ` <clustering.html#removing-a-node-cleanly>` __ от клъстера и или да премине през възстановяване, за да се получи достъп до данните му (но то вече няма да бъде част от клъстера), или да бъде върнато към фабричните настройки и да премине отново през процеса на присъединяване от самото начало.

Настъпва разделяне на мрежата и кворумът все още е достигнат¶

Това е просто обобщение на предишния сценарий. В клъстер с 5 възела, където например 3 възела са на едно физическо място А и 2 възела са на друго място В, мрежовият проблем, изолиращ А и В, би означавал следното:

Трите възела в местоположение А отговарят на кворума (3 в този случай), така че продължават да работят.
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).
Ако проблемът с мрежата е решен, двата възела ще се присъединят обратно към останалите три.

С други думи, при най-лошия възможен сценарий на разделяне на мрежата (в клъстер с нечетен брой възли) по-голямата половина от клъстера ще остане в изправно състояние, а по-малката половина ще бъде извън строя, докато разделянето не бъде отстранено.

Кворумът е трайно загубен¶

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.

Това може да се случи например при отказ на един възел в клъстер с два възела (където кворумът е 2). В тази ситуация отказалият възел не може да бъде отстранен от клъстера, тъй като останалият здрав възел вече не работи, тъй като е загубил кворум.

Ето защо се препоръчва винаги да имате нечетен брой възли в клъстера и често да правите резервни копия.

За да сме наясно, временно загубата на кворум (например ако рестартирате всички възли на клъстера заедно или временна повреда в мрежата изолира възлите) не е проблем: след като достатъчно възли се свържат отново (без да се налага ръчно повторно свързване), за да достигнат кворум, клъстерът ще възобнови нормалната си работа. Само при постоянни повреди, като например мрежови раздели, неправилна конфигурация на мрежата, проблеми с удостоверяването или хардуерни повреди, се изисква ръчно действие.

За повече информация вижте ЧЕСТО ЗАДАВАНИ ВЪПРОСИ на etcd.

Клъстер с 2 възела¶

Активен/пасивен клъстер с два възела все още не се поддържа и ще бъде добавен в бъдеща версия. Препоръчваме въвеждането на трети възел, или трети NetHSM, или „свидетел“ на etcd, който може да се използва на всеки хост. Вижте следващия раздел „Свидетел“.

Свидетел¶

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.

Въпреки това дизайнът на функцията е такъв, че не е необходимо да добавяте пълно, истинско устройство NetHSM към вашия клъстер, за да достигнете стабилен брой възли. Вместо това можете сами да разгърнете и добавите възел „свидетел“. Такъв възел е просто инстанция на etcd, работеща на избрана от вас машина (или в контейнер) и свързана с клъстера. Той ще бъде разпознат като нормален възел от реалните устройства в клъстера и ще получава всички данни и актуализации от устройствата (но, разбира се, няма да можете да извършвате никакви HSM операции с него - той само съхранява данни).

Security Considerations¶

Свидетелският възел (или всеки, който има достъп до него) има директен достъп до бекенда за съхранение на всички възли в клъстера (например можете да изведете всички записи и съответните стойности с etcdctl get "/" "0").

Въпреки това, с изключение на версията на конфигурацията (/config/version, която винаги трябва да бъде „1“), стриктно всички стойности са криптирани (или с ключ на устройството за стойности, специфични за възел, или с ключове на домейна за други), което гарантира поверителността на чувствителните данни.

Имайте предвид обаче, че злонамерен възел може да:

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.

Какво се споделя между възлите¶

Наличието на клъстер от NetHSM означава, че по-голямата част от данните се споделят между тях. Всяко добавяне, промяна или изтриване на ключове, потребители или пространства от имена в един възел в крайна сметка се отразява на всички останали. По принцип всяка операция, която променя състоянието, ще промени състоянието на всеки възел. Това включва операцията за архивиране възстановяване, която работи по нормален начин.

В следващите раздели е описано подробно кои данни са изцяло локални, кои данни се съхраняват в споделеното хранилище etcd, но остават специфични за всеки възел, и кои данни са изцяло споделени между възлите.

Не се съхранява в etcd¶

Ключът на устройството **** на всеки възел се съхранява само локално и никога не се споделя между възлите.

Съхраняват се в etcd, но са специфични за възела¶

Следните данни се съхраняват в etcd в различни обхвати за всеки възел. Следователно тя е достъпна за всеки възел, но не е еднаква за всички възли (всеки възел може да има различна стойност за тези данни).

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

Обърнете внимание, че макар всеки възел да има своя собствена версия на заключения ключ на домейна (защото всеки възел го заключва със своя ключ на устройството или парола за отключване), основният ключ на домейна е споделен между възлите (за достъп до техните споделени HSM данни, като например ключове).

Съхранява се в etcd и е споделено¶

Всички изброени по-долу данни се съхраняват в etcd в глобалния обхват, така че са еднакви за всички възли на клъстера:

Данни за HSM:

Keys
Потребители
Пространства от имена

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¶

Първоначално всеки клъстер ще започне от един възел. Нови възли се присъединяват към клъстера един по един.

Preparing Nodes¶

Мрежовият трафик между възлите се криптира и удостоверява с помощта на техния TLS сертификат.

Всички възли, които се очаква да бъдат част от един и същ клъстер, трябва първо да инсталират общ удостоверяващ орган (CA), който ще им позволи да проверяват дали другите възли са легитимни.

По-долу приемаме, че всички възли са прясно осигурени и функционират.

Networking¶

Nodes must first be reconfigured with their expected final network configuration as described in the section Network.

Създаване и инсталиране на CA¶

Потребителите трябва да създадат УО със собствени средства и в съответствие със собствените си оперативни ограничения, като се уверят, че той позволява поне използването на keyCertSign ключ.

Например минимален CA може да бъде създаден с 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

Сега този CA трябва да бъде инсталиран на всеки възел.

За да направите това, първо генерирайте заявка за подписване на сертификат (CSR) от възела, както е описано в раздела „ “ TLS Certificate. С nitropy това се извършва с nitropy nethsm --host $NETHSM_HOST csr --api.

Note

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

При нитропия използвайте опцията --san, например --san "IP:192.168.1.1".

Ако искате да използвате публичен сертификационен център (CA) за подписване на вашите сертификати, вашите възли трябва да използват публични IP адреси. Това се дължи на изискване за сигурност, което забранява на публичния сертификационен център да издава сертификати с частен IP адрес в полето „IP SAN“.

Като имаме получения CSR (нека го наречем nethsm.csr), можем да генерираме сертификат за него, готов за инсталиране. Например с 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

След това инсталирайте получения файл new_cert.pem, както е описано в раздела TLS Certificate (с нитропия: 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.

Аргументи

Аргумент	Описание
`FILENAME`	The path of the CA file

Пример

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

Инсталираният кластер на сертификационния орган може да бъде извлечен с командата „ nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate“.

Note

Този процес трябва да се повтори за всеки възел.

Синхронизация на часовника¶

Уверете се, че на всеки възел е зададено точно системно време – в идеалния случай чрез NTP/NTS, а не чрез ръчна настройка. Това може да се направи чрез конфигурацията на Time и NTS/NTP.

Adding a New Node¶

Adding a node to a cluster is done in three steps:

Register the addition to the cluster (through any one of its members)
Tell the new node to join
След като навакса, повишете статуса на възла от „ученик“ до „пълноправен член“

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.

Регистриране на нов възел¶

Имайте под ръка IP адреса на възела, който ще се присъедини. Пълният URL адрес (наричан също peer URL адрес в терминологията etcd) на този възел ще бъде https://<IP_of_node>:2380 (например https://192.168.1.1:2380). Портът трябва да бъде 2380, така че се уверете, че всяка защитна стена между възлите ще позволява TCP трафик на този порт.

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.

Пример

$ nitropy nethsm --host $NETHSM_HOST list-cluster-members

Call GET /cluster/members (refer to the API documentation).

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

Възможни опции

Опция	Описание
`--url` `TEXT`	URL адресът на връстника на новия възел (може да се зададе няколко пъти)

Аргументи

Аргумент	Описание
`JOIN_DATA_PATH`	Пътят към файла, в който се записват данните от обединяването

Пример

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

Командата извежда списък с членовете на клъстера и записва във файла данните, необходими на новия възел, за да се присъедини към клъстера (включително комплекта за присъединяване). Запазете този файл за следващата стъпка.

Call the POST /cluster/members endpoint (refer to the API documentation), passing it a JSON body containing the URL.

A successful call returns a JSON body of the form:

{
  "members": [
    {
      "name": "",
      "urls": [
        "https://172.22.1.3:2380"
      ],
      "learner": true
    },
    {
      "name": "9ZVNM2MNWP",
      "urls": [
        "https://172.22.1.2:2380"
      ],
      "learner": false
    }
  ],
  "joinerKit": "eyJiYWNrdXBfc2FsdCI6IkVlUzNPOEhHSEc5NnlNRktrdG1NZmc9PSIsInVubG9ja19zYWx0IjoiU3phMkEvYW13NlhxVWsrdHZMMmFubm5SZFlWd2ZQUjdpZ3IxK1RSdTdVaU14dmh3d0x2NWIvYVNkY2c9IiwibG9ja2VkX2RvbWFpbl9rZXkiOiIyMnNGVlkyelhQUVZ6S1pQenI3MmkwTk1WM3lmQ2k5dGwzeDhUbGtuOXM0WjFOd3JoZkRQTFZIVHp1WVl0YkQxaVZCMlovV3JHUHJlMXlwN0t4U0w4WkxjY2ZUTmUzcFg0WXE4YXNlY0wwREhXNGlIaXlPMlZnPT0ifQ=="
}

която съдържа необходимата информация за присъединяването на новия възел към клъстера. По-специално, в него се изброяват всички членове на клъстера (където членът с празно име е новият присъединяващ се). Той съдържа и ключа на домейна, криптиран с паролата за отключване и паролата за резервно копие - така че преди това трябва да е била конфигурирана парола за резервно копие.

Note

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.

Макар че тази концепция за „ученик“ добавя допълнителна стъпка (повишаване), тя осигурява по-безопасна работа на клъстера, тъй като евентуален проблем с новия възел не може да доведе до нестабилност в целия клъстер преди повишаването му.

Запазете файла с данните от съединяването за следващата стъпка (или отговора, ако сте използвали REST API).

Joining the Cluster as a Learner¶

Присъединете се към клъстера на възла, който се очаква да се присъедини, като използвате данните от последната стъпка и резервната парола на възла, на който е регистриран новият участник.

Задължителни опции

Опция	Описание
`--backup-passphrase` `TEXT`	Резервната парола на възела, на който е регистриран новият участник

Аргументи

Аргумент	Описание
`JOIN_DATA_PATH`	Пътят към файла с данни за обединяване от последната стъпка

Пример

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

Take the response from the last step and append to it a backupPassphrase field containing the backup passphrase, and pass that data to a call to POST /cluster/join (refer to the API documentation).

Warning

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.

На този етап новият възел се е присъединил като възел от типа „ “ ( ): той се синхронизира с клъстера, но все още не е готов за работа. От друга страна, евентуален проблем с възела на този етап няма да доведе до проблеми за клъстера, което прави тази операция безопасна.

Последната стъпка за завършване на присъединяването е новият възел да бъде повишен в пълноправен член.

Promoting the New Learner¶

В зависимост от състоянието на мрежата и клъстера, може да отнеме известно време, докато новият член се синхронизира с клъстера. След като това стане, той може да бъде повишен от статут на „ученик“ до пълноправен член.

Warning

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.

Можете да опитате да повишите новия член по следния начин. Идентификационният номер на члена може да бъде намерен чрез извеждане на списък с членовете на клъстера.

Аргументи

Аргумент	Описание
`MEMBER_ID`	The ID of the learner to be promoted

Пример

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

Call POST /cluster/members/{MemberID}/promote (refer to the API documentation).

Ако обучаемият все още не е наваксал, операцията ще се провали (HTTP код 412 в REST API) и преминаването към следващото ниво трябва да се опита отново по-късно.

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¶

Ще ви е необходима среда с налична версия etcd v3.6, с IPv4 адрес (поне), който да е достъпен за другите членове на вашия клъстер. Трябва да бъде разрешен TCP трафикът към и от порт 2380.

Създайте празна директория, в която etcd ще съхранява данните си, и запишете пътя до нея (ние ще използваме /var/etcd/data). Уверете се, че потребителят, който ще стартира процеса, има право да чете и записва в директорията.

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.

След това ще трябва да създадете сертификат за свидетеля и да го подпишете с удостоверяващия орган, за да може той да комуникира със своите колеги. Това може да се направи например чрез 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

Съхранявайте получените witness.key и witness.pem и в /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¶

За разлика от NetHSM, които автоматично избират име на възел за себе си (като използват идентификатора на устройството), трябва да изберете име за всеки добавен свидетел, като се уверите, че имената са уникални. В следващите примери ще използваме „свидетел1“.

С отговора на NetHSM за регистриране на свидетеля подгответе променливи на формуляра:

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"

Накрая създайте файл etcd.conf.yml, като използвате файла-шаблон, предоставен в docs/etcd_witness.conf.template:

$ envsubst < NETHSM_ROOT/docs/etcd_witness.conf.template > /var/etcd/witness.conf.yml
$ cat witness.conf.yml

Това ще ви даде файл с формата:

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¶

Стартирайте etcd по предпочитания от вас начин (ръчно, systemd услуга, контейнер и т.н.), като го насочите към конфигурационния файл, създаден в предишната стъпка:

$ cd /var/etcd
$ etcd --config-file witness.conf.yml

Трябва да видите как започва, да се присъедините към клъстера като „ученик“ и да се синхронизирате с данните.

Promote the Witness¶

Накрая, след като измине известно време, следвайте обичайните инструкции от раздела „Насърчаване на новия обучаем“ <clustering.html#promoting-the-new-learner>` __ на сайта `, за да насърчите свидетеля. Ако това не даде резултат, опитайте отново по-късно.

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

etcdctl get /config/version

Този ключ трябва да съществува и да съдържа „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¶

Архивиране и възстановяване¶

Операцията за архивиране работи по същия начин, както без клъстер, и може да бъде заявена от всеки възел на клъстера. Тя ще архивира данните за целия клъстер, включително полетата, специфични за възела (въпреки че те ще бъдат пренебрегнати, освен ако не възстановите резервното копие на невъведен възел).

Резервно копие, направено на клъстер, може да бъде възстановено на същия клъстер, дори ако някои възли са били добавени или премахнати след това. Такива възстановявания, извършени на оперативни клъстери, няма да засегнат стойностите на конфигурацията (само ключове, потребители, пространства от имена), както всяко друго частично възстановяване.

Възстановяването на резервно копие на възел, който не е предоставен, ще възстанови специфичните за възела полета (като мрежова конфигурация, сертификати и др.) на възела, който е използван за създаване на резервното копие.

Възстановяването на голямо резервно копие може да претовари клъстера за известно време, докато възелът, който прилага възстановяването, препраща промените към останалите.

Тази операция остава съвместима с резервни копия, направени с предишни версии на NetHSM.

Note

Възстановяването във възел A на резервно копие, направено в друг възел Z с различен ключ на домейна, ще презапише правилно ключа на домейна на A, както преди. Ако обаче A е бил в клъстер с възел B, B ще стане неработещ, тъй като ключът на домейна Z няма да бъде възстановен на B.

С други думи, възстановявайте само в клъстер, чиито резервни копия са направени в същия клъстер (въпреки че оттогава възлите може да са били премахнати или добавени). Ако искате да възстановите чуждо резервно копие на даден възел, първо го премахнете безопасно от неговия клъстер, след това го нулирайте фабрично и възстановете резервното копие.

Чисто премахване на възел¶

Докато част от клъстера все още отговаря на кворума, всеки от неговите членове може да бъде използван за отстраняване на друг възел от клъстера, независимо дали този възел вече е недостъпен, или се очаква да бъде.

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.

Аргументи

Аргумент	Описание
`MEMBER_ID`	The ID of the node to be removed

Пример

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

Note

Възел, който се е присъединил към клъстера, но все още не е бил повишен в ранг, също може безопасно да бъде премахнат по този начин.

Recovering a Failed Node¶

Възел, който съобщава състоянието „ Failed“ ( се провали), ще откаже да отговори на повечето обичайни операции. Все пак той може да бъде изключен, рестартиран, нулиран, диагностициран или изолиран.

Warning

Наличието на състоянието „ “ (Неуспешен ), както и операциите diagnose и force-new, важи само за версия 5.0 и по-новите версии. В версия 4.0 възел с изгубено кворум ще спре да отговаря на всички заявки all. Той трябва да бъде възстановен към фабричните настройки.

Честите причини, поради които даден възел може да се намира в състоянието „ “ с грешка „ “, включват:

Трайно загуба на кворум.
Временно загубено кворум (например, когато се добавя втори възел към клъстера, а вторият възел все още не се е присъединил).
etcd в момента се рестартира (например защото сертификатите са се променили или мрежата е била преконфигурирана).
Клъстерът е подложен на изключително голямо натоварване (например по време на възстановяване на много голям архив).

Независимо от причината, NetHSM ще премине в състоянието „ Failed“ ( ) едва след не по-малко от една пълна минута неуспешни опити за взаимодействие с базата данни. Това се прави, за да се избегнат неоснователни преходи, причинени от много кратки периоди на нестабилност.

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.

Пример

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

Note

Ако и когато базата данни отново стане достъпна (например, кворумът бъде възстановен, защото проблемът с мрежата е решен), NetHSM автоматично ще премине от състоянието „ Failed“ към състоянието, в което се е намирал преди това (или ще възобнови нормалната последователност на зареждане, ако е бил в процес на зареждане), без да е необходимо каквото и да е ръчно действие. След като проблемът бъде отстранен, ще отнеме до една минута, докато клъстерът се стабилизира, HSM засече, че проблемът е отстранен, и промени състоянието си.

Ако стигнете до заключението, че неизправността е трайна (например загуба на кворум, без надежда за разрешаване на основния проблем), можете да:

Възстановете фабричните настройки на устройството, което ще изтрие всички данни, и възстановете резервно копие.
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.

Note

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

Warning

След актуализация от версия < 5.0 крайната точка „ ` “ force-new` винаги ще показва състоянието „Unauthorized“, докато HSM не бъде отключен или паролата за отключване не бъде променена поне веднъж.

Software Updates in Clusters¶

Бъдещите актуализации ще бъдат маркирани като „безопасни за клъстера“ (това трябва да е мнозинството) или „опасни за клъстера“.

Актуализациите, защитени от клъстери, могат да бъдат прилагани към възли, които са част от клъстер, без те да бъдат премахвани от клъстера. Въпреки това, както при всички операции, трябва да се уверите, че това се прави на един възел в даден момент и в клъстер, в който премахването на възел не води до намаляване на кворума (напр. ако актуализацията се провали).

Актуализациите, които не са безопасни за клъстера, трябва да се прилагат към изолирани възли. Трябва да разглобите клъстера (като премахвате възлите един по един), да възстановите фабричните настройки на всички възли с изключение на един, да приложите актуализацията на всеки възел, след което да накарате всички възли да се присъединят към останалия възел.

Не забравяйте да направите резервно копие преди такива операции.

Преконфигуриране на съществуващ клъстер¶

Changing the Cluster CA¶

Съществуващ клъстер (с два или повече възела) не може да промени своя CA на клъстера по време на работа. Ако трябва да промените този сертификат: изберете възел, премахнете всички останали възли, актуализирайте CA, след което накарайте останалите членове да се присъединят отново.

Changing the Network Configuration of Nodes¶

Промяната на мрежовата конфигурация на даден възел (например промяна на неговия IP адрес) автоматично информира останалите възли за актуализацията. Трябва обаче да се уверите, че извършвате такива актуализации само на един възел в даден момент и в клъстер, в който загубата на този възел няма да доведе до загуба на кворум.