ホストサーバの診断手順

コマンド操作によって実施できるホストサーバの診断手順を示します。一部は「ブラウザによる診断手順」と内容が重複します。

なお、この診断手順ではホストサーバに SSH でログインして操作する必要があります。診断手順によっては管理者権限が必要になりますのでご注意ください。

ホストサーバの正常性の確認

システムのホストサーバが正常に動作していることを、以下の観点で確認してください。クラスタ構成の場合は全てのノードの状態を確認してください。

SSH またはコンソールで対象ノードにログインできる。
ホスト名およびネットワークアドレスが正しく構成されている。
所属ネットワークへの導通（例えばデフォルトゲートウェイへの ping）が確認できる。

いずれかの確認で問題がある場合は、Kompira システム以前に、まずホストサーバについて適切な保守対応を実施して正常化を行なってください。

ホストサーバの保守手順については、本マニュアルの範囲外になります。

クラスタ構成の場合は、さらに以下も確認してください。

2 台目以上のノードを起動している場合は、クラスタを構成するノード間の導通も確認してください。導通が確認できない場合はクラスタが正常に動作しませんので、ネットワークの状態の確認と正常化を行なってください。
クラスタを構成する半数以下のノードしか起動していない場合は、クラスタとして開始できません。クラスタの開始を参考に適切にクラスタの開始を行なってください。

シングル構成でホストサーバに問題が無い場合、または、クラスタ構成で過半数のノードが正常に動作している場合は、次の診断に進んでください。

ホストサーバのリソース状況の確認

KE2 APP にパフォーマンスの低下（遅延・エラー頻発）が見られる場合、ホストサーバのリソースが過負荷になっている可能性があります。以下を確認してください。クラスタ構成の場合は全てのノードを確認してください。

CPU 使用率
メモリ使用率
ディスク使用率

とくにディスク使用率については、空き容量が少なくなるとシステムが正常に動作できなくなる場合があります。例えば rabbitmq コンテナは空き容量が一定以下（デフォルト 50MB 以下）になると一部の動作を停止します。

参考: 目安としては、常に 200MB 以上の空き容量がある状況を維持してください。

リソース使用率が常に高い（例えば 90% 以上）か、増加し続けて下がらない場合、Docker や KE2 APP でさまざまなエラーが発生する可能性があります。以下では sysstat（sar）による確認手法を示しますが、監視システムの導入も検討してください。

sar コマンドが利用できない場合は、sysstat パッケージをインストールしてください。

CPU 使用率を確認する

数日分の平均 CPU 使用量を確認します（sysstat が以前からインストールされている前提）。
```
$ sar -u -f /var/log/sa/sa$(date --date="1 days ago" +%d)
$ sar -u -f /var/log/sa/sa$(date --date="today" +%d)
```
sysstat が以前からインストールされていなかった場合は最新状況を確認します。
```
$ sar -u 2 30

08:50:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:00:01 PM     all      2.44      1.37      1.82      0.01      0.00     94.37
Average:        all      2.34      1.60      1.81      0.01      0.00     94.24
```
%user または %system 使用率が常に 90% を超える場合は CPU コア数を増やすことを検討してください。増加し続けて下がらない場合は、CPU を多く消費しているプロセスを特定します。
```
$ ps aux --sort=-%cpu | head

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     2956484  1.3  1.0 108636 84416 ?       Sl   Oct29  18:29 kompirad: [Engine-5931] started
root     4041128  0.7  3.8 2974996 299280 ?     Ssl  Oct27  31:20 /usr/bin/dockerd -H fd:// ...
```
KE2 APP に関係する処理（kompirad / kompira_jobmngrd / dockerd など）で高消費の場合は、Docker コンテナで利用のリソース状況の確認を確認してください。

特に kompirad:Executor の CPU 使用量が急増する場合は、ジョブフローの設計や実装を見直してください。

メモリ使用率を確認する

$ sar -r -f /var/log/sa/sa$(date --date="today" +%d)
# sysstat が未導入だった場合
$ sar -r 2 30

08:50:04 PM kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached ...
09:00:00 PM   1499600   2776648   6369344     80.94       132   1455240 ...
Average:      1193391   2697519   6675553     84.83       132   1564541 ...

%memused が常に 90% を超える場合はメモリを増やすことを検討してください。増加し続けて下がらない場合は、メモリを多く消費しているプロセスを特定します。

$ ps aux --sort=-%mem | head

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     4041128  0.7  3.8 2974996 299280 ?     Ssl  Oct27  31:28 /usr/bin/dockerd -H fd:// ...
root     2957006  0.5  2.6 1344704 204640 ?     Sl   Oct29   7:29 /opt/erlang/.../beam.smp ... rabbit ...

ディスクスペースを確認する

$ df -h

Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   38G   13G   25G  34% /
localhost:/gvol0        38G   14G   25G  36% /mnt/gluster

空きスペースが不足している場合は不要なファイルを削除してください。

ホストサーバが高いリソースを使用している場合、Docker デーモンが不安定になる可能性があります。その際は docker ログを確認してください。

クラスタ構成: Docker 不安定性（node underweighting） / error while reading from stream
シングル構成: docker デーモンが不安定

