![]() |
![]() |
日本-日本語 | ![]() |
|
|
|
![]() |
![]() OpenVMS マニュアル |
|
![]() |
HP OpenVMS
|
目次 | 索引 |
サテライト・システムにいずれかのバージョンの OpenVMS がインストールされたローカル・ディスクが接続されている場合,ログインしてください。あるいは,インストール DVD からブートしてオプション 8 (Execute DCL commands and procedures) を選択し,次のコマンドを実行してください。
$ LANCP :== $LANCP $ LANCP SHOW CONFIG LAN Configuration: Device Parent Medium/User Version Link Speed Duplex Size MAC Address Current Address Type ------------- ----------- ------- ---- ----- ------ ---- ----------------- --------------- ---------- EIB0 Ethernet X-16 Up 1000 Full 1500 00-13-21-5B-86-49 00-13-21-5B-86-49 UTP i82546 EIA0 Ethernet X-16 Up 1000 Full 1500 00-13-21-5B-86-48 00-13-21-5B-86-48 UTP i82546 |
ブートに使用するアダプタの MAC アドレスを書き留めてください。ブート・サーバでサテライト・システムを定義する際にこの MAC アドレスが必要になります。 "Current Address" の値が "MAC Address" の値と異なる場合は, "MAC Address" の値を使用してください。
9.5.2 サテライト・システムにおけるブートおよびクラッシュ・ダンプに関する設定 |
![]() |
サテライトのローカル・ディスクに OpenVMS がインストールされている場合はログインしてください。 OpenVMS がインストールされたローカル・ディスクがない場合は,インストール DVD からブートしてオプション 8 (Execute DCL commands and procedures) を選択してください。ブートに使用するネットワーク・アダプタをブート・メニューのオプションに追加するには SYS$MANAGER:BOOT_OPTIONS.COM を使用してください。このプロシージャはこのネットワーク・エントリがサテライト・ブート用であるかどうか尋ね,その場合はブート・エントリに対し,サテライト・ブートに必要な Memory Disk ブート・オプション・フラグ (0x200000) を設定します。
そのシステムを主にサテライト・ブートに使用したい場合は,ネットワーク・ブート・オプションをポジション 1 に設定してください。またサテライト・システムは,クラッシュ・ダンプのためと,リブートやクラッシュ時のエラー・ログ・バッファの内容の保管のために DOSD (Dump Off the System Disk) を必要とします。 BOOT_OPTIONS.COM は,DOSD デバイス・リストの管理にも使用できます。この際,DOSD デバイス・リストを作成することができます。 DOSD デバイス・リストの設定については,『HP OpenVMS システム管理者マニュアル(下巻)』を参照してください。
9.5.3 ブート・サーバでのサテライト・システムの設定 |
![]() |
Integrity サーバ・サテライト・システムは PXE プロトコルでブートします。 OpenVMS では,PXE は TCP/IP 製品の BOOTP によって処理されます。クラスタ環境でブート・サーバとして 1 つ以上の Integrity サーバを使用している場合,BOOTP データベースを共通ディスク上に置くようにしてください。 TCP/IP コンポーネントの構成については, TCP/IP のドキュメントを参照してください。サテライト・システムを設定する際には, TCP/IP のインストールおよび構成が完了しており,そのシステムで TCP/IP が実行されていることが必要です。
ブート・サーバとして機能させる Integrity サーバ・システムにシステム管理者アカウントあるいは必要な特権付きアカウントにログインし,コマンド・プロシージャ SYS$MANAGER:CLUSTER_CONFIG_LAN.COM を実行してください (DECnet を使用してサテライト・ノードを構成する CLUSTER_CONFIG.COM は, Integrity サーバ・システムをサポートしません)。しかし,Integrity サーバ・システムでは CLUSTER_CONFIG.COM が CLUSTER_CONFIG_LAN を自動的に起動します。 CLUSTER_CONFIG_LAN は,サテライト・システムの構成に利用できるメニュー方式のコマンド・プロシージャです。このメニューは状況依存で,アーキテクチャやインストールされている製品によって異なります。 CLUSTER_CONFIG_LAN コマンド・プロシージャについては,システム管理者マニュアルを参照してください。
Integrity サーバ・サテライトを追加するための必須情報は,そのノードの SCS ノード名,SCS システム ID,およびハードウェア・アドレスです。また,そのサテライトの IP アドレス,ネットワーク・マスク,ゲートウェイ・アドレスも知っておく必要があります。これらの情報についての説明は TCP/IP のドキュメントを参照してください。このプロシージャは,そのサテライトのシステム・ルートを作成します。
CLUSTER_CONFIG_LAN はサテライト・システムをブート可能にするためのすべてのステップを実行するようになっています。ローカル・ページング・ファイルおよびローカル・スワッピング・ファイルを選択する場合,それらのファイルが作成されるようにサテライト・システムをクラスタ内にブートするためのプロンプトが表示されます。そうでない場合,ページング・ファイルおよびスワッピング・ファイルはサービスする側のシステム・ディスクに作成され,そのサテライトのブートはユーザの都合の良いときに実行できます。
9.5.4 サテライトのブート |
![]() |
ブート・メニューにオプションを追加してある場合は,そのオプションを選択します。そうでない場合は,ハードウェアのドキュメントを参照して,ネットワーク・アダプタからブートするための手順を確認してください。なお,環境変数 VMS_FLAGS にメモリ・ディスク・ブート・フラグ (0x200000) が含まれるように設定されていることを確認してください。ネットワークから VMS_LOADER が取得されるとシステムはブートの進捗状況を示すシステム・メッセージを表示し,ブートシーケンスを開始するためのファイルがダウンロードされるたびにコンソール・デバイスにドット文字が出力され,最後に, IPB (プライマリ・ブートストラップ・イメージ) がロードされたことを示すメッセージが表示されます。
以下に例を示します。
Loading.: Satellite Boot EIA0 Mac(00-13-21-5b-86-48) Running LoadFile() CLIENT MAC ADDR: 00 13 21 5B 86 48 CLIENT IP: 16.116.43.79 MASK: 255.255.248.0 DHCP IP: 0.240.0.0 TSize.Running LoadFile() Starting: Satellite Boot EIA0 Mac(00-13-21-5b-86-48) Loading memory disk from IP 16.116.43.78 ............................................................................ Loading file: $13$DKA0:[SYS10.SYSCOMMON.SYSEXE]IPB.EXE from IP 16.116.43.78 %IPB-I-SATSYSDIS, Satellite boot from system device $13$DKA0: HP OpenVMS Industry Standard 64 Operating System, Version V8.3 Copyright 1976-2006 Hewlett-Packard Development Company, L.P. |
最初にフル・ブートを実行した際,サテライト・システムは AUTOGEN を実行しリブートされます。
9.5.5 サテライト・システムにおけるその他の作業 |
![]() |
まだ DOSD 用のダンプ・ファイルを作成していない場合は作成します。 SYS$STARTUP:SYCONFIG.COM ファイルを編集して, DOSD デバイスをマウントするためのコマンドを追加します。エラー・ログ・バッファが復元されるようにするには, DOSD デバイスは SYCONFIG でマウントする必要があります。
![]() | 9.6 IP インターコネクトでのサテライトのブート (Integrity および Alpha) | ![]() |
Alpha サテライト・ノードの場合,サテライト・ノードとそのブート・サーバは同じ LAN 上に存在しなければなりません。サテライト・ブートに使用するインタフェースを選択するには,サテライト・ノードは OpenVMS を実行するディスクが接続されていないことを前提とします。 Alpha システムをサテライト・ノードとして追加している場合, >>>プロンプトで次のコマンドを実行することにより必要な情報が得られます。
P00>>>show device dga5245.1003.0.3.0 $1$DGA5245 COMPAQ HSV110 (C)COMPAQ 3028 dga5245.1004.0.3.0 $1$DGA5245 COMPAQ HSV110 (C)COMPAQ 3028 dga5890.1001.0.3.0 $1$DGA5890 COMPAQ HSV110 (C)COMPAQ 3028 dga5890.1002.0.3.0 $1$DGA5890 COMPAQ HSV110 (C)COMPAQ 3028 dka0.0.0.2004.0 DKA0 COMPAQ BD03685A24 HPB7 dka100.1.0.2004.0 DKA100 COMPAQ BD01864552 3B08 dka200.2.0.2004.0 DKA200 COMPAQ BD00911934 3B00 dqa0.0.0.15.0 DQA0 HL-DT-ST CD-ROM GCR-8480 2.11 dva0.0.0.1000.0 DVA0 eia0.0.0.2005.0 EIA0 00-06-2B-03-2D-7D pga0.0.0.3.0 PGA0 WWN 1000-0000-c92a-78e9 pka0.7.0.2004.0 PKA0 SCSI Bus ID 7 pkb0.6.0.2.0 PKB0 SCSI Bus ID 6 5.57 P00>>> |
この出力では LAN インタフェースは EIA0 で, IP アドレスがそのインタフェースに定義され,クラスタ構成に使用されます。
![]() | 注意 Alpha コンソールは,サテライト・システムのネットワーク・ロードに MOP プロトコルを使用します。 MOP プロトコルはルータブルではないので,サテライト・ブート・サーバおよびそこからブートされるすべてのサテライトは同じ LAN 上に存在しなければなりません。また,Alpha サテライト・ノードがシステム・ディスクにアクセスできるように,ブート・サーバはクラスタ通信に使用できる LAN デバイスを少なくとも 1 つは待っていなければなりません。 |
Integrity サーバ・システムでは,インタフェース名は EI あるいは EW のどちらかで始まります。たとえば最初のインタフェースであれば EIA0 あるいは EWA0 になります。インタフェースの MAC アドレスは Shell プロンプトから取得します。 Integrity サーバでインタフェース情報を取得するには, EFI シェルで次のコマンドを実行します。
Shell> lanaddress LAN Address Information LAN Address Path ----------------- ---------------------------------------- Mac(00306E4A133F) Acpi(HWP0002,0)/Pci(3|0)/Mac(00306E4A133F)) *Mac(00306E4A02F9) Acpi(HWP0002,100)/Pci(2|0)/Mac(00306E4A02F9)) Shell> |
アクティブなインタフェースは EIA0 と想定されるので EIA0 でサテライトを構成します。 EIA0 でブートしない場合は,その後 EWA0 で試してみます。サテライト・ノードの構成については 第 8.2.3.4 項 を参照してください。
![]() | 9.7 システム・ディスクのスループット | ![]() |
十分なシステム・ディスクのスループットを達成するには,以下の手法を組み合わせて使用することが必要です。
手法 | 関連項目 |
---|---|
ブート時にディスクが再構築されるのを回避する。 | 第 9.7.1 項 |
システム・ディスクから作業負荷を軽減する。 | 第 9.7.2 項 |
複数のシステム・ディスクを構成する。 | 第 9.7.3 項 |
Volume Shadowing for OpenVMS を使用する。 | 第 6.6 節 |
9.7.1 ディスクの再構築の回避 |
![]() |
OpenVMS ファイル・システムは,あらかじめ割り当てられているファイル・ヘッダとディスク・ブロックを格納したキャッシュを管理しています。システム障害が発生した場合などのように,ディスクが正しくディスマウントされていない場合,このあらかじめ割り当てられた領域が一時的に使用できなくなります。ディスクが再びマウントされると,OpenVMS はディスクをスキャンして,その領域を回復します。この処理をディスクの再構築と呼びます。
大規模な OpenVMS Cluster システムでは,妥当な時間内にノードをブートできるように十分なキャパシティを確保しておかなければなりません。ブート時にディスクの再構築の影響をできるだけ少なくするには,以下の変更を行うことを考慮します。
操作 | 結果 |
---|---|
少なくともサテライト・ノードで,すべてのユーザ・ディスクに対して DCL コマンド MOUNT/NOREBUILD を使用する。ユーザ・ディスクをマウントするスタートアップ・プロシージャにこのコマンドを登録する。 | サテライト・ノードがディスクを再構築するように設定するのは不適切であるが,サテライトまたは別のノードで障害が発生した後,サテライトが最初にリブートされる場合は,この動作が発生する可能性がある。 |
少なくともサテライト・ノードに対して,システム・パラメータ ACP_REBLDSYSD を 0 に設定する。 | このように設定しておくと,ブート・プロセスの初期段階で OpenVMS によってシステム・ディスクが暗黙にマウントされるときに,再構築操作が実行されるのを防止できる。 |
システムの負荷がそれほど高くない時刻に, SET VOLUME/REBUILD コマンドを使用することにより,通常の勤務時間帯にディスクの再構築が実行されないようにする。コンピュータが起動された後,バッチ・ジョブまたはコマンド・プロシージャを実行して,各ディスク・ドライブに対して SET VOLUME/REBUILD コマンドを実行する。 | ディスクの再構築操作を行うと,そのディスクに対する大部分の I/O 処理がブロックされるため,ユーザの応答時間が低下する可能性がある。SET VOLUME/REBUILD コマンドは再構築が必要であるかどうか判断するので,ジョブはすべてのディスクに対してコマンドを実行できる。このジョブは作業負荷の低い時間に,できるだけ強力なノードで実行する。 |
![]() | 注意 大規模な OpenVMS Cluster システムでは,大量のディスク領域をキャッシュにあらかじめ割り当てることができます。多くのノードがクラスタから突然削除された場合 (たとえば電源障害が発生した場合),この領域は一時的に使用できなくなります。通常,ほとんどディスクが満杯の状態でシステムが稼動している場合は,ブート時にサーバ・ノードで再構築を無効にしないでください。 |
OpenVMS Cluster 全体のブートでは,システム・ディスクのスループットに関する問題が発生しますが,その他に安定した状態での操作 (ログイン,アプリケーションの起動,PRINT コマンドの実行など) でも,特定のシステム・ファイルへのアクセスによって応答時間に影響することがあります。
パフォーマンス・ツールや監視ツール ( 第 1.5.2 項 に示したツールなど) を使用して, ホット・システム・ファイルを特定し,以下の表に示した手法を利用して,システム・ディスクでホット・ファイルに対する I/O 操作を削減することができます。
可能性のあるホット・ファイル | 役立つ方法 |
---|---|
ページ・ファイルとスワップ・ファイル | コンピュータの追加時に CLUSTER_CONFIG_LAN.COM または CLUSTER_CONFIG.COM を実行して,ページ・ファイルとスワップ・ファイルのサイズと場所を指定する場合は,以下の方法でファイルを移動する。
|
以下の利用頻度の高いファイルをシステム・ディスクから移動する。
|
以下のいずれかの方法を使用する。
|
これらのファイルをシステム・ディスクから別のディスクに移動すると,システム・ディスクに対する大部分の書き込み操作を行わないようにすることができます。その結果,読み込み/書き込み率を向上でき,Volume Shadowing for OpenVMS を使用している場合は,システム・ディスクでのシャドウイングのパフォーマンスを最大限に向上できます。
9.7.3 複数のシステム・ディスクの構成 |
![]() |
大規模なクラスタに含まれるコンピュータの数と,実行される作業に応じて,1 つのシステム・ディスクを構成するのか,複数のシステム・ディスクを構成するのか,その長所と短所を評価しなければなりません。
1 つのシステム・ディスクは管理が簡単ですが,大規模なクラスタでは, 1 つのシステム・ディスクで提供できるキャパシティより多くのシステム・ディスク I/O キャパシティが必要になることがあります。満足できるパフォーマンスを達成するために,複数のシステム・ディスクが必要になることがあります。しかし,複数のシステム・ディスクを管理する場合は,システム管理作業が増加することを考慮しなければなりません。
複数のシステム・ディスクが必要かどうか判断する場合は,以下のことを考慮してください。
条件 | 結果 | 説明 |
---|---|---|
多くのユーザが同時にアクティブになるか,または複数のアプリケーションを同時に実行する。 | システム・ディスクの負荷はかなり大きくなる可能性がある。複数のシステム・ディスクが必要になる可能性がある。 | 一部の OpenVMS Cluster システムの場合,すべてのユーザが常にアクティブであることを想定して構成しなければならない。このような作業状況では,パフォーマンスを低下させずにピーク時の負荷を処理できるような,大規模でコストのかかる OpenVMS Cluster システムが必要になる可能性がある。 |
少ない数のユーザが同時にアクティブになる。 | 1 つのシステム・ディスクで多くのサテライトをサポートできる可能性がある。 | ほとんどの構成の場合,大部分のユーザが同時にアクティブになる可能性は低い。このような典型的な作業状況では,小規模でそれほどコストのかからない OpenVMS Cluster システムを構成できるが,負荷のピーク時にはパフォーマンスがある程度低下する可能性がある。 |
大部分のユーザが長期間にわたって 1 つのアプリケーションを実行する。 | 多くの I/O 要求をアプリケーション・データ・ディスクに渡すことができる場合は,1 つのシステム・ディスクで多くのサテライトをサポートできる。 | OpenVMS Cluster システムの各ワークステーション・ユーザは専用のコンピュータを保有しているため,大規模な演算中心ジョブをその専用コンピュータで実行するユーザは, OpenVMS Cluster システム内の他のコンピュータのユーザに大きな影響を与えない。クラスタに接続されているワークステーションの場合,重要な共用リソースはディスク・サーバである。したがって,ワークステーション・ユーザが I/O 集約型ジョブを実行する場合は,同じディスク・サーバを共用する他のワークステーションに与える影響が顕著になる可能性がある。 |
目次 | 索引 |
![]() |
||||||||
|