OpenVMS マニュアル

A.7.2 マルチホスト SCSI 環境におけるエラー・レポートと OPCOM メッセージ

マルチホスト SCSI バスでホストのブートやシャット・ダウンなどの一般的な操作では， SCSI バスの他のホストにエラーが発生することがあります。また，シングル・ホスト SCSI 構成ではまれにしか発生しないエラーが，マルチホスト SCSI バスで発生する場合があります。

このようなエラーを一時的エラーと言い，OpenVMS がエラーを検出，レポートし，回復処理を行っても実行中のアプリケーションのデータが失われたり影響を受けることはありません。この項では，このようなエラーの発生要件，および，オペレータ・コンソールに表示されエラー・ログに入力されるメッセージについて説明します。

電源入力やリブートで SCSI バスに接続されたホストを最初に起動する際は， SCSI バスやその上のデバイスの状態はホストにはわかりません。ANSI SCSI 標準では， BUS RESET という方式でバスやその上のデバイスを既知の状態に強制的に設定する機能を定めています。ホストは，最初のスタートアップとシャットダウンのときに，各 SCSI バス上で通常は RESET シグナルを 1 回以上表明します。RESET を表明しているホストではこれが正常な動作ですが，RESET ではホストの強制終了と，実行中のすべての I/O 操作の再起動が必要になるため，他のホストにとって RESET シグナルはエラー扱いになります。

ホストが正常な処理の途中で，他の方法では修正できない問題を検出したときもホストはバスをリセットします。このようなリセットは，一般的ではありませんが，通常はバス上の何かが乱れたときに発生します。たとえば，SCSI デバイスがアクティブなときにホット・プラグしようとしたり ( 付録 A.7.6 項 参照)，Ctrl/P でホストのどれかを一時停止しようとすると，1 つ以上のホストがバス・リセットを発行しなければならない条件が揃います。

ホストが SCSI バス上のデバイスとデータを交換するときに，ホストがデバイスや SCSI アダプタの反応を待機しなければならないポイントが数個所にあります。 OpenVMS システムでは，待機中にホストを他の処理に振り向けることができますが，待機時間が長くなりすぎるのを防ぐため，タイマが起動します。SCSI デバイスやアダプタからの応答が来る前にタイマが時間切れになった場合，その状態をタイムアウトと呼びます。

タイムアウトには 3 種類あります。

• 切断タイムアウト (Disconnect timeout) --- デバイスがホストからコマンドを受信し，コマンドの処理時にバスとの接続を切断したが，バスを再接続できずトランザクションを終了できなかった。このエラーは，バスのビジーが続いて発生するのが一般的です。詳細については， 付録 A.7.5 項 を参照してください。切断タイムアウト時間はデバイスによって異なりますが，ほとんどのディスクでは約 20 秒に設定されています。

• 選択タイムアウト (Selection timeout) --- ホストから SCSI バス上のデバイスにコマンドを送信しようとしたが，デバイスが応答しない。デバイスが存在しないか，バスから取り外されているか，電源が入っていないというのがこのタイムアウトの原因のほとんどです。(このエラーは，マルチ・イニシエータ・システムではあまり発生しません。) 選択タイムアウト時間は約 0.25 秒です。

• 割り込みタイムアウト (Interrupt timeout) --- ホストからアダプタに他の何らかの理由による応答が要求されたが，応答がない。このエラーは，通常は SCSI バスのビジー状態を表します。このエラーの原因としては，イニシエータの番号を上位番号 (6 や 7) ではなく下位番号 (0 か 1) にした場合に多く見られます。割り込みタイムアウト時間は，約 4 秒です。

SCSI OpenVMS Cluster システムでは，タイムアウト・エラーは，避けられないわけではありません。しかし，トラフィックがヘビーな SCSI バスやイニシエータが 2 つある SCSI バスでは，さらに発生頻度が高くなります。タイムアウト・エラーが，必ずしもハードウェアやソフトウェアの問題を意味するわけではありません。頻繁に記録されるようなら，SCSI バスの負荷の軽減を検討してください (たとえば，新規バスの追加など)。

