目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availability Extensionのドキュメント / 管理ガイド / 設定および管理 / 設定および管理の基本事項
適用項目 SUSE Linux Enterprise High Availability Extension 15 SP4

6 設定および管理の基本事項

HAクラスタの主な目的はユーザサービスの管理です。ユーザサービスの典型的な例は、Apache Webサーバまたはデータベースです。サービスとは、ユーザの観点からすると、指示に基づいて特別な何かを行うことを意味していますが、クラスタにとっては開始や停止できるリソースにすぎません。サービスの性質はクラスタには無関係なのです。

この章では、リソースを設定しクラスタを管理する場合に知っておく必要のある基本概念を紹介します。後続の章では、High Availability Extensionが提供する各管理ツールを使用して、主要な設定および管理タスクを行う方法を説明します。

6.1 ユースケースのシナリオ

一般的に、クラスタは次の2つのカテゴリのいずれかに分類されます。

  • 2ノードクラスタ

  • 2ノードより多いクラスタ。これは通常、奇数のノード数を意味します。

異なるトポロジを追加して、異なるユースケースを生成することもできます。次のユースケースは最も一般的です。

1つの場所の2ノードクラスタ

設定:FC SANまたは同様の共有ストレージ、レイヤ2ネットワーク。

使用シナリオ:サービスの高可用性、およびデータレプリケーションのデータ冗長性なしに焦点を当てた埋め込みクラスタ。このようなセットアップは無線ステーションや組立てラインコントローラなどに使用されます。

2つの場所の2ノードクラスタ(最も広く使用されている)

設定:対称的なストレッチクラスタ、FC SAN、およびレイヤ2ネットワークのすべてが2つの場所に及ぶ。

使用シナリオ:サービスの高可用性、およびローカルデータの冗長性に焦点を当てた従来のストレッチクラスタ。データベースおよびエンタープライズリソース計画に適しており、ここ数年間で最も人気のあるセットアップの1つです。

3つの場所の奇数のノード数

設定:2×N+1ノード、FC SANが2つの主な場所に及ぶ。FC SANを使用しない補助的な3番目のサイト、過半数メーカーとして機能する。レイヤ2ネットワーク、少なくとも2つの主な場所に及ぶ。

使用シナリオ:サービスの高可用性、およびデータの冗長性に焦点を当てた従来のストレッチクラスタ。たとえば、データベース、エンタープライズリソースプランニング。

6.2 クォーラムの判断

1つ以上のノードとその他のクラスタ間で通信が失敗した場合は、常にクラスタパーティションが発生します。ノードは同じパーティション内の他のノードのみと通信可能で、切り離されたノードは認識しません。クラスタパーティションは、ノード(投票)の過半数を保有する場合、クォーラムを持つ(定足数に達している)と定義されます。これを実現する方法は「クォーラム計算」によって実行されます。クォーラムはフェンシングの要件です。

クォーラム計算はSUSE Linux Enterprise High Availability Extension 11とSUSE Linux Enterprise High Availability Extension 15の間で変更されました。SUSE Linux Enterprise High Availability Extension 11では、クォーラムはPacemakerによって計算されました。SUSE Linux Enterprise High Availability Extension 12以降では、CorosyncがPacemakerの設定を変更せずに直接2ノードクラスタのクォーラムを処理できます。

クォーラムの計算方法は、次のような要因によって影響されます。

クラスタノード数

実行中のサービスを継続させるため、2ノードを超えるクラスタはクラスタパーティションの解決においてクォーラム(過半数)に依存します。次の数式に基づき、クラスタが機能するために必要な動作ノードの最少数を計算できます。

N ≥ C/2 + 1

N = minimum number of operational nodes
C = number of cluster nodes

たとえば、5ノードクラスタでは、最低3つの動作ノード(または障害が発生する可能性のある2ノード)が必要です。

2ノードクラスタまたは奇数のクラスタノードのいずれかを使用することを強くお勧めします。2ノードクラスタは、2サイト間のストレッチセットアップで重要です。奇数のノード数を持つクラスタは、1つのシングルサイトで構築するか、または3つのサイト間で分散させることができます。

Corosyncの設定

Corosyncはメッセージングおよびメンバーシップ層です。6.2.4項 「2ノードクラスタのCorosync設定」および6.2.5項 「NノードクラスタのCorosync設定」を参照してください。

6.2.1 グローバルクラスタオプション

グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御します。それらは、セットにグループ化され、Hawk2やcrmシェルなどのクラスタ管理ツールで表示したり、変更することができます。

事前に定義されている値は、通常は、そのまま保持できます。ただし、クラスタの主要機能を正しく機能させるには、クラスタの基本的なセットアップ後に、次のパラメータを調整する必要があります。

6.2.2 グルーバルオプションno-quorum-policy

このグローバルオプションは、クラスタパーティションにクォーラムがない(ノードの過半数がパーティションに含まれない)場合どうするかを定義します。

許容値は、次のとおりです。

ignore

no-quorum-policyignoreに設定するとクラスタがクォーラムを持つように動作します。リソース管理は続行されます。

SLES 11では、この値が2ノードのクラスタ用の推奨設定でした。SLES 12以降、このオプションは廃止されました。設定と条件に基づいて、Corosyncはクラスタノードまたは単一ノードにクォーラムを与えます。または与えません。

2ノードのクラスタの場合、クォーラムが失われた場合の唯一の意味のある動作は、常に反応することです。最初のステップとして、クォーラムを失ったノードのフェンシングを試行してください。

freeze

クォーラムが失われた場合は、クラスタパーティションがフリーズします。リソース管理は続行されます。実行中のリソースは停止されません(ただし、イベントの監視に対応して再起動される可能性があります)。ただし、影響を受けたパーティション内では、以後のリソースが開始されません。

