High Availability Extensionは次のシナリオをサポートしています。

クラスタには、最大32のLinuxサーバを含めることができます。pacemaker_remoteを使用すると、この制限を超えて追加のLinuxサーバを含めるようにクラスタを拡張できます。クラスタ内のどのサーバも、クラスタ内の障害が発生したサーバのリソース(アプリケーション、サービス、IPアドレス、およびファイルシステム)を再起動することができます。

High Availability Extensionには、Corosyncメッセージングおよびメンバーシップ層のほか、Pacemakerクラスタリソースマネージャが標準装備されています。管理者は、Pacemakerを使用して、リソースのヘルスと状態を継続的に監視し、依存関係を管理することができます。高度に設定可能なルールとポリシーに基づいて、サービスを自動的に停止および開始することができます。High Availability Extensionでは、ユーザの組織に適した特定のアプリケーションおよびハードウェアインフラストラクチャに合わせて、クラスタのカスタマイズが可能です。時間依存設定を使用して、サービスを特定の時刻に修復済みのノードに自動的にフェールバック(マイグレート)させることができます。

High Availability Extensionでは必要に応じてサーバストレージを自動的に割り当て、再割り当てすることができます。ファイバチャネルまたはiSCSIストレージエリアネットワーク(SAN)をサポートしています。共有ディスクもサポートされていますが、必要要件ではありません。SUSE Linux Enterprise High Availability Extensionには、クラスタ対応のファイルシステム(OCFS2)とCluster Logical Volume Manager (Cluster LVM2)も含まれています。データをレプリケーションする場合は、DRBD*を使用して、High Availabilityサービスのデータをクラスタのアクティブノードからスタンバイノードへミラーリングします。さらに、SUSE Linux Enterprise High Availability Extensionでは、Sambaクラスタリング技術であるCTDB (Cluster Trivial Database)もサポートしています。

SUSE Linux Enterprise High Availability Extensionは、物理Linuxサーバと仮想Linuxサーバの混合クラスタリングをサポートしています。SUSE Linux Enterprise Server 15 SP3には、オープンソースの仮想化ハイパーバイザであるXenと、KVM (カーネルベースの仮想マシン)が付属しています。KVMは、ハードウェア仮想化の拡張機能に基づいた、Linux用の仮想化ソフトウェアです。High Availability Extension内のクラスタリソースマネージャは、仮想サーバで実行中のサービスと物理サーバで実行中のサービスを認識、監視、および管理できます。ゲストシステムは、クラスタにサービスとして管理されます。

SUSE Linux Enterprise High Availability Extensionは、様々な地理的なシナリオをサポートするように拡張されています。SUSE Linux Enterprise High Availability Extension用のGeo Clusteringでは、地理的に分散したクラスタ(Geoクラスタ)のサポートが利用可能です。

個々のクラスタノード間の地理的距離が大きいほど、クラスタが提供するサービスの高可用性を妨げる可能性のある要因が多くなります。ネットワークの遅延時間、限られた帯域幅およびストレージへのアクセス が長距離クラスタの課題として残ります。

SUSE Linux Enterprise High Availability Extensionには、Apache、IPv4、IPv6、その他多数のリソースを管理するための膨大な数のリソースエージェントが含まれています。またIBM WebSphere Application Serverなどの一般的なサードパーティアプリケーション用のリソースエージェントも含まれています。ご利用の製品に含まれているOpen Cluster Framework (OCF)リソースエージェントの概要は、8.1.3項 「OCFリソースエージェントに関する情報の表示」で説明されるcrm raコマンドを使用してください。

High Availability Extensionには、一連の強力なツールが付属しています。クラスタの基本的なインストールとセットアップ、および効果的な設定と管理のためにこれらのツールを使用してください。

High Availability Extensionのアーキテクチャは層化されています。図1.6「アーキテクチャ」に異なる層と関連するコンポーネントを示します。

