適用項目 SUSE Linux Enterprise High Availability 15 SP6

6 クラスタリソースの設定 #

クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実行する各アプリケーションに対してクラスタリソースを作成する必要があります。クラスタリソースには、Webサイト、メールサーバ、データベース、ファイルシステム、仮想マシン、およびユーザが常時使用できるその他のサーバベースのアプリケーションまたはサービスなどが含まれます。

6.1 リソースのタイプ #

次のリソースタイプを作成できます。

プリミティブ

プリミティブリソースは、リソースの中で最も基本的なタイプです。

グループ

グループには、一緒の場所で見つけ、連続して開始し、逆の順序で停止する必要のあるリソースセットが含まれます。

クローン

クローンは、複数のホスト上でアクティブにできるリソースです。対応するリソースエージェントがサポートしていれば、どのようなリソースもクローン化できます。

プロモータブルクローン(マルチステートリソースとも呼ばれていました)は、昇格できる特別なタイプのクローンリソースです。

6.2 サポートされるリソースエージェントクラス #

追加するクラスタリソースごとに、リソースエージェントが準拠する基準を定義する必要があります。リソースエージェントは、提供するサービスを抽象化して正確なステータスをクラスタに渡すので、クラスタは管理するリソースについてコミットする必要がありません。クラスタは、リソースエージェントに依存して、start、stop、またはmonitorのコマンドの発行に適宜対応します。

通常、リソースエージェントはシェルスクリプトの形式で配布されます。SUSE Linux Enterprise High Availabilityは次のリソースエージェントクラスをサポートします。

Open Cluster Framework (OCF)リソースエージェント

OCF RAエージェントは、High Availabilityでの使用に最適であり、特に、プロモータブルクローンリソースまたは特殊なモニタリング機能を必要とする場合に適しています。それらのエージェントは、通常、/usr/lib/ocf/resource.d/provider/にあります。この機能はLSBスクリプトの機能と同様です。ただし、環境設定では、常に、パラメータの受け入れと処理を容易にする環境変数が使用されます。OCF仕様ではアクションによってどの出口コードが返されるか、厳密な定義があります。10.3項「OCF戻りコードと障害回復」を参照してください。クラスタは、それらの仕様に正確に準拠します。

すべてのOCFリソースエージェントは少なくともstart、stop、status、monitorおよびmeta-dataの各アクションが必要です。meta-dataアクションは、エージェントの設定方法についての情報を取得します。たとえば、プロバイダIPaddrでheartbeatエージェントの詳細を知るには、次のコマンドを使用します。

OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/IPaddr meta-data

出力は、XML形式の情報であり、いくつかのセクションを含みます(一般説明、利用可能なパラメータ、エージェント用の利用可能なアクション)。

または、crmshを使用して、OCFリソースエージェントに関する情報を表示します。詳細については、5.5.4項「OCFリソースエージェントに関する情報の表示」を参照してください。

Linux Standards Base (LSB)スクリプト

LSBリソースエージェントは一般にオペレーティングシステム/配布パッケージによって提供され、/etc/init.dにあります。リソースエージェントをクラスタで使用するには、それらのエージェントがLSB iniスクリプトの仕様に準拠している必要があります。たとえば、エージェントには複数のアクションが実装されている必要があります。少なくともstart、stop、restart、reload、force-reloadおよびstatusが実装されている必要があります。詳細については、https://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.htmlを参照してください。

これらのサービスの構成は標準化されていません。High AvailabilityでLSBスクリプトを使用する場合は、該当のスクリプトの設定方法を理解する必要があります。これに関する情報は、多くの場合、/usr/share/doc/packages/PACKAGENAME内の該当パッケージのマニュアルに記載されています。

systemd

Pacemakerは、systemdサービスが存在する場合は、それを管理できます。initスクリプトの代わりに、systemdはユニットファイルを持ちます。一般的に、サービス(またはユニットファイル)は、オペレーティングシステムによって提供されます。既存のinitスクリプトを変換する場合は、https://0pointer.de/blog/projects/systemd-for-admins-3.htmlで詳細情報を検索してください。

サービス

現在、並列に存在するタイプのシステムサービスが多数あります: LSB (System V initに属する)、systemd、および(一部のディストリビューションでは) upstart。そのため、Pacemakerは、どれが指定のクラスタノードに適用されるのかを理解する特殊なエイリアスをサポートします。これは、クラスタにsystemd、upstart、およびLSBサービスが混在する場合には特に役立ちます。Pacemakerは、次の順番で指定されたサービスを検索しようとします: LSB (SYS-V) initスクリプト、systemdユニットファイル、またはUpstartジョブ。

Nagios

モニタリングプラグイン(かつてはNagiosプラグインと呼ばれていた)により、リモートホスト上のサービスを監視できます。Pacemakerは、モニタリングプラグインが存在する場合は、これを使用してリモートモニタリングを実行できます。詳細については、9.1項「監視プラグインを使用したリモートホストでのサービスの監視」を参照してください。

