OpenVMS Alpha
V7.3-2 リリース・ノート【翻訳版】

前へ 次へ 目次 索引

4.13.5 複合バージョンのクラスタにおける FDDI 経由のサテライトのブート

V7.3

OpenVMS Version 7.3 以降での変更により， Version 7.3 より前の OpenVMS を実行しているサテライトでの FDDI 経由のサテライト・ブートに影響が出る可能性があります。 NISCS_LAN_OVRHD システム・パラメータを 6 未満の値に設定し ( デフォルト値は 18)，NISCS_MAX_PKTSZ システム・パラメータを FDDI パケットの最大サイズ (4468) に設定すると，問題が発生することがあります。 NISCS_LAN_OVRHD によって， DESNC ( イーサネットの暗号化デバイス ) などのデバイスを調整する LAN 通信で使用する最大パケット・サイズが減ります。 OpenVMS Version 7.3 以降では， NISCS_LAN_OVRHD が使用されないため，最大パケット・サイズは減りません。

問題は， FDDI ブート・ドライバで使用するバッファ・サイズが 12 バイト少ないことです。サテライトのブートの FDDI ブート・ドライバにより， 12 バイトの不正データ (通常は 0) が SYSBOOT 中にロードされたイメージ内に挿入されます。そのため，早い段階で (数秒程度で) 不明なシステム・エラーやシステム停止が発生します。

この問題を解決するには，修正用ブート・ドライバ・パッチ・キットを入手して，サテライト・システムのルートにインストールします。または，サテライトにシステム・ディスクをサービスするシステムで NISCS_MAX_PKTSZ システム・パラメータの値が FDDI の最大パケット・サイズより 12 バイト以上少ないことを確認してください。

影響を受けるシステムは，次のとおりです。

4.13.6 PEdriver のエラー・メッセージの変更

V7.3-2

OpenVMS Version 7.3-2 の最終ビルドで， PEdriver が仮想サーキットをクローズする際のエラー・メッセージの出力形式が，バグによって変わってしまったことが分かりました。 Version 7.3-2 より前では，エラー・メッセージにリモート・ノード名が表示されていました。例を次に示します。 


%PEA0, Software is Closing Virtual Circuit - REMOTE NODE LARRY

Version 7.3-2 のメッセージでは，リモート・ノード名ではなく，PEdriver でリモート・ポートに内部的に割り当てた番号が表示されます。例を次に示します。 


%PEA0, Software is Closing Virtual Circuit - REMOTE PORT 219

あいにく，リモート・ポート番号に対応するノード名を簡単に調べる方法はありません。

この問題は，次回のリリースで修正されます。

4.13.7 優先順位 -128 の PEdriver チャネルは使用されない

V7.3-2

OpenVMS Version 7.3-2 から，優先順位が -128 の PEdriver チャネルは，クラスタ通信には使用されなくなりました。このため，SCACP または Availability Manager を使用してチャネルの優先順位に -128 を設定することで，特定のチャネルのクラスタ通信を無効にすることができます。

チャネルの優先順位は，ローカル LAN デバイスとチャネルそのものに割り当てられた管理優先順位の合計です。したがって，チャネルと LAN デバイスの管理優先順位の値が合計で -128 となる任意の組み合わせを割り当てることができます。

4.13.8 CI と LAN との間の回線切り替えによるクラスタの性能の低下

V7.3-1

CI と，複数の FDDI，100 Mb/s または Gb/s のイーサネット・ベースの CIRCUIT の両方を含む OpenVMS Cluster 構成では， SCS 接続が CI 回線と LAN 回線の間を約 1 分単位で移動することがまれにあります。この頻繁な回線の切り替えが原因で，クラスタの性能が低下したり，シャドウ・セット・メンバのマウント確認が行われる場合があります。

PEdriver では，数秒間継続している LAN 輻輳を検出し，対処することができます。 LAN パスでの遅延時間の大幅な増加やパケットの損失が検出されると， PEdriver はそのパスを使用しなくなります。パスの性能が回復したことが確認されると，そのパスを再度使用するようになります。

限界条件下では，LAN パスにクラスタ・トラフィックで使用する負荷が追加されると，遅延やパケットの損失が容認できる限界を超える場合があります。クラスタの負荷が取り除かれると，パスの性能は再度使用できる状態まで回復できる場合があります。

LAN 回線の負荷クラスに限界 LAN パスを割り当てると，その回線の負荷クラスが増加して CI の負荷クラス値 140 を超えて限界パスが対象となる場合 (また，反対に LAN 回線の負荷クラスが減少して 140 を下回り限界パスが除外される場合) に， SCS 接続は CI 回線と LAN 回線の間を移動します。

LAN 回線と CI 回線間の接続の移動を確認するには， CONNECTION クラスと CIRCUITS クラスを追加した SHOW CLUSTER を使用します。

回避方法

接続の移動が頻繁に行われている場合は，次のいずれかの回避方法を使用してください。

4.13.9 OpenVMS Cluster システムでの Gigabit Ethernet スイッチの制限事項

永続的な制限事項

