ホストサーバの診断手順
システム操作によって実施できる診断手順を以下に示します。 一部は「ユーザ操作による診断手順」と診断内容が重複しているものもあります。
なお、この診断手順ではホストサーバに SSH でログインして操作する必要があります。 また診断手順によっては管理者権限が必要になりますのでご注意ください。
DIAG-A1: ホストサーバの正常性の確認
システムのホストサーバが正常に動作していることを、以下のような観点で確認してください。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。
- SSH またはコンソールで対象ノードにログインできる。
- ホスト名およびネットワークアドレスが正しく構成されている。
- 所属ネットワークへの導通（例えばデフォルトゲートウェイへの ping）が確認できる。
いずれかの確認で問題があるような場合は、Kompira システム以前にまずご利用になっているホストサーバについて、適切な保守対応を実施して正常化を行なってください。
ホストサーバの保守手順については、本マニュアルの範囲外になります。
クラスタ構成の場合は、さらに以下のような観点でも確認を行なってください。
- 2台目以上のノードを起動している場合は、クラスタを構成するノード間の導通についても確認してください。
- ノード間の導通が確認できないような場合はクラスタが正常に動作しませんので、ネットワークの状態の確認と正常化を行なってください。
- ネットワークの保守対応はこちらのマニュアルの範囲外となります。
- ノード間の導通が確認できないような場合はクラスタが正常に動作しませんので、ネットワークの状態の確認と正常化を行なってください。
- クラスタを構成する半数以下のノードしか起動していない場合は、クラスタとして開始できません。
- クラスタの開始 を参考に適切にクラスタの開始を行なってください。
シングル構成でホストサーバに問題が無い場合、または、クラスタ構成で過半数のノードが正常に動作している場合は、次の診断に進んでください。
DIAG-A2: ホストサーバのリソース状況の確認
KE2 APP にパフォーマンスの低下が見られる場合（例えば、KE2 APP が遅くなったり、エラーが頻発したりする場合）、KE2 APP のホストサーバーのリソースが過負荷になっている可能性があります。そのような場合には、ホストサーバーのリソース状況を確認することが重要です。 クラスタ構成の場合は全てのノードの状態を確認するようにしてください。
- CPU 使用率
- メモリ使用率
- ディスク使用率
とくにディスク使用率については、空き容量が少なくなるとシステムが正常に動作できなくなる場合があります。 例えば rabbitmq コンテナは自身でディスクの空き容量をモニタリングしていて、空き容量が一定以下（デフォルトでは 50MB 以下）になると一部の動作を停止するようになっています。この状況になると Kompira システムとしても正常に動作できなくなりますので、注意してください。
参考: 目安としては、常に 200MB 以上の空き容量がある状況を維持するようにしてください。
ホストサーバの保守手順については、本マニュアルの範囲外になります。
リソース使用率が常に高く、例えば90%以上であるか、増加し続けて下がらない場合、リソース不足の状況が発生し、DockerやKE2 APPでさまざまなエラーが発生する可能性があります。
システム運用中のリソース状況を確認できるようにすることは重要になりますが、KE2 の標準のデプロイ手順では過去のリソース状況を確認するシステムなどは導入されません。
以下では Linux サーバ自身で簡単にリソース状況を確認できる sysstat を用いた手法を紹介しますが、監視システムを導入して本格的にリソース監視を行なうことも検討してください。
sar コマンドが利用できない場合は、sysstat パッケージをインストールしてください。
-
CPU 使用率を確認する
ホストサーバの CPU 負荷の履歴を確認するために、以下のコマンドを実行して数日の平均CPU使用量を確認します。
数日前に、sysstat パッケージがインストールされていたと仮定します
$ sar -u -f /var/log/sa/sa$(date --date="3 days ago" +%d) $ sar -u -f /var/log/sa/sa$(date --date="2 days ago" +%d) $ sar -u -f /var/log/sa/sa$(date --date="1 days ago" +%d) $ sar -u -f /var/log/sa/sa$(date --date="today" +%d)上の各コマンドで以下のような結果が表示されます。
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 09:10:21 PM all 2.28 1.31 1.80 0.01 0.00 94.60 09:20:01 PM all 2.34 1.53 1.73 0.01 0.00 94.40 09:30:15 PM all 1.93 1.09 1.37 0.01 0.00 95.60 09:40:01 PM all 1.79 0.84 1.29 0.01 0.00 96.08 09:50:00 PM all 1.92 1.03 1.36 0.01 0.00 95.69 10:00:31 PM all 1.88 1.07 1.38 0.01 0.00 95.67 10:10:31 PM all 1.85 0.78 1.36 0.01 0.00 96.01 10:20:01 PM all 1.96 0.99 1.41 0.01 0.00 95.63 10:30:01 PM all 2.12 1.26 1.48 0.01 0.00 95.14 10:40:08 PM all 1.95 1.02 1.43 0.01 0.00 95.59 10:50:01 PM all 2.12 1.29 1.47 0.01 0.00 95.12 11:00:11 PM all 1.87 0.91 1.41 0.01 0.00 95.81 11:10:21 PM all 2.09 1.42 1.51 0.03 0.00 94.95 11:20:31 PM all 1.99 1.08 1.50 0.01 0.00 95.41 11:30:05 PM all 1.92 1.03 1.49 0.01 0.00 95.55 11:40:00 PM all 2.08 1.20 1.56 0.01 0.00 95.15 11:50:31 PM all 1.95 1.09 1.50 0.01 0.00 95.46 Average: all 2.34 1.60 1.81 0.01 0.00 94.24ホストサーバに sysstat パッケージが以前からインストールされていなかった場合は、以下のコマンドで最新の状況を確認してください。
$ sar -u 2 30結果の各行にご注意ください。特に %user または %system 使用率が高いか常に90%を超えている場合、CPU コア数を増やすことをお勧めします。
定常的に %user または %system の使用率が増加し続けて下がらない場合、何らかの処理が CPU を大量に消費している可能性があります。以下のコマンドで CPU を多く消費しているプロセスを一覧表示します。
$ ps aux --sort=-%cpu | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND setroub+ 3196005 26.1 1.7 748920 139356 ? SNsl 08:24 0:01 /usr/libexec/platform-python -Es /usr/sbin/setroubleshootd -f root 3196021 18.2 1.0 585332 86228 ? Sl 08:24 0:00 /usr/libexec/platform-python /usr/share/setroubleshoot/SetroubleshootPrivileged.py root 2956484 1.3 1.0 108636 84416 ? Sl Oct29 18:29 kompirad: [Engine-5931] started root 2957605 1.3 1.1 113892 94288 ? Sl Oct29 18:38 kompirad: [Executor-1] started root 2957588 0.7 1.0 103240 86180 ? Sl Oct29 9:58 kompirad: [Executor-0] started root 2957623 0.7 1.0 102208 84336 ? Sl Oct29 10:15 kompirad: [Executor-2] started root 2957645 0.7 1.0 97256 80736 ? Sl Oct29 10:07 kompirad: [Executor-3] started root 4041128 0.7 3.8 2974996 299280 ? Ssl Oct27 31:20 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock root 2957285 0.6 0.5 56088 43292 ? Sl Oct29 9:50 kompira_jobmngrd: [JobManager] started上記のコマンドを毎回実行し、高いリソース使用率が増加し続けて下がらないプロセスを調査します。 KE2 APP に関係がある処理 (たとえあば kompirad や kompira_jobmngrd や dockerd など) で高いリソースを消費している場合、Docker コンテナでご利用リソースの状況をご確認ください。
特に、kompirad:Executor の CPU 使用量が急増し、非常に高い場合は、ジョブフローの設計や実装を見直してください。
それ以外の処理で高いリソースを消費している場合、システム管理者と連携して、リソースを解放するために必要な手順を講じてください。必要ならサーバスペック、コア数を増やしてください。ホストサーバーの再起動は、一時的な解決策かもしれません。
-
メモリ使用率を確認する
ホストサーバのメモリ負荷の履歴を確認するために、以下のコマンドを実行して数日の平均メモリ使用量を確認します。
数日前に、sysstat パッケージがインストールされていたと仮定します
$ sar -r -f /var/log/sa/sa$(date --date="3 days ago" +%d) $ sar -r -f /var/log/sa/sa$(date --date="2 days ago" +%d) $ sar -r -f /var/log/sa/sa$(date --date="yesterday" +%d) $ sar -r -f /var/log/sa/sa$(date --date="today" +%d)上記の各コマンド実行すると以下のような結果が表示されます。
08:50:04 PM kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:00:00 PM 1499600 2776648 6369344 80.94 132 1455240 8134220 55.78 1025128 4286144 1364 09:10:14 PM 1515532 2775416 6353412 80.74 132 1438076 8137516 55.80 1025540 4270032 1352 09:20:02 PM 1516612 2778204 6352332 80.73 132 1439784 8136328 55.80 1025964 4268600 92 09:30:13 PM 1511668 2775028 6357276 80.79 132 1441556 8129160 55.75 1026384 4272116 1360 09:40:07 PM 1505828 2770888 6363116 80.86 132 1451448 8143276 55.84 1026792 4279196 88 09:50:07 PM 1503888 2770660 6365056 80.89 132 1453160 8144972 55.86 1027216 4280068 1408 10:00:08 PM 1499524 2768044 6369420 80.94 132 1454908 8144748 55.85 1027640 4283828 1368 10:10:20 PM 1618340 2888632 6250604 79.43 132 1456668 8024212 55.03 1028060 4164820 120 10:20:00 PM 1425136 2697108 6443808 81.89 132 1458360 8367948 57.38 1028472 4355864 1388 10:30:19 PM 1492616 2766388 6376328 81.03 132 1460160 8138932 55.81 1028908 4288252 1352 10:40:00 PM 1492240 2767680 6376704 81.04 132 1461832 8144272 55.85 1029316 4289300 104 10:50:07 PM 1609696 2886836 6259248 79.54 132 1463512 8018288 54.99 1029720 4172520 88 11:00:09 PM 1606720 2885612 6262224 79.58 132 1465280 8022040 55.01 1030156 4174036 44 11:10:00 PM 1606476 2887048 6262468 79.58 132 1466952 8001308 54.87 1030560 4174380 64 11:20:09 PM 1602572 2884868 6266372 79.63 132 1468684 8030580 55.07 1030980 4177176 44 11:30:31 PM 1411720 2695804 6457224 82.06 132 1470476 8231824 56.45 1031420 4366480 100 11:40:07 PM 1589248 2874944 6279696 79.80 132 1480260 8035704 55.11 1031788 4189460 12 11:50:04 PM 1470172 2757572 6398772 81.32 132 1481984 8151500 55.90 1032192 4307644 1400 Average: 1193391 2697519 6675553 84.83 132 1564541 8103370 55.57 999682 4408849 892ホストサーバに sysstat パッケージが以前からインストールされていなかった場合は、以下のコマンドで最新の状況を確認してください。
$ sar -r 2 30結果の各行にご注意ください。特にに %user または %memused の使用率が高いか常に90%を超えている場合、メモリを増やすことをお勧めします。
定常的に %memused の使用率が増加し続けて下がらない場合、何らかの処理がメモリを大量に消費している可能性があります。以下のコマンドでメモリを多く消費しているプロセスを特定します。
$ 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:// --containerd=/run/containerd/containerd.sock root 3021 0.0 2.6 1010536 212360 ? Ssl Oct03 2:19 /usr/libexec/packagekitd root 2957006 0.5 2.6 1344704 204640 ? Sl Oct29 7:29 /opt/erlang/lib/erlang/erts-14.2.5.4/bin/beam.smp -W w -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -pc unicode -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -sbwt none -sbwtdcpu none -sbwtdio none -B i -- -root /opt/erlang/lib/erlang -bindir /opt/erlang/lib/erlang/erts-14.2.5.4/bin -progname erl -- -home /var/lib/rabbitmq -- -pa -noshell -noinput -s rabbit boot -boot start_sasl -syslog logger [] -syslog syslog_error_logger false -kernel prevent_overlapping_partitions false root 746 0.0 2.3 317296 183364 ? Ss Oct03 8:20 /usr/lib/systemd/systemd-journald setroub+ 3201072 19.3 1.7 749188 141352 ? SNsl 08:53 0:01 /usr/libexec/platform-python -Es /usr/sbin/setroubleshootd -f root 3188193 0.1 1.6 11859744 126852 ? Sl 07:39 0:07 /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/node --dns-result-order=ipv4first /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false root 2957605 1.3 1.1 113492 93920 ? Sl Oct29 19:00 kompirad: [Executor-1] started root 2957395 0.6 1.1 108984 88792 ? Sl Oct29 8:58 uwsgi --module=kompira_site.wsgi:application --env DJANGO_SETTINGS_MODULE=kompira_site.settings --master --pidfile=/tmp/kompira-master.pid --processes=5 --socket=0.0.0.0:8000 --enable-threads root 3188153 0.0 1.0 1332228 86480 ? Sl 07:39 0:04 /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/node /root/.vscode-server/cli/servers/Stable-4849ca9bdf9666755eb463db297b69e5385090e3/server/out/server-main.js --connection-token=remotessh --accept-server-license-terms --start-server --enable-remote-auto-shutdown --socket-path=/tmp/code-84732503-7e19-4e61-9cec-d73ea5bb62ee上記のコマンドを毎回実行し、高いリソース使用率が増加し続けて下がらないプロセスを調査します。 KE2 APP に関係がある処理 (たとえあば kompirad や kompira_jobmngrd や uwsgi や dockerd など) で高いリソースを消費している場合、Docker コンテナでご利用リソースの状況をご確認ください。
特に Executor のメモリ使用量が急増するようであればジョブフローの設計や実装を見直してください。
それ以外の処理で高いリソースを消費している場合、システム管理者と連携して、リソースを解放するために必要な手順を講じてください。必要ならサーバスペック、メモリを増やしてください。ホストサーバーの再起動は、一時的な解決策かもしれません。
-
VM で利用可能なディスクスペースを確認する:
[ke2-rhel89-swarm-1]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.8G 0 3.8G 0% /dev/shm tmpfs 3.8G 426M 3.4G 12% /run tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/mapper/rhel-root 38G 13G 25G 34% / /dev/sda2 1014M 267M 748M 27% /boot /dev/sda1 599M 5.8M 594M 1% /boot/efi /dev/mapper/rhel-home 19G 180M 19G 1% /home tmpfs 769M 12K 769M 1% /run/user/42 tmpfs 769M 0 769M 0% /run/user/0 localhost:/gvol0 38G 14G 25G 36% /mnt/gluster空きディスクスペースが十分にあるか確認します。空きスペースが不足している場合は不要なファイルを削除します。
ホストサーバーが高いリソースを使用している場合、Dockerデーモンが不安定になる可能性があります。その際、Dockerのログには以下のようなエラーが表示される可能性があります。
クラスタ構成の場合、
シングル構成の場合、
DIAG-A3: docker の正常動作の確認
全てのノードで docker が正常に動作していることを確認してください。
-
docker が実行中場合
以下のコマンドで
Active: active (running)と表示されていれば、Docker は実行中です。$ systemctl status docker.service docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2024-10-01 14:53:15 JST; 1 weeks 2 days ago Docs: https://docs.docker.com Main PID: 1489 (dockerd) Tasks: 15 Memory: 563.4M CGroup: /system.slice/docker.service └─1489 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock -
docker が停止している場合
以下のコマンドで Active: inactive (dead) と表示されている場合は、Docker は何らかの異常が発生して停止しています。
$ systemctl status docker.service docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: inactive (dead) since Thu 2024-10-10 16:57:52 JST; 2s ago Docs: https://docs.docker.com Process: 1489 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=0/SUCCESS) Main PID: 1489 (code=exited, status=0/SUCCESS)停止してしまった場合、まず、以下のコマンドで Docker を起動し、再度ステータスを確認します。
$ systemctl start docker.service何らかの異常が残っている場合は、docker を起動しても安定して動作できないこともあります。そうしたときは docker のログを確認してみてください。
クラスタ構成の場合、
シングル構成の場合、
＊ Docker デーモンの不安定はさまざまな原因で発生する可能性がありますが、通常はサーバーリソースが原因です。
DIAG-A4: ネットワーク導通の確認
-
クライアントとホスト間のネットワーク導通を確認してください。
# [クライアント]$ ping -c 5 <KE2 APP ホストサーバ IP> # 例: $ ping -c 5 10.20.47.12 PING 10.20.47.12 (10.20.47.12) 56(84) bytes of data. 64 bytes from 10.20.47.12: icmp_seq=1 ttl=64 time=0.041 ms 64 bytes from 10.20.47.12: icmp_seq=2 ttl=64 time=0.028 ms 64 bytes from 10.20.47.12: icmp_seq=3 ttl=64 time=0.036 ms 64 bytes from 10.20.47.12: icmp_seq=4 ttl=64 time=0.032 ms 64 bytes from 10.20.47.12: icmp_seq=5 ttl=64 time=0.032 ms --- 10.20.47.12 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4103ms rtt min/avg/max/mdev = 0.028/0.033/0.041/0.008 ms応答があることを確認してください。答えがない場合以下ような結果が表示される。
# [クライアント]$ ping -c 5 <KE2 APP ホストサーバ IP> # 例： $ ping -c 5 10.20.47.12 PING 10.20.47.12 (10.20.47.12) 56(84) bytes of data. From 10.20.47.12 icmp_seq=1 Destination Host Unreachable From 10.20.47.12 icmp_seq=2 Destination Host Unreachable From 10.20.47.12 icmp_seq=3 Destination Host Unreachable From 10.20.47.12 icmp_seq=4 Destination Host Unreachable From 10.20.47.12 icmp_seq=5 Destination Host Unreachable --- 10.20.47.12 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4094ms pipe 3様々な理由でこのようなこのような状況発生される可能性があります。
- ホストサーバの正常性の確認
- KE2 APP ホストサーバのネットワークインターフェイスの状態を確認してください
- KE2 APP ホストサーバの Network 設定確認してください。
＊ クラスタ構成の場合、上と同じようにクライアントと各ホスト間のネットワーク導通を確認してください。
-
クラスタ構成の場合、KE2 APP ホストサーバの全てのノード間のネットワーク導通を確認してください。
-
pingコマンドで応答があることを確認してください。応答がない場合は、以下のような調査をしてみてください。- ホストサーバの正常性の確認
- KE2 APP ホストサーバのネットワークインターフェイスの状態を確認してください
- KE2 APP ホストサーバの Network 設定確認してください。
ノード間のネットワーク導通に問題があるときは、docker ログにエラーが記録されている場合がありますので、以下について確認してみてください。
-
pingが成功になっていますが高い遅延の可能性もあります。$ ping -c 10 -i 2 10.20.47.11 PING 10.20.47.11 (10.20.47.11) 56(84) bytes of data. Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 64 bytes from 10.20.47.11: icmp_seq=4 ttl=57 time=2002 ms Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 64 bytes from 10.20.47.11: icmp_seq=7 ttl=57 time=2003 ms Request timeout for icmp_seq 8 Request timeout for icmp_seq 9 64 bytes from 10.20.47.11: icmp_seq=10 ttl=57 time=2001 ms --- 10.20.47.11 ping statistics --- 10 packets transmitted, 3 received, 70% packet loss, time 18003ms rtt min/avg/max/mdev = 2001/2002/2003/0.5 ms高いネットワーク遅延またはパケットロス場合、docker ログ見ると以下ようなエラー表示される可能性です。
-
ネットワークの保守手順については、本マニュアルの範囲外になります。
DIAG-A5: KE2 APP ホストサーバと外部データベース間のネットワーク導通の確認
外部 DB がシングル構成またはクラスタ構成の場合、外部 DB が使用されています。KE2 APP ホストサーバーと外部データベース間のネットワーク接続に問題があると、Docker で操作中の kompira コンテナや kengine コンテナに直接影響を及ぼします。
KE2 APP ホストサーバから DB サーバに ping 失敗
外部 DB サーバが ping に応答する構成の場合は、様々な原因で KE2 APP ホストサーバから外部 DB ホストサーバに ping しても答えがない可能性があります。以下の確認を行なってみてください。
- 外部 DB ホストサーバの正常性をご確認ください。
- 外部 DB ホストサーバのネットワークインターフェイスの状態を確認してください。
- 外部 DB ホストサーバの Network 設定を確認してください。
KE2 のログ分析すると以下ようなログ表示される可能性があります。
docker ログ:
kompira コンテナログ:
- 外部 DB がシングル構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている
- クラスタ構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Host is unreachable」というエラーが記録されている
KE2 APP ホストサーバーから DB サーバーに ping を実行し、ネットワークに高い遅延の確認。
ping が成功になっていますが高い遅延の可能性もあります。
$ ping -c 10 -i 2 10.20.47.20
PING 10.20.47.20 (10.20.47.20) 56(84) bytes of data.
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 10.20.47.20: icmp_seq=4 ttl=57 time=2002 ms
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 10.20.47.20: icmp_seq=7 ttl=57 time=2003 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 10.20.47.20: icmp_seq=10 ttl=57 time=2001 ms
--- 10.20.47.20 ping statistics ---
10 packets transmitted, 3 received, 70% packet loss, time 18003ms
rtt min/avg/max/mdev = 2001/2002/2003/0.5 ms
高いネットワーク遅延またはパケットロスがあれば解決してください。
ネットワークの保守手順については、本マニュアルの範囲外になります。
外部 DB Pgpool ご利用場合、 Pgpool のノード間のネットワーク遅延確認
Pgpool のノード間のネットワーク遅延を確認してください。Pgpool のノード間のネットワークの問題があればKE2 に影響を及ぼします。
KE2 ログ見ると以下ような情報表示だれます。
- クラスタ場合、kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている
- 外部 DB がシングル構成場合、kengine ログに「ERROR: unable to read message kind DETAIL: kind does not match between main(4e) slot[1] (53)」というエラーが記録されている
ネットワークの保守手順については、本マニュアルの範囲外になります。
DIAG-A6: 外部データベースへのアクセス確認
KE2 APP のホストサーバから外部 DB にアクセスの確認
psql コマンドが利用できない場合は、CentOS/RHEL: postgresql、Debian/Ubuntu: postgresql-client をインストールしてください
外部 DB にアクセスの確認
以下のコマンド実行します。アクセスが成功になると以下ような情報見ることができます
# ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
# pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
# postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
# USER は postgres です。
# DATABASE は kompira です。
# 例：
$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "SELECT 1;"
Password for user postgres: ****
?column?
----------
1
(1 row)
アクセス失敗場合、以下のような情報表示されます
$ psql -h 10.20.47.20 -p 9999 -U postgres -d kompira -c "SELECT 1;"
psql: could not connect to server: No route to host
Is the server running on host "10.20.47.20" and accepting
TCP/IP connections on port 9999?
DB サーバダウンかネットワークに到達できない場合このような状況発生されます。
KE2 のログに以下のようなエラーが記録されている場合があります。
- 外部 DB がシングル構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている
- クラスタ構成場合、kengine ログに「Is the server running on that host and accepting TCP/IP connections? Connection refused」というエラーが記録されている
DB 操作の確認
# ベーシックコマンド: psql -h <DB IP> -p <DB PORT> -U <USER> -d <DATABASE>
# pgpool場合、DB IP は Virtual IP です。DB PORT は defaultでは 9999 です。
# postgres場合、DB IP は DB サーバ IP です。DB PORT は defaultでは 5432 です。
# USER は postgres です。
# DATABASE は kompira です。
# 例：
$ psql -h 10.20.47.20 -p 9999 -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;"
Password for user postgres: *****
value
------------------
Dummy Test Value
(1 row)
問題があれば、外部 DB 管理者に連絡してください。
KE2 のログに以下のようなエラーが記録されている場合がありますので、ログを確認してみてください。
- クラスタ構成場合、kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている
- 外部 DB がシングル構成場合、kengine ログに「database error: cannot execute UPDATE in a read-only transaction」というエラーが記録されている
外部 DB の保守手順については、本マニュアルの範囲外になります。
DIAG-A7: クラスタ構成における共有ファイルシステム glusterd の正常動作の確認
全てのノードで glusterd が正常に動作していることを確認してください。
-
glusterd が実行中場合
以下のコマンドで
Active: active (running)と表示されていれば、 glusterd は実行中です。$ systemctl status glusterd glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2024-09-23 19:31:39 JST; 3 weeks 3 days ago Docs: man:glusterd(8) Process: 1168 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited,> Main PID: 1192 (glusterd) Tasks: 39 (limit: 48801) Memory: 136.4M CGroup: /system.slice/glusterd.service ├─ 1192 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO -
glusterd が停止した場合
以下のコマンドで
Active: inactive (dead)と表示されていれば、Docker は停止してしまった。$ systemctl status docker.service glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2024-10-18 09:08:46 JST; 1s ago Docs: man:glusterd(8) Process: 1168 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited,> Main PID: 1192 (code=exited, status=15) Tasks: 31 (limit: 48801) Memory: 126.3M CGroup: /system.slice/glusterd.service停止してしまった場合、以下のコマンドで glusterd を起動し、再度ステータスを確認します。
$ systemctl start glusterdglusterd を起動しても glusterd の不安定の可能性もあります。ざまざまな原因でこのような状況発生するの可能性があります。 主にホストサーバのリソース正常にあるかどうかご確認ください。