Clustering¶
Примечание
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 на каждом узле теряет возможность выполнять операции чтения и записи. Это влечет за собой следующие сценарии.
Один узел вышел из строя, но кворум все равно достигнут¶
В кластере из 3 узлов, если один узел выходит из строя (падает или становится недоступным из-за сетевых условий), два других узла продолжают работать и обслуживать запросы.
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>` __ и либо провести его восстановление по адресу ` <clustering.html#recovering-a-failed-node>` __ для доступа к данным (однако в этом случае оно больше не будет входить в состав кластера), либо выполнить сброс к заводским настройкам и заново пройти процесс подключения с нуля.
Произошло разделение сети, но кворум все еще достигнут¶
Это просто обобщение предыдущего сценария. В кластере из 5 узлов, где, например, 3 узла находятся в одном физическом месте A, а 2 узла - в другом месте B, сетевая проблема, изолирующая A и B, будет означать следующее:
Три узла в расположении A удовлетворяют кворуму (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).
Если проблема с сетью решена, эти 2 узла без проблем присоединятся к 3 другим.
Другими словами, в случае наихудшего сценария разъединения сети (в кластере с нечетным количеством узлов) большая половина кластера останется работоспособной, а меньшая половина — неработоспособной до тех пор, пока разъединение не будет устранено.
Кворум окончательно потерян¶
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). В такой ситуации отказавший узел нельзя удалить из кластера, поскольку оставшийся здоровый узел уже неработоспособен, так как потерял кворум.
Поэтому рекомендуется всегда иметь нечетное количество узлов в кластере и часто выполнять резервное копирование.
To be clear, temporarily losing quorum (for example, if you are restarting all nodes of a cluster together, or a temporary network failure isolates nodes) is not a problem: once enough nodes are reconnected (without having to manually re-join) to reach quorum, the cluster will resume its normal operation. Only permanent failures such as network partitions, network misconfigurations, authentication issues or hardware failures, will require manual action.
Дополнительные сведения см. на сайте ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ.
2-узловой кластер¶
Двухузловой активный/пассивный кластер пока не поддерживается и будет добавлен в будущей версии. Мы рекомендуем ввести третий узел, либо третий NetHSM, либо «свидетель» etcd, который может работать на любом хосте. См. следующий раздел «Свидетель».
Свидетель¶
Природа кластеризации с etcd делает ее тем надежнее, чем больше узлов в кластере. Как объясняется в разделе `»Оперативная избыточность», кластеры в идеале должны иметь не менее 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).
Создание и установка ЦС¶
Пользователи должны создавать ЦС собственными средствами и в соответствии со своими операционными ограничениями, убедившись, что он позволяет использовать, по крайней мере, ключ keyCertSign.
Например, минимальный ЦС может быть создан с помощью 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
Теперь этот ЦС должен быть установлен на каждом узле.
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).
Примечание
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-сертификат будет им подписан. В противном случае операция будет отклонена.
Примечание
Этот процесс необходимо повторить для каждого узла.
Синхронизация часов¶
Убедитесь, что на каждом узле установлено точное системное время; в идеале следует использовать протоколы 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 ` <https://nethsmdemo.nitrokey.com/api_docs/index.html>` __), передавая ей тело 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=="
}
который содержит информацию, необходимую новому узлу для присоединения к кластеру. В частности, в нем перечислены все члены кластера (где член с пустым именем - это новый участник). Он также содержит ключ домена, зашифрованный парольной фразой для разблокировки и резервной фразой - поэтому резервная парольная фраза должна быть настроена ранее.
Примечание
Обратите внимание, что в приведенном выше ответе новый узел имеет статус «learner»: теперь он может подключаться к кластеру и получать от него данные, но не может участвовать в работе, пока не получит более высокий статус, о чем пойдет речь ниже.
Хотя данная концепция «учащегося узла» добавляет дополнительный этап (повышение статуса), она обеспечивает более безопасную работу кластера, поскольку любая проблема с новым узлом не может привести к нестабильности всего кластера до того, как ему будет присвоен более высокий статус.
Сохраните этот ответ для следующего шага.
Joining the Cluster as a Learner¶
Возьмите ответ с последнего шага и добавьте к нему поле backupPassphrase, содержащее резервную парольную фразу узла, на котором был зарегистрирован новый участник, и передайте эти данные в вызов POST /cluster/join (см. документацию API) на узле, к которому ожидается присоединение.
Предупреждение
Вызов функции 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¶
В зависимости от состояния сети и кластера новому участнику может потребоваться некоторое время, чтобы синхронизироваться с кластером. Как только это произойдет, его статус можно будет повысить с «обучающегося» до «полноправного участника».
Предупреждение
Повышение статуса узла приводит к увеличению порога кворума кластера (см. документацию по 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, которые автоматически выбирают имя узла для себя (используя идентификатор устройства), вы должны выбрать имя для каждого добавляемого свидетеля, убедившись, что имена уникальны. В следующих примерах мы будем использовать «witness1».
Вместе с ответом 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¶
Наконец, через некоторое время следуйте стандартным инструкциям из раздела « » («Содействие новому ученику»), чтобы повысить статус свидетеля. Если это не сработает, попробуйте позже.
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.
Примечание
Восстановление на узле A резервной копии, сделанной на другом узле Z с другим ключом домена, корректно перезапишет ключ домена A, как и раньше. Однако если A находился в кластере с узлом B, B станет неработоспособным, поскольку ключ домена Z не будет восстановлен на B.
Другими словами, выполняйте восстановление только в кластере с резервными копиями, созданными в том же кластере (хотя с тех пор узлы могли быть удалены или добавлены). Если вы хотите восстановить чужую резервную копию на узле, сначала безопасно удалите его из кластера, затем выполните заводской сброс и восстановите резервную копию.
Чистое удаление узла¶
Пока какая-то часть кластера продолжает удовлетворять кворуму, любой из его членов может быть использован для удаления другого узла из кластера, независимо от того, является ли этот узел уже недоступным или ожидается, что он станет таковым.
Сначала нужно узнать ID узла, который вы хотите удалить, перечислив все узлы через 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.
Примечание
Узел, который присоединился к кластеру, но ещё не был повышен в статусе, также можно безопасно удалить таким образом.
Recovering a Failed Node¶
Узел, сообщающий о состоянии «Сбой » ( Failed), не будет отвечать на большинство стандартных операций. Его по-прежнему можно выключить, перезагрузить, выполнить сброс настроек , провести диагностику или , а также изолировать.
Предупреждение
Наличие состояния « » (Ошибка: ), а также операций diagnose и force-new применимо только к версии 5.0 и более поздним версиям. В версии 4.0 узел, утративший кворум, перестанет отвечать на все запросы. Его необходимо сбросить к заводским настройкам.
К числу распространенных причин, по которым узел может находиться в состоянии « » (Ошибка), относятся:
Длительная потеря кворума ` <clustering.html#the-quorum-is-durably-lost>` __.
Временная потеря кворума (например, при добавлении второго узла в кластер, когда второй узел ещё не присоединился).
etcdв данный момент перезапускается (например, из-за смены сертификатов или перенастройки сети).Кластер испытывает очень высокую нагрузку (например, во время восстановления очень объёмной резервной копии).
Независимо от причины, NetHSM перейдет в состояние « Failed» ( ) только после не менее одной полной минуты безуспешных попыток взаимодействия с базой данных. Это сделано для того, чтобы избежать ложных переходов, вызванных кратковременными сбоями.
Чтобы вам было проще понять, в каком состоянии находится ваш узел, конечная точка GET /health/diagnose по-прежнему доступна и возвращает информацию о текущем состоянии etcd и его базы данных, включая журналы (см. документацию по API).
Примечание
Если и когда база данных вновь станет доступной (например, кворум будет восстановлен вследствие устранения сетевой проблемы), NetHSM автоматически перейдет из состояния « » (Сбой ) в состояние, в котором он находился ранее (или возобновит нормальную последовательность загрузки, если в этот момент происходила загрузка), без необходимости каких-либо действий со стороны пользователя. После устранения проблемы потребуется до одной минуты, чтобы кластер стабилизировался, HSM обнаружил устранение проблемы и изменил состояние.
Если вы придете к выводу, что сбой носит постоянный характер (например, утрата кворума без надежды на устранение причины), вы можете либо:
Сбросьте настройки устройства до заводских значений ( ), что приведет к удалению всех данных, а затем восстановите резервную копию.
Изолируйте узел с конечной точкой
POST /cluster/force-new, который необратимо «забудет» всех остальных участников кластера, восстановит данныеetcd, имеющиеся на диске, и перезагрузится. Если исходный сбой был связан с кластером, узел выполнит стандартную последовательность загрузки и перейдет либо в состояние «Заблокирован», либо в состояние «Рабочее» в зависимости от настроек автоматической загрузки.
Примечание
Если узел изолирован с помощью команды ` force-new `, он теперь будет десинхронизирован с кластером: любые новые записи, выполненные на этом узле или в кластере, не смогут быть согласованы. Узел по-прежнему сможет вновь присоединиться к кластеру, но при этом потеряет все свои локальные изменения.
Конечная точка POST /cluster/force-new, доступная только в состоянии « » (Сбой), требует аутентификации, поскольку может привести к потере данных. Однако, поскольку в этом состоянии пользователи и роли HSM недоступны, конечная точка предполагает, что HTTPS-клиенты всегда будут проходить аутентификацию с использованием фиктивного пользователя unlock и последней известной парольной фразы разблокировки в качестве пароля.
Предупреждение
После обновления с версии < 5.0 конечная точка force-new будет всегда возвращать статус «Unauthorized», пока HSM не будет разблокирован или пока пароль разблокировки не будет изменен хотя бы один раз.
Software Updates in Clusters¶
Будущие обновления будут помечены как «кластерно-безопасные» (это должно быть большинство) или «кластерно-небезопасные».
Кластерно-безопасные обновления можно применять к узлам, входящим в кластер, не удаляя их из кластера. Однако, как и при любых других операциях, вы должны убедиться, что это делается на одном узле за раз и в таком кластере, где удаление узла не приведет к снижению кворума (например, если обновление не удастся).
Небезопасные для кластера обновления должны применяться на изолированных узлах. Вам следует разобрать кластер (удаляя узлы по одному), сбросить все узлы, кроме одного, применить обновление к каждому узлу, а затем заставить все сброшенные узлы присоединиться к оставшемуся узлу.
Перед такими операциями обязательно создайте резервную копию.
Изменение конфигурации существующего кластера¶
Changing the Cluster CA¶
Существующий кластер (с двумя или более узлами) не может изменить свой кластерный ЦС во время работы. Если вам нужно изменить этот сертификат: выберите узел, удалите все остальные узлы, обновите ЦС, а затем попросите остальных участников снова присоединиться.
Changing the Network Configuration of Nodes¶
Изменение сетевой конфигурации узла (например, изменение его IP) автоматически сообщит об этом другим узлам. Однако следует убедиться, что такие обновления выполняются только на одном узле за раз и в таком кластере, где потеря этого узла не приведет к потере кворума.