test

Sun Enterprise 10000 DR 構成マニュアル

第 1 章 DR の構成

この章では、DR の主な機能を説明し、DR を構成する作業について解説します。以下のトピックを取り上げています。

注 -

このマニュアルでは、「DR 切り離し操作」とは、システムボードの「Complete Detach (切り離し完了)操作」または「削除」を意味します。Hostview、dr シェル、または ADR コマンドを使用すると、この切り離し操作を行うことができます。DR モデル 2.0 または 3.0 ドメインからのボードの切り離し手順については、『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』を参照してください。

DR モデル

Solaris 8 10/01 オペレーティング環境のリリースから、Sun Enterprise 10000 のドメインに対して、2 種類の DR モデルがサポートされるようになりました。両モデルをそれぞれ、DR モデル 2.0 および DR モデル 3.0 と呼びますが、このモデルを使用することにより、ドメインのダウン時間を最小限に抑えながら、システムボードを Solaris オペレーティング環境に論理的に接続したり、オペレーティング環境から論理的に切り離すことができます。

ホットスワップとはシステムボードを物理的に取り付けたり、取り外す処理を指しますが、DR はこのホットスワップと連携して使用します。DR を使用して以下のことが行えます。

ドメイン上で同時に複数の DR モデルを稼動させることはできません。DR モデル 2.0 と 3.0 の相違点を次の節で説明します。

DR モデル 2.0

DR モデル 2.0 は、Sun Enterprise 10000 のドメイン上にデフォルトで設定される DR モデルとなります。このモデルは、dr_daemon(1M) を使用してドメイン上で行われる DR 操作を制御します。以下の機能やツールを System Service Processor (SSP) 上で使用して DR 操作を行うことができます。

Hostview の使い方についての詳細は、『Sun Enterprise 10000 SSP 3.5 ユーザーマニュアル』および『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』を参照してください。dr シェルおよび ADR コマンドの使い方については、『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』を参照してください。

Solaris 8、7、2.6、および 2.5.1 オペレーティング環境のすべてのリリースで、デフォルトとして設定される DR モデルは DR モデル 2.0 となります。

代替パスソフトウェアをドメイン上に導入する場合、またはすでに使用している場合、DR モデル 2.0 のドメインには、Sun Enterprise サーバーの Alternate Pathing ソフトウェアが必要です。Solaris 8 オペレーティング環境をドメイン上で実行している場合は、AP 2.3.1 を使用してください。

DR モデル 2.0 と代替パスとの相互処理については、DR モデル 2.0 と AP との相互処理を参照してください。代替パスについての詳細は、『Sun Enterprise サーバー Alternate Pathing ユーザーマニュアル』を参照してください。

DR モデル 3.0

DR モデル 3.0 は、このリリースの Solaris 8 10/01 オペレーティング環境で初めて導入された DR モデルです。DR モデル 3.0 は、ドメイン構成サーバーである dcs(1M)を使用して、Sun Enterprise 10000 ドメインで行われる DR 操作を制御します。DR 操作を行う場合は、ADR コマンドの addboard(1M)、moveboard(1M)、および deleteboard(1M) を使用し、デバイスおよびボードの状態情報を表示する場合は、showdevices(1M) と rcfgadm(1M) コマンドを使用します。これらのコマンドは SSP 上で実行してください。DR モデル 3.0 の実行についての詳細は、『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』を参照してください。

DR モデル 3.0 のドメインは Reconfiguration Coordination Manager (RCM) とも接続しますので、ドメイン上で実行されるデータベース、クラスタ、ボリューム管理ソフトウェアなどのアプリケーションと DR 操作を調整することができます。RCM についての詳細は、「Solaris 8 10/01 Update Collection - Japanese」の『Solaris 8 のシステム管理 (追補)』を参照してください。

DR モデル 3.0 は、Solaris 8 10/01 リリースの Solaris オペレーティング環境でのみ使用することができます。DR モデル 3.0 を実行するには、SSP 上で SSP 3.5 ソフトウェアも実行する必要があります。

DR モデル 3.0 ドメイン上にマルチパスソフトウェアを導入する場合、あるいはすでに実行している場合、IPMP (Solaris オペレーティング環境で提供される IP マルチパスソフトウェア) と Sun StorEdgeTM Traffic Manager (MPxIO とも呼びます) を使用してください。