マウント検査は，ホストがデバイスについて宣言する状態です。バス・リセットやタイムアウトなど数多くの一時的なエラーの兆候が続くと，ホストがこの状態を宣言します。デバイスがマウント検査状態にある場合，正しいデバイスの存在と，デバイスのアクセス可能状態が確認されるまで，ホストは正常な I/O を中断します。再開後，マウント検査処理は正しいデータの読み書きができる状態で，中断していた I/O を再試行します。アプリケーション・プログラムにとって，マウント検査の状態が発生してもマウント検査が終了するまでは認識できません。

ホストが一定の時間内に正しいデバイスをアクセスできない場合，ホストはマウント検査タイムアウトを宣言し，アプリケーション・プログラムにはデバイスが利用できないことが通知されます。ホストがマウント検査タイムアウトを宣言したら，手作業でデバイスをサービス状態に復元する必要があります。マウント検査タイムアウトは，通常はエラーが一時的ではないことを表します。システム管理者は，マウント検査のタイムアウト時間を指定できます。デフォルトでは 1 時間になります。

シャドウ・ボリューム処理は，マウント検査に似ていますが，シャドウ・セット・メンバが対象です。シャドウ・セットのどれかのメンバにエラーが発生すると，そのセットはボリューム処理状態になり，OpenVMS がメンバのアクセスを再度確立できるまで I/O はブロックされます。シャドウ・ボリューム処理がタイムアウトになる前にアクセスが確立されると，中断していた I/O が再発行され，シャドウ・セットは正常動作に戻ります。タイムアウトが発生すると，障害の発生したメンバはセットから削除されます。システム管理者は，システム・ディスク・シャドウ・セットのタイムアウト値と，アプリケーション・シャドウ・セットのタイムアウト値を 1 つずつ設定できます。両方のタイムアウトのデフォルトは 20 秒です。

注意 SCSI 切断タイムアウトとデフォルトのシャドウ・ボリューム処理タイムアウトは同じです。SCSI バスの負荷が大きく，切断タイムアウトが発生しそうな場合は，シャドウ・ボリューム処理タイムアウトの値を大きくします。(推奨値は 60 秒です。) これにより，切断タイムアウト・エラーになってもシャドウ・セット・メンバが切断されるのを防ぐことができます。

バス・リセットが発生すると，マウント・ディスクがマウント検査やシャドウ・ボリューム処理を出入りするたびにOPCOM メッセージが表示されます。

ドライブの I/O でタイムアウト・エラーになると，マウント・ディスクがマウント検査やシャドウ・ボリューム処理を出入りするたびにOPCOM メッセージが表示されます。

クォーラム・ディスクや共用 SCSI バスに以上のどちらかのエラーが発生すると，さらに追加の OPCOM メッセージが表示され，クォーラム・ディスクとの接続が失われ，再接続されたことを表します。

OpenVMS システムでは，デバイス・ドライバに異常が発生すると，Error Log ユーティリティでその関連情報を保存できます。従来は，ほとんどの例外条件はハードウェア障害，ソフトウェア障害，一時条件 (ケーブルのゆるみなど) などのエラーの結果として発生していました。

DCL コマンド SHOW ERROR を入力すると，システムは，システムのブート後に発生したエラーの要約を表示します。以下に例を示します。

$ SHOW ERROR
Device                           Error Count 
SALT$PKB0:                               6 
$1$DKB500:                              10 
PEA0:                                    1 
SALT$PKA0:                               9 
$1$DKA0:                                 0 
 

この場合，SALT の SCSI ポート B (PKB0) における 6 つのエラーと，ディスク $1$DKB500 に対する 10 のエラー，その他が記録されています。

これらのエラーの詳細を確認するには，コマンド ANALYZE/ERROR/SINCE= dd-mmm-yyyy:hh:mm:ss を DCL プロンプトで実行します。このコマンドからの出力では，エラー・ログ・エントリのリストが以下のような情報とともに表示されます。

******************************* ENTRY    2337. ******************************* 
ERROR SEQUENCE 6.                               LOGGED ON:  CPU_TYPE 00000002 
DATE/TIME 29-MAY-1995 16:31:19.79                            SYS_TYPE 0000000D 
 
<identification information> 
 
       ERROR TYPE            03 
                                       COMMAND TRANSMISSION FAILURE 
       SCSI ID               01 
                                       SCSI ID = 1. 
       SCSI LUN              00 
                                       SCSI LUN = 0. 
       SCSI SUBLUN           00 
                                       SCSI SUBLUN = 0. 
       PORT STATUS     00000E32 
                                       %SYSTEM-E-RETRY，RETRY OPERATION 
 
