| 前へ | 次へ | 目次 | 索引 |
重要: 表 9-8 の説明に従って SET HALT コマンドを設定した場合，電源障害が発生した後，電源が復旧しても，サテライトは自動的にリブートされず，コンソール・プロンプトで停止します。大規模な電源障害の場合は，この動作が適切ですが，サテライトの電源コードに誰かがつまずいたような場合は，サテライトを使用できなくなるため不便です。
以下の操作を実行するバッチ・ジョブを定期的に実行するようにすれば，このようにしてダウン状態になっているサテライトをスキャンし，起動することができます。
9.5 システム・ディスクのスループット
十分なシステム・ディスクのスループットを達成するには，以下の手法を組み合わせて使用することが必要です。
| 手法 | 関連項目 |
|---|---|
| ブート時にディスクが再構築されるのを回避する。 | 第 9.5.1 項 |
| システム・ディスクから作業負荷を軽減する。 | 第 9.5.2 項 |
| 複数のシステム・ディスクを構成する。 | 第 9.5.3 項 |
| Volume Shadowing for OpenVMS を使用する。 | 第 6.6 節 |
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 を実行して，ページ・ファイルとスワップ・ファイルのサイズと場所を指定する場合は，以下の方法でファイルを移動する。
|
以下の利用頻度の高いファイルをシステム・ディスクから移動する。
|
以下のいずれかの方法を使用する。
|
これらのファイルをシステム・ディスクから別のディスクに移動すると，システム・ディスクに対する大部分の書き込み操作を行わないようにすることができます。その結果，読み込み/書き込み率を向上でき，Volume Shadowing for OpenVMS を使用している場合は，システム・ディスクでのシャドウイングのパフォーマンスを最大限に向上できます。
9.5.3 複数のシステム・ディスクの構成
大規模なクラスタに含まれるコンピュータの数と，実行される作業に応じて，1 つのシステム・ディスクを構成するのか，複数のシステム・ディスクを構成するのか，その長所と短所を評価しなければなりません。
1 つのシステム・ディスクは管理が簡単ですが，大規模なクラスタでは， 1 つのシステム・ディスクで提供できるキャパシティより多くのシステム・ディスク I/O キャパシティが必要になることがあります。満足できるパフォーマンスを達成するために，複数のシステム・ディスクが必要になることがあります。しかし，複数のシステム・ディスクを管理する場合は，システム管理作業が増加することを考慮しなければなりません。
複数のシステム・ディスクが必要かどうか判断する場合は，以下のことを考慮してください。
| 条件 | 結果 | 説明 |
|---|---|---|
| 多くのユーザが同時にアクティブになるか，または複数のアプリケーションを同時に実行する。 | システム・ディスクの負荷はかなり大きくなる可能性がある。複数のシステム・ディスクが必要になる可能性がある。 | 一部の OpenVMS Cluster システムの場合，すべてのユーザが常にアクティブであることを想定して構成しなければならない。このような作業状況では，パフォーマンスを低下させずにピーク時の負荷を処理できるような，大規模でコストのかかる OpenVMS Cluster システムが必要になる可能性がある。 |
| 少ない数のユーザが同時にアクティブになる。 | 1 つのシステム・ディスクで多くのサテライトをサポートできる可能性がある。 | ほとんどの構成の場合，大部分のユーザが同時にアクティブになる可能性は低い。このような典型的な作業状況では，小規模でそれほどコストのかからない OpenVMS Cluster システムを構成できるが，負荷のピーク時にはパフォーマンスがある程度低下する可能性がある。 |
| 大部分のユーザが長期間にわたって 1 つのアプリケーションを実行する。 | 多くの I/O 要求をアプリケーション・データ・ディスクに渡すことができる場合は，1 つのシステム・ディスクで多くのサテライトをサポートできる。 | OpenVMS Cluster システムの各ワークステーション・ユーザは専用のコンピュータを保有しているため，大規模な演算中心ジョブをその専用コンピュータで実行するユーザは， OpenVMS Cluster システム内の他のコンピュータのユーザに大きな影響を与えない。クラスタに接続されているワークステーションの場合，重要な共用リソースはディスク・サーバである。したがって，ワークステーション・ユーザが I/O 集約型ジョブを実行する場合は，同じディスク・サーバを共用する他のワークステーションに与える影響が顕著になる可能性がある。 |
複数のシステム・ディスクを作成する別の方法として， Volume Shadowing for OpenVMS があります。ボリューム・シャドウイングを使用すると，1 つのシステム・ディスクの読み込み I/O キャパシティを増大することができ，しかも管理しなければならないシステム・ディスクの数を必要最低限に抑えることができます。これは，インストールやアップグレードを，ボリューム・シャドウイングされたシステム・ディスクに対して 1 回だけ適用すればよいからです。大量のシステム・ディスク I/O が必要なクラスタの場合，複数のシステム・ディスクを使用し，各システム・ディスクをシャドウ・セットとして構成することができます。
複数のシステム・ディスクを管理するための方法として，システム・ディスクのクローンがあります。システム・ディスクをクローンするには，以下の操作を行います。
サテライト・ルート用の基本ファイルは，ほとんど領域を必要としないため，1 つのシステム・ディスクに 96 以上のルートを簡単に格納できます。しかし，各サテライト・ノードに対して個別のダンプ・ファイルを使用する場合や，すべてのサテライト・ノードのページ・ファイルとスワップ・ファイルをシステム・ディスクに格納する場合は，ディスク領域がすぐに満杯になります。
9.6.1 手法
ディスク領域がすべて使用されてしまうのを回避するには，すべてのサテライトまたはサテライト・ノードのグループに対して共通のダンプ・ファイルを設定します。デバッグの目的で，各 MOP サーバとディスク・サーバに対して個別のダンプ・ファイルを作成しておくと最適です。また，ページ・ファイルとスワップ・ファイルをシステム・ディスクに格納するのではなく，サテライト・ノードのローカル・ディスクに格納することもできます。さらに，MOP サーバとディスク・サーバのページ・ファイルとスワップ・ファイルをシステム・ディスクから移動することもできます。
関連項目: ダンプ・ファイルの管理方法の計画については，
第 10.8 節 を参照してください。
9.7 システム・パラメータの調整
OpenVMS Cluster システムが拡大していくと，多くのノードに対応できるようにするために，OpenVMS 内の特定のデータ構造を拡張しなければならなくなります。しかし，拡張できない場合は (たとえば，非ページング・プールが不足しているため)，診断が困難な問題が断続的に発生する可能性があります。
クラスタが拡大する場合は，FEEDBACK オプション付きで AUTOGEN を頻繁に実行することで，多くのパラメータの設定を調整できるようにしなければなりません。AUTOGEN の実行の詳細については， 第 8.7 節 を参照してください。
FEEDBACK オプション付きで AUTOGEN を実行する他に，以下のパラメータを調べ，手動で調整しなければなりません。
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 の値を大きくしてください。
| 前へ | 次へ | 目次 | 索引 |