日本-日本語
≫日本HPホーム ≫製品 & サービス ≫OpenVMS製品情報
≫  お問い合わせ


OpenVMS マニュアル
≫ 

OpenVMS ドキュメント
ライブラリ

≫ タイトルページ
≫ 目次
≫ まえがき
≫ 第1章：OpenVMS Cluster システムの管理の概要
≫ 第2章：OpenVMS Cluster の概念
≫ 第3章：OpenVMS Cluster インターコネクト構成
≫ 第4章：OpenVMS Cluster オペレーティング環境
≫ 第5章：共用環境の準備
≫ 第6章：クラスタ・ストレージ・デバイス
≫ 第7章：クラスタ・キューの設定と管理
≫ 第8章：OpenVMS Cluster システムの構成
≫ 第9章：大規模な OpenVMS Cluster システムの構築
≫ 第10章：OpenVMS Cluster システムの保守
≫ 付録A ：クラスタ・システム・パラメータ
≫ 付録B ：共通ファイルの作成
≫ 付録C ：クラスタのトラブルシューティング
≫ 付録D ：LAN 制御のためのサンプル・プログラム
≫ 付録E ：LAN 制御のためのサブルーチン
≫ 付録F ：NISCA プロトコルのトラブルシューティング
≫ 付録G ：NISCA トランスポート・プロトコル輻輳制御
≫ 索引
PDF
≫ OpenVMS ホーム

HP OpenVMS
OpenVMS Cluster システム
目次 索引


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

  • それぞれの追加 LAN アダプタに対して，擬似ノードを定義します。

  • 異なるブート・ノードに対して，異なるノード・データベースを作成し，管理します。

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

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

  • アドレスが，既存のノード定義と同じクラスタ・サテライト・ルート・ディレクトリを指していることを確認します (擬似ノードとサテライトを対応付けるため)。

  • 代替 LAN アダプタのハードウェア・アドレスを擬似ノード定義に指定します。

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

表 9-3 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 ノードの例である。

表 9-4 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 ノードの例である。

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

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

  • 1 つの LAN アダプタからブートされるシステムが MOP サーバのサブセットから応答を受信するように，データベースを設定します。異なる LAN アダプタからの同じシステム・ブートは，異なる MOP サーバのサブセットから応答を受信します。

  • 各データベースで，同じノード定義に対して異なる LAN アドレスを指定します。

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

表 9-5 異なる 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 ファイルが相互のコピーである場合は，ノード名，LOAD FILE，ロード・アシスト・エージェント，ロード・アシスト・パラメータはすでに設定されている。新しいハードウェア・アドレスだけを指定しなければならない。

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

表 9-6 異なる 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 修飾子の値はすでに設定されている。新しいアドレスだけを指定すればよい。

サテライトが 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-7 には，DECnet for OpenVMS 固有の例が示されています。DECnet-Plus の例については， DECnet-Plus のマニュアルを参照してください。

表 9-7 サテライト・ブートの制御
方法 説明
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

  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 命令を実行する。

重要: 表 9-7 の説明に従って SET HALT コマンドを設定した場合，電源障害が発生した後，電源が復旧しても，サテライトは自動的にリブートされず，コンソール・プロンプトで停止します。大規模な電源障害の場合は，この動作が適切ですが，サテライトの電源コードに誰かがつまずいたような場合は，サテライトを使用できなくなるため不便です。

以下の操作を実行するバッチ・ジョブを定期的に実行するようにすれば，このようにしてダウン状態になっているサテライトをスキャンし，起動することができます。

  1. DCL レキシカル関数 F$GETSYI を使用して，クラスタ内の各ノードが正常に動作しているかどうか確認します。

  2. CLUSTER_MEMBER レキシカル・アイテムを確認します。

  3. 現在，クラスタのメンバでないサテライトに対して， NCP TRIGGER コマンドを実行します。



9.5 サテライト・ノードの構成とブート (Integrity サーバ)

サテライト

OpenVMS Version 8.3 システムあるいはセルベース・システムの nPartition は，サテライトとして使用することができます。 nPartition のサポートにはファームウェアのアップグレードが必要な場合があります。

サテライト・ブートはコア I/O LAN アダプタ経由でのみサポートされます。クラッシュ・ダンプとエラー・ログを保管するために，各サテライト・システムは少なくとも 1 つのローカル・ディスクが必要です。ディスクレス・システムは，ソフトウェアの異常終了の際にクラッシュ・ダンプを取ることはできません。

ブート・サーバ

OpenVMS Version 8.3 がサポートするすべての Integrity サーバはブート・サーバとしてサポートされます。現時点では Integrity サテライト・システムに対するクロスアーキテクチャ・ブートはサポートしていなため，Integrity サテライト・システムを含むクラスタでは，ブート・ノードとして動作するIntegrity サーバ・システムが少なくとも 1 つ必要になります。

必要なソフトウェア

  • OpenVMS Version 8.3 以上

  • HP TCP/IP Services for OpenVMS Version 5.6 以上

他のサテライト・システムと同様に，システム・ソフトウェアはそのクラスタの 1 つあるいは複数のノードによってサービスされるディスクから提供されます。サテライト・システム・ディスクはブート・サーバのシステム・ディスクと同じ場合もありますが，必ずしもそうである必要はありません。 Alpha サテライトの場合，ブート・サーバにシステム・ディスクがマウントされていることが推奨されますが必須ではありません。一方 Integrity サテライト・システムでは，ブート・サーバにシステム・ディスクがマウントされていなければなりません。

TCP/IP はブート・サーバのシステム・ディスクにインストールされていなければなりません。 OpenVMS Version 8.3 は，ブート・サーバのディスクとサテライト・システムのディスクが異なる場合，両方にインストールされていなければなりません。

TCP/IP は，BOOTP，TFTP，および 1 つ以上のインタフェースを有効にして構成しなければなりません。少なくとも 1 つのインタフェースは，各サテライト・システムから見えるセグメントに接続されていなければなりません。ブート・サーバとすべてのサテライト・システムには IP アドレスが必要です。 TCP/IP Services for OpenVMS の構成については，『HP TCP/IP Services for OpenVMS Version 5.6 インストレーション/コンギュレーション・ガイド』を参照してください。

目次 索引

© 2012 Hewlett-Packard Development Company, L.P.