test

Sun Cluster 2.2 のシステム管理

パート III 技術リファレンス

ボリュームマネージャの管理

この付録では、Solstice DiskSuite のディスクセットとメタデバイス、および Sun StorEdge Volume Manager と Cluster Volume Manager のオブジェクトを管理する方法について説明します。この付録に示す作業は、ボリューム管理ソフトウェアによって異なります。

この付録で説明する手順は次のとおりです。

Sun Cluster 環境での Solstice DiskSuite の使用

この節では、Solstice DiskSuite による次に示すデバイスの管理について説明します。

Solstice DiskSuite オブジェクトの管理についての詳細は、Solstice DiskSuite のマニュアルを参照してください。

メタデバイスとディスクセットの管理

メタデバイスとディスクセットは、Solstice DiskSuite のコマンド行ユーティリティ、または DiskSuite Tool (metatool(1M)) の GUI を使用して管理します。

Solstice DiskSuite のマニュアルを使用して Sun Cluster 構成内のディスクセットとメタデバイスを管理する場合は、あらかじめこの章の情報に目を通してください。

ディスクセットは、ディスクをグループにしたものです。ディスクセットの主な管理作業として、ディスクの追加と削除が挙げられます。

ディスクセットに含めたディスクを使用する前に、そのディスクのスライスを使用するメタデバイスを設定する必要があります。メタデバイスは、連結、ストライプ、ミラー、UFS ロギングデバイス (トランスデバイスとも呼ばれる) のどれかです。また、メタデバイスにエラーが発生した場合に代替デバイスとして機能する、スライスを含むホットスペアプールを作成することもできます。

注 -

メタデバイス名は、d から始まり、その後に番号が続きます。Sun Cluster 構成のデフォルトでは、128 (0 〜 127) の一意のメタデバイスが存在します。ユーザーが作成する各 UFS ロギングデバイスは、少なくても 7 つのメタデバイス名を使用します。したがって、大規模な Sun Cluster 構成では、128 を超えるデフォルトメタデバイス名が必要になることもあります。デフォルトの数を変更する方法については、Solstice DiskSuite のマニュアルを参照してください。ホットスペアプール名は、hsp で始まり、その後に番号が続きます。使用できるホットスペアプールは、最高 1000 (hsp000 〜 hsp999) です。

ディスクセットについて

この節では、ディスクセットの概要、ディスクセットと論理ホストとの関係の概要、論理ホストに対応するディスクセットにディスクの追加と削除を行う方法について説明します。

Sun Cluster の論理ホストは、物理ホストにマスターされます。論理ホストのディスクセットにアクセスできるのは、論理ホストをマスターしている物理ホストだけです。物理ホストが論理ホストのディスクセットをマスターする場合、そのディスクセットの所有権があると言います。ディスクセットの所有権は、通常、Sun Cluster によって管理されます。しかし、論理ホストが保守状態 (hastat(1M) コマンドで報告される) の場合は、DiskSuite の metaset -t コマンドを使用して、ディスクセットの所有権を手動で取得できます。論理ホストをサービスに戻す前に、metaset -r コマンドを使用してディスクセットの所有権を解放してください。

注 -

論理ホストが稼動している場合は、metaset(1M) コマンドの -t (所有権を取得する) または -r (所有権を解放する) オプションによるディスクセット管理は行わないでください。これらのオプションは Sun Cluster ソフトウェアによって内部的に使用され、クラスタノード間で調整されるべきものです。

ディスクセットへのディスクの追加

ディスクセットに追加されるディスクがサブミラーとして使用される場合、ミラー化が行えるように、2 台の多重ホストディスク拡張装置で 2 つのディスクが使用できるようにする必要があります。ただし、ディスクがホットスペアとして使用される場合は、単一のディスクを追加できます。

ディスクセットにディスクを追加するには (Solstice DiskSuite)

  1. ディスクにデータが存在しないことを確認します。

    パーティションテーブルが作成し直され、ディスク上にメタデバイス状態データベースの複製の領域が割り当てられるため、この確認は必ず行なってください。

  2. 多重ホストディスク拡張装置にディスクデバイスを挿入します。

    ディスク拡張装置のハードウェアマニュアルに示されたディスクの追加と取り外しの方法に従ってください。

  3. ディスクセットにディスクを追加します。

    コマンドの構文を次に示します。diskset には、ディスクの追加先であるディスクセットの名前を指定します。drive には、ディスクの DID 名を dN (Sun Cluster を新たにインストールする場合) または cNtYdZ (HA 1.3 からアップグレードする場合) の形式で指定します。


    # metaset -s diskset -a drive

  4. metaset(1M) コマンドでディスクセットにディスクを追加した後、scadmin(1M) コマンドを使用して、追加されたディスクに対してフェイルファストの予約と有効化を行います。


    phys-hahost1# scadmin reserve drivename

ディスクセットからのディスクの削除

ディスクセットに含まれるディスクは、ディスク上のスライスがメタデバイスやホットスペアプールで使用中でないかぎり、任意の時点で削除できます。

ディスクセットからディスクを削除するには (Solstice DiskSuite)

  1. metastat(1M) コマンドを使用して、メタデバイスまたはホットスペアとして使用されているスライスが存在しないことを確認します。

  2. metaset(1M) コマンドを使用して、ディスクセットから目的のディスクを削除します。

    このコマンドの構文を次に示します。diskset には、取り外す (障害が発生した) ディスクを含むディスクセットの名前を指定します。drive には、ディスクの DID 名を dN (Sun Cluster を新たにインストールする場合) または cNtYdZ (HA 1.3 からアップグレードする場合) の形式で指定します。


    # metaset -s diskset -d drive

    この処理は、構成のサイズとディスクの数に応じて 15 分以上かかります。

多重ホストメタデバイスの管理

次の節では、Sun Cluster の多重ホスト環境でのメタデバイスの管理と、単一ホスト環境での管理の違いについて述べます。

次の節では、特に記述がないかぎり、Solstice DiskSuite のマニュアルに示されている方法を使用できます。

注 -

Solstice DiskSuite のマニュアルの操作説明は、単一ホスト構成だけを対象としています。

次の節では、作業に使用する Solstice DiskSuite コマンド行プログラムについて説明しています。特に指示がないかぎり、これらの作業は metatool(1M) の GUI を使用しても行えます。metatool(1M) を実行する場合は、ディスクセット名を指定できるように -s オプションを使用してください。

メタデバイスの管理

「監視ユーティリティ」で説明しているように、メタデバイスを管理するには、操作中に起こるメタデバイスのエラーを絶えず監視する必要があります。

hastat(1M) によってディスクセットの問題が報告された場合は、metastat(1M) コマンドを使用してエラーが発生したメタデバイスを特定してください。

metastat(1M) または metatool(1M) を実行するには、ディスクセット名を指定できるように -s オプションを使用する必要があります。

注 -

メタデバイス構成を変更する場合は、その構成情報を保存しておいてください。metastat -p を使用して md.tab ファイル内の情報に似た出力を作成し、続いてその出力を保存してください。パーティション分割情報の保存については、「ディスクパーティション情報の保存 (Solstice DiskSuite)」を参照してください。

ディスクへのミラーの追加

ミラー化されたメタデバイスは、Sun Cluster の可用性の高いアプリケーションに使用されるロギング UFS ファイルシステムの一部として使用できます。

ディスクセットに含まれるディスク上のアイドル状態のスライスは、metainit(1M) コマンドを使用してメタデバイスに組み込むことができます。

ディスクセットのミラーの削除

Sun Cluster の可用性の高いデータベースアプリケーションは、ミラー化された raw メタデバイスを使用してデータベースを格納できます。これらのミラーについては、各論理ホストの dfstab.logicalhost ファイルや vfstab ファイルには示されていませんが、関連する Sun Cluster データベース構成ファイルには出現します。これらの構成ファイルのミラーは削除する必要があります。このためには、まず Sun Cluster データベースシステムがミラーを使用するのを停止します。続いて、metaclear(1M) コマンドを使用してミラーを削除します。

サブミラーのオフライン化

SPARCstorage Array を使用している場合は、SPARCstorage Array のディスクの交換または追加を行う前に、そのトレー上のメタデバイスをすべてオフラインにする必要があります。

対称構成では、2 つのディスクセットのそれぞれのディスクが SPARCstorage Array の同じトレーに存在する可能性があるため、保守のためにサブミラーをオフラインにするのは困難です。トレーを取り外す前に、各ディスクセットのメタデバイスをオフラインにする必要があります。

トレー内の各ディスクのサブミラーをすべてオフラインにするには、metaoffline(1M) コマンドを使用します。

新しいメタデバイスの作成

ディスクセットにディスクを追加した後、metainit(1M) または metatool(1M) を使用して新しいメタデバイスを作成してください。新しいデバイスがホットスペアの場合、metahs(1M) コマンドを使用して、ホットスペアプールにホットスペアを入れてください。

エラーが発生したコンポーネントの交換

エラーが発生したメタデバイスコンポーネントを交換するには、metareplace(1M) コマンドを使用します。

代替のスライス (またはディスク) は、使用可能な状態でなければなりません。これは、使用されていない既存のデバイスでも、ディスクセットに追加した新しいデバイスでもかまいません。

metareplace -e コマンドを使用して、(シャーシの停電などが原因の) 一時エラーが起きるドライブをサービスに戻すこともできます。

メタデバイスの削除

メタデバイスを削除する前に、Sun Cluster HA for NFS によって使用されているコンポーネントがメタデバイス内に存在しないことを確認してください。その後、metaclear(1M) コマンドを使用してメタデバイスを削除してください。

