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<https://etcd.io>`__ に基づいています。このクラスタは、`Raftコンセンサス・アルゴリズム<https://raft.github.io/>`__ を使用して強力な一貫性を実現しています。これにより、すべてのNetHSMでデータ（鍵など）が常に正しいことが保証される。

NetHSM クラスタをセットアップする前に、このテクノロジーとその制約についてよく理解し、偶発的な停止やデータ損失を避けるようにしてください。このドキュメントに加えて、`etcd のドキュメント<https://etcd.io/docs/latest/learning/>`__ も参照してください。

Operational Redundancy

クラスタの一部であることが期待される NetHSM を「ノード」と呼ぶことにする。**** ``N``**ノードからなるクラスタは、少なくとも** ``(N/2)+1``**ノードが健康で到達可能である限り運用を継続する。** 健康で到達可能なノードの最小数を**クォーラム** と呼びます。

この閾値を下回ったクラスタ（例えば、ネットワークの問題などが原因で）では、リーダーが選出されなくなり、各ノード上の``etcd``のローカルインスタンスは、読み取りおよび書き込みを実行できなくなります。これにより、次のようなシナリオが生じます。

1つのノードがダウンしても定足数に達する

3ノードクラスタでは、1つのノードに障害が発生しても（クラッシュしたり、ネットワーク状況により到達できなくなったりしても）、他の2つのノードは動作を継続し、リクエストに対応する。

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>`__ を行うか（ただし、その場合はクラスタの一部ではなくなります）、あるいは工場出荷時設定にリセットして、最初から再度クラスタへの参加プロセスを経る必要があります。

ネットワーク・パーティションが発生しても定足数に達する

これは前のシナリオの一般化である。例えば3ノードがある物理的な場所Aにあり、2ノードが別の場所Bにある5ノードのクラスタでは、AとBを分離するネットワーク問題は次のようになります：

• ロケーションAの3ノードは定足数（この場合は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ノードクラスタ（クォーラムが2）で1つのノードが故障した場合に起こり得ます。このような状況では、障害が発生したノードを事後的にクラスタからきれいに削除することはできません。なぜなら、残っている健全なノードはクォーラムを失っているため、すでに操作不能になっているからです。

したがって、クラスタ内のノード数は常に奇数にし、頻繁にバックアップを取ることをお勧めする。

はっきりさせておくと、一時的に クォーラムを失っても（例えば、クラスタの全ノードをまとめて再起動する場合や、一時的なネットワーク障害でノードが孤立した場合など）問題はありません。クォーラムに達するだけのノードが（手動で再接続しなくても）再接続されれば、クラスタは通常の動作を再開します。ネットワーク・パーティション、ネットワークの誤設定、認証の問題、ハードウェアの故障などの恒久的な障害に限り、手動での対処が必要になります。

詳しくは、`etcdのよくあるご質問<https://etcd.io/docs/v3.6/faq/#why-an-odd-number-of-cluster-members>`__を参照のこと。

2ノードクラスタ

2ノードのアクティブ/パッシブクラスターはまだサポートされておらず、将来のバージョンで追加される予定です。3台目の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

どのクラスターも最初は1つのノードから始まります。新しいノードは1つずつクラスタに参加します。

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を作成すべきである。

例えば、最小の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を各ノードにインストールする必要がある。

これを行うには、まず「`TLS Certificate<administration.html#tls-certificate>`__」のセクションに記載されている手順に従って、ノードから証明書署名要求（CSR）を生成します。ニトロピ を使用する場合、これは `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アドレスを使用する必要があります。これは、パブリックCAが、IP SANにプライベートIPアドレスを含む証明書を発行することを禁じているセキュリティ要件によるものです。

取得した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

<administration.html#tls-certificate>`次に、「`」のセクションに記載されている手順に従って、取得した``new_cert.pem`` をインストールします（ニトロピ:nitropy nethsm --host $NETHSM_HOST set-certificate --api new_cert.pem）。

Finally, the CA (CA.pem) can now be installed. This is only possible once the installed TLS certificate is signed by it. Otherwise, the operation will be rejected.

nitropyREST API

**論評

論証	説明
FILENAME。	The path of the CA file

**例

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

インストール済みのクラスタCAは、nitropy nethsm --host $NETHSM_HOST get-cluster-ca-certificate で確認できます。

注釈

このプロセスをノードごとに繰り返さなければならない。

クロック同期

すべてのノードに正確なシステム時刻が設定されていることを確認してください。手動での時刻設定ではなく、NTP/NTS を使用するのが理想的です。これは、`（時刻）<administration.html#time>`__ および`（NTS/NTP）<administration.html#ntp-nts>`__ の設定を行うことで実現できます。

Adding a New Node

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

1. Register the addition to the cluster (through any one of its members)

2. Tell the new node to join

3. 追いついたら、そのノードを「学習者」から「正式メンバー」に昇格させる

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* （etcd``の用語では*ピアURL* とも呼ばれる）は``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.

nitropyREST API

**例

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

