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

サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」を使い、「WordPressサーバ」の高可用性を確保する方法を解説します。後編は、自動切り替えのキモとなる「Pacemaker」と「Corosync」の設定ノウハウと共に、「高可用性WordPressシステム」を完成させます。

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

colocationとorderの設定を行う

　続いて「共存関係」を設定するために、colocationの設定も行います。

# pcs constraint colocation add wp-ha ms_drbd_r0 INFINITY with-rsc-role=Master
# pcs constraint colocation add wp-ha ms_drbd_r1 INFINITY with-rsc-role=Master

　ここで、「ms_drbd_r0」がプライマリ機（Master）となっているサーバで、「wp-ha」グループを実行するという関係性を定義します。

　wp-haグループとは、先ほど登録したグループのリソース群です。2行目も同様です。「ms_drbd_r1」がプライマリ機（Master）となっているサーバで「wp-ha」グループを実行する関係性を定義しています。

　「order」も以下のように設定します。orderは、上のcolocationと連動した設定項目です。

# pcs constraint order promote ms_drbd_r0 then start wp-ha
# pcs constraint order promote ms_drbd_r1 then start wp-ha

　この設定は、「ms_drbd_r0」が起動した後に「wp-ha」グループを起動するように指定する「起動順」になります。2行目も「ms_drbd_r1」以外は同じです。

　クラスタ起動時に優先的にプライマリになるサーバを指定します。

# pcs constraint location wp-ha prefers wp-ha1=100

　以上をまとめます。colocationでDRBDのプライマリとwp-haグループを同じサーバで起動する「共存関係」を定義し、orderではDRBDが起動してからwp-haグループを起動する起動順を定義します。

　よって、colocationとorderはセットで設定する必要があります。どちらかの設定を入れ忘れないように注意してください。

　リソースの状態をクリアします。

# pcs resource cleanup

　以上で全ての設定が終了しました。おつかれさまでした。

　最後に一号機でクラスタを再起動します。

# pcs cluster stop --all
# pcs cluster start --all

colocation／orderの設定を間違えて登録してしまったら

　colocationの設定は、「pcs constraint colocation remove <リソース名> <リソース名>」、orderの設定は「pcs constraint order remove <リソース名> <リソース名>」のコマンドで削除できます。

pcs constraint colocation remove wp-ha ms_drbd_r0

colocationの削除を行うコマンド

pcs constraint order remove ms_drbd_r0 wp-ha

orderの削除を行うコマンド

　リソース名ではなく、今回のようにグループ名を指定することもできます。設定を削除した場合は「pcs config」コマンドで忘れずに確認しましょう。