障害時にサブサーバへ自動で切り替える「高可用性WordPressシステム」の作り方 後編：DRBDの仕組みを学ぶ（6）（3/3 ページ）

[澤田健，株式会社サードウェア]

WordPressの高可用性システムをテストする

　これで、二重化した高可用性WordPressシステムが構築できました。

　最終テストをしましょう。本システムのWordPressサイト「http://192.168.0.50/wordpress/」へアクセスします。サイトがきちんと表示されればOKです。

「http://192.168.0.50/wordpress/」へアクセスしたところ

　念のため、サーバのステータスを確認します。一号機へpcs statusコマンドを送ります。

# pcs status
Cluster name: wp-cluster
Last updated: Wed Jan  6 23:56:21 2016          Last change: Wed Jan  6 23:56:18 2016 by root vi
crm_resource on wp-ha2
Stack: corosync
Current DC: wp-ha1 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 9 resources configured
Online: [ wp-ha1 wp-ha2 ]
Full list of resources:
 Master/Slave Set: ms_drbd_r0 [res_drbd_r0]
     Masters: [ wp-ha1 ]
     Slaves: [ wp-ha2 ]
 Master/Slave Set: ms_drbd_r1 [res_drbd_r1]
     Masters: [ wp-ha1 ]
     Slaves: [ wp-ha2 ]
 Resource Group: wp-ha
     res_ip     (ocf::heartbeat:IPaddr2):       Started wp-ha1
     res_filesystem     (ocf::heartbeat:Filesystem):    Started wp-ha1
     res_httpd  (ocf::heartbeat:apache):        Started wp-ha1
     res_filesystem_mysql       (ocf::heartbeat:Filesystem):    Started wp-ha1
     res_mysql  (ocf::heartbeat:mysql): Started wp-ha1
（一部省略）

　各リソースが「Started wp-ha1」となっていること、DRBDのリソースは「Masters: [ wp-ha1 ]」となっていることを確認します。

　catコマンドでDRBDの状態も確認しましょう。

# cat /proc/drbd

catコマンドで確認したDRBDのステータス

　各DRBDのリソースは、一号機側がプライマリ（Primary）となっていればOKです。

ワンポイント：WordPressサイトの表示が崩れていたら

　WordPress管理画面の「設定」から、「WordPressアドレス（URL）」と「サイトアドレス（URL）」の設定項目を確認します。

　今回のシステムでは、この二つを「VIP（仮想IPアドレス）」のURLに指定してください。

二号機へリソースを移動させるテストを行う

　障害発生時のテストとして、リソースを一号機側から二号機側に移動させつつも、WordPressのURLへ変わることなくアクセスできることも確認しましょう。

　pcs resource moveで仮想IPアドレスのリソースを二号機側へ移動します。このコマンドの実行後は、pcs resource clearコマンドも忘れずに実行してください。「pcs resource move」コマンドを実行すると、先ほど設定したlocationとは別のlocation設定が自動的に入ってしまい、リソースの動作するサーバを固定してしまいます。この固定を解除するコマンドが「pcs resource clear」です。

　なお、これら二つのコマンドは「移動元のサーバ」で実行します。一号機から二号機へリソースを移動させるならば「一号機」で、二号機から一号機へリソースを移動させるならば「二号機」でコマンドを実行します。

# pcs resource move res_ip

# pcs resource clear res_ip

　実際に二号機側へリソースがきちんと移動したかを確認します。

# pcs status
Cluster name: wp-cluster
Last updated: Thu Jan  7 00:13:10 2016          Last change: Wed Jan  6 23:56:17 2016 by root vi
crm_resource on wp-ha2
Stack: corosync
Current DC: wp-ha2 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 9 resources configured
Online: [ wp-ha1 wp-ha2 ]
Full list of resources:
 Master/Slave Set: ms_drbd_r0 [res_drbd_r0]
     Masters: [ wp-ha2 ]
     Slaves: [ wp-ha1 ]
 Master/Slave Set: ms_drbd_r1 [res_drbd_r1]
     Masters: [ wp-ha2 ]
     Slaves: [ wp-ha1 ]
 Resource Group: wp-ha
     res_ip     (ocf::heartbeat:IPaddr2):       Started wp-ha2
     res_filesystem     (ocf::heartbeat:Filesystem):    Started wp-ha2
     res_httpd  (ocf::heartbeat:apache):        Started wp-ha2
     res_filesystem_mysql       (ocf::heartbeat:Filesystem):    Started wp-ha2
     res_mysql  (ocf::heartbeat:mysql): Started wp-ha2
（一部省略）

　各リソースが「Started wp-ha2」となり、DRBDのリソースが「Masters: [ wp-ha2 ]」となっていれば正常です。

　移動したリソースを元に戻すのも、同じくpcs resource moveコマンドです。二号機で実行します。同様にpcs resource clearコマンドも忘れずに実行してください。

# pcs resource move res_ip

# pcs resource clear res_ip

　障害時の動作テストとして、今回はリソースを移動するコマンドを使いましたが、プライマリ機である一号機でサーバをいきなりシャットダウンしてもよいかもしれません。問題なく他方のサーバに切り替わっているはずです。

　最後にOSの準備で一時停止していた、firewalld、iptablesを起動してください。

　なお、今回の高可用性システムで使用しているポートは「7788」「7789」です。実運用においては、7788と7789ポートの開放も行ってください。

高可用性システム関連のログの場所

　DRBDはシステムログに出力されます。その他のPacemaker、Corosyncのログは以下に出力されます。

• DRBD：/var/log/message
• Pacemaker：/var/log/pacemaker.log
• Corosync：/var/log/cluster/corosync.log

---

　これで、WordPressの高可用性システムを構築できました。またサーバの切り替えが自動で行われることも確認できたでしょうか。

　設定作業が多く、少し大変かもしれません。しかし、Webサーバ／WordPressサーバのサービス継続性、そして災害復旧（DR）対策は、今後の自社のビジネスに直結する課題です。ぜひ、実際のWebサーバでもこのノウハウを参照しながら高可用性システムを構築してみてください。

　次回はDRBD＋DRBD Proxyを組み合わせて、オンプレミス環境のデータをクラウド環境へ遠隔保存するシステムの実装ノウハウを紹介します。お楽しみに。

筆者紹介

澤田健（さわだ けん）

株式会社サードウェア

さまざまなIT関連業務経験ののちに2013年よりインフラエンジニアとしての業務に携わる。また、DRBDを始めとするオープンソースソースウエアのサポート業務にも携わっている。ツイッターでDRBDの情報発信も行っている。TwitterID：@ksawada1979。