| 前へ | 次へ | 目次 | 索引 |
クラスタ統合テスト・フェーズは，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 プロセスがエラー・ログ・バッファ空間を開放すると，ただちに，エラー・ログは再開されます。
エラーが多すぎてエラー・ログ・ファイルに書き込めなくなると， ERRFMT プロセスは，システム・コンソール・ターミナルにエラー・メッセージを表示し，自分で実行を停止します。 ERRFMT プロセスを再開する方法については，
第 20.3.1 項 を参照してください。
20.3 エラー・ログ・フォーマッタの使用法
エラー・ログ・フォーマッタ(ERRFMT)プロセスは，ブート時に自動的に起動されます。次に各作業の実行方法と参照箇所を示します。
| 作業項目 | 参照箇所 |
|---|---|
| ERRFMT プロセスの再起動 (必要な場合) | 第 20.3.1 項 |
| エラー・ログ・ファイルの管理 | 第 20.3.2 項 |
| ERRFMT プロセスが削除されたときのメールの送信 | 第 20.3.3 項 |
ERRFMT プロセスを再起動するためには，次の手順に従ってください。
$ @SYS$SYSTEM:STARTUP ERRFMT |
システム・ディスク上でディスク・クォータが使用可能になっている状態で， UIC [1,4] が十分なクォータを持っている場合にのみ，ERRFMT は起動されます。 |
エラー・ログ・ファイル SYS$ERRORLOG:ERRLOG.SYS は共用ファイルのため， ANALYZE/ERROR_LOG ユーティリティがそのファイルの既存のエラー・ログ・エントリを読み込んだり抽出したりしている間にも，ERRFMT プロセスは新しいエントリを書き込みます。
ERRLOG.SYS は，システム管理者が明示的にリネームするか削除するまで大きくなっていきます。したがって，エラー・ログ・ファイルは定期的に整理する必要があります。 1 つの方法として，1 日 1 回 ERRLOG.SYS をリネームします。そうすると，新しいエラー・ログ・ファイルが自動的に作成されます。たとえば，毎朝 9 時に ERRLOG.SYS を ERROLOG.OLD にリネームします。リネームした古いエラー・ログ・ファイルは別のボリュームに移すか，システム・ディスクから削除すれば，システム・ディスクの空間が解放されます。
また，論理名 SYS$ERRORLOG をエラー・ログ・ファイルを格納したい装置とディレクトリに定義することにより，システム・ディスク以外のディスク上にエラー・ログ・ファイルを格納する方法もあります。次に例を示します。
$ DEFINE/SYSTEM/EXECUTIVE SYS$ERRORLOG DUA2:[ERRORLOG] |
システムを起動するたびにこの論理名を定義する場合は，論理名定義を SYLOGICALS.COM プロシージャに追加します。詳細は 第 5.2.5 項 を参照してください。
このとき，誤って使用中のエラー・ログ・ファイルを削除しないように注意してください。また，リネームするときに，ファイル名の先頭あるいは最後に日付を付けて整理する方法もあります。
20.3.3 ERRFMT によるメールの送信
エラー・フォーマッタ (ERRFMT) を使用すれば， ERRFMT プロセスが回復不可能なエラーを検出し，プロセス自身を削除するときに，システム管理者や他の指定したユーザにメールを送ることができます。
2 つのシステム論理名 ERRFMT$_SEND_MAIL および ERRFMT$_SEND_TO が，この機能を制御します。
上記の論理名を定義するには，次のいずれかを行います。
20.3.3.1 メールを送信するための ERRFMT の停止と再起動
ERRFMT$_SEND_MAIL が TRUE と定義されている場合，ユーザは， ERRFMT がプロセス自身を削除するという表題のメール・メッセージを受信します。オペレータ・ログ・ファイルおよびシステム・コンソール OPA0: には，発生した障害についての詳細な情報，および ERRFMT を再起動するための指示が出力されます。しかし，ユーザはコンソールにいないこともあるので，この情報を見ないかもしれません。
たとえば，メールの送信が可能なモードで ERRFMT を使用している場合，メールの送信を禁止にするには，システム管理者のアカウントを使って， SYS$STARTUP:SYLOGICAL.COM を編集し，次のコマンドを追加します。
$ DEFINE/SYSTEM ERRFMT$_SEND_MAIL FALSE |
もう一度，メールの送信を可能にするには，システム管理者のアカウントを使って， SYS$STARTUP:SYLOGICAL.COM を編集し，次のコマンドを追加します。
$ DEFINE/SYSTEM ERRFMT$_SEND_MAIL TRUE |
| 前へ | 次へ | 目次 | 索引 |