| 前へ | 次へ | 目次 | 索引 |
以下の項では，SCSI インターコネクトを使用する OpenVMS Cluster システムの代表的な問題について説明します。
A.7.4.1 終端問題
すべての SCSI インターコネクトに 2 つのターミネータがあるか確認してください (インターコネクトの両端に 1 つずつ)。外部からは見えませんが，BA350 エンクロージャ， BA356 エンクロージャ，DWZZx，KZxxx の各アダプタには内部ターミネータがあります ( 付録 A.4.4 項 参照)。
A.7.4.2 正しくない構成が原因のブート障害やマウント障害
OpenVMS では，この項で説明するエラーが自動的に検出され，バグチェックやディスク・マウントの拒否により，このような構成エラーが原因のデータ・ロスを回避しています。
A.7.4.2.1 ブートストラップ・プロセス間のバグチェック
OpenVMS Alpha バージョン 7.2 より前のバージョンでは，バグチェックを実行する原因になるブート時の構成エラーが 3 種類ありました。バグチェック・コードは， VAXCLUSTER，Error detected by OpenVMS Cluster softwareです。
OpenVMS がブートすると，すべての SCSI ID に照会コマンドを送信して SCSI バス上のデバイスを認識します。デバイスは照会を受け取ると，ディスク，テープ，またはプロセッサのどれであるかを表すデータを戻します。
プロセッサ・デバイス (ホスト・アダプタ) によっては，オペレーティング・システムの助けがなくてもこの照会に応答しますが，他のデバイスは，オペレーティング・システムが実行していないと応答できません。OpenVMS Cluster システムでサポートしているアダプタには，オペレーティング・システムの助けが必要です。このようなアダプタは， OpenVMS の助けを借りて照会に対する応答により情報を伝え，応答の受信側は，以下の構成エラーを検出します。
OpenVMS Alpha バージョン 7.2 では，正しく構成されていないバス上の SCSI デバイス ( 付録 A.7.4.2.1 項 参照) は構成されません。そして不正構成を記述するエラー・メッセージが表示されます。
A.7.4.2.3 マウント障害
ディスクのマウントが失敗する原因の構成エラーには 2 種類あります。
まず，共用 SCSI バス上のディスクからシステムがブートするときにシステム・ディスクのマウントが失敗することがあります。これは，同じ SCSI バスにブート済みの別のシステムがあって，問題のシステム・ディスクにそのシステムが別のデバイス名を使用している場合に発生します。(前の項で説明したように，2 つのシステムが使用しているコントローラ名や割り当てクラスの構成が間違っていると，共用バス上のデバイス名に関する競合が発生します。) 前の項で説明したバグチェックを先に実行しない場合は，コンソールに以下のエラー・メッセージが表示されます。
%SYSINIT-E- error when mounting system device, retrying..., status = 007280B4 |
この状態をデコードすると次のようになります。
VOLALRMNT， another volume of same label already mounted |
このエラーは，システム・ディスクがすでにマウント済みであり，OpenVMS Cluster システムの他のドライブ名として扱われているようなので再度マウントはできない，ということを表しています。これを解決するには，共用 SCSI バスのノードごとに，コントローラ名と割り当てクラスの値をチェックします。
もう一つの構成エラーは，ディスクがタグ付きコマンド・キューイング (TCQ) をサポートしていないと，共用 SCSI バス上の SCSI ディスクは両方のシステムでマウントできません。TCQ が OpenVMS Cluster の状態遷移で必要とされるコマンド整列保証動作を渡すからです。
OpenVMS は， 付録 A.7.4.2.1 項 で説明する機構を利用して認証時に， SCSI バス上に他のプロセッサがあるか判断します。SCSI バスにおける別のホストの存在は，システムをリブートするまで記録として保存されます。
この情報は，非 TCQ デバイスをマウントするときに使用します。デバイスがマルチホスト・バスにない場合，マウントは失敗し，以下のメッセージが戻ります。
%MOUNT-F-DRVERR，fatal drive error. |
同じ SCSI 上の複数のホストでこのドライブをマウントする場合は，TCQ をサポートするドライブに置き換える必要があります。
マルチホスト SCSI バスで最初にブートするプロセッサは，他のホストが OpenVMS をまだ実行していないため，他のホストからの照会応答を受け取りません。したがって，最初にブートするシステムは，同じバスに複数のホストがあることを認識しないので非 TCQ ドライブを共用バスにマウントできます。その SCSI バスの他のホストは，最初のホストを検出しますが，デバイスのマウントはできません。2 つのプロセッサが同時にブートすると，互いの存在を検出し，どちらも共用バス上に非 TCQ ドライブをマウントできなくなります。
A.7.4.3 接地
接地オフセット電圧が高すぎたり，最大 SCSI インターコネクト長を超えると，システム障害が生じたりパフォーマンスが低下したりします。SCSI 接地要件の詳細については， 付録 A.7.8 項 を参照してください。
A.7.4.4 インターコネクトの長さ
シグナルの一貫性を確保するには，SCSI バスの長さを厳しく守る必要があります。バスの長さの推奨値を守らないと，診断が困難な問題が発生します (断続的なエラーなど)。 SCSI バスの長さについては， 付録 A.4.3 項 を参照してください。
A.7.5 SCSI アービトレーション上の注意
SCSI バスはどの一瞬をとってみても，制御できるイニシエータ (通常は，ホスト・システム) やターゲット (通常は，周辺機器) は 1 つだけです。複数のターゲットによる SCSI バスのアクセスで混雑しているコンピューティング環境では，これらのターゲットの一部でスループットに関る問題が発生することがあります。この項では，SCSI バスの制御，その制御がコンピューティング環境に及ぼす影響，および，最良の結果を得るために何ができるかについて説明します。
SCSI バスの制御は常に変化します。イニシエータから SCSI ターゲットにコマンド (READ 等) を発行すると，ターゲットはコマンドを処理している間，通常，SCSI かバスとの接続を切断して，他のターゲットやイニシエータにそのバスを開放します。ターゲットがコマンドに対する応答準備を整えたら，再び SCSI バスの制御を取り戻す必要があります。同じく，イニシエータがターゲットにコマンドを送信するときも，SCSI バスの制御をとる必要があります。
複数のターゲットとイニシエータがバスの制御を同時に要求した場合，バスの所有権は， SCSI 標準に定められたアービトレーションというプロセスで決まります。デフォルトのアービトレーション規則は単純です。つまり，バスの制御は，要求イニシエータや最上位のユニット番号を持つターゲットに与えられます。
以下の項では，アービトレーションの意味と，環境に関係のあるアービトレーション状態に対する応答方法を説明します。
A.7.5.1 マルチディスク環境におけるアービトレーション問題
バスがあまりビジーでなく，バスの競合もあまりない場合は，単純なアービトレーション方式で，システム上のすべてのデバイスに対し，その I/O 要求に十分に応えることができます。しかし，イニシエータからの I/O 要求が増えれば増えるほど，バスの競合がますます通常の状態になってきます。その結果，ID 番号が下位のターゲットは，バス上の他のデバイス (特に ID 番号が上位のターゲット) によって頻繁に I/O 要求を阻止されるため，そのパフォーマンスが低下します。ある程度バスがビジーになると，下位のターゲットは要求を達成することができなくなります。このような状況では，同時に一時停止になるコマンドが増えるため，イニシエータが複数あるシステムで発生しやすくなります。
OpenVMS システムでは，I/O 要求の処理にかかる時間を監視して下位ターゲットが完全にブロックされるのを防いでいます。指定した時間内に要求が処理されない場合，その I/O が終了するまでOpenVMS システムは新しい要求の送信を停止します。このアルゴリズムは，すべてのターゲットがバスを均等にアクセスできることを保証するものではありませんが，下位番号のターゲットが完全にブロックされることはなくなります。
A.7.5.2 アービトレーション問題の対策
I/O に大きな負荷がかかっている時間帯に，サービスを迅速に受けられないディスクが見つかった場合は，サイトの状況に合わせて以下の対策をいくつか実行してみてください。
下位と上位の ID 番号のディスクに対するサービスをより平均化できるもう 1 つの方式として，ホスト ID を最上位ではなく最下位の番号 (0 か 1) にする方法があります。この方式では，ホストはバスの制御が得られないので，最下位の ID のディスクも含め，すべてのディスクがバスを必要とする限り，新しいコマンドを送信できなくなります。この選択肢では一定の状況下では公正さを達成できるものの，以下のような理由から，多くの場合あまり望ましい構成ではありません。
バス・セグメントを接続する DWZZx などのアクティブ・デバイスでは，あるセグメントのデバイスから別のセグメントのデバイスへのシグナルの受け渡しで，わずかな遅延が生じます。状況によっては，このような遅延がアンフェア・アービトレーションのもう 1 つの原因になることがあります。たとえば，大きなワーク・ロードの下ではディスク・サービス問題 (枯渇) が発生する場合があります。
ディスク 5 の ID 番号は最上位ですが，ディスク 5 からのバスへのアクセス順位が最下位になる場合もあります。そのような状態は，下位番号のディスクのどれかがバスの制御をとり，バスの制御が必要な操作を終了した後に発生します。この時点でディスク 5 は，バスが開放されていることを認識できないので，バスの制御のアービトレーションまで待機します。その結果，バスが開放されたことを認識して，バス要求を発行した下位ディスクのどれかがそのバスの制御を得ます。
この種の問題は，以下の対策で削減できます。
A.7.6 OpenVMS Cluster システムが実行中の SCSI デバイスの取り外しや取り付け
手順が正しければ，バスの実行中の操作を割り込むことなく一定の SCSI デバイスはアクティブな SCSI バスに挿入したり取り外すことができます。この機能を ホット・プラグと呼びます。ホット・プラグでは，障害が発生した構成要素を交換中でも，OpenVMS Cluster システムの処理を続行できるような構成が可能です。ホット・プラグ機能がない場合は，SCSI バスに対するデバイスの追加，削除をする前に，SCSI バスを非アクティブにし，SCSI バスの電源を切る必要があります。
SCSI OpenVMS Cluster システムでホット・プラグを利用するには，バス上のすべてのデバイスが一定の電気的特性を備え，SCSI バスに正しく構成できることが前提になります。ホット・プラグを成功させるには，この項で説明する手順に正しく従う必要があります。これらの手順では，アクティブ・バス・シグナルの邪魔にならないよう，ホット・プラグしたデバイスは非アクティブになります。
この項では，OpenVMS を実行中のホストと同じ SCSI バス上にあるデバイスのホット・プラグ手順を説明します。手順の内容は，ストレージ・コントローラが背後にある HSZxx などの SCSI バスでは異なります。デバイスのホット・プラグ手順については，ストレージ・コントローラのマニュアルを参照してください。 |
この項で太字になっている用語は，プラグ規則と手順で使用する言葉です。
| 前へ | 次へ | 目次 | 索引 |