Serviceguard 環境でのフェイルオーバー時間の最適化

Serviceguard 環境でのフェイルオーバー時間の 適化

目次

概要.........................................................................................................................................................2 HP Serviceguard のフェイルオーバー プロセス ...............................................................................................2

ノード障害のフェイルオーバー プロセス ......................................................................................................2 ノード障害の検出 ................................................................................................................................3 クラスタ メンバシップの選定 ..................................................................................................................3 ロックの取得 ......................................................................................................................................4 静止 .................................................................................................................................................4 クラスタ コンポーネントの復旧 ...............................................................................................................4 標準的な Serviceguard システム：リソースの復旧 ....................................................................................4 標準的な Serviceguard システム：アプリケーションの復旧 .........................................................................4 Serviceguard Extension for RAC：グループ メンバシップの再構成 ..............................................................5 Serviceguard Extension for RAC：RAC の再構成.....................................................................................5

パッケージの障害のフェイルオーバー プロセス............................................................................................5 標準的な Serviceguard システム：リソース障害の検出..............................................................................6 標準的な Serviceguard システム：パッケージの決定 ................................................................................6 標準的な Serviceguard システム：リソースの復旧 ....................................................................................6 標準的な Serviceguard システム：アプリケーションの起動 .........................................................................7 Serviceguard Extension for RAC：グループ メンバシップの再構成 ..............................................................7 Serviceguard Extension for RAC：RAC の再構成とデータベースの復旧.......................................................7

フェイルオーバー時間を 適化する方法 ........................................................................................................7 フェイルオーバーの時間を見積もるための参考情報 .....................................................................................8 ノードタイムアウト値 ................................................................................................................................8

テスト ................................................................................................................................................9 ロックの取得 (クラスタ ロック: タイブレーカまたはアービトレータとも呼ばれる).................................................10 ハートビート サブネットワーク .................................................................................................................10 ネットワーク障害の検出 .........................................................................................................................10 ノード数とパッケージ数 ..........................................................................................................................11 EMS リソース .......................................................................................................................................11 パッケージ制御スクリプト .......................................................................................................................11 アプリケーション ...................................................................................................................................12

Serviceguard Extension for Faster Failover ..................................................................................................12 SGeFF の要件 .....................................................................................................................................13 SGeFF に適切な環境 ............................................................................................................................13 クラスタ パラメータに関する検討事項.......................................................................................................14

まとめ.....................................................................................................................................................15 詳細情報 ................................................................................................................................................15

1

概要

高可用性/ミッションクリティカル環境の有効性を示す も重要な指標の 1 つに、障害発生時に、エンド ユーザーがどの

程度の遅延を感じるか、ということがあります。これらの高可用性/ミッションクリティカル環境では、障害の検出、作業の

再開方法の判断、データの整合性の保証、およびアプリケーションの再起動とエンド ユーザーから使用可能にすること

など、いくつか処理を行う必要があります。

ビジネス ニーズが異なれば、必要な環境も異なります。予定外のダウンタイムに対する許容範囲、ハードウェア構成、

専門的なソフトウェア、およびシステム管理とデータ管理に関して、各環境は大きく異なります。高可用性環境を構築す

るためには、これらの要因を注意深く検討する必要があります。運用環境またはそれに近い環境で完全なテストを行い、

構成したクラスタが要件を満たすことを確認する必要があります。テストおよび詳細な調整を行うことで、フェイルオーバ

ー時間を 適化し、エンド ユーザーに対するアプリケーションの可用性を向上させることができます。

本書では、まず HP Serviceguard のフェイルオーバー プロセスについて説明します。次に、クラスタのフェイルオーバー

時間を 適化する方法を説明します。さらに、フェイルオーバー プロセスのうちの Serviceguard 部分を短縮するため、

別途購入可能な Serviceguard アドオン製品 Serviceguard Extension for Faster Failover について説明します。

HP Serviceguard のフェイルオーバー プロセス

ノード障害のフェイルオーバー プロセス

Serviceguard の各ノードは互いに監視を行い、すべてのノードが通信可能かつ協調動作可能なことを確認します。

Serviceguard クラスタ内の各ノードは、ネットワークを通してハートビート メッセージを送信し、他のノードからのハートビ

ート メッセージを受信します。ハートビート メッセージは、クラスタ設定ファイル内に HEARTBEAT_INTERVAL で定義され

た一定の間隔で送信されます。

ノードは、別のノードからのハートビートを受け取れない場合、クラスタの再編成プロセスを開始し、通信できないノードを

クラスタのメンバシップから削除します。図 1 に、ノード障害によって発生するフェイルオーバーのプロセスを示します。

図 1. 標準的な Serviceguard システムで、ノード障害によって発生するフェイルオーバーのプロセス

選定 ロックの取得 静止 ノード障害の検出

クラスタの再編成

クラスタ コンポーネントの復旧

リソースの復旧 (VG、FS、IP)

アプリケーションの復旧

フェイルオーバー時間のうちの Serviceguard 部分 アプリケーションに依存する

フェイルオーバー時間

注：図の各部分の大きさの割合は、実際にかかる時間の比率を反映しているわけではありません。

(パッケージ障害ではなく) ノード障害で発生したフェイルオーバーの合計時間のうち、Serviceguard 部分は、ノード障害

の検出、選定、ロックの取得、静止、およびクラスタ コンポーネントの復旧で構成されています。

�� ノード障害の検出—システムが、他のクラスタ ノードと通信できないクラスタ ノードを検出します。Serviceguard は、

クラスタの再編成を開始します。

�� 選定—クラスタノードは、再編成するクラスタに参加するノードを決定します。

�� ロックの取得—2 つ以上のノード グループがクラスタの再編成を行おうとしている場合で、どのグループも明確にメ

ンバの過半数を所有していない場合には、クラスタ ロックを 初に取得したグループがクラスタの再編成を行いま

す。

�� 静止—この静止待機時間の間に、新しく編成するクラスタに入っていないメンバが排除されます。

�� クラスタ コンポーネントの復旧—クラスタが業務を再開する前に、Serviceguard は、クラスタ情報の同期化やパッ

