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

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

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

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

SUSE Linux Enterprise High Availability Extensionは、物理Linuxサーバと仮想Linuxサーバ両方のクラスタリングをサポートしています。両タイプのサーバの混合もサポートしています。SUSE Linux Enterprise Server 12 SP5には、XenおよびKVM (カーネルベースの仮想マシン)が付属しています。両方がオープンソース仮想ハイパーバイザーです。仮想ゲストシステム(VMとも呼ばれる)はクラスタによるサービスとして管理できます。

SUSE Linux Enterprise High Availability Extensionは、様々な地理的なシナリオをサポートするように拡張されています。Geo Clustering for SUSE Linux Enterprise High Availability Extensionという、High Availability Extensionの個別の拡張として、地理的に離れたクラスタ(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: アーキテクチャ #

SUSE Linux Enterprise High Availability Extensionでは、PacemakerをCRMとして使用します。CRMは各クラスタノード上にインスタンスを持つデーモン(crmd)として実装されます。Pacemakerは、マスタとして動作するcrmdインスタンスを１つ選択することにより、クラスタのすべての意思決定を一元化します。選択したcrmdプロセス(またはその下のノード)で障害が発生したら、新しいcrmdプロセスが確立されます。

クラスタの設定とクラスタ内のすべてのリソースの現在の状態を反映したCIBが、各ノードに保存されます。CIBのコンテンツはクラスタ全体で自動的に同期化されます。

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

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

CIBの情報に基づき、PEがクラスタの理想的な状態と実行方法を計算し、指示リストをDCに送ります。DCはメッセージング/インフラストラクチャ層を介してコマンドを送信し、他のノードのcrmdピアがこれらのコマンドを受信します。各crmdはLRM(lrmdとして実装)を使用してリソースを変更します。lrmdはクラスタに対応しておらず、リソースエージェント(スクリプト)と直接通信します。

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

場合によっては、共有データの保護や完全なリソース復旧のためにノードの電源を切らなければならないことがあります。このPacemakerにはフェンシングサブシステムとしてstonithdが内蔵されています。STONITHは「Shoot The Other Node In The Head」の略です。通常は、STONITH共有ブロックデバイス、リモート管理ボード、またはリモートパワースイッチを使用して実装されます。Pacemakerで、STONITHデバイスはリソースとしてモデル化されており(そしてCIBで設定されており)、簡単に使用することができます。ただし、stonithdがSTONITHトポロジの把握を担うため、そのクライアントはノードのフェンシングを要求し、残りをstonithdが行います。

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

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

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

csync2 -help

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

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

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

「詳細情報の参照先」の列に示すマニュアルはすべてhttps://documentation.suse.comで入手できます。

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

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

High Availability Extension 12クラスタスタックでは、さまざまなコンポーネントに大幅な変更が導入されています(たとえば、/etc/corosync/corosync.conf、OCFS2のディスクフォーマットなど)。したがって、SUSE Linux Enterprise High Availability Extension 11バージョンからのローリングアップグレードはサポートされません。代わりに、手順5.1「クラスタ全体のオフラインマイグレーション」で説明されているように、すべてのクラスタノードをオフラインにしてから、クラスタ全体を移行する必要があります。

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

リソースをグループ化するタグと一部のACLの機能は、pacemaker-2.0以上のCIB構文バージョンでのみ動作します(現在のバージョンを確認するには、cibadmin -Q |grep validate-withコマンドを使用します)。SUSE Linux Enterprise High Availability Extension 11 SPxからアップグレードした場合、デフォルトではCIBバージョンがアップグレード「されません」。最新のCIBバージョンに手動でアップグレードするには、以下のコマンドのいずれかを使用します:

root # cibadmin --upgrade --force

または

root # crm configure upgrade force

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

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

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

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

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

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

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

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

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

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

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

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

何らかの理由でフェンシングを無効にする必要がある場合は、stonith-enabledをfalseに設定しますが、これはご使用の製品のサポートステータスに影響を及ぼすことに注意してください。また、stonith-enabled="false"を指定すると、Distributed Lock Manager (DLM)のようなリソースやDLMによるすべてのサービス(cLVM、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ソフトウェアが、すべてのサービスの開始または停止アクションを実行します。

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

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

追加するクラスタリソースごとに、リソースエージェントが準拠する基準を定義する必要があります。リソースエージェントは、提供するサービスを抽象化して正確なステータスをクラスタに渡すので、クラスタは管理するリソースについてコミットする必要がありません。クラスタは、リソースエージェントに依存して、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.4.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 vip1 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サービスに関する詳細については(詳細な設定手順からなる複数の使用例を含む)、『Pacemaker Remote—Extending High Availability into Virtual Nodes』を参照してください(http://www.clusterlabs.org/doc/から入手可能)。

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

クラスタ管理者はクラスタ設定を知る必要がある場合があります。Hawk2は、現在の設定をcrmシェル構文で、XMLとして、およびグラフとして表示できます。クラスタ設定をcrmシェル構文で表示するには、左ナビゲーションバーから、Edit Configuration (設定の編集)を選択し、Show (表示)をクリックします。代わりに設定を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リソースが定義されていない場合、クラスタはどのリソースの開始も拒否します。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/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 - コロケーション制約 #

順序制約は、リソースを開始および停止する順序を定義します。順序制約はリソース間の依存関係を定義するため、順序制約を作成するには、少なくとも2つのリソースを作成する必要があります。

図 7.13: Hawk2 - 順序制約 #

制約を定義するための別のフォーマットとして、リソースセットを使用することができます。これらは、グループと同じ意味論に従います。

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

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

リソースがフェールオーバーする特定のノードを前もって指定するには、次の手順に従います。

マイグレーションしきい値と失敗カウントに関連したプロセスフローは、例6.8「マイグレーションしきい値 - プロセスフロー」に示されています。

リソースの失敗回数は、自動的に期限切れにする代わりに、いつでも、手動でクリーンアップすることもできます。詳細については、7.7.3項 「リソースのクリーンアップ」を参照してください。

ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元のノードにフェールバックすることがあります。このことを防ぐ、またはリソースのフェールバック先として別のノードを指定するには、リソースの固着性の値を変更します。リソースの固着性は、リソースを作成するとき、または作成した後のどちらでも指定できます。

さまざまなリソース固着性値の意味については、6.5.5項 「フェールバックノード」を参照してください。

すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースでは、そのホストであるノードがリソースの容量要件を満たす必要があります。配置したリソースの要件の合計が提供容量よりも大きくなった場合には、リソースのパフォーマンスが低下するか、または失敗します。

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

詳細と設定例については、6.5.6項 「負荷インパクトに基づくリソースの配置」を参照してください。

使用属性は、リソースの要件と、ノードが提供する容量の両方を設定するために使用されます。リソースが要求する容量を設定するには、その前にノードの容量を設定する必要があります。

ノードが提供する容量とリソースが要求する容量を設定してから、配置ストラテジをグローバルクラスタオプションに設定します。そうしないと、容量設定は有効になりません。負荷のスケジュールに使用できるストラテジがいくつかあります。たとえば、負荷をできるだけ少ない数のノードに集中したり、使用可能なすべてのノードに均等に分散できます。詳細については、6.5.6項 「負荷インパクトに基づくリソースの配置」を参照してください。

既存のリソースを編集する必要がある場合は、状態画面に移動します。操作列で、変更したいリソースまたはグループの横にある下矢印アイコンをクリックして編集を選択します。

編集画面が表示されます。プリミティブリソースを編集する場合は、次の操作が使用できます。

グループを編集する場合は、次の操作が使用できます。

クラスタリソースは、起動する前に、正しく設定されているようにします。たとえば、Apacheサーバをクラスタリソースとして使用する場合は、まず、Apacheサーバを設定します。クラスタでそれぞれのリソースを開始する前に、Apache設定を完了します。

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

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

ただし、サービスが適切に構成されているか確認したい場合は手動で開始しますが、High Availabilityが起動する前に停止してください。

現在クラスタで管理されているリソースへの介入については、まず、リソースをmaintenance modeに設定します。詳細については、手順16.5「リソースをHawk2を使用して保守モードにする」を参照してください。

Hawk2でリソースを作成するときには、target-roleメタ属性でその初期状態を設定することができます。その値をstoppedに設定した場合、リソースは、作成後、自動的に開始することはありません。

リソースは、失敗した場合は自動的に再起動しますが、失敗のたびにリソースの失敗回数が増加します。

リソースに対してmigration-thresholdが設定されていた場合、失敗回数が移行しきい値に達すると、そのリソースはそのノードでは実行されなくなります。

リソースの失敗回数は、(リソースにfailure-timeoutオプションを設定することにより)自動的にリセットするか、または次に示すように手動でリセットできます。

リソースをクラスタから削除する必要がある場合は、次の手順に従って、設定エラーが発生しないようにします。

7.6.6項 「リソースフェールオーバーノードの指定」で説明したように、ソフトウェアまたはハードウェアの障害時には、クラスタは定義可能な特定のパラメータ(たとえばマイグレーションしきい値やリソースの固着性など)に従って、リソースを自動的にフェールオーバー(マイグレート)させます。クラスタ内の別のノードにリソースを手動で移行させることもできます。または、リソースを現在のノードから出すかはユーザが判断し、どこに移動するかはクラスタに判断させます。

リソースを再び元に戻すには、次の手順に従います。

詳細については、http://www.clusterlabs.org/doc/から入手できる『Pacemaker Explained』を参照してください。特に、「Resource Migration」のセクションを参照してください。

単一クラスタを監視するには、状態画面を使用します。Hawk2にログインした後で、状態画面がデフォルトで表示されます。右上隅のアイコンに、クラスタの状態の概要が表示されます。詳細情報を参照する場合は、次のカテゴリを確認します。

図 7.15: Hawk2 - クラスタの状態 #

複数のクラスタを監視するには、Hawk2 Dashboard (ダッシュボード)を使用します。ダッシュボード画面に表示されるクラスタ情報は、サーバ側に保管されています。これらは、クラスタノード間で同期が取られています(クラスタノード間にパスワード不要のSSHアクセスが設定されている場合)。詳細については、D.2項 「パスワード不要のSSHアカウントの設定」を参照してください。ただし、Hawk2を実行するマシンは、その目的のためにクラスタの一部である必要はなく、別個の無関係のシステムで構いません。

Hawk2で複数のクラスタを監視するには、一般的なHawk2の要件に加え、次の前提条件も満たす必要があります。