Red Hat Training

A Red Hat training course is available for RHEL 8

高可用性クラスターの設定および管理

Red Hat Enterprise Linux 8

Red Hat High Availability Add-On の設定および管理

Red Hat Customer Content Services

概要

本書は、Red Hat Enterprise Linux 8 に Red Hat High Availability Add-On をインストール、設定、および管理する方法を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 High Availability Add-On の概要

High Availability Add-On は、基幹実稼働サービスに、信頼性、スケーラビリティー、および可用性を提供するクラスターシステムです。

クラスターは、連携してタスクを実行する 2 つ以上のコンピューター (ノード または メンバー と呼ばれています) を指します。クラスターを使用すると、可用性の高いサービスまたはリソースを提供できます。複数のマシンによr冗長性は、様々な障害から保護するために使用されます。

高可用性クラスターは、単一障害点を排除し、ノードが稼働しなくなった場合に、あるクラスターノードから別のクラスターノードにサービスをフェイルオーバーして、可用性が高いサービスを提供します。通常、高可用性クラスターのサービスは、(read-write でマウントされたファイルシステム経由で) データの読み取りや書き込みを行います。したがって、あるクラスターノードが別のクラスターノードからサービスの制御を引き継ぐ際に、高可能性クラスターでデータ整合性を維持する必要があります。高可用性クラスター内のノードの障害は、クラスター外にあるクライアントからは確認できません。また、高可用性クラスターはフェイルオーバークラスターと呼ばれることがあります。 High Availability Add-On は、高可用性サービス管理コンポーネントの Pacemaker を介して、高可用性クラスタリングを提供します。

1.1. High Availability Add-On コンポーネント

High Availability Add-On は、以下の主要なコンポーネントで構成されています。

  • クラスターインフラストラクチャー - クラスターとして連携するように、ノード群に基本的な機能 (設定ファイル管理、メンバーシップ管理、ロック管理、およびフェンシング) を提供します。
  • 高可用性サービス管理 - 1 つのクラスターノードが動作不能になった場合は、そのクラスターノードから別のノードにサービスのフェイルオーバーを提供します。
  • クラスター管理ツール - High Availability Add-On のセットアップ、設定、および管理を行うツール。このツールは、クラスターインフラストラクチャーのコンポーネント、高可用性およびサービス管理のコンポーネント、ならびにストレージで使用されます。

以下のコンポーネントで、High Availability Add-On を補完できます。

  • Red Hat GFS2 (Global File System 2) - Resilient Storage Add-On に同梱され、High Availability Add-On で使用するクラスターファイルシステムを提供します。GFS2 により、ストレージがローカルで各クラスターノードに接続されているかのように、ブロックレベルにおいて、複数ノードでストレージを共有できるようになります。GFS2 クラスターファイルシステムを使用する場合は、クラスターインフラストラクチャーが必要になります。
  • LVM ロッキングデーモン (lvmlockd) - Resilient Storage Add-On に同梱され、クラスターストレージのボリューム管理を提供します。lvmlockd に対応するには、クラスターインフラストラクチャーも必要になります。
  • Load Balancer Add-On - レイヤー 4 (TCP) およびレイヤー 7 (HTTP および HTTPS) サービスで高可用性負荷分散とフェイルオーバーを提供するルーティングソフトウェアです。Load Balancer Add-On は、負荷アルゴリズムを使用して、クライアント要求を実サーバーに分散する冗長な仮想ルーターのクラスターで実行し、まとまって仮想サーバーとして機能します。Load Balancer Add-On は、Pacemaker と併用する必要はありません。

1.2. Pacemaker の概要

Pacemaker は、クラスターリソースマネージャーです。クラスターインフラストラクチャーのメッセージング機能およびメンバーシップ機能を使用して、ノードおよびリソースレベルの障害を防ぎ、障害から復旧することで、クラスターサービスおよびリソースの可用性を最大化します。

1.2.1. Pacemaker アーキテクチャーコンポーネント

Pacemaker で設定されたクラスターは、クラスターメンバーシップを監視する個別のコンポーネントデーモン、サービスを管理するスクリプト、および異なるリソースを監視するリソース管理サブシステムで構成されます。

Pacemaker アーキテクチャーを形成するコンポーネントは、以下のとおりです。

Cluster Information Base (CIB)
XML を内部的に使用して、DC (Designated Coordinator) (CIB を介してクラスターのステータスと動作を格納および分散するために、Pacemaker により割り当てられたノード) から、他のすべてのクラスターノードに対して現在の設定とステータスの情報を分散し、同期する Pacemaker 情報デーモン。
Cluster Resource Management Daemon (CRMd)

Pacemaker クラスターリソースの動作は、このデーモンを介してルーティングされます。CRMd により管理されるリソースは、必要に応じてクライアントシステムが問い合わせることができます。また、リソースを移動したり、インスタンス化したり、変更したりできます。

各クラスターノードには、CRMd とリソースの間のインターフェースとして動作する LRMd (Local Resource Manager daemon) も含まれます。LRMd は、起動、停止、ステータス情報のリレーなどのコマンドを、CRMd からエージェントに渡します。

Shoot the Other Node in the Head (STONITH)
STONITH は Pacemaker フェンシングの実装です。STONITH は、フェンス要求を処理する Pacemaker のクラスターリソースとして動作し、強制的にノードをシャットダウンし、クラスターからノードを削除してデータの整合性を確保します。STONITH は、CIB で設定し、通常のクラスターリソースとして監視できます。フェンシングの概要は「フェンシングの概要」を参照してください。
corosync

corosync は、コアメンバーシップと、高可用性クラスターのメンバー間の通信ニーズに対応するコンポーネントで、デーモンも同じ名前になります。これは、High Availability Add-On が機能するのに必要です。

corosync は、このようなメンバーシップとメッセージング機能のほかに、以下も提供します。

  • クォーラムのルールおよび決定を管理します。
  • クラスターの複数のメンバーに渡って調整または動作するアプリケーションへのメッセージング機能を提供します。そのため、インスタンス間で、ステートフルな情報またはその他の情報を通信できる必要があります。
  • kronosnet ライブラリーをネットワークトランスポートとして使用し、複数の冗長なリンクおよび自動フェイルオーバーを提供します。

1.2.2. 設定ツールおよび管理ツール

High Availability Add-On には、クラスターのデプロイメント、監視、および管理に使用する 2 つの設定ツールが含まれます。

pcs

pcs コマンドラインインターフェースは、Pacemaker および corosync ハートビートデーモンを制御し、設定します。コマンドラインベースのプログラムである pcs は、以下のクラスター管理タスクを実行できます。

  • Pacemaker/Corosync クラスターの作成および設定
  • 実行中のクラスターの設定変更
  • Pacemaker と Corosync の両方のリモートでの設定、ならびにクラスターの起動、停止、およびステータス情報の表示
pcsd Web UI
Pacemaker/Corosync クラスターを作成および設定するグラフィカルユーザーインターフェースです。

1.2.3. クラスターおよび Pacemaker の設定ファイル

Red Hat High Availability Add-On の設定ファイルは、corosync.conf および cib.xml です。

corosync.conf ファイルは、Pacemaker を構築するクラスターマネージャー (corosync) が使用するクラスターパラメーターを提供します。通常は、直接 corosync.conf を編集するのではなく、pcs インターフェースまたは pcsd インターフェースを使用します。

cib.xml ファイルは、クラスターの設定、およびクラスターの全リソースにおいて現在の状態を表す XML ファイルです。このファイルは、Pacemaker のクラスター情報ベース (CIB) により使用されます。CIB の内容は、自動的にクラスター全体に同期されます。cib.xml ファイルは直接編集せず、代わりに pcs インターフェースまたは pcsd インターフェースを使用してください。

1.3. フェンシングの概要

クラスター内のノードの 1 つと通信が失敗した場合に、障害が発生したクラスターノードがアクセスする可能性があるリソースへのアクセスを、その他のノードが制限したり、解放したりできるようにする必要があります。クラスターノードが応答しない可能性があるため、そのクラスターノードと通信しても成功しません。代わりに、フェンスエージェントを使用した、フェンシングと呼ばれる外部メソッドを指定する必要があります。フェンスデバイスは、クラスターが使用する外部デバイスのことで、このデバイスを使用して、不安定なノードによる共有リソースへのアクセスを制限したり、クラスタノードでハードリブートを実行します。

フェンスデバイスが設定されていないと、以前使用していたリソースが解放されていることを切断されているクラスターノードが把握できず、他のクラスターノードでサービスを実行できなくなる可能性があります。また、クラスターノードがそのリソースを解放したとシステムが誤って想定し、データが破損または損失する可能性もあります。フェンスデバイスが設定されていないと、データの整合性は保証できず、クラスター設定はサポートされません。

フェンシングの進行中は、他のクラスター操作を実行できません。クラスターノードの再起動後にフェンシングが完了するか、クラスターノードがクラスターに再度参加するまで、クラスターの通常の動作を再開することができません。

フェンシングの詳細は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。

1.4. クォーラムの概要

クラスターの整合性と可用性を維持するために、クラスターシステムは、クォーラム と呼ばれる概念を使用してデータの破損や損失を防ぎます。クラスターノードの過半数がオンラインになると、クラスターでクォーラムが確立されます。クラスターでクォーラムが確立されない場合は、障害によるデータ破損の可能性を小さくするために、Pacemaker はデフォルトですべてのリソースを停止します。

クォーラムは、投票システムを使用して確立されます。クラスターノードが通常どおり機能しない場合や、クラスターの他の部分との通信が失われた場合に、動作している過半数のノードが、問題のあるノードを分離するように投票し、必要に応じて、接続を切断して別のノードに切り替えてサービスを継続 (フェンス) します。

たとえば、6 ノードクラスターで、4 つ以上のクラスターノードが動作している場合にクォーラムが確立されます。過半数のノードがオフラインまたは利用できない状態になると、クラスターでクォーラムが確立されず、Pacemaker がクラスター化サービスを停止します。

Pacemaker におけるクォーラム機能は、スプレットブレイン と呼ばれる状況が発生しないようにします。スプレットブレインは、クラスターが通信から分離されたあとも、各部分が別のクラスターとして機能し続けることで、同じデータの書き込みや、データの破壊または損失が発生する可能性がある現象です。スプリットブレイン状態の詳細と、一般的なクォーラムの概念は「Exploring Concepts of RHEL High Availability Clusters - Quorum」を参照してください。

Red Hat High Availability Add-On クラスターは、スプリットブレインの状況を回避するために、votequorum サービスをフェンシングと併用します。クラスターの各システムには多くの投票数が割り当てられ、過半数の票を取得しているものだけがクラスターの操作を継続できます。

1.5. リソースの概要

クラスターリソース は、クラスターサービスで管理するプログラム、データ、またはアプリケーションのインスタンスです。このようなリソースは、クラスター環境でリソースを管理する標準インターフェースを提供する エージェント により抽象化されます。

リソースを健全な状態に保つために、リソースの定義に監視操作を追加できます。リソースの監視操作を指定しない場合は、デフォルトで監視操作が追加されます。

クラスター内のリソースの動作は、制約 を指定することで設定できます。以下の制約のカテゴリーを設定できます。

  • 場所の制約 - リソースを実行できるノードを設定する
  • 順序の制約 - リソースを実行する順序を設定する
  • コロケーションの制約 - 他のリソースに対して相対的なリソースの配置先を設定する

クラスターの最も一般的な構成要素の 1 つがリソースセットです。リソースセットはまとめて配置し、順番に起動し、その逆順で停止する必要があります。この設定を簡略化するために、Pacemaker では グループ という概念がサポートされます。

1.6. Red Hat High Availability クラスターの LVM 論理ボリューム

Red Hat High Availability Add-On で対応している LVM ボリュームでは、2 つのクラスター設定を使用できます。

  • アクティブ/パッシブのフェイルオーバー設定の HA-LVM (High Availability LVM) ボリューム。クラスターで同時にストレージにアクセスするノードは 1 つだけになります。
  • アクティブ/アクティブ設定でストレージデバイスを管理する lvmlockd を使用する LVM ボリューム。クラスターで、1 つ以上のクラスターが同時にストレージにアクセスする必要があります。lvmlockd デーモンは、Resilient Storage Add-On で提供されます。

1.6.1. HA-LVM または共有ボリュームの選択

HA-LVM、または lvmlockd デーモンが管理する共有論理ボリュームを使用するタイミングは、デプロイされるアプリケーションまたはサービスのニーズに基づいて決定する必要があります。

  • クラスターの複数のノードが、アクティブ/アクティブシステムで LVM ボリュームへの同時読み取りまたは書き込みを必要とする場合に、lvmlockd デーモンを使用して、ボリュームを共有ボリュームとして設定します。lvmlockd デーモンは、クラスターのノード全体で、LVM ボリュームのアクティベーションおよび変更を同時に調整するシステムを提供します。lvmlockd デーモンのロックサービスでは、クラスターのさまざまなノードがボリュームと対話し、レイアウトに変更を加えて、LVM メタデータを保護します。この保護は、複数のクラスタノードで同時にアクティブにされるボリュームグループを共有ボリュームとして構成することにより決まります。
  • アクティブ/パッシブで共有リソースを管理するように HA クラスターを設定し、指定した LVM ボリュームに同時にアクセスするメンバーを 1 つのみにした場合は、HA-LVM で lvmlockd ロックサービスを使用する必要はありません。

ほとんどのアプリケーションは、その他のインスタンスと同時に実行するように設計または最適化されていないため、アクティブ/パッシブ設定での実行により適しています。共有論理ボリュームで、クラスターに対応していないアプリケーションを実行すると、パフォーマンスが低下することがあります。これは、論理ボリューム自体にクラスター通信のオーバーヘッドが発生するためです。クラスター対応のアプリケーションは、クラスターファイルシステムとクラスター対応の論理ボリュームにより発生するパフォーマンスの低下を上回るパフォーマンスの向上を実現できるようにする必要があります。実現が容易かどうかは、アプリケーションやワークロードによって異なります。クラスターの要件を判断し、アクティブ/アクティブのクラスターを最適化する努力に価値があるかどうかを判断して、どちらの LVM を使用するかを選択します。ほとんどの場合は、HA-LVM を使用すると HA を最適化できます。

HA-LVM および lvmlockd を使用する共有論理ボリュームは、複数のマシンが変更を重複して行うと発生する、LVM メタデータとその論理ボリュームの破損を防ぐという点で似ています。HA-LVM では、論理ボリュームは、アクティベートする場合は排他的に行うように制限されているため、一度に 1 つのマシンでしかアクティブになりません。そのため、ストレージドライバーのローカル (非クラスター) 実装のみが使用されます。このようにクラスターの調整オーバーヘッドが発生しないようにすると、パフォーマンスが向上します。lvmlockd を使用する共有ボリュームにはこのような制限はなく、ユーザーは、クラスターのすべてのマシンで論理ボリュームをアクティベートできます。これにより、クラスター対応のストレージドライバーの使用が強制され、クラスター対応のファイルシステムとアプリケーションが優先されます。

1.6.2. クラスター内での LVM ボリュームの設定

Red Hat Enterprise Linux 8 では、クラスターは Pacemaker で管理されます。HA-LVM および共有論理ボリュームは、Pacemaker クラスターと併用される場合のみサポートされ、クラスターリソースとして設定する必要があります。

第2章 Pacemaker の使用の開始

以下の手順では、Pacemaker クラスターを作成するのに使用するツールとプロセスの概要を説明します。ここで説明する内容は、クラスターソフトウェアの概要と、作業用のクラスターを設定せずに管理する方法に関心のあるユーザーを対象としています。

注記

ここで説明する手順では、2 つ以上のノードとフェンシングデバイスの設定が必要となるサポート対象の Red Hat クラスターは作成されません。

2.1. Pacemaker の使用方法

この例では、RHEL 8 を実行している 1 つのノードと、そのノードに静的に割り当てられている IP アドレスの 1 つと同じネットワークにあるフローティング IP アドレスが必要です。

  • この例で使用されているノードは、z1.example.com です。
  • この例で使用されているフローティング IP アドレスは、192.168.122.120 です。
注記

/etc/hosts ファイルに、実行しているノードの名前があることを確認してください。

ここでは、Pacemaker を使用してクラスターを設定する方法、クラスターのステータスを表示する方法、およびクラスターサービスを設定する方法を学習します。この例では、Apache HTTP サーバーをクラスターリソースとして作成し、リソースに障害が発生した場合のクラスターの応答方法を表示します。

  1. High Availability チャンネルから Red Hat High Availability Add-On ソフトウェアパッケージをインストールし、pcsd サービスを起動して有効にします。

    # yum install pcs pacemaker fence-agents-all
    ...
    # systemctl start pcsd.service
    # systemctl enable pcsd.service

    firewalld デーモンを実行している場合は、Red Hat High Availability Add-On で必要なポートを有効にします。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  2. クラスターの各ノードにユーザー hacluster のパスワードを設定し、pcs コマンドを実行するノードにあるクラスターの各ノードに対して、hacluster ユーザーの認証を行います。この例では、ノードを 1 つだけ使用し、そのノードからコマンドを実行していますが、このステップはサポート対象の Red Hat High Availability マルチノードクラスターを設定する際に必要となるため、この手順に含まれています。

    # passwd hacluster
    ...
    # pcs host auth z1.example.com
  3. メンバーを 1 つ含む my_cluster という名前のクラスターを作成し、クラスターのステータスを確認します。この 1 つのコマンドで、クラスターが作成され、起動します。

    # pcs cluster setup my_cluster --start z1.example.com
    ...
    # pcs cluster status
    Cluster Status:
     Stack: corosync
     Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
     Last updated: Thu Oct 11 16:11:18 2018
     Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z1.example.com
     1 node configured
     0 resources configured
    
    PCSD Status:
      z1.example.com: Online
  4. Red Hat High Availability クラスターでは、クラスターのフェンシングを設定することが必要になります。この要件が必要になる理由は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。ただし、ここでは基本的な Pacemaker コマンドの使用方法を説明することを目的としているため、stonith-enabled クラスターのオプションを false に設定し、フェンシングを無効にします。

    警告

    stonith-enabled=false の使用は、実稼働クラスターには完全に適していません。これにより、障害が発生したノードが適切にフェンスされていることを装うようにクラスターに指示されます。

    # pcs property set stonith-enabled=false
  5. システムに Web ブラウザーを設定し、Web ページを作成して簡単なテキストメッセージを表示します。firewalld デーモンを実行している場合は、httpd で必要なポートを有効にします。

    注記

    システムの起動時に使用する場合は、systemctl enable で、クラスターが管理するサービスを有効にしないでください。

    # yum install -y httpd wget
    ...
    # firewall-cmd --permanent --add-service=http
    # firewall-cmd --reload
    
    # cat <<-END >/var/www/html/index.html
    <html>
    <body>My Test Site - $(hostname)</body>
    </html>
    END

    Apache リソースエージェントが Apache のステータスを取得できるようにするため、既存の設定に以下の内容を追加して、ステータスサーバーの URL を有効にします。

    # cat <<-END > /etc/httpd/conf.d/status.conf
    <Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from ::1
    </Location>
    END
  6. クラスターが管理するリソース IPaddr2 および apache を作成します。「IPaddr2」はフローティング IP であるため、物理ノードに関連付けられている IP アドレスは使用できません。「IPaddr2」の NIC デバイスを指定しない場合は、そのノードで使用される、静的に割り当てられた IP アドレスと同じネットワークにフローティング IP が存在する必要があります。

    利用可能なリソースタイプの一覧を表示する場合は、pcs resource list コマンドを使用します。指定したリソースタイプに設定できるパラメーターを表示する場合は、pcs resource describe resourcetype コマンドを使用します。たとえば、以下のコマンドは、apache タイプのリソースに設定できるパラメーターを表示します。

    # pcs resource describe apache
    ...

    この例では、IP アドレスリソースと apache リソースの両方が apachegroup グループに含まれるように設定します。これにより、両リソースが一緒に保存され、作業用のマルチノードクラスターを設定する際に、同じノードで実行できます。

    # pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.120 --group apachegroup
    
    # pcs resource create WebSite ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" --group apachegroup
    
    # pcs status
    Cluster name: my_cluster
    Stack: corosync
    Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
    Last updated: Fri Oct 12 09:54:33 2018
    Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com
    
    1 node configured
    2 resources configured
    
    Online: [ z1.example.com ]
    
    Full list of resources:
    
    Resource Group: apachegroup
        ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
        WebSite    (ocf::heartbeat:apache):        Started z1.example.com
    
    PCSD Status:
      z1.example.com: Online
    ...

    クラスターリソースを設定したら、pcs resource config コマンドを使用して、そのリソースに設定したオプションを表示します。

    # pcs resource config WebSite
    Resource: WebSite (class=ocf provider=heartbeat type=apache)
     Attributes: configfile=/etc/httpd/conf/httpd.conf statusurl=http://localhost/server-status
     Operations: start interval=0s timeout=40s (WebSite-start-interval-0s)
                 stop interval=0s timeout=60s (WebSite-stop-interval-0s)
                 monitor interval=1min (WebSite-monitor-interval-1min)
  7. ブラウザーで、設定済みのフローティング IP アドレスを使用して作成した Web サイトを開くように指定します。定義したテキストメッセージが表示されるはずです。
  8. Apache Web サービスを停止し、クラスターのステータスを確認します。killall -9 を使用して、アプリケーションレベルのクラッシュをシミュレートします。

    # killall -9 httpd

    クラスターのステータスを確認します。Web サービスは停止したためアクションは失敗しますが、クラスターソフトウェアがサービスを再起動したため、Web サイトに引き続きアクセスできることが確認できるはずです。

    # pcs status
    Cluster name: my_cluster
    ...
    Current DC: z1.example.com (version 1.1.13-10.el7-44eb2dd) - partition with quorum
    1 node and 2 resources configured
    
    Online: [ z1.example.com ]
    
    Full list of resources:
    
    Resource Group: apachegroup
        ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
        WebSite    (ocf::heartbeat:apache):        Started z1.example.com
    
    Failed Resource Actions:
    * WebSite_monitor_60000 on z1.example.com 'not running' (7): call=13, status=complete, exitreason='none',
        last-rc-change='Thu Oct 11 23:45:50 2016', queued=0ms, exec=0ms
    
    PCSD Status:
        z1.example.com: Online

    サービスが再開すると、障害が発生したリソースの障害 (failure) ステータスが削除されるため、クラスターステータスを確認する際に、障害が発生したアクションの通知が表示されなくなります。

    # pcs resource cleanup WebSite
  9. クラスターと、クラスターのステータスを確認したら、ノードでクラスターサービスを停止します。(この手順を試すために、実際にサービスを起動したノードが 1 つだけであっても) --all パラメーターを追加してください。これにより実際のマルチノードクラスターの全ノードでクラスターサービスが停止します。

    # pcs cluster stop --all

2.2. フェイルオーバーの設定方法

以下の手順では、サービスを実行する Pacemaker クラスターの作成方法を紹介します。このサービスは、サービスを実行しているノードが利用できなくなると、現在のノードから別のノードにフェイルオーバーします。この手順を行って、2 ノードクラスターでサービスを作成する方法と、サービスを実行しているノードでサービスが失敗するとどうなるかを確認します。

この手順では、Apache HTTP サーバーを実行する 2 ノード Pacemaker クラスターを設定します。その後、1 つのノードで Apache サービスを停止し、どのようにしてサービスを利用可能のままにしているかを確認できます。

この手順では、相互に通信が可能な Red Hat Enterprise Linux 8 を実行するノードを 2 つ用意するという要件を満たし、フローティング IP アドレスが、そのノードに静的に割り当てられている IP アドレスの 1 つと同じネットワークにあることが必要です。

  • この例で使用されるノードは、z1.example.com および z2.example.com です。
  • この例で使用されているフローティング IP アドレスは、192.168.122.120 です。
注記

各ノードの /etc/hosts ファイルに、使用しているノード名が登録されていることを確認します。

  1. 両方のノードで、High Availability チャンネルから Red Hat High Availability Add-On ソフトウェアパッケージをインストールし、pcsd サービスを起動して有効にします。

    # yum install pcs pacemaker fence-agents-all
    ...
    # systemctl start pcsd.service
    # systemctl enable pcsd.service

    firewalld デーモンを実行している場合は、両方のノードで、Red Hat High Availability Add-On で必要なポートを有効にします。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  2. クラスター内の両方のノードに、hacluster ユーザーのパスワードを設定します。

    # passwd hacluster
  3. pcs コマンドを実行するノードで、クラスター内の各ノードに対して hacluster ユーザーの認証を行います。

    # pcs host auth z1.example.com z2.example.com
  4. 両方のノードで、クラスターメンバーとなるクラスター my_cluster を作成します。この 1 つのコマンドで、クラスターが作成され、起動します。pcs 設定コマンドはクラスター全体に適用されるため、このコマンドは、クラスター内のいずれかのノードで実行してください。

    クラスター内のいずれかのノードで、以下のコマンドを実行します。

    # pcs cluster setup my_cluster --start z1.example.com z2.example.com
  5. Red Hat High Availability クラスターでは、クラスターのフェンシングを設定することが必要になります。この要件が必要になる理由は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。ただし、この設定でフェイルオーバーがどのように機能するかを示す場合は、stonith-enabled クラスターのオプションを false に設定し、フェンシングを無効にします。

    警告

    stonith-enabled=false の使用は、実稼働クラスターには完全に適していません。これにより、障害が発生したノードが適切にフェンスされていることを装うようにクラスターに指示されます。

    # pcs property set stonith-enabled=false
  6. クラスターを作成し、フェンシングを無効にしたら、クラスターのステータスを確認します。

    注記

    pcs cluster status コマンドを実行したときの出力は、一時的に、システムコンポーネントの起動時の例とは若干異なる場合があります。

    # pcs cluster status
    Cluster Status:
     Stack: corosync
     Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
     Last updated: Thu Oct 11 16:11:18 2018
     Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z1.example.com
     2 nodes configured
     0 resources configured
    
    PCSD Status:
      z1.example.com: Online
      z2.example.com: Online
  7. 両方のノードに Web ブラウザーを設定し、Web ページを作成して簡単なテキストメッセージを表示します。firewalld デーモンを実行している場合は、httpd で必要なポートを有効にします。

    注記

    システムの起動時に使用する場合は、systemctl enable で、クラスターが管理するサービスを有効にしないでください。

    # yum install -y httpd wget
    ...
    # firewall-cmd --permanent --add-service=http
    # firewall-cmd --reload
    
    # cat <<-END >/var/www/html/index.html
    <html>
    <body>My Test Site - $(hostname)</body>
    </html>
    END

    Apache リソースエージェントが、クラスターの各ノードで Apache のステータスを取得できるようにするため、既存の設定に以下の内容を追加して、ステータスサーバーの URL を有効にします。

    # cat <<-END > /etc/httpd/conf.d/status.conf
    <Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from ::1
    </Location>
    END
  8. クラスターが管理するリソース IPaddr2 および apache を作成します。「IPaddr2」はフローティング IP であるため、物理ノードに関連付けられている IP アドレスは使用できません。「IPaddr2」の NIC デバイスを指定しない場合は、そのノードで使用される、静的に割り当てられた IP アドレスと同じネットワークにフローティング IP が存在する必要があります。

    利用可能なリソースタイプの一覧を表示する場合は、pcs resource list コマンドを使用します。指定したリソースタイプに設定できるパラメーターを表示する場合は、pcs resource describe resourcetype コマンドを使用します。たとえば、以下のコマンドは、apache タイプのリソースに設定できるパラメーターを表示します。

    # pcs resource describe apache
    ...

    この例では、IP アドレスリソースおよび apache リソースの両方が、apachegroup という名前のグループに含まれるように設定します。これにより、両リソースが一緒に保存され、同じノードで実行できます。

    クラスター内のいずれかのノードで、次のコマンドを実行します。

    # pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.120 --group apachegroup
    
    # pcs resource create WebSite ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" --group apachegroup
    
    # pcs status
    Cluster name: my_cluster
    Stack: corosync
    Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
    Last updated: Fri Oct 12 09:54:33 2018
    Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com
    
    2 nodes configured
    2 resources configured
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
    
    Resource Group: apachegroup
        ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
        WebSite    (ocf::heartbeat:apache):        Started z1.example.com
    
    PCSD Status:
      z1.example.com: Online
      z2.example.com: Online
    ...

    このインスタンスでは、apachegroup サービスが z1.example.com ノードで実行していることに注意してください。

  9. 作成した Web サイトにアクセスし、サービスを実行しているノードでそのサービスを停止し、2 番目のノードにサービスがフェイルオーバーする方法を確認してください。

    1. ブラウザーで、設定済みのフローティング IP アドレスを使用して作成した Web サイトを開くように指定します。定義したテキストメッセージが表示され、Web サイトを実行しているノードの名前が表示されるはずです。
    2. Apache Web サービスを停止します。killall -9 を使用して、アプリケーションレベルのクラッシュをシミュレートします。

      # killall -9 httpd

      クラスターのステータスを確認します。Web サービスを停止したためにアクションが失敗したものの、サービスが実行していたノードでクラスターソフトウェアがサービスを再起動するため、Web サイトに引き続きアクセスできるはずです。

      # pcs status
      Cluster name: my_cluster
      Stack: corosync
      Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
      Last updated: Fri Oct 12 09:54:33 2018
      Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com
      
      2 nodes configured
      2 resources configured
      
      Online: [ z1.example.com z2.example.com ]
      
      Full list of resources:
      
      Resource Group: apachegroup
          ClusterIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
          WebSite    (ocf::heartbeat:apache):        Started z1.example.com
      
      Failed Resource Actions:
      * WebSite_monitor_60000 on z1.example.com 'not running' (7): call=31, status=complete, exitreason='none',
          last-rc-change='Fri Feb  5 21:01:41 2016', queued=0ms, exec=0ms

      サービスが再開したら、障害 (failure) ステータスを削除します。

      # pcs resource cleanup WebSite
    3. サービスを実行しているノードをスタンバイモードにします。フェンシングを無効にしているため、ノードレベルの障害 (電源ケーブルを引き抜くなど) を効果的にシミュレートできません。クラスターがこのような状態から復旧するにはフェンシングが必要になるためです。

      # pcs node standby z1.example.com
    4. クラスターのステータスを確認し、サービスを実行している場所をメモします。

      # pcs status
      Cluster name: my_cluster
      Stack: corosync
      Current DC: z1.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
      Last updated: Fri Oct 12 09:54:33 2018
      Last change: Fri Oct 12 09:54:30 2018 by root via cibadmin on z1.example.com
      
      2 nodes configured
      2 resources configured
      
      Node z1.example.com: standby
      Online: [ z2.example.com ]
      
      Full list of resources:
      
      Resource Group: apachegroup
          ClusterIP  (ocf::heartbeat:IPaddr2):       Started z2.example.com
          WebSite    (ocf::heartbeat:apache):        Started z2.example.com
    5. Web サイトにアクセスします。サービスの切断はありません。表示メッセージには、サービスを実行しているノードが含まれるはずです。
  10. クラスターサービスを最初のノードに復元するには、そのノードをスタンドバイモードから回復します。ただし、必ずしもそのサービスが最初のノードに戻るわけではありません。

    # pcs node unstandby z1.example.com
  11. 最終的なクリーンナップを行うために、両方のノードでクラスターサービスを停止します。

    # pcs cluster stop --all

第3章 pcs コマンドラインインターフェース

pcs コマンドラインインターフェースを使用すると、corosyncpacemakerboothsbd などのクラスターサービスを制御し、設定を簡単に行うことができます。

cib.xml 設定ファイルは直接編集しないでください。ほとんどの場合、Pacemaker は、直接編集した cib.xml ファイルを受け付けません。

3.1. pcs help display

pcs コマンドで -h オプションを使用すると、pcs コマンドのパラメーターと、その説明が表示されます。たとえば、以下のコマンドは、pcs resource コマンドのパラメーターを表示します。出力の一部だけが表示されます。

# pcs resource -h

3.2. 未編集のクラスター設定の表示

クラスター設定ファイルは直接編集しないようにしてください。未編集のクラスター設定は、pcs cluster cib コマンドで表示できます。

pcs cluster cib filename コマンドを使用すると、未編集のクラスター設定を、指定したファイルに保存できます。クラスターを事前に設定していて、アクティブな CIB が存在する場合は、以下のコマンドを実行して、未編集の xml ファイルを保存します。

pcs cluster cib filename

たとえば、次のコマンドを使用すると、testfile という名前のファイルに、未編集の CIB の xml ファイルが保存されます。

pcs cluster cib testfile

3.3. 作業ファイルへの設定変更の保存

クラスターを設定する際に、アクティブな CIB に影響を及ぼさずに、指定したファイルに設定変更を保存できます。これにより、個々の更新を使用して実行中のクラスター設定を直ちに更新することなく、設定の更新を指定できます。

CIB をファイルに保存する方法は、「raw クラスター設定の表示」を参照してください。そのファイルを作成したら、pcs コマンドの -f オプションを使用したアクティブな CIB ではなく、ファイルに設定変更を保存できます。変更を完了し、アクティブな CIB ファイルへの更新が用意できたら、pcs cluster cib-push コマンドでファイルの更新をプッシュできます。

以下は、CIB のファイルに変更をプッシュする際に推奨される手順です。この手順は、保存した CIB ファイルのコピーを作成し、そのコピーを変更します。アクティブな CIB にその変更をプッシュする場合は、ここで、pcs cluster cib-push コマンドの diff-against オプションを指定して、元のファイルと、変更したファイルの差異だけが CIB にプッシュされるようにします。これにより、ユーザーが互いを上書きしないように、並列に変更を加えることができます。ここでは、構成ファイル全体を解析する必要はないため、Pacemaker への負荷が減ります。

  1. ファイルへのアクティブな CIB を保存します。この例では、original.xml という名前のファイルに CIB が保存されます。

    # pcs cluster cib original.xml
  2. 設定の更新に使用する作業ファイルに、保存したファイルをコピーします。

    # cp original.xml updated.xml
  3. 必要に応じて設定を更新します。以下のコマンドは、updated.xml ファイルにリソースを作成しますが、現在実行しているクラスター設定にはそのリソースを追加しません。

    # pcs -f updated.xml resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 op monitor interval=30s
  4. 更新したファイルを、アクティブな CIB にプッシュします。元のファイルに加えた変更のみをプッシュするように指定します。

    # pcs cluster cib-push updated.xml diff-against=original.xml

もしくは、次のコマンドを使用して、CIB ファイルの現在のコンテンツ全体をプッシュできます。

pcs cluster cib-push filename

CIB ファイル全体をプッシュすると、Pacemaker はバージョンを確認して、クラスターにあるものよりも古い場合は CIB ファイルをプッシュしません。クラスターにあるものよりも古いバージョンで CIB ファイル全体を更新する必要がある場合は、pcs cluster cib-push コマンドの --config オプションを使用します。

pcs cluster cib-push --config filename

3.4. クラスターのステータス表示

次のコマンドで、クラスターおよびクラスターリソースのステータスを表示します。

pcs status

pcs status コマンドの commands パラメーター (resourcesclusternodes、または pcsd) を指定すると、特定のクラスターコンポーネントのステータスを表示できます。

pcs status commands

たとえば、次のコマンドは、クラスターリソースのステータスを表示します。

pcs status resources

このコマンドはクラスターの状態を表示しますが、クラスターリソースの状態は表示しません。

pcs cluster status

3.5. クラスターの全設定の表示

現在のクラスター設定をすべて表示する場合は、次のコマンドを実行します。

pcs config

第4章 Pacemaker を使用した Red Hat High Availability クラスターの作成

以下の手順では、pcs を使用して、2 ノードの Red Hat High Availability クラスターを作成します。

この例では、クラスターを設定するために、システムに以下のコンポーネントを追加する必要があります。

  • クラスターを作成するのに使用する 2 つのノード。この例では、使用されるノードは z1.example.com および z2.example.com です。
  • プライベートネットワーク用のネットワークスイッチ。クラスターノード同士の通信、およびその他のクラスターハードウェア (ネットワーク電源スイッチやファイバーチャネルスイッチなど) との通信にプライベートネットワークを使用することが推奨されますが、必須ではありません。
  • クラスターの各ノード用のフェンスデバイス。この例では、APC 電源スイッチの 2 ポートを使用します。ホスト名は zapc.example.com です。

4.1. クラスターソフトウェアのインストール

以下の手順では、クラスターソフトウェアをインストールし、システムでクラスターの作成を構成するように設定します。

  1. クラスターの各ノードに、Red Hat High Availability Add-On ソフトウェアパッケージと、使用可能なすべてのフェンスエージェントを、High Availability チャンネルからインストールします。

    # yum install pcs pacemaker fence-agents-all

    または、次のコマンドを実行して、Red Hat High Availability Add-On ソフトウェアパッケージと、必要なフェンスエージェントのみをインストールすることもできます。

    # yum install pcs pacemaker fence-agents-model

    次のコマンドは、利用できるフェンスエージェントの一覧を表示します。

    # rpm -q -a | grep fence
    fence-agents-rhevm-4.0.2-3.el7.x86_64
    fence-agents-ilo-mp-4.0.2-3.el7.x86_64
    fence-agents-ipmilan-4.0.2-3.el7.x86_64
    ...
    警告

    Red Hat High Availability Add-On パッケージをインストールしたら、自動的に何もインストールされないように、ソフトウェア更新設定を行う必要があります。実行中のクラスターにインストールすると、予期しない動作が発生する可能性があります。詳細は「RHEL 高可用性またはレジリエントストレージクラスターにソフトウェアアップデートを適用するのに推奨されるプラクティス」を参照してください。

  2. firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

    注記

    firewalld デーモンがシステムにインストールされているかどうかを確認する場合は、rpm -q firewalld コマンドを実行します。firewalld デーモンがインストールされている場合は、firewall-cmd --state コマンドで、実行しているかどうかを確認できます。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --add-service=high-availability
    注記

    クラスターコンポーネントの理想的なファイアウォール設定は、ローカル環境によって異なります。ここでは、ノードに複数のネットワークインターフェースがあるかどうか、またはオフホストのファイアウォールがあるかどうかを検討しないといけない場合があります。この例では、Pacemaker クラスターで通常必要となるポートを開きますが、ローカル条件に合わせて変更する必要があります。「High Availability Add-On のポートの有効化」では、Red Hat High Availability Add-On で有効にするポートと、各ポートの使用目的を説明します。

  3. pcs を使用してクラスターの設定やノード間の通信を行うため、pcs の管理アカウントとなるユーザー ID hacluster のパスワードを各ノードに設定する必要があります。hacluster ユーザーのパスワードは、各ノードで同じにすることが推奨されます。

    # passwd hacluster
    Changing password for user hacluster.
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.
  4. クラスターを設定する前に、各ノードで、システムの起動時に pcsd デーモンを起動できるように、デーモンを起動して有効にしておく必要があります。このデーモンは、pcs コマンドで動作し、クラスターのノード全体で設定を管理します。

    クラスターの各ノードで次のコマンドを実行して、システムの起動時に pcsd サービスが起動し、pcsd が有効になるように設定します。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service

4.2. pcp-zeroconf パッケージのインストール (推奨)

クラスターを設定する際に、PCP (Performance Co-Pilot) ツールの pcp-zeroconf パッケージをインストールすることが推奨されます。PCP は、RHEL システムに推奨される Red Hat の resource-monitoring ツールです。pcp-zeroconf パッケージをインストールすると、PCP を実行してパフォーマンス監視データを収集して、フェンシング、リソース障害、およびクラスターを中断するその他のイベントの調査に役立てることができます。

注記

PCP が有効になっているクラスターデプロイメントには、/var/log/pcp/ を含むファイルシステムで PCPが取得したデータ用に十分な領域が必要です。PCP による一般的な領域使用はデプロイメントごとに異なりますが、通常 pcp-zeroconf のデフォルト設定を使用する場合は 10Gb で十分であり、環境によっては必要な量が少なくなることがあります。一般的なアクティビティーの 14 日間におけるこのディレクトリーの使用状況を監視すると、より正確な使用状況の概算値が得られます。

pcp-zeroconf パッケージをインストールするには、次のコマンドを実行します。

# yum install pcp-zeroconf

このパッケージは pmcd を有効にし、10 秒間隔でデータキャプチャーを設定します。

PCP データを確認する方法は、Red Hat カスタマーポータルの「Why did a RHEL High Availability cluster node reboot - how can I prevent it again」を参照してください。

4.3. 高可用性クラスターの作成

この手順では、z1.example.com ノードおよび z2.example.com ノードで構成される Red Hat High Availability Add-On クラスターを作成します。

  1. pcs を実行するノードで、クラスター内の各ノードに対して、pcs ユーザー hacluster を認証します。

    次のコマンドは、z1.example.comz2.example.com で構成される 2 ノードクラスターの両ノードに対して、z1.example.comhacluster ユーザーを認証します。

    [root@z1 ~]# pcs host auth z1.example.com z2.example.com
    Username: hacluster
    Password:
    z1.example.com: Authorized
    z2.example.com: Authorized
  2. z1.example.com で以下のコマンドを実行し、2 つのノード z1.example.comz2.example.com で構成される 2 ノードクラスター my_cluster を作成します。これにより、クラスター設定ファイルが、クラスターの両ノードに伝搬されます。このコマンドには --start オプションが含まれます。このオプションを使用すると、クラスターの両ノードでクラスターサービスが起動します。

    [root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com
  3. クラスターサービスを有効にし、ノードの起動時にクラスターの各ノードでクラスターサービスが実行するようにします。

    注記

    使用している環境でクラスターサービスを無効のままにしておきたい場合などは、この手順を省略できます。この手順を行うことで、ノードがダウンした場合にクラスターやリソース関連の問題をすべて解決してから、そのノードをクラスターに戻すことができます。クラスターサービスを無効にしている場合は、ノードを再起動する時に、ノードで pcs cluster start コマンドを実行し、サービスを手動で起動する必要があります。

    [root@z1 ~]# pcs cluster enable --all

pcs cluster status コマンドを使用すると、クラスターの現在のステータスを表示できます。pcs cluster setup コマンドで --start オプションを使用してクラスターサービスを起動した場合は、クラスターが稼働するのに時間が少しかかる可能性があるため、クラスターとその設定で後続の動作を実行する前に、クラスターが稼働していることを確認する必要があります。

[root@z1 ~]# pcs cluster status
Cluster Status:
 Stack: corosync
 Current DC: z2.example.com (version 2.0.0-10.el8-b67d8d0de9) - partition with quorum
 Last updated: Thu Oct 11 16:11:18 2018
 Last change: Thu Oct 11 16:11:00 2018 by hacluster via crmd on z2.example.com
 2 Nodes configured
 0 Resources configured

...

4.4. 複数のリンクを使用した高可用性クラスターの作成

pcs cluster setup コマンドを使用して、各ノードにリンクをすべて指定することで、複数のリンクを持つ Red Hat High Availability クラスターを作成できます。

2 つのリンクを持つ 2 ノードクラスターを作成するコマンドの形式は、以下のとおりです。

pcs cluster setup cluster_name node1_name addr=node1_link0_address addr=node1_link1_address node2_name addr=node2_link0_address addr=node2_link1_address

複数のリンクを持つクラスタを作成する場合は、次に示す内容を検討してください。

  • addr=address パラメーターの順番は重要です。ノード名の後に指定する最初のアドレスは link0 に使用され、2 番目以降のアドレスは link1 以降に順に使用されます。
  • デフォルトのトランスポートプロトコルである knet トランスポートプロトコルを使用して、リンクを 8 つまで指定できます。
  • addr= パラメーターの数は、すべてのノードで同じでなければなりません。
  • RHEL 8.1 より、pcs cluster link add コマンド、pcs cluster link remove コマンド、pcs cluster link delete コマンド、および pcs cluster link update コマンドを使用して、既存クラスターのリンクを追加、削除、および変更できます。
  • シングルリンククラスターと同様、1 つのリンクで IPv4 アドレスと IPv6 アドレスを混在させないでください。ただし、1 つのリンクで IPv4 を実行し、別のリンクで IPv6 を実行することはできます。
  • シングルリンククラスターと同様、1 つのリンクで IPv4 アドレスと IPv6 アドレスが混在しない IPv4 アドレスまたは IPv6 アドレスで名前が解決される限り、アドレスを IP アドレスまたは名前として指定できます。

この例では、2 つのノード rh80-node1rh80-node2 で構成される 2 ノードクラスター my_twolink_cluster を作成します。rh80-node1 のインターフェースとして、IP アドレス 192.168.122.201 を link0、192.168.123.201 を link1 に設定します。rh80-node2 のインターフェースとして、IP アドレス 192.168.122.202 を link0、192.168.123.202 を link1 に設定します。

# pcs cluster setup my_twolink_cluster rh80-node1 addr=192.168.122.201 addr=192.168.123.201 rh80-node2 addr=192.168.122.202 addr=192.168.123.202

複数のリンクを持つ既存クラスターにノードを追加する方法は、「複数リンクを持つクラスターへのノードの追加」を参照してください。

複数のリンクを持つ既存クラスターのリンクを変更する方法は、「既存クラスターのリンクの追加および修正」を参照してください。

4.5. フェンシングの設定

クラスターの各ノードにフェンスデバイスを設定する必要があります。フェンスの設定コマンドおよびオプションに関する情報は「Red Hat High Availability クラスターでのフェンシングの設定」を参照してください。

フェンシングの概要と、Red Hat High Availability クラスターにおけるフェンシングの重要性は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。

注記

フェンスデバイスを設定する場合は、そのデバイスが、クラスター内のノードまたはデバイスと電源を共有しているかどうかに注意する必要があります。ノードとそのフェンスデバイスが電源を共有していると、その電源をフェンスできず、フェンスデバイスが失われた場合は、クラスターがそのノードをフェンスできない可能性があります。このようなクラスターには、フェンスデバイスおよびノードに冗長電源を提供するか、または電源を共有しない冗長フェンスデバイスが存在する必要があります。SBD やストレージフェンシングなど、その他のフェンシング方法でも、分離した電源供給の停止時に冗長性を得られます。

ここでは、ホスト名が zapc.example.com の APC 電源スイッチを使用してノードをフェンスし、fence_apc_snmp フェンスエージェントを使用します。どちらのノードも同じフェンスエージェントでフェンシングされるため、pcmk_host_map オプションを使用して、両方のフェンスデバイスを 1 つのリソースとして設定できます。

pcs stonith create コマンドを使用して、stonith リソースとしてデバイスを設定し、フェンスデバイスを作成します。以下のコマンドは、z1.example.com ノードおよび z2.example.com ノードの fence_apc_snmp フェンスエージェントを使用する、stonith リソース myapc を設定します。pcmk_host_map オプションにより、z1.example.com がポート 1 にマップされ、z2.example.com がポート 2 にマップされます。APC デバイスのログイン値とパスワードはいずれも apc です。デフォルトでは、このデバイスは各ノードに対して、60 秒間隔で監視を行います。

また、ノードのホスト名を指定する際に、IP アドレスを使用できます。

[root@z1 ~]# pcs stonith create myapc fence_apc_snmp \
ipaddr="zapc.example.com" pcmk_host_map="z1.example.com:1;z2.example.com:2" \
login="apc" passwd="apc"

次のコマンドは、既存の STONITH デバイスのパラメーターを表示します。

[root@rh7-1 ~]# pcs stonith config myapc
 Resource: myapc (class=stonith type=fence_apc_snmp)
  Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2 login=apc passwd=apc
  Operations: monitor interval=60s (myapc-monitor-interval-60s)

フェンスデバイスの設定後に、デバイスをテストする必要があります。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

注記

ネットワークインターフェースを無効にしてフェンスデバイスのテストを実行しないでください。フェンシングが適切にテストされなくなります。

注記

フェンシングを設定してクラスターが起動すると、タイムアウトに到達していなくても、ネットワークの再起動時に、ネットワークを再起動するノードのフェンシングが発生します。このため、ノードで意図しないフェンシングが発生しないように、クラスターサービスの実行中はネットワークサービスを再起動しないでください。

4.6. クラスター設定のバックアップおよび復元

次のコマンドを使用して、クラスター設定のバックアップを tarball に作成できます。ファイル名を指定しないと、標準出力が使用されます。

pcs config backup filename
注記

pcs config backup コマンドは、CIB に設定したようにクラスターの設定だけをバックアップします。リソースデーモンの設定は、このコマンドに含まれません。たとえば、クラスターで Apache リソースを設定すると、(CIB にある) リソース設定のバックアップが作成されますが、(/etc/httpd に設定したとおり) Apache デーモン設定と、そこで使用されるファイルのバックアップは作成されません。同様に、クラスターに設定されているデータベースリソースがある場合は、データベースそのもののバックアップが作成されません。ただし、データベースのリソース設定のバックアップ (CIB) は作成されます。

以下のコマンドを使用して、バックアップからすべてのノードのクラスター設定ファイルを復元します。ファイル名を指定しないと、標準入力が使用されます。--local オプションは、現在のノードにあるファイルだけを復元します。

pcs config restore [--local] [filename]

4.7. High Availability Add-On のポートの有効化

クラスターコンポーネントの理想的なファイアウォール設定は、ローカル環境によって異なります。ここでは、ノードに複数のネットワークインターフェースがあるかどうか、またはオフホストのファイアウォールがあるかどうかを検討しないといけない場合があります。

firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

ローカルの状況に合わせて開くポートを変更することが必要になる場合があります。

注記

firewalld デーモンがシステムにインストールされているかどうかを確認する場合は、rpm -q firewalld コマンドを実行します。firewalld デーモンをインストールしている場合は、firewall-cmd --state コマンドを使用して、そのデーモンが実行しているかどうかを確認できます。

表4.1「High Availability Add-On で有効にするポート」では、Red Hat High Availability Add-On で有効にするポートを示し、ポートの使用目的を説明します。

表4.1 High Availability Add-On で有効にするポート

ポート必要になる場合

TCP 2224

すべてのノードに必要なデフォルトの pcsd ポートで必須 (pcsd Web UI で必要、ノード間通信で必須) です。/etc/sysconfig/pcsd ファイルの PCSD_PORT パラメーターを使用して pcsd を設定できます。

ポート 2224 を開いて、任意のノードの pcs が、それ自体も含め、クラスター内のすべてのノードに通信できるようにする必要があります。Booth クラスターチケットマネージャーまたはクォーラムデバイスを使用する場合は、Booth Arbiter、クォーラムデバイスなどのすべての関連ホストで、ポート 2224 を開く必要があります。

TCP 3121

クラスターに Pacemaker リモートノードがある場合に、すべてのノードで必須です。

完全なクラスターノードにある Pacemaker の pacemaker-based デーモンは、ポート 3121 で Pacemaker リモートノードの pacemaker_remoted デーモンへの通信を行います。クラスター通信に別のインターフェースを使用する場合は、そのインターフェースでポートを開くことのみが必要になります。少なくとも、ポートは、Pacemaker リモートノードの全クラスターノードに対して開いている必要があります。ユーザーは完全なノードとリモートノード間でホストを変換する可能性があるか、ホストのネットワークを使用してコンテナー内でリモートノードを実行する可能性があるため、すべてのノードにポートを開くと便利になる場合があります。ノード以外のホストにポートを開く必要はありません。

TCP 5403

corosync-qnetd で、クォーラムデバイスを使用するクォーラムデバイスホストで必須です。デフォルト値は、corosync-qnetd コマンドの -p オプションで変更できます。

UDP 5404-5412

ノード間の通信を容易にするために corosync ノードで必須です。ポート 5404-5412 を開いて、任意のノードの corosync が、それ自体も含め、すべてのノードと通信できるようにする必要があります。

TCP 21064

DLM が必要なリソースがクラスターに含まれる場合に、すべてのノードで必須です (例: GFS2)。

TCP 9929、UDP 9929

Booth チケットマネージャーを使用してマルチサイトクラスターを確立する場合に、同じノードから接続するために、すべてのクラスターノードと、Booth 仲裁ノードで開いている必要があります。

第5章 Red Hat High Availability クラスターでのアクティブ/パッシブ Apache HTTP サーバーの設定

以下の手順では、pcs を使用して、2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターでアクティブ/パッシブな Apache HTTP サーバーを設定し、クラスターリソースを設定します。このユースケースでは、クライアントはフローティング IP アドレスを使用して Apache HTTP サーバーにアクセスします。Web サーバーは、クラスターにある 2 つのノードのいずれかで実行します。Web サーバーが実行しているノードが正常に動作しなくなると、Web サーバーはクラスターの 2 番目のノードで再起動し、サービスの中断は最小限に抑えられます。

図5.1「2 ノードの Red Hat High Availability クラスターの Apache」は、クラスターがネットワーク電源スイッチと共有ストレージで構成された 2 ノードの Red Hat High Availability クラスターであるクラスターの高レベルの概要を示しています。クライアントは仮想 IP を使用して Apache HTTP サーバーにアクセスするため、クラスターノードはパブリックネットワークに接続されます。Apache サーバーは、ノード 1 またはノード 2 のいずれかで実行します。いずれのノードも、Apache のデータが保持されるストレージにアクセスできます。この図では、Web サーバーが ノード 1 で実行しており、ノード 1 が正常に動作しなくなると、ノード 2 がサーバーを実行できます。

図5.1 2 ノードの Red Hat High Availability クラスターの Apache

2 ノードの Red Hat High Availability クラスターの Apache

このユースケースでは、システムに以下のコンポーネントが必要です。

  • 各ノードに電源フェンスが設定されている 2 ノードの Red Hat High Availability クラスター。プライベートネットワークが推奨されますが、必須ではありません。この手順では、「Pacemaker を使用した Red Hat High Availability クラスターの作成」で説明されているサンプルのクラスターを使用します。
  • Apache に必要なパブリック仮想 IP アドレス。
  • iSCSI (もしくは他の共有ネットワークデバイス) またはファイバーチャネルを使用する、クラスターのノードに対する共有ストレージ。

クラスターは、Web サーバーで必要な LVM リソース、ファイルシステムリソース、IP アドレスリソース、Web サーバーリソースなどのクラスターコンポーネントを含む Apache リソースグループで設定されます。このリソースグループは、クラスター内のあるノードから別のノードへのフェールオーバーが可能なため、いずれのノードでも Web サーバーを実行できます。このクラスターのリソースグループを作成する前に、以下の手順を実行します。

  1. 論理ボリューム my_lv に、 ext4 ファイルシステムを設定します。
  2. Web サーバーを設定します。

上記の手順をすべて完了したら、リソースグループと、そのグループに追加するリソースを作成します。

5.1. Pacemaker クラスターで ext4 ファイルシステムを持つ LVM ボリュームの設定

このユースケースでは、クラスターのノード間で共有されるストレージに、LVM 論理ボリュームを作成する必要があります。

注記

LVM ボリュームと、クラスターノードで使用するパーティションおよびデバイスは、クラスターノード以外には接続しないでください。

以下の手順では、LVM 論理ボリュームを作成して Pacemaker クラスターで使用できるように、ボリュームに ext4 ファイルシステムを作成します。この例では、LVM 論理ボリュームを作成する LVM 物理ボリュームを保管するのに、共有パーティション /dev/sdb1 が使用されます。

  1. クラスターの両ノードで以下の手順を実行し、LVM システム ID の値を、システムの uname 識別子の値に設定します。LVM システム ID を使用すると、クラスターのみがボリュームグループをアクティブにできるようになります。

    1. /etc/lvm/lvm.conf 設定ファイルの system_id_source 設定オプションを uname に設定します。

      # Configuration option global/system_id_source.
      system_id_source = "uname"
    2. ノードの LVM システム ID が、ノードの uname に一致することを確認します。

      # lvm systemid
        system ID: z1.example.com
      # uname -n
        z1.example.com
  2. LVM ボリュームを作成し、そのボリュームに ext4 ファイルシステムを作成します。/dev/sdb1 パーティションは共有されるストレージであるため、この手順のこの部分は、1 つのノードでのみ実行してください。

    1. パーティション /dev/sdb1 に LVM 物理ボリュームを作成します。

      # pvcreate /dev/sdb1
        Physical volume "/dev/sdb1" successfully created
    2. 物理ボリューム /dev/sdb1 で構成されるボリュームグループ my_vg を作成します。

      # vgcreate my_vg /dev/sdb1
        Volume group "my_vg" successfully created
    3. 新規ボリュームグループには、実行中のノードで、かつボリュームグループの作成元であるノードのシステム ID があることを確認します。

      # vgs -o+systemid
        VG    #PV #LV #SN Attr   VSize  VFree  System ID
        my_vg   1   0   0 wz--n- <1.82t <1.82t z1.example.com
    4. ボリュームグループ my_vg を使用して、論理ボリュームを作成します。

      # lvcreate -L450 -n my_lv my_vg
        Rounding up size to full physical extent 452.00 MiB
        Logical volume "my_lv" created

      lvs コマンドを実行すると、論理ボリュームを表示できます。

      # lvs
        LV      VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
        my_lv   my_vg   -wi-a---- 452.00m
        ...
    5. 論理ボリューム my_lv に、ext4 ファイルシステムを作成します。

      # mkfs.ext4 /dev/my_vg/my_lv
      mke2fs 1.44.3 (10-July-2018)
      Creating filesystem with 462848 1k blocks and 115824 inodes
      ...

5.2. Apache HTTP サーバーの設定

以下の手順で、Apache HTTP サーバーを設定します。

  1. クラスターの各ノードに、Apache HTTP サーバーがインストールされていることを確認します。Apache HTTP サーバーのステータスを確認するには、クラスターに wget ツールがインストールされている必要があります。

    各ノードで、以下のコマンドを実行します。

    # yum install -y httpd wget

    firewalld デーモンを実行している場合は、クラスターの各ノードで、Red Hat High Availability Add-On に必要なポートを有効にします。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --reload
  2. Apache リソースエージェントが Apache HTTP サーバーのステータスを取得できるようにするには、クラスター内の各ノードの /etc/httpd/conf/httpd.conf ファイルに以下のテキストが含まれ、コメントアウトされていないことを確認してください。これが記載されていない場合は、ファイルの末尾に追加します。

    <Location /server-status>
        SetHandler server-status
        Require local
    </Location>
  3. apache リソースエージェントを使用して Apache を管理する場合は systemd が使用されません。このため、Apache で提供される logrotate スクリプトを編集して、systemctl を使用して Apache を再ロードしないようにする必要があります。

    クラスター内の各ノードで、/etc/logrotate.d/httpd ファイルから以下の行を削除します。

    /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true

    削除した行を以下の行に置き換えます。

    /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
  4. Apache で提供する Web ページを作成します。クラスター内のいずれかのノードに、「LVM ボリュームと ext4 ファイルシステムの設定」で作成したファイルシステムをマウントし、そのファイルシステムで index.html ファイルを作成し、ファイルシステムをアンマウントします。

    # mount /dev/my_vg/my_lv /var/www/
    # mkdir /var/www/html
    # mkdir /var/www/cgi-bin
    # mkdir /var/www/error
    # restorecon -R /var/www
    # cat <<-END >/var/www/html/index.html
    <html>
    <body>Hello</body>
    </html>
    END
    # umount /var/www

5.3. リソースおよびリソースグループの作成

このユースケースでは、クラスターリソースを 4 つ作成する必要があります。すべてのリソースが必ず同じノードで実行するように、このリソースを、リソースグループ apachegroup に追加します。作成するリソースは、以下の順に開始します。

  1. 「LVM ボリュームと ext4 ファイルシステムの設定」で作成した LVM ボリュームグループを使用する LVM リソース my_lvm
  2. 「LVM ボリュームと ext4 ファイルシステムの設定」で作成したファイルシステムデバイス /dev/my_vg/my_lv を使用する Filesystem リソース my_fs
  3. apachegroup リソースグループのフローティング IP アドレスである IPaddr2 リソース。物理ノードに関連付けられている IP アドレスは使用できません。IPaddr2 リソースの NIC デバイスを指定していない場合は、そのノードに静的に割り当てられている IP アドレスの 1 つと同じネットワークにフローティング IP が存在していないと、フローティング IP アドレスを割り当てる NIC デバイスが適切に検出されません。
  4. apache リソース Website で、index.html ファイルと「Apache HTTP サーバーの設定」で定義した Apache 設定を使用します。

以下の手順で、apachegroup リソースグループと、このグループに追加するリソースを作成します。リソースは、グループに追加された順序で起動し、その逆の順序で停止します。この手順は、クラスター内のいずれかのノードで実行してください。

  1. 次のコマンドは、LVM が有効 なリソース my_lvm を作成します。リソースグループ apachegroup は存在しないため、このコマンドによりリソースグループが作成されます。

    注記

    アクティブ/パッシブの HA 設定で、同じ LVM ボリュームグループを使用する LVM が有効 なリソースを複数設定するとデータが破損する場合があるため、そのようなリソースは 1 つ以上設定しないでください。また、LVM が有効 なリソースは、アクティブ/パッシブの HA 設定のクローンリソースとして設定しないでください。

    [root@z1 ~]# pcs resource create my_lvm ocf:heartbeat:LVM-activate vgname=my_vg vg_access_mode=system_id --group apachegroup

    リソースを作成すると、そのリソースは自動的に起動します。以下のコマンドを使用すると、リソースが作成され、起動していることを確認できます。

    # pcs resource status
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM-activate):	Started

    pcs resource disable コマンドおよび pcs resource enable コマンドを使用すると、各リソースを個別に停止および起動できます。

  2. 以下のコマンドでは、設定に必要な残りのリソースを作成し、作成したリソースを既存の apachegroup リソースグループに追加します。

    [root@z1 ~]# pcs resource create my_fs Filesystem \
    device="/dev/my_vg/my_lv" directory="/var/www" fstype="ext4" \
    --group apachegroup
    
    [root@z1 ~]# pcs resource create VirtualIP IPaddr2 ip=198.51.100.3 \
    cidr_netmask=24 --group apachegroup
    
    [root@z1 ~]# pcs resource create Website apache \
    configfile="/etc/httpd/conf/httpd.conf" \
    statusurl="http://127.0.0.1/server-status" --group apachegroup
  3. リソースと、そのリソースを含むリソースグループの作成が完了したら、クラスターのステータスを確認します。4 つのリソースがすべて同じノードで実行していることに注意してください。

    [root@z1 ~]# pcs status
    Cluster name: my_cluster
    Last updated: Wed Jul 31 16:38:51 2013
    Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.10-5.el7-9abe687
    2 Nodes configured
    6 Resources configured
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
     myapc	(stonith:fence_apc_snmp):	Started z1.example.com
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM):	Started z1.example.com
         my_fs	(ocf::heartbeat:Filesystem):	Started z1.example.com
         VirtualIP	(ocf::heartbeat:IPaddr2):	Started z1.example.com
         Website	(ocf::heartbeat:apache):	Started z1.example.com

    クラスターのフェンスデバイスを設定していないと、リソースがデフォルトで起動しません。

  4. クラスターが稼働したら、ブラウザーで、IPaddr2 リソースとして定義した IP アドレスを指定して、「Hello」と単語が表示されるサンプル表示を確認します。

    Hello

    設定したリソースが実行していない場合は、pcs resource debug-start resource コマンドを実行して、リソースの設定をテストします。

5.4. リソース設定のテスト

「リソースおよびリソースグループの作成」で説明するクラスターのステータス表示では、すべてのリソースが z1.example.com ノードで実行します。以下の手順に従い、1 番目のノードを スタンバイ モードにし、リソースグループが z2.example.com ノードにフェールオーバーするかどうかをテストします。1 番目のノードをスタンバイモードにすると、このノードはリソースをホストできなくなります。

  1. 以下のコマンドは、z1.example.com ノードを スタンバイ モードにします。

    [root@z1 ~]# pcs node standby z1.example.com
  2. z1スタンバイ モードにしたら、クラスターのステータスを確認します。リソースはすべて z2 で実行しているはずです。

    [root@z1 ~]# pcs status
    Cluster name: my_cluster
    Last updated: Wed Jul 31 17:16:17 2013
    Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.10-5.el7-9abe687
    2 Nodes configured
    6 Resources configured
    
    Node z1.example.com (1): standby
    Online: [ z2.example.com ]
    
    Full list of resources:
    
     myapc	(stonith:fence_apc_snmp):	Started z1.example.com
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM):	Started z2.example.com
         my_fs	(ocf::heartbeat:Filesystem):	Started z2.example.com
         VirtualIP	(ocf::heartbeat:IPaddr2):	Started z2.example.com
         Website	(ocf::heartbeat:apache):	Started z2.example.com

    定義している IP アドレスの Web サイトは、中断せず表示されているはずです。

  3. スタンバイ モードから z1 を削除するには、以下のコマンドを実行します。

    [root@z1 ~]# pcs node unstandby z1.example.com
    注記

    ノードを スタンバイ モードから削除しても、リソースはそのノードにフェイルオーバーしません。これは、リソースの resource-stickiness 値により異なります。resource-stickiness メタ属性の詳細は、「現在のノードを優先するようにリソースを設定」を参照してください。

第6章 Red Hat High Availability クラスターのアクティブ/パッシブな NFS サーバーの設定

以下の手順では、共有ストレージを使用して、2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターで、高可用性アクティブ/パッシブ NFS サーバーを設定します。この手順では、pcs を使用して Pacemaker クラスターリソースを設定します。このユースケースでは、クライアントが、フローティング IP アドレスから NFS ファイルシステムにアクセスします。NFS サービスは、クラスターにある 2 つのノードのいずれかで実行します。NFS サーバーが実行しているノードが正常に動作しなくなると、NFS サーバーはクラスターの 2 番目のノードで再起動し、サービスの中断が最小限に抑えられます。

6.1. 前提条件

このユースケースでは、システムに以下のコンポーネントが必要です。

  • 各ノードに電源フェンスが設定されている 2 ノードの Red Hat High Availability クラスター。プライベートネットワークが推奨されますが、必須ではありません。この手順では、「Pacemaker を使用した Red Hat High Availability クラスターの作成」で説明されているサンプルのクラスターを使用します。
  • NFS サーバーに必要なパブリック仮想 IP アドレス。
  • iSCSI (もしくは他の共有ネットワークデバイス) またはファイバーチャネルを使用する、クラスターのノードに対する共有ストレージ。

6.2. 手順の概要

既存の 2 ノードの Red Hat Enterprise Linux High Availability クラスターで高可用性アクティブ/パッシブ NFS サーバーを設定するには、以下の手順を実行する必要があります。

  1. クラスターのノードの共有ストレージの LVM 論理ボリューム my_lv に、ext4 ファイルシステムを設定する。
  2. 共有ストレージの LVM 論理ボリュームで NFS 共有を設定する。
  3. クラスターリソースを作成する。
  4. 設定した NFS サーバーをテストする。

6.3. Pacemaker クラスターで ext4 ファイルシステムを持つ LVM ボリュームの設定

このユースケースでは、クラスターのノード間で共有されるストレージに、LVM 論理ボリュームを作成する必要があります。

注記

LVM ボリュームと、クラスターノードで使用するパーティションおよびデバイスは、クラスターノード以外には接続しないでください。

以下の手順では、LVM 論理ボリュームを作成して Pacemaker クラスターで使用できるように、ボリュームに ext4 ファイルシステムを作成します。この例では、LVM 論理ボリュームを作成する LVM 物理ボリュームを保管するのに、共有パーティション /dev/sdb1 が使用されます。

  1. クラスターの両ノードで以下の手順を実行し、LVM システム ID の値を、システムの uname 識別子の値に設定します。LVM システム ID を使用すると、クラスターのみがボリュームグループをアクティブにできるようになります。

    1. /etc/lvm/lvm.conf 設定ファイルの system_id_source 設定オプションを uname に設定します。

      # Configuration option global/system_id_source.
      system_id_source = "uname"
    2. ノードの LVM システム ID が、ノードの uname に一致することを確認します。

      # lvm systemid
        system ID: z1.example.com
      # uname -n
        z1.example.com
  2. LVM ボリュームを作成し、そのボリュームに ext4 ファイルシステムを作成します。/dev/sdb1 パーティションは共有されるストレージであるため、この手順のこの部分は、1 つのノードでのみ実行してください。

    1. パーティション /dev/sdb1 に LVM 物理ボリュームを作成します。

      # pvcreate /dev/sdb1
        Physical volume "/dev/sdb1" successfully created
    2. 物理ボリューム /dev/sdb1 で構成されるボリュームグループ my_vg を作成します。

      # vgcreate my_vg /dev/sdb1
        Volume group "my_vg" successfully created
    3. 新規ボリュームグループには、実行中のノードで、かつボリュームグループの作成元であるノードのシステム ID があることを確認します。

      # vgs -o+systemid
        VG    #PV #LV #SN Attr   VSize  VFree  System ID
        my_vg   1   0   0 wz--n- <1.82t <1.82t z1.example.com
    4. ボリュームグループ my_vg を使用して、論理ボリュームを作成します。

      # lvcreate -L450 -n my_lv my_vg
        Rounding up size to full physical extent 452.00 MiB
        Logical volume "my_lv" created

      lvs コマンドを実行すると、論理ボリュームを表示できます。

      # lvs
        LV      VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
        my_lv   my_vg   -wi-a---- 452.00m
        ...
    5. 論理ボリューム my_lv に、ext4 ファイルシステムを作成します。

      # mkfs.ext4 /dev/my_vg/my_lv
      mke2fs 1.44.3 (10-July-2018)
      Creating filesystem with 462848 1k blocks and 115824 inodes
      ...

6.4. NFS 共有の設定

次の手順では、NFS サービスのフェールオーバーに、NFS 共有を設定します。

  1. クラスターの両方のノードに、/nfsshare ディレクトリーを作成します。

    # mkdir /nfsshare
  2. クラスター内の 1 ノードで、以下の手順を行います。

    1. 「LVM ボリュームと ext4 ファイルシステムの設定」で作成した ext4 ファイルシステムを、/nfsshare ディレクトリーにマウントします。

      [root@z1 ~]# mount /dev/my_vg/my_lv /nfsshare
    2. /nfsshare ディレクトリーに、exports ディレクトリーツリーを作成します。

      [root@z1 ~]# mkdir -p /nfsshare/exports
      [root@z1 ~]# mkdir -p /nfsshare/exports/export1
      [root@z1 ~]# mkdir -p /nfsshare/exports/export2
    3. NFS クライアントがアクセスするファイルを、exports ディレクトリーに置きます。この例では、テストファイル clientdatafile1 および clientdatafile2 を作成します。

      [root@z1 ~]# touch /nfsshare/exports/export1/clientdatafile1
      [root@z1 ~]# touch /nfsshare/exports/export2/clientdatafile2
    4. ext4 ファイルシステムをアンマウントし、LVM ボリュームグループを非アクティブにします。

      [root@z1 ~]# umount /dev/my_vg/my_lv
      [root@z1 ~]# vgchange -an my_vg

6.5. クラスターの NFS サーバーへリソースおよびリソースグループを設定

このセクションでは、このユースケースで、クラスターリソースを設定する手順を説明します。

注記

クラスターにフェンスデバイスを設定していないと、リソースはデフォルトでは起動しないことに注意してください。

設定したリソースが実行していない場合は、pcs resource debug-start resource コマンドを実行して、リソースの設定をテストします。このコマンドは、クラスターの制御や認識の範囲外でサービスを起動します。設定したリソースが再稼働したら、pcs resource cleanup resource を実行して、クラスターが更新を認識するようにします。

以下の手順では、システムリソースを設定します。これらのリソースがすべて同じノードで実行するように、これらのリソースはリソースグループ nfsgroup に含まれます。リソースは、グループに追加された順序で起動し、その逆の順序で停止します。この手順は、クラスター内のいずれかのノードで実行してください。

  1. LVM が有効なリソース my_lvm を作成します。リソースグループ my_lvm は存在しないため、このコマンドによりリソースグループが作成されます。

    警告

    データ破損のリスクとなるため、アクティブ/パッシブの HA 設定で、同じ LVM ボリュームグループを使用する LVM が有効 なリソースを複数設定しないでください。また、LVM が有効 なリソースは、アクティブ/パッシブの HA 設定のクローンリソースとして設定しないでください。

    [root@z1 ~]# pcs resource create my_lvm ocf:heartbeat:LVM-activate vgname=my_vg vg_access_mode=system_id --group nfsgroup
  2. クラスターのステータスを確認し、リソースが実行していることを確認します。

    root@z1 ~]#  pcs status
    Cluster name: my_cluster
    Last updated: Thu Jan  8 11:13:17 2015
    Last change: Thu Jan  8 11:13:08 2015
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.12-a14efad
    2 Nodes configured
    3 Resources configured
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
    
    PCSD Status:
      z1.example.com: Online
      z2.example.com: Online
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled
  3. クラスターに Filesystem リソースを設定します。

    以下のコマンドは、ext4 の Filesystem リソース nfsshare を、nfsgroup リソースグループに追加します。このファイルシステムは、「ext4 ファイルシステムを持つ LVM ボリュームの設定」で作成した、LVM ボリュームグループおよび ext4 ファイルシステムを使用します。このファイルシステムは、「NFS 共有の設定」で作成した /nfsshare ディレクトリーにマウントされます。

    [root@z1 ~]# pcs resource create nfsshare Filesystem \
    device=/dev/my_vg/my_lv directory=/nfsshare \
    fstype=ext4 --group nfsgroup

    options=options パラメーターを使用すると、Filesystem リソースのリソース設定にマウントオプションを指定できます。すべての設定オプションを確認する場合は、pcs resource describe Filesystem コマンドを実行します。

  4. my_lvm リソースおよび nfsshare リソースが実行していることを確認します。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
    ...
  5. nfsgroup リソースグループに、nfs-daemon という名前の nfsserver リソースを作成します。

    注記

    nfsserver リソースを使用して、nfs_shared_infodir パラメーターを指定できます。これは、NFS サーバーが、NFS 関連のステートフル情報を保管するのに使用するディレクトリーです。

    この属性は、このエクスポートのコレクションで作成した Filesystem リソースのいずれかのサブディレクトリーに設定することが推奨されます。これにより、NFS サーバーは、このリソースグループを再配置する必要がある場合に別のノードで使用できるデバイスに、ステートフル情報を保存します。この例では、以下のように設定されています。

    • /nfsshare は、Filesystem リソースにより管理される shared-storage ディレクトリーです。
    • /nfsshare/exports/export1 および /nfsshare/exports/export2 は、エクスポートディレクトリーです。
    • /nfsshare/nfsinfo は、nfsserver リソースの共有情報ディレクトリーです。
    [root@z1 ~]# pcs resource create nfs-daemon nfsserver \
    nfs_shared_infodir=/nfsshare/nfsinfo nfs_no_notify=true \
    --group nfsgroup
    
    [root@z1 ~]# pcs status
    ...
  6. exportfs リソースを追加して、/nfsshare/exports ディレクトリーをエクスポートします。このリソースは、nfsgroup リソースグループに含まれます。これにより、NFSv4 クライアントの仮想ディレクトリーが構築されます。このエクスポートには、NFSv3 クライアントもアクセスできます。

    注記

    fsid=0 オプションは、NFSv4 クライアントに仮想ディレクトリーを作成する場合にのみ必要です。詳細は、「NFS サーバーで /etc/exports ファイルの fsid オプションを設定する方法」を参照してください。

    [root@z1 ~]# pcs resource create nfs-root exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash \
    directory=/nfsshare/exports \
    fsid=0 --group nfsgroup
    
    [root@z1 ~]# # pcs resource create nfs-export1 exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash directory=/nfsshare/exports/export1 \
    fsid=1 --group nfsgroup
    
    [root@z1 ~]# # pcs resource create nfs-export2 exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash directory=/nfsshare/exports/export2 \
    fsid=2 --group nfsgroup
  7. NFS 共有にアクセスするために、NFS クライアントが使用するフローティング IP アドレスリソースを追加します。このリソースは、リソースグループ nfsgroup に含まれます。このデプロイメント例では、192.168.122.200 をフローティング IP アドレスとして使用します。

    [root@z1 ~]# pcs resource create nfs_ip IPaddr2 \
    ip=192.168.122.200 cidr_netmask=24 --group nfsgroup
  8. NFS デプロイメント全体が初期化されたら、NFSv3 の再起動通知を送信する nfsnotify リソースを追加します。このリソースは、リソースグループ nfsgroup に含まれます。

    注記

    NFS の通知が適切に処理されるようにするには、フローティング IP アドレスにホスト名が関連付けられており、それが NFS サーバーと NFS クライアントで同じである必要があります。

    [root@z1 ~]# pcs resource create nfs-notify nfsnotify \
    source_host=192.168.122.200 --group nfsgroup
  9. リソースとリソースの制約を作成したら、クラスターのステータスを確認できます。すべてのリソースが同じノードで実行していることに注意してください。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z1.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z1.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z1.example.com
    ...

6.6. NFS リソース設定のテスト

以下の手順を使用すると、システムの設定を検証できます。NFSv3 または NFSv4 のいずれかで、エクスポートされたファイルシステムをマウントできるはずです。

6.6.1. NFS エクスポートのテスト

  1. デプロイメントと同じネットワークにあるクラスター外部のノードで NFS 共有をマウントして、NFS 共有が表示されることを確認します。この例では、192.168.122.0/24 ネットワークを使用します。

    # showmount -e 192.168.122.200
    Export list for 192.168.122.200:
    /nfsshare/exports/export1 192.168.122.0/255.255.255.0
    /nfsshare/exports         192.168.122.0/255.255.255.0
    /nfsshare/exports/export2 192.168.122.0/255.255.255.0
  2. NFSv4 で NFS 共有をマウントできることを確認する場合は、クライアントノードのディレクトリーに NFS 共有をマウントします。マウントしたら、エクスポートディレクトリーの内容が表示されることを確認します。テスト後に共有をアンマウントします。

    # mkdir nfsshare
    # mount -o "vers=4" 192.168.122.200:export1 nfsshare
    # ls nfsshare
    clientdatafile1
    # umount nfsshare
  3. NFSv3 で NFS 共有をマウントできることを確認します。マウントしたら、テストファイル clientdatafile1 が表示されていることを確認します。NFSv4 とは異なり、NFSv3 は仮想ファイルシステムを使用しないため、特定のエクスポートをマウントする必要があります。テスト後に共有をアンマウントします。

    # mkdir nfsshare
    # mount -o "vers=3" 192.168.122.200:/nfsshare/exports/export2 nfsshare
    # ls nfsshare
    clientdatafile2
    # umount nfsshare

6.6.2. フェイルオーバーのテスト

  1. クラスター外のノードで、NFS 共有をマウントし、「NFS 共有の設定」で作成した clientdatafile1 へのアクセスを確認します。

    # mkdir nfsshare
    # mount -o "vers=4" 192.168.122.200:export1 nfsshare
    # ls nfsshare
    clientdatafile1
  2. クラスター内で、nfsgroup を実行しているノードを確認します。この例では、nfsgroupz1.example.com で実行しています。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z1.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z1.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z1.example.com
    ...
  3. クラスター内のノードから、nfsgroup を実行しているノードをスタンバイモードにします。

    [root@z1 ~]# pcs node standby z1.example.com
  4. nfsgroup が、別のクラスターノードで正常に起動することを確認します。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z2.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z2.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z2.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z2.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z2.example.com
    ...
  5. NFS 共有をマウントしたクラスターの外部のノードから、この外部ノードが NFS マウント内のテストファイルに引き続きアクセスできることを確認します。

    # ls nfsshare
    clientdatafile1

    フェイルオーバー時に、クライアントに対するサービスが一時的に失われますが、クライアントはユーザーが介入しなくても回復します。デフォルトでは、NFSv4 を使用するクライアントの場合は、マウントの復旧に最大 90 秒かかることがあります。この 90 秒は、システムの起動時にサーバーが監視する NFSv4 ファイルのリースの猶予期間です。NFSv3 クライアントでは、数秒でマウントへのアクセスが回復します。

  6. クラスター内で、最初に nfsgroup を実行していたノードをスタンバイモードから削除します。

    注記

    ノードを スタンバイ モードから削除しても、リソースはそのノードにフェイルオーバーしません。これは、リソースの resource-stickiness 値により異なります。resource-stickiness メタ属性の詳細は、「現在のノードを優先するようにリソースを設定」を参照してください。

    [root@z1 ~]# pcs node unstandby z1.example.com

第7章 クラスター内の GFS2 ファイルシステム

本セクションでは、以下を説明します。

  • GFS2 ファイルシステムを含む Pacemaker クラスターを設定する手順
  • RHEL 8 クラスターに GFS2 ファイルシステムが含まれている RHEL 7 の論理ボリュームを移行する手順

7.1. クラスターに GFS2 ファイルシステムを設定

この手順は、GFS2 ファイルシステムを含む Pacemaker クラスターをセットアップするのに必要なステップの概要を説明します。この例では、3 つの論理ボリュームに 3 つの GFS2 ファイルシステムを作成します。

この手順の前提条件として、すべてのノードで、クラスターソフトウェアをインストールおよび起動し、基本的な 2 ノードクラスターを作成する必要があります。また、クラスターにフェンシングを設定することも必要です。Pacemaker クラスターの作成およびクラスターのフェンシングの設定情報は「Pacemaker を使用した Red Hat High Availability クラスターの作成」を参照してください。

  1. クラスターの両方のノードで、lvm2-lockd パッケージ、gfs2-utils パッケージ、および dlm パッケージをインストールします。lvm2-lockd パッケージは AppStream チャンネルで提供され、gfs2-utils パッケージおよび dlm パッケージは、Resilient Storage チャンネルで提供されます。

    # yum install lvm2-lockd gfs2-utils dlm
  2. グローバル Pacemaker パラメーター no_quorum_policyfreeze に設定します。

    注記

    デフォルトでは、no-quorum-policy の値は stop に設定され、定足数が失われると、残りのパーティションのリソースがすべて即座に停止されます。通常、このデフォルトは最も安全なオプションですが、ほとんどのリソースとは異なり、GFS2 ではクォーラムが機能する必要があります。GFS2 マウントを使用すると両方のアプリケーションでクォーラム (定足数) が失われ、GFS2 マウント自体が正しく停止できません。クォーラムなしでこれらのリソースの停止を試みると、クォーラムが失われるたびにクラスター全体がフェンシングされます。

    この状況に対処するには、GFS2 を使用している場合は no-quorum-policyフリーズ に設定します。つまり、クォーラムが失われると、クォーラムが回復するまで残りのパーティションで何も実行されません。

    # pcs property set no-quorum-policy=freeze
  3. dlm リソースをセットアップします。これは、クラスター内で GFS2 ファイルシステムを設定するために必要な依存関係です。この例では、dlm リソースを作成し、リソースグループ locking に追加します。

    [root@z1 ~]# pcs resource create dlm --group locking ocf:pacemaker:controld op monitor interval=30s on-fail=fence
  4. リソースグループがクラスターの両方のノードでアクティブになるように、locking リソースグループのクローンを作成します。

    [root@z1 ~]# pcs resource clone locking interleave=true
  5. lvmlockd リソースを、locking グループに追加します。

    [root@z1 ~]# pcs resource create lvmlockd --group locking ocf:heartbeat:lvmlockd op monitor interval=30s on-fail=fence
  6. クラスターのステータスを確認し、クラスターの両方のノードで locking リソースグループが起動していることを確認します。

    [root@z1 ~]# pcs status --full
    Cluster name: my_cluster
    [...]
    
    Online: [ z1.example.com (1) z2.example.com (2) ]
    
    Full list of resources:
    
     smoke-apc      (stonith:fence_apc):    Started z1.example.com
     Clone Set: locking-clone [locking]
         Resource Group: locking:0
             dlm    (ocf::pacemaker:controld):      Started z1.example.com
             lvmlockd       (ocf::heartbeat:lvmlockd):      Started z1.example.com
         Resource Group: locking:1
             dlm    (ocf::pacemaker:controld):      Started z2.example.com
             lvmlockd       (ocf::heartbeat:lvmlockd):      Started z2.example.com
         Started: [ z1.example.com z2.example.com ]
  7. lvmlockd デーモンが、クラスターの両方のノードで実行していることを確認します。

    [root@z1 ~]# ps -ef | grep lvmlockd
    root     12257     1  0 17:45 ?        00:00:00 lvmlockd -p /run/lvmlockd.pid -A 1 -g dlm
    [root@z2 ~]# ps -ef | grep lvmlockd
    root     12270     1  0 17:45 ?        00:00:00 lvmlockd -p /run/lvmlockd.pid -A 1 -g dlm
  8. クラスターの 1 つのノードで、2 つの共有ボリュームグループを作成します。一方のボリュームグループには GFS2 ファイルシステムが 2 つ含まれ、もう一方のボリュームグループには GFS2 ファイルシステムが 1 つ含まれます。

    以下のコマンドは、共有ボリュームグループ shared_vg1/dev/vdb に作成します。

    [root@z1 ~]# vgcreate --shared shared_vg1 /dev/vdb
      Physical volume "/dev/vdb" successfully created.
      Volume group "shared_vg1" successfully created
      VG shared_vg1 starting dlm lockspace
      Starting locking.  Waiting until locks are ready...

    以下のコマンドは、共有ボリュームグループ shared_vg2/dev/vdc に作成します。

    [root@z1 ~]# vgcreate --shared shared_vg2 /dev/vdc
      Physical volume "/dev/vdc" successfully created.
      Volume group "shared_vg2" successfully created
      VG shared_vg2 starting dlm lockspace
      Starting locking.  Waiting until locks are ready...
  9. クラスター内の 2 番目のノードで、共有ボリュームグループごとにロックマネージャーを起動します。

    [root@z2 ~]# vgchange --lock-start shared_vg1
      VG shared_vg1 starting dlm lockspace
      Starting locking.  Waiting until locks are ready...
    [root@z2 ~]# vgchange --lock-start shared_vg2
      VG shared_vg2 starting dlm lockspace
      Starting locking.  Waiting until locks are ready...
  10. クラスター内の 1 つのノードで、共有論理ボリュームを作成し、ボリュームを GFS2 ファイルシステムでフォーマットします。ファイルシステムをマウントするノードごとに、ジャーナルが 1 つ必要になります。クラスター内の各ノードに十分なジャーナルを作成してください。

    [root@z1 ~]# lvcreate --activate sy -L5G -n shared_lv1 shared_vg1
      Logical volume "shared_lv1" created.
    [root@z1 ~]# lvcreate --activate sy -L5G -n shared_lv2 shared_vg1
      Logical volume "shared_lv2" created.
    [root@z1 ~]# lvcreate --activate sy -L5G -n shared_lv1 shared_vg2
      Logical volume "shared_lv1" created.
    
    [root@z1 ~]# mkfs.gfs2 -j2 -p lock_dlm -t my_cluster:gfs2-demo1 /dev/shared_vg1/shared_lv1
    [root@z1 ~]# mkfs.gfs2 -j2 -p lock_dlm -t my_cluster:gfs2-demo2 /dev/shared_vg1/shared_lv2
    [root@z1 ~]# mkfs.gfs2 -j2 -p lock_dlm -t my_cluster:gfs2-demo3 /dev/shared_vg2/shared_lv1
  11. すべてのノードで論理ボリュームを自動的にアクティブにするために、各論理ボリュームに LVM が有効 なリソースを作成します。

    1. ボリュームグループ shared_vg1 の論理ボリューム shared_lv1 に、LVM が有効 なリソース sharedlv1 を作成します。このコマンドは、リソースを含むリソースグループ shared_vg1 も作成します。この例のリソースグループの名前は、論理ボリュームを含む共有ボリュームグループと同じになります。

      [root@z1 ~]# pcs resource create sharedlv1 --group shared_vg1 ocf:heartbeat:LVM-activate lvname=shared_lv1 vgname=shared_vg1 activation_mode=shared vg_access_mode=lvmlockd
    2. ボリュームグループ shared_vg1 の論理ボリューム shared_lv2 に、LVM が有効 なリソース sharedlv2 を作成します。このリソースは、リソースグループ shared_vg1 に含まれます。

      [root@z1 ~]# pcs resource create sharedlv2 --group shared_vg1 ocf:heartbeat:LVM-activate lvname=shared_lv2 vgname=shared_vg1 activation_mode=shared vg_access_mode=lvmlockd
    3. ボリュームグループ shared_vg2 の論理ボリューム shared_lv1 に、LVM が有効 なリソース sharedlv3 を作成します。このコマンドは、リソースを含むリソースグループ shared_vg2 も作成します。

      [root@z1 ~]# pcs resource create sharedlv3 --group shared_vg2 ocf:heartbeat:LVM-activate lvname=shared_lv1 vgname=shared_vg2 activation_mode=shared vg_access_mode=lvmlockd
  12. リソースグループのクローンを新たに 2 つ作成します。

    [root@z1 ~]# pcs resource clone shared_vg1 interleave=true
    [root@z1 ~]# pcs resource clone shared_vg2 interleave=true
  13. dlm リソースおよび lvmlockd リソースを含む locking リソースグループが最初に起動するように、順序の制約を設定します。

    [root@z1 ~]# pcs constraint order start locking-clone then shared_vg1-clone
    Adding locking-clone shared_vg1-clone (kind: Mandatory) (Options: first-action=start then-action=start)
    [root@z1 ~]# pcs constraint order start locking-clone then shared_vg2-clone
    Adding locking-clone shared_vg2-clone (kind: Mandatory) (Options: first-action=start then-action=start)
  14. コロケーション制約を設定して、vg1 および vg2 のリソースグループが locking リソースグループと同じノードで起動するようにします。

    [root@z1 ~]# pcs constraint colocation add shared_vg1-clone with locking-clone
    [root@z1 ~]# pcs constraint colocation add shared_vg2-clone with locking-clone
  15. クラスターの両ノードで、論理ボリュームがアクティブであることを確認します。数秒の遅延が生じる可能性があります。

    [root@z1 ~]# lvs
      LV         VG          Attr       LSize
      shared_lv1 shared_vg1  -wi-a----- 5.00g
      shared_lv2 shared_vg1  -wi-a----- 5.00g
      shared_lv1 shared_vg2  -wi-a----- 5.00g
    
    [root@z2 ~]# lvs
      LV         VG          Attr       LSize
      shared_lv1 shared_vg1  -wi-a----- 5.00g
      shared_lv2 shared_vg1  -wi-a----- 5.00g
      shared_lv1 shared_vg2  -wi-a----- 5.00g
  16. ファイルシステムリソースを作成し、各 GFS2 ファイルシステムをすべてのノードに自動的にマウントします。

    このファイルシステムは Pacemaker のクラスターリソースとして管理されるため、/etc/fstab ファイルには追加しないでください。マウントオプションは、options=options で、リソース設定に指定できます。すべての設定オプションを確認する場合は、pcs resource describe Filesystem コマンドを実行します。

    以下のコマンドは、ファイルシステムのリソースを作成します。これらのコマンドは各リソースを、そのファイルシステムの論理ボリュームを含むリソースグループに追加します。

    [root@z1 ~]# pcs resource create sharedfs1 --group shared_vg1 ocf:heartbeat:Filesystem device="/dev/shared_vg1/shared_lv1" directory="/mnt/gfs1" fstype="gfs2" options=noatime op monitor interval=10s on-fail=fence
    [root@z1 ~]# pcs resource create sharedfs2 --group shared_vg1 ocf:heartbeat:Filesystem device="/dev/shared_vg1/shared_lv2" directory="/mnt/gfs2" fstype="gfs2" options=noatime op monitor interval=10s on-fail=fence
    [root@z1 ~]# pcs resource create sharedfs3 --group shared_vg2 ocf:heartbeat:Filesystem device="/dev/shared_vg2/shared_lv1" directory="/mnt/gfs3" fstype="gfs2" options=noatime op monitor interval=10s on-fail=fence
  17. GFS2 ファイルシステムが、クラスターの両方のノードにマウントされていることを確認します。

    [root@z1 ~]# mount | grep gfs2
    /dev/mapper/shared_vg1-shared_lv1 on /mnt/gfs1 type gfs2 (rw,noatime,seclabel)
    /dev/mapper/shared_vg1-shared_lv2 on /mnt/gfs2 type gfs2 (rw,noatime,seclabel)
    /dev/mapper/shared_vg2-shared_lv1 on /mnt/gfs3 type gfs2 (rw,noatime,seclabel)
    
    [root@z2 ~]# mount | grep gfs2
    /dev/mapper/shared_vg1-shared_lv1 on /mnt/gfs1 type gfs2 (rw,noatime,seclabel)
    /dev/mapper/shared_vg1-shared_lv2 on /mnt/gfs2 type gfs2 (rw,noatime,seclabel)
    /dev/mapper/shared_vg2-shared_lv1 on /mnt/gfs3 type gfs2 (rw,noatime,seclabel)
  18. クラスターのステータスを確認します。

    [root@z1 ~]# pcs status --full
    Cluster name: my_cluster
    [...1
    
    Full list of resources:
    
     smoke-apc      (stonith:fence_apc):    Started z1.example.com
     Clone Set: locking-clone [locking]
         Resource Group: locking:0
             dlm    (ocf::pacemaker:controld):      Started z2.example.com
             lvmlockd       (ocf::heartbeat:lvmlockd):      Started z2.example.com
         Resource Group: locking:1
             dlm    (ocf::pacemaker:controld):      Started z1.example.com
             lvmlockd       (ocf::heartbeat:lvmlockd):      Started z1.example.com
         Started: [ z1.example.com z2.example.com ]
     Clone Set: shared_vg1-clone [shared_vg1]
         Resource Group: shared_vg1:0
             sharedlv1      (ocf::heartbeat:LVM-activate):  Started z2.example.com
             sharedlv2      (ocf::heartbeat:LVM-activate):  Started z2.example.com
             sharedfs1      (ocf::heartbeat:Filesystem):    Started z2.example.com
             sharedfs2      (ocf::heartbeat:Filesystem):    Started z2.example.com
         Resource Group: shared_vg1:1
             sharedlv1      (ocf::heartbeat:LVM-activate):  Started z1.example.com
             sharedlv2      (ocf::heartbeat:LVM-activate):  Started z1.example.com
             sharedfs1      (ocf::heartbeat:Filesystem):    Started z1.example.com
             sharedfs2      (ocf::heartbeat:Filesystem):    Started example.co
         Started: [ z1.example.com z2.example.com ]
     Clone Set: shared_vg2-clone [shared_vg2]
         Resource Group: shared_vg2:0
             sharedlv3      (ocf::heartbeat:LVM-activate):  Started z2.example.com
             sharedfs3      (ocf::heartbeat:Filesystem):    Started z2.example.com
         Resource Group: shared_vg2:1
             sharedlv3      (ocf::heartbeat:LVM-activate):  Started z1.example.com
             sharedfs3      (ocf::heartbeat:Filesystem):    Started z1.example.com
         Started: [ z1.example.com z2.example.com ]
    
    ...

7.2. RHEL7 から RHEL8 へ GFS2 ファイルシステムの移行

Red Hat Enterprise Linux 8 では、LVM は、clvmd の代わりに LVM ロックデーモン lvmlockd を使用して、アクティブ/アクティブのクラスターで共有ストレージデバイスを管理します。これにより、アクティブ/アクティブのクラスターに共有論理ボリュームとして使用する必要がある論理ボリュームを設定する必要があります。また、これにより、LVM が有効 なリソースを使用して LVM ボリュームを管理し、lvmlockd リソースエージェントを使用して lvmlockd デーモンを管理する必要があります。共有論理ボリュームを使用して、GFS2 ファイルシステムを含む Pacemaker クラスターを設定する手順は「クラスターでの GFS2 ファイルシステムの設定」を参照してください。

GFS2 ファイルシステムを含む RHEL8 クラスターを設定する際に、既存の Red Hat Enterprise Linux 7 論理ボリュームを使用する場合は、RHEL8 クラスターから以下の手順を実行します。この例では、クラスター化された RHEL 7 論理ボリュームが、ボリュームグループ upgrade_gfs_vg に含まれます。

注記

既存のファイルシステムを有効にするために、RHEL8 クラスターの名前は、GFS2 ファイルシステムに含まれる RHEL7 クラスターと同じになります。

  1. GFS2 ファイルシステムを含む論理ボリュームが現在非アクティブであることを確認してください。すべてのノードがボリュームグループを使用して停止した場合にのみ、この手順は安全です。
  2. クラスター内の 1 つのノードから、強制的にボリュームグループをローカルに変更します。

    [root@rhel8-01 ~]# vgchange --lock-type none --lock-opt force upgrade_gfs_vg
    Forcibly change VG lock type to none? [y/n]: y
      Volume group "upgrade_gfs_vg" successfully changed
  3. クラスター内の 1 つのノードから、ローカルボリュームグループを共有ボリュームグループに変更します。

    [root@rhel8-01 ~]# vgchange --lock-type dlm upgrade_gfs_vg
       Volume group "upgrade_gfs_vg" successfully changed
  4. クラスター内の各ノードで、ボリュームグループのロックを開始します。

    [root@rhel8-01 ~]# vgchange --lock-start upgrade_gfs_vg
      VG upgrade_gfs_vg starting dlm lockspace
      Starting locking.  Waiting until locks are ready...
    [root@rhel8-02 ~]# vgchange --lock-start upgrade_gfs_vg
      VG upgrade_gfs_vg starting dlm lockspace
      Starting locking.  Waiting until locks are ready...

この手順を実行すると、各論理ボリュームに、LVM が有効 なリソースを作成できます。

第8章 pcsd Web UI の使用

pcsd Web UI は、Pacemaker クラスターおよび Corosync クラスターを作成および設定するグラフィカルユーザーインターフェースです。

8.1. クラスターソフトウェアのインストール

以下の手順では、クラスターソフトウェアをインストールし、システムでクラスターの作成を構成するように設定します。

  1. クラスターの各ノードに、Red Hat High Availability Add-On ソフトウェアパッケージと、使用可能なすべてのフェンスエージェントを、High Availability チャンネルからインストールします。

    # yum install pcs pacemaker fence-agents-all

    または、次のコマンドを実行して、Red Hat High Availability Add-On ソフトウェアパッケージと、必要なフェンスエージェントのみをインストールすることもできます。

    # yum install pcs pacemaker fence-agents-model

    次のコマンドは、利用できるフェンスエージェントの一覧を表示します。

    # rpm -q -a | grep fence
    fence-agents-rhevm-4.0.2-3.el7.x86_64
    fence-agents-ilo-mp-4.0.2-3.el7.x86_64
    fence-agents-ipmilan-4.0.2-3.el7.x86_64
    ...
    警告

    Red Hat High Availability Add-On パッケージをインストールしたら、自動的に何もインストールされないように、ソフトウェア更新設定を行う必要があります。実行中のクラスターにインストールすると、予期しない動作が発生する可能性があります。詳細は「RHEL 高可用性またはレジリエントストレージクラスターにソフトウェアアップデートを適用するのに推奨されるプラクティス」を参照してください。

  2. firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

    注記

    firewalld デーモンがシステムにインストールされているかどうかを確認する場合は、rpm -q firewalld コマンドを実行します。firewalld デーモンがインストールされている場合は、firewall-cmd --state コマンドで、実行しているかどうかを確認できます。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --add-service=high-availability
    注記

    クラスターコンポーネントの理想的なファイアウォール設定は、ローカル環境によって異なります。ここでは、ノードに複数のネットワークインターフェースがあるかどうか、またはオフホストのファイアウォールがあるかどうかを検討しないといけない場合があります。この例では、Pacemaker クラスターで通常必要となるポートを開きますが、ローカル条件に合わせて変更する必要があります。「High Availability Add-On のポートの有効化」では、Red Hat High Availability Add-On で有効にするポートと、各ポートの使用目的を説明します。

  3. pcs を使用してクラスターの設定やノード間の通信を行うため、pcs の管理アカウントとなるユーザー ID hacluster のパスワードを各ノードに設定する必要があります。hacluster ユーザーのパスワードは、各ノードで同じにすることが推奨されます。

    # passwd hacluster
    Changing password for user hacluster.
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.
  4. クラスターを設定する前に、各ノードで、システムの起動時に pcsd デーモンを起動できるように、デーモンを起動して有効にしておく必要があります。このデーモンは、pcs コマンドで動作し、クラスターのノード全体で設定を管理します。

    クラスターの各ノードで次のコマンドを実行して、システムの起動時に pcsd サービスが起動し、pcsd が有効になるように設定します。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service

8.2. pcsd Web UI の設定

Pacemaker 設定ツールをインストールし、システムをクラスター設定用に設定したら、以下の手順に従ってシステムを設定し、pcsd Web UI を使用してクラスターを設定します。

  1. いずれかのシステムで以下の URL をブラウザーで開き、クラスターのノードのいずれかを指定します (https プロトコルを使用することに注意してください)。これにより、pcsd Web UI のログイン画面が表示されます。

    https://nodename:2224
  2. ユーザー hacluster としてログインします。これにより、図8.1「クラスターの管理ページ」に示されるように、クラスターの管理 ページが表示されます。

    図8.1 クラスターの管理ページ

    クラスターの管理ページ

8.3. pcsd Web UI でクラスターの作成

クラスターの管理ページから、新規クラスターの作成、既存のクラスターの Web UI への追加、または Web UI からのクラスターの削除を行うことができます。

  • クラスターを作成するには、新規作成 をクリックします。作成するクラスターの名前と、クラスターを構成するノードの名前を入力します。クラスター内の各ノードでユーザー hacluster を認証していない場合は、クラスターノードの認証が要求されます。
  • クラスターの作成時に、この画面で Go to advanced settings をクリックして、高度なクラスターオプションを設定できます。設定できる高度なクラスター設定は、「pcsd Web UI で高度なクラスター設定オプションの設定」を参照してください。
  • 既存のクラスターを Web UI に追加するには、既存の追加 をクリックし、Web UI で管理するクラスターのノードのホスト名または IP アドレスを入力します。

クラスターを作成または追加すると、クラスターの管理ページにクラスター名が表示されます。クラスターを選択すると、クラスターに関する情報が表示されます。

注記

pcsd Web UI を使用してクラスターを設定する場合、多くのオプションを説明するテキストでマウスを移動すると、そのオプションの詳細な説明が ツールチップ として表示されます。

8.3.1. pcsd Web UI で高度なクラスター設定オプションの設定

クラスターの作成時に、クラスターの作成画面の 高度な設定へ進む をクリックすると、追加のクラスターオプションを設定できます。これにより、以下のクラスターコンポーネントで可能な設定を変更できます。

  • トランスポート設定 - クラスター通信に使用されるトランスポートメカニズムの値
  • クォーラム設定 - votequorum サービスのクォーラムオプションの値
  • Totem の設定 - Corosync で使用される Totem プロトコルの値

上記のオプションを選択すると、構成可能な設定が表示されます。各設定の詳細は、そのオプションにマウスポインターを合わせると表示されます。

8.3.2. クラスター管理パーミッションの設定

ユーザーに付与できるクラスターパーミッションには、以下の 2 つのセットがあります。

  • Web UI を使用してクラスターを管理するためのパーミッション。ネットワーク経由でノードに接続する pcs コマンドを実行するパーミッションも付与されます。本セクションでは、Web UI でこのパーミッションを設定する方法を説明します。
  • ACL を使用し、クラスター設定への読み取り専用アクセスまたは読み書きアクセスをローカルユーザーに許可するパーミッション。Web UI で ACL を設定する方法は、「pcsd Web UI でクラスターコンポーネントの設定」を参照してください。

グループ haclient にユーザーを追加することで、ユーザー hacluster 以外の特定のユーザーにパーミッションを付与し、Web UI でクラスターを管理し、ネットワーク経由でノードに接続する pcs コマンドを実行できます。次に、クラスターの管理ページのパーミッションタブをクリックし、表示された画面でパーミッションを設定することで、グループ haclient の個別のメンバーにパーミッションセットを設定できます。この画面では、グループのパーミッションを設定することもできます。

以下のパーミッションを付与できます。

  • 読み取りパーミッション (クラスター設定の表示)
  • 書き込みパーミッション (パーミッションおよび ACL を除くクラスター設定の変更)
  • 付与パーミッション (クラスターパーミッションおよび ACL の変更)
  • フルパーミッション (ノードの追加および削除、鍵および証明書へのアクセスを含むクラスターへの無制限アクセス)

8.4. pcsd Web UI でクラスターコンポーネントの設定

クラスターのコンポーネントおよび属性を設定するには、クラスターの管理 画面に表示されるクラスターの名前をクリックします。これにより、「pcsd Web UI でクラスターノードの設定」に示されるように、ノード ページが表示されます。このページには、ページの上部に、以下のエントリーを含むメニューが表示されます。

8.4.1. pcsd Web UI でクラスターノードの設定

クラスター管理ページの上部にあるメニューから ノード オプションを選択すると、現在設定されているノードと、現在選択されているノードの状態 (ノードで実行しているリソースや、リソースの場所設定など) が表示されます。これは、クラスターの管理 画面でクラスターを選択すると表示されるデフォルトページです。

このページを形成すると、ノードを追加または削除できます。また、ノードをスタンバイモードまたはメンテナンスモードにしたり、開始、停止、再起動を実行することもできます。スタンドバイモードの詳細は「ノードをスタンバイモードにする」を参照してください。メンテナンスモードの詳細は「クラスターをメンテナンスモードに」を参照してください。

また、フェンシングの設定 を選択することで、説明されているように、このページで直接フェンスデバイスを設定することもできます。フェンスデバイスの設定は、「pcsd Web UI でフェンスデバイスの設定」で説明します。

8.4.2. pcsd Web UI でクラスターリソースの設定

クラスター管理ページの上部にあるメニューから リソース オプションを選択すると、クラスターに現在設定されているリソースが、リソースグループに整理されて表示されます。グループまたはリソースを選択すると、そのグループまたはリソースの属性が表示されます。

この画面では、リソースの追加または削除、既存リソースの設定の編集、およびリソースグループの作成を行うことができます。

新規リソースをクラスターに追加するには、以下を行います。

  • 追加 をクリックします。これにより、リソースの追加 画面が表示されます。
  • ドロップダウンの タイプ メニューからリソースタイプを選択すると、そのリソースに指定する必要がある引数がメニューに表示されます。
  • 任意の引数 をクリックすると、定義するリソースに指定できる任意の引数を表示できます。
  • 作成するリソースのパラメーターを入力したら、リソースの作成 をクリックします。

リソースの引数を設定する際に、引数の簡単な説明がメニューに表示されます。カーソルをフィールドに移動すると、その引数のヘルプが表示されます。

リソースをクローンリソースとして定義することも、昇格可能なクローンリソースとしても定義できます。このリソースタイプの詳細は、「複数のノードでアクティブなクラスターリソース (クローンリソース) の作成」を参照してください。

少なくとも 1 つのリソースを作成したら、リソースグループを作成できます。リソースグループの一般情報は「リソースグループの設定」を参照してください。

リソースグループを作成するには、以下を行います。

  • リソース 画面からグループの一部であるリソースを選択し、グループの作成 をクリックします。これにより、グループの作成 画面が表示されます。
  • グループの作成 画面から、ドラッグアンドドロップを使用してリソースのリストを移動することで、リソースグループ内のリソースの順番を再編成できます。
  • グループ名を入力し、グループの作成 をクリックします。これにより、グループ名とそのグループ内のリソースが表示される リソース 画面に戻ります。

リソースグループを作成したら、追加のリソースを作成または変更する際に、グループ名をリソースパラメーターとして指定できます。

8.4.3. pcsd Web UI でフェンスデバイスの設定

クラスター管理ページの上部にあるメニューから フェンスデバイス オプションを選択すると フェンスデバイス 画面が表示され、現在設定されているフェンスデバイスが表示されます。

新しいフェンスデバイスをクラスターに追加するには、以下を行います。

  • 追加 をクリックします。フェンスデバイスの追加 画面が表示されます。
  • ドロップダウンメニューの タイプ からフェンスデバイスのタイプを選択すると、そのフェンスデバイスに指定する必要がある引数がメニューに表示されます。
  • 任意の引数 をクリックして、定義するフェンスデバイスに指定できる追加の引数を表示できます。
  • 新しいフェンスデバイスのパラメーターを入力したら、フェンスインスタンスの作成 をクリックします。

SBD フェンスデバイスを設定するには、フェンスデバイス 画面の SBD をクリックします。これにより、クラスターで SBD を有効または無効にできる画面が呼び出されます。

フェンスデバイスの詳細は「Red Hat High Availability クラスターでのフェンシングの設定」を参照してください。

8.4.4. pcsd Web UI で ACL の設定

クラスター管理ページの上部にあるメニューから ACL オプションを選択すると、ローカルユーザーのパーミッションを設定できる画面が表示され、アクセス制御リスト (ACL) を使用して、クラスター設定への読み取り専用アクセスまたは読み書きアクセスが可能になります。

ACL パーミッションを割り当てるには、ロールを作成し、そのロールのアクセスパーミッションを定義します。各ロールには、XPath クエリーまたは特定要素の ID のいずれかにパーミッション (読み取り/書き込み/拒否) をいくつでも適用できます。ロールを定義したら、既存のユーザーまたはグループに割り当てることができます。

ACL を使用してパーミッションを割り当てる方法は、「ACL を使用したローカルパーミッションの設定」を参照してください。

8.4.5. pcsd Web UI でクラスタープロパティの設定

クラスター管理ページの上部にあるメニューから クラスターのプロパティー オプションを選択するとクラスタープロパティが表示され、そのプロパティーの値をデフォルト値から変更できます。Pacemaker クラスターのプロパティは、「Pacemaker クラスターのプロパティー」を参照してください。

8.5. 高可用性の pcsd Web UI の設定

pcsd Web UI を使用すると、クラスターのノードのいずれかに接続して、クラスター管理ページを表示できます。接続先のノードがダウンするか、使用できなくなった場合は、クラスターの別のノードを指定する URL でブラウザーを開くと、クラスターに再接続できます。

ただし、高可用性に pcsd Web UI 自体を設定することもできます。この場合は、新しい URL を入力しなくても、引き続きクラスターを管理できます。

高可用性に pcsd Web UI を設定するには、以下の手順を実行します。

  1. /etc/sysconfig/pcsd 設定ファイルで PCSD_SSL_CERT_SYNC_ENABLEDtrue に設定して、pcsd 証明書がクラスターのノード間で同期されるようにします。証明書の同期を有効にすると、pcsd がクラスター設定およびノードの追加コマンドの証明書を同期します。RHEL 8 では、PCSD_SSL_CERT_SYNC_ENABLED がデフォルトで false に設定されています。
  2. pcsd Web UI への接続に使用するフローティング IP アドレスである IPaddr2 クラスターリソースを作成します。物理ノードに関連付けられている IP アドレスは使用できません。IPaddr2 リソースの NIC デバイスを指定していない場合は、そのノードに静的に割り当てられている IP アドレスの 1 つと同じネットワークにフローティング IP が存在していないと、フローティング IP アドレスを割り当てる NIC デバイスが適切に検出されません。
  3. pcsd を使用するためにカスタムの SSL 証明書を作成し、pcsd Web UI への接続に使用するノードのアドレスに対して有効であることを確認します。

    1. カスタムの SSL 証明書を作成するには、ワイルドカード証明書を使用するか、SAN (Subject Alternative Name: サブジェクトの別名) 証明書の延長を使用できます。Red Hat Certificate System の詳細は、『Red Hat Certificate System Administration Guide』を参照してください。
    2. pcs pcsd certkey コマンドを使用して pcsd のカスタム証明書をインストールします。
    3. pcs pcsd sync-certificates コマンドを使用して、pcsd 証明書を、クラスター内のすべてのノードに同期させます。
  4. クラスターリソースとして設定したフローティング IP アドレスを使用して、pcsd Web UI に接続します。
注記

高可用性に pcsd Web UI を設定している場合でも、ユーザーが接続しているノードがダウンすると、再びログインするように求められます。

第9章 Red Hat High Availability クラスターでのフェンシングの設定

応答しないノードがデータへのアクセスを続けている可能性があります。データが安全であることを確認する場合は、STONITH を使用してノードをフェンシングすることが唯一の方法になります。STONITH は「Shoot The Other Node In The Head」の頭字語で、不安定なノードや同時アクセスによるデータの破損を防ぐことができます。STONITH を使用すると、別のノードからデータをアクセスする前に、そのノードが完全にオフラインであることを確認できます。

STONITH はクラスター化したサービスを停止できない場合にも役に立ちます。この場合は、クラスターが STONITH を使用してノード全体を強制的にオフラインにし、その後サービスを別の場所で開始すると安全です。

フェンシングの概要と、Red Hat High Availability クラスターにおけるフェンシングの重要性は「RHEL 高可用性クラスターでフェンシングが重要なのはなぜですか?」を参照してください。

クラスターのノードにフェンスデバイスを設定して、Pacemaker クラスターに STONITH を実装します。

9.1. 利用可能なフェンスエージェントと、そのオプションの表示

以下のコマンドは、利用可能な STONITH エージェントを一覧表示します。フィルターを指定すると、フィルターに一致する STONITH エージェントのみが表示されます。

pcs stonith list [filter]

指定した STONITH エージェントのオプションを表示するには、次のコマンドを使用します。

pcs stonith describe stonith_agent

次のコマンドでは Telnet または SSH 経由の APC 用フェンスエージェントのオプションを表示します。

# pcs stonith describe fence_apc
Stonith options for: fence_apc
  ipaddr (required): IP Address or Hostname
  login (required): Login Name
  passwd: Login password or passphrase
  passwd_script: Script to retrieve password
  cmd_prompt: Force command prompt
  secure: SSH connection
  port (required): Physical plug number or name of virtual machine
  identity_file: Identity file for ssh
  switch: Physical switch number on device
  inet4_only: Forces agent to use IPv4 addresses only
  inet6_only: Forces agent to use IPv6 addresses only
  ipport: TCP port to use for connection with device
  action (required): Fencing Action
  verbose: Verbose mode
  debug: Write debug information to given file
  version: Display version information and exit
  help: Display help and exit
  separator: Separator for CSV created by operation list
  power_timeout: Test X seconds for status change after ON/OFF
  shell_timeout: Wait X seconds for cmd prompt after issuing command
  login_timeout: Wait X seconds for cmd prompt after login
  power_wait: Wait X seconds after issuing ON/OFF
  delay: Wait X seconds before fencing is started
  retry_on: Count of attempts to retry power on
警告

method オプションを提供するフェンスエージェントでは cycle がサポートされず、データの破損が生じる可能性があるため、この値は指定できません。

9.2. フェンスデバイスの作成

stonith デバイスを作成するコマンドの形式は、以下のとおりです。利用可能な stonith 作成オプションの一覧は、pcs stonith -h の出力を参照してください。

pcs stonith create stonith_id stonith_device_type [stonith_device_options] [op  operation_action operation_options]

以下のコマンドは、1 つのノードに対して、1 つのフェンスデバイスを作成します。

# pcs stonith create MyStonith fence_virt pcmk_host_list=f1 op monitor interval=30s

1 つのノードのみをフェンスできるフェンスデバイスや、複数のノードをフェンスできるデバイスもあります。フェンスデバイスの作成時に指定するパラメーターは、フェンスデバイスが対応しているか、必要としているかにより異なります。

  • フェンスデバイスの中には、フェンスできるノードを自動的に判断できるものがあります。
  • フェンスデバイスの作成時に pcmk_host_list パラメーターを使用すると、フェンスデバイスで制御されるすべてのマシンを指定できます。
  • フェンスデバイスによっては、フェンスデバイスが理解する仕様へのホスト名のマッピングが必要となるものがあります。フェンスデバイスの作成時に、pcmk_host_map パラメーターを使用して、ホスト名をマッピングできます。

pcmk_host_list パラメーターおよび pcmk_host_map パラメーターの詳細は、「フェンスデバイスの一般的なプロパティー」を参照してください。

フェンスデバイスを設定したら、デバイスをテストして正しく機能していることを確認してください。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

9.3. フェンスデバイスの一般的なプロパティー

クラスターノードは、フェンスリソースが開始しているかどうかに関わらず、フェンスデバイスでその他のクラスターノードをフェンスできます。以下の例外を除き、リソースが開始しているかどうかは、デバイスの定期的なモニターのみを制御するものとなり、使用可能かどうかは制御しません。

  • フェンスデバイスは、pcs stonith disable stonith_id コマンドを実行して無効にできます。これにより、ノードがそのデバイスを使用できないように設定できます。
  • 特定のノードがフェンスデバイスを使用できないようにするには、pcs constraint location …​ avoids コマンドで、フェンスリソースの場所制約を設定できます。
  • stonith-enabled=false を設定すると、フェンシングがすべて無効になります。ただし、実稼働環境でフェンシングを無効にすることは適していないため、フェンシングが無効になっている場合は、Red Hat ではクラスターがサポートされないことに注意してください。

表9.1「フェンスデバイスの一般的なプロパティー」は、フェンスデバイスに設定できる一般的なプロパティーを説明します。

表9.1 フェンスデバイスの一般的なプロパティー

フィールドタイプデフォルト説明

pcmk_host_map

文字列

 

ホスト名を、ホスト名に対応していないデバイスのポート番号へマッピングします。たとえば、node1:1;node2:2,3 の場合は、node1 にはポート 1 を使用し、node2 にはポート 2 と 3 を使用するようにクラスターに指示します。

pcmk_host_list

文字列

 

このデバイスで制御するマシンの一覧です (pcmk_host_check=static-list 以外は任意)。

pcmk_host_check

文字列

* pcmk_host_list または pcmk_host_map が設定されている場合は static-list

* それが設定されておらず、フェンスデバイスが list アクションに対応する場合は dynamic-list になります。

* それ以外で、フェンスデバイスが status アクションに対応している場合は status になります。

* それ以外は、none になります。

デバイスで制御するマシンを指定します。使用できる値は、dynamic-list (デバイスへの問い合わせ)、static-list (pcmk_host_list 属性の確認)、なし (すべてのデバイスで全マシンのフェンスが可能と見なされる) です。

9.4. 高度なフェンス設定オプション

フェンスデバイスに設定できるその他のプロパティーは表9.2「フェンスデバイスの高度なプロパティー」にまとめられています。これらのオプションは高度な設定を行う場合にのみ使用されます。

表9.2 フェンスデバイスの高度なプロパティー

フィールドタイプデフォルト説明

pcmk_host_argument

文字列

port

port の代替パラメーターです。デバイスによっては、標準の port パラメーターに対応していない場合や、そのデバイス固有のパラメーターも提供している場合があります。このパラメーターを使用して、デバイス固有の代替パラメーターを指定します。これは、フェンシングするマシンを示します。クラスターが追加パラメーターを提供しないようにする場合は、none 値を使用します。

pcmk_reboot_action

文字列

reboot

reboot の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このパラメーターを使用して、再起動を実行するデバイス固有の代替コマンドを指定します。

pcmk_reboot_timeout

時間

60s

stonith-timeout の代替コマンドで、再起動にタイムアウトを指定します。再起動が完了するまでに通常より長い時間を要するデバイスもあれば、通常より短い時間で完了するデバイスもあります。このパラメーターを使用して、再起動にデバイス固有のタイムアウトを指定します。

pcmk_reboot_retries

整数

2

タイムアウト期間内に、reboot コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による再起動の動作の再試行回数を変更する場合に使用します。

pcmk_off_action

文字列

off

off の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、オフ操作を実行するデバイス固有のコマンドを指定します。

pcmk_off_timeout

時間

60s

stonith-timeout の代替コマンドで、オフ操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、オフ操作にデバイス固有のタイムアウトを指定します。

pcmk_off_retries

整数

2

タイムアウト期間内に、off コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker によるオフ動作の再試行回数を変更する場合に使用します。

pcmk_list_action

文字列

list

list の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、list 操作を実行するデバイス固有のコマンドを指定します。

pcmk_list_timeout

時間

60s

list 操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、list 操作にデバイス固有のタイムアウトを指定します。

pcmk_list_retries

整数

2

タイムアウト期間内に、list コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による list 動作の再試行回数を変更する場合に使用します。

pcmk_monitor_action

文字列

monitor

monitor の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、監視操作を実行するデバイス固有のコマンドを指定します。

pcmk_monitor_timeout

時間

60s

stonith-timeout の代替コマンドで、監視にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、監視操作にデバイス固有のタイムアウトを指定します。

pcmk_monitor_retries

整数

2

タイムアウト期間内に、monitor コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による監視操作の再試行回数を変更する場合に使用します。

pcmk_status_action

文字列

status

status の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、status 操作を実行するデバイス固有のコマンドを指定します。

pcmk_status_timeout

時間

60s

stonith-timeout の代替コマンドで、status 操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、status 操作にデバイス固有のタイムアウトを指定します。

pcmk_status_retries

整数

2

タイムアウト期間内に、status コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が失敗する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による status 動作の再試行回数を変更する場合に使用します。

pcmk_delay_base

時間

0s

stonith 操作のベース遅延を有効にし、ベース遅延の値を指定します。ノードの数が偶数になるクラスターでは、遅延を設定すると、均等の分割時に同時にノードが互いにフェンシングするのを回避できます。ランダムな遅延は、すべてのノードに同じフェンスデバイスが使用されている場合に役に立つことがあります。また、静的遅延を変更すると、各ノードで異なるデバイスが使用される場合に各フェンシングデバイスで役に立つことがあります。全体の遅延は、合計が最大遅延を下回るように、ランダムな遅延値に静的遅延を加算します。pcmk_delay_base を設定し、pcmk_delay_max を設定しない場合は、遅延にランダムなコンポーネントはなく、pcmk_delay_base の値となります。

各フェンスエージェントには「delay」パラメーターが実装されています。これは、pcmk_delay_* プロパティーで設定された遅延の影響は受けません。この遅延の両方が構成されている場合は、その両方が一緒に追加されるため、通常は併用されません。

pcmk_delay_max

時間

0s

stonith 動作のランダムな遅延を有効にし、ランダムな遅延の最大値を指定します。ノードの数が偶数になるクラスターでは、遅延を設定すると、均等の分割時に同時にノードが互いにフェンシングするのを回避できます。ランダムな遅延は、すべてのノードに同じフェンスデバイスが使用されている場合に役に立つことがあります。また、静的遅延を変更すると、各ノードで異なるデバイスが使用される場合に各フェンシングデバイスで役に立つことがあります。全体の遅延は、合計が最大遅延を下回るように、このランダムな遅延値に静的遅延を加算します。pcmk_delay_max を設定し、pcmk_delay_base を設定しない場合は、静的なコンポーネントが遅延に含まれません。

各フェンスエージェントには「delay」パラメーターが実装されています。これは、pcmk_delay_* プロパティーで設定された遅延の影響は受けません。この遅延の両方が構成されている場合は、その両方が一緒に追加されるため、通常は併用されません。

pcmk_action_limit

整数

1

このデバイスで並行して実行できる操作の上限です。最初に、クラスタープロパティーの concurrent-fencing=true を設定する必要があります (これは、RHEL 8.1 以降のデフォルト値です)。値を -1 にすると無制限になります。

pcmk_on_action

文字列

on

高度な使用のみ - on の代替コマンドです。標準的なコマンドに対応していないデバイスや、別のコマンドを提供しているデバイスがあります。このような場合は、このパラメーターを使用して、on 操作を実行するデバイス固有のコマンドを指定します。

pcmk_on_timeout

時間

60s

高度な使用のみ - stonith-timeout の代替コマンドで、on 操作にタイムアウトを指定します。デバイスによって、この操作が完了するのにかかる時間が、通常と大きく異なる場合があります。このパラメーターを使用して、on 操作にデバイス固有のタイムアウトを指定します。

pcmk_on_retries

整数

2

高度な使用のみ - タイムアウト期間内に、on コマンドを再試行する回数の上限です。複数の接続に対応していないデバイスもあります。デバイスが別のタスクでビジー状態になると操作が 失敗 する場合があるため、タイムアウトに達していなければ、Pacemaker が操作を自動的に再試行します。Pacemaker による on 動作の再試行回数を変更する場合に使用します。

個々のフェンスデバイスに設定できるプロパティーのほかにも、表9.3「フェンス動作を決定するクラスタープロパティ」で説明しているように、フェンス動作を判断するクラスタープロパティも設定できます。

表9.3 フェンス動作を決定するクラスタープロパティ

オプションデフォルト説明

stonith-enabled

true

障害が発生したノードと、停止できないリソースが含まれるノードをフェンスする必要があることを示します。データを保護するには、true に設定する必要があります。

true または未設定の場合は、STONITH リソースが設定されていない限り、クラスターによりリソースの起動が拒否されます。

Red Hat は、この値が true に設定されたクラスターのみをサポートします。

stonith-action

reboot

STONITH デバイスに送るアクション。使用できる値は rebootoff です。poweroff 値も使用できますが、レガシーデバイスでのみ使用されます。

stonith-timeout

60s

STONITH アクションが完了するのを待つ時間。

stonith-max-attempts

10

クラスターがすぐに再起動できなくなるまで、ターゲットでフェンシングが失敗する回数。

stonith-watchdog-timeout

 

ノードがハードウェアウォッチドッグによって強制終了すまで待機する最大時間。この値は、ハードウェアウォッチドッグのタイムアウト値の倍に設定することが推奨されます。このオプションは、ウォッチドッグベースの SBD がフェンシングに使用される場合にのみ必要です。

concurrent-fencing

true (RHEL 8.1 以降)

フェンシング操作を並行して実行できるようにします。

fence-reaction

stop

(Red Hat Enterprise Linux 8.2 以降) 独自のフェンシングの通知を受信した場合は、クラスターノードがどのように反応するかを決定します。クラスターノードは、フェンシングの設定が間違っている場合に独自のフェンシングの通知を受信するか、またはファブリックフェンシングがクラスター通信を遮断しない状態である可能性があります。許可される値は、Pacemaker をすぐに停止し、停止したままにする stop と、ローカルノードを直ちに再起動して失敗した場合に停止する panic です。

このプロパティーのデフォルト値は stop ですが、この値に最も安全な選択肢は panic であり、ローカルノードを直ちに再起動しようとします。停止動作を希望する場合は、おそらくファブリックフェンシングと併用する場合は、明示的に指定することが推奨されます。

クラスターのプロパティの設定は、「クラスタープロパティーの設定および削除」を参照してください。

9.5. フェンスデバイスのテスト

フェンシングは、Red Hat Cluster インフラストラクチャーの基本的な部分を構成しているため、フェンシングが適切に機能していることを確認またはテストすることは重要です。

以下の手順で、フェンスデバイスをテストします。

  1. デバイスへの接続に使用する ssh、telnet、HTTP などのリモートプロトコルを使用して、手動でログインしてフェンスデバイスをテストしたり、出力される内容を確認します。たとえば、IPMI 対応デバイスのフェンシングを設定する場合は、ipmitool を使用してリモートでのログインを試行します。手動でログインする際に使用するオプションに注意してください。これらのオプションは、フェンスエージェントを使用する際に必要になる場合があります。

    フェンスデバイスにログインできない場合は、そのデバイスが ping 可能であること、ファイアウォール設定がフェンスデバイスへのアクセスを妨げていないこと、フェンスデバイスでリモートアクセスが有効になっていること、認証情報が正しいことなどを確認します。

  2. フェンスエージェントスクリプトを使用して、フェンスエージェントを手動で実行します。フェンスエージェントを実行するのに、クラスターサービスが実行している必要はないため、デバイスをクラスターに設定する前にこのステップを完了できます。これにより、先に進む前に、フェンスデバイスが適切に応答することを確認できます。

    注記

    本セクションの例では、iLO デバイスの fence_ipmilan フェンスエージェントスクリプトを使用します。実際に使用するフェンスエージェントと、そのエージェントを呼び出すコマンドは、お使いのサーバーハードウェアによって異なります。指定するオプションを確認するには、フェンスエージェントの man ページを参照してください。通常は、フェンスデバイスのログイン、パスワードなどの情報と、その他のフェンスデバイスに関する情報を把握しておく必要があります。

    以下の例は、-o status パラメーターを指定して fence_ipmilan フェンスエージェントスクリプトを実行する場合に使用する形式になります。このコマンドを実行すると、フェンシングは実行せずに、別のノードのフェンスデバイスインターフェースのステータスを確認します。ノードの再起動を試行する前にデバイスをテストして、動作させることができます。このコマンドを実行する際に、iLO デバイスの電源をオン/オフにするパーミッションを持つ iLO ユーザーの名前およびパスワードを指定します。

    # fence_ipmilan -a ipaddress -l username -p password -o status

    以下の例は、-o reboot パラメーターを指定して fence_ipmilan フェンスエージェントスクリプトを実行するのに使用する形式になります。このコマンドを 1 つのノードで実行すると、この iLO デバイスで管理するノードが再起動します。

    # fence_ipmilan -a ipaddress -l username -p password -o reboot

    フェンスエージェントがステータス、オフ、オン、または再起動の動作を適切に実行しない場合は、ハードウェア、フェンスデバイスの設定、およびコマンドの構文を確認する必要があります。さらに、デバッグ出力を有効にした状態で、フェンスエージェントスクリプトを実行できます。デバッグ出力は、一部のフェンスエージェントで、フェンスデバイスにログインする際に、フェンスエージェントスクリプトに問題が発生しているイベントシーケンスの場所を確認するのに役に立ちます。

    # fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)-fence_agent.debug

    発生した障害を診断する際に、フェンスデバイスに手動でログインする際に指定したオプションが、フェンスエージェントスクリプトでフェンスエージェントに渡した内容と同一であることを確認する必要があります。

    フェンスエージェントが、暗号化した接続に対応する場合は、証明書の検証で障害が生じているためにエラーが出力される場合があり、ホストを信頼することや、フェンスエージェントの ssl-insecure パラメーターを使用することが求められます。同様に、ターゲットデバイスで SSL/TLS を無効にした場合は、フェンスエージェントに SSL パラメーターを設定する際に、これを考慮しないといけない場合があります。

    注記

    テストしているフェンスエージェントが fence_drac または fence_ilo の場合、もしくはその他の、継続して失敗したその他のシステム管理デバイスのフェンスエージェントの場合は、フォールバックして fence_ipmilan を試行します。多くの場合、システム管理カードは IPMI リモートログインに対応しており、フェンスエージェントとしては fence_ipmilan だけに対応しています。

  3. フェンスデバイスを、手動で機能したオプションと同じオプションでクラスターに設定し、クラスターを起動したら、以下の例にあるように、任意のノードから pcs stonith fence コマンドを実行してフェンシングをテストします (または複数のノードから複数回実行します)。pcs stonith fence コマンドは、クラスター設定を CIB から読み取り、フェンス動作を実行するように設定したフェンスエージェントを呼び出します。これにより、クラスター設定が正確であることが確認できます。

    # pcs stonith fence node_name

    pcs stonith fence コマンドに成功すると、フェンスイベントの発生時に、クラスターのフェンシング設定が機能します。このコマンドが失敗すると、クラスター管理が取得した設定でフェンスデバイスを起動することができません。以下の問題を確認し、必要に応じてクラスター設定を更新します。

    • フェンス設定を確認します。たとえば、ホストマップを使用したことがある場合は、指定したホスト名を使用して、システムがノードを見つけられるようにする必要があります。
    • デバイスのパスワードおよびユーザー名に、bash シェルが誤って解釈する可能性がある特殊文字が含まれるかどうかを確認します。パスワードとユーザー名を引用符で囲んで入力すると、この問題に対処できます。
    • pcs stonith コマンドで IP アドレスまたはホスト名を使用してデバイスに接続できるかどうかを確認します。たとえば、stonith コマンドでホスト名を指定し、IP アドレスを使用して行ったテストは有効ではありません。
    • フェンスデバイスが使用するプロトコルにアクセスできる場合は、そのプロトコルを使用してデバイスへの接続を試行します。たとえば、多くのエージェントが ssh または telnet を使用します。デバイスへの接続は、デバイスの設定時に指定した認証情報を使用して試行する必要があります。これにより、有効なプロンプトを取得し、そのデバイスにログインできるかどうかを確認できます。

      すべてのパラメーターが適切であることが確認できたものの、フェンスデバイスには接続できない時に、フェンスデバイスでログ機能が使用できる場合は、ログを確認できます。これにより、ユーザーが接続したかどうかと、ユーザーが実行したコマンドが表示されます。/var/log/messages ファイルで stonith やエラーを確認すれば、発生している問題のヒントが得られる可能性もあります。また、エージェントによっては、より詳細な情報が得られる場合があります。

  4. フェンスデバイステストに成功し、クラスターが稼働したら、実際の障害をテストします。このテストでは、クラスターで、トークンの損失を生じさせる動作を実行します。

    • ネットワークを停止します。ネットワークの利用方法は、設定により異なります。ただし、多くの場合は、ネットワークケーブルまたは電源ケーブルをホストから物理的に抜くことができます。ネットワーク障害をシミュレートする方法は「RHEL クラスターで、正しくネットワーク障害をシミュレーションするにはどうすればよいですか?」を参照してください。

      注記

      ネットワークや電源ケーブルを物理的に切断せずに、ローカルホストのネットワークインターフェースを無効にすることは、フェンシングのテストとしては推奨されません。実際に発生する障害を正確にシミュレートしていないためです。

    • ローカルのファイアウォールを使用して、corosync の受信トラフィックおよび送信トラフィックをブロックします。

      以下の例では corosync をブロックします。ここでは、デフォルトの corosync ポートと、ローカルのファイアウォールとして firewalld が使用されていることと、corosync が使用するネットワークインターフェースがデフォルトのファイアウォールゾーンにあることが前提となっています。

      # firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP
      # firewall-cmd --add-rich-rule='rule family="ipv4" port port="5405" protocol="udp" drop'
    • sysrq-trigger でクラッシュをシミュレートし、マシンをクラッシュします。ただし、カーネルパニックを発生させると、データが損失する可能性があることに注意してください。クラッシュする前に、クラスターリソースを無効にすることが推奨されます。

      # echo c > /proc/sysrq-trigger

9.6. フェンスレベルの設定

Pacemaker は、フェンストポロジーと呼ばれる機能を用いて、複数デバイスでのノードのフェンシングに対応します。トポロジーを実装するには、通常の方法で各デバイスを作成し、設定のフェンストポロジーセクションでフェンスレベルを 1 つ以上定義します。

  • レベルは、1 から昇順で試行されていきます。
  • デバイスに障害が発生すると、現在のレベルの処理が終了します。同レベルのデバイスには試行されず、次のレベルが試行されます。
  • すべてのデバイスのフェンシングが正常に完了すると、そのレベルが継承され、他のレベルは試行されなくなります。
  • いずれかのレベルで成功するか、すべてのレベルが試行され失敗すると、操作は終了します。

ノードにフェンスレベルを追加する場合は、次のコマンドを使用します。デバイスは、stonith ID をコンマで区切って指定します。stonith ID が、指定したレベルで試行されます。

pcs stonith level add level node devices

次のコマンドを使用すると現在設定されている全フェンスレベルが表示されます。

pcs stonith level

以下の例では、ノード rh7-2 に、2 つのフェンスデバイス (il0 フェンスデバイス my_iloと、apc フェンスデバイス my_apc) が設定されています。このコマンドはフェンスレベルを設定し、デバイス my_ilo に障害が発生し、ノードがフェンスできない場合に、Pacemaker がデバイス my_apc の使用を試行できるようにします。この例では、レベル設定後の pcs stonith level コマンドの出力も表示されています。

# pcs stonith level add 1 rh7-2 my_ilo
# pcs stonith level add 2 rh7-2 my_apc
# pcs stonith level
 Node: rh7-2
  Level 1 - my_ilo
  Level 2 - my_apc

次のコマンドは、指定したノードおよびデバイスのフェンスレベルを削除します。ノードやデバイスを指定しないと、指定したフェンスレベルがすべてのノードから削除されます。

pcs stonith level remove level [node_id] [stonith_id] ... [stonith_id]

以下のコマンドを使用すると、指定したノードや stonith id のフェンスレベルが削除されます。ノードや stonith id を指定しないと、すべてのフェンスレベルが削除されます。

pcs stonith level clear [node|stonith_id(s)]

複数の stonith IDを指定する場合はコンマで区切って指定します。空白は入力しないでください。以下に例を示します。

# pcs stonith level clear dev_a,dev_b

次のコマンドは、フェンスレベルで指定されたフェンスデバイスとノードがすべて存在することを確認します。

pcs stonith level verify

フェンストポロジーのノードは、ノード名に適用する正規表現と、ノードの属性 (およびその値) で指定できます。たとえば、次のコマンドでは、ノード node1node2、および node3 で、フェンスデバイス apc1 および apc2 を使用するように設定し、ノード node4node5、および node6 には、フェンスデバイス apc3 および apc4 を使用するように設定します。

pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2
pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4

次のコマンドでは、ノード属性のマッチングを使用して、同じように設定します。

pcs node attribute node1 rack=1
pcs node attribute node2 rack=1
pcs node attribute node3 rack=1
pcs node attribute node4 rack=2
pcs node attribute node5 rack=2
pcs node attribute node6 rack=2
pcs stonith level add 1 attrib%rack=1 apc1,apc2
pcs stonith level add 1 attrib%rack=2 apc3,apc4

9.7. 冗長電源のフェンシング設定

冗長電源にフェンシングを設定する場合は、ホストを再起動するときに、クラスターが、最初に両方の電源をオフにしてから、いずれかの電源をオンにするようにする必要があります。

ノードの電源が完全にオフにならないと、ノードがリソースを解放しない場合があります。このとき、解放できなかったリソースに複数のノードが同時にアクセスして、リソースが破損する可能性があります。

以下の例にあるように、各デバイスを一度だけ定義し、両方のデバイスがノードのフェンスに必要であると指定する必要があります。

# pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"

# pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2"

# pcs stonith level add 1 node1.example.com apc1,apc2
# pcs stonith level add 1 node2.example.com apc1,apc2

9.8. 設定済みのフェンスデバイスの表示

以下のコマンドは、現在設定されているフェンスデバイスをすべて表示します。stonith_id を指定すると、設定されているその stonith デバイスのオプションだけが表示されます。--full オプションが指定されていると、設定された stonith のオプションがすべて表示されます。

pcs stonith config [stonith_id] [--full]

9.9. フェンスデバイスの修正と削除

現在設定されているフェンスデバイスのオプションを修正したり、新たにオプションを追加する場合は次のコマンドを使用します。

pcs stonith update stonith_id [stonith_device_options]

現在の設定からフェンスデバイスを削除する場合は次のコマンドを使用します。

pcs stonith delete stonith_id

9.10. 手動によるクラスターノードのフェンシング

次のコマンドで、ノードを手動でフェンスできます。--off を指定すると、stonith に API コールの off を使用し、ノードをオフにします (再起動はしません)。

pcs stonith fence node [--off]

ノードがアクティブでない場合でも、そのノードを stonith デバイスがフェンスできない状況では、そのノードのリソースをクラスターが復旧できない可能性があります。この場合は、ノードの電源が切れたことを手動で確認した後、次のコマンドを入力して、ノードの電源が切れたことをクラスターに確認し、そのリソースを回復のために解放できます。

警告

指定したノードが実際にオフになっていない状態で、クラスターソフトウェア、または通常クラスターが制御するサービスを実行すると、データ破損またはクラスター障害が発生します。

pcs stonith confirm node

9.11. フェンスデバイスの無効化

フェンスデバイス/リソースを無効にする場合は、pcs stonith disable コマンドを実行します。

以下のコマンドは、フェンスデバイス myapc を無効にします。

# pcs stonith disable myapc

9.12. ノードがフェンスデバイスを使用しないように設定

特定のノードがフェンスデバイスを使用できないようにするには、フェンスリソースの場所の制約を設定します。

以下の例では、フェンスデバイスの node1-ipmi が、node1 で実行されないようにします。

# pcs constraint location node1-ipmi avoids node1

9.13. 統合フェンスデバイスで使用する ACPI の設定

クラスターが統合フェンスデバイスを使用する場合は、即時かつ完全なフェンシングを実行できるように、ACPI (Advanced Configuration and Power Interface) を設定する必要があります。

クラスターノードが統合フェンスデバイスでフェンシングされるように設定されている場合は、そのノードの ACPI Soft-Off を無効にします。ACPI Soft-Off を無効にすることにより、統合フェンスデバイスは、クリーンシャットダウンを試行する代わりに、ノードを即時に、かつ完全にオフにできます (例: shutdown -h now)。それ以外の場合は、ACPI Soft-Off が有効になっていると、統合フェンスデバイスがノードをオフにするのに 4 秒以上かかることがあります (以下の注記部分を参照してください)。さらに、ACPI Soft-Off が有効になっていて、ノードがシャットダウン時にパニック状態になるか、フリーズすると、統合フェンスデバイスがノードをオフにできない場合があります。このような状況では、フェンシングが遅延するか、失敗します。したがって、ノードが統合フェンスデバイスでフェンシングされ、ACPI Soft-Off が有効になっている場合は、クラスターが徐々に復元します。または管理者の介入による復旧が必要になります。

注記

ノードのフェンシングにかかる時間は、使用している統合フェンスデバイスによって異なります。統合フェンスデバイスの中には、電源ボタンを押し続けるのと同じ動作を実行するものもあります。この場合は、ノードがオフになるのに 4 秒から 5 秒かかります。また、電源ボタンを押してすぐ離すのと同等の動作を行い、ノードの電源をオフにする行為をオペレーティングシステムに依存する統合フェンスデバイスもあります。この場合は、ノードがオフになるのにかかる時間は 4~ 5 秒よりも長くなります。

  • ACPI Soft-Off を無効にする場合は、BIOS 設定を「instant-off」、またはこれに類似する設定に変更することが推奨されます。これにより、「BIOS で ACPI Soft-Off を無効化」で説明しているように、ノードは遅延なくオフになります。

システムによっては、BIOS で ACPI Soft-Off を無効にできません。お使いのクラスターでは、BIOS で ACPI Soft-Off を無効にできない場合に、以下のいずれかの方法で ACPI Soft-Off を無効にできます。

  • 「logind.conf ファイルで ACPI Soft-Off の無効化」で説明しているように、HandlePowerKey=ignore/etc/systemd/logind.conf ファイルに設定し、ノードがフェンシングされるとすぐにオフになることを確認します。これが、ACPI Soft-Off を無効にする 1 つ目の代替方法です。
  • 「GRUB 2 ファイルを使用した ACPI の完全な無効化」で説明しているように、カーネル起動コマンドラインに acpi=off を追加します。これは、ACPI Soft-Off を無効にする 2 つ目の代替方法です。この方法の使用が推奨される場合、または 1 つ目の代替方法が利用できない場合に使用してください。

    重要

    この方法は、ACPI を完全に無効にします。コンピューターの中には、ACPI が完全が無効になってるとシステムが正しく起動しないものもあります。お使いのクラスターに適した方法が他にない場合に 限り、この方法を使用してください。

9.13.1. BIOS で ACPI Soft-Off を無効化

以下の手順で、各クラスターノードの BIOS を設定して、ACPI Soft-Off を無効にできます。

注記

BIOS で ACPI Soft-Off を無効にする手順は、サーバーシステムにより異なる場合があります。この手順は、お使いのハードウェアのドキュメントで確認する必要があります。

  1. ノードを再起動して BIOS CMOS Setup Utility プログラムを起動します。
  2. 電源メニュー (または同等の電源管理メニュー) に移動します。
  3. 電源メニューで、Soft-Off by PWR-BTTN 機能 (または同等の機能) を Instant-Off (または、遅延なく電源ボタンでノードをオフにする設定と同等の設定) に設定します。BIOS CMOS Setup Utilityでは、ACPI FunctionEnabled に設定され、Soft-Off by PWR-BTTNInstant-Off に設定されている電源メニューを表示します。

    注記

    ACPI FunctionSoft-Off by PWR-BTTN、および Instant-Off に相当するものは、コンピューターによって異なります。ただし、この手順の目的は、電源ボタンを使用して遅延なしにコンピューターをオフにするように BIOS を設定することです。

  4. BIOS CMOS Setup Utility プラグラムを終了して、BIOS 設定を保存します。
  5. ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

BIOS CMOS Setup Utility

`Soft-Off by PWR-BTTN` set to
`Instant-Off`

+---------------------------------------------|-------------------+
|    ACPI Function             [Enabled]      |    Item Help      |
|    ACPI Suspend Type         [S1(POS)]      |-------------------|
|  x Run VGABIOS if S3 Resume   Auto          |   Menu Level   *  |
|    Suspend Mode              [Disabled]     |                   |
|    HDD Power Down            [Disabled]     |                   |
|    Soft-Off by PWR-BTTN      [Instant-Off   |                   |
|    CPU THRM-Throttling       [50.0%]        |                   |
|    Wake-Up by PCI card       [Enabled]      |                   |
|    Power On by Ring          [Enabled]      |                   |
|    Wake Up On LAN            [Enabled]      |                   |
|  x USB KB Wake-Up From S3     Disabled      |                   |
|    Resume by Alarm           [Disabled]     |                   |
|  x  Date(of Month) Alarm       0            |                   |
|  x  Time(hh:mm:ss) Alarm       0 :  0 :     |                   |
|    POWER ON Function         [BUTTON ONLY   |                   |
|  x KB Power ON Password       Enter         |                   |
|  x Hot Key Power ON           Ctrl-F1       |                   |
|                                             |                   |
|                                             |                   |
+---------------------------------------------|-------------------+

この例では、ACPI FunctionEnabled に設定され、Soft-Off by PWR-BTTNInstant-Off に設定されていることを示しています。

9.13.2. logind.conf ファイルで ACPI Soft-Off の無効化

/etc/systemd/logind.conf ファイルで電源キーの処理を無効にする場合は、以下の手順を行います。

  1. /etc/systemd/logind.conf ファイルに、以下の設定を定義します。

    HandlePowerKey=ignore
  2. systemd-logind サービスを再起動します。

    # systemctl restart systemd-logind.service
  3. ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

9.13.3. GRUB 2 ファイルを使用した ACPI の完全な無効化

ACPI Soft-Off は、カーネルの GRUB メニューエントリーに acpi=off を追加して無効にできます。

重要

この方法は、ACPI を完全に無効にします。コンピューターの中には、ACPI が完全が無効になってるとシステムが正しく起動しないものもあります。お使いのクラスターに適した方法が他にない場合に 限り、この方法を使用してください。

以下の手順で、GRUB 2 ファイルで ACPI を無効にします。

  1. 以下のように、grubby ツールで、--args オプションと --update-kernel オプションを使用して、各クラスターノードの grub.cfg ファイルを変更します。

    # grubby --args=acpi=off --update-kernel=ALL
  2. ノードを再起動します。
  3. ノードがフェンシングされるとすぐにオフになることを確認します。フェンスデバイスをテストする方法は「フェンスデバイスのテスト」を参照してください。

第10章 クラスターリソースの設定

クラスターリソースを作成するコマンドの形式は、以下のとおりです。

pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action operation_options [operation_action operation options]...] [meta meta_options...] [clone [clone_options] | master [master_options] | --group group_name [--before resource_id | --after resource_id] | [bundle bundle_id] [--disabled] [--wait[=n]]

主なクラスターリソースの作成オプションには、以下が含まれます。

  • --group オプションを指定すると、名前付きのリソースグループにリソースが追加されます。グループが存在しない場合は作成され、そのグループにリソースが追加されます。
  • --before および --after オプションは、リソースグループに含まれるリソースを基準にして、追加するリソースの位置を指定します。
  • --disabled オプションは、リソースが自動的に起動しないことを示しています。

リソースの制約を設定して、クラスター内のそのリソースの動作を指定できます。

リソース作成の例

以下のコマンドは、仕様 ocf、プロバイダー heartbeat、およびタイプ IPaddr2 で、リソース VirtualIP を作成します。このリソースのフローティングアドレスは 192.168.0.120 であり、システムは、30 秒間隔で、リソースが実行しているかどうかを確認します。

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s

または、以下のように、standard フィールドおよび provider フィールドを省略できます。規格とプロバイダーはそれぞれ ocfheartbeat にデフォルト設定されます。

# pcs resource create VirtualIP IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s

設定済みリソースの削除

設定したリソースを削除する場合は、次のコマンドを実行します。

pcs resource delete resource_id

たとえば、次のコマンドは、リソース ID が VirtualIP の既存リソースを削除します。

# pcs resource delete VirtualIP

10.1. リソースエージェント識別子

リソースに定義する識別子は、リソースに使用するエージェント、そのエージェントを検索する場所、およびそれが準拠する仕様をクラスターに指示します。表10.1「リソースエージェント識別子」では、このプロパティーを説明します。

表10.1 リソースエージェント識別子

フィールド説明

standard

エージェントが準拠する規格。使用できる値とその意味は以下のとおりです。

* ocf - 指定した type は、Open Cluster Framework Resource Agent API に準拠した実行可能ファイルの名前で、/usr/lib/ocf/resource.d/provider の下に置かれます。

* lsb - 指定した type は、Linux Standard Base Init Script Actions に準拠する実行ファイルの名前です。type で完全パスを指定しないと、システムは /etc/init.d ディレクトリーを探します。

* systemd - 指定した type は、インストール済み systemd ユニットの名前です。

* service - Pacemaker は、指定した type を選択します (まずは lsb エージェントとして、次に systemd エージェントとして)。

* nagios - 指定した type は、Nagios Plugin API に準拠する実行可能ファイルの名前で、/usr/libexec/nagios/plugins ディレクトリーに置かれます。OCF スタイルのメタデータは、/usr/share/nagios/plugins-metadata ディレクトリーに置かれます (一般的なプラグインは nagios-agents-metadata パッケージで入手可能)。

type

使用するリソースエージェントの名前 (例: IPaddr または Filesystem)

provider

OCF 仕様により、複数のベンダーで同じリソースエージェントを指定できます。Red Hat が提供するエージェントのほとんどは、プロバイダーに heartbeat を使用しています。

表10.2「リソースプロパティーを表示させるコマンド」は、利用可能なリソースプロパティーを表示するコマンドの概要を示しています。

表10.2 リソースプロパティーを表示させるコマンド

pcs 表示コマンド出力

pcs resource list

利用できる全リソースの一覧を表示

pcs resource standards

利用できるリソースエージェントの一覧を表示

pcs resource providers

利用できるリソースエージェントプロバイダーの一覧を表示

pcs resource list string

利用できるリソースを指定文字列でフィルターした一覧を表示。仕様名、プロバイダー名、タイプ名などでフィルターを指定して、リソースを表示できます。

10.2. リソース固有のパラメーターの表示

各リソースで以下のコマンドを使用すると、リソースの説明、そのリソースに設定できるパラメーター、およびそのリソースに設定されるデフォルト値が表示されます。

pcs resource describe [standard:[provider:]]type

たとえば、以下のコマンドは、apache タイプのリソース情報を表示します。

# pcs resource describe ocf:heartbeat:apache
This is the resource agent for the Apache Web server.
This resource agent operates both version 1.x and version 2.x Apache
servers.

...

10.3. リソースのメタオプションの設定

リソースには、リソース固有のパラメーターの他に、リソースオプションを設定できます。このような追加オプションは、クラスターがリソースの動作を決定する際に使用されます。

表10.3「リソースのメタオプション」は、リソースメタオプションを示しています。

表10.3 リソースのメタオプション

フィールドデフォルト説明

priority

0

すべてのリソースをアクティブにできない場合に、クラスターは優先度の低いリソースを停止して、優先度が高いリソースを実行し続けます。

target-role

Started

クラスターが維持するリソースのステータスです。使用できる値は以下のようになります。

* Stopped - リソースの強制停止

* Started - リソースの起動を許可 (クローン昇格でき、適切な場合は、マスターロールに昇格する)

* Master - リソースの起動を許可し、必要に応じて昇格

* Slave - リソースが昇格可能な場合は、リソースの開始は可能だが、スレーブモードでのみ可能

is-managed

true

クラスターによるリソースの起動と停止が可能かどうか。使用できる値は true または false です。

resource-stickiness

0

リソースを同じ場所に残すための優先度の値です。

requires

Calculated

リソースを起動できる条件を示します。

以下の条件を除き、fencing がデフォルトに設定されます。以下の値が使用できます。

* nothing - クラスターは常にリソースを開始できます。

* quorum - クラスターは、設定されているノードの過半数がアクティブな場合に限りこのリソースを起動できます。stonith-enabledfalse に設定されている場合、またはリソースの standardstonith の場合は、このオプションがデフォルト値となります。

* fencing -設定されているノードの過半数がアクティブ、かつ 障害が発生しているノードや不明なノードがフェンスになっている場合に限り、クラスターはこのリソースを起動できます。

* unfencing - 設定されているノードの過半数がアクティブで、かつ 障害が発生しているノードや不明なノードがすべてフェンスされており、フェンシング されていないノードに 限り、クラスターはこのリソースを起動できます。provides=unfencing stonith メタオプションがフェンスデバイスに設定されている場合のデフォルト値です。

migration-threshold

INFINITY

指定したリソースが任意のノードで失敗した回数です。この回数を超えると、そのノードには、このリソースのホストとして不適格とするマークが付けられます。値を 0 にするとこの機能は無効になり、ノードに不適格マークが付けられることはありません。INFINITY (デフォルト) に設定すると、クラスターは、これを非常に大きい有限数として扱います。このオプションは、失敗した操作に on-fail=restart (デフォルト) が設定されていて、かつ失敗した起動操作のクラスタープロパティー start-failure-is-fatalfalse に設定されている場合に限り有効です。

failure-timeout

0 (無効)

migration-threshold オプションと併用されます。障害が発生していないかのように動作し、障害が発生したノードにリソースを戻せるようになるまで待機する秒数を示します。タイムベースのアクションと同様、これが、cluster-recheck-interval クラスターパラメーターの値よりも頻繁に確認される保証はありません。

multiple-active

stop_start

リソースが複数のノードでアクティブであることが検出された場合に、クラスターが実行する動作です。使用できる値は以下のようになります。

* block - リソースに unmanaged のマークを付けます。

* stop_only - 実行中のインスタンスをすべて停止し、以降の動作は行いません。

* stop_start - 実行中のインスタンスをすべて停止してから、リソースを 1 カ所でのみ起動します。

10.3.1. リソースオプションのデフォルト値の変更

リソースオプションのデフォルト値を変更する場合は、次のコマンドを使用します。

pcs resource defaults options

たとえば、次のコマンドは、resource-stickiness のデフォルト値を 100 にリセットします。

# pcs resource defaults resource-stickiness=100

10.3.2. 現在設定されているリソースのデフォルトの表示

pcs resource defaultsoptions パラメーターを省略すると、現在設定されているリソースオプションのデフォルト値の一覧が表示されます。次の例では resource-stickiness のデフォルト値を 100 にリセットした後のコマンド出力を示しています。

# pcs resource defaults
resource-stickiness: 100

10.3.3. リソース作成でメタオプションの設定

リソースのメタオプションにおけるデフォルト値のリセットの有無に関わらず、リソースを作成する際に、特定リソースのリソースオプションをデフォルト以外の値に設定できます。以下は、リソースのメタオプションの値を指定する際に使用する pcs resource create コマンドの形式です。

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta meta_options...]

たとえば、以下のコマンドでは resource-stickiness の値を 50 に設定したリソースを作成します。

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 meta resource-stickiness=50

また、次のコマンドを使用すると既存のリソース、グループ、クローン作成したリソース、マスターリソースなどのリソースメタオプションの値を作成することもできます。

pcs resource meta resource_id | group_id | clone_id meta_options

以下の例では、dummy_resource という名前の既存リソースがあります。このコマンドは、failure-timeout メタオプションの値を 20 秒に設定します。これにより 20 秒でリソースが同じノード上で再起動を試行できるようになります。

# pcs resource meta dummy_resource failure-timeout=20s

上記のコマンドを実行した後、リソースの値を表示して、failure-timeout=20s が設定されているかどうかを確認できます。

# pcs resource config dummy_resource
 Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
  Meta Attrs: failure-timeout=20s
  ...

10.4. リソースグループの設定

クラスターの最も一般的な構成要素の 1 つがリソースセットです。リソースセットはまとめて配置し、順番に起動し、その逆順で停止する必要があります。この設定を簡単にするため、Pacemaker はリソースグループの概念をサポートします。

10.4.1. リソースグループの作成

以下のコマンドを使用してリソースグループを作成し、グループに追加するリソースを指定します。グループが存在しない場合は、このコマンドによりグループが作成されます。グループが存在する場合は、このコマンドにより別のリソースがグループに追加されます。リソースは、このコマンドで指定された順序で起動し、その逆順で停止します。

pcs resource group add group_name resource_id [resource_id] ... [resource_id] [--before resource_id | --after resource_id]

このコマンドの --before オプションおよび --after オプションを使用して、追加するリソースの位置を、そのグループにすでに含まれるリソースを基準にして指定できます。

以下のコマンドを使用して、リソースを作成するときに、既存のグループに新しいリソースを追加することもできます。以下のコマンドでは、作成するリソースが group_name グループに追加されます。group_name グループが存在しない場合は作成されます。

pcs resource create resource_id [standard:[provider:]]type [resource_options] [op operation_action operation_options] --group group_name

グループに含まれるリソースの数に制限はありません。グループの基本的なプロパティーは以下のとおりです。

  • グループ内に、複数のリソースが置かれています。
  • リソースは、指定した順序で起動します。グループ内に実行できないリソースがあると、そのリソースの後に指定されたリソースは実行できません。
  • リソースは、指定した順序と逆の順序で停止します。

以下の例では、既存リソースの IPaddrEmail が含まれるリソースグループ shortcut が作成されます。

# pcs resource group add shortcut IPaddr Email

この例では、以下のように設定されています。

  • IPaddr が起動してから、Email が起動します。
  • Email リソースが停止してから、IPAddr が停止します。
  • IPaddr を実行できない場合は、Email も実行できません。
  • Email を実行できなくても、IPaddr には影響ありません。

10.4.2. リソースグループの削除

以下のコマンドを使用して、グループからリソースを削除します。グループにリソースが残っていないと、このコマンドによりグループ自体が削除されます。

pcs resource group remove group_name resource_id...

10.4.3. リソースグループの表示

以下のコマンドは、現在設定されているリソースグループを一覧表示します。

pcs resource group list

10.4.4. グループオプション

リソースグループには、priority オプション、target-role オプション、または is-managed オプションを設定できます。このオプションは、1 つのリソースに設定されている場合と同じ意味を維持します。リソースのメタオプションの詳細は、「リソースメタオプションの設定」を参照してください。

10.4.5. グループの粘着性

粘着性は、リソースを現在の場所に留ませる優先度の度合いを示し、グループで加算されます。グループのアクティブなリソースが持つ stickness 値の合計が、グループの合計になります。そのため、resource-stickiness のデフォルト値が 100 で、グループに 7 つのメンバーがあり、そのメンバーの 5 つがアクティブな場合は、グループ全体でスコアが 500 の現在の場所が優先されます。

10.5. リソース動作の決定

リソースの制約を設定して、クラスター内のそのリソースの動作を指定できます。以下の制約のカテゴリーを設定できます。

複数リソースをまとめて配置して、順番に起動するまたは逆順で停止する一連の制約を簡単に設定する方法として、Pacemaker ではリソースグループという概念に対応しています。リソースグループの作成後に、個別のリソースの制約を設定するようにグループ自体に制約を設定できます。リソースグループの情報は「リソースグループの設定」を参照してください。

第11章 リソースを実行するノードの決定

場所の制約は、リソースを実行するノードを指定します。場所の制約を設定することで、たとえば特定のノードで優先してリソースを実行する、または特定のノードではリソースを実行しないことを決定できます。

場所の制約に加え、リソースが実行されるノードは、そのリソースの resource-stickiness 値に影響されます。これは、リソースが現在実行しているノードに留まることをどの程度優先するかを決定します。resource-stickiness 値を設定する方法は、「現在のノードを優先するようにリソースの設定」を参照してください。

11.1. 場所の制約の設定

基本的な場所の制約を設定し、オプションの score 値で制約の相対的な優先度を指定することで、リソースの実行を特定のノードで優先するか、または回避するかを指定できます。

以下のコマンドは、リソースの実行を、指定した 1 つまたは複数のノードで優先するように、場所の制約を作成します。1 回のコマンドで、特定のリソースの制約を複数のノードに対して作成できます。

pcs constraint location rsc prefers node[=score] [node[=score]] ...

次のコマンドは、リソースが指定ノードを回避する場所の制約を作成します。

pcs constraint location rsc avoids node[=score] [node[=score]] ...

表11.1「場所の制約オプション」では、場所の制約を設定する基本的なオプションを説明します。

表11.1 場所の制約オプション

フィールド説明

rsc

リソース名

node

ノード名

score

指定のリソースが指定のノードを優先するべきか回避するべきかを示す優先度を示す正の整数値。INFINITY は、リソースの場所制約のデフォルト score 値です。

リソースを特定ノードで優先的に実行するように設定するコマンドで score の値を INFINITY にすると、そのノードが利用可能な場合は、リソースがそのノードで優先的に実行します。ただし、そのノードが利用できない場合に、別のノードでそのリソースを実行しないようにする訳ではありません。リソースがノードを回避するように設定するコマンドで INFINITY を設定した場合は、その他のノードが利用できない場合でも、そのリソースはそのノードでは実行されません。

数値スコア (INFINITY 以外) は、その制約が任意で、それを上回る要因が他にない限り有効となることを意味します。たとえば、リソースが別のノードに置かれ、その resource-stickiness スコアが、場所制約のスコアよりも 優先 される場合は、リソースがその場所に残されます。

以下のコマンドは、Webserver リソースが、node1 ノードで優先的に実行するように指定する場所の制約を作成します。

pcs constraint location Webserver prefers node1

pcs では、コマンドラインの場所の制約に関する正規表現に対応しています。この制約は、リソース名に一致する正規表現に基づいて、複数のリソースに適用されます。これにより、1 つのコマンドラインで複数の場所の制約を設定できます。

次のコマンドは、dummy0 から dummy9 までのリソースの実行が node1 に優先されるように指定する場所の制約を作成します。

pcs constraint location 'regexp%dummy[0-9]' prefers node1

Pacemaker は、 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04 に説明されているとおり、POSIX 拡張正規表現を使用するため、次のコマンドを実行しても同じ制約を指定できます。

pcs constraint location 'regexp%dummy[[:digit:]]' prefers node1

11.2. ノードのサブセットへのリソース検出を制限

Pacemaker がどこでリソースを開始しても、開始する前にそのリソースがすでに実行しているかどうかを確認するために、すべてのノードでワンタイム監視操作 (「プローブ」とも呼ばれています) を実行します。このリソース検出のプロセスは、監視を実行できないノードではエラーになる場合があります。

ノードに場所の制約を設定する際に、pcs constraint location コマンドの resource-discovery オプションを指定して、指定したリソースに対して、Pacemaker がこのノードでリソース検出を実行するかどうかの優先度を指定できます。物理的にリソースが稼働可能なノードのサブセットでリソース検出を制限すると、ノードが大量に存在する場合にパフォーマンスを大幅に改善できます。pacemaker_remote を使用して、ノード数を 100 単位で拡大する場合は、このオプションの使用を検討してください。

以下のコマンドは、pcs constraint location コマンドで resource-discovery オプションを指定する場合の形式を示しています。このコマンドでは、基本的な場所の制約に対応します。score を正の値にすると、リソースが特定のノードで優先的に実行するように設定されます。score を負の値にすると、リソースがノードを回避するように設定されます。基本的な場所の制約と同様に、制約にリソースの正規表現を使用することもできます。

pcs constraint location add id rsc node score [resource-discovery=option]

表11.2「リソース検出制約パラメーター」では、リソース検出の制約を設定する基本パラメーターを説明します。

表11.2 リソース検出制約パラメーター

フィールド

説明

id

制約自体にユーザーが選択した名前。

rsc

リソース名

node

ノード名

score

指定のリソースが指定のノードを優先するべきか回避するべきかを示す優先度を示す整数値。スコアが正の値の場合は、ノードを優先するようにリソースを設定する基本的な場所の制約となり、負の場合は、ノードを回避するようにリソースを設定する基本的な場所の制約となります。

score の値を INFINITY に設定すると、そのノードが利用可能な場合は、リソースがそのノードで優先的に実行します。ただし、そのノードが利用できない場合に、別のノードでそのリソースを実行しないようにする訳ではありません。リソースがノードを回避するように設定するコマンドで INFINITY を設定した場合は、その他のノードが利用できない場合でも、そのリソースはそのノードでは実行されません。

数値スコア (INFINITY または -INFINITY 以外) は、その制約が任意で、それを上回る要因が他にない限り有効となることを意味します。たとえば、リソースが別のノードに置かれ、その resource-stickiness スコアが、場所制約のスコアよりも 優先 される場合は、リソースがその場所に残されます。

resource-discovery オプション

* always - このノードに指定したリソースで、リソース検出を常に実行します。これは、リソースの場所の制約の resource-discovery のデフォルト値です。

* never - このノードで、指定したリソースに対してリソース検出を行いません。

* exclusive - このノード (および同様に exclusive マークが付いているその他のノード) で指定したリソースに対してのみ、リソースの検出を行います。複数のノードで同じリソースの exclusive 検出を使用する複数の場所制約により、resource-discovery が排他的であるノードのサブセットが作成されます。1 つまたは複数のノードで、リソースが exclusive 検出用にマーク付けされている場合、そのリソースは、ノードのサブセット内にのみ配置できます。

警告

resource-discoverynever または exclusive に設定すると、Pacemaker が、想定されていない場所で実行している不要なサービスのインスタンスを検出して停止する機能がなくなります。関連するソフトウェアをアンインストールしたままにするなどして、リソース検出なしでサービスがノードでアクティブにならないようにすることは、システム管理者の責任です。

11.3. 場所の制約方法の設定

場所の制約を使用する場合は、リソースをどのノードで実行できるかを指定する一般的な方法を設定できます。

  • オプトインクラスター - デフォルトでは、すべてのリソースを、どのノードでも実行できません。そして、特定のリソースに対してノードを選択的に許可できるようにクラスターを設定します。
  • オプトアウトクラスター - デフォルトでは、すべてのリソースをどのノードでも実行できるクラスターを設定してから、リソースを特定のノードで実行しないように、場所の制約を作成します。

クラスターでオプトインまたはオプトアウトのどちらを選択するかは、優先する設定やクラスターの構成により異なります。ほとんどのリソースをほとんどのノードで実行できるようにする場合は、オプトアウトを使用した方が設定しやすくなる可能性があります。ほとんどのリソースを、一部のノードでのみ実行する場合は、オプトインを使用した方が設定しやすくなる可能性があります。

11.3.1. 「オプトイン」クラスターの設定

オプトインクラスターを作成する場合は、クラスタープロパティー symmetric-clusterfalse に設定し、デフォルトでは、いずれのノードでもリソースの実行を許可しないようにします。

# pcs property set symmetric-cluster=false

個々のリソースでノードを有効にします。以下のコマンドは、場所の制約を設定し、Webserver リソースでは example-1 ノードが優先され、Database リソースでは example-2 ノードが優先されるようにし、いずれのリソースも優先ノードに障害が発生した場合は example-3 ノードにフェールオーバーできるようにします。オプトインクラスターに場所の制約を設定する場合は、スコアをゼロに設定すると、リソースに対してノードの優先や回避を指定せずに、リソースをノードで実行できます。

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver prefers example-3=0
# pcs constraint location Database prefers example-2=200
# pcs constraint location Database prefers example-3=0

11.3.2. 「オプトアウト」クラスターの設定

オプトアウトクラスターを作成するには、クラスタープロパティー symmetric-clustertrue に設定し、デフォルトで、すべてのノードでリソースの実行を許可します。これは、symmetric-cluster が明示的に設定されていない場合のデフォルト設定です。

# pcs property set symmetric-cluster=true

以下のコマンドを実行すると、「「オプトイン」クラスターの設定」の例と同じ設定になります。全ノードのスコアは暗黙で 0 になるため、優先ノードに障害が発生した場合はいずれのリソースも example-3 ノードにフェールオーバーできます。

# pcs constraint location Webserver prefers example-1=200
# pcs constraint location Webserver avoids example-2=INFINITY
# pcs constraint location Database avoids example-1=INFINITY
# pcs constraint location Database prefers example-2=200

INFINITY は、スコアのデフォルト値であるため、上記コマンドでは、スコアに INFINITY を指定する必要はないことに注意してください。

11.4. 現在のノードを優先するようにリソースを設定

リソースには、「リソースのメタオプションの設定」で説明されているように、リソースの作成時にメタ属性として設定できる resource-stickiness 値があります。resource-stickiness 値は、現在実行しているノード上にリソースが残す量を決定します。Pacemaker は、resource-stickiness の値を他の設定 (場所の制約の score 値など) と併用して、リソースを別のノードに移動するか、またはこれをそのまま残すかを決定します。

デフォルトで、リソースは resource-stickiness の値 0 で作成されます。resource-stickiness が 0 に設定され、場所の制約が設定されていない場合に Pacemaker のデフォルト動作により、リソースがクラスターノード間で均等に分散されるようにします。これにより、健全なリソースが、ユーザーが発見するよりも頻繁に移動する可能性があります。この動作を防ぐには、デフォルトの resource-stickiness の値を 1 に設定します。このデフォルトは、クラスター内のすべてのリソースに適用されます。この小さい値は、作成する他の制約で簡単に上書きできますが、Pacemaker がクラスター全体で正常なリソースを不必要に移動しないようにするには十分です。

以下のコマンドは、resource-stickiness のデフォルト値を 1 に設定します。

# pcs resource defaults resource-stickiness=1

resource-stickiness の値が設定されている場合は、リソースが新たに追加されたノードに移動しません。この時点でリソースバランスが必要な場合は、resource-stickiness の値を一時的に 0 に設定できます。

場所の制約スコアが resource-stickiness 値よりも高い場合、クラスターは、場所の制約が指すノードに正常なリソースを移動する可能性があります。

Pacemaker がリソースを配置する場所を決定する方法の詳細は、「ノード配置ストラテジーの設定」を参照してください。

第12章 クラスターリソースの実行順序の決定

リソースが実行する順序を指定する、順序の制約を設定できます。

次は、順序の制約を設定するコマンドの形式です。

pcs constraint order [action] resource_id then [action] resource_id [options]

表12.1「順序の制約のプロパティー」では、順序の制約を設定する場合のプロパティーとオプションをまとめています。

表12.1 順序の制約のプロパティー

フィールド説明

resource_id

動作を行うリソースの名前。

action

リソースで実行する動作。action プロパティーでは、以下の値が使用できます。

* start - リソースを起動する

* stop - リソースを停止する

* promote - スレーブリソースからマスターリソースにリソースの昇格を行う

* demote - マスターリソースからスレーブリソースにリソースの降格を行う

動作を指定しない場合のデフォルトの動作は start です。

kind オプション

制約の実施方法。kind オプションでは、以下の値が使用できます。

* Optional - 両方のリソースが指定の動作を実行する場合のみ適用されます。オプションの順序の詳細は「勧告的な順序付けの設定」を参照してください。

* Mandatory - 常に実施 (デフォルト値) します。1 番目に指定したリソースが停止していたり、起動できない場合は、2 番目に指定したリソースが停止します。この強制的な順序付けの詳細は「強制的な順序付けの設定」を参照してください。

* Serialize - 指定するリソースに対して、複数の停止または起動のアクションが同時に発生しないようにします。指定した 1 番目および 2 番目のリソースは、いずれの順序でも起動できますが、片方が完了しないともう片方が開始しません。典型的なユースケースは、リソースの起動によりホストの負荷が高くなる場合です。

symmetrical オプション

true にすると、逆の制約は、逆のアクションに適用されます (たとえば A が開始してから B が開始する場合は、B が停止するまで、kindSerialize である順序制約を対称にすることはできません)。デフォルト値は、Mandatory および Ordering の場合は true で、Serialize の場合は false になります。

次のコマンドを使用すると、すべての順序の制約からリソースが削除されます。

pcs constraint order remove resource1 [resourceN]...

12.1. 強制的な順序付けの設定

必須順序制約は、最初のリソースに対する最初のアクションが正常に完了しない限り、2 番目のリソースの 2 番目のアクションが開始しないことを示しています。命令できるアクションが stop または start で、昇格可能なクローンが demote および promote とします。たとえば、「A then B」(「start A then start B」と同等) は、A が適切に開始しない限り、B が開始しないことを示しています。順序の制約は、この制約の kind オプションが Mandatory に設定されているか、デフォルトのままに設定されている場合は必須になります。

symmetrical オプションが true に設定されているか、デフォルトのままにすると、逆のアクションの命令は逆順になります。startstop のアクションは対称になり、demotepromote は対称になります。たとえば、対称的に、「promote A then start B」順序は「stop B then demote A」(B が正常に停止するまで A が降格しない) ことを示しています。対称順序は、A の状態を変更すると、B に予定されているアクションが発生すること示しています。たとえば、「A then B」と設定した場合は、失敗により A が再起動すると、B が最初に停止してから、A が停止し、それにより A が開始し、それにより B が開始することを示します。

クラスターは、それぞれの状態変化に対応することに注意してください。2 番目のリソースで停止操作を開始する前に 1 番目のリソースが再起動し、起動状態にあると、2 番目のリソースを再起動する必要がありません。

12.2. 勧告的な順序付けの設定

順序の制約に kind=Optional オプションを指定すると、制約はオプションと見なされ、両方のリソースが指定の動作を実行する場合にのみ適用されます。1 番目に指定しているリソースの状態を変更しても、2 番目に指定しているリソースには影響しません。

次のコマンドは、VirtualIPdummy_resource という名前のリソースに、勧告的な順序の制約を設定します。

# pcs constraint order VirtualIP then dummy_resource kind=Optional

12.3. リソースセットへの順序の設定

一般的に、管理者は、複数のリソースの連鎖を作成する際に順序を設定します (例: リソース A が開始してからリソース B を開始し、その後にリソース C を開始)。複数のリソースを作成して同じ場所に配置し (コロケーションを指定)、起動の順序を設定する必要がある場合は、「リソースグループの設定」に従って、このようなリソースが含まれるリソースグループを設定できます。

ただし、特定の順序で起動する必要があるリソースをリソースグループとして設定することが適切ではない場合があります。

  • リソースを順番に起動するように設定する必要があるものの、リソースは必ずしも同じ場所に配置しない場合
  • リソース C の前にリソース A または B のいずれかが起動する必要があるものの、A と B の間には関係が設定されていない場合
  • リソース C およびリソース D の前にリソース A およびリソース B の両方が起動している必要があるものの、A と B、または C と D の間には関係が設定されていない場合

このような状況では、pcs constraint order set コマンドを使用して、1 つまたは複数のリソースセットに対して順序の制約を作成できます。

pcs constraint order set コマンドを使用して、リソースセットに以下のオプションを設定できます。

  • sequential - リソースセットに順序を付ける必要があるかどうかを指定します。true または false に設定できます。デフォルト値は true です。

    sequentialfalse に設定すると、セットのメンバーに順序を設定せず、順序の制約にあるセット間で順序付けできます。そのため、このオプションは、制約に複数のセットが登録されている場合に限り有効です。それ以外の場合は、制約を設定しても効果がありません。

  • require-all - 続行する前にセットの全リソースがアクティブである必要があるかどうかを指定します。true または false に設定できます。require-allfalse に設定すると、次のセットに進む前に、セットの 1 つのリソースのみを開始する必要があります。require-allfalse に設定しても、sequentialfalse に設定されている順序なしセットと併用しない限り、効果はありません。デフォルト値は true です。
  • action - 「順序の制約のプロパティー」で説明しているように、startpromotedemote、または stop に設定できます。
  • role - StoppedStartedMaster、または Slave に設定できます。

pcs constraint order set コマンドの setoptions パラメーターに続いて、リソースのセットに対する以下の制約オプションを設定できます。

pcs constraint order set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]

D1D2D3 という 3 つのリソースがある場合は、次のコマンドを実行すると、この 3 つのリソースを、順序を指定したリソースセットとして設定します。

# pcs constraint order set D1 D2 D3

この例では、ABCDE、および F という名前の 6 つのリソースがある場合に、以下のように、起動するリソースセットに順序制約を設定します。

  • AB は、互いに独立して起動します。
  • A または B のいずれかが開始すると、C が開始します。
  • C が開始すると、D が開始します。
  • D が開始したら、EF が互いに独立して起動します。

symmetrical=false が設定されているため、リソースの停止は、この制約の影響を受けません。

# pcs constraint order set A B sequential=false require-all=false set C D set E F sequential=false setoptions symmetrical=false

12.4. Pacemaker で管理されないリソース依存関係の起動順序の設定

クラスターは、クラスターが管理していない依存関係を持つリソースを含めることができます。この場合は、Pacemaker を起動する前にその依存関係を起動し、Pacemaker が停止した後に停止する必要があります。

systemd resource-agents-deps ターゲットを使用してこの条件を構成するために、スタートアップ順序を設定できます。このターゲットに対して systemd ドロップインユニットを作成すると、Pacemaker はこのターゲットに対して相対的な順序を適切に設定できます。

たとえば、クラスターが管理していない外部サービス foo に依存するリソースがクラスターに含まれている場合は、以下の手順を実行します。

  1. 以下を含むドロップインユニット /etc/systemd/system/resource-agents-deps.target.d/foo.conf を作成します。

    [Unit]
    Requires=foo.service
    After=foo.service
  2. systemctl daemon-reload コマンドを実行します。

この方法で指定するクラスターの依存関係はサービス以外のものとなります。たとえば、/srv にファイルシステムをマウントする依存関係がある場合は、以下の手順を実行してください。

  1. /etc/fstab ファイルに /srv が記載されていることを確認します。これは、システムマネージャーの設定が再読み込みされる際に、システムの起動時に systemd ファイルの srv.mount に自動的に変換されます。詳細は、man ページの systemd.mount(5) および systemd-fstab-generator(8) を参照してください。
  2. ディスクのマウント後に Pacemaker が起動するようにするには、以下を含むドロップインユニット /etc/systemd/system/resource-agents-deps.target.d/srv.conf を作成します。

    [Unit]
    Requires=srv.mount
    After=srv.mount
  3. systemctl daemon-reload コマンドを実行します。

第13章 クラスターリソースのコロケーション

あるリソースの場所を、別のリソースの場所に依存させるように指定する場合は、コロケーションの制約を設定します。

2 つのリソース間にコロケーション制約を作成すると、リソースがノードに割り当てられる割り当てる順序に重要な影響を及ぼす点に注意してください。リソース B の場所を把握していない場合は、リソース B に相対的となるようにリソース A を配置することができません。このため、コロケーションの制約を作成する場合は、リソース A をリソース B に対してコロケーションを設定するのか、もしくはリソース B をリソース A に対してコロケーションを設定するのかを考慮する必要があります。

また、コロケーションの制約を作成する際に注意しておきたいもう 1 つの点として、リソース A をリソース B に対してコロケーションを設定すると仮定した場合は、クラスターがリソース B に選択するノードを決定する際に、リソース A の優先度も考慮に入れます。

次のコマンドはコロケーションの制約を作成します。

pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]

表13.1「コロケーション制約のプロパティー」は、コロケーション制約を設定するのに使用するプロパティーおよびオプションをまとめています。

表13.1 コロケーション制約のプロパティー

フィールド説明

source_resource

コロケーションソース。制約の条件を満たさない場合、クラスターではこのリソースの実行を許可しないことを決定する可能性があります。

target_resource

コロケーションターゲット。クラスターは、このリソースの配置先を決定してから、ソースリソースの配置先を決定します。

score

正の値を指定するとリソースが同じノードで実行します。負の値を指定すると同じノードで実行しなくなります。デフォルト値である +INFINITY を指定すると、source_resource は必ず target_resource と同じノードで実行します。-INFINITY は、source_resourcetarget_resource と同じノードで実行してはならないことを示しています。

13.1. リソースの強制的な配置の指定

制約スコアが +INFINITY または -INFINITY の場合は常に強制的な配置が発生します。制約条件が満たされないと source_resource の実行が許可されません。score=INFINITY には、target_resource がアクティブではないケースも含まれます。

myresource1 を、常に myresource2 と同じマシンで実行する必要がある場合は、次のような制約を追加します。

# pcs constraint colocation add myresource1 with myresource2 score=INFINITY

INFINITY を使用しているため、(何らかの理由で) myresource2 がクラスターのいずれのノードでも実行できない場合は、myresource1 の実行が許可されません。

または、逆の設定、つまり myresource1myresource2 と同じマシンでは実行されないようにクラスターを設定することもできます。この場合は score=-INFINITY を使用します。

# pcs constraint colocation add myresource1 with myresource2 score=-INFINITY

ここでも、-INFINITY を指定することで、制約は結合しています。このため、実行できる場所として残っているノードで myresource2 がすでに実行されている場合は、いずれのノードでも myresource1 を実行できなくなります。

13.2. リソースの勧告的な配置の指定

「必ず実行する (または必ず実行しない)」状況を「強制的な配置」とするならば、「勧告的な配置」は、ある状況下で優先される状況を指しています。制約のスコアが -INFINITY より大きく、INFINITY より小さい場合、クラスターはユーザーの希望を優先しようとしますが、クラスターリソースを一部停止することを希望する場合は無視します。

13.3. 複数リソースのコロケーション

コロケーションと順序が適用されるリソースのセットを作成する必要がある場合は、「リソースグループの設定」に従って、このようなリソースを含むリソースグループを設定できます。ただし、コロケーションを設定する必要があるリソースをリソースグループとして設定することが適切ではない場合もあります。

  • リソースのセットにコロケーションを設定する必要があるものの、リソースが必ずしも順番に起動する必要がない場合
  • リソース C を、リソース A またはリソース B のいずれかに対してコロケーションを設定する必要があるものの、リソース A とリソース B との間に関係が設定されていない場合
  • リソース C およびリソース D を、リソース A およびリソース B の両方に対してコロケーションを設定する必要があるものの、A と B の間、または C と D の間に関係が設定されていない場合

このような状況では、pcs constraint colocation set コマンドを使用して、リソースの 1 つまたは複数のセットでコロケーションの制約を作成できます。

pcs constraint colocation set コマンドを使用すると、リソースのセットに対して以下のオプションを設定できます。

  • sequential - セットのメンバーで相互のコロケーションが必要であるかどうかを指定します。true または false に設定できます。

    sequentialfalse に設定すると、このセットのメンバーがアクティブであるかどうかに関係なく、このセットのメンバーを、制約の中で、このセットの後にリストされている他のセットに対してコロケーションを設定できます。そのため、このオプションは制約でこのセットの後に他のセットが指定されている場合に限り有効です。他のセットが指定されていない場合は、制約の効果がありません。

  • role - StoppedStartedMaster、または Slave に設定できます。

pcs constraint colocation set コマンドの setoptions パラメーターの後に、リソースのセットに対する以下の制約オプションを設定できます。

  • id - 定義する制約の名前を指定します。
  • score - 制約の優先度を示します。このオプションの詳細は、「場所の制約オプション」を参照してください。

セットのメンバーをリストすると、各メンバーは、自身の前のメンバーに対してコロケーションが設定されます。たとえば、「set A B」は B が A の場所に配置されることを意味します。しかし、複数のセットをリストする場合、各セットはその後のメンバーと同じ場所に配置されます。たとえば、「set C D sequential=false set A B」は、C と D のセットが、A と B のセットと同じ場所に配置されることを意味します (ただし、C と D には関係がなく、B は A にはコロケーションが設定されています)。

以下のコマンドは、リソースのセットにコロケーションの制約を作成します。

pcs constraint colocation set resource1 resource2 [resourceN]... [options] [set resourceX resourceY ... [options]] [setoptions [constraint_options]]

13.4. コロケーション制約の削除

コロケーション制約を削除する場合は、source_resource を指定して、次のコマンドを使用します。

pcs constraint colocation remove source_resource target_resource

第14章 リソース制約の表示

設定した制約を表示させるコマンドがいくつかあります。

14.1. 設定済みの全制約の表示

以下のコマンドは、現在の場所、順序、ロケーションの制約をすべて表示します。--full オプションを指定すると、制約の内部 ID が表示されます。

pcs constraint [list|show] [--full]

RHEL 8.2 の時点では、リソース制約をデフォルトで一覧表示すると、期限切れの制約が表示されなくなりました。期限切れな制約を含めるには、pcs constraint コマンドの --all オプションを使用します。これにより、期限切れの制約の一覧が表示され、制約とそれに関連するルールが (expired) として表示されます。

14.2. 場所の制約の表示

以下のコマンドは、現在の場所の制約を一覧表示します。

  • resources を指定すると、リソース別に場所の制約が表示されます。これはデフォルトの動作です。
  • nodes を指定すると、ノード別に場所の制約が表示されます。
  • 特定のリソースまたはノードを指定すると、そのリソースまたはノードの情報のみが表示されます。
pcs constraint location [show [resources [resource...]] | [nodes [node...]]] [--full]

14.3. 順序の制約の表示

以下のコマンドは、現在の順序の制約をすべて表示します。

pcs constraint order [show]

14.4. コロケーション制約の表示

次のコマンドは、現在のコロケーション制約を一覧表示します。

pcs constraint colocation [show]

14.5. リソース固有の制約の表示

以下のコマンドは、特定リソースを参照する制約を一覧表示します。

pcs constraint ref resource ...

14.6. リソース依存関係の表示 (Red Hat Enterprise Linux 8.2 以降)

次のコマンドは、クラスターリソース間の関係をツリー構造で表示します。

pcs resource relations resource [--full]

--full オプションを指定すると、制約 ID およびリソースタイプを含む追加情報が表示されます。

以下の例では、C、D、および E の 3 つのリソースが設定されています。

# pcs constraint order start C then start D
Adding C D (kind: Mandatory) (Options: first-action=start then-action=start)
# pcs constraint order start D then start E
Adding D E (kind: Mandatory) (Options: first-action=start then-action=start)

# pcs resource relations C
C
`- order
   |  start C then start D
   `- D
      `- order
         |  start D then start E
         `- E
# pcs resource relations D
D
|- order
|  |  start C then start D
|  `- C
`- order
   |  start D then start E
   `- E
# pcs resource relations E
E
`- order
   |  start D then start E
   `- D
      `- order
         |  start C then start D
         `- C

以下の例では、A および B のリソースが 2 つ設定されています。リソース A および B はリソースグループ G の一部です。

# pcs resource relations A
A
`- outer resource
   `- G
      `- inner resource(s)
         |  members: A B
         `- B
# pcs resource relations B
B
`- outer resource
   `- G
      `- inner resource(s)
         |  members: A B
         `- A
# pcs resource relations G
G
`- inner resource(s)
   |  members: A B
   |- A
   `- B

第15章 ルールによるリソースの場所の決定

さらに複雑な場所の制約には、Pacemaker のルールを使用してリソースの場所を決定できます。

15.1. Pacemaker ルール

ルールは、設定をより動的にするのに使用できます。ルールには、(ノード属性を使用して) 時間ベースで異なる処理グループにマシンを割り当て、場所の制約の作成時にその属性を使用する方法があります。

各ルールには、日付などの様々な式だけでなく、その他のルールも含めることができます。ルールの boolean-op フィールドに応じて各種の式の結果が組み合わされ、最終的にそのルールが true または false のどちらに評価されるかどうかが決まります。次の動作は、ルールが使用される状況に応じて異なります。

表15.1 ルールのプロパティー

フィールド説明

role

リソースが指定のロールにある場合にのみ適用するルールを制限します。使用できる値は StartedSlave、および Master です。注意: role="Master" が指定されたルールは、クローンインスタンスの最初の場所を判断できません。どのアクティブインスタンスが昇格されるかにのみ影響します。

score

ルールが true に評価される場合に適用されるスコア。場所の制約として、ルールでの使用に制限されます。

score-attribute

ルールが true に評価されると検索し、スコアとして使用するノード属性。場所の制約として、ルールでの使用に制限されます。

boolean-op

複数の式オブジェクトからの結果を組み合わせる方法。使用できる値は and および or です。デフォルト値は and です。

15.1.1. ノード属性の式

ノードで定義される属性に応じてリソースを制御する場合に使用されるノード属性の式です。

表15.2 式のプロパティー

フィールド説明

attribute

テストするノード属性。

type

値をテストする方法を指定します。使用できる値は、stringintegerversion です。デフォルト値は string です。

operation

実行する比較動作。使用できる値は以下のようになります。

* lt - ノード属性の値が value 未満の場合は True

* gt - ノード属性の値が value を超える場合は True

* lte - ノード属性の値が value 未満または同等になる場合は True

* gte - ノード属性の値が value を超えるか、または同等になる場合は True

* eq - ノード属性の値が value と同等になる場合に True

* ne - ノード属性の値が value と同等にならない場合は True

* defined - ノードに指定属性がある場合は True

* not_defined - ノードに指定属性がない場合は True

value

比較のためにユーザーが提供した値 (operationdefined または not_defined に設定されていない場合に限り必要)

管理者が追加する属性のほかに、表15.3「組み込みノード属性」で説明されているように、クラスターは、使用可能な各ノードに特殊な組み込みノード属性を定義します。

表15.3 組み込みノード属性

名前説明

#uname

ノード名

#id

ノード ID

#kind

ノードタイプ。使用できる値は、clusterremote、および container です。kind の値は、ocf:pacemaker:remote リソースで作成された Pacemaker リモートノードの remote、および Pacemaker リモートゲストノードおよびバンドルノードの container です。

#is_dc

このノードが指定コントローラー (DC) の場合は true、それ以外の場合は false

#cluster_name

cluster-name クラスタープロパティーの値 (設定されている場合)。

#site_name

site-name ノード属性の値 (設定されている場合)。それ以外は #cluster-name と同じ。

#role

関連する昇格可能なクローンがこのノードで果たす役割。昇格可能なクローンに対する場所の制約のルール内でのみ有効です。

15.1.2. 時刻と日付ベースの式

日付の式は、現在の日付と時刻に応じてリソースまたはクラスターオプションを制御する場合に使用します。オプションで日付の詳細を含めることができます。

表15.4 日付の式のプロパティー

フィールド説明

start

ISO 8601 仕様に準じた日付と時刻。

end

ISO 8601 仕様に準じた日付と時刻。

operation

状況に応じて、現在の日付と時刻を start と end のいずれかの日付、または両方の日付と比較します。使用できる値は以下のようになります。

* gt - 現在の日付と時刻が start 以降の場合は True

* lt - 現在の日付と時刻が end 以前の場合は True

* in_range - 現在の日付と時刻が start 以降、かつ end 以前の場合は True

* date-spec - 現在の日付/時刻に対して cron のような比較を実行します。

15.1.3. 日付の詳細

日付の詳細は、時間に関係する cron のような式を作成するのに使用されます。各フィールドには 1 つの数字または範囲が含まれます。指定のないフィールドは、デフォルトを 0 に設定するのではなく、無視されます。

たとえば、monthdays="1" は各月の最初の日と一致し、hours="09-17" は午前 9 時から午後 5 時まで (両時間を含む) の時間と一致します。ただし、weekdays="1,2" または weekdays="1-2,5-6" には複数の範囲が含まれるため、指定することはできません。

表15.5 日付詳細のプロパティー

フィールド説明

id

日付の一意の名前

hours

使用できる値 - 0~23

monthdays

使用できる値 - 0~31(月と年に応じて異なる)

weekdays

使用できる値 - 1~7 (1=月曜日、7=日曜日)

yeardays

使用できる値 - 1~366 (年に応じて異なる)

months

使用できる値 - 1~12

weeks

使用できる値 - 1~53 (weekyear に応じて異なる)

years

グレゴリオ暦 (新暦) に準じる年

weekyears

グレゴリオ暦の年とは異なる場合がある (例: 2005-001 Ordinal2005-01-01 Gregorian であり 2004-W53-6 Weekly でもある)

moon

使用できる値 - 0~7 (0 は新月、4 は満月)

15.2. ルールを使用した Pacemaker の場所の制約の設定

以下のコマンドを使用して、ルールを使用する Pacemaker 制約を使用します。score を省略すると、デフォルトの INFINITY に設定されます。resource-discovery を省略すると、デフォルトの always に設定されます。

resource-discovery オプションの詳細は、「ノードのサブセットへリソース検出の制限」を参照してください。

基本的な場所の制約と同様に、制約にリソースの正規表現を使用することもできます。

ルールを使用して場所の制約を設定する場合は、score を正または負の値にすることができます。正の値は「prefers」を示し、負の値は「avoids」を示します。

pcs constraint location rsc rule [resource-discovery=option] [role=master|slave] [score=score | score-attribute=attribute] expression

expression オプションは、duration_options および date_spec_options のいずれかに設定できます。使用できる値は、「日付詳細のプロパティー」で説明されているように、hours、monthdays、weekdays、yeardays、months、weeks、years、weekyears、moon になります。

  • defined|not_defined attribute
  • attribute lt|gt|lte|gte|eq|ne [string|integer|version] value
  • date gt|lt date
  • date in_range date to date
  • date in_range date to duration duration_options …​
  • date-spec date_spec_options
  • expression and|or expression
  • (expression)

持続時間は、計算により in_range 操作の終了を指定する代替方法です。たとえば、19 カ月間を期間として指定できます。

以下の場所の制約は、現在が 2018 年の任意の時点である場合に true の式を設定します。

# pcs constraint location Webserver rule score=INFINITY date-spec years=2018

以下のコマンドは、月曜日から金曜日までの 9 am から 5 pm までが true となる式を設定します。hours の値 16 には、時間 (hour) の値が一致する 16:59:59 までが含まれます。

# pcs constraint location Webserver rule score=INFINITY date-spec hours="9-16" weekdays="1-5"

以下のコマンドは、13 日の金曜日が満月になると true になる式を設定します。

# pcs constraint location Webserver rule date-spec weekdays=5 monthdays=13 moon=4

ルールを削除するには、以下のコマンドを使用します。削除しているルールがその制約内で最後のルールになる場合は、その制約も削除されます。

pcs constraint rule remove rule_id

第16章 クラスターリソースの管理

本セクションでは、クラスターリソースを管理するのに使用できる様々なコマンドを説明します。

16.1. 設定されているリソースの表示

設定されているリソースの一覧を表示する場合は、次のコマンドを使用します。

pcs resource status

たとえば、システムを設定していたリソースの名前が VirtualIPWebSite の場合は、pcs resource show コマンドを実行すると次のような出力が得られます。

# pcs resource status
 VirtualIP	(ocf::heartbeat:IPaddr2):	Started
 WebSite	(ocf::heartbeat:apache):	Started

設定したリソースの一覧と、そのリソースに設定したパラメーターを表示する場合は、以下のように、pcs resource config コマンドの --full オプションを使用します。

# pcs resource config
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s
 Resource: WebSite (type=apache class=ocf provider=heartbeat)
  Attributes: statusurl=http://localhost/server-status configfile=/etc/httpd/conf/httpd.conf
  Operations: monitor interval=1min

リソースに設定されているパラメーターを表示する場合は、次のコマンドを使用します。

pcs resource config resource_id

たとえば、次のコマンドは、現在設定されているリソース VirtualIP のパラメーターを表示します。

# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s

16.2. リソースパラメーターの修正

設定されているリソースのパラメーターを変更する場合は、次のコマンドを使用します。

pcs resource update resource_id [resource_options]

以下のコマンドシーケンスでは、VirtualIP リソースに設定したパラメーターの初期値、ip パラメーターの値を変更するコマンド、変更されたパラメーター値を示しています。

# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.168.0.120 cidr_netmask=24
  Operations: monitor interval=30s
# pcs resource update VirtualIP ip=192.169.0.120
# pcs resource config VirtualIP
 Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat)
  Attributes: ip=192.169.0.120 cidr_netmask=24
  Operations: monitor interval=30s
注記

pcs resource update コマンドを使用してリソースの動作を更新すると、特に呼び出しのないオプションはデフォルト値にリセットされます。

16.3. クラスターリソースの障害ステータスの解除

リソースに障害が発生すると、クラスターの状態を表示するときに障害メッセージが表示されます。このリソースを解決する場合は、pcs resource cleanup コマンドで障害状態を消去できます。このコマンドはリソースの状態と failcount をリセットし、リソースの動作履歴を消去して現在の状態を再検出するようにクラスターに指示します。

次のコマンドは、resource_id で指定したリソースをクリーンアップします。

pcs resource cleanup resource_id

resource_id を指定しないと、このコマンドは、全リソースのリソース状態と failcount をリセットします。

pcs resource cleanup コマンドは、失敗したアクションとして表示されるリソースのみを検証します。全ノードの全リソースを調査するには、次のコマンドを入力します。

pcs resource refresh

デフォルトでは、pcs resource refresh コマンドは、リソースのステータスが分かっているノードだけを検証します。ステータスが分からないすべてのリソースを検証するには、以下のコマンドを実行します。

pcs resource refresh --full

16.4. クラスター内のリソースの移動

Pacemaker は、リソースを別のノードに移動するように設定し、必要に応じて手動でリソースを移動するように設定する様々なメカニズムを提供します。

「クラスターリソースの手動による移動」に従って、pcs resource move コマンドと pcs resource relocate コマンドで、クラスターのリソースを手動で移動します。

このコマンドの他にも、「クラスターリソースの有効化、無効化、および禁止」に従ってリソースを有効、無効、および禁止にすることで、クラスターリソースの挙動を制御することもできます。

失敗した回数が、定義した値を超えると、新しいノードに移動し、外部接続が失われた時にリソースを移動するようにクラスターを設定できます。

16.4.1. 障害発生によるリソースの移動

リソースの作成時に、リソースに migration-threshold オプションを設定し、定義した回数だけ障害が発生した場合にリソースが新しいノードに移動されるように設定できます。このしきい値に一度到達すると、このノードでは、以下が行われるまで、障害が発生したリソースを実行できなくなります。

  • 管理者が pcs resource cleanup コマンドを使用して、リソースの failcount を手動でリセットします。
  • リソースの failure-timeout 値に到達します。

デフォルトで、migration-threshold の値が INFINITY に設定されています。INFINITY は、内部的に非常に大きな有限数として定義されます。0 にすると、migration-threshold 機能が無効になります。

注記

リソースの migration-threshold を設定するのと、リソースの状態を維持しながら別の場所に移動させるようにリソースの移動を設定するのは同じではありません。

次の例では、dummy_resource リソースに、移行しきい値 10 を追加します。この場合は、障害が 10 回発生すると、そのリソースが新しいノードに移動します。

# pcs resource meta dummy_resource migration-threshold=10

次のコマンドを使用すると、クラスター全体にデフォルトの移行しきい値を追加できます。

# pcs resource defaults migration-threshold=10

リソースの現在の障害ステータスと制限を確認するには、pcs resource failcount show コマンドを使用します。

移行しきい値の概念には、「リソース起動の失敗」と「リソース停止の失敗」の 2 つの例外があります。クラスタープロパティー start-failure-is-fataltrue に設定された場合 (デフォルト) は、起動の失敗により failcountINFINITY に設定され、リソースが常に即座に移動するようになります。

停止時の失敗は、起動時とは若干異なり、極めて重大となります。リソースの停止に失敗し STONITH が有効になっていると、リソースを別のノードで起動できるように、クラスターによるノードのフェンスが行われます。STONITH を有効にしていない場合はクラスターに続行する手段がないため、別のノードでのリソース起動は試行されません。ただし、障害のタイムアウト後に再度停止が試行されます。

16.4.2. 接続状態の変更によるリソースの移動

以下の 2 つのステップに従って、外部の接続が失われた場合にリソースが移動するようにクラスターを設定します。

  1. ping リソースをクラスターに追加します。ping リソースは、同じ名前のシステムユーティリティーを使用して、マシン (DNS ホスト名または IPv4/IPv6 アドレスによって指定される一覧) にアクセス可能であるかをテストし、その結果を使用して pingd と呼ばれるノード属性を維持します。
  2. 接続が失われたときに別のノードにリソースを移動させる、リソース場所制約を設定します。

表10.1「リソースエージェント識別子」には、ping リソースに設定できるプロパティーを示します。

表16.1 ping リソースのプロパティー

フィールド説明

dampen

今後の変更が発生するまでに待機する (弱める) 時間。これにより、クラスターノードが、わずかに異なる時間に接続が失われたことに気が付いたときに、クラスターでリソースがバウンスするのを防ぎます。

multiplier

接続された ping ノードの数は、ノードの数にこの値を掛けて、スコアを取得します。複数の ping ノードが設定された場合に便利です。

host_list

現在の接続状態を判断するために接続するマシン。使用できる値には、解決可能な DNS ホスト名、IPv4 アドレス、および IPv6 アドレスが含まれます。ホストリストのエントリーはスペースで区切られます。

次のコマンド例は、gateway.example.com への接続を検証する ping リソースを作成します。実際には、ネットワークゲートウェイやルーターへの接続を検証します。リソースがすべてのクラスターノードで実行されるように、ping リソースをクローンとして設定します。

# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone

以下の例は、既存のリソース Webserver に場所制約ルールを設定します。これにより、Webserver リソースが現在実行しているホストが gateway.example.com へ ping できない場合に、Webserver リソースを gateway.example.com へ ping できるホストに移動します。

# pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
 Module included in the following assemblies:
//
// <List assemblies here, each on a new line>
// rhel-8-docs/enterprise/assemblies/assembly_managing-cluster-resources.adoc

16.5. 監視操作の無効化

定期的な監視を停止する最も簡単な方法は、監視を削除することです。ただし、一時的に無効にしたい場合もあります。このような場合は、操作の定義に enabled="false" を追加します。監視操作を再度有効にするには、操作の定義に enabled="true" を設定します。

pcs resource update コマンドを使用してリソースの動作を更新すると、特に呼び出しのないオプションはデフォルト値にリセットされます。たとえば、カスタムのタイムアウト値 600 を使用して監視操作を設定している場合に以下のコマンドを実行すると、タイムアウト値がデフォルト値の 20 にリセットされます (pcs resource ops default コマンドを使用しても、デフォルト値を設定できます)。

# pcs resource update resourceXZY op monitor enabled=false
# pcs resource update resourceXZY op monitor enabled=true

このオプションの元の値 600 を維持するために、監視操作に戻す場合は、以下の例のように、その値を指定する必要があります。

# pcs resource update resourceXZY op monitor timeout=600 enabled=true

第17章 複数のノードでアクティブなクラスターリソース (クローンリソース) の作成

クラスターリソースが複数のノードでアクティブになるように、リソースのクローンを作成できます。たとえば、ノードの分散のために、クローンとなるリソースを使用して、クラスター全体に分散させる IP リソースのインスタンスを複数構成できます。リソースエージェントが対応していれば、任意のリソースのクローンを作成できます。クローンは、1 つのリソースまたは 1 つのリソースグループで構成されます。

注記

同時に複数のノードでアクティブにできるリソースのみがクローンに適しています。たとえば、共有メモリーデバイスから ext4 などの非クラスター化ファイルシステムをマウントする Filesystem リソースのクローンは作成しないでください。ext4 パーティションはクラスターを認識しないため、同時に複数のノードから繰り返し行われる読み取りや書き込みの操作には適していません。

17.1. クローンリソースの作成および削除

リソースの作成と、そのリソースのクローン作成を同時に行う場合は、次のコマンドを使用します。

pcs resource create resource_id [standard:[provider:]]type [resource options] [meta resource meta options] clone [clone options]

クローンの名前は resource_id-clone となります。

1 つのコマンドで、リソースグループの作成と、リソースグループのクローン作成の両方を行うことはできません。

作成済みリソースまたはリソースグループのクローンを作成する場合は、次のコマンドを実行します。

pcs resource clone resource_id | group_name [clone options]...

クローンの名前は、resource_id-clone または group_name-clone となります。

注記

リソース設定の変更が必要なのは、1 つのノードのみです。

注記

制約を設定する場合は、グループ名またはクローン名を必ず使用します。

リソースのクローンを作成すると、そのクローンの名前は、リソース名に -clone を付けた名前になります。次のコマンドは、タイプが apache のリソース webfarm と、そのクローンとなるリソース webfarm-clone を作成します。

# pcs resource create webfarm apache clone
注記

あるリソースまたはリソースグループのクローンを、別のクローンの後にくるように作成する場合は、多くの場合 interleave=true オプションを設定する必要があります。これにより、依存されているクローンが同じノードで停止または開始した時に、依存しているクローンのコピーを停止または開始できるようになります。このオプションを設定しない場合は、次のようになります。クローンリソース B がクローンリソース A に依存していると、ノードがクラスターから離れてから戻ってきてから、そのノードでリソース A が起動すると、リソース B の全コピーが、全ノードで再起動します。これは、依存しているクローンリソースに interleave オプションが設定されていない場合は、そのリソースの全インスタンスが、そのリソースが依存しているリソースの実行インスタンスに依存するためです。

リソースまたはリソースグループのクローンを削除する場合は、次のコマンドを使用します。リソースやリソースグループ自体は削除されません。

pcs resource unclone resource_id | group_name

表17.1「リソースのクローンオプション」には、クローンのリソースに指定できるオプションを示します。

表17.1 リソースのクローンオプション

フィールド説明

priority, target-role, is-managed

表10.3「リソースのメタオプション」に従って、クローンされたリソースから継承されるオプション。

clone-max

起動するリソースのコピーの数。デフォルトは、クラスター内のノード数です。

clone-node-max

1 つのノードで起動できるリソースのコピー数。デフォルト値は 1 です。

notify

クローンのコピーを停止したり起動する時に、前もって、およびアクションが成功した時に、他のコピーに通知します。使用できる値は false および true です。デフォルト値は false です。

globally-unique

クローンの各コピーで異なる機能を実行させるかどうか。使用できる値は false および true です。

このオプションの値を false にすると、リソースが実行しているすべてのノードで同じ動作を行うため、1 台のマシンごとに実行できるクローンのコピーは 1 つです。

このオプションの値を true にすると、任意のマシンで実行中のクローンのコピーが、別のインスタンスが別のノードまたは同じノードで実行されているかに関係なく、そのインスタンスと同等ではありません。clone-node-max の値が「1」より大きい場合にはデフォルト値が true になり、小さい場合は false がデフォルト値になります。

ordered

コピーを、(並列ではなく) 連続して開始する必要があります。使用できる値は false および true です。デフォルト値は false です。

interleave

(クローン間の) 順序制約の動作を変更して、(2 番目のクローンの全インスタンスが終了するまで待機する代わりに) 2 番目のクローンと同じノードにあるコピーが起動または停止するとすぐに、最初のクローンのコピーが起動または停止できるようにします。使用できる値は false および true です。デフォルト値は false です。

clone-min

このフィールドに値を指定した場合は、interleave オプションが true に設定されていても、元のクローンの後に順序付けされたクローンは、元のクローンに指定された数だけインスタンスが実行するまで、起動できません。

安定した割り当てパターンを実現するために、クローンは、デフォルトでわずかに固定 (sticky) されています。これは、クローンが実行しているノードにとどまることをわずかに優先することを示します。resource-stickiness の値を指定しないと、クローンが使用する値は 1 となります。値を小さくすることで他のリソースのスコア計算への阻害を最小限に抑えながら、Pacemaker によるクラスター内の不要なコピーの移動を阻止することができます。resource-stickiness リソースのメタオプションを設定する方法は、「リソースのメタオプションの設定」を参照してください。

17.2. クローンリソース制約の表示

ほとんどの場合、アクティブなクラスターノードに対するクローンのコピーは 1 つです。ただし、リソースクローンの clone-max には、そのクラスター内のノード合計より小さい数を設定できます。この場合は、リソースの場所の制約を使用して、クラスターが優先的にコピーを割り当てるノードを指定できます。これらの制約は、クローンの ID を使用する必要があることを除いて、通常のリソースの制約と同じように記述されます。

次のコマンドは、クラスターがリソースのクローン webfarm-clonenode1 に優先的に割り当てる場所の制約を作成します。

# pcs constraint location webfarm-clone prefers node1

順序制約の動作はクローンでは若干異なります。以下の例では、interleave クローンオプションをデフォルトの false のままにしているため、起動する必要がある webfarm-clone のすべてのインスタンスが起動するまで、webfarm-stats のインスタンスは起動しません。webfarm-clone のコピーを 1 つも起動できない場合にのみ、webfarm-stats がアクティブになりません。さらに、webfarm-stats が停止するまで待機してから、webfarm-clone が停止します。

# pcs constraint order start webfarm-clone then webfarm-stats

通常のリソース (またはリソースグループ) とクローンのコロケーションは、リソースを、クローンのアクティブコピーを持つ任意のマシンで実行できることを意味します。クラスターは、クローンが実行している場所と、リソース自体の場所の優先度に基づいてコピーを選択します。

クローン間のコロケーションも可能です。この場合、クローンに対して許可できる場所は、そのクローンが実行中のノード (または実行するノード) に限定されます。割り当ては通常通り行われます。

以下のコマンドは、コロケーション制約を作成し、webfarm-stats リソースが webfarm-clone のアクティブなコピーと同じノードで実行するようにします。

# pcs constraint colocation add webfarm-stats with webfarm-clone

17.3. 昇格可能なクローンリソースの作成

昇格可能なクローンリソースは、promotable メタ属性が true に設定されているクローンリソースです。昇格可能なクローンリソースにより、インスタンスの操作モードは、Master および Slave のいずれかにできます。モードの名前には特別な意味はありませんが、インスタンスの起動時に、Slave 状態で起動する必要があるという制限があります。

17.3.1. 昇格可能なリソースの作成

次のコマンドを実行すると、リソースを昇格可能なクローンとして作成できます。

pcs resource create resource_id [standard:[provider:]]type [resource options] promotable [clone options]

昇格可能なクローンの名前は resource_id-clone となります。

また、次のコマンドを使用して、作成済みのリソースまたはリソースグループから、昇格可能なリソースを作成することもできます。昇格可能なクローンの名前は、resource_id-clone または group_name-clone になります。

pcs resource promotable resource_id [clone options]

表17.2「昇格可能なクローンに利用できる追加のクローンオプション」には、昇格可能なリソースに指定できる追加クローンオプションを示します。

表17.2 昇格可能なクローンに利用できる追加のクローンオプション

フィールド説明

promoted-max

昇格できるリソースのコピー数。デフォルト値は 1 です。

promoted-node-max

1 つのノードで昇格できるリソースのコピー数。デフォルト値は 1 です。

17.3.2. 昇格可能なリソース制約の表示

ほとんどの場合、昇格可能なリソースには、アクティブなクラスターノードごとに 1 つのコピーがあります。そうではない場合は、リソースの場所制約を使用して、クラスターが優先的にコピーを割り当てるノードを指定できます。これらの制約は、通常のリソースと同様に記述されます。

リソースのロールをマスターにするかスレーブにするかを指定するコロケーション制約を作成できます。次のコマンドは、リソースのコロケーション制約を作成します。

pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [score] [options]

コロケーションの制約を設定する方法は、「クラスターリソースのコロケーション」を参照してください。

昇格可能なリソースが含まれる順序制約を設定する場合に、リソースに指定できるアクションに、リソースのスレーブロールからマスターへのロールの昇格を指定する promote があります。また、demote を指定すると、マスターからスレーブにリソースを降格できます。

順序制約を設定するコマンドは次のようになります。

pcs constraint order [action] resource_id then [action] resource_id [options]

リソースの順序制約の詳細は、「クラスターリソースの実行順序の決定」を参照してください。

第18章 クラスターノードの管理

次のセクションでは、クラスターサービスの起動や停止、クラスターノードの追加や削除など、クラスターノードの管理で使用するコマンドを説明します。

18.1. クラスターサービスの停止

次のコマンドで、指定ノード (複数指定可) のクラスターサービスを停止します。pcs cluster start と同様、--all オプションを使用すると、全ノードのクラスターサービスが停止します。ノードを指定しないと、ローカルノードのクラスターサービスのみが停止します。

pcs cluster stop [--all | node] [...]

次のコマンドで、ローカルノードのクラスターサービスを強制的に停止できます。このコマンドは、kill -9 コマンドを実行します。

pcs cluster kill

18.2. クラスターサービスの有効化および無効化

次のコマンドを使用して、クラスターサービスを有効にします。これにより、指定した 1 つまたは複数のノードで、システムの起動時にクラスターサービスが実行するように設定されます。ノードがフェンスされた後にクラスターに自動的に再参加するようになり、クラスターが最大強度を下回る時間が最小限に抑えられます。クラスターサービスを有効にしていないと、クラスターサービスを手動で開始する前に、管理者が問題を調査できます。これにより、たとえばハードウェアに問題があるノードで再度問題が発生する可能性がある場合は、クラスターに戻さないようにできます。

  • --all オプションを使用すると、全ノードでクラスターサービスが有効になります。
  • ノードを指定しないと、ローカルノードでのみクラスターサービスが有効になります。
pcs cluster enable [--all | node] [...]

指定した 1 つまたは複数のノードの起動時に、クラスターサービスが実行されないよう設定する場合は、次のコマンドを使用します。

  • --all オプションを指定すると、全ノードでクラスターサービスが無効になります。
  • ノードを指定しないと、ローカルノードでのみクラスターサービスが無効になります。
pcs cluster disable [--all | node] [...]

18.3. クラスターノードの追加

注記

運用保守期間中に、既存のクラスターにノードを追加することが強く推奨されます。これにより、新しいノードとそのフェンシング設定に対して、適切なリソースとデプロイメントのテストを実行できます。

既存クラスターに新しいノードを追加する場合は、以下の手順に従ってください。この手順は、corosync を実行している標準クラスターを追加します。corosync 以外のノードをクラスターに統合する方法は「corosync 以外のノードのクラスターへの統合: pacemaker_remote サービス」を参照してください。

この例では、clusternode-01.example.comclusternode-02.example.com、および clusternode-03.example.com が既存のクラスターノードになります。新たに追加するノードは newnode.example.com になります。

クラスターに追加する新しいノードで、以下の作業を行います。

  1. クラスターパッケージをインストールします。クラスターで SBD、Booth チケットマネージャー、またはクォーラムデバイスを使用する場合は、対応するパッケージ (sbdbooth-sitecorosync-qdevice) を、新しいノードにも手動でインストールする必要があります。

    [root@newnode ~]# yum install -y pcs fence-agents-all

    クラスターパッケージに加えて、既存のクラスターノードにインストールしたクラスターで実行しているすべてのサービスをインストールおよび構成する必要があります。たとえば、Red Hat の高可用性クラスターで Apache HTTP サーバーを実行している場合は、追加するノードにサーバーをインストールする必要があります。また、サーバーのステータスを確認する wget ツールも必要です。

  2. firewalld デーモンを実行している場合は、次のコマンドを実行して、Red Hat High Availability Add-On で必要なポートを有効にします。

    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --add-service=high-availability
  3. ユーザー ID hacluster のパスワードを設定します。クラスターの各ノードで、同じパスワードを使用することが推奨されます。

    [root@newnode ~]# passwd hacluster
    Changing password for user hacluster.
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.
  4. 次のコマンドを実行して pcsd サービスを開始し、システムの起動時に pcsd が有効になるようにします。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service

既存クラスターのノードの 1 つで、以下の作業を行います。

  1. 新しいクラスターノードで hacluster ユーザーを認証します。

    [root@clusternode-01 ~]# pcs host auth newnode.example.com
    Username: hacluster
    Password:
    newnode.example.com: Authorized
  2. 新しいノードを既存のクラスターに追加します。さらに、このコマンドは corosync.conf クラスター設定ファイルを、クラスターのすべてのノード (追加する新しいノードを含む) に同期させます。

    [root@clusternode-01 ~]# pcs cluster node add newnode.example.com

クラスターに追加する新しいノードで、以下の作業を行います。

  1. 新しいノードで、クラスターサービスを開始して有効にします。

    [root@newnode ~]# pcs cluster start
    Starting Cluster...
    [root@newnode ~]# pcs cluster enable
  2. 新しいクラスターノードに対して、フェンシングデバイスを設定してテストします。

18.4. クラスターノードの削除

次のコマンドは、指定したノードをシャットダウンして、クラスター内のその他のすべてのノードで、クラスターの設定ファイル corosync.conf からそのノードを削除します。

pcs cluster node remove node

18.5. 複数のリンクを持つクラスターへのノードの追加

複数のリンクを持つクラスターにノードを追加する場合は、すべてのリンクにアドレスを指定する必要があります。以下の例では、ノード rh80-node3 をクラスターに追加し、最初のリンクに IP アドレス 192.168.122.203 を指定し、192.168.123.203 を次のリンクとして指定します。

# pcs cluster node add rh80-node3 addr=192.168.122.203 addr=192.168.123.203

第19章 Pacemaker クラスターにユーザーパーミッションの設定

hacluster ユーザー以外の特定のユーザーに、Pacemaker クラスターを管理するパーミッションを付与できます。個々のユーザーに付与できるパーミッションには、以下の 2 つのセットがあります。

  • 個々のユーザーが Web UI を介してクラスターを管理し、ネットワーク経由でノードに接続する pcs コマンドを実行できるパーミッション。ネットワーク経由でノードに接続するコマンドには、クラスターを設定するコマンド、またはクラスターからノードを追加または削除するためのコマンドが含まれます。
  • クラスター設定の読み取り専用アクセスまたは読み書きアクセスを許可するためのローカルユーザーのパーミッションです。ネットワーク経由で接続する必要のないコマンドには、リソースの作成や制約の設定など、クラスター構成を編集するコマンドが含まれます。

両方のパーミッションセットが割り当てられている状況では、ネットワーク経由で接続するコマンドのパーミッションが最初に適用され、次にローカルノードのクラスター構成を編集するパーミッションが適用されます。ほとんどの pcs コマンドでは、ネットワークアクセスは必要ありません。その場合は、ネットワークパーミッションが適用されません。

19.1. ネットワーク上でノードにアクセスするためのパーミッションの設定

特定のユーザーに、Web UI でクラスターを管理し、ネットワーク経由でノードに接続する pcs コマンドを実行するパーミッションを付与するには、パーミッションを付与するユーザーをグループ haclient に追加します。これはクラスター内のすべてのノードで行う必要があります。

19.2. ACL でローカルパーミッションの設定

pcs acl コマンドを使用して、ローカルユーザーにアクセス制御リスト (ACL) を使用してクラスター設定への読み取り専用アクセスまたは読み取り/書き込みアクセスを許可するパーミッションを設定できます。

デフォルトでは、ACL は有効になっていません。ACL が有効になっていないと、root ユーザーと、すべてのノードの haclient グループのメンバーであるユーザーには、クラスター設定へのローカルの読み取り/書き込みに関する完全なパーミッションが付与されます。一方、haclient グループのメンバーではないユーザーには、パーミッションが付与されません。ただし、ACL が有効になっている場合は、haclient グループのメンバーであっても、ACL からそのユーザーに付与されたものにしかアクセスできません。

ローカルユーザーのパーミッションを設定するには、以下の 2 つの手順を実行します。

  1. pcs acl role create…​ コマンドを実行して、そのロールのパーミッションを定義する ロール を作成します。
  2. pcs acl user create コマンドで、作成したロールをユーザーに割り当てます。複数のロールを同じユーザーに割り当てると、拒否 パーミッションが優先されてから、書き込み読み取り の順に適用されます。

以下の例では、rouser という名前のローカルユーザーに、クラスター設定に対する読み取り専用アクセスを提供します。設定の特定の部分のみにアクセスを制限することもできます。

警告

この手順を root として実行するか、すべての構成の更新を作業ファイルに保存して、完了したらアクティブな CIB にプッシュできるようにすることが重要です。それ以外の場合は、それ以上変更を加えられないようにすることができます。作業ファイルに設定の更新を保存する方法は「作業ファイルへの設定変更の保存」を参照してください。

  1. この手順では、rouser ユーザーがローカルシステムに存在し、rouser ユーザーが haclient グループのメンバーであることが必要です。

    # adduser rouser
    # usermod -a -G haclient rouser
  2. pcs acl enable コマンドを使用して、Pacemaker ACL を有効にします。

    # pcs acl enable
  3. cib に対して読み取り専用のパーミッションが付与されている read-only という名前のロールを作成します。

    # pcs acl role create read-only description="Read access to cluster" read xpath /cib
  4. pcs ACL システムで rouser ユーザーを作成し、そのユーザーに read-only ロールを割り当てます。

    # pcs acl user create rouser read-only
  5. 現在の ACL を表示します。

    # pcs acl
    User: rouser
      Roles: read-only
    Role: read-only
      Description: Read access to cluster
      Permission: read xpath /cib (read-only-read)

第20章 リソースの監視操作

リソースを健全な状態に保つために、リソースの定義に監視操作を追加できます。リソースの監視動作を指定しないと、デフォルトでは、pcs コマンドにより監視動作が作成されします。監視の間隔はリソースエージェントにより決定します。リソースエージェントでデフォルトの監視間隔が提供されない場合は、pcs コマンドにより 60 秒間隔の監視動作が作成されます。

表20.1「動作のプロパティー」に、リソースの監視動作のプロパティーを示します。

表20.1 動作のプロパティー

フィールド説明

id

動作の一意の名前。システムは、操作を設定する際に、これを割り当てます。

name

実行する動作。一般的な値は、monitorstartstop です。

interval

値をゼロ以外に設定すると、この周波数で繰り返される反復操作 (秒単位) が作成されます。ゼロ以外の値は、アクション monitor に設定されている場合に限り有効になります。監視の反復アクションは、リソースの起動が完了するとすぐに実行し、その後の監視アクションの開始は、前の監視アクションが完了した時点でスケジュールされます。たとえば、interval=20s の監視アクションを 01:00:00 に実行すると、次の監視アクションは 01:00:20 ではなく、最初の監視アクションが完了してから 20 秒後に発生します。

この値を、デフォルト値であるゼロに設定すると、このパラメーターで、クラスターが作成した操作に使用する値を指定できます。たとえば、interval をゼロに設定し、操作の namestartに設定し、timeout 値を 40 に設定すると、Pacemaker がこのリソースを開始する場合に 40 秒のタイムアウトを使用します。monitor 操作の間隔をゼロに設定した場合は、システムの起動時に Pacemaker が行うプローブの timeout/on-fail/enabled を設定して、デフォルトが望ましくない場合に、すべてのリソースの現在のステータスを取得できます。

timeout

このパラメーターで設定された時間内に操作が完了しないと、操作を中止し、失敗したと見なします。デフォルト値は、pcs resource op defaults コマンドで設定した場合は timeout 値、設定していない場合は 20 秒 です。システムで操作 (startstopmonitor など) の実行に許可されている時間よりも長い時間が必要なリソースがシステムに含まれている場合は、原因を調査して、実行時間が長いと予想される場合は、この値を増やすことができます。

timeout 値はいかなる遅延でもありません。また、タイムアウト期間が完了する前に操作が戻ると、クラスターはタイムアウト期間が終わる前に待機を終了します。

on-fail

この動作が失敗した場合に実行する動作。使用できる値は以下のようになります。

* ignore - リソースが失敗していなかったように振る舞う

* block - リソースでこれ以上、一切の操作を行わない

* stop - リソースを停止して別の場所で起動しない

* restart - リソースを停止して、(おそらく別の場所で) 再起動する

* fence - 失敗したリソースがあるノードを STONITH する

* standby - 失敗したリソースがあるノード上の すべて のリソースを移行する

STONITH が有効な場合、stop 動作のデフォルトは fence になります。そうでない場合は block となります。その他のすべての操作は、デフォルトで restart です。

enabled

falseの場合、操作は存在しないものとして処理されます。使用できる値は true または false です。

20.1. リソースの監視動作の設定

次のコマンドでリソースを作成すると、監視操作を設定できます。

pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options [operation_type operation_options]...]

たとえば、次のコマンドは、監視操作付きの IPaddr2 リソースを作成します。新しいリソースには VirtualIP という名前が付けられ、eth2 で IP アドレス 192.168.0.99、ネットマスク 24 になります。監視操作は、30 秒ごとに実施されます。

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2 op monitor interval=30s

また、次のコマンドで既存のリソースに監視操作を追加することもできます。

pcs resource op add resource_id operation_action [operation_properties]

設定されているリソース操作を削除する場合は、次のコマンドを使用します。

pcs resource op remove resource_id operation_name operation_properties
注記

操作プロパティーを正しく指定して、既存の操作を適切に削除する必要があります。

監視オプションの値を変更する場合は、リソースを更新します。たとえば、以下のコマンドで VirtualIP を作成できます。

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2

デフォルトでは、次の操作が作成されます。

Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
            stop interval=0s timeout=20s (VirtualIP-stop-timeout-20s)
            monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)

stop の timeout 操作を変更するには、以下のコマンドを実行します。

# pcs resource update VirtualIP op stop interval=0s timeout=40s

# pcs resource show VirtualIP
 Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
  Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
              monitor interval=10s timeout=20s (VirtualIP-monitor-interval-10s)
              stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

20.2. グローバルリソース操作のデフォルトの設定

次のコマンドを使用して、監視操作のグローバルデフォルト値を設定できます。

pcs resource op defaults [options]

たとえば、次のコマンドは、すべての監視操作に対して、timeout 値のグローバルデフォルトを 240 秒に設定します。

# pcs resource op defaults timeout=240s

監視操作に現在設定されているデフォルト値を表示する場合は、オプションを指定せずに pcs resource op defaults コマンドを実行します。

たとえば、以下のコマンドを実行すると、クラスター監視操作のデフォルト値を表示します。この例では、timeout 値が 240 秒に設定されています。

# pcs resource op defaults
timeout: 240s

クラスターリソース定義でオプションが指定されていない場合に限り、クラスターリソースがグローバルデフォルトを使用することに注意してください。デフォルトでは、リソースエージェントがすべての操作の timeout オプションを定義します。グローバル操作のタイムアウト値を有効にするには、timeout オプションを明示的に指定せずにクラスターリソースを作成するか、次のコマンドのように、クラスターリソースを更新して timeout オプションを削除する必要があります。

# pcs resource update VirtualIP op monitor interval=10s

たとえば、すべての監視操作に、グローバルデフォルトの timeout 値 240 秒を設定し、クラスターリソース VirtualIP を更新して、monitor 操作のタイムアウト値を削除すると、リソース VirtualIP には、startstop、および monitor の操作のタイムアウト値が、それぞれ 20 秒、40 秒、240 秒に設定されます。タイムアウト操作のグローバルなデフォルト値は、ここでは monitor にのみ適用されます。ここでは、前のコマンドにより、デフォルトの timeout オプションが削除されています。

# pcs resource show VirtualIP
 Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: ip=192.168.0.99 cidr_netmask=24 nic=eth2
   Operations: start interval=0s timeout=20s (VirtualIP-start-timeout-20s)
               monitor interval=10s (VirtualIP-monitor-interval-10s)
               stop interval=0s timeout=40s (VirtualIP-name-stop-interval-0s-timeout-40s)

20.3. 複数の監視操作の設定

リソースエージェントが対応する範囲で、1 つのリソースに複数の監視操作を設定できます。これにより、1 分ごとに表面的なヘルスチェックを行い、徐々に頻度を上げてより正確なチェックを行うこともできます。

注記

複数の監視操作を設定する場合は、2 種類の操作が同じ間隔で実行されないように注意してください。

様々なレベルで行う詳細なヘルスチェックに対応する追加の監視操作をリソースに設定する場合は、OCF_CHECK_LEVEL=n オプションを追加します。

たとえば、以下のように IPaddr2 リソースを設定すると、デフォルトでは 10 秒間隔でタイムアウト値が 20 秒の監視操作が作成されます。

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=24 nic=eth2

仮想 IP が、深さ 10 の様々なチェックに対応する場合は、次のコマンドを実行すると、Pacemaker は、通常の 10 秒間隔の仮想 IP チェックに加えて、60 秒ごとに高度な監視チェックを実行します。なお、上述のとおり、追加の監視操作は 10 秒間隔にしないようにしてください。

# pcs resource op add VirtualIP monitor interval=60s OCF_CHECK_LEVEL=10

第21章 Pacemaker クラスターのプロパティー

クラスターのプロパティーは、クラスター動作中に発生する可能性がある状況に直面した場合に、クラスターの動作を制御します。

21.1. クラスタープロパティーおよびオプションの要約

表21.1「クラスターのプロパティー」には、Pacemaker クラスターのプロパティーのデフォルト値や、設定可能な値などをまとめています。

フェンス動作を決定するクラスタープロパティーがあります。これらのプロパティーの詳細は、「高度なフェンス設定オプション」を参照してください。

注記

この表に記載しているプロパティー以外にも、クラスターソフトウェアで公開されるクラスタープロパティーがあります。このようなプロパティーでは、デフォルト値を別の値には変更しないことが推奨されます。

表21.1 クラスターのプロパティー

オプションデフォルト説明

batch-limit

0

クラスターを並列に実行できるリソースアクションの数。「正しい」値は、ネットワークおよびクラスタノードの速度と負荷によって異なります。デフォルト値の 0 は、任意のノードで CPU の負荷が高い場合に動的に制限を課すことを意味します。

migration-limit

-1 (無制限)

クラスターが、ノードで並行に実行することが許可されている移行ジョブの数。

no-quorum-policy

stop

クラスターにクォーラムがない場合のアクション。使用できる値は以下のようになります。

* ignore - 全リソースの管理を続行する

* freeze - リソース管理は継続するが、影響を受けるパーティションに含まれないノードのリソースは復帰させない

* stop - 影響を受けるクラスターパーティション内の全リソースを停止する

* suicide - 影響を受けるクラスターパーティション内の全ノードをフェンスする

symmetric-cluster

true

リソースを、デフォルトで任意のノードで実行できるかどうかを示します。

cluster-delay

60s

(アクションの実行を除く) ネットワーク上のラウンドトリップ遅延です。「正しい」値は、ネットワークおよびクラスタノードの速度と負荷によって異なります。

stop-orphan-resources

true

削除されたリソースを停止すべきかどうかを示します。

stop-orphan-actions

true

削除されたアクションをキャンセルするかどうかを示します。

start-failure-is-fatal

true

特定のノードでリソースの起動に失敗した場合に、そのノードで開始試行を行わないようにするかを示します。false に設定すると、クラスターは、同じノードで開始するかどうかを、リソースが失敗した回数と、移行しきい値により設定します。リソースに migration-threshold オプションを設定する方法は、「リソースのメタオプションの設定」を参照してください。

start-failure-is-fatalfalse に設定すると、リソースを起動できない障害があるノードが、すべての依存アクションを遅らせる可能性があるというリスクが発生します。この理由により、start-failure-is-fatal のデフォルトは true となっています。start-failure-is-fatal=false を設定するリスクは、移行しきい値を低く設定することで軽減できます。これにより、何度も失敗してもその他のアクションを続行できます。

pe-error-series-max

-1 (すべて)

「ERROR」となるスケジューラー入力を保存する数。問題を報告する場合に使用されます。

pe-warn-series-max

-1 (すべて)

「WARNING」となるスケジューラー入力を保存する数。問題を報告する場合に使用されます。

pe-input-series-max

-1 (すべて)

「normal」となるスケジューラー入力を保存する数。問題を報告する場合に使用されます。

cluster-infrastructure

 

Pacemaker が現在実行しているメッセージングスタック。情報提供および診断目的に使用されます。ユーザーは設定できません。

dc-version

 

クラスターの DC (Designated Controller) で Pacemaker のバージョン。診断目的に使用され、ユーザーは設定できません。

cluster-recheck-interval

15 分

時間ベースでオプション、リソースパラメーター、および制約を変更するポーリング間隔。使用できる値は、ポーリングを無効にする 0 (ゼロ) と、秒単位で間隔を示す正の値です (5min など、他の SI 単位が指定されていない場合に限ります)。この値は確認が行われる間隔に対する最大時間であることに注意してください。クラスターイベントが、この値で指定された時間よりも早く発生した場合は、確認が行われるタイミングが早くなります。

maintenance-mode

false

メンテナンスモードでは、クラスターが「干渉されない」モードになり、指示されない限り、サービスを起動したり、停止したりしません。メンテナンスモードが完了すると、クラスターは、サービスの現在の状態のサニティーチェックを実行してから、これを必要とするサービスを停止するか、または開始します。

shutdown-escalation

20min

正常にシャットダウンして終了を試みるのをやめる時間。高度な使用のみ。

stop-all-resources

false

クラスターがすべてのリソースを停止します。

enable-acl

false

クラスターが、pcs acl コマンドで設定したアクセス制御一覧を使用できるかどうかを示します。

placement-strategy

default

クラスターノードでリソースの配置を決定する際に、クラスターが使用率属性を考慮にいれるかどうかと、どのように考慮するかを示します。

21.2. クラスターのプロパティーの設定と削除

クラスタープロパティーの値を設定するには、次の pcs コマンドを使用します。

pcs property set property=value

たとえば、symmetric-cluster の値を false に設定する場合は、次のコマンドを使用します。

# pcs property set symmetric-cluster=false

設定からクラスタープロパティーを削除する場合は、次のコマンドを使用します。

pcs property unset property

または、pcs property set コマンドの値フィールドを空白にしても、クラスタープロパティーを設定から削除できます。これにより、そのプロパティーの値がデフォルト値に戻されます。たとえば、symmetric-cluster プロパティーを false に設定したことがある場合は、設定した値が次のコマンドにより削除され、symmetric-cluster の値がデフォルト値の true に戻されます。

# pcs property set symmetic-cluster=

21.3. クラスタープロパティー設定のクエリー

ほとんどの場合は、各種のクラスターコンポーネントの値を表示するのに pcs コマンドを使用する場合に、pcs list または pcs show を同じように使用できます。次の例では、pcs list は、複数のプロパティーの設定を完全に表示するのに使用される形式で、pcs show は、特定のプロパティーの値を表示する場合に使用される形式です。

クラスターに設定されたプロパティー設定の値を表示する場合は、次の pcs コマンドを使用します。

pcs property list

明示的に設定されていないプロパティー設定のデフォルト値など、クラスターのプロパティー設定の値をすべて表示する場合は、次のコマンドを使用します。

pcs property list --all

特定のクラスタープロパティーの現在の値を表示する場合は、次のコマンドを使用します。

pcs property show property

たとえば、cluster-infrastructure プロパティーの現在の値を表示する場合は、次のコマンドを実行します。

# pcs property show cluster-infrastructure
Cluster Properties:
 cluster-infrastructure: cman

情報提供の目的で、次のコマンドを使用して、プロパティーがデフォルト以外の値に設定されているかどうかに関わらず、プロパティーのデフォルト値の一覧を表示できます。

pcs property [list|show] --defaults

第22章 ノードの正常なシャットダウン時に停止したままになるようにリソースを設定 (RHEL 8.2 以降)

クラスターノードがシャットダウンしたときの Pacemaker のデフォルトの応答は、シャットダウンが正常なシャットダウンであっても、そのノードで実行中のすべてのリソースを停止し、別の場所でリソースを復元することです。RHEL 8.2 以降では、ノードが正常にシャットダウンすると、ノードに接続されているリソースがノードにロックされ、シャットダウンしたノードがクラスターに再度参加するときに再び起動するまで、他の場所で起動できないように、Pacemaker を設定できます。これにより、ノードのリソースをクラスター内の他のノードにフェールオーバーせずに、サービスの停止が許容できるメンテナンスウィンドウ中にノードの電源を切ることができます。

22.1. ノードの正常なシャットダウン時に停止したままになるようにリソースを設定するためのクラスタープロパティー

ノードの正常なシャットダウンでリソースがフェイルオーバーしないようにする機能は、以下のクラスタープロパティーで実装されます。

shutdown-lock

このクラスタープロパティーをデフォルト値の false に設定すると、クラスターは、ノードで適切にシャットダウンしているノードでアクティブなリソースを復旧します。このプロパティーを true に設定すると、適切にシャットダウンしているノードでアクティブなリソースは、クラスターに再参加した後にノードで再起動するまで別の場所で起動できなくなります。

shutdown-lock プロパティーはクラスターノードまたはリモートノードのいずれかで機能しますが、ゲストノードは機能しません。

shutdown-locktrue に設定すると、ノードがダウンした場合にクラスターリソースのロックを削除し、以下のコマンドを実行してノードで手動更新を実行してリソースを別の場所で起動できるようになります。

pcs resource refresh resource --node node

リソースのロックが解除されると、クラスターはリソースを別の場所に移動できるようになることに注意してください。リソースのスティッキネスの値または場所の設定を使用することにより、これが発生する可能性を抑制できます。

注記

手動更新は、最初に次のコマンドを実行するとリモートノードで機能します。

  1. リモートノードで systemctl stop pacemaker_remote コマンドを実行してノードを停止します。
  2. pcs resource disable remote-connection-resource コマンドを実行します。

その後、リモートノードで手動更新を実行できます。

shutdown-lock-limit

このクラスタープロパティーをデフォルト値の 0 以外の値に設定すると、シャットダウンを開始してから指定した時間内にノードが再参加しない場合に、他のノードの復旧にリソースが利用可能になります。

注記

shutdown-lock-limit プロパティーは、以下のコマンドを最初に実行した場合に限りリモートノードで動作します。

  1. リモートノードで systemctl stop pacemaker_remote コマンドを実行してノードを停止します。
  2. pcs resource disable remote-connection-resource コマンドを実行します。

このコマンドの実行後、shutdown-lock-limit で指定した時間が経過すると、リモートノード上で実行しているリソースが他のノードの復旧に利用できます。

22.2. shutdown-lock クラスタープロパティーの設定

以下の例では、サンプルのクラスターで shutdown-lock クラスタープロパティーを true に設定し、ノードをシャットダウンして再起動したときの影響を示しています。この例のクラスターは、z1.example.comz2.example.com、および z3.example.com の 3 つのノードで構成されます。

  1. shutdown-lock プロパティーを true に設定し、その値を確認します。この例では、shutdown-lock-limit プロパティーはデフォルト値 0 を維持します。

    [root@z3.example.com ~]# pcs property set shutdown-lock=true
    [root@z3.example.com ~]# pcs property list --all | grep shutdown-lock
     shutdown-lock: true
     shutdown-lock-limit: 0
  2. クラスターのステータスを確認します。この例では、3 番目と 5 番目のリソースが z1.example.com で実行しています。

    [root@z3.example.com ~]# pcs status
    ...
    Full List of Resources:
    ...
     * first	(ocf::pacemaker:Dummy):	Started z3.example.com
     * second	(ocf::pacemaker:Dummy):	Started z2.example.com
     * third	(ocf::pacemaker:Dummy):	Started z1.example.com
     * fourth	(ocf::pacemaker:Dummy):	Started z2.example.com
     * fifth	(ocf::pacemaker:Dummy):	Started z1.example.com
    ...
  3. z1.example.com をシャットダウンします。これにより、そのノードで実行中のリソースを停止します。

    [root@z3.example.com ~] # pcs cluster stop z1.example.com
    Stopping Cluster (pacemaker)...
    Stopping Cluster (corosync)...
  4. pcs status コマンドを実行すると、ノードの z1.example.com がオフラインであることを示し、z1.example.com で実行していたリソースは、ノードの停止時に LOCKED になります。

    [root@z3.example.com ~]# pcs status
    ...
    
    Node List:
     * Online: [ z2.example.com z3.example.com ]
     * OFFLINE: [ z1.example.com ]
    
    Full List of Resources:
    ...
     * first	(ocf::pacemaker:Dummy):	Started z3.example.com
     * second	(ocf::pacemaker:Dummy):	Started z2.example.com
     * third	(ocf::pacemaker:Dummy):	Stopped z1.example.com (LOCKED)
     * fourth	(ocf::pacemaker:Dummy):	Started z3.example.com
     * fifth	(ocf::pacemaker:Dummy):	Stopped z1.example.com (LOCKED)
    
    ...
  5. クラスターサービスを z1.example.com で再度起動し、クラスターに再参加できるようにします。ロックされたリソースは、そのノードで開始する必要がありますが、いったん起動すると、必ずしも同じノードに留まるわけではありません。

    [root@z3.example.com ~]# pcs cluster start z1.example.com
    Starting Cluster...
  6. この例では、3 番目および 5 番目のリソースが、z1.example.com ノードで復元されます。

    [root@z3.example.com ~]# pcs status
    ...
    
    Node List:
     * Online: [ z1.example.com z2.example.com z3.example.com ]
    
    Full List of Resources:
    ..
     * first	(ocf::pacemaker:Dummy):	Started z3.example.com
     * second	(ocf::pacemaker:Dummy):	Started z2.example.com
     * third	(ocf::pacemaker:Dummy):	Started z1.example.com
     * fourth	(ocf::pacemaker:Dummy):	Started z3.example.com
     * fifth	(ocf::pacemaker:Dummy):	Started z1.example.com
    
    ...

第23章 ノード配置ストラテジーの設定

Pacemaker は、すべてのノードのリソース割り当てスコアに従って、リソースを配置する場所を決定します。このリソースは、リソースのスコアが最も高いノードに割り当てられます。この割り当てスコアは、リソースの制約、resource-stickiness の設定、各ノードにおけるリソースの過去の障害履歴、各ノードの使用率などの要因の組み合わせから導出されます。

すべてのノードでリソース割り当てスコアが等しい場合、デフォルトの配置ストラテジーにより、Pacemaker は、負荷を分散するために、割り当てられたリソースの数が最も少ないノードを選択します。各ノードのリソースの数が等しい場合は、CIB の最初の対象ノードがリソースを実行するのに選択されます。

ただし、多くの場合、リソースが使用するノードの容量 (メモリーや I/O など) の割合は、状況によって大きく異なります。そのため、ノードに割り当てられているリソースの数のみを考慮して、いつでも思想的な負荷分散が行われるとは限りません。また、リソースの合計要件が、指定の容量を超えるように配置されている場合は、リソースが完全に起動できなくなるか、パフォーマンスが低下した状態で起動することがあります。このような要因を考慮するために、Pacemaker では次の要素を設定できます。

  • 特定のノードの容量
  • 特定のリソースが必要な容量
  • リソースの配置の全体的なストラテジー

23.1. 使用率属性および配置ストラテジー

ノードが提供する容量、またはリソースが必要な容量を設定するには、ノードとリソースに 使用率属性 を使用します。これを行うには、リソースの使用率変数を設定し、その変数に値を割り当ててリソースに必要なものを示してから、同じ使用率変数をノードに設定し、その変数に値を割り当ててそのノードが提供するものを示します。

設定に応じて使用率属性に名前を付け、構成に必要な数だけ名前と値のペアを定義できます。使用率属性の値は整数である必要があります。

23.1.1. ノードおよびリソース容量の設定

以下の例では、2 つのノードに CPU 容量の使用率属性を設定し、この属性を変数 cpu として設定します。また、RAM 容量の使用率属性を構成し、この属性を変数 memory として設定します。この例では、以下のように設定されています。

  • ノード 1 は、CPU 容量 2 と、RAM 容量 2048 を指定するように定義されています。
  • ノード 2 は、CPU 容量 4 と、RAM 容量 2048 を指定するように定義されています。
# pcs node utilization node1 cpu=2 memory=2048
# pcs node utilization node2 cpu=4 memory=2048

次の例では、3 つの異なるリソースに必要な、同じ使用率属性を指定します。この例では、以下のように設定されています。

  • dummy-small リソースには、CPU 容量 1 と、RAM 容量 1024 が必要です。
  • dummy-medium リソースには、CPU 容量 2 と、RAM 容量 2048 が必要です。
  • dummy-large リソースには、CPU 容量 1 と、RAM 容量 3072 が必要です。
# pcs resource utilization dummy-small cpu=1 memory=1024
# pcs resource utilization dummy-medium cpu=2 memory=2048
# pcs resource utilization dummy-large cpu=3 memory=3072

使用率属性で定義されているリソースの要件を満たすのに十分な空き容量があれば、ノードはリソースに適格と見なされます。

23.1.2. 配置ストラテジーの設定

ノードが提供する容量と、リソースが必要とする容量を設定したら、placement-strategy クラスタープロパティーを設定する必要があります。これを設定しないと、容量を設定しても効果がありません。

placement-strategy クラスタープロパティーには、4 つの値を使用できます。

  • default - 使用率の値は全く考慮されません。リソースは、割り当てスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。
  • utilization - 使用率の値は、ノードが適格と見なされるかどうか (つまり、リソースの要件を満たすのに十分な空き容量があるかどうか) を決定する場合にのみ考慮されます。負荷分散は、ノードに割り当てられたリソースの数に基づいて行われます。
  • balanced - 使用率の値は、ノードがリソースを提供する資格があるかどうかを判断する際、および負荷分散する際に考慮されるため、リソースのパフォーマンスを最適化する方法でリソースを分散しようとします。
  • minimal - 使用率の値は、ノードがリソースを提供する資格があるかどうかを決定する場合に限り考慮されます。負荷分散は、できるだけ少ないノードにリソースを集中させて、残りのノードで電力を節約できるようにします。

以下の例のコマンドでは、placement-strategy の値を balanced に設定します。このコマンドを実行すると、Pacemaker は、複雑な一連のコロケーション制約を使用せずに、リソースからの負荷がクラスター全体に均等に分散されるようにします。

# pcs property set placement-strategy=balanced

23.2. Pacemaker リソースの割り当て

以下のセクションでは、Pacemaker がリソースを割り当てる仕組みをまとめています。

23.2.1. ノードの優先順位

Pacemaker は、以下のストラテジーに従ってリソースを割り当てる際に優先されるノードを決定します。

  • 重みが最も高いノードが最初に消費されます。ノードの重みは、ノードの状態を表すためにクラスターによって維持されるスコアです。
  • ノードの重みが、複数のノードで同じ場合は、以下のようになります。

    • placement-strategy クラスタープロパティーが default または utilization の場合は、以下のようになります。

      • 割り当てられているリソースの数が最も少ないノードが最初に使用されます。
      • 割り当てられているリソースの数が等しい場合は、CIB に登録されている最初の対象ノードが最初に使用されます。
    • placement-strategy クラスタープロパティーが balanced である場合は、以下のようになります。

      • 空き容量が最も多いノードが最初に使用されます。
      • ノードの空き容量が等しい場合は、割り当てられているリソースの数が最も少ないノードが最初に使用されます。
      • ノードの空き容量が等しく、割り当てられているリソースの数が等しい場合は、CIB に最初に登録されている対象ノードが最初に使用されます。
    • placement-strategy クラスタープロパティーが minimal の場合は、CIB に登録されている最初の対象ノードが最初に使用されます。

23.2.2. ノードの容量

Pacemaker は、以下のストラテジーに従って、どのノードに最も空き容量があるかを判断します。

  • 使用率属性が 1 種類だけ定義されている場合、空き容量は単純な数値比較となります。
  • 定義されている使用属性の種類が複数になる場合は、ほとんどの属性タイプで数値が最も高いノードの空き容量が、最も大きくなります。以下に例を示します。

    • NodeA の空き CPU が多く、NodeB の空きメモリーが多い場合は、互いの空き容量は等しくなります。
    • NodeA の空き CPU が多く、NodeB の空きメモリーとストレージが多い場合、NodeB の方が空き容量が多くなります。

23.2.3. リソースの割り当て設定

Pacemaker は、以下のストラテジーに従って、最初に割り当てられるリソースを決定します。

  • 優先度の最も高いリソースが最初に割り当てられます。リソースの作成時に、リソースの優先度を設定できます。
  • リソースの優先度が等しい場合は、リソースのシャッフルを防ぐために、実行中のノードで最も高いスコアを持つリソースが最初に割り当てられます。
  • リソースが実行しているノードのリソーススコアが等しい場合や、リソースが実行していない場合は、優先ノードで最もスコアが高いリソースが最初に割り当てられます。この場合、優先ノードのリソーススコアが等しい場合は、CIB に最初に登録されている実行可能なリソースが最初に割り当てられます。

23.3. リソース配置ストラテジーのガイドライン

リソースに対する Pacemaker の配置ストラテジーが最も効果的に機能するようにするためにも、システムを設定するときに次の点を考慮する必要があります。

  • 物理容量が十分にあることを確認します。

    ノードの物理容量が、通常の状態でほぼ最大に使用されているとすると、フェイルオーバーの際に問題が発生する可能性があります。使用率機能がなくても、タイムアウトや二次障害が発生する可能性があります。

  • ノードに設定する容量にバッファをいくつか構築します。

    物理的に存在するよりもわずかに多くのノードリソースが通知されます。ここでは、Pacemaker リソースが、設定した CPU、メモリーなどを常に 100% 使用しないことが想定されます。このような状況は、オーバーコミットと呼ばれることもあります。

  • リソースの優先度を指定します。

    クラスターがサービスを犠牲にする場合、犠牲にするサービスは一番重要でないことが理想的です。最も重要なリソースが最初にスケジュールされるように、リソースの優先度が適切に設定されていることを確認してください。

23.4. NodeUtilization リソースエージェント

NodeUtilization エージェントは、使用可能な CPU、ホストメモリーの可用性、およびハイパーバイザーのメモリーの可用性に関するシステムパラメーターを検出し、このようなパラメーターを CIB に追加します。エージェントをクローンリソースとして実行して、各ノードにこのようなパラメーターを自動的に入力することができます。

NodeUtilization リソースエージェントと、このエージェントのリソースオプションの詳細は、pcs resource describe NodeUtilization コマンドを実行してください。

第24章 仮想ドメインをリソースとして設定

pcs resource create コマンドを使用して、VirtualDomain をリソースタイプとして指定すると、libvirt 仮想化フレームワークが管理する仮想ドメインを、クラスターリソースとして構成できます。

仮想ドメインをリソースとして設定する場合は、以下の点を考慮してください。

  • 仮想ドメインは、クラスターリソースとして構成する前に停止する必要があります。
  • 仮想ドメインをクラスターリソースにすると、クラスターツールを使用しない限り、起動、停止、または移行を行うことができません。
  • クラスターリソースとして設定した仮想ドメインを、ホストの起動時に起動するように設定することはできません。
  • 仮想ドメインの実行を許可するすべてのノードは、その仮想ドメインに必要な設定ファイルおよびストレージデバイスにアクセスできるようにする必要があります。

クラスターが仮想ドメイン内のサービスを管理できるようにする場合は、仮想ドメインをゲストノードとして設定できます。

24.1. 仮想ドメインリソースのオプション

表24.1「仮想ドメインリソースのリソースオプション」では、VirtualDomain リソースに設定できるリソースオプションを説明します。

表24.1 仮想ドメインリソースのリソースオプション

フィールドデフォルト説明

config

 

(必須) この仮想ドメインの libvirt 設定ファイルへの絶対パス。

hypervisor

システムに依存

接続先のハイパーバイザーの URI。virsh --quiet uri コマンドを実行して、システムのデフォルト URI を確認できます。

force_stop

0

停止時にドメインを常に強制的にシャットダウン (「破棄」) します。デフォルト動作では、正常なシャットダウンの試行に失敗した後でのみ、強制シャットダウンを実行します。仮想ドメイン (または仮想化バックエンド) が正常なシャットダウンに対応していない場合に限り、これを true に設定する必要があります。

migration_transport

システムに依存

移行中にリモートハイパーバイザーに接続するのに使用されるトランスポート。このパラメーターを省略すると、リソースは libvirt のデフォルトトランスポートを使用して、リモートハイパーバイザーに接続します。

migration_network_suffix

 

専用の移行ネットワークを使用します。移行 URI は、このパラメーターの値をノード名の末尾に追加することで構成されます。ノード名が完全修飾ドメイン名 (FQDN) の場合は、FQDN の最初のピリオド (.) の直前にサフィックスを挿入します。この構成されたホスト名がローカルで解決可能であり、関連する IP アドレスが優先ネットワークを介して到達可能であることを確認してください。

monitor_scripts

 

仮想ドメイン内でサービスの監視を追加で実行する場合は、監視するスクリプトの一覧とともに、このパラメーターを追加します。注記: 監視スクリプトを使用する場合、start および migrate_from の操作は、すべての監視スクリプトが正常に完了した場合にのみ完了します。この遅延に対応できるように、この操作のタイムアウトを必ず設定してください。

autoset_utilization_cpu

true

true に設定すると、監視の実行時に、エージェントが virsh から domainUvCPU 数を検出し、これをリソースのCPU 使用率に組み込みます。

autoset_utilization_hv_memory

true

true に設定すると、監視の実行時に、エージェントが virsh から Max memor 数を検出し、これをリソースの hv_memory の使用率に組み込みます。

migrateport

ランダムハイポート

このポートは、qemu 移行 URI で使用されます。これを設定しないと、ポートにはランダムハイポートが使用されます。

snapshot

 

仮想マシンイメージが保存されるスナップショットディレクトリーへのパス。このパラメーターが設定されていると、仮想マシンの RAM 状態は、停止時にスナップショットディレクトリーのファイルに保存されます。起動時にドメインのステータスファイルが存在すると、ドメインは、最後に停止する直前の状態に復元されます。このオプションは、force_stop オプションと互換性がありません。

VirtualDomain リソースオプションに加えて、allow-migrate メタデータオプションを構成して、リソースの別のノードへのライブ移行を許可できます。このオプションを true に設定すると、状態を失うことなくリソースを移行できます。このオプションがデフォルトの状態である false に設定されていると、仮想ドメインは、ノード間で移行される際に、最初のノードでシャットダウンしてから、2 番目のノードで再起動します。

24.2. 仮想ドメインリソースの作成

以下の手順を使用して、作成されている仮想マシンのクラスターに VirtualDomain リソースを作成します。

  1. 仮想マシンを管理するために VirtualDomain リソースエージェントを作成する場合、Pacemaker では、ディスクのファイルに、仮想マシンの xml 設定ファイルをダンプする必要があります。たとえば、guest1 という名前の仮想マシンを作成した場合は、ゲストを実行できるクラスターノードのいずれかにファイルに xml ファイルをダンプします。任意のファイル名を使用できますが、この例では /etc/pacemaker/guest1.xml を使用します。

    # virsh dumpxml guest1 > /etc/pacemaker/guest1.xml
  2. 仮想マシンの xml 設定ファイルを、各ノードの同じ場所にあるゲストを実行できるその他のすべてのクラスターノードにコピーします。
  3. 仮想ドメインの実行が許可されているすべてのノードが、その仮想ドメインに必要なストレージデバイスにアクセスできるようにします。
  4. 仮想ドメインが、仮想ドメインを実行する各ノードで起動および停止できることを別途テストします。
  5. ゲストノードが実行している場合はシャットダウンします。Pacemaker は、クラスターで構成されているノードを起動します。仮想マシンは、ホストの起動時に自動的に起動するように設定することはできません。
  6. pcs resource create コマンドを使用して、VirtualDoman リソースを設定します。たとえば、次のコマンドは、VM という名前のVirtualDomain リソースを設定します。allow-migrate オプションが true に設定されているため、pcs move VM nodeX コマンドはライブ移行として実行されます。

    この例では、migration_transportssh に設定されます。SSH 移行が適切に機能するには、鍵を使用しないロギングがノード間で機能する必要があります。

    # pcs resource create VM VirtualDomain config=/etc/pacemaker/guest1.xml migration_transport=ssh meta allow-migrate=true

第25章 クラスタークォーラム

Red Hat High Availability Add-On クラスターは、スプリットブレインの状況を回避するために、votequorum サービスをフェンシングと併用します。クラスターの各システムには多くの投票数が割り当てられ、過半数の票を取得しているものだけがクラスターの操作を継続できます。サービスは、すべてのノードに読み込むか、いずれのノードにも読み込まないようにする必要があります。サービスをクラスタノードのサブセットに読み込むと、結果が予想できなくなります。votequorum サービスの設定および操作の詳細は、man ページの votequorum(5) を参照してください。

25.1. クォーラムオプションの設定

pcs cluster setup コマンドを使用してクラスターを作成する場合は、クォーラム設定の特殊な機能を使用できます。表25.1「クォーラムオプション」には、このようなオプションをまとめています。

表25.1 クォーラムオプション

オプション説明

auto_tie_breaker

これを有効にすると、クラスターは、決定論的に最大 50% のノードが同時に失敗しても存続されます。クラスターパーティションや、auto_tie_breaker_node に設定された nodeid (設定されていない場合は最小の nodeid) と通信したままのノードのセットは、クォーラムに達した状態を維持します。その他のノードはクォーラムに達しません。

auto_tie_breaker オプションを指定すると、均等の分割でクラスターが動作を継続できるようになるため、主に偶数個のノードがあるクラスターで使用されます。複数で不均等の分割などの、より複雑な障害は、「クォーラムデバイス」を参照してください。

auto_tie_breaker オプションは、クォーラムデバイスと互換性がありません。

wait_for_all

有効にすると、最低 1 回、同時にすべてのノードが現れた後に、初回だけ、クラスターがクォーラムに達します。

wait_for_all オプションは、主にクォーラムデバイス lms (last man standing) アルゴリズムを使用する 2 ノードクラスター、および偶数のノードで構成されるクラスターに使用されます。

wait_for_all オプションは、クラスターに 2 つのノードがあり、クォーラムデバイスを使用せず、auto_tie_breaker が無効になっている場合に自動的に有効になります。wait_for_all を明示的に 0 に設定すると、このオプションをオーバーライドできます。

last_man_standing

有効にすると、クラスターは特定の状況で expected_votes とクォーラムを動的に再計算します。このオプションを有効にする場合は、wait_for_all を有効にする必要があります。last_man_standing オプションには、クォーラムデバイスとの互換性がありません。

last_man_standing_window

クラスターのノードが失われた後の、expected_votes およびクォーラムを再計算するまでの待ち時間 (ミリ秒単位) です。

このオプションの設定および使用の詳細は、man ページの votequorum(5) を参照してください。

25.2. クォーラムオプションの変更

pcs quorum update コマンドを使用して、クラスターの一般的なクォーラムオプションを変更できます。このコマンドを実行する場合は、クラスターを停止する必要があります。クォーラムオプションの詳細は、man ページの votequorum(5) を参照してください。

pcs quorum update コマンドの形式は以下のとおりです。

pcs quorum update [auto_tie_breaker=[0|1]] [last_man_standing=[0|1]] [last_man_standing_window=[time-in-ms] [wait_for_all=[0|1]]

以下の一連のコマンドは、wait_for_all クォーラムオプションを変更し、このオプションの更新された状態を表示します。クラスターの稼働中はこのコマンドを実行できないことに注意してください。

[root@node1:~]# pcs quorum update wait_for_all=1
Checking corosync is not running on nodes...
Error: node1: corosync is running
Error: node2: corosync is running

[root@node1:~]# pcs cluster stop --all
node2: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (pacemaker)...
node1: Stopping Cluster (corosync)...
node2: Stopping Cluster (corosync)...

[root@node1:~]# pcs quorum update wait_for_all=1
Checking corosync is not running on nodes...
node2: corosync is not running
node1: corosync is not running
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded

[root@node1:~]# pcs quorum config
Options:
  wait_for_all: 1

25.3. クォーラム設定およびステータスの表示

クラスターの実行したら、以下のクラスタークォーラムコマンドを実行できます。

次のコマンドは、クォーラムの設定を表示します。

pcs quorum [config]

次のコマンドは、クォーラムのランタイム状態を表示します。

pcs quorum status

25.4. クォーラムに達しないクラスターの実行

長時間、クラスターからノードを削除したためクォーラムが損失した場合は、pcs quorum expected-votes コマンドを使用すると、ライブクラスターの expected_votes パラメーターの値を変更できます。これにより、クォーラムがない場合でも、クラスターは操作を継続できます。

警告

ライブクラスターで期待される票数 (vote) を変更する場合は、細心の注意を払って行ってください。期待される票数を手動で変更したために、実行しているクラスターが 50% 未満となる場合は、クラスターの他のノードを個別に起動してクラスターサービスを開始できるため、データの破損や予期せぬ結果が発生することがあります。この値を変更する場合は、wait_for_all パラメーターが有効になっていることを確認してください。

次のコマンドは、ライブクラスターで期待される票数を、指定の値に設定します。これはライブクラスターにのみ影響し、設定ファイルは変更されません。リロードが行われると、expected_votes の値は、設定ファイルの値にリセットされます。

pcs quorum expected-votes votes

クォーラムに達していない状態でクラスターにリソース管理を続行させたい場合は、pcs quorum unblock コマンドを使用して、クォーラムの確立時にクラスターがすべてのノードを待機することのないようにします。

注記

このコマンドは細心の注意を払って使用する必要があります。このコマンドを実行する前に、現在クラスターにないノードの電源を切り、共有リソースにアクセスできない状態であることを確認する必要があります。

# pcs quorum unblock

25.5. クォーラムデバイス

クラスター用のサードパーティ仲裁デバイスとして機能する別のクォーラムデバイスを設定することにより、標準のクォーラムルールで許容されるよりも多くのノード障害に耐えられるようにすることができます。クォーラムデバイスは、偶数のノードで構成されるクラスターに推奨されます (2 ノード構成のクラスターには強く推奨されます)。

クォーラムデバイスを設定する場合は、以下を考慮する必要があります。

  • クォーラムデバイスは、クォーラムデバイスを使用するクラスターと同じ場所にある別の物理ネットワークで実行することが推奨されます。理想としては、クォーラムデバイスホストを、メインクラスターとは別のラックに置くか、少なくとも別の PSU に置くようにします。corosync リングと同じネットワークセグメントには置かないようにしてください。
  • 複数のクォーラムデバイスをクラスターで同時に使用することはできません。
  • 複数のクォーラムデバイスをクラスターで同時に使用することはできません。ただし、複数のクラスターが 1 つのクォーラムデバイスを同時に使用することはできます。アルゴリズムやクォーラムオプションはクラスターノード自体に保存されるため、同じクォーラムデバイスを使用する各クラスターが、複数のアルゴリズムやクォーラムオプションを使用できます。たとえば、ffsplit ((fifty/fifty split) アルゴリズムを使用するクラスターと、lms (last man standing) アルゴリズムを使用する別のクラスターが、1 つのクォーラムデバイスを使用できます。
  • クォーラムデバイスは、既存のクラスターノードで実行しないでください。

25.5.1. クォーラムデバイスパッケージのインストール

クラスターにクォーラムデバイスを設定するには、以下のパッケージをインストールする必要があります。

  • 既存クラスターのノードで、corosync-qdevice をインストールします。

    [root@node1:~]# yum install corosync-qdevice
    [root@node2:~]# yum install corosync-qdevice
  • クォーラムデバイスホストに、pcs および corosync-qnetd をインストールします。

    [root@qdevice:~]# yum install pcs corosync-qnetd
  • pcsd サービスを起動し、システムの起動時に pcsd がクォーラムデバイスホストで有効になるようにします。

    [root@qdevice:~]# systemctl start pcsd.service
    [root@qdevice:~]# systemctl enable pcsd.service

25.5.2. クォーラムデバイスの設定

以下の手順では、クォーラムデバイスを設定し、そのクォーラムデバイスをクラスターに追加します。この例では、以下のように設定されています。

  • クォーラムデバイスに使用されるノードは qdevice です。
  • クォーラムデバイスモデルは net で、これは現在対応している唯一のクォーラムデバイスモデルです。net モデルは、以下のアルゴリズムに対応します。

    • ffsplit (fifty-fifty split) - これにより、アクティブなノードの数が最も多いパーティションに 1 票が提供されます。
    • lms (last-man-standing) - ノードが qnetd サーバーを確認できるクラスター内に残っている唯一のノードである場合に、1 票が返されます。

      警告

      LMS アルゴリズムにより、ノードが 1 つしか残っていなくてもクラスターはクォーラムを維持できますが、number_of_nodes - 1 と同じであるため、クォーラムデバイスの投票力が大きいことを意味します。クォーラムデバイスとの接続が失われると、number_of_nodes - 1 の票が失われます。つまり、(クォーラムデバイスを無効にすることで) すべてのノードがアクティブなクラスターのみがクォーラムに達したままになります。他のクラスターは、クォーラムに達しなくなります。

      これらのアルゴリズムの実装の詳細は、man ページの corosync-qdevice(8) を参照してください。

  • クラスターノードは node1node2 です。

以下の手順は、クォーラムデバイスを設定し、そのクォーラムデバイスをクラスターに追加します。

  1. クォーラムデバイスをホストするために使用するノードで以下のコマンドを使用し、クォーラムデバイスを設定します。このコマンドは、クォーラムデバイスモデルである net を設定および開始し、システムの起動時にデバイスが開始するように設定します。

    [root@qdevice:~]# pcs qdevice setup model net --enable --start
    Quorum device 'net' initialized
    quorum device enabled
    Starting quorum device...
    quorum device started

    クォーラムデバイスの設定後、そのステータスを確認できます。corosync-qnetd デーモンが実行中であり、この時点でクライアントが接続されていないことが分かります。--full コマンドオプションを指定すると詳細が出力されます。

    [root@qdevice:~]# pcs qdevice status net --full
    QNetd address:                  *:5403
    TLS:                            Supported (client certificate required)
    Connected clients:              0
    Connected clusters:             0
    Maximum send/receive size:      32768/32768 bytes
  2. 以下のコマンドを実行して、firewalldhigh-availability サービスを有効にして、pcsd デーモンおよび net クォーラムデバイスで必要なファイアウォールのポートを有効にします。

    [root@qdevice:~]# firewall-cmd --permanent --add-service=high-availability
    [root@qdevice:~]# firewall-cmd --add-service=high-availability
  3. 既存クラスターのいずれかのノードにより、クォーラムデバイスをホストしているノードで hacluster ユーザーを認証します。これにより、クラスターの pcsqdevice ホストの pcs にアクセスできるようになりますが、qdevice ホストの pcs は、クラスターの pcs に接続することを許可しません。

    [root@node1:~] # pcs host auth qdevice
    Username: hacluster
    Password:
    qdevice: Authorized
  4. クォーラムデバイスをクラスターに追加します。

    クォーラムデバイスを追加する前に、後で比較するために、クォーラムデバイスの現在の設定と状況を確認できます。これらのコマンドの出力は、クラスターがクォーラムデバイスを使用していないことを示し、各ノードの Qdevice メンバーシップステータスが NR (Not Registered) であることを示します。

    [root@node1:~]# pcs quorum config
    Options:
    [root@node1:~]# pcs quorum status
    Quorum information
    ------------------
    Date:             Wed Jun 29 13:15:36 2016
    Quorum provider:  corosync_votequorum
    Nodes:            2
    Node ID:          1
    Ring ID:          1/8272
    Quorate:          Yes
    
    Votequorum information
    ----------------------
    Expected votes:   2
    Highest expected: 2
    Total votes:      2
    Quorum:           1
    Flags:            2Node Quorate
    
    Membership information
    ----------------------
        Nodeid      Votes    Qdevice Name
             1          1         NR node1 (local)
             2          1         NR node2

    以下のコマンドは、作成しておいたクォーラムデバイスをクラスターに追加します。複数のクォーラムデバイスをクラスターで同時に使用することはできません。ただし、複数のクラスターが 1 つのクォーラムデバイスを同時に使用することはできます。以下のコマンド例では、ffsplit アルゴリズムを使用するようにクォーラムデバイスを設定します。クォーラムデバイスの設定オプションの詳細は、man ページの corosync-qdevice(8) を参照してください。

    [root@node1:~]# pcs quorum device add model net host=qdevice algorithm=ffsplit
    Setting up qdevice certificates on nodes...
    node2: Succeeded
    node1: Succeeded
    Enabling corosync-qdevice...
    node1: corosync-qdevice enabled
    node2: corosync-qdevice enabled
    Sending updated corosync.conf to nodes...
    node1: Succeeded
    node2: Succeeded
    Corosync configuration reloaded
    Starting corosync-qdevice...
    node1: corosync-qdevice started
    node2: corosync-qdevice started
  5. クォーラムデバイスの設定状態をチェックします。

    クラスター側から以下のコマンドを実行すると、設定の変更内容を確認できます。

    pcs quorum config は、設定されたクォーラムデバイスを表示します。

    [root@node1:~]# pcs quorum config
    Options:
    Device:
      Model: net
        algorithm: ffsplit
        host: qdevice

    pcs quorum status コマンドは、クォーラムデバイスのステータスを表示し、クォーラムデバイスが使用中であることを示します。各クラスターノードの Qdevice メンバーシップ情報ステータスの値の意味は次のとおりです。

    • A/NA - クォーラムデバイスが存続しているかどうかで、qdevicecorosync の間にハートビートがあるかどうかを示します。これは、クォーラムデバイスが常に有効であることを示します。
    • V/NV - クォーラムデバイスがノードに投票を行ったときに V が設定されます。この例では、相互通信が可能であるため、両方のノードが V に設定されます。クラスターが 1 ノードクラスターに分割される場合は、いずれかのノードが V に設定され、もう一方のノードは NV に設定されます。
    • MW/NMW - クォーラムデバイス master_ wins フラグが設定されているか、設定されていません。デフォルトでは、フラグは設定されておらず、値は NMW (Not Master Wins) となります。master_wins フラグの詳細は、man ページの votequorum_qdevice_master_wins(3) を参照してください。

      [root@node1:~]# pcs quorum status
      Quorum information
      ------------------
      Date:             Wed Jun 29 13:17:02 2016
      Quorum provider:  corosync_votequorum
      Nodes:            2
      Node ID:          1
      Ring ID:          1/8272
      Quorate:          Yes
      
      Votequorum information
      ----------------------
      Expected votes:   3
      Highest expected: 3
      Total votes:      3
      Quorum:           2
      Flags:            Quorate Qdevice
      
      Membership information
      ----------------------
          Nodeid      Votes    Qdevice Name
               1          1    A,V,NMW node1 (local)
               2          1    A,V,NMW node2
               0          1            Qdevice

      pcs quorum device status は、クォーラムデバイスのランタイムステータスを表示します。

      [root@node1:~]# pcs quorum device status
      Qdevice information
      -------------------
      Model:                  Net
      Node ID:                1
      Configured node list:
          0   Node ID = 1
          1   Node ID = 2
      Membership node list:   1, 2
      
      Qdevice-net information
      ----------------------
      Cluster name:           mycluster
      QNetd host:             qdevice:5403
      Algorithm:              ffsplit
      Tie-breaker:            Node with lowest node ID
      State:                  Connected

      クォーラムデバイスから次のコマンドを実行して、corosync-qnetd デーモンのステータスを表示できます。

      [root@qdevice:~]# pcs qdevice status net --full
      QNetd address:                  *:5403
      TLS:                            Supported (client certificate required)
      Connected clients:              2
      Connected clusters:             1
      Maximum send/receive size:      32768/32768 bytes
      Cluster "mycluster":
          Algorithm:          ffsplit
          Tie-breaker:        Node with lowest node ID
          Node ID 2:
              Client address:         ::ffff:192.168.122.122:50028
              HB interval:            8000ms
              Configured node list:   1, 2
              Ring ID:                1.2050
              Membership node list:   1, 2
              TLS active:             Yes (client certificate verified)
              Vote:                   ACK (ACK)
          Node ID 1:
              Client address:         ::ffff:192.168.122.121:48786
              HB interval:            8000ms
              Configured node list:   1, 2
              Ring ID:                1.2050
              Membership node list:   1, 2
              TLS active:             Yes (client certificate verified)
              Vote:                   ACK (ACK)

25.5.3. クォーラムデバイスサービスの管理

次のコマンド例が示すように、PCS は、ローカルホスト (corosync-qnetd) でクォーラムデバイスサービスを管理する機能を提供します。このコマンドは、corosync-qnetd サービスにのみ影響することに注意してください。

[root@qdevice:~]# pcs qdevice start net
[root@qdevice:~]# pcs qdevice stop net
[root@qdevice:~]# pcs qdevice enable net
[root@qdevice:~]# pcs qdevice disable net
[root@qdevice:~]# pcs qdevice kill net

25.5.4. クラスターでクォーラムデバイス設定の管理

以下のセクションでは、クラスター内のクォーラムデバイスの設定を管理するのに使用できる PCS コマンドを説明します。

25.5.4.1. クォーラムデバイス設定の変更

クォーラムデバイスの設定を変更する場合は、pcs quorum device update コマンドを使用します。

警告

クォーラムデバイスモデル nethost オプションを変更する場合は、pcs quorum device remove コマンドおよび pcs quorum device add コマンドを使用し、設定を適切に行います (変更前のホストと変更後のホストが同じマシンである場合を除く)。

以下のコマンドは、クォーラムデバイスアルゴリズムを lms に変更します。

[root@node1:~]# pcs quorum device update model algorithm=lms
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Reloading qdevice configuration on nodes...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
node1: corosync-qdevice started
node2: corosync-qdevice started

25.5.4.2. クォーラムデバイスの削除

以下のコマンドを使用して、クラスターノードに設定されたクォーラムデバイスを削除します。

[root@node1:~]# pcs quorum device remove
Sending updated corosync.conf to nodes...
node1: Succeeded
node2: Succeeded
Corosync configuration reloaded
Disabling corosync-qdevice...
node1: corosync-qdevice disabled
node2: corosync-qdevice disabled
Stopping corosync-qdevice...
node1: corosync-qdevice stopped
node2: corosync-qdevice stopped
Removing qdevice certificates from nodes...
node1: Succeeded
node2: Succeeded

クォーラムデバイスを削除すると、クォーラムデバイスの状態を表示するときに、次のエラーメッセージが表示されます。

[root@node1:~]# pcs quorum device status
Error: Unable to get quorum status: corosync-qdevice-tool: Can't connect to QDevice socket (is QDevice running?): No such file or directory

25.5.4.3. クォーラムデバイスの破棄

クォーラムデバイスホストのクォーラムデバイスを無効にするか停止して、設定ファイルをすべて削除するには、次のコマンドを実行します。

[root@qdevice:~]# pcs qdevice destroy net
Stopping quorum device...
quorum device stopped
quorum device disabled
Quorum device 'net' configuration files removed

第26章 クラスターイベントのスクリプトの実行 (トリガー)

Pacemaker クラスターはイベント駆動型のシステムで、イベントはリソースやノードの障害、設定の変更、またはリソースの開始や停止になります。Pacemaker クラスターアラートを設定して、アラートエージェントによりクラスターイベントが発生したときに何らかの外部アクションを実行できます。アラートエージェントは、クラスターがリソースエージェントを呼び出してリソースの構成と操作を処理するのと同じ方法で呼び出す外部プログラムです。

クラスターは、環境変数を用いてイベントの情報をエージェントに渡します。エージェントは、E メールメッセージの送信、ログのファイルへの記録、監視システムの更新など、この情報を自由に使用できます。

  • Pacemaker は、デフォルトで /usr/share/pacemaker/alerts にインストールされるアラートエージェントのサンプルを複数提供します。これらのサンプルスクリプトは、コピーしてそのまま使用したり、目的に合わせて編集するテンプレートとして使用することもできます。対応する全属性は、サンプルエージェントのソースコードを参照してください。
  • サンプルアラートエージェントがニーズを満たしていない場合は、Pacemaker アラートを呼び出すアラートエージェントを作成できます。

26.1. サンプルアラートエージェントのインストールおよび設定

サンプルアラートエージェントの 1 つを使用するとき、スクリプトがニーズにあっていることを確認してください。サンプルエージェントは、特定のクラスター環境用のカスタムスクリプトを作成するためのテンプレートとして提供されます。Red Hat は、Pacemaker との通信にアラートエージェントスクリプトが使用するインターフェースをサポートしますが、カスタムエージェント自体にはサポートを提供していないことに注意してください。

サンプルアラートエージェントの 1 つ を使用するには、クラスターの各ノードにエージェントをインストールする必要があります。たとえば、次のコマンドは、alert_file.sh.sample スクリプトを alert_file.sh としてインストールします。

# install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample /var/lib/pacemaker/alert_file.sh

スクリプトをインストールしたら、スクリプトを使用するアラートを作成できます。

以下の例では、インストールした alert_file.sh アラートエージェントを使用してイベントのログをファイルに記録するアラートを設定します。アラートエージェントは、最低限のパーミッションを持つ hacluster ユーザーとして実行します。

この例では、イベントの記録に使用するログファイル pcmk_alert_file.log を作成します。また、アラートエージェントを作成し、その受信先としてログファイルへのパスを追加します。

# touch /var/log/pcmk_alert_file.log
# chown hacluster:haclient /var/log/pcmk_alert_file.log
# chmod 600 /var/log/pcmk_alert_file.log
# pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh
# pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log

以下の例では、alert_snmp.sh.sample スクリプトを alert_snmp.sh としてインストールし、インストールした alert_snmp.sh アラートエージェントを使用してクラスターイベントを NSMP トラップとして送信するアラートを設定します。デフォルトでは、正常な監視呼び出し以外のすべてのイベントを SNMP サーバーに送信します。この例では、タイムスタンプの形式をメタオプションとして設定します。この例では、アラートの設定後にアラートの受信側が設定され、アラート設定が表示されます。

# install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample /var/lib/pacemaker/alert_snmp.sh
# pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-format="%Y-%m-%d,%H:%M:%S.%01N"
# pcs alert recipient add snmp_alert value=192.168.1.2
# pcs alert
Alerts:
 Alert: snmp_alert (path=/var/lib/pacemaker/alert_snmp.sh)
  Meta options: timestamp-format=%Y-%m-%d,%H:%M:%S.%01N.
  Recipients:
   Recipient: snmp_alert-recipient (value=192.168.1.2)

以下の例は、alert_smtp.sh エージェントをインストールし、インストールしたアラートエージェントを使用するアラートを設定して、クラスターイベントを E メールメッセージとして送信します。この例では、アラートの設定後に受信側が設定され、アラート設定が表示されます。

# install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample /var/lib/pacemaker/alert_smtp.sh
# pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com
# pcs alert recipient add smtp_alert value=admin@example.com
# pcs alert
Alerts:
 Alert: smtp_alert (path=/var/lib/pacemaker/alert_smtp.sh)
  Options: email_sender=donotreply@example.com
  Recipients:
   Recipient: smtp_alert-recipient (value=admin@example.com)

26.2. クラスターアラートの作成

次のコマンドは、クラスターアラートを作成します。設定するオプションは、追加の環境変数として指定するパスで、アラートエージェントスクリプトに渡されるエージェント固有の設定値です。id の値を指定しないと、値が生成されます。

pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]

複数のアラートエージェントを設定できます。クラスターは、各イベントに対して、すべてのアラートエージェントを呼び出します。アラートエージェントはクラスターノードでのみ呼び出されます。アラートエージェントは、Pacemaker リモートノードが関係するイベントに対して呼び出されますが、このようなノードでは呼び出されません。

以下の例は、各イベントで myscript.sh を呼び出す簡単なアラートを作成します。

# pcs alert create id=my_alert path=/path/to/myscript.sh

26.3. クラスターアラートの表示、変更、および削除

次のコマンドは、設定されたすべてのアラートと、設定されたオプションの値を表示します。

pcs alert [config|show]

以下のコマンドは、指定した alert-id 値を持つ既存のアラートを更新します。

pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-option=value]...]

次のコマンドは、指定した alert-id 値を持つアラートを削除します。

pcs alert remove alert-id

代わりに pcs alert delete コマンドを実行できます。これは pcs alert remove コマンドと同じです。pcs alert delete コマンドおよび pcs alert remove コマンドの両方を使用すると、複数のアラートを削除できるようになります。

26.4. アラート受信側の設定

通常、アラートは受信側に送信されます。したがって、各アラートには、1 人以上の受信者を追加で設定できます。クラスターは、受信側ごとに別々にエージェントを呼び出します。

受信側は、IP アドレス、メールアドレス、ファイル名、特定のエージェントがサポートするものなど、アラートエージェントが認識できるものを設定します。

次のコマンドは、新しい受信側を指定のアラートに追加します。

pcs alert recipient add alert-id value=recipient-value [id=recipient-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]

次のコマンドは、既存のアラート受信側を更新します。

pcs alert recipient update recipient-id [value=recipient-value] [description=description] [options [option=value]...] [meta [meta-option=value]...]

次のコマンドは、指定のアラート受信側を削除します。

pcs alert recipient remove recipient-id

代わりに、pcs alert recipient delete コマンドを実行できます。これは、pcs alert recipient remove コマンドと同じです。pcs alert recipient remove コマンドおよび pcs alert recipient delete コマンドの両方を使用すると、複数のアラート受信者を削除できます。

次のコマンド例は、受信者 ID が my-recipient-id のアラート受信側 my-alert-recipient を、アラート my-alert に追加します。これにより、クラスターが各イベントの my-alert 用に設定したアラートスクリプトを呼び出すように構成され、受信者 some-address が環境変数として渡されます。

#  pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address

26.5. アラートメタオプション

リソースエージェントと同様に、メタオプションをアラートエージェントに対して設定すると、Pacemaker の呼び出し方法を調整できます。表26.1「アラートメタオプション」では、アラートメタオプションを説明します。メタオプションは、アラートエージェントごと、または受信側ごとに設定できます。

表26.1 アラートメタオプション

メタ属性デフォルト説明

timestamp-format

%H:%M:%S.%06N

イベントのタイムスタンプをエージェントに送信するときにクラスターが使用する形式です。この文字列は date(1) コマンドで使用されます。

timeout

30s

アラートエージェントがこの時間内に完了しないと終了させられます。

以下の例は、myscript.sh スクリプトを呼び出すアラートを設定し、2 つの受信側をアラートに追加します。最初の受信側の ID は my-alert-recipient1 で、2 つ目の受信側の ID は my-alert-recipient2 です。スクリプトは各イベントで 2 回呼び出され、呼び出しのタイムアウト値はそれぞれ 15 秒です。呼び出しの 1 つは受信側 someuser@example.com に渡され、タイムスタンプの形式は %D %H:%M になります。もう 1 つの呼び出しは受信側 otheruser@example.com へ渡され、タイムスタンプの形式は %c になります。

# pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s
# pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta timestamp-format="%D %H:%M"
# pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta timestamp-format="%c"

26.6. アラート設定コマンドの例

以下の例は、基本的なアラート設定コマンドの一部と、アラートの作成、受信側の追加、および設定されたアラートの表示に使用される形式を表しています。

クラスターの各ノードにアラートエージェント自体をインストールする必要がありますが、pcs コマンドを実行する必要があるのは 1 回だけです。

以下のコマンドは簡単なアラートを作成し、アラートに 2 つの受信側を追加した後、設定された値を表示します。

  • アラート ID の値が指定されていないため、alert のアラート ID が作成されます。
  • 最初の受信側作成コマンドは、rec_value の受信側を指定します。このコマンドには受信側 ID が指定されていないため、alert-recipient の値が受信側 ID として使用されます。
  • 2 番目の受信側作成コマンドは、rec_value2 の受信側を指定します。このコマンドは、my-recipient を受信側 ID として指定します。
# pcs alert create path=/my/path
# pcs alert recipient add alert value=rec_value
# pcs alert recipient add alert value=rec_value2 id=my-recipient
# pcs alert config
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)

以下のコマンドは、2 番目のアラートとそのアラートの受信側を追加します。2 番目のアラートのアラート ID は my-alert で、受信側の値は my-other-recipient です。受信側 ID が指定されていないため、my-alert-recipient が受信側 ID として使用されます。

# pcs alert create id=my-alert path=/path/to/script description=alert_description options option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S"
# pcs alert recipient add my-alert value=my-other-recipient
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=value1
  Meta options: timestamp-format=%H%B%S timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)

以下のコマンドは、アラート my-alert と受信側 my-alert-recipient のアラート値を変更します。

# pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"
# pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
   Recipient: my-recipient (value=rec_value2)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format=%H%M%S timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    Options: option1=new
    Meta options: timeout=60s

次のコマンドは、受信側 my-alert-recipientalert から削除します。

# pcs alert recipient remove my-recipient
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)
 Alert: my-alert (path=/path/to/script)
  Description: alert_description
  Options: opt=val option1=newvalue1
  Meta options: timestamp-format="%M%B%S" timeout=50s
  Recipients:
   Recipient: my-alert-recipient (value=my-other-recipient)
    Options: option1=new
    Meta options: timeout=60s

次のコマンドは、設定から myalert を削除します。

# pcs alert remove myalert
# pcs alert
Alerts:
 Alert: alert (path=/my/path)
  Recipients:
   Recipient: alert-recipient (value=rec_value)

26.7. アラートエージェントの作成

Pacemaker アラートには、ノードアラート、フェンスアラート、およびリソースアラートの 3 種類があります。アラートエージェントに渡される環境変数は、アラートの種類によって異なります。表26.2「アラートエージェントに渡される環境変数」には、アラートエージェントに渡される環境変数と、環境変数が特定のアラートタイプに関連付けられるタイミングをまとめています。

表26.2 アラートエージェントに渡される環境変数

環境変数説明

CRM_alert_kind

アラートの種類 (ノード、フェンス、またはリソース)

CRM_alert_version

アラートを送信する Pacemaker のバージョン

CRM_alert_recipient

設定された送信側

CRM_alert_node_sequence

アラートがローカルノードで発行されるたびに増加するシーケンス番号。これは、Pacemaker によりアラートが発行された順序を参照するのに使用できます。後で発生したイベントのアラートは、先に発生したイベントのアラートよりもシーケンス番号が大きくなります。この番号は、クラスター全体を対象とする番号ではないことに注意してください。

CRM_alert_timestamp

timestamp-format メタオプションで指定された形式で、エージェントの実行前に作成されたタイムスタンプ。これにより、エージェントは、エージェント自体が呼び出されたタイミング (システムの負荷やその他の状況により遅延する可能性があります) に関係なく、信頼できる高精度のイベント発生時間を使用できます。

CRM_alert_node

影響を受けるノードの名前

CRM_alert_desc

イベントの詳細。ノードアラートの場合は、ノードの現在の状態 (番号または lost) になります。フェンスアラートの場合は、フェンス操作の要求元、ターゲット、フェンス操作のエラーコードなどを含む要求されたフェンス操作の概要になります。リソースアラートの場合は、CRM_alert_status と同等の読み取り可能な文字列になります。

CRM_alert_nodeid

状態が変更したノードの ID (ノードアラートの場合のみ提供)。

CRM_alert_task

要求されたフェンスまたはリソース操作 (フェンスおよびリソースアラートの場合のみ提供)。

CRM_alert_rc

フェンスまたはリソース操作の数値の戻りコード (フェンスおよびリソースアラートの場合のみ提供)。

CRM_alert_rsc

影響を受けるリソースの名前 (リソースアラートのみ)。

CRM_alert_interval

リソース操作の間隔 (リソースアラートのみ)

CRM_alert_target_rc

操作の予期される数値の戻りコード (リソースアラートのみ)。

CRM_alert_status

Pacemaker が、操作の結果を示すために使用する数値コード (リソースアラートのみ)。

アラートエージェントを記述する際は、以下を考慮する必要があります。

  • アラートエージェントは受信者なしで呼び出されることがあります (受信者が構成されていない場合)。したがって、エージェントは、このような状況では終了しかしない場合でも、この状態に対応できなければなりません。設定を段階的に変更し、後で受信側を追加することもできます。
  • 1 つのアラートに複数の受信側が設定されると、アラートエージェントは受信側ごとに 1 回呼び出されます。エージェントが同時に実行できない場合は、受信側を 1 つのみ設定する必要があります。エージェントは、受信側をリストとして解釈することができます。
  • クラスターイベントの発生時、すべてのアラートは別々のプロセスとして同時に発生します。設定されているアラートと受信者の数、およびアラートエージェント内で行われている内容に応じて、負荷が急激に増加する可能性があります。たとえば、リソースを大量に消費するアクションを直接実行するのではなく、別のインスタンスのキューに追加することで、これを考慮に入れるようにエージェントを作成できます。
  • アラートエージェントは、最低限のパーミッションを持つ hacluster ユーザーで実行します。アラートエージェントに追加のパーミッションが必要な場合は、適切な特権を持つ別のユーザーが、エージェントが必要なコマンドを実行できるように、sudo を設定することが推奨されます。
  • CRM_alert_timestamp (このコンテンツはユーザー設定の timestamp-format によって指定)、CRM_alert_recipient、すべてのアラートオプションなど、ユーザー設定のパラメーターを検証およびサニタイズする場合は十分注意してください。これは、設定エラーから保護するために必要です。また、クラスターノードへの hacluster レベルのアクセスがなくても CIB を変更できるユーザーが存在する場合は、セキュリティーの問題が発生する可能性もあり、コードを挿入できないようにする必要があります。
  • onfail パラメーターが fence に設定されている操作を持つリソースがクラスターに含まれる場合は、障害発生時に複数のフェンス通知 (このパラメーターが設定されているリソースごとに 1 つの通知と、追加の通知 1 つ) が送信されます。pacemaker-fenced および pacemaker-controld の両方が通知を送信します。この場合、送信される通知の数に関係なく、Pacemaker は 1 つのフェンス操作のみを実際に実行します。
注記

アラートインターフェースは、ocf:pacemaker:ClusterMon リソースで使用される外部スクリプトインターフェースと後方互換性を維持するよう設計されています。この互換性を維持するには、先頭に CRM_notify_ および CRM_alert_ が付けいたアラートエージェントに渡される環境変数を使用できます。互換性の問題の 1 つは、アラートエージェントが hacluster ユーザーで実行している最中に、ClusterMon リソースが root ユーザーで外部スクリプトを実行したことです。

第27章 Pacemaker を用いたマルチサイトクラスターの設定

クラスターが複数のサイトにまたがる場合は、サイト間のネットワーク接続の問題が原因でスプリットブレインが発生する可能性があります。接続が切断されたときに、別のサイトのノードで障害が発生したのか、またはサイト間の接続に失敗した状態で別サイトのノードが機能しているかどうかをノードが判断する方法がありません。さらに、同時を維持するには離れすぎている 2 つのサイト間で高可用性サービスを提供することが問題になることがあります。

この問題に対応するため、Pacemaker は、Booth クラスターチケットマネージャーを使用して、複数のサイトにまたがる高可用性クラスターを構成する機能を完全にサポートしています。

27.1. Booth クラスターチケットマネージャーの概要

Booth チケットマネージャー は、特定サイトのクラスターノードを接続するネットワークとは異なる物理ネットワークで実行することを目的とした分散サービスです。それは、サイトの通常のクラスターにある別のゆるいクラスターである Booth フォーメーション を生成します。この集約通信層は、個別の Booth チケットに対して合意ベースの決定プロセスを促進します。

Booth チケット は、Booth フォーメーションのシングルトンで、時間に依存する移動可能な承認の単位を表します。実行には特定のチケットを要求するようにリソースを設定できます。これにより、1 つまたは複数のチケットが付与されているサイトで、リソースは一度に 1 つのサイトでのみ実行されるようになります。

Booth フォーメーションは、複数のサイトで実行しているクラスターで構成され、元のクラスターがすべて独立しているオーバーレイクラスターと考えることができます。チケット付与の有無についてクラスターと通信するのは Booth サービスで、Pacemaker のチケット制約に基づいてクラスターでリソースを実行するかどうかを判断するのは Pacemaker です。これは、チケットマネージャーを使用する場合に、各クラスターが独自のリソースと共有リソースを実行できることを示しています。たとえば、リソース A、B、および C は 1 つのクラスターでのみ実行され、リソース D、E、および F は別のクラスターでのみ実行されるとします。リソース G および H は、チケットによって決定されたこの 2 つのクラスターのいずれかで実行されます。また、別のチケットにより、この 2 つのクラスターのいずれかで実行できるリソース J を追加することもできます。

27.2. Pacemaker を用いたマルチサイトクラスターの設定

以下の手順は、Booth チケットマネージャーを使用するマルチサイト構成を設定する手順の概要を示しています。

ここで使用するコマンド例は以下を前提とします。

  • Cluster 1 は、ノード cluster1-node1 および cluster1-node2 で構成されます。
  • Cluster 1 に割り当てられたフローティング IP アドレスは 192.168.11.100 です。
  • Cluster 2 は、cluster2-node1 および cluster2-node2 で構成されます。
  • Cluster 2 に割り当てられたフローティング IP アドレスは 192.168.22.100 です。
  • 仲裁ノードは arbitrator-node で、IP アドレスは 192.168.99.100 です。
  • この設定が使用する Booth チケットの名前は apacheticket です。

ここで使用するコマンド例は、Apache サービスのクラスターリソースが、各クラスターの apachegroup リソースグループの一部として設定されていることを前提としています。各クラスターの Pacemaker インスタンスは独立しているため、このリソースのチケット制約を設定するために、各クラスターでリソースとリソースグループが同じである必要はありませんが、これはフェールオーバーの一般的な事例になります。

設定手順のどの時点でも、pcs booth config コマンドを実行すると、現在のノードまたはクラスターの Booth 設定を表示できます。また、pcs booth status コマンドを実行すると、ローカルノードの現在の Booth 状態を表示できます。

  1. booth-site Booth チケットマネージャーパッケージを、両方のクラスターの各ノードにインストールします。

    [root@cluster1-node1 ~]# yum install -y booth-site
    [root@cluster1-node2 ~]# yum install -y booth-site
    [root@cluster2-node1 ~]# yum install -y booth-site
    [root@cluster2-node2 ~]# yum install -y booth-site
  2. pcs パッケージ、booth-core パッケージ、および booth-arbitrator パッケージを仲裁ノードにインストールします。

    [root@arbitrator-node ~]# yum install -y pcs booth-core booth-arbitrator
  3. firewalld デーモンを実行している場合は、両方のクラスターのすべてのノードと arbitrator ノードで次のコマンドを実行し、Red Hat High Availability Add-On で必要なポートを有効にします。

    # firewall-cmd --permanent --add-service=high-availability`
    # firewall-cmd --add-service=high-availability`

    ローカルの状況に合わせて開くポートを変更することが必要になる場合があります。Red Hat High-Availability Add-On で必要なポートの詳細は、「High Availability Add-On のポートの有効化」を参照してください。

  4. 1 つのクラスターの 1 つのノードで Booth 設定を作成します。各クラスターおよび仲裁ノードに指定するアドレスは IP アドレスでなければなりません。各クラスターにはフローティング IP アドレスを指定します。

    [cluster1-node1 ~] # pcs booth setup sites 192.168.11.100 192.168.22.100 arbitrators 192.168.99.100

    このコマンドを実行すると、設定ファイルの /etc/booth/booth.conf および /etc/booth/booth.key がノードに作成されます。

  5. Booth 設定のチケットを作成します。このチケットは、このチケットがクラスターに付与された場合のみリソースの実行を許可するリソース抑制を定義するのに使用します。

    このフェイルオーバー設定手順は基本的な手順で、チケットを 1 つだけ使用します。各チケットが別の 1 つ以上のリソースに関連付けられる、より複雑な事例では追加のチケットを作成します。

    [cluster1-node1 ~] # pcs booth ticket add apacheticket
  6. 現在のクラスターのすべてのノードに対して Booth 設定を同期します。

    [cluster1-node1 ~] # pcs booth sync
  7. 仲裁ノードから、Booth 設定を仲裁者へプルします。この作業をこれまで行ったことがない場合は、最初に、設定をプルするノードに pcs を認証する必要があります。

    [arbitrator-node ~] # pcs host auth cluster1-node1
    [arbitrator-node ~] # pcs booth pull cluster1-node1
  8. Booth 設定を別のクラスターにプルし、そのクラスターのすべてのノードを同期します。仲裁ノードでこの作業を行ったことがない場合は、最初に、設定をプルするノードに pcs を認証する必要があります。

    [cluster2-node1 ~] # pcs host auth cluster1-node1
    [cluster2-node1 ~] # pcs booth pull cluster1-node1
    [cluster2-node1 ~] # pcs booth sync
  9. 仲裁ノードで Booth を開始して有効にします。

    注記

    Booth はクラスターで Pacemaker リソースとして実行するため、クラスターのノードで Booth を手動で開始したり有効にしたりしないでください。

    [arbitrator-node ~] # pcs booth start
    [arbitrator-node ~] # pcs booth enable
  10. Booth を設定し、両方のクラスターサイトでクラスターリソースとして実行されるようにします。booth-ip および booth-service をグループのメンバーとするリソースグループが作成されます。

    [cluster1-node1 ~] # pcs booth create ip 192.168.11.100
    [cluster2-node1 ~] # pcs booth create ip 192.168.22.100
  11. 各クラスターに定義したリソースグループにチケット制約を追加します。

    [cluster1-node1 ~] # pcs constraint ticket add apacheticket apachegroup
    [cluster2-node1 ~] # pcs constraint ticket add apacheticket apachegroup

    次のコマンドを実行すると、現在設定されているチケット制約を表示できます。

    pcs constraint ticket [show]
  12. この設定用に作成したチケットを最初のクラスターに付与します。

    チケットを付与する前にチケット抑制を定義する必要はありません。最初にチケットをクラスターに付与した後、pcs booth ticket revoke コマンドで手動でオーバーライドしない限り、Booth はチケットの管理を引き継ぎます。pcs booth 管理コマンドの詳細は、pcs booth コマンドの PCS ヘルプ画面を参照してください。

    [cluster1-node1 ~] # pcs booth ticket grant apacheticket

チケットは、いつでも (この手順の完了後でも) 追加および削除できます。ただし、チケットを追加または削除した後、この手順の説明どおりに、他のノード、クラスター、および仲裁ノードに対して構成ファイルを同期し、チケットを付与する必要があります。

Booth 設定ファイル、チケット、およびリソースのクリーンアップや削除に使用できるその他の Booth 管理コマンドに関する情報は、pcs booth コマンドの PCS ヘルプ画面を参照してください。

第28章 corosync 以外のノードのクラスターへの統合: pacemaker_remote サービス

pacemaker_remote サービスを使用すると、corosync を実行していないノードをクラスターに統合し、そのリソースが実際のクラスターノードであるかのように、クラスターがリソースを管理できます。

pacemaker_remote サービスが提供する機能には以下が含まれます。

  • pacemaker_remote サービスを使用すると、RHEL 8.1 の 32 ノードのサポート制限を超えた拡張が可能になります。
  • pacemaker_remote サービスを使用すると、仮想環境をクラスターリソースとして管理でき、さらに仮想環境内の個別のサービスをクラスターリソースとして管理できます。

pacemaker_remote サービスは、以下の用語を使用して記述されます。

  • クラスターノード - 高可用性サービスを実行しているノード (pacemaker および corosync)。
  • リモートノード - pacemaker_remote を実行して、corosync クラスターメンバーシップを必要としないクラスターにリモートで統合するノード。リモートノードは、ocf:pacemaker:remote リソースエージェントを使用するクラスターリソースとして設定されます。
  • ゲストノード - pacemaker_remote サービスを実行する仮想ゲストノード。仮想ゲストリソースはクラスターにより管理されます。クラスターにより起動し、リモートノードとしてクラスターに統合されます。
  • pacemaker_remote - Pacemaker クラスター環境のリモートノードおよび KVM ゲストノードでリモートアプリケーション管理を実行できるサービスデーモン。このサービスは、corosync を実行していないノードでリソースをリモートで管理できる Pacemaker のローカル実行プログラムデーモン (pacemaker-execd) の拡張バージョンです。

pacemaker_remote サービスを実行している Pacemaker クラスターには次のような特徴があります。

  • リモートノードおよびゲストノードは、pacemaker_remote サービスを実行します (仮想マシン側で必要な設定はほとんどありません)。
  • クラスターノードで実行しているクラスタースタック (pacemaker および corosync) はリモートノードで pacemaker_remote サービスに接続するため、クラスターに統合できます。
  • クラスターノードで実行しているクラスタースタック (pacemaker および corosync) はゲストノードを開始し、ゲストノードで pacemaker_remote サービスに即座に接続するため、クラスターに統合できます。

クラスターノードと、クラスターノードが管理するリモートおよびゲストノードの主な違いは、リモートおよびゲストノードはクラスタースタックを実行しないことです。そのため、リモートおよびゲストノードには以下の制限があります。

  • クォーラムでは実行されない
  • フェンスデバイスの動作を実行しない
  • クラスターの指定コントローラー (DC) として機能できない
  • pcs コマンドは一部しか実行できない

その一方で、リモートノードおよびゲストノードは、クラスタースタックに関連するスケーラビリティーの制限に拘束されません。

このような制限事項以外に、リモートノードとゲストノードは、リソース管理に関してクラスターノードと同様に動作し、リモートノードとゲストノード自体をフェンスすることができます。クラスターは、各リモートノードおよびゲストノードのリソースを完全に管理し、監視できます。このようなノードに制約を作成したり、ノードをスタンバイ状態にできます。または、pcs コマンドを使用して、クラスターノードでその他の動作を実行することもできます。リモートノードおよびゲストノードは、クラスターノードと同様にクラスターステータスの出力に表示されます。

28.1. pacemaker_remote ノードのホストおよびゲストの認証

クラスターノードと pacemaker_remote の間の接続には、TLS (Transport Layer Security) が使用され、PSK (Pre-Shared Key) の暗号化と TCP 上の認証 (デフォルトで 3121 ポートを使用) でセキュア化されます。そのため、クラスターノードと、pacemaker_remote を実行しているノードは、同じ秘密鍵を共有する必要があります。デフォルトでは、クラスターノードとリモートノードの両方でこのキーを /etc/pacemaker/authkey に配置する必要があります。

pcs cluster node add-guest コマンドは、ゲストノードに authkey を設定し、pcs cluster node add-remote コマンドは、リモートノードに authkey を設定します。

28.2. KVM ゲストノードの設定

Pacemaker ゲストノードは、pacemaker_remote サービスを実行する仮想ゲストノードです。仮想ゲストノードはクラスターにより管理されます。

28.2.1. ゲストノードリソースのオプション

ゲストノードとして動作するように仮想マシンを設定する場合は、仮想マシンを管理する VirtualDomain リソースを作成します。VirtualDomain リソースに設定できるオプションの説明は、表24.1「仮想ドメインリソースのリソースオプション」を参照してください。

VirtualDomain リソースオプションのほかにも、メタデータオプションはリソースをゲストノードとして定義し、接続パラメーターを定義します。pcs cluster node add-guest コマンドを使用して、これらのリソースオプションを設定します。表28.1「KVM リソースをリモートノードとして設定するためのメタデータオプション」 では、これらのメタデータオプションを説明します。

表28.1 KVM リソースをリモートノードとして設定するためのメタデータオプション

フィールドデフォルト説明

remote-node

<none>

このリソースが定義するゲストノードの名前。リソースをゲストノードとして有効にし、ゲストノードの識別に使用される一意名を定義します。警告: この値を、リソースやノードの ID と重複させることはできません。

remote-port

3121

pacemaker_remote へのゲスト接続に使用するカスタムのポートを設定します。

remote-addr

pcs host auth コマンドで指定されるアドレス

接続先の IP アドレスまたはホスト名

remote-connect-timeout

60s

保留中のゲスト接続がタイムアウトするまでの時間

28.2.2. 仮想マシンのゲストノードとしての統合

以下の手順では、libvirt と KVM 仮想ゲストを使用して、Pacemaker で仮想マシンを起動し、そのマシンをゲストノードとして統合する手順の概要を説明します。

  1. VirtualDomain リソースを設定します。
  2. すべての仮想マシンで次のコマンドを実行し、pacemaker_remote パッケージをインストールし、pcsd サービスを起動し、これを起動時に実行できるようにし、ファイアウォールを介して、TCP の 3121 ポートを許可します。

    # yum install pacemaker-remote resource-agents pcs
    # systemctl start pcsd.service
    # systemctl enable pcsd.service
    # firewall-cmd --add-port 3121/tcp --permanent
    # firewall-cmd --add-port 2224/tcp --permanent
    # firewall-cmd --reload
  3. 各仮想マシンに、すべてのノードが認識できる静的ネットワークアドレスと一意なホスト名を割り当てます。ゲスト仮想マシンに静的 IP アドレスを設定する方法は『仮想化の導入および管理ガイド』を参照してください。
  4. ゲストノードとして統合しようとしているノードに pcs を認証していない場合は認証します。

    # pcs host auth nodename
  5. 次のコマンドを使用して、既存の VirtualDomain リソースをゲストノードに変換します。このコマンドは、追加するゲストノードではなく、クラスターノードで実行する必要があります。リソースを変換する以外にも、このコマンドは /etc/pacemaker/authkey をゲストノードにコピーし、ゲストノードで pacemaker_remote デーモンを起動して有効にします。任意に定義できるゲストノードのノード名は、ノードのホスト名とは異なる場合があります。

    # pcs cluster node add-guest nodename resource_id [options]
  6. VirtualDomain リソースの作成後は、クラスターの他のノードと同じように、ゲストノードを扱うことができます。たとえば、クラスターノードから実行される次のコマンドのように、リソースを作成し、リソースにリソース制約を設定してゲストノードで実行できます。ゲストノードはグループに追加できます。これにより、ストレージデバイス、ファイルシステム、および仮想マシンをグループ化できます。

    # pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
    # pcs constraint location webserver prefers nodename

28.3. Pacemaker リモートノードの設定

リモートノードは、ocf:pacemaker:remote がリソースエージェントとして指定された状態で、クラスターリソースとして定義されます。pcs cluster node add-remote コマンドを使用してこのリソースを作成します。

28.3.1. リモートノードリソースのオプション

表28.2「リモートノードのリソースオプション」は、remote リソースに設定できるリソースオプションを説明します。

表28.2 リモートノードのリソースオプション

フィールドデフォルト説明

reconnect_interval

0

リモートノードへのアクティブな接続が切断された後、リモートノードへの再接続を試みる前に待機する時間 (秒単位)。この待機期間は繰り返し発生します。待機期間の後に再接続に失敗した場合、待機期間の後に、新しい再接続が試行されます。このオプションが使用されると、Pacemaker は待機期間の後に無限にリモートノードへ接続を試みます。

server

pcs host auth コマンドで指定されるアドレス

接続するサーバーの場所。IP アドレスまたはホスト名を指定できます。

port

 

接続する TCP ポート。

28.3.2. リモートノードの設定の概要

本セクションでは、Pacemaker リモートノードを設定し、そのノードを既存の Pacemaker クラスター環境に統合する手順の概要を説明します。

  1. リモートノードを設定するノードで、ローカルファイアウォールを介してクラスター関連のサービスを許可します。

    # firewall-cmd --permanent --add-service=high-availability
    success
    # firewall-cmd --reload
    success
    注記

    iptables を直接使用する場合や、firewalld 以外のファイアウォールソリューションを使用する場合は、単に TCP のポート 2224 および 3121 を開きます。

  2. リモートノードに、pacemaker_remote デーモンをインストールします。

    # yum install -y pacemaker-remote resource-agents pcs
  3. リモートノードで、pcsd を開始し、有効にします。

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  4. リモートノードとして追加するノードに pcs を認証していない場合は、認証します。

    # pcs host auth remote1
  5. 以下のコマンドを使用して、リモートノードリソースをクラスターに追加します。このコマンドは、関連するすべての設定ファイルを新規ノードに追加し、ノードを起動し、これをシステムの起動時に pacemaker_remote を開始するように設定することもできます。このコマンドは、追加するリモートノードではなく、クラスターノードで実行する必要があります。

    # pcs cluster node add-remote remote1
  6. remote リソースをクラスターに追加した後、リモートノードを、クラスター内の他のノードを処理するのと同じように処理できます。たとえば、以下のコマンドをクラスターノードから実行すると、リソースを作成し、そのリソースにリソース制約を配置して、リモートノードで実行できます。

    # pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s
    # pcs constraint location webserver prefers remote1
    警告

    リソースグループ、コロケーション制約、または順序制約でノード接続リソースを利用しないでください。

  7. リモートノードのフェンスリソースを設定します。リモートノードは、クラスターノードと同じ方法でフェンスされます。クラスターノードと同様に、リモートノードで使用するフェンスリソースを設定します。リモートノードはフェンスアクションを開始できないことに注意してください。クラスタノードのみが、実際に別のノードに対してフェンシング操作を実行できます。

28.4. ポートのデフォルトの場所の変更

Pacemaker または pacemaker_remote のいずれかのポートのデフォルトの場所を変更する必要がある場合は、これらのデーモンのどちらにも影響を与える PCMK_remote_port 環境変数を設定できます。この環境変数は、以下のように /etc/sysconfig/pacemaker に配置して有効にできます。

====# Pacemaker Remote
...
#
# Specify a custom port for Pacemaker Remote connections
PCMK_remote_port=3121

特定のゲストノードまたはリモートノードで使用されるデフォルトのポートを変更する場合は、PCMK_remote_port 変数を、そのノードの /etc/sysconfig/pacemaker ファイルに設定する必要があります。また、ゲストノードまたはリモートノードの接続を作成するクラスターリソースを、同じポート番号で設定する必要もあります (ゲストノードの場合は remote-port メタデータオプション、リモートノードの場合は port オプションを使用します)。

28.5. pacemaker_remote ノードを含むシステムのアップグレード

アクティブな Pacemaker リモートノードで pacemaker_remote サービスが停止すると、クラスターは、ノードの停止前に、リソースをノードから正常に移行します。これにより、クラスターからノードを削除せずに、ソフトウェアのアップグレードやその他の定期的なメンテナンスを実行できるようになりました。ただし、pacemaker_remote がシャットダウンすると、クラスターは即座に再接続を試みます。リソースの監視タイムアウトが発生する前に pacemaker_remote が再起動しないと、クラスターは監視操作が失敗したと判断します。

アクティブな Pacemaker リモートノードで、pacemaker_remote サービスが停止したときに監視が失敗しないようにするには、以下の手順に従って、pacemaker_remote を停止する可能性があるシステム管理を実行する前に、ノードをクラスターから削除します。

  1. ノードからすべてのサービスを移行する pcs resource disable resourcename を使用して、ノードの接続リソースを停止します。ゲストノードの場合は、仮想マシンも停止するため、(virsh などを使用して) 仮想マシンをクラスターの外部で起動し、メンテナンスを実行する必要があります。
  2. 必要なメンテナンスを実行します。
  3. ノードをクラスターに戻す準備ができたら、pcs resource enable でリソースを再度有効にします。

第29章 クラスターメンテナンスの実行

クラスターのノードでメンテナンスを実行するには、そのクラスターで実行しているリソースおよびサービスを停止するか、または移行する必要がある場合があります。または、サービスを変更しない状態で、クラスターソフトウェアの停止が必要になる場合があります。Pacemaker は、システムメンテナンスを実行するための様々な方法を提供します。

  • クラスターの別のノードでサービスが継続的に実行している状態で、クラスター内のノードを停止する必要がある場合は、そのクラスターノードをスタンバイモードにすることができます。スタンバイノードのノードは、リソースをホストすることができなくなります。ノードで現在アクティブなリソースは、別のノードに移行するか、(他のノードがそのリソースを実行できない場合は) 停止します。スタンドバイモードの詳細は「ノードをスタンバイモードにする」を参照してください。
  • リソースを停止せずに、現在実行しているノードから個別のリソースを移行する必要がある場合は、pcs resource move コマンドを使用してリソースを別のノードに移行できます。pcs resource move コマンドの詳細は、「クラスターリソースの手動による移行」を参照してください。

    pcs resource move コマンドを実行すると、現在実行しているノードでそれが実行されないように、制約がリソースに追加されます。リソースを戻す準備ができたら、pcs resource clear コマンドまたは pcs constraint delete コマンドを実行して制約を削除できます。ただし、このコマンドを実行しても、リソースが必ずしも元のノードに戻る訳ではありません。その時点でリソースが実行できる場所は、リソースを最初に設定した方法によって異なるためです。「リソースを優先ノードへ移行」に従って、pcs resource relocate run コマンドを実行して、リソースを優先ノードに移動できます。

  • 実行中のリソースを完全に停止し、クラスターが再び起動しないようにする必要がある場合は、pcs resource disable コマンドを使用できます。pcs resource disable コマンドの詳細は、「クラスターリソースの有効化、無効化、および禁止」を参照してください。
  • Pacemaker が、リソースに対して何らかのアクションを実行しないようにする場合 (たとえば、リソースのメンテナンス中に復元アクションを無効にする場合や、/etc/sysconfig/pacemaker 設定をリロードする必要がある場合) は、「リソースの非管理モードへの設定」で説明されているように pcs resource unmanage コマンドを使用します。Pacemaker Remote 接続リソースは、非管理モードにしないでください。
  • クラスターを、サービスの開始や停止が行われない状態にする必要がある場合は、maintenance-mode クラスタープロパティーを設定できます。クラスターをメンテナンスモードにすると、すべてのリソースが自動的に非管理モードになります。メンテナンスモードのクラスターの詳細は「クラスターをメンテナンスモードに」を参照してください。
  • RHEL High Availability Add-On および Resilient Storage Add-On に含まれるパッケージを更新する必要がある場合は、「Red Hat Enterprise Linux High Availability クラスターの更新」で説明されているように、一度に 1 つのパッケージを更新するか、または全体のクラスターに対して更新を行うことができます。
  • Pacemaker リモートノードでメンテナンスを実行する必要がある場合は、「リモートノードおよびゲストノードのアップグレード」で説明されているように、リモートノードリソースを無効にすることで、ノードをクラスターから削除できます。

29.1. ノードをスタンバイモードに

クラスターノードがスタンバイモードになると、ノードがリソースをホストできなくなります。ノードで現在アクティブなリソースは、すべて別のノードに移行されます。

以下のコマンドは、指定ノードをスタンバイモードにします。--all を指定すると、このコマンドはすべてのノードをスタンバイモードにします。

このコマンドは、リソースのパッケージを更新する場合に使用できます。また、設定をテストして、ノードを実際にシャットダウンせずに復元のシュミレーションを行う場合にも、このコマンドを使用できます。

pcs node standby node | --all

次のコマンドは、指定したノードをスタンバイモードから外します。このコマンドを実行すると、指定ノードはリソースをホストできるようになります。--all を指定すると、このコマンドはすべてのノードをスタンバイモードから外します。

pcs node unstandby node | --all

pcs resource ban コマンドを実行すると、指定されたノードでリソースが実行されないことに注意してください。pcs node unstandby コマンドを実行すると、指定されたノードでリソースを実行できます。このコマンドを実行しても、リソースが必ずしも指定のノードに戻る訳ではありません。その時点でリソースが実行できる場所は、リソースを最初に設定した方法によって異なります。

29.2. クラスターリソースの手動による移行

クラスターの設定を無視して、強制的にリソースを現在の場所から移行させることができます。次のような 2 つの状況が考えられます。

  • ノードがメンテナンスで、そのノードで実行中の全リソースを別のノードに移行する必要がある
  • 個別に指定したリソースを移行する必要がある

ノードで実行中の全リソースを別のノードに移行する場合は、そのノードをスタンバイモードにします。

個別に指定したリソースは、以下のいずれかの方法で移行できます。

  • pcs resource move コマンドを使用して、現在実行しているノードからリソースを移行できます。
  • pcs resource relocate run コマンドを使用して、現在のクラスターのステータス、制約、リソースの場所、およびその他の設定により決定される優先ノードへ、リソースを移行します。

29.2.1. 現在のノードからのリソースの移動

現在実行しているノードからリソースを移動するには、以下のコマンドを使用して、リソースの resource_id を定義どおりに指定します。移行するリソースを実行する移行先のノードを指定する場合は、destination_node を使用します。

pcs resource move resource_id [destination_node] [--master] [lifetime=lifetime]
注記

pcs resource move コマンドを実行すると、現在実行しているノードでそれが実行されないように、制約がリソースに追加されます。pcs resource clear コマンドまたは pcs constraint delete コマンドを実行すると、制約を削除できます。このコマンドを実行しても、リソースが必ずしも元のノードに戻る訳ではありません。この時点でリソースが実行できる場所は、リソースの最初の設定方法によって異なります。

pcs resource move コマンドの --master パラメーターを指定すると、制約の範囲がマスターロールに限定され、resource_id の代わりに master_id を指定する必要があります。

任意で pcs resource move コマンドの lifetime パラメーターを設定すると、制限が維持される期間を指定できます。lifetime パラメーターの単位は、ISO 8601 に定義されている形式に従って指定します。ISO 8601 では、Y (年)、M (月)、W (週)、D (日)、H (時)、M (分)、S (秒) のように、単位を大文字で指定する必要があります。

分単位の M と、月単位の M を区別するには、分単位の値の前に PT を指定する必要があります。たとえば、lifetime パラメーターが 5M の場合は 5 カ月の間隔を示し、PT5M の場合は 5 分の間隔を示します。

lifetime パラメーターは、cluster-recheck-interval クラスタープロパティーに定義した間隔で確認されます。デフォルト値は 15 分です。このパラメーターをより頻繁に確認する必要がある場合は、次のコマンドを実行して、この値をリセットできます。

pcs property set cluster-recheck-interval=value

任意で、pcs resource move コマンドに --wait[=n] パラメーターを設定し、移行先のノードでリソースが起動するまでの待機時間 (秒単位) を指定できます。待機時間がこの値を超えると、リソースが起動した場合に 0 が返され、リソースが起動しなかった場合は 1 が返されます。n の値を指定しないと、デフォルトのリソースのタイムアウト値が使用されます。

以下のコマンドは、resource1 リソースを example-node2 ノードへ移動し、1 時間 30 分は元のノードへ戻らないようにします。

pcs resource move resource1 example-node2 lifetime=PT1H30M

以下のコマンドは、resource1 リソースを example-node2 ノードへ移行し、30 分は元のノードへ戻らないようにします。

pcs resource move resource1 example-node2 lifetime=PT30M

29.2.2. リソースを優先ノードへ移行

フェイルオーバーや管理者の手作業によるノードの移行により、リソースが移行した後、フェイルオーバーの原因となった状況が改善されたとしても、そのリソースが必ずしも元のノードに戻るとは限りません。リソースを優先ノードへ移行するには、以下のコマンドを実行します。優先ノードは、現在のクラスター状態、制約、リソースの場所、およびその他の設定により決定され、時間とともに変更する可能性があります。

pcs resource relocate run [resource1] [resource2] ...

リソースを指定しないと、すべてのリソースが優先ノードに移行します。

このコマンドは、リソースのスティッキネスを無視し、各リソースの優先ノードを算出します。優先ノードの算出後、リソースを優先ノードに移行する場所の制約を作成します。リソースが移行すると、制約が自動的に削除されます。pcs resource relocate run コマンドにより作成された制約をすべて削除するには、pcs resource relocate clear コマンドを実行します。リソースの現在の状態と、リソースのスティッキネスを無視した最適なノードを表示する場合は、pcs resource relocate show コマンドを実行します。

29.3. クラスターリソースの無効化、有効化、および禁止

pcs resource move コマンドや pcs resource relocate コマンドのほかにも、クラスターリソースの動作を制御するのに使用できる様々なコマンドがあります。

クラスターリソースの無効化

実行中のリソースを手動で停止し、クラスターが再起動しないようにする場合は、以下のコマンドを使用します。その他の設定 (制約、オプション、失敗など) によっては、リソースが起動した状態のままになる可能性があります。--wait オプションを指定すると、pcs はリソースが停止するまで「n」秒間待機します。その後、リソースが停止した場合は 0 を返し、リソースが停止しなかった場合は 1 を返します。「n」を指定しないと、デフォルトの 60 分に設定されます。

pcs resource disable resource_id [--wait[=n]]

Red Hat Enterprise Linux 8.2 では、リソースを無効にしても、他のリソースに影響が及ばない場合に限り、リソースを無効にできます。これを確認することは、複雑なリソース関係が設定されている場合は手作業では不可能です。

  • pcs resource disable --simulate コマンドは、クラスター設定を変更せずに、リソースを無効にする効果を表示します。
  • pcs resource disable --safe コマンドは、あるノードから別のノードに移行されるなど、その他のリソースが何らかの影響を受けない場合にのみリソースを無効にします。pcs resource safe-disable コマンドは、pcs resource disable --safe コマンドのエイリアスです。
  • pcs resource disable --safe --no-strict コマンドは、他のリソースが停止または降格されない場合に限りリソースを無効にします。

クラスターリソースの有効化

クラスターがリソースを起動できるようにするには、次のコマンドを使用します。他の設定によっては、リソースが停止したままになることがありす。--wait オプションを指定すると、pcs はリソースが開始するまで最長で「n」秒間待機します。その後、リソースが開始した場合には 0、リソースが開始しなかった場合には 1 を返します。「n」を指定しないと、デフォルトの 60 分に設定されます。

pcs resource enable resource_id [--wait[=n]]

特定のノードでリソースが実行されないようにする

指定したノードでリソースが実行されないようにする場合は、次のコマンドを使用します。ノードを指定しないと、現在実行中のノードでリソースが実行されないようになります。

pcs resource ban resource_id [node] [--master] [lifetime=lifetime] [--wait[=n]]

pcs resource ban コマンドを実行すると、場所の制約である -INFINITY がリソースに追加され、リソースが指定のノードで実行されないようにします。pcs resource clear コマンドまたは pcs constraint delete コマンドを実行すると、制約を削除できます。このコマンドを実行しても、リソースが必ずしも指定のノードに戻る訳ではありません。その時点でリソースが実行できる場所は、リソースを最初に設定した方法によって異なります。

pcs resource ban コマンドの --master パラメーターを指定すると、制約の範囲がマスターロールに限定され、resource_id の代わりに master_id を指定する必要があります。

任意で pcs resource ban コマンドに lifetime パラメーターを設定し、制約が持続する期間を指定できます。

任意で、pcs resource ban コマンドに --wait[=n] パラメーターを設定し、移行先のノードでリソースが起動するまでの待機時間 (秒単位) できます。待機時間がこの値を超えると、リソースが起動した場合に 0 が返され、リソースが起動しなかった場合は 1 が返されます。n の値を指定しないと、デフォルトのリソースのタイムアウト値が使用されます。

現在のノードでリソースを強制的に起動

指定したリソースを現在のノードで強制的に起動する場合は、pcs resource コマンドの debug-start パラメーターを使用します。この場合、クラスターの推奨は無視され、起動しているリソースからの出力が表示されます。これは、主にデバッグリソースに使用されます。クラスターでのリソースの起動は (ほぼ) 毎回 Pacemaker で行われるため、直接 pcs コマンドを使用した起動は行われません。リソースが起動しない原因は、大抵、リソースが誤って設定されているか (システムログでデバッグします)、リソースが起動しないように制約が設定されているか、リソースが無効になっているかのいずれかになります。この場合は、次のコマンドを使用してリソースの設定をテストできます。ただし、通常は、クラスター内でリソースを起動するのに使用しないでください。

debug-start コマンドの形式は以下のようになります。

pcs resource debug-start resource_id

29.4. リソースの非管理モードへの設定

リソースが 非管理 モードの場合、リソースは引き続き設定に含まれますが、Pacemaker はこのリソースを管理しません。

以下のコマンドは、指定のリソースを 非管理 モードに設定します。

pcs resource unmanage resource1  [resource2] ...

以下のコマンドは、リソースをデフォルトの 管理 モードに設定します。

pcs resource manage resource1  [resource2] ...

pcs resource manage コマンドまたは pcs resource unmanage コマンドを使用して、リソースグループの名前を指定できます。このコマンドは、グループのすべてのリソースに対して実行されるため、1 つのコマンドでグループ内の全リソースすべて 管理 または 非管理 モードに設定し、グループに含まれるリソースを個別に管理できます。

29.5. クラスターをメンテナンスモードに

クラスターがメンテナンスモードの場合、クラスターは指示されない限り、サービスを開始したり、停止したりしません。メンテナンスモードが完了すると、クラスターは、サービスの現在の状態のサニティーチェックを実行してから、これを必要とするサービスを停止するか、または開始します。

クラスターをメンテナンスモードにするには、以下のコマンドを使用して、maintenance-mode クラスタープロパティーを true に設定します。

# pcs property set maintenance-mode=true

クラスターをメンテナンスモードから外すには、次のコマンドを使用して、maintenance-mode クラスタープロパティーを false に設定します。

# pcs property set maintenance-mode=false

設定からクラスタープロパティーを削除するには、次のコマンドを実行します。

pcs property unset property

または、pcs property set コマンドの値フィールドを空白にしても、クラスタープロパティーを設定から削除できます。これにより、そのプロパティーの値がデフォルト値に戻されます。たとえば、symmetric-cluster プロパティーを false に設定したことがある場合は、設定した値が次のコマンドにより削除され、symmetric-cluster の値がデフォルト値の true に戻されます。

# pcs property set symmetric-cluster=

29.6. RHEL 高可用性クラスターの更新

RHEL High Availability Add-On および Resilient Storage Add-On を構成するパッケージを、個別または一括で更新するには、以下に示す一般的な方法のいずれかを使用できます。

  • ローリングアップデート - サービスからノードを、一度に 1 つずつ削除し、そのソフトウェアを更新してから、そのノードをクラスターに戻します。これにより、各ノードの更新中も、クラスターがサービスの提供とリソースの管理を継続できます。
  • クラスター全体の更新 - クラスター全体を停止し、更新をすべてのノードに適用してから、クラスターのバックアップを開始します。
警告

Red Hat Enterprise LInux の High Availability クラスターおよび Resilient Storage クラスターのソフトウェア更新手順を実行する場合は、更新を開始する前に、更新を行うノードがクラスターのアクティブなメンバーではないことを確認する必要があります。

これらの各方法の詳細な説明および更新手順は「Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster」を参照してください。

29.7. リモートノードおよびゲストノードのアップグレード

アクティブなリモートノードまたはゲストノードで pacemaker_remote サービスが停止すると、クラスターは、ノードを停止する前に、ノードからリソースを適切に移行します。これにより、クラスターからノードを削除せずに、ソフトウェアのアップグレードやその他の定期的なメンテナンスを実行できるようになりました。ただし、pacemaker_remote がシャットダウンすると、クラスターは即座に再接続を試みます。リソースの監視タイムアウトが発生する前に pacemaker_remote が再起動しないと、クラスターは監視操作が失敗したと判断します。

アクティブな Pacemaker リモートノードで、pacemaker_remote サービスが停止したときに監視が失敗しないようにするには、以下の手順に従って、pacemaker_remote を停止する可能性があるシステム管理を実行する前に、ノードをクラスターから削除します。

  1. ノードからすべてのサービスを移行する pcs resource disable resourcename を使用して、ノードの接続リソースを停止します。ゲストノードの場合は、仮想マシンも停止するため、(virsh などを使用して) 仮想マシンをクラスターの外部で起動し、メンテナンスを実行する必要があります。
  2. 必要なメンテナンスを実行します。
  3. ノードをクラスターに戻す準備ができたら、pcs resource enable でリソースを再度有効にします。

29.8. RHEL クラスターでの仮想マシンの移行

仮想化クラスターメンバーそ使用する RHEL 高可用性クラスターのサポートポリシーに関する情報は、「Support Policies for RHEL High Availability Clusters - General Conditions with Virtualized Cluster Members」を参照してください。前述のように、Red Hat はハイパーバイザーまたはホスト全体のアクティブなクラスターノードのライブマイグレーションをサポートしていません。ライブマイグレーションを実行する必要がある場合は、まず仮想マシンでクラスターサービスを停止してクラスターからノードを削除し、移行後にクラスターのバックアップを開始する必要があります。以下の手順では、クラスターから仮想マシンを削除し、仮想マシンを移行し、クラスターに仮想マシンを復元する手順の概要を説明します。

この手順は、完全なクラスターノードとして使用される仮想マシンに適用され、クラスターリソース (ゲストノードとして使用される仮想マシンを含む) として、特別な予防措置なしにライブマイグレーションが可能な仮想マシンには適用されません。RHEL High Availability および Resilient Storage Add-On を構成するパッケージを更新するのに必要な一般的な手順は、「RHEL 高可用性またはレジリエントストレージクラスターにソフトウェアアップデートを適用するのに推奨されるプラクティス」を参照してください。

注記

この手順を実行する前に、クラスターノードを削除するクラスタークォーラム (定足数) への影響を考慮してください。たとえば、3 ノードクラスターがあり、ノードを 1 つ削除すると、クラスターはさらに 1 つのノード障害にしか対応できません。3 ノードクラスターの 1 つのノードがすでにダウンしている場合は、2 番目のノードを削除するとクォーラムが失われます。

  1. 移行する仮想マシンで実行しているリソースやソフトウェアの停止または移動を行う前に準備を行う必要がある場合は、以下の手順を実行します。
  2. 仮想マシンで以下のコマンドを実行して、仮想マシン上のクラスターソフトウェアを停止します。

    # pcs cluster stop
  3. 仮想マシンのライブマイグレーションを実行します。
  4. 仮想マシンでクラスターサービスを起動します。

    # pcs cluster start

第30章 障害復旧クラスターの設定

高可用性クラスターに障害復旧を提供する 1 つの方法は、2 つのクラスターを構成することです。次に、1 つのクラスターをプライマリーサイトクラスターとして構成し、2 番目のクラスターを災害復旧クラスターとして構成できます。

通常の場合、プライマリークラスターは実稼働モードでリソースが実行されている状態です。障害復旧クラスターにはすべてのリソースが設定されており、それらを降格モードで実行するか、または全く実行しません。たとえば、昇格モードでプライマリークラスターで実行され、降格モードで障害復旧クラスターで実行されているデータベースがあるとします。この設定のデータベースが、プライマリーから障害復旧サイトにデータが同期されるように設定されます。これは、pcs コマンドインターフェースではなく、データベース設定自体で行われます。

プライマリークラスターがダウンした場合、ユーザーは pcs コマンドラインインターフェースを使用して、手動でリソースを障害復旧サイトにフェイルオーバーできます。その後、障害のサイトにログインして、そのサイトを昇格し、そこでリソースを起動できます。プライマリークラスターが復元した後、pcs コマンドラインインターフェースを使用してリソースをプライマリーサイトに手動で移動できます。

Red Hat Enterprise Linux 8.2 以降では、pcs コマンドを使用して、いずれかのサイトの 1 つのノードから、プライマリーおよび障害復旧サイトクラスターの両方のステータスを表示できます。

30.1. 障害復旧クラスターに関する考慮事項

pcs コマンドラインインターフェースで管理および監視を行う障害復旧サイトの計画および構成を行うときは、次の考慮事項に注意してください。

  • 障害復旧サイトはクラスターである必要があります。これにより、プライマリーサイトと同じツールや同様の手順で設定できるようになります。
  • プライマリークラスターおよび障害復旧クラスターは、独立した pcs cluster setup コマンドで作成されます。
  • クラスターとそのリソースは、データが同期され、フェイルオーバーが可能になるように設定する必要があります。
  • 復旧サイトのクラスターノードには、プライマリーサイトのノードと同じ名前を持つことができません。
  • pcs コマンドを実行するノードの両方のクラスターに対して、pcs ユーザー hacluster が認証されている必要があります。

30.2. 復旧クラスターの状態の表示 (RHEL 8.2 以降)

両方のクラスターのステータスを表示できるように、プライマリークラスターおよび障害復旧クラスターを設定するには、次の手順を実行します。

注記

障害復旧クラスターを設定すると、自動的にリソースを設定したり、データを複製したりしません。これらのアイテムはユーザーが手動で設定する必要があります。

この例では、以下のように設定されています。

  • プライマリークラスターは PrimarySite という名前で、z1.example.com ノードと z2.example.com ノードで構成されます。
  • 障害復旧サイトのクラスターは DRsite という名前で、z3.example.com ノードおよび z4.example.com ノードで構成されます。

この例では、リソースやフェンスが設定されていない基本的なクラスターを設定します。

  1. 両方のクラスターで使用されるすべてのノードを認証します。

    [root@z1 ~]# pcs host auth z1.example.com z2.example.com z3.example.com z4.example.com -u hacluster -p password
    z1.example.com: Authorized
    z2.example.com: Authorized
    z3.example.com: Authorized
    z4.example.com: Authorized
  2. プライマリークラスターとして使用されるクラスターを作成し、クラスターのクラスターサービスを開始します。

    [root@z1 ~]# pcs cluster setup PrimarySite z1.example.com z2.example.com --start
    {...}
    Cluster has been successfully set up.
    Starting cluster on hosts: 'z1.example.com', 'z2.example.com'...
  3. 障害復旧クラスターとして使用されるクラスターを作成し、クラスターのクラスターサービスを開始します。

    [root@z1 ~]# pcs cluster setup DRSite z3.example.com z4.example.com --start
    {...}
    Cluster has been successfully set up.
    Starting cluster on hosts: 'z3.example.com', 'z4.example.com'...
  4. プライマリークラスターのノードから、2 つ目のクラスターを復旧サイトとして設定します。復旧サイトは、ノードのいずれかの名前により定義されます。

    [root@z1 ~]# pcs dr set-recovery-site z3.example.com
    Sending 'disaster-recovery config' to 'z3.example.com', 'z4.example.com'
    z3.example.com: successful distribution of the file 'disaster-recovery config'
    z4.example.com: successful distribution of the file 'disaster-recovery config'
    Sending 'disaster-recovery config' to 'z1.example.com', 'z2.example.com'
    z1.example.com: successful distribution of the file 'disaster-recovery config'
    z2.example.com: successful distribution of the file 'disaster-recovery config'
  5. 障害復旧設定を確認します。

    [root@z1 ~]# pcs dr config
    Local site:
      Role: Primary
    Remote site:
      Role: Recovery
      Nodes:
        z1.example.com
        z2.example.com
  6. プライマリークラスターのステータスと、プライマリークラスターのノードの障害復旧クラスターのステータスを確認します。

    [root@z1 ~]# pcs dr status
    --- Local cluster - Primary site ---
    Cluster name: PrimarySite
    
    WARNINGS:
    No stonith devices and stonith-enabled is not false
    
    Cluster Summary:
      * Stack: corosync
      * Current DC: z2.example.com (version 2.0.3-2.el8-2c9cea563e) - partition with quorum
      * Last updated: Mon Dec  9 04:10:31 2019
      * Last change:  Mon Dec  9 04:06:10 2019 by hacluster via crmd on z2.example.com
      * 2 nodes configured
      * 0 resource instances configured
    
    Node List:
      * Online: [ z1.example.com z2.example.com ]
    
    Full List of Resources:
      * No resources
    
    Daemon Status:
      corosync: active/disabled
      pacemaker: active/disabled
      pcsd: active/enabled
    
    
    --- Remote cluster - Recovery site ---
    Cluster name: DRSite
    
    WARNINGS:
    No stonith devices and stonith-enabled is not false
    
    Cluster Summary:
      * Stack: corosync
      * Current DC: z4.example.com (version 2.0.3-2.el8-2c9cea563e) - partition with quorum
      * Last updated: Mon Dec  9 04:10:34 2019
      * Last change:  Mon Dec  9 04:09:55 2019 by hacluster via crmd on z4.example.com
      * 2 nodes configured
      * 0 resource instances configured
    
    Node List:
      * Online: [ z3.example.com z4.example.com ]
    
    Full List of Resources:
      * No resources
    
    Daemon Status:
      corosync: active/disabled
      pacemaker: active/disabled
      pcsd: active/enabled

災害復旧構成の追加の表示オプションは、pcs dr コマンドのヘルプ画面を参照してください。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。