クラスタの構成

ロックディスクの指定

2 台のノードから成るクラスタには、クラスタロックディスク、ロック LUN、またはクォーラムサーバーが必要です。クラスタロックは、すべてのノードからアクセス可能で、しかもこれらのノードとは別の電源で動作するものでなければなりません。詳細については、第 3 章の「クラスタロック」を参照してください。

ロックディスクを作成するには、クラスタ名の後ろに、ロックディスク情報を入力します。ロックディスクは、クラスタ内のすべてのノードからアクセスできる LVM ボリュームグループ内に存在しなければなりません。

cmquerycl で作成された ASCII 形式のテンプレートに記述されているデフォルトの FIRST_CLUSTER_LOCK_VG および FIRST_CLUSTER_LOCK_PV は、すべてのクラスタノードに接続されたディスクのボリュームグループ名と物理ボリューム名です。このようなディスクが複数ある場合は、フェイルオーバーの時間が最短になるものが選択されます。このディスクが電源配線の要件に合っていることを必ず確認し、 必要であれば電源を変更して、そのディスクの電源系統がクラスタ内の半数を超えるノードに電力を供給しないようにしてください。

ディスクのフェイルオーバー時間を表示するには、次のように、クラスタ内のすべてのノードを指定して cmquerycl コマンドを実行します。コマンドを実行すると、各ノードに接続されているディスクと、それぞれに対応する再編成時間の一覧が出力されます。

ノードの完全ドメイン名は指定しないでください。たとえば、次のように、ftsys9.cup.hp.com ではなく、ftsys9 と指定します。

cmquerycl -v -n ftsys9 -n ftsys10

cmquerycl では、現在クラスタに属しているボリュームグループの再編成時間は表示されません。 cmquerycl にボリュームグループの再編成時間を表示させたい場合には、vgchange -c n <vg name> を実行して、ボリュームグループからクラスタ ID をクリアしてください。作業が終わった後に、vgchange -c y vgname を実行して、クラスタ ID をボリュームグループに書き戻すのを忘れないでください。次に例を示します。

vgchange -c y /dev/vglock

	注記: 特別な構成が必要とされない限り、2 番目のロックボリュームグループまたは物理ボリュームを構成してはなりません。詳細は、第 3 章の「二重ロックディスク」の項を参照してください。

2 番目のクラスタロックを構成する必要がある場合には、クラスタ構成ファイルに次のパラメータを追加します。

SECOND_CLUSTER_LOCK_VG /dev/volume-group
SECOND_CLUSTER_LOCK_PV /dev/dsk/block-special-file

/dev/volume-group は 2 番目のボリュームグループの名前で、block-special-file はそのボリュームグループのロックディスクの物理ボリューム名です。上記の 2 行は、ノードごとに追加します。以下に例を示します。

SECOND_CLUSTER_LOCK_VG /dev/vglock
SECOND_CLUSTER_LOCK_PV /dev/dsk/c4t0d0 

または (柔軟なアドレッシングを使う場合については、「デバイスファイル名について (デバイス特殊ファイル)」を参照してください)

SECOND_CLUSTER_LOCK_VG /dev/vglock
SECOND_CLUSTER_LOCK_PV /dev/disk/disk100 

「クラスタロックディスクの選択」も参照してください。

ロック LUN の指定

2 台のノードから成るクラスタには、クラスタロックディスク、ロック LUN、またはクォーラムサーバーが必要です。ロックは、すべてのノードからアクセス可能で、しかもこれらのノードとは別の電源で動作するものでなければなりません。詳細は、「クラスタロック」と「ロック LUN の設定」を参照してください。

クラスタ構成ファイルでロック LUN を指定するには、次の例のように、各ノード名の後にロック LUN 情報を入力します。

NODE_NAME hasupt21
  NETWORK_INTERFACE lan1
    HEARTBEAT_IP 15.13.173.189
  NETWORK_INTERFACE lan2
  NETWORK_INTERFACE lan3
  CLUSTER_LOCK_LUN /dev/dsk/c0t1d1

クォーラムサーバーの指定

2 台のノードから成るクラスタには、クラスタロックディスク、ロック LUN、またはクォーラムサーバーが必要です。ロックディスクやロック LUN の代わりにクォーラムサーバーを指定するには、cmquerycl コマンドの -q オプションでクォーラムサーバーのホストサーバーを指定します。例を次に示します。

cmquerycl -n ftsys9 -n ftsys10 -q qshost

この場合に生成されるクラスタ構成ファイルには、クォーラムサーバーを定義するパラメータが入っています。ファイルのこの部分を次に示します。

