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

ドライバエラーメッセージに、インスタンス名が報告される場合があります。インスタンス名は、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 つの SPARCstorage^TM 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 に変わります。

再構成再起動の実行

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

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

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

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

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