一定のリソースが他のノードとの通信に依存しているクラスタの場合(たとえば、OCFS2マウントなど)は、この設定が推奨されます。この場合、デフォルト設定no-quorum-policy=stopは、次のようなシナリオになるので有効でありません。つまり、ピアノードが到達不能な間はそれらのリソースを停止できなくなります。その代わり、停止の試行は最終的にタイムアウトし、stop failureになり、エスカレートされた復元とフェンシングを引き起こします。

stop (デフォルト値)

クォーラムが失われると、影響を受けるクラスタパーティション内のすべてのリソースが整然と停止します。

suicide

クォーラムが失われると、影響を受けるクラスタパーティション内のすべてのノードがフェンシングされます。このオプションは、SBDと組み合わせる場合にのみ機能します。第11章 「ストレージ保護とSBDを参照してください。

6.2.3 グローバルオプションstonith-enabled

このグローバルオプションは、フェンシングを適用して、STONITHデバイスによる、障害ノードや停止できないリソースを持つノードのダウンを許可するかどうか定義します。通常のクラスタ操作には、STONITHデバイスの使用が必要なので、このグローバルオプションは、デフォルトでtrueに設定されています。デフォルト値では、クラスタは、STONITHリソースが定義されていない場合にはリソースの開始を拒否します。

何らかの理由でフェンシングを無効にする必要がある場合は、stonith-enabledfalseに設定しますが、これはご使用の製品のサポートステータスに影響を及ぼすことに注意してください。また、stonith-enabled="false"を指定すると、Distributed Lock Manager (DLM)のようなリソースやDLMによるすべてのサービス(lvmlockd、GFS2、OCFS2など)は開始できません。

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

STONITHがないクラスタはサポートされません。

6.2.4 2ノードクラスタのCorosync設定

ブートストラップスクリプトを使用する場合、Corosyn設定には次のオプションを持つquorumセクションがあります。

例 6.1: 2ノードクラスタのCorosync設定の例
quorum {
   # Enable and configure quorum subsystem (default: off)
   # see also corosync.conf.5 and votequorum.5
   provider: corosync_votequorum
   expected_votes: 2
   two_node: 1
}

SUSE Linux Enterprise 11とは反対に、SUSE Linux Enterprise 12以降のvotequorumサブシステムは、Corosyncバージョン2.xで機能します。つまり、no-quorum-policy=ignoreオプションは使用してはならないことを意味します。

デフォルトで、two_node: 1が設定されている場合、wait_for_allオプションが自動的に有効になります。wait_for_allが有効でない場合、クラスタは両方のノードでパラレルに開始される必要があります。または、最初のノードが、見つからない2番目のノードで起動フェンシングを実行します。

6.2.5 NノードクラスタのCorosync設定

2ノードクラスタを使用しない場合、Nノードクラスタに奇数のノードを使用することを強くお勧めします。クォーラム設定の場合、次のオプションがあります。

  • crm cluster joinコマンドを使用したノードの追加、または

  • Corosync設定の手動調整。

/etc/corosync/corosync.confを手動で調整する場合、次の設定を使用します。

例 6.2: NノードクラスタのCorosync設定の例
quorum {
   provider: corosync_votequorum 1
   expected_votes: N 2
   wait_for_all: 1 3
}

1

Corosyncからのクォーラムサービスの使用

2

予想される投票数。このパラメータはquorumセクション内で提供されるか、またはnodelistセクションが利用できる場合に自動的に計算されます。

3

wait for all (WFA)機能を有効にします。WFAが有効な場合、クラスタはすべてのノードが認識可能になった後でのみ定足数に達します。一部の起動時の競合状態を回避するために、wait_for_all1に設定すると役立つ場合があります。たとえば、5ノードクラスタでは、すべてのノードに1つの投票が割り当てられているため、expected_votes5に設定します。3つ以上のノードが互いに認識できる場合、クラスタパーティションが定足数に達し、動作を開始できます。

6.3 クラスタリソース

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

6.3.1 リソースの管理

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

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

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

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

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

クラスタ内でリソースを設定したら、クラスタ管理ツールを使用して、すべてのリソースを手動で起動、停止、クリーンアップ、削除、または移行します。これらの操作の詳細については、使用しているクラスタ管理ツールに応じて次のいずれかを参照してください。

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

クラスタリソースとクラスタノードは異なる名前にする必要があります。そうでない場合、Hawk2は失敗します。

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

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

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

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

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

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

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

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

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

Linux Standards Base (LSB)スクリプト

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

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

Systemd

SUSE Linux Enterprise 12から、一般的なSystem V initデーモンがsystemdに置き代わりました。Pacemakerは、systemdサービスが存在する場合は、それを管理できます。initスクリプトの代わりに、systemdはユニットファイルを持ちます。一般的に、サービス(またはユニットファイル)は、オペレーティングシステムによって提供されます。既存のinitスクリプトを変換する場合は、http://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は、モニタリングプラグインが存在する場合は、これを使用してリモートモニタリングを実行できます。詳細については、6.6.1項 「監視プラグインを使用したリモートホストでのサービスの監視」を参照してください。

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

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

High Availability Extensionで提供されるエージェントは、OCF仕様に従って作成されています。

6.3.3 リソースのタイプ

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

プリミティブ

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

選択したクラスタ管理ツールでプリミティブリソースを作成する方法については、次を参照してください。

グループ

グループには、一緒の場所で見つけ、連続して開始し、逆の順序で停止する必要のあるリソースセットが含まれます。詳細については、6.3.5.1項 「グループ」を参照してください。

クローン

クローンは、複数のホスト上でアクティブにできるリソースです。対応するリソースエージェントがサポートしていれば、どのようなリソースもクローン化できます。詳細については、6.3.5.2項 「クローン」を参照してください。

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

6.3.4 リソーステンプレート

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

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

選択したクラスタ管理ツールでリソーステンプレートを定義する方法については、次を参照してください。

