test

Sun Cluster 2.2 のシステム管理

パート I Sun Cluster の管理

Sun Cluster の管理の準備

この章では、Sun Cluster 構成の管理を行うための準備作業について説明します。この章に示す作業の一部は、使用しているボリューム管理ソフトウェア (Solstice DiskSuite、Sun StorEdge Volume Manager、Cluster Volume Manager) によって異なります。ボリュームマネージャによって作業方法が異なる場合は、作業のタイトルにボリュームマネージャ名が示されています。

ディスクパーティション情報の保存 (Solstice DiskSuite)

すべてのノードと多重ホストディスクのディスクパーティション情報を Sun Cluster 構成で管理し、ディスクセットに新しいディスクを追加する場合やディスクのパーティションを変更する場合には、この情報が最新に保たれるように更新してください。ディスクを交換する場合にこの情報が必要になります。

すべての Sun Cluster ノード上のローカルディスクは同じようにパーティション分割されるため、ローカルディスクのパーティション情報はあまり重要ではありません。ローカルディスクに障害が発生した場合は、通常、ほかの Sun Cluster ノードからパーティション情報を取り出せます。

多重ホストディスクを交換する場合、交換用ディスクのパーティション構成はもとのディスクと同じでなければなりません。ディスクの障害が発生した状況によっては、ディスクの交換時にこのパーティション情報が入手できない場合があります。そのため、ディスクセット内で異なる複数のパーティション方式を使用している場合は、ディスクパーティション情報の記録を残すことが特に重要になります。

注 -

SSVM と CVM にはこの制限はありませんが、これらのボリュームマネージャを使用する場合もディスクパーティション情報を保存することを推奨します。

ディスクパーティション情報を保存する簡単な方法を、次のスクリプト例に示します。このようなスクリプトは Sun Cluster ソフトウェアを構成した後で実行してください。この例では、ボリューム構成テーブル (VTOC) 情報が入ったファイルは、prtvtoc(1M) コマンドによってローカルディスクの /etc/opt/SUNWcluster/vtoc ディレクトリに書き込まれます。

例 1-1 VTOC 情報を保存するスクリプト例

#! /bin/sh
 DIR=/etc/opt/SUNWcluster/vtoc
 mkdir -p $DIR
 cd /dev/rdsk
 for i in *s7
 do prtvtoc $i >$DIR/$i || rm $DIR/$i
 done

Solstice DiskSuite ディスクセット内の各ディスクには、Slice 7 がなければなりません。このスライスには、メタデバイス状態データベースの複製が入っています。

ローカルディスクにも有効な Slice 7 が存在する場合、例 1-1のスクリプト例の実行によって VTOC 情報も保存されます。ただし、起動ディスクは、通常、有効な Slice 7 が存在しないため VTOC 情報は保存されません。

注 -

このスクリプトは、どのディスクもほかの Sun Cluster ノードに所有されていないときに実行してください。このスクリプトが正常に動作するのは、論理ホストが保守モードにあるか、論理ホストがローカルホストに所有されているか、Sun Cluster が動作していない場合だけです。

VTOC 情報の保存と復元 (Solstice DiskSuite)

すべての多重ホストディスクの VTOC 情報を保存すると、この情報を使用してディスクを交換できます。次のコード例に示したスクリプト例は、例 1-1 のスクリプトで保存された VTOC 情報を使用して、交換用ディスクに、障害が発生したディスクと同じパーティションを作成します。この例の c1t0d0s7 と c1t0d1s7 は、追加するディスクの実際の名前に置き換えてください。ディスクを複数指定する場合は、空白で区切って入力します。

例 1-2 VTOC 情報を復元するスクリプト例

#! /bin/sh
 DIR=/etc/opt/SUNWcluster/vtoc
 cd /dev/rdsk
 for i in c1t0d0s7 c1t0d1s7
 do fmthard -s $DIR/$i $i
 done
注 -

交換用ドライブのサイズと構成は、障害が発生したドライブと同じでなければなりません (一般には同じメーカーの同じモデル)。サイズと構成が異なると、本来の VTOC が交換用ドライブに適さない場合があります。

この VTOC 情報を記録していなくても、スライスをディスクごとにミラー化してある場合は (両方のミラーの VTOC が同じ場合など)、ほかのサブミラーディスクから交換用ディスクに VTOC 情報をコピーできます。この処理を確実に行うためには、交換用ディスクが保守モードであるか、交換用ディスクが障害が発生したディスクと同じホストに所有されているか、Sun Cluster が停止していなければなりません。この処理を次の例に示します。

例 1-3 ミラーから VTOC 情報をコピーするスクリプト例


#! /bin/sh
 cd /dev/rdsk
 OTHER_MIRROR_DISK=c2t0d0s7
 REPLACEMENT_DISK=c1t0d0s7
 prtvtoc $OTHER_MIRROR_DISK | fmthard -s - $REPLACEMENT_DISK

VTOC 情報を保存せず、ディスクごとのミラーも作成しなかった場合には、metaset(1M) コマンドでコンポーネントサイズを確認し、VTOC 情報のリバースエンジニアを行えます。この作業の算定は複雑なため、熟練したサービス担当者以外はこの作業を行わないでください。

デバイス構成情報の保存

/etc/path_to_inst と /etc/name_to_major 情報を、着脱式媒体 (フロッピーディスクやバックアップテープ) に記録してください。

path_to_inst(4) ファイルには、各多重ホストディスク拡張装置内のディスクのマイナー装置番号が入っています。この情報は、Sun Cluster ノードの起動ディスクに障害が発生して交換しなければならない場合に必要となります。

インスタンス名と番号付け

ドライバエラーメッセージに、インスタンス名が報告される場合があります。インスタンス名は、ssd20 や hme5 のようなシステムデバイスを示します。

物理名に割り当てられているインスタンス名は、/var/adm/messages または dmesg(1M) の出力で確認できます。

ssd20 at SUNW,pln0:
 ssd20 is /io-unit@f,e0200000/sbi@0,0/SUNW,soc@3,0/SUNW,pln@a0000800,20183777 ¥
 /ssd@4,0

 le5 at lebuffer5: SBus3 slot 0 0x60000 SBus level 4 sparc ipl 7
 le5 is /io-unit@f,e3200000/sbi@0,0/lebuffer@0,40000/le@0,60000

インスタンス名は、いったんあるデバイスに割り当てられると、そのデバイスにバインドされた状態になります。

インスタンス番号は、デバイスのマイナー番号にコード化されます。再起動が繰り返されてもインスタンス番号が同じに保たれるように、システムはこの番号を /etc/path_to_inst ファイルに記録します。起動時にだけ読み込まれるこのファイルは、add_drv(1M) コマンドと drvconfig(1M) コマンドで最新に更新できます。詳細は、path_to_inst(4) のマニュアルページを参照してください。

ノードに Solaris オペレーティング環境をインストールする場合、前回の Solaris インストール以降にハードウェアの追加または削除が行われていると、インスタンス番号が変わる可能性があります。このため、Sun Cluster ノードに SBus や FC/OM カードなどのデバイスを追加する場合、あるいは Sun Cluster ノードからこれらのデバイスを削除する場合は注意してください。再インストールまたは再構成再起動が行われる際にシステムが混乱しないように、既存のデバイスの構成は同じに保つ必要があります。

構成内で、インスタンス番号の問題が発生する場合があります。例として、各ノードの SBus スロット 1、2、4 に Fibre Channel/SBus (FC/S) カードが入った 3 つの SPARCstorageTM Array から成る Sun Cluster 構成を考えてみましょう。コントローラ番号は、c1、c2、c3 になります。システム管理者が SBus スロット 3 の FC/S カードを使用し、この構成に別の SPARCstorage Array を追加すると、対応するコントローラ番号は c4 になります。これらのノードの 1 つで Solaris が再インストールされると、コントローラ番号 c3 と c4 は別々の SPARCstorage Array を参照するようになります。ほかの Sun Cluster ノードは、依然として元のインスタンス番号で SPARCstorage Array を参照します。Solstice DiskSuite は、c3 と c4 コントローラに接続されたディスクと通信を行わなくなります。

Ethernet 接続のインスタンス番号でも問題が発生する可能性があります。たとえば、各 Sun Cluster ノードのスロット 1、2、3 に Ethernet SBus カードが入っており、インスタンス番号が hme1、hme2、hme3 であるとします。中央のカード (hme2) が取り除かれて Solaris が再インストールされると、3 つ目の SBus カード名は hme3 から hme2 に変わります。

再構成再起動の実行

このマニュアルで説明している管理作業の中には、OpenBootTM PROM の boot -r コマンドを使用するか、ノード上に /reconfugure ファイルを作成した後で再起動することによって再構成再起動を行うものがあります。

注 -

既存の多重ホストディスク拡張装置にディスクを追加する場合は、再構成再起動を行う必要はありません。

電源が切れているか障害のあるハードウェア (特に多重ホストディスク拡張装置またはディスク) が存在する場合は、Solaris 再構成再起動は行わないでください。このような場合に再構成再起動を行うと、そのディスクデバイスに対応した /devices 内の i ノードと、/dev/dsk および /dev/rdsk 内のシンボリックリンクが削除されます。その後再構成再起動が行われるまで、それらのディスクは Solaris にアクセスできなくなります。後続の再構成再起動ではコントローラの本来のマイナー装置番号が復元されないことがあり、そのためボリュームマネージャがディスクへのアクセスを拒否することがあります。本来の番号が復元されると、ボリュームマネージャソフトウェアは対応したオブジェクトにアクセスできるようになります。

すべてのハードウェアに障害がなければ、再構成再起動を正常に行い、ノードにディスクコントローラを追加できます。コントローラは、両方のノードに対して対称的になるように追加してください (ノードをアップグレードする間の一時的な非対称的な状態は可)。また、すべてのハードウェアに障害がなければ、再構成再起動を正常に行い、ハードウェアを削除できます。

注 -

Sun StorEdge A3000 では、単一のコントローラに障害が発生した場合、障害が発生したコントローラをできるかぎり速やかに交換する必要があります。通常 boot -r を必要とするほかの管理作業 (新しい SCSI デバイスを追加した後など) は、障害が発生したコントローラが交換されてオンラインに戻され、かつすべての論理ユニット番号 (LUN) がフェイルオーバーが発生する以前のバランスのとれた状態に戻るまで延期することをお勧めします。詳細は、Sun StorEdge A3000 のマニュアルを参照してください。

root でサーバーにログインする

コンソール以外の端末から Sun Cluster ノードに root としてログインする場合は、/etc/default/login ファイルを編集して次の行をコメントアウトする必要があります。 

CONSOLE=/dev/console

これにより、rlogin(1)、telnet(1) などのプログラムによる root ログインが可能になります。

Sun Cluster の管理ツール

この章では、次の項目について説明します。

This chapter includes the following procedures:

Sun Cluster ソフトウェアの管理は、次の 3 つのグラフィカルユーザーインタフェース (GUI) を使用して行えます。

クラスタコントロールパネル (CCP) - クラスタコンソールなどのシステム管理ツールを起動します。

クラスタコンソール (CC) - クラスタ管理を簡潔化するために、クラスタ内の複数のノードで同時にコマンドを実行します。

Sun Cluster Manager (SCM) - HotJava ブラウザを介して、クラスタ内のすべてのノードの現在の状態を監視します。

これらの GUI の詳細は、オンラインヘルプを参照してください。Sun Cluster ソフトウェアの監視は、ユーティリティを使用しても行えます。

監視ユーティリティ

Sun Cluster 構成の監視を行うには、/var/adm/messages ファイルのほかに、Sun Cluster の hastat(1M) ユーティリティも使用できます。また、主要なクラスタコンポーネントとサブコンポーネントの状態を表示する Sun Cluster Manager GUI も使用できます。Sun Cluster Manager の詳細は、「Sun Cluster Manager による Sun Cluster サーバーの監視 」を参照してください。Sun Cluster には、同時に最大 32 のクラスタを監視できる SNMP エージェントもあります。詳細は、付録 D 「Sun Cluster SNMP の使用」を参照してください。

Solstice DiskSuite が稼動している場合は、ディスクセットの状態監視に metastat(1M)、metadb(1M)、metatool(1M)、medstat(1M)、mdlogd(1M) ユーティリティも使用できます。SNMP ベースの Solstice DiskSuite ログデーモン、mdlogd(1M) は、Solstice DiskSuite が syslog ファイルにメッセージを記録する際に一般的な SNMP トラップを生成します。mdlogd.cf(4) 構成ファイルに正規表現を指定することにより、特定のメッセージが記録される場合だけ mdlogd(1M) がトラップを送信するように構成できます。トラップは、mdlogd.cf(4) 構成ファイルに指定された管理ホストに送信されます。管理ホストでは、Solstice SunNet ManagerTM のようなネットワーク管理アプリケーションが実行されていなければなりません。Solstice DiskSuite のエラーや警告を見つけるために定期的に metastat(1M) を実行したり、syslog 出力をスキャンしたりするのを避けたい場合は、mdlogd(1M) を使用できます。詳細は、mdlogd(1M) のマニュアルページを参照してください。

SSVM または CVM が稼動している場合は、vxprint、vxstat、vxtrace、vxnotify、vxva ユーティリティを使用できます。これらのユーティリティの詳細は、使用しているボリューム管理ソフトウェアのマニュアルを参照してください。

注 -

障害のあるコンポーネントの障害追跡と修復の詳細は、該当するハードウェアマニュアルを参照してください。

hastat(1M) による構成の監視

hastat(1M) プログラムは、構成の現在の状態を表示します。表示されるのは、ホスト、論理ホスト、プライベートネットワーク、パブリックネットワーク、データサービス、ローカルディスク、ディスクセットの状態に関する情報と、最新のエラーメッセージです。hastat(1M) プログラムは、/var/adm/messages ファイルから Sun Cluster 関連のエラーメッセージを抽出し、-m が指定されている場合は各ホストの最後の数メッセージを出力します。最新のエラーメッセージリストはログメッセージからの抜粋であるため、メッセージによっては前後関係がわからなくなることもあります。完全なメッセージリストは、/var/adm/messages ファイルで確認してください。次に、hastat(1M) の出力例を示します。 

# hastat -m 10

 HIGH AVAILABILITY CONFIGURATION AND STATUS
 -------------------------------------------

 LIST OF NODES CONFIGURED IN <ha-host1> CLUSTER
       phys-host1 phys-host2

 CURRENT MEMBERS OF THE CLUSTER

      phys-host1 is a cluster member

      phys-host2 is a cluster member

 CONFIGURATION STATE OF THE CLUSTER

      Configuration State on phys-host1: Stable

      Configuration State on phys-host2: Stable

 UPTIME OF NODES IN THE CLUSTER

      uptime of phys-host1:         12:47pm  up 12 day(s), 21:11,  1 user,
 load average: 0.21, 0.15, 0.14

      uptime of phys-host2:         12:46pm  up 12 day(s),  3:15,  3 users,
 load average: 0.40, 0.20, 0.16

 LOGICAL HOSTS MASTERED BY THE CLUSTER MEMBERS

 Logical Hosts Mastered on phys-host1:
         ha-host-1
 Loghost Hosts for which phys-host1 is Backup Node:
         ha-host2

 Logical Hosts Mastered on phys-host2:
         ha-host2
 Loghost Hosts for which phys-host2 is Backup Node:
         ha-host1

 LOGICAL HOSTS IN MAINTENANCE STATE

      None

 STATUS OF PRIVATE NETS IN THE CLUSTER

      Status of Interconnects on phys-host1:
         interconnect0: selected
         interconnect1: up
      Status of private nets on phys-host1:
         To phys-host1 - UP
         To phys-host2 - UP

      Status of Interconnects on phys-host2:
         interconnect0: selected
         interconnect1: up
      Status of private nets on phys-host2:
         To phys-host1 - UP
         To phys-host2 - UP

 STATUS OF PUBLIC NETS IN THE CLUSTER

 Status of Public Network On phys-host1:

 bkggrp  r_adp   status  fo_time live_adp
 nafo0   le0     OK      NEVER   le0

 Status of Public Network On phys-host2:

 bkggrp  r_adp   status  fo_time live_adp
 nafo0   le0     OK      NEVER   le0

 STATUS OF SERVICES RUNNING ON LOGICAL HOSTS IN THE CLUSTER

        Status Of Registered Data Services
        q:                       Off
        p:                       Off
        nfs:                     On
        oracle:                  On
        dns:                     On
        nshttp:                  Off
        nsldap:                  On

       Status Of Data Services Running On phys-host1
       Data Service HA-NFS:
       On Logical Host ha-host1:      Ok
     
       Status Of Data Services Running On phys-host2
       Data Service HA-NFS:
       On Logical Host ha-host2:      Ok
       
        Data Service "oracle":
        Database Status on phys-host2:
        SC22FILE - running;

        No Status Method for Data Service "dns"

        RECENT  ERROR MESSAGES FROM THE CLUSTER

        Recent Error Messages on phys-host1
        ...
        Recent Error Messages on phys-host2
        ...

メッセージファイルの確認

Sun Cluster ソフトウェアは、コンソールにメッセージを出力するほかに、/var/adm/messages ファイルにメッセージを書き込みます。次に、ディスクエラーが発生した時に報告されるメッセージ例を示します。 

...
 Jun 1 16:15:26 host1 unix: WARNING: /io-unit@f,e1200000/sbi@0.0/SUNW,pln@a0000000,741022/ssd@3,4(ssd49):  
 Jun 1 16:15:26 host1 unix: Error for command `write(I))' Err
 Jun 1 16:15:27 host1 unix: or Level: Fatal
 Jun 1 16:15:27 host1 unix: Requested Block 144004, Error Block: 715559
 Jun 1 16:15:27 host1 unix: Sense Key: Media Error
 Jun 1 16:15:27 host1 unix: Vendor `CONNER':
 Jun 1 16:15:27 host1 unix: ASC=0x10(ID CRC or ECC error),ASCQ=0x0,FRU=0x15
 ...
注 -

Solaris と Sun Cluster の両方のエラーメッセージが /var/adm/messages ファイルに書き込まれるために、/var ディレクトリが満杯になることがあります。この問題を修正する方法については、「/var ファイルシステムの管理」を参照してください。

高可用性データサービスのためのユーティリティ

Sun Cluster には、高可用性データサービスの構成と管理を行うユーティリティもあります。次に、これらのユーティリティを示します。詳細は、付録 B 「Sun Cluster マニュアルページのクイックリファレンス」を参照してください。

オンラインヘルプシステム

各 Sun Cluster 管理ツールには、詳しいオンラインヘルプがあります。このオンラインヘルプにアクセスするには、管理ワークステーションから管理ツールを起動し、メニューバーの「ヘルプ」を選択します。

「クラスタコントロールパネル」の「ヘルプ」アイコンをダブルクリックして表示することもできます。

ヘルプトピックには、管理作業の説明のほかに管理ツールの詳細についての説明もあります。特定の作業の詳しい操作説明については、第 4 章「一般的な Sun Cluster の管理」も参照してください。

図 2-1 は、「クラスタコントロールパネル」の「ヘルプ」ウィンドウの例を示しています。テキストは、特定のトピックを説明したものです。ツールから「ヘルプ」ウィンドウを初めて開いた時には、トップレベルのホームトピックが表示されます。その後は、表示された最後のトピックが表示されます。ほかのトピックに対するハイパーテキストリンクは、下線が引かれた色付きのテキストとして示されます。

ハイパーテキストリンクをクリックすると、そのトピックのテキストが表示されます。オンラインヘルプシステムには、以前にアクセスされた情報を記憶する自動履歴リスト機能もあります。このリストを表示するには、「表示」メニューの「トピックの履歴」を選択します。

「ヘルプ」ウィンドウには、スクロール可能なテキスト領域、メニューバー、ボタンなどがあります。これらの項目については、以下の各節で説明します。

図 2-1 クラスタコントロールパネルの「ヘルプ」ウィンドウの例

Graphic

ヘルプでは、次の方法で各プルダウンメニューを表示できます。

ニモニックとショートカットキーはカスタマイズできます。詳細は、オンラインヘルプを参照してください。

この節の表は、各メニュー項目、メニュー機能、ショートカットキー (キーの組み合わせ) を示しています。

「ヘルプ」ウィンドウのメニューバー項目

「ヘルプ」ウィンドウメニューには、メニュー項目として「ファイル」、「表示」、「ヘルプ」があります。これらのメニューの項目を表示するには、そのメニューを選択します。

「ファイル」メニュー

「ファイル」メニューには、次の項目があります。

表 2-1 「ファイル」メニューの項目

項目 

機能 

ショートカットキー 

トピックを印刷 

「ヘルプ」ウィンドウのスクロールテキスト領域に現在表示されているトピックを印刷する 

Alt + R 

取り消し 

「ヘルプ」ウィンドウを閉じる 

Alt + D 

「表示」メニュー

「表示」メニューには、次の項目があります。

表 2-2 「表示」メニューの項目

項目 

機能 

ショートカットキー 

前のトピック 

直前のヘルプトピックを表示する (存在する場合) 

Alt + P 

次のトピック 

次のヘルプトピックを表示する (存在する場合) 

Alt + N 

ホームトピック 

ホーム (トップレベル) トピックを表示する 

Alt + O 

トピックの履歴... 

