障害時にサブサーバへ自動で切り替える「高可用性WordPressシステム」の作り方 後編:DRBDの仕組みを学ぶ(6)(3/3 ページ)
サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」を使い、「WordPressサーバ」の高可用性を確保する方法を解説します。後編は、自動切り替えのキモとなる「Pacemaker」と「Corosync」の設定ノウハウと共に、「高可用性WordPressシステム」を完成させます。
WordPressの高可用性システムをテストする
これで、二重化した高可用性WordPressシステムが構築できました。
最終テストをしましょう。本システムのWordPressサイト「http://192.168.0.50/wordpress/」へアクセスします。サイトがきちんと表示されればOKです。
念のため、サーバのステータスを確認します。一号機へ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
各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。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 障害時にサブサーバへ自動で切り替える「高可用性WordPressシステム」の作り方 前編
サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」。今回は、CMSツールとして多くのWebサイトで利用されている「WordPressサーバ」の高可用性をDRBDで確保する方法を解説します。前編は、必要なソフトウェアのインストールと初期設定までを説明します。 - DRBD(Distributed Replicated Block Device)とは何か
障害監視ツールなどと一緒に使うことで、サービスの継続提供を助けるDRBD。Linuxカーネルに統合されている機能ですが、上手に使いこなしているでしょうか? 本連載では、DRBDの動作や使いどころを順を追って紹介していきます。 - ミラーリングツール「DRBD」によるデータ保護
「Heartbeat」の適切な導入によってHAクラスタを構成し、Linux上で動作しているサービスの可用性を上げることができます。続いて、肝心のデータそのものを保護できるツール「DRBD」について紹介しましょう。 - ここが変わったCentOS 7──「新機能の概要とインストール」編
「CentOS 7」を皆さんどれだけ理解していますでしょうか。CentOS 7は、以前のバージョンから使い勝手がかなり変わりました。本連載では、今さら聞けない/おさらいしたいというインフラエンジニアに向け、CentOS 7の概要と基礎から活用Tipsまでを紹介していきます。 - DRBD+iSCSI夢の共演(前編)〜 Windowsドライブをミラーリングで保護 〜
Linux上で動作するオープンソースソフトウエア「DRBD」とiSCSIを組み合わせ、部門内のWindows端末のデータをバックアップするシステムを構築してみよう - OSSとLinuxで高可用システム構築を支援、サードウェア
- Sambaサーバー構築、5つのべからず− 若葉マーク管理者に捧げる
LinuxやUNIXをWindowsのファイルサーバー/プリントサーバーとしてしまうことができる「Samba」は、手軽にファイル共有環境を構築することができ、サーバー管理入門にもぴったりです。インターネット上の関連情報も豊富ですが、しっかり出所を確かめないと誤った設定を招く恐れがあります。