6.3.5 高度なリソースタイプ

プリミティブは、最も単純なタイプのリソースなので、設定が容易ですが、クラスタ設定には、より高度なリソースタイプ(グループ、クローン、プロモータブルクローンリソースなど)が必要になることがあります。

6.3.5.1 グループ

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

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

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

グループリソース
図 6.1: グループリソース

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

開始と停止

リソースは認識される順序で開始し、逆の順番で停止します。

依存関係

グループ内のリソースがどこかで開始できない場合は、グループ内のその後の全リソースは実行することができません。

目次

グループにはプリミティブクラスタリソースしか含むことができません。グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループリソースの子を参照するには、グループのIDではなく子のIDを使用します。

制約

制約でグループの子を参照することはできますが、通常はグループ名を使用することをお勧めします。

固着性

固着性はグループ内で統合可能なプロパティです。グループ内のアクティブな各メンバーは、グループの合計値に対して固着性を追加します。したがって、デフォルトのresource-stickiness100で、グループに7つのメンバーがあり、そのうち5つがアクティブな場合は、グループが全体として、スコア500で、現在の場所を優先します。

リソース監視

グループのリソース監視を有効にするには、グループ内で監視の必要な各リソースに対して監視を設定する必要があります。

選択したクラスタ管理ツールでグループを作成する方法については、次を参照してください。

6.3.5.2 クローン

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

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

匿名クローン

最も簡単なクローンタイプです。実行場所にかかわらず、同じ動作をします。このため、マシンごとにアクティブな匿名クローンのインスタンスは1つだけ存在できます。

グローバルに固有なクローン

このリソースは独自のエントリです。1つのノードで実行しているクローンのインスタンスは、別なノードの別なインスタンスとは異なり、同じノードの2つのインスタンスが同一になることもありません。

プロモータブルクローン(マルチステートリソース)

このリソースのアクティブインスタンスは、アクティブとパッシブという2つの状態に分けられます。これらはプライマリとセカンダリと呼ばれることもあります。プロモータブルクローンが、匿名またはグローバルに固有の場合もあります。6.3.5.3項 「プロモータブルクローン(マルチステートリソース)」も参照してください。

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

リソースのモニタリングまたは制約を設定する場合、クローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(http://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。特に、「Clones - Resources That Get Active on Multiple Hosts」のセクションを参照してください。

選択したクラスタ管理ツールでクローンを作成する方法については、次を参照してください。

6.3.5.3 プロモータブルクローン(マルチステートリソース)

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

リソースのモニタリングまたは制約を設定する場合、プロモータブルクローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』を参照してください。Pacemaker 1.1のバージョンはhttp://www.clusterlabs.org/pacemaker/doc/から入手できます。特に、「Multi-state - Resources That Have Multiple Modes」のセクションを参照してください。

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

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

表 6.1: プリミティブリソースのオプション

オプション

説明

デフォルト

優先度

一部のリソースをアクティブにできない場合、クラスタは優先度の低いリソースを停止して、優先度の高いリソースをアクティブに維持します。

0

target-role

クラスタが維持しようとするこのリソースの状態。使用できる値: Stopped (停止)Started (開始)Unpromoted (未昇格)Promoted (昇格)

開始日

is-managed

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

true

保守モード

リソースは手動でタッチできるかどうか。使用できる値:truefalsetrueに設定すると、すべてのリソースが非管理対象になり、クラスタによる監視が停止されるため、ステータスは追跡されなくなります。クラスタによってクラスタリソースの再起動が試行される代わりに、ユーザがクラスタリソースを停止または再起動できます。

false

resource-stickiness

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

計算済み

migration-threshold

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

INFINITY (無効)

multiple-active

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

stop_start

failure-timeout

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

0 (無効)

allow-migrate

migrate_toまたはmigrate_fromのアクションをサポートするリソースにリソース移行を許可。

false

remote-node

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

警告
警告: 固有のIDの使用

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

なし(無効)

remote-port

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

3121

remote-addr

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

remote-node (ホスト名として使用される値)

remote-connect-timeout

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

60s

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

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

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

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

root # crm ra info resource_agent

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

たとえば、次のコマンドを使用します。

root # crm ra info IPaddr

次の出力が返されます。

Manages virtual IPv4 addresses (portable version) (ocf:heartbeat:IPaddr)

This script manages IP alias IP addresses
It can add an IP alias, or remove one.

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

ip* (string): IPv4 address
The IPv4 address to be configured in dotted quad notation, for example
"192.168.1.1".

nic (string, [eth0]): Network interface
The base network interface on which the IP address will be brought
online.

If left empty, the script will try and determine this from the
routing table.

Do NOT specify an alias interface in the form eth0:1 or anything here;
rather, specify the base interface only.

cidr_netmask (string): Netmask
The netmask for the interface in CIDR format. (ie, 24), or in
dotted quad notation  255.255.255.0).

If unspecified, the script will also try to determine this from the
routing table.

broadcast (string): Broadcast address
Broadcast address associated with the IP. If left empty, the script will
determine this from the netmask.

iflabel (string): Interface label
You can specify an additional label for your IP address here.

lvs_support (boolean, [false]): Enable support for LVS DR
Enable support for LVS Direct Routing configurations. In case a IP
address is stopped, only move it to the loopback device to allow the
local node to continue to service requests, but no longer advertise it
on the network.

local_stop_script (string):
Script called when the IP is released

local_start_script (string):
Script called when the IP is added

ARP_INTERVAL_MS (integer, [500]): milliseconds between gratuitous ARPs
milliseconds between ARPs

ARP_REPEAT (integer, [10]): repeat count
How many gratuitous ARPs to send out when bringing up a new address

ARP_BACKGROUND (boolean, [yes]): run in background
run in background (no longer any reason to do this)