メタデバイスの拡張

メタデバイスを拡張するには、別々の多重ホストディスク拡張装置で少なくても 2 つのスライス (ディスク) が使用できるようにする必要があります。新しい 2 つのスライスはそれぞれ、metainit(1M) コマンドを使用して別々のサブミラーに追加します。続いて、growfs(1M) コマンドを使用してファイルシステムを拡張できます。

注意 - 注意 -

growfs(1M) コマンドの実行中、クライアントサービスが停止する場合があります。

ファイルシステムを拡張している間にテイクオーバーが発生すると、ファイルシステムは拡張されません。テイクオーバーが終了した後で、growfs(1M) コマンドを再実行する必要があります。

注 -

/logicalhost/statmon が含まれるファイルシステムの拡張は行えません。statd(1M) プログラムはこのディレクトリを変更するため、ファイルシステムの拡張が行われている間は長時間ブロックされます。このため、ネットワークファイルのロックプロトコルに予測できない影響が出る場合があります。これは、Sun Cluster HA for NFS を使用した構成だけの問題です。

ホットスペアプールの管理

ホットスペアデバイスは、それらが使用中でないかぎり、いつでもスペアプールに追加または削除できます。また、新しいスペアプールを作成し、metahs(1M) コマンドを使用してそれらをサブミラーに関連付けることができます。

UFS ログの管理

多重ホストディスク上の UFS ログはすべてミラー化されます。サブミラーに障害が発生すると、そのサブミラーはエラーが発生したコンポーネントとして報告されます。サブミラーの障害は、metareplace(1M) または metatool(1M) を使用して修復してください。

UFS ログが入ったミラー全体に障害が発生した場合は、ファイルシステムのマウントを解除します。次に、アクセス可能なデータのバックアップ、エラーの修復、ファイルシステムの修復 (fsck(1M) を使用) を行います。その後ファイルシステムをマウントし直す必要があります。

論理ホストへの UFS ロギングの追加

フェイルオーバーまたは haswitch(1M) タイムアウトの基準を満たすため、論理ホスト内の UFS ファイルシステムは、すべてロギング UFS システムでなければなりません。ロギング UFS システムにより、高速のスイッチオーバーとテイクオーバーが容易になります。

ロギング UFS ファイルシステムは、ミラー化されたロギングデバイスと UFS マスターファイルシステムを使用して、トランスデバイスを作成することにより設定します。ロギングデバイスと UFS マスターデバイスは共にミラー化する必要があります。

通常、ディスクセット内の各ドライブのスライス 6 は、UFS ログとして使用できます。スライスは、UFS ログサブミラーに使用できます。スライスが希望するログサイズよりも小さい場合は、複数のスライスを連結できます。通常、UFS ログには 100M バイトあたり 1M バイトが適切です (最大 64M バイト)。ログスライスのドライブが、UFS マスターデバイスのドライブと異なることが理想的です。

注 -

UFS ログ用の領域を確保するためにディスクのパーティション分割を再度行う必要がある場合は、シリンダ 0 から始まる最低 2M バイトの既存のスライス 7 を保持してください。スライス 7 は、メタデバイス状態データベースの複製に必要な領域として予約されています。Tag と Flag フィールドは (format(1M) コマンドで報告されるように)、スライス 7 用に保持する必要があります。Tag と Flag フィールドは、最初の構成が確立されると、metaset(1M) コマンドにより正しく設定されます。

トランスデバイスが構成された後で、newfs(1M) を使用してトランスデバイス上に UFS ファイルシステムを作成してください。

newfs 処理が終了した後、次の方法に従って論理ホストの vfstab ファイルに UFS ファイルシステムを追加してください。

    /etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost ファイルを編集して、管理情報と多重ホスト UFS ファイルシステム情報を更新します。

すべてのクラスタノードの vfstab.logicalhost ファイルに同じ情報が入っていることを確認してください。クラスタ内のすべてのノードで vfstab.logicalhost ファイルを同時に編集するには、cconsole(1) 機能を使用してください。

次に、管理ファイルシステムとその他 4 つの UFS ファイルシステムの情報が入った vfstab.logicalhost ファイルの例を示します。


#device                 device                   mount       FS  fsck  mount mount
 #to mount                to fsck                    point       type pass  all   options#
 /dev/md/hahost1/dsk/d11  /dev/md/hahost1/rdsk/d11 /hahost1    ufs  1     no   -
 /dev/md/hahost1/dsk/d1   /dev/md/hahost1/rdsk/d1  /hahost1/1  ufs  1     no   -
 /dev/md/hahost1/dsk/d2   /dev/md/hahost1/rdsk/d2  /hahost1/2  ufs  1     no   -
 /dev/md/hahost1/dsk/d3   /dev/md/hahostt1/rdsk/d3 /hahost1/3  ufs  1     no   -
 /dev/md/hahost1/dsk/d4   /dev/md/hahost1/rdsk/d4  /hahost1/4  ufs  1     no   -

ファイルシステムが Sun Cluster HA for NFS によって共有される場合は、『Sun Cluster 2.2 ソフトウェアのインストール』の Sun Cluster HA for NFS についての章で説明されている、NFS ファイルシステムを共有する方法に従ってください。

新しいファイルシステムは、メンバーシップモニターの次の再構成時に自動的にマウントされます。メンバーシップの再構成を強制するには、次のコマンドを使用してください。 


# haswitch -r

ローカルメタデバイスの管理

ローカルディスクはミラー化できます。一方のミラーに障害が発生した場合は、Solstice DiskSuite のマニュアルに示された方法でそのミラーを交換し、新たに追加したディスクと正常なディスクとの同期をとり直してください。

サポートされていない (障害を起こす) メタデバイスアクション

次のメタデバイスアクションは、Sun Cluster 構成でサポートされていません。

Sun Cluster 環境での SSVM と CVM の使用

Sun StorEdge Volume Manager (SSVM) と Cluster Volume Manager (CVM) は、同じボリュームマネージャをもとにした製品です。CVM は、Oracle Parallel Server (OPS) 構成でだけ使用されます。この節では、ボリュームマネージャの制御下にあるディスクを使用して次のオブジェクトを管理する方法について説明します。

これらのオブジェクトの管理の詳細は、該当する節を参照してください。

オブジェクト管理の概要 (SSVM と CVM)

ボリュームマネージャの制御下にあるオブジェクトは、コマンド行ユーティリティまたは Visual Administrator の GUI を使用して作成と管理を行います。

SSVM と CVM のマニュアルを使用して Sun Cluster 構成内でボリュームマネージャの制御下にあるオブジェクトを管理する場合は、あらかじめこの章の情報に目を通してください。ここに示す作業は、以下の作業を行うための方法の 1 つです。実際の構成に最も適した方法を使用してください。

これらのオブジェクトは、通常、次のような関係を持ちます。

デフォルトのディスクグループは rootdg (ルートディスクグループ) です。必要に応じて、さらにディスクグループを作成できます。ディスクグループの主な管理作業として、ディスクの追加と削除が挙げられます。

ディスクグループに含めたディスクを使用する前に、物理ディスクのスライスを使用して (ボリュームマネージャ制御下の) ディスクとサブディスクを設定することにより、プレックス (ミラー) を構築する必要があります。プレックスは、連結またはストライプです。

SSVM と CVM では、アプリケーションは、スライスではなく (ボリュームマネージャディスクに作成された) ボリュームにアクセスします。

次の節では、作業に使用する SSVM と CVM のコマンド行プログラムについて説明しています。特に指示がないかぎり、これらの作業はすべて GUI を使用しても行えます。

注 -

Sun Cluster HA データサービスを使用しているノードでは、ディスクグループの論理ホストが保守モードにないかぎり、Sun Cluster の制御下にあるディスクグループに対して vxdg import または deport オプションを手動で実行しないでください。ディスクグループを手動でインポートまたはデポートする前に、ディスクグループを制御できるすべてのノードで scadmin stopnode を実行してそれらのノードの Sun Cluster を停止するか、haswitch -m コマンドを使用して対応するすべての論理ホストを保守モードに切り替える必要があります。ディスクグループの制御を Sun Cluster に戻す用意ができた時点で、ディスクグループをデポートし、その後 scadmin startnode または haswitch(1M) を実行して論理ホストを Sun Cluster の制御下に置くのが最も安全な方法です。

ディスクについて

ディスクを SSVM または CVM で使用するには、ボリュームマネージャに制御されるディスクとしてあらかじめ識別 (初期化) する必要があります。初期化が正しく行われたディスクは、ディスクグループへの追加、障害のあるディスクの交換、新しいディスクグループの作成などに使用できます。

ディスクの初期化と構成を行うには (SSVM と CVM)

  1. ディスクにデータが存在しないことを確認します。

    ディスクが初期化されると既存のデータは完全に消去されるため、この確認は必ず行なってください。

  2. 付属のハードウェアマニュアルの操作指示に従って、ディスク格納装置にディスクデバイスを挿入し、取り付けます。

  3. ディスクを初期化し、ディスクグループに加えます。

    この作業は、通常、vxdiskadm メニューまたは GUI を使用して行います。また、コマンド行ユーティリティの vxdisksetup と vxdg addisk を使用して、ディスクの初期化とディスクグループへの追加を行うこともできます。

ディスクをオフラインにする

物理ディスクをオフラインにする必要が生じることがあります。ディスクが破損している場合は、無効にして取り外す必要があります。別のシステムに接続するために物理ディスクをほかの場所に移動する場合も、あらかじめディスクを無効にする必要があります。