# Quorum Server Parameters. Use the QS_HOST, QS_POLLING_INTERVAL,
# and QS_TIMEOUT_EXTENSION parameters to define a quorum server.
# The QS_HOST is the host name or IP address of the system
# that is running the quorum server process.  The 
# QS_POLLING_INTERVAL (microseconds) is the interval at which
# The optional QS_TIMEOUT_EXTENSION (microseconds) is used to increase
# the time interval after which the quorum server is marked DOWN.
#
# The default quorum server interval is calculated from the
# Serviceguard cluster parameters, including NODE_TIMEOUT and
# HEARTBEAT_INTERVAL. If you are experiencing quorum server
# timeouts, you can adjust these parameters, or you can include
# the QS_TIMEOUT_EXTENSION parameter.
#
# For example, to configure a quorum server running on node
# "qshost" with 120 seconds for the QS_POLLING_INTERVAL and to
# add 2 seconds to the system assigned value for the quorum server
# timeout, enter:
#
# QS_HOST qshost
# QS_POLLING_INTERVAL 120000000
# QS_TIMEOUT_EXTENSION 2000000

QS_HOST、QS_POLLING_INTERVAL を入力し、オプションでQS_TIMEOUT_EXTENSION も入力してください。

ハートビートサブネットの識別

クラスタ構成ファイルには、ハートビートサブネット上の IP アドレスのエントリーが含まれています。専用のハートビートサブネットを使用することをお勧めします。また、他のサブネット (データサブネットを含む) 上にもハートビートを構成することをお勧めします。

ハートビートは IPv4 サブネット上に設定し、IPv4 アドレスを用いる必要があります。IPv6 によるハートビートは、サポートされていません。

	注記: Veritas CVM バージョン 3.5 のディスクグループを使用している場合には、専用のサブネットを使用したハートビートサブネットを 1 つしか構成できません。高可用性ハートビートパスを確保するために、このサブネット上の各システムには予備の LAN が構成されていなければなりません。 バージョン 4.1 以降では、複数のハートビートを使うことができるため、複数のハートビートを構成するか、待機 LAN のある単一のハートビートを構成する必要があります。 CVM はすべてのシステムでサポートされているわけではありません。「Symantec 社の Veritas CFS と CVM」を参照してください。

構成できるパッケージの最大数を指定する

クラスタに構成できるパッケージの最大数を指定します。

パラメータの値は、クラスタに現在構成されているパッケージ数以上の値でなければなりません。この数には、すべての種類のパッケージ (フェイルオーバーパッケージ、マルチノードパッケージ、システムマルチノードパッケージ) が含まれます。

Serviceguard A.11.17 では、デフォルトは 150 です。これがクラスタに許されるパッケージの最大数です。

	注記: 各ノード上の HP-UX カーネルパラメータを調整して、そのノード上で同時に実行されるパッケージの最大数を上回る値を設定してください。

クラスタのタイミングパラメータの変更

cmquerycl コマンドは、HEARTBEAT_INTERVAL と NODE_TIMEOUT に対してクラスタのデフォルトのタイミングパラメータを設定します。これらのパラメータを変更することにより、クラスタの再編成とフェイルオーバー回数が直接影響を受けます。システム負荷が非常に大きい、またはネットワークのデータ通信量が過剰なために時々クラスタの再編成が発生する場合は、これらのパラメータの変更が有効です。この変更は、クラスタが稼働しているときに行うことができます。

NODE_TIMEOUT のデフォルト値 (2 秒) を使用することにより、フェイルオーバー時間は最適時間の 30 秒となります。NODE_TIMEOUT を 10 秒に変更すると、クラスタマネージャはノードのタイムアウトまで 5 倍長く待つことになり、フェイルオーバー時間も 5 倍 (約 150 秒) に増加します。NODE_TIMEOUT は、少なくとも 2*HEARTBEAT_INTERVAL でなければなりません。大体の目安として、NODE_TIMEOUT 時間の間に 2〜3 回のハートビートが送られるように設定します。ノードのタイムアウトについての詳細は、「ノードがタイムアウトしたときの動作」を参照してください。

最適化

Serviceguard Extension for Faster Failover (SGeFF) は、別途購入する必要がある製品です。SGeFF をインストールすると、この機能を有効にするためのパラメータが構成ファイルに追加されます。

SGeFF を使うと、Serviceguard がフェイルオーバーを処理するのに要する時間が短縮されます。ただし、パッケージやアプリケーションが安全にシャットダウンして再起動するのに要する時間は変わりません。

クラスタ構成テンプレートファイルで概要が説明されているように、SGeFF ではクラスタ構成に関する必要条件があります。

詳細は、『HP Serviceguard Extension for Faster Failover リリースノート』を参照してください。このドキュメントは、http://docs.hp.com/ja -> [ハイ アベイラビリティ] にあります。

また、『Optimizing Failover Time in a Serviceguard Environment』 も参照してください。このホワイトペーパーは、http://docs.hp.com -> [High Availability] -> [Serviceguard] -> [White Papers] にあります。

アクセス制御ポリシー

アクセス制御ポリシーを使うと、非ルートユーザーが通常の管理コマンドを使用できるようになります。

非ルートユーザーが、グラフィカルユーザーインタフェースである Serviceguard Manager を使って、Serviceguard クラスタやパッケージを表示したり管理するためには、アクセスポリシーが設定されている必要があります。新しく構成を作成したときには、少なくとも 1 つの Monitor アクセスポリシーをすぐに設定することをお勧めします。

