(cluster-manage)= # クラスタを管理するには クラスタを形成した後、メンバーの一覧と状態を見るには [`incus cluster list`](incus_cluster_list.md) を使用します: ```{terminal} :input: incus 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 | +---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+ ``` ここのクラスタメンバーについてより詳細な情報を見るには、以下のコマンドを実行します: incus cluster show クラスタメンバーの状態と使用状況を見るには、以下のコマンドを実行します: incus cluster info ## クラスタを設定するには クラスタを設定するには、[`incus config`](incus_config.md) を使用します。 たとえば: incus config set cluster.max_voters 5 いくつかの {ref}`サーバー設定 ` はグローバルで他はローカルであることに注意してください。 グローバル設定はどのクラスタメンバー上でも実行でき、変更は分散データベースを通して他のクラスタメンバーにも伝搬されます。 ローカル設定は設定したサーバー上でのみ(あるいは `--target` で指定したサーバー上でのみ)変更されます。 サーバー設定に加えて、各クラスタメンバーに固有ないくつかのクラスタ設定があります。 利用可能な設定のすべてについては {ref}`cluster-member-config` を参照してください。 これらの設定を変更するには、[`incus cluster set`](incus_cluster_set.md) か [`incus cluster edit`](incus_cluster_edit.md) を使用します。 たとえば: incus cluster set server1 scheduler.instance manual ### メンバーロールを割り当てる クラスタメンバーに {ref}`メンバーロール ` を追加または削除するには [`incus cluster role`](incus_cluster_role.md) コマンドを使用します。 たとえば: incus cluster role add server1 event-hub ```{note} Incus で自動で割り当てられないロールのみが追加または削除できます。 ``` ### クラスタメンバー設定を編集する メンバー固有設定、メンバーロール、failure domain とクラスタグループを含むクラスタメンバーのプロパティを編集するには [`incus cluster edit`](incus_cluster_edit.md) コマンドを使用します。 (cluster-evacuate)= ## クラスタメンバーの退避と復元 既存のクラスタメンバーのすべてのインスタンスを空にしたい(たとえば再起動が必要なシステムのアップデートを適用するような日常のメンテナンスやハードウェアの変更を行う場合など)ようなケースがあります。 このためには [`incus cluster evacuate`](incus_cluster_evacuate.md) コマンドを使用します。 このコマンドは指定したサーバー上のすべてのインスタンスを他のクラスタメンバーに移動します。 退避したクラスタメンバーは "evacuated" 状態になり、このメンバー上でインスタンスの作成はできなくなります。 各インスタンスがどのように移動するかは {config:option}`instance-miscellaneous:cluster.evacuate` インスタンス設定で制御できます。 インスタンスは `boot.host_shutdown_timeout` 設定にしたがってクリーンにシャットダウンされます。 退避したサーバーが再び利用可能になったときに、サーバーを通常の稼働状態に戻すには [`incus cluster restore`](incus_cluster_restore.md) コマンドを使用します。 このコマンドは退避したインスタンスを一時的に保持していたサーバーから戻します。 (cluster-automatic-evacuation)= ### クラスタヒーリング Incusは故障したサーバーを自動で検出し修復できます。これは{config:option}`server-cluster:cluster.healing_threshold` 設定をゼロでない値に設定することで実現できます。 クラスタメンバーがオフラインになったとリーダーが判断したらインスタンスは他のサーバーに自動的に退避されます。 故障したサーバーが再び利用可能になったら、それが手動で退避された場合と同じように手動で復元する必要があります。 ```{note} 自動クラスタヒーリングはローカルデバイスを一切使用しない共用ストレージ上のインスタンスにのみ適用されます。 ``` ```{warning} この機能を有効にすると中途半端に接続できない問題の結果としてサーバーがオフラインと判定された場合にデータが破損するリスクがあります。 Incusはハートビートのパケットに反応せずさらにICMPパケットにも反応しない場合にサーバーがオフラインだと判定します。 オフラインと判定されたサーバーが実際にオフラインとなりインスタンスを稼働させないことが非常に大切です。 これを自動的に実現する一つの方法はIncusの`cluster-member-healed`イベントを監視するソフトウェアを稼働させ問題のあるサーバーをBMCやPDUを操作して即座に電源を切ることです。 ``` (cluster-automatic-balancing)= ### クラスタのリバランシング Incusはクラスタメンバー間で負荷を自動的に分散できます。 これはいくつかの設定オプションにより行います: - {config:option}`server-cluster:cluster.rebalance.batch` - {config:option}`server-cluster:cluster.rebalance.cooldown` - {config:option}`server-cluster:cluster.rebalance.interval` - {config:option}`server-cluster:cluster.rebalance.threshold` Incusはすべてのサーバーの負荷を比較し、差異のパーセントがしきい値を超えたら、安全にライブマイグレーションできる仮想マシンの選定を開始し、もっとも負荷の低いサーバーに移動します。 (cluster-manage-delete-members)= ## クラスタメンバーを削除する クラスタからメンバーをクリーンに削除するには以下のコマンドを使用します: incus cluster remove オンラインでインスタンスが 1 つも存在しないメンバーだけがクリーンに削除できます。 ### オフラインのクラスタメンバーの強制削除 クラスタメンバーが恒久的にオフラインになった場合、クラスタメンバーをクラスタから強制削除できます。 メンバーを復旧できないと気づいたらすぐに削除するようにしてください。 クラスタにオフラインのメンバーを残しておくと、クラスタを新しいバージョンにアップグレードする際に問題が起きるかもしれません。 クラスタメンバーを強制削除するには、引き続きオンラインになっているクラスタメンバーの 1 つで以下のコマンドを入力します: incus cluster remove --force ```{caution} クラスタメンバーを強制削除するとメンバーのデータベースが不整合な状態(例えば、メンバー上のストレージプールが削除されないなど)のままになります。 結果として、後で Incus を再び初期化できなくなり、サーバーを完全に再インストールするしかなくなります。 ``` ## クラスタメンバーをアップグレードする クラスタをアップグレードするには、すべてのメンバーをアップグレードする必要があります。 すべてのメンバーを同じ Incus のバージョンにアップグレードしなければなりません。 ```{caution} オフラインのメンバーがいる場合はクラスタをアップグレードしないでください。 オフラインのメンバーはアップグレードできず、クラスタがブロックした状態になってしまいます。 ``` 単一のメンバーをアップグレードするには、単にそのホスト上で Incus パッケージをアップグレードして Incus デーモンを再起動します。 新しいバージョンのデーモンがデータベーススキーマまたは API に変更がある場合、アップグレードされたメンバーは "blocked" 状態に遷移するかも知れません。 この場合、メンバーは Incus API リクエストに応答しなくなります(これはこのメンバー上では `incus` コマンドがもはや使用できなくなることを意味します)が、稼働中のインスタンスは引き続き稼働します。 これはアップグレードされておらず古いバージョンを稼働している他のクラスタメンバーがある場合に発生します。 ブロックされているメンバーがあるかを確認するには、ブロックされていないクラスタメンバー上で [`incus cluster list`](incus_cluster_list.md) を実行します。 残りのクラスタメンバーのアップグレードを進めると、それらすべてのメンバーが "blocked" 状態になります。 最後のメンバーをアップグレードすると、ブロックされたメンバーはすべてのサーバーが最新になったことを検知し、ブロックされたメンバーが再び使用可能になります。 ## クラスタ証明書をアップグレードする Incus クラスタ内ですべてのサーバー上の API は同じ共有された証明書で応答します。これは通常有効期限が 10 年に設定されたごく普通の自己署名証明書です。 証明書は `/var/lib/incus/cluster.crt` に保管され、すべてのクラスタメンバー上で同じです。 この自己署名証明書を別の証明書、たとえば、 ACME サービス経由で得られた有効な証明書(詳細は {ref}`authentication-server-certificate` を参照)に置き換えることができます。 そのためには [`incus cluster update-certificate`](incus_cluster_update-certificate.md) コマンドを使用します。 このコマンドはクラスタ内のすべてのサーバーの証明書を置き換えます。