| 前へ | 次へ | 目次 | 索引 |
OpenVMS Alpha バージョン 7.3-1 では，Fibre Channel および SCSI のディスク・デバイスとテープ・デバイスのマルチパス・フェールオーバの機能が大幅に拡張され，パスの自動的なバランス調整が行われるようになりました。各デバイスのパスの選択は，接続されているパスのうち，現在のパスとして使用しているデバイスの数が最も少ないパスが選択されるようになりました。
自動的なマルチパス・バランス調整の導入の他に，マルチパス・フェールオーバのパス選択アルゴリズムも変更され，パフォーマンスが向上しました。詳細については，『OpenVMS Cluster 構成ガイド』の 6.7.8 項，「 OpenVMS によるパス選択」を参照してください。
4.16.7 フェールオーバも含めた，Fibre Channel 構成のマルチパス・テープのサポート
OpenVMS Alpha バージョン 7.3 では，Fibre Channel 構成でテープがサポートされます。SCSI テープ・デバイスは，MDR(Modular Data Router)という Fibre-to-SCSI ブリッジを介して Fibre Channel に接続できます。MDR はデュアル・ポートであり，MDR へのパスを 2 つ設定することができます。たとえば，Alpha システムに 4 台の KGPSA アダプタがある場合，Fibre Channel 上でテープ・ドライブに対して 4 つの異なるパスが存在します。4 台の KGPSA アダプタがデュアル・ポート MDR に接続されている Alpha システムでは，実際にはテープ・ドライブに対して 8 つの異なるパスが存在します。
OpenVMS Alpha バージョン 7.3 では，複数のパスを利用していませんでした。自動構成で検出された最初のパスだけが使用されていて，また，残りのパスが認識されることはなく，最初のパスが切断された場合でも，他のパスを使用することはできませんでした。このシングル・パス・モデルには次の 2 つの制限がありました。
最初の制限に関しては，MDR ユーティリティの選択的ストレージ・プレゼンテーション(SSP)機能を使用することで回避できます。しかし，2 番目の制限に関しては，まったく回避方法がありません。
OpenVMS Alpha バージョン 7.3-1 では，この 2 つの制限がどちらも解消されました。Alpha システムから Fibre Channel テープへの可能なすべてのパスが構成され，使用可能になります。DCL コマンド SET DEVICE/SWITCH を使用して特定のパスを指定することができます。接続障害が発生した場合は，自動的にフェールオーバが実行されます。
マルチパス・フェールオーバは，マルチパス・セットのメンバである Fibre Channel に直接接続されているテープ・デバイス間でサポートされます。セットの 1 つのメンバで障害が発生すると，別のメンバがクライアントにテープ・デバイスを提供します。 しかし，ダイレクト・パスと MSCP によってサービスされるパスの間のマルチパス・フェールオーバは，テープ・デバイスに対してサポートされていません。 |
Fibre Channel 構成でのテープのサポートの詳細については，『OpenVMS Cluster 構成ガイド』を参照してください。
4.16.8 新しいクラスタ SCA サーキットおよびポート機能
ここでは，SCA サーキットおよびポートで使用できる新機能と，SCS ダイナミック・ロード・クラスの新しいサポートについて説明します。さらに，個々の PEdriver 仮想サーキット(VC)でチェックサムを個別に有効または無効に設定することができます。これらの変更により，OpenVMS Cluster システムで全体的なパフォーマンスを向上するために，これまでよりダイナミックな接続環境を構築できます。
4.16.8.1 ポートとサーキットの優先順位を設定する機能
OpenVMS Cluster のコードでは，常にパフォーマンスが最高のクラスタ・インターコネクト上のサーキットに SCS 接続を自動的に割り当てようとします。これらの割り当ては，インターコネクト固有のロード・クラスの値をもとに行われていました。しかし，自動サーキット選択では，各ユーザが必要とするパフォーマンスや可用性にとって最適な接続割り当てが必ずしも行われるとは限りません。それでも，自動サーキット選択を無効にする機能はこれまでありませんでした。この問題は OpenVMS バージョン 7.3-1 で解決されました。
OpenVMS バージョン 7.3-1 以降，SCS 接続のために選択されるサーキットを直接管理できるようになりました。パフォーマンスや可用性に対するそれぞれの要件に合わせてクラスタを調整することができるように，最高のロード・クラス値を持つサーキットを自動的に選択するという機能を無効にすることが可能になりました。
自動サーキット選択を無効にするには，SCACP ユーティリティまたは Availability Manager を使用して，個々のサーキットまたは SCA ポートに管理優先順位値を割り当てます(サーキットの現在の優先順位の値は，管理者の割り当てたローカル・ポートの優先順位とそのサーキットに割り当てられている管理優先順位の値の合計です)。
優先順位の最も高いサーキットに接続が割り当てられます。優先順位が最高のサーキットが複数ある場合は，ロード・クラスが最高のサーキットが選択されます。サーキットの現在の優先順位が変化すると，次のいずれかの結果になります。
|
サーキットがクローズされると，管理優先順位の設定は失われます。これは，サーキットに関する情報を格納するデータ構造の割り当てが，サーキットのクローズのたびに解除されるからです。サーキットが再びオープンされると，データ構造はデフォルト値で初期化されます。したがって，サーキット管理優先順位の値は，VC がクローズされるたびにリセットされ，伝達されません。 |
OpenVMS バージョン 7.3-1 より前のバージョンでは，チェックサムはノードのすべてのサーキットで有効または無効に設定しなければなりませんでした。このため，チェックサム機能が不要なサーキットでも，CPU が無駄に使用されるという問題がありました。OpenVMS バージョン 7.3-1 以降，チェックサムは各 LAN サーキットで個別に有効または無効に設定できるようになりました。この結果，ディザスタ・トレラント・クラスタのサイト間のサーキットなど，必要なサーキットに対してだけチェックサムを使用することを指定できるようになりました。
4.16.8.3 新しい SCS ダイナミック・ロード・クラスのサポート
OpenVMS バージョン 7.3-1 より前のバージョンでは，SCS サーキットのロード・クラスは，ポートのハード・コーディングされたロード・クラス値によってのみ決定されていました。この結果，GigaBit Ethernet サーキットから CI サーキットや DSSI サーキットが選択されていました。OpenVMS バージョン 7.3-1 以降，PEdriver は現在使用中の LAN パスのパフォーマンスを反映するように，SCS サーキットのロード・クラス値を動的に更新するようになりました。
同じ優先順位を持つサーキットが複数ある場合，サーキットのロード・クラスが変化すると，次のいずれかの結果になります。
OpenVMS Registry の新機能としては，Registry Control Program(REG$CP)の 2 つの機能拡張と，インデックスによるパフォーマンスの向上があります。
4.17.1 データベース・バージョンのサポート
Registry Control Program，REG$CP は，Registry データベースの異なるバージョンをサポートするように拡張されました。CREATE DATABASE コマンドで /VERSION 修飾子を使用できるようになりました。OpenVMS バージョン 7.3-1 では，バージョン 1 またはバージョン 2 のデータベースを指定できます。デフォルトでは，CREATE DATABASE はバージョン 2 のデータベースを作成します。
4.17.2 値タイプのサポート
SZ，EXPAND_SZ，MULTI_SZ，DWORD という値タイプの他に，Registry Control Program，REG$CP は値の作成または変更(/TYPE_CODE=BINARY)のときに BINARY 値タイプをサポートするように拡張されました。値タイプが BINARY の値をリストする場合，データは 16 進数で表示されます。
値の作成および変更では，/INPUT 修飾子が追加されたことにより，値データをファイルから読み込むことができるようになりました。入力データ・タイプは，ファイル・レコードに埋め込まれたキーワードで指定されます。これらのキーワードはエクスポートされたデータベース・ファイルに含まれるキーワードと互換性があります。
/TYPE_CODE 修飾子で指定されるストレージ・データ・タイプは，入力データ・タイプから独立しています。たとえば，値タイプを SZ(Unicode 文字列)として指定し，値データを 16 進数で入力することができます。
これらの機能を組み合わせることで，REG$CP を介して大量の未処理データを入力することができます。一方，/DATA 修飾子と DWORD データ・タイプによるデータの入力は，未処理データを入力することができますが，データの長さに制限があります。同様に，SZ 値タイプと /DATA による入力は，長さの制限は受けませんが，入力できるデータのタイプが制限されます。つまり，Unicode 文字列しか入力できません。また，コマンド・ラインでは /DATA を使用して入力できるデータの量も制限されます。/INPUT 修飾子を使用すると，これらの制限を回避することができます。
4.17.3 新しい Registry データベース・バージョン
OpenVMS NT Registry のパフォーマンスはバージョン 7.3-1 で向上しました。このようにパフォーマンスが向上したのは，主に Registry データベースにインデックスを付けたことによります。しかし，この変更の結果，新しいバージョンの Registry データベースを作成する必要が発生しました。
Registry サーバは今後も以前のデータベース・フォーマットであるバージョン 1.0 をサポートします。しかし，インデックスを活用するには，現在のデータベースをバージョン 2.0 に変換する必要があります。
バージョン 1 のデータベースをバージョン 2 に変換するかどうかは任意です。クラスタをアップグレードする間，複合バージョン・クラスタ内のノードで Registry サーバを実行する予定がある場合は，Registry データベースを変換しないでください。バージョン 7.3-1 より前のバージョンの OpenVMS を実行するノードでは，Registry サーバはバージョン 2 のデータベースにアクセスできません。
OpenVMS Registry データベースの変換の詳細については，『COM, Registry, and Events for OpenVMS Developer's Guide』を参照してください。
4.18 SHOW CLUSTER ユーティリティに追加された新しいフィールド
OpenVMS Show Cluster ユーティリティ(SHOW CLUSTER)は，OpenVMS Cluster 内のノードを監視し，クラスタ固有の動作とパフォーマンスに関する情報を表示します。このユーティリティは，仮想サーキットとローカル・ポートに関する追加情報を表示するように拡張されました。
表 4-4 は，仮想サーキット情報を表示するために CIRCUITS クラスで使用できる新しいフィールドについて説明しています。
| フィールド名 | 説明 |
|---|---|
| LD_CLASS | サーキットの現在の容量。 |
| MGT_PRIORITY | 管理操作によってサーキットに割り当てられた優先順位。 |
| PRIORITY | サーキットの現在の優先順位。この値は，サーキットに割り当てられた管理優先順位と割り当てられているローカル・ポートの優先順位の合計である。 |
表 4-5 は，ローカル・ポートの追加情報を表示するために LOCAL_PORTS クラスで使用できる新しいフィールドについて説明しています。
| フィールド名 | 説明 |
|---|---|
| LP_LD_CLASS | ポートのインターコネクトの速度(メガビット/秒)をもとにしたポートのハード・コーディングされた容量。 |
| LP_PRIORITY | ポートに割り当てられた管理優先順位。 |
SHOW CLUSTER ユーティリティの詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。
4.19 生成されたサブプロセスの新しい命名方法
OpenVMS で生成されたサブプロセスに名前を付ける方法は，パフォーマンスを向上するために変更されました。
DCL_CTLFLAGS は，システム単位で特定のコマンドのデフォルト動作を変更するために使用されるビットマスクです。現在，このビットマスクの下位ビットだけが定義されています。下位ビットは，SPAWN コマンドまたは LIB$SPAWN ルーチンを使用して生成されたサブプロセスに割り当てられるデフォルトのプロセス名を制御します。
OpenVMS バージョン 7.3-1 より前のバージョンでは，プロセス名が指定されていない場合，システムはユーザ名に _n を追加することで名前を作成していました。ただし，n はシステムに現在存在するプロセスに対して次に使用可能な，重複しない整数です。たとえば，SYSTEM というユーザから最初に生成されたプロセスは SYSTEM_1 という名前になり，2 番目のプロセスは SYSTEM_2 になります。ギャップが見つかると，次に使用可能な番号が選択されます。
次に使用可能な番号を判断するという手法方法では，固有の番号が見つかるまで，名前の末尾の番号に 1 を加算することにより，プロセス名を作成する必要があるため，パフォーマンスの点で問題があります。複数のサブプロセスがすでに存在する場合，サブプロセスを生成するコストはさらにかさみます。多くのプロセスが同じ OpenVMS グループ内に存在する場合，プロセス名はグループ全体で一意でなければならないため，コストはさらに増大します。
OpenVMS バージョン 7.3-1 から，サブプロセスに対してデフォルトで作成されるプロセス名が変更されました。次に使用可能な固有の番号を順に検索するのではなく，ランダムな番号がユーザ名に追加されるようになりました。したがって，SYSTEM というユーザから生成された最初のプロセスは，SYSTEM_154，SYSTEM_42，SYSTEM_87 などのようになります。この手順では，同じ番号がすでに使用されている可能性は低いため，最初の試行で一意な名前を検索できる可能性が非常に高くなります。この結果，プロセス生成のコストを大幅に削減することができ，サブプロセスの生成が頻繁に行われるアプリケーションでは，この変更によってパフォーマンスを大幅に向上することができます。
しかし，アプリケーションによっては，サブプロセス内の割り当てに関して以前の方法に依存している可能性があります。このため，システムを必要に応じて構成できるように，DCL_CTLFLAGS パラメータを使用することができます。
DCL_CTLFLAGS のビット 0 は，デフォルトのサブプロセス名を割り当てる動作を選択します。
4.20 SYSMAN ユーティリティに追加された新しいコマンドと修飾子
表 4-7 で説明しているように，SYSMAN ユーティリティでは，既存の RESERVED_MEMORY ADD コマンドと RESERVED_MEMORY MODIFY コマンドに新しい修飾子が追加され，さらに 2 つの新しいコマンドも追加されました。
| コマンド | 修飾子 | 説明 |
|---|---|---|
| RESERVED_MEMORY ADD | /RAD | Reserved Memory Registry データ・ファイルで予約する RAD を指定する。 |
| RESERVED_MEMORY MODIFY | /RAD | Reserved Memory Registry データ・ファイルで既存の RAD を変更する。 |
| /NEW_RAD | Reserved Memory Registry データ・ファイルで置換する RAD を指定する。 |
表 4-7 は，OpenVMS バージョン 7.3-1 に追加された新しい SYSMAN コマンドを説明しています。
| コマンド | 説明 |
|---|---|
| RESERVED_MEMORY EXTEND | RESERVED_MEMORY ADD コマンドは，メモリ予約と呼ばれる物理メモリを予約する。1 つのメモリ予約のために，複数の RAD(resource affinity domain)を格納するためのメモリ・セクションを追加する場合は，RESERVED_MEMORY EXTEND コマンドを使用する。このコマンドには次の 2 つの修飾子がある。
|
| RESERVED_MEMORY LIST | Reserved Memory Registry データ・ファイルに現在格納されている予約をプレビューする。予約を指定しなかった場合は，現在のすべての予約が表示される。 |
| 前へ | 次へ | 目次 | 索引 |