クラスタノードの診断手順

共有ファイルシステム (glusterfs)の正常性確認

glusterd の正常性確認

すべての glusterd ノードの `State` が `Connected` であることを確認してください。

```bash
$ gluster pool list

UUID					Hostname          	State
448d38ce-bc9c-4bca-ae77-8876cbb4ab32	ke2-rhel89-swarm-1	Connected 
28cdd9bc-4a49-48ac-a7ab-635f35e90bda	ke2-rhel89-swarm-3	Connected 
0760ce31-9b1e-4697-980e-721bbd0f4862	localhost         	Connected 
```

- いずれかの gluster ノードの State が Disconnected 状態になっている場合は、そのホストの glusterd サービスが正常に動作していなかったり、ネットワークに問題が生じているといった可能性があります。
    ```bash
    $ gluster pool list

    UUID					Hostname          	State
    448d38ce-bc9c-4bca-ae77-8876cbb4ab32	ke2-rhel89-swarm-1	Disconnected 
    28cdd9bc-4a49-48ac-a7ab-635f35e90bda	ke2-rhel89-swarm-3	Connected 
    0760ce31-9b1e-4697-980e-721bbd0f4862	localhost         	Connected
    ```

    このような状況の場合、以下の確認を行なってみてください。
    - [ホストサーバの正常性の確認](./host-server-diag.html#diag-a1-ホストサーバの正常性の確認)
    - [クラスタ構成における共有ファイルシステム glusterd の正常動作の確認](./host-server-diag.html#diag-a7-クラスタ構成における共有ファイルシステム-glusterd-の正常動作の確認)
    - [ネットワーク導通の確認](./host-server-diag.html#diag-a4-ネットワーク導通の確認)

    上記の対策を行なっても回復しない場合は、サポートまでお問い合わせください

gluster ボリューム の正常性確認

すべてのノードの gluster ボリューム状態 `Status` が `Started` であることを確認してください。
```bash
$ gluster volume info

Volume Name: gvol0
Type: Replicate
Volume ID: 71d358be-7b95-4c03-a528-9cb15d37a3c3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: ke2-rhel89-swarm-1:/var/glustervol0
Brick2: ke2-rhel89-swarm-2:/var/glustervol0
Brick3: ke2-rhel89-swarm-3:/var/glustervol0
Options Reconfigured:
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
```

- ボリューム `Status` が `Stopped` になっている場合、 そのノードのボリュームが停止されてしまったの可能性があります。
    ```bash
    $ gluster volume info

    Volume Name: gvol0
    Type: Replicate
    Volume ID: 71d358be-7b95-4c03-a528-9cb15d37a3c3
    Status: Stopped
    Snapshot Count: 0
    Number of Bricks: 1 x 3 = 3
    Transport-type: tcp
    Bricks:
    Brick1: ke2-rhel89-swarm-1:/var/glustervol0
    Brick2: ke2-rhel89-swarm-2:/var/glustervol0
    Brick3: ke2-rhel89-swarm-3:/var/glustervol0
    Options Reconfigured:
    cluster.granular-entry-heal: on
    storage.fips-mode-rchecksum: on
    transport.address-family: inet
    nfs.disable: on
    performance.client-io-threads: off
    ```

    この状況なら以下のコマンドでボリュームを起動してください。
    ```bash
    $ gluster volume start <volume-name>

    volume start: <volume-name>: success
    ```

gluster ボリュームのマウントの正常性確認

すべての glusterd ノードにおいて gluster ボリュームがマウントされていることを確認してください。mount コマンドを実行すると `localhost:/gvol0 on /mnt/gluster` という表示があるはずです
```bash
$ mount | grep gluster

localhost:/gvol0 on /mnt/gluster type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
```

gluster ボリュームがマウントされていない場合は、以下のコマンドでマウントしてください。
 ```bash
 $ mount -t glusterfs localhost:/gvol0 /mnt/gluster
 ```

＊ 特定のノードで gluster ボリュームが正しくマウントされない場合は、kompira コンテナのログで以下のようなエラーが記録されることがあります。

swarm ノードのステータスの正常性確認

swarm ノードの正常性については、docker node ls コマンドの結果から以下を確認してください。

  • すべてのノードの STATUS が Ready であること。
  • すべてのノードの Availability が Active であること。
  • MANAGER STATUS については、1 台が Leader であり、残りのノードが Reachable であること。
  • すべてのノードの ENGINE VERSION が同一であること。
$ docker node ls

ID                            HOSTNAME             STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
fki8ndj78y2khgyt7j6xn2duf     ke2-rhel89-swarm-1   Ready     Active         Reachable        26.1.3
ly4ik4v3pw9rgom0htt281aus *   ke2-rhel89-swarm-2   Ready     Active         Reachable        26.1.3
if1r8znj7v7dsym4r9ya26gmt     ke2-rhel89-swarm-3   Ready     Active         Leader           26.1.3

  • マネージャーの半数以上がオンラインでない、または正常でない場合、次のエラーが発生します。

    $ docker node ls

Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader.
It's possible that too few managers are online. Make sure more than half of the managers are online.

    このような状況の場合、全てのノードで以下の診断手順を行なってみてください。

    上記の調査で問題を見つけて修正した場合、あらためて docker node ls コマンドを実行して Swarm ノードの状況を確認してください。STATUS、AVAILABILITY、MANAGER STATUS などが正常であれば、KE2 クラスタは正常であると言えます。

    まだ、swarm クラスタは正常ではない場合、必要なポートが開いていない可能性があります。この場合、ファイアウォールの設定 を見てください。

    それでも swarm クラスタが正常に戻らない場合は、各 VM を一度再起動してみてください。Docker の自動起動設定が有効であれば、swarm クラスタは正常に戻るはずです。

    swarm クラスタが正常に戻っても KE2 APP が全体的に操作しない可能性があります。

    その時、まずはすべてのノードの gluster ボリュームの正常性確認を行ってください。そして、KE2 APPを以下の手順で再デプロイしてください。

    [いずれかのノード]$ docker stack rm ke2
[いずれかのノード]$ cd ke2/cluster/swarm
[いずれかのノード]$ docker stack deploy -c docker-swarm.yml ke2

    最後に、KE2 APP の全体ステータスをご確認ください。

  • もしいずれかのノードの MANAGER STATUS が Unreachable と STATUS が Down 状態になっている場合、 そのノードが止めされてしまったの可能性があります。

    $ docker node ls

ID                            HOSTNAME             STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
fki8ndj78y2khgyt7j6xn2duf     ke2-rhel89-swarm-1   Down      Active         Unreachable      26.1.3
ly4ik4v3pw9rgom0htt281aus *   ke2-rhel89-swarm-2   Ready     Active         Reachable        26.1.3
if1r8znj7v7dsym4r9ya26gmt     ke2-rhel89-swarm-3   Ready     Active         Leader           26.1.3

    上の状況が起きた場合、問題があるノードで以下の分析を行ってください。

    問題が解決できない場合、必要なポートが開いていない可能性があります。この場合、ファイアウォールの設定 を見てください。

    それでも問題が解決しない場合は、問題があるノードを再起動してください。docker と glusterfs 自動起動設定があれば特定の ホストの swarm node と 関係があるコンテナが自動回復になります。

    そして、KE2 APP の全体ステータスをみてください。

上記の対策を行なっても回復しない場合は、サポートまでお問い合わせください。