日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  OpenVMS >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:OpenVMS Cluster システムの管理の概要
第 2 章:OpenVMS Cluster の概念
第 3 章:OpenVMS Cluster インターコネクト構成
第 4 章:OpenVMS Cluster オペレーティング環境
第 5 章:共用環境の準備
第 6 章:クラスタ・ストレージ・デバイス
第 7 章:クラスタ・キューの設定と管理
第 8 章:OpenVMS Cluster システムの構成
第 9 章:大規模な OpenVMS Cluster システムの構築
第 10 章:OpenVMS Cluster システムの保守
付録 A :クラスタ・システム・パラメータ
付録 B :共通ファイルの作成
付録 C :クラスタのトラブルシューティング
付録 D :LAN 制御のためのサンプル・プログラム
付録 E :LAN 制御のためのサブルーチン
付録 F :NISCA プロトコルのトラブルシューティング
付録 G :NISCA トランスポート・プロトコル・チャネル選択および輻輳制御
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本

OpenVMS
OpenVMS Cluster システム


目次 索引

重要: 表 9-8 の説明に従って SET HALT コマンドを設定した場合,電源障害が発生した後,電源が復旧しても,サテライトは自動的にリブートされず,コンソール・プロンプトで停止します。大規模な電源障害の場合は,この動作が適切ですが,サテライトの電源コードに誰かがつまずいたような場合は,サテライトを使用できなくなるため不便です。

以下の操作を実行するバッチ・ジョブを定期的に実行するようにすれば,このようにしてダウン状態になっているサテライトをスキャンし,起動することができます。

  1. DCL レキシカル関数 F$GETSYI を使用して,クラスタ内の各ノードが正常に動作しているかどうか確認します。

  2. CLUSTER_MEMBER レキシカル・アイテムを確認します。

  3. 現在,クラスタのメンバでないサテライトに対して, NCP TRIGGER コマンドを実行します。



9.5 システム・ディスクのスループット

十分なシステム・ディスクのスループットを達成するには,以下の手法を組み合わせて使用することが必要です。

手法 関連項目
ブート時にディスクが再構築されるのを回避する。 第 9.5.1 項
システム・ディスクから作業負荷を軽減する。 第 9.5.2 項
複数のシステム・ディスクを構成する。 第 9.5.3 項
Volume Shadowing for OpenVMS を使用する。 第 6.6 節



9.5.1 ディスクの再構築の回避

OpenVMS ファイル・システムは,あらかじめ割り当てられているファイル・ヘッダとディスク・ブロックを格納したキャッシュを管理しています。システム障害が発生した場合などのように,ディスクが正しくディスマウントされていない場合,このあらかじめ割り当てられた領域が一時的に使用できなくなります。ディスクが再びマウントされると,OpenVMS はディスクをスキャンして,その領域を回復します。この処理をディスクの再構築と呼びます。

大規模な OpenVMS Cluster システムでは,妥当な時間内にノードをブートできるように十分なキャパシティを確保しておかなければなりません。ブート時にディスクの再構築の影響をできるだけ少なくするには,以下の変更を行うことを考慮します。

操作 結果
少なくともサテライト・ノードで,すべてのユーザ・ディスクに対して DCL コマンド MOUNT/NOREBUILD を使用する。ユーザ・ディスクをマウントするスタートアップ・プロシージャにこのコマンドを登録する。 サテライト・ノードがディスクを再構築するように設定するのは不適切であるが,サテライトまたは別のノードで障害が発生した後,サテライトが最初にリブートされる場合は,この動作が発生する可能性がある。
少なくともサテライト・ノードに対して,システム・パラメータ ACP_REBLDSYSD を 0 に設定する。 このように設定しておくと,ブート・プロセスの初期段階で OpenVMS によってシステム・ディスクが暗黙にマウントされるときに,再構築操作が実行されるのを防止できる。
システムの負荷がそれほど高くない時刻に, SET VOLUME/REBUILD コマンドを使用することにより,通常の勤務時間帯にディスクの再構築が実行されないようにする。コンピュータが起動された後,バッチ・ジョブまたはコマンド・プロシージャを実行して,各ディスク・ドライブに対して SET VOLUME/REBUILD コマンドを実行する。 ディスクの再構築操作を行うと,そのディスクに対する大部分の I/O 処理がブロックされるため,ユーザの応答時間が低下する可能性がある。SET VOLUME/REBUILD コマンドは再構築が必要であるかどうか判断するので,ジョブはすべてのディスクに対してコマンドを実行できる。このジョブは作業負荷の低い時間に,できるだけ強力なノードで実行する。