ケージの決定など、各種のタスクを実行します。

2

フェイルオーバー時間のうちアプリケーションに関連する段階では、Serviceguard が、ユーザーによって記述されたパッ

ケージ制御スクリプトを開始します。図 1 に示すように、標準的な Serviceguard システムでは、この段階は次の 2 つのステップで構成されます。

�� リソースの復旧—パッケージのリソースを使用可能にします。

�� アプリケーションの復旧—アプリケーションやプロセスを新しいノードに移動した場合、再起動します。

図 2 に示すように、アプリケーションに依存するステップは、Serviceguard Extension for RAC のクラスタ内の Oracle® RAC (Real Application Clusters) パッケージに対するものは多少異なります。

図 2. Serviceguard Extension for RAC システムで、ノード障害のフェイルオーバーの手順

選定 ロックの取得 静止 ノード障害の検出

クラスタの再編成

クラスタ コンポーネントの復旧

グループ メンバシップの 再構成

RAC の再構成と データベースの復旧

フェイルオーバー時間のうちの Serviceguard 部分

アプリケーションに依存する フェイルオーバー時間

注：図の各部分の大きさの割合は、実際にかかる時間の比率を反映しているわけではありません。

RAC システムの アプリケーション依存ステップは、次の 2 つの各ステップで構成されます。

�� グループ メンバシップの再構成—メンバ構成に変更があると、RAC は再構成を開始します。

�� RAC の再構成とデータベースの復旧—クラスタのメンバシップが変化すると、RAC は、障害ノードのものであった

データベース ロックの再割り当てを行い、データベースを再起動します。

ノード障害の検出

ノードは、別ノードからハートビート メッセージを受け取れなくなると、そのノードを通信不能として宣言します。ノードは、

様々な理由で通信不能となる可能性があります。ネットワーク アクティビティ、I/O や CPU の瞬間的な過負荷、カーネ

ルの一時的な停止など、短時間で自動的に回復する一時的な中断の場合もあります。また、ハードウェアや電源障害、

オペレーティング システムのクラッシュなど、自動的または迅速に復旧できない障害もあります。

クラスタ構成ファイル内の NODE_TIMEOUT で指定された時間内にハートビートがないと、ノードに障害が発生したと判

断されます。Serviceguard は、NODE_TIMEOUT 値に達すると、障害ノードを除いてクラスタの再編成を開始します。

クラスタ メンバシップの選定

ノードは、別ノードの障害を検出すると、クラスタ再編成プロセスを開始します。クラスタ ノードは、新しく再編成するクラ

スタのメンバとなるノードを選定します。

正常な各ノードは、クラスタの業務の引き継ぎを試行します。通信可能なノードを参加させ、通信不能なノードを排除す

るように、クラスタ メンバシップを変更します。

1 つのノードに障害が発生した場合で、他のすべてのノードは互いに引き続き通信可能な場合には、障害ノードを除くノ

ード群で迅速にグループを編成します。しかし、正常ノードのグループが、他の正常ノードと通信できない場合もあります。

この場合、複数のグループがクラスタの編成を試行する可能性があります。

クォーラムを満たすグループが、新しいクラスタとなります。グループがクォーラムを達成するのは、次の 2 つの場合で

す。

�� 前回クラスタの編成時にアクティブであったノードの半数を超えるノードが含まれるグループが存在する場合、その

グループが過半数を保持するためクォーラムを達成します。

�� 前回クラスタの編成時にアクティブであったノードのちょうど半数を持つグループが 2 つ存在する場合、クラスタ ロックを取得したグループがクォーラムを達成します。(クラスタ ロックの詳細は、「ロックの取得」を参照してください。)

3

クォーラムを達成したグループが、そのクラスタの業務を引き継ぎます。除外されたノードはクラスタの再編成に進むこと

なく、再起動されます。

選定に要する時間は、基本的には NODE_TIMEOUT と HEARTBEAT_INTERVAL の値によって決まります。一時的な中

断と復旧が複数回発生すると、ノード間の通信の喪失と再開が繰り返し行われる可能性があります。この場合、選定を

繰り返すため、このプロセスに要する時間が長くなります。

ロックの取得

大きさの同じ 2 つのグループがクラスタの再編成を行う場合、クラスタ ロックがアービトレータ (調停機能) またはタイブ

レーカの役割を果たします。

クラスタ ロックを取得したグループがクォーラムを満たし、新しいクラスタ メンバシップを編成します。

Serviceguard は、次の 3 種類のクラスタ ロックを使用します。

�� クォーラム サーバ (HP-UX および Linux®)

�� ロック ディスク (HP-UX のみ)

�� ロック ディスク LUN (Linux のみ)

2 ノードのクラスタにはクラスタ ロックが必要です。3 ノード以上のクラスタでは、ロックを 1 つ持つことを強くお勧めしま

す。ロック ディスクは、2、3 または 4 ノードのクラスタで使用できます。クォーラム サーバは、任意の規模のクラスタで

使用できます。

ロック ディスクと比較すると、クォーラム サーバまたはロック ディスク LUN の取得は一般に短時間で済みます。

静止

静止は、新しいクラスタ メンバシップを決定した後の静止待機時間を意味しています。新しいメンバシップ外のノードは、

強制的に再起動されます。待機時間は、データの破壊を防ぐためのものです。これにより、再起動が終了するまで、除

外されたノードによってパッケージや I/O が実行されないように保証できます。

クラスタ内のいくつかのノードが互いに通信できない状態で引き続きアプリケーションの実行が可能な場合、特に各ノー

ドが共通データベースにアクセスする場合には、静止が重要な意味を持ちます。

静止時間は Serviceguard によって計算され、ユーザーが直接変更することはできません。

クラスタ コンポーネントの復旧

Serviceguard は、この短いステップ (一般に 1 秒未満) で、クラスタ情報の同期やパッケージの決定など各種のタスク