物理ディスクをオフラインにするには、まずディスクグループからそのディスクを削除し、続いて vxdisk(1M) コマンドを使用してディスクをオフラインにします。

ディスクの削除

ディスクを別のシステムに移動させる場合や、ディスクが故障しかかっているか完全に故障した場合は、ディスクを削除することができます。また、不要になったボリュームも削除できます。

ディスクグループからディスクを削除するには、vxdg(1M) コマンドを使用します。プライベートパーティションとパブリックパーティションを削除してボリュームマネージャによるディスク制御を解除するには、vxdiskunsetup(1M) コマンドを使用します。これらのコマンドの詳細は、vxdg(1M) と vxdiskunsetup(1M) のマニュアルページを参照してください。

ディスクグループの管理

SSVM と CVM では、特定のディスクグループのデフォルトマスターであるアクティブノードからディスクグループの生成を行うのが最も便利です。N+1 構成では、これらのデフォルトマスターノードはそれぞれ、多重ホストディスクコネクティビティを、クラスタ内の 1 つのノードであるホットスタンバイノードとだけ共有します。これらのノードを使用してディスクグループを生成すると、不正に構成されたグループの作成を避けることができます。

ディスクグループを作成するには (SSVM と CVM)

新しいディスクグループは、vxdiskadm メニューまたは GUI を使用して作成できます。また、コマンド行ユーティリティ vxdg init も使用できます。

ディスクグループの生成が終わると、vxdg deport コマンドを使用して各ディスクグループをデポートする必要があります。続いて、-t オプションを使用して各グループをホットスタンバイノードにインポートします。-t オプションはインポートが次の起動まで持続することを防止するため、必ず指定してください。SSVM または CVM のプレックスとボリュームをすべて作成した後に、ボリュームを起動する必要があります。

ディスクを別のディスクグループに移動させるには (SSVM と CVM)

ディスクをディスクグループ間で移動させるには、ディスクグループからそのディスクを削除し、別のディスクグループに追加します。

次の例は、コマンド行ユーティリティを使用して、物理ディスク c1t0d1 をディスクグループ acct からディスクグループ log_node1 に移動させます。

  1. vxprint(1M) コマンドを使用して、ディスクが使用中であるかどうかを確認します。


    # vxprint -g acct
 TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg acct         acct         -        -        -        -        -       -

 dm c1t0d0       c1t0d0s2     -        2050272  -        -        -       -
 dm c1t0d1       c1t0d1s2     -        2050272  -        -        -       -
 dm c2t0d0       c2t0d0s2     -        2050272  -        -        -       -
 dm c2t0d1       c2t0d1s2     -        2050272  -        -        -       -

 v  newvol       gen          ENABLED  204800   -        ACTIVE   -       -
 pl newvol-01    newvol       ENABLED  205632   -        ACTIVE   -       -
 sd c1t0d1-01    newvol-01    ENABLED  205632   0        -        -       -
 pl newvol-02    newvol       ENABLED  205632   -        ACTIVE   -       -
 sd c2t0d1-01    newvol-02    ENABLED  205632   0        -        -       -

 v  vol01        gen          ENABLED  1024000  -        ACTIVE   -       -
 pl vol01-01     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c1t0d0-01    vol01-01     ENABLED  1024128  0        -        -       -
 pl vol01-02     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c2t0d0-01    vol01-02     ENABLED  1024128  0        -        -       -

  2. vxedit(1M) コマンドを使用してボリュームを削除し、c1t0d1 ディスクを解放します。

    vxedit コマンドは、共有ディスクグループをマスターしている CVM ノードから実行する必要があります。


    # vxedit -g acct -fr rm newvol

    -f オプションは、操作を強制します。-r オプションは、操作を繰り返し実行します。

  3. c1t0d1 ディスクを acct ディスクグループから削除します。

    共有ディスクグループをマスターしている CVM ノードから、vxdg コマンドを実行してください。


    # vxdg -g acct rmdisk c1t0d1

  4. c1t0d1 ディスクを log_node1 ディスクグループに追加します。


    # vxdg -g log_node1 adddisk c1t0d1
    注意 - 注意 -

    この作業は、ディスク上に構成やデータを保存しません。

    c1t0d1 が削除された後の acct ディスクグループの状態を次に示します。


    # vxprint -g acct
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg acct         acct         -        -        -        -        -       -

 dm c1t0d0       c1t0d0s2     -        2050272  -        -        -       -
 dm c2t0d0       c2t0d0s2     -        2050272  -        -        -       -
 dm c2t0d1       c2t0d1s2     -        2050272  -        -        -       -

 v  vol01        gen          ENABLED  1024000  -        ACTIVE   -       -
 pl vol01-01     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c1t0d0-01    vol01-01     ENABLED  1024128  0        -        -       -
 pl vol01-02     vol01        ENABLED  1024128  -        ACTIVE   -       -
 sd c2t0d0-01    vol01-02     ENABLED  1024128  0        -        -       -

    c1t0d1 が追加された後の log_node1 ディスクグループの状態を次に示します。


    # vxprint -g log_node1
 TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
 dg log_node1    log_node1    -        -        -        -        -       -

 dm c1t0d1       c1t0d1s2     -        2050272  -        -        -       -
 dm c1t3d0       c1t3d0s2     -        2050272  -        -        -       -
 dm c2t3d0       c2t3d0s2     -        2050272  -        -        -       -
 #

    ボリュームのアクセス権または所有権を変更するには、vxedit コマンドを使用する必要があります。

    注意 - 注意 -

    chmod と chgrp は使用しないでください。chmod または chgrp によって設定されるアクセス権と所有権は、再起動時に自動的に root に再設定されます。

    変更前の /dev/vx/rdsk ディレクトリ内のボリューム vol01 と vol02 のアクセス権と所有権の例を次に示します。


    # ls -l
crw-------		 	 1	 	root 	root	 nnn,nnnnn		 date	time 	vol01
crw-------		 	 1	 	root	 root 	nnn,nnnnn		date 	time 	vol02
 ...

    vol01 のアクセス権と所有権を変更する例を次に示します。


    # vxedit -g group_name set mode=755 user=oracle vol01

    編集後にアクセス権と所有権がどのように変わったかを注意してください。


    # ls -l
crwxr-xr-x		 	 1 	oracle	 root	 nnn,nnnnn	 	date 	time 	vol01
crw-------		 	 1	 root	 root	 nnn,nnnnn 		date 	time 	vol02
 ...

SSVM オブジェクトと CVM オブジェクトの管理

ボリューム (仮想ディスク) には、ファイルシステムやデータベースなどのアプリケーションを格納できます。ボリュームは、サブディスクを含むプレックス (最大 32) で構成されます。ボリュームを使用するためには、関連付けられた 1 つ以上のサブディスクに対応する 1 つ以上のプレックスが存在しなければなりません。ボリューム内のサブディスクはすべて、同じディスクグループに属する必要があります。

ボリュームの作成とボリュームへのミラーの追加

各ディスクグループのボリュームの作成と、各ボリュームに対応するミラーの作成には、GUI またはコマンド行ユーティリティ vxassist(1M) を使用してください。

SSVM デバイスまたは CVM デバイスの実際のサイズは、ディスクドライブ全体の容量よりもわずかに小さくなります。SSVM と CVM は、個人的な使用のための領域 (非共有領域と呼ばれる) を少量確保します。

注 -

異なるディスクグループにボリュームが属する場合は、同じボリューム名を使用することができます。

ダーティーリージョンログの追加

ダーティーリージョンログ (DRL) は、システム障害が発生した後に、ミラー化されたボリュームをすばやく回復させるために使用される、オプションのボリュームプロパティです。DRL は、ミラー化されたボリュームに対する I/O 書き込みが原因で変化した領域の記録をとり、この情報を使用して回復を要するボリュームの一部だけを回復させます。

既存のボリュームのログファイルの作成

ログサブディスクは、DRL が有効になっているボリュームの DRL を保存するために使用されます。DRL を使用するボリュームには、最低 1 つのログサブディスクが存在します (複数のログサブディスクを使用して DRL をミラー化できます)。各ログサブディスクは、ボリュームのプレックスの 1 つに対応しています。ログサブディスクは、プレックスあたり 1 つしか存在できません。プレックスにログサブディスクだけが含まれ、データサブディスクが含まれない場合、そのプレックスはログプレックスとして参照できます。ログサブディスクは、データサブディスクが入った通常のプレックスと関連付けることもできます。この場合、データサブディスクの 1 つに障害が発生したためにプレックスの切り離しが必要になると、ログサブディスクは使用できなくなる可能性があります。

既存のボリュームのログを作成するには、GUI またはコマンド行ユーティリティ vxassist(1M) を使用してください。

ホットリロケーション

ホットリロケーションは、冗長 (ミラー化または RAID5) ボリュームマネージャオブジェクトの I/O 障害に自動的に反応し、それらのオブジェクトの冗長性とアクセスを自動的に復元するシステム機能です。ホットリロケーションは、SSVM を使用した構成でのみサポートされます。SSVM は、ボリュームマネージャオブジェクトの I/O 障害を検出し、影響を受けたサブディスクをスペアディスクに指定されたディスクに再配置するか、ディスクグループ内の領域を解放します。続いて SSVM は、障害が発生する前に存在していたオブジェクトを再構築し、それらを冗長でアクセス可能な状態に戻します。

部分的なディスク障害 (ディスク上の一部のサブディスクにだけ影響する障害) が発生した場合、ディスクの障害部分に存在する冗長データは再配置され、影響がなかったディスク部分から構成される既存のボリュームは以前のままアクセスできます。

注 -