マルチパスについての詳細は、「Solaris 8 10/01 Update Collection - Japanese」の『IP ネットワークマルチパスの管理』、および Sun Download Center (http://www.sun.com/download) より入手可能な『MPxIO Installation and Configuration Guide』を参照してください。MPxIO ソフトウェアとマニュアルの入手方法については、『SSP 3.5 インストールマニュアルおよびご使用の手引き』を参照してください。

注 -

MPxIO は、すべてのデバイスについて自動パス切り替えをサポートしているわけではありません。詳細については、『MPxIO Installation and Configuration Guide』を参照してください。サポートされていないデバイスで自動パス切り替えを行う場合は、Alternate Pathing ソフトウェアと DR モデル 2.0 を使用してください。

再構成の準備

DR 操作を実行する前に、以下の作業を行う必要があります。

デバイスに関する必要条件

DR では、DR 切り離し操作の対象となるボードに実装されているデバイスのドライバが、以下の条件を満たしていることが必要です。

注 -

Sun MicrosystemsTMからリリースされている一時停止に対して安全なドライバには、st、sd、isp、esp、fas、sbus、pci、pci-pci、qfe、hme (Sun FastEthernetTM)、nf (NPI-FDDI)、qe (Quad Ethernet)、le (Lance Ethernet)、SSA ドライバ (soc、pln、および ssd)、Sun StorEdge A5000 ドライバ (sf、socal、ses) があります。

ドメインへの十分なスワップ領域の割り当て

ドメインのスワップ領域は、スワップデバイスと swapfs (メモリー) から構成されます。ドメインには、ページング可能なメモリーをフラッシュできるだけの十分なスワップ領域が必要です。たとえば、2 GB のドメインから 1 GB のメモリーを切り離す場合、負荷に応じて、1 GB のスワップ領域が必要です。スワップ領域が不足している場合、DR 操作を完了することができません。

ドメインのスワップ領域は、別々のボードがホストとなっているコントローラに接続されているディスク上に、複数のパーティションとして構成する必要があります。この種の構成では、スワップパーティションを動的に追加・削除できるので、特定のスワップパーティションに重要性が偏らなくなります (詳細については、swap(1M) に関するマニュアルページを参照してください)。

注 -

メモリー (swapfs) やディスク上のスワップ領域を切り離す場合は、現在実行中のプログラムに対応できるだけの十分なメモリーまたはスワップ領域がドメイン内に残っている必要があります。

サードパーティ製デバイスドライバの適正確認

ほとんどのサードパーティ製ドライバ (サン以外のベンダーから購入するドライバ) は、Solaris の modunload(1M) 標準インタフェースをサポートしていません。切り離しに対して危険なデバイスドライバや、一時停止に対して危険なデバイスドライバについては、このインタフェースを使用して、ドライバの読み込みを解除しています。通常の操作中にドライバ機能を呼び出す状況は頻繁にありません。また、機能が足りなかったり、正しく働かない場合もあります。サンでは、サードパーティ製デバイスの適正確認や実装を行う段階で、そのデバイスに添付されているドライバの機能を実際にテストすることを推奨しています。

DR 構成作業の概要

この節では、DR モデル 2.0 または 3.0 のドメイン上で DR 操作を実行する前に行っておく必要がある構成作業について説明します。ただし、使用するシステムボードの種類、および実行する DR 操作の種類によっては、この節で説明しているすべての作業を行う必要はありません。

DR を構成した後、また、DR 構成を変更した後は、ドメインを必ず再起動してください。再起動させるドメインの数を最小限に抑えるには、まず、ユーザーの DR 環境に適用する構成作業の組み合わせを決め、各ドメインに該当する構成作業を実行してからドメインを再起動するようにします。

  1. DR 切り離し操作を行う場合は、カーネルケージを有効にするで説明している手順に従って、カーネルケージを使用可能にします。

  2. デバイスに対しては、以下の作業を行います。

  3. ドメイン上で実行する DR モデルを決めます。場合によっては、DR モデルを選択するで説明している手順に従って、DR モデルを切り替えます。

  4. マルチパスを使用する場合は、ドメインをマルチパス用に構成し、そのドメインに適したマルチパスソフトウェアを実行します。

    それぞれの DR モデルと互換性を持つマルチパスソフトウェアについては、DR モデル 2.0および DR モデル 3.0を参照してください。

  5. ドメインを再起動して、構成の変更を反映させます。

    注 -

    DR の構成になんらかの変更を加えた場合は、必ずドメインを再起動してください。再起動の回数を最小限に抑えるには、各種の構成作業を一度に行ってからドメインを再起動するようにしてください。

  6. 再起動が正常に行われたら、/var/adm/messages ファイルを開いて、DR 構成が確実に変更されたことを示すメッセージを見つけます。

    たとえば、カーネルケージを有効に変更し、DR モデルを 2.0 から 3.0 へ切り替えると、以下のようなメッセージが生成されます。


    NOTICE:DR Kernel Cage is Enabled
.
.
.
NOTICE:Next Generation DR Model (3.0) is enabled

カーネルケージを有効にする

ケージ化されたカーネルは、ページング不可能なメモリーを最小システムボード台数 (通常は 1 台) に制限します。デフォルトでは、カーネルケージは無効に設定されており、DR 切り離し操作は行えません。DR 切り離し操作を行う場合は、以下で説明している手順に従って、system(4) 変数 kernel_cage_enableを使用してカーネルケージを有効にする必要があります。

ただし、kernel_cage_enable 変数の設定に関わらず、DR 接続 (addboard) 操作はデフォルトで使用可能になっています。

注 -

Solaris 7 オペレーティング環境より前のリリースでは、dr-max-mem 変数を使用して DR を使用可能にしていました。この変数は、Solaris 7 および Solaris 8 オペレーティング環境では使用されなくなりました。

  1. テキストエディタを使用して、ドメインの /etc/system ファイルを開き、kernel_cage_enable 変数の値を 1 に変更します。


    set kernel_cage_enable=1

  2. すべての DR 構成作業が終了したら、必ず、ドメインを再起動して上記の構成を有効にします。

  3. /var/adm/messages ファイルを開いて、構成が変更されていることを確認します。

    messages ファイルの一部を下記に示します。この例は、カーネルケージが有効になっていることを示しています。


    NOTICE:DR Kernel Cage is Enabled

ネットワークドライバのドライバパラメタを保持する

ndd(1M) コマンドを使用して、ネットワークデバイスのドライバ構成パラメタを設定しても、DR 操作が終了するとこれらのパラメタは保持されません。

  1. ドライバの構成パラメタを保持するには、/etc/system ファイル、またはdriver.conf ファイルで、ドライバごとにパラメタを設定してください。

soc および pln ドライバのデバイス一時停止を使用可能にする

システムボードに soc および pln デバイスが搭載されている場合、以下の手順を行ってドライバを一時停止に対して安全にします。

  1. テキストエディタを使用して /etc/system ファイルを開き、以下の例に示すように、pln_enable_detach_suspend 変数と soc_enable_detach_suspend 変数の値を 1 に変更します。


    set pln:pln_enable_detach_suspend=1
set soc:soc_enable_detach_suspend=1

  2. すべての DR 構成作業が終了したら、必ず、ドメインを再起動して上記の構成を有効にします。

危険なドライバのリストを指定する

dr.conf ファイル (DR モデル 2.0 ドメインの場合)、および ngdr.conf ファイル (DR モデル 3.0 ドメインの場合) に「危険なドライバのリスト」を指定することにより、システム内に存在する一時停止に対して危険なデバイスに関する情報を Solaris オペレーティング環境に与えることができます。

DR は、オペレーティング環境の一時停止を行う際にこのリストを読み込み、ページング不可能なメモリーを搭載しているボードを切り離せるようにしています。危険なドライバのリストから、現在動作しているドライバを DR が見つけると、DR は操作を中止してエラーメッセージを返します。このメッセージには、現在動作している危険なドライバが特定されています。手動によりそのデバイスを一時停止させ、DR 操作が行えるようにします。

  1. テキストエディタを使用して下記のファイルを開き、例に示すように、一時停止に対して危険なデバイスドライバを指定します。

    • /platform/SUNW,Ultra-Enterprise-10000/kernel/drv/dr.conf

    • /platform/SUNW,Ultra-Enterprise-10000/kernel/drv/ngdr.conf 


    unsupported-io-drivers="ドライバ 1","ドライバ 2","ドライバ 3";

    ここで、ドライバは、一時停止に対して危険なデバイスドライバの名称を示します。

    注 -

    DR モデルを切り替えるかどうかに関わらず、危険なドライバをすべてdr.conf ファイルと ngdr.conf ファイルの両方にリストすることを推奨します。このようにしておくと、後から DR モデルを切り替えることになっても、両方の構成ファイルにすべての危険なドライバの参照が組み込まれていることになります。

  2. すべての DR 構成作業が終了したら、必ずドメインを再起動して上記の構成を有効にします。

サポートされていないテープデバイスを切り離しに対して安全にする

Solaris 8 オペレーティング環境の場合、サンが元々サポートしているテープデバイスは一時停止および切り離しに対して安全なデバイスです。サンがサポートしているドライブのリストについては、st(7D) に関するマニュアルページを参照してください。切り離そうとしているシステムボードにサンがサポートしているテープデバイスが搭載されている場合、デバイスを一時停止しなくても、そのボードを安全に切り離すことができます。

サンがサポートしていないテープデバイスでも使用することは可能ですが、以下の手順を行って、そのテープデバイスを切り離しに対して安全にする必要があります。

  1. /kernel/drv/st.conf ファイルを開き、ST_UNLOADABLE (0x0400) フラグをエントリに設定します。詳細については、st(7D) に関するマニュアルページを参照してください。

  2. すべての DR 構成作業が終了したら、必ず、ドメインを再起動して上記の構成を有効にします。

DR モデルを選択する

ドメインを DR モデル 2.0 から モデル 3.0 へ、または DR モデル 3.0 から モデル 2.0 へ変更するには、ngdr.conf ファイルの変更と、ドメインの再起動といった作業が必要です。

  1. 『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』の説明に従って、ngdr.conf ファイルを変更します。

    注 -

    ドメイン上で DR モデル 2.0 から モデル 3.0 へ切り替える場合、DR モデル 3.0 ドメインは Solaris 8 10/01 オペレーティング環境を実行する必要があることを念頭に置いてください。また、SSP も SSP 3.5 ソフトウェアを実行する必要があります。

DR 切り離し操作の準備

以下に説明している手順に従って、DR 切り離し操作に備えてボードを準備する必要があります。以下にリストする手順は順番に並んでいますが、その順番にこだわる必要はありません。また、以下の手順は、入出力デバイスまたはネットワーク関連以外のデバイスを搭載したボードに適用されます。さらに、DR モデル 2.0 のみに適用する手順もありますので、DR モデル 3.0 を実行する場合は、これらの手順をとばしてください。

  1. DR モデル 2.0 ドメインについて、ネットワーク関連以外のデバイスを搭載しているボードを切り離す場合は以下に注意してください。

    • Alternate Pathing ソフトウェア機能や Solstice DiskSuiteTM のミラー化機能により提供される冗長性を利用して、ボードに接続されている非ネットワークデバイスへアクセスする場合は、これらサブシステムを再構成して、他のシステムボード上のコントローラからデバイスまたはネットワークへアクセスできるようにします。

      Alternate Pathing ソフトウェアは、代替インタフェースが使用できる場合に、ディスクデバイスをそのインタフェースへ自動的に切り替えます。

    • Alternate Pathing または Solstice DiskSuite のデータベースをボード常駐パーティションから削除します。Alternate Pathing または Solstice DiskSuite のデータベースの保存ディレクトリは、ユーザーが明示的に選択するディレクトリであり、変更することもできます。

    • Sun Enterprise Volume ManagerTM または Veritas Volume Manager が使用している占有領域を削除します。

      デフォルトの設定では、Volume Manager は制御対象の各デバイス上の占有領域を使用します。したがって、こうしたデバイスを切り離すには、まず Volume Manager の制御からデバイスを解放する必要があります。

  2. ファイルシステムをマウント解除 (アンマウント) します。

    たとえば、Solstice DiskSuite のメタデバイスを使用している場合、ボード常駐パーティションを持っているメタデバイスのファイルシステムをマウント解除する必要があります (たとえば、umount /partit と入力します)。

    一時停止に対して危険なデバイスがファイルシステムを管理している場合は、切り離し操作を行う前にそのファイルシステムをマウント解除する必要があります。危険なデバイスがファイルシステムを管理している場合、このデバイスを手動により一時停止させるには、まず lockfs(1M) コマンドを使用してそのファイルシステムをロックしてから、手動で一時停止させます。

    注意 - 注意 -

    share(1M) ユーティリティーを使用して共有ファイルシステムをマウント解除すると、NFS クライアントシステムに影響を与えます。

  3. swap(1M) コマンドを使用して、スワップ構成からディスクパーティションを削除します。

  4. Sun StorEdge A3000 コントローラをホストしているボードを切り離す場合は、そのコントローラをアイドル状態にするか、rm6 または rdacutil プログラムを実行して、手動によりオフラインにします。

    Sun StorEdge A3000 (旧製品名は RSM Array 2000) は、デュアルコントローラパスを持ち、自動負荷分散および自動フェイルオーバー機能を搭載しています。

  5. 以下の操作を行って、非ネットワークデバイスをすべて閉じます。

    • デバイスまたは raw パーティションを直接開いている処理をすべて終了するか、または処理をリダイレクトしてボード上で開いているデバイスを閉じることにより、デバイスのインスタンスをすべて閉じます。

      DR モデル 2.0 を使用している場合は、Hostview のデバイス表示画面、または drshow(1M) コマンドによる入出力リスト表示を使用すれば、指定するデバイスを開いている処理の数を示すオープンカウント (open count) フィールドを表示させることができます。ドメインに対して fuser(1M) コマンドを使用すると、これらデバイスを開いている処理を調べることができます。

    • modunload(1M) を実行すると、切り離しに対して危険なドライバ、または読み込まれているデバイスドライバごとに、読み込みを解除できます。

    注 -

    危険なドライバを使用するデバイスの読み込みを解除できない場合は、危険なデバイスを搭載しているボードをブラックリストに登録し、ドメインを再起動してください。このようにすると、後からボードを削除できます。ブラックリストへの登録についての詳細は、blacklist(1M) に関するマニュアルページを参照してください。

  6. Solaris オペレーティング環境を一時停止する必要がある場合は、開いているリアルタイム処理をすべて終了するか、ボード上のプロセッサと結合している処理をすべてアンバインド (終了) します。

    ボードのプロセッサと結合している処理があると、ボードを切り離せなくなります。pbind(1M) を使用すれば、こうした処理を他のプロセッサへ再結合させることができます。

DR 操作中の構成変更

この節では、以下のトピックについて説明します。

システム休止に影響する強制休止可能状態の制御

ページング不可能なメモリーを搭載したボードの DR 切り離し操作中に、Solaris オペレーティング環境が休止できない場合、理由が画面に表示されます。

リアルタイム処理が実行中である、または一時停止に対して危険なデバイスが開いているために休止が失敗した場合は「強制休止可能状態」です。この場合の選択肢としては、操作を再試行するか、強制的に休止させる方法があります。プロセスが一時停止できない状態は、通常一時的なものです。休止に成功するまで操作を繰り返すことができます。

強制的に休止させるということは、強制休止可能状態 (リアルタイム処理が実行中、または一時停止に対して危険なデバイスが開いている状態) が継続しても、オペレーティング環境に対して休止を続行させる権利を与えることです。この操作を行うと、オペレーティング環境に対して強制的に切り離しを行うことになります。ただし、システム内で一時停止に対して危険なデバイスが開いていても、切り離し操作を強制的に続行することはできますが、切り離しに対して危険なデバイスがボードに搭載されていて、そのドライバが読み込まれているときに切り離し操作を強制的に行うことはできません。

リアルタイム処理が動作中である場合は、そのプロセスを一時停止することによって、プロセスが実行する機能に悪影響を与えないかどうかを判断します。影響がなければ、オペレーティング環境の休止を強制することができます。

ドメインを休止させる最も直接的な方法は、一時停止に対して危険なデバイスをすべて閉じることです。ネットワークドライバごとに、ifconfig(1M) コマンドに down パラメタを付けて実行し、再度、 unplumb パラメタを付けて実行してください (詳細については、ifconfig(1M) に関するマニュアルページを参照してください)。

注 -

ネットワークドライバをすべて unplumb することは可能です。ただし、この操作は正常な環境でテストされることは稀で、ドライバエラーを引き起こす可能性があります。DR を使用する場合、一時停止に対して危険なデバイスの適正確認や実装を行う段階で、こうしたドライバ機能を実際にテストすることを推奨しています。

一時停止に対して危険なデバイスが開いていて閉じることができない場合は、手動でそのデバイスを停止してから、オペレーティング環境に休止を強制することができます。オペレーティング環境が再開したら、以下で説明する手順に従って、手動でそのデバイスを再開します。

注 -

デバイスがドメインのセンタープレーンにアクセスするのを一時停止できない場合は、オペレーティング環境に休止を強制できません。強制すると、ドメインの障害やハングアップが生じることがあります。この場合は、一時停止に対して危険なデバイスが閉じた状態になるまで DR 操作を延期します。

一時停止に対して危険なデバイスを手動で停止する

  1. 以下の操作のいずれか、またはそれらを組み合わせることにより、デバイスの使用を解放します。

    1. デバイスを使用している処理を終了させて、デバイスを閉じます。

    2. すべてのユーザーに対して、そのデバイスを使用しないように通知します。

    3. そのデバイスに接続しているケーブルを外します。

      たとえば、非同期の任意入力を許可するデバイスが開いる場合は、オペレーティング環境を休止させる前にケーブルの接続を外すことによって、トラフィックがそのデバイスに到着してそのデバイスがドメインのセンタープレーンにアクセスするこを防止することができます。オペレーティング環境が再開してから、再度ケーブルを接続します。

    4. modunload(1M) コマンドを使用して、デバイスドライバの読み込みを解除します。

  2. DR 操作の再試行を行います。

  3. 以下の作業を行ってください。

    1. modload(1M) コマンドを使用して、デバイスドライバを読み込みます。

    2. デバイスへケーブルを再接続します。

    3. デバイスが再び使えるようになったことをユーザーに通知します。

    4. デバイスに関連する処理をすべて再起動します。

    注意 - 注意 -

    一時停止に対して危険なデバイスの処理を実行中に、休止操作を強制すると、ドメインがハングアップすることがあります。ドメインがハングアップしても、Sun Enterprise 10000 システム上で実行中の他のドメインには影響しません。

システムを強制的に休止する
注意 - 注意 -

force オプションを使用する場合は注意が必要です。オペレーティング環境の強制休止を正常に行うには、まず手動でコントローラを休止させる必要があります。休止手順が使える場合でも、デバイスごとに異なります。また、この操作の間は、デバイスがデータの転送、メモリーの参照、または割り込みの発生を行わないようにする必要があります。コントローラが開いているときに停止させる手順については、重要なユーザーシステムでその手順を実行する前に、必ずテストしてください。コントローラを正常に休止させられるかが不明のまま、force オプションを使用してオペレーティング環境を休止させると、ドメイン障害を発生させ、再起動を繰り返す事態になる可能性があります。

  1. DR モデル 2.0 の場合の操作では、以下のいずれかを行います。

    • 『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』で説明している Hostview の Force ボタンをクリックします。

    • dr(1M) シェルアプリケーションで、complete_detach(1M) コマンドに force オプションを付けて入力します。

    • deleteboard(1M) コマンド、または moveboard(1M) コマンドに -f オプションを付けて実行します。

  2. DR モデル 3.0 の場合の操作では、deleteboard(1M) コマンド、または moveboard(1M) コマンドに -f オプションを付けて実行します。

ターゲットメモリーに関する制約事項

ページング不可能なメモリーが付いているボードを切り離すとき、DR はページング不可能なメモリーコピー先となる、代替 （ターゲット) メモリーボードを指定します。

