序章

サービスの停止は非常にコストがかかる可能性があるため、高可用性は今日の重要なトピックです。 停止した場合に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 またはお気に入りのテキストエディタ。

  1. 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をインストールします。

  1. sudo yum install httpd

Apacheリソースエージェントは、Apacheサーバーのステータスページを使用して、Apacheサービスの状態をチェックします。 ファイルを作成してステータスページをアクティブ化する必要があります /etc/httpd/conf.d/status.conf.

  1. 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クラスターシェルをインストールします。 後者を後でクラスターの構成に使用します。

  1. sudo yum install pacemaker pcs

次に、ノード間でCorosync構成を同期するために使用されるpcsデーモンを起動する必要があります。

  1. sudo systemctl start pcsd.service

再起動するたびにデーモンが起動するように、サービスも有効にします。

  1. sudo systemctl enable pcsd.service

これらのパッケージをインストールすると、haclusterという名前の新しいユーザーがシステムに追加されます。 インストール後、このユーザーのリモートログインは無効になります。 構成の同期や他のノードでのサービスの開始などのタスクでは、このユーザーに同じパスワードを設定する必要があります。

  1. sudo passwd hacluster

ステップ4—Pacemakerの設定

次に、FirewallDでクラスタートラフィックを許可して、ホストが通信できるようにします。

まず、FirewallDが実行されているかどうかを確認します。

  1. sudo firewall-cmd --state

実行されていない場合は、起動します。

  1. sudo systemctl start firewalld.service

両方のホストでこれを行う必要があります。 実行したら、を追加します high-availability FirewallDへのサービス。

  1. sudo firewall-cmd --permanent --add-service=high-availability

この変更後、FirewallDをリロードする必要があります。

  1. sudo firewall-cmd --reload

FirewallDの詳細については、CentOS7でFirewallDを構成する方法に関するこのガイドをお読みください。

2つのホストが相互に通信できるようになったので、1つのホスト（この場合は webnode01 ）でこのコマンドを実行することにより、2つのノード間の認証を設定できます。

  1. sudo pcs cluster auth webnode01 webnode02

  2. Username: hacluster

次の出力が表示されます。

出力
webnode01: Authorized
webnode02: Authorized

次に、同じホスト上でCorosync構成を生成して同期します。 ここでは、クラスターに webcluster という名前を付けますが、任意の名前を付けることができます。

  1. 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で次のコマンドを実行することで開始できます。

  1. sudo pcs cluster start --all

Pacemakerとcorosyncが起動時に確実に起動するようにするには、両方のホストでサービスを有効にする必要があります。

  1. sudo systemctl enable corosync.service

  2. sudo systemctl enable pacemaker.service

これで、いずれかのホストで次のコマンドを実行して、クラスターのステータスを確認できます。

  1. 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は、さまざまなフェンシングデバイスをサポートしています。 サーバー用の無停電電源装置または管理インターフェースカード。

ノードレベルのフェンシング構成は環境に大きく依存するため、このチュートリアルでは無効にします。

  1. sudo pcs property set stonith-enabled=false

注：実稼働環境でPacemakerを使用する場合は、環境に応じてSTONITHの実装を計画し、有効にしておく必要があります。

クォーラムとは何ですか？

ノードの半分以上がオンラインの場合、クラスターにはクォーラムがあります。 Pacemakerのデフォルトの動作は、クラスターにクォーラムがない場合にすべてのリソースを停止することです。 ただし、これは2ノードクラスターでは意味がありません。 1つのノードに障害が発生すると、クラスターはクォーラムを失います。

このチュートリアルでは、Pacemakerにクォーラムを無視するように指示します。 no-quorum-policy:

  1. sudo pcs property set no-quorum-policy=ignore

手順7—仮想IPアドレスを構成する

これからは、を介してクラスターと対話します pcs シェルなので、すべてのコマンドは1つのホストでのみ実行する必要があります。 どちらでも構いません。

