| 前へ | 次へ | 目次 | 索引 |
マルチパス・デバイスへの現在のパスの選択方法は，デバイス・タイプと，パス選択の要因となったイベントによって決まります。
マルチパス・ディスク (DG，DK) またはテープ・デバイス (MG) への新しいパスが構成されると，現在のパスとして，最もデバイス数の少ない直接パスが自動的に選択されます。このときには，オペレータ・メッセージは表示されません。 ( このタイプのパス選択は，OpenVMS Alpha バージョン 7.3-1 から導入されました。) DG，DK，または MG デバイスでは，システム・ブート後初めてデバイスが使用されるまで，またはパスの手動切り替えが SET DEVICE/SWITCH コマンドで実行されるまで，このタイプのパス選択が行われます。
汎用のマルチパス SCSI デバイス (GG，GK) への新しいパスが構成されると，現在のパスとして，最初に検出されたパス ( プライマリ・パス ) が自動的に選択されます。 GG および GK デバイスの場合は，新しいパスが構成されても，プライマリ・パスが現在のパスとしてそのまま使用されます。通常，GG および GK デバイスは， HSG コントローラ LUN または HSV コントローラ LUN またはテープ・メディア・ロボットのコンソール LUN になります。
MOUNT コマンドを実行すると，マルチパス・ディスク・デバイスへの現在のパスが変わる場合があります。 MOUNT コマンドで実行された I/O により，ディスク・デバイスを別の HSx コントローラにフェールオーバする必要がない直接パスの検索が実行されます。
DG または DK ディスク・デバイスでの MOUNT コマンドによるパス選択は，次のように実行されます。
MOUNT ユーティリティでは，作業パスが見つかるまで，このパス選択アルゴリズムが繰り返し行われます。正確な再試行回数は，前の試行での経過時間と，MOUNT コマンドで指定した修飾子の両方で決まります。
OpenVMS Alpha バージョン 7.3-1 から導入されたこのパス選択プロセスには，次の利点があります。
この選択プロセスでは， 2 つの HSx コントロール間でデバイスを分散できます。これを行うには，次のような HSx コンソール・コマンドを使用します。
HSG> SET UNIT PREFERRED_PATH=THIS_CONTROLLER HSG> SET UNIT PREFERRED_PATH=OTHER_CONTROLLER |
また， 第 6.7.7 項 で説明したパスの手動切り替えの DCL コマンドを使用して，同じ HSx コントローラで別のホスト・バス・アダプタまたは別のポートを選択したり，デバイスを強制的に別の HSx コントローラへフェールオーバすることができます。
マルチパス・テープ・ドライブのサポートと，このタイプのパス選択は， OpenVMS Alpha バージョン 7.3-1 から導入されました。 MOUNT コマンド実行時のパス選択は，以下の理由から，マルチパス・テープ・ドライブ・デバイスの場合と，ディスク・デバイスの場合とで若干異なります。
MG テープ・ドライブ・デバイスでの MOUNT コマンドによるパス選択は，次のように実行されます。
6.7.9 OpenVMS によるマルチパス・フェールオーバの方法
マウント検証の対象となっているデバイスに対する I/O 操作が失敗し，失敗の状態から再試行が可能とされる場合，マウント検証が呼び出されます。デバイスがマルチパス・デバイス，またはマルチパス・デバイスを含むシャドウ・セットである場合，マウント検証中にそのデバイスへの代替パスが自動的に試行されます。これによって，デバイスがある HSx コントローラまたは MDR から別のものへフェールオーバした状態から透過的に回復することができ，デバイスへのパスの障害から，透過的に回復できます。
マウント検証の対象となるのは，次のデバイスです。
フォーリン・マウント・ディスク・ボリュームと汎用 SCSI デバイス (GG および GK) は，マウント検証の対象とならないため，自動マルチパス・フェールオーバは実行できません。
マウント検証中のパス選択は以下のように実行されます。
動作するパスが見つかるまで，またはマウント検証がタイムアウトになるまで手順 1 から 6 を繰り返します。動作するパスが見つかり，そのパスが異なる場合は，現在のパスが自動的にその新しいパスに切り替わり， OPCOM メッセージが発行されます。マウント検証が完了すると，失敗した I/O 操作が再開され，新しい I/O の処理が実行されます。このパス選択プロシージャでは，以下のような理由から， HSx コントローラ間で不必要にデバイスのフェールオーバが行われないような仕組みになっています。
このパス選択プロシージャでは， MSCP サービス対象パスよりも直接パスが優先して選択されます。これは，MSCP サービス対象パスを使用すると，サーバ・システムに余計な CPU および I/O オーバヘッドがかかるからです。それに比べ，直接パスでは，MSCP サーバ・システムに余計な CPU または I/O オーバヘッドがかかることはありません。このプロシージャで MSCP サービス対象パスが選択されるのは，利用可能な直接パスがどれも稼動していない場合だけです。さらに，このパス選択プロシージャでは，不必要なコントローラ・フェールオーバを行わないという制約に従って，利用可能な直接パスの使用量が調整されます。
6.7.10 直接パスへの自動フェールバック (ディスクのみ)
第 6.7.9 項 で説明したマルチパス・フェールオーバは， MSCP サービス対象パスにも適用されます。つまり，現在のパスが MSCP サービス対象パス経由であるときに，そのサービス対象パスで障害が発生した場合は，マウント検証によって，元の使用状態の直接パスへ自動フェールオーバが行われます。
ただし，MSCP パスで I/O エラーが発生した場合は，直接パスへフェールバックを行う必要があります。以下の順にイベントが発生したとします。
この場合，デバイスに対して直接パスの方が望ましい場合でも， MSCP サービス対象パスが継続して使用されます。これは，MSCP サービス対象パスでエラーが発生しなければ，パス選択プロシージャが実行されないからです。
自動フェールバック機能を使用すると，このような状態を解決することができます。マルチパス・ポーリングにより，次のすべての条件に該当することが確認されると，直接パスへフェールバックされます。
マウント検証によって自動フェールバックが実行されると，自動フェールオーバ・プロシージャが対象デバイスで行われます。
マルチパス・ポーリングは，主に，未使用パスの状態をテストして，以下のような状況にならないようにするために使用します。
ポーリングは，障害が発生してから 1 分以内にパス B の障害を検出し， OPCOM メッセージを発行します。システム管理者がこのメッセージに気がつくことにより，直ちに適切な処置を行うことができます。
デバイスは，パス・ポーリングが発行した SCSI INQUIRY コマンドに正常に応答しても，そのパスでのパスの切り替えやマウント検証に失敗する場合があります。システム管理者またはオペレータは，以下の 3 つの方法で自動フェールバックを制御できます。
マウントされたデバイスに直接パスと MSCP サービス対象パスの両方が存在する場合は，パス選択手順，自動フェールオーバ手順，自動フェールバック機能により，そのデバイスへの現在のパスは，通常，直接パスになります。例外として，パスが MSCP サービス対象パスに手動で切り替えられた場合，または使用状態の直接パスが存在しない場合などは， MSCP サービス対象パスが現在のパスになります。
6.7.11 パス切り替え候補としてのパスの有効化または無効化
デフォルトで，すべてのパスがパス切り替えの候補になります。パスは，SET DEVICE コマンドに /[NO]ENABLE 修飾子を指定して，切り替え候補として無効化または再有効化できます。以下のような場合にこの操作をします。
現在のパスは無効にできませんので注意してください。
パスを有効，無効にするためのコマンド構文は以下のとおりです。
SET DEVICE device-name/[NO]ENABLE/PATH=path-identifier |
以下のコマンドでは，デバイス $2$DKA502 の MSCP サービス対象のパスが有効になる。
$ SET DEVICE $2$DKA502/ENABLE/PATH=MSCP |
以下のコマンドでは，デバイス $2$DKA502 のローカル・パスが無効になる。
$ SET DEVICE $2$DKA502/NOENABLE/PATH=PKC0.5 |
パスを無効にするときは注意が必要です。
図 6-21 にあるような無効な構成を作成しないようにしてください。
6.7.12 パフォーマンスについての考慮
MSCP パスが現在のパスでない場合，ディスク・マルチパス・セット内に MSCP サービス対象パスが存在していても，安定した状態の I/O パフォーマンスには大きな影響はありません。
マルチパス・セット内に MSCP サービス対象パスが存在する場合は，特定の異常障害でのマウント検証中に，作業パスの検出に時間がかかる場合があります。直接パスが最初に試行されるため， MSCP パスが存在しても回復時間には影響ありません。
ただし，直接パスから MSCP サービス対象パスへ動的に切り替える機能を使用すると，マルチパス・ディスク・ストレージへの直接パスを使用する特定の MSCP サーバ・システムに対する I/O サービス負荷が大幅に増える可能性があります。サービス対象の I/O は， MSCP サーバのその他のほとんどすべての処理より優先されるため， MSCP サービス対象パスへのフェールオーバは，サーバのキャパシティとサービス対象の I/O 要求の増加率により，その MSCP サーバ上の他のアプリケーションの応答に影響を与える可能性があります。
たとえば，アプリケーションの作業負荷を処理できるだけの十分な CPU および I/O 処理能力がある OpenVMS Cluster 構成において，すべての共用 SCSI ストレージに直接 SCSI パスでアクセスするとします。このような構成の場合は，障害が発生しても，制限された数のデバイスが MSCP サービス対象パスへ強制的に切り替えられるので，機能することができます。しかし，さらに多くの障害が発生すると， MSCP サービス対象パスに対する負荷がクラスタのキャパシティに近づくため，アプリケーションのパフォーマンスが許容できないレベルに低下します。
システム管理者は， MSCP_BUFFER および MSCP_CREDITS システム・パラメータを使用して， MSCP サービスにリソースを割り当てることができます。 MSCP サーバに，すべての受信 I/O 要求を処理するだけのリソースがない場合，この MSCP サーバの MSCP パスに存在するデバイスにアクセスしているシステムのパフォーマンスが低下します。
MONITOR MSCP コマンドを使用すると， MSCP サーバでリソースが不足していないかどうか確認できます。 Buffer Wait Rate が 0 以外の場合は，その MSCP サーバが，リソースの待機中に一部の I/O を停止する必要があったことを示しています。
これらのパラメータには，適切な推奨値はありません。ただし，OpenVMS Alpha バージョン 7.2-1 から， MSCP_BUFFER のデフォルト値が 128 から 1024 に増やされました。
オンライン・ヘルプの SYSGEN ユーティリティに関するトピックで説明しているように， MSCP_BUFFER には，MSCP サーバのローカル・バッファ領域に割り当てるページレットの数を指定します。また，MSCP_CREDITS には， 1 つのクライアント・システムからアクティブにできる未処理の I/O 要求の数を指定します。たとえば，多くのディスクがいくつかの OpenVMS システムにサービスしているシステムの場合は，MSCP_BUFFER の値を 4000 以上に設定し， MSCP_CREDITS の値を 128 以上に設定します。
システム・パラメータの変更については，『OpenVMS システム管理者マニュアル』を参照してください。
MSCP サービス対象パスへのフェールオーバに依存している構成を， MSCP サービス対象パスに対する負荷レベルを最悪な状態にして，テストすることをお勧めします。複数サイト SAN を使用する複数サイトのディザスタ・トレラント・クラスタを構成している場合は， SAN をパーティション化し，MSCP サービス対象パスを強制的に使用する原因となる障害について検討してください。対称的なデュアル・サイト構成では，MSCP サービス対象パスからアクセスする SAN ストレージの 50 % をキャパシティとして指定することをお勧めします。
構成のキャパシティをテストするには，パスの手動切り替えを使用して， MSCP サービス対象パスを強制的に使用します。
| 前へ | 次へ | 目次 | 索引 |