日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V7.3-2
ライブラリ

タイトルページ
目次
まえがき
第 1 章:インストールに関する注意事項
第 2 章:関連製品に関する注意事項
第 3 章:一般ユーザ向けの注意事項
第 4 章:システム管理に関する注意事項
第 5 章:プログラミングに関する注意事項
第 6 章:ハードウェアに関する注意事項
付録 A:リタイア製品情報
付録 B:インターロックされたメモリ命令の使用
索引
PDF
OpenVMS ホーム
OpenVMS Alpha | HPE 日本

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


目次 索引



V7.3-2

システムと,SCSI デバイスまたは Fibre Channel デバイスの間に存在する複数のパス間でのフェールオーバをサポートするマルチパス機能は, OpenVMS Alpha Version 7.2-1 で導入されました。 OpenVMS Alpha Version 7.3-1 では, Fibre Channel マルチパス・テープ・デバイス間でのフェールオーバのサポートが導入されました。

このマルチパス機能は,サード・パーティのディスク・キャッシング,ディスク・シャドウイング,または類似の機能を持つ製品との互換性がないことがあります。この機能がソフトウェアの製造元でサポートされるようになるまでは,そのようなソフトウェアを,マルチパス・フェールオーバ用に構成された SCSI デバイスまたは Fibre Channel デバイスでは使用しないでください。

OpenVMS Alpha SCSI ディスク・クラス・ドライバ (SYS$DKDRIVER.EXE), OpenVMS Alpha SCSI テープ・クラス・ドライバ (SYS$MKDRIVER.EXE),または SCSI 汎用クラス・ドライバ (SYS$GKDRIVER) の Driver Dispatch Table (DDT) の変更に依存しているサード・パーティ製品で SCSI マルチパス機能が正常に動作するようにするには,製品を変更する必要があります。

このようなソフトウェアの作成者は,OpenVMS Alpha Version 7.3-2 で導入された新しい DDT Intercept Establisher ルーチンを使用して,ソフトウェアを変更できるようになりました。これらのルーチンの詳細は,『HP OpenVMS Alpha Version 7.3--2 新機能説明書』を参照してください。

注意

サード・パーティ製のディスク・キャッシュ製品や,ディスク・シャドウィング・アプリケーションを使用している場合は,アプリケーションがこれらの新しいルーチンを使用するように改訂されるまで, OpenVMS SCSI マルチパス構成や Fibre Channel マルチパス構成でこれらの製品を使用しないでください。

OpenVMS Alpha SCSI マルチパス機能と Fibre Channel マルチパス機能の詳細は,『OpenVMS Cluster 構成ガイド』を参照してください。

4.13.3 SCSI テープ・ドライブ: テープのディスマウント後の MEDOFL エラー

V7.3-2

DISMOUNT/NOUNLOAD コマンドを使用してテープをディスマウントした後, SCSI テープに対して最初に実行したコマンドで, "%SYSTEM-F-MEDOFL, medium is offline" エラーが発生することがあります。たとえば,テープをディスマウントした直後にテープを初期化またはマウントしようとすると,このエラーが発生することがあります。ディスマウント操作の一環としてテープがまだリワインドされているため,このエラーが返されます。

テープ・ユニットがマルチパス・セットのメンバの場合,マルチパス回復の一環として (MEDOFL エラーの代わりに) パス・スイッチが発生することがあります。これらの MEDOFL エラーとパス・スイッチは,一部のモデルの SCSI テープ・ドライブ (LTO-2 HP Ultrium 460 など) で発生する傾向があります。

テープに対する DISMOUNT コマンド実行後の最初のコマンドでパス・スイッチが発生した場合,テープが回復され,ユーザ・アクションが不要であることを示しています。 MEDOFL エラーが発生した場合は,テープのリワインド完了後,失敗したコマンドを再実行してください。このような手作業での再実行を不要にするために, SCSI テープ・ドライバは,将来の修正キットで変更されます。

4.13.4 CLUSTER_CONFIG.COM と,ルート・ディレクトリ名の制限

