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 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, который может работать на любом хосте. См. следующий раздел «Свидетель».

Свидетель¶

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.

Создание и установка ЦС¶

Пользователи должны создавать ЦС собственными средствами и в соответствии со своими операционными ограничениями, убедившись, что он позволяет использовать, по крайней мере, ключ 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

Теперь этот ЦС должен быть установлен на каждом узле.

Для этого сначала необходимо сгенерировать запрос на подпись сертификата (CSR) с узла, как описано в разделе TLS Certificate. С помощью nitropy это делается с помощью команды nitropy nethsm --host $NETHSM_HOST csr --api.

Примечание

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

Примечание

Этот процесс необходимо повторить для каждого узла.

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

Убедитесь, что на каждом узле установлено точное системное время; в идеале следует использовать протоколы 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=="
}

который содержит информацию, необходимую новому узлу для присоединения к кластеру. В частности, в нем перечислены все члены кластера (где член с пустым именем - это новый участник). Он также содержит ключ домена, зашифрованный парольной фразой для разблокировки и резервной фразой - поэтому резервная парольная фраза должна быть настроена ранее.

Примечание

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

Предупреждение

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¶

В зависимости от состояния сети и кластера новому участнику может потребоваться некоторое время, чтобы синхронизироваться с кластером. Как только это произойдет, его статус можно будет повысить с «обучающегося» до «полноправного участника».

Предупреждение

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, которые автоматически выбирают имя узла для себя (используя идентификатор устройства), вы должны выбрать имя для каждого добавляемого свидетеля, убедившись, что имена уникальны. В следующих примерах мы будем использовать «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,..."

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¶

Наконец, через некоторое время следуйте стандартным инструкциям из раздела « » («Содействие новому ученику»), чтобы повысить статус свидетеля. Если это не сработает, попробуйте позже.

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.

Другими словами, выполняйте восстановление только в кластере с резервными копиями, созданными в том же кластере (хотя с тех пор узлы могли быть удалены или добавлены). Если вы хотите восстановить чужую резервную копию на узле, сначала безопасно удалите его из кластера, затем выполните заводской сброс и восстановите резервную копию.

Чистое удаление узла¶

Пока какая-то часть кластера продолжает удовлетворять кворуму, любой из его членов может быть использован для удаления другого узла из кластера, независимо от того, является ли этот узел уже недоступным или ожидается, что он станет таковым.

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

Выведите список узлов с помощью команды GET /cluster/members и удалите один из них, вызвав команду DELETE /cluster/members/<id>.

Примечание

Узел, который присоединился к кластеру, но ещё не был повышен в статусе, также можно безопасно удалить таким образом.

Recovering a Failed Node¶

Узел, сообщающий о состоянии «Сбой » ( Failed), не будет отвечать на большинство стандартных операций. Его по-прежнему можно выключить, перезагрузить, выполнить сброс настроек , провести диагностику или , а также изолировать.

Предупреждение

Наличие состояния « » (Ошибка: ), а также операций diagnose и force-new применимо только к версии 5.0 и более поздним версиям. В версии 4.0 узел, утративший кворум, перестанет отвечать на все запросы. Его необходимо сбросить к заводским настройкам.

К числу распространенных причин, по которым узел может находиться в состоянии « » (Ошибка), относятся:

Длительная потеря кворума ` <clustering.html#the-quorum-is-durably-lost>` __.
Временная потеря кворума (например, при добавлении второго узла в кластер, когда второй узел ещё не присоединился).
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

Примечание

Если и когда база данных вновь станет доступной (например, кворум будет восстановлен вследствие устранения сетевой проблемы), NetHSM автоматически перейдет из состояния « » (Сбой ) в состояние, в котором он находился ранее (или возобновит нормальную последовательность загрузки, если в этот момент происходила загрузка), без необходимости каких-либо действий со стороны пользователя. После устранения проблемы потребуется до одной минуты, чтобы кластер стабилизировался, 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.

Примечание

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

Предупреждение

После обновления с версии < 5.0 конечная точка force-new будет всегда возвращать статус «Unauthorized», пока HSM не будет разблокирован или пока пароль разблокировки не будет изменен хотя бы один раз.

Software Updates in Clusters¶

Будущие обновления будут помечены как «кластерно-безопасные» (это должно быть большинство) или «кластерно-небезопасные».

Кластерно-безопасные обновления можно применять к узлам, входящим в кластер, не удаляя их из кластера. Однако, как и при любых других операциях, вы должны убедиться, что это делается на одном узле за раз и в таком кластере, где удаление узла не приведет к снижению кворума (например, если обновление не удастся).

Небезопасные для кластера обновления должны применяться на изолированных узлах. Вам следует разобрать кластер (удаляя узлы по одному), сбросить все узлы, кроме одного, применить обновление к каждому узлу, а затем заставить все сброшенные узлы присоединиться к оставшемуся узлу.

Перед такими операциями обязательно создайте резервную копию.

Изменение конфигурации существующего кластера¶

Changing the Cluster CA¶

Существующий кластер (с двумя или более узлами) не может изменить свой кластерный ЦС во время работы. Если вам нужно изменить этот сертификат: выберите узел, удалите все остальные узлы, обновите ЦС, а затем попросите остальных участников снова присоединиться.

Changing the Network Configuration of Nodes¶

Изменение сетевой конфигурации узла (например, изменение его IP) автоматически сообщит об этом другим узлам. Однако следует убедиться, что такие обновления выполняются только на одном узле за раз и в таком кластере, где потеря этого узла не приведет к потере кворума.