を実行します。パッケージが障害で停止した場合、Serviceguard は、パッケージを再開すべきかどうか、またどのノード (またはノード群) で開始すべきかを判断します。(6 ページの「標準的な Serviceguard システム：パッケージの決定」を

参照してください。)

クラスタ コンポーネントの復旧に必要な時間は、主に再起動が必要なパッケージの数によって決まります。この復旧段

階の終わりに、Serviceguard は、exec プロセスを使用してパッケージの制御スクリプトを 1 つずつ開始することにより

パッケージを起動します。

ユーザーは、クラスタ コンポーネントの復旧に必要な時間を直接変更することはできません。

標準的な Serviceguard システム：リソースの復旧

Serviceguard がパッケージの制御スクリプトを開始するときに、フェイルオーバーのうちのアプリケーション依存部分が

開始されます。パッケージ リソースが使用可能となり、パッケージのアプリケーションを開始する準備が整います。パッ

ケージ リソースには、パッケージに必要な IP アドレス、ファイル システム、ボリューム グループ、およびディスク グルー

プが含まれます。いくつかのリソースでは、使用する前に他の復旧ステップの実行が必要なものがあります。

リソースの復旧を完了するのに必要な時間は、主にパッケージ制御スクリプトによって定まり、パッケージのアプリケー

ション、サービス、およびリソースに影響されます。

標準的な Serviceguard システム：アプリケーションの復旧

制御スクリプトのコマンドは、フェイルオーバーのアプリケーション依存部分を完了し、パッケージ アプリケーションの復

旧と再起動を行います。必要な時間は、アプリケーションとその構成方法によって異なります。

4

Serviceguard Extension for RAC：グループ メンバシップの再構成

Serviceguard Extension for RAC が Oracle RAC にグループ メンバシップを伝えると、RAC フェイルオーバーのアプリ

ケーション依存部分が開始します。メンバシップに変更がある場合、RAC は再構成を開始します。RAC は、再編成した

クラスタにどのノードが参加しているか知る必要があります。データベース ロックを持つノードがクラスタを離脱する場合、

別のノードがロックを要求する必要があります。

グループ メンバシップの再構成に必要な時間は RAC によって決定され、ユーザーが直接変更することはできません。

Serviceguard Extension for RAC：RAC の再構成

Oracle RAC は、クラスタ メンバシップの変更を通知されると、独自の再構成を起動して障害ノードが持っていたデータ

ベース ロックを要求します。RAC の再構成と復旧は、クラスタ内の他のノード上で動作する RAC インスタンスで実行さ

れます。

このステップに必要な時間は RAC によって決定され、ユーザーが直接変更することはできません。

パッケージの障害のフェイルオーバー プロセス

次に、(ノード障害ではなく) パッケージ障害によって発生するフェイルオーバーの各ステップを示します。

図 3. 標準的な Serviceguard システムで、パッケージ障害のフェイルオーバーのプロセス

リソース障害の検出

パッケージの判断 リソースの復旧(VG、FS、IP)

アプリケーションの復旧

フェイルオーバー時間のうちのServiceguard 部分

アプリケーションに依存する フェイルオーバー時間

注：図の各部分の大きさの割合は、実際にかかる時間の比率を反映しているわけではありません。

フェイルオーバーのうち Serviceguard 部分は次のステップで構成されます。

�� リソース障害の検出—Serviceguard は、監視中のサービスまたはリソースが停止したことを検出します。

�� パッケージの判断—Serviceguard は、パッケージを再起動すべきか、またどこで再起動するかを判断します。

標準的な Serviceguard システムでは、アプリケーション依存部分は次の各ステップで構成されます。

�� リソースの復旧 Serviceguard は、パッケージ制御スクリプトを使用して、パッケージに対してリソースを使用可能

にします。

�� アプリケーションの復旧—ここでは、新しいノードに移動したアプリケーションやプロセスを再起動します。

5

Serviceguard Extension for RAC では、RAC パッケージに障害が発生しても、Serviceguard からフェイルオーバー処

理が実行されることはありません。データベース インスタンスのクラッシュなどの障害が発生した場合、Serviceguard クラスタは再編成を行うことなく運用を継続します。したがって、Serviceguard 部分のフェイルオーバーは発生しません。

Oracle RAC が、新しいメンバシップを再編成し、データベース復旧を実行します。

図 4. Serviceguard Extension for RAC システムで、パッケージ障害によって発生するフェイルオーバーのプロセス

グループ メンバシップの 再構成

RAC の再構成と データベースの復旧

アプリケーションに依存する フェイルオーバー時間

注：図の各部分の大きさの割合は、実際にかかる時間の比率を反映しているわけではありません。

RAC では、フェイルオーバーのうちアプリケーションに依存する次の 2 つのステップが、標準的な Serviceguard システ

ムの手順とは異なります。

�� グループ メンバシップの再構成—メンバシップに変更があると、RAC は再構成を開始します。

�� RAC の再構成とデータベースの復旧—クラスタのメンバシップが変化すると、RAC は、障害ノードのものであった

データベース ロックの再割り当てを行い、データベースを再起動します。

標準的な Serviceguard システム：リソース障害の検出

Serviceguard は、構成されたパッケージ サービスとネットワークを監視します。

Serviceguard パッケージ構成には、ストレージなどのハードウェアを監視する EMS (Event Monitoring Service) を入れ

ることができます。EMS は、EMS リソース モニタにポーリングを行い、応答を受け取ります。ポーリング間隔は、パッケ

ージ構成ファイルに設定されています。EMS は、リソース障害を検出すると、即座に Serviceguard に通知します。

一 般 に 、 リ ソ ー ス に 障 害 が 発 生 す る と 、 パ ッ ケ ー ジ は 別 の ノ ー ド に フ ェ イ ル オ ー バ ー し ま す 。

NODE_FAIL_FAST_ENABLED に YES を設定してパッケージを構成した場合には、Serviceguard は、ノードを強制停止

して再起動させます。この状態が発生すると、プロセスは、前節で説明した 初のステップ、「ノード障害のフェイルオー

バープロセス」から開始します。

標準的な Serviceguard システム：パッケージの決定