文字列 (特にANY_USER やCLUSTER_MEMBER_NODE などのワイルドカード) を入力する際には、つづりを確認してください。つづり間違いがあると、個別のユーザーやノードであると判断され、意図したアクセスポリシーが構成されないことになります。

クラスタのルートユーザーは、クラスタが稼働中でもアクセスポリシーの作成や変更を行うことができます。

詳細は、「アクセスロール」と「セキュリティファイルの編集」を参照してください。

ボリュームグループの追加

構成した LVM ボリュームグループを、ASCII 形式のクラスタ構成ファイルに追加します。クラスタ内で使用されるクラスタ対応のボリュームグループごとに、VOLUME_GROUP パラメータを記述します。これらのボリュームグループは、cmapplyconf コマンドを実行したときに、クラスタ ID を使用して初期化されます。さらに、ボリュームグループをアクティブ化する各パッケージ制御スクリプトへ、適切なボリュームグループ、論理ボリューム、およびファイルシステムの情報を追加する必要があります。この処理については、第 6 章で説明します。

	注記: CVM ディスクグループを使用している場合、クラスタの構成後に「Veritas Cluster Volume Manager (CVM) による記憶領域インフラストラクチャとファイルシステムの作成」の手順を使用して、これらのディスクグループを構成する必要があります。Veritas ディスクグループは、第 6 章で説明しているようにパッケージ制御ファイルに追加されます。CVM はすべてのシステムでサポートされているわけではありません。「Symantec 社の Veritas CFS と CVM」を参照してください。

クラスタ構成の確認

クラスタ構成ファイルをコマンド行で編集した場合は、ファイルの内容を確認するために次のコマンドを使用します。

cmcheckconf -k -v -C /etc/cmcluster/clust1.config

以下の項目が確認されます。

クラスタがオンラインの場合は、構成上の個々の変更が条件を満足しているかどうかも確認されます。

	注記: -k オプションを使用した場合、cmcheckconf は ASCII 形式の構成ファイルで指定されている LVM ディスクへの接続だけをチェックします。-k オプションを使用しない場合 (デフォルト動作) は、cmcheckconf はすべてのノード上のすべての LVM ディスクの接続をチェックします。-k を使用すると、コマンドの動作が非常に速くなります。

バイナリ構成ファイルの配布

クラスタのパラメータをすべて指定した後、構成を適用します。この作業により、クラスタ内のすべてのノードに対してバイナリ構成ファイルが配布されます。この作業は、パッケージを構成する以前に、あらかじめ済ませておくとよいでしょう (次章を参照)。このようにすると、稼働中のクラスタに対して cmviewcl コマンドを実行して、クラスタロック、ハートビートネットワーク、その他のクラスタレベルの動作を確認できます。構成を配布する前に、クラスタノード間でセキュリティファイルのコピーが許可されていることを確かめておきます。詳細については、本章冒頭の 「システムの準備」を参照してください。

以下の手順に従ってバイナリ構成ファイルを作成し、クラスタ内の全ノードに配布します。

cmapplyconf コマンドを実行すると、バイナリ形式のクラスタ構成ファイルが作成され、クラスタ内の全ノードに配布されます。これにより、全ノードが同じ内容の構成ファイルを持つことができます。ただし cmapplyconf コマンドでは、ASCII 形式の構成ファイルは配布されません。

	注記: 適用前に、クラスタロックボリュームグループが 1 台のノードだけでアクティブになっていないと、適用は完了しません。ただし、この規則には例外が 1 つあります。クラスタロックが、適用前と同じ物理ボリュームとボリュームグループで構成された場合です。 構成を適用したら、クラスタロックボリュームグループを非アクティブ化する必要があります。

ボリュームグループとクラスタロックの構成データの保存

クラスタを構成したら、作成したボリュームグループごとに vgcfgbackup コマンドを実行して、LVM ボリュームグループ構成のバックアップコピーを作成します。このようにしておくと、ボリュームグループ内でディスクの交換が必要なときに、vgcfgrestore コマンドを使ってそのディスクのメタデータを復元できます。手順については、第8章 「クラスタのトラブルシューティング」の「ディスクの交換」を参照してください。

すべてのボリュームグループ (特に、クラスタロックボリュームグループ) に対して vgcfgbackup を使用してください。

	注記: System Management Homepage (SMH)、SAM、HP-UX コマンドのいずれを使ってボリュームグループを作成した場合でも、クラスタロックディスクの構成データのバックアップ作成には vgcfgbackup コマンドを使用します。 クラスタ稼働中にロックディスク交換の必要が生じた場合は、vgcfgrestore コマンドを使用して、交換後のディスクにロック情報を復元します。このようにしておかなければ、ロックディスクの冗長コピーのすべてに障害が発生し、交換した機構または LUN にロック構成を復元できない場合に、障害がクラスタ全体に及ぶおそれがあります。(クラスタロックディスクがディスクアレイに構成されている場合、RAID 保護機能によってクラスタロックデータの冗長性が確保されます。Mirrordisk/UX は、クラスタロック情報をミラー化しません。)