ARP_NETMASK (string, [ffffffffffff]): netmask for ARP
netmask for ARP - in nonstandard hexadecimal format.

Operations' defaults (advisory minimum):

start         timeout=90
stop          timeout=100
monitor_0     interval=5s timeout=20s
注記
注記: グループ、クローン、またはプロモータブルクローンのインスタンス属性

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

6.3.8 リソース操作

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

表 6.2: リソース操作のプロパティ

操作

説明

id

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

name

実行するアクション。共通の値: monitorstartstop

interval

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

timeout

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

requires

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

on-fail

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

  • ignore: リソースが失敗しなかったのように動作します。

  • block: リソースにこれ以上の操作を実行しません。

  • stop: リソースを停止して、他の場所でも開始しません。

  • restart: リソースを停止して再起動します(別のノード上で)。

  • fence: リソースが失敗したノードを停止します(STONITH)。

  • standby: リソースが失敗したノードからすべてのリソースを移動させます。

enabled

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

role

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

record-pending

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

description

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

6.3.9 タイムアウト値

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

  • op_defaults (操作用のグローバルタイムアウト)

  • リソーステンプレートに対して定義された特定のタイムアウト値

  • リソースに対して定義された特定のタイムアウト値

注記
注記: 値の優先度

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

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

  1. リソースでタイムアウトが発生すると、リソースは失敗し、クラスタはリソースを停止しようとします。

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

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

手順 6.1: タイムアウト値の決定
  1. 負荷の下でリソースが開始および停止するためにかかる時間を確認します。

  2. 必要に応じて、op_defaultsパラメータを追加して、それに応じて(デフォルトの)タイムアウト値を設定します。

    1. たとえば、op_defaults60秒に設定します。

      crm(live)configure#  op_defaults timeout=60
    2. さらに長い時間を必要とするリソースについては、個別の値を定義します。

  3. あるリソースに対して操作を設定する場合には、個別のstartおよびstop操作を追加します。Hawk2を使用して設定する場合、これらの操作に適したタイムアウト値候補が表示されます。

6.4 リソース監視

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

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

  • /etc/corosync/corosync.confloggingセクションで指定された設定に従って、ログファイルメッセージが生成されます。

  • 障害がクラスタ管理ツール(Hawk2、crm status)と、CIBステータスセクションに反映されます。

  • クラスタが明瞭な復旧アクションを開始します。これらのアクションには、リソースを停止して障害状態を修復する、ローカルまたは別のノードでリソースを再起動するなどが含まれる場合があります。設定やクラスタの状態によっては、リソースが再起動されないこともあります。

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

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

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

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の値に依存したくない場合は、このリソースの「プローブ」に対して特定の監視操作を定義します。interval0に設定した監視操作を追加することで、この操作を行います。たとえば次のようになります。

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

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

選択したクラスタ管理ツールでリソースに対して監視操作を追加する方法については、次を参照してください。

6.5 リソースの制約

すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが必要なすべてのリソースを認識しても、正しく処理できるとは限りません。リソースの制約を指定して、リソースを実行可能なクラスタノード、リソースのロード順序、特定のリソースが依存している他のリソースを指定することができます。

6.5.1 制約のタイプ

使用可能な制約には3種類あります。

リソースの場所

場所の制約はリソースを実行できるノード、できないノード、または実行に適したノードを定義するものです。

リソースのコロケーション

コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。

リソースの順序

アクションの順序を定義する、順序の制約です。

重要
重要: 制約および特定のタイプのリソースに関する制限
  • リソースグループの「メンバー」に対してコロケーション制約を作成しないでください。代わりに、リソースグループ全体を指すリソース制約を作成してください。その他のタイプの制約はすべて、リソースグループのメンバーに対して使用しても問題ありません。

  • クローンリソースまたはプロモータブルクローンリソースが適用されているリソースで制約を使用しないでください。制約はクローンまたはプロモータブルクローンリソースに適用する必要があり、その子リソースに適用することはできません。

6.5.1.1 リソースセット

6.5.1.1.1 制約を定義するためにリソースセットを使用する

場所、コロケーション、または順序の制約を定義するための別のフォーマットとして、resource setsを使用することができます。リソースセットでは、プリミティブが1つのセットでグループ化されます。以前は、これはリソースグループを定義するか(デザインを正確に表現できない場合もあった)、個々の制約として各関係を定義することでこの操作が可能でした。個々の制約として定義した場合、多数のリソースとの組み合わせが増えるにつれて、制約が飛躍的に増加しました。リソースセットを介した設定で、冗長性が常に低減されるわけではありませんが、次の例が示すように、定義内容の把握と管理がより容易になります。

例 6.4: 場所制約のリソースセット

たとえば、crmshでリソースセット(loc-alice)の次の設定を使用して、2つの仮想IP (vip1vip2)を同じノードaliceに配置できます。

crm(live)configure# primitive vip1 IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip2 IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice

リソースセットを使用してコロケーション制約の設定を置き換える場合は、次の2つの例を検討します。

例 6.5: コロケートされたリソースのチェーン
<constraints>
     <rsc_colocation id="coloc-1" rsc="B" with-rsc="A" score="INFINITY"/>
     <rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/>
     <rsc_colocation id="coloc-3" rsc="D" with-rsc="C" score="INFINITY"/>
</constraints>

リソースセットで表される同一の設定:

<constraints>
    <rsc_colocation id="coloc-1" score="INFINITY" >
     <resource_set id="colocated-set-example" sequential="true">
      <resource_ref id="A"/>
      <resource_ref id="B"/>
      <resource_ref id="C"/>
      <resource_ref id="D"/>
     </resource_set>
    </rsc_colocation>
</constraints>

リソースセットを使用して順序の制約の設定を置き換える場合は、次の2つの例を検討します。