プロセッサ

起動プロセッサは、netcon BBSRAM バッファーを保持する役割があります。

起動プロセッサが常駐するボードを切り離す前に、DR によって起動プロセッサの役割を別のアクティブな （オンライン） プロセッサに割り当てる必要があります。

ネットワークデバイス

DR モデル 2.0 の切り離し操作では、切り離されているボード上のすべてのネットワークインタフェースの使用が自動的に終了されます。切り離し操作を完了すると、dr_daemon(1M) によって、切り離されたボード上の構成されたインタフェースがすべて識別され、次のようなifconfig(1M) コマンドが各インタフェース上に発行されます。


ifconfig インタフェース down
ifconfig インタフェース unplumb

さらに、FDDI インタフェースが切り離されている場合は、切り離し操作を実行する前に、DR によって FDDI ネットワーク監視デーモンが終了されます。FDDI ネットワーク監視デーモンは、切り離しが完了した後で DR によって再起動されます。nf デバイスの /usr/sbin/nf_snmd デーモンの起動や停止は、FDDI インタフェースを含むボードが接続されるときには行われないことに注意してください。

これらのコマンドは、次のいずれかの条件を満たすネットワークインタフェースを含むボード上では実行されません。これらの場合、切り離し操作は失敗し、エラーメッセージが表示されます。