ホットリロケーションが行われるのは、障害が発生したディスク上の冗長 (ミラー化または RAID5) サブディスクに対してだけです。障害が発生したディスク上の非冗長サブディスクは再配置されませんが、それらの障害の通知は行われます。

スペアディスクを交換用として使用するには、あらかじめ初期化し、ディスクグループにスペアとして入れておく必要があります。障害発生時にスペアに指定されたディスクが存在しないと、SSVM は障害が発生したディスクグループ内の使用できる任意の空き領域を自動的に使用します。十分な空き容量がない場合には、スペア領域と空き領域が組み合わされて使用されます。各ディスクグループでは、vxedit(1M) コマンドを使用して 1 つ以上のディスクをホットリロケーションのスペアとして指定できます。

VxFS ファイルシステムの使用

タイプが fsgen であるボリューム上の、論理ホストのディスクグループに対応するファイルシステム (UFS または VxFS) は構成と指定が行えます。クラスタノードが論理ホストを制御する場合、ディスクグループに対応する、論理ホストのファイルシステムは制御側ノードの指定されたマウント先にマウントされます。

論理ホストの再構成作業が行われている間、fsck(1M) コマンドを使用してファイルシステムを検査する必要があります。この処理は UFS ファイルシステム上で非対話式の並列モードで行われますが、再構成作業の総合的な時間に影響を与える可能性があります。UFS、SDS、VxFS ファイルシステムのロギング機能は、ファイルシステムのマウントの前に fsck(1M) が使用する時間を大幅に短縮します。

ボリューム回復に加えてデータサービスのスイッチオーバーが必要な場合、回復は再構成にかかる時間よりも長くなります。この場合はタイムアウトし、ノードが停止します。

このため、ミラー化ボリュームを設定する場合は、システム障害時のボリューム回復時間を短縮するために必ず DRL ログを追加してください。クラスタ環境でミラー化ボリュームが使用されている場合は、500M バイトを超えるボリュームに DRL を割り当てる必要があります。

HA データサービスに 500M バイトを超える大きなファイルシステムが使用されている場合は、VxFS を使用してください。通常、VxFS は Sun Cluster には含まれていないため、Veritas 社から別途購入する必要があります。

注 -

非常に小さなミラー化ファイルシステムを使用して論理ホストを構成することも可能ですが、ファイルシステムのサイズが増えるにつれてタイムアウトが発生する可能性があるため、ダーティーリージョンログ (DRL) または VxFS ファイルシステムを使用することをお勧めします。

ファイルシステムの拡張

ファイルシステムが含まれるストライプ化されたボリュームまたは RAID5 ボリュームを拡張するには、そのボリュームに現在存在するディスクと同じ数のディスク上に空き領域がなければなりません。たとえば、一緒にストライプ化された 4 つの 1G バイトディスク (4G バイトファイルシステム 1 つ) が存在し、1G バイトの容量を追加する場合 (5G バイトのファイルシステムを作成する)、少なくても 0.25G バイトの空き領域をそれぞれ持つ 4 つの新しいディスクが必要です。つまり、1 つのディスクを 4 ディスク構成のストライプに追加することはできません。

SSVM または SSVM の GUI は、ファイルシステムを拡張するディスクを選択します。ファイルシステムを拡張させる特定のディスクを選択するには、コマンド行インタフェースを使用してください。

UFS ファイルシステムを直接縮小することは不可能ですが、ボリュームを作成し直し、そのボリュームに対して newfs を実行し、その後バックアップからデータを復元すれば縮小されたファイルシステムができます。

ローカルミラーの管理

ローカルディスクはミラー化できます。一方のミラーに障害が発生した場合は、ボリュームマネージャのマニュアルで説明されている方法に従って、障害が発生したミラーを交換し、新たに追加したディスクと正常なディスクの同期をとり直してください。

Solstice Backup による多重ホストデータのバックアップ

この節では、Solstice BackupTM を使用して Sun Cluster ファイルシステムをバックアップする方法について説明しています。

Solstice Backup は、単一のサーバーでサーバーソフトウェアの各コピーを実行するように設計されています。Solstice Backup は、ファイルのバックアップ元と同じ物理ディスクを使用してファイルの回復が行われることを想定します。

Solstice Backup は、サーバーとクライアントに対応する物理マシンについての多くのデータ (ホスト名とホスト ID) を保持しています。論理ホストが構成される実際の物理マシンに関するこれらの情報は、Solstice Backup がクライアントインデックスをどのように格納するかに影響を与えます。

Solstice Backup の /nsr データベースは、多重ホストディスクに格納しないでください。2 つの Solstice Backup サーバーが同じ /nsr データベースにアクセスを試みると、衝突が起きます。

Solstice Backup は、クライアントインデックスを一定の方法で格納します。そのため、別の日に個別の Solstice Backup サーバーを使用して個々のクライアントをバックアップすることは避けてください。バックアップを行う場合は必ず、その論理ホストが常に同じ物理サーバーによってマスターされていることを確認してください。これは、将来の回復作業を円滑に行うためです。

注 -

デフォルトでは、Sun Cluster システムはバックアップ構成の詳しいファイルシステムの一覧を生成しません。保存セットの一覧にキーワード All が含まれる場合、どのファイルシステムを保存すべきか決定するために、/etc/vfstab ファイルが検査されます。Sun Cluster の vfstab ファイルはデフォルトでは /etc/opt/SUNWcluster/conf/hanfs に保持されるため、保存する Sun Cluster ファイルシステムを明示的に指定しないかぎり、Solstice Backup はそれらを見つけることができません。バックアップ作業のテストを行う場合、バックアップを要するすべての Sun Cluster ファイルシステムが、Solstice Backup ファイルシステム一覧に含まれることを確認してください。

次に、Solstice Backup を構成するための 4 つの方法を示します。使用している Sun Cluster 構成に応じて、適切な方法を選択してください。この場合、スイッチオーバーの回数も考慮してください。方法を決定したら、将来の回復作業が円滑に行われるように、以降は同じ方法でバックアップを行なってください。

構成方法を次に示します。

上記の 4 つのバックアップ方法はすべて、指定した Solstice Backup サーバーがダウンしている場合に一時的にバックアップを行う別のサーバーを構成できます。一時的な Solstice Backup サーバーを使用して、通常の Solstice Backup サーバーによってバックアップされたファイルを回復させることはできません。また、通常のバックアップサーバーから、一時的なサーバーによってバックアップされたファイルを回復させることもできません。

Sun Cluster マニュアルページのクイックリファレンス

この付録では、Sun Cluster フレームワークと Sun Cluster データサービスに関連するすべてのコマンドとユーティリティの構文と内容を示します。この付録は、クイックリファレンスとして使用してください。各コマンドとユーティリティは、該当するマニュアルページの節にアルファベット順に示されています。

注 -

この付録に挙げるマニュアルページはすべて、man(1) コマンドを使用してオンラインでも見ることができます。

man1

man1M

man3HA

man4

man7

Sun Cluster の障害追跡

この付録では、Sun Cluster の障害追跡について説明します。

この節では、Sun Cluster の障害検証の概要を説明します。この障害検証は、主に次の 3 つの方法によって行われます。

障害監視は、問題の原因が正常なノードではなく障害ノードにあることを確認するために、妥当性検査を行います。

この付録に示された情報の一部はこの Sun Cluster リリース固有のもので、製品のバージョンアップに伴い変更される場合があります。各種の障害検証に示された時間予測は概算です。この付録は、Sun Cluster 内部についてのプログラムロジックやプログラミングインタフェースについて説明するためのものではありません。

障害追跡の概要

Sun Cluster の基本的なアーキテクチャの説明で述べたように、1 台のサーバーがダウンした場合、ほかのサーバーがテイクオーバーします。ここでは、「あるサーバーがダウンしたことを別のサーバーはどのようにして認識するのか」を説明します。

Sun Cluster は、3 つの障害検証方法を使用します。

2 つ目と 3 つ目の方法では、1 台のサーバーがほかのサーバーの応答を検証します。明らかな問題が検出されると、検証側サーバーは、ほかのサーバーからのテイクオーバーを強行する前に、それ自体の妥当性検査を多数行います。これらの妥当性検査では、ほかのサーバーから応答がない実際の原因が検証側サーバーにないことを確認します。これらの妥当性検査は、Sun Cluster のベースフレームワークの一部であるライブラリサブルーチン hactl(1M) によって提供されます。そのため、データサービス固有の障害検証コードは、検証側サーバーの妥当性検査を行う場合 hactl(1M) を呼び出すだけですみます。詳細は、hactl(1M) のマニュアルページを参照してください。

ハートビート機構: クラスタメンバーシップモニター

Sun Cluster は、ハートビート機構を使用します。ハートビート処理は、メモリーに固定される優先度の高いリアルタイムプロセスによって処理されます。つまり、ハートビート処理は、ページングに制約されません。この処理は、クラスタメンバーシップモニターと呼ばれます。クラスタメンバーシップモニターは、ps(1) による出力には clustd という名前で示されます。

各サーバーは、両方のプライベートリンクを介して約 2 秒に 1 度、稼動していること示すメッセージ (ハートビート) を送信します。そして、両方のプライベートリンク上で、ほかのサーバーからのハートビートメッセージを受信します。どちらかのプライベートリンク上でハートビートを受信していることは、ほかのサーバーの稼動を示す十分な証拠となります。一定の時間 (約 12 秒) ほかのサーバーからのハートビートメッセージがない場合、サーバーはそのサーバーがダウンしていると判断します。