例 6.6: 順序付けされたリソースのチェーン
<constraints>
     <rsc_order id="order-1" first="A" then="B" />
     <rsc_order id="order-2" first="B" then="C" />
     <rsc_order id="order-3" first="C" then="D" />
</constraints>

順序付けされたリソースを持つリソースセットを使用して、同様な目的を達成できます。

例 6.7: リソースセットとして表される順序付けされたリソースのチェーン
<constraints>
     <rsc_order id="order-1">
     <resource_set id="ordered-set-example" sequential="true">
     <resource_ref id="A"/>
     <resource_ref id="B"/>
     <resource_ref id="C"/>
     <resource_ref id="D"/>
     </resource_set>
     </rsc_order>
</constraints>

これらのセットは、順序付けされている(sequential=true)場合もあれば、順序付けされていない場合(sequential=false)場合もあります。また、require-all属性を使用して、ANDおよびORロジック間を切り替えることができます。

6.5.1.1.2 依存関係のないコロケーション制約のリソースセット

同じノード上にリソースのグループを配置する方が役立つ場合がありますが(コロケーション制約を定義)、リソース間に困難な依存関係を持つことはありません。たとえば、同じノード上に2つのリソースを配置したいが、それらの一方で障害が発生した場合に他方をクラスタで再起動したくない場合があります。これは、weak bondコマンドを使用して、crmシェルで実行できます。

選択したクラスタ管理ツールでこれらの弱い結合を設定する方法については、次を参照してください。

6.5.1.2 詳細の参照先

様々な種類の制約を追加する方法については、選択したクラスタ管理ツールに応じて次のいずれかを参照してください。

制約の設定の詳細や、順序付けおよびコロケーションの基本的な概念についての詳しいバックグラウンド情報は次のドキュメントを参照してください。これらのドキュメントは、http://www.clusterlabs.org/pacemaker/doc/で入手できます。

  • Pacemaker Explained』の「Resource Constraints」の章

  • Colocation Explained

  • オーダーの概要

6.5.2 スコアと無限大

制約を定義する際は、スコアも扱う必要があります。あらゆる種類のスコアはクラスタの動作方法と密接に関連しています。スコアの操作によって、リソースのマイグレーションから、速度が低下したクラスタで停止するリソースの決定まで、あらゆる作業を実行できます。スコアはリソースごとに計算され、リソースに対して負のスコアが付けられているノードは、そのリソースを実行できません。リソースのスコアを計算した後、クラスタはスコアが最も高いノードを選択します。

INFINITYは現在1,000,000と定義されています。この値の増減は、次の3つの基本ルールに従います。

  • 任意の値+ INFINITY = INFINITY

  • 任意の値- INFINITY = -INFINITY

  • INFINITY - INFINITY = -INFINITY

リソース制約を定義する際は、各制約のスコアを指定します。スコアはこのリソース制約に割り当てる値を示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。1つのリソースに対して場所の制約を複数作成し、それぞれに異なるスコアを指定することで、リソースがフェールオーバーするノードの順序を指定できます。

6.5.3 リソーステンプレートと制約

リソーステンプレートを定義したら(6.3.4項 「リソーステンプレート」を参照)、次のタイプの制約で参照できます。

  • 順序の制約

  • コロケーション制約

  • rsc_ticket制約(Geoクラスタの場合)

ただし、コロケーション制約には、テンプレートへの参照を複数含めることはできません。リソースセットには、テンプレートへの参照を含めることはできません。

制約内で参照されたリソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表します。これは、そのリソーステンプレートを参照しているすべてのプリミティブリソースに、この制約が適用されることを意味します。制約内でリソーステンプレートを参照すれば、リソースセットの代替となり、クラスタ設定をかなりの程度単純化することができます。リソースセットの詳細については、手順7.17「制約のためにリソースセットを使用する」を参照してください。

6.5.4 フェールオーバーノード

リソースに障害が発生すると、自動的に再起動されます。現在のノードで再起動できない場合、または現在のノードでN回失敗した場合は、別のノードへのフェールオーバーが試行されます。リソースが失敗するたびに、その失敗回数が増加します。新しいノードへのマイグレートを行う基準(migration-threshold)となるリソースの失敗をいくつか定義できます。クラスタ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先のノードはHigh Availabilityソフトウェアが選択します。

ただし、リソースに1つ以上の場所の制約とmigration-thresholdを設定することで、そのリソースのフェールオーバー先にするノードを指定できます。

選択したクラスタ管理ツールでフェールオーバーノードを指定する方法については、次を参照してください。

例 6.8: マイグレーションしきい値 - プロセスフロー

たとえば、リソース「rsc1」に場所の制約を設定し、このリソースを「alice」で優先的に実行するように指定したと仮定します。そのノードで実行できなかった場合は、「migration-threshold」を確認して失敗回数と比較します。失敗回数 >= マイグレーションしきい値の場合は、リソースは次の優先実行先として指定されているノードにマイグレートされます。

デフォルトでは、いったんしきい値に達すると、そのノードでは、リソースの失敗回数がリセットされるまで、失敗したリソースを実行できなくなります。これは、手動でクラスタ管理者が行うか、リソースにfailure-timeoutオプションを設定することで実行できます。

たとえば、migration-threshold=2failure-timeout=60sを設定すると、リソースは、2回の失敗の後に新しいノードに移行します。そして、1分後に復帰できます(固着性と制約のスコアによる)。

移行しきい値の概念には2つの例外があり、これらの例外は、リソースの開始失敗か、停止失敗のどちらかで発生します。

  • 起動の失敗では、失敗回数がINFINITYに設定されるので、常に、即時に移行が行われます。

  • 停止時の失敗ではフェンシングが発生します([stonith-enabled]がデフォルトである「true」に設定されている場合)。

    STONITHリソースが定義されていない場合は(またはstonith-enabledfalseに設定されている場合)、リソースの移行は行われません。