Gigabit Ethernet スイッチを介して Gigabit Ethernet ノードを OpenVMS Cluster システムに追加しようとすると，スイッチが自動ネゴシエーションをサポートしていない場合には，失敗することがあります。DEGPA はデフォルトで自動ネゴシエーションを有効化しますが，すべての Gigabit Ethernet スイッチが自動ネゴシエーションをサポートしているとは限りません。

さらに，表示されるメッセージが誤解を招く場合もあります。たとえば， CLUSTER_CONFIG.COM を使用してノードを追加し，ローカル・ページをインストールするオプションとスワップ・ディスクを選択していると，ディスク・サービスの問題であるかのように見えます。CLUSTER_CONFIG.COM を実行しているノードは "waiting for node-name to boot" というメッセージを表示する一方で，ブート・ノードは "waiting to tune system" というメッセージを表示するためです。使用可能なディスクのリストはまったく表示されません。ネットワーク・パスが失われているのは，DEGPA とスイッチの間の自動ネゴシエーションのミスマッチが原因であることが伝わりません。

この問題を回避するには，新しいノードの DEGPA での自動ネゴシエーションを，次のように無効にします。

4.13.10 マルチパス・テープ・フェールオーバの制限事項

V7.3-1

Fibre Channel マルチパス・テープ・セット内の 1 つのデバイスで INITIALIZE コマンドを実行している間は，そのセットの別のメンバへマルチパス・フェールオーバを実行できません。別のマルチパス・テープ・デバイスが初期化されている間に，現在のパスで障害が発生した場合は，テープ・デバイスが機能しているパスへフェールオーバした後に， INITIALIZE コマンドを再試行してください。

この制限は，今後のリリースで無くなる予定です。

4.13.11 SCSI マルチパス媒体チェンジャでは自動フェールオーバは行われない

V7.3-1

Fibre と SCSI 間のテープ・ブリッジを使用して Fibre Channel に接続されている SCSI 媒体チェンジャ (テープ・ロボット) 向けの OpenVMS Alpha Version 7.3-1 以降には，パスの自動切り替えが実装されていません。そのようなデバイスに対しては複数のパスを構成できますが，別のパスに切り替える場合は，SET DEVICE/SWITCH コマンドを使用してパスの手動切り替えを使用する方法しかありません。

この制限は，今後のリリースで無くなる予定です。

4.14 OpenVMS Galaxy

OpenVMS は，AlphaServer ES47，ES80，および GS1280 システム上で Galaxy をサポートしています。これらのシステムで Galaxy を利用するためには，Version 6.6 ファームウェアが必要です。またさらに，Version 7.3-2 パッチ・キットが必要になることもあります。このファームウェアは，次の Web サイトから入手できます。 


http://ftp.digital.com/pub/Digital/Alpha/firmware/interim/gs1280/

最終的には， Version 6.6 ファームウェアは CD-ROM でも提供されます。

ここでは，OpenVMS Galaxy システムに関する注意事項をまとめます。また， 第 6.5 節 の注意事項も参照してください。

4.14.1 OpenVMS Graphical Configuration Manager

現時点では，OpenVMS Graphical Configuration Manager (GCM) は， AlphaServer ES47/ES80/GS1280 Galaxy の構成ではサポートされていません。ただし，Graphical Configuration Utility (GCU) はサポートされています。この制限は，今後無くなる予定です。

4.14.2 Smart Array 5300 の制限事項

現時点では，Smart Array 5300 (KZPDC) Backplane Raid Controller は， ES47/ES80/GS1280 Galaxy 構成ではデータ・デバイスとしてのみサポートされています。現在これらのコントローラでは，ブートおよびクラッシュ・ダンプ機能はサポートされていません。最終的には，ファームウェアの修正または OpenVMS ソフトウェアの修正によってサポートされます。

AlphaServer ES47/ES80/GS1280 システムでの Galaxy の構成については，『OpenVMS Alpha パーティショニングおよび Galaxy ガイド』を参照してください。

4.14.3 ファームウェアおよびパッチ・キットの要件

ハード・パーティション・サポート (ファームウェアのアップデートとパッチ・キットが必要) の品質試験が完了し， AlphaServer ES47/ES80/GS1280 システムで利用できるようになりました。『OpenVMS Alpha パーティショニングおよび Galaxy ガイド』では，ファームウェアとパッチ・キットの要件の詳細と，これらのシステムでハード・パーティションを構成する方法について説明しています。

注意
これまでの制限事項のうち解除されたものは，システム・ビルディング・ブロック境界上のハード・パーティションに関するものだけです。『OpenVMS Alpha パーティショニングおよび Galaxy ガイド』に記載されているとおり，サブシステム・ビルディング・ブロック境界上のハード・パーティションはサポートされるようになりました。『OpenVMS Alpha パーティショニングおよび Galaxy ガイド』に記載されているとおり，サブシステム・ビルティング・ブロックのハード・パーティションについての制限事項に注意してください。 ES47/ES80/GS1280 システム上のハード・パーティションは，最大 64 個のプロセッサをサポートできます。

4.14.4 共用メモリのグローバル・セクション作成で誤ったステータスが返されることがある