警告: 大規模な OpenVMS Cluster システムでは,大量のディスク領域をキャッシュにあらかじめ割り当てることができます。多くのノードがクラスタから突然削除された場合 (たとえば電源障害が発生した場合),この領域は一時的に使用できなくなります。通常,ほとんどディスクが満杯の状態でシステムが稼動している場合は,ブート時にサーバ・ノードで再構築を無効にしないでください。

9.5.2 作業負荷の軽減

OpenVMS Cluster 全体のブートでは,システム・ディスクのスループットに関する問題が発生しますが,その他に安定した状態での操作 (ログイン,アプリケーションの起動,PRINT コマンドの実行など) でも,特定のシステム・ファイルへのアクセスによって応答時間に影響することがあります。

パフォーマンス・ツールや監視ツール ( 第 1.5.2 項 に示したツールなど) を使用して, ホット・システム・ファイルを特定し,以下の表に示した手法を利用して,システム・ディスクでホット・ファイルに対する I/O 操作を削減することができます。

可能性のあるホット・ファイル 役立つ方法
ページ・ファイルとスワップ・ファイル コンピュータの追加時に CLUSTER_CONFIG_LAN.COM または CLUSTER_CONFIG.COM を実行して,ページ・ファイルとスワップ・ファイルのサイズと場所を指定する場合は,以下の方法でファイルを移動する。

  • コンピュータのページ・ファイルとスワップ・ファイルをシステム・ディスクから移動する。

  • サテライトにローカル・ディスクがある場合,そのディスクにサテライトのページ・ファイルとスワップ・ファイルを設定する。

以下の利用頻度の高いファイルをシステム・ディスクから移動する。

  • SYSUAF.DAT

  • NETPROXY.DAT

  • RIGHTSLIST.DAT

  • ACCOUNTNG.DAT

  • VMSMAIL_PROFILE.DATA

  • QMAN$MASTER.DAT

  • +VMS$OBJECTS.DAT

  • レイヤード製品および他のアプリケーション・ファイル

以下のいずれかの方法を使用する。

  • 第 5 章 の説明に従って,ファイルの新しい場所を指定する。

  • HSC サブシステムまたは RF/RZ ディスクでキャッシュを使用して,実際のシステム・ディスク・スループットを改善する。

  • ソリッドステート・ディスクを構成に追加する。これらのデバイスは待ち時間が短く,通常の磁気ディスクより多くの要求を処理することができる。ソリッドステート・ディスクはシステム・ディスクとして利用でき,またシステム・ファイルを格納するためにも使用できる。

  • DECram ソフトウェアを使用して,MOP サーバに RAMdisk を作成し,選択した読み取り専用のホット・ファイルのコピーを格納して,ロード時間を短縮する。RAMdisk はシステム内のメイン・メモリの領域であり,データを格納するように設定されているが,ディスクであるかのようにアクセスされる。


+VAX 固有

これらのファイルをシステム・ディスクから別のディスクに移動すると,システム・ディスクに対する大部分の書き込み操作を行わないようにすることができます。その結果,読み込み/書き込み率を向上でき,Volume Shadowing for OpenVMS を使用している場合は,システム・ディスクでのシャドウイングのパフォーマンスを最大限に向上できます。

9.5.3 複数のシステム・ディスクの構成

大規模なクラスタに含まれるコンピュータの数と,実行される作業に応じて,1 つのシステム・ディスクを構成するのか,複数のシステム・ディスクを構成するのか,その長所と短所を評価しなければなりません。

1 つのシステム・ディスクは管理が簡単ですが,大規模なクラスタでは, 1 つのシステム・ディスクで提供できるキャパシティより多くのシステム・ディスク I/O キャパシティが必要になることがあります。満足できるパフォーマンスを達成するために,複数のシステム・ディスクが必要になることがあります。しかし,複数のシステム・ディスクを管理する場合は,システム管理作業が増加することを考慮しなければなりません。