選択したクラスタ管理ツールでマイグレーションしきい値を使用し、失敗回数をリセットする方法については、次を参照してください。

6.5.5 フェールバックノード

ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元のノードにフェールバックすることがあります。リソースを実行していたノードにリソースをフェールバックさせたくない場合や、リソースのフェールバック先として別のノードを指定する場合は、リソースの固着性の値を変更します。リソースの固着性は、リソースの作成時でも、その後でも指定できます。

リソース固着性値の指定時には、次の予想される結果について考慮してください。

0の値:

デフォルトです。リソースはシステム内で最適な場所に配置されます。現在よりも状態のよい、または負荷の少ないノードが使用可能になると、移動することを意味しています。このオプションは自動フェールバックとほとんど同じですが、以前アクティブだったノード以外でもリソースをフェールバックできるという点が異なります。

0より大きい値:

リソースは現在の場所に留まることを望んでいますが、状態がよいノードが使用可能になると移動される可能性があります。値が大きくなるほど、リソースが現在の場所に留まることを強く望んでいることを示します。

0より小さい値:

リソースは現在の場所から別な場所に移動することを望んでいます。絶対値が大きくなるほど、リソースが移動を強く望んでいることを示します。

INFINITYの値:

ノードがリソースの実行権利がなくなったために強制終了される場合(ノードのシャットダウン、ノードのスタンバイ、migration-thresholdに到達、または設定変更)以外は、リソースは常に現在の場所に留まります。このオプションは自動フェールバックを完全に無効にする場合とほとんど同じです。

-INFINITYの値:

リソースは現在の場所から常に移動されます。

6.5.6 負荷インパクトに基づくリソースの配置

すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースでは、そのホストであるノードがリソースの容量要件を満たす必要があります。リソースの組み合わされたニーズが提供された容量より大きくなるようにリソースが配置されると、リソースのパフォーマンスが低下します(あるいは失敗することさえあります)。

これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定できます。

  1. 一定のノードが提供する容量

  2. 一定のリソースが要求する容量

  3. リソースの配置に関する全体的なストラテジ

選択したクラスタ管理ツールでこれらの設定を設定する方法については、次を参照してください。

ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソースに対して資格があるとみなされます。High Availability Extensionにとって、容量の性質は重要ではありません。High Availability Extensionは、リソースをノードに移動する前に、リソースのすべての容量要件が満たされているかどうかを確認するだけです。

リソースの要件とノードが提供する容量を手動で設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。ただし、属性値は、整数にする必要があります。

使用属性を持つ複数のリソースがグループ化されていたり、これらにコロケーション制約がある場合、High Availability Extensionではそのことを考慮に入れます。可能な場合、これらのリソースは、すべての容量要件を満たすことができるノードに配置されます。

注記
注記: グループの使用属性

リソースグループに対して使用属性を直接設定することはできません。ただし、グループの設定を簡素化するために、グループ内のすべてのリソースに必要な合計容量を含む使用属性を追加することができます。

High Availability Extensionには、ノードの容量とリソースの要件を自動的に検出し、設定する手段も用意されています。

NodeUtilizationリソースエージェントは、ノードの容量をチェックします(CPUとRAMについて)。自動検出を設定するには、クラス、プロバイダ、タイプがocf:pacemaker:NodeUtilizationのクローンリソースを作成します。このクローンのインスタンスが各ノードに1つずつ実行している必要があります。インスタンスが開始すると、CIBでそのノードの設定にutilizationセクションが追加されます。

リソースの最小要件の自動検出(RAMとCPU)に配慮し、Xenリソースエージェントが改良されました。Xenリソースは、開始時点でRAMとCPUの消費状況を反映します。リソース設定には、使用属性が自動的に追加されます。

注記
注記: Xenとlibvirtに異なるリソースエージェントを適用

ocf:heartbeat:Xenリソースエージェントは、libvirtに使用するべきではありません。libvirtではマシン記述ファイルの変更が想定されているためです。

libvirtには、ocf:heartbeat:VirtualDomainリソースエージェントを使用します。

最小要件を検出することに加え、High Availability Extensionは、VirtualDomainリソースエージェントを通して現在の利用状況を監視することができ、仮想マシンでのCPUとRAMの使用状況を検出します。この機能を使用するには、クラス、プロバイダ、およびタイプがocf:heartbeat:VirtualDomainのリソースを設定します。次のインスタンス属性を使用できます。autoset_utilization_cpuautoset_utilization_hv_memory。両方ともデフォルトはtrueです。これにより、監視サイクルのたびにCIBで使用値が更新されます。

容量と要件を手動と自動のどちらで設定する場合でも、placement-strategyプロパティ(グローバルクラスタオプション内)で、配置ストラテジを指定する必要があります。次の値を使用できます。

default (デフォルト値)

使用値は考慮しません。リソースは、場所のスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。

utilization

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当てられたリソースの数に基づいて行われます。

minimal

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。できるだけ少ない数のノードにリソースを集中しようとします(残りのノードの電力節約のため)。

balanced

リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。リソースを均等に分散して、リソースのパフォーマンスを最適化しようとします。

注記
注記: リソース優先度の設定

使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリスティックソルバで、常に最適な割り当て結果を得るには至っていません。リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュールされるようにしてください。

例 6.9: 負荷分散型配置の設定例

次の例は、同等のノードから成る3ノードクラスタと4つの仮想マシンを示しています。

node alice utilization memory="4000"
node bob utilization memory="4000"
node  charlie utilization memory="4000"
primitive xenA Xen utilization hv_memory="3500" \
     params xmfile="/etc/xen/shared-vm/vm1"
     meta priority="10"
primitive xenB Xen utilization hv_memory="2000" \
     params xmfile="/etc/xen/shared-vm/vm2"
     meta priority="1"
