本文に進む 日本−日本語
日本HPホーム 製品とサービス お客様サポート/ ダウンロード ソリューション ご購入の方法
≫ お問い合わせ
詳細検索オプション
日本HPホーム
 Serviceguard の管理 > 第4章 HA クラスタのプランニングと文書化

パッケージ構成のプランニング
≫ 

テクニカル ドキュメント

PDF版
≫ 関連ドキュメント
≫ フィードバック
ここから本文が始まります

 ≫ 目次

 ≫ 索引

spacerspacerspacer
spacer
spacer
  		 
 

パッケージのプランニングには、各グループの高可用性サービスに関する情報の収集作業が含まれます。

注記: Serviceguard A.11.18 から、新しい簡単なパッケージ構成方法が提供されます。この方法を使うと、小規模なモジュールを組み合わせてパッケージを構築することができ、独立したパッケージ制御スクリプトが不要になり、そのスクリプトを手作業で配布する必要がなくなります。手順の詳細は、第6章 「パッケージとサービスの構成」を参照してください。

本書では、新しい方法で作成されたパッケージをモジュラーパッケージ、古い方法で作成されたパッケージを従来のパッケージと呼びます。

以降の説明は、モジュラー方式を使っていることを前提としています。従来のパッケージの作成と維持についての情報と手順は、「従来のパッケージの構成」を参照してください。

論理ボリュームとファイルシステムのプランニング

注記: パッケージによってアクティブ化される LVM ボリュームグループについても、クラスタ構成ファイルでクラスタ対応として定義する必要があります。「クラスタ構成のプランニング」を参照してください。パッケージによりアクティブ化されるディスクグループ (Veritas Volume Manager 用) は、パッケージ構成ファイルで定義しなければなりません (下記の説明を参照)。

クラスタ上でパッケージが動作するためのインフラストラクチャの一部として、ボリュームグループ内で論理ボリュームを使用することが必要です。一方のノードからもう一方のノードへパッケージが移動するとき、移動前のノード上のディスクと同じディスクにあるデータにアクセスできなければなりません。このためには、ボリュームグループをアクティブ化してファイルシステムをマウントします。

Serviceguard では、高可用性アプリケーション、サービス、データは、共有バス上のボリュームグループに置かれます。ノードで障害が発生した場合、そのノードのアプリケーション、サービス、データを持つボリュームグループは、障害の発生したノード上で非アクティブ化され、引き継ぎノード上でアクティブ化されます。このような動作をさせるためには、ボリュームグループを構成して、障害の発生したノードから引き継ぎノードへボリュームグループを移動できるようにしなければなりません。

プランニングの一部として、以下の項目を決定する必要があります。

  • どのようなボリュームグループが必要か

  • どれくらいのディスクスペースが必要か。また、このスペースを論理ボリューム内でどのように割り当てるか

  • 各パッケージにどのファイルシステムのマウントが必要か

  • どのノードがどの論理ボリューム構成をインポートするか

  • パッケージが引き継ぎノードへ移動する場合、移動したパッケージは性能にどのように作用するか

ボリュームグループ、論理ボリュームおよびファイルシステムのリストをパッケージごとに作成してください。同じファイルシステムに対して別のタイミングでアクセスする必要のあるノードを明示してください。

論理ボリューム名をカスタマイズして、デフォルトの論理ボリューム名 (lvol1、lvol2 など) 以外の名前を使用することをお勧めします。関連する高可用性アプリケーションを示す名前 (lvoldatabase など) を付けておくと、クラスタが管理しやすくなります。

各ノード上の、パッケージに関連するボリュームグループ、論理ボリューム、ファイルシステムに関する詳しい説明を記述したいときには、/etc/fstab ファイルにコメント行を追加します。データベースアプリケーションの例を以下に示します。

# /dev/vg01/lvoldb1 /applic1 vxfs defaults 0 1   # These six entries are
# /dev/vg01/lvoldb2 /applic2 vxfs defaults 0 1   # for information purposes
# /dev/vg01/lvoldb3 raw_tables ignore ignore 0 0 # only. They record the
# /dev/vg01/lvoldb4 /general vxfs defaults 0 2   # logical volumes that
# /dev/vg01/lvoldb5 raw_free ignore ignore 0 0   # exist for Serviceguard's
# /dev/vg01/lvoldb6 raw_free ignore ignore 0 0   # HA package. Do not uncomment.