V7.3-2

この注意事項は,『OpenVMS Cluster システム』の表 8-3 (「CLUSTER_CONFIG_LAN.COM および CLUSTER_CONFIG.COM から要求されるデータ」) のアップデートに関するものです。

このドキュメントでは,システム・ディスクに直接アクセスするコンピュータで使用できる, 16 進数の桁数の制限を記載しています。この制限は,VAX コンピュータについては正しいのですが, Alpha コンピュータについては正しくありません。

このコマンド・プロシージャで,次の情報の入力が求められます。


Computer's root directory name on cluster system disk: 

このドキュメントには,次のように記載されています。

プロシージャから提供されるデフォルトをそのまま使用するときは, Return キーを押す。または SYSx という形式で名前を指定する。

  • システム・ディスクに直接アクセスできるコンピュータの場合, x は 1 〜 9 または A 〜 D の 16 進数である (たとえば,SYS1 や SYSA)。

  • サテライトの場合,x は 10 〜 FFFF の値でなければならない。

システム・ディスクに直接アクセスできる 16 進値の範囲の制限は, VAX コンピュータについては正しく記載されています。システム・ディスクに直接アクセスできる Alpha コンピュータでは,この 16 進値の有効範囲はもっと広く, VAX の範囲と同じ 1 〜 9 または A 〜 D の他に, 10 〜 FFFF の範囲も含まれます。 SYSE と SYSF は,システム用に予約されています。

『OpenVMS Cluster システム』の次の版には,この情報が盛り込まれます。

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 バイト以上少ないことを確認してください。

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

  • NISCS_MAX_PKTSZ システム・パラメータの値が 4456 より大きく, OpenVMS Version 7.3 以降の Alpha システムまたは VAX システムから FDDI アダプタ経由でブートされる Alpha サテライト。

  • NISCS_MAX_PKTSZ から NISCS_LAN_OVRHD を引いた値が 4456 より大きく, FDDI 経由でシステム・ディスクをサービスし,OpenVMS Version 7.3 より前のシステムから FDDI アダプタ経由でブートされる Alpha サテライト。サービスされるシステム・ディスクの OpenVMS は, Version 7.3 以降でもそれより前のバージョンでも構いませんが,旧バージョンでは NISCS_LAN_OVRHD が通常 18 に設定されるため,システム・ディスクが Version 7.3 以降の場合にこの問題が発生しやすくなります。



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 を使用します。

回避方法

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

  • SCACP または AM を使用して,使用する回線またはポートにより高い優先順位を割り当て,自動接続割り当てと移動を無効にします。
    SCACP コマンドの例を次に示します。


    $ MC SCACP 
    SCACP> SET PORT PNA0 /PRIORITY=2    ! This will cause circuits from local 
                                        ! CI port PNA0 to be chosen over 
                                        ! lower priority circuits. 
     
     
    SCACP> SET PORT PEA0 /PRIORITY=2    ! This will cause LAN circuits to be 
                                        ! chosen over lower priority circuits. 
    

  • SCACP SHOW CHANNEL コマンドを使用して,使用の切り替えが行われているチャネルを確認します。次に,SCACP を使用して,特定のチャネルに目的のチャネルよりも低い値を割り当てて,そのチャネルを明示的に除外することもできます。たとえば,次のように指定します。


    SCACP> SET CHANNEL LARRY /LOCAL=EWB/REMOTE=EWB /PRIORITY=-2 
    


    max,max-1 の範囲内にある CHANNEL および LAN デバイスの優先順位値は等価とみなされます。つまり,この両方のデバイスに,最大優先順位値が指定されているものとみなされます。チャネルまたは LAN デバイスを使用対象から外す場合は,優先順位値に 2 以上の差をつける必要があります。



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 での自動ネゴシエーションを,次のように無効にします。

  • 最初にノードをクラスタ内でブートするときには,会話型ブートを実行する。

  • 新しいノードのシステム・パラメータ LAN_FLAGS の値を 32 に設定して, 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 個のプロセッサをサポートできます。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項