パッケージ構成ファイルで AUTO_RUN に YES が設定されている場合、パッケージに障害が発生すると、Serviceguard はパッケージの再起動を試みます。また、次にどこでパッケージを起動するか決定します。ノードの順序リストを作成しま

す。このリストでは、ノード リスト、およびパッケージの設定ファイル内のフェイルオーバーおよびフェイルバック ポリシー

の設定に従って優先順位が付けられています。

ユーザーは、パッケージの決定に必要な時間を直接変更することはできません。

標準的な Serviceguard システム：リソースの復旧

Serviceguard が各パッケージの制御スクリプトを開始すると、フェイルオーバーのアプリケーション依存の部分が開始さ

れます。フェイルオーバーでは、アプリケーションを起動する前に、パッケージ リソースを使用可能にする必要がありま

す。パッケージ リソースには、IP アドレス、ファイル システム、ボリューム グループ、およびディスク グループが含まれ

ます。いくつかのリソースでは、使用開始の前に復旧が必要なものがあります。この指示は、各パックの制御スクリプト

に記述されています。

リソースの復旧に必要な時間は、リソースの数と、制御スクリプト内の指示によって異なります。

6

標準的な Serviceguard システム：アプリケーションの起動

制御スクリプトは、パッケージ アプリケーションの復旧と再起動のためのコマンドに従って、フェイルオーバーのアプリケ

ーション依存部分を完了します。また、パッケージとアプリケーションによっては、開始する前に独自の復旧を行うものが

あります。

アプリケーションの起動に必要な時間は、各アプリケーションとその構成方法によって異なります。

Serviceguard Extension for RAC：グループ メンバシップの再構成

RAC グループ メンバシップの再構成は、フェイルオーバーがノード障害による場合でも、パッケージ障害による場合で

も同じになります。Serviceguard Extension for RAC は、グループ メンバシップ再構成を開始するために、Oracle RAC にグループ メンバシップを伝達します。メンバシップに変更がある場合、RAC は再構成を行います。

グループ メンバシップの再構成に必要な時間は、RAC 構成によって異なります。

Serviceguard Extension for RAC：RAC の再構成とデータベースの復旧

Oracle RAC は、クラスタ メンバシップの変更を通知されると、独自の再構成と復旧を開始します。

RAC の再構成とデータベースの復旧に必要な時間は、RAC 構成によって異なります。

フェイルオーバー時間を 適化する方法

ユーザーの環境に合わせてフェイルオーバー プロセスを 適化し、パッケージのダウンタイムを短縮するには、いくつ

か方法があります。フェイルオーバー プロセスが必要以上に長くかかる場合、可用性を 大限に活用していないことに

なります。しかし、フェイルオーバーの開始、完了が早すぎる場合には、クラスタのパフォーマンスを低下させる不必要な

フェイルオーバーが発生して、逆に可用性を低下させている可能性があります。両極端のバランスを取ることが重要で

す。

適なフェイルオーバー時間は、回復可能な中断を許容できるだけ十分長い時間であり、それ以上長くない時間となり

ます。

フェイルオーバーの Serviceguard 部分に必要な時間は、主にノードタイムアウト値に依存しますが、ハートビート間隔、

クラスタ内のノード数、および使用するクラスタ ロックによっても異なります。これらの要因を詳細に調整して、フェイルオ

ーバーを 適化するには、いくつか方法があります。

Serviceguard パラメータを設定するには、一時的な中断の確率と、一時的な中断から回復し、処理を継続するまでの時

間を判断する必要があります。クラスタのリソースが使用率の高い環境にある場合には、ハートビートの一時的な遅延

が発生する可能性があります。その場合、不要なフェイルオーバーが発生し、しかも繰り返し発生する可能性がありま

す。しかし、ネットワークとシステムに過重な負荷がかかっていない場合には、不要なフェイルオーバーの発生確率が低

いため、フェイルオーバー パラメータをより短く設定できます。

中断を減らし、中断から回復する時間を短縮するように環境を調整してください。クラスタ全体にワークロードを分散する

方法を検討してください。また、クラスタへのノードの追加を検討してください。 長の回復時間を許容するようにノードタ

イムアウト値を設定する必要があるため、一時的な中断の時間を短くすることができれば、ノードタイムアウト値を小さく

することができます。

フェイルオーバーのうちアプリケーションに依存する部分にかかる時間を検討してください。アプリケーションの復旧と再

起動の時間が短くてすむ場合には、フェイルオーバー パラメータをより短く設定する余地があります。アプリケーション

の復旧と再起動を迅速に行うことができれば、障害に対して迅速な対応を行ううえで有利になります。しかし、アプリケー

ションの再起動やデータベースの復旧に長い時間がかかる場合には、ノードタイムアウト値をより長く設定することも考

えられます。長い時間のかかるフェイルオーバーを開始する前に、一時的な問題が自然に回復するのを待つ方が有利

な場合があるからです。

7

フェイルオーバーの時間を見積もるための参考情報

次の表に、Serviceguard クラスタの合計フェイルオーバー時間を見積もるための参考情報を示します。

フェイルオーバーの構成要素名 見積り時間

リソース障害の検出

ネットワーク障害の検出 NETWORK_POLLING_INTERVAL の 6 倍

EMS リソース障害の検出 RESOURCE_POLLING_INTERVAL

サービス障害の検出 即時

ノード障害の検出 NODE_TIMEOUT

クラスタ メンバシップの再編成時間 (ノード障害のフェイルオーバー時間のうち、Serviceguard 部分)

主に NODE_TIMEOUT に依存します。また、ハートビート ネットワークの数、クラスタ ロックのタイプ、および HEARTBEAT_INTERVAL にも影響されます。

NODE_TIMEOUT を 2 秒に設定し、2 つ以上のハートビート サブネットワークが存在し、QS_TIMEOUT_EXTENSION に 0 を設定してクォーラム サーバを構成した場合には、再編成時間は 28 秒になります。