図 1.6: アーキテクチャ #

 

pacemakerdデーモンは、その他のあらゆる関連デーモンの起動と監視を行います。pacemaker-controldデーモンはすべてのアクションを統括し、自身のインスタンスを各クラスタノードに配置します。Pacemakerは、マスタとして動作するインスタンスを１つ選択することにより、クラスタのすべての意思決定を一元化します。選択したpacemaker-controldデーモンで障害が発生する場合は、新たなインスタンスがマスタになります。

クラスタ内で実行するアクションの多くは、クラスタ全体におよぶ変更を伴います。これらのアクションにはクラスタリソースの追加や削除、リソース制約の変更などがあります。このようなアクションを実行する場合は、クラスタ内でどのような変化が発生するのかを理解することが重要です。

たとえば、クラスタIPアドレスリソースを追加するとします。そのためには、crmシェルかWebインタフェースを使用してCIBを変更できます。DCでアクションを実行する必要はありません。クラスタの任意のノードでいずれかのツールを使用して、DCにリレーされます。そして、DCがすべてのクラスタノードにCIBの変更を複製します。

このときは、CIBの情報に基づいて、pacemaker-schedulerdがクラスタの理想的な状態とその達成方法を計算し、命令のリストをDCにフィードします。DCはメッセージング/インフラストラクチャ層を介してコマンドを送信し、他のノードのpacemaker-controldピアがこれらのコマンドを受信します。それぞれのピアは、ローカルでリソースエージェントエグゼキュータ(pacemaker-execd)を使用してリソースに変更を加えます。pacemaker-execdはクラスタに対応しておらず、リソースエージェントと直接通信します。

すべてのピアノードは操作結果をDCに返送します。DCが、すべての必要な操作がクラスタ内で成功したことを確認すると、クラスタはアイドル状態に戻り、次のイベントを待機します。予定通り実行されなかった操作があれば、CIBに記録された新しい情報を基に、pacemaker-schedulerdを再度呼び出します。

場合によっては、共有データの保護や完全なリソース復旧のためにノードの電源を切らなければならないことがあります。Pacemakerクラスタにおけるノードレベルフェンシングの実装は、STONITHです。このPacemakerにはフェンシングサブシステムpacemaker-fencedが内蔵されています。STONITHデバイスは、(特定のフェンシングエージェントを使用する)クラスタリソースとして設定する必要があります。これにより、初めてフェンシングデバイスの監視が可能になるからです。クライアントは障害を検出すると、pacemaker-fencedへ要求を送信します。このデーモンはフェンシングエージェントを実行することにより、ノードを停止します。

Csync2を使用してファイルを正常に同期するには、以下の前提条件が満たされている必要があります。

したがって、Csync2を初めて実行する前に、以下の準備を行う必要があります。

Csync2オプションの詳細については、次のコマンドを実行してください

csync2 -help

注記: 変更後の同期のプッシュ

Csync2は変更のみをプッシュします。Csync2はマシン間でファイルを絶えず同期しているわけではありません。

同期が必要なファイルを更新する際はいつも、変更を加えたマシン上でcsync2  -xvを実行することで、変更をその他のマシンにプッシュする必要があります。変更されていないファイルが配置された他のマシン上でこのコマンドを実行しても、何も起こりません。

この項は次のシナリオに適用されます。

クラスタがまだこれらより古い製品バージョンに基づいている場合は、まず、必要なターゲットバージョンにアップグレードするためのソースとして使用できるバージョンのSLESおよびSLE HAにクラスタをアップグレードします。

注記: CIB構文バージョンのアップグレード

新しい機能は、最新のCIB構文バージョンでのみ使用可能な場合もあります。新しい製品バージョンにアップグレードした場合でも、デフォルトではCIB構文バージョンはアップグレードされません。

1. バージョンをチェックします。

   cibadmin -Q | grep validate-with