複数のシステム・ディスクが必要かどうか判断する場合は,以下のことを考慮してください。

  • 同時に実行されるユーザ操作
    多くのサテライトを含むクラスタでは,これらのサテライトで実行されるユーザ操作の量と種類がシステム・ディスクの負荷に影響し,したがって, 1 つのシステム・ディスクでサポートできるサテライトの数にも影響します。以下の例を参照してください。

    条件 結果 説明
    多くのユーザが同時にアクティブになるか,または複数のアプリケーションを同時に実行する。 システム・ディスクの負荷はかなり大きくなる可能性がある。複数のシステム・ディスクが必要になる可能性がある。 一部の OpenVMS Cluster システムの場合,すべてのユーザが常にアクティブであることを想定して構成しなければならない。このような作業状況では,パフォーマンスを低下させずにピーク時の負荷を処理できるような,大規模でコストのかかる OpenVMS Cluster システムが必要になる可能性がある。
    少ない数のユーザが同時にアクティブになる。 1 つのシステム・ディスクで多くのサテライトをサポートできる可能性がある。 ほとんどの構成の場合,大部分のユーザが同時にアクティブになる可能性は低い。このような典型的な作業状況では,小規模でそれほどコストのかからない OpenVMS Cluster システムを構成できるが,負荷のピーク時にはパフォーマンスがある程度低下する可能性がある。
    大部分のユーザが長期間にわたって 1 つのアプリケーションを実行する。 多くの I/O 要求をアプリケーション・データ・ディスクに渡すことができる場合は,1 つのシステム・ディスクで多くのサテライトをサポートできる。 OpenVMS Cluster システムの各ワークステーション・ユーザは専用のコンピュータを保有しているため,大規模な演算中心ジョブをその専用コンピュータで実行するユーザは, OpenVMS Cluster システム内の他のコンピュータのユーザに大きな影響を与えない。クラスタに接続されているワークステーションの場合,重要な共用リソースはディスク・サーバである。したがって,ワークステーション・ユーザが I/O 集約型ジョブを実行する場合は,同じディスク・サーバを共用する他のワークステーションに与える影響が顕著になる可能性がある。

  • 並列ブート処理
    OpenVMS Cluster のすべてのコンピュータが同時にアクティブになることはほとんどありませんが,クラスタがリブートされる場合はこのような状況になります。すべてのサテライトがオペレーティング・システムの再ロードを待機し,ブート・サーバが使用可能になると直ちに,並列にブートを開始します。このブート処理では,ブート・サーバ,システム・ディスク,インターコネクトに大きな I/O 負荷がかかります。
    注意: 複数のシステム・ディスクを構成し,コンピュータのシステム・ルートをこれらのディスクに等しく分散すれば,クラスタ全体のブート時間を短縮できます。この手法では,全体的なシステム・ディスク I/O キャパシティを拡大できるという利点がありますが,必要なシステム管理作業が増加するという欠点もあります。たとえば,レイヤード製品をインストールしたり, OpenVMS オペレーティング・システムをアップグレードする場合,各システム・ディスクに対して 1 回ずつ操作を繰り返さなければなりません。

  • システム管理
    システム・ディスクを追加すると,管理しなければならないシステム・ディスクの数に比例して,システム管理作業の負荷が増大するため,システム・ディスクの数は必要なパフォーマンス・レベルを達成するのに必要最低限の数にする必要があります。

複数のシステム・ディスクを作成する別の方法として, Volume Shadowing for OpenVMS があります。ボリューム・シャドウイングを使用すると,1 つのシステム・ディスクの読み込み I/O キャパシティを増大することができ,しかも管理しなければならないシステム・ディスクの数を必要最低限に抑えることができます。これは,インストールやアップグレードを,ボリューム・シャドウイングされたシステム・ディスクに対して 1 回だけ適用すればよいからです。大量のシステム・ディスク I/O が必要なクラスタの場合,複数のシステム・ディスクを使用し,各システム・ディスクをシャドウ・セットとして構成することができます。