障害の検出という視点から見ると、クラスタメンバーシップモニターのハートビート機構は防御の第一線に当たります。ハートビートが受信されないと、ハードウェアの障害とオペレーティングシステムの障害がすぐに検出されます。ハートビート機構は、すべての通信バッファーの漏出などのような顕著なオペレーティングシステム上の問題を検出することもあります。ハートビート機構は、Sun Cluster の最も高速な障害検証方法でもあります。クラスタメンバーシップモニターはリアルタイムに優先されて動作するとともに、メモリー内に固定されるため、比較的短時間のハートビートの欠如は認められます。逆に、ほかの障害検証方法では、サーバーの速度が単に非常に遅いためにそのサーバーがダウンしていると Sun Cluster で判断されることを避けなければなりません。それらの方法では、数分という比較的長時間のタイムアウトが使用され、複数の長時間タイムアウトが発生しないと Sun Cluster がテイクオーバーを行わないこともあります。

クラスタメンバーシップモニターがリアルタイムに優先されて動作し、かつメモリー内に固定されるという事実は、そのサーバーがデータサービスレベルで有用な作業を行なっていない場合でもメンバーシップモニターが活動する可能性があるという矛盾を生みます。「データサービス固有の障害検証」で説明しているように、データサービス固有の障害監視がこの問題を解決します。

検証側ノードの妥当性検査

ネットワーク障害の検証とデータサービス固有の障害検証では、各ノードは別のノードの応答を検証する必要があります。テイクオーバーを行う前に、検証側ノードは自身の基本的な妥当性検査を多数行います。これらの検査は、障害の原因が実際に検証側ノードにないことを確認するとともに、障害があると思われるサーバーからのテイクオーバーによって状況が実際に改善されるかどうかを確認します。これらの妥当性検査が行われないと、誤ったテイクオーバーが発生する可能性があります。つまり、欠陥のあるノードに、ほかのノードが応答しないことによって、その欠陥のあるノードが誤って問題のないそのサーバーをテイクオーバーすることがあります。

検証側ノードは、別のノードをテイクオーバーする前に、自身に対して次の妥当性検査を行います。

パブリックネットワークモニター (PNM)

PNM コンポーネントには、主な機能が 2 つあります。

PNM は、ノード内のパブリックネットワークインタフェースセットについてのネットワーク統計を周期的に収集するデーモン (pnmd) として実装されています。この統計収集の結果に異常が認められた場合、pnmd は次の 3 つの場合のどれに該当するかを調べます。

続いて PNM は、同じサブネット上で対等デーモンに対して ping を実行します。応答がない場合、PNM は同じサブネット上でブロードキャスト ping を行います。続いて PNM は検索の結果を CCD に格納し、ローカル結果を CCD 内のほかのノードの結果 (これも CCD に格納される) と比較します。この比較は、ネットワークがダウンしているか、それともネットワークインタフェースに障害があるかを確認するために行われます。ネットワークインタフェースに障害があり、バックアップアダプタが構成されていることを検出すると、PNM はネットワークアダプタのフェイルオーバーを実行します。

PNM 監視の結果は、さまざまなエンティティで使用されます。PNM のネットワークアダプタフェイルオーバーコンポーネントは、監視結果を使用してアダプタフェイルオーバーが有益かどうかを判断します。たとえば、ネットワークに障害が発生している場合、アダプタフェイルオーバーは行われません。Sun Cluster HA データサービスに対応した障害モニターと、API 呼び出し hactl は、PNM 機能を使用してデータサービス障害の原因を診断します。PNM が返す情報は、データサービスを移動させるかどうかの決定、および移動後のデータサービスの位置の決定に使用されます。

アダプタ障害の検出時に PNM 機能によって書き込まれる syslog メッセージは Sun Cluster Manager によって読み込まれ、グラフィックアイコンにより GUI を介して表示されます。

PNM ユーティリティをコマンド行で実行し、ネットワークコンポーネントの状態を確認することもできます。詳細は、pnmset(1M)、pnmstat(1M)、pnmptor(1M)、pnmrtop(1M)、pnmd(1M) のマニュアルページを参照してください。

Sun Cluster の障害検証

PNM は、パブリックネットワークの状態を監視し、必要に応じてバックアップ接続に切り替えます。しかし、パブリックネットワークアクセス全体が停止した場合、PNM はデータサービスも論理ホストフェイルオーバーも提供しません。このような状況が発生した場合、PNM はアクセスの停止を報告しますが、バックアップノード間の切り替えに対処するかどうかは外部の障害検証次第です。

ボリュームマネージャとして SSVM を使用している場合、SSVM フレームワークは、論理ホストごとに定義されたネットワークアダプタフェイルオーバー (NAFO) の各バックアップグループを監視し、次の条件のどちらかが満たされる場合にバックアップノードに対するスイッチオーバーを開始する必要があります。

これらの条件のどちらも満たされない場合、Sun Cluster はスイッチオーバーを行いません。

ボリュームマネージャが Solstice DiskSuite の場合、パブリックネットワークが停止すると、切断されたノードはアボートし、そのノードが制御している論理ホストはバックアップノードに移動します。

Sun Cluster フレームワークは、構成に論理ホストが含まれている場合と、データサービスが「有効」状態で、かつその論理ホストに登録されている場合だけパブリックネットワークを監視します。監視されるのは、論理ホストに使用されている NAFO バックアップグループだけです。

データサービス固有の障害検証

データサービス固有の障害検証は、サーバーノードとオペレーティングシステムが動作している場合でも、データサービスレベルでの有用な作業が発生していないという混乱した状態に、ソフトウェアやハードウェアが置かれている可能性がある場合に行われます。ノードまたはオペレーティングシステムの完全な停止は、総合的なアーキテクチャにおいて、クラスタメンバーシップモニターのハートビート機構によって検出されます。しかし、データサービスが有用な作業を行なっていない場合でも、ハードビート機構が実行を継続すると判断する程度に、ノードが十分動作していることがあります。

逆に、データサービス固有の障害検証は、ノードがクラッシュしたか、クラスタハートビートメッセージの送信を停止した状態を検出する必要がありません。クラスタメンバーシップモニターはこのような状態を検出し、かつデータサービスの障害検証自体にはこれらの状態を処理するロジックはないと仮定されます。

データサービスの障害検証は、データサービスのクライアントのように動作します。マシン上で行われる障害検証は、そのマシンがエクスポートするデータサービスを監視するとともに、(さらに重要なことに) ほかのサーバーがエクスポートするデータサービスも監視します。欠陥のあるサーバーがそれ自体の欠陥を正しく検出する可能性は低いため、各サーバーは自身の監視に加えてほかのノードの監視も行います。

データサービス固有の障害検証は、クライアントのように動作するほかに、データサービスの統計情報を使用して有用な作業が行われているかどうかを検査する場合もあります。また、特定のデータサービスにきわめて重要な特定のプロセスが存在するかどうかを検査する場合もあります。

一般に、この障害検証は、1 台のサーバーにほかのサーバーをテイクオーバーさせることによって、サービスの欠如に応答します。場合によっては、テイクオーバーを行う前にまず本来のマシン上のデータサービスの再起動を試みます。短時間で再起動が何度も発生する場合は、マシンに重大な問題があることを意味します。この場合、ほかのローカル再起動が試されることなく、ただちに別のサーバーによるテイクオーバーが行われます。

Sun Cluster HA for NFS の障害検証

検証側サーバーは、ほかのサーバーの NFS サービスに対して、2 種類の周期的な検証を行います。

  1. 検証側サーバーは、NFS サービスを提供する必要がある、対象ノード上のすべてのデーモンプロセス (rpcbind、mountd、nfsd、lockd、statd) に NULL RPC を送信します。

  2. 検証側サーバーは、ほかのノードから NFS ファイルシステムのマウントを試み、続いてそのファイルシステムに対してファイルの読み書きを試すことによって、終端間テストを行います。この終端間テストは、そのノードが現在共有しているファイルシステムごとに行われます。マウントは手間がかかるため、ほかの検証よりも行われる頻度は少なくなります。

これらの検証のどれかが失敗すると、検証側ノードはサービスを行なっているノードからのテイクオーバーを検討します。しかし、次のような理由によりテイクオーバーをただちに実施しないこともあります。

これらの Sun Cluster HA for NFS 固有のテストをパスした後、テイクオーバーを行うべきかどうかを検討するプロセスは、hactl(1M) を呼び出して継続します (「検証側ノードの妥当性検査」を参照)。

検証側サーバーは、それ自体の NFS サービスも検査します。ロジックはほかのサーバーの検証に似ていますが、テイクオーバーを行うのではなく、syslog にエラーメッセージを記録し、プロセスが存在しなくなったデーモンの再起動を試みます。つまり、デーモンプロセスの再起動は、デーモンプロセスが終了したかクラッシュした場合だけ行われます。デーモンプロセスがまだ存在するが応答していないという場合は、デーモンプロセスの再起動は行われません。これは、このような状況で再起動を行うと、デーモンがどのデータ構造を更新しているかを認識せずにデーモンを停止してしまうためです。また、この 1 時間以内にローカル再起動が試みられたばかりの場合も再起動は行われません。代わりに、ほかのサーバーにテイクオーバーの検討指示が出されます (そのサーバーがそれ自体の妥当性検査をパスしている場合)。rpcbind デーモンが再起動することはありません。これは、rpcbind に登録しているプロセスに、再登録が必要であることを知らせる方法がないためです。

HA-DBMS の障害検証

Sun Cluster HA for Oracle、Sun Cluster HA for Sybase、Sun Cluster HA for Informix の各障害検証は、データベースサーバーを同じように監視します。HA-DBMS の障害検証を構成するには、ユーティリティ haoracle(1M)、hasybase(1M)、hainformix(1M) の 1 つを実行します (これらのユーティリティのオプションの詳細はマニュアルページを参照)。