HP-UX では、cmquerycl コマンドで時間をチェックしてください。クラスタを構成した後、cmquerycl –c <cluster_name> コマンドを発行して出力を確認します。クラスタ ロックの隣の値が、クラスタ メンバシップの再編成時間です。

クラスタ コンポーネントの復旧 EMS リソース、パッケージ、ノードなどの数に依存します。この時間は、一般に、合計フェイルオーバー時間と比較して非常に短時間です。

リソースの復旧 ボリューム グループ、IP アドレス、サービスなどの数に依存します。一般に、短い場合で 1 秒から長い場合で数分までの範囲に渡ります。

アプリケーションの起動と復旧の時間 完全にアプリケーションに依存します。

ノードタイムアウト値

フェイルオーバー時間を 適化する場合、まずクラスタ構成環境で NODE_TIMEOUT の設定を詳細に検討、調整してく

ださい。この設定を変更すると、クラスタ フェイルオーバー時間に非常に大きな違いが発生します。ノードがタイムアウト

すると、Serviceguard は、そのノードを障害として認識し、クラスタ再編成プロセスを開始します。

Serviceguard では、サポートされている NODE_TIMEOUT の値の範囲は 2 秒から 30 秒です。大部分のクラスタでは、

推奨値は 5 秒から 8 秒です。

ノード タイムアウトを短縮すると、ノード障害を検出するまでの時間が短縮し、合計フェイルオーバー時間も短縮します。

しかし、ノード タイムアウト値を小さくすると、リスクも大きくなります。一時的な中断が発生した場合に、ノードのタイムア

ウト値が、通信の回復時間より短い場合、ノードが不必要に障害と判断される可能性があり、またクラスタで不必要な再

編成が実行される可能性があります。

パラメータに過度に小さい値を設定すると、不要な (回避すべき) フェイルオーバーが発生する可能性があります。通信

不能なノードが一時的な中断から回復するより前に再編成が完了するほど小さい値をパラメータに設定すると、そのノ

ードは強制的に再起動されます。そのノードで動作している全てのパッケージは、別のノードにフェイルオーバーされま

す。

再編成が完了する前に通信不能なノードが通信を回復できる場合には、そのノードはクラスタに再統合されます。再編

成が実行されたのにメンバシップが何も変化しない場合には、ノードタイムアウト値がすでに限界に近づいています。全

体的なフェイルオーバー時間をこれ以上短くしないでください。また、syslog に “Warning: cmcld process was unable to run for the last <xxx> seconds.” というメッセージが表示された場合にも、限界に近い値であることを意味しています。

アプリケーションの復旧と再起動に長い時間がかかる場合には、ノード タイムアウト値を長めに設定してください。デー

タベースの復旧に数分かかる場合には、Serviceguard フェイルオーバー時間を数秒短くして、不要なフェイルオーバー

を行うリスクを取る価値はありません。

8

迅速に再起動するアプリケーションの場合には、ノードタイムアウト値をより短く設定できます。アプリケーションの再起

動に数秒しか要しない場合には、中断から回復するまで数秒待機することに大きな利点はありません。復旧時間および

再起動時間が短い場合には、ノードタイムアウト値の短縮を試してみる価値があります。

負荷の軽い小さいシステムは、中断が少なく、より迅速に回復できる傾向があります。また、多数のディスクを持つ負荷

の重いシステムは、より頻繁に中断し、回復により長時間を要する傾向があります。このようなシステムでは、負荷を分

散し、アクティビティの瞬間的な過負荷を回避してください。負荷が も重い場合には、中断の回復時間を許容するよう

にノード タイムアウト値を設定します。

仮想パーティションは、ハードウェアとソフトウェアの共有のため、独立ノードとは異なる遅延特性を持つ可能性がありま

す。クラスタ内で仮想パーティションを使用する場合には、構成に関するノードタイムアウト値をテストするときに、さらに

別 の 検 討 項 目 が 発 生 す る 可 能 性 が あ り ま す 。 詳 細 は、 www.docs.hp.com/hpux/ha で ホ ワ イ ト ペ ー パ ー

『ServiceGuard Cluster Configuration for Partitioned Systems』を参照してください。

テスト

パラメータを詳細に調整するには、実際の運用環境を反映する環境でクラスタをテストすることが重要です。すべてのパ

ッケージを実行して、ネットワーク、CPU、および I/O に対して予想される も重い負荷をかけてクラスタをテストしてくだ

さい。

フェイルオーバー時間を計測するためには、各パッケージを強制的に別のノードにフェイルオーバーします。強制的にフ

ェイルオーバーする 1 つの方法として、パッケージが動作しているノードの電源を切断する方法があります。フェイルオ

ーバーのログを参照し、タイム スタンプに注目してください。

パラメータを少しずつ変更し、再評価と再テストを行います。そして、システム ログをチェックします。中断や一時的な問

題を意味する項目が存在する場合には、その復旧時間を検証してください。クラスタ メンバシップの変更を伴わない再

編成が見られる場合は、ノードタイムアウト値の下限に到達したことを意味しています。

適なノードタイムアウト値が見つかるまで、いろいろな設定を試してください。回復可能な一時的な問題による不要な

再編成やフェイルオーバーが発生することのない、 短のフェイルオーバー時間をもたらす値を追及します。

テスト済みのノードタイムアウト値に、安全性のため多少の猶予時間を考慮します。どの程度の時間を許容するかは、

も負荷の高い時間における実際の使用環境を、テスト環境でどの程度緊密に反映しているかによって異なります。

特に、クラスタに新しいディスク、ネットワーク、またはアプリケーションを追加する場合には、設定を定期的に再テストお

よび再評価してください。ハートビート ネットワークのトラフィックを監視して、トラフィックの増加、特に一時的に瞬間的な

過負荷をもたらすトラフィックに注意してください。

9

ロックの取得 (クラスタ ロック: タイブレーカまたはアービトレータとも呼ばれる)

ロック ディスクの選択肢を検討することで、フェイルオーバー時間を 適化することができます。ノードタイムアウト値を 6 秒以下に設定すると、クォーラム サーバ、LUN、または LVM (Logical Volume Manager) SCSI ロック ディスクで、ロ