primitive xenC Xen utilization hv_memory="2000" \
     params xmfile="/etc/xen/shared-vm/vm3"
     meta priority="1"
primitive xenD Xen utilization hv_memory="1000" \
     params xmfile="/etc/xen/shared-vm/vm4"
     meta priority="5"
property placement-strategy="minimal"

3ノードはすべてアクティブであり、まず、リソースxenAがノードに配置され、次に、xenDが配置されます。xenBxenCは、一緒に割り当てられるか、またはどちらか1つがxenDとともに割り当てられます。

1つのノードに障害が発生した場合、残りのノード上で利用できるメモリ合計が少なすぎて、これらのリソースすべてはホストできません。xenAは確実に割り当てられ、xenDも同様です。ただし、残りのリソースxenBxenCは、そのどちらかしか割り当てられません。xenBとxenCの優先度は同等なので、結果はまだ決められません。これを解決するためにも、どちらかに高い優先度を設定する必要があります。

6.5.7 タグの使用によるリソースのグループ化

タグは最近Pacemakerに追加された新機能です。タグは、コロケーションの作成や関係の順序付けを行わずに、複数のリソースをただちに参照する方法です。これは、概念的に関連するリソースをグループ化するのに役立つ場合があります。たとえば、データベースに関連するいくつかのリソースがある場合、databasesというタグを作成し、データベースに関連するすべてのリソースをこのタグに追加します。これにより、1つのコマンドでそれらすべてのリソースを停止または起動できます。

タグは制約でも使用できます。たとえば、次の場所制約loc-db-preferは、databasesでタグ付けしたリソースのセットに適用されます。

location loc-db-prefer databases 100: alice

選択したクラスタ管理ツールでタグを作成する方法については、次を参照してください。

6.6 リモートホストでのサービスの管理

リモートホストでサービスを監視および管理できることが、ここ数年の間にますます重要になってきています。SUSE Linux Enterprise High Availability Extension 11 SP3では、監視プラグインを介したリモートホスト上のサービスの詳細な監視機能を提供してきました。SUSE Linux Enterprise High Availability Extension 15 SP4では、最近追加された pacemaker_remoteサービスを使用すると、リモートマシンにクラスタスタックをインストールしていなくても、実際のクラスタノードと同様にリモートホスト上のリソースを全面的に管理および監視できます。

6.6.1 監視プラグインを使用したリモートホストでのサービスの監視

仮想マシンの監視はVMエージェント(ハイパーバイザにゲストが出現する場合のみチェックを行う)を使用して行うか、VirtualDomainまたはXenエージェントから呼び出される外部スクリプトによって行うことができます。これまでは、精度の高い監視を行うには、仮想マシン内にHigh Availabilityスタックを完全にセットアップするしか方法がありませんでした。

今回、High Availability Extensionでは、監視プラグイン(旧称はNagiosプラグイン)に対するサポートを提供することで、リモートホスト上のサービスを監視できるようになりました。ゲストイメージを変更することなく、ゲストの外部ステータスを収集できます。たとえば、VMゲストはWebサービスまたは単純なネットワークリソースを実行している可能性があり、これらはアクセス可能である必要があります。Nagiosリソースエージェントによって、ゲスト上のWebサービスまたはネットワークリソースを監視できるようになりました。これらのサービスにアクセスできなくなった場合は、High Availability Extensionがそれぞれのゲストの再起動またはマイグレーションをトリガします。

ゲストがサービス(そのゲストによって使用されるNFSサーバなど)に依存している場合、そのサービスは、クラスタによって管理される通常のリソースか、Nagiosリソースによって監視される外部サービスのどちらかにすることができます。

Nagiosリソースを設定するには、ホスト上に次のパッケージをインストールする必要があります:

  • monitoring-plugins

  • monitoring-plugins-metadata

必要に応じて、YaSTまたはZypperが、これ以上のパッケージに対する依存性を解決します。

一般的な使用例としては、1つのリソースコンテナに属するリソースとして監視プラグインを設定します。このリソースコンテナは通常はVMです。いずれかのリソースに障害が発生したら、このコンテナが再起動されます。設定例については、例6.10「監視プラグインのリソースの設定」を参照してください。または、Nagiosリソースエージェントを使用してネットワーク経由でホストまたはサービスを監視する場合、このエージェントを通常のリソースとして設定することもできます。

例 6.10: 監視プラグインのリソースの設定
primitive vm1 VirtualDomain \
    params hypervisor="qemu:///system" config="/etc/libvirt/qemu/vm1.xml" \
    op start interval="0" timeout="90" \
    op stop interval="0" timeout="90" \
    op monitor interval="10" timeout="30"
primitive vm1-sshd nagios:check_tcp \
    params hostname="vm1" port="22" \ 1
    op start interval="0" timeout="120" \ 2
    op monitor interval="10"
group g-vm1-and-services vm1 vm1-sshd \
    meta container="vm1" 3

1

サポートされるパラメータは、監視プラグインの長いオプションと同じです。プラグインは、パラメータhostnameによってサービスと接続します。したがって、この属性の値は解決可能なホスト名かIPアドレスである必要があります。

2

ゲストオペレーティングシステムが起動してサービスが実行されるまでには少し時間がかかるので、監視リソースの起動タイムアウトは十分な長さに設定する必要があります。

3

タイプがocf:heartbeat:Xenocf:heartbeat:VirtualDomain、またはocf:heartbeat:lxcのクラスタリソースコンテナ。VMまたはLinuxコンテナのいずれかに設定できます。

上の例には、check_tcpプラグイン用の1つのリソースしか含まれていませんが、様々なプラグインタイプ(たとえば、check_httpcheck_udpなど)用に複数のリソースを設定することもできます。

複数のサービスのホスト名が同じである場合、hostnameパラメータを個別のプリミティブに追加するのではなく、グループに対して指定することもできます。例:

