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 <clustering.html#recovering-a-failed-node> must be performed.
Това може да се случи например при отказ на един възел в клъстер с два възела (където кворумът е 2). В тази ситуация отказалият възел не може да бъде отстранен от клъстера, тъй като останалият здрав възел вече не работи, тъй като е загубил кворум.
Ето защо се препоръчва винаги да имате нечетен брой възли в клъстера и често да правите резервни копия.
За да сме наясно, временно загубата на кворум (например ако рестартирате всички възли на клъстера заедно или временна повреда в мрежата изолира възлите) не е проблем: след като достатъчно възли се свържат отново (без да се налага ръчно повторно свързване), за да достигнат кворум, клъстерът ще възобнови нормалната си работа. Само при постоянни повреди, като например мрежови раздели, неправилна конфигурация на мрежата, проблеми с удостоверяването или хардуерни повреди, се изисква ръчно действие.
За повече информация вижте ЧЕСТО ЗАДАВАНИ ВЪПРОСИ на etcd.
Клъстер с 2 възела¶
Активен/пасивен клъстер с два възела все още не се поддържа и ще бъде добавен в бъдеща версия. Препоръчваме въвеждането на трети възел, или трети NetHSM, или „свидетел“ на etcd, който може да се използва на всеки хост. Вижте следващия раздел „Свидетел“.
Свидетел¶
Естеството на клъстерирането с etcd го прави толкова по-надеждно, колкото повече възли има в клъстера. Както е обяснено в раздела `Operational Redundancy (Оперативно резервиране) `_, в идеалния случай клъстерите трябва да имат поне 3 възела, за да има място за отказ, тъй като клъстер с 2 възела ще се провали изцяло, ако само единият се откаже.
Въпреки това дизайнът на функцията е такъв, че не е необходимо да добавяте пълно, истинско устройство 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.
Creating a Cluster¶
Първоначално всеки клъстер ще започне от един възел. Нови възли се присъединяват към клъстера един по един.
Preparing Nodes¶
Мрежовият трафик между възлите се криптира и удостоверява с помощта на техния TLS сертификат.
Всички възли, които се очаква да бъдат част от един и същ клъстер, трябва първо да инсталират общ удостоверяващ орган (CA), който ще им позволи да проверяват дали другите възли са легитимни.
По-долу приемаме, че всички възли са прясно осигурени и функционират.
Networking¶
Nodes must first be reconfigured with their expected final network configuration using the /config/network endpoint (refer to the API documentation).
Създаване и инсталиране на 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 трябва да бъде инсталиран на всеки възел.
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).
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" ]
Ако искате да използвате публичен сертификационен център (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
Then install the obtained new_cert.pem with the /config/tls/cert.pem endpoint (refer to the API documentation).
И накрая, CA (CA.pem) вече може да се инсталира с крайната точка /config/tls/cluster-ca.pem (вижте документацията на API). Това е възможно само след като инсталираният TLS сертификат е подписан от него. В противен случай операцията ще бъде отхвърлена.
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¶
Първо се уверете, че е конфигурирана резервна парола на възела, който ще се използва за регистриране на нов присъединител (вижте документацията на API на крайната точка /config/backup-passphrase).
Регистриране на нов възел¶
Имайте под ръка IP адреса на възела, който ще се присъедини. Пълният URL адрес (наричан също peer URL адрес в терминологията etcd) на този възел ще бъде https://<IP_of_node>:2380 (например https://192.168.1.1:2380). Портът трябва да бъде 2380, така че се уверете, че всяка защитна стена между възлите ще позволява TCP трафик на този порт.
Можете да проверите два пъти дали URL адресът е правилен, като извикате GET /cluster/members на възела, към който се очаква да се присъедините. Това трябва да изведе само един член: самия него.
След това регистрирайте този очакван URL адрес във всеки съществуващ възел на клъстера (ако все още нямате клъстер, направете това в NetHSM, който ще служи като начален възел на клъстера). Това се прави с помощта на крайната точка POST /cluster/members (вижте документацията на API), като ѝ предадете JSON тяло, съдържащо URL адреса.
При успех се връща JSON тяло на формуляра:
{
"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
Обърнете внимание, че в отговора по-горе новоприсъединилият се възел е „ученик“: той вече може да се свърже с клъстера и да получава данни от него, но не може да участва, докато не бъде повишен в ранг, което ще бъде разгледано по-долу.
Макар че тази концепция за „ученик“ добавя допълнителна стъпка (повишаване), тя осигурява по-безопасна работа на клъстера, тъй като евентуален проблем с новия възел не може да доведе до нестабилност в целия клъстер преди повишаването му.
Запазете този отговор за следващата стъпка.
Joining the Cluster as a Learner¶
Вземете отговора от последната стъпка и добавете към него поле backupPassphrase, съдържащо резервната парола на възела, на който е регистриран новият присъединяващ се, и предайте тези данни на извикване на POST /cluster/join (вижте документацията на API) на възела, към който се очаква да се присъедини.
Warning
Извикването на POST /cluster/join ще остане в очакване, докато новият възел не бъде ръчно повишен (виж по-долу). Това е нормално. Когато извикването се върне успешно, това означава, че присъединяването и повишаването са преминали успешно.
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
Повишаването на статуса на даден възел увеличава прага на кворума на клъстера (вижте документацията за API на „ “, както и раздела „ “ (Оперативна излишност) в настоящия документ). Уверете се, че новият възел има стабилна връзка с клъстера, преди да повишите статуса му.
Можете да опитате да повишите статуса на новия член чрез извикване на POST /cluster/members/{MemberID}/promote (вижте документацията за API-то на ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __). Ако обучаващият се все още не е наваксал, операцията ще се провали с HTTP код 412 и трябва да се опитате да го повишите отново по-късно.
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).
Запишете отговора от клъстера: той трябва да съдържа списък на членовете на клъстера и комплект за присъединяване (тази част няма да ви е необходима).
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,..."
Ако приемем, че отговорът на NetHSM се съхранява във файл response.json, можете да генерирате последните две променливи автоматично със следните изрази jq:
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.
С други думи, възстановявайте само в клъстер, чиито резервни копия са направени в същия клъстер (въпреки че оттогава възлите може да са били премахнати или добавени). Ако искате да възстановите чуждо резервно копие на даден възел, първо го премахнете безопасно от неговия клъстер, след това го нулирайте фабрично и възстановете резервното копие.
Чисто премахване на възел¶
Докато част от клъстера все още отговаря на кворума, всеки от неговите членове може да бъде използван за отстраняване на друг възел от клъстера, независимо дали този възел вече е недостъпен, или се очаква да бъде.
Първо трябва да знаете идентификатора на възела, който искате да премахнете, като направите списък на всички възли чрез GET /cluster/members и потърсите правилния.
Then it can be removed by calling DELETE /cluster/members/<id>. 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.
Note
Възел, който се е присъединил към клъстера, но все още не е бил повишен в ранг, също може безопасно да бъде премахнат по този начин.
Recovering a Failed Node¶
Възел, който съобщава състоянието „ Failed“ ( се провали), ще откаже да отговори на повечето обичайни операции. Все пак той може да бъде изключен, рестартиран, нулиран, диагностициран или изолиран.
Warning
Наличието на състоянието „ “ (Неуспешен ), както и операциите diagnose и force-new, важи само за версия 5.0 и по-новите версии. В версия 4.0 възел с изгубено кворум ще спре да отговаря на всички заявки all. Той трябва да бъде възстановен към фабричните настройки.
Честите причини, поради които даден възел може да се намира в състоянието „ “ с грешка „ “, включват:
Трайно загуба на кворум.
Временно загубено кворум (например, когато се добавя втори възел към клъстера, а вторият възел все още не се е присъединил).
etcdв момента се рестартира (например защото сертификатите са се променили или мрежата е била преконфигурирана).Клъстерът е подложен на изключително голямо натоварване (например по време на възстановяване на много голям архив).
Независимо от причината, NetHSM ще премине в състоянието „ Failed“ ( ) едва след не по-малко от една пълна минута неуспешни опити за взаимодействие с базата данни. Това се прави, за да се избегнат неоснователни преходи, причинени от много кратки периоди на нестабилност.
За да ви помогнем да разберете в какъв статус се намира вашият възел, крайната точка GET /health/diagnose продължава да е достъпна и предоставя информация за текущото състояние на etcd и неговата база данни, включително логовете (вижте документацията за API).
Note
Ако и когато базата данни отново стане достъпна (например, кворумът бъде възстановен, защото проблемът с мрежата е решен), NetHSM автоматично ще премине от състоянието „ Failed“ към състоянието, в което се е намирал преди това (или ще възобнови нормалната последователност на зареждане, ако е бил в процес на зареждане), без да е необходимо каквото и да е ръчно действие. След като проблемът бъде отстранен, ще отнеме до една минута, докато клъстерът се стабилизира, HSM засече, че проблемът е отстранен, и промени състоянието си.
Ако стигнете до заключението, че неизправността е трайна (например загуба на кворум, без надежда за разрешаване на основния проблем), можете да:
Възстановете фабричните настройки на устройството, което ще изтрие всички данни, и възстановете резервно копие.
Изолирайте възела с крайната точка
POST /cluster/force-new, което ще доведе до необратимо забравяне на всички останали членове на клъстера, възстановяване на даннитеetcd, налични на диска, и рестартиране. Ако основната повреда е свързана с клъстера, възелът ще следва нормалната последователност на зареждане и ще премине в състояние „Locked“ или „Operational“ в зависимост от настройката за автоматично зареждане.
Note
Ако даден възел бъде изолиран с командата „ ` “ force-new`, той вече ще бъде десинхронизиран с клъстера: нови записи, направени на него или в клъстера, няма да могат да бъдат съгласувани. Възелът все още може да се присъедини отново към клъстера, но ще загуби всички свои локални промени.
Крайната точка „ ` “ POST /cluster/force-new`, която е достъпна само в състоянието „ Failed“, изисква удостоверяване на автентичност, тъй като може да доведе до загуба на данни. Тъй като обаче потребителите и ролите на HSM не са достъпни в това състояние, крайната точка очаква HTTPS клиентите винаги да се удостоверяват с фалшивия потребител „ ` “ unlock` и с най-новата известна парола за отключване като парола.
Warning
След актуализация от версия < 5.0 крайната точка „ ` “ force-new` винаги ще показва състоянието „Unauthorized“, докато HSM не бъде отключен или паролата за отключване не бъде променена поне веднъж.
Software Updates in Clusters¶
Бъдещите актуализации ще бъдат маркирани като „безопасни за клъстера“ (това трябва да е мнозинството) или „опасни за клъстера“.
Актуализациите, защитени от клъстери, могат да бъдат прилагани към възли, които са част от клъстер, без те да бъдат премахвани от клъстера. Въпреки това, както при всички операции, трябва да се уверите, че това се прави на един възел в даден момент и в клъстер, в който премахването на възел не води до намаляване на кворума (напр. ако актуализацията се провали).
Актуализациите, които не са безопасни за клъстера, трябва да се прилагат към изолирани възли. Трябва да разглобите клъстера (като премахвате възлите един по един), да възстановите фабричните настройки на всички възли с изключение на един, да приложите актуализацията на всеки възел, след което да накарате всички възли да се присъединят към останалия възел.
Не забравяйте да направите резервно копие преди такива операции.
Преконфигуриране на съществуващ клъстер¶
Changing the Cluster CA¶
Съществуващ клъстер (с два или повече възела) не може да промени своя CA на клъстера по време на работа. Ако трябва да промените този сертификат: изберете възел, премахнете всички останали възли, актуализирайте CA, след което накарайте останалите членове да се присъединят отново.
Changing the Network Configuration of Nodes¶
Промяната на мрежовата конфигурация на даден възел (например промяна на неговия IP адрес) автоматично информира останалите възли за актуализацията. Трябва обаче да се уверите, че извършвате такива актуализации само на един възел в даден момент и в клъстер, в който загубата на този възел няма да доведе до загуба на кворум.