ック取得にかかる時間を短縮できます。しかし、ノードタイムアウト値が 6 秒より大きい場合、ロックのタイプは合計フェ

イルオーバー時間にほとんど影響を与えません。

ロック ディスクが異なれば、ロック取得時間も異なります。ロック ディスクを使用する場合、または使用を計画している場

合には、その解説書で取得にかかる時間を確認してください。

�� LVM SCSI ロック ディスクの取得には約 10 秒かかります。

�� ファイバ チャネル LVM ロック ディスクの取得には約 32 秒かかります。

�� ロック LUN SCSI またはクォーラム サーバを取得する時間は NODE_TIMEOUT の値によって増加しますが、直接

比例するわけではありません。たとえば、ノードタイムアウト値が 2 秒の場合、取得には約 8 秒かかります。ノード

タイムアウト値が 4 秒の場合、約 14 秒かかります。

クォーラム サーバを選択した場合には、そのサーバとノード間のネットワークが高度な可用性と信頼性を持っていること

を確認してください。クォーラム サーバへの到達に遅延が発生する場合には、QS_TIMEOUT_EXTENSION を設定でき

ますが、この拡張時間はロック取得時間に直接追加されます。

Serviceguard は、実際のロック取得時間を計算します。この時間は直接変更できませんが、より高速なロック デバイス

を設定してロック取得時間を短縮できます。

ハートビート サブネットワーク

スタンバイ LAN をもつハートビート 1 本のみを使用し、NODE_TIMEOUT 値を 4 秒未満に設定する場合には、代わり

に複数のハートビートを設定することでフェイルオーバー時間を短縮できます。ハートビート メッセージはすべてのハー

トビート サブネットワークに同時に送信されるため、プライマリ LAN に障害が発生した場合に、複数のハートビートを持

つ場合には、ネットワークの切り替えのための待ち時間が発生しません。負荷の高いネットワークによる遅延を回避する

ため、ハートビート用に専用のプライベート ネットワークを少なくとも 1 つ設定してください。

VERITAS CVM (Cluster Volume Manager) を使用する構成など、特定の構成では複数のハートビートを使用できないこ

とに注意してください。

ネットワーク障害の検出

NETWORK_POLLING_INTERVAL では、Serviceguard がその構成ネットワークをチェックする頻度を指定します。一般

には、デフォルト値が も有効です。

頻繁にポーリングを行うことにより、Serviceguard は、LAN の障害により迅速に対応できます。これにより、フェイルオ

ーバーをより早く開始できることから、パッケージのフェイルオーバー時間が短縮します。ただし、ポーリング間隔が短す

ぎると、トラフィックが頻繁に発生することにより、ネットワークとシステムに負荷がかかることになります。

10

ノード数とパッケージ数

Serviceguard の Package Manager は、パッケージ制御スクリプトを実行します。これに要する時間は、少数のノード上

で多数のパッケージを設定している場合にだけ重要になります。たとえば、一般的なシステムでは、50 パッケージを 1

つのノードにフェイルオーバーすると、スクリプトの開始に数秒を要します。

他に 2 か所で多少の影響が現れます。

�� 再編成の間、8 ノードを超えるクラスタでは、クラスタ情報の同期に余分な時間を要することがあります。

�� リソース復旧の間、Package Manager は 2 つのタスクを行います。まず、障害が発生したパッケージを判断しま

す。パッケージ数が多い場合には、必要な時間も長くなります。次に、パッケージを引き継ぐノードを判断し、再編成

の後で実行する必要があります。各ノードにパッケージ数が多い場合には、必要な時間も長くなります。

EMS リソース

EMS リソースに関して、検討すべき要因は 2 つあります。

�� EMS リソース モニタ検出時間—EMS リソース モニタとその動作方法に完全に依存します。モニタの解説書を参照

してください。一般に、この時間は設定できます。

�� EMS メッセージが Serviceguard に届くのに要する時間— 大で、RESOURCE_POLLING_INTERVAL に設定した

時間を要します。パッケージ構成ファイルで、時間間隔を十分に短く設定することにより、障害を迅速に発見できま

す。しかし、短く設定しすぎると、頻繁なポーリングによってネットワークとシステムにより大きな負荷がかかることに

なります。

パッケージ制御スクリプト

多数のストレージ ユニットが含まれる場合には、リソースの復旧時間を短縮して、フェイルオーバーの 適化をはかれ

ます。ご使用の Serviceguard バージョンのマニュアル『Serviceguard の管理』の「多数の記憶装置の 適化」の項を参

照してください。マニュアルは、www.docs.hp.com/ja/hpuxha.html –> [Serviceguard] から入手できます。

ファイル システムの種類によっては、ファイルの整合性チェックに要する時間を大幅に短縮できます。HP-UX 上のパッケ

ージについては、VxFS の方が HFS よりも高速です。Linux では、ジャーナルファイル システム (Reiser FS や ext3 FS など) は、非ジャーナルファイル システム (ext2) よりも高速です。

IP アドレスの追加と削除にはある程度の時間を要し、フェイルオーバーの時間に影響を与えます。HP-UX では、DAD (duplicate address detection: 重複アドレスの検出) を有効にすると、IPv6 アドレスの追加に少なくとも 1 秒長くかかり

ます。詳細は、ご使用の Serviceguard バージョンのマニュアル『Serviceguard の管理』の「IPv6 再配置可能アドレスと

重複アドレス検出機能」の項を参照してください。このマニュアルは、www.docs.hp.com/ja/hpuxha.html –> [Serviceguard] から入手できます。

制御スクリプトを、可能な限り効率的にしてください。サービスの開始と停止に必要な時間が、フェイルオーバー時間の

合計に加算されます。カスタマ定義の機能を簡素化して、時間を短縮してください。

11

アプリケーション

多数の異なるアプリケーションを、1 つのソリューションで効率化することは困難です。しかし、一般的なヒントは存在しま

す。

フェイルオーバー アプリケーションは、データの復旧に長い時間を消費します。この時間を短縮できないか確認してくだ

