前へ | 次へ | 目次 | 索引 |
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 種類の方法のいずれかを使用できます。
異なる DECnet アドレスまたは LANCP アドレスを使用して,擬似ノードを定義する場合は,以下の操作を行います。
DECnet の場合は, 表 9-4 に示す手順に従います。LANCP の場合は, 表 9-5 に示す手順に従います。
ステップ | 手順 | 説明 |
---|---|---|
1 | 以下の NCP コマンドを使用して,ノードの既存の定義を表示する。
$ RUN SYS$SYSTEM:NCP |
このコマンドは,ハードウェア・アドレス,ロード・アシスト・エージェント,ロード・アシスト・パラメータなど,サテライトの属性の一覧を表示する。 |
2 | 以下に示すように,NCP コマンド・プロンプトに対して,固有の DECnet アドレスとノード名を定義することにより,擬似ノードを作成する。
++DEFINE NODE pseudo-area.pseudo-number - |
この例は Alpha ノード固有の例である。VAX ノードの場合は, LOAD FILE APB.EXE コマンドを TERTIARY LOADER SYS$SYSTEM:TERTIARY_VMB.EXE に変更する。 |
ステップ | 手順 | 説明 |
---|---|---|
1 | 以下の LANCP コマンドを使用して,ノードの既存の定義を表示する。
$ RUN SYS$SYSTEM:LANCP |
このコマンドは,ハードウェア・アドレスやルート・ディレクトリ・アドレスなど,サテライトの属性の一覧を表示する。 |
2 | 以下に示すように,LANCP コマンド・プロンプトに対して,固有の LANCP アドレスとノード名を定義することにより,擬似ノードを作成する。
++DEFINE NODE pseudo-node-name - |
この例は Alpha ノード固有の例である。VAX ノードの場合は,修飾子 FILE=APB.EXE を FILE=NISCS_LOAD.EXE に変更する。 |
異なるブート・ノードに対する異なるノード・データベースの作成
異なるブート・ノードに対して異なる DECnet または LANCP データベースを作成する場合は,以下の操作を行います。
手順は DECnet の場合も LANCP の場合も類似していますが,データベース・ファイル名,ユーティリティ,コマンドは異なります。 DECnet プロシージャの場合は, 表 9-6 を参照してください。LANCP プロシージャの場合は, 表 9-7 を参照してください。
ステップ | 手順 | 説明 |
---|---|---|
1 | 異なるファイルを参照するように,異なるノードで論理名 NETNODE_REMOTE を異なる値に定義する。 | 論理名 NETNODE_REMOTE は,作成しているリモート・ノード・ファイルのワーキング・コピーを指す。 |
2 | 各ノードのシステム固有の領域に NETNODE_REMOTE.DAT ファイルを格納する。
各ブート・サーバで,サテライトのアダプタのいずれかと一致する固有のアドレスとしてハードウェア・アドレスが定義されていることを確認する。NCP コマンド・プロンプトに対して,以下のコマンドを入力する。
|
システム・ルート 0 からのシステム・ブートの場合, [SYS0.SYSEXE] に格納されている NETNODE_REMOTE.DAT ファイルは [SYS0.SYSCOMMON.SYSEXE] に格納されているファイルより優先する。
NETNODE_REMOTE.DAT ファイルが相互のコピーである場合は,ノード名,3 次ローダ (VAX の場合) または LOAD FILE (Alpha の場合),ロード・アシスト・エージェント,ロード・アシスト・パラメータはすでに設定されている。新しいハードウェア・アドレスだけを指定しなければならない。 デフォルト・ハードウェア・アドレスは NETUPDATE.COM に格納されるため,2 番目のブート・サーバでこのファイルを編集しなければならない。 |
ステップ | 手順 | 説明 |
---|---|---|
1 | 異なるファイルを参照するように,論理名 LAN$NODE_DATABASE を異なるノードで異なる値に定義する。 | 論理名 LAN$NODE_DATABASE は,作成しているリモート・ノード・ファイルのワーキング・コピーを指す。 |
2 | 各ノードのシステム固有の領域に LAN$NODE_DATABASE.DAT ファイルを格納する。
各ブート・サーバで,サテライトのアダプタの 1 つと一致する固有のアドレスとしてハードウェア・アドレスが定義されていることを確認する。LANCP コマンド・プロンプトに対して,以下のコマンドを入力する。
|
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-8 には,DECnet for OpenVMS 固有の例が示されています。DECnet-Plus の例については, DECnet-Plus のマニュアルを参照してください。
方法 | 説明 | ||||
---|---|---|---|---|---|
DECbootsync を使用する方法 | |||||
同時に起動されるワークステーションの数を制御するには, DECbootsync を使用する。これは,以下の NSIS Reusable Software ライブラリから提供される。
http://eadc.aeo.dec.com/
DECbootsync は分散ロック・マネージャを使用して,同時にスタートアップ・コマンド・プロシージャを続行できるサテライトの数を制御する。 |
DECbootsync は,OpenVMS オペレーティング・システムのブートを制御しないが,サテライトでスタートアップ・コマンド・プロシージャの実行とレイヤード製品のインストールを制御する。 | ||||
MOP サーバで一時的に MOP サービスを無効にする方法 | |||||
MOP サーバが独自のスタートアップ操作を完了できるまで,以下に示すように DECnet Ethernet サーキットを "Service Disabled" 状態に設定することにより,ブート要求を一時的に無効にできる。
|
この方法では,MOP サーバがサテライトをサービスすることが禁止される。しかし,サテライトが他の MOP サーバからブートを要求することは禁止されない。
ブートを要求しているサテライトが応答を受信できない場合は,しばらくしていくつかのブート要求を行う。したがって, MOP サービスが再び有効にされた後,サテライトのブートは通常より長い時間がかかる可能性がある。
|
||||
個々のサテライトに対して MOP サービスを無効にする方法 | |||||
ノード単位で一時的に要求を無効にして, DECnet データベースからノードの情報を消去することができる。 NCP を使用して MOP サーバで DECnet データベースからノードの情報を消去した後,ブートを制御するために必要に応じてノードを再び有効にする。
|
この方法では,サテライトが別の MOP サーバからブート・サービスを要求することは禁止されない。
|
||||
シャットダウン時にサテライトをコンソール・プロンプト・モードに設定する方法 | |||||
電源が復旧したときに,サテライトが (リブートされるのではなく) 停止するように設定するには,以下のいずれかの方法を使用する。
|
DECnet Trigger 操作を使用する予定がある場合は,サテライトがコンソール・モードになるような HALT 命令を実行するプログラムを使用することが重要である。これは,システムがコンソール・モードの間,リモート・トリガをサポートするシステムだけがサテライトをサポートするからである。
|
||||
Trigger によってリモートからサテライトをブートする方法 | |||||
VAX 3100 や VAX 4000 などの一部のサテライトのコンソール・ファームウェアでは,DECnet Trigger 操作を使用してリモートからブートすることが可能である。この機能は, NCP コマンド TRIGGER を入力する前に,コンソール・プロンプトで有効に設定しなければならない。以下の例を参照。
|
また,コマンド・プロシージャを実行し,一度に 5〜10 台のサテライトを起動して,ブート時の作業負荷を分散するように, MOP サーバを設定することができる。優先順位の高い順にサテライトをブートすることができる。たとえば,自分のサテライトを最初にブートし,次に優先順位の高いサテライトをブートすることができる。
|
前へ | 次へ | 目次 | 索引 |