初期クラスタとサービスの構成

3 初期クラスタとサービスの構成

この章では、解決可能なホスト名node1およびnode2を持つシステムでホストされている2つのノード間で初期クラスタを構成する手順とともに、例を示します。各システムは、PacemakerおよびCorosyncのインストールと構成に記載されている手順を使用してインストールおよび構成します。

クラスタは、resource-agentsパッケージに含まれるサービスDummyを実行するように構成されます。このパッケージは、pacemakerパッケージとともにインストールしておく必要があります。このツールは単に、サービスが実行中かどうかを追跡します。Pacemakerは、Dummyプロセスが失敗したかどうかを判断するチェック間の待機時間を決定する間隔パラメータを使用して構成されます。

Dummyプロセスは、障害をシミュレートするためにPacemakerツールの外部で手動で停止されます。これを使用して、プロセスが代替ノードで自動的に再起動される方法を示します。

クラスタの作成

クラスタを作成するには:

クラスタの一部を構成するノードの1つで次のコマンドを実行して、構成内の各ノードでhaclusterユーザー用のpcsクラスタ構成ツールを認証します。
```
sudo pcs host auth node1 node2 -u hacluster
```
node1およびnode2を、クラスタの一部を構成するノードの解決可能なホスト名に置き換えます。

または、ノード名が解決可能でない場合は、次の例に示すように、ノードにアクセスできるIPアドレスを指定します。
```
sudo pcs host auth node1 addr=192.0.2.1 node2 addr=192.0.2.2 -u hacluster
```
192.0.2.1および192.0.2.2を、クラスタ内の各ホストのIPアドレスに置き換えます。

ツールにより、haclusterユーザーのパスワードの入力を求められます。各ノードにPacemakerソフトウェアをインストールして構成したときにこのユーザーに対して設定したパスワードを指定します。
pcs cluster setupコマンドを使用してクラスタを作成します。クラスタの名前と、クラスタ内の各ノードのノード名およびIPアドレスを指定する必要があります。たとえば、次のようなコマンドを実行します。
```
sudo pcs cluster setup pacemaker1 node1 addr=192.0.2.1 node2 addr=192.0.2.2
```
pacemaker1をクラスタの適切な名前に置き換えます。node1およびnode2を、クラスタ内のノードの解決可能なホスト名に置き換えます。192.0.2.1および192.0.2.2を、クラスタ内の各ホストのIPアドレスに置き換えます。

ノードの認証時にaddrオプションを使用してIPアドレスを指定した場合、pcs cluster setupコマンドの実行時にIPアドレスを再度指定する必要はありません。

クラスタ設定プロセスでは、指定されたノード上の既存のクラスタ構成が破棄され、クラスタ内の各ノードにコピーされるCorosyncサービスの構成ファイルが作成されます。

オプションで、pcs cluster setupコマンドの実行時に--startオプションを使用すると、クラスタの作成時に自動的に起動できます。
クラスタ設定コマンドの一部としてクラスタをまだ起動していない場合は、すべてのノードでクラスタを起動します。クラスタを手動で起動するには、pcsコマンドを使用します。
```
sudo pcs cluster start --all
```
systemdからpacemakerサービスを起動してすべてのノードでクラスタを起動する方法もあります。次に例を示します。
```
sudo systemctl start pacemaker.service
```
オプションで、これらのサービスをブート時に起動できるようにし、ノードがリブートした場合に自動的にクラスタに再参加するようにできます。次に例を示します。
```
sudo pcs cluster enable --all
```
または、pacemakerサービスをすべてのノードでsystemdから有効にすることもできます。次に例を示します。
```
sudo systemctl enable pacemaker.service
```
ノート:

ノードがクラスタに再参加する前にシステム全体のリブートの原因となるノード障害を適切にデバッグできるように、これらのサービスを有効にしないことを選択するユーザーもいます。

クラスタ・パラメータの設定

フェンシングは、本番レベルのHAクラスタを設定するための重要な要素です。簡潔にするために、この例では無効になっています。stonithを利用する場合の詳細は、フェンシング(stonith)構成についてを参照してください。

クラスタ・パラメータを設定するには:

次のコマンドを実行してフェンシング機能を無効にします。
```
sudo pcs property set stonith-enabled=false
```
フェンシングは、障害が発生しているノードまたは使用不可になっているノードによってデータが破損しないようにする高度な機能です。Pacemakerでは、フェンシング・オプションを示すためにstonith (Shoot The Other Node In The Head)という語が使用されます。この構成は、特定のハードウェアと、フェンシング・プロセスに対するより深い理解に左右されます。このため、フェンシング機能は無効にすることをお薦めします。
オプションで、次のコマンドを実行して、クォーラム状態を無視するようにクラスタを構成します。
```
sudo pcs property set no-quorum-policy=ignore
```
この例では2ノード・クラスタを使用するため、クォーラム・ポリシーを無効にすることが最も合理的です。クォーラムが実行可能な構成になるには技術的に3つ以上のノードが必要なためです。ノードの半分以上がクラスタのステータスに同意した場合にのみクォーラムに達します。