ユーティリティの構成とアクティブ化が終わると、クライアントアクセスをシミュレートして、ローカルノードで 2 つのプロセスが開始され、遠隔ノードで 2 つのプロセスが開始されます。遠隔の障害検証は、ha_dbms_serv デーモンによって初期化され、hareg -y detaservicename が初期化される際に起動されます。

HA-DBMS モジュールは、2 つの方法を使用して DBMS サービスが使用できるかどうかを監視します。HA-DBMS は、まず DBMS 自体から統計情報を抽出します。

クライアントの作業が行われていることを統計情報が示す場合、DBMS の検証はそれ以上必要ありません。作業が行われていないことを DBMS 統計が示す場合、HA-DBMS は DBMS に対して小さなテストトランザクションを発行します。この場合、偶然にすべてのクライアントがアイドル状態であると、DBMS 統計は作業がまったく発生していないことを示します。つまり、テストトランザクションはハングしたデータベース状態と通常のアイドル状態を区別します。テストトランザクションは、アクティビティが存在しないことを統計情報が示す場合にだけ実行されるため、アクティブなデータベースにオーバーヘッドを強要することはありません。このトランザクションでは次の作業が行われます。

HA-DBMS は、テイクオーバーを引き起こすコードと引き起こさないコードが示されたテーブルを使用して、DBMS が返すエラーコードを慎重に調べます。たとえば、Sun Cluster HA for Oracle では、table space full というケースはテイクオーバーを発生させません。これは、この状況を修復するには管理者が介入する必要があるためです (テイクオーバーが発生すると新しいマスターサーバーは同じ table space full 状態になります)。

一方、 could not allocate Unix semaphore のようなエラーリターンコードでは、Sun Cluster HA for Oracle はこのサーバーマシンで ORACLE をローカルに再起動しようとします。ローカル再起動が発生したばかりの場合は、代わってほかのマシンが (それ自体の妥当性検査にパスした後で) テイクオーバーします。

Sun Cluster HA for Netscape の障害検証

すべての Sun Cluster HA for Netscape データサービスの障害モニターは、データサービスインスタンスの障害監視を同じ方法で行います。これらはどれも、遠隔とローカルの障害監視という概念を使用します。

データサービスが実行されている論理ホストを現在制御しているノード上の障害モニタープロセスは、ローカル障害モニターと呼ばれます。論理ホストのマスターとなり得るノード上の障害監視プロセスは、遠隔障害モニターと呼ばれます。

Sun Cluster HA for Netscape の障害モニターは、サーバーに対して簡単なデータサービスオペレーションを周期的に行います。このオペレーションが失敗するか、あるいはタイムアウトする場合、この検証は失敗したと宣言されます。

検証が失敗した場合、ローカル障害検証はデータサービスをローカルに再起動しようと試みます。これで、通常はデータサービスが復元されます。遠隔検証は検証失敗の記録を保存しますが、何もアクションはとりません。検証が連続して 2 度失敗した場合 (データサービスの再起動が問題を解決しなかったことを示す)、遠隔検証は hactl(1M) コマンドを「テイクオーバー」モードで呼び出し、論理ホストのフェイルオーバーを開始します。Netscape データサービスの中には、検証の成功と失敗のスライド式ウィンドウアルゴリズムを使用するものがあります。このアルゴリズムでは、ウィンドウ内に事前に構成された失敗の数によって検証アクションが引き起こされます。

hadsconfig(1M) コマンドを使用して、Sun Cluster HA for Netscape 障害モニターの検証の間隔とタイムアウトの値を調整できます。障害検証の検証間隔の値を減らすと、問題が早く検出されますが、一時的な障害による誤ったフェイルオーバーが発生する可能性もあります。同様に、検証タイムアウトの値を減らすと、データサービスインスタンスに関連する問題が早く検出されますが、負荷が重いためにデータサービスが単にビジーになっている場合に誤ったテイクオーバーが発生する可能性があります。ほとんどの状況においては、これらのパラメータのデフォルト値で十分です。これらのパラメータについては、hadsconfig(1M) のマニュアルページと、『Sun Cluster 2.2 ソフトウェアのインストール』の各データサービスの構成に関する節に挙げられています。

Sun Cluster HA for DNS の障害検証

Sun Cluster HA for DNS の障害検証は、Sun Cluster HA for DNS サーバーの状態を検査するために nslookup オペレーションを実行します。このオペレーションは、Sun Cluster HA for DNS ロジカルホストのドメイン名を Sun Cluster HA for DNS サーバーから調べます。Sun Cluster HA for DNS の主サーバーがダウンしている場合は、nslookup は /etc/resolv.conf ファイルの構成にもとづいてほかのサーバーと通信する場合もあります。したがって、Sun Cluster HA for DNS の主サーバーがダウンしている場合でも、nslookup オペレーションが成功することがあります。このことを防止するため、障害検証は複製が Sun Cluster HA for DNS の主サーバーのものであるか、ほかのサーバーのものであるかを調べます。

Sun Cluster HA for Netscape HTTP の障害検証

Sun Cluster HA for Netscape HTTP の障害検証は、構成されたポート上の論理ホストアドレスで http サーバーに接続を試みることによって、http サーバーの状態を検査します。障害モニターは、nshttp サービスインスタンスの構成時に hadsconfig(1M) に指定されたポート番号を使用します。

Sun Cluster HA for Netscape News の障害検証

Sun Cluster HA for Netscape News の障害検証は、論理ホスト IP アドレスと nntp ポート番号で新しいサーバーに接続することによって、そのサーバーの状態を検査します。続いて、その新しいサーバーで NNTP date コマンドの実行を試み、指定された検証タイムアウトの間、サーバーからの応答を待ちます。

Sun Cluster HA for Netscape Mail または Message Server の障害検証

Sun Cluster HA for Netscape Mail または Message Server の障害検証は、サーバーのサービスを受ける 3 つのサービスポートすべて (SMTP、IMAP、POP3 ポート) でメールサーバーまたはメッセージサーバーの状態を検査します。

障害検証は、これらのテストはすべてについて、検証タイムアウトの間、サーバーからの応答文字列を待ちます。上記の 3 つのサービスポートのどれで検証が失敗しても、サーバー障害とみなされます。誤ったフェイルオーバーを避けるため、nsmail 障害検証はスライド式ウィンドウアルゴリズムを使用して、検証の失敗と成功を追跡します。スライド式ウィンドウ内の検証失敗の数が事前に構成されている数を超えた場合、遠隔検証によってテイクオーバーが開始されます。

Sun Cluster HA for Netscape LDAP の障害検証

Sun Cluster HA for Netscape LDAP の障害検証は、フェイルオーバーを開始する前にローカル再起動 (回数は変更可能) を実行できます。ローカル再起動機構は、スライド式ウィンドウアルゴリズムを使用します。つまり、そのウィンドウ内で再試行の数がなくなった場合だけフェイルオーバーが発生します。

Sun Cluster HA for Netscape LDAP の遠隔検証は、LDAP ポートに対する単純な telnet 接続を使用してサーバーの状態を検査します。LDAP ポート番号は、hadsconfig(1M) を使用して最初の設定時に指定されたものです。

ローカル検証は、

Sun Cluster HA for Lotus の障害検証

Sun Cluster HA for Lotus の障害検証には、Lotus Domino サーバープロセスが現在動作しているノードで実行されるローカル検証と、Lotus Domino サーバーの論理ホストのマスターになり得るほかのノード上で実行される遠隔検証があります。

両方の検証とも Lotus Domino ポートに対する単純な telnet 接続を使用して、Domino サーバーの状態を検査します。接続に失敗した場合、検証は hactl(1M) コマンドを呼び出してフェイルオーバーまたはテイクオーバーを開始します。

ローカル障害検証は、フェイルオーバーを開始する前に、ローカル再起動を 3 度行えます。ローカル再起動機構は、スライド式のタイムウィンドウアルゴリズムを使用します。このアルゴリズムでは、そのウィンドウで再試行回数がなくなった場合だけ、フェイルオーバーが発生します。

Sun Cluster HA for Tivoli の障害検証

Sun Cluster HA for Tivoli の障害検証は、ローカル障害検証だけ使用します。この検証は、Tivoli オブジェクトディスパッチャ oserv デーモンが現在動作しているノードで行われます。

この障害検証は、Tivoli コマンド wping を使用して監視対象である oserv デーモンの状態を検査します。oserv デーモンの wping は、次の理由で失敗することがあります。

oserv デーモンに対する ping の実行に失敗した場合、ローカル検証は hactl(1M) コマンドを呼び出してフェイルオーバーを開始します。この障害検証は、フェイルオーバーを開始する前に、ローカル再起動を 1 度実行します。

Sun Cluster HA for SAP の障害検証

Sun Cluster HA for SAP の障害検証は、セントラルインスタンス (メッセージサーバー、エンキューサーバー、ディスパッチャ) が使用できるかどうかを監視します。この検証は、重要な SAP プロセスの存在を検査することにより、ローカルノードだけを検査します。また、SAP ユーティリティ lgtst を使用して、SAP メッセージサーバーがアクセス可能であるかも調べます。

