| 前へ | 次へ | 目次 | 索引 |
サテライトをクラスタに追加した状態では， OPCOM (Operator Communication Manager) は以下のデフォルト設定になっています。
表 10-3 は，コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COM で以下のシステム論理名を定義して，OPCOM のデフォルト設定を変更する方法を示しています。
| システム論理名 | 機能 |
|---|---|
| OPC$OPA0_ENABLE | TRUE に定義されている場合は，OPA0: はオペレータ・コンソールとして有効になる。FALSE に定義されている場合は，OPA0: はオペレータ・コンソールとして有効に設定されない。DCL は T または Y から始まる文字列，および奇数の整数を TRUE であると解釈し，他のすべての値を FALSE であると解釈する。 |
| OPC$OPA0_CLASSES | OPA0: で有効に設定されるオペレータ・クラスを定義する。論理名は，許可されているクラスの検索リスト，クラスのリスト，またはその組み合わせのいずれでもかまわない。以下の例を参照。
$ DEFINE/SYSTEM OP$OPA0_CLASSES CENTRAL,DISKS,TAPE OPC$OPA0_ENABLE が定義されていない場合でも， OPC$OPA0_CLASSES を定義できる。この場合，クラスは，有効に設定されているどのオペレータ・コンソールに対しても使用されるが，オペレータ・コンソールを有効に設定するかどうかは，デフォルトを使用して判断される。 |
| OPC$LOGFILE_ENABLE | TRUE に定義されている場合は，オペレータ・ログ・ファイルがオープンされる。FALSE に定義されている場合は，ログ・ファイルはオープンされない。 |
| OPC$LOGFILE_CLASSES | ログ・ファイルに対して有効に設定されるオペレータ・クラスを定義する。論理名は，許可されているクラスの検索リスト，カンマで区切ったリスト，その 2 つの組み合わせのいずれでもかまわない。OPC$LOGFILE_ENABLE システム論理名が定義されていない場合でも，このシステム論理名を定義できる。その場合，クラスは，オープンされているどのログ・ファイルに対しても使用されるが，ログ・ファイルをオープンするかどうかは，デフォルトを使用して判断される。 |
| OPC$LOGFILE_NAME | ログ・ファイルの名前を定義するために，デフォルト名 SYS$MANAGER:OPERATOR.LOG と組み合わせて使用される情報を指定する。ログ・ファイルがシステム・ディスク以外のディスクに書き込まれる場合は，ディスクをマウントするコマンドを SYLOGICALS.COM コマンド・プロシージャに指定しなければならない。 |
以下の例では，OPC$OPA0_CLASSES システム論理名を使用して，有効に設定するオペレータ・クラスを定義する方法を示しています。以下のコマンドを使用すると，SECURITY クラス・メッセージは OPA0 に表示されなくなります。
$ DEFINE/SYSTEM OPC$OPA0_CLASSES CENTRAL,PRINTER,TAPES,DISKS,DEVICES, - _$ CARDS,NETWORK,CLUSTER,LICENSE,OPER1,OPER2,OPER3,OPER4,OPER5, - _$ OPER6,OPER7,OPER8,OPER9,OPER10,OPER11,OPER12 |
大規模なクラスタでは，状態遷移 (コンピュータがクラスタに追加されたり，クラスタから削除される状態) で，ブート・サーバのコンソール・デバイスに多くの複数行の OPCOM メッセージが生成されます。 DCL コマンド REPLY/DISABLE=CLUSTER を適切なサイト固有のスタートアップ・コマンド・ファイルに指定するか，またはシステム管理者のアカウントから会話方式でコマンドを入力することにより，このようなメッセージが表示されないようにすることができます。
10.7 クラスタのシャットダウン
デフォルト・シャットダウン・オプションである NONE の他に， OpenVMS Alpha および OpenVMS VAX オペレーティング・システムでは， OpenVMS Cluster のコンピュータをシャットダウンするために，以下のオプションが用意されています。
さらに，"Shutdown options [NONE]:" プロンプトに対する応答として， DISABLE_AUTOSTART=n オプションを指定できます。ただし，n は，シャットダウン・シーケンスで自動起動キューが無効に設定されるまでの分数です。
関連項目: 詳細については， 第 7.13 節 を参照してください。
これらのオプションをどれも選択しないと (つまり，デフォルトの SHUTDOWN オプションである NONE を選択すると)，シャットダウン・プロシージャはスタンドアロン・コンピュータをシャットダウンする場合の通常の操作を実行します。間もなくクラスタに再び追加する予定のあるコンピュータをシャットダウンする場合は，デフォルト・オプション NONE を指定できます。その場合，そのコンピュータがクラスタに間もなく再追加されるものと，オペレーティング・システムが判断するため，クラスタ・クォーラムは調整されません。
10.7.1 コンピュータの削除
長時間にわたってクラスタに再び追加される予定のないコンピュータをシャットダウンする場合は， REMOVE_NODE オプションを使用します。たとえば，コンピュータに必要な新しいハードウェアが納入されるのを待っている場合や，コンピュータを当面スタンドアロン操作用に使用する場合などがあります。
REMOVE_NODE オプションを使用する場合は，削除されるコンピュータのボーツがクォーラム値に加算されないことを反映するために，クラスタの残りの部分のアクティブ・クォーラムが現在の値より小さい値に調整されます。シャットダウン・プロシージャは， SET CLUSTER/EXPECTED_VOTES コマンドを実行することにより，クォーラムを再調整します。その場合， 第 10.12 節 で説明する通常の制約が適用されます。
注意: システム管理者は，新しい構成を反映するように， OpenVMS Cluster の他のコンピュータで EXPECTED_VOTES システム・パラメータを変更しなければなりません。
10.7.2 クラスタのシャットダウン
CLUSTER_SHUTDOWN オプションを選択すると，コンピュータが通常のシャットダウンでクラスタから削除される時点まで，すべてのシャットダウン操作が実行されます。クラスタから削除される時点に到達すると，クラスタ内の他のすべてのノードが同じ時点に到達するまで，コンピュータは待機状態になります。すべてのノードがシャットダウン操作を完了すると，同期のとれた 1 つの操作でクラスタ全体が消去されます。この方式では，個々のノードが独立してシャットダウンを完了するわけではなく，状態遷移を起動したり，クォーラムなしでクラスタから削除される可能性がないという利点があります。
CLUSTER_SHUTDOWN を実行する場合は， OpenVMS Cluster のすべてのコンピュータでこのオプションを指定しなければなりません。いずれかのコンピュータが含まれていないと，クラスタ単位のシャットダウンは実行できません。
10.7.3 リブート
REBOOT_CHECK オプションを選択すると，シャットダウン・プロシージャは，コンピュータを正しくリブートするのに必要な基本システム・ファイルが存在するかどうか確認し，不足するファイルがある場合は，そのことを通知します。このようなファイルは，処理を続行する前に復元しなければなりません。すべてのファイルが存在する場合は，以下の情報メッセージが表示されます。
%SHUTDOWN-I-CHECKOK, Basic reboot consistency check completed. |
注意:
REBOOT_CHECK オプションは単独で使用することができ， REMOVE_NODE または CLUSTER_SHUTDOWN オプションと組み合わせて使用することもできます。REBOOT_CHECK を他のオプションのいずれかと組み合わせて選択する場合は，カンマで区切ったリストとしてオプションを指定しなければなりません。
10.7.4 AUTOGEN フィードバックの保存
AUTOGEN フィードバック操作を有効に設定するには， SAVE_FEEDBACK オプションを使用します。
注意: このオプションは，典型的な作業負荷を反映できるだけの十分長い時間，コンピュータが実行された場合にだけ選択します。
関連項目: AUTOGEN フィードバックの詳細については，『Compaq OpenVMS システム管理者マニュアル』を参照してください。
10.8 ダンプ・ファイル
OpenVMS Cluster システムで 1 つの共通システム・ディスクを使用する場合も，複数のシステム・ディスクを使用する場合も，ダンプ・ファイルを管理する方法を計画しなければなりません。
10.8.1 サイズと作成の制御
1 つのシステム・ディスクを使用する大規模なクラスタの場合，ダンプ・ファイルの管理が特に重要です。たとえば，256 MB の OpenVMS Alpha コンピュータでは，AUTOGEN が 500,000 ブロック以上のダンプ・ファイルを作成します。
ソフトウェアで検出されるシステム障害が発生すると，各コンピュータは分析のためにシステム・ディスクのフル・ダンプ・ファイルにメモリの内容を書き込みます。デフォルト設定では，このフル・ダンプ・ファイルは物理メモリのサイズに数ページを加算したサイズです。システム・ディスク領域が制限されている場合 (大規模なクラスタに対して 1 つのシステム・ディスクだけを使用する場合は，おそらくこのケースです)，サテライトに対してダンプ・ファイルを作成しないこと，または AUTOGEN が選択型ダンプ・ファイルを作成することを指定しなければならない可能性があります。選択型ダンプ・ファイルは通常，フル・ダンプ・ファイルのサイズの 30〜60% です。
各コンピュータに対して，ダンプ・ファイルのサイズと，ダンプ・ファイルを作成するかどうかを制御できます。この 2 つを制御するには，AUTOGEN シンボル DUMPSTYLE と DUMPFILE に対して適切な値を，コンピュータの MODPARAMS.DAT ファイルに指定します。 表 10-4 を参照して，ダンプ・ファイルを指定します。
| 指定する値 | 結果 |
|---|---|
| DUMPSTYLE = 0 | フル・ダンプ・ファイルが作成される (デフォルト)。 |
| DUMPSTYLE = 1 | 選択型ダンプ・ファイルが作成される。 |
| DUMPFILE = 0 | ダンプ・ファイルは作成されない。 |
警告: ダンプ・ファイルなしでコンピュータを構成することもできますが，ダンプ・ファイルがないと，システム障害の原因を判断するのが困難になったり，不可能になる可能性があります。
たとえば，メモリの大きなシステムでシステム・ダンプ・ファイルのサイズを変更するには，以下のコマンドを使用します。
$ MCR SYSGEN SYSGEN> USE CURRENT SYSGEN> SET DUMPSTYLE 1 SYSGEN> CREATE SYS$SYSTEM:SYSDUMP.DMP/SIZE=70000 SYSGEN> WRITE CURRENT SYSGEN> EXIT $ @SHUTDOWN |
70,000 ブロックのダンプ・ファイル・サイズは，約 32 MB のメモリに対応できるだけの十分なサイズです。このサイズは通常，システム障害を分析するのに必要な情報を格納できるだけの十分な大きさです。
システムをリブートした後，SYSDUMP.DMP は消去してもかまいません。
10.8.2 ダンプ・ファイルの共用
ダンプ・ファイルの領域を節約するためのもう 1 つの方法として，複数のコンピュータ間で 1 つのダンプ・ファイルを共用する方法があります。この方法では，切り分けられたコンピュータ障害を分析することができます。しかし，複数のコンピュータで同時に障害が発生したり，最初の障害を分析する前に，2 台目のコンピュータで障害が発生した場合，ダンプは失われます。ブート・サーバの障害は，他のコンピュータの障害より，クラスタ操作に大きな影響を与えるため，問題をスピーディに分析することができるように，ブート・サーバではフル・ダンプ・ファイルを構成しなければなりません。
VAX システムで Alpha コンピュータとダンプ・ファイルを共用することはできず，その逆も同様です。しかし，1 つのダンプ・ファイルを複数の Alpha コンピュータで共用し，別のダンプ・ファイルを VAX コンピュータで共用することは可能です。各オペレーティング・システムに対して，以下の操作を行います。
| ステップ | 操作 |
|---|---|
| 1 | フル・ダンプ・ファイルを使用するのか，選択型ダンプ・ファイルを使用するのかを判断する。 |
| 2 | サテライトで必要とされる最大ダンプ・ファイルのサイズを判断する。 |
| 3 | クラスタ内でメモリ構成が最大のサテライトを選択し，以下の操作を実行する。
|
| 4 | ダンプ・ファイルの名前を SYS$COMMON:[SYSEXE]SYSDUMP-COMMON.DMP に変更するか，または SYSDUMP-COMMON.DMP という新しいダンプ・ファイルを SYS$COMMON:[SYSEXE]に作成する。 |
| 5 | ダンプ・ファイルを共用する各サテライトに対して，以下の操作を実行する。
|
| 6 | ダンプ・ファイルを所有している各システムで，元のシステム固有のダンプ・ファイルの名前を変更する。
$ RENAME SYS$SYSDEVICE:[SYSn.SYSEXE]SYSDUMP.DMP .OLD コマンド・ラインの n の値は，各システムのルートである (たとえば SYS0 や SYS1)。システムがリブートされるときに，オペレーティング・システム・ソフトウェアがそのファイルをダンプ・ファイルとして使用しないように，ファイル名を変更する。 |
| 7 | 各ノードをリブートして，新しい共通ダンプ・ファイルにマッピングできるようにする。オペレーティング・システム・ソフトウェアは，システムがリブートされるまで，クラッシュ・ダンプのために新しいファイルを使用することができない。 |
| 8 | リブートした後，各システム固有のルートから SYSDUMP.OLD ファイルを削除する。SYSDUMP.DMP というファイルを削除してはならない。このファイルの名前を変更し，リブートした後，ステップ 6 とステップ 7 の説明に従ってファイルを削除する。 |
10.9 OpenVMS Cluster メンバーシップの整合性の管理
複数の LAN クラスタおよび複合インターコネクト・クラスタが 1 つの拡張 LAN に共存するため，オペレーティング・システムでは個々のクラスタの整合性を確保し，登録されていないコンピュータがクラスタにアクセスするのを防止するような機能を提供しています。
以下の機能は，クラスタの整合性を確保できるように設計されています。
クラスタ・グループ番号とパスワードの目的は，登録されていないコンピュータがクラスタに誤ってアクセスするのを防止することです。通常の状況では，システム管理者はインストール時，または CLUSTER_CONFIG.COM を実行して ( 例 8-11 を参照)， OpenVMS Cluster システム内で動作するようにスタンドアロン・コンピュータを変換するときに，クラスタ・グループ番号とパスワードを指定します。
OpenVMS Cluster システムでは，これらの機能を使用して，クラスタの整合性を保護し，以下のような状況で発生する可能性のある問題を防止しています。
関連項目: これらの機能の詳細については， 第 10.9.1 項 と 第 8.2.1 項 を参照してください。
| 前へ | 次へ | 目次 | 索引 |