DR 遠隔通信

DR モデル 2.0 ドメインでは、dr_daemon(1M) は、遠隔手続き呼び出し (RPC) を通して Hostview および dr(1M) シェルアプリケーション (両方とも SSP 上で実行されます) と通信します。DR モデル 3.0 ドメインでは、dcs(1M) (ドメイン構成サーバー) がドメインの DR 操作を制御します。

DR 操作中に接続障害が発生した場合は、ドメインで実行されている DR モデルに適した手順を行います。

DR モデル 2.0 操作中に発生した RPC タイムアウトまたは接続障害をトラブルシューティングする

  1. ドメインを調べます。

    このデーモンは、各ドメインの /etc/inetd.conf ファイル内に必ず設定しておきます。以下の行が ファイル内に必要です。


    300326/4 tli rpc/tcp wait root \
/platform/SUNW,Ultra-Enterprise-10000/lib/dr_daemon/ dr_daemon

  2. DR デーモンが /etc/inetd.confファイル内に設定されていて、dr_daemon(1M) が動作中の場合は、このデーモンを終了させます。次に、HUP 信号を inetd(1M) デーモンに送ります。これによって、inetd(1M) デーモンがinetd.conf(4) 構成ファイルを読み込み直します。


    # kill dr_daemon_pid
# kill -HUP inetd_pid

    ここで、dr_daemon_pid は dr(1M) デーモンのプロセス ID、また、inetd_pid は inetd(1M) デーモンのプロセス ID を示します。

  3. dr_daemon(1M) の起動で問題が発生する場合は、/var/adm/messages に、inetd(1M) 関連のエラーメッセージがないかを調べてください。

    DR デーモンの実行ファイルは、/platform/SUNW,Ultra-Enterprise-10000/lib ディレクトリにあります。

  4. この時点で DR 操作を再度、最初から試みてください。