V7.3-2

SEC$M_SHMGS フラグを設定した SYS$CRMPSC_GDZRO_64 への呼び出しが， SS$_INSF_SHM_REG ステータスではなく， SS$_INFMEM ステータスで失敗することがあります。

このエラーの最も可能性の高い原因は， Galaxy の共用メモリ・コードが，内部の SHM_REG データ構造体を使い尽くしたことです。この状況を解消するには，SYSGEN パラメータ GLX_SHM_REG の値を大きくし，この大きいパラメータ値ですべての Galaxy インスタンスをリブートします。

各 SHM_REG データ構造体は，メモリを少ししか消費しません。したがって，このパラメータは，比較的大きな値 (たとえば，予想される共用メモリ領域の数の倍) にしても安全です。これにより，このパラメータを少しづつ大きくして， Galaxy 全体を何度もリブートすることになるのを避けることができます。

複合バージョン・クラスタでは， Galaxy の共用メモリのインタコネクト・エラーを避けるために，ドライバ・キット VMS73_DRIVER-V0300以降と， VMS722_DRIVER-V0300以降をインストールしなければなりません。

4.14.5 ES40 上の Galaxy: 非圧縮ダンプの制限事項

永続的な制限事項

AlphaServer ES40 Galaxy システムでは，インスタンス 1 のメモリが 4 GB (物理) 以上から始まっている場合，インスタンス 1 から raw (非圧縮) ダンプを書き出すことはできません。代わりに，圧縮ダンプを書き出さなければなりません。

4.14.6 ES40 上の Galaxy: Fast Path の無効化

V7.3-1

AlphaServer ES40 システムで Galaxy を使用する場合，インスタンス 1 でFast Pathを無効化する必要があります。そのためには，そのインスタンスで SYSGEN パラメータ FAST_PATH を 0 に設定します。

インスタンス 1 で Fast Path を無効化しないと，インスタンス 0 のリブート時にインスタンス 1 での入出力がハングします。この状態は，PCI バスをリセットし，インスタンス 1 をリブートするまで続きます。共有する SCSI または Fibre Channel がある場合，共有ノードでの入出力がハングし，これらのデバイスへのすべてのパスが無効になります。

4.15 OpenVMS Management Station

V7.3-2

OpenVMS Management Station for OpenVMS Alpha Version 7.3-2 の推奨バージョンは， Version 3.2B です。ただし，OpenVMS Management Station は， OpenVMS Version 6.2 およびそれ以降について，旧製品との互換性があります。

OpenVMS Alpha Version 7.3-2 のインストールには OpenVMS Management Station Version 3.2B が含まれます。 OpenVMS Management Station Version 3.2B は Web サイトからも入手できます。

4.16 OpenVMS Registry は Version 2 フォーマットのデータベースを壊すことがある

V7.3-2

キー・ツリーに揮発性のサブキーを 8 個以上作成して，スタンドアロン・システムやクラスタをリブートした場合，リブート後にサーバが起動すると，OpenVMS Registry サーバは， Version 2 フォーマットの Registry データベースを壊すことがあります。

この問題を回避するには，以下のいずれかを実行します。

Advanced Server for OpenVMS と COM for OpenVMS は，揮発性のキーを作成しません。

4.17 RMS Journaling

ここでは，RMS Journaling for OpenVMS に関する注意事項をまとめます。

RMS Journaling の詳細は，『RMS Journaling for OpenVMS Manual』を参照してください。このマニュアルは，OpenVMS Documentation CD-ROM (アーカイブ・マニュアルのディレクトリ) に入っています。

4.17.1 カーネル・スレッドと互換性のないリカバリ・ユニット・ジャーナリング

V7.3

DECdtm Services は複数カーネル・スレッド環境でサポートされず， RMS リカバリ・ユニット・ジャーナリングは DECdtm Services に依存しているため，RMS リカバリ・ユニット・ジャーナリングは，複数カーネル・スレッドが有効になっているプロセスではサポートされません。

4.17.2 変更されたジャーナル・ファイルの作成

V7.2

Version 7.2 より前には，リカバリ・ユニット(RU) ジャーナルは，ジャーナリングされたファイルと同じボリュームの [SYSJNL] ディレクトリに一時的に作成されていました。リカバリ・ユニット・ジャーナルのファイル名は RMS$process_id (process_id はプロセス ID の 16 進表現) という形式であり，ファイル・タイプは RMS$JOURNAL でした。

OpenVMS Version 7.2 では，RU ジャーナル・ファイルの作成に関して，次の点が変更されました。

これらの変更により，ジャーナル・ファイルの作成と削除で発生するディレクトリのオーバヘッドが削減されます。

次の例に，以前のバージョンと現在のバージョンの両方のジャーナル・ファイルの作成を示します。

以前のバージョン: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
現在のバージョン: [SYSJNL.NODE1]CB300412.;1

RMS が [SYSJNL] ディレクトリまたはノード固有のディレクトリを見つけることができない場合は，RMS は自動的にそのディレクトリを作成します。

前へ 次へ 目次 索引