test

Sun Cluster 2.2 のシステム管理

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 ログインが可能になります。