DR モデル 3.0 操作中に発生した接続障害をトラブルシューティングする

  1. ドメインを調べます。

    dcs(1M) は、各ドメインの /etc/inetd.conf ファイル内に必ず設定しておきます。以下の行がファイル内に必要です。


    sun-dr stream tcp   wait root /usr/lib/dcs dcs
sun-dr stream tcp6  wait root /usr/lib/dcs dcs

  2. dcs デーモンが /etc/inetd.confファイル内に設定されていて、このデーモンが動作中の場合は、以下のように入力して dcs(1M) を終了します。次に、HUP 信号を inetd(1M) デーモンに送信して、inetd.conf(4) 構成ファイルを読み込み直します。


    # kill -9 dcs_pid
# kill -HUP inetd_pid

    ここで、dcs_pid は dcs(1M) デーモンの処理 ID、また、inetd_pid は inetd(1M) デーモンの処理 ID を示します。

  3. inetd(1M) デーモンが dcs(1M) デーモンを起動できない場合は、/var/adm/messages ファイルに、inetd(1M) デーモンからのエラーメッセージがないかどうかを調べてください。

    dcs(1M) デーモンの実行ファイルは、/usr/lib ディレクトリにあります。

  4. この時点で DR 操作を再度、最初から試みてください。

DR モデル 2.0 の構成に関する詳細

