| 前へ | 次へ | 目次 | 索引 |
システム・ロード・テストの目的は，システム資源を同時に要求する複数のターミナル・ユーザをシミュレートすることです。 システム・ロード・テストは，さまざまなコマンド・プロシージャを実行する独立プロセスを複数作成します。この結果は，ファイル UETLOAD00.DAT に出力されます。各プロセスは，ターミナルにログインしたユーザをシミュレートします。つまり，各プロシージャ内のコマンドは，ターミナルからユーザが入力したコマンドと同じタイプのコマンドです。ロード・テストは連続して複数の独立プロセスを作成し，各独立プロセスがそれぞれのコマンド・プロシージャを同時に実行します。つまり，独立プロセスと同じ数のユーザが同時にターミナルからコマンドを入力するのと同じような影響をシステムに与えます。このようにして，ロード・テストは，通常のシステムにおける使用と同じような環境を作り出します。
ロード・テストは，論理名 LOADS を使って，作成する独立プロセスの数を決定します。 UETP コマンド・プロシージャを起動すると，シミュレートするユーザの人数，つまり，作成する独立プロセスの数を尋ねてきます ( 第 19.4.3 項 を参照)。この数は，使用しているシステムのメモリ量，スワップ領域，およびページング領域を考慮して決める必要があります。このときのユーザの応答によって，グループ論理名 LOADS が定義されます。
UETP マスタ・コマンド・プロシージャは，終了フェーズにおいて，テストによって行われたグループ論理名の割り当てを解除します。 UETP パッケージが正常終了しなかった場合のみ，グループ論理名 LOADS の割り当ては解除されません。
作成する独立プロセスの数にもよりますが，ロード・テストによって実行されるコマンド・プロシージャは大量の出力を生成します。各独立プロセス (すなわちユーザ) に対して，テストは UETLOnnnn.LOG と呼ばれる出力ファイルのバージョンを作成します (nnnn は数値文字列)。コンソールには，ロード・テストの進行を表す状態情報だけ表示されます。
ロード・テストが完全な UETP の一部として実行される場合も，独立したフェーズとして実行される場合も， UETP は UETLOnnnn.LOG ファイルを結合し，出力をファイル UETP.LOG に書き込み，最後に，個々の出力ファイルを削除します。
システム・ロード・テストを独立したフェーズとして実行するには，スタートアップ・ダイアログの中から LOAD を選択します ( 第 19.4.1 項 を参照)。
19.8.4 DECnet for OpenVMS テスト・フェーズ
DECnet for OpenVMS ソフトウェアがユーザの OpenVMS システムに組み込まれている場合，完全な UETP の実行によって， DECnet ハードウェアおよびソフトウェアが自動的にテストされます。通信装置は DECnet に割り当てられ， DECnet 装置は UETP 装置テストでテストできないので， DECnet for OpenVMS または他のアプリケーションがその装置を割り当てている場合， UETP はイーサネット・アダプタをテストしません。 DECnet テストの開始時，DECnet ノードおよびサーキット・カウンタはゼロにされ，実行時の障害監視が可能になります。
他の UETP フェーズと同様に， DECnet for OpenVMS フェーズを独立させて実行することもできます。
第 19.4.1 項 を参照してください。
19.8.4.1 環境
DECnet for OpenVMS テストは，DECnet がサポートするすべてのノード・タイプ (ルーティング・ノードおよび非ルーティング・ノードを含む) に接続された OpenVMS システム，および若干異なるタイプのオペレーティング・システム (RSTS，RSX，TOPS，RT など) 上で正常に動作します。遠隔システムには，システム間でファイルをコピーするための省略時のアクセス権が必要です。DECnet フェーズでは，次のテストを行います。
テストがサポートする通信回線の数には制限はありません。ある隣接ノードにおけるテストを，通常の通信転送率で 2 分以上継続してはなりません。
UETP は，ユーザのシステムが FAL オブジェクトに対して省略時のアクセス権を持っていることを想定しています。しかし，ネットワーク構成コマンド・プロシージャ NETCONFIG.COM は，省略時の設定で，FAL オブジェクトに対するアクセス権を提供しません。 NETCONFIG.COM が提供する省略時の設定で DECnet ソフトウェアをインストールする場合，UETP DECnet フェーズでエラー・メッセージが表示されることがあります。このエラー・メッセージは無視してかまいません。詳細は 第 19.7.13 項 を参照してください。 |
UETP (UETPHAS00.EXE の制御下において) は，ファイル UETDNET00.DAT を読み込み， DECnet for OpenVMS フェーズ中に次の手順を行います。
UETININET.TMP ファイルは，テストする装置を決定するために， DECnet フェーズ全体で使用される。
カウンタをゼロにしたくない場合は， DECnet for OpenVMS ソフトウェアをテストしないでください。 |
%UETP-S-BEGIN, UETNETS00 beginning at 22-JUN-2000 13:45:33.18 %UETP-W-TEXT, Circuit DMC-0 to (NODENAME1) OK. %UETP-I-TEXT, Node (NODENAME2) over DMC-1 response timeouts = 1. %UETP-I-TEXT, Circuit DMC-1 to (NODENAME2) local buffer errors = 34. %UETP-I-TEXT, Node (NODENAME3) over DMP-0 response timeouts = 3. %UETP-S-ENDED, UETNETS00 ended at 22-JUN-2000 13:45:36.34 |
カウンタの劣化が必ずしもエラーの原因となるわけではないので，テストが成功したかどうかは，システムではなく，ユーザが判断することである。次のカウンタは劣化を示す。
サーキットの場合
ノードの場合
クラスタ統合テスト・フェーズは，DECnet for OpenVMS ソフトウェアに大きく依存する 1 つのプログラムおよび 1 つのコマンド・ファイルから構成されます。このフェーズは，DECnet for OpenVMS ソフトウェアを使って，クラスタ中の各 OpenVMS ノード上に SYSTEST_CLIG プロセスを作成し，各ノードと通信します。 SYSTEST_CLIG は SYSTEST に類似するアカウントです。しかし，SYSTEST_CLIG はクラスタ統合テストでしか使用されません。クラスタ・テスト・フェーズを正しく実行するには，次の SYSTEST_CLIG アカウントの制限が必要です。
これらの項目は，システムの機密保護およびプライバシーを守るために必要です。SYSTEST_CLIG プロセスが OpenVMS ノード上に作成できない場合は，障害の原因が示され，ファイル・テスト中にはロック・テストおよび共用アクセス用のノードが無視されます。また，このテストでは，SYSTEST_CLIG プロセスが作成されなかったノードからのログ・ファイルのコピーは行われません。SYSTEST_CLIG プロセスの作成後， SYSTEST_CLIG プロセスとの通信に問題が発生した場合，それ以降のロック・テストおよびファイル共用テストでは，このノードは除外されます。クラスタ統合テストの終了時，当該ノードでエラーが発生したかどうかが報告されます。
UETCLIG00.EXE は， 1次スレッドと2次スレッドという，2 つの実行用スレッドを持っています。 1次スレッドは，クラスタ構成 (OpenVMS ノード，HSC ノード，およびテストを実行するノードで使用できる取り付けディスク)をチェックします。選択された OpenVMS ノードの場合，1次スレッドは DECnet ソフトウェアを使って SYSTEST_CLIG プロセスを起動しようとします。1次スレッドが SYSTEST_CLIG プロセスをノード上で起動できた場合，そのノードはコマンド・ファイル UETCLIG00.COM を起動します。このコマンド・ファイルは，UETCLIG00.EXE を起動し，2次実行スレッドを実行します。
1次スレッドを実行しているプロセスは，2次スレッドを実行しているプロセスと通信できるかどうかチェックします。次に，ロックを外し，デッドロック状態が作成されるよう， 2次スレッドに命令します。
1次スレッドは，クラスタ中で選択した OpenVMS および HSC ノード上の同じディスクにファイルを作成しようとします。 1次スレッドはブロックを書き込み，そのブロックを再び読み取り，最後に，そのブロックを確認します。次に，OpenVMS ノードを 1 つランダムに選択し，そのブロックの読み込みと確認を行うよう指示します。次に，1次スレッドは他のブロックを書き込むことによって，ファイルを拡大し，2次ブロックは2 番目のブロックを読み込み，確認します。このファイルは削除されます。
2次プロセスは終了します。2次プロセスは，自身の SYS$ERROR ファイルの内容を1次プロセスにコピーするので， UETP ログ・ファイルおよびコンソール・レポートはすべての問題を 1つの場所に表示することができます。 DECnet for OpenVMS ソフトウェアは，テストの実行時に自動的に SYS$TEST の中に NETSERVER.LOG を作成します。したがって，必要であれば，後でこのノードのファイルを読むことができます。
テストの実行中，1次プロセスはシステム・サービス SYS$BRKTHRU を使って，テストの開始と終了を各 OpenVMS ノードのコンソール・ターミナルに知らせます。
グループ論理名 MODE を文字列 DUMP と同等に定義することによって，ほとんどのイベントの発生を追跡することができます。論理名の定義は，定義されたノード上でしか適用されません。 MODE は， イベントを追跡したいクラスタ中の各ノード上で定義しなければなりません。
本章では，システム・ログ・ファイルの設定と管理，エラー・ログ・ファイルの管理，およびシステム管理ユーティリティを使ったシステムの監視について説明します。
本章では，次の作業を説明します。
| 作業 | 参照箇所 |
|---|---|
| エラー・フォーマッタ (ERRFMT) の使用方法 | 第 20.3 節 |
| エラー・ログ・ユーティリティ (ERROR LOG) を使ったレポート作成方法 | 第 20.4 節 |
| DECevent を使ったシステム・イベント報告方法 | 第 20.5 節 |
| オペレータ・ログ・ファイルの設定，管理，プリント | 第 20.6 節 |
| 機密保護監査機能の使用法 | 第 20.7 節 |
| MONITOR ユーティリティを使用したシステムの性能の監視 | 第 20.8 節 |
さらに，次の項目について説明します。
| 項目 | 参照箇所 |
|---|---|
| システム・ログ・ファイル | 第 20.1 節 |
| エラー・ログ機構 | 第 20.2 節 |
| エラー・ログ・ユーティリティ (ERROR LOG) | 第 20.4.1 項 |
| DECevent イベント管理ユーティリティ | 第 20.5.1 項 |
| オペレータ・ログ・ファイル | 第 20.6.1 項 |
| OPCOM メッセージ | 第 20.6.2 項 |
| 機密保護監査機構 | 第 20.7.1 項 |
| Monitor ユーティリティ | 第 20.8.1 項 |
システム管理を行う場合，システム・イベントに関する情報を収集して検討することが必要になります。 OpenVMS オペレーティング・システムでは，システム資源の使用状況，エラー状態，他のシステム・イベントの情報を記録するログ・ファイルがいくつか提供されます。これらのログ・ファイルについて 表 20-1 で簡単にまとめます。
| ログ・ファイル | 説明 | 参照箇所 |
|---|---|---|
| エラー・ログ・ファイル | このファイルには，装置および CPU に関するエラー・メッセージが自動的に記録される。 | 第 20.2 節 |
| オペレータ・ログ・ファイル | このファイルには，オペレータ通信マネージャ (OPCOM) によって，システム・イベントが記録される。 |
第 2 章 ，
第 20.6 節 |
| 会計情報ファイル | このファイルには，システム資源の使用状況が記録される。 | 第 21 章 |
| 機密保護監査ログ・ファイル | 監査サーバ・プロセスにより，機密保護関係のシステム・イベントが書き込まれる。 | 第 20.7 節 |
エラー・ログ機構は，自動的にエラー・メッセージを最新バージョンのエラー・ログ・ファイル SYS$ERRORLOG:ERRLOG.SYS に書き込みます。 エラー・ログ・レポートは，主に，弊社のサポート担当者がハードウェアの問題箇所を特定するときに使用するものです。また，システム管理者でも，あるシステム障害が頻繁に発生する場合には，それが注意を要するものであるかどうか，エラー・ログ・レポートから判断することができます。
バージョン 7.2 以降の OpenVMS では，エラー・ログ・ファイルの解析に DECevent バージョン 2.9 以降が必要になりました。DECevent バージョン 2.9 は， DECevent キットの中に，独立したユーティリティである Binary Error Log Translation ユーティリティを提供しています。 このユーティリティは，新しい Common Event Header (CEH) バイナリ・エラー・ログ・ファイルを，DECevent の以前のバージョンや古い Error Log ユーティリティからも読み込み可能なヘッダ形式と構造のバイナリ・エラー・ログ・ファイルに変換します。
Binary Error Log Translation ユーティリティの詳細については， OpenVMS キットと共に出荷されている DECevent キットに含まれているマニュアルを参照してください。
エラー・ログ機構は， 表 20-2 に示す 3 つの部分から構成されます。
| 構成要素 | 説明 |
|---|---|
| エグゼクティブ・ルーチン | エラーおよびイベントを検出し，関連する情報をメモリ内のエラー・ログ・バッファに書き込む。 |
| エラー・フォーマッタ (ERRFMT) |
ERRFMT プロセス は，システムのブート時に起動し，定期的にエラー・ログ・バッファを空にするとともに，エラーの記述を標準形式に変形し，書式化した情報をシステム・ディスク上のエラー・ログ・ファイルに格納する ( 第 20.3.2 項 を参照)。
エラー・フォーマッタを使えば， ERRFMT プロセスが回復不可能なエラーに遭遇してプロセス自身を削除する場合に， SYSTEM アカウントや他のユーザにメール送ることができる ( 第 20.3.3 項 を参照)。 |
| エラー・ログ・ユーティリティ (ERROR LOG) | エラー・ログ・ファイルの内容を選択して報告する エラー・ログ・レポート・フォーマッタ (ERF) を呼び出す。 ERROR LOG を呼び出すには，DCL の ANALYZE/ERROR_LOG を入力する ( 第 20.4.2 項 を参照)。 |
| DECevent | イベント・ログ・ファイルの内容を選択して報告する。 DECevent を呼び出すには，DCL の DIAGNOSE コマンドを入力する ( 第 20.5 節 を参照)。バージョン 2.9 以降の DECevent には， Binary Error Log Translation ユーティリティが含まれている。 |
エグゼクティブ・ルーチンとエラー・フォーマッタ (ERRFMT) プロセスは継続的に稼動します。途中，ユーザと対話することはありません。エグゼクティブ・ルーチンは，エラーやイベントを検出すると，そのままの形でメモリ上のエラー・ログ・バッファに格納します。エラー・ログ・バッファの 1 つがいっぱいになるか，または，あらかじめ設定された時間が経過すると，ERRFMT は自動的にエラー・ログ・バッファを SYS$ERRORLOG:ERRLOG.SYS に書き込みます。
しかし，エラーが瞬時に大量に発生し，ERRFMT プロセスがエラー・ログ・バッファを空にする前に，エラー・ログ・バッファがあふれてしまうこともあります。この状態を発見するためには，エラー・ログ・レポートを読んで，レコード番号の途中に抜けた箇所がないかどうか調べます。ERRFMT プロセスがエラー・ログ・バッファ空間を開放すると，ただちに，エラー・ログは再開されます。
| 前へ | 次へ | 目次 | 索引 |