この節では、以下のトピックについて説明します。
DR 切り離し操作を行っている間に、システムの休止に影響する強制休止可能な状態を制御する方法
DR 切り離し操作中に DR が行う各種構成変更
ページング不可能なメモリーを搭載したボードの DR 切り離し操作中に、Solaris オペレーティング環境が休止できない場合、理由が画面に表示されます。
ドメイン内でリアルタイム処理が実行中である
オペレーティング環境が休止できないデバイス (つまり、一時停止に対して危険なデバイス) が開いている
リアルタイム処理が実行中である、または一時停止に対して危険なデバイスが開いているために休止が失敗した場合は「強制休止可能状態」です。この場合の選択肢としては、操作を再試行するか、強制的に休止させる方法があります。プロセスが一時停止できない状態は、通常一時的なものです。休止に成功するまで操作を繰り返すことができます。
強制的に休止させるということは、強制休止可能状態 (リアルタイム処理が実行中、または一時停止に対して危険なデバイスが開いている状態) が継続しても、オペレーティング環境に対して休止を続行させる権利を与えることです。この操作を行うと、オペレーティング環境に対して強制的に切り離しを行うことになります。ただし、システム内で一時停止に対して危険なデバイスが開いていても、切り離し操作を強制的に続行することはできますが、切り離しに対して危険なデバイスがボードに搭載されていて、そのドライバが読み込まれているときに切り離し操作を強制的に行うことはできません。
リアルタイム処理が動作中である場合は、そのプロセスを一時停止することによって、プロセスが実行する機能に悪影響を与えないかどうかを判断します。影響がなければ、オペレーティング環境の休止を強制することができます。
ドメインを休止させる最も直接的な方法は、一時停止に対して危険なデバイスをすべて閉じることです。ネットワークドライバごとに、ifconfig(1M) コマンドに down パラメタを付けて実行し、再度、 unplumb パラメタを付けて実行してください (詳細については、ifconfig(1M) に関するマニュアルページを参照してください)。
ネットワークドライバをすべて unplumb することは可能です。ただし、この操作は正常な環境でテストされることは稀で、ドライバエラーを引き起こす可能性があります。DR を使用する場合、一時停止に対して危険なデバイスの適正確認や実装を行う段階で、こうしたドライバ機能を実際にテストすることを推奨しています。
一時停止に対して危険なデバイスが開いていて閉じることができない場合は、手動でそのデバイスを停止してから、オペレーティング環境に休止を強制することができます。オペレーティング環境が再開したら、以下で説明する手順に従って、手動でそのデバイスを再開します。
デバイスがドメインのセンタープレーンにアクセスするのを一時停止できない場合は、オペレーティング環境に休止を強制できません。強制すると、ドメインの障害やハングアップが生じることがあります。この場合は、一時停止に対して危険なデバイスが閉じた状態になるまで DR 操作を延期します。
以下の操作のいずれか、またはそれらを組み合わせることにより、デバイスの使用を解放します。
DR 操作の再試行を行います。
以下の作業を行ってください。
modload(1M) コマンドを使用して、デバイスドライバを読み込みます。
デバイスへケーブルを再接続します。
デバイスが再び使えるようになったことをユーザーに通知します。
デバイスに関連する処理をすべて再起動します。
一時停止に対して危険なデバイスの処理を実行中に、休止操作を強制すると、ドメインがハングアップすることがあります。ドメインがハングアップしても、Sun Enterprise 10000 システム上で実行中の他のドメインには影響しません。
force オプションを使用する場合は注意が必要です。オペレーティング環境の強制休止を正常に行うには、まず手動でコントローラを休止させる必要があります。休止手順が使える場合でも、デバイスごとに異なります。また、この操作の間は、デバイスがデータの転送、メモリーの参照、または割り込みの発生を行わないようにする必要があります。コントローラが開いているときに停止させる手順については、重要なユーザーシステムでその手順を実行する前に、必ずテストしてください。コントローラを正常に休止させられるかが不明のまま、force オプションを使用してオペレーティング環境を休止させると、ドメイン障害を発生させ、再起動を繰り返す事態になる可能性があります。
DR モデル 2.0 の場合の操作では、以下のいずれかを行います。
『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』で説明している Hostview の Force ボタンをクリックします。
dr(1M) シェルアプリケーションで、complete_detach(1M) コマンドに force オプションを付けて入力します。
deleteboard(1M) コマンド、または moveboard(1M) コマンドに -f オプションを付けて実行します。
DR モデル 3.0 の場合の操作では、deleteboard(1M) コマンド、または moveboard(1M) コマンドに -f オプションを付けて実行します。
ページング不可能なメモリーが付いているボードを切り離すとき、DR はページング不可能なメモリーコピー先となる、代替 (ターゲット) メモリーボードを指定します。
DR モデル 2.0 では、ターゲットボードが見つからない場合は、切り離し操作が拒否され、DR はシステムコンソールに以下の警告メッセージを表示します。
WARNING: sfdr: sfdr_pre_release_mem: no available target for mem-unit (board.0) |
DR モデル 3.0 の場合、コピーおよび名称変更操作の対象となるターゲットボードが見つからないと、deleteboard(1M) および moveboard(1M) コマンドは以下のエラーメッセージを表示します。
deleteboard: unconfigure SB2: No available memory target: dr@0:SB2::memory |
moveboard: unconfigure SB2: No available memory target: dr@0:SB2::memory |
起動プロセッサは、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 インタフェースを含むボードが接続されるときには行われないことに注意してください。
これらのコマンドは、次のいずれかの条件を満たすネットワークインタフェースを含むボード上では実行されません。これらの場合、切り離し操作は失敗し、エラーメッセージが表示されます。
インタフェースが、ドメインの主ネットワークインタフェースである。すなわち、IP アドレスがファイル /etc/nodename に含まれるネットワークインタフェース名に対応する場合です。
この場合、ドメインの主ネットワークインタフェースを終了すると、ネットワーク情報ネームサービスが動作しなくなり、ftp(1)、rsh(1)、rcp(1)、rlogin(1) などのアプリケーションを使用した遠隔ホストへのネットワーク接続が不可能になります。NFS クライアントおよびサーバー間の動作も影響を受けます。
インタフェースがシステムの SSP ホストと同じサブネット上にある。すなわち、/etc/ssphostname にある SSP ホスト名に対応する IPアドレスのサブネット上にある場合です。
この場合、このインタフェースを終了すると、ホストと SSP が通信できなくなります。DR 操作は SSP 上で開始されるため、切り離しプロセスの制御が失わます。/etc/ssphostname ファイルにはホストを制御する SSP 名が含まれているため、SSP 名を変更した場合は、/etc/ssphostname ファイルを手動で更新する必要があります。
インタフェースが、AP メタデバイスが plumb されたときの、Alternate Pathing (AP) メタデバイスに対する有効な代替パスである。AP によって使用されるインタフェースは、ボードが切り離されたときの有効なパスであってはいけません。
AP 2.1 では切り替えが自動的に行われます。ただし、アクティブなパスを、切り離されているボード上にないインタフェースに手動で切り替えることができます。そのようなパスが存在しない場合は、AP インタフェース上で ifconfig down コマンドおよび ifconfig unplumb コマンドを手動で実行します。アクティブなパスを手動で切り替えるには、apconfig(1M) コマンドを使用します。
ネットワークインタフェースを切り離すと、NFS クライアントシステムが影響を受ける場合があります。
DR モデル 2.0 ドメインでは、dr_daemon(1M) は、遠隔手続き呼び出し (RPC) を通して Hostview および dr(1M) シェルアプリケーション (両方とも SSP 上で実行されます) と通信します。DR モデル 3.0 ドメインでは、dcs(1M) (ドメイン構成サーバー) がドメインの DR 操作を制御します。
DR 操作中に接続障害が発生した場合は、ドメインで実行されている DR モデルに適した手順を行います。
ドメインを調べます。
このデーモンは、各ドメインの /etc/inetd.conf ファイル内に必ず設定しておきます。以下の行が ファイル内に必要です。
300326/4 tli rpc/tcp wait root \ /platform/SUNW,Ultra-Enterprise-10000/lib/dr_daemon/ dr_daemon |
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 を示します。
dr_daemon(1M) の起動で問題が発生する場合は、/var/adm/messages に、inetd(1M) 関連のエラーメッセージがないかを調べてください。
DR デーモンの実行ファイルは、/platform/SUNW,Ultra-Enterprise-10000/lib ディレクトリにあります。
この時点で DR 操作を再度、最初から試みてください。
ドメインを調べます。
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 |
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 を示します。
inetd(1M) デーモンが dcs(1M) デーモンを起動できない場合は、/var/adm/messages ファイルに、inetd(1M) デーモンからのエラーメッセージがないかどうかを調べてください。
dcs(1M) デーモンの実行ファイルは、/usr/lib ディレクトリにあります。
この時点で DR 操作を再度、最初から試みてください。