Corosyncの現在のリリースでは、この問題は2ノード・クラスタに関して特別に処理されます。この場合、プライマリ・ノードが常にクォーラムに達しているとみなされるように、クォーラム値は人為的に1に設定されます。ネットワークの停止によって両方のノードが一定期間オフラインになる場合、ノードは互いに競い合ってフェンシングし、最初に成功した方がクォーラムを獲得します。通常、1つのノードが優先されるようにフェンシング・エージェントを構成でき、これによりそのノードはクォーラムを獲得しやすくなります(これが望ましい場合)。
次のコマンドを実行して、移行ポリシーを構成します。
```
sudo pcs resource defaults update
```
このコマンドを実行すると、1回の障害後にサービスを新しいノードに移動するようにクラスタが構成されます。

サービスの作成とフェイルオーバーのテスト

サービスを作成してフェイルオーバーをテストするには:

サービスを作成し、通常は、プロセスの開始および停止を処理するリソース・エージェントを実行するように構成します。ほとんどのリソース・エージェントは、Linux Standard Base (LSB)の拡張機能として定義されているOpen Cluster Framework (OCF)仕様に従って作成されています。resource-agentsパッケージには、よく使用されるプロセスのための便利なリソース・エージェントが多数含まれており、よく使用されるデーモンやサービスがまだ実行中かどうかを追跡する様々なハートビート・エージェントなどがあります。

次の例では、Pacemakerのテストのために作成されたDummyリソース・エージェントを使用するサービスが設定されます。このエージェントを使用する理由は、このエージェントが基本的な構成を必要とし、環境やPacemakerで実行する予定のサービスのタイプについて何も想定していないからです。

pcs resource createコマンドを使用して、サービスをリソースとして追加します。
```
sudo pcs resource create dummy_service ocf:pacemaker:Dummy op monitor interval=120s
```
前の例では、dummy_serviceがこのリソースのサービスに指定された名前です。

Dummyリソース・エージェントを起動するには、表記(ocf:pacemaker:Dummy)を使用して、これがOCF標準に準拠すること、Pacemakerのネームスペースで実行されること、およびDummyスクリプトを使用する必要があることを指定します。Oracle Databaseのハートビート・モニター・サービスを構成している場合は、ocf:heartbeat:oracleリソース・エージェントを使用できます。

リソースはエージェントのモニター操作を使用するように構成され、サービスのヘルスをチェックする間隔が設定されます。この例では、フェイルオーバーのデモ中にサービスが失敗するのに十分な時間を与えるために、間隔が120秒に設定されています。デフォルトでは、この間隔は通常20秒に設定されますが、サービスのタイプおよび特定の環境に応じて変更できます。

サービスを作成すると、クラスタはリソース・エージェントの起動コマンドを使用してノード上でリソースを起動します。

リソースの開始および実行ステータスを表示します。次に例を示します。

sudo pcs status

次のような出力結果が表示されます。

Cluster name: pacemaker1
Stack: corosync
Current DC: node2 (version 2.1.2-4.0.1.el8_6.2-ada5c3b36e2) - partition with quorum
Last updated: Wed Jul 13 04:56:27 2022
Last change: Wed Jul 13 04:56:11 2022 by root via cibadmin on node1

2 nodes configured
1 resource configured

Online: [ node1 node2 ]

Full list of resources:

 dummy_service  (ocf::pacemaker:Dummy): Started node1

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

サービスを直接強制停止することによってサービス障害をシミュレートするには、crm_resourceコマンドを実行します。
```
sudo crm_resource --resource dummy_service --force-stop
```
crm_resourceコマンドを実行すると、サービスが手動で停止されたことをクラスタが認識しなくなります。
ノードに障害が発生するまで待機できるように、crm_monコマンドを対話型モードで実行し、Failed Actionsメッセージを調べます。次に例を示します。
```
sudo crm_mon
```
次のような出力結果が表示されます。
```
Stack: corosync
Current DC: node1 (version 2.1.2-4.0.1.el8_6.2-ada5c3b36e2) - partition with quorum
Last updated: Wed Jul 13 05:00:27 2022
Last change: Wed Jul 13 04:56:11 2022 by root via cibadmin on node1

3 nodes configured
1 resource configured

Online: [ node1 node2 ]

Active resources:

dummy_service   (ocf::pacemaker:Dummy): Started node2

Failed Resource Actions:
* dummy_service_monitor_120000 on node1 'not running' (7): call=7, status=complete, exitreason='',
    last-rc-change='Wed Jul 13 05:00:11 2022', queued=0ms, exec=0ms
```
代替ノードでサービスが再起動されたことがわかります。デフォルトのモニター期間が120秒に設定されているため、その時間いっぱいまで待機しないと、ノードがオフラインになったことを示す通知が表示されないことがあります。

ヒント:

[Ctrl]+[C]のキーの組合せを使用すると、任意の時点でcrm_monを終了できます。
サービスが実行されているノードをリブートし、ノード障害発生時にフェイルオーバーも発生するかどうかを確認します。

corosyncおよびpacemakerサービスをブート時に起動できるようにしていない場合は、次のコマンドを実行して、リブートしたノードでサービスを手動で起動する必要がある場合があります:
```
sudo pcs cluster start node1
```