すでに表示したヘルプトピックを簡単にナビゲートできる「ヘルプトピックの履歴」ダイアログボックスを表示する。スクロールリスト内の先頭のトピックは、表示された最初のトピック。最後のトピックは、現在のパスで表示された最後のトピック。強調表示されたトピックは現在のトピック。 

Alt + I 

ダイアログボックスを表示するには、「トピックの履歴...」を選択します (図 2-2)。

図 2-2 「ヘルプ」ウィンドウの「ヘルプトピックの履歴」

Graphic

「ヘルプ」メニュー

「ヘルプ」メニューには、次の項目があります。

表 2-3 「ヘルプ」メニューの項目

項目 

機能 

ショートカットキー 

ヘルプの使い方...  

「ヘルプ」ウィンドウとその使用方法について説明する  

Alt + E 

概要... 

 

バージョン番号などのアプリケーション情報が入った「概要」を表示する 

Alt + B 

「ヘルプ」ウィンドウのボタン

次の表は、「ヘルプ」ウィンドウのボタンとそれらの機能を示しています。

表 2-4 「ヘルプ」ウィンドウのボタン

ボタン 

機能 

ホーム 

そのアプリケーションのホームページを表示する 

取り消し 

「ヘルプ」ウィンドウを閉じる 

トピックを印刷 

デフォルトプリンタに現在のトピックを印刷する 

前へ

直前に表示されたトピックに戻る。この左向きの矢印を繰り返しクリックすると、最終的に、ユーザーが表示した最初のトピックに戻る。トピックは、自動的にヘルプ履歴のリストに記録される。 

次へ

表示済みのヘルプトピック内を一度に 1 つずつ前方へ進み、最終的に履歴リスト内の最後のトピックが表示される。 

クラスタコントロールパネル (CCP) について

「クラスタコントロールパネル」 (CCP) は、「クラスタコンソール」などのシステム管理ツールを起動するための GUI です。CCP には、これらのツールを示すアイコンがあります。

CCP を起動するには

管理ワークステーションに Sun Cluster クライアントソフトウェアをインストールした後に CCP からアプリケーションを実行するには、次の方法を使用してください。

  1. スーパーユーザーになり、Sun Cluster ツールディレクトリ /opt/SUNWcluster/bin を管理ワークステーションのパスに追加します。

    注 -

    Sun Enterprise 10000 の場合、最初に システムサービスプロセッサ (SSP) にログインし、netcon コマンドを使用して接続する必要があります。接続が完了したら、Shift + @ キーを入力してコンソールのロックを解除し、書き込み権を取得します。その後で手順 2 に進んでください。

  2. ワークステーションのシェルウィンドウで、CCP を起動します。

    監視するクラスタの名前を指定します。 

    # ccp clustername
    注 -

    Sun Cluster ツールがデフォルトの /opt/SUNWcluster 以外の場所にインストールされている場合は、環境変数 $CLUSTER_HOME をその場所に設定する必要があります。

CCP の項目

CCP (次の図を参照) には、メニューバーと、このコントロールパネルに現在あるツールをすべて表示したアイコン区画があります。メニューバーを使用して、ツールの追加、削除、変更を行えます。

図 2-3 クラスタコントロールパネルの例

Graphic

「ファイル」メニューまたは「属性」メニューを使用して、次の作業が行えます。

CCP の詳細は、オンラインヘルプを参照してください。

ツールとその使用方法については、「クラスタコンソールについて」を参照してください。HotJava ブラウザを使用してクラスタ構成を監視する方法については、「Sun Cluster Manager による Sun Cluster サーバーの監視 」を参照してください。

CCP 構成ファイルの場所

CCP は、属性などの情報を、構成ディレクトリ内の構成ファイルに格納します。デフォルトの構成ディレクトリは、/opt/SUNWcluster/etc/ccp です。

注 -

このディレクトリに書き込みを行うには、root (スーパーユーザー) でなければなりません。この構成ディレクトリ内の項目の追加、削除、変更が行えるのは root だけです。

また、独自の構成ディレクトリを作成し、環境変数 $CCP_CONFIG_DIR を使用してその位置を定義できます。$CCP_CONFIG_DIR 変数は、項目プロパティが入った構成ファイルが格納される構成ディレクトリを示します。パス名が設定されないと、/opt/SUNWcluster/etc/ccp がデフォルトで使用されます。独自の構成ディレクトリを作成するには、新しいディレクトリを作成し、環境変数 $CCP_CONFIG_DIR を新しいディレクトリの完全パス名に設定します。

これらのファイルは、項目の作成、変更、削除があるたびに ccp によって作成、変更、削除されます。そのため、これらのファイルを手動で編集する必要はありません。

クラスタコンソールについて

「クラスタコンソール」(CC) GUI を使用すると、複数のノードで同時にコマンドを実行し、クラスタ管理を簡潔化できます。クラスタコンソールは、クラスタノードごとに 1 つの端末ウィンドウと、すべてのウィンドウを同時に制御できる共通ウィンドウを表示します。

さまざまな遠隔セッションにより、ホストのコンソールに接続したり、rlogin または telnet を使用して遠隔でログインしたりできます。ホストは、コマンド行で指定でき、プログラムを実行した後で「ホストを選択」ダイアログボックスで追加または削除が行えます。セッションタイプは、コマンド行でしか指定できません。いったん開始すると、セッションタイプは変更できません。

共通ウィンドウでは複数のホストに対してコマンドを発行でき、端末ウィンドウでは単一のホストに対してコマンドを発行できます。端末ウィンドウは、VT100 端末エミュレーションを使用します。

アクセスするホスト以外のすべてのホストを「ホスト」メニューで切断し、その後共通ウィンドウのテキストフィールドでコマンドを発行することもできます。

クラスタコンソールを起動するには

クラスタコンソールは、CCP (「クラスタコントロールパネル (CCP) について」)、またはシェルウィンドウのコマンド行から起動できます。オプションパラメータを指定すると、クラスタ内のホストまたは指定されたホストごとに端末ウィンドウが作成されます。

    cconsole と入力して、遠隔コンソールアクセスを開始します。 

% cconsole [clustername | hostname...]

    ctelnet と入力して、コンソールからの telnet(1) 接続を確立します。 

% ctelnet [clustername | hostname...]

    自分のユーザー名を使用して crlogin を起動し、コンソールからの rlogin(1) 接続を確立します。 

% crlogin -l user name [clustername | hostname...]

上記の 3 つのコマンドはすべて、標準の X/Motif コマンド行引数も受け付けます。クラスタコンソールが起動すると、「クラスタコンソール」ウィンドウが表示されます。

クラスタコンソールの詳細は、オンラインヘルプを参照してください。

共通ウィンドウのメニューバー

共通ウィンドウ (次の図を参照) は、入力をすべてのノードに送信するために使用される主要なウィンドウです。共通ウィンドウは、クラスタコンソールの起動時に常に表示されます。

図 2-4 図 2-4 クラスタコンソールの共通ウィンドウのメニューバー

Graphic

ウィンドウには、3 つのメニューがあるメニューバーと、コマンドを入力するためのテキストフィールドがあります。「ホスト」メニューでは、「ホストを選択」ダイアログボックスを使用して次の作業が行えます。

「オプション」メニューでは、共通ウィンドウと端末ウィンドウのグループ化とグループ化の解除が行えます。

クラスタコンソールが使用する構成ファイル

クラスタコンソールは、2 つの構成ファイル、clusters と serialports を使用します。これらは、/etc ファイルか NIS/NIS+ データベースのどちらかです。NIS+ 環境を使用する利点は、クラスタコンソールを複数の管理ワークステーションで実行できることです。詳細は、NIS/NIS+ のシステム管理マニュアルを参照してください。

clusters ファイルについて

clusters ファイルは、クラスタ名を、そのクラスタを構成するホスト名に対応付けたものです。次の例に示すように、このファイルの各行はクラスタを 1 つ指定します。 

planets      mercury venus earth mars
 wine         zinfandel merlot chardonnay riesling

clusters ファイルは、クラスタコンソールの 3 つのセッションタイプすべて (cconsole、ctelnet、crlogin) に使用されます。これらのセッションは、このファイルを使用して、コマンド行または「ホストを選択」ダイアログボックスでクラスタ名をホスト名に対応付けます。詳細は、「clusters ファイルの変更」を参照してください。

serialports ファイルについて

serialports ファイルは、ホスト名を、端末集配信装置とホストが接続される端末集配信装置シリアルポートに対応付けたものです。このデータベースの各行は、ホストのシリアルポートを 1 つ示します。

次に、Sun Enterprise 10000 の serialports ファイルデータベース例を示します。

mercury    systemserviceprocessorname    23
 venus      systemserviceprocessorname    23
 earth      systemserviceprocessorname    23
 mars       systemserviceprocessorname    23

次に、ほかのノードの serialports ファイルデータベースの例を示します。

mercury        planets-tc   5002
 venus          planets-tc   5003
 earth          planets-tc   5004
 mars           planets-tc   5005

serialports ファイルは、クラスタコンソールの cconsole セッションだけに使用されます。cconsole セッションは、このファイルを使用して、コマンド行または「ホストを選択」ダイアログボックスに指定されたホストまたはクラスタのために、どの端末集配信装置とポートを接続するかを決定します。

前述の例では、ノード mercury は planets-tc ポート 2 に接続されており、ノード venus は planets-tc ポート 3 に接続されています。ポート 1 は、端末集配信装置の管理用として予約されています。

詳細は、「serialports ファイルの変更」を参照してください。

Sun Cluster Manager による Sun Cluster サーバーの監視

Sun Cluster Manager (SCM) は、Sun Cluster のコマンド行監視機能の多くに単一のインタフェースを提供します。SCM は、SCM サーバーソフトウェアと SCM グラフィカルユーザーインタフェース (GUI) から構成されます。SCM サーバーは、クラスタ内の各ノードで動作します。SCM GUI は、HotJava のような Java Development Kit (JDK) 準拠のブラウザで動作します。HotJava ブラウザは、クラスタノードを始めとするどのマシンでも動作します。SCM GUI は、次の情報を報告します。

HotJava ブラウザでの SCM GUI の実行

この節では、HotJava ブラウザで SCM を実行する場合に必要な作業の概要を示します。

必要に応じて、次のプログラムのバージョンが適切かどうかを確認してください。

注 -

Solaris 2.6 または Solaris 7 オペレーティングシステムに付属の HotJava ブラウザを使用する場合は、メニューの使用で問題が発生する可能性があります (メニュー選択後その選択がブラウザに表示されたままになるなど)。ソフトウェア要件の詳細は、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

ソフトウェア要件の詳細は、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

次のことを行うかどうかを決定する必要があります。

これらの決定に応じて、該当する作業を参照してください。

JDK のバージョンを確認するには

    クラスタのサーバーで、コンソールプロンプトから次のコマンドを入力します。

java -version

ソフトウェア要件の詳細は、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

HotJava のバージョンを確認するには

    HotJava を実行しているマシンで、HotJava ブラウザの「ヘルプ」メニューから「HotJava について...」を選択します。

ソフトウェア要件の詳細は、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

クラスタノードから HotJava ブラウザの SCM アプレットを実行するには

  1. クラスタ内のノードで、HotJava ブラウザを実行します。

  2. X Window ワークステーションで、HotJava ブラウザを遠隔表示します。

  3. HotJava ブラウザで、アプレットのセキュリティについて設定します。

  4. 「編集」メニューの「ユーザ設定」から「アプレットのセキュリティ...」を選択します。

  5. 「署名のないアプレットのデフォルト設定」として、「中セキュリティ」をクリックします。

  6. SCM によるクラスタ監視を開始する用意ができた時点で、該当する URL を入力します。

    file:/opt/SUNWcluster/scmgr/index.html

  7. ブラウザが起動されているクラスタノードのファイル、ポートなどに遠隔のディスプレイワークステーションからアクセスする権限を求めるダイアログボックスが表示されますが、すべてにおいて「OK」をクリックします。

    注 -

    HotJava によるアプレットのダウンロードと実行は時間がかかることがあります。この間、状態情報は表示されません。

    メニュー間のナビゲーション、およびメニューによる作業と照会の詳細は、オンラインヘルプを参照してください。

SCM で動作するように Web サーバーを設定するには

必要に応じて、クラスタノード上に Web サーバーをインストールして、SCM で動作させることができます。

  1. HTML 2.0 以降をサポートする Web サーバーをクラスタ内のすべてのノードにインストールします。

    Web サーバーには、http://www.sun.com/solaris/webserver からダウンロードできる Sun Web Server などがあります。

    注 -

    SCM で HA-HTTP サービスと HTTP サーバーを稼動させる場合、HTTP サーバーが個別のポートで待機 (listen) するように構成する必要があります。同一のポートを使用すると、2 者間でポートの衝突が発生します。

  2. Web サーバーの構成作業に従って、SCM の index.html ファイルがクライアントからアクセス可能であることを確認します。

    SCM のクライアントアプレットは、/opt/SUNWcluster/scmgr ディレクトリの index.html ファイルに入っています。

    たとえば、HTTP サーバーのドキュメントルートに移動し、/opt/SUNWcluster/scmgr ディレクトリに対するリンクを作成します。

  3. 管理ワークステーションから HotJava ブラウザを実行します。

  4. HotJava ブラウザで、アプレットのセキュリティについて設定します。

    1. 「編集」メニューの「ユーザ設定」から「アプレットのセキュリティ...」を選択します。

    2. 「署名のないアプレットのデフォルト設定」として、「中セキュリティ」をクリックします。

  5. SCM によるクラスタ監視を開始する用意ができた時点で、該当する URL を入力します。

    http://cluster node/scmgr/index.html

  6. ブラウザが起動されているクラスタノードのファイル、ポートなどに遠隔のディスプレイワークステーションからアクセスする権限を求めるダイアログボックスが表示されますが、すべてにおいて「OK」をクリックします。

    注 -

    HotJava によるアプレットのダウンロードと実行は時間がかかることがあります。この間、状態情報は表示されません。

    メニュー間のナビゲーション、およびメニューによる作業と照会の詳細は、オンラインヘルプを参照してください。

SCM オンラインヘルプシステム

SCM オンラインヘルプを表示するには

    SCM から「ヘルプ」ウィンドウを表示するには、「ヘルプの内容」を選択します。

フォルダの上部にあるツールバーで「ヘルプ」アイコンをクリックして表示することもできます。

必要に応じて、次の URL を入力して、別のブラウザでオンラインヘルプを実行することも可能です。

file:/opt/SUNWcluster/scmgr/help/locale/ja/main.howtotopics.html

Sun Cluster 構成の変更

この章では、次の項目について説明します。

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

クラスタノードの追加と削除

クラスタノードの追加または削除を行う場合は、Sun Cluster ソフトウェアを再構成する必要があります。クラスタの最初のインストールで、scinstall(1M) コマンドによりクラスタ内の「アクティブ」ノードの数と「潜在」ノードの数が指定されます。この節の作業は、潜在ノードの追加とアクティブノードの削除をする場合に行なってください。

潜在ノードとしてまだ指定されていなノードを追加するには、クラスタ全体を停止し、再構成する必要があります。

クラスタノードを追加するには

この作業は、最初のインストールですでに「潜在」と指定されたノードに対してだけ行なってください。

  1. scinstall(1M) コマンドを使用して、追加するノード上に Sun Cluster 2.2 をインストールします。

    『Sun Cluster 2.2 ソフトウェアのインストール』で説明しているインストール作業を行なってください。ただし、scinstall(1M) プロンプトに応答する場合は、次の点に注意してください。

    • アクティブノードの数を入力するプロンプトには、現在追加しようとしているノードも合計に含めてください。

    • 新しいクラスタノード数は 3 つ以上になります。そのため、クラスタ構成データベース (CCD) の共有情報のプロンプトは表示されません。

    • (直接接続デバイスを使用した SSVM のみ) ノードロックポートのプロンプトでは、指定されたノードロックデバイスとポートを入力してください。

    • (SSVM のみ) 定足数デバイスのプロンプトでは、定足数デバイスを選択しないでください。代わりに、complex モードを選択し、続いて -N を選択してください。定足数デバイスの構成は、後で scconf -q コマンドを使用して行います。

    • (SSVM のみ) クラスタの分割動作を選択するために、ask を選択してください。

  2. (SCI のみ) sm_config テンプレートファイルを更新して、新しいノードの情報を検証します。

    この手順は、Ethernet 構成では不要です。

    最初のインストールで「潜在」と指定されたノードは、それらのホスト名が _% という文字でコメントアウトされた状態で sm_config ファイルに含められています。アクティブにするノードの名前のコメントアウトを解除し、ファイル内の構成情報がノードの実際のレイアウトと一致しているか確認してください。

  3. (SCI のみ) sm_config を実行します。

  4. (SSVM のみ) ルートディスクグループを設定します。

    詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』の SSVM と CVM の構成に関する付録を参照してください。

  5. (SDS のみ) Solstice DiskSuite ディスクセットを設定します。

    詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』の Solstice DiskSuite の構成に関する付録を参照してください。

  6. すべてのノードに接続された直接接続デバイスがある場合には、新しいノードの直接接続ディスクフラグを設定します。

    すべてのノードの cdb ファイルについて直接接続フラグを正しく設定するには、クラスタ内のすべてのノードで次のコマンドを実行してください。この例では、クラスタ名は sc-cluster です。

    # scconf sc-cluster +D

  7. (SSVM のみ) 共通の定足数デバイスを選択します。

    ボリュームマネージャが SSVM か CVM で、すべてのノードに接続された直接接続デバイスが存在する場合は、すべてのノードで次のコマンドを実行し、共有の定足数デバイスを選択します。

    # scconf sc-cluster -q -D

    すべてのノードに接続された直接接続ディスクが存在しない場合は、定足数デバイスを新しいノードと共有するノードペアごとに次のコマンドを実行します。 

    # scconf -q

  8. (SSVM のみ) 新しいノードで、ノードロックポートを設定します。

    直接接続ディスクをインストールしたばかりの場合は、すべてのノードでノードロックポートを設定します。

    クラスタにすでに直接接続ディスクが含まれている場合は、新しいノードでだけ次のコマンドを実行してください。この例では、クラスタ名は sc-cluster で、端末集配信装置は cluster-tc です。 

    # scconf sc-cluster -t cluster-tc -l port_number

  9. クラスタを停止します。

  10. すべてのノードで scconf -A コマンドを実行して、アクティブノードの数を更新します。

    詳細は、scconf(1M) のマニュアルページを参照してください。この例では、クラスタ名は sc-cluster で、アクティブノードの新しい合計数は 3 です。

    # scconf sc-cluster -A 3

  11. (SSVM のみ) 共有 CCD が存在する場合は、これを削除します。共有 CCD は 2 ノードクラスタ以外では使用されません。

    すべてのノードで次のコマンドを実行します。 

    # scconf sc-cluster -S none

  12. ftp をバイナリモードで使用し、既存のノードから新しいノードに cdb ファイルをコピーします。

    cdb ファイルは、通常 /etc/opt/SUNWclus/conf/clustername.cdb です。

  13. 新しいノードを再起動します。

  14. クラスタを起動します。

    1 つのノード (任意) で、次のコマンドを実行します。 

    # scadmin startcluster phys-hahost sc-cluster

    続いて、ほかのすべてのノードで次のコマンドを実行します。

    # scadmin startnode

クラスタノードを削除するには

scconf(1M) コマンドを使用すると、scinstall(1M) コマンドによってクラスタソフトウェアのインストール時に設定されたアクティブノードの数を減らし、ノードを削除できます。この作業を行うには、クラスタ内のすべてのノードで scconf(1M) コマンドを実行する必要があります。

  1. HA 構成の場合、削除するノードがマスターとなっているすべての論理ホストをスイッチオーバーします。

    パラレルデータベース構成の場合、この手順は省略してください。

    # haswitch phys-hahost3 hahost1

  2. scconf -A コマンドを実行して、ノードを削除します。

    scconf(1M) コマンドは、すべてのクラスタノードで実行してください。詳細は、scconf(1M) のマニュアルページを参照してください。この例では、クラスタ名は sc-cluster で、アクティブノードの新しい合計数は 2 です。 

    # scconf sc-cluster -A 2

クラスタノード名の変更

クラスタノード名は、scconf(1M) コマンドで変更できます。詳細は、scconf(1M) のマニュアルページを参照してください。

クラスタノード名を変更するには

  1. 現在のクラスタノード名を確認します。

    アクティブクラスタメンバーである任意のノードで、scconf -p コマンドを実行してください。

    # scconf clustername -p 
 Current Configuration for Cluster clustername:
        Hosts in cluster: phys-hahost1 phys_hahost2 phys-hahost3
        Private Network Interfaces for
            phys-hahost1: be0 be1
            phys-hahost2: be0 be1
            phys-hahost3: hme0 hme1

  2. クラスタ内のすべてのノードで、scconf -h コマンドを実行します。

    scconf(1M) コマンドは、すべてのノードで実行してください。詳細は、scconf(1M) のマニュアルページを参照してください。

    # scconf -h clustername hostname0 [...hostname3]

    新しいノード名は、scconf -p コマンドで表示される順に指定する必要があります。たとえば、名前 phys-hahost3 を phys-opshost1 に変更するには、すべてのクラスタノードで次のコマンドを実行します。 

    # scconf -h sccluster phys-hahost1 phys-hahost2 phys-opshost1