複数のシステム・ディスクを管理するための方法として,システム・ディスクのクローンがあります。システム・ディスクをクローンするには,以下の操作を行います。

  • すべての OpenVMS Cluster ノードに対して,ルートを持つシステム・ディスク (またはシャドウ・セット) を作成します。

  • このディスクをマスタ・コピーとして使用し,このシステム・ディスクですべてのソフトウェア・アップグレードを実行します。

  • マスタ・コピーを他のディスクにバックアップして, クローンされたシステム・ディスクを作成します。

  • 固有の名前になるように,ボリューム名を変更します。

  • システム・ファイルをシステム・ディスクから移動しなかった場合は, SYLOGICALS.COM スタートアップ・ファイルがマスタ・システム・ディスクのシステム・ファイルを指すようにしなければなりません。

  • アップグレードを行う前に,最後にアップグレードした後でクローンされたディスクから必要な変更を保存しておかなければなりません。たとえば,MODPARAMS.DAT および AUTOGEN フィードバック・データ,請求のためのアカウンティング・ファイル,パスワードの履歴などを保存しておく必要があります。



9.6 システム・ディスクの領域の節約

サテライト・ルート用の基本ファイルは,ほとんど領域を必要としないため,1 つのシステム・ディスクに 96 以上のルートを簡単に格納できます。しかし,各サテライト・ノードに対して個別のダンプ・ファイルを使用する場合や,すべてのサテライト・ノードのページ・ファイルとスワップ・ファイルをシステム・ディスクに格納する場合は,ディスク領域がすぐに満杯になります。

9.6.1 手法

ディスク領域がすべて使用されてしまうのを回避するには,すべてのサテライトまたはサテライト・ノードのグループに対して共通のダンプ・ファイルを設定します。デバッグの目的で,各 MOP サーバとディスク・サーバに対して個別のダンプ・ファイルを作成しておくと最適です。また,ページ・ファイルとスワップ・ファイルをシステム・ディスクに格納するのではなく,サテライト・ノードのローカル・ディスクに格納することもできます。さらに,MOP サーバとディスク・サーバのページ・ファイルとスワップ・ファイルをシステム・ディスクから移動することもできます。

関連項目: ダンプ・ファイルの管理方法の計画については, 第 10.8 節 を参照してください。

9.7 システム・パラメータの調整

OpenVMS Cluster システムが拡大していくと,多くのノードに対応できるようにするために,OpenVMS 内の特定のデータ構造を拡張しなければならなくなります。しかし,拡張できない場合は (たとえば,非ページング・プールが不足しているため),診断が困難な問題が断続的に発生する可能性があります。

クラスタが拡大する場合は,FEEDBACK オプション付きで AUTOGEN を頻繁に実行することで,多くのパラメータの設定を調整できるようにしなければなりません。AUTOGEN の実行の詳細については, 第 8.7 節 を参照してください。

FEEDBACK オプション付きで AUTOGEN を実行する他に,以下のパラメータを調べ,手動で調整しなければなりません。

  • SCSBUFFCNT

  • SCSRESPCNT

  • CLUSTER_CREDITS

OpenVMS バージョン 7.2 より前のバージョンでは, SCSCONNCNT パラメータもチェックする必要がありました。しかし,OpenVMS バージョン 7.2 以降では, SCSCONNCNT パラメータは使用されなくなりました。現在では,SCS 接続は必要な場合にだけ割り当てられ,最大 65,000 の上限まで拡張されるようになりました。

9.7.1 SCSBUFFCNT パラメータ (VAX のみ)

注意: Alpha システムでは,SCS バッファは必要に応じて割り当てられ, SCSBUFFCNT パラメータは OpenVMS で使用するためにだけ確保されています。

説明: VAX システムでは,SCSBUFFCNT パラメータは,ノード間のブロック・データ転送で使用されるデータ・バッファを記述するバッファ記述子テーブル (BDT) のエントリの数を制御します。

エントリの不足の症状: エントリが不足すると,パフォーマンスに影響します。その中でも特に,MSCP サービスを実行するノードに影響する可能性があります。

BDT エントリの不足の判断方法: SDA ユーティリティ (または Show Cluster ユーティリティ) を使用して,BDT エントリを待機しているシステムを識別します。


SDA> READ SYS$SYSTEM:SCSDEF
%SDA-I-READSYM, reading symbol table  SYS$COMMON:[SYSEXE]SCSDEF.STB;1
SDA> EXAM @SCS$GL_BDT + CIBDT$L_QBDT_CNT
8046BB6C:  00000000   "...."
SDA>

不足の解決方法: SDA EXAMINE コマンドで 0 以外の値が表示された場合は, BDT 待ちが発生しています。値が 0 以外で,通常の操作でこの値が増大し続ける場合は,SCSBUFFCNT の値を大きくしてください。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