前へ | 次へ | 目次 | 索引 |
すべての 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 の助けを借りて照会に対する応答により情報を伝え,応答のを受信側は,以下の構成エラーを検出します。
ポート割り当てクラスを使用する場合を除き,SCSI バス上の各アダプタの OpenVMS デバイス名は同一でなければなりません (すべて PKC0 など)。同一にしない場合,OpenVMS Cluster ソフトウェアはホストからストレージまでのアクセスを管理できなくなります ( 付録 A.6.2 項 と 付録 A.6.3 項 参照)。
OpenVMS は,照会応答でコントローラ名を送信し,これを自動的にチェックします。ブート・システムはこの応答を受け取り,リモート・コントローラ名とローカル・コントローラ名を比較します。一致しない場合は,OPCOM メッセージが出力され, VAXCLUSTER バグチェックとともにシステムが停止してデータ・ロスを防ぎます。詳細については,Help Message ユーティリティの NOMATCH エラーの説明を参照してください。(Help Message ユーティリティを NOMATCH に使用するには,DCL プロンプトで HELP/MESSAGE NOMATCH を入力します。)
SCSI バス上の各ホストのディスク割り当てクラスの値は,ゼロ以外の同じ値であるか,対応するポート割り当てクラスの値とします。それ以外の値では,OpenVMS Cluster ソフトウェアはホストからストレージへのアクセスを管理できません ( 付録 A.6.2 項 and 付録 A.6.3 項 参照)。
OpenVMS は照会応答の中で,必要な情報を送信してこれを自動的にチェックします。ブート・システムは応答を受け取ると,リモート値をローカル値と比較します。一致しない場合または値がゼロの場合,OPCOM メッセージが出力され,システムは VAXCLUSTER バグチェックを出力して停止し,データ・ロスを防ぎます。Help Message ユーティリティの ALLODIFF エラーと ALLOZERO エラーの説明を参照してください。
OpenVMS を実行していなかったり,構成のチェックに必要なコントローラ名や割り当てクラスの情報を戻さないプロセッサが,SCSI バスにあります。ブート・システムが照会応答を受け取り,その応答に OpenVMS の特別な構成情報が含まれていない場合, OPCOM メッセージが出力され,VAXCLUSTER バグチェックが実行されます。Help Message ユーティリティの CPUNOTSUP エラーの説明を参照してください。
システムの SCSI バスにプロセッサ・デバイスが必要な場合,SYSGEN の特別なパラメータ (この場合は SCSICLUSTER_Pn) については,Help Message ユーティリティの CPUNOTSUP メッセージの説明を参照してください。
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 バスでは異なります。デバイスのホット・プラグ手順については,ストレージ・コントローラのマニュアルを参照してください。 |
この項で太字になっている用語は,プラグ規則と手順で使用する言葉です。
バス・アイソレータに接続されているセグメントは,そのセグメント上のすべてのデバイス (場合によってはバス・アイソレータを除く) が非アクティブのとき非アクティブになります。
ホット・プラグの計画と実行にあたっては,以下の 3 つの規則に従ってください。
ホット・プラグしたデバイスでは,SCSI バスと 1 個でしか接続できず,デバイスで SCSI バスを終端することはできず,またデバイスの接続はスタブの許容最大長さを超えることができないことを意味します。 図 A-3 を参照してください。有効なホット・プラグである SCSI バス・トポロジの例を 図 A-13 に示します。
図 A-13 SCSI バス・トポロジ
同じ理由から,デバイスは非アクティブな状態で電源を切っておくほうが良いでしょう。 |
デバイスを確実に非アクティブにする手順については, 付録 A.7.6.3 項 を参照してください。
クォーラム・ディスクを取り外すには,クォーラム・ディスクとしてデバイスを取り外すように OpenVMS Cluster システムを再構成する必要があります。操作手順については,『Compaq OpenVMS Cluster システム』を参照してください。
クォーラム・ディスクの可用性を強化するには,HSZxx ミラー・セットをクォーラム・ディスクとして使用します。この場合,クォーラム・ディスクの機能を維持しながら,障害が発生したメンバを交換できます。
以上のことから,ホット・プラグ操作では,バス・アイソレータに接続されているセグメントのどれかを (潜在的な) アクティブ・セグメントとして指定し,他は非アクティブにしておきます。 図 A-14 を参照してください。セグメントを確実に非アクティブにするための手順については, 付録 A.7.6.3 項 を参照してください。
図 A-14 バス・アイソレータのホット・プラグ
バス・アイソレータには複数のスタブ接続があるので,それぞれにホット・プラグが可能ですが,ホット・プラグ操作では,同時に複数のセグメントをアクティブ・セグメントにすることはできません。
同じデバイス・タイプの異なる実装は互換性があります (たとえば,RZ26L は RZ28B と交換できます)。ただし,新しいデバイスのマウントを開始するまで,システムはデバイス・タイプの変更を認識しません。また,ホスト方式のシャドウイングでは,シャドウ・セットのすべてのメンバが同じデバイス・タイプでなければなりません。
この規則が必要なのは,SCSI バスのノードに,MSCP サービス提供によるパスではなく直接パスでディスクをアクセスさせるためです。新しいデバイスを (SYSMAN IO コマンドで) システム上に構成すると,システムは共用 SCSI バスの二次システムにそのデバイスをサービスします。二次システムは,MSCP サービスによるパスで新しいデバイスを自動的に構成します。この場合,MSCP サービスによるパスから直接 SCSI パスへのフェールオーバが実装されていないため,二次システムは新しいデバイスに直接 SCSI パスを使用できなくなります。
前へ | 次へ | 目次 | 索引 |