IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

クラウド時代のサーバー運用入門

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート 

第6回 クラウド時代の障害対応術 (5) WEBサイトが落ちた? (2)(前編) (濱田康貴) 2018年3月

みなさんこんにちは。本コラムも先月から実践編ということで、実際のサーバー障害を例に対処方法をご紹介しています。前回はリモートホストの障害切り分けに役立つコマンドを紹介し、WEBサーバーの外形監視、ステータスコードの取得や名前解決の方法をご紹介しましたが、今回は実際に障害が発生しているWEBサーバーへログインし、原因特定を行ってみたいと思います。

今回、疑似障害を発生させるサーバーは次のスペックです。

  • OS : CentOS7.4
  • WEBサーバー : Nginx + PHP-FPM
    • » Nginx : 1.13.8
    • » PHP : 7.1.13
  • DBサーバー : MariaDB 10.2.12
  • CMS : WordPress4.9.4

今回は実際に、壊してもよいWEBサーバーを構築してハンズオンっぽくやってみたいと思います。ですので、社内に余ったサーバーかクラウド環境をご用意いただき実践してみることをおすすめします。

WordPressへログインできない

ある日、お客様から電話があり「御社で管理いただいているサイト(WordPress)にログインできない」と申告がありました。幸い、サイトの表示ができているのでいつものようにWordPressの管理画面へログインを試みたところ、確かにログインできません。いつも自分で覚えているIDとパスワードでログインを試みるのですが、管理画面へ遷移する気配がありません。

そもそもサイトが見えているのですが、念のためにSSHでサーバーにログインし、psコマンドでプロセスの確認をします。

[hamada@popotest ~]$ ps -aef | egrep '([p]hp|[n]ginx)'
root       863     1  0  1月18 ?      00:03:09 php-fpm: master process (/etc/php-fpm.conf)
root       886     1  0  1月18 ?      00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx      891   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      892   886  0  1月18 ?      00:00:01 nginx: worker process
nginx      893   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      894   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      895   886  0  1月18 ?      00:00:18 nginx: cache manager process
nginx     1010   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1011   863  0  1月18 ?      00:00:06 php-fpm: pool www
nginx     1012   863  0  1月18 ?      00:00:06 php-fpm: pool www
nginx     1013   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1014   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1072   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1114   863  0  1月18 ?      00:00:04 php-fpm: pool www

NginxもPHP-FPMも動いています。MySQL(MariaDB)も動いているか確認します。

[hamada@popotest ~]$ ps -aef | egrep -i [m]ysqld
mysql      922     1  0  1月18 ?      00:41:00 /usr/sbin/mysqld
手詰まりか?トラブルシュート

少なくとも、サーバー上で動いているプロセスには問題がなさそうです。アプリケーションを開発しているメンバーにも相談してみましたが、特に設定を変えたりはしていないとのことでした。(順番が違うような気もしますが)上司に相談すると、「ログは見たのかね?」と。そう言えばログを見ていなかった・・・これではいけません。

今の状況を整理してみると

  1. WordPressのサイトそのものは表示されている
  2. ordPressの管理画面へログインできない
  3. WordPressを実行しているサーバーへSSHログインできる
  4. Nginx PHP-FPM MySQL(MariaDB)のプロセスは動いている

という状況になります。

再現環境構築

さて、今回は障害実践編ということもありますので、実際に環境を作ってみたいと思います。
本稿の再現環境として、拙作のサーバープロビジョニングコマンド「ICHIGEKI」を使い、さくらのクラウドでWordPress実行環境を構築しています。

https://github.com/nullpopopo/ichigeki/blob/master/ICHIGEKI

そして、今回は以下のコマンドで擬似障害を発生させています。

$(echo L3Vzci9iaW4vZGQK | openssl enc -d -base64) bs=1048576k count=$(df -h | egrep /$ | awk '{print $2}' | sed -e "s/[[:alpha:]]//g") if=/dev/zero of=DEVZERO

※ このコマンドは、本稿での障害を擬似的に発生させるものです。絶対に本番環境で実行しないようお願いします。

上記「ICHIGEKI」を少しカスタマイズすることで、すぐにWordPressの実行環境を構築することができます。最初の変数指定部分を以下のようにし、構築対象のサーバーへアップロードし、rootユーザーで実行します。

ADMINUSER_MAIL=<メールアドレス>
ADMINUSER_ID=<sshおよびWordPressログインユーザー名>
ADMINUSER_PW=<sshおよびWordPressログインユーザーのパスワード>
ADMINUSER_PUBKEY="公開鍵の文字列"
WORDPRESS_TITLE="WordPressのタイトル"

FQDN=<DNSで名前解決のできるホスト名> CMSINSTALL_CHOICE=WorsPress

ICHIGEKIでのサーバー構築が困難な場合、KUSANAGIでサーバーを構築しても構いません。ICHIGEKIおよびKUSANAGIでのサーバー構築方法の詳細は割愛いたしますが、サーバー構築後の疑似障害発生コマンドを実行してみてください(繰り返しになりますが、くれぐれも本番環境で実行しないよう、お願いします)。

先輩からのアドバイスを思い出そう

障害原因特定に行き詰ったら、上司から「ログは見たのかね?」と言われました。「ログってどこにあるのだろう?」「どうやって見ればよいのだろう?」ふたたび上司に相談しようとすると「これからお客様先訪問だから後で!」と言われてしまいました。肩を落として自席に戻るとこんなメモ書きが置かれており・・・

  • ログファイルのパスは設定ファイルに書いてあるぞ。
  • サーバー全体のログは /var/log/messagesだ。
  • ログは口ほどに物を言う。

もう一度サーバーにログインし、ログファイルを探し始めることにしました。

読者の皆様へ

さて、今回はハンズオンっぽい内容ですので、次回までの宿題を出してみたいと思います。

  1. どこに何のログがあるかを探してみよう
    (ア) Nginx
    (イ) PHP-FPM
    (ウ) MySQL(MariaDB)
  2. ログにはどんなエラーが書かれているかを確認してみよう
  3. エラーメッセージから読み取った障害原因と、復旧方法、確認方法
  4. 再発防止策
    (ア) そもそも同じ原因での障害を再発させないために、どうすればよいのか
    (イ) どうすれば障害発生を早期に気づくことができるのか

それぞれの回答と解説は次回に。それでは、ごきげんよう。

 


 

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート