---
discourse: 11330
---

(cluster-manage)=
# クラスタを管理するには

クラスタを形成した後、メンバーの一覧と状態を見るには `lxc cluster list` を使用します。

```{terminal}
:input: lxc cluster list
:scroll:

+---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+
| NAME    |            URL             |      ROLES       | ARCHITECTURE | FAILURE DOMAIN | DESCRIPTION | STATE  |      MESSAGE      |
+---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+
| server1 | https://192.0.2.101:8443   | database-leader  | x86_64       | default        |             | ONLINE | Fully operational |
|         |                            | database         |              |                |             |        |                   |
+---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+
| server2 | https://192.0.2.102:8443   | database-standby | aarch64      | default        |             | ONLINE | Fully operational |
+---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+
| server3 | https://192.0.2.103:8443   | database-standby | aarch64      | default        |             | ONLINE | Fully operational |
+---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+
```

ここのクラスタメンバーについてより詳細な情報を見るには、以下のコマンドを実行します。

    lxc cluster show <member_name>

クラスタメンバーの状態と使用状況を見るには、以下のコマンドを実行します。

    lxc cluster info <member_name>

## クラスタを設定するには

クラスタを設定するには、`lxc config` を使用します。
例えば以下のようにします。

    lxc config set cluster.max_voters 5

いくつかの {ref}`サーバー設定 <server>` はグローバルで他はローカルであることに注意してください。
グローバル設定はどのクラスタメンバー上でも実行でき、変更は分散データベースを通して他のクラスタメンバーにも伝搬されます。
ローカル設定は設定したサーバー上でのみ (あるいは `--target` で指定したサーバー上でのみ) 変更されます。

サーバー設定に加えて、各クラスタメンバーに固有ないくつかのクラスタ設定があります。
利用可能な設定の全てについては {ref}`cluster-member-config` を参照してください。

これらの設定を変更するには、`lxc cluster set` か `lxc cluster edit` を使用します。
例えば以下のようにします。

    lxc cluster set server1 scheduler.instance manual

### メンバーロールを割り当てる

クラスタメンバーに {ref}`メンバーロール <clustering-member-roles>` を追加または削除するには `lxc cluster role` コマンドを使用します。
例えば以下のようにします。

    lxc cluster role add server1 event-hub

```{note}
LXD で自動で割り当てられないロールのみが追加または削除できます。
```

### クラスタメンバー設定を編集する

メンバー固有設定、メンバーロール、failure domain とクラスタグループを含むクラスタメンバーのプロパティを編集するには `lxc cluster edit` コマンドを使用します。

(cluster-evacuate)=
## クラスタメンバーの退避と復元

既存のクラスタメンバーの全てのインスタンスを空にしたい (例えば再起動が必要なシステムのアップデートを適用するような日常のメンテナンスやハードウェアの変更を行う場合など) ようなケースがあります。

このためには `lxc cluster evacuate` コマンドを使用します。
このコマンドは指定したサーバー上の全てのインスタンスを他のクラスタメンバーに移動します。
退避したクラスタメンバーは "evacuated" 状態になり、このメンバー上でインスタンスの作成はできなくなります。

各インスタンスがどのように移動するかは [`cluster.evacuate`](instance-options-misc) インスタンス設定で制御できます。
インスタンスは `boot.host_shutdown_timeout` 設定にしたがってクリーンにシャットダウンされます。

退避したサーバーが再び利用可能になったときに、サーバーを通常の稼働状態に戻すには `lxc cluster restore` コマンドを使用します。
このコマンドは退避したインスタンスを一時的に保持していたサーバーから戻します。

(cluster-automatic-evacuation)=
### 自動での退避

[`cluster.healing_threshold`](server-options-cluster)設定をゼロでない値に設定すると、クラスタメンバーがオフラインになったら、インスタンスは自動的に退避されます。

退避されたサーバーが再び利用可能になったら、手動で復元する必要があります。

(cluster-manage-delete-members)=
## クラスタメンバーを削除する

クラスタからメンバーをクリーンに削除するには以下のコマンドを使用します。

    lxc cluster remove <member_name>

オンラインでインスタンスが 1 つも存在しないメンバーだけがクリーンに削除できます。

### オフラインのクラスタメンバーの強制削除

クラスタメンバーが恒久的にオフラインになった場合、クラスタメンバーをクラスタから強制削除できます。
メンバーを復旧できないと気づいたらすぐに削除するようにしてください。
クラスタにオフラインのメンバーを残しておくと、クラスタを新しいバージョンにアップグレードする際に問題が起きるかもしれません。

クラスタメンバーを強制削除するには、引き続きオンラインになっているクラスタメンバーの1つで以下のコマンドを入力します。

    lxc cluster remove --force <member_name>

```{caution}
クラスタメンバーを強制削除するとメンバーのデータベースが不整合な状態 (例えば、メンバー上のストレージプールが削除されないなど) のままになります。
結果として、後で LXD を再び初期化できなくなり、サーバーを完全に再インストールするしかなくなります。
```

## クラスタメンバーをアップグレードする

クラスタをアップグレードするには、全てのメンバーをアップグレードする必要があります。
全てのメンバーを同じ LXD のバージョンにアップグレードしなければなりません。

```{caution}
オフラインのメンバーがいる場合はクラスタをアップグレードしないでください。
オフラインのメンバーはアップグレードできず、クラスタがブロックした状態になってしまいます。

さらに snap をお使いの場合、アップグレードは自動で実行されますので、問題を避けるためには、オフラインメンバーを直ちに復旧するか削除するほうが良いです。
```

単一のメンバーをアップグレードするには、単にそのホスト上で LXD パッケージをアップグレードして LXD デーモンを再起動します。
例えば、snap を使用していれば、LXDを現在のチャンネルの最新バージョンとコホートにリフレッシュ(さらにLXDをリロード)します。

    sudo snap refresh lxd --cohort="+"

新しいバージョンのデーモンがデータベーススキーマまたは API に変更がある場合、アップグレードされたメンバーは "blocked" 状態に遷移するかも知れません。
この場合、メンバーは LXD API リクエストに応答しなくなります (これはこのメンバー上では `lxc` コマンドがもはや使用きなくなることを意味します) が、稼働中のインスタンスは引き続き稼働します。

これはアップグレードされておらず古いバージョンを稼働している他のクラスタメンバーがある場合に発生します。
ブロックされているメンバーがあるかを確認するには、ブロックされていないクラスタメンバー上で `lxc cluster list` を実行します。

残りのクラスタメンバーのアップグレードを進めると、それら全てのメンバーが "blocked" 状態になります。
最後のメンバーをアップグレードすると、ブロックされたメンバーは全てのサーバーが最新になったことを検知し、ブロックされたメンバーが再び使用可能になります。

## クラスタ証明書をアップグレードする

LXD クラスタ内で全てのサーバー上の API は同じ共有された証明書で応答します。これは通常有効期限が 10 年に設定されたごく普通の自己署名証明書です。

証明書は `/var/snap/lxd/common/lxd/cluster.crt` (snap を使用している場合) か `/var/lib/lxd/cluster.crt` (それ以外の場合) に保管され、全てのクラスタメンバー上で同じです。

この自己署名証明書を別の証明書、例えば、 ACME サービス経由で得られた有効な証明書 (詳細は {ref}`authentication-server-certificate` を参照) に置き換えることができます。
そのためには `lxc cluster update-certificate` コマンドを使用します。
このコマンドはクラスタ内の全てのサーバーの証明書を置き換えます。