library home hp.com home products and services support and drivers solutions
cd-rom home
End of Jump to page title
HP OpenVMS Systems
Documentation

Jump to content


OpenVMS

OpenVMS
OpenVMS Cluster システム


前へ 次へ 目次 索引


9.4.3 複数の LAN アダプタからのブート (Alpha のみ)

Alpha システムでは,ブートのために複数の LAN アダプタを使用することで,可用性を向上できます。これは,MOP サーバおよびディスク・サーバへのアクセスが異なる LAN アダプタを介して可能になるからです。複数のアダプタ・ブートを使用するには,以下の表に示す操作を実行します。

ステップ 操作
  1 追加 LAN アダプタの物理アドレスを取得する。
  2 これらのアドレスを使用して,一部の MOP サーバの DECnet または LANCP データベースに格納されているノード定義を更新して,サテライトが認識されるようにする ( 第 9.4.4 項 を参照)。
  3 サテライトが DECnet データベースにすでに定義されている場合は,ステップ 4 を実行する必要がない。サテライトが DECnet データベースに定義されていない場合は, Alpha ネットワーク・データベースに SYS$SYSTEM:APB.EXE ダウンライン・ロード・ファイルを指定する ( 例 10-2 を参照)。
  4 ブート・コマンド・ラインに複数の LAN アダプタを指定する (アダプタの名前を取得するには,SHOW DEVICE または SHOW CONFIG コンソール・コマンドを使用する)。

以下のコマンド・ラインは,Alpha システムで 1 つの LAN アダプタからブートする場合に使用するコマンドと同じですが ( 第 9.4.2 項 を参照),ブート・デバイスとして, eza0 と ezb0 の 2 つの LAN アダプタが指定されている点が異なります。


>>> b -flags 0,1 eza0, ezb0

このコマンド・ラインでは,以下の処理が実行されます。

ステージ 実行される処理
  1 MOP ブートが最初のデバイス (eza0) から行われる。ブートできない場合は,MOP ブートが次のデバイス (ezb0) から行われる。ネットワーク・デバイスからブートするときに,どのデバイスからも MOP ブートを行うことができない場合は,コンソールは最初のデバイスからもう一度開始する。
  2 MOP ロードが完了すると,ブート・ドライバはすべての LAN アダプタで NISCA プロトコルを起動する。NISCA プロトコルは,システム・ディスク・サーバにアクセスして,オペレーティング・システムのロードを完了するために使用される ( 付録 F を参照)。

9.4.4 代替 LAN アダプタを使用してブートするためのサテライトの有効化

OpenVMS では,DECnet または LANCP データベースで 1 つのリモート・ノード・テーブルに対して,ハードウェア・アドレス属性が 1 つだけサポートされます。複数の LAN アダプタが接続されているサテライトでクラスタにブートするときに,どの LAN アダプタも使用できるようにするには,以下の 2 種類の方法のいずれかを使用できます。

追加 LAN アダプタに対する擬似ノードの定義

異なる DECnet アドレスまたは LANCP アドレスを使用して,擬似ノードを定義する場合は,以下の操作を行います。

DECnet の場合は, 表 9-4 に示す手順に従います。LANCP の場合は, 表 9-5 に示す手順に従います。

表 9-4 DECnet MOP サービスを使用して擬似ノードを定義する手順
ステップ 手順 説明
  1 以下の NCP コマンドを使用して,ノードの既存の定義を表示する。
$ RUN SYS$SYSTEM:NCP

NCP> SHOW NODE node-name CHARACTERISTICS
このコマンドは,ハードウェア・アドレス,ロード・アシスト・エージェント,ロード・アシスト・パラメータなど,サテライトの属性の一覧を表示する。
  2 以下に示すように,NCP コマンド・プロンプトに対して,固有の DECnet アドレスとノード名を定義することにより,擬似ノードを作成する。
++DEFINE NODE
pseudo-area.pseudo-number -

NAME pseudo-node-name -
LOAD FILE APB.EXE -
LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE -
LOAD ASSIST PARAMETER disk$sys:[< root.>] -
HARDWARE ADDRESS xx-xx-xx-xx-xx-xx
この例は Alpha ノード固有の例である。VAX ノードの場合は, LOAD FILE APB.EXE コマンドを TERTIARY LOADER SYS$SYSTEM:TERTIARY_VMB.EXE に変更する。


++Alpha 固有

表 9-5 LANCP MOP サービスを使用して擬似ノードを定義する手順
ステップ 手順 説明
  1 以下の LANCP コマンドを使用して,ノードの既存の定義を表示する。
$ RUN SYS$SYSTEM:LANCP