プライベートネットワークインタフェースの変更

クラスタ内のノードのプライベートネットワークインタフェースは、scconf(1M) コマンドで変更できます。詳細は、scconf(1M) のマニュアルページを参照してください。

プライベートネットワークインタフェースを変更するには

クラスタ内のすべてのノードで、scconf(1M) コマンドを実行します。

次に例を示します。

# scconf planets -i mercury scid0 scid1
# scconf planets -i venus   scid0 scid1
# scconf planets -i pluto   scid0 scid1
# scconf planets -i jupiter scid0 scid1

これらのコマンドを実行した後、4 つのノード (mercury、venus、pluto、jupiter) はすべてインタフェース scid0 と scid1 を使用するようになります。

注意 - 注意 -

クラスタが稼動している間は、ifconfig(1M) コマンドを使用しないでください。このコマンドを実行すると、稼動中のシステムに予測できない状況をもたらすことがあります。

クラスタ構成の出力

クラスタ構成情報は、scconf(1M) で出力できます。詳細は、scconf(1M) のマニュアルページを参照してください。

クラスタ構成を出力するには

アクティブクラスタメンバーである任意のノードで、scconf(1M) コマンドを実行します。

次に例を示します。

# scconf planets -p

次のようなメッセージが表示されます (プライベートネットワークの種類によっては scid ではなく hme と表示される場合がある)。 

Current Configuration for Cluster planets:
   Hosts in cluster: mercury venus pluto jupiter

   Private Network Interfaces for
       mercury: scid0 scid1
       venus: scid0 scid1
       pluto: scid2 scid3
       jupiter: scid2 scid3

論理ホストの追加と削除

論理ホストは、ノードが故障した場合にフェイルオーバーを行うオブジェクトです。各論理ホストは、1 つ以上のディスクグループ、再割り当てが可能な IP アドレス、論理ホスト名から構成されます。論理ホストが使用されるのは、HA データサービスによる構成の場合だけです。パラレルデータベース構成には論理ホストは存在しません。

論理ホストを追加または削除するには、論理ホストの情報を更新し、クラスタを再構成します。クラスタの最初の構成では、scinstall(1M) に論理ホスト構成の情報を指定します。クラスタが起動した後、この情報は次の 2 つの方法で変更できます。

クラスタに論理ホストを追加するには

論理ホストを追加する作業の一部として、次の情報を指定する必要があります。

作業を開始する前に、これらの事項について確認、決定を行なってください。新しい論理ホストが使用するディスクグループは、あらかじめ設定しておく必要があります。詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』のボリュームマネージャについて説明している付録を参照してください。

クラスタに論理ホストを追加するには、次の作業を行います。

  1. scinstall(1M) コマンドを実行し、「Main Menu」から「Change」を選択します。

    # scinstall
Assuming a default cluster name of planets
 Note: Cluster planets is currently running.
       Install/Uninstall actions are disabled during
       cluster operation.

         <<Press return to continue>>

         Checking on installed package state
 ........................

 ============ Main Menu =================

 1) Change  - Modify cluster or data service configuration.
 2) Verify  - Verify installed package sets.
 3) List    - List installed package sets.

 4) Quit    - Quit this program.
 5) Help    - The help screen for this menu.

 Please choose one of the menu items: [5]:  1

  2. 「Change」メニューから「Logical Hosts」を選択します。

    =========== Changes Menu ================

 Choices from this menu:

 1) Logical Hosts       - Change the logical hosts configuration.
 2) NAFO                - Re-initialize the NAFO configuration.

 3) Close  - Close this menu to return to the Main Menu.
 4) Quit   - Exit this program.
 5) Help   - Show the Help screen.

 Please choose a displayed option: [5] 1

    「Logical Hosts Configuration」メニューが表示されます。

  3. 「Logical Hosts Configuration」メニューから、「Add」を選択します。

    ====== Logical Hosts Configuration ======

 1) Add     - Add a logical host to the cluster.
 2) Remove  - Remove a logical host from the cluster.
 3) List    - List the logical hosts in the cluster.

 4) Close   - Return to the previous menu.
 5) Quit    - Exit.


 Please choose an option:  1

    新しい論理ホストについて、多数の質問が表示されます。 

    What is the primary public network controller for "phys-hahost1"?
 What is the primary public network controller for "phys-hahost2"?
 Does the cluster serve any secondary public subnets (yes/no) [no]?
 Re-initialize NAFO on "phys-hahost1" with one ctlr per group
 (yes/no)?
 What is the name of the new logical host?  hahost1
What is the name of the default master for "hahost1"? phys-hahost1
Enable automatic failback for "hahost1" (yes/no) [no]?
 Disk group name for logical host "hahost1" [hahost1]?
 Is it okay to add logical host "hahost1" now (yes/no) [yes]?
 /etc/opt/SUNWcluster/conf/ha.cdb
 Checking node status...

  4. 質問ごとに、必要な情報を応答します。

    この作業の scinstall(1M) の部分が終わると、「Logical Hosts Configuration」メニューに戻ります。

  5. 新しい HA 管理ファイルシステムを作成し、/etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost ファイルを更新します。

    新しい論理ホストを追加する場合、管理情報を格納するために論理ホスト内のディスクグループにファイルシステムを設定する必要があります。HA 管理ファイルシステムの設定手順は、使用しているボリュームマネージャによって異なります。これらの手順については、『Sun Cluster 2.2 ソフトウェアのインストール』の付録で説明しています。

    注 -

    論理ホストにはホスト名の別名を使用しないでください。論理ホスト名の別名を使用する Sun Cluster ファイルシステムをマウントする NFSTM クライアントで、statd のロック回復問題が発生する可能性があります。

クラスタから論理ホストを削除するには

クラスタ構成から論理ホストを削除するには、クラスタが動作しており、その論理ホストにデータサービスが登録されていない状態でなければなりません。

  1. 削除する論理ホスト上で動作しているデータサービスアプリケーションをすべて停止します。

    # hareg -n detaservice

  2. そのデータサービスの登録を解除します。 

    # hareg -u detaservice

  3. クラスタから論理ホストを削除します。

    『Sun Cluster 2.2 ソフトウェアのインストール』の説明に従って scinstall(1M) コマンドを実行し、「Main Menu」から「Change」を選択します。 

    # scinstall
Assuming a default cluster name of planets
 Note: Cluster planets is currently running.
       Install/Uninstall actions are disabled during
       cluster operation.

         <<Press return to continue>>

         Checking on installed package state
 ........................

 ============ Main Menu =================

 1) Change  - Modify cluster or data service configuration.
 2) Verify  - Verify installed package sets.
 3) List    - List installed package sets.

 4) Quit    - Quit this program.
 5) Help    - The help screen for this menu.

 Please choose one of the menu items: [5]:  1

  4. 「Change」メニューから、「Logical Hosts」を選択します。

    =========== Changes Menu ================

 Choices from this menu:

 1) Logical Hosts       - Change the logical hosts configuration.
 2) NAFO                - Re-initialize the NAFO configuration.

 3) Close  - Close this menu to return to the Main Menu.
 4) Quit   - Exit this program.
 5) Help   - Show the Help screen.

 Please choose a displayed option: [5] 1

    「Logical Hosts Configuration」メニューが表示されます。

  5. 「Logical Hosts Configuration」メニューから、「Remove」を選択します 

    ====== Logical Hosts Configuration ======

 1) Add     - Add a logical host to the cluster.
 2) Remove  - Remove a logical host from the cluster.
 3) List    - List the logical hosts in the cluster.

 4) Close   - Return to the previous menu.
 5) Quit    - Exit.

 Please choose an option:  2

    構成済みの論理ホストが表示されます。

  6. 構成済み論理ホストのリストから削除する論理ホストの名前を入力します。 

    The list of logical hosts is:

         hahost1
         hahost2

 Which one do you want to remove?  hahost1

    以上で作業が終了し、「Logical Hosts Configuration」メニューに戻ります。

  7. クラスタ構成にその論理ホストが追加された時に作成された /etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost ファイルを、root として削除します。

論理ホストの IP アドレスの変更

論理ホストの IP アドレスは、「論理ホストの追加と削除」に示された方法で、論理ホストを削除した後に新しい IP アドレスを使用して論理ホストを追加することによって変更できます。また、この節の作業を行なっても変更できます。

詳細は、scconf(1M) のマニュアルページを参照してください。

論理ホストの IP アドレスを変更するには

クラスタメンバーである 1 つのノードで、次の手順に従います。

  1. すべてのノードで次のコマンドを実行し、構成ファイルからその論理ホストの既存のエントリを削除します。

    # scconf clustername -L logicalhost -r

  2. すべてのクラスタノードで次のコマンドを実行し、論理ホスト名が同じで IP アドレスが異なる新しい論理ホストエントリを作成します。 

    # scconf clustername -L logicalhost -n nodelist -g diskgroup -i interfaces_and_IP

クラスタ再構成の強制

haswitch(1M) コマンドを使用するか、scconf(1M) コマンドでクラスタメンバーシップを変更することにより、クラスタ再構成を強制的に行うことができます。

クラスタ再構成を強制的に行うには

クラスタ再構成を強制的に行うには、クラスタメンバーである任意のノードで haswitch(1M) コマンドを実行します。次に例を示します。

# haswitch -r

詳細は、haswitch(1M) のマニュアルページを参照してください。

Sun Cluster データサービスの構成

この節では、Sun Cluster データサービスを構成する方法について説明します。これらのデータサービスは、通常、クラスタインストールの一環として論理ホストと共に構成されます。しかし、インストール後、論理ホストとデータサービスを構成することも可能です。データサービスの詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

注 -

この節で使用しているコマンドはすべて、クラスタメンバーであるどのノードからでも実行できます。このノードは、指定された論理ホストのマスターになれなくても、指定されたデータサービスを実行できなくてもかまいません。これらのコマンドは、クラスタメンバーシップにノードが 1 つしか存在しなくても実行できます。

注意 - 注意 -

この節で使用しているコマンドは CCD を更新します。これは、定足数に満たない場合でも同様です。そのため、不正な手順でノードが停止されて起動された場合は、CCD に対する更新が消失する場合があります。したがって、クラスタから最後に切り離されるノードは、scadmin startcluster コマンドでクラスタに戻される最初のノードでなければなりません。CCD の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

Sun Cluster データサービスを構成するには

  1. 次の作業が完了していることを確認します。

    • データサービスを実行する論理ホストが構成されている。論理ホストの構成方法については、「論理ホストの追加と削除」を参照してください。

    • 必要なディスクグループ、論理ボリューム、ファイルシステムが設定されている。詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

    • HA 管理ファイルシステムと vfstab.logicalhost ファイルが設定されている。この作業は、ボリュームマネージャによって異なります。ボリュームマネージャの構成方法については、『Sun Cluster 2.2 ソフトウェアのインストール』の付録を参照してください。

  2. データサービスを登録します。

    論理ホストに対応する Sun Cluster データサービスを登録します。

    # hareg -s -r dataservice [-h logicalhost]

    このコマンドは、データサービスがすでにインストールされており、そのメソッドが使用可能であることを前提としています。

    hareg -r コマンドで -h オプションが指定されると、データサービスは引数 logicalhost で指定される論理ホスト上でだけ構成されます。-h オプションが指定されないと、データサービスは現在存在するすべての論理ホスト上で構成されます。詳細は、hareg(1M) のマニュアルページを参照してください。

    注 -

    データサービスの登録の後で作成される論理ホストのいずれかにデータサービスが関連付けられる場合は、すべてのクラスタノードで scconf -s を実行してデータサービスに対応する論理ホストのセットを拡張してください。

  3. データサービスを起動します。

    # hareg -y dataservice

Sun Cluster データサービスの構成解除

Sun Cluster データサービスの構成を解除するには、この作業を行なってください。データサービスの詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

Sun Cluster データサービスの構成を解除するには

  1. 構成を解除するデータサービスアプリケーションをすべて停止します。

    データサービスアプリケーションの通常の停止作業を行なってください。

  2. データサービスがデータベース管理システム (DBMS) の場合は、障害モニターをすべて停止します。

  3. すべての論理ホストで、データサービスを停止します。

    # hareg -n dataservice

  4. データサービスの登録を解除します。

    # hareg -u dataservice
    注 -

    hareg -u コマンドが失敗すると、クラスタ構成データベース (CCD) が矛盾した状態になることがあります。このような場合は、すべてのクラスタノードで scconf clustername -R dataservice を実行し、CCD から強制的にデータサービスを削除してください。

  5. (省略可能) クラスタ構成から論理ホストを削除します。

    クラスタ構成から論理ホストを削除できるのは、すべてのデータサービスがその論理ホストと対応していない場合だけです。

    論理ホストを削除するには、次に示すいずれかの方法を使用してください。

    • 次の scconf(1M) コマンドを、クラスタメンバーである 1 つのノードで実行します。 

    # scconf clustername -L logicalhost -r

    • scinstall(1M) コマンドを、「論理ホストの追加と削除」で説明している方法で実行します。scinstall(1M) を使用する場合は、手順 6で示しているクラスタ再構成を行う必要はありません。

  6. haswitch(1M) コマンドを使用して、クラスタ再構成を行います。 

    # haswitch -r

    必要に応じて、削除した論理ホストに対応した vfstab.logicalhost と dfstab.logicalhost ファイルの削除または名前変更を行い、そのボリュームとファイルシステムが占めている領域を開放できます。これらのファイルは、scconf(1M) による削除作業では削除されません。

clusters ファイルの変更

/etc/clusters ファイルには、ローカルネームドメイン内の既知のクラスタに関する情報が含まれます。このファイルは、クラスタ名をクラスタ内のホスト名リストに割り当てることができます。NIS または NIS+ マップとして作成することも、/etc ディレクトリにローカルに作成することもできます。

/etc/clusters ファイルの更新が必要になるのは、次の場合だけです。

NIS マップと NIS+ マップの詳細は、NIS/NIS+ のシステム管理マニュアルを参照してください。/etc/clusters ファイルの作成については、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。NIS/NIS+ ファイルの変更は、NIS/NIS+ サーバーで行う必要があります。

clusters ファイルを変更するには

すべてのノードのクラスタ名と物理ホスト名を追加するには、/etc/clusters ファイルを編集します。

たとえば、ノード 0 phys-hahost1、ノード 1 phys-hahost2、ノード 2 phys-hahost3、ノード 3 phys-hahost4 から構成される hacluster というクラスタを作成するには、次のエントリを追加します。

# Sun Enterprise Cluster nodes
  hacluster phys-hahost1 phys-hahost2 phys-hahost3 phys-hahost4

各クラスタノードで、/etc/clusters ファイルを同様に変更します。

clusters テーブルを作成するには

NIS+ 環境では、clusters テーブルを作成する必要があります。このテーブルのエントリは、/etc/clusters ファイルのエントリと同じです。

たとえば、NIS+ 環境の mydomain というドメインに clusters テーブルを作成するには、次のコマンドを使用します。

# nistbladm -c key-value key=SI value= clusters.mydomain.
注 -

nistbladm コマンドの末尾にあるピリオド (.) は必須です。

serialports ファイルの変更

serialports ファイルは、端末集配信装置と、ホストコンソールの接続先である端末集配信装置シリアルポートにホスト名を対応付けるものです。このファイルは、NIS または NIS+ マップとして作成することも、/etc ディレクトリにローカルに作成することもできます。

serialports ファイルの更新が必要になるのは、次の場合だけです。

/etc/serialports ファイルの作成については、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。NIS マップと NIS+ マップの詳細は、NIS/NIS+ のシステム管理マニュアルを参照してください。

serialports ファイルを変更するには

  1. root として、/etc ディレクトリに serialports ファイルを作成します。

  2. Sun Enterprise 10000 システムでは、serialports ファイルに hostname sspname 23 と入力します。ほかのハードウェアシステムでは、serialports ファイルに hostname terminal_concentrator serial_port と入力します。

    Sun Enterprise 10000 の場合

    # Sun Enterprise Cluster nodes
   phys-hahost1 sspname 23
   phys-hahost2 sspname 23
   phys-hahost3 sspname 23
   phys-hahost4 sspname 23

    その他のシステムの場合

    # Sun Enterprise Cluster nodes
   phys-hahost1 hacluster-tc    5002
   phys-hahost2 hacluster-tc    5003
   phys-hahost3 hacluster-tc    5004
   phys-hahost4 hacluster-tc    5005

serialports テーブルを作成するには

NIS+ 環境では、serialports テーブルを作成する必要があります。このテーブルのエントリは、/etc/serialports ファイルのエントリと同じです。

たとえば、NIS+ 環境の mydomain というドメインに serialports テーブルを作成するには、次のコマンドを使用します。

# nistbladm -c key-value key=SI value=clusters.mydomain.
注 -

nistbladm コマンドの末尾にあるピリオド (.) は必須です。

TC/SSP 情報の変更

Sun Cluster ソフトウェアをインストールする場合は、端末集配信装置 (TC) またはシステムサービスプロセッサ (SSP) についての情報が必要です。この情報は、クラスタ構成データベース (CCD) に格納されています。

この情報は次の目的で使用されます。

この 2 つの機構は、直接接続された記憶装置を持つ 4 ノード構成のクラスタにおけるデータの完全性を守る役割を果たします。

次の作業で説明しているように、特定のノードに対応する TC 情報または SSP 情報を変更するには、scconf(1M) コマンドを使用します。

TC/SSP 情報を変更するには

TC 情報または SSP 情報を変更するには、すべてのクラスタノードで scconf(1M) コマンドを実行します。この場合、ノードごとに該当する新しい情報を入力する必要があります。次の例は、情報変更の種類ごとに使用できる scconf(1M) コマンド構文を示しています。

ノードのアーキテクチャータイプと IP アドレス - クラスタ名、ホスト名、新しいアーキテクチャータイプ、新しい IP アドレスを指定します。

# scconf clustername -H hostname -d E10000 -t new_ip_address
注 -

同じ TC に複数のホストを接続できます。-H オプションは、コマンド行に指定されたホストに対応する情報にだけ影響します。

TC または SSP のパスワード - クラスタ名、IP アドレス、新しいパスワードを指定します。

# scconf clustername -t ip_address -P
 ip_address (129.34.123.51) Password:

SSP コンソールのポート番号 - クラスタ名、ホスト名、新しいポート番号を指定します。 

# scconf clustername -H hostname -p new_port_number

TC 名または IP アドレス - クラスタ名、ホスト名、新しい TC 名または IP アドレスを指定します。 

# scconf clustername -H hostname -t new_tc_name|new_ip_address

TC 情報または SSP 情報の変更についての詳細は、scconf(1M) のマニュアルページと第 8 章「端末集配信装置の管理」を参照してください。

定足数デバイスの変更

定足数デバイスは、SSVM 構成と CVM 構成にだけ使用されます。定足数デバイスは、Solstice DiskSuite 構成には使用されません。

定足数デバイスをディスクまたはコントローラに変更するには、scconf -q コマンドを使用します。このオプションは、定足数デバイスがサービスを必要とする場合に便利です。詳細は、scconf(1M) のマニュアルページを参照してください。

注 -

定足数デバイスがディスクの場合、ディスクアドレス (cxtydzs2 の形式で示される) が変わるたびに scconf -q コマンドを使用する必要があります。これは、ディスクのシリアル番号が保存されている場合も同様です。ディスクアドレスの変化は、ドライブコントローラの SBus スロットが変わる場合に起きる可能性があります。

注意 - 注意 -

クラスタが稼動している間は、scconf -q オプションを使用して定足数デバイストポロジを変更しないでください。2 つのクラスタノード (クラスタ内のノードペア) 間では定足数デバイスの追加や削除は行えません。

定足数デバイスを変更するには

  1. デバイスのサービスを開始する前に、すべてのクラスタノードで scconf -q コマンドを実行して定足数デバイスを別のデバイスに変更できます。

    たとえば、ノード phys-hahost1 と phys-hahost2 のクラスタ haclust の定足数デバイスを変更するには、次のように scconf(1M) コマンドを実行します。

    # scconf haclust -q phys-hahost1 phys-hahost2
