システムの準備

Serviceguard は、HP-UX に組み込まれている名前解決サービスを使います。名前解決は、DNS や NIS サービスだけに依存するのではなく、最初に各ノードの /etc/hosts ファイルで解決するように定義することをお勧めします。

たとえば、2 つのプライベートサブネットと 1 つのパブリックサブネットを持つ 2 ノード (gryf と sly) のクラスタがあるとします。プライベートサブネットを共有していない非クラスタノード (bit) にこれらのノードへのアクセスを許可するとします。両方のクラスタノード上の /etc/hosts ファイルには、以下の内容が含まれていなければなりません。

15.145.162.131  gryf.uksr.hp.com    gryf 
10.8.0.131      gryf.uksr.hp.com    gryf 
10.8.1.131      gryf.uksr.hp.com    gryf

15.145.162.132  sly.uksr.hp.com     sly 
10.8.0.132      sly.uksr.hp.com     sly 
10.8.1.132      sly.uksr.hp.com     sly 

15.145.162.150  bit.uksr.hp.com     bit 

	注記: Serviceguard は、完全修飾ドメイン名 (上記の例のように、4 つの要素をピリオドで区切った名前) のうち、ホスト名部分 (最初の要素) だけを認識します。そのため、たとえば、2 つのノード gryf.uksr.hp.com と gryf.cup.hp.com は、同じホスト gryf として扱われるため、同じクラスタ内には存在できません。

アプリケーションで、ホスト名の別名を使う必要がある場合は、Serviceguard ホスト名は、別名の 1 つである必要があります。以下に例を示します。

15.145.162.131   gryf.uksr.hp.com    gryf  node1
10.8.0.131       gryf2.uksr.hp.com   gryf 
10.8.1.131       gryf3.uksr.hp.com   gryf

15.145.162.132   sly.uksr.hp.com     sly   node2
10.8.0.132       sly2.uksr.hp.com    sly 
10.8.1.132       sly3.uksr.hp.com    sly 

	注記: ネームサービススイッチは、DNS、NIS、LDAP などのサービスを参照する前に /etc/hosts ファイルを参照するように構成します。設定方法については、「名前解決サービスの定義」を参照してください。

Serviceguard は、identd デーモンを使って、ネットワーク接続の要求元のユーザー名を検証します。通常、このデーモンは、/etc/inetd.conf の設定に従って inetd から起動されます。Serviceguard デーモンが identd デーモンに接続できない場合、要求は拒否されます。

Serviceguard が、リモートユーザーをリモートノードのルートユーザーと見なすためには、identd がユーザー名 “root” を返さなければなりません。identd は、最初に一致した UID 0 のユーザー名を返すため、各ノードの /etc/passwd 内の root ユーザーのエントリーは、UID が 0 の他のエントリーより前に記述する必要があります。

identd を無効にする場合は、identd を使わないように Serviceguard を構成することができます。

	注意: この設定はお勧めしません。詳細は、ホワイトペーパー『 Securing Serviceguard』 を参照してください。このホワイトペーパーは、http://docs.hp.com -> [High Availability] -> [Serviceguard] -> [White Papers] にあります。

identd を無効にする必要がある場合は、/etc/inetd.conf 内の tcp hacl-cfg コマンドと hacl-probe コマンドに -i オプションを追加します。

以下に例を示します。

パッケージ構成とクラスタ構成でロールに矛盾があると、パッケージの構成が失敗します。そのため、パッケージのロールを作成するときには、クラスタ構成ファイルを参照することをお勧めします。クラスタ構成ファイルのリストを出力するには、cmgetconf を使います。

ユーザー名またはホスト名に対してクラスタ構成ファイルでロールが構成されている場合、パッケージ構成ファイルでは同じユーザー名またはホスト名に対してロールを指定しないでください。また、クラスタとそのパッケージの管理に対する完全な制御権をすでに持っているクラスタルートユーザーに、パッケージ管理ロールを割り当てても意味はありません。