STONITH(フェンシング)リソースエージェント

このクラスは、フェンシング関係のリソース専用に使用されます。詳細については、第12章「フェンシングとSTONITH」を参照してください。

SUSE Linux Enterprise High Availabilityによって提供されるエージェントは、OCFの仕様に基づいて開発されています。

6.3 タイムアウト値 #

リソースのタイムアウト値は次の3つのパラメータの影響を受けることがあります。

op_defaults (操作用のグローバルタイムアウト)
リソーステンプレートに対して定義された特定のタイムアウト値
リソースに対して定義された特定のタイムアウト値

注記: 値の優先度

リソースに対して「特定の」値が定義される場合、グローバルデフォルトより優先されます。また、リソースに対して定義された特定の値は、リソーステンプレートで定義された値より優先されます。

タイムアウト値を適切に設定することは非常に重要です。これらの値を短くしすぎると、次のような理由で、多数の(不必要な)フェンシング処理が発生します。

リソースでタイムアウトが発生すると、リソースは失敗し、クラスタはリソースを停止しようとします。
リソースの停止も失敗した場合(たとえば、停止用タイムアウトの設定が低すぎるため)、クラスタはノードをフェンシングします。これが制御不能になるノードを考慮します。

操作に対するグローバルデフォルトを調整し、crmshおよびHawk2の両方で特定のタイムアウト値を設定できます。タイムアウト値の決定および設定のベストプラクティスは次のとおりです。

手順 6.1: タイムアウト値の決定 #

負荷の下でリソースが開始および停止するためにかかる時間を確認します。
必要な場合、パラメータop_defaultsを追加し、それに応じて(デフォルトの)タイムアウト値を設定します。
1. たとえば、op_defaultsを60秒に設定します。
```
crm(live)configure# op_defaults timeout=60
```
2. さらに長い時間を必要とするリソースについては、個別の値を定義します。
あるリソースに対して操作を設定する場合には、個別のstart操作およびstop操作を追加します。Hawk2を使用して設定する場合、これらの操作に適したタイムアウト値候補が表示されます。

6.4 プリミティブリソースの作成 #

リソースは、クラスタで使用する前にセットアップする必要があります。たとえば、Apacheサーバをクラスタリソースとして使用するには、まず、Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラスタで個々のリソースを起動します。

リソースに特定の環境要件がある場合は、それらの要件がすべてのクラスタノードに存在し、同一であることを確認してください。SUSE Linux Enterprise High Availabilityはこの種の設定は管理しません。これは、管理者自身が行う必要があります。

Hawk2またはcrmshのいずれかを使用してプリミティブリソースを作成できます。

注記: クラスタによって管理されるサービスには介入しないでください

SUSE Linux Enterprise High Availabilityでリソースを管理しているときに、同じリソースを他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始したり、停止してはいけません。High Availabilityソフトウェアが、すべてのサービスの開始または停止アクションを実行します。

サービスがクラスタ制御下ですでに実行された後にテストまたは保守タスクを実行する必要がある場合は、リソース、ノード、またはクラスタ全体を保守モードに設定してから、これらのいずれかに手動でタッチしてください。詳細については、28.2項「保守タスクのためのさまざまなオプション」を参照してください。

重要: リソースIDとノード名

クラスタリソースとクラスタノードは異なる名前にする必要があります。同じ名前にするとHawk2で障害が発生します。

6.4.1 Hawk2を使用したプリミティブリソースの作成 #

最も基本的なタイプのリソースを作成するには、次の手順に従います。

手順 6.2: Hawk2を使用したプリミティブリソースの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › プリミティブの順に選択します。
固有のリソースIDを入力します。
リソース設定の基にするリソーステンプレートが存在する場合は、テンプレートで目的のテンプレートを選択します。
クラスで、使用するリソースエージェントのクラスを選択します。lsb、ocf、service、stonith、またはsystemdから選択できます。詳細については、6.2項「サポートされるリソースエージェントクラス」を参照してください。
ocfをクラスとして選択した場合、OCFリソースエージェントのプロバイダを指定します。OCFの指定によって、複数のベンダが同じリソースエージェントを提供できるようになります。
タイプリストから、使用するリソースエージェントを選択します(たとえばIPaddrまたはFilesystem)。このリソースエージェントの簡単な説明が表示されます。
注記
タイプリストに表示される選択肢は、選択したクラス(OCFリソースの場合は、プロバイダも)によって異なります。
図 6.1: Hawk2 - プリミティブリソース #
リソースの基本を指定すると、Hawk2には次のカテゴリが表示されます。Hawk2の提案に従ってこれらのカテゴリを保持するか、必要に応じて編集します。
パラメータ(インスタンス属性)
リソースが制御するサービスのインスタンスを決定します。リソースを作成する際、Hawk2は必要なパラメータを自動的に表示します。これらを編集して、有効なリソースの設定を取得します。
詳細については、6.13項「インスタンス属性(パラメータ)」を参照してください。
操作
リソース監視に必要です。リソースを作成する際、Hawk2は、最も重要なリソース操作(monitor、startおよびstop)を表示します。
詳細については、6.14項「リソース操作」を参照してください。
メタ属性
特定のリソースの処理方法をCRMに指示します。リソースを作成する際、Hawk2はそのリソースの重要なメタ属性を自動的にリストにします(たとえばリソースの初期状態を定義するtarget-role属性です。デフォルトではStoppedに設定されているため、リソースはすぐには始動しません)。
詳細については、6.12項「リソースオプション(メタ属性)」を参照してください。
使用率
特定のリソースがノードから要求する容量をCRMに指示します。
詳細については、7.10.1項「Hawk2を使用した負荷インパクトに基づくリソースの配置」を参照してください。
作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