docker の正常動作の確認

全てのノードで docker が正常に動作していることを確認してください。

$ systemctl status docker.service

docker.service - Docker Application Container Engine
     Active: active (running) since Tue 2024-10-01 14:53:15 JST; 1 weeks 2 days ago

Active: active (running) であれば実行中です。何らかの異常で停止している場合は Active: inactive (dead) と表示されます。

docker.service - Docker Application Container Engine
     Active: inactive (dead) since Thu 2024-10-10 16:57:52 JST; 2s ago

停止している場合は起動して再度ステータスを確認してください。

$ systemctl start docker.service

起動しても安定して動作しない場合は docker のログを確認してください。

クラスタ構成: Docker 不安定性（node underweighting）
シングル構成: docker デーモンが不安定
あわせてホストサーバのリソース状況の確認

ネットワーク導通の確認

クライアントとホスト間のネットワーク導通を確認してください。

$ ping -c 5 <HOST_SERVER_IP>

64 bytes from 10.20.47.12: icmp_seq=1 ttl=64 time=0.041 ms
...
5 packets transmitted, 5 received, 0% packet loss, time 4103ms

応答がない場合は次のように表示されます（Destination Host Unreachable など）。

From 10.20.47.12 icmp_seq=1 Destination Host Unreachable
...
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4094ms

この場合は以下を確認してください。

ホストサーバの正常性の確認
KE2 APP ホストサーバのネットワークインターフェイスの状態
KE2 APP ホストサーバの Network 設定

クラスタ構成の場合は、KE2 APP ホストサーバの全ノード間のネットワーク導通も確認してください。導通に問題があるときは docker ログにエラーが記録されている場合があります。

ping が成功していても高い遅延・パケットロスがある場合があります（ping -c 10 -i 2 <IP> で確認）。高遅延の場合、docker ログに以下が表示される可能性があります。

ネットワークの保守手順については、本マニュアルの範囲外になります。

KE2 APP ホストサーバと外部データベース間のネットワーク導通の確認

外部DBシングル構成・Swarmクラスタ構成では外部 DB が使用されます。KE2 APP ホストサーバと外部データベース間のネットワーク接続に問題があると、kompira / kengine コンテナに直接影響します。

外部 DB サーバへ ping しても応答がない場合は、外部 DB ホストサーバの正常性・ネットワークインターフェイス・Network 設定を確認してください。KE2 のログには以下が記録される可能性があります。

docker ログ: 外部データベースまたは Swarm ノードとの高いネットワーク遅延
kengine ログ: 外部 DB へ到達不可（Host is unreachable）

ping が成功していても高い遅延の可能性があります（ping -c 10 -i 2 <DB_IP>）。高遅延・パケットロスがあれば解決してください。

外部 DB で Pgpool を利用している場合、Pgpool ノード間のネットワーク遅延も確認してください。問題があると KE2 に影響し、ログに以下が表示される可能性があります。

pgpool ノード間の不整合（unable to read message kind）

ネットワークの保守手順については、本マニュアルの範囲外になります。

外部データベースへのアクセス確認

KE2 APP のホストサーバから外部 DB にアクセスできるか確認します。

psql コマンドが利用できない場合は、CentOS/RHEL: postgresql、Debian/Ubuntu: postgresql-client をインストールしてください。

# pgpool 場合 DB IP は Virtual IP、DB PORT は既定 9999。postgres 場合は DB サーバ IP、既定 5432。USER は postgres、DATABASE は kompira。
$ psql -h <DB_IP> -p <DB_PORT> -U postgres -d kompira -c "SELECT 1;"

アクセスに失敗する場合（No route to host など）は、DB サーバダウンまたはネットワーク到達不可が考えられます。KE2 のログに以下が記録される場合があります。

外部 DB が停止（Connection refused）

DB 操作の確認

$ psql -h <DB_IP> -p <DB_PORT> -U postgres -d kompira -c "CREATE TEMP TABLE pg_temp.test_table (value TEXT); INSERT INTO pg_temp.test_table (value) VALUES ('Dummy Test Value'); SELECT * FROM pg_temp.test_table;"

問題があれば外部 DB 管理者に連絡してください。KE2 のログに以下が記録される場合があります。

読み取り専用トランザクション（cannot execute UPDATE in a read-only transaction）

外部 DB の保守手順については、本マニュアルの範囲外になります。

クラスタ構成における共有ファイルシステム glusterd の正常動作の確認

全てのノードで glusterd が正常に動作していることを確認してください。

$ systemctl status glusterd

glusterd.service - GlusterFS, a clustered file-system server
     Active: active (running) since Mon 2024-09-23 19:31:39 JST; 3 weeks 3 days ago

Active: active (running) であれば実行中です。停止している場合は Active: inactive (dead) と表示されます。停止している場合は起動して再度ステータスを確認してください。

$ systemctl start glusterd

起動しても不安定な場合は、主にホストサーバのリソースが正常かどうかを確認してください（ホストサーバのリソース状況の確認）。

クラスタの glusterfs ボリューム自体の正常性確認はクラスタノードの診断手順を参照してください。

Kompira Enterprise 2.0 管理者マニュアル