各ボリュームグループにエントリーを作成して、ファイルシステムまたは raw デバイス向けであることを明記してください。行をコメントアウト (例のように# 文字を使用) することを忘れないでください。

注記: Serviceguard パッケージが使用するファイルシステムのマウントには /etc/fstab ファイルを使用しないでください。

Veritas Cluster Volume Manager (CVM) と Cluster File System (CFS) のプランニング

注記: CVM と CFS は、HP-UX のいくつかのリリースでサポートされていますが、現行リリースのすべてでサポートされているわけではありません。最新情報については、お使いのバージョンに対応する Serviceguard の最新のリリースノートを参照してください (http://docs.hp.com/ja -> [ハイ アベイラビリティ] -> [Serviceguard] から入手可能です)。

CVM または CFS を使っているフェイルオーバーパッケージでは、ボリュームグループとファイルシステムを扱うシステムマルチノードパッケージを構成します。

注意: Serviceguard は Veritas プロセス (具体的には、gab と llt) をシステムマルチノードパッケージを使って管理するため、gabconfig、llthosts、lltconfig などの Veritas 管理コマンドは、gabconfig -a などの表示モードでしか使うことはできません。gab* コマンドや llt* コマンドを使って、コンポーネントを構成したり実行時の動作を制御しようとすると、ノードやクラスタ全体がクラッシュするおそれがあります。

CVM バージョン 3.5

Veritas Cluster Volume Manager 3.5 は、クラスタのボリュームを管理するために、システムマルチノードパッケージ VxVM-CVM-pkg を使います。

CVM 3.5 と VxVM-CVM-pkg では、1 つのハートビートネットワークしか構成できません。複数のハートビートはサポートされていません。APA、Infiniband、VLAN インタフェースをハートビートネットワークとして使うこともできません。

CFS を使わない CVM 4.1 以降

Veritas Cluster Volume Manager 4.1 以降は、クラスタのボリュームを管理するために、システムマルチノードパッケージ SG-CFS-pkg を使います。

CVM 4.1 以降と SG-CFS-pkg を使うときには、複数のハートビートネットワーク、または待機 LAN のあるハートビートネットワークを 1 つ構成する必要があります。APA、Infiniband、VLAN インタフェースをハートビートネットワークとして使うことはできません。

CFS を使う CVM 4.1 以降

Veritas Cluster Volume Manager Version 4.1 以降では、CFS (Veritas Cluster File System) の利用がサポートされています。

システムマルチノードパッケージ SG-CFS-pkg は、クラスタのボリュームを管理します。CFS マウントパッケージ SG-CFS-MP-id# と、CFS ディスクグループパッケージ SG-CFS-DG-id# の、2 つのマルチノードパッケージも使われます。マルチノードパッケージは、cfs ファミリーのコマンドを使って作成します。構成ファイルは編集しないでください。

CVM 4.1 以降と SG-CFS-pkg を使うときには、複数のハートビートネットワーク、または待機 LAN のあるハートビートネットワークを 1 つ構成する必要があります。APA、Infiniband、VLAN インタフェースをハートビートネットワークとして使うことはできません。

アプリケーションフェイルオーバーパッケージと非フェイルオーバーパッケージには、パッケージ依存関係のチェーンを作成します。

  1. フェイルオーバーパッケージのアプリケーションは、マウントポイントパッケージが動作していない限り、ノード上で実行しないようにします。

    パッケージの構成ファイルに依存関係のパラメータを記入して、要件を設定します (SAME_NODE に対して、SG-CFS-MP-id# =UP を設定)。

  2. マウントポイントパッケージは、ディスクグループパッケージが動作していない限り実行しないようにします。

    cfsmntadm と cfsmount コマンドを使って、マウントポイントパッケージを作成します。Serviceguard は自動的に ID の数を増やして、マウントポイントパッケージ、SG-CFS-MP-id# を作成します。Serviceguard は、ディスクグループパッケージの依存関係を構成ファイルに設定します。

  3. ディスクグループパッケージは、ボリュームを管理する CFS システムマルチノードパッケージ (SG-CFS-pkg) が動作していない限り実行しないようにします。

    cfsdgadm コマンドを使ってディスクグループパッケージを作成します。Serviceguard は自動的に ID の数を増やして、ディスクグループパッケージ、SG-CFS-DG-id# を作成します。Serviceguard は、CFS システムマルチノードパッケージ (SG-CFS-pkg) に対する依存関係を構成ファイルに設定します。

    注意: ディスクグループパッケージとマウントポイントパッケージを作成したら、cfsdgadm、cfsmntadm、cfsmount、cfsumount などの cfs コマンドを使ってクラスタを管理する必要があります。mount や umount のような一般的なコマンドを使うと、クラスタファイルシステムではなくローカルファイルシステムへの書き込みが行われるなど、深刻な問題が起きる可能性があります。

    cfsmount または cfsumount 以外のすべての形式の mount コマンド (たとえば、mount -o cluster、dbed_chkptmount、sfrac_chkptmount) は、CFS を使った HP Serviceguard Storage Management Suite 環境では注意深く使う必要があります。このような cfs 用でないコマンドを使用すると、その後のファイルシステムまたは Serviceguard パッケージに対するコマンド操作で、整合性の問題が発生する場合があります。また、このような形式の mount コマンドを使うと、適切なマルチノードパッケージが生成されないため、クラスタパッケージはファイルシステムの変更を認識できません。

    注記: ディスクグループ (DG) およびマウントポイント (MP) のマルチノードパッケージ (SG-CFS-DG_ID# と SG-CFS-MP_ID#) は、ディスクグループとマウントポイントの稼働状態を監視しません。これらに依存するアプリケーションパッケージがディスクグループとマウントポイントにアクセスできるかどうかは監視されます。依存するアプリケーションパッケージがアクセスできなくなって、ディスクへの読み書きが不可能になると、このパッケージは障害状態になります。ただし、DG または MP のマルチノードパッケージが障害状態になるわけではありません。

  4. cfscluster コマンドを使って CFS パッケージ SG-CFS-pkg を作成します。このシステムマルチノードパッケージは CVM 4.1 以降で使われるボリュームを管理します。システムマルチノードパッケージは、他のパッケージに対する依存関係を持ちません。

拡張のプランニング

実行中のクラスタにパッケージを追加することができます。このプロセスについては、第7章 「クラスタとパッケージの管理」で説明しています。

パッケージを追加する際には、クラスタ構成ファイルで定義されている max_configured_packages の値を上回らないように注意してください (「クラスタ構成のパラメータ」を参照)。必要であれば、クラスタの稼働中にこのパラメータを変更することができます。

切り替え動作とフェイルオーバー動作の選択

フェイルオーバーパッケージ (「パッケージのタイプ」を参照) は、障害の発生した LAN カードから同じ物理サブネット上の予備の LAN カードへ IP アドレスが切り替わるように構成することができます。この動作を有効にするには、 local_lan_failover_allowed パラメータを使います (yes がデフォルトで、有効という意味です)。

フェイルオーバーパッケージのフェイルオーバー動作を設定するために、動作していないパッケージを Serviceguard が自動的に起動する場所を決定する方針を定義します。さらに、一次ノードが使用可能になったときにパッケージを一次ノードに自動的に戻すかどうかを指定するフェイルバックポリシーを定義できます。

表 3-3 「パッケージフェイルオーバー動作」では、各種のフェイルオーバー動作とその動作を決定するためのパラメータの設定方法が説明されています。

EMS リソースを構成するパラメータ

注記: モジュラーパッケージ構成ファイルのパラメータ名とリテラル値のデフォルトの形式は小文字です。従来のパッケージではデフォルトは大文字です。互換性の問題はありません。Serviceguard は、少なくともパラメータ名については、大文字と小文字を区別しないためです。本書では、パラメータが従来のパッケージでのみ使われる場合や、前後関係から従来のパッケージだけを対象にしていることがわかる場合を除き、パラメータ名には小文字を使います。

Serviceguard では、EMS (Event Monitoring Service) リソースを構成する一連のパラメータが提供されています。これらは、resource_name、resource_polling_interval、resource_start、および resource_up_value です。パッケージが依存している各リソースについて、これらのパラメータをパッケージ構成ファイルに構成します。

resource_start パラメータは、Serviceguard が EMS リソースのリソース監視をいつ開始するかを決定します。resource_start には、automatic またはdeferred のいずれかを設定することができます。

Serviceguard は、Serviceguard のクラスタデーモンがノード上で起動されると、automatic リソースのリソース監視を自動的に開始します。

Serviceguard は、ノードの起動時にはdeferred リソースの監視は開始せず、パッケージの実行時にこれらのリソースの監視を開始します。

deferred リソースとautomatic リソースの構成方法の例を、次に示します。

resource_name /net/interfaces/lan/status/lan0
resource_polling_interval 60
resource_start deferred
resource_up_value = up

resource_name /net/interfaces/lan/status/lan1
resource_polling_interval 60
resource_start deferred
resource_up_value = up

resource_name /net/interfaces/lan/status/lan0
resource_polling_interval 60
resource_start automatic
resource_up_value = up
注記: 従来のパッケージでは、DEFERRED_RESOURCE_NAME パラメータを使って、パッケージ制御スクリプトにもdeferred リソースを指定します。
DEFERRED_RESOURCE_NAME[0]="/net/interfaces/lan/status/lan0"
DEFERRED_RESOURCE_NAME[1]="/net/interfaces/lan/status/lan1"

従来の構成ファイルでAUTOMATIC としてリソースが構成されている場合は、パッケージ制御スクリプトで DEFERRED_RESOURCE_NAME を定義する必要はありません。

パッケージの依存関係について

Serviceguard A.11.17 から、パッケージは他のパッケージへの依存関係 (つまり、依存しているパッケージがノード上で実行されない限り、パッケージは起動されない) を持つことができるようになりました。

Serviceguard A.11.17 では、パッケージの依存関係は、Veritas Cluster File System (CFS) をサポートしているシステム上で CFS と共に使うために当社が提供しているマルチノードパッケージやシステムマルチノードパッケージなど、当社が指定した一部のアプリケーション用としてのみサポートされています。

Serviceguard A.11.18 では、パッケージの依存関係にこのような制限はなくなりました。第 6 章の「dependency_condition」で説明している条件に従えば、同じクラスタノード上で実行されている他の任意のパッケージに対して、パッケージの依存関係を設定できます。

あるパッケージが、他のパッケージが提供するサービスなしでは機能できない (または機能してはならない) 場合に、他のパッケージに対するパッケージの依存関係を設定してください。たとえば、pkg2 が管理しているデータベースへのリアルタイム Web インタフェースを pkg1 が実行しているとします。この場合、pkg1 は pkg2 に依存しているといえます。

パッケージ間の依存関係を設定するかどうかを検討する際には、以下の「規則」と「ガイドライン」を参考にしてください。

規則

pkg1 を pkg2 に依存させたいとします。

注記: pkg1 は、他の複数のパッケージに依存することができます。pkg2 も、他の 1 つ以上のパッケージに依存することができます。ここでは規則をできるだけ分かりやすくするために、パッケージは 2 つだけであるとします。

  • pkg1 は、pkg2 がノード上で実行中でなければ、どのノード上でも起動されません。

  • pkg1 の「package_type」と「failover_policy」は、以下のように、 pkg2 のタイプと特性を制限します。

    • pkg1 がマルチノードパッケージの場合、pkg2 はマルチノードパッケージまたはシステムマルチノードパッケージでなければなりません。 (システムマルチノードパッケージは一般的な用途にはサポートされていないことに注意してください。)

    • pkg1 がフェイルオーバーパッケージで、その failover_policy がmin_package_node の場合、pkg2 はマルチノードパッケージまたはシステムマルチノードパッケージでなければなりません。

    • pkg1 がフェイルオーバーパッケージで、その failover_policy がconfigured_node の場合、pkg2 は次のいずれかでなければなりません。

      • マルチノードパッケージまたはシステムマルチノードパッケージ。

      • failover_policy がconfigured_node のフェイルオーバーパッケージ。

  • pkg2 は、failover_policy がmin_package_node のフェイルオーバーパッケージであってはなりません。

  • pkg2 のノードリスト (「node_name」の node_name を参照) には、pkg1 のすべてのノードが含まれていなければなりません。

    • failover_policy がconfigured_node のパッケージ間の依存関係の場合、できればノードを同じ順序でリストしてください。同じ順序でリストされていないと、cmcheckconf と cmapplyconf で警告が表示されます。

  • パッケージは、直接的であっても間接的であっても、自分自身に依存することはできません。

    つまり、pkg1 は自分自身を「dependency_condition」に指定してはならないだけでなく、pkg2 が pkg1 に依存している場合や、pkg2 が pkg3 に依存していて pkg3 が pkg1 に依存している場合も、pkg2 への依存関係を設定してはなりません。

  • pkg1 がフェイルオーバーパッケージであり、pkg2 がマルチノードパッケージまたはシステムマルチノードパッケージで、pkg2 に障害が発生した場合、pkg1 は停止し、その node_name リスト上の次のノード (pkg2 が動作し、リソースの依存関係や第 3 のパッケージへの依存関係など、他の依存関係を満たしている) にフェイルオーバーします。

  • failover_policy がconfigured_node のフェイルオーバーパッケージの場合、一連の規則により、特定のノード上での pkg2 の起動を pkg1 が強制できる状況を指定します。これをドラッグといい、各パッケージの「priority」で決定されます。「ドラッグ規則」を参照してください。

  • pkg2 に障害が発生すると、Serviceguard は pkg1 を停止し、また pkg2 に直接的または間接的に依存している他のパッケージを停止します。

    Serviceguard はデフォルトでは、依存しているパッケージをまず停止してから、そのパッケージに依存されているパッケージを停止するというように、依存順にパッケージを停止します。この例では、まず pkg1 が停止してから、pkg2 が停止します。pkg1 に依存する第 3 のパッケージ pkg3 が存在する場合、pkg3 がまず停止してから、pkg1 が停止し、次に pkg2 が停止します。

    依存しているパッケージの停止スクリプトがハングアップすると、依存されているパッケージは、デフォルトでは永久に待ち状態になります (pkg2 は pkg1 を永久に待ち、pkg1 に依存する pkg3 が存在する場合、pkg1 は永久に pkg3 を待ちます)。この動作は、successor_halt_timeout パラメータを使って変更することができます (「successor_halt_timeout」を参照)。(パッケージの後続パッケージは、そのパッケージに依存しています。この例では、 pkg1 は pkg2 の後続パッケージです。逆に pkg2 は、pkg1 の先行パッケージと言います。)

ドラッグ規則

priority パラメータを使うと、failover_policy がconfigured_node のフェイルオーバーパッケージのセットにおいて、1 つ以上のパッケージが他のパッケージに依存しているときに、起動、フェイルオーバー、およびフェイルバックの動作に影響を与えることができます。

優先順位の高いパッケージが、優先順位の低いパッケージをドラッグし、優先順位の高いパッケージに合ったノードで起動させたり、そのノードへ移動できるというのが、大まかな規則です。

注記: この項目は、パッケージが自動的に起動された (パッケージ切り替えが使用可能である) 場合にのみ適用されます。cmrunpkg で起動したパッケージが強制的に停止されることはありません。

他のパッケージに依存するパッケージが存在する場合でも、priority を設定する必要はありません。多くの場合、デフォルト値のno_priority で、ユーザーが期待する動作となります。たとえば、pkg1 が pkg2 に依存しており、どちらのパッケージの priority にもno_priority が設定されていて、この項で推奨したとおりに node_name や auto_run などの他のパラメータが設定されている場合、両方のパッケージを実行できるときには、pkg1 は通常、pkg2 の後に実行されます。これは、常識的な (最も望ましい) 動作です。

以下の例は、「failover_policy」がconfigured_node の 2 つのフェイルオーバーパッケージに適用される規則について示しています。 pkg1 が pkg2 に依存していて、node1、node2、および node3 が各パッケージの構成ファイルの「node_name」に一定の順序ですべて指定されており、また各パッケージの「failback_policy」にautomatic が設定されているものとします。

注記: 下記の例を参照する際と、実際に優先順位を構成する際には、以下の事項に注意してください。

  1. 関連するすべてのパッケージの「auto_run」には、yes が設定されていなければなりません。この例では、この設定を前提としています。

  2. 優先順位は、ランクの順序を示しています。そのため、小さい値ほど優先順位は高くなります (たとえば、10 は 30 よりも優先順位が高い)。

    値は 20 の倍数で指定して、序列内に隙間を残しておくことをお勧めします。そうしないと、新しいパッケージに優先順位を割り当てるときに、すべての既存の優先順位をふり直さなくてはならなくなることがあります。

    デフォルトのno_priority は、どの数値よりも低い優先順位として扱われます。

  3. no_priority のパッケージはすべて同じ優先順位です。同じ優先順位を割り当てる方法は、他にはありません。数値の優先順位は、同じクラスタ内で重複があってはなりません。詳細は、priority (「priority」) を参照してください。

pkg1 が pkg2 に依存し、pkg1 の優先順位が pkg2 の優先順位以下で、pkg2 のノード順序が優先される場合。pkg2 のノード順序は、node1、node2、node3 とします。

  • 起動時:

    • pkg2 は、node1 で起動されます。node1 が利用できないか、依存関係のすべての条件を現在満たしていないなどの場合は、node2 で起動されます。

      • pkg1 の他の依存関係をすべて満たしていれば、pkg1 は pkg2 が起動されたノードで (pkg1 の node_name リストのどこにそのノードが指定されているかにかかわらず) 起動されます。

      • pkg2 が起動されたノードが、pkg1 の依存関係のすべてを満たしていない場合は、pkg1 は起動されません。

  • フェイルオーバー時:

    • node1 上で pkg2 に障害が発生すると、pkg2 は node2 に (または、node2 が利用できないか、依存関係のすべての条件を現在満たしていないなどの場合は、node3 に) フェイルオーバーします。

      • pkg1 の依存関係をすべて満たしていれば、pkg1 は pkg2 が再起動されたノードへ (pkg1 の node_name リストのどこにそのノードが指定されているかにかかわらず) フェイルオーバーします。

        • pkg2 が再起動されたノードが、pkg1 の依存関係のすべてを満たしていない場合は、pkg1 は再起動されません。

    • pkg1 で障害が発生した場合、pkg1 はフェイルオーバーしません。

      これは、pkg2 がいずれかの引き継ぎノード上で実行されるまでは pkg1 をそのノード上で再起動できませんが、pkg2 が元のノード上で実行されたままとなっているためです。pkg1 は、優先順位が十分でないため、pkg2 をドラッグすることはできません。

  • フェイルバック時:

    • 両方のパッケージが node1 から node2 に移動され、node1 が利用可能になったときは、pkg2 の優先順位が pkg1 の優先順位よりも高い場合だけ、pkg2 が node1 にフェイルバックします。

      • 優先順位が等しい場合、どちらのパッケージもフェイルバックしません (ただし、pkg1 が実行されていない場合、pkg2 はフェイルバックできます)。

      • pkg2 の優先順位が pkg1 の優先順位よりも高い場合、pkg2 は node1 にフェイルバックし、pkg1 の他の依存関係がすべてそのノードで満たされれば、pkg1 は node1 にフェイルバックします。

        • pkg2 が node1 にフェイルバックしたが、node1 が pkg1 の依存関係をすべて満たさなければ、pkg1 は停止します。

pkg1 が pkg2 に依存し、pkg1 の優先順位が pkg2 の優先順位より高く、pkg1 のノード順序が優先される場合。pkg1 のノード順序は、node1、node2、node3 とします。

  • 起動時:

    • pkg1 は、起動場所として node1 を選択します。

    • pkg2 は、node1 で動作可能であれば、node1 で (pkg2 の node_name リストのどこに node1 が指定されているかにかかわらず) 起動されます。

      • pkg2 は、他のノード上ですでに実行されている場合、node1 で動作可能であれば、node1 にドラッグされます。

    • pkg2 を node1 上で起動できなければ、パッケージは両方とも node2 (このノードでも起動できなければ、次のノード) で起動されます。

    ノードは、pkg1 の node_name リスト順で試されます。pkg2 は、現在他のノードで実行されているかどうかにかかわらず、このリスト上の、最初に適したノードにドラッグされます。

  • フェイルオーバー時:

    • node1 上で pkg1 に障害が発生すると、pkg1 は node2 (または、node3 で動作可能で、node2 が利用できないか、依存関係のすべての条件を現在満たしていないなどの場合は、node3) をフェイルオーバー用に選択します。

    • pkg2 は、pkg1 が選択したノードにドラッグされ、そこで再起動されます。その後、pkg1 がそのノードで再起動されます。

  • フェイルバック時:

    • 両方のパッケージが node2 に移動され、node1 が利用可能になったときは、そのノードで両方のパッケージが動作可能であれば、pkg1 は node1 にフェイルバックします。

      • これ以外の場合は、どちらのパッケージもフェイルバックしません。

ガイドライン

「ドラッグ規則」で分かるように、 pkg1 が pkg2 に依存している場合、pkg1 で障害が発生したときのフェイルオーバー (およびフェイルバック) が最も成功しやすくなるため、 pkg1 に高い優先順位を割り当てることは、場合によっては良い方法です。

ただし、パッケージの相対的な重要度も考慮する必要があります。ビジネスのかなめとなるデータベースを pkg2 が実行している場合は、依存しているアプリケーションパッケージに何が起こっても、データベースの実行に支障がない方がよいと考えられます。このような場合は、データベースパッケージを最高の優先順位とします。

優先順位が設定されていない場合、ドラッグ規則では、他パッケージから依存されているパッケージを、そのパッケージに依存しているパッケージよりも優先します。

依存するパッケージと依存されるパッケージの重要度が現実的にほぼ同じ場合は、依存する側のパッケージに高い優先順位を割り当ててください。同じでない場合は、重要なパッケージに高い優先順位を割り当てるか、両方のパッケージの優先順位をデフォルトのままとしてください。

また、パッケージの障害時に何が発生するかも考えなければなりません。他のパッケージがそのパッケージに依存している場合、Serviceguard はこれらのパッケージ (および、これらのパッケージに依存しているパッケージ) を停止します。この状況は、障害が発生したパッケージの優先順位にかかわらず発生します。

デフォルトでは、パッケージは起動されたときと逆の順序で停止されます。依存する側のパッケージの停止スクリプトがハングアップした場合、障害が発生したパッケージは自身の停止処理の完了を無限に待ちます。これにより、依存するすべてのパッケージが完全に停止する可能性が最も高くなりますが、ユーザーが期待する動作とは異なる可能性があります。この動作は、successor_halt_timeout パラメータを使って変更することができます (「successor_halt_timeout」を参照)。

successor_halt_timeout にゼロを設定すると、Serviceguard は依存する側のパッケージを、障害が発生したパッケージと同時に停止します。このパラメータに正の数を設定すると、Serviceguard は起動時と逆の順番でパッケージを停止しますが、successor_halt_timeout 秒後には、依存する側のパッケージが停止スクリプトを完了したかどうかにかかわらず、障害が発生したパッケージを停止させることができます。

外部スクリプトについて

モジュラースクリプトのパッケージ構成テンプレートにより、外部スクリプトを明示的に指定できます。このスクリプトは従来のスクリプトの CUSTOMER DEFINED FUNCTION に代わるもので、以下のいずれかの場合に実行できます。

  • パッケージの起動時とシャットダウン時。つまり基本的には、パッケージが実行する最初と最後の関数です。このスクリプトは、「external_pre_script」パラメータで起動されます。

  • パッケージの実行中、ボリュームグループとファイルシステムの起動後、IP アドレスの割り当て後、かつサービスおよびリソースの関数の実行前。そして再度、逆順でパッケージのシャットダウン時。このスクリプトは、「external_script」により起動されます。

このスクリプトは、cmcheckconf と cmapplyconf でパッケージを検証する際にも実行されるため、検証用のエントリーポイントを持たせる必要があります。以下の説明を参照してください。

1 つのパッケージは両方の種類のスクリプトを使うことができ、それぞれの種類のスクリプトを複数起動することができます。この場合、スクリプトは、パッケージ構成ファイルにリストされている順序 (パッケージのシャットダウン時には逆順) で実行されます。

外部スクリプトには、3 つのエントリーポイントstart、stop、およびvalidate が必要で、以下の値のいずれかで終了しなければなりません。

  • 0 - 成功を示します。

  • 1 - スクリプトが失敗したため、パッケージが停止されるが、再起動してはならないことを示します。

  • 2 - パッケージが別のノードで再起動されるか、使用可能な他のノードがない場合は停止されることを示します。

注記: validate エントリーポイントの場合、終了値1 と2 は同様に扱われます。どちらの値でも検証の失敗を示すことができます。

スクリプトは、パッケージを実行するパッケージマネージャまたはマスター制御スクリプトがエクスポートした環境変数の標準セット (パッケージ名SG_PACKAGE と、ローカルノード名SG_NODE を含む) を使うことができます。また、ログ関数や他のユーティリティ関数を取り込むための関数を呼び出すこともできます。このような関数の 1 つ、sg_source_pkg_env() を呼び出すと、pev_ パラメータ (「pev_」を参照) により構成された、パッケージ固有の環境変数を含め、このパッケージに構成されているすべてのパラメータにアクセスできます。

詳細は、$SGCONF/examples/external_script.template のテンプレートを参照してください。

以下に、サンプルのスクリプトを示します。このスクリプトでは、一部のアプリケーションを監視する Serviceguard サービスとして構成される、monitor.sh という別のスクリプトがあることを前提としています。monitor.sh スクリプト (ここには記載されていません) は、パッケージ構成ファイルで定義されている PEV_MONITORING_INTERVAL パラメータを使って、監視対象のアプリケーションを定期的にポーリングします。例を次に示します。

PEV_MONITORING_INTERVAL 60

サンプルスクリプトは検証時に、PEV_MONITORING_INTERVAL パラメータと監視サービスが適切に構成されていることを確認します。また、このスクリプトは起動時と停止時に、この時間間隔をログファイルに出力します。

#!/bin/sh
# Source utility functions.
if [[ -z $SG_UTILS ]]
then
    . /etc/cmcluster.conf
    SG_UTILS=$SGCONF/scripts/mscripts/utils.sh
fi

if [[ -f ${SG_UTILS} ]]; then
    . ${SG_UTILS}
    if (( $? != 0 ))
    then
        echo "ERROR: Unable to source package utility functions file: ${SG_UTILS}"
        exit 1
    fi
else
    echo "ERROR: Unable to find package utility functions file: ${SG_UTILS}"
    exit 1
fi

# Get the environment for this package through utility function
# sg_source_pkg_env().
sg_source_pkg_env $*

function validate_command
{
    typeset -i ret=0
    typeset -i i=0
    typeset -i found=0
    # check PEV_ attribute is configured and within limits
    if [[ -z PEV_MONITORING_INTERVAL ]]
    then
        sg_log 0 "ERROR: PEV_MONITORING_INTERVAL attribute not configured!"
        ret=1
    elif (( PEV_MONITORING_INTERVAL < 1 ))
    then
        sg_log 0 "ERROR: PEV_MONITORING_INTERVAL value ($PEV_MONITORING_INTERVAL) not within legal limits!"
        ret=1
    fi
    # check monitoring service we are expecting for this package is configured
    while (( i < ${#SG_SERVICE_NAME[*]} ))
    do
        case ${SG_SERVICE_CMD[i]} in
            *monitor.sh*) # found our script
                          found=1
                          break
                          ;;
                       *)
                          ;;
        esac
        (( i = i + 1 ))
    done
    if (( found == 0 ))
    then
        sg_log 0 "ERROR: monitoring service not configured!"
        ret=1
    fi
    if (( ret == 1 ))
    then
        sg_log 0 "Script validation for $SG_PACKAGE_NAME failed!"
    fi

    return $ret
}
function start_command
{
    sg_log 5 "start_command"

    # log current PEV_MONITORING_INTERVAL value, PEV_ attribute can be changed
    # while the package is running

    sg_log 0 "PEV_MONITORING_INTERVAL for $SG_PACKAGE_NAME is
$PEV_MONITORING_INTERVAL"

    return 0
}
function stop_command
{
    sg_log 5 "stop_command"
    # log current PEV_MONITORING_INTERVAL value, PEV_ attribute can be changed
    # while the package is running
    sg_log 0 "PEV_MONITORING_INTERVAL for $SG_PACKAGE_NAME is
$PEV_MONITORING_INTERVAL"
    return 0
}
typeset -i exit_val=0
case ${1} in
     start)
           start_command $*
           exit_val=$?
           ;;
     stop)
           stop_command $*
           exit_val=$?
           ;;
     validate)
           validate_command $*
           exit_val=$?
           ;;
     *)
           sg_log 0 "Unknown entry point $1"
           ;;
esac
exit $exit_val

アプリケーションと Serviceguard の統合についての詳細は、カスタマイズ可能なスクリプトのスイートが記載されているホワイトペーパー『 Framework for HP Serviceguard Toolkits』 を参照してください。このホワイトペーパーは、http://www.hp.com/go/softwaredepot から無償でダウンロードできる Serviceguard Developer’s Toolbox に含まれています。

外部スクリプトでの Serviceguard コマンドの使用

パッケージから実行する外部スクリプトで、Serviceguard コマンド (cmmodpkg など) を使うことができます。ただし、これらのコマンドで、パッケージそのものとデータをやり取りしてはなりません。

Serviceguard コマンドが他のパッケージとデータをやり取りする場合は、コマンドループが発生しないように注意してください。コマンドループが発生するのは次のような場合です。pkg1 が実行したスクリプトが pkg2 の cmmodpkg -d を実行し、pkg2 が実行したスクリプトが pkg1 の cmmodpkg -d を実行するとします。pkg1 と pkg2 が同時に起動されると、pkg1 スクリプトは pkg2 に対して cmmodpkg を実行しようとします。ところがこの cmmodpkg は、pkg2 の起動が完了しなければ実行できません。一方 pkg2 スクリプトも pkg1 に対して cmmodpkg を実行しようとしますが、同様に、pkg2 は pkg1 の起動が完了しなければ実行できないので、コマンドループが発生します。

このようなコマンドループが発生しないように、すべてのパッケージ (特に、外部スクリプトで Serviceguard コマンドを使うパッケージ) に run_script_timeout と halt_script_timeout を指定しておくとよいでしょう。タイムアウトの指定をしていないときに上記のようなコマンドループが発生すると、クラスタがハングするなど、望ましくない状況が発生する可能性があります。

パッケージ構成ファイルのパラメータ

パッケージ構成ファイルを編集する前に、以下の情報を収集し、各パッケージのワークシートに記入してください。各パラメータについての詳細は、「パッケージのパラメータの説明」を参照してください。また、次のようなコマンドを使うと、完全なパッケージ構成ファイルを生成し、出力することができます。

cmmakepkg -m sg/all $SGCONF/sg-all

package_name 

パッケージの名前。パッケージ名は、クラスタ内で重複してはいけません。この名前を使って、パッケージの起動、停止、修正、表示を行います。

パッケージ名に使用できる文字数は、1〜39 文字です。詳細は、第 6 章の「package_name」で説明しています。

package_type 

パッケージの種類です。このパラメータは、パッケージが同時に 1 つのノードでのみ動作するのか、または複数のノードで動作するかを示します。設定できる種類は、failover、multi_node、およびsystem_multi_node です。デフォルトはfailover です。system_multi_node パッケージは、Veritas Cluster File System (CFS) などの、当社が提供するアプリケーションでのみサポートされています。

構成テンプレートを編集して Veritas Cluster File System パッケージを作成しないでください。CFS をサポートしているシステムで、付録 A の CFS 管理コマンドを使ってください。「Veritas システムマルチノードパッケージの構成」と「Veritas マルチノードパッケージの構成」を参照してください。

node_name 

パッケージの一次ノードと代替ノードの名前。パッケージが実行できる各ノードの node_name を入力します。

ノード名を指定する順序は重要です。最初に一次ノード名 (パッケージを通常起動するノード) を指定してから、1 番目の引き継ぎノード名、2 番目の引き継ぎノード名、その他のノード名と、優先する順に指定します。フェイルオーバーでは、パッケージの制御はパッケージ構成ファイルで指定されている次の引き継ぎノードへ移行されます。そのノードが利用できないか、その時点でパッケージを実行できない場合は、リスト上のその次のノードへと順に選択されます。

クラスタ内のすべてのノードでパッケージを実行でき、順序は重要ではない場合は、node_name * と指定できます。

ノード名の長さは、最大 39 文字です。詳細は、第 6 章の「node_name」を参照してください。

auto_run 

auto_run にyes が設定されている場合、Serviceguard は、該当するノードが使用可能であればそのノードでパッケージを自動的に起動し、パッケージで障害が発生すると、別のノードへ自動的にフェイルオーバーします。auto_run にno が設定されている場合、Serviceguard はパッケージを自動的には起動しません。ユーザーが cmrunpkg コマンドを使って手動で起動する必要があります。

パッケージが起動されると、Package Switching フラグは auto_run の設定に合わせて設定されますが、cmmodpkg コマンドを使って、パッケージの実行中にこのフラグを変更することができます。

デフォルトは yes です。

node_fail_fast_enabled
  

このパラメータにyes を設定しておくと、以下のいずれかの事象が発生した場合に、Serviceguard は、制御スクリプトで障害が発生したノードで、システムを停止 (HP-UX システムのリセット) します。

  • パッケージのサブネットに障害が発生し、バックアップ用ネットワークが使用不能

  • EMS リソースに障害が発生した

  • Serviceguard が停止関数を実行できない

  • 起動または停止関数がタイムアウトした

注記: パッケージ停止関数が “exit 1” で異常終了した場合、Serviceguard はノードを停止させませんが、そのパッケージにno_restart を設定します。この設定によりパッケージ切り替え (auto_run) が無効になり、そのパッケージはどの引き継ぎノードでも実行されません。
設定可能な値は、yes とno です。デフォルトはno です。

run_script_timeout および halt_script_timeout
  

それぞれパッケージの起動および停止に許される時間を示します。タイムアウト値を指定し、その時間内にパッケージの起動またはシャットダウンが完了しなかった場合、Serviceguard は起動処理またはシャットダウン処理を終了します。詳細は、「run_script_timeout」を参照してください。

注記: VxVM ディスクグループはパッケージの実行時にインポートされ、パッケージの停止時にエクスポートされます。パッケージで多数の VxVM ディスクグループを使用している場合、タイムアウト値は、インポートやエクスポートがすべて完了するのに十分な大きさでなければなりません。

successor_halt_timeout
  

Serviceguard が、パッケージを停止する前に、このパッケージに依存しているパッケージが停止を待つ時間 (秒数) です。設定できる値は0〜4292、またはno_timeout です。

詳細は、第 6 章の「successor_halt_timeout」で説明しています。また、「パッケージの依存関係について」も参照してください。

script_log_file 

スクリプトログファイルには、パッケージの起動と停止の動作が記録されます。詳細は、第 6 章の「script_log_file」で説明しています。

log_level 

パッケージの検証時に stdout に出力される情報量と、パッケージの起動および停止時に「script_log_file」に出力される情報量を決定します。設定できる値は、 0〜5 です。詳細は、第 6 章の「log_level」で説明しています。

failover_policy 

パッケージマネージャが、フェイルオーバーパッケージを自動起動するノードを選択するために使用するポリシーです。

デフォルトはconfigured_node であり、パッケージマネージャは、そのパッケージのノード名リストに記述されている、次に使用可能なノードを選択します。選択される順序は、パッケージ構成ファイル内のノード名エントリーの順です。

デフォルト以外に、min_package_node というポリシーがあります。このポリシーを指定すると、パッケージマネージャは、実行中のパッケージが最も少ないノードを (このパッケージを実行できるノードのリストから) 選択します。

「パッケージの依存関係について」も参照してください。

failback_policy 

一次ノード (node_name リスト上の 1 番目のノード) がパッケージを実行できる状態であるにもかかわらず、フェイルオーバーパッケージが一次ノードで実行されていない場合のパッケージマネージャの動作を決定するポリシーです。

デフォルトはmanual で、パッケージが代替ノードで実行されていても、そのパッケージを一次ノードへ戻す動作は行われません。(これは、Serviceguard の以前のバージョンと同じ動作です。) デフォルト以外にautomatic というポリシーがあり、このポリシーを指定すると、一次ノードがパッケージを実行できる状態になるとすぐに、パッケージは停止され、一次ノードで再起動されます。ただしパッケージフェイルオーバー方針としてmin_package_node が設定されている場合は、現在のノードで実行中のパッケージの数より一次ノードで実行中のパッケージの数が少ない場合にのみフェイルバックされます。

「パッケージの依存関係について」も参照してください。

priority 

パッケージに優先順位を割り当てます。パッケージが、自分が依存している別のパッケージを別のノードに「ドラッグ」できるかどうかを判断するために使われます。「パッケージの依存関係について」を参照してください。

設定可能な値は、1〜3000、またはno_priority です。デフォルトはno_priority です。

優先順位を割り当てる場合は、クラスタ内で一意でなければなりません。小さい値ほど優先順位が高くなります。

値は 20 の倍数で指定して、序列内に隙間を残しておくことをお勧めします。そうしないと、新しいパッケージに優先順位を割り当てるときに、すべての既存の優先順位をふり直さなくてはならなくなることがあります。

詳細は、第 6 章の「priority」で説明しています。

(パッケージの依存関係)  

dependency_name (依存対象の一意の識別子)
dependency_condition <pkgname> = up
dependency_location same_node

詳細は、「パッケージの依存関係について」を参照してください。

local_lan_failover_allowed
  

設定できる値は、yes またはno です。このパラメータにyes を設定しておくと、LAN カードの障害が発生した場合に、Serviceguard はパッケージ IP アドレスを待機 LAN カードへ移動します。デフォルトはyes です。

monitored_subnet 

パッケージ用に監視する IP サブネットを指定します。

cluster_interconnect_subnet
  

Serviceguard Extension for Real Application Cluster (SGeRAC) がインストールされている場合だけ使います。詳細は、http://docs.hp.com/ja -> [ハイ アベイラビリティ] -> [Serviceguard Extension for Real Application Cluster (ServiceGuard OPS Edition)] にある、最新の『 Serviceguard Extension for RAC ユーザーガイド』を参照してください。

ip_subnet および ip_address
  

パッケージで使う IP サブネットと再配置可能 IP アドレスを指定します。

「定常 IP アドレスと再配置可能 IP アドレス」を参照してください。詳細は、第 6 章の「ip_subnet」で説明しています。

service_name 

各サービスの固有の名前です。

1 つのパッケージにつき最大 30 サービス、1 つのクラスタにつき最大 900 サービスを構成できます。サービス名に使用できる文字数は、最大 39 文字です。詳細は、第 6 章の「service_name」で説明しています。

各サービスに対し、service_name パラメータ、service_cmd パラメータ、service_restart パラメータ、service_fail_fast_enabled パラメータ、および service_halt_timeout パラメータを入力してください。

service_cmd 

service_name のアプリケーションやサービスを実行するコマンドです。詳細は、第 6 章の「service_cmd」で説明しています。

service_restart 

Serviceguard が service_cmd を再実行する回数です。設定できる値は、unlimited、none、または正の整数値です。

service_fail_fast_enabled
  

サービスごとに、サービスの障害をノードの障害として扱うかどうかを示します。設定できる値は、yes またはno です。

このパラメータをyes とした場合、サービスで障害が発生すると、Serviceguard はサービスが動作しているノードを停止させます (HP-UX システムのリセット)。(最初に、ノードをリブートしようとします。) デフォルトはno です。

service_halt_timeout
  

サービスが停止した場合、Serviceguard はまず、サービスを終了させるために SIGTERM シグナルを送信します。それでもプロセスが終了しない場合は、Serviceguard は指定されたタイムアウト時間待機した後、プロセスを強制終了させる SIGKILL シグナルを送信します。

サービスごとに service_halt_timeout を 1 つ定義します。値を指定しないと、Serviceguard はタイムアウトを設けません (0 秒)。最大値は、HP-UX のパラメータ ULONG_MAX でのみ制限され、絶対上限は 4,294 秒です。

resource_name 

Serviceguard がパッケージの依存対象として監視する Event Monitoring Service リソースの名前。

各 resource_name に対して、resource_polling_interval を 1 つ、resource_start 値を 1 つ、resource_up_value を 1 つ以上指定します。以降の項目と、「EMS リソースを構成するパラメータ」を参照してください。

リソースの一覧は、Serviceguard Manager ([構成] -> [パッケージの作成] -> [モニターするリソース] -> [使用可能な EMS リソース])、またはリソースモニターに付属しているドキュメントを参照してください。

1 つのクラスタにつき最大 60 個の EMS リソースを定義できます。後述する resource_up_value の上限にも注意してください。

resource_name に使用できる文字数は、最大 1024 文字です。

resource_polling_interval
  

構成したパッケージリソースを監視する時間間隔 (秒)。

デフォルトは 60 秒です。最小値は 1 です (実用上の最大値の制限はありません)。

resource_start 

Serviceguard によるリソースの監視を、パッケージの起動時に開始するか、ノードがクラスタに結合したときに開始するかを決定します。

「EMS リソースを構成するパラメータ」を参照してください。

resource_up_value
  

パッケージリソースが異常終了していないかどうかを判断する基準値。

1 つのパッケージにつき合計 15 個の resource_up_value を構成できます。たとえば、パッケージにリソース (resource_name) が 1 つしかない場合は、最大 15 個の resource_up_value を定義できます。2 つの resource_name が定義されていて、一方のリソースに 10 個の resource_up_value が定義されている場合は、もう一方の resource_name に定義できる resource_up_value は 5 個だけとなります。

resource_up_value 文字列の最大文字数は、1024 文字です。詳細は、第 6 章の「resource_up_value」で説明しています。

concurrent_vgchange_operations
  

パッケージの起動またはシャットダウン時にボリュームグループを同時にアクティブ化または非アクティブ化できる数を指定します。設定できる値は、0 より大きい任意の数です。デフォルトは1 です。パッケージが、多数の LAN ボリュームグループをアクティブ化する必要がある場合は、第 6 章の「concurrent_vgchange_operations」の説明を参照してください。

vgchange_cmd 

LVM ボリュームグループをアクティブ化する方法を指定します。詳細は、第 6 章の「vgchange_cmd」と、パッケージ構成ファイル内で説明しています。

cvm_activation_cmd
  

Veritas CVM ディスクグループをアクティブ化するコマンドを指定します (CVM をサポートしているシステムについては、「Symantec 社の Veritas CFS と CVM」を参照してください)。

詳細は、第 6 章の「cvm_activation_cmd」と、パッケージ構成ファイル内で説明しています。

vxvol_cmd 

ミラー化 VxVM ボリュームのミラー回復方法を制御します。

vg 

パッケージがアクティブ化する LVM ボリュームグループです。

cvm_dg 

パッケージが使う CVM ディスクグループです (CVM をサポートしているシステムについては、「Symantec 社の Veritas CFS と CVM」を参照してください)。

vxvm_dg 

パッケージがアクティブ化する Veritas VxVM ディスクグループです。

注記: VxVM ディスクグループでは、ユーザーがアクティブ化コマンドを選択することはできません。VxVM ディスクグループのアクティブ化では、必ず同じコマンドが使われます。
deactivation_retry_count
  

障害と見なすまでに、パッケージシャットダウンスクリプトがボリュームグループ (LVM) またはディスクグループ (VxVM、CVM) の非アクティブ化を試みる回数です。デフォルトは 0 です。

kill_processes_accessing_raw_devices
  

raw デバイスにアクセスしているプロセス (たとえば、データベースアプリケーション) をパッケージ停止スクリプトが抹消するかどうかを指定します。パッケージの停止時に raw デバイスにアクセスしているプロセスがあると、ボリュームグループまたはディスクグループの非アクティブ化に失敗し、パッケージが停止できなくなります。設定できる値は、yes とno です。

concurrent_fsck_operations
  

パッケージの起動時に、マウントするファイルシステムに対して同時に実行できる fsck 操作の数です。

設定できる値は、ゼロより大きい任意の数です。デフォルトは 1 です。

concurrent_mount_and_umount_operations
  

パッケージの起動または停止時に、同時に実行できる mount および umount の数を指定します。デフォルトは 1 です。パッケージが多数のファイルシステムをマウントする場合は、この値を大きくすることを検討してください。

fs_mount_retry_count
  

各ファイルシステムのマウント再試行回数です。デフォルトは 0 です。詳細は、第 6 章の「fs_mount_retry_count」で説明しています。

fs_umount_retry_count
  

パッケージのシャットダウン時に各ファイルシステムで試行するマウント解除の回数です。デフォルトはゼロです。

(論理ボリューム、ファイルシステム、およびマウントオプション)
  

起動時に 1 つ以上のストレージグループをアクティブ化し、ファイルシステムの論理ボリュームをマウントするように、パッケージを構成することができます。停止時に、スクリプトはファイルシステムをマウント解除し、各ストレージグループを非アクティブ化します。すべてのストレージグループは、各ターゲットノード上でアクセス可能でなければなりません。 (CVM をサポートしているシステムでは、CVM ディスクグループは、クラスタ内のすべてのノード上でアクセス可能でなければなりません。)

パッケージ構成ファイルで指定した各ファイルシステム (fs_name) に対して、論理ボリューム、マウントポイント、マウント、マウント解除、および fsck のオプションと、ファイルシステムのタイプを指定しなければなりません。例を次に示します。

fs_name /dev/vg01/lvol1

fs_directory /pkg01aa

fs_mount_opt "-o rw"

fs_umount_opt "-s"

fs_fsck_opt "-s"

fs_type "vxfs"

論理ボリュームは、LVM ボリュームグループ、Veritas VxVM ディスクグループ、または Veritas CVM ディスクグループ (CVM をサポートしているシステムの場合) 上に構築できます。論理ボリュームは、使用するストレージグループのタイプにかかわらず、任意の順で指定できます。

pev_ 

cmgetpkgenv (1m) コマンドで external_pre_script、external_script、またはその両方に渡すことができるパッケージ環境変数を指定します。詳細は、第 6 章の「pev_」で説明しています。

external_pre_script
  

パッケージの起動の際はボリュームグループとディスクグループがアクティブ化される前に、パッケージのシャットダウンの際はこれらのグループが非アクティブ化された後に実行される外部スクリプトの絶対パス名 (つまり、パッケージ起動の最初の手順と、パッケージシャットダウンの最後の手順) です。

詳細は、第 6 章の「external_pre_script」で説明しています。

external_script 

パッケージの起動の際は、IP アドレスが割り当てられた後、サービスが開始される前に実行され、パッケージのシャットダウンの際は、サービスが停止された後、IP アドレスが削除される前に実行される外部スクリプトの絶対パス名です。

詳細は、第 6 章の「external_script」で説明しています。

(アクセス制御ポリシー) 

パッケージに対して、パッケージ管理アクセスを構成することができます。このポリシーが、クラスタ構成ファイルで定義されているアクセスポリシーと矛盾したり、重複していないことを確認してください。詳細は、「セキュリティファイルの編集」を参照してください。

パッケージ構成のワークシート

次の例に示すように、パッケージごとにパッケージ構成データを 1 つのワークシートに集めます。(未記入のワークシートは、付録 F 「プランニングワークシート」にあります。) 

Package Configuration File Data:
==========================================================================

Package Name: ______pkg11____________Package Type:___Failover____________

Primary Node: ______ftsys9_______________ 

First Failover Node:____ftsys10_______________
Additional Failover Nodes:__________________________________

Run Script Timeout: _no_timeout_____ Halt Script Timeout: _no_timeout___

Package AutoRun Enabled?  __yes_____ Local LAN Failover Allowed?  ___yes__

Node Failfast Enabled?      ____no____
Failover Policy:__configured_node___ Failback_policy:____automatic____
_______________________________________________________________________
Additional Package Resource:

Resource Name:___________ Polling Interval_______ 
Start____________________Resource UP Value________
_______________________________________________________________________
Access Policies:
User:___any_user______ From node:___ftsys9____ Role:__package_admin____
User:___lee ron admn__ From node:__ftsys10__ Role:__package_admin____
_______________________________________________________________________
Log level__1__ Log file:_________________________________________________
_________________________________________________________________________
priority__no_priority________ Successor_halt_timeout____no_timeout
dependency_name _pkg12_____ dependency_condition _pkg12 = up__ 
dependency_location _same_node_
==========================================================================
LVM Volume Groups:

vg____vg01___________vg________________vg________________vg________________

vgchange_cmd: __"vgchange -a e"____________________________________________

CVM Disk Groups [ignore CVM items if CVM is not being used]:

cvm_vg___/dev/vx/dg01____cvm_dg_____________cvm_vg_______________

cvm_activation_cmd: ______________________________________________

VxVM Disk Groups:

vxvm_dg___/dev/vx/dg01____vxvm_dg____________vxvm_dg_____________
vxvol_cmd  ______________________________________________________
________________________________________________________________________________
Logical Volumes and File Systems:
fs_name___/dev/vg01/1v011___fs_directory____/mnt1______fs_mount_opt_"-o rw"___
fs_umount_opt_"-s"__________fs_fsck_opt__"-s"__________fs_type_"vxfs"
fs_name____________________fs_directory________________fs_mount_opt____________
fs_umount_opt_____________ fs_fsck_opt_________________fs_type_________________
fs_name____________________fs_directory________________fs_mount_opt____________
fs_umount_opt_____________ fs_fsck_opt_________________fs_type_________________
fs_mount_retry_count: ____________fs_umount_retry_count:___________________

Concurrent vgchange operations: ___________________________________________-
  
Concurrent mount/umount operations: ______________________________________

Concurrent fsck operations: ______________________________________________
Kill processes accessing raw devices?__no___
===============================================================================
Network Information:
IP ____15.13.171.14____ IP___________IP___________subnet ___15.13.168________
IP______________________IP____________IP___________subnet_______________________
Monitored subnet:_______________________________________________________________
Cluster interconnect subnet [SGeRAC only]:____________________________________
====================================================