Serviceguard では、ノードがクラスタに構成されているかどうかに応じて、アクセス制御のために使われるメカニズムが異なります。次の 2 つの項では、これら 2 つのケースでアクセス制御ポリシーを構成する方法について説明します。

Serviceguard を初めてシステムにンストールしたときは、アクセス制御ポリシーは定義されていません。このシステムをクラスタのメンバーにするためには、他のすべてのクラスタノードのルートユーザーに対して、そのノードへのルートアクセスを許可する必要があります。そのためのメカニズムが、$SGCONF/cmclnodelist です。このファイルはデフォルトでは存在しませんが、次の項の説明に従って作成する必要があります。

cmclnodelist ファイルは、新規インストールの際にはデフォルトでは作成されません。このファイルを作成するときには、ファイルの先頭に次のようなコメントを追加することをお勧めします。

###########################################################
# Do not edit this file!
# Serviceguard uses this file only to authorize access to an 
# unconfigured node. Once a cluster is created, Serviceguard  
# will not consult this file.
###########################################################

cmclnodelist ファイル内のエントリーの形式は、次のとおりです。

[hostname or IP address] [user] [#Comment]

例を次に示します。

gryf  root     #cluster1,node1
gryf  user1    #cluster1,node 1

sly   root     # cluster1, node2
sly   user1    #cluster1, node 2

bit   root     #Administration/COM Server

ルートアクセスが可能なユーザーは、すべてのクラスタ構成コマンドを使うことができます。ルートアクセスを持たないユーザーには、モニターロールが割り当てられ、ノードの構成に対する読み取り専用アクセスが許可されます。この例では、ノード gryf、sly、bit 上のルートユーザーは、この cmclnodelist ファイルがあるノードに対してルートの権限を持ちます。非ルートユーザー user1 は、ノード gryf と sly からこのノードに接続すると、モニターロールが割り当てられます。

Serviceguard は、cmclnodelist ファイルでの “+” の使用も認めています。この指定は、任意のノード上の任意のルートユーザーがこのノードを構成でき、任意の非ルートユーザーがモニターロールを持つことを示します。

	注記: $SGCONF/cmclnodelist が存在しないと、Serviceguard は ~/.rhosts を参照します。cmclnodelist を使うことを強くお勧めします。

ノードをクラスタに構成すると、クラスタ全体のセキュリティはアクセス制御ポリシーで決まります。cmclnodelist への変更は無視されます。各クラスタノードのルートユーザーは、自動的に他のノードへのルートアクセスが許可されます。その他のユーザーには、非ルートロールが与えられます。

	注記: クラスタ外のシステムのユーザーが、クラスタノードに対してルートの権限を持つことはできません。

クラスタのアクセス制御ポリシーは、クラスタ構成ファイルで定義し、特定のパッケージのアクセス制御ポリシーは、パッケージ構成ファイルで定義します。ホストとユーザーの任意の組み合わせに対して、クラスタのロールを割り当てることができます。クラスタあたり最大 200 のアクセスポリシーが定義できます。

アクセスポリシーは、構成ファイル内で以下の 3 つのパラメータを使って定義します。

	注記: アクセス制御ポリシーを構成/変更するために、クラスタまたはパッケージを停止する必要はありません。

アクセス制御ポリシーの例を示します。

USER_NAME john
USER_HOST bit
USER_ROLE PACKAGE_ADMIN

このポリシーがクラスタ構成ファイルで定義されている場合には、ユーザー john に対して、ノード bit のすべてのパッケージの PACKAGE_ADMIN ロールが与えられます。また、PACKAGE_ADMIN には MONITOR が含まれているため、ユーザー john にはクラスタ全体の MONITOR ロールも与えられます。

このポリシーが PackageA のパッケージ構成ファイルで定義されている場合には、ノード bit のユーザー john に対して、PackageA だけについての PACKAGE_ADMIN ロールが与えられます。

衝突するロールを構成することは許されていません。衝突するロールを指定すると、Serviceguard は構成を適用する際にエラーで失敗します (ただし、ワイルドカードは例外です。衝突するロールを指定すると、ANY_USER と john に異なるロールを与えることができます)。

たとえば、以下のエントリーをクラスタ構成ファイルに指定したとします。

# Policy 1:
USER_NAME john
USER_HOST bit
USER_ROLE PACKAGE_ADMIN

# Policy 2:
USER_NAME john
USER_HOST bit
USER_ROLE MONITOR

# Policy 3:
USER_NAME ANY_USER
USER_HOST ANY_SERVICEGUARD_NODE
USER_ROLE MONITOR

この例では、ユーザー john に 2 つのロールを割り当てているため失敗します (いずれにしても、PACKAGE_ADMIN には MONITOR ロールがすでに含まれているため、Policy 2 は不要です)。

ワイルドカード ANY_USER にはユーザー john が含まれていますが、Policy 3 は他のポリシーとは衝突しません。

	注記: ANY_SERVICEGUARD_NODE へのアクセスを許可する場合は、慎重に行ってください。この設定を行うと、サブネット上の任意のノードからのアクセスが有効になります。

クラスタのロールを計画したら、できるだけ早めに検証してください。組織のセキュリティポリシーで許可されている場合は、グループログインを作成する方が簡単な場合があります。たとえば、ANY_CLUSTER_NODE のユーザー operator1 に MONITOR ロールを割り当てます。そして、このログイン名とパスワードを、クラスタを監視するすべての人に知らせることができます。

ここでは、信頼性の高い名前解決構成を作成し、DNS サービスや NIS サービスが障害になっても、クラスタノード同士が通信を続けられるようにする方法について説明します。待機 LAN が構成されている場合は、このアプローチにより、プライマリ LAN が障害になっても、(cmrunnode や cmruncl などのコマンドも含め) クラスタは完全に機能し続けることができます。

	注記: NIC が障害になると、ノードがクラスタ内で動作している限り、影響のあるノードは待機 LAN にフェイルオーバーすることができます。しかし、影響のあるノードがクラスタ内で動作していないときに Serviceguard が使っている NIC が障害になると、Serviceguard はノードを再起動することができません (障害になった NIC を交換する方法については、「LAN カードまたは Fibre Channel カードの交換」を参照してください)。

クラスタを構成し、クラスタロック ボリュームグループおよび物理ボリュームを作成した後、各ロックボリュームグループ上のボリュームグループ構成データのバックアップを取る必要があります。構成した各ロックボリュームグループに対して vgcfgbackup コマンドを使用して、ディスク障害後に vgcfgrestore コマンドでロック構成を新しいディスクに復元できるように、ファイルをバックアップします。

	注記: ロックボリュームグループをどのように作成したかによらず、ロックボリュームグループ構成データのバックアップと復元には、vgcfgbackup コマンドと vgcfgrestore コマンドを使用しなければなりません。

idisk ユーティリティを使うと、HP Integrity サーバーだけからなるクラスタ内に、ロック LUN 用のパーティションを作成できます。以下の手順に従ってください。詳細は、idisk (1m) のマンページを参照してください。この手順は、このロック LUN を使うクラスタ内のノードのいずれかで実行してください。

	注意: 手順を開始する前に、パーティションに分割するディスクまたは LUN 上に、必要なデータがないことを確認してください。idisk は、既存のデータをすべて破棄します。

cmquerycl -L を使って、ロック LUN を定義するクラスタ構成ファイルを作成します。

これらのコマンドは、構成ファイルを作成します。その構成ファイルは、適用準備が整った時点でクラスタ構成に適用することができます。「バイナリ構成ファイルの配布」を参照してください。また、「ロック LUN の指定」を参照してください。

	注意: クラスタ構成ファイル内にロック LUN を指定した後は、cmapplyconf を実行すると、LUN 上にあるデータが破壊されます。

cmquerycl や cmapplyconf を使用するときには、クォーラムサーバーが稼働していなければなりません。

デフォルトでは、クォーラムサーバーのランタイムメッセージは stdout と stderr に書き込まれます。/var/adm/qs ディレクトリを作成して、stdout と stderr をこのディレクトリ内のファイル (たとえば /var/adm/qs/qs.log) にリダイレクトすることをお勧めします。

クォーラムサーバーを起動するためには、ルートのパーミッションが必要です。単独のシステムでは、インストール先のシステムが再スタートまたはリブートしたときにクォーラムサーバーが常に起動されるように構成してください。このように構成するには、次のようなエントリーを、/etc/inittab ファイルに追加します。

qs:345:respawn:/usr/lbin/qs >> /var/adm/qs/qs.log 2>&1

次のコマンドで、クォーラムサーバーを起動します。

init q

コマンドが完了すると、プロンプトが表示されます。

qs.log ファイルをチェックして、クォーラムサーバーが実行されていることを確認してください。

cat /var/adm/qs/qs.log

クォーラムサーバーが起動したことを示す次のようなエントリーが、このログファイルに記録されます。

Oct 04 12:25:06:0:main:Starting Quorum Server
Oct 04 12:25:09:0:main:Server is up and waiting for connections at port 1238

クォーラムサーバーの動作についての詳細は、「スプリットブレインの問題を回避するクラスタ定足数」を参照してください。また、 cmquerycl コマンドを使ってクラスタ構成ファイル内にクォーラムサーバーを指定する方法については、「クォーラムサーバーの指定」の項を参照してください。

詳細は、http://docs.hp.com/ja> -> [ハイ アベイラビリティ] -> [Quorum サーバ] にある、ご使用のバージョンの Quorum Server のリリースノートを参照してください。

以下の手順では、物理ボリュームグループを使って個々のディスクをミラー化し、各論理ボリュームが異なる I/O バス上のディスクにミラー化されるようにします。これは PVG 限定のミラー化と呼ばれる手法です。ミラーコピーとして使用するディスクは、一次コピーが使用するバスとは別のバスにより、各ノードに接続されているものとします。

LVM の使用の詳細については、『HP-UX システム管理者ガイド: 論理ボリュームの管理』を参照してください。

System Management Homepage を使って、ボリュームグループの作成や拡張を行ったり、論理ボリュームを作成することができます。System Management Homepage から、[Disks and File Systems] を選択します。必ず PVG 限定の割り当てを使ってミラー化された論理ボリュームを作成してください。

論理ボリュームを作成し、ボリュームグループの作成または拡張を終えたら、ボリュームグループにマウントするファイルシステムを指定し、「ボリュームグループの非アクティブ化」の項に進みます。

コマンド行からボリュームグループを構成するには、以下のようにします。

ボリュームグループがセットアップされていない場合は、以下の手順でセットアップしてください。LVM の構成をすでに行っている場合は、「クラスタの構成」の項に進んでください。

両方のノード上のディスクのリストを取得して、両方のノード上で同じディスクに対して使用されているデバイスファイルを確認します。次に、各ノードで以下のコマンドを実行して、各システムで定義されている使用可能なディスクのリストを取得します。

lssf /dev/d*/*

次の例では、/dev/rdsk/c1t2d0 と /dev/rdsk/c0t2d0 が、ftsys9 と ftsys10 のそれぞれで同じディスクに対するデバイス名として用いられています。ノードによってデバイスファイル名が異なる場合は、 デバイスファイル名の対応関係に注意してください。

	注記: 柔軟なアドレッシングの下では、以下の例の物理デバイスの名前は、/dev/rdisk/disk1 および /dev/rdisk/disk2 のようになります。「デバイスファイル名について (デバイス特殊ファイル)」を参照してください。

構成ノード (ftsys9) 上で、pvcreate コマンドを使用して、ディスクを物理ボリュームとして定義します。この作業は、構成ノードでのみで行います。以下は、この例で使用している 2 つの物理ボリュームを作成するコマンドを示しています。

pvcreate -f /dev/rdsk/c1t2d0
pvcreate -f /dev/rdsk/c0t2d0

PV 限定ミラー化の使用: 以下の手順に従って、構成ノード (ftsys9) 上でボリュームグループを作成します。その後、他のノード上に同じボリュームグループを作成します。

論理ボリュームの作成: 論理ボリュームを作成するには、次のコマンドを使用します。(例では /dev/vgdatabase の論理ボリューム)

lvcreate  -L 120 -m 1 -s g /dev/vgdatabase

このコマンドは、lvol1 という 120MB のミラー化ボリュームを作成します。このボリューム名は、コマンドでボリューム名が省略されたときのデフォルトのボリューム名です。-s g オプションは、ミラー化が PVG 限定であること (データのミラーコピーが異なる物理ボリュームグループにあること) を示します。

	注記: RAID 1 モードまたは RAID 5 モードでディスクアレイを使用している場合は、-m 1 オプションと-s g オプションを省略してください。

ファイルシステムの作成: インスタレーションでファイルシステムを使用する場合は、ファイルシステムを作成します。次のコマンドを使用して、作成した論理ボリュームにマウントするファイルシステムを作成します。

他のノードへのボリュームグループの配布: クラスタデータ用のボリュームグループを作成した後、作成したボリュームグループをアクティブ化するクラスタノードがそのボリュームグループを使用できるように、ボリュームグループを配布します。クラスタロックボリュームグループは、すべてのノードが使える状態にする必要があります。

ボリュームグループの非アクティブ化: ボリュームグループを作成した時点で、そのボリュームグループは、構成ノード (ftsys9 など) 上でアクティブになっています。次のステップは、ファイルシステムをアンマウントし、ボリュームグループを非アクティブ化することです。ftsys9 の場合の例を示します。

umount /mnt1 
vgchange -a n /dev/vgdatabase

	注記: この手順は、この設定作業でのみ実行し、アクティブ化とマウントが、実行時にパッケージ制御スクリプトによって実行されるようにします。マップファイルを作成するためだけにボリュームを非アクティブ化してアンマウントする必要はありません (以下の手順の手順 1 のように)。

ボリュームグループの配布: 同じボリュームグループを他のクラスタノード上にセットアップするには、次のコマンドを使用します。この例のコマンドでは、ftsys10 に新しいボリュームグループをセットアップして、ftsys9 で使用可能であった物理ボリュームを使用できるようにします。セットアップする手順は、そのボリュームグループのパッケージを実行する各ノードごとに個別に行います。

ftsys10 上にボリュームグループをセットアップするには、以下の手順に従います。

物理ボリュームグループのファイルの一貫性: 個々のミラー化ディスクに対して物理ボリュームグループを使用していない場合は、次項へ進んでください。

Serviceguard のクラスタでは、ノードのサブセットにより、アクティブ化するボリュームグループが異なる場合があります。また、ノードによっては同じディスクに別の物理ボリューム名を付けている場合もあります。このため、個々のノード自身のプライベートな (クラスタが認識していない) ディスクだけではなく、クラスタが認識している他ノードのディスクを含むすべてのディスクを各ノードがまったく同様に認識できるように、全ノード上の /etc/lvmpvg ファイルを正しくマージする必要があります。ファイルのマージを容易にするために、物理ボリュームグループ名は必ずボリュームグループプランニングワークシート (第4章 「HA クラスタのプランニングと文書化」参照) に詳しく記録しておいてください。

以下の手順に従って、構成ノード (ftsys9) のファイルとボリュームグループをインポートするノード (ftsys10) のファイルをマージします。