6.4.2 crmshを使用したプリミティブリソースの作成 #

手順 6.3: crmshを使用したプリミティブリソースの追加 #

rootとしてログインし、crmツールを開始します。
```
# crm configure
```
プリミティブIPアドレスを設定します。
```
crm(live)configure# primitive myIP IPaddr \
      params ip=127.0.0.99 op monitor interval=60s
```
前のコマンドは「プリミティブ」に名前myIPを設定します。クラス(ここではocf)、プロバイダ(heartbeat)、およびタイプ(IPaddr)を選択する必要がありますさらに、このプリミティブでは、IPアドレスなどのパラメータが必要です。自分の設定に合わせてアドレスを変更してください。
行った変更を表示して確認します。
```
crm(live)configure# show
```
変更をコミットして反映させます。
```
crm(live)configure# commit
```

6.5 リソースグループの作成 #

クラスタリソースの中には、他のコンポーネントやリソースに依存しているものもあります。それぞれのコンポーネントやリソースが決められた順序で開始され、依存しているリソースと同じサーバ上で同時に実行していなければならない場合があります。この設定を簡素化するには、クラスタリソースグループを使用できます。

Hawk2またはcrmshのいずれかを使用してリソースグループを作成できます。

例 6.1: Webサーバのリソースグループ #

リソースグループの一例として、IPアドレスとファイルシステムを必要とするWebサーバがあります。この場合、各コンポーネントは、個々のリソースであり、それらが組み合わされてクラスタリソースグループを構成します。リソースグループは、1つ以上のサーバで実行されます。ソフトウェアまたはハードウェアが機能しない場合には、個々のクラスタリソースと同様に、グループはクラスタ内の別のサーバにフェールオーバーします。

図 6.2: グループリソース #

グループには次のプロパティがあります。

開始と停止: リソースは認識される順序で開始し、逆の順番で停止します。
依存関係: グループ内のリソースがどこかで開始できない場合は、グループ内のその後の全リソースは実行することができません。
目次: グループにはプリミティブクラスタリソースしか含むことができません。グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループリソースの子を参照するには、グループのIDではなく子のIDを使用します。
制約: 制約でグループの子を参照することはできますが、通常はグループ名を使用することをお勧めします。
固着性: 固着性はグループ内で統合可能なプロパティです。グループ内の「アクティブな」各メンバーは、グループの合計値に対して固着性を追加します。したがって、デフォルトのresource-stickinessが100で、グループに7つのメンバーがあり、そのうち5つがアクティブな場合は、グループが全体として、スコア500で、現在の場所を優先します。
リソース監視: グループのリソース監視を有効にするには、グループ内で監視の必要な各リソースに対して監視を設定する必要があります。

6.5.1 Hawk2を使用したリソースグループの作成 #

注記: 空のグループ

グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループの作成中に、Hawk2ではさらにプリミティブを作成し、それらをグループに追加できます。

手順 6.4: Hawk2を使用したリソースグループの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › グループの順に選択します。
固有のグループIDを入力します。
グループメンバーを定義するには、子リストで1つまたは複数のエントリを選択します。グループメンバーを再ソートするには、右側の「ハンドル」アイコンを使用して、メンバーを目的の順序にドラッグアンドドロップします。
必要に応じて、メタ属性を変更または追加します。
作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 6.3: Hawk2 - リソースグループ #

6.5.2 crmshを使用したリソースグループの作成 #

次の例では、2つのプリミティブ(IPアドレスと電子メールリソース)を作成します。

手順 6.5: crmshを使用したリソースグループの追加 #

crmコマンドをシステム管理者として実行します。プロンプトがcrm(live)に変化します。

プリミティブを設定します。

crm(live)# configure
crm(live)configure# primitive Public-IP ocf:heartbeat:IPaddr2 \
    params ip=1.2.3.4 \
    op monitor interval=10s
crm(live)configure# primitive Email systemd:postfix \
    op monitor interval=10s

該当するIDを使用して、正しい順序で、プリミティブをグループ化します。
```
crm(live)configure# group g-mailsvc Public-IP Email
```