Select quorum device for nodes 0 (phys-hahost1) and 1 (phys-hahost2).
 Type the number corresponding to the desired selection.
 For example: 1<CR>

  1) DISK:c2t2d0s2:01943825
  2) DISK:c2t3d0s2:09064321
  3) DISK:c2t4d0s2:02171369
  4) DISK:c2t5d0s2:02149886
  5) DISK:c2t8d0s2:09062992
  6) DISK:c2t9d0s2:02166472
  7) DISK:c3t2d0s2:02183692
  8) DISK:c3t3d0s2:02183488
  9) DISK:c3t4d0s2:02160277
 10) DISK:c3t5d0s2:02166396
 11) DISK:c3t8d0s2:02164352
 12) DISK:c3t9d0s2:02164312
 Quorum device: 12

    -q オプションは、各ノードに接続されたデバイスの一覧を調べ、2 つのノードが共有しているデバイスを表示します。この一覧から、定足数デバイスを選択できます。

    遠隔ホストに接続されたデバイスを検証できるように、ローカルの /.rhosts ファイルは rsh(1) 権限を与えるように変更されます。この権限は、このコマンドが完了すると無効になります。

    注 -

    この動作は、このコマンドがすべてのノードから同時に実行される場合だけ発生します。遠隔の root アクセス機能が必要ない場合は、-m オプションを使用してください。

  2. この一覧の SSA コントローラまたはディスクを定足数デバイスとして選択できます。

    SSA コントローラを選択すると、そのコントローラ内のディスクの一覧が表示されます。

  3. 手順 2で SSA コントローラを選択した場合、その SSA のディスクを定足数デバイスとして選択できます。

    この手順でディスクを選択しないと、手順 2 で選択された SSA コントローラが定足数デバイスとなります。

    -q オプションは、メンバーシップに含まれないほかのノードが原因で、ノードが定足数デバイスを予約していないかどうかも確認します。予約している場合、-q オプションは、古い定足数デバイスの予約を解放し、新しい定足数デバイスを予約します。

    注 -

    scconf -q コマンドを正常に実行するためには、指定されたすべてのノードを起動する必要があります。起動されないノードがあると、このコマンドはローカルノード上のすべてのデバイスを検証し、そのリストを表示します。定足数デバイスには、必ず共有デバイスを選択してください。

    定足数デバイスとして使用するデバイスの名前がわかる場合は、-m オプションを使用して新しいデバイスを指定してください。 

    # scconf clustername -q -m quorum-device hostname1 hostname2

    定足数デバイスは、SSA コントローラの固有の名称 (World Wide Name: WWN)、SSA ディスクのディスク識別子 (WWN.disk-serial-id)、または SSA 以外のディスクのディスク識別子 (disk-address:disk-serial-id) で指定できます。disk-address は、cxtydzs2 という形式で指定します。SSA ディスクまたは SSA 以外のディスクのシリアル番号を調べるには、finddevices(1M) コマンドを使用します。

    すべてのノードが共通定足数デバイスを共有する、3 ノード以上から構成されるクラスタでは、-q -D オプションを使用して新しい共通定足数デバイスを指定できます。 

    # scconf clustername -q -D

    クラスタ内のホストはすべて共通デバイスを共有するため、ホスト一覧の指定は不要です。

    これは、各ホストに接続されたデバイスの一覧を検証し、続いて共有されたデバイスの一覧を示す対話型のオプションです。この一覧から定足数デバイスを選択してください。

    注 -

    scconf -q -D コマンドを正常に実行するためには、クラスタ内に定義されたすべてのアクティブホストを起動する必要があります。起動されないノードがあると、このコマンドはローカルホスト上のすべてのデバイスを検証し、そのリストを表示します。定足数デバイスには、必ず共有デバイスを選択してください。

    -q -D オプションは、クラスタに含まれないほかのノードが原因で、クラスタのノードが定足数デバイスを予約していないかどうかも確認します。予約している場合、古い定足数デバイスの予約は解放され、新しい定足数デバイスが予約されます。

    このコマンドが cconsole と crlogin GUI インタフェースを介してすべてのノードから同時に実行されると、rsh(1) 権限を与えるようにローカルの /.rhosts ファイルが変更されます。これにより、遠隔ホストに接続されたデバイスの検証が行えるようになります。この権限は、このコマンドが完了すると無効になります。

    遠隔の root アクセスが必要ない場合は、-m オプションを追加できます。定足数デバイスを構成するこのオプションは、指定されたノードに対するコマンドの最後の引数として指定します。

    # scconf clustername -q -D -m quorum-device

    定足数デバイスは、cxtydzs2:disk-serial-ID という形式のディスク識別子です。ディスクのシリアル番号を調べるには、finddevices(1M) コマンドを使用します。

クラスタ遷移ステップのタイムアウトの構成

Sun Cluster では、クラスタのメンバーシップの変化に応じて、HA フレームワークの論理ホストが交替されるクラスタ遷移ステップにタイムアウトを構成できます。このタイムアウトは、各ノードにおいて多数のデータサービスから成る構成を効果的に処理するように、必要に応じて調整してください。タイムアウトが非常に大きなデフォルト値に設定される場合を除いて、さまざまな構成に一定のタイムアウト値を使用することは実用的ではありません。

タイムアウトを調整する場合、次の 2 つの事項を必ず考慮してください。

個々のインストールに適した値を推測するのは困難です。これらの値は、試行錯誤によって決定するしかありません。ガイドラインとしては、各クラスタ遷移ステップの先頭と最後についてのクラスタコンソールメッセージを使用できます。これらのガイドラインから、ステップのおおよその実行時間を推測できます。

タイムアウトは、最悪の状況とみなす必要があります。クラスタのタイムアウトを構成する場合は、1 つのクラスタノードが一度にマスターできる論理ホストの最大数について考慮してください。

たとえば、N+1 構成では、スタンバイノードはほかのクラスタノードの論理ノードをすべてマスターできます。この場合、再構成タイムアウトは、クラスタに構成されているすべての論理ホストをマスターできるだけの十分な余裕がなければなりません。

クラスタタイムアウトを調整するには

  1. scconf -T コマンドを使用して、クラスタ再構成タイムアウトを調整します。

    たとえば、構成可能な遷移ステップタイムアウト値を 500 秒に変更するには、すべてのクラスタノードで次のコマンドを実行します。

    # scconf clustername -T 500

    これらのステップのデフォルト値は 720 秒です。現在のタイムアウト値を確認するには、ssconf -p コマンドを使用してください。

    これらのステップにすべての論理ホストをマスターする十分な時間がない場合は、クラスタコンソールにエラーメッセージが表示されます。

    再構成ステップでは、単一の論理ホストをマスターするのにかかる時間は、各論理ホストに構成されているデータサービスの数によって異なります。論理ホストをマスターする十分な時間がない (つまり loghost_timeout パラメータが小さすぎる) 場合は、コンソールに次のようなメッセージが表示されます。


    ID[SUNWcluster.ccd.ccdd.5001]: error freeze cmd =
 command /opt/SUNWcluster/bin/loghost_sync timed out.

    この例では、クラスタフレームワークは、論理ホストの放棄を試みることによって、システムを一貫した状態に戻そうと「最善の努力」をしています。この試みが失敗すると、ノードは矛盾を防ぐためにクラスタから停止することがあります。

  2. scconf -l オプションを使用して、loghost_timeout パラメータを調整します。

    デフォルトは 180 秒です。

    注 -

    再構成ステップのタイムアウトは、loghost_timeout 値より小さくはできません。loghost_timeout 値よりも小さい値が指定されると、エラーが発生し、クラスタ構成ファイルは変更されません。この条件は、scconf -T または scconf -l オプションで確認できます。これらのタイムアウトのどちらかが 100 秒以下に設定されると、警告が表示されます。

一般的な Sun Cluster の管理

この章では、次の項目について説明します。

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

クラスタとクラスタノードの起動

ノードをクラスタの最初のメンバーにするには、scadmin startcluster コマンドを使用します。このノードは、そのクラスタのノード 0 になります。その他の Sun Cluster ノードは、scadmin startnode コマンドで起動します。このコマンドは、複数のノードの同期に必要なプログラムを起動するとともに、Sun Cluster ソフトウェアが最初のノードですでに動作している場合、2 つ目以降のノードが最初のノードと統合するように調整します。クラスタからノードを削除するには、削除するノード上で stopnode オプションを指定して scadmin コマンドを実行します。

クラスタの最初のメンバーには、ローカルノードを指定してください。scadmin startcluster コマンドを正常に実行するためには、このノードがクラスタで構成されていなければなりません。このコマンドの実行が正常に終了すると、ほかのノードをクラスタに加えることができます。ほかのノードをクラスタに加えている間に何らかの理由でローカルノードが停止する場合、CCD が破損することがあります。このような状況が発生した場合は、「CCD を復元するには」に従って CCD を復元してください。

ローカルノードをクラスタの構成ノードにするには、3-2 ページの 3.1 節「クラスタノードの追加と削除」を参照してください。

クラスタを起動するには