2. 最新のCIB構文バージョンにアップグレードします。

   root # cibadmin --upgrade --force

手順 5.2: 製品バージョン12から15へのアップグレード: クラスタオフラインアップグレード #

 

重要: 最初からのインストール

クラスタノードを(アップグレードするのではなく)最初からインストールすることにした場合、2.2項 「ソフトウェアの必要条件」SUSE Linux Enterprise High Availability Extension15 SP3 に必要なモジュールのリストについて、を参照してください。モジュール、拡張機能、および関連製品の詳細については、SUSE Linux Enterprise Server 15のリリースノートを確認してください。これらは、https://www.suse.com/releasenotes/から入手できます。

1. SUSE Linux Enterprise High Availability Extension 15へのオフラインアップグレードを開始する前に、注記: CIB構文バージョンのアップグレードの説明に従って現在のクラスタでCIB構文を手動でアップグレードしてください。

2. 各クラスタノードにログインし、次のコマンドを使用してクラスタスタックを停止します。

   root # crm cluster stop

3. クラスタノードごとに、目的のターゲットバージョンのSUSE Linux Enterprise ServerおよびSUSE Linux Enterprise High Availability Extensionへのアップグレードを実行します。5.2.1項 「SLE HAおよびSLE HA Geoでサポートされるアップグレードパス」を参照してください。

4. アップグレードプロセスが完了した後で、SUSE Linux Enterprise ServerおよびSUSE Linux Enterprise High Availability Extensionのアップグレード済みバージョンがインストールされた各ノードにログインして起動します。

5. Cluster LVMを使用する場合は、clvmdからlvmlockdに移行する必要があります。lvmlockdのマニュアルページの「changing a clvm VG to a lockd VG」および22.4項 「Mirror LVからCluster MDへのオンラインマイグレーション」を参照してください。

6. 次のコマンドを実行してこのクラスタスタックを開始します。

   root # crm cluster start

7. crm statusまたはHawk2を使用してクラスタの状態を確認します。

この項は次のシナリオに適用されます。

シナリオに合わせて次の手順のいずれかを使用します。

警告: アクティブなクラスタスタック

ノードのアップグレードを開始する前に、「そのノード上の」クラスタスタックを「停止」します。

ソフトウェアの更新中にノード上のクラスタリソースマネージャがアクティブな場合、アクティブノードのフェンシングのような結果を招く場合があります。

重要: クラスタローリングアップグレードの時間制限

最新の製品バージョンに装備されている新機能は、「すべての」クラスタノードが最新の製品バージョンにアップグレードされた後でないと使用できません。混合バージョンのクラスタは、クラスタローリングアップグレード中の短いタイムフレームでのみサポートされます。クラスタローリングアップグレードは1週間以内に完了してください。

すべてのオンラインノードでアップグレードされたバージョンが実行される場合、古いバージョンの他のノードはアップグレードせずに(再)参加できなくなります。

重要: ローリングアップグレードの時間制限

最新の製品バージョンに装備されている新機能は、「すべての」クラスタノードが最新の製品バージョンにアップグレードされた後でないと使用できません。混合バージョンのクラスタは、ローリングアップグレード中の短いタイムフレームでのみサポートされます。ローリングアップグレードは1週間以内に完了してください。

クラスタノードに異なるCRMバージョンが検出される場合、Hawk2の状態画面に警告も表示されます。

多くのお客様は、インプレースアップグレードのほかに、次のサービスパックに移行する場合でも新規インストールを希望しています。次の手順では、ノードaliceとbobを持つ2ノードクラスタを次のサービスパック(SP)にアップグレードする場合のシナリオを示しています。

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

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

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

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

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

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

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

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

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

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番目のノードで起動フェンシングを実行します。

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

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