6.6 クローンリソースの作成 #

クラスタ内の複数のノードで特定のリソースを同時に実行することができます。このためには、リソースをクローンとして設定する必要があります。クローンとして設定するリソースの一例として、OCFS2などのクラスタファイルシステムが挙げられます。提供されているどのリソースも、クローンとして設定できます。これは、リソースのリソースエージェントによってサポートされます。クローンリソースは、ホスティングされているノードによって異なる設定をすることもできます。

リソースクローンには次の3つのタイプがあります。

匿名クローン: 最も簡単なクローンタイプです。実行場所にかかわらず、同じ動作をします。このため、マシンごとにアクティブな匿名クローンのインスタンスは1つだけ存在できます。
グローバルに固有なクローン: このリソースは独自のエントリです。1つのノードで実行しているクローンのインスタンスは、別なノードの別なインスタンスとは異なり、同じノードの2つのインスタンスが同一になることもありません。
プロモータブルクローン(マルチステートリソース): このリソースのアクティブインスタンスは、アクティブとパッシブという2つの状態に分けられます。これらはプライマリとセカンダリと呼ばれる場合もあります。プロモータブルクローンが、匿名またはグローバルに固有の場合もあります。詳細については、6.7項「プロモータブルクローン(マルチステートリソース)の作成」を参照してください。

クローンは、グループまたは通常リソースを1つだけ含む必要があります。

