障害時にサブサーバへ自動で切り替える「高可用性WordPressシステム」の作り方 後編:DRBDの仕組みを学ぶ(6)(1/3 ページ)
サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」を使い、「WordPressサーバ」の高可用性を確保する方法を解説します。後編は、自動切り替えのキモとなる「Pacemaker」と「Corosync」の設定ノウハウと共に、「高可用性WordPressシステム」を完成させます。
(←前編に戻る)
障害時にサブサーバへ自動で切り替える「高可用性WordPressシステム」の構築ノウハウをお届けする本稿。前編では、「DRBD(Distributed Replicated Block Device)」を用いた高可用性WordPressシステムの構築において、サーバ環境を用意し、必要なソフトウェアをインストールするまでを解説しました。
後編となる今回は、自動切り替えのキモとなるソフトウェア「Pacemaker」と「Corosync」の設定をじっくり行い、高可用性WordPressシステムの完成までを解説します。
Pacemakerの設定を行う
Pacemakerの設定を行いましょう。
ワンポイント
ここで、WordPressシステムで使われるApacheとMariaDBが停止していることを確認しましょう。また、それらの自動起動がオフとなっていることも確認してください。
今後はPacemakerでリソースの起動を制御するので、設定前からApacheとMariaDBが起動していると、各リソースが正常に動作しないためです。
Pacemakerの役割は、リソース(アプリケーション)の管理です。実際の各アプリケーションの起動、停止などの制御は「リソースエージェント」が実施します。このリソースとは、「Pacemakerのリソース」を指します(DRBDの設定で説明したリソースとは異なりますのでご注意ください)。Apache、MariaDB、仮想IPアドレスなど、それぞれをリソースとして定義し、Pacemakerが管理します。
ここまでクラスタ、Pacemaker、リソース、リソースエージェントなどの単語が続々と出てきましたので、いったん整理しましょう。
クラスタ、Pacemaker、リソース、リソースエージェントの関係は図3のようになります。
前編で「wp-cluster」という名前のクラスタを登録し、一号機と二号機を所属させました。
そこに、Pacemakerのリソースを登録していきます。Pacemakerは指令塔の役割を果たして、各リソースの管理とモニターを行います。リソースエージェントは実際のリソースの起動・停止を制御します。リソースエージェントは「/usr/lib/ocf/resource.d」に格納されています。
では、Pacemakerの各リソースを設定していきます。Pacemakerはpcsというコマンドで設定を行います。pcsコマンドは原則としてプライマリ機のみで実行します。
まず、stonithの設定を無効にします。
# pcs property set stonith-enabled=false
次にPacemakerで使われるスコア(stickiness)の設定を行います。
# pcs property set default-resource-stickiness=200
仮想IPアドレス(VIP)のリソースを設定します。
# pcs resource create res_ip ocf:heartbeat:IPaddr2 \ params ip="192.168.0.50" cidr_netmask="24" \ op start interval="0" timeout="20" \ op stop interval="0" timeout="20" \ op monitor interval="10" timeout="20"
複数行にまたがっていますが、そのままコピー&ペーストでコマンドを投入してください。行の最後の「\(環境によっては、半角逆スラッシュ)」が改行なしで設定が続いていることを示しています。「\」を省いて1行で一気に記述することも可能ですが、ここでは理解のしやすさを考え、このようにしました。
では、1行ずつ解説します。
1行目:pcs resource create res_ip ocf:heartbeat:IPaddr2
「res_ip」という名前でリソースを定義します。このres_ipリソースを「ocf:heartbeat:IPaddr2」にあるリソースエージェントで操作する、という意味です。
2行目:params ip="192.168.0.50" cidr_netmask="24"
リソースのパラメーターを定義します。仮想IPアドレスを「192.168.0.50」に、サブネットは「255.255.255.0」とすることを示します。
3行目:op start interval="0" timeout="20"
オプションの設定です。このリソースが起動するまでの間隔(interval)を「0」秒として、さらに「20」秒以内に起動できなかったらタイムアウトエラーとする設定にしています。
4行目:op stop interval="0" timeout="20"
同じくオプションの設定です。このリソースが停止するまでの間隔(interval)を「0」秒として、さらに「20」秒以内に停止できなかったらタイムアウトエラーとする設定にしています。
5行目:op monitor interval="10" timeout="20"
同じくオプションの設定です。このリソースが正常稼働していることを「10」秒に1回確認し、さらに「20」秒以内に稼働確認ができなかったらタイムアウトエラーとする設定にしています。
以降、op(オプション)に関する設定が繰り返し出てきます。設定の意味は同じですので、適宜こちらを参照してください。
この他の各リソースを定義する
この他の各リソースも定義していきます。
Apacheのリソースを定義する
# pcs resource create res_httpd ocf:heartbeat:apache \ params port="80" configfile="/etc/httpd/conf/httpd.conf" \ op start interval=0 timeout=40 \ op stop interval=0 timeout=60 \ op monitor interval=10 timeout=20
1行目は、「res_httpd」という名前でリソースを定義し、res_httpdリソースを「ocf:heartbeat:apache」にあるリソースエージェントで操作することを示します。
2行目は、リソースが使用するポートを「80」と決め、リソースの使用する設定ファイルが「/etc/httpd/conf/httpd.conf」であることを意味します。
DRBDのWordPress用リソースを定義する
DRBDのWordPress用リソースを定義します。
# pcs resource create res_drbd_r0 ocf:linbit:drbd \ params drbd_resource="r0" \ op start interval="0" timeout="240" \ op stop interval="0" timeout="120" \ op monitor interval="20" role="Slave" timeout="20" \ op monitor interval="10" role="Master" timeout="20"
1行目は、「res_drbd_r0」という名前でリソースを定義し、res_drbd_r0リソースを「ocf:linbit:drbd」にあるリソースエージェントで操作することを示します。2行目は、DRBDのリソース「r0」を使うことを示しています。
続いて、マルチステートメントリソース(MS)の設定をします。DRBD以外のリソースは一号機もしくは二号機のどちらかで起動しますが、DRBDはリアルタイムレプリケーション(即時複製)をするために、二つのサーバで常に起動することになります。常に起動するリソースのためにMSの設定で定義します。
# pcs resource master ms_drbd_r0 res_drbd_r0 \ master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
2行目で、Master(プライマリ)になれるサーバは最大で「1」台とし、所属しているサーバは「2」台であることを示しています。notify=trueでMSの設定を有効にします。
DRBDのMariaDB用リソースを定義します。
# pcs resource create res_drbd_r1 ocf:linbit:drbd \ params drbd_resource="r1" \ op start interval="0" timeout="240" \ op stop interval="0" timeout="120" \ op monitor interval="20" role="Slave" timeout="20" \ op monitor interval="10" role="Master" timeout="20"
1行目は、「res_drbd_r1」という名前でリソースを定義し、res_drbd_r1リソースを「ocf:linbit:drbd」にあるリソースエージェントで操作することを示します。
2行目は、DRBDのリソース「r1」を使うことを示しています。同じくMSの設定も行います。
# pcs resource master ms_drbd_r1 res_drbd_r1 \ master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
WordPress用ファイルシステムとMariaDBのリソースを定義する
WordPress用ファイルシステムのリソースも定義します。設定作業はあと少しです。
# pcs resource create res_filesystem ocf:heartbeat:Filesystem \ params device="/dev/drbd0" directory="/var/www/html/wordpress" fstype="xfs" options="noatime" \ op start interval="0" timeout="60" \ op stop interval="0" timeout="60" \ op monitor interval="20" timeout="40"
1行目は、「res_filesystem」という名前でリソースを定義し、res_filesystemリソースを「ocf:heartbeat:Filesystem」にあるリソースエージェントで操作することを示します。
2行目は、「/dev/drbd0」のデバイスをマウントし、対象のディレクトリ名は「/var/www/html/wordpress」、ファイルシステムは「xfs」であることを指定しています。
MariaDB用ファイルシステムのリソースを定義します
# pcs resource create res_filesystem_mysql ocf:heartbeat:Filesystem \ params device="/dev/drbd1" directory="/var/lib/mysql" fstype="xfs" options="noatime" \ op start interval="0" timeout="60" \ op stop interval="0" timeout="60" \ op monitor interval="20" timeout="40"
1行目は、「res_filesystem_mysql」という名前でリソースを定義し、res_filesystem_mysqlリソースを「ocf:heartbeat:Filesystem」にあるリソースエージェントで操作することを示します。
2行目は、「/dev/drbd0」のデバイスをマウントし、対象のディレクトリ名は「/var/lib/mysql」、ファイルシステムは「xfs」であることを指定しています。
MariaDB用のリソースも定義します。
# pcs resource create res_mysql ocf:heartbeat:mysql \ params binary="/usr/bin/mysqld_safe" pid="/var/run/mysqld/mysqld.pid" \ op start interval="0" timeout="120" \ op stop interval="0" timeout="120" \ op monitor interval="20" timeout="30"
1行目は、「res_mysql」という名前でリソースを定義し、res_mysqlリソースを「ocf:heartbeat:mysql」にあるリソースエージェントで操作することを示します。
2行目は、binaryの場所とpidの配置場所を指定しています。
各リソースのグループ設定を行う
「wp-ha」というグループを作り、DRBD以外の各リソースをそのグループに所属させます。
# pcs resource group add wp-ha res_ip res_filesystem res_httpd res_filesystem_mysql res_mysql
なぜ、グループへの登録が必要なのでしょう。
何かの原因でApacheのサービスだけが止まったとします。今回のシステムですと、停止を把握してApacheは一号機から二号機に自動的に切り替わります。しかし、Apache以外のサービスはそのまま一号機で稼働し続けるというバラバラなシステムになってしまいます。
このような事態を防ぐために、対になっている各リソースをまとめておく必要があるのです。グループへの登録により、所属するグループのリソースが1つでも他方へ切り替わったら、それと連動してグループに所属している全てのリソースも切り替わるように制御できます。
なお、リソースは上記のグループ設定コマンドで記載した順に起動されます。例では、res_ipが最初に、最後にres_mysqlが起動することになります。
ワンポイント:リソース/グループを間違えて登録してしまったら
リソースおよびグループの削除は以下のコマンドで可能です。
pcs resource delete <リソース名>
pcs resource group delete <グループ名>
なお、現在の設定内容は、pcs configコマンドで確認できます。
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」は、手軽にファイル共有環境を構築することができ、サーバー管理入門にもぴったりです。インターネット上の関連情報も豊富ですが、しっかり出所を確かめないと誤った設定を招く恐れがあります。