この節では、DR モデル 2.0 にのみ適用される構成について説明します。

DR モデル 2.0 操作後の再構成

システムボードの接続または切り離しを行ったら、DR モデル 2.0 ドメインを再構成する必要があります。DR モデル 2.0 では、DR 操作後でもドメインを再構成することができます。

注 -

DR モデル 2.0 ドメインで Solaris 8 オペレーティング環境を実行している場合は、この節で説明している手動再構成手順を行う必要はありません。新たに導入された DDI サブシステム (devfsadm) により、再構成作業がすべて自動的に完了します。詳細については、devfsadm(1M) のマニュアルページを参照してください。

ドメインの再構成が必要な場合

以下のことが発生した場合は、ドメインの再構成が必要です。

再構成シーケンスは、起動再構成シーケンス (boot -r) と同じです。


drvconfig; devlinks; disks; ports; tapes;

ボードを接続した後で、再構成シーケンスを実行すると、ドメインが認識していなかったデバイスのパス名が /etc/path_to_inst ファイルに書き込まれます。同じパス名が、/devices 階層にも追加され、それらへのリンクが /dev ディレクトリに作成されます。

ディスクデバイス

ディスクコントローラは、 disks(1M) プログラムが認識する順に連続番号が割り当てられます。ディスクのパーティションには、disks(1M) が割り当てたディスクコントローラ番号に従って、/dev 名が付けられます。たとえば、ディスクコントローラ 1 を使用してアクセス可能なディスクパーティションには、すべて/dev/dsk/cXtYdZsWという名前が付けられます。