Then register that expected URL on any existing node of the cluster (if you don't have a cluster yet, do this on the NetHSM that will serve as the initial node of the cluster).

nitropyREST API

オプション設定

オプション	説明
--url TEXT	新しいノードのピアURL（複数回設定可能）

**論評

論証	説明
JOIN_DATA_PATH	結合データが書き込まれるファイルのパス

**例

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

このコマンドは、クラスタのメンバーを一覧表示し、新しいノードがクラスタに参加するために必要なデータ（joiner kit を含む）をファイルに書き出します。次の手順のために、このファイルを保管しておいてください。

注釈

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

前の手順で取得したデータと、新規参加ノードが登録されたノードのバックアップパスフレーズを使用して、参加予定のノードからクラスタに参加してください。

nitropyREST API

必須オプション

オプション	説明
--backup-passphrase TEXT	新規参加者が登録されたノードのバックアップパスフレーズ

**論評

論証	説明
JOIN_DATA_PATH	前の手順で作成した結合データファイルのパス

**例

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

警告

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.

新しいメンバーを昇格させるには、以下の手順を試してみてください。メンバーIDは、クラスタのメンバー一覧を表示することで確認できます。

nitropyREST API

**論評

論証	説明
MEMBER_ID	The ID of the learner to be promoted

**例

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

学習者がまだ追いついていない場合、この処理は失敗し（REST APIでは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アドレス（少なくとも）を持つ環境が必要です。ポート2380を発着するTCPトラフィックが許可されている必要があります。

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.

その後、ウィットネス用の証明書を作成し、CAで署名して、ウィットネスがピアと通信できるようにする必要があります。これは例えば``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

デバイス ID を使用して）自動的にノード名を選択する 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"

最後に、docs/etcd_witness.conf.template で提供されているテンプレート・ファイルを使用して、etcd.conf.yml ファイルを作成する：

$ 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 で作成されたバックアップと互換性があります。

注釈

異なるドメイン鍵で別のノードZに作成されたバックアップをノードAにリストア すると、Aのドメイン鍵は以前と同様に正しく書き換えられる。しかし、AがノードBとクラスタ内にあった場合、ZのドメインキーがB上にリストアされないため、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.

nitropyREST API

**論評

論証	説明
MEMBER_ID	The ID of the node to be removed

**例

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

注釈

クラスタに参加しているが、まだ昇格されていないノードも、この方法で安全に削除することができます。

Recovering a Failed Node

「Failed」 という状態を報告しているノードは、通常の操作のほとんどに応答しなくなります。ただし、シャットダウン、再起動、リセット*、診断* 、または隔離** を行うことは可能です。

警告

Failed ステート、diagnose および``force-new`` 操作の存在は、バージョン 5.0 以降にのみ適用されます。バージョン 4.0 では、クォーラムを失ったノードは、すべての リクエストへの応答を停止します。このノードは*必ず* 工場出荷時設定にリセットする必要があります。

ノードが「*」の「Failed* 」状態になる一般的な原因には、次のようなものがあります。

• `がクオラムを失った状態が長期間続いた<clustering.html#the-quorum-is-durably-lost>`__。

• 一時的に定足数を満たさなくなった状態（例：クラスタに 2 番目のノードを追加する際、そのノードがまだクラスタに参加していない場合など）。

• etcd は現在、再起動中です（例：証明書が変更された、またはネットワーク設定が再構成されたためなど）。

• クラスタは非常に高い負荷がかかっています（例：非常に大規模なバックアップの復元中など）。

原因が何であれ、NetHSMは、データベースとの通信が1分以上連続して失敗した場合にのみ、「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.

nitropyREST API

**例

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

注釈

データベースが再び利用可能になった場合（例：ネットワークの問題が解決され、クォーラムが復旧した場合など）、NetHSMは、手動での操作を必要とすることなく、「Failed 」状態から、以前の状態へ自動的に移行します（または、起動中であった場合は通常の起動シーケンスを再開します）。 問題が解決してから、クラスタが安定し、HSMが問題の解決を検知して状態を変更するまで、最大1分程度かかります。

その障害が永続的であると判断した場合（例：クォーラムが失われ、根本的な原因を解決する見込みがない場合など）、以下のいずれかの対応をとることができます：

• ノードを工場出荷時設定にリセット（ ）して、すべてのデータを消去し、バックアップを復元します。

• 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 未満からアップデートした後、HSM のロックが解除されるか、ロック解除パスフレーズが少なくとも 1 回変更されるまでは、`` の force-new` エンドポイントへのアクセスは常に「Unauthorized」となります。

Software Updates in Clusters

今後のアップデートは、"cluster-safe"（これが大多数であるべきだ）または "cluster-unsafe "としてマークされる。

クラスタセーフ・アップデートは、クラスタの一部であるノードに対して、そのノードをクラスタから削除することなく適用できます。ただし、すべての操作と同様に、一度に1つのノードで、ノードを削除してもクォーラムを下回らないクラスタ内で（アップデートに失敗した場合など）、これを実行するようにしてください。

クラスタ安全でないアップデートは、分離されたノードに適用する必要があります。クラスタを解体し（ノードを1つずつ削除し）、1つのノードを除くすべてのノードをファクトリーリセットし、すべてのノードにアップデートを適用し、リセットしたすべてのノードを残りのノードに参加させる必要があります。

このような操作の前には、必ずバックアップを取ってください。

既存のクラスタの再構成

Changing the Cluster CA

** 既存のクラスタ（2つ以上のノードを持つ）**、運用中にクラスタCAを変更することはできません。この証明書を変更する必要がある場合は、ノードを選択し、他のノードをすべて削除し、CAを更新してから、他のメンバーを再参加させます。

Changing the Network Configuration of Nodes

あるノードのネットワーク設定を変更すると（IPを変更するなど）、他のノードにその更新が自動的に通知されます。ただし、このような更新は一度に1つのノードに対してのみ行い、そのノードを失ってもクォーラムが失われないクラスタ内で行うようにしてください。