問題が検出されると (プロセスの停止が早すぎる場合や lgtst がエラーを報告する場合など)、障害検証はまずローカルノード上で、hadsconfig(1M) を使用して構成可能な回数だけ SAP の再起動を試みます。ユーザーが構成してある再起動回数がなくなると、このインスタンスがフェイルオーバーを許可するように構成されている場合 (hadsconfig(1M) でも構成可能)、障害検証は hactl(1M) を呼び出してスイッチオーバーを開始します。セントラルインスタンスはスイッチオーバーが発生する前に停止し、スイッチオーバーが終了した後に遠隔ノード上で再起動します。

Sun Cluster SNMP の使用

この付録では、SNMP を使用して Sun Cluster 構成の動作を監視する方法について説明します。

この付録で説明する手順は次のとおりです。

次の SNMP Management を使用して、Sun Cluster 構成を監視できます。

クラスタ SNMP Agent とクラスタ Management Information Base

Sun Cluster には、クラスタ用として、Management Information Base (MIB) のほかに Simple Network Management Protocol (SNMP) が付属しています。エージェントファイルの名前は snmpd (SNMP デーモン)、MIB の名前は sun.mib です。

クラスタ SNMP エージェントは、複数のクラスタ (最大 32) を同時に監視できるプロキシエージェントです。通常の Sun Cluster は、管理ワークステーションまたはシステムサービスプロセッサ (SSP) から管理できます。管理ワークステーションまたは SSP にクラスタ SNMP エージェントをインストールすると、ネットワークトラフィックが調整される上、SNMP パケットの転送でノードの CPU パワーが浪費されることがありません。

snmpd デーモンの内容を次に示します。

スーパーモニターデーモンである smond は、クラスタの各メンバーノードから in.mond デーモンに接続することにより、ハードウェア構成情報と重要なクラスタイベントを収集します。smond デーモンは、続いてこの情報を SNMP デーモン (snmpd) に報告します。

注 -

1 つの smond デーモンを構成することで、複数のクラスタ情報を収集することができます。

SUNWcsnmp パッケージには、次のものが含まれます。

snmpd と smond デーモンの詳細は、付録 B 「Sun Cluster マニュアルページのクイックリファレンス」を参照してください。

クラスタ Management Information Base

Management Information Base (MIB) は、ネットワーク管理プロトコルを介してアクセスできるオブジェクトのコレクションです。オブジェクトの定義は、さまざまな管理プラットフォームがその定義を読み込んで解析できるように、一般的で、一貫したものでなければなりません。

snmpd デーモンは、クラスタ管理ワークステーションである管理サーバー、または任意のクライアントで実行してください。このエージェントは、クラスタ MIB に定義されているすべての SNMP 属性に、smond から収集された情報を提供します。この MIB ファイルは、一般に SunNet Manager Console のような「SNMP 対応の」ネットワークマネージャにコンパイルされます。「snmpd.conf ファイルの変更」を参照してください。

sun.mib ファイルは、クラスタ情報を次に示すテーブルの形で提供します。

注 -

上記のテーブルにおける、時刻はテーブルが管理される SNMP サーバー上のローカル時刻を指します。したがって、時刻はサーバー上で属性変更が報告される時刻を示します。

clustersTable の属性

clustersTable (クラスタテーブル) は、監視対象のすべてのクラスタのエントリから構成されます。テーブル内の各エントリには、クラスタ情報を提供する特定の属性が含まれています。clustersTable の属性については、表 D-1を参照してください。

表 D-1 clustersTable の属性

属性名 

説明 

clusterName

クラスタ名 

clusterDescr

クラスタの説明 

clusterVersion

クラスタのリリースバージョン 

numNodes

クラスタ内のノード数 

nodeNames

コンマで区切られた、クラスタ内のすべてのノードの名前 

quorumDevices

コンマで区切られた、クラスタ内のすべての定足数デバイスの名前 

clusterLastUpdate

このエントリの属性のどれかが最後に変更された時刻 

clusterNodesTable の属性

clusterNodesTable (クラスタノードテーブル) は、監視対象のすべてのクラスタの既知のノードから構成されます。各エントリには、そのノードについての具体的な情報が含まれています。clusterNodesTable の属性については、表 D-2を参照してください。

注 -

相互参照を使用する場合、belongsToCluster の属性はこのテーブルと clustersTable 間のキー参照として動作します。

表 D-2 clusterNodesTable の属性

属性名 

説明 

nodeName

ノードのホスト名 

belongsToCluster

このノードが属しているクラスタの名前 

scState

このノード上の Sun Cluster ソフトウェアコンポーネントの状態 (Stopped、Aborted、In Transition、Included、Excluded、Unkonwn)。エンタプライズ固有のトラップが、状態の変化を知らせる 

vmState

このノード上のボリュームマネージャソフトウェアコンポーネントの状態。エンタプライズ固有のトラップが、状態の変化を知らせる 

dbState

このノード上のデータベースソフトウェアコンポーネントの状態 (Down、Up、Unknown)。エンタプライズ固有のトラップが、状態の変化を知らせる 

vmType

このノードで現在使用されているボリュームマネージャの種類 

vmOnNode

このノード上の SSVM ソフトウェアコンポーネントのモード (Master、Slave、Unkown)。エンタプライズ固有のトラップが、状態の変化を知らせる。この属性は、ほかのボリュームマネージャを使用しているクラスタには無効 

nodeLastUpdate

このエントリの属性のどれかが最後に変更された時刻 

switchesTable の属性

switchesTable (スイッチテーブル) は、すべてのスイッチのエントリから構成されます。このテーブルの各エントリには、クラスタ内のスイッチについての具体的な情報が含まれています。switchesTable の属性については、表 D-3を参照してください。

表 D-3 switchesTable の属性

属性名 

説明 

switchName

スイッチ名 

numPorts

スイッチのポートの数 

connectedNodes

スイッチのポートに現在接続されているすべてのノードの名前 

switchLastUpdate

このエントリのスイッチ属性のどれかが最後に変更された時刻 

portsTable の属性

portsTable (ポートテーブル) は、すべてのスイッチポートのエントリから構成されます。このテーブルの各エントリには、スイッチ内のポートについての具体的な情報が含まれています。portsTable の属性については、表 D-4を参照してください。

注 -

相互参照を使用する場合、belongsToSwitch の属性はこのテーブルと switchesTable 間のキー参照として動作します。

表 D-4 portsTable の属性

属性名 

説明 

portId

ポート ID または番号 

belongsToSwitch

このポートが属しているスイッチの名前 

connectedNode

このポートが現在接続されているノードの名前 

nodeAdapterId

このポートが接続されているノード上の SCI カードのアダプタ ID 

portStatus

ポートの状態 (Active、Inactive など) 

portLastUpdate

このエントリのポート属性のどれかが最後に変更された時刻 

lhostTable の属性

lhostTable (論理ホストテーブル) は、クラスタに構成されている各論理ホストのエントリから構成されます。lhostTable の属性については、表 D-5を参照してください。

表 D-5 lhostTable の属性

属性名 

説明 

lhostName

論理ホストの名前 

lhostMasters

論理ホストを構成しているノードの名前リスト 

lhostCurrMaster

論理ホストの現在のマスターであるノードの名前 

lhostDS

この論理ホスト上で実行されるように構成されているデータサービスのリスト 

lhostDG

この論理ホスト上に構成されているディスクグループ 

lhostLogicalIP

この論理ホストに対応する論理 IP アドレス 

lhostStatus

論理ホストの現在の状態 (UP または DOWN) 

lhostLastUpdate

このエントリの属性のどれかが最後に変更された時刻 

dsTable の属性

dsTable (データサービステーブル) は、監視対象クラスタ内のすべての論理ホストに構成されているすべてのデータサービスのエントリから構成されます。このテーブル内の各エントリには、論理ホストに構成されているデータサービスについての具体的な情報が含まれています。dsTable の属性については、表 D-6 を参照してください。

注 -

相互参照を使用する場合、dsonLhost の属性はこのテーブルと lhostTable 間のキー参照として動作します。

表 D-6 dsTable の属性

属性名 

説明 

dsName

データサービスの名前 

dsOnLhost

データサービスが構成されている論理ホストの名前 

dsReg

値は、データサービスが動作するように設定されている (1) か、動作しないように設定されている (0) 

dsStatus

データサービスの現在の状態 (ON、OFF、INST DOWN) 

dsDep

このデータサービスが依存しているほかのデータサービスのリスト 

dsPkg

データサービスのパッケージ名 

dsLastUpdate

このエントリの属性のどれかが最後に変更された時刻 

dsinstTable の属性

dsinstTable (データサービスインスタンステーブル) は、すべてのデータサービスインスタンスのエントリから構成されます。dsinstTable の属性については、表 D-7を参照してください。

注 -

相互参照を使用する場合、dsinstOfDS の属性はこのテーブルと dsTable 間のキー参照として使用できます。同様に、dsinstOnLhost 属性は、このテーブルと lhostTable 間のキー参照として使用できます。

表 D-7 dsinstTable の属性

属性名 

説明 

dsinstName

データサービスインスタンスの名前 

dsinstOfDS

このデータサービスインスタンスのデータサービスの名前 

dsinstOnLhost

このデータサービスインスタンスが動作している論理ホストの名前 

dsinstStatus

データサービスインスタンスの状態 

dsinstLastUpdate

このエントリの属性のどれかが最後に変更された時刻 

クラスタ SNMP デーモンとスーパーモニターデーモンのオペレーション

SNMP デーモンは、次の規則にもとづいて動作します。

SNMP トラップ

SNMP トラップは、監視対象オブジェクトの状態に対する意図的でない変更を示す、SNMP エージェントによって生成される非同期通知です。

このソフトウェアは、重要なクラスタイベントの Sun Cluster 固有のトラップを生成します。これらのイベントを、以下の表に示します。