さい。具体的な調整のヒントについては、各アプリケーション ベンダーやシステム インテグレータに連絡してください。

データベース管理システムを使用する場合には、Oracle RAC の実装を検討してください。RAC は、RAC インスタンス

の障害後のリソース復旧時間を短縮するので、アプリケーション復旧時間の短縮にも繋がります。Serviceguard 環境で Oracle RAC を使用するには、Serviceguard Extension for RAC を購入してください。

Serviceguard Extension for Faster Failover

SGeFF (Serviceguard Extension for Faster Failover) では、Serviceguard フェイルオーバー時間のより一層の 適化

が可能です。この製品は HP-UX 上の Serviceguard に対するアドオン製品であり、フェイルオーバーの高速化が必要で

あり、そのために特定種類のクラスタを構成することが可能なユーザー用に作成されています。

フェイルオーバーのうちの Serviceguard 部分は、Serviceguard Extension for Faster Failover を導入すると図 5 に示

すように変化します。

図 5：Serviceguard Extension for Faster Failover でのフェイルオーバーのプロセス

ロックの取得 静止 ノード障害の検出

クラスタの再編成

クラスタ コンポーネントの復旧

フェイルオーバー時間のうちの Serviceguard 部分

注：図の各部分の大きさの割合は、実際にかかる時間の比率を反映しているわけではありません。

SGeFF は、フェイルオーバー時間のうちの Serviceguard 部分を次の方法で短縮します。

�� 通常の Serviceguard で必要であるメンバシップ選定時間を必要としません。

�� クラスタ ロックの取得に要する時間を短縮します。

�� 通常の Serviceguard で必要であるハートビートのローカル切り替えにかかる時間を必要としません (10 ページの

「ハートビート サブネットワーク」を参照)。

SGeFF は、データベースやアプリケーションなど、アプリケーションに依存するフェイルオーバー時間は変更できません。

12

SGeFF の要件

すべての SGeFF クラスタは、これらの構成に関する要件を満たす必要があります。

�� Serviceguard A.11.16 と SGeFF を、クラスタ内のすべてのノードにインストールする必要があります。

�� クラスタのノード数は、2 ノード以下に限定されます。*

�� クラスタは、クラスタの外部にインストールされたクォーラム サーバ クラスタ ロックを持つ必要があります。

�� 2 つ以上のハートビート ネットワークを設定する必要があります。

�� ハートビート ネットワークには、RS-232 リンクは使用できません。

�� CVM は単一のハートビートを必要とし、SGeFF は複数のハートビートを必要とするため、CVM を SGeFF クラスタ

で使用することはできません。

SGeFF でファイバ チャネル ストレージを使用する場合、フェイルオーバー時間が短いために、複雑な構成のファブリック

であるとノード停止後も I/O が残ってしまうことがあります。フェイルオーバー後のデータ一貫性を保証するためには、

SGeFF でファイバ チャネル スイッチを使用する場合、ノードとストレージ間で、スイッチは 2 段以下に設定することをお

勧めします。

SGeFF クラスタは、3 ノード以上のクラスタでは使用できません。SGeFF を、有効化または無効化するには、クラスタ全

体を停止させる必要があります。

遠 距 離 ク ラ ス タ で SGeFF を 使 用 す る 場 合 に は 、 www.docs.hp.com/hpux/ha –> [Metrocluster] ま た は [Continentalcluster] から入手可能な『Designing Disaster Tolerant High Availability Clusters』に記載されている「two data centers and third location」構成を使用してください。

SGeFF に適切な環境

適度で予測可能な負荷をもつシステムが、SGeFF の候補となります。Serviceguard の通常運用に影響するような大き

な瞬間的な過負荷 が、CPU、ネットワーク、または I/O アクティビティに頻繁に発生しないことが、適切なシステムの条

件となります。

SGeFF は、フェイルオーバー時間のうち、Serviceguard に関する部分だけを短縮するのであり、アプリケーションに依

存するフェイルオーバー時間には影響しないことに注意してください。「フェイルオーバー時間を 適化する方法」で説明

したように、フェイルオーバー時間のうち、Serviceguard に関する部分とアプリケーションに依存する部分の両方を短縮

することが重要です。アプリケーションの起動と復旧の完了に長い時間 (たとえば 5 分) かかる場合には、SGeFF を使

用しても合計フェイルオーバー時間が大きく短縮することはありません。

SGeFF は、次の場合に適しています。

�� アプリケーションの開始にまったく時間がかからないか、または非常に短い

�� アプリケーションの復旧時間が非常に短い

�� アプリケーションの復旧リソースが少量であるか、または迅速 (たとえば、パッケージのボリューム グループが少数、

ファイル システムが少数、高速復旧用の VxFS)

次に、SGeFF に十分に適合する環境の例を示します。

�� 次の SGeRAC 環境

– すべてのノードですでに Oracle RAC インスタンスが動作しているため、アプリケーションの起動時間が不要

– 高速復旧用に Oracle RAC を調整可能。一般に 10 ～ 60 秒

�� 復旧時間を 小化するように調整された従来のデータベース ソフトウェアを使用するアプリケーション

�� 復旧時間の短い IP ベースの任意のアプリケーション

* SGeFF クラスタには 2 ノードが必要です。1 ノードクラスタも許可されており、構成を開始できますが、1 ノードだけではフェイルオーバーを行うことはできま

せん。

13

クラスタ パラメータに関する検討事項

Serviceguard Extension for Faster Failover の短いフェイルオーバー時間に関しては、いくつかリスクがあります。一時

的な中断が発生する場合には、中断から回復するのに十分な長さにノードタイムアウト値を設定する必要があります。

各システム管理者は、障害の可能性 (不確実な場合) をクラスタが確認するのに必要な時間を判断する必要があります。

ネットワーク、I/O、または CPU に頻繁にまたは大きな瞬間的な過負荷が発生する負荷の大きいシステムでは、一時的

な問題によってハートビートの遅延が発生する可能性があります。

SGeFF では、NODE_TIMEOUT の 小値として 1.6 秒、HEARTBEAT_INTERVAL に 0.8 秒がサポートされています。

