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

サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD」。今回は、CMSツールとして多くのWebサイトで利用されている「WordPressサーバ」の高可用性をDRBDで確保する方法を解説します。前編は、必要なソフトウェアのインストールと初期設定までを説明します。

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

PacemakerとCorosyncのインストールと設定を行う

　では、「Pacemaker」と「Corosync」をインストールしていきます。PacemakerとCorosyncの詳細は、第2回で解説した「“高可用性システム”で、DRBDをどう活用するか」を参照してください。

（参考記事）DRBDの仕組みを学ぶ（2）：「高可用性システム」で、DRBDをどう活用するか

# yum install pacemaker corosync pcs

　今回は、PacemakerとCorosyncと一緒に、Pacemakerのクラスタ管理ツールである「pcs」もインストールします。

Corosyncの設定を行う

　ではCorosyncの設定から行いましょう。

　まず「hacluster」ユーザーのパスワードを設定します。一号機、二号機の両方で実行してください。

# passwd hacluster

　「pcsd」を起動し、自動起動も有効にします。こちらも一号機、二号機の両方で実行してください。

# systemctl start pcsd
# systemctl enable pcsd

　次に、一号機と二号機をクラスタとして登録します。

　まず、一号機と二号機間で認証設定を行います。パスワードには、先ほど設定した「hacluster」ユーザーのパスワードを使います。

# pcs cluster auth 10.0.0.1 10.0.0.2 -u hacluster -p <パスワード> --force
10.0.0.1: Authorized
10.0.0.2: Authorized

※「10.0.0.1」は一号機、「10.0.0.2」は二号機です

　pcs cluster setupコマンドでクラスタにサーバを登録します。「wp-cluster」という名称のクラスタを作成し、一号機と二号機を登録します。特に記述がない限り、これ以降のCorosync設定は一号機（プライマリ機）のみで実行します。

# pcs cluster setup --name wp-cluster 10.0.0.1 10.0.0.2

　実行後、「10.0.0.1: Success」「10.0.0.2: Success」が出力されることを確認してください。確認ができたら、クラスタを起動します。

# pcs cluster start --all

　pcs statusコマンドでクラスタの起動を確認します。これまでの設定が正しければ、以下のように表示されます。

# pcs status
Cluster name: wp-cluster
WARNING: no stonith devices and stonith-enabled is not false
WARNING: corosync and pacemaker node names do not match (IPs used in setup?)
Last updated: Sun Dec 27 22:31:45 2015          Last change: Sun Dec 27 22:31:32 2015 by hacluster vi
crmd on wp-ha2
Stack: corosync
Current DC: wp-ha2 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 0 resources configured
Online: [ wp-ha1 wp-ha2 ]
Full list of resources:
PCSD Status:
  wp-ha1 (10.0.0.1): Online
  wp-ha2 (10.0.0.2): Online
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

　これで、一号機と二号機がクラスタとして登録されました。

　続いてCorosyncの設定ファイル「/etc/corosync/corosync.conf」にviなどのエディタで追記をします。

　7行目の「rrp_mode: active」、12行目の「ring1_addr: 10.0.1.1」、17行目の「ring1_addr: 10.0.1.2」が追記した内容です。corosync.confは一号機、二号機ともに追記してください。

# vi /etc/corosync/corosync.conf
totem {
    version: 2
    secauth: off
    cluster_name: wp-cluster
    transport: udpu
    rrp_mode: active
}
nodelist {
    node {
        ring0_addr: 10.0.0.1
        ring1_addr: 10.0.1.1
        nodeid: 1
    }
    node {
        ring0_addr: 10.0.0.2
        ring1_addr: 10.0.1.2
        nodeid: 2
    }
}
quorum {
    provider: corosync_votequorum
    two_node: 1
}
logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
}

　デフォルトでは、eth1だけで一号機と二号機を相互に監視する設定になっていました。上記の設定を追記することで、監視するネットワークインタフェースとしてeth2も追加され、eth1に障害発生に備えた監視経路の冗長化が実現します。

---

　これで、DRBDによる「高可用性WordPressシステム」で必要なソフトウェアのインストールと初期設定が済みました。後編は、少し作業量が多くて複雑な「Pacemakerの設定」「colocationとorderの設定」を行いながら、「高可用性WordPressシステム」の完成までを解説します。お楽しみに。

　（→後編へ）

筆者紹介

澤田健（さわだ けん）

株式会社サードウェア

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