表 D-8 は、ノード上のクラスタソフトウェアの状態を反映した Sun Cluster トラップを示しています。

表 D-8 ノード上のソフトウェアを反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

0 

sc:stopped

1 

sc:aborted

2 

sc:in_transition

3 

sc:included

4 

sc:excluded

5 

sc:unknown

表 D-9 は、ノード上のボリュームマネージャの状態を反映した Sun Cluster トラップを示しています。

表 D-9 ノード上のボリュームマネージャを反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

10 

vm:down

11 

vm:up

12 

vm:unknown

表 D-10 は、ノード上のデータベースの状態を反映した Sun Cluster トラップを示しています。

表 D-10 ノード上のデータベースを反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

20 

db:down

21 

db:up

22 

db:unknown

表 D-11 は、ノード上の Cluster Volume Manager (マスターまたはスレーブ) の特性を反映した Sun Cluster トラップを示しています。

表 D-11 ノード上の Cluster Volume Manager を反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

30 

vm_on_node:master

31 

vm_on_node:slave

32 

vm_on_node:unknown

表 D-12 は、論理ホストの状態を反映した Sun Cluster トラップを示しています。

表 D-12 論理ホストの状態を反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

40 

lhost:givingup

41 

lhost:given

42 

lhost:takingover

43 

lhost:taken

46 

lhost:unknown

表 D-13 は、データサービスインスタンスの状態を反映した Sun Cluster トラップを示しています。

表 D-13 データサービスインスタンスの状態を反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

50 

ds:started

51 

ds:stopped

52 

ds:in-transition

53 

ds:failed-locally

54 

ds:failed-remotely

57 

ds:unknown

表 D-14 は、HA-NFS データサービスの状態を反映した Sun Cluster トラップを示しています。

表 D-14 HA-NFS データサービスインスタンスの状態を反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

60 

hanfs:start

61 

hanfs:stop

70 

hanfs:unknown

表 D-15 は、SNMP エラーを反映した Sun Cluster トラップを示しています。

表 D-15 SNMP エラーを反映した Sun Cluster トラップ

トラップ番号 

トラップ名 

100 

SOCKET_ERROR:node_out_of_system_resources

101 

CONNECT_ERROR:node_out_of_system_resources

102 

BADMOND_ERROR:node_running_bad/old_mond_version

103 

NOMOND_ERROR:mond_not_installed_on_node

104 

NOMONDYET_ERROR:mond_on_node_not_responding:node_may_be_rebooting

105 

TIMEOUT_ERROR:timed_out_upon_trying_to_connect_to_nodes_mond

106 

UNREACHABLE_ERROR:node's_mond_unreachable:network_problems??

107 

READFAILED_ERROR:node_out_of_system_resources

108 

NORESPONSE_ERROR:node_out_of_system_resources

109 

BADRESPONSE_ERROR:unexpected_welcome_message_from_node's_mond

110 

SHUTDOWN_ERROR:node's_mond_shutdown

200 

Fatal:super_monitor_daemon(smond)_exited!

トラップ番号 100 〜 110 については、障害のあるノードを検査し、問題を修復してください。トラップ番号 200 については、「SNMP の障害追跡」を参照してください。

snmpd.conf ファイルの変更

snmpd.conf ファイルは、構成情報に使用されます。このファイルの各エントリは、キーワードと、それに続くパラメータ文字列から構成されます。通常は、ファイル内のデフォルト値で十分です。

snmpd.conf ファイルを変更するには

  1. snmpd.conf ファイルを編集します。

    キーワードの詳細は、snmpd(7) のマニュアルページを参照してください。

  2. snmpd.conf ファイルを変更した後、次のコマンドを入力して smond と snmpd プログラムを停止し、続いてこれらのスクリプトを再起動します。

    # /opt/SUNWcluster/bin/smond_ctl stop
# /opt/SUNWcluster/bin/init.snmpd stop
# /opt/SUNWcluster/bin/init.snmpd start
# /opt/SUNWcluster/bin/smond_ctl start

    次に、snmpd.conf ファイルの例を示します。

    sysdescr        Sun SNMP Agent, SPARCstation 10, Company
                              Property Number 123456
 syscontact 	Coby Phelps
 sysLocation 	Room 123
 #
 system-group-read-community     public
 system-group-write-community    private
 #
 read-community  all_public
 write-community all_private
 #
 trap            localhost
 trap-community  SNMP-trap
 #
 #kernel-file    /vmunix
 #
 managers        lvs golden

クラスタ SNMP エージェントポートの構成

デフォルトでは、クラスタ SNMP エージェントは、SNMP マネージャ (SunNet Manager Console など) の要求を、ユーザーデータグラムプロトコル (UDP) ポート 161 でリスン (listen) します。このポートは、snmpd と smond デーモンに -p オプションを使用して変更できます。

snmpd と smond デーモンを正常に機能させるには、これらのデーモンを同じポートに構成する必要があります。

注意 - 注意 -

Solaris 2.6 オペレーティング環境または互換バージョンで稼動する SSP または管理ワークステーションにクラスタ SNMP エージェントをインストールする場合は、必ずデフォルトの UDP ポート 161 以外のポートに snmpd と smond プログラムを構成してください。

たとえば SSP では、クラスタ SNMP エージェントは、同じく UDP ポート 161 を使用する SSP SNMP エージェントを妨害します。この妨害によって、Sun Enterprise 10000 サーバーの RAS 機能が失われることがあります。

クラスタ SNMP エージェントポートを構成するには

デフォルトの UDP ポート 161 以外のポートにクラスタ SNMP エージェントを構成するには、次の手順を実行します。

  1. /opt/SUNWcluster/bin/init.snmpd ファイルを編集し、CSNMP_PORT 変数の値を 161 以外の任意の値に変更します。

  2. /opt/SUNWcluster/bin/smond_ctl ファイルを編集し、CSNMP_PORT 変数の値を 手順 1で選択したものと同じ値に変更します。

  3. 変更を反映させるため、snmpd と smond デーモンの両方を停止し、続いて再起動します。

    # /opt/SUNWcluster/bin/smond_ctl stop
# /opt/SUNWcluster/bin/init.snmpd stop
# /opt/SUNWcluster/bin/smond_ctl start
# /opt/SUNWcluster/bin/init.snmpd start
    注 -

    SNMP マネージャに新しいポート番号を認識させるには、SNMP マネージャ固有の構成ファイルを編集しなければならない場合があります。詳細は、SNMP マネージャのマニュアルを参照してください。また、管理ワークステーションでマスター SNMP エージェントを構成し、クラスタ SNMP プロキシエージェントを 161 以外のポートでサブエージェントとして起動することもできます。マスター SNMP エージェントの構成方法の詳細は、『Solstice Enterprise Agents User's Guide』または snmpdx(1M) のマニュアルページを参照してください。

SunNet Manager での SNMP エージェントの使用

クラスタ SNMP エージェントは、SunNet Manager で使用できます。SunNet Manager を使用してクラスタを監視する前に、次の作業を行なってください。

注 -

これらの作業は、SNMP に UDP ポート 161 が使用されていることを想定しています。「クラスタ SNMP エージェントポートの構成」で説明しているようにポート番号を変更した場合は、そのポートを使用するために SunNet Manager SNMP プロキシエージェント na.snmp を実行する必要があります。

SunNet Manager で SNMP エージェントを使用してクラスタを監視するには

  1. SunNet Manager コンソールで、クラスタ MIB /opt/SUNWcluster/etc/sun.mib を /opt/SUNWconn/snm/agents/cluster.mib にコピーします。

  2. SunNet Manager コンソールで、コピーされた cluster.mib ファイルに対して mib2schema を実行します。

    # /opt/SUNWconn/snm/bin/mib2schema cluster.mib

  3. Sun Cluster 管理ワークステーションで、snmpd.conf ファイルを編集し、trap キーワード内のパラメータ文字列を SunNet Manager コンソールの名前に設定します。

    snmpd.conf ファイルの編集の詳細は、「snmpd.conf ファイルの変更」を参照してください。

  4. Sun Cluster 管理ワークステーションで、監視するクラスタごとに smond_conf コマンドを実行します。次に例を示します。

    # /opt/SUNWcluster/bin/smond_conf -h [clustername ...]

  5. cluster-snmp のプロキシを、SunNet Manager コンソールの名前になるように設定します。

    注 -

    クラスタを監視するには、SunNet Manager を使用して管理ワークステーションの監視も行う必要があります。

smond を再構成して別のクラスタを監視するには

smond デーモンを再構成して別のクラスタを監視できます。

  1. 次のコマンドを使用して、snmpd デーモンを停止します。

    # /opt/SUNWcluster/bin/init.snmpd stop

  2. 次のコマンドを使用して、smond デーモンを再構成します。

    # /opt/SUNWcluster/bin/smond_conf -h [clustername ...]

  3. 次のコマンドを使用して、snmpd デーモンを起動します。

    # /opt/SUNWcluster/bin/init.snmpd start

  4. 次のコマンドを使用して、smond デーモンを起動します。

    # /opt/SUNWcluster/bin/smond_ctl start

SNMP の障害追跡

アプリケーションにクラスタ MIB テーブルが書き込まれていないか、トラップ番号 200 を受ける場合は、次のコマンドを実行して snmpd と smond デーモンが動作していることを確認してください。

# ps -ef | grep snmpd
# ps -ef | grep smond

これらのデーモンが動作していない場合、出力は行われません。

デーモンが動作していない場合、次のコマンドを入力してください。

# /opt/SUNWcluster/bin/init.snmpd start
# /opt/SUNWcluster/bin/smond_ctl start