リソースのモニタリングまたは制約を設定する場合、クローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(https://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。

Hawk2またはcrmshのいずれかを使用してクローンリソースを作成できます。

6.6.1 Hawk2を使用したクローンリソースの作成 #

注記: クローンの子リソース

クローンには、プリミティブまたはグループのいずれかを子リソースとして含めることができます。Hawk2では、クローンの作成中に子リソースを作成したり変更したりすることはできません。クローンを追加する前に、子リソースを作成し、必要に応じて設定しておいてください。

手順 6.6: Hawk2を使用したクローンリソースの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › クローンの順に選択します。
固有のクローンIDを入力します。
子リソースリストから、クローンのサブリソースとして使用するプリミティブまたはグループを選択します。
必要に応じて、メタ属性を変更または追加します。
作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 6.4: Hawk2 - クローンリソース #

6.6.2 crmshを使用したクローンリソースの作成 #

匿名クローンリソースを作成するには、まずプリミティブリソースを作成して、それをcloneコマンドで指定します。

手順 6.7: crmshを使用したクローンリソースの追加 #

rootとしてログインし、crm対話型シェルを開始します。
```
# crm configure
```
次のように、プリミティブを設定します。
```
crm(live)configure# primitive Apache apache
```
プリミティブをクローンします。
```
crm(live)configure# clone cl-apache Apache
```

6.7 プロモータブルクローン(マルチステートリソース)の作成 #

プロモータブルクローン(以前はマルチステートリソースと呼ばれていました)は、クローンが得意とするところです。これにより、インスタンスを2つの動作モード(プライマリまたはセカンダリ)のいずれかに設定できます。プロモータブルクローンは、グループまたは通常リソースを1つだけ含む必要があります。

リソースのモニタリングまたは制約を設定する場合、プロモータブルクローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(https://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。

Hawk2またはcrmshのいずれかを使用してプロモータブルクローンを作成できます。

6.7.1 Hawk2を使用したプロモータブルクローンの作成 #

注記: プロモータブルクローンの子リソース

プロモータブルクローンには、プリミティブまたはグループのいずれかを子リソースとして含めることができます。Hawk2では、プロモータブルクローンの作成中に子リソースを作成したり変更したりすることはできません。プロモータブルクローンを追加する前に、子リソースを作成し、必要に応じて設定します。6.4.1項「Hawk2を使用したプリミティブリソースの作成」または6.5.1項「Hawk2を使用したリソースグループの作成」を参照してください。

手順 6.8: Hawk2を使用したプロモータブルクローンの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › マルチステートの順に選択します。
マルチステートIDに固有のIDを入力します。
子リソースリストから、マルチステートリソースのサブリソースとして使用するプリミティブまたはグループを選択します。
必要に応じて、メタ属性を変更または追加します。
作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

6.7.2 crmshを使用したプロモータブルクローンの作成 #

プロモータブルクローンリソースを作成するには、まずプリミティブリソースを作成してから、プロモータブルクローンリソースを作成します。プロモータブルクローンリソースは少なくとも、昇格および降格操作をサポートしている必要があります。

手順 6.9: crmshを使用したプロモータブルクローンの追加 #

rootとしてログインし、crm対話型シェルを開始します。
```
# crm configure
```

プリミティブを作成します。必要に応じて間隔を変更します。

crm(live)configure# primitive my-rsc ocf:myCorp:myAppl \
    op monitor interval=60 \
    op monitor interval=61 role=Promoted

プロモータブルクローンリソースを作成します。
```
crm(live)configure# clone clone-rsc my-rsc meta promotable=true
```

6.8 リソーステンプレートの作成 #

類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプレートを定義することです。定義されたテンプレートは、プリミティブ内で参照したり、7.3項「リソーステンプレートと制約」で説明するように、特定のタイプの制約内で参照することができます。

プリミティブ内でテンプレートを参照すると、そのテンプレートで定義されている操作、インスタンス属性(パラメータ)、メタ属性、使用属性がすべてプリミティブに継承されます。さらに、プリミティブに対して特定の操作または属性を定義することもできます。これらのいずれかがテンプレートとプリミティブの両方で定義されていた場合、プリミティブで定義した値の方が、テンプレートで定義された値よりも優先されます。

Hawk2またはcrmshのいずれかを使用してリソーステンプレートを作成できます。

6.8.1 Hawk2を使用したリソーステンプレートの作成 #

リソーステンプレートは、プリミティブリソースと同様の方法で設定します。

手順 6.10: リソーステンプレートの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › テンプレートの順に選択します。
固有のリソースIDを入力します。
手順6.2「Hawk2を使用したプリミティブリソースの追加」のステップ 5以降の手順に従います。

6.8.2 crmshを使用したリソーステンプレートの作成 #

次の構文を知るには、rsc_templateコマンドを使用してください。

# crm configure rsc_template
 usage: rsc_template <name> [<class>:[<provider>:]]<type>
        [params <param>=<value> [<param>=<value>...]]
        [meta <attribute>=<value> [<attribute>=<value>...]]
        [utilization <attribute>=<value> [<attribute>=<value>...]]
        [operations id_spec
            [op op_type [<attribute>=<value>...] ...]]

たとえば、次のコマンドは、ocf:heartbeat:Xenリソースと、デフォルト値および操作に由来するBigVMの名前を持つ新しいリソーステンプレートを作成します。

crm(live)configure# rsc_template BigVM ocf:heartbeat:Xen \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

新しいリソーステンプレートを定義したら、それをプリミティブとして使用すること、または順序、コロケーション、またはrsc_ticketの制約で参照することができます。リソーステンプレートを参照するには、@記号を使用します。

crm(live)configure# primitive MyVM1 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1"

新しいプリミティブMy-VM1は、BigVMリソーステンプレートからすべてを継承します。たとえば、上の2つに等しいものは次のようになります。

crm(live)configure# primitive MyVM1 Xen \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1" \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

オプションや操作を上書きしたい場合は、自分の(プリミティブの)定義を追加します。たとえば、次の新しいプリミティブMyVM2は監視操作のタイムアウトを2倍にしますが、その他はそのままに残します。

crm(live)configure# primitive MyVM2 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM2" name="MyVM2" \
   op monitor timeout=120s interval=30s

リソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表すものとして、制約で参照することができます。これにより、クラスタ設定をいっそう簡潔かつクリアに行うことができます。リソーステンプレートは、場所の制約を除くすべての制約から参照することができます。コロケーション制約には、複数のテンプレート参照を含めることはできません。

6.9 STONITHリソースの作成 #

重要: STONITHがない場合はサポートなし

クラスタにはノードフェンシングメカニズムが必要です。
グローバルクラスタオプションstonith-enabledおよびstartup-fencingはtrueに設定する必要があります。これらを変更するとサポートされなくなります。

デフォルトでは、グローバルクラスタオプションのstonith-enabledはtrueに設定されています。STONITHリソースが定義されていない場合、クラスタはどのリソースも開始することを拒否します。STONITHリソースが定義されていない場合、クラスタはどのリソースを開始することも拒否します。1つ以上のSTONITHリソースを設定して、STONITHのセットアップを完了します。STONITHリソースは他のリソースと同様に設定しますが、その動作はいくつかの点で異なっています。詳細については、12.3項「STONITHのリソースと環境設定」を参照してください。

Hawk2またはcrmshのいずれかを使用してSTONITHリソースを作成できます。

6.9.1 Hawk2を使用したSTONITHリソースの作成 #

SBD、libvirt (KVM/Xen)、またはvCenter/ESX ServerのSTONITHリソースを追加する場合、Hawk2ウィザードを使用するのが最も簡単な方法です。

手順 6.11: Hawk2を使用したSTONITHリソースの追加 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
左のナビゲーションバーから、環境設定 › Add Resource (リソースの追加) › プリミティブの順に選択します。
固有のリソースIDを入力します。
クラスリストで、リソースエージェントクラスとしてstonithを選択します。
タイプリストから、使用しているSTONITHデバイスを制御するためのSTONITHプラグインを選択します。このプラグインの簡単な説明が下に表示されます。
Hawk2は、自動的にそのリソースに必要なパラメータを表示します。それぞれのパラメータの値を入力します。
Hawk2は、重要なリソース操作を表示し、デフォルト値を提案します。設定を変更しない場合、確定するとすぐに、Hawk2は提案した操作およびデフォルト値を追加します。
変更理由がない場合は、デフォルトのメタ属性設定を保持します。
図 6.5: Hawk2 - STONITHリソース #
変更を確認して、STONITHリソースを作成します。
画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

フェンシングを設定するには、制約を追加します。詳細については、第12章「フェンシングとSTONITH」を参照してください。

6.9.2 crmshを使用したSTONITHリソースの作成 #

手順 6.12: crmshを使用したSTONITHリソースの追加 #

rootとしてログインし、crm対話型シェルを開始します。
```
# crm
```

次のコマンドで、すべてのSTONITHタイプのリストを取得します。

crm(live)# ra list stonith
apcmaster                  apcmastersnmp              apcsmart
baytech                    bladehpi                   cyclades
drac3                      external/drac5             external/dracmc-telnet
external/hetzner           external/hmchttp           external/ibmrsa
external/ibmrsa-telnet     external/ipmi              external/ippower9258
external/kdumpcheck        external/libvirt           external/nut
external/rackpdu           external/riloe             external/sbd
external/vcenter           external/vmware            external/xen0
external/xen0-ha           fence_legacy               ibmhmc
ipmilan                    meatware                   nw_rpc100s
rcd_serial                 rps10                      suicide
wti_mpc                    wti_nps

上記のリストからSTONITHタイプを選択し、利用できるオプションのリストを表示します。次のコマンドを実行します。

crm(live)# ra info stonith:external/ipmi
IPMI STONITH external device (stonith:external/ipmi)

ipmitool based power management. Apparently, the power off
method of ipmitool is intercepted by ACPI which then makes
a regular shutdown. In case of a split brain on a two-node,
it may happen that no node survives. For two-node clusters,
use only the reset method.

Parameters (* denotes required, [] the default):

hostname (string): Hostname
   The name of the host to be managed by this STONITH device.
...

stonithクラス、ステップ 3で選択したタイプ、および必要に応じて該当するパラメータを使用して、STONITHリソースを作成します。たとえば、次のようにします。

crm(live)# configure
crm(live)configure# primitive my-stonith stonith:external/ipmi \
   params hostname="alice" \
   ipaddr="192.168.1.221" \
   userid="admin" passwd="secret" \
   op monitor interval=60m timeout=120s

6.10 リソース監視の設定 #

リソースが実行中であるかどうか確認するには、そのリソースにリソースの監視を設定しておく必要があります。Hawk2またはcrmshのいずれかを使用してリソース監視を設定できます。

リソースモニタが障害を検出すると、次の処理が行われます。

/etc/corosync/corosync.confのloggingセクションで指定された設定に従って、ログファイルメッセージが生成されます。
障害がクラスタ管理ツール(Hawk2、crm status)と、CIBステータスセクションに反映されます。
クラスタが明瞭な復旧アクションを開始します。これらのアクションには、リソースを停止して障害状態を修復する、ローカルまたは別のノードでリソースを再起動するなどが含まれる場合があります。設定やクラスタの状態によっては、リソースが再起動されないこともあります。

リソースの監視を設定しなかった場合、開始成功後のリソース障害は通知されず、クラスタは常にリソース状態を良好として表示してしまいます。

通常、リソースは動作中にのみ、クラスタによって監視されます。しかし、同時実行違反を検出するために、停止されるリソースの監視も設定する必要があります。リソースを監視するには、タイムアウト、開始遅延のいずれか、または両方と、間隔を指定します。間隔の指定によって、CRMにリソースステータスの確認頻度を指示します。timeoutまたはstart操作に対するstopなど、特定のパラメータも設定できます。

監視操作パラメータの詳細については、6.14項「リソース操作」を参照してください。

6.10.1 Hawk2を使用したリソース監視の設定 #

手順 6.13: 操作の追加または変更 #

Hawk2にログインします。
```
https://HAWKSERVER:7630/
```
手順6.2「Hawk2を使用したプリミティブリソースの追加」の説明に従ってリソースを追加するか、既存のプリミティブを選択して編集します。
Hawk2は、最も重要な操作(start、stop、monitor)を自動的に表示し、デフォルト値を提案します。
提案された各値に属する属性を参照するには、マウスポインタをそれぞれの値に合わせます。
図 6.6: 操作値 #
timeoutまたはstart操作に対して提案されたstopの値を変更するには、次の手順に従います。
1. 操作の隣のペンアイコンをクリックします。
2. 表示されるダイアログで、timeoutパラメータに別の値(例: 10)を入力し、変更内容を確認します。
操作に対して提案されたintervalmonitorの値を変更するには、次の手順に従います。
1. 操作の隣のペンアイコンをクリックします。
2. 表示されるダイアログで、intervalに対して監視間隔の別の値を入力します。
3. リソースが停止されている場合にリソース監視を設定するには、次の手順に従います。
  1. 下にある空のドロップダウンボックスからroleエントリを選択します。
  2. roleドロップダウンボックスから、Stoppedを選択します。
  3. 適用をクリックし、変更内容を確認して操作のダイアログを閉じます。
リソース設定画面で変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

リソースの障害を表示するには、Hawk2で状態画面に切り替えて、関係するリソースを選択します。操作列で、下矢印アイコンをクリックして最近のイベントを選択します。表示されるダイアログに、リソースに対して実行された最近のアクションが一覧表示されます。障害は赤で表示されます。リソースの詳細を表示するには、操作列で虫眼鏡アイコンをクリックします。

図 6.7: Hawk2 - リソース詳細 #

6.10.2 crmshを使用したリソース監視の設定 #

リソースを監視するには、2つの方法(opキーワードで監視処理を定義するか、monitorコマンドを使用するか)があります。次の例では、Apacheリソースを設定し、opキーワードを使用して60秒ごとに監視します。

crm(live)configure# primitive apache apache \
  params ... \
  op monitor interval=60s timeout=30s

次のコマンドを使用して同じ操作を実行できます。

crm(live)configure# primitive apache apache \
   params ...
 crm(live)configure# monitor apache 60s:30s

停止されたリソースの監視

通常、リソースは動作中にのみ、クラスタによって監視されます。しかし、同時実行違反を検出するために、停止されるリソースの監視も設定する必要があります。例:

crm(live)configure# primitive dummy1 Dummy \
     op monitor interval="300s" role="Stopped" timeout="10s" \
     op monitor interval="30s" timeout="10s"

この設定は、300秒ごとに、リソースdummy1に対する監視操作をトリガします。これは、リソースがrole="Stopped"に入ると有効になります。実行中には、リソースは30秒ごとに監視されます。

プローブ

CRMはすべてのノードの各リソースに対して、probeと呼ばれる初期監視を実行します。probeはリソースのクリーンアップ後にも実行されます。1つのリソースに対して複数の監視操作が定義されている場合、CRMは最も時間間隔の短い監視操作を1つ選択し、そのタイムアウト値をプローブのデフォルトタイムアウトとして使用します。監視操作が何も設定されていない場合は、クラスタ規模のデフォルトが適用されます。デフォルトは、20秒です(別途op_defaultsパラメータを設定して指定されていない場合)。自動計算やop_defaultsの値に依存したくない場合は、このリソースの「プローブ」に対して特定の監視操作を定義します。intervalを0に設定した監視操作を追加することで、この操作を行います。たとえば次のようになります。

crm(live)configure# primitive rsc1 ocf:pacemaker:Dummy \
     op monitor interval="0" timeout="60"

rsc1のプローブは60sでタイムアウトになります。この値は、op_defaultsで定義されているグローバルなタイムアウト値や、その他の操作で設定されたタイムアウト値とは無関係です。それぞれのリソースのプローブを指定するためにinterval="0"を設定していない場合、CRMは、そのリソースに定義されている監視操作が他にないかどうかを自動的に確認し、上で説明されているようにプローブのタイムアウト値を計算します。

6.11 ファイルからのリソースのロード #

設定の一部またはすべてをローカルファイルまたはネットワークURLからロードできます。次の3つの異なる方法を定義できます。

replace: このオプションは、現在の設定を新たなソース設定に置き換えます。
update: このオプションは、ソース設定のインポートを試みます。現在の設定に新たな項目を追加したり、既存の項目を更新したりします。
push: このオプションは、ソースからのコンテンツを現在の設定にインポートします(updateと同じ)。ただし、新しい設定で使用できないオブジェクトを削除します。

ファイルmycluster-config.txtから新しい設定をロードするには、次の構文を使用します。

# crm configure load push mycluster-config.txt

6.12 リソースオプション(メタ属性) #

追加した各リソースについて、オプションを定義できます。クラスタはオプションを使用して、リソースの動作方法を決定します。CRMに特定のリソースの処理方法を通知します。リソースオプションは、crm_resource --metaコマンドまたはHawk2を使用して設定できます。

以下のリストは、一般的なオプションを示しています。

priority

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

デフォルトの設定は0です。

target-role

クラスタが維持しようとするこのリソースの状態。使用できる値: Stopped, Started, Unpromoted, Promoted.

デフォルトの設定はStartedです。

is-managed

クラスタがリソースを開始して停止できるかどうか。使用できる値: true, false.値がfalseに設定されていても、リソースの状態は引き続き監視され、障害が発生した場合は報告されます。これは、リソースをmaintenance="true""に設定するのとは異なります。

デフォルトの設定はtrueです。

maintenance

リソースは手動でタッチできるかどうか。使用できる値: true, false.trueに設定されている場合、すべてのリソースは非管理になります。つまり、クラスタはリソースの監視を停止し、その状態を認識しなくなります。クラスタによってクラスタリソースの再起動が試行される代わりに、ユーザがクラスタリソースを停止または再起動できます。

デフォルトの設定はfalseです。

resource-stickiness

リソースが現在の状態をどの程度維持したいか。

デフォルト値は、個別のクローンインスタンスに対しては1、その他すべてのリソースに対しては0です。

migration-threshold

ノードがこのリソースをホストできなくなるまで、このリソースについてノード上で発生する失敗の回数。

デフォルトの設定はINFINITYです。

multiple-active

複数のノードでアクティブなリソースを検出した場合のクラスタの動作。使用できる値: block (リソースを管理されていないとマークする)、stop_only、stop_start。

デフォルトの設定はstop_startです。

failure-timeout

失敗が発生していないかように動作する(場合によっては、リソースを失敗したノードに戻す)前に、待機する秒数。

デフォルト値は0 (無効)です。

allow-migrate

migrate_toアクションおよびmigrate_fromアクションをサポートするリソースのライブマイグレーションを許可するかどうか。値がtrueに設定されている場合、リソースは状態を失うことなく移行できます。値がfalseに設定されている場合、リソースは最初のノードでシャットダウンされ、2つ目のノードで再起動されます。

デフォルト値は、ocf:pacemaker:remoteリソースに対してはtrue、その他すべてのリソースに対してはfalseです。

allow-unhealthy-nodes

通常であればノードのヘルススコアが低くリソースを実行できない場合でも、この設定によりリソースがノード上で実行されることを許可します。

デフォルトの設定はfalseです。

remote-node

このリソースが定義するリモートノードの名前。これにより、リモートノードのリソースが有効化されるだけでなく、リモートノードの識別に使用される固有の名前が定義されます。また、他のパラメータが設定されていない場合、この値はremote-portポートで接続するホスト名と想定されます。

デフォルトでは、このオプションは無効になっています。

警告: 固有のIDの使用

この値は、既存のリソースやノードIDとは重複させないでください。

remote-port

pacemaker_remoteへのゲスト接続用のカスタムポート。

デフォルトの設定は3121です。

remote-addr

リモートノードの名前がゲストのホスト名ではない場合に接続するIPアドレスまたはホスト名。

デフォルト値はremote-nodeによって設定された値です。

remote-connect-timeout

中断したゲスト接続がタイムアウトするまでの時間。

デフォルトの設定は60sです。

6.13 インスタンス属性(パラメータ) #

すべてのリソースクラスのスクリプトでは、動作方法および管理するサービスのインスタンスを指定するパラメータを指定できます。リソースエージェントがパラメータをサポートする場合、それらのパラメータをcrm_resourceコマンドまたはHawk2を使用して追加できます。インスタンス属性は、crmコマンドラインユーティリティではparams、Hawk2ではParameterと呼ばれます。OCFスクリプトでサポートされているインスタンス属性のリストは、次のコマンドをrootとして実行すると参照できます。

# crm ra info [class:[provider:]]resource_agent

または(オプション部分なし):

# crm ra info resource_agent

出力には、サポートされているすべての属性、それらの目的、およびデフォルト値が一覧されます。

注記: グループ、クローン、またはプロモータブルクローンのインスタンス属性

グループ、クローン、およびプロモータブルクローンリソースには、インスタンス属性がないので注意してください。ただし、インスタンス属性のセットは、グループ、クローン、またはプロモータブルクローンの子によって継承されます。

6.14 リソース操作 #

デフォルトで、クラスタはリソースが良好な状態であることを保証しません。クラスタにこれを行わせるには、リソースの定義に監視操作を追加する必要があります。監視操作は、すべてのクラスまたはリソースエージェントに追加できます。

監視操作には、次のプロパティがあります。

id

アクションに指定する名前。一意にする必要があります。(IDは表示されません)

name

実行するアクション。一般的な値: monitor、start、stop。

interval

操作を実行する頻度(秒単位)。

timeout

アクションが失敗したと宣言する前に待機する長さ。

requires

このアクションが発生する前に満たす必要のある条件。使用できる値: nothing, quorum, fencing.デフォルトは、フェンシングが有効でリソースのクラスがstonithかどうかによります。STONITHリソースの場合、デフォルトはnothingです。

on-fail

このアクションが失敗した場合に実行するアクション。使用できる値:

ignore: リソースが失敗しなかったのように動作します。
block: リソースにこれ以上の操作を実行しません。
stop: リソースを停止して、他の場所でも開始しません。
restart: リソースを停止して再起動します(別のノード上の場合あり)。
fence: リソースが失敗したノードを停止します(STONITH)。
standby: リソースが失敗したノードからすべてのリソースを移動させます。

enabled

falseの場合、操作は存在していない場合と同様に処理されます。使用できる値: true, false.

role

リソースにこの役割がある場合のみ操作を実行します。

record-pending

グローバルに設定したり、個々のリソースに対して設定できます。リソース上の「in-flight」操作の状態をCIBに反映させます。

description

操作について説明します。