これでPacemakerクラスターが稼働し、最初のリソースである仮想IPアドレスを追加できます。 これを行うには、 ocf:heartbeat:IPaddr2 リソースエージェントですが、最初にいくつかの用語を取り上げましょう。

すべてのリソースエージェント名には、コロンで区切られた3つまたは2つのフィールドがあります。

  • 最初のフィールドはリソースクラスです。これは、リソースエージェントが準拠する標準です。 また、スクリプトの場所をPacemakerに通知します。 The IPaddr2 リソースエージェントは、OCF（Open Cluster Framework）標準に準拠しています。

  • 2番目のフィールドは規格によって異なります。 OCFリソースは、OCF名前空間の2番目のフィールドを使用します。

  • 3番目のフィールドは、リソースエージェントの名前です。

リソースは、メタ属性およびインスタンス属性を持つことができます。 メタ属性はリソースタイプに依存しません。 インスタンス属性はリソースエージェント固有です。 このリソースエージェントに必要な唯一のインスタンス属性は ip （仮想IPアドレス）が、明確にするために、 cidr_netmask （CIDR表記のサブネットマスク）。

リソース操作は、クラスターがリソースに対して実行できるアクションです（例： 開始、停止、監視）。 それらはキーワードで示されます op. 追加します monitor クラスターがリソースがまだ正常であるかどうかを20秒ごとにチェックするように、20秒間隔で操作します。 正常と見なされるものは、リソースエージェントによって異なります。

まず、仮想IPアドレスリソースを作成します。 ここでは、 127.0.0.2 仮想IPとして、リソースの名前としてCluster_VIPを使用します。

  1. sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip=127.0.0.2 cidr_netmask=24 op monitor interval=20s

次に、リソースのステータスを確認します。

  1. 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秒のモニター間隔を選択します。

  1. 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

以前と同じように、リソースのステータスを照会できます。

  1. sudo pcs status

webnode02で実行されている出力にWebServerが表示されます。

出力
...
Full list of resources:

 Cluster_VIP	(ocf::heartbeat:IPaddr2):	Started webnode01
 WebServer	(ocf::heartbeat:apache):	Started webnode02
...

ご覧のとおり、リソースはさまざまなホストで実行されます。 これらのリソースは同じホスト上で実行する必要があるため、ノード全体に均等に分散されることをPacemakerにまだ伝えていません。

注：を実行してApacheリソースを再起動できます sudo pcs resource restart WebServer （例えば Apache構成を変更した場合）。 使用しないでください systemctl Apacheサービスを管理します。

ステップ9—コロケーション制約の構成

リソースを実行する場所の選択など、Pacemakerクラスター内のほとんどすべての決定は、スコアを比較することによって行われます。 スコアはリソースごとに計算され、クラスターリソースマネージャーは特定のリソースのスコアが最も高いノードを選択します。 （ノードのリソースのスコアが負の場合、そのリソースはそのノードで実行できません。）

制約付きでクラスターの決定を操作できます。 制約にはスコアがあります。 制約のスコアがINFINITYよりも低い場合、それは単なる推奨事項です。 INFINITYのスコアは、それが必須であることを意味します。

両方のリソースが同じホストで実行されるようにしたいので、スコアがINFINITYのコロケーション制約を定義します。

  1. sudo pcs constraint colocation add WebServer Cluster_VIP INFINITY

制約定義内のリソースの順序は重要です。 ここでは、Apacheリソース（WebServer）仮想IPを同じホストで実行する必要があります（Cluster_VIP）がアクティブです。 これはまた、 WebSite 次の場合、どこでも実行することは許可されていません Cluster_VIP アクティブではありません。

順序の制約を作成してリソースを実行する順序を定義したり、場所の制約を作成して一部のリソースに対して特定のホストを優先したりすることもできます。

両方のリソースが同じホストで実行されていることを確認します。

  1. 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と統合できます。