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 <clustering.html#recovering-a-failed-node> 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の "ウィットネス "を導入することをお勧めします。次のセクション「ウィットネス」を参照してください。
証人¶
``etcd``によるクラスタリングの性質上、クラスタ内のノード数が多いほど信頼性が高くなります。`Operational Redundancy`_のセクションで説明したように、クラスターは理想的には少なくとも3つのノードが故障する余地を持つべきです。
しかし、この機能の設計では、安定したノード数に到達するために、クラスタに完全な本物の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¶
どのクラスターも最初は1つのノードから始まります。新しいノードは1つずつクラスタに参加します。
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を作成すべきである。
例えば、最小の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).
注釈
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アドレスを使用する必要があります。これは、パブリック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
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 documentation<https://nethsmdemo.nitrokey.com/api_docs/index.html>`__ を参照)。これは、インストールされたTLS証明書がCAによって署名された場合にのみ可能です。そうでない場合、操作は拒否されます。
注釈
このプロセスをノードごとに繰り返さなければならない。
クロック同期¶
すべてのノードに正確なシステム時刻が設定されていることを確認してください。手動での時刻設定ではなく、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:
Register the addition to the cluster (through any one of its members)
Tell the new node to join
追いついたら、そのノードを「学習者」から「正式メンバー」に昇格させる
Configure a Backup Passphrase¶
まず、新しいジョイナーの登録に使用するノードでバックアップパスフレーズが設定されていることを確認する（``/config/backup-passphrase``エンドポイントのAPIドキュメントを参照）。
新規ノードの登録¶
参加するノードのIPを手元に用意する。そのノードの完全な*URL* （etcd``の用語では*ピアURL* とも呼ばれる）は``https://<IP_of_node>:2380``（例：``https://192.168.1.1:2380）となる。ポート**** は2380でなければならないので、ノード間のファイアウォールがそのポートのTCPトラフィックを許可していることを確認してください。
URL が正しいかどうかは、GET /cluster/members を参加予定のノードで呼び出すことで再確認できる。これによって1つのメンバーだけがリストアップされるはずです。
次に、その URL をクラスタの既存のノードに登録します（まだクラスタがない場合は、クラスタの初期ノードとなる NetHSM で行います）。これには``POST /cluster/members`` エンドポイント（`API documentation<https://nethsmdemo.nitrokey.com/api_docs/index.html>`__ を参照）を使用し、URLを含む JSON ボディを渡します。
成功すれば、フォームの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 documentation<https://nethsmdemo.nitrokey.com/api_docs/index.html>`__ を参照)への呼び出しに渡す。
警告
POST /cluster/join への呼び出しは、新しいノードが手動で昇格されるまで（後述参照）応答しなくなります。これは正常な動作です。呼び出しが正常に返された場合は、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 ドキュメント<https://nethsmdemo.nitrokey.com/api_docs/index.html>`__ および、本書の「`運用上の冗長性」<clustering.html#operational-redundancy>`__ のセクションを参照してください）。昇格を行う前に、この新しいノードがクラスタと安定した接続を確立していることを確認してください。
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アドレス（少なくとも）を持つ環境が必要です。ポート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).
クラスタからの応答を書き留めてください。クラスタメンバーのリストとジョイナーキットが含まれているはずです（この部分は必要ありません）。
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,..."
NetHSM のレスポンスが``response.json`` ファイルに保存されていると仮定すると、以下の``jq`` 式で最後の2つの変数を自動的に生成することができます：
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は操作不能になる。
言い換えれば、同じクラスタでバックアップが行われたクラスタでのみリストアを実行してください（ただし、その後ノードが削除または追加されている可能性があります）。あるノードの外部バックアップをリストアしたい場合は、まずそのノードをクラスタから安全に削除し、ファクトリーリセットしてからバックアップをリストアします。
ノードをきれいに削除する¶
クラスタのどこかがまだ定足数を満たしている限り、そのメンバーのいずれかを使って、他のノードをクラスタから取り除くことができる。
まず、削除したいノードの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」 という状態を報告しているノードは、通常の操作のほとんどに応答しなくなります。ただし、シャットダウン、再起動、リセット*、診断* 、または隔離** を行うことは可能です。
警告
Failed ステート、diagnose および``force-new`` 操作の存在は、バージョン 5.0 以降にのみ適用されます。バージョン 4.0 では、クォーラムを失ったノードは、すべての リクエストへの応答を停止します。このノードは*必ず* 工場出荷時設定にリセットする必要があります。
ノードが「*」の「Failed* 」状態になる一般的な原因には、次のようなものがあります。
`がクオラムを失った状態が長期間続いた<clustering.html#the-quorum-is-durably-lost>`__。
一時的に定足数を満たさなくなった状態（例：クラスタに 2 番目のノードを追加する際、そのノードがまだクラスタに参加していない場合など）。
etcdは現在、再起動中です（例：証明書が変更された、またはネットワーク設定が再構成されたためなど）。クラスタは非常に高い負荷がかかっています（例：非常に大規模なバックアップの復元中など）。
原因が何であれ、NetHSMは、データベースとの通信が1分以上連続して失敗した場合にのみ、「Failed 」状態に移行します。これは、ごく短時間の不安定状態によって引き起こされる誤った状態遷移を防ぐためです。
ノードがどの状態にあるかを把握しやすくするため、GET /health/diagnose エンドポイントは引き続き利用可能であり、etcd およびそのデータベースの現在のステータスに関する情報（ログを含む）を返します（APIドキュメントを参照してください）。
注釈
データベースが再び利用可能になった場合（例：ネットワークの問題が解決され、クォーラムが復旧した場合など）、NetHSMは、手動での操作を必要とすることなく、「Failed 」状態から、以前の状態へ自動的に移行します（または、起動中であった場合は通常の起動シーケンスを再開します）。 問題が解決してから、クラスタが安定し、HSMが問題の解決を検知して状態を変更するまで、最大1分程度かかります。
その障害が永続的であると判断した場合（例：クォーラムが失われ、根本的な原因を解決する見込みがない場合など）、以下のいずれかの対応をとることができます：
ノードを工場出荷時設定にリセット（ ）して、すべてのデータを消去し、バックアップを復元します。
** `` ` エンドポイントを持つノード（ ）を隔離します。これにより、そのノードは他のすべてのクラスタメンバーを不可逆的に忘却し、ディスク上に存在する ` ` データを復元した上で再起動します。根本的な障害がクラスタ関連であった場合、そのノードは通常の起動シーケンスに従い、無人起動の設定に応じて、 Locked または Operational のいずれかの状態になります。POST /cluster/force-new`** etcd ** **
注釈
ノードが ` および `force-new によって隔離された場合、そのノードはクラスタとの同期が失われます。つまり、そのノードまたはクラスタに対する新しい書き込みは、調整できなくなります。このノードは引き続きクラスタに再参加することは可能ですが、ローカルでの変更内容はすべて失われます。
POST /cluster/force-new エンドポイントは、Failed 状態でのみ利用可能であり、破壊的な操作を引き起こす可能性があるため、認証が必要です。ただし、この状態では HSM ユーザーおよびロールが利用できないため、このエンドポイントは、HTTPS クライアントが常に``unlock`` の偽ユーザーと、パスワードとして最新の既知のロック解除パスフレーズを使用して認証することを想定しています。
警告
バージョン 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つのノードに対してのみ行い、そのノードを失ってもクォーラムが失われないクラスタ内で行うようにしてください。