<additional information> 
 

この例では，ERROR TYPE に注目してください。また，場合によっては，PORT STATUS フィールドも重要です。この例で，エラー・タイプは 03，COMMAND TRANSMISSION FAILURE，ポート状態は 00000E32，SYSTEM-E-RETRY となっています。

この項で示したエラー・ログ・エントリは，マルチホスト SCSI 構成で発生するエラーを想定しており，一般には気にかける必要はありません。ただし，この項で紹介した以外のメッセージのエラー・ログ・エントリはよく確認してください。

• ERROR TYPE 0007, BUS RESET DETECTED
  他のシステムが SCSI バスのリセット・シグナルを表明すると発生します。原因は次のとおりです。

  • システムの電源入力時の実行診断テストが実行された。

  • コンソール INIT コマンドが実行された。

  • EISA 構成ユーティリティ (ECU) が実行された。

  • コンソール BOOT コマンドが実行された (この場合，数回のリセットが実行されます)。

  • システム・シャットダウンが終了した。

  • システムがアダプタや SCSI バスに問題を検出した (割り込みタイムアウトなど)。

  
  このエラーが発生すると，マウントされているすべてのディスクについてマウント検査が開始します。

• ERROR TYPE 05, EXTENDED SENSE DATA RECEIVED
  SCSI バスをリセットしたときに，イニシエータは各デバイスから"センス・データ" を受け取る必要があります。このデータを受け取ったイニシエータは， EXTENDED SENSE DATA RECEIVED エラーをログします。これは正規の動作です。

• ERROR TYPE 03, COMMAND TRANSMISSION FAILURE
  PORT STATUS E32，SYSTEM-E-RETRY
  他のディスクとエラー情報を交換中のディスクに，ホストからコマンドが送信されることがあります。その場合，大半のディスクは SCSI "BUSY" コードを戻します。この SCSI BUSY コードに対し，OpenVMS システムはエラーをログし，操作を再試行します。このエラーが最もよく発生するのは，バスをリセットして間がない状況です。通常，リセット直後には発生しないはずですが，直後に発生する場合は正規の動作なので回避できません。

• ERROR TYPE 204, TIMEOUT
  割り込みタイムアウトが発生しました ( 付録 A.7.2.2 項 参照)。このエラーが発生するとディスクのマウント検査が開始します。

• ERROR TYPE 104, TIMEOUT
  選択タイムアウトが発生しました ( 付録 A.7.2.2 項 参照)。このエラーが発生するとディスクのマウント検査が開始します。

A.7.3 制限事項と既知の問題

複数のホストを同じSCSI バスに構成した OpenVMS Cluster ソフトウェアには，以下の制限事項があります。

• OpenVMS Alpha バージョン 7.2 より前のバージョンでは，ノードからディスクへのアクセスは，直接 SCSI パスから MSCP サービスによるパスにフェールオーバしません。
  MSCP サービスによるパスから直接 SCSI パスへのフェールオーバも実装されていません。一般に，この種のフェールオーバは，重要ではありません。 OpenVMS が直接パスとサービスによるパスの両方を検出すると，OpenVMS は必ず直接パスを選択するためです。ただし，MSCP サービスによるパスが最初のパスとして使用可能になり，直接パスが使用可能になる前に OpenVMS によって選択されるのを避けたい場合もあります。これを避けるには，以下の規則に従います。

  • SCSI システム・ディスクまでの直接パスがあるノードは，必ずSCSI ポートから直接ブートし，LAN は経由しないこと。

  • ノードが MSCP サーバを実行している場合，第 2 のノードがブート後は， SCSI ディスクをマルチホスト SCSI バスに追加しないこと (物理的な挿入や HSZxx のいずれも不可)。
    2 個のノードのブート後にデバイスを追加し，SYSMAN でデバイスを構成すると，直接パスが認識されるまでは，サービスによるパスを介していずれかのシステムに認識されます。イベントのタイミングにもよりますが，以下の手順でこの問題を回避できる場合もあります。

    $ MCR SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> IO AUTOCONFIGURE

    
    新しいデバイスまでの直接パスを確保するには (HSZxx 仮想デバイスも含む)，デバイスの追加後はノードをリブートしてください。