この形式では、

X は、コントローラ番号です。

Y は、ターゲットディスク番号です（例外あり）。

Z は、論理ユニット番号です。

W は、パーティション番号です。

ボードを切り離した後で再構成シーケンスを実行すると、ボード上のすべてのディスクパーティションに対する /dev リンクが削除されます。残りのボードの番号は、そのままです。新たに装着したボードのディスクコントローラには、disks(1M) によって、次に使用可能な最小の番号が割り当てられます。.

注 -

ディスクコントローラ番号は、ディスクにアクセスするときに使用される /dev リンク名の一部です。再構成シーケンスでこの番号が変更されると、/dev リンク名も変更されます。この変更は、/dev リンク名を使用するファイルシステムテーブルやソフトウェア、たとえば Solstice DiskSuite に影響することがあります。/etc/vfstab ファイルを更新し、/dev リンク名を変更するためのその他の管理手順を行ってください。

DR モデル 2.0 と AP との相互処理

切り離すボードが、重要なシステム資源に接続されている入出力コントローラをホストしている場合、DR 切り離し操作は、代替パス (AP) 機能、または Solstice DiskSuite 機能と連携して動作します。たとえば、ボード上のコントローラがディスク上の root (/) または /usr パーティションに接続されている場合、そのディスクへのハードウェア代替パスが存在し、かつこれを利用するように AP が構成されているか、またはそのディスクがミラー化されていない限り、このボードを切り離すことはできません。代替パスまたはミラーは、ドメイン内の別のボードによりホストされている必要があります。同じことがネットワークコントローラにも当てはまります。SSP と Sun Enterprise 10000 プラットフォーム間を接続する Ethernet コントローラをホストしているボードは、このネットワーク接続を維持するため、別のボード上の Ethernet コントローラへの代替パスが存在しない限り、切り離すことはできません。

