CentOS7でPacemakerを使用してApacheアクティブ-パッシブクラスターをセットアップする方法
序章
サービスの停止は非常にコストがかかる可能性があるため、高可用性は今日の重要なトピックです。 停止した場合にWebサイトまたはWebアプリケーションを実行し続けるための対策を講じることが賢明です。 Pacemakerスタックを使用すると、高可用性クラスターを構成できます。
Pacemakerは、クラスターリソースマネージャーです。 すべてのクラスターサービス(リソース)を管理し、基盤となるクラスターエンジンのメッセージングおよびメンバーシップ機能を使用します。 クラスターエンジンとしてCorosyncを使用します。 リソースにはリソースエージェントがあります。これは、サービスを抽象化する外部プログラムです。
アクティブ-パッシブクラスターでは、すべてのサービスがプライマリシステムで実行されます。 プライマリシステムに障害が発生した場合、すべてのサービスがバックアップシステムに移動されます。 アクティブ-パッシブクラスターにより、中断することなくメンテナンス作業を行うことができます。
このチュートリアルでは、高可用性Apacheアクティブ-パッシブクラスターを構築する方法を学習します。 Webクラスターは仮想IPアドレスでアドレス指定され、ノードに障害が発生した場合は自動的にフェイルオーバーします。
ユーザーは、Pacemakerによって管理されている仮想IPアドレスを使用してWebアプリケーションにアクセスします。 Apacheサービスと仮想IPは常に同じホスト上にあります。 このホストに障害が発生すると、2番目のホストに移行され、ユーザーは停止に気付くことはありません。
前提条件
このチュートリアルを開始する前に、次のものが必要です。
- クラスターノードとなる2つのCentOS7ドロップレット。 これらをwebnode01(IPアドレス:
your_first_server_ip
)およびwebnode02(IPアドレス:your_second_server_ip
)と呼びます。 - ルート権限を持つ両方のサーバー上のユーザー。 これを設定するには、この CentOS7を使用したサーバーの初期設定チュートリアルに従います。
両方のサーバーでいくつかのコマンドを実行し、一方のサーバーでいくつかのコマンドを実行する必要があります。
ステップ1—名前解決の構成
まず、両方のホストが2つのクラスターノードのホスト名を解決できることを確認する必要があります。 これを実現するために、/etc/hosts
ファイルにエントリを追加します。 webnode01とwebnode02の両方でこの手順に従います。
/etc/hosts
をnano
またはお好みのテキストエディタで開きます。
sudo nano /etc/hosts
ファイルの最後に次のエントリを追加します。
/ etc / hosts
your_first_server_ip webnode01.example.com webnode01 your_second_server_ip webnode02.example.com webnode02
ファイルを保存して閉じます。
ステップ2—Apacheをインストールする
このセクションでは、ApacheWebサーバーをインストールします。 両方のホストでこの手順を完了する必要があります。
まず、Apacheをインストールします。
sudo yum install httpd
Apacheリソースエージェントは、Apacheサーバーのステータスページを使用して、Apacheサービスの状態をチェックします。 ファイル/etc/httpd/conf.d/status.conf
を作成して、ステータスページをアクティブ化する必要があります。
sudo nano /etc/httpd/conf.d/status.conf
このファイルに次のディレクティブを貼り付けます。 これらのディレクティブは、ローカルホストからのステータスページへのアクセスを許可しますが、他のホストからのアクセスは許可しません。
/etc/httpd/conf.d/status.conf
<Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 127.0.0.1 </Location>
ファイルを保存して閉じます。
ステップ3—Pacemakerのインストール
次に、Pacemakerスタックをインストールします。 両方のホストでこの手順を完了する必要があります。
Pacemakerスタックとpcsクラスターシェルをインストールします。 後者を後でクラスターの構成に使用します。
sudo yum install pacemaker pcs
次に、ノード間でCorosync構成を同期するために使用されるpcsデーモンを起動する必要があります。
sudo systemctl start pcsd.service
再起動するたびにデーモンが起動するように、サービスも有効にします。
sudo systemctl enable pcsd.service
これらのパッケージをインストールすると、haclusterという名前の新しいユーザーがシステムに追加されます。 インストール後、このユーザーのリモートログインは無効になります。 構成の同期や他のノードでのサービスの開始などのタスクでは、このユーザーに同じパスワードを設定する必要があります。
sudo passwd hacluster
ステップ4—Pacemakerの設定
次に、FirewallDでクラスタートラフィックを許可して、ホストが通信できるようにします。
まず、FirewallDが実行されているかどうかを確認します。
sudo firewall-cmd --state
実行されていない場合は、起動します。
sudo systemctl start firewalld.service
両方のホストでこれを行う必要があります。 実行したら、high-availability
サービスをFirewallDに追加します。
sudo firewall-cmd --permanent --add-service=high-availability
この変更後、FirewallDをリロードする必要があります。
sudo firewall-cmd --reload
FirewallDの詳細については、CentOS7でFirewallDを構成する方法に関するこのガイドをお読みください。
2つのホストが相互に通信できるようになったので、1つのホスト(この場合は webnode01 )でこのコマンドを実行することにより、2つのノード間の認証を設定できます。
sudo pcs cluster auth webnode01 webnode02 Username: hacluster
次の出力が表示されます。
出力
webnode01: Authorized webnode02: Authorized
次に、同じホスト上でCorosync構成を生成して同期します。 ここでは、クラスターに webcluster という名前を付けますが、任意の名前を付けることができます。
sudo pcs cluster setup --name webcluster webnode01 webnode02
次の出力が表示されます。
出力
Shutting down pacemaker/corosync services... Redirecting to /bin/systemctl stop pacemaker.service Redirecting to /bin/systemctl stop corosync.service Killing any remaining services... Removing all cluster configuration files... webnode01: Succeeded webnode02: Succeeded
これで、corosync構成が作成され、すべてのノードに分散されます。 構成はファイル/etc/corosync/corosync.conf
に保存されます。
ステップ5—クラスターを開始する
クラスターは、webnode01で次のコマンドを実行することで開始できます。
sudo pcs cluster start --all
Pacemakerとcorosyncが起動時に確実に起動するようにするには、両方のホストでサービスを有効にする必要があります。
sudo systemctl enable corosync.service sudo systemctl enable pacemaker.service
これで、いずれかのホストで次のコマンドを実行して、クラスターのステータスを確認できます。
sudo pcs status
出力で両方のホストがオンラインとしてマークされていることを確認します。
出力
. . . Online: [ webnode01 webnode02 ] Full list of resources: PCSD Status: webnode01: Online webnode02: Online Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
注:最初のセットアップ後、ノードがオンラインとしてマークされるまでに時間がかかる場合があります。
ステップ6—STONITHを無効にしてクォーラムを無視する
STONITHとは何ですか?
pcs status
の出力に、STONITHデバイスが構成されておらず、STONITHが無効になっていないという警告が表示されます。
警告
. . . WARNING: no stonith devices and stonith-enabled is not false . . .
これはどういう意味ですか、なぜ気にする必要がありますか?
クラスター・リソース・マネージャーがノードまたはノード上のリソースの状態を判別できない場合、 fencing を使用して、クラスターを既知の状態に戻します。
リソースレベルのフェンシングは、リソースを構成することにより、停止時にデータが破損しないことを主に保証します。 たとえば、リソースレベルのフェンシングをDRBD(Distributed Replicated Block Device)で使用して、通信リンクがダウンしたときにノード上のディスクを古いものとしてマークすることができます。
ノードレベルのフェンシングは、ノードがリソースを実行しないことを保証します。 これはノードをリセットすることによって行われ、そのPacemaker実装はSTONITH(「頭の中で他のノードを撃つ」の略)と呼ばれます。 Pacemakerは、さまざまなフェンシングデバイスをサポートしています。 サーバー用の無停電電源装置または管理インターフェースカード。
ノードレベルのフェンシング構成は環境に大きく依存するため、このチュートリアルでは無効にします。
sudo pcs property set stonith-enabled=false
注:実稼働環境でPacemakerを使用する場合は、環境に応じてSTONITHの実装を計画し、有効にしておく必要があります。
クォーラムとは何ですか?
ノードの半分以上がオンラインの場合、クラスターにはクォーラムがあります。 Pacemakerのデフォルトの動作は、クラスターにクォーラムがない場合にすべてのリソースを停止することです。 ただし、これは2ノードクラスターでは意味がありません。 1つのノードに障害が発生すると、クラスターはクォーラムを失います。
このチュートリアルでは、no-quorum-policy
を設定して、クォーラムを無視するようにPacemakerに指示します。
sudo pcs property set no-quorum-policy=ignore
手順7—仮想IPアドレスを構成する
今後は、pcs
シェルを介してクラスターと対話するため、すべてのコマンドを1つのホストで実行するだけで済みます。 どちらでも構いません。
これでPacemakerクラスターが稼働し、最初のリソースである仮想IPアドレスを追加できます。 これを行うには、ocf:heartbeat:IPaddr2
リソースエージェントを構成しますが、最初に、いくつかの用語について説明します。
すべてのリソースエージェント名には、コロンで区切られた3つまたは2つのフィールドがあります。
- 最初のフィールドはリソースクラスです。これは、リソースエージェントが準拠する標準です。 また、スクリプトの場所をPacemakerに通知します。
IPaddr2
リソースエージェントは、OCF(Open Cluster Framework)標準に準拠しています。 - 2番目のフィールドは規格によって異なります。 OCFリソースは、OCF名前空間の2番目のフィールドを使用します。
- 3番目のフィールドは、リソースエージェントの名前です。
リソースは、メタ属性およびインスタンス属性を持つことができます。 メタ属性はリソースタイプに依存しません。 インスタンス属性はリソースエージェント固有です。 このリソースエージェントに必要なインスタンス属性はip
(仮想IPアドレス)のみですが、わかりやすくするために、cidr_netmask
(CIDR表記のサブネットマスク)も設定します。
リソース操作は、クラスターがリソースに対して実行できるアクションです(例: 開始、停止、監視)。 それらはキーワードop
で示されます。 monitor
操作を20秒間隔で追加して、クラスターがリソースがまだ正常であるかどうかを20秒ごとにチェックするようにします。 正常と見なされるものは、リソースエージェントによって異なります。
まず、仮想IPアドレスリソースを作成します。 ここでは、仮想IPとして127.0.0.2
を使用し、リソースの名前としてCluster_VIPを使用します。
sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip=127.0.0.2 cidr_netmask=24 op monitor interval=20s
次に、リソースのステータスを確認します。
sudo pcs status
出力で次の行を探します。
出力
... Full list of resources: Cluster_VIP (ocf::heartbeat:IPaddr2): Started webnode01 ...
仮想IPアドレスはホストwebnode01でアクティブです。
ステップ8—Apacheリソースの追加
これで、2番目のリソースをクラスターに追加できます。これはApacheサービスになります。 サービスのリソースエージェントはocf:heartbeat:apache
です。
リソースにWebServer
という名前を付け、インスタンス属性configfile
(Apache構成ファイルの場所)とstatusurl
(ApacheサーバーステータスページのURL)を設定します。 再度20秒のモニター間隔を選択します。
sudo pcs resource create WebServer ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://127.0.0.1/server-status" op monitor interval=20s
以前と同じように、リソースのステータスを照会できます。
sudo pcs status
webnode02で実行されている出力にWebServerが表示されます。
出力
... Full list of resources: Cluster_VIP (ocf::heartbeat:IPaddr2): Started webnode01 WebServer (ocf::heartbeat:apache): Started webnode02 ...
ご覧のとおり、リソースはさまざまなホストで実行されます。 これらのリソースは同じホスト上で実行する必要があるため、ノード全体に均等に分散されることをPacemakerにまだ伝えていません。
注: sudo pcs resource restart WebServer
を実行すると、Apacheリソースを再起動できます(例: Apache構成を変更した場合)。 Apacheサービスの管理にsystemctl
を使用しないように注意してください。
ステップ9—コロケーション制約の構成
リソースを実行する場所の選択など、Pacemakerクラスター内のほとんどすべての決定は、スコアを比較することによって行われます。 スコアはリソースごとに計算され、クラスターリソースマネージャーは特定のリソースのスコアが最も高いノードを選択します。 (ノードのリソースのスコアが負の場合、そのリソースはそのノードで実行できません。)
制約付きでクラスターの決定を操作できます。 制約にはスコアがあります。 制約のスコアがINFINITYよりも低い場合、それは単なる推奨事項です。 INFINITYのスコアは、それが必須であることを意味します。
両方のリソースが同じホストで実行されるようにしたいので、スコアがINFINITYのコロケーション制約を定義します。
sudo pcs constraint colocation add WebServer Cluster_VIP INFINITY
制約定義内のリソースの順序は重要です。 ここでは、Apacheリソース(WebServer
)が、仮想IP(Cluster_VIP
)がアクティブになっているのと同じホストで実行される必要があることを指定します。 これは、Cluster_VIP
がアクティブでない場合、WebSite
はどこでも実行できないことも意味します。
順序の制約を作成してリソースを実行する順序を定義したり、場所の制約を作成して一部のリソースに対して特定のホストを優先したりすることもできます。
両方のリソースが同じホストで実行されていることを確認します。
sudo pcs status
出力
... Full list of resources: Cluster_VIP (ocf::heartbeat:IPaddr2): Started webnode01 WebServer (ocf::heartbeat:apache): Started webnode01 ...
現在、両方のリソースがwebnode01にあります。
結論
仮想IPアドレスでアクセスできるApache2ノードアクティブ-パッシブクラスターを設定しました。 これでApacheをさらに構成できますが、ホスト間で構成を同期するようにしてください。 このためのカスタムスクリプトを書くことができます(例: rsync
)を使用するか、csync2のようなものを使用できます。
Webアプリケーションのファイルをホスト間で配布する場合は、DRBDボリュームをセットアップし、それをPacemakerと統合できます。