# Compaq OpenVMS
OpenVMS Cluster システム

前へ | 次へ | 目次 | 索引

## 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 の値を大きくしてください。

## 9.7.2 SCSRESPCNT パラメータ

説明: SCSRESPCNT パラメータは，システムで使用できる応答記述子テーブル (RDT) のエントリの数を制御します。 2 つのノード間で実行されている各メッセージ交換に対して， RDT エントリが必要です。

エントリの不足の症状: エントリが不足すると，エントリが使用可能になるまでメッセージ転送が遅延するため，パフォーマンスが低下します。

RDT エントリの不足の判断方法: 以下に示すように SDA ユーティリティを使用して，十分な数の RDT を使用できないために待ち状態になっている要求がないかどうか，各システムを確認します。

    SDA> READ SYS$SYSTEM:SCSDEF
    %SDA-I-READSYM, reading symbol table  SYS$COMMON:[SYSEXE]SCSDEF.STB;1
    SDA> EXAM @SCS$GL_RDT + RDT$L_QRDT_CNT
    8044DF74:  00000000   "...."
    SDA>

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

## 9.7.3 CLUSTER_CREDITS パラメータ

説明: CLUSTER_CREDITS パラメータは，VMS$VAXcluster 通信を受信するためにノードが割り当てる接続ごとのバッファの数を指定します。このシステム・パラメータは動的ではありません。つまり，値を変更した場合，変更したノードをリブートしなければなりません。

デフォルト: デフォルト値は 10 です。非常にロック・レートの高いクラスタの場合，デフォルト値では不足することがあります。

クラスタ・クレジットの問題の症状: クレジットが不足すると，クレジットを使用できるようになるまでメッセージ転送が遅延するため，パフォーマンスが低下します。 SHOW CLUSTER コマンドでは，クレジット待ち (credit waits) として表示されます。

クレジット待ちが発生しているかどうかの判断方法: 以下に示す手順で SHOW CLUSTER ユーティリティを使用します。

1. SHOW CLUSTER/CONTINUOUS を実行します。

2. REMOVE SYSTEM/TYPE=HS と入力します。

3. ADD LOC_PROC, CR_WAIT と入力します。

4. SET CR_WAIT/WIDTH=10 と入力します。

5. リモート・ノードの VMS$VAXcluster 接続に対して，ログに記録されている CR_WAITS (クレジット待ち) の数が常に増加しているかどうかを確認します。理想的な状態では，クレジット待ちは発生しないはずです。しかし，非常に負荷の高い状況では，ときどきクレジット待ちが発生します。

クレジット待ちの増加の解決方法:

1 分間に 2 回以上，CR_WAITS の数が増加する場合は，以下の操作を行います。

1. ログに記録されているノードで，CLUSTER_CREDITS パラメータの値を 5 だけ大きくします。パラメータは，SHOW CLUSTER を実行しているノードではなく，リモート・ノードで変更しなければなりません。

2. ノードをリブートします。

すべてのノードで CLUSTER_CREDITS パラメータの値が同一である必要はありません。

# 9.8 ネットワーク・インスタビリティの最小化

ネットワーク・インスタビリティも OpenVMS Cluster の動作に影響します。 表 9-9 は，典型的なネットワークの問題をできるだけ発生しないようにするための手法を示しています。

表 9-9 ネットワークの問題をできるだけ発生しないようにする手法
手法 | 説明
--- | ---
RECNXINTERVAL パラメータを調整する。 | RECNXINTERVAL システム・パラメータは， OpenVMS Cluster システムがノードと連絡できなくなったときに，そのノードを構成から削除するまでの待ち時間を秒数で指定する。多くの大規模な OpenVMS Cluster 構成では， RECNXINTERVAL パラメータは 40 秒に設定されている (デフォルト値は 20 秒である)。 RECNXINTERVAL の値を大きくすると，アプリケーションの一時停止が長くなる可能性がある。特に，ノードが OpenVMS Cluster システムから異常な状態で削除されるときは，このような状況が発生する。一時停止は，RECNXINTERVAL によって指定される秒数だけ接続マネージャが待機することによって発生する。
ネットワークを保護する。 | LAN が OpenVMS Cluster システムの一部であるかのように取り扱う。たとえば，20 台のサテライトがハングしているときに，不特定のユーザが ThinWire セグメントを切断して，新しい PC を接続できるような環境を認めない。
ハードウェアおよび構成を注意深く選択する。 | 特定のハードウェアは大規模な OpenVMS Cluster システムで使用するのに適さない。 ネットワーク・コンポーネントの中には，軽い負荷では適切に動作するが，トラフィックが高くなると，正常に動作できなくなるものがある。正常に動作しないと，パケットが紛失したり，壊れる可能性があり，その結果，パケットを再送しなければならなくなる。その結果，パフォーマンスが低下し，OpenVMS Cluster 構成の安定性に影響する。 完全なライン速度でフィルタリングや転送を行うことができないブリッジや，混雑した状況を適切に処理できないリピータには注意する。 適切な OpenVMS Cluster 構成と機能を判断するには，『Compaq OpenVMS Cluster 構成ガイド』を参照する。
LAVC$FAILURE_ANALYSIS 機能を使用する。 | ネットワーク障害を切り分ける方法については， 付録 D.5 節 を参照する。

# 9.9 DECnet クラスタ・エイリアス

少なくとも 1 つの OpenVMS Cluster メンバがクライアント・プログラムの要求を処理できるときに，リモート・アクセスが正常に行われるように， OpenVMS Cluster に対してクラスタ・エイリアスを定義しなければなりません。

クラスタ・エイリアスは，OpenVMS Cluster システムの 1 つのネットワーク・ノード識別子として機能します。クラスタ内のコンピュータは，DECnet ネットワーク内の他のコンピュータとの通信でエイリアスを使用できます。 DECnet for OpenVMS を稼動しているノードは，DECnet-Plus を稼動しているノードと別の固有のクラスタ・エイリアスを使用できます。さらに，DECnet-Plus を稼動しているクラスタは， VAX に対して 1 つのクラスタ・エイリアス，Alpha に対して別のもう 1 つのクラスタ・エイリアス，さらに VAX と Alpha の両方に対して別のエイリアスを使用できます。

注意: 1 つのクラスタ・エイリアスに，DECnet for OpenVMS または DECnet-Plus のどちらか一方を稼動しているノードを含むことができますが，両方を含むことはできません。また， DECnet for OpenVMS と DECnet-Plus の両方を稼動している OpenVMS Cluster では，複数のシステム・ディスク (それぞれに 1 つずつ) が必要です。

関連項目: OpenVMS Cluster システムでのクラスタ・エイリアスの設定と使用の詳細については， 第 4 章 を参照してください。

前へ | 次へ | 目次 | 索引