group g-vm1-and-services vm1 vm1-sshd vm1-httpd \
     meta container="vm1" \
     params hostname="vm1"

監視プラグインによって監視されているいずれかのサービスに、VM内で障害が発生した場合は、クラスタがこれを検出し、コンテナリソース(VM)を再起動します。この場合に実行される操作は、サービスの監視操作に関するon-fail属性を指定することで設定できます。デフォルトでは、restart-containerに設定されています。

VMのマイグレーションしきい値を検討する場合は、サービスの障害発生回数が考慮されます。

6.6.2 pacemaker_remoteを使用したリモートノードでのサービスの管理

pacemaker_remoteサービスを使用すると、High Availabilityクラスタを仮想ノードまたはリモートベアメタルマシンに拡張することができます。クラスタスタックを実行して、クラスタのメンバーになる必要はありません。

High Availability Extensionでは現在、仮想環境(KVMおよびLXC)、およびこれらの仮想環境内に存在するリソースを起動できるようになりました(PacemakerまたはCorosyncの実行に仮想環境は必要としません)。

クラスタリソースとしての仮想マシンおよびVM内に存在するリソースの両方を管理する使用例では、次の設定を使用できるようになりました。

  • 通常(ベアメタル)クラスタノードは、High Availability Extensionを実行します。

  • 仮想マシンは、pacemaker_remoteサービスを実行します(VM側で必要な設定はほとんどありません)。

  • 通常クラスタノード上のクラスタスタックはVMを起動し、VM上で実行されているpacemaker_remoteサービスに接続して、それらをリモートノードとしてクラスタに統合します。

リモートノードでクラスタスタックがインストールされていないときは、これには次の意味があります。

  • リモートノードはクォーラムに参加しません。

  • リモートノードはDCになることはできません。

  • リモートノードは、スケーラビリティの制約に制限されません(Corosyncには32ノードのメンバー制限があります)。

remote_pacemakerサービスに関する詳細については(詳細な設定手順からなる複数の使用例を含む)、Pacemaker Remote Quick Startを参照してください。

6.7 システムヘルスの監視

ノードがディスク容量が使い尽くしたために、そこに割り当てられたリソースを管理できなくなることを避けるため、High Availability Extensionでは、ocf:pacemaker:SysInfoというリソースエージェントが提供されています。これを使用して、ディスクパーティションに関してノードのヘルスを監視します。SysInfo RAは、#health_diskという名前のノード属性を作成します。この属性は、監視対象のディスク空き容量が指定された制限を下回るとredに設定されます。

ノードのヘルスがクリティカルな状態に達した場合のCRMの対応方法を定義するには、グローバルなクラスタオプションであるnode-health-strategyを使用します。

手順 6.2: システムヘルスの監視設定

ノードがディスク容量を使い尽くした場合に、リソースを自動的にノードから移動させるには、次の手順に従います。

  1. ocf:pacemaker:SysInfoリソースを設定します。

    primitive sysinfo ocf:pacemaker:SysInfo \
         params disks="/tmp /var"1 min_disk_free="100M"2 disk_unit="M"3 \
         op monitor interval="15s"

    1

    監視対象のディスクパーティション。たとえば、/tmp/usr/var/devなど。複数のパーティションを属性値として指定するには、空白で区切ります。

    注記
    注記: /のファイルシステムは常に監視されます。

    disksでルートパーティション(/)を指定する必要はありません。これはデフォルトで常に監視されます。

    2

    これらのパーティションの必要最小限の空きディスク容量。オプションで、計測に使用する単位を指定できます(上記の例では、メガバイトを表すMが使用されています)。指定しない場合、min_disk_freedisk_unitパラメータで定義されている単位にデフォルト設定されます。

    3

    ディスク容量をレポートする場合の単位。

  2. リソース設定を完了するには、ocf:pacemaker:SysInfoのクローンを作成し、各クラスタノードでそれを起動します。

  3. node-health-strategymigrate-on-redに設定します。

    property node-health-strategy="migrate-on-red"

    #health_disk属性がredに設定されている場合、pacemaker-schedulerdによって、そのノードのリソースのスコアに-INFが追加されます。これにより、このノードからすべてのリソースが移動します。この処理はSTONITHリソースのところで停止しますが、STONITHリソースが実行されていない場合でも、ノードをフェンスすることができます。フェンスでCIBに直接アクセスすることで、動作を続行できるからです。

ノードのヘルス状態がredになったら、原因となる問題を解決します。次にredステータスをクリアして、ノードを再びリソースの実行に適した状態にします。クラスタノードにログインして、次のいずれかの方法を使用します。

  • 次のコマンドを実行します。

    root # crm node status-attr NODE delete #health_disk
  • 該当するノードでPacemakerを再起動します。

  • ノードを再起動します。

ノードがサービスに復帰し、再びリソースを実行できるようになります。

6.8 詳細の参照先

http://crmsh.github.io/

crmシェル(crmsh)、High Availabilityクラスタ管理用の高度なコマンドラインインタフェースのホームページ。

http://crmsh.github.io/documentation

crmshを使用した基本的なクラスタ設定の『Getting Started』チュートリアルとcrmシェルの包括的なマニュアルを含む、crmシェルに関するいくつかのドキュメント。マニュアルはhttp://crmsh.github.io/man-2.0/で入手できます。チュートリアルはhttp://crmsh.github.io/start-guide/に用意されています。

http://clusterlabs.org/

High Availability Extensionに含まれているクラスタリソースマネージャであるPacemakerのホームページ。

http://www.clusterlabs.org/pacemaker/doc/

いくつかの包括的なマニュアルと一般的な概念を説明するより簡潔なドキュメント。例:

  • Pacemaker Explained』: 参考として包括的で詳細な情報が記載されています。

  • Colocation Explained

  • オーダーの概要