| 前へ | 次へ | 目次 | 索引 |
クロスアーキテクチャ・サテライト・ブートを利用すると， VAX ブート・ノードは Alpha サテライトにブート・サービスを提供でき， Alpha ブート・ノードは VAX サテライトにブート・サービスを提供できます。一部の OpenVMS Cluster 構成では，クロスアーキテクチャ・ブートのサポートにより，日常のシステム操作が単純化され，VAX システムと Alpha システムの両方を含む OpenVMS Cluster の管理の複雑さを軽減することができます。
注意: クロスアーキテクチャ・ブートのサポートが技術的に可能な限り，弊社は今後もこのサポートを提供します。しかし，OpenVMS オペレーティング・システムの将来のリリースでは，このサポートは削除される可能性があります。
10.5.1 構成例
この後の構成例では，Alpha と VAX のブート・ノードとサテライト・ノードを含む OpenVMS Cluster を構成する方法を示しています。各アーキテクチャには，インストールとアップグレードで使用されるシステム・ディスクがそれぞれ必要です。
警告: OpenVMS オペレーティング・システムとレイヤード製品のインストールおよびアップグレードは，異なるアーキテクチャ間で行うことができません。たとえば，OpenVMS Alpha ソフトウェアのインストールとアップグレードは， Alpha システムを使用して実行しなければなりません。クロスアーキテクチャ・ブート機能を使用する OpenVMS Cluster システムを構成する場合，インストールとアップグレードで使用できるディスクを装備したシステムを各アーキテクチャで少なくとも 1 台構成してください。 図 10-1 と 図 10-2 に示した構成では，ワークステーションが 1 台ずつ，この目的でローカル・ディスクを使用するように構成されています。
図 10-1 では，DSSI インターコネクトを使用する 2 台の VAX ブート・ノードと複数の VAX ワークステーションを含む既存の VAXcluster 構成に，複数の Alpha ワークステーションが追加されています。高い可用性を実現するために， Alpha システム・ディスクは複数のブート・サーバからアクセスできるように DSSI 上にあります。
図 10-1 VAX ノードによる Alpha サテライトのブート
図 10-2 の構成には，もともと 1 台の VAX ブート・ノードと複数の VAX ワークステーションが含まれていました。その後，VAX ブート・ノードがパフォーマンスの高い新しい Alpha ブート・ノードに変更されました。また，数台の Alpha ワークステーションも追加されました。もともと含まれていた VAX ワークステーションはそのまま構成に残されており，ブート・サービスを必要としています。新しい Alpha ブート・ノードはこのサービスを実行できます。
図 10-2 Alpha ノードと VAX ノードによる Alpha サテライトと VAX サテライトのブート
クロスアーキテクチャ・ブート機能を使用する場合は，以下のガイドラインに従ってください。
以下の例では，クロスアーキテクチャ・ブートを実行するように DECnet データベースを構成する方法を示しています。この機能は， DECnet for OpenVMS (フェーズ IV) を実行するシステムに対してだけ提供されます。
以下の説明に従って， 例 10-2 と 例 10-3 のコマンド・プロシージャをカスタマイズします。
| 変更前 | 変更後 |
|---|---|
| alpha_system_disk または vax_system_disk | サーバの適切なディスク名 |
| label | サーバのディスクの適切なラベル名 |
| ccc-n | サーバ・サーキット名 |
| alpha または vax | サテライトの DECnet ノード名 |
| xx.yyyy | サテライトの DECnet area.address |
| aa-bb-cc-dd-ee-ff | サテライトのロードで使用されるサテライト上の LAN アダプタのハードウェア・アドレス |
| satellite_root | サテライトのシステム・ディスクのルート (たとえば SYS10) |
例 10-2 は，ローカルにマウントされている Alpha システム・ディスクをサービスするように VAX システムを設定する方法を示しています。
| 例 10-2 VAX ブート・ノードでの Alpha サテライトの定義 |
|---|
$! VAX system to load Alpha satellite $! $! On the VAX system: $! ----------------- $! $! Mount the system disk for MOP server access. $! $ MOUNT /SYSTEM alpha_system_disk: label ALPHA$SYSD $! $! Enable MOP service for this server. $! $ MCR NCP NCP> DEFINE CIRCUIT ccc-n SERVICE ENABLED STATE ON NCP> SET CIRCUIT ccc-n STATE OFF NCP> SET CIRCUIT ccc-n ALL NCP> EXIT $! $! Configure MOP service for the ALPHA satellite. $! $ MCR NCP NCP> DEFINE NODE alpha ADDRESS xx.yyyy NCP> DEFINE NODE alpha HARDWARE ADDRESS aa-bb-cc-dd-ee-ff NCP> DEFINE NODE alpha LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE NCP> DEFINE NODE alpha LOAD ASSIST PARAMETER ALPHA$SYSD:[satellite_root.] NCP> DEFINE NODE alpha LOAD FILE APB.EXE NCP> SET NODE alpha ALL NCP> EXIT |
例 10-3 は，ローカルにマウントされている VAX システム・ディスクをサービスするように， Alpha システムを設定する方法を示しています。
| 例 10-3 Alpha ブート・ノードでの VAX サテライトの定義 |
|---|
$! Alpha system to load VAX satellite $! $! On the Alpha system: $! -------------------- $! $! Mount the system disk for MOP server access. $! $ MOUNT /SYSTEM vax_system_disk: label VAX$SYSD $! $! Enable MOP service for this server. $! $ MCR NCP NCP> DEFINE CIRCUIT ccc-n SERVICE ENABLED STATE ON NCP> SET CIRCUIT ccc-n STATE OFF NCP> SET CIRCUIT ccc-n ALL NCP> EXIT $! $! Configure MOP service for the VAX satellite. $! $ MCR NCP NCP> DEFINE NODE vax ADDRESS xx.yyyy NCP> DEFINE NODE vax HARDWARE ADDRESS aa-bb-cc-dd-ee-ff NCP> DEFINE NODE vax TERTIARY LOADER SYS$SYSTEM:TERTIARY_VMB.EXE NCP> DEFINE NODE vax LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE NCP> DEFINE NODE vax LOAD ASSIST PARAMETER VAX$SYSD:[satellite_root.] NCP> SET NODE vax ALL NCP> EXIT |
その後，サテライトをブートするには，以下の操作を行います。
サテライトをクラスタに追加した状態では， 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 クラスタのシャットダウン
SYSMAN ユーティリティの SHUTDOWN コマンドには， OpenVMS Cluster のコンピュータをシャットダウンするために， 5 つのオプションが用意されています。
これらのオプションについて，以下で説明します。
10.7.1 NONE オプション
デフォルトの SHUTDOWN オプションである NONE を選択すると，シャットダウン・プロシージャはスタンドアロン・コンピュータをシャットダウンする場合の通常の操作を実行します。間もなくクラスタに再び追加する予定のあるコンピュータをシャットダウンする場合は，デフォルト・オプション NONE を指定できます。その場合，そのコンピュータがクラスタに間もなく再追加されるものと，オペレーティング・システムが判断するため，クラスタ・クォーラムは調整されません。
"Shutdown options [NONE]:" プロンプトに対する応答として， DISABLE_AUTOSTART=n オプションを指定できます。ただし，n は，シャットダウン・シーケンスで自動起動キューが無効に設定されるまでの分数です。詳細については， 第 7.13 節 を参照してください。
10.7.2 REMOVE_NODE オプション
長時間にわたってクラスタに再び追加される予定のないコンピュータをシャットダウンする場合は， REMOVE_NODE オプションを使用します。たとえば，コンピュータに必要な新しいハードウェアが納入されるのを待っている場合や，コンピュータを当面スタンドアロン操作用に使用する場合などがあります。
REMOVE_NODE オプションを使用する場合は，削除されるコンピュータのボーツがクォーラム値に加算されないことを反映するために，クラスタの残りの部分のアクティブ・クォーラムが現在の値より小さい値に調整されます。シャットダウン・プロシージャは， SET CLUSTER/EXPECTED_VOTES コマンドを実行することにより，クォーラムを再調整します。その場合， 第 10.12 節 で説明する通常の制約が適用されます。
注意: システム管理者は，新しい構成を反映するように， OpenVMS Cluster の他のコンピュータで EXPECTED_VOTES システム・パラメータを変更しなければなりません。
10.7.3 CLUSTER_SHUTDOWN オプション
CLUSTER_SHUTDOWN オプションを選択すると，コンピュータが通常のシャットダウンでクラスタから削除される時点まで，すべてのシャットダウン操作が実行されます。クラスタから削除される時点に到達すると，クラスタ内の他のすべてのノードが同じ時点に到達するまで，コンピュータは待機状態になります。すべてのノードがシャットダウン操作を完了すると，同期のとれた 1 つの操作でクラスタ全体が消去されます。この方式では，個々のノードが独立してシャットダウンを完了するわけではなく，状態遷移を起動したり，クォーラムなしでクラスタから削除される可能性がないという利点があります。
CLUSTER_SHUTDOWN を実行する場合は， OpenVMS Cluster のすべてのコンピュータでこのオプションを指定しなければなりません。いずれかのコンピュータが含まれていないと，クラスタ単位のシャットダウンは実行できません。
10.7.4 REBOOT_CHECK オプション
REBOOT_CHECK オプションを選択すると，シャットダウン・プロシージャは，コンピュータを正しくリブートするのに必要な基本システム・ファイルが存在するかどうか確認し，不足するファイルがある場合は，そのことを通知します。このようなファイルは，処理を続行する前に復元しなければなりません。すべてのファイルが存在する場合は，以下の情報メッセージが表示されます。
%SHUTDOWN-I-CHECKOK, Basic reboot consistency check completed. |
注意: REBOOT_CHECK オプションは単独で使用することができ， REMOVE_NODE または CLUSTER_SHUTDOWN オプションと組み合わせて使用することもできます。REBOOT_CHECK を他のオプションのいずれかと組み合わせて選択する場合は，カンマで区切ったリストとしてオプションを指定しなければなりません。
| 前へ | 次へ | 目次 | 索引 |