この時点では、ほかのノードがクラスタソフトウェアを実行していてはなりません。他のクラスタノードがアクティブであることをこのノードが検出した場合、ローカルノードは起動しません。

  1. scadmin(1M) コマンドを使用して、クラスタの最初のノードを起動します。 

    # scadmin startcluster localnode clustername

    コマンドが実行されるノードの名前と localnode が一致しない場合、startcluster オプションは動作しません。詳細は、scadmin(1M) のマニュアルページを参照してください。

    次に例を示します。

    phys-hahost1# scadmin startcluster phys-hahost1 haclust
 Node specified is phys-hahost1
 Cluster specified is haclust

 =========================== WARNING============================
 =                     Creating a new cluster 	 	 	 	 	 	 	 	 	=
 ===============================================================

 You are attempting to start up the cluster node 'phys-hahost1' 
 as the only node in a new cluster.  It is important that no 
 other cluster nodes be active at this time.  If this node hears 
 from other cluster nodes, this node will abort. Other nodes may 
 only join after this command has completed successfully.  Data 
 corruption may occur if more than one cluster is active.


 Do you want to continue [y,n,?] y

    reconfig.4013 エラーメッセージが表示された場合は、クラスタにすでにノードが存在するか、ほかのノードがまだ停止の途中にあります。動作していると思われるノードの状態を調べるには、そのノードで get_node_status(1M) コマンドを実行してください。

  2. クラスタにほかのノードをすべて追加します。

    ほかのすべてのノードで、次のコマンドを実行してください。このコマンドは、複数のノードで同時に実行できます。 

    # scadmin startnode

    次に示す reconfig.4015 エラーメッセージが表示された場合は、クラスタが存在しない可能性があります。scadmin startcluster localnode コマンドを使用して、クラスタを再起動してください。

    SUNWcluster.clustd.reconf.4015
 "Aborting--no existing or intact cluster to join."

    パーティションまたはノードの障害も考えられます (2 つのノードの一方に障害が発生している間に、2 ノードクラスタに対して 3 つ目のノードの追加が試みられているなど)。これらの障害が発生した場合は、障害が落ち着くまで待ち、何か問題があれば解決し、その後クラスタへの追加を再度試みてください。

    必要なソフトウェアパッケージが欠如している場合、コマンドは失敗し、コンソールに次のようなメッセージが表示されます。

    Assuming a default cluster name of haclust
 Error: Required SC package `SUNWccm' not installed!
 Aborting cluster startup.

    Sun Cluster ソフトウェアパッケージのインストールについては、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

クラスタとクラスタノードの停止

ノードをマルチユーザー以外のモードに設定する場合、あるいはノードを停止または再起動する場合は、Sun Cluster メンバーシップモニターを停止する必要があります。停止した後で、サイトに適した方法でノード管理を継続できます。

クラスタを停止するには、すべてのクラスタノードで scadmin stopnode コマンドを同時に実行し、すべてのノードのメンバーシップモニターを停止する必要があります。

phys-hahost1# haswitch ...
 phys-hahost1# scadmin stopnode

scadmin stopnode コマンドの実行時にそのノードが論理ホストを所有している場合、メンバーシップモニターが停止される前に、その論理ホストをマスターできる別のノードに所有権が移されます。論理ホストのマスターとなることができる別のノードがダウンしている場合、scadmin stopnode コマンドはメンバーシップモニターを停止するとともにデータサービスを停止します。

scadmin stopnode コマンドの実行後、システムを再起動しても Sun Cluster は停止したままとなります。Sun Cluster を起動するには、scadmin startnode コマンドを実行する必要があります。

scadmin stopnode コマンドは、クラスタからノードを削除します。ほかに同時に障害が発生していないかぎり、残っているノードで定足数を満たした範囲で、いくつでもノードを停止できます (定足数が満たされないとクラスタ全体が停止します)。

ディスクの保守のためにノードを停止する場合は、第 10 章「Sun Cluster ローカルディスクの管理」で説明している起動ディスクの作業、またはボリュームマネージャのマニュアルで説明しているデータディスクの作業を行なって、起動ディスクまたはデータディスクを用意する必要もあります。

SBus カードの追加や削除などのハードウェア保守作業を行うには、Sun Cluster ノードを停止しなければならない場合があります。以下の節では、単一のノードまたはクラスタ全体を停止する方法を説明します。

1 つのクラスタノードで Sun Cluster を停止するには

  1. データを使用できる状態にしておく必要がない場合は、論理ホスト (ディスクグループ) を保守モードにします。

    phys-hahost2# haswitch -m logicalhost

    詳細は、haswitch(1M) マニュアルページを参照してください。

    注 -

    halt(1M) コマンドを使用すると、Sun Cluster ノードを停止し、フェイルオーバーによりバックアップノードで論理ホストサービスを復元できます。しかし、halt(1M) を実行すると、ノードに障害が発生する可能性があります。論理ホストの所有権をスイッチオーバーする方法としては、haswitch(1M) コマンドの方が信頼性があります。

  2. クラスタ内のほかのノードで動作しているサービスを停止することなく、1 つのノードで Sun Cluster を停止します。

    phys-hahost1# scadmin stopnode

  3. ノードを停止します。

    phys-hahost1# halt

    以上で、ノードの保守作業が行える状態になります。

すべてのノードの Sun Cluster を停止するには

環境状態が極めて悪い場合 (冷却システムの障害や稲光を伴った嵐が発生した場合など) は、Sun Cluster 構成内のすべてのノードを停止できます。

  1. scadmin(1M) コマンドを使用して、すべてのノードで同時にメンバーシップモニターを停止します。

    クラスタコンソールを使用すると、この作業を一度で行えます。

    phys-hahost1# scadmin stopnode
...

  2. halt(1M) を使用して、すべてのノードを停止します。 

    phys-hahost1# halt
...

Sun Cluster ノードを停止するには

Sun Cluster ノードはどれも、halt(1M) コマンドまたは uadmin(1M) コマンドで停止できます。

ノードの停止時にメンバーシップモニターが動作している場合、そのノードは通常「Failfast タイムアウト」をとり、次のメッセージを表示します。

panic[cpu9]/thread=0x50f939e0: Failfast timeout - unit

この状況を避けるには、ノードを停止する前にメンバーシップモニターを停止します。詳細は、「すべてのノードの Sun Cluster を停止するには」の作業を参照してください。

RDBMS インスタンスの実行中におけるメンバーシップモニターの停止

データベースサーバーインスタンスをノード上で実行するには、あらかじめ startnode オプションを呼び出し、そのノードをクラスタに加える必要があります。stopnode オプションの呼び出しは、すべてのデータベースインスタンスを停止した後に行います。

注 -

Oracle7 Parallel Server、Oracle8 Parallel Server、または Informix XPS を使用している場合は、各製品のマニュアルで停止方法を参照してください。

ノードで Oracle7 または Oracle8 インスタンスが動作している間に stopnode コマンドを実行すると、stopnode はハングアップし、コンソールに次のメッセージが表示されます。

ID[vxclust]: stop: waiting for applications to end

stopnode コマンドを正常に終了させるためには、Oracle7 または Oracle8 インスタンスを停止する必要があります。

ノード上で Informix-Online XPS インスタンスが動作している間に stopnode コマンドを実行すると、データベースがハングアップし、使用できなくなります。

論理ホストのスイッチオーバー

指定した論理ホスト (および関連するディスクグループ、データサービス、論理 IP アドレス) を宛先ホストによって指定されたノードにスイッチオーバーするには、haswitch(1M) コマンドを使用します。たとえば、次のコマンドは、論理ホスト hahost1 と hahost2 の両方が phys-hahost1 に、マスターされるようにスイッチオーバーします。

# haswitch phys-hahost1 hahost1 hahost2

論理ホストに複数のデータサービスが構成されている場合、それらのデータサービスの 1 つまたは一部だけを選択してスイッチオーバーすることはできません。論理ホスト上のデータサービスはすべてスイッチオーバーする必要があります。

注 -

宛先ホストと論理ホストの現在のマスターは、クラスタのメンバーでなければなりません。この条件に当てはまらない場合、コマンドは失敗します。

自動スイッチオーバーの無効化

HA データサービスを提供するクラスタでは、ノード障害のためにマスターされている論理ホストが別のノードにスイッチオーバーされ、障害が発生したノードが後でクラスタに戻されるという状況に対し、「自動スイッチオーバー」を設定できます。スイッチオーバー先のホストでマスターが続行するように構成しないかぎり、論理ホストは自動的にそれらのデフォルトのマスターで再び制御されます。

論理ホストが本来のマスターに自動的にスイッチバックしないようにする場合は、-m オプション を指定して scconf(1M) コマンドを実行します。詳細は、scconf(1M) のマニュアルページを参照してください。

注 -

論理ホストの自動スイッチオーバーを無効にするには、クラスタのアクティブメンバーである単一のノードで scconf(1M) コマンドを実行します。


# scconf clustername -L logicalhost -n node1,node2 -g dg1 -i qe0,qe0,logaddr1 -m

論理ホストを保守モードに設定する

ファイルシステムとディスクグループの管理作業では、保守モードを使用すると便利な場合があります。論理ホストのディスクグループを保守モードにするには、-m オプションを指定して haswitch(1M) コマンドを実行します。

注 -

論理ホストのほかの所有権と異なり、保守モードはノードの再起動を行なっても持続します。

次に、論理ホスト hahost1 を保守モードにする例を示します。 

phys-hahost2# haswitch -m hahost1

このコマンドは、現在このディスクグループを所有している Sun Cluster ノード上の、hahost1 に対応するデータサービスを停止するとともに、すべての Sun Cluster ノード上の、hahost1 に対応する障害監視プログラムを停止します。このコマンドは、この論理ホスト上のすべての Sun Cluster ファイルシステムの umount(1M) も実行します。対応するデータサービスの所有権は解放されます。

このコマンドは、論理ホストとディスクグループの現在の所有権にかかわらず、どのホストでも実行できます。

保守モードでは、ディスクグループを所有する予定の物理ホストを指定してスイッチオーバーを実行することにより論理ホストを削除できます。たとえば、保守モードで hahost1 を削除するには次のコマンドを使用できます。 

phys-hahost1# haswitch phys-hahost1 hahost1

クラスタ分割からの復元

ネットワーク分割のような複合的な障害が発生すると、クラスタメンバーの複数のサブセットがクラスタに留まる場合があります。通常、これらのサブセットは相互通信の一部が不可能になるか、まったく通信できない状態になります。このような場合、ソフトウェアは有効なクラスタを 1 つだけ残すように試みます。そのため、ソフトウェアはノードの一部またはすべてを停止させる場合があります。この節では、これらの決定に使用される基準について説明します。

定足数基準は、クラスタノードの本来のセット (構成ノードに限らない) の半分以上のメンバーを含むサブセットと決められています。サブセットが定足数基準に満たない場合、サブセット内のノードは自ら停止し、reconfig.4014 エラーメッセージが表示されます。定足数基準に満たない原因は、ネットワーク分割や、半分を超えるノードで同時に障害が発生したことなどが考えられます。

注 -

有効なクラスタには、プライベートネットワーク上で互いに通信できるノードだけが含まれます。

2 つのサブセットに分割された 4 ノードクラスタを考えてみましょう。この 2 つのサブセットの一方は 1 つのノード、他方は 3 つのノードから構成されています。各サブセットは、定足数基準を満たそうと試みます。最初のサブセットには本来の 4 つのうちの 1 つのノードしかなく、定足数基準を満たしていません。そのため、このサブセットのノードは停止します。2 つ目のサブセットには本来の 4 つのうちの 3 つのノードが含まれ、定足数基準を満たしているため、動作したままとなります。

別の例として、定足数デバイスを持つ 2 ノードクラスタを考えてみます。このような構成で分割が発生する場合、一方のノードと定足数デバイスで定足数基準が満たされるため、クラスタは起動したままとなります。

split-brain 分割 (SSVM または CVM のみ)

split-brain 分割は、1 つのサブセットにクラスタメンバーのちょうど半分が含まれる場合に発生します (split-brain 分割には 2 ノードクラスタ + 定足数デバイスというケースは含まれない)。Sun Cluster の最初のインストールでは、split-brain 分割が発生する場合の復元方法の選択を求められます。選択肢は ask と select です。ask を選択した場合、split-brain 分割の発生時にシステムはどのノードを起動しておくか尋ねてきます。select を選択した場合、システムはどのクラスタメンバーを起動しておくべきか自動的に選択します。

split-brain 分割の処理方法として自動選択ポリシーを選択した場合は、Lowest Nodeid または Highest Nodeid を選択できます。Lowest Nodeid を選択すると、最小の ID 値を持つノードが入ったサブセットが新しいクラスタになります。Highest Nodeid を選択すると、最大の ID 値を持つノードが入ったサブセットが新しいクラスタになります。詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』のインストールについての説明を参照してください。

どちらの場合も、ほかのサブセットのノードは手動で停止する必要があります。

自動選択ポリシーを選択しなかった場合 (分割発生時にシステムが入力を求めてくる場合)、システムは次のエラーメッセージを表示します。 

SUNWcluster.clustd.reconf.3010
 "*** ISSUE ABORTPARTITION OR CONTINUEPARTITION *** 
Proposed cluster: xxx  
Unreachable nodes: yyy"

さらに、10 秒ごとにコンソールに次のようなメッセージが表示されます。

*** ISSUE ABORTPARTITION OR CONTINUEPARTITION ***
 If the unreachable nodes have formed a cluster, issue ABORTPARTITION.
 (scadmin abortpartition <localnode> <clustername>)
 You may allow the proposed cluster to form by issuing CONTINUEPARTITION.
 (scadmin continuepartition <localnode> <clustername>)
 Proposed cluster partition:  0  Unreachable nodes: 1

自動選択処理を選択しなかった場合は、「新しいクラスタを選択するには」の作業を行なって新しいクラスタを選択してください。

注 -

split-brain 障害の後でクラスタを再起動するには、停止したノードが完全に起動するまで待ち (ノードの自動再構成または自動再起動が起きる場合があります)、その後 scadmin startnode コマンドを使用してそのノードをクラスタに戻します。

新しいクラスタを選択するには

  1. どのサブセットで新しいクラスタを構成するかを決定します。停止させるサブセット内のノードの 1 つで、次のコマンドを実行します。

    # scadmin abortpartition

    1 つのノードで abortpartition コマンドを発行すると、クラスタメンバーシップモニター (CMM) がそのコマンドをそのパーティション内のすべてのノードに伝播します。そのため、パーティション内のすべてのノードがそのコマンドを受け取った場合、それらはすべて停止します。しかし、CMM が通信できないノードがパーティションに存在する場合、それらは手動で停止させる必要があります。停止しない残ったノードで、scadmin abortpartition コマンドを実行してください。

  2. 起動したままにしておくサブセット内のノードの 1 つで、次のコマンドを実行します。

    # scadmin continuepartition
    注 -

    新しいクラスタで別の障害が発生すると、さらに再構成が行われます。アクティブクラスタは、常に 1 つです。

/var ファイルシステムの管理

/var/adm/messages ファイルに Solaris と Sun Cluster ソフトウェアのエラーメッセージが書き込まれるために、/var ファイルシステムが満杯になることがあります。ノードの動作中に /var ファイルシステムが満杯になっても、ノードは継続して動作しますが、/var ファイルシステムが満杯のままでは、通常、そのノードにログインできません。ノードが停止すると、Sun Cluster は起動せず、ログインはできません。このような状況が発生した場合には、シングルユーザーモード (boot -s) で再起動する必要があります。

ノードが /var ファイルシステムが満杯であることを報告し、Sun Cluster サービスを継続して実行する場合は、次の作業を行なってください。

満杯の /var ファイルシステムを修復するには

この例では、phys-hahost1 に満杯の /var ファイルシステムが存在していると仮定します。

  1. スイッチオーバーを行います。

    問題が発生しているノードから論理ノードをすべて移動させます。

    phys-hahost2# haswitch phys-hahost2 hahost1 hahost2

  2. クラスタメンバーシップからそのノードを削除します。

    phys-hahost1 にアクティブなログインがある場合は、次のコマンドを入力します。

    phys-hahost1# scadmin stopnode

    phys-hahost1 にアクティブなログインがない場合は、ノードを停止します。

  3. ノードをシングルユーザーモードで再起動します。 

    (0) ok boot -s
INIT: SINGLE USER MODE

 Type Ctrl-d to proceed with normal startup,
 (or give root password for system maintenance): <root_passward>
 Entering System Maintenance Mode

 Sun Microsystems Inc. SunOS 5.6 Generic August 1997

  4. 満杯のファイルシステムを消去するための通常の手順を実行します。

  5. ファイルシステムが消去された後で、マルチユーザーモードに入ります。 

    # exit

  6. scadmin startnode コマンドを使用して、そのノードを構成に再度加えます。 

    # scadmin startnode

Sun Cluster 構成における時間の管理

Solaris オペレーティング環境に Network Time Protocol (NTP) が付属している場合は、NTP を使用してクラスタノード間の時間の同期を管理することをお勧めします。

注意 - 注意 -

管理者は、Sun Cluster 構成内のノードの時間は調整できません。date(1)、rdate(1M)、xntpdate(1M) コマンドによる時間変更は決して行わないでください。

Sun Cluster 環境では、クラスタノードは NTP クライアントとして動作できます。NTP を使用するには、クラスタの外で NTP サーバーの設定と構成を行う必要があります。クラスタノードは、NTP サーバーとしては構成できません。NTP クライアントと NTP サーバーについては、xntpd(1M) のマニュアルページを参照してください。

クラスタノードを NTP クライアントとして稼動させる場合、ntpdate(1M) を呼び出す crontab(1) エントリが存在しないことを確認してください。NTP クライアントでは、xntpd(1M) を実行する方がより安全です。このコマンドは、大きな進みや遅れを出すことなくクロックの同期を保ちます。

障害が発生したノードの交換

1 つのノードにハードウェア障害が発生し、新しいノードと交換が必要になった場合は、次の手順に従ってください。

注 -

この作業は、障害が発生したノードのルートディスクがまだ使用可能であることを想定しています。障害が発生したルートディスクがミラー化されていない場合は、ご購入先にお問い合わせください。

障害が発生したノードを交換するには

障害が発生したノードが使用不可能な場合は、手順 5から始めてください。

  1. パラレルデータベース構成の場合は、データベースを停止します。

    注 -

    データサービスについては、該当するマニュアルを参照してください。HA アプリケーションはすべて、scadmin stopnode コマンドで自動的に停止します。

  2. クラスタコンソールを使用して、端末ウィンドウを開きます。

  3. root として、端末ウィンドウに次のコマンドを入力します。

    このコマンドは、クラスタからノードを削除し、Sun Cluster ソフトウェアを停止し、そのノード上のボリュームマネージャを無効にします。

    # scadmin stopnode

  4. ノード上のオペレーティングシステムを停止します。

    『Solaris のシステム管理』を参照してください。

  5. ノードの電源を切ります。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

    注意 - 注意 -

    この時点で、障害が発生したノードからケーブルを抜かないでください。

  6. 障害が発生したノードから、起動ディスクを取り外します。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  7. 起動ディスクを、新しいノードの同一のスロットに差し込みます。

    ルートディスクは、以前と同じアドレスでアクセスできます。詳細は、ハードウェアのサービスマニュアルを参照してください。

    注 -

    新しいノードの IP アドレスが、障害が発生したシステムと同じであることを確認してください。必要に応じて、起動サーバーまたは arp サーバーを変更し、新しい Ethernet アドレスに IP アドレスを割り当て直してください。詳細は、『NIS+ と DNS の設定と構成』を参照してください。

  8. 新しいノードに電源を入れます。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  9. ノードが自動的に起動する場合は、オペレーティングシステムを停止し、システムを OpenBoot PROM モニターの状態にします。

    詳細は、shutdown(1M) のマニュアルページを参照してください。

  10. ハードウェア計画とインストールに関するマニュアルを参照して、すべての scsi-initiator-id が正しく設定されているか確認します。

  11. 新しいノードの電源を切ります。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  12. 多重ホストディスクを障害が発生したノードと共有するほかのノードで、障害が発生したノードに接続されている 1 台のディスク拡張装置内のすべてのディスクを取り外します。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  13. ディスク拡張装置の電源を切ります。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

    注 -

    障害が発生したノードを交換する間、システムコンソールに次のようなメッセージが表示される場合があります。このメッセージは問題についての説明ではない場合があるため、無視してください。

    Nov 3 17:44:00 updb10a unix: WARNING: /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17):
 Nov 3 17:44:00 updb10a unix: SCSI transport failed: reason 'incomplete': retrying ¥ command
 Nov 3 17:44:03 updb10a unix: WARNING: /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17):
 Nov 3 17:44:03 updb10a unix:   disk not responding to selection

  14. 障害が発生したノードから SCSI ケーブルを抜き、新しいノードの対応するスロットに差し込みます。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  15. ディスク拡張装置の電源を入れます。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  16. 手順 12で取り外したディスクをすべて、元のように設置します。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  17. ディスク拡張装置内のすべてのボリュームが回復するのを待ちます。その後、対応するミラーディスク拡張装置を取り外します。

    ボリューム回復がいつ発生したかを確認するには、ボリュームマネージャソフトウェアを使用してください。

  18. 残っているすべてのディスク拡張装置について、手順 12から 手順 17 を繰り返します。

  19. 交換したノード (新しいノード) に電源を入れます。

    詳細は、ハードウェアのサービスマニュアルを参照してください。

  20. ノードを再起動し、システムが起動するのを待ちます。

    <#0> boot

  21. 交換したノードの Ethernet アドレスを決定します。

    # /usr/sbin/arp nodename

  22. 交換したノードのノード ID を決定します。

    消去法によって、クラスタにどのノードが存在しないかを確認できます。ノード ID は、ノード 0 から始まる連続した番号にする必要があります。

    # get_node_status
sc: included in running cluster
 node id: 0       
 membership: 0
 interconnect0: unknown
 interconnect1: unknown
 vm_type: cvm
 vm_on_node: master
 vm: up
 db: down

  23. すべてのクラスタノードで次のコマンドを入力し、クラスタシステムに交換ノードの新しい Ethernet アドレスを知らせます。

    # scconf clustername -N node-id ethernet-address-of-host

    手順 22 の例を使用した場合、ノード ID は 1 になります。

    # scconf clustername -N 1 ethernet-address-of-host

  24. 交換したノードを起動します。

    # scadmin startnode

  25. パラレルデータベース構成の場合は、データベースを再起動します。

    注 -

    データサービスについては、該当するマニュアルを参照してください。HA アプリケーションはすべて、scadmin startcluster コマンドと scadmin startnode コマンドで自動的に起動します。

障害が発生した端末集配信装置の交換

クラスタを動作させておくために、端末集配信装置が操作可能である必要はありません。端末集配信装置に障害が発生しても、クラスタ自体に障害が発生することはありません。

障害が発生した端末集配信装置は、クラスタに影響を与えることなく交換できます。新しい端末集配信装置が元の名前、IP アドレス、パスワードをそのまま使用する場合は、クラスタコマンドは不要です。新しい端末集配信装置にプラグを差し込むだけで、正常に動作します。

交換した新しい端末集配信装置が新しい名前、IP アドレス、パスワードを使用する場合は、「TC/SSP 情報の変更」で説明しているように、scconf(1M) コマンドを使用してクラスタデータベース内のこの情報を変更してください。この作業は、クラスタを動作させたまま、クラスタの処理に影響を与えることなく行えます。

クラスタ構成データベースの管理

クラスタ構成データベース (CCD) の管理作業には、ccdadm(1M) コマンドを使用します。詳細は、ccdadm(1M) のマニュアルページを参照してください。

注 -

ccdadm(1M) コマンドは、root として任意のアクティブノードで実行できます。このコマンドは、クラスタ内のすべてのノードを更新します。

クラスタ構成が更新されるごとに、ccdadm(1M) に -c (checkpoint) オプションを使用し、CCD の状態を記録することをお勧めします。Sun Cluster フレームワークは、論理ホストと HA データサービスに関連した構成データを格納するために CCD を頻繁に使用します。CCD は、PNM が使用するネットワークアダプタ構成データの格納にも使用されます。クラスタの HA 構成または PNM 構成を変更した後は、将来障害が発生する場合に起き得る問題への対応策として、-c オプションを使用して CCD の現在の有効スナップショットをキャプチャすることを強くお勧めします。この必要性は、データベース管理者やシステム管理者が、予測できない状況によって起きる将来のデータ損失を防ぐためにデータを頻繁にバックアップしなければならないのと同じです。

CCD の全体的な整合性を検証するには

動的 CCD を検証する場合は、-v オプションを実行してください。

このオプションは、すべてのクラスタノード上の各 CCD コピーの整合性記録を比較します。この比較により、すべてのノードに渡ってデータベースに矛盾がないことを検証できます。この検証が行われる間、CCD の照会は無効になります。 

# ccdadm clustername -v

CCD のバックアップをとるには

-c オプションは、週に 1 度実行するか、CCD のバックアップごとに実行してください。

このオプションは、動的 CCD のバックアップコピーを作成します。作成したバックアップコピーは、-r オプションで動的 CCD を復元する場合に使用できます。詳細は、「CCD を復元するには」を参照してください。

注 -

CCD をバックアップする場合は、ccdadm -c コマンドを実行する前にすべての論理ホストを保守モードにしてください。論理ホストは、CCD データベースの復元時にも保守モードにする必要があります。したがって、復元状態に近いバックアップファイルを用意すれば、不要なエラーや問題を防止できます。 

# ccdadm clustername -c checkpoint-filename

checkpoint-filename には、バックアップコピーの名前を指定します。

CCD を復元するには

CCD が破損した場合は、-r オプションを指定して ccdadm(1M) を実行してください。このオプションは、動的 CCD の現在のコピーを破棄し、指定される復元ファイルの内容を使用して復元を行います。このコマンドは、クラスタの再起動時に、ccdd(1M) 再構成アルゴリズムが有効な CCD コピーを選択するのに失敗した後、動的 CCD を初期化または復元する場合に使用してください。復元が終わると、CCD は有効と見なされます。

  1. 必要に応じて、定足数を無効にします。

    詳細は 「CCD 定足数を有効 / 無効にするには」を参照してください。

    # ccdadm clustername -q off

  2. 論理ホストを保守モードにします。

    # haswitch -m logicalhost

  3. CCD を復元します。

    restore-filename には、復元するファイルの名前を指定します。

    # ccdadm clustername -r restore-filename

  4. 必要に応じて、CCD 定足数を有効に戻します。

    # ccdadm clustername -q on

  5. 論理ホストをオンラインに戻します。

    次に例を示します。 


    # haswitch phys-host1 logicalhost1
 # haswitch phys-host2 logicalhost2

CCD 定足数を有効 / 無効にするには

一般に、クラスタソフトウェアは、CCD を更新する前に定足数を必要とします。-q オプションを使用すると、この制限を無効にし、任意の数のノードで CCD を更新できます。

-q オプションは、動的 CCD の更新または復元時に定足数を有効または無効にする場合に使用します。quorum_flag は、オン (定足数を有効にする) とオフ (定足数を無効にする) のトグルになっています。定足数は、デフォルトでは有効に設定されています。

たとえば、3 つの物理ノードが存在する場合、更新を行うには少なくても 2 つのノードが必要です。ハードウェア障害のために 1 つのノードしか起動できない場合は、クラスタソフトウェアは CCD の更新を認めません。しかし、ccdadm -q コマンドを実行すると、ソフトウェアの制御を無効にして CCD を更新できます。

# ccdadm clustername -q on|off

CCD を浄化 (purify) するには

-p オプションは、CCD データベースファイルを浄化 (内容を検証して構文をチェックする) します。このオプションは、CCD データベースファイルに構文エラーがある場合に実行してください。 

# ccdadm -p CCD-filename

-p オプションは、指定されたファイル内の書式エラーを報告し、修正されたコピーを .pure という拡張子の付いたファイルに書き込みます。この「浄化された」ファイルは、新しい CCD データベースとして復元に使用できます。詳細は、「CCD を復元するには」を参照してください。

共有 CCD を無効にするには

障害追跡を行う場合や、共有 CCD が不要になるように 2 ノードクラスタを 3 ノードクラスタに変更するような場合は、共有 CCD を無効にできます。

  1. クラスタ内の 1 つのノードを停止します。

    次のコマンドは、phys-hahost2 を停止します。

    phys-hahost2# scadmin stopnode

  2. 共有 CCD を安全な位置にバックアップします。

  3. scconf(1M) コマンドを使用して、共有 CCD を無効にします。

    このコマンドは、すべてのノードで実行してください。

    phys-hahost1# scconf -S none

  4. 共有ディスクセットから両方のノードに CCD をコピーします。

  5. 共有 CCD ボリュームのマウントを解除します。

    phys-hahost1# umount /etc/opt/SUNWcluster/conf/ccdssa

  6. 共有 CCD が存在するディスクグループをデポートします。 

    phys-hahost1# vxdg deport sc_dg

  7. 停止したノードを再起動します。 

    phys-hahost2# scadmin startnode

    以上の作業で、各ノードのプライベート CCD が同じになります。共有 CCD を元どおり有効にするには、『Sun Cluster 2.2 ソフトウェアのインストール』の SSVM の構成に関する付録に示された手順に従ってください。

CCD の障害追跡

システムは、CCD 内のエラーを /var/opt/SUNWcluster/ccd/ccd.log ファイルに記録します。重大なエラーメッセージは、クラスタコンソールにも渡されます。さらに、クラッシュというまれな状況が発生した場合は、/var/opt/SUNWcluster/ccd にコアファイルが作成されます。

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

lpc204# cat ccd.log
Apr 16 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) starting `START' transition 
with time-out 10000
Apr 16 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) completed `START' transition 
with status 0
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) starting `STEP1' transition 
with time-out 20000
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1000]: (info) Nodeid = 0 Up = 0 Gennum = 0 
Date = Feb 14 10h30m00 1997 Restore = 4
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1002]: (info) start reconfiguration elected 
CCD from Nodeid = 0
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1004]: (info) the init CCD database is 
consistent
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1001]: (info) Node is up as a one-node 
cluster after scadmin startcluster; skipping ccd quorum test
Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) completed `STEP1' transition 
with status 0

次の表は、主なエラーメッセージと問題の解決方法を示しています。エラーメッセージの一覧は、『Sun Cluster 2.2 Error Messages Manual』を参照してください。

表 4-1 クラスタ構成データベースの主なエラーメッセージ

番号範囲 

説明 

処理 

4200 

Cannot open file 

ccdadm -r コマンドを実行して CCD を復元する

4302 

File not found 

ccdadm -r コマンドを実行して CCD を復元する

4307 

Inconsistent Init CCD 

Sun Cluster ソフトウェアを削除し、再度インストールする 

4402 

Error registering RPC server 

パブリックネットワークを確認する (ネットワーク障害) 

4403 

RPC client create failed 

パブリックネットワークを確認する (ネットワーク障害) 

5000 

System execution error 

スクリプトの権限を確認する (同期スクリプトにエラーがある) 

5300 

Invalid CCD, needs to be restored 

ccdadm -r コマンドを実行して CCD を復元する

5304 

Error running freeze command 

スクリプトの書式が正しいか確認する (実行された同期スクリプトに不正な引数が存在する) 

5306 

Cluster pointer is null 

入力したクラスタ名が正しいか確認する (このメッセージは ccdadm cluster に指定されたクラスタが存在しないことを示す)

共有ディスクの予約 (SSVM と CVM)

ボリュームマネージャによって管理されるディスク一覧は、障害防御用のデバイスセットとして使用されます。システム内にディスクグループが存在しない場合、障害防御用のデバイスは存在しません (保護すべきデータが実際に存在しないため)。しかし、ノードがクラスタに存在しない間に新しい共有ディスクグループがインポートされる場合には、追加分のデバイスセットが障害防御を必要とすることをクラスタに知らせる必要があります。

共有デバイスを予約するには (SSVM と CVM)

ノードがクラスタに存在しない間に新しい共有ディスクグループがインポートされる場合、追加分のデバイスセットが障害防御を必要とすることをクラスタに知らせる必要があります。これは、新しいディスクグループにアクセスできるノードから scadmin resdisk コマンドを実行して行えます。

# scadmin resdisks

同じデバイスセットに接続できるノードがクラスタメンバーシップにほかに存在しない場合、このコマンドは 1 つのノードに接続されたすべてのデバイスを予約します。つまり、そのデバイスに実際に直結されたすべてのノードのうち 1 つのノードだけがクラスタメンバーシップに入っている場合にかぎり予約が行われます。この条件が満たされない場合、scadmin resdisks コマンドは無効です。このコマンドは、クラスタ再構成が進行中の場合も失敗します。共有デバイスの予約は、この唯一のノードが停止した場合や、その共有デバイスに直結されたほかのノードがクラスタメンバーシップに加わる場合に自動的に解除されます。

注 -

すべてのノードがクラスタに存在する間に共有ディスクグループがインポートされる場合は、scadmin resdisks コマンドを実行する必要はありません。予約と障害防御は、完全なクラスタメンバーシップが存在する場合には適用されません。

ただし、共有ディスクグループがデポートされると、デポートされたディスクグループ内の共有デバイスに対する予約は解除されません。これらの予約は、予約を行うノードが停止されるか、デバイスを共有するほかのノードがクラスタに加わるまでは解除されません。

デポートされたディスクグループに属するディスクをすぐに使用できるようにするには、共有ディスクグループをデポートした後、すべてのディスクノードで、連続して次の 2 つのコマンドを入力します。

# scadmin reldisks
# scadmin resdisks

最初のコマンドは、すべての共有デバイスの予約を解除します。2 つ目のコマンドは、現在インポートされているディスクグループセットにもとづいて実際に再予約を行い、デポートされたディスクグループに関連付けられた一連のディスクを自動的に除外します。

電力損失 (停電) からの回復

この章では、さまざまな電力損失について説明し、システムを通常の状態に戻すための手順を示します。この章で説明する項目は次のとおりです。

Sun Cluster 構成の管理には、電力損失のような障害の処理も含まれます。電力損失が発生すると、Sun Cluster 構成全体が停止することもあれば、構成内の一部のコンポーネントが停止することもあります。Sun Cluster ノードの動作は、停電するコンポーネントによって異なります。以下の各節は、典型的な状況と回復方法を説明しています。

完全な電力損失からの回復

単一の電源を使用した Sun Cluster 構成では、停電が起きると多重ホストディスク拡張装置と共にすべての Sun Cluster ノードが停止します。すべてのノードで停電が起きると、構成全体が停止します。

完全な停電が起きた場合、クラスタハードウェアを動作状態に戻す試みとして、次の 2 つの方法を使用できます。

部分的な電力損失からの回復

Sun Cluster ノードと多重ホストディスク拡張装置が個別の電源を使用している場合は、停電によってコンポーネントが停止する可能性があります。発生する可能性の高い状況を次に示します。

1 つのノードの停電

ノードと多重ホストディスク拡張装置が個別の電源を使用している場合にノードの 1 つだけが停電すると、ほかのノードがその停電を検出し、テイクオーバーを開始します。

停電したノードは、電力が戻ると再起動します。クラスタは、scadmin startnode コマンドを使用して結合し直す必要があります。その後で、デフォルトの論理ホストの所有権を復元するために、haswitch(1M) コマンドを使用して手動でスイッチオーバーを行います。

多重ホストディスク拡張装置の停電

多重ホストディスク拡張装置の 1 台が停電すると、ボリューム管理ソフトウェアが影響を受けたディスクのエラーを検出し、それらをエラー状態にするアクションを実行します。ディスクがミラー化されていると、この停電は Sun Cluster の障害監視に検出されず、スイッチオーバーとテイクオーバーは発生しません。

多重ホストディスク拡張装置に電力が戻った時点で、第 11 章「SPARCstorage Array の管理」または第 12 章「Sun StorEdge MultiPack と Sun StorEdge D1000 の管理」で説明している作業を行なってください。

1 台のサーバーと 1 台の多重ホストディスク拡張ユニットの停電

Sun Cluster ノードの 1 つと多重ホストディスク拡張装置の 1 台が停電すると、二次ノードがすぐにテイクオーバーを開始します。

電力が戻った後で、ノードを再起動し、scadmin startnode コマンドを使用してそのノードを構成に加え直し、監視作業を開始する必要があります。手動のスイッチオーバーが構成されている場合は、haswitch(1M) コマンドを使用して、停電したノードにディスクセットの所有権を手動で戻してください。詳細は、「論理ホストのスイッチオーバー」を参照してください。

ディスクセットの所有権がデフォルトマスターに戻された後、エラーを報告した多重ホストディスクをすべてサービスの状態に戻す必要があります。この方法については、使用しているディスク拡張装置に関する章に示された作業方法を参照してください。

注 -

ノードは、多重ホストディスク拡張装置を再起動する前に再起動する場合があります。その場合、関連付けられたディスクにはアクセスできません。多重ホストディスク拡張装置が起動した後に、ノードを再起動してください。

システムへの電源投入

システムキャビネット、ノード、起動ディスクに電源を入れる方法は、使用しているキャビネットの種類と、ノードの AC 配電の状態によって異なります。

独立した電源から AC 電力を受けないディスクアレイの場合、システムキャビネットの電源投入時に電源が入ります。

Sun StorEdge MultiPack の個々の電源投入方法については、『Sun StorEdge MultiPack Service Manual』を参照してください。

システムキャビネットから AC 電力を受ける端末集配信装置は、キャビネットの電源投入時に電源が入ります。システムキャビネットからの配電がない場合は、個々に電源を入れる必要があります。

ネットワークインタフェースの管理

この章では、Sun Cluster のパブリックネットワーク管理 (PNM) の機能と、ネットワークインタフェースコンポーネントの追加または交換を行う方法について説明します。この章で説明する項目は次のとおりです。

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

パブリックネットワーク管理 (PNM) の概要

Sun Cluster の PNM 機能は、障害監視とフェイルオーバーによって、単一のネットワークアダプタまたはケーブルの障害によってノードが使用できなくなる状況を防ぎます。PNM の障害監視は、ローカルノードモードまたは全クラスタモードで、ノード、ネットワークアダプタ、ケーブル、ネットワークトラフィックの状態を確認します。PNM フェイルオーバーは、「バックアップグループ」と呼ばれるネットワークアダプタセットを使用して、クラスタノードとパブリックネットワーク間に冗長接続を提供します。障害監視機能とフェイルオーバー機能は、サービス継続のため連携して動作します。

HA データサービスは、PNM の障害監視に依存します。そのため、構成に HA データサービスが含まれる場合は、PNM を有効にする必要があります。HA データサービスで可用性問題が発生すると、HA データサービスはその問題がパブリックネットワーク接続に関連したものであるかを確認するため、クラスタフレームワークを介して PNM に問い合わせます。パブリックネットワーク接続に関連している場合、データサービスは PNM が問題を解決するまで待ちます。パブリックネットワーク接続に関連していない場合、データサービスは独自のフェイルオーバー機構を呼び出します。

PNM パッケージ SUNWpnm は、Sun Cluster ソフトウェアの最初のインストール時にインストールされます。PNM に関連するコマンドを次に示します。

詳細は、対応するマニュアルページを参照してください。

PNM の障害監視とフェイルオーバー

PNM は、クラスタ内の各ノードに対応するパブリックネットワークとネットワークアダプタの状態を監視し、疑わしい状態またはエラー状態を報告します。主アダプタ (現在、ノードとの間でネットワークトラフィックを伝送しているアダプタ) からの応答がないことを感知すると、PNM はそのノードのアダプタバックアップグループに存在する別の稼動アダプタに、ネットワークサービスをフェイルオーバーします。続いて、PNM は、アダプタとネットワークのどちらに障害が発生しているかを確認します。

アダプタ障害の場合、PNM は syslog(3) にエラーメッセージを送ります。このエラーメッセージは、次にクラスタマネージャによって検出され、GUI を介してユーザーに表示されます。障害が発生したアダプタは、修復された後、次のクラスタ再構成時にバックアップグループで自動的にテストされ回復されます。アダプタバックアップグループ全体がダウンしている場合には、Sun Cluster フレームワークはノードのフェイルオーバーを呼び出して、ノードを使用できる状態に保ちます。サブネット全体の障害のようにエラーが PNM 制御の範囲外で発生した場合には、通常のフェイルオーバーとクラスタ再構成が行われます。

PNM 監視は、クラスタ認識モードとクラスタ非認識モードで行われます。PNM は、クラスタが使用可能な場合、クラスタ認識モードで動作します。PNM は、クラスタ構成データベース (CCD) を使用して、ネットワークの状態を監視します。CCD の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』の概要の章を参照してください。PNM は、CCD を使用して、パブリックネットワーク障害とローカルアダプタ障害を区別します。パブリックネットワーク障害によって起きる論理ホストのフェイルオーバーについては、「Sun Cluster の障害検証」を参照してください。

PNM は、クラスタが使用不可能な場合、クラスタ非認識モードで動作します。このモードでは PNM は CCD を使用できないため、PNM はアダプタ障害とネットワーク障害を区別できません。クラスタ非認識モードでは、PNM はローカルネットワーク接続の問題を検出するだけです。

パブリックネットワークとアダプタの状態は、PNM 監視コマンド pnmstat(1M) を使用して確認できます。詳細は、マニュアルページを参照してください。

バックアップグループ

バックアップグループは、単一のクラスタノードとパブリックネットワーク間に冗長接続を提供するネットワークアダプタセットです。バックアップグループは、最初のインストール時に scinstall(1M) コマンドを使用して構成するか、最初のインストールの後で pnmset(1M) コマンドを使用して構成します。冗長アダプタは、単一のホスト上にいくつでも構成できます。

バックアップグループを初めて構成する場合は、クラスタが起動する前に root として pnmset(1M) を実行します。このコマンドは、対話型のスクリプトとして動作し、バックアップグループの構成と検証を行います。このコマンドは、主 (アクティブ) アダプタとして使用されるアダプタの選択も行います。pnmset(1M) コマンドは、バックアップグループに nafon という名前を付けます (n はユーザーが割り当てる整数)。このコマンドは、バックアップグループ情報を /etc/pnmconfig ファイルに格納します。

クラスタノードの既存の PNM 構成を変更するには、クラスタからそのノードを削除し、続いて pnmset(1M) コマンドを実行する必要があります。PNM は、変更を監視して、バックアップグループメンバーシップにその変更を動的に組み入れます。

注 -

ソフトウェアのアップグレードなどの際に SUNWpnm パッケージが削除されても、/etc/pnmconfig ファイルは削除されません。つまり、ソフトウェアアップグレードが行われてもバックアップグループのメンバーシップ情報は維持されるため、バックアップグループメンバーシップの変更が必要ない場合は、pnmset(1M) ユーティリティを再実行する必要はありません。

nsswitch.conf に対する更新

バックアップネットワークアダプタを使用して PNM を構成する場合、/etc/nsswitch.conf ファイルに netmasks エントリとして次の 1 つを指定します。

表 6-1 /etc/nsswitch.conf ファイルのネームサービスエントリの選択

使用中のネームサービス 

netmasks エントリ

なし 

netmasks: files

nis

netmasks: files [NOTFOUND=return] nis

nisplus

netmasks: files [NOTFOUND=return] nisplus

上記の設定が行われると、NIS/NIS+ ルックアップテーブルで netmasks 設定は照合されません。このことは、障害が発生したアダプタが主パブリックネットワークであり、そのため要求された情報を提供できない場合に重要な意味を持ちます。ネットマスクエントリが所定の方法で設定されない場合、バックアップアダプタに対するフェイルオーバーは成功しません。

注意 - 注意 -

上記の変更が行われると、ルックアップテーブルとしてローカルファイル /etc/netmasks と /etc/groups が使用されます。NIS/NIS+ サービスは、これらのローカルファイルが使用できない場合にだけ使用されます。そのため、これらのファイルはその NIS/NIS+ バージョンを使用して最新の状態に保つ必要があります。更新が行われないと、クラスタノードでこれらのファイル内の期待値にアクセスできなくなります。

パブリックネットワーク管理 (PNM) の設定

この節では、PNM の設定とバックアップグループの構成を行う方法について説明します。

PNM を設定するには

次に、PNM の設定手順の概略を示します。

次に、PNM の詳しい設定手順を示します。

  1. 同じサブセットを使用して、単一のノード上に複数のネットワークアダプタが存在するようにノードハードウェアを設定します。

    ネットワークアダプタを設定するには、Sun Cluster ノードのハードウェアのマニュアルを参照してください。

  2. Sun Cluster ノードソフトウェアパッケージがまだインストールされていない場合は、scinstall(1M) コマンドを使用してそれらをインストールします。

    scinstall(1M) コマンドで、選択されたパッケージを対話形式でインストールします。PNM パッケージ SUNWpnm は、ノードパッケージセットの一部です。クラスタのインストール作業の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

  3. 各ノードでデフォルトのネットワークインタフェースを登録します (まだ登録されていない場合)。

    各ノードに対応するインタフェースデータベース内のノードごとにデフォルトネットワークインタフェースを 1 つ登録するとともに、そのインタフェースが取り付けられ、正常に動作していることを確認する必要があります。

    1. 各ノードでインタフェースデータベースを作成し、主パブリックネットワークインタフェースを登録します。

      各ノードの /etc ディレクトリに、インタフェースデータベースとして使用するファイルを作成します。このファイルに、hostname.interfaceという名前を付けます (hostname は主物理ホストの名前)。続いて、そのノードのインタフェース名が入った 1 行を追加します。たとえば、デフォルトインタフェース qfe-1 を持つノード phys-hahost1 で、次に示す行が入ったファイル /etc/phys-hahost1.qfe1 を作成します。 

      phys-hahost1-qfe1

    2. 各ノードの /etc/hosts ファイルで、主パブリックネットワークインタフェース名と IP アドレスを関連付けます。

      次の例では、主物理ホスト名は phys-hahost1 です。

      129.146.75.200 phys-hahost1-qfe1

      システムが /etc/hosts 以外の命名方法を使用している場合は、『TCP/IP とデータ通信』の該当する説明を参照し、同等の機能を実行してください。

  4. pnmset(1M) コマンドを使用して、PNM バックアップグループを作成します。

    対話式の pnmset(1M) スクリプトを実行して、バックアップグループを設定してください。

    注意 - 注意 -

    論理ホストとデータサービスをすでに構成してある場合は、pnmset(1M) を使用してバックアップグループメンバーシップを変更する前に、HA データサービスを停止する必要があります。pnmset(1M) コマンドを実行する前にデータサービスを停止しないと、重大な問題やデータサービス障害が発生することがあります。

    1. pnmset(1M) コマンドを実行します。

      phys-hahost1# /opt/SUNWpnm/bin/pnmset

    2. 構成するバックアップグループの合計数を入力します。

      通常、この数はパブリックサブネットの数に一致します。

      In the following dialog, you will be prompted to configure public 
network management.

 do you want to continue ... [y/n]: y

 How many NAFO backup groups on the host [1]: 2

    3. バックアップグループ番号を割り当てます。

      プロンプトで、0 〜 255 (最大) の範囲で整数を指定します。pnmset(1M) コマンドは、この数字を文字列 nafo に加えてバックアップグループ名にします。

      Enter backup group number [0]: 0

    4. アダプタをバックアップグループに割り当てます。

      Please enter all network adapters under nafo0:
 qe0 qe1
...

      続けて、構成内のほかのすべてのバックアップグループに、バックアップグループ番号とアダプタを割り当てます。

    5. pnmset(1M) コマンドによって、アダプタ構成のテストが始まります。

      pnmset(1M) コマンドは、アダプタ構成の正確さをテストします。この例では、バックアップグループにアクティブアダプタが 1 つ、冗長アダプタが 2 つ含まれています。

      The following test will evaluate the correctness of the customer 
NAFO configuration...
 name duplication test passed


 Check nafo0... < 20 seconds
 qe0 is active
 remote address = 192.168.142.1
 nafo0 test passed


 Check nafo1... < 20 seconds
 qe3 is active
 remote address = 192.168.143.1
 test qe4 wait...
 test qe2 wait...
 nafo1 test passed
 phys-hahost1#

      構成の検証が終わると、PNM デーモン pnmd(1M) は自動的に構成の変更を認識し、インタフェースの監視を開始します。

      注 -

      バックアップグループのアダプタの内、取り付けが行われ、/etc/hostname.adapter というファイルにエントリを持つのは、1 つのアダプタだけです。バックアップアダプタに IP アドレスは割り当てないでください。バックアップアダプタは取り付けられません。

      注 -

      PNM は、ブロードキャスト ping(1M) を使用してネットワークを監視します。ネットワークは、ブロードキャスト ICMP (Internet Control Message Protocol) パケットを使用して、ほかの遠隔ホストと通信を行います。ルーターの中にはブロードキャスト ICMP パケットを転送しないものがあり、PNM の障害検出動作はこの影響を受けます。この問題の対策については、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

  5. scadmin(1M) コマンドを使用してクラスタを起動します。

    1 つのノードで、次のコマンドを実行してください。

    # scadmin startcluster physical-hostname sc-cluster

    続いて、ほかのすべてのノードで次のコマンドを実行し、クラスタにほかのすべてのノードを追加してください。

    # scadmin startnode

  6. pnmstat(1M) コマンドを使用して、PNM 構成を検証します。

    phys-hahost1# /opt/SUNWpnm/bin/pnmstat -l
bkggrp  r_adp   status  fo_time live_adp
 nafo0   hme0    OK      NEVER   hme0
 phys-hahost1#

    以上で、PNM の初期設定は終了です。

PNM を再構成するには

ネットワークアダプタを追加または削除して既存の PNM 構成を再構成する方法を次に示します。作業中も Sun Cluster サービスを利用できるように、この手順は一度に 1 つのノードに対して行なってください。

  1. 再構成するノードで、Sun Cluster ソフトウェアを停止します。 

    phys-hahost1# scadmin stopnode

  2. ネットワークアダプタを追加または削除します。

    「ネットワークインタフェースの追加と削除」に説明されている作業を行なってください。

  3. pnmset(1M) コマンドを実行して、バックアップグループを再構成します。

    「PNM を設定するには」の手順 4 に説明されているように、pnmset(1M) コマンドを使用してバックアップグループを再構成してください。

    phys-hahost1# pnmset

  4. そのノードで、Sun Cluster ソフトウェアを再起動します。

    管理ワークステーションから次のコマンドを実行して、ノードを再起動してください。

    phys-hahost1# scadmin startnode

  5. 再構成するノードごとに、手順 1 〜 4 を繰り返します。

バックアップグループの状態を確認するには

pnmptor(1M) と pnmrtop(1M) コマンドを使用すると、ローカルバックアップグループだけの状態を確認できます。pnmstat(1M) コマンドを使用すると、ローカルまたは遠隔のバックアップグループの状態を確認できます。

    アダプタが属しているバックアップグループを確認するには、pnmptor(1M) コマンドを実行します。

pnmptor(1M) コマンドは、実際のアダプタ名に指定する疑似アダプタ名を割り当てます。次の例では、システム出力は、疑似アダプタ名 nafo0 がアクティブアダプタ hme2 に対応することを示しています。

phys-hahost1# pnmptor nafo0
hme2

    特定のバックアップグループに対応するアクティブアダプタを確認するには、pnmrtop(1M) コマンドを実行してください。

次の例では、システム出力は、アダプタ hme1 がバックアップグループ nafo0 に属することを示しています。

phys-hahost1# pnmrtop hme1
nafo0

    バックアップグループの状態を確認するには、pnmstat(1M) コマンドを実行します。

ローカルホスト上のバックアップグループの状態を確認するには、-c オプションを使用します。

phys-hahost1# pnmstat -c nafo0
OK
 NEVER
 hme2

遠隔ホスト上のバックアップグループの状態を確認するには、次の構文を使用します。

phys-hahost1# pnmstat -sh remotehost -c nafo1
 OK
 NEVER
 qe1
注 -

-s と -h オプションを共に使用することは重要です。-s オプションが指定されると、pnmstat(1M) はプライベートインターコネクトを介して通信を行います。-s オプションが省略されると、pnmstat(1M) はパブリックインターコネクトを介して照会を行います。remotehost と pnmstat(1M) を実行するホストは、両方ともクラスタメンバーでなければなりません。

ローカルホストと遠隔ホストのどちらを確認している場合でも、pnmstat(1M) コマンドは状態、履歴、現在のアクティブアダプタを報告します。詳細は、マニュアルページを参照してください。

構成可能な PNM パラメータ

次の表は、ユーザーが構成できる PNM パラメータについて説明しています。これらのパラメータは、PNM をインストールした後で (ただしクラスタを立ち上げる前)、クラスタ内のすべてのノードの構成ファイル /opt/SUNWcluster/conf/TEMPLATE.cdb を手作業で編集して構成してください。1 つのノードで編集したファイルをほかのすべてのノードにコピーすることも、クラスタコンソールを使用してすべてのノードでファイルを同時に変更することも可能です。現在の PNM 構成は、pnmset -l を使用して表示できます。

表 6-2 構成可能な PNM パラメータ

pnmd.inactive_time

秒単位で示した障害検証間の時間。デフォルトの間隔は 5 秒。 

pnmd.ping_timeout

秒単位で示した、障害検証がタイムアウトするまでの時間。デフォルトのタイムアウト値は 4 秒。 

pnmd.repeat_test

PNM が失敗した検証を再試行する回数。この回数を過ぎると、PNM は障害があると判断する。デフォルトの反復数は 3 回。 

pnmd.slow_network

秒単位で示した、障害検証の待機 (listen) 段階とアクティブ検証段階の間の応答時間。デフォルトの応答時間は 2 秒。ネットワークが遅く、PNM が疑似テイクオーバーを引き起こす場合は、この応答時間を増やすとよい。 

PNM エラーの障害追跡

以下に、PNM が返す主なエラーを示します。 

PNM rpc svc failed

このエラーは、PNM デーモンがまだ起動していないことを示します。次のコマンドを使用して、PNM を再起動してください。node-id は、/opt/SUNWcluster/bin/get_node_status コマンドによって返される値です。


# /opt/SUNWpnm/bin/pnmd -s -c clustername -l node-id



PNM not started

このメッセージは、バックアップグループが構成されていないことを示します。バックアップグループを作成するには、pnmset(1M)コマンドを使用してください。

No nafoXX

このメッセージは、無効なバックアップグループ名が指定されたことを示します。特定のアダプタに対応するバックアップグループ名を確認するには、pnmrtop(1M) コマンドを使用してください。有効なバックアップグループ名を使用して、コマンドを再実行してください。

PNM configure error

このメッセージは、PNM デーモンがアダプタを構成できなかったか、構成ファイル /etc/pnmconfig にフォーマットエラーがあるかのいずれかを示しています。syslog メッセージを確認し、Sun Cluster Manager で指定された作業を行なってください。詳細は第 2 章「Sun Cluster の管理ツール」を参照してください。

Program error

このメッセージは、PNM デーモンがシステムコールを実行できなかったことを示しています。syslog メッセージを確認、Sun Cluster Manager で指定された作業を行なってください。詳細は第 2 章「Sun Cluster の管理ツール」を参照してください。

ネットワークインタフェースの追加と削除

この節で説明する作業は、クラスタ構成内のパブリックネットワークインタフェースカードの追加または削除に使用できます。

論理ホストの制御にネットワークインタフェースを追加または削除するには、そのインタフェースを使用するように構成された各論理ホストを変更する必要があります。論理ホストの構成を変更するには、クラスタからその論理ホストを完全に削除した後、必要な変更を加えて追加し直します。論理ホストは、scconf(1M) または scinstall(1M) コマンドを使用して再構成できます。この節の例では、scconf(1M) コマンドを使用しています。scinstall(1M) コマンドによる論理ホストの構成手順については、「論理ホストの追加と削除」を参照してください。

ネットワークインタフェースの追加

ネットワークインタフェースを追加するには、そのインタフェースに対応する論理ホストの構成を解除し、再構成します。この作業は短時間ですみますが、その間すべてのデータサービスはアクセスできなくなることに注意してください。

ネットワークインタフェースを追加するには

新しいネットワークインタフェースを追加するノードごとに、次の手順を実行します。

  1. クラスタソフトウェアを停止します。

    phys-hahost# scadmin stopnode

  2. カードに付属している説明書の指示に従って、新しいインタフェースカードを追加します。

  3. 各ノードで、新しいネットワークインタフェースを構成します。

    この手順は、新しいインタフェースが論理ホストの一部である場合だけ必要です。構成に論理ホストが含まれない場合、この手順は省略してください。

    phys-hahost# pnmset

    Ethernet の場合、各ノードの新しいインタフェースごとに新しい /etc/hostname.if ファイルを作成し、非クラスタ環境で通常行うように ifconfig(1M) コマンドを実行します。

    注 -

    複数のネットワークインタフェースをクラスタ内の別々の論理ホストで使用するように構成する場合、それらのインタフェースをすべて同じサブネットに接続する必要があります。

  4. クラスタソフトウェアを起動します。

    すべてのノードが停止している場合は、ノード 0 で scadmin startcluster コマンドを実行し、続いてほかのすべてのノードで scadmin startnode コマンドを実行してください。クラスタソフトウェアを停止していないノードがある場合は、ほかのノードで scadmin startnode コマンドを実行してください。

    phys-hahost# scadmin startnode

    新しいインタフェースが既存のバックアップグループに追加される場合は、作業は以上で終了します。

    バックアップグループ構成を変更した場合は、クラスタを通常のオペレーションに戻し、新しいネットワークコントローラセットを使用する各論理ホストを再構成する必要があります。論理ホストごとに構成を解除して再構成するため、これらの手順を開始する前に scconf -p コマンドを実行して現在の構成を出力してください。scconf -p コマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    論理ホストの構成を解除して再構成するには、これらの例に示されているように scconf(1M) コマンドを使用するか、「論理ホストの追加と削除」に説明されているように scinstall(1M) コマンドを使用できます。

  5. 影響を受ける論理ホストのデータサービスがしばらく使用できなくなることをユーザーに知らせます。

  6. 元の構成に復元する場合に備えて、各ノードの /etc/opt/SUNWcluster/conf/ccd.database ファイルのコピーを保存します。

  7. データサービスを無効にします。

    phys-hahost# hareg -n dataservice

  8. データサービスの登録を解除します。

    phys-hahost# hareg -u dataservice

  9. クラスタから論理ホストを削除します。

    アクティブクラスタメンバーである任意のノードで、次のコマンドを実行してください。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -r

  10. 論理ホストを再構成して、新しいインタフェースを含めます。

    アクティブクラスタメンバーである任意のノードで次のコマンドを実行してください。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -n nodelist -g dglist -i logaddrinfo

    logaddrinfo フィールドには、新しいインタフェース名を指定します。各論理ホストを再構成するには、scconf -p コマンド出力で表示されるリストを参照してください。

  11. データサービスを再登録します。

    phys-hahost# hareg [-s] -r dataservice

  12. データサービスを有効にします。

    phys-hahost# hareg -y dataservice

  13. データサービスに対するアクセスを確認します。

  14. データサービスが元どおり使用できるようになったことをユーザーに知らせます。

    以上で、ネットワークインタフェースの追加作業は終了です。

ネットワークインタフェースの削除

クラスタからパブリックネットワークインタフェースを削除するには、次の作業を行なってください。

ネットワークインタフェースを削除するには

すべてのノードがクラスタに属している間に、1 つのノードだけで次の手順を実行してください。

  1. ネットワークインタフェースを削除するために、どの論理ホストの再構成が必要かを確認します。

    これらの論理ホストはすべて、構成を解除した後で再構成する必要があります。scconf -p コマンドを実行して現在の構成の論理ホストの一覧を出力し、後で使用できるようにこの一覧を保存してください。scconf -p コマンドは、すべてのクラスタノードで実行する必要はありません。このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。

  2. pnmset(1M) コマンドを実行し、現在の PNM 構成を表示します。

  3. 必要に応じて、バックアップグループからコントローラを削除します。

    削除するコントローラがバックアップグループの一部である場合は、すべての論理ホストからコントローラを削除し、その後 pnmset(1M) コマンドを実行してバックアップグループからコントローラを削除します。

  4. 影響を受ける論理ホストのデータサービスがしばらく使用できなくなることをユーザーに知らせます。

  5. データサービスを無効にします。

    phys-hahost# hareg -n dataservice

  6. データサービスの登録を解除します。

    phys-hahost# hareg -u dataservice

  7. クラスタから論理ホストを削除します。

    注 -

    論理ホストの構成を解除して再構成する (手順 7と 手順 8) には、これらの手順で示されているように scconf(1M) コマンドを実行することも、「論理ホストの追加と削除」で説明しているように scinstall(1M) コマンドを実行することもできます。

    このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -r

  8. 論理ホストを再構成して、新しいインタフェースを含めます。

    このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -n nodelist -g dglist -i logaddrinfo

    logaddrinfo フィールドには、新しいインタフェース名を指定します。各論理ホストを再構成するには、scconf -p コマンド出力で表示される一覧を参照してください。

  9. 削除するコントローラがバックアップグループの一部である場合は、pnmset(1M) コマンドを再実行します。

    pnmset(1M) コマンドを再実行し、コントローラを削除してください。

  10. (省略可能) ノードからネットワークアダプタを削除する場合は、影響を受ける各ノードで次の手順を実行します。

    1. クラスタソフトウェアを停止します。

      phys-hahost# scadmin stopnode

    2. ノードを停止し、インタフェースカードを取り外します。

    3. ノードを起動します。

    4. 通常行う Solaris システム管理作業 (hostname.if ファイルの削除、/etc/hosts の更新など) を実行して、ネットワークインタフェースを削除します。

    5. クラスタソフトウェアを再起動します。すべてのノードが停止されている場合は、scadmin startcluster コマンドを使用して最初のノードを起動します。クラスタソフトウェアをまだ実行しているノードがある場合は、ほかのノードを再起動します。

      phys-hahost# scadmin startnode

  11. データサービスを登録します。

    phys-hahost# hareg -r dataservice

  12. データサービスを有効にします。

    phys-hahost# hareg -y dataservice

  13. データサービスに対するアクセスを確認します。

  14. データサービスが元どおり使用できるようになったことをユーザーに知らせます。

スイッチ管理エージェントの管理

スイッチ管理エージェント (SMA) は、クラスタプライベートインターコネクトを介して通信チャネルを管理するクラスタモジュールです。SMA は、プライベートインターコネクトを監視し、障害を検出した場合にバックアップネットワークに対するフェイルオーバーを呼び出します。

作業を開始する前に、次の制限に注意してください。

スイッチと SCI カードを追加するには

クラスタノードにスイッチと SCI カードを追加するには、次の作業を行なってください。詳細は、sm_config(1M) マニュアルページを参照してください。

  1. sm_config 一時ファイルを編集して、構成変更を反映させます。

    この一時ファイルは、通常、/opt/SUNWsma/bin/Examples にあります。

  2. ノードの 1 つから sm_config(1M) コマンドを実行して、SCI SBus カードを構成します。

    このコマンドを再実行して、SCI のノード ID と IP アドレスがクラスタノードに正しく割り当てられていることを確認してください。割り当てが不正に行われていると、ノード間で通信不良が発生することがあります。

  3. 新しいノードを再起動します。

SCI ソフトウェアの障害追跡

SCI に問題が発生した場合は、次の点を確認してください。

次に示す問題とその解決方法も参考にしてください。

ノード間の接続を検査するには

ノード間の接続を検査するには、get_ci_status(1M) または ping(1) を実行できます。

    get_ci_status(1M) コマンドは、すべてのクラスタノードで実行します。

次に、get_ci_status(1M) の出力例を示します。

# /opt/SUNWsma/bin/get_ci_status
sma: sci #0: sbus_slot# 1; adapter_id 8 (0x08); ip_address 1; switch_id# 0; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: sci #1: sbus_slot# 2; adapter_id 12 (0x0c); ip_address 17; switch_id# 1; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: Switch_id# 0
sma: port_id# 1: host_name = interconn2; adapter_id = 72; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 136; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 200; active | operational
sma: Switch_id# 1
sma: port_id# 1: host_name = interconn2; adapter_id = 76; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 140; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 204; active | operational
#

最初の 4 つの行は、ローカルノード (この例では interconn1) の状態を示しています。ローカルノードは、switch_id# 0 および switch_id# 1 と通信しています (Link Status - UP)。

sma: sci #0: sbus_slot# 1; adapter_id 8 (0x08); ip_address 1; switch_id# 0; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: sci #1: sbus_slot# 2; adapter_id 12 (0x0c); ip_address 17; switch_id# 1; 
port_id# 0; Adapter Status - UP; Link Status - UP

ほかの行は、クラスタ内のほかのノードの全体的な状態を示しています。2 つのスイッチ上のノードはすべて、それらのノードと通信しています。ハードウェアに問題があると、active ではなく inactive が表示されます。ソフトウェアに問題があると、operational ではなく inoperational が表示されます。

sma: Switch_id# 0
sma: port_id# 1: host_name = interconn2; adapter_id = 72; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 136; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 200; active | operational
sma: Switch_id# 1
sma: port_id# 1: host_name = interconn2; adapter_id = 76; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 140; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 204; active | operational
#

    ping(1) コマンドは、遠隔ノードのすべての IP アドレスに対して実行します。

次に、ping(1) の出力例を示します。

# ping IP-address

IP アドレスは、/etc/sma.ip ファイルに入っています。ping(1) コマンドは、必ずクラスタ内のノードごとに実行してください。

ping(1) コマンドは、2 つの末端が支障なく通信している場合、「alive」というメッセージを返します。問題がある場合は、エラーメッセージが表示されます。

次に例を示します。

# ping 204.152.65.2
204.152.65.2 is alive

SCI インタフェース構成を検査するには

    すべての SCI インタフェースが動作しており、クラスタノードの IP アドレスが正しいことを確認するには、ifconfig -a コマンドを実行します。

IP アドレスの最後の 8 ビットは、/etc/sma.config ファイルの IP フィールドの値に一致する必要があります。 

# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 	inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
 	inet 129.146.238.55 netmask ffffff00 broadcast 129.146.238.255
 	ether 8:0:20:7b:fa:0
scid0: flags=80cl<UP,RUNNING,NOARP,PRIVATE> mtu 16321
 	inet 204.152.65.1 netmask fffffff0
scid1: flags=80cl<UP,RUNNING,NOARP,PRIVATE> mtu 16321
 	inet 204.152.65.17 netmask fffffff0

サーバーコンポーネントの管理

この章では、Sun Cluster のノードコンポーネントを追加または取り外すためのソフトウェア作業について説明します。この章で説明する項目は次のとおりです。

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

システムボードの交換

Sun Cluster の Solstice DiskSuite コンポーネントはデバイス番号に影響を受けやすいため、システムボードを頻繁に移動させると混乱を起こします。インスタンスの名前と番号付けの詳細は、第 1 章「Sun Cluster の管理の準備」を参照してください。

ノードが最初に起動される時に、/dev ディレクトリ内の多重ホストディスク拡張装置エントリは接続スロットに関連付けられます。

たとえば、ノードが起動される時、システムボード 0 と SBus スロット 1 が多重ホストディスク拡張装置の識別情報の一部となります。このボードまたは SBus カードが新しい位置に移し替えられると、それらが新しい位置に移った時点で Solaris は SBus コントローラに新しいコントローラ番号を割り当てます。そのため、Solstice DiskSuite に混乱が生じます。

注 -

SBus カードは、スロット内の SBus カードの種類が同じであれば、移動できます。

多重ホストディスク拡張装置に通じているファイバケーブルの移動も、問題を起こす可能性があります。SBus カードを切り替える場合は、多重ホストディスク拡張装置も、変更前にそれらが接続されていた SBus スロットに接続し直す必要があります。

ボードレベルモジュールの追加

SIMM や CPU などのボードレベルモジュールの追加または交換を行うには、ソフトウェアとハードウェアの両方の作業が必要です。

ボードレベルモジュールを追加するには

  1. ボードレベルモジュールを追加するノードで、Sun Cluster を停止します。

    この例では、phys-hahost2 がボードレベルモジュールを追加する最初のノードです。

    phys-hahost2# scadmin stopnode

  2. ノードを停止します。

    phys-hahost2# halt

  3. ノードの電源を切ります。

  4. 該当するハードウェアマニュアルの操作指示に従って、ボードレベルモジュールを取り付けます。

  5. ノードに電源を入れます。

  6. 再構成再起動を行います。 

    ok boot -r

  7. ノードで、クラスタソフトウェアを起動します。

    # scadmin startnode

  8. 同様にハードウェアのアップグレードが必要なほかの Sun Cluster ノードで、手順 1 から 手順 7 を繰り返します。

  9. 必要に応じて、各論理ホストをそれらのデフォルトのマスターにスイッチバックします。

    手動モードが設定されていない場合は、自動スイッチバックが行われます。

    phys-hahost2# haswitch phys-hahost1 hahost1

SBus カードの交換

Sun Cluster ノードの SBus カードを交換するには、ボード交換を行う稼動中のノードにデータサービスをスイッチオーバーします。論理ホストは、次の作業でデフォルトマスターにスイッチバックできます。

SBus カードを交換するには

  1. SBus カードの交換が必要な Sun Cluster ノードから、論理ホストの所有権を切り替えます。

    たとえば、物理ホスト phys-hahost2 のボードを交換する場合は、次のように入力します。

    phys-hahost1# haswitch phys-hahost1 hahost1 hahost2

  2. 影響を受けるノードで Sun Cluster を停止します。

    障害のある SBus カードを持つホストで、stopnode オプションを指定して scadmin(1M) コマンドを実行してください。

    phys-hahost2# scadmin stopnode

  3. 影響を受けるノードを停止し、電源を切ります。

  4. ハードウェアの交換作業を行います。

    SBus カードの交換方法は、該当するハードウェアのサービスマニュアルで説明している手順を参照してください。

  5. ノードに電源を入れ、そのノードでクラスタソフトウェアを起動します。

    # scadmin startnode

    ノードは、自動的に Sun Cluster 構成に再結合します。

  6. 必要に応じて、論理ホストをデフォルトのマスターにスイッチバックします。

    手動モードが設定されていない場合、自動スイッチバックが行われます。

    phys-hahost1# haswitch phys-hahost2 hahost2

端末集配信装置の管理

この章では、Sun Cluster 構成の管理を行う場合に端末集配信装置を使用する方法について説明します。この章で説明する項目は次のとおりです。

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

Sun Clusterコンソールへの接続

管理作業は、任意の Sun Cluster ノードに接続されたウィンドウから実行できます。端末集配信装置の最初の設定作業とセキュリティの設定方法は、Sun Cluster ノードのハードウェア計画とインストールに関するマニュアル、および端末集配信装置のマニュアルで説明されています。

次の作業は、Sun Cluster 構成の管理ワークステーションから接続を確立する方法を説明しています。

shelltool(1) には可変の値を指定できる上、接続の確立はシリアルポートコンソールインタフェースを介して行われるため、コンソールポートは接続が確立された shelltool(1) のウィンドウサイズを決定できません。列と行の数についての情報を必要とするアプリケーションの場合、ノードでウィンドウサイズを手動で設定する必要があります。

Sun Cluster サーバーコンソールに接続するには

  1. ワークステーションのデスクトップで、shelltool(1) ウィンドウを開きます。

  2. tput(1) コマンドを実行し、shelltool(1) ウィンドウのサイズを書き留めます。

    このサイズは、手順 6 で使用します。

    # tput lines
35
# tput cols
80

  3. 端末集配信装置を介して Sun Cluster ノードの 1 つに telnet(1) 接続を開くために、次のコマンドを入力します。 

    # telnet terminal-concentrator-name 5002
 Trying 192.9.200.1 ...
 Connected to 192.9.200.1.
 Escape character is '^]'.
    注 -

    ポート番号は構成に依存します。通常、ポート 2 と 3 (この例では 5002 と 5003) は、サイトにおける最初の Solaris クラスタに使用されます。

  4. 別の shelltool(1) ウィンドウを開き、次のコマンドを入力してそのノードに対する telnet(1) 接続を開きます。

    # telnet terminal-concentrator-name 5003
 Trying 192.9.200.1 ...
 Connected to 192.9.200.1.
 Escape character is '^]'.
    注 -

    Sun Cluster ノードのハードウェア計画とインストールに関するマニュアルに説明されているようにセキュリティを設定する場合は、ポートのパスワードの入力を求める画面が表示されます。接続を確立すると、ログイン名とパスワードの入力を求める画面が表示されます。

  5. ノードにログインします。 

    Console login: root
 Password: <root-password>

  6. stty(1) コマンドを使用して、端末の行と列の値を 手順 2 で確認した値に再設定します。 

    # stty rows 35
# stty cols 80

  7. TERM 環境変数を、手順 1で使用したウィンドウの種類に基づいて、適切な値に設定します。

    たとえば、xterm ウィンドウを使用している場合、次のように入力します。

    　

    # TERM=xterm; export TERM (sh または ksh の場合)
または
# setenv TERM xterm (csh の場合)

端末集配信装置の接続のリセット

この節では、端末集配信装置の接続をリセットする方法について説明します。

端末集配信装置上の Sun Cluster ノードコンソールポートに別のユーザーが接続している場合、ポートをリセットしてそのユーザーとの接続を切断できます。この作業は、すぐに管理作業を行う必要がある場合に便利です。

端末集配信装置に接続できない場合は、次のメッセージが表示されます。 

# telnet terminal-concentrator-name 5002
 Trying 192.9.200.1 ...
 telnet: Unable to connect to remote host: Connection refused
 #

ポートセレクタを使用している場合は、ポートがビジー状態であることを示すメッセージが表示される場合があります。

端末集配信装置の接続をリセットするには

  1. 接続を確立した後に Return キーを 1 回余分に押し、端末集配信装置に接続するためのコマンド行インタフェース (cli) を選択します。

    annex: プロンプトが表示されます。 

    # telnet terminal-concentrator-name
 ...
 Enter Annex port name or number: cli
 ...
 annex:

  2. su コマンドとパスワードを入力します。

    デフォルトのパスワードは、端末集配信装置の IP アドレスです。 

    annex: su
 Password:

  3. どのポートをリセットするか決定します。

    この例のポートはポート 2 です。接続を表示するには、端末集配信装置の組み込みコマンド who を使用してください。

    annex# who
 Port			What			User			Location					When			Idle			Address
 2			PSVR			---			---					---			1:27			192.9.75.12
 v1			CLI			---			---					---						192.9.76.10

  4. ポートをリセットします。

    端末集配信装置の組み込みコマンド reset を使用して、ポートをリセットします。この例は、ポート 2 の接続を切断します。 

    annex# admin reset 2

  5. 端末集配信装置から切断します。 

    annex# hangup

  6. ポートに再接続します。

    # telnet terminal-concentrator-name 5002

Sun Cluster サーバーにおける OpenBoot PROM の入力

この節では、端末集配信装置から OpenBoot PROM を入力する方法を説明しています。

OpenBoot PROM を入力するには

  1. ポートに接続します。

    # telnet terminal-concentrator-name 5002
 Trying 192.9.200.1 ...
 Connected to 129.9.200.1 .
 Escape character is '^]'.

  2. 必要に応じて、scadmin stopnode コマンドを使用してクラスタソフトウェアを停止し、続いてシステムを停止します。

    システムは、halt(1M) コマンドを使用して停止してください。

    # halt

    halt(1M) コマンドでシステムを停止できない場合は、telnet(1) コマンドモードを使用してください。デフォルトの telnet(1) エスケープ文字は、Control-] です。

  3. ノードにブレークを送信します。 

    telnet> send brk

  4. OpenBoot PROM コマンドを実行します。

端末集配信装置の障害追跡

この節では、端末集配信装置に関連する障害追跡方法について説明します。

ポート構成のアクセスエラー

telnet(1) を使用して端末集配信装置にアクセスしようとした時に、connect: Connection refused というメッセージが表示された場合は、以下の原因が考えられます。

ポート構成のアクセスエラーを修正するには

  1. 端末集配信装置に対してポートを指定せずに telnet を実行し、続いて対話形式でポートを指定します。 

    # telnet terminal-concentrator-name
 Trying ip_address ..
 Connected to 192.9.200.1
 Escape character is '^]'.
 [you may have to enter a RETURN to see the following prompts]
 
 Rotaries Defined:
       cli                              -
 
 Enter Annex port name or number: 2

    次のメッセージが表示される場合、ポートは使用中です。

    Port(s) busy, do you wish to wait? (y/n) [y]:

    次のメッセージが表示される場合、ポートの構成が正しくありません。

    Port 2
 Error: Permission denied.

    ポートが使用中の場合、「端末集配信装置の接続のリセット」で説明されている作業方法に従って端末集配信装置の接続をリセットしてください。ポートが不正に構成されている場合は、次の作業を行なってください。

    1. コマンド行インタプリタ (cli) を選択し、端末集配信装置のスーパーユーザーになります。

      Enter Annex port name or number: cli
 
 Annex Command Line Interpreter   *   Copyright 1991 Xylogics, Inc.
 
 annex: su
Password:

    2. 端末集配信装置のスーパーユーザーとして、ポートモードをリセットします。 

      annex# admin
 Annex administration MICRO-XL-UX R7.0.1, 8 ports
 admin: port 2
admin: set port mode slave
	You may need to reset the appropriate port, Annex subsystem or
 	reboot the Annex for changes to take effect.
 admin: reset 2
 admin:

      以上の操作で、ポートは正しく構成されます。

      端末集配信装置の管理コマンドの詳細は、『Sun Terminal Concentrator General Reference Guide』を参照してください。

端末集配信装置の接続に対する断続的な割り込み

ルーターを介して行われる端末集配信装置の接続は、断続的な割り込みを受ける場合があります。そのため、断続的に接続が行われたり、接続が停止したりします。接続が停止している場合、新しい端末集配信装置の接続を試みるとタイムアウトします。端末集配信装置は、再起動の兆候は示しません。その後、必要な経路が再確立されても、結果的に消滅するだけです。この問題の原因は、端末集配信装置のルーティングテーブルのオーバーフローとネットワーク接続の失敗です。

このことは、端末集配信装置と同じネットワーク上に存在するホストから確立された接続には問題となりません。

この問題を解決するには、端末集配信装置内にデフォルトの経路を確立し、routed 機能を無効にします。デフォルト経路の消滅を防ぐには、routed 機能を無効にする必要があります。次の作業は、この方法を示しています。詳細は、端末集配信装置のマニュアルを参照してください。

端末集配信装置の EEPROM ファイルシステム内に、config.annex ファイルが作成されています。このファイルを使用して、デフォルトの経路が使用されるように定義します。このファイルを使用すると、ポート番号の代わりに使用することができる記号名を定義することもできます。routed 機能を無効にするには、端末集配信装置の set コマンドを使用してください。

デフォルトの経路を確立するには

  1. 端末集配信装置に対して、shelltool(1) 接続を開きます。

    # telnet terminal-concentrator-name
Trying 192.9.200.2 ...
 Connected to xx-tc.
 Escape character is '^]'.
 
 
 Rotaries Defined:
     cli                              -
 
 Enter Annex port name or number: cli
 
 
 Annex Command Line Interpreter   *   Copyright 1991 Xylogics, Inc.

  2. su コマンドと管理パスワードを入力します。

    デフォルトのパスワードは、端末集配信装置の IP アドレスです。

    annex: su
 Password: administrative-password

  3. config.annex ファイルを編集します。

    annex# edit config.annex

  4. IP アドレスは、実際に使用するデフォルトルーターのものに置き換えてください。 

    Ctrl-W:save and exit Ctrl-X: exit Ctrl-F:page down Ctrl-B:page up
 %gateway  net default gateway 192.9.200.2 metric 1 active ^W

  5. ローカル routed を無効にします。

    annex# admin set annex routed n
   You may need to reset the appropriate port, Annex subsystem or
    reboot the Annex for changes to take effect.
 annex#

  6. 端末集配信装置を再起動します。

    annex# boot

    端末集配信装置の再起動には数分かかります。この間、Sun Cluster ノードコンソールにはアクセスできません。

TC/SSP 情報の変更

Sun Cluster 2.2 では、インストール時に端末集配信装置 (TC) またはシステムサービスプロセッサ (Sun Enterprise 10000 のみ) についての情報を必要とします。この情報は、クラスタ構成ファイルに格納されています。

この情報は次の目的で使用されます。

この 2 つの機構は、直接接続された記憶装置を使用した 4 ノード構成のクラスタにおけるデータの完全性を守る役割を果たします。

注 -

Solstice DiskSuite を使用している場合、tcmon と quorum は無効になっており、TC 情報は不要です。

scconf(1M) コマンドを使用すると、クラスタハードウェア構成の TC または SSP 情報が変更される場合などに、クラスタ構成ファイルの情報を変更できます。

TC または SSP 情報の変更の詳細は、表 8-1と scconf(1M) のマニュアルページを参照してください。

注 -

これらのコマンドは、すべてのクラスタノードで実行する必要があります。

表 8-1 作業一覧

目的 

実行するコマンド 

TC の IP アドレスまたは名前を置換する 

scconf(1m) -t -i new-IP-address old-IP-address|TC-name

新しいパスワードを指定する 

scconf(1m) -t -P old-IP-address|TC-name

クラスタ全体のロック機構に使用されるポート番号を変更する (TC のみ) 

scconf(1m) -t -l new-port old-IP-address|TC-name

ホスト情報を変更するには

特定のホストに対応する情報を変更するには、scconf -H コマンドを使用します。たとえば、あるホストのアーキテクチャタイプを変更して、その SSP (または TC) に新しい IP アドレスを指定するには、すべてのクラスタノードで次のコマンドを実行します。このコマンドの -d には、そのホストに対応する新しいアーキテクチャ (この例では Sun Enterprise 10000) を指定します。-t には、そのホストに接続された SSP (または TC) の新しい IP アドレスまたはホスト名 (この例では foo-ssp) を指定します。

# scconf clustername -H foo -d E10000 -t foo-ssp

SSP または TC のポート番号を指定するには

SSP (または TC) のホストのコンソールにポート番号を指定するには、すべてのクラスタノードで scconf -p コマンドを実行します。

# scconf clustername -H hostname -p port-number

次に例を示します。

# scconf clustername -H foo -p 10
注 -

複数のホストを同じ TC に接続できます。-H オプションは、特定のホストに対応する情報にだけ影響します。

TC の構成を変更するには

システム内の特定の TC の構成を変更するには、すべてのクラスタノードで scconf -t コマンドを実行します。たとえば、TC の IP アドレスを変更するには、次のコマンドを使用します。このコマンドの -i には、指定する端末集配信装置 (または SSP) の IP アドレス (この例では 129.34.123.52) を指定します。-l には、障害防御でロックのために使用する新しいポート (この例では 8) を指定します。

# scconf clustername -t foo-tc -i 129.34.123.52 -l -8

端末集配信装置が使用中の場合は、2 〜 n の範囲の未使用の TC ポートを指定します (n は TC 内のポートの数)。SSP が使用中の場合、値 -1 を指定する必要があります。

SSP または TC に新しいパスワードを指定するには

SSP (または TC) に新しいパスワードを指定するには、すべてのクラスタノードで scconf -P コマンドを実行します。

# scconf clustername -t foo-ssp -P
 foo-ssp(129.34.123.51) Password:*****
注 -

SSP または TC でユーザーパスワードを変更する場合は、各クラスタノードからこの作業を実行して、 Sun Cluster ソフトウェアにも変更を知らせる必要があります。この通知を行わないと、SSP または TC から「ブレーク送信」を行うことにより障害のあるノードを強制的に停止する必要がある場合に、障害防御が適切に動作しない場合があります。

dual-string メディエータの使用

この章では、Solstice DiskSuite の dual-string メディエータについて説明します。この機能によって、Sun Cluster は 2 つのディスク string だけを使用して高可用性データサービスを実行できます。Solstice DiskSuite の機能と概念の詳細は、Solstice DiskSuite のマニュアルを参照してください。

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

メディエータの概要

Sun Cluster では、dual-string (2 つのディスク string だけを使用した構成) はユーザーが介入をすることなく、単一のノードやドライブの単一の string に起きる障害を回避する必要があります。

dual-string 構成では、メタデバイス状態データベースの複製は、複製のちょうど半分が 1 つの string に、残りの半分が 2 つめの string に存在するように置かれます。現行データの大部分を提示するためには、複製の定足数 (半分 + 1 以上) が必要です。dual-string 構成では、1 つの string が使用できなくなると、複製の定足数を使用できません。

メディエータは、メディエータデータを格納するホスト (ノード) です。メディエータデータは、ほかのメディエータの位置情報を提供します。メディエータには、複製データベースに格納されているコミット回数と同じコミット回数が格納されています。このコミット回数は、メディエータデータが複製データベース内のデータと同期がとれていることを確認するために使用されます。メディエータデータは、使用前に個々に検証されます。

Solstice DiskSuite は、オペレーション状況が「安全」な時点を判定するために、複製定足数 (半分 + 1) を必要とします。これにより、データの正当性が保証されます。dual-string 構成では、アクセス可能な string が 1 つだけという場合があります。このような状況では、複製定足数を得ることは不可能です。メディエータが使用されていてメディエータ定足数が存在する場合は、メディエータデータを使用して、アクセス可能な string 上のデータが最新のものであり、安全に使用できるかどうかを確認できます。

Sun Cluster ソフトウェアにメディエータを導入すると、dual-string 構成で単一の string に障害が発生した場合にほとんどの現行データを提示できます。

ゴールデンメディエータ

一部の dual-string 障害において不要なユーザー介入を防ぐために、ゴールデンメディエータという概念が実装されました。複製データベースのちょうど半分がアクセス可能なときにメディエータホストの更新が必要なイベントが発生すると、2 つのメディエータの更新が試みられます。最初の更新は、コミット回数の変更を試み、メディエータを「非ゴールデン」に設定します。2 つめの更新は、最初の段階ですべてのメディエータホストが正常なことが確認され、かつアクセス可能な複製 (これらはコミット回数が増えている) の数が複製の合計数のちょうど半分であった場合だけ発生します。すべての条件が満たされると、2 つめの更新によってメディエータの状態が「ゴールデン」に設定されます。これにより、ユーザーの介入なしで、ゴールデン状態のホストに対するテイクオーバーが進行します。状態がゴールデンではない場合、データは読み取り専用に設定されます。テイクオーバーやフェイルオーバーを正常に行うためにはユーザーの介入が必要です。ユーザーがテイクオーバーやフェイルオーバーを開始するには、複製のちょうど半分がアクセス可能でなければなりません。

ゴールデン状態は、揮発性メモリー (RAM) にだけ格納されます。いったんテークオーバーが発生すると、メディエータデータは再更新されます。メディエータホストのどれかが更新不可能な場合、ゴールデン状態が取り消されます。状態は RAM だけに格納されるため、メディエータホストを再起動するとゴールデン状態が取り消されます。メディエータのデフォルト状態はゴールデンではありません。

メディエータの構成

図 9-1 は、2 つの Sun Cluster ノードに 2 つの string とメディエータが構成された Sun Cluster システムを示しています。

ノードの数に関係なく、クラスタ内には 2 つのメディエータホストしか存在しません。このクラスタ内でメディエータを使用しているディスクセットはすべて、メディエータホストが同じです。これは、メディエータホストが、このディスクセットをマスターできるサーバーセットのメンバーでない場合も同様です。

図を簡潔にするため、この構成では 1 つのディスクセットと対称構成しか示していません。ディスクセットの数は、この場合は重要ではありません。安定状態では、ディスクセットは phys-hahost1 によってマスターされます。

図 9-1 メディエータを使用した安定状態の Sun Cluster システム

Graphic

通常、複製データベースの半分 + 1 がアクセス可能な場合、メディエータは使用されません。複製のちょうど半分がアクセス可能な場合は、メディエータのコミット回数を使用して、アクセス可能な半分が最新状態であるかどうかを確認できます。正しいメディエータコミット回数が使用されるようにするには、両方のメディエータをアクセス可能にするか、メディエータの 1 つをゴールデンに設定する必要があります。メディエータ定足数は、メディエータの半分 + 1 です。メディエータ定足数は、複製の定足数には関係ありません。

メディエータが示す障害

メディエータを使用すると、単一障害および一部の二重障害からの回復が行えます。Sun Cluster で保証されているのは単一障害からの自動回復だけであるため、この節では単一障害からの回復についてだけ詳細を述べます。二重障害については、一般的な回復処理だけを示します。

図 9-1 は、安定状態の dual-string 構成を示しています。メディエータは、両方の Sun Cluster ノードで確立されています。そのため、メディエータ定足数が存在し、メディエータが使用されるようにするには、両方のノードを動作させる必要があります。1 つの Sun Cluster ノードで障害が発生した場合、複製定足数は存在します。ディスクセットのテイクオーバーが必要な場合、メディエータを使用せずにテークオーバーは発生します。

以下の各節では、メディエータを使用して障害を回復する方法を説明します。

単一のサーバーの障害

図 9-2 は、1 つの Sun Cluster ノードに障害が発生した状況を示しています。この場合は、複製定足数が使用できるため、メディエータソフトウェアは使用されません。Sun Cluster ノード phys-hahost2 は、以前に phys-hahost1 によってマスターされていたディスクセットをテイクオーバーします。

回復処理は、Sun Cluster ノードに障害が発生して 3 つ以上のディスク string が存在する場合に行う処理と同じです。通常、phys-hahost1 がクラスタに再度加わった後で、スイッチオーバーを行います。これ以外の管理作業を行う必要はありません。スイッチオーバーの手順については、haswitch(1M) のマニュアルページを参照してください。

図 9-2 メディエータ構成における単一の Sun Cluster サーバーの障害

Graphic

単一の string の障害

図 9-3 は、図 9-1 に示した安定状態から単一の string に障害が発生した場合を示しています。String 1 に障害が発生すると、phys-hahost1 と phys-hahost2 双方のメディエータホストはそのイベントを反映するように更新され、システムは次に示すように継続して動作します。

コミット回数が増やされ、メディエータはゴールデンのまま留まります。

図 9-3 メディエータ構成における単一の string の障害

Graphic

この場合に必要な管理作業は、3 つ以上の string 構成で単一の string に障害が発生する場合に必要な処理と同じです。これらの作業の詳細は、使用しているディスク拡張装置のマニュアルを参照してください。

ホストと string の障害

図 9-4 は、String 1 と phys-hahost2 に障害が発生した二重障害を示しています。string にまず障害が発生し、その後ホストに障害が発生した場合、phys-hahost1 上のメディエータはゴールデンである可能性があります。この場合の状況を次に示します。

図 9-4 多重障害 - 1 つのサーバーと 1 つの string

Graphic

このような障害は、Sun Cluster によって自動的に回復します。ディスクセットのマスターは、phys-hahost2 によってマスターされていた場合、phys-hahost1 にテークオーバーされます。phys-hahost1 によってマスターされていた場合は、phys-hahost1 がそのままマスターを続けます。String 1 の修復が終わった時点で、String 1 のデータは String 2 のデータと同期をとり直す必要があります。同期をとり直す方法については、『Solstice DiskSuite ユーザーズガイド』と metareplace(1M) のマニュアルページを参照してください。

注意 - 注意 -

この状況では回復が可能ですが、3 つめの障害が発生するとクラスタが使用できなくなるため、障害が発生したコンポーネントは速やかに復元してください。

phys-hahost1 のメディエータがゴールデンではない場合、このケースは Sun Cluster によって自動回復されず、管理者の介入を必要とします。この場合、Sun Cluster はエラーメッセージを生成し、論理ホストは保守モード (読み取り専用) に置かれます。このような多重障害が発生した場合は、ご購入先にお問い合わせください。

メディエータの管理

メディエータの管理は、medstat(1M) と metaset(1M) コマンドを使用して行います。これらのコマンドを使用すると、メディエータホストの追加と削除、メディエータデータの確認と修復などが行えます。詳細は、medstat(1M)、metaset(1M)、mediator(7) の各マニュアルページを参照してください。

メディエータホストを追加するには

この作業は、Solstice DiskSuite のインストールと構成が終わった後で行なってください。

  1. すべてのノードでクラスタソフトウェアを起動します。

    最初のノードで次のコマンドを実行してください。

    # scadmin startcluster

    残ったほかのノードで次のコマンドを実行してください。

    # scadmin startnode

  2. 各ノードのプライベートリンクの名前を確認します。

    grep(1) を使用して、clustername.cdb ファイルに含まれているプライベートリンクを確認してください。 

    host1# grep "^cluster.node.0.hostname" ¥
 /etc/opt/SUNWcluster/conf/clustername.cdb
cluster.node.0.hostname : host0
 host1# grep "cluster.node.0.hahost" ¥
 /etc/opt/SUNWcluster/conf/clustername.cdb | grep 204
 204.152.65.33
 
 host1# grep "^cluster.node.1.hostname" ¥
 /etc/opt/SUNWcluster/conf/clustername.cdb
 cluster.node.1.hostname : host1
 host1# grep "cluster.node.1.hahost" ¥
 /etc/opt/SUNWcluster/conf/clustername.cdb | grep 204
204.152.65.34

    この例では、204.152.65.33 が host0 のプライベートリンクで、204.152.65.34 が host1 のプライベートリンクです。

  3. metaset(1M) コマンドを使用して、メディエータを構成します。

    ディスクセットに接続された各ホストを、そのディスクセットトのメディエータとして追加します。各コマンドは、現在ディスクセットをマスターしているホストで実行してください。ディスクセットの現在のマスターは、hastat(1M) コマンドで確認できます。論理ホストについて hastat(1M) が返す情報に、ディスクセットマスターが示されています。

    host1# metaset -s disksetA -a -m host0,204.152.65.33
host1# metaset -s disksetA -a -m host1,204.152.65.34
host1# metaset -s disksetB -a -m host0,204.152.65.33
host1# metaset -s disksetB -a -m host1,204.152.65.34
host1# metaset -s disksetC -a -m host0,204.152.65.33
host1# metaset -s disksetC -a -m host1,204.152.65.34

    metaset(1M) コマンドは、プライベートリンクを別名として扱います。

メディエータデータの状態を確認するには

medstat(1M) コマンドを実行します。 

phys-hahost1# medstat -s diskset

出力の解釈については、medstat(1M) のマニュアルページを参照してください。指定したディスクセットのメディエータホストのメディエータデータが不正であることが表示された場合は、次の方法を参照して問題を修正してください。

不正なメディエータデータを修正するには

注 -

medstat(1M) コマンドは、メディエータの状態を確認します。この作業は、medstat(1M) を実行し、メディエータホストに問題があることが報告された場合に行なってください。

  1. 影響を受けるディスクセットから問題のあるメディエータホストを削除します。

    影響を受けるディスクセットを所有している Sun Cluster ノードにログインし、次のコマンドを入力してください。 

    phys-hahost1# metaset -s diskset -d -m bad_mediator_host

  2. メディエータホストとその別名を復元します。


    phys-hahost1# metaset -s diskset -a -m bad_mediator_host, physical_host_alias,...
    注 -

    プライベートリンクは、メディエータホストの別名として割り当てる必要があります。metaset(1M) コマンド行に、まず実際のホストの IP アドレスを指定し、続いて HA プライベートリンクを指定してください。この場合の metaset(1M) コマンドの使用法については、mediator(7) のマニュアルページを参照してください。

自動回復しない障害の処理

二重障害の中には、Sun Cluster によって自動回復しない場合もあります。次に例を示します。

ディスクセット、複製、メディエータの状態を定期的に監視することは非常に重要です。これらの監視には、medstat(1M) コマンドが便利です。多重障害を悪化させる危険性を避けるために、問題のあるメディエータデータ、複製、ディスクは常に速やかに修復してください。

この種の障害が発生した場合、次のようなエラーメッセージの 1 つがログに記録されます。 

ERROR: metaset -s <diskset> -f -t exited with code 66
ERROR: Stale database for diskset <diskset>
NOTICE: Diskset <diskset> released
 
ERROR: metaset -s <diskset> -f -t exited with code 2
ERROR: Tagged data encountered for diskset <diskset>
NOTICE: Diskset <diskset> released
 
ERROR: metaset -s <diskset> -f -t exited with code 3
ERROR: Only 50% replicas and 50% mediator hosts available for 
diskset <diskset>
NOTICE: Diskset <diskset> released

最終的に、次のメッセージも表示されます。 

ERROR: Could not take ownership of logical host(s) <lhost>, so 
switching into maintenance mode
ERROR: Once in maintenance mode, a logical host stays in 
maintenance mode until the admin intervenes manually
ERROR: The admin must investigate/repair the problem and if 
appropriate use haswitch command to move the logical host(s) out of 
maintenance mode

この種の二重障害では、データの完全性維持を優先するため、高可用性は犠牲になります。そのため、データがしばらく使用できなくなる可能性があります。また、完全なデータ回復やデータの整合性は保証されません。

ログメッセージを調べ、問題を見極め、障害が発生したハードウェアをできるかぎり修復した後、mediator(7) のマニュアルページに説明されている特殊な metaset(1M) オプションのいくつかを使用して、データアクセスを復元できる場合があります。しかし、これらのオプションの使用は、不正なデータの回復を避けるために、細心の注意を払う必要があります。

注意 - 注意 -

2 つの string 間の相互アクセスは、絶対に行わないでください。このようなアクセスが試みられると、状況は悪化します。

データのクライアントアクセスを復元する前に、データセット全体、またはそのデータセットに対する最近のトランザクションによって影響を受けているデータに対して任意の妥当性検査を行なってください。

論理ホストを保守モードから戻す haswitch(1M) コマンドを実行する前に、必ず関連するディスクセットの所有権を解放してください。

メディエータに関連するエラーログメッセージ

次の syslog (コンソール) メッセージは、メディエータまたはメディエータデータに問題があることを示しています。この問題を解決するには、「不正なメディエータデータを修正するには」の手順に従ってください。 

Attention required - medstat shows bad mediator data on host %s 
for diskset %s
 
Attention required - medstat finds a fatal error in probing 
mediator data on host %s for diskset %s!
 
Attention required - medstat failed for diskset %s