• OpenVMS Alpha バージョン 7.2 より前のバージョンでは，デバイスまでのパスが 2 本ある場合，$DEVICE_SCAN システム・サービスと F$DEVICE レキシカル関数により，共用バス上のデバイスが 2 回リストされます。非 SCSI システム・ディスクをブートすると，DCL コマンド SHOW DEVICE の出力に共用バス上のデバイスも 2 回リストされます。この二重リストは，表示プログラムのエラーです。これは特に問題ではなく，また，直接 SCSI パスの代わりに MSCP サービスによるパスが使用されることを意味しているわけでもありません。

• システムの電源入力時，ブート時，またはシャット・ダウン時に，システムは SCSI バスをリセットします。このリセットにより，SCSI バス上の他のホストが I/O エラーになります。Files-11 ボリュームの場合，このようなエラーはマウント検査ファシリティによって自動的に回復され，中断していた I/O が完了します。その結果，エラーなしでユーザ・プロセスが続行します。
  このレベルのエラー回復は，/FOREIGN 修飾子でマウントしたボリュームには適用できません。そのため，バスのリセット発生時に I/O が中断するとユーザ・プロセスは I/O エラー通知を受け取ります。
  マルチホスト SCSI バスには，できるだけフォーリン・デバイスをマウントしないでください。どうしてもフォーリン・デバイスを共用バスにマウントしなければならない場合は，フォーリン・デバイスに I/O を実行中にその共用バス上のシステムが SCSI バス・リセットを表明しないようにしてください。

• マルチホスト SCSI バス上で ARC コンソールが有効になっていると，すべてのローカル・ホスト・アダプタの SCSI ターゲット ID は 7 に設定されます。ホストやデバイスが ID 7 のバスにあると，この設定で SCSI ID 競合が発生します。この種の競合が発生すると，一般にそのバスだけでなく，場合によってはそのバス上のすべてのシステムもハングしてしまいます。
  ARC コンソールの使用対象は，KZPSA 構成ユーティリティなど一定のプログラムのアクセスに限定してください。ARC コンソールを実行するときは，まずマルチホスト SCSI バスや SCSI ID 7 でデバイスを接続しているバスからシステムを切り離します。

• システムの電源入力時，ブート時，シャットダウン時に SCSI バス・リセットが発生すると，その SCSI バス上の他のシステムがエラーをログし，OPCOM メッセージが表示されます。これは正規の動作であり，問題ではありません。

• マルチホスト SCSI バス上のシステムを急激にホルトすると (コンソールで Ctrl/P を押すなど)，KZPAA SCSI アダプタは同じバス上の他のホストの操作を干渉するようになります。システムが急激に停止した場合は，できるだけ早く初期化，ブート，または復帰 (CONTINUE) を続行してください。

• マイクロコードを更新中は，ディスク・ドライブに対する I/O をすべて停止してください。これについては，シングル・ホスト環境の場合よりもマルチホスト環境の方で特に注意が必要です。必要な手順については， 付録 A.7.6.3 項 を参照してください。

• EISA 構成ユーティリティ (ECU) を実行すると多数の SCSI バスをリセットできます。このリセットにより，同じ SCSI バス上の他のシステムは，そのバス上の I/O サブシステムが回復するまで一時停止します。ECU が実行中は，共用 SCSI バス上のシステムをシャットダウンすることをお勧めします(必須ではありません)。

OpenVMS Cluster システムでは，SCSI クォーラム・ディスクがシングル・ホスト SCSI バスにあるかマルチホスト SCSI バスにあるかに関わらず，制限事項が 1 つあります。 SCSI クォーラム・ディスクは，タグ付きコマンド・キューイング (TCQ) をサポートしなければなりません。この制限事項は，クォーラム I/O が OpenVMS SCSI ドライバで受け取る特別な処理に必ず適用します。

いずれにしてもマルチホスト SCSI バス上のディスクは，すべてタグ付きコマンド・キューイングをサポートする必要があり ( 付録 A.7.7 項 参照)，クォーラム・ディスクは一般にはシングル・ホスト・バスでは使用しないのでこの制限事項をそれほど気にする必要はありません。

A.7.4 トラブルシューティング

以下の項では，SCSI インターコネクトを使用する OpenVMS Cluster システムの代表的な問題について説明します。

---

目次

索引