これらの値によって、フェイルオーバー時間のうちの Serviceguard 部分を 5 秒間に短縮できます。ただし、このような

小さな値は、すべての SGeFF 環境で適切とは限りません。

SGeFF クラスタでは、NODE_TIMEOUT を注意深く設定、テストする必要があります。Faster Failover クラスタの再編成

プロセスは、即座に終了します。したがって、一時的な問題を持った正常ノードがクラスタから排除される可能性が高くな

ります。

ノードタイムアウト値は、一時的な問題や中断を許容できないほど短くすべきではありません。各システム管理者は

Serviceguard がハートビート遅延をタイムアウトと判断する前に一時的な中断からの回復を待つのに十分なだけの

適時間を決定する必要があります。

ノードタイムアウト値は、正常ノードからのハートビートの遅延によって、クラスタが再編成を開始するほど短くすべきで

はありません。短く設定すると、ノードが不必要にクラスタから排除されたり、また時間内に復旧してクラスタに再度追加

される可能性が高くなります。2 番目の場合、クラスタは再編成を行いますが、メンバシップは再編成前と同じになりま

す。

NODE_TIMEOUT の値は、Faster Failover クラスタに大きな影響を及ぼします。たとえば、Faster Failover が構成可能

な 2 つの同等な 2 ノード クラスタを想定します。1 つは標準の Serviceguard システムであり、もう 1 つは SGeFF シス

テムとします。どちらも、QS_TIMEOUT_EXTENSION に 0、NODE_TIMEOUT に 2 秒を設定します。8 秒以上継続す

る一時的な問題が発生すると、2 つのクラスタでは結果が異なります。

�� 標準の Serviceguard システムでは、再編成に約 28 秒かかります。再編成が終了するまでに一時的な問題から

回復し、したがってノードは継続して稼働し、クラスタに再度参加できます。

�� SGeFF システムでは、再編成は 6 秒で完了しますが、これは、問題から回復するための時間よりもかなり短い時

間です。クラスタは、このノードを除いて再編成を行います。ノードは再起動されます。

SGeFF クラスタ内のフェイルオーバーは、標準的な Serviceguard クラスタのフェイルオーバーよりも格段に高速です。

前述の SGeFF クラスタの例を使用すると、SGeFF クラスタでは、ノードタイムアウト値を 2 倍に設定した場合でも、標準

的なフェイルオーバーの Serviceguard 部分と比較して半分の時間しか必要としません。

�� 上記のようにインストールされた標準的な Serviceguard クラスタでは、ノードタイムアウト値が 2 秒の場合は、フェ

イルオーバーの Serviceguard 部分は 28 秒になります。

�� SGeFF を使用する場合、ノードタイムアウト値を 4 秒に変更すると、フェイルオーバーの Serviceguard 部分は、

12 秒になります。

仮想パーティションは、ハードウェアとソフトウェアの共有のため、独立ノードとは異なる遅延特性を持つ可能性がありま

す。クラスタ内で仮想パーティションを使用する場合には、構成に関するノードタイムアウト値をテストするときに、さらに

別の検討項目についての考慮が必要な場合あります。詳細は、www.docs.hp.com/hpux/ha でホワイト ペーパー

『ServiceGuard Cluster Configuration for Partitioned Systems』を参照してください。

14

まとめ

Serviceguard クラスタ内の合計フェイルオーバー時間は、多くの要因、そしてその要因間の相互作用によって異なりま

す。Serviceguard ユーザーは、フェイルオーバー時間を 適化することによって、アプリケーションの稼働時間を 大に

することができます。

フェイルオーバー時間の 適化は、必要以上に待機する場合と、対処開始が早すぎる場合との間の、バランスを取るこ

とを意味しています。フェイルオーバー プロセスの時間を短くすることは、パッケージのダウンタイムが短いことを意味し

ています。クラスタは、障害を速やかに検出し、再編成とアプリケーションの再起動を迅速に実行できます。しかし、タイ

ミングをあまりにも短く設定すると、不必要なフェイルオーバーが発生し、場合によっては繰り返されることになり、 終

的には全体的な可用性が低下することになります。

フェイルオーバーの合計時間には、Serviceguard 部分とアプリケーション依存部分が含まれます。1 つの部分の 適化

を過度に強調すると、可用性が極度に低下する可能性があります。

Serviceguard 部 分 の 時 間 を 短 縮 す る た め に は 、 い く つ か の タ イ ミ ン グ パ ラ メ ー タ の 設 定 、 基 本 的 に は NODE_TIMEOUT の設定を検査してください。

アプリケーションの起動と復旧の時間を短縮するには、制御スクリプトと各アプリケーションのドキュメントを確認してくだ

さい。

さらにアドオン製品の Serviceguard Extension for Faster Failover では、Serviceguard のフェイルオーバー時間を 5 秒間へ短縮できます。この製品は、特定の構成でのみサポートされています。

詳細情報

HP の高可用性製品とソリューションについては、次の URL を参照してください。

www.hp.com/go/serviceguard (英語)

http://h50146.www5.hp.com/products/software/oe/hpux/developer/software/ha/ (日本語)

お問い合わせはカスタマー インフォメーションセンターへ

03-6416-6660 月～金9:00～19:00 土10:00～18:00 (日、祝祭日、年末年始および5/1を除く) P-UX 製品に関する情報は http://www.hp.com/jp/hpux H

記載されている会社名および商品名は、各社の商標または登録商標です。 記載事項は2004年07月現在のものです。 本書に記載された内容は、予告なく変更されることがあります。 本書中の技術的あるいは校正上の誤り、省略に対して、 いかなる責任も負いかねますのでご了承ください。 本書は、『Optimizing failover time in a Serviceguard environment 』（英語）をもとに日本語で提供するものです。 © Copyright 2004 Hewlett-Packard Development Company,L.P.

ー

日本ヒューレット・パッカード株式会社 〒140-8641 東京都品川区東品川2-2-24 天王洲セントラルタワ

PDFHS04044-01