quorum {
   provider: corosync_votequorum 1
   expected_votes: N 2
   wait_for_all: 1 3
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3.5.1 グループ #

 

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

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

 

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

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

 

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

開始と停止

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

依存関係

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

コンテンツ

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

制約

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

固着性

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

リソース監視

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

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

• Hawk2: 手順7.9「リソースグループの追加」

• crmsh: 8.3.10項 「クラスタリソースグループの設定」

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

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

 

オプション	説明	デフォルト
優先度	一部のリソースをアクティブにできない場合、クラスタは優先度の低いリソースを停止して、優先度の高いリソースをアクティブに維持します。	0
target-role	クラスタが維持しようとするこのリソースの状態。使用できる値: stopped、started、master	開始日
is-managed	クラスタがリソースを開始して停止できるかどうか。使用できる値:true、false値がfalseに設定されていても、リソースの状態は引き続き監視され、障害が発生した場合は報告されます。これは、リソースをmaintenance="true"に設定するのとは異なります。	true
保守モード	リソースは手動でタッチできるかどうか。使用できる値:true、falsetrueに設定すると、すべてのリソースが非管理対象になり、クラスタによる監視が停止されるため、ステータスは追跡されなくなります。クラスタによってクラスタリソースの再起動が試行される代わりに、ユーザがクラスタリソースを停止または再起動できます。	false
resource-stickiness	リソースが現在の状態をどの程度維持したいか。	計算済み
migration-threshold	ノードがこのリソースをホストできなくなるまで、このリソースについてノード上で発生する失敗の回数。	INFINITY (無効)
multiple-active	複数のノードでアクティブなリソースを検出した場合のクラスタの動作。使用できる値: block (リソースを管理されていないとマークする)、stop_only、stop_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

すべてのリソースクラスのスクリプトでは、動作方法および管理するサービスのインスタンスを指定するパラメータを指定できます。リソースエージェントがパラメータをサポートする場合、それらのパラメータを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.4項 「リソース監視」を参照してください。

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

注記: 値の優先度

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

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

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

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

重要: 制約および特定のタイプのリソースに関する制限

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソースに対して資格があるとみなされます。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_cpuとautoset_utilization_hv_memory。両方ともデフォルトはtrueです。これにより、監視サイクルのたびにCIBで使用値が更新されます。

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

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

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

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

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

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

location loc-db-prefer databases 100: alice

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

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

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

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

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

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

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

primitive vm1 ocf:heartbeat: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

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

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

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

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

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

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

Hawk2の最上位の行には、次のエントリが表示されます。

クラスタ管理者はクラスタ設定を知る必要がある場合があります。Hawk2は、現在の設定をcrmシェル構文で、XMLとして、およびグラフとして表示できます。クラスタ設定をcrmシェル構文で表示するには、左ナビゲーションバーから、環境設定 › Edit Configuration (設定の編集)を選択し、表示をクリックします。代わりに設定をraw XMLで表示するには、XMLをクリックします。CIBで設定されたノードとリソースのグラフィカルな表現を示すには、グラフをクリックします。リソース間の関係も表示されます。

Hawk2ウィザードは、仮想IPアドレスやSDB STONITHリソースなどの単純なリソースを設定する場合に便利です。また、DRBDブロックデバイスやApache Webサーバのリソース設定などの、複数リソースを含む複雑な設定においても役立ちます。設定手順をウィザードに従って進めることができ、入力が必要なパラメータについては情報が提供されます。

図 7.2: Hawk2 - Apache Webサーバ用のウィザード #

 

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

類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプレートを定義することです。リソーステンプレートを定義した後は、プリミティブの中や、特定のタイプの制約で参照できるようになります。リソーステンプレートの機能と使用方法の詳細については、6.5.3項 「リソーステンプレートと制約」を参照してください。

リソースの作成後、必要に応じてパラメータ、操作、またはメタ属性を調整することで、いつでもその設定を編集できます。

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

• クラスタにはノードフェンシングメカニズムが必要です。

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

デフォルトでは、グローバルクラスタオプションのstonith-enabledはtrueに設定されています。STONITHリソースが定義されていない場合、クラスタはどのリソースも開始することを拒否します。STONITHリソースが定義されていない場合、クラスタはどのリソースを開始することも拒否します。1つ以上のSTONITHリソースを設定して、STONITHのセットアップを完了します。SBD、libvirt (KVM/Xen)、またはvCenter/ESX ServerのSTONITHリソースを追加する場合、Hawk2ウィザードを使用するのが最も簡単な方法です(7.5.2項 「ウィザードを使用したリソースの追加」を参照してください)。STONITHは他のリソースと同様に設定しますが、その動作はいくつかの点で異なっています。詳細については、10.3項 「STONITHのリソースと環境設定」を参照してください。

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

クラスタリソースの中には、他のコンポーネントやリソースに依存しているものもあります。このような場合、各コンポーネントまたはリソースは特定の順番で起動し、同じサーバ上で動作する必要があります。この設定を簡単にするため、SUSE Linux Enterprise High Availability Extensionは、グループのコンセプトをサポートしています。

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

注記: 空のグループ

グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループの作成中に、Hawk2ではさらにプリミティブを作成し、それらをグループに追加できます。詳細については、7.7.1項 「リソースとグループの編集」を参照してください。

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

 

特定のリソースをクラスタ内の複数のノードで同時に実行することが必要な場合には、それらのリソースをクローンとして設定します。クローンとして設定できるリソースの一例は、OCFS2などのクラスタファイルシステムのocf:pacemaker:controldです。標準のリソースまたはリソースグループであれば、どれでもクローンを作成できます。クローンリソースの各インスタンスは、すべて同じ動作にすることができます。ただし、ホストされているノードに応じて設定を変えることもできます。

利用可能なリソースクローンのタイプの概要は、6.3.5.2項 「クローン」を参照してください。

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

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

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

 

マルチステートリソースは、クローンが得意とするところです。これにより、インスタンスを2つの動作モード(active/passive、primary/secondary、またはmaster/slaveと呼ばれます)のいずれかに設定できます。マルチステートリソースは、グループまたは通常リソースを1つだけ含む必要があります。

リソースの監視または制約を設定する場合、マルチステートリソースには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(http://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。特に、「Multi-state - Resources That Have Multiple Modes」のセクションを参照してください。

注記: マルチステートリソースの子リソース

マルチステートリソースには、プリミティブまたはグループのいずれかを子リソースとして含めることができます。Hawk2では、マルチステートリソースの作成中に子リソースを作成したり変更したりすることはできません。マルチステートリソースを追加する前に、子リソースを作成し、必要に応じて設定しておいてください。詳細については、7.5.3項 「単純なリソースの追加」または7.5.7項 「クラスタリソースグループの追加」を参照してください。

図 7.8: Hawk2 - マルチステートリソース #

 

タグは、コロケーションの作成や関係の順序付けを行わずに、複数のリソースをただちに参照する方法です。タグを使用して、概念的に関連するリソースをグループ化できます。たとえば、データベースに関連する複数のリソースがある場合、関連するすべてのリソースをdatabaseという名前のタグに追加できます。

同じタグに属するすべてのリソースは、1つのコマンドで開始または停止できます。

図 7.9: Hawk2 - タグ #

 

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

リソースモニタが障害を検出した場合の処理については、6.4項 「リソース監視」を参照してください。

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

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

 

場所制約は、リソースを実行できるノード、実行に適したノード、または実行できないノードを決定します。たとえば、場所制約により、特定のデータベースに関連するすべてのリソースを同じノードに配置します。

図 7.11: Hawk2 - 場所制約 #

 

コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。コロケーション制約はリソース間の依存関係を定義するため、コロケーション制約を作成するには、少なくとも2つのリソースが必要です。

図 7.12: Hawk2 - コロケーション制約 #