システムボードが接続または切り離されるか、あるいはドレイン状態になると、DR はそのことを AP サブシステムに通知します。加えて、DR は AP に対し、どのコントローラが AP のデータベースにあり、その状態がどうなっているか (有効か無効) を問い合わせます。このやり取りは、dr_daemon(1M) と ap_daemon(1M) 間で行われます。ap_daemon(1M) がない場合は、ドメインの syslog メッセージバッファーにエラーメッセージが書き込まれて、DR 操作がエラーなしで続行されます。

DR と ap_daemon との相互処理を無効にするには、dr_daemon(1M) の起動時に、-a オプションを使用します。『Sun Enterprise 10000 Dynamic Reconfiguration リファレンスマニュアル』のdr_daemon(1M) コマンドの説明を参照してください。

AP バージョン 2.1 を使用している場合は、DR の complete-detach 段階でオペレーティング環境が、切り離すボード上の有効なディスクコントローラを自動的にオフに切り換えます。しかし、AP バージョン 2.0 を使用している場合は、complete-detach を開始する前に、有効なディスクコントローラを手動で無効に切り換える必要があります。Solaris 8 オペレーティング環境をドメイン上で実行している場合は、AP バージョン 2.3.1 を使用してください。

DR と AP の相互処理についての詳細は、『Sun Enterprise サーバー Alternate Pathing 2.3.1 ユーザーマニュアル』を参照してください。AP および Solstice DiskSuite については、『RAS Companion』を参照してください。