LANCP> SHOW NODE node-name
このコマンドは,ハードウェア・アドレスやルート・ディレクトリ・アドレスなど,サテライトの属性の一覧を表示する。
  2 以下に示すように,LANCP コマンド・プロンプトに対して,固有の LANCP アドレスとノード名を定義することにより,擬似ノードを作成する。
++DEFINE NODE
pseudo-node-name -

/FILE= APB.EXE -
/ROOT= disk$sys:[< root.>] -
/ADDRESS= xx-xx-xx-xx-xx-xx
この例は Alpha ノード固有の例である。VAX ノードの場合は,修飾子 FILE=APB.EXE を FILE=NISCS_LOAD.EXE に変更する。


++Alpha 固有

異なるブート・ノードに対する異なるノード・データベースの作成

異なるブート・ノードに対して異なる DECnet または LANCP データベースを作成する場合は,以下の操作を行います。

手順は DECnet の場合も LANCP の場合も類似していますが,データベース・ファイル名,ユーティリティ,コマンドは異なります。 DECnet プロシージャの場合は, 表 9-6 を参照してください。LANCP プロシージャの場合は, 表 9-7 を参照してください。

表 9-6 異なる DECnet ノード・データベースを作成する手順
ステップ 手順 説明
  1 異なるファイルを参照するように,異なるノードで論理名 NETNODE_REMOTE を異なる値に定義する。 論理名 NETNODE_REMOTE は,作成しているリモート・ノード・ファイルのワーキング・コピーを指す。
  2 各ノードのシステム固有の領域に NETNODE_REMOTE.DAT ファイルを格納する。

各ブート・サーバで,サテライトのアダプタのいずれかと一致する固有のアドレスとしてハードウェア・アドレスが定義されていることを確認する。NCP コマンド・プロンプトに対して,以下のコマンドを入力する。

++DEFINE NODE
area.number -

NAME node-name -
LOAD FILE APB.EXE -
LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE -
LOAD ASSIST PARAMETER disk$sys:[< root.>] -
HARDWARE ADDRESS xx-xx-xx-xx-xx-xx
システム・ルート 0 からのシステム・ブートの場合, [SYS0.SYSEXE] に格納されている NETNODE_REMOTE.DAT ファイルは [SYS0.SYSCOMMON.SYSEXE] に格納されているファイルより優先する。

NETNODE_REMOTE.DAT ファイルが相互のコピーである場合は,ノード名,3 次ローダ (VAX の場合) または LOAD FILE (Alpha の場合),ロード・アシスト・エージェント,ロード・アシスト・パラメータはすでに設定されている。新しいハードウェア・アドレスだけを指定しなければならない。

デフォルト・ハードウェア・アドレスは NETUPDATE.COM に格納されるため,2 番目のブート・サーバでこのファイルを編集しなければならない。


++Alpha 固有

表 9-7 異なる LANCP ノード・データベースを作成する手順
ステップ 手順 説明
  1 異なるファイルを参照するように,論理名 LAN$NODE_DATABASE を異なるノードで異なる値に定義する。 論理名 LAN$NODE_DATABASE は,作成しているリモート・ノード・ファイルのワーキング・コピーを指す。
  2 各ノードのシステム固有の領域に LAN$NODE_DATABASE.DAT ファイルを格納する。

各ブート・サーバで,サテライトのアダプタの 1 つと一致する固有のアドレスとしてハードウェア・アドレスが定義されていることを確認する。LANCP コマンド・プロンプトに対して,以下のコマンドを入力する。

++DEFINE NODE
node-name -

/FILE= APB.EXE -
/ROOT= disk$sys:[< root.>] -
/ADDRESS= xx-xx-xx-xx-xx-xx
LAN$NODE_DATABASE.DAT ファイルが相互のコピーである場合は,ノード名と FILE 修飾子および ROOT 修飾子の値はすでに設定されている。新しいアドレスだけを指定すればよい。


++Alpha 固有

サテライトが MOP サーバから MOP ダウンライン・ロードを受信すると,サテライトはブートしている LAN アダプタを使用して,システム・ディスクをサービスしているどのノードにも接続できます。実行時ドライバのロードが完了するまで,サテライトはブート・コマンド・ラインに指定された LAN アダプタを独占的に使用します。その後,サテライトは実行時ドライバを使用するように変更され,すべての LAN アダプタでローカル・エリア OpenVMS Cluster プロトコルを起動します。

NCP コマンドの構文の詳細については,『DECnet for OpenVMS Network Management Utilities』を参照してください。

DECnet-Plus の場合: DECnet-Plus を実行している OpenVMS Cluster では,複数の LAN アダプタを使用するサテライトをサポートするために,同じ操作を実行する必要はありません。サテライトをダウンライン・ロードするための DECnet-Plus のサポートでは,LAN アダプタ・アドレスの一覧を指定したエントリをデータベースに登録できます。詳細については, DECnet-Plus のマニュアルを参照してください。

9.4.5 MOP サービスの構成

ブート・ノードで,CLUSTER_CONFIG.COM は, DECnet データベースから最初に検出されたサーキットで DECnet MOP ダウンライン・ロード・サービスを有効にします。

DECnet for OpenVMS を実行しているシステムで,以下のコマンドを使用して,サーキットの状態とサービス (MOP ダウンライン・ロード・サービス) の状態を表示します。


$ MCR NCP SHOW CHAR KNOWN CIRCUITS


           . 
           . 
           . 
   Circuit = SVA-0 
 
   State                    = on 
   Service                  = enabled  
           . 
           . 
           . 

この例では,サーキット SVA-0 が ON 状態であり, MOP ダウンライン・サービスが有効に設定されていることが示されています。これは,サテライトに対して MOP ダウンライン・ロードをサポートするための正しい状態です。

追加の LAN アダプタ (サーキット) で MOP サービスを有効に設定する操作は,手動で行わなければなりません。たとえば,以下の NCP コマンドを入力して,サーキット QNA-1 に対してサービスを有効にします。


$ MCR NCP SET CIRCUIT QNA-1 STATE OFF
$ MCR NCP SET CIRCUIT QNA-1 SERVICE ENABLED STATE ON
$ MCR NCP DEFINE CIRCUIT QNA-1 SERVICE ENABLED

関連項目: 詳細については,『DECnet for OpenVMS Network Management Utilities』を参照してください。

9.4.6 サテライト・ブートの制御

サテライト・ブート処理は多くの方法で制御できます。 表 9-8 には,DECnet for OpenVMS 固有の例が示されています。DECnet-Plus の例については, DECnet-Plus のマニュアルを参照してください。

表 9-8 サテライト・ブートの制御
方法 説明
DECbootsync を使用する方法
同時に起動されるワークステーションの数を制御するには, DECbootsync を使用する。これは,以下の NSIS Reusable Software ライブラリから提供される。 http://eadc.aeo.dec.com/

DECbootsync は分散ロック・マネージャを使用して,同時にスタートアップ・コマンド・プロシージャを続行できるサテライトの数を制御する。

DECbootsync は,OpenVMS オペレーティング・システムのブートを制御しないが,サテライトでスタートアップ・コマンド・プロシージャの実行とレイヤード製品のインストールを制御する。
MOP サーバで一時的に MOP サービスを無効にする方法
MOP サーバが独自のスタートアップ操作を完了できるまで,以下に示すように DECnet Ethernet サーキットを "Service Disabled" 状態に設定することにより,ブート要求を一時的に無効にできる。

1 MOP サーバのスタートアップ時に MOP サービスを無効にするには,以下のコマンドを入力する。
$ MCR NCP DEFINE CIRCUIT MNA-1 -

_$ SERVICE DISABLED
$ @SYS$MANAGER:STARTNET
$ MCR NCP DEFINE CIRCUIT MNA-1 -
_$ SERVICE ENABLED
2 後で MOP サービスを再び有効にするには,コマンド・プロシージャに以下のコマンドを入力して,コマンドが迅速に実行されるようにし,ユーザに対する DECnet サービスが中断されないようにする。
$ MCR NCP

NCP> SET CIRCUIT MNA-1 STATE OFF
NCP> SET CIRCUIT MNA-1 SERVICE ENABLED
NCP> SET CIRCUIT MNA-1 STATE ON

この方法では,MOP サーバがサテライトをサービスすることが禁止される。しかし,サテライトが他の MOP サーバからブートを要求することは禁止されない。

ブートを要求しているサテライトが応答を受信できない場合は,しばらくしていくつかのブート要求を行う。したがって, MOP サービスが再び有効にされた後,サテライトのブートは通常より長い時間がかかる可能性がある。

  1. MNA-1 は MOP サービス・サーキットを表す。

    これらのコマンドを入力した後,運用時データベースでサービスが無効に設定される。サービスを永久に無効に設定してはならない。

  2. 左記の方法でサービスを再び有効にする。

個々のサテライトに対して MOP サービスを無効にする方法
ノード単位で一時的に要求を無効にして, DECnet データベースからノードの情報を消去することができる。 NCP を使用して MOP サーバで DECnet データベースからノードの情報を消去した後,ブートを制御するために必要に応じてノードを再び有効にする。

1 特定のノードに対して MOP サービスを無効にするには,以下のコマンドを入力する。
$ MCR NCP

NCP> CLEAR NODE satellite HARDWARE ADDRESS
2 そのノードに対して MOP サービスを再び有効にするには,以下のコマンドを入力する。
$ MCR NCP

NCP> SET NODE satellite ALL

この方法では,サテライトが別の MOP サーバからブート・サービスを要求することは禁止されない。

  1. コマンドを入力した後,サービスは運用時データベースで無効に設定される。サービスを永久に無効設定にしてはならない。

  2. 左記に示す方法でサービスを再び有効にする。

シャットダウン時にサテライトをコンソール・プロンプト・モードに設定する方法
電源が復旧したときに,サテライトが (リブートされるのではなく) 停止するように設定するには,以下のいずれかの方法を使用する。

1 VAXcluster Console System (VCS) を使用する。
2 Halt または電源投入時にコンソール・モードで停止する。

Alpha コンピュータの場合:

>>> SET AUTO_ACTION HALT

VAX 3100 または VAX 4000 シリーズ・コンピュータの場合:

>>> SET HALT 3

VAX 2000 シリーズ・コンピュータの場合:

>>> TEST 53

2 ? >>> 3
3 以下の一覧の指示に従って,HALT 命令が実行されるときに,コンソール・モードで停止するようにサテライトを設定する。

  1. リブート時に HALT 命令を実行するイメージがロードされるように,以下の NCP コマンドを入力する。
    $ MCR NCP
    
    NCP> CLEAR NODE node LOAD ASSIST PARAMETER
    NCP> CLEAR NODE node LOAD ASSIST AGENT
    NCP> SET NODE node LOAD FILE -
    _ MOM$LOAD:READ_ADDR.SYS

  2. 以下の SYSMAN コマンドを使用してサテライトをシャットダウンし,即時リブートを指定する。
    $ MCR SYSMAN
    
    SYSMAN> SET ENVIRONMENT/NODE= satellite
    SYSMAN> DO @SYS$UPDATE:AUTOGEN REBOOT

  3. サテライトを通常の方法でブートするように設定する場合は,以下の NCP コマンドを入力して,OpenVMS が後でロードされるようにする。
    $ MCR NCP
    
    NCP> SET NODE satellite ALL

DECnet Trigger 操作を使用する予定がある場合は,サテライトがコンソール・モードになるような HALT 命令を実行するプログラムを使用することが重要である。これは,システムがコンソール・モードの間,リモート・トリガをサポートするシステムだけがサテライトをサポートするからである。

  1. 電源が復旧したときや HALT 命令が実行されたときに,自動的にリブートされるのではなく,停止するように,一部の (全部ではない) サテライトを設定することができる。

    注意: 設定は不揮発性 RAM に保存されるため,SET コマンドは各システムで 1 回入力するだけでよい。

  2. サテライト・ノードの Ethernet アドレスを検出するために通常使用される READ_ADDR.SYS プログラムも,終了時に HALT 命令を実行する。

Trigger によってリモートからサテライトをブートする方法
VAX 3100 や VAX 4000 などの一部のサテライトのコンソール・ファームウェアでは,DECnet Trigger 操作を使用してリモートからブートすることが可能である。この機能は, NCP コマンド TRIGGER を入力する前に,コンソール・プロンプトで有効に設定しなければならない。以下の例を参照。

1 DECnet Trigger 機能を使用して VAX サテライトをブートするには,コンソール・プロンプトに対して以下のコマンドを入力する。
>>> SET MOP 1

>>> SET TRIGGER 1
>>> SET PSWD
2 サテライト・ブートをリモートから起動するには,NCP プロンプトに対して以下のコマンドを入力する。
$ MCR NCP

NCP> TRIGGER NODE satellite -
_ VIA MNA-1 SERVICE PASSWORD password

また,コマンド・プロシージャを実行し,一度に 5〜10 台のサテライトを起動して,ブート時の作業負荷を分散するように, MOP サーバを設定することができる。優先順位の高い順にサテライトをブートすることができる。たとえば,自分のサテライトを最初にブートし,次に優先順位の高いサテライトをブートすることができる。

  1. SET TRIGGER 1 コマンドは DECnet MOP リスナを有効にし,SET PSWD コマンドはリモート・トリガを有効にする。 SET PSWD コマンドは,リモート・トリガ要求の認証で使用される 16 桁の 16 進パスワード文字列を 2 回入力するように要求する。

    注意: 設定は不揮発性 RAM に保存されるため,SET コマンドは各システムで 1 回だけ入力すればよい。

  2. MNA-1 は MOP サービス・サーキットを表し, password は SET PSWD コマンドのステップ 1 で指定した 16 進数である。


前へ 次へ 目次 索引