| 前へ | 次へ | 目次 | 索引 |
説明: 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 分間に 2 回以上，CR_WAITS の数が増加する場合は，以下の操作を行います。
すべてのノードで CLUSTER_CREDITS パラメータの値が同一である必要はありません。
9.8 ネットワーク・インスタビリティの最小化
ネットワーク・インスタビリティも OpenVMS Cluster の動作に影響します。 表 9-9 は，典型的なネットワークの問題をできるだけ発生しないようにするための手法を示しています。
| 手法 | 説明 |
|---|---|
| RECNXINTERVAL パラメータを調整する。 | RECNXINTERVAL システム・パラメータは， OpenVMS Cluster システムがノードと連絡できなくなったときに，そのノードを構成から削除するまでの待ち時間を秒数で指定する。多くの大規模な OpenVMS Cluster 構成では， RECNXINTERVAL パラメータは 40 秒に設定されている (デフォルト値は 20 秒である)。
RECNXINTERVAL の値を大きくすると，アプリケーションの一時停止が長くなる可能性がある。特に，ノードが OpenVMS Cluster システムから異常な状態で削除されるときは，このような状況が発生する。一時停止は，RECNXINTERVAL によって指定される秒数だけ接続マネージャが待機することによって発生する。 |
| ネットワークを保護する。 | LAN が OpenVMS Cluster システムの一部であるかのように取り扱う。たとえば，20 台のサテライトがハングしているときに，不特定のユーザが ThinWire セグメントを切断して，新しい PC を接続できるような環境を認めない。 |
| ハードウェアおよび構成を注意深く選択する。 | 特定のハードウェアは大規模な OpenVMS Cluster システムで使用するのに適さない。
|
| LAVC$FAILURE_ANALYSIS 機能を使用する。 | ネットワーク障害を切り分ける方法については， 付録 D.5 節 を参照する。 |
少なくとも 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 章 を参照してください。
クラスタが起動され，動作するようになったら，サイト固有の日常の保守操作を行うことができます。たとえば，ディスクのバックアップやユーザ・アカウントの追加，ソフトウェアのアップグレードやインストール，フィードバック・オプション付きの AUTOGEN の定期的な実行，システムのパフォーマンスの監視などを行うことができます。
現在の構成データの記録を管理することも必要です。特に，ハードウェア・コンポーネントやソフトウェア・コンポーネントの変更は記録しておく必要があります。サテライト・ノードを含むクラスタを管理する場合は， LAN の動作を監視することが重要です。
以下の特殊な保守操作が必要になることがあります。
定期的なシステム管理手順の一部として，OpenVMS Backup ユーティリティを使用して，オペレーティング・システム・ファイル，アプリケーション・ソフトウェア・ファイル，関連ファイルを別のデバイスにコピーしなければなりません。
OpenVMS Cluster で行う一部のバックアップ操作は，シングル OpenVMS システムの場合と同じです。たとえば，使用中のディスクの追加型バックアップや，非共用ディスクのバックアップは同じです。
クラスタで使用するバックアップ・ツールとしては， 表 10-1 に示すものがあります。
| ツール | 使い方 |
|---|---|
| オンライン・バックアップ | 以下のディスクをバックアップするために，実行中のシステムから使用する。
警告: バックアップを実行する時点で書き込みのためにオープンされているファイルは，正しくバックアップされないことがある。 |
| メニュー・ドリブンまたは +スタンドアロン BACKUP | 以下のいずれかの方法を使用する。
|
アプリケーションやユーザの要件に応じて，バックアップ・プロセスは定期的に実行するようにしてください。バックアップ・スケジュールを作成する際は，ユーザとアプリケーションによるシステムの利用が少ない時刻にバックアップを行うように調整してください。
関連項目: OpenVMS Backup ユーティリティの詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻 ) 』を参照してください。
10.2 OpenVMS オペレーティング・システムの更新
OpenVMS オペレーティング・システムを更新する場合は， 表 10-2 の手順に従います。
| ステップ | 操作 |
|---|---|
| 1 | システム・ディスクをバックアップする。 |
| 2 | 各システム・ディスクに対して 1 回ずつ，更新手順を実行する。 |
| 3 | 必須アップデートをインストールする。 |
| 4 | そのシステム・ディスクからブートされる各ノードで AUTOGEN を実行する。 |
| 5 | UETP (User Environment Test Package) を実行して，インストールをテストする。 |
| 6 | OpenVMS Backup ユーティリティを使用して，新しいシステム・ボリュームのコピーを作成する。 |
関連項目: 詳細については，適切な OpenVMS アップグレードおよびインストール・マニュアルを参照してください。
10.2.1 ローリング・アップグレード
OpenVMS オペレーティング・システムでは，複数のオペレーティング・システムを使用している OpenVMS Cluster システムは，システム・ソフトウェアをアップグレードする間もサービスを提供できます。このプロセスを ローリング・アップグレード と呼びます。これは，すべてのノードがアップグレードされるまで，各ノードが順にアップグレードされ，リブートされるからです。
システムを 1 つのシステム・ディスクから 2 つ以上のシステム・ディスクに移行しなければならない場合は，以下の操作を行います。
| ステップ | 操作 |
|---|---|
| 1 | 第 8.5 節 の手順に従って，ディスクの複製を作成する。 |
| 2 | システム・ファイルの調整については， 第 5.10 節 の説明に従う。 |
ここに示した各関連項目は，システム・ディスクを追加し，複数のシステム・ディスクに共通のユーザ環境を準備することにより，キュー・データベース，ライトリスト，プロキシ，メール，その他のファイルなどの共用システム・ファイルを OpenVMS Cluster システム全体で使用可能にするときに参照すると役立ちます。
10.3 LAN ネットワーク障害の分析
OpenVMS オペレーティング・システムでは， LAN で発生した OpenVMS Cluster ネットワーク障害を分析するのに役立つサンプル・プログラムが提供されています。 SYS$EXAMPLES:LAVC$FAILURE_ANALYSIS.MAR プログラムを編集して，利用することにより，障害が発生しているネットワーク・コンポーネントを検出し，切り分けることができます。ネットワーク障害分析プログラムを利用すると，障害が発生しているネットワーク・コンポーネントを検出して切り分けるのに必要な時間を短縮することができ，その結果，クラスタの可用性を大幅に向上できます。
関連項目: ネットワーク障害分析プログラムの詳細については， 付録 D を参照してください。
10.4 構成データの記録
OpenVMS Cluster システムを効果的に管理するには，すべてのハードウェア・コンポーネントとソフトウェア・コンポーネントの現在の状態，およびこれらのコンポーネントに対して行った変更に関する正確な記録を保存しておかなければなりません。クラスタ・コンポーネントを変更すると，クラスタ全体の動作に大きな影響がある可能性があります。障害が発生した場合は，この記録を調べて，問題の診断に役立てることができます。
構成に関する現在の記録の管理は，日常の操作にとっても，問題が発生したときのトラブルシューティングにとっても必要です。
10.4.1 レコード情報
構成レコードには，少なくとも以下の情報を含まなければなりません。
CLUSTER_CONFIG.COM を初めて実行してサテライトを追加する場合，このプロシージャはブート・サーバの SYS$SPECIFIC:[SYSMGR] ディレクトリに NETNODE_UPDATE.COM ファイルを作成します ( 共通環境クラスタの場合は，このファイル名を SYS$COMMON:[SYSMGR] ディレクトリに変更する必要があります。 第 5.10.2 項 を参照してください )。このファイルは，サテライトを追加または削除するときや， Ethernet または FDDI ハードウェア・アドレスを変更するたびに更新されます。このファイルには，サテライトの重要なすべてのネットワーク構成データが格納されています。
サイトで予測しない状況が発生して，構成データが失われた場合は， NETNODE_UPDATE.COM を使用して復元できます。また，個々のサテライトのデータを取得しなければならない場合も，このファイルを読み込むことができます。ファイルはときどき編集して，古くなったエントリを削除しておく必要があります。
例 10-1 は，サテライト EUROPA と GANYMD がクラスタに追加された後，ファイルの内容がどのようになるかを示しています。
| 例 10-1 NETNODE_UPDATE.COM ファイルの例 |
|---|
$ RUN SYS$SYSTEM:NCP
define node EUROPA address 2.21
define node EUROPA hardware address 08-00-2B-03-51-75
define node EUROPA load assist agent sys$share:niscs_laa.exe
define node EUROPA load assist parameter $1$DJA11:<SYS10.>
define node EUROPA tertiary loader sys$system:tertiary_vmb.exe
define node GANYMD address 2.22
define node GANYMD hardware address 08-00-2B-03-58-14
define node GANYMD load assist agent sys$share:niscs_laa.exe
define node GANYMD load assist parameter $1$DJA11:<SYS11.>
define node GANYMD tertiary loader sys$system:tertiary_vmb.exe
|
関連項目: DECnet-Plus の NCL コマンドについては，DECnet-Plus のマニュアルを参照してください。
| 前へ | 次へ | 目次 | 索引 |