| 前へ | 次へ | 目次 | 索引 |
コンピュータが最初に OpenVMS Cluster に追加されるときに，通常，コンピュータのシステム・リソースを制御するシステム・パラメータが，以下に示すように複数のステップで調整されます。
最初の AUTOGEN 操作 (CLUSTER_CONFIG_LAN.COM または CLUSTER_CONFIG.COM から開始される操作) は，ミニマム環境でしかもフィードバックなしで実行されるため，新たに追加されたコンピュータは OpenVMS Cluster 環境で実行するのに適切な構成になっていない可能性があります。この理由から， 第 8.7.3 項
および 第 8.7.4 項
で説明しているような追加の構成方式を実装しなければならないことがあります。
8.7.3 妥当なフィードバックの取得
コンピュータを最初に OpenVMS Cluster にブートする場合，コンピュータの多くのリソースの利用状況は，現在の OpenVMS Cluster 構成によって判断されます。コンピュータの数，ディスク・サーバの数，使用可能またはマウントされているディスクの数などは，一定の必要最低限のリソースとして解釈されます。この必要最低限のリソースは，コンピュータを継続的に使用しても変化しないため，必要なリソースに関するフィードバック情報は直ちに有効になります。
しかし，通常のユーザの活動によって影響を受ける情報など，他のフィードバック情報は，直ちには提供されません。これは，"ユーザ" だけがシステム・スタートアップ・プロセスだからです。この時点でフィードバック・オプション付きで AUTOGEN を実行しても，一部のシステム値は適切な値より低い値に設定される可能性があります。
最初のプロダクション・ブートの最後に，シミュレートされたユーザ負荷を実行することで，AUTOGEN は確実に妥当なフィードバック情報を活用できるようになります。オペレーティング・システムに添付されている UETP (User Environment Test Package) には，このような負荷をシミュレートするテストが含まれています。このテスト (UETP LOAD フェーズ) は初期プロダクション・ブートの一部として実行でき，その後，ユーザにログインを許可する前に，フィードバック付きで AUTOGEN を実行します。
この手法を実装するには， 第 8.7.4 項
の手順のステップ 1 に示したようなコマンド・ファイルを作成し，クラスタの共通 SYSTARTUP プロシージャからコンピュータのローカル・バッチ・キューにファイルを登録します。コマンド・ファイルは条件に応じて UETP LOAD フェーズを実行し，AUTOGEN フィードバックを実行してコンピュータをリブートします。
8.7.4 AUTOGEN を実行するためのコマンド・ファイルの作成
以下のサンプル・ファイルに示すように，UETP ではコンピュータが最初にクラスタに追加されるときに，そのコンピュータで実行される典型的なユーザ負荷を指定できます。 UETP を実行すると，フィードバック付きでコンピュータをリブートするときに，AUTOGEN がそのコンピュータの適切なシステム・パラメータ値を設定するのに必要なデータが生成されます。しかし，UETP のユーザ負荷のデフォルト設定では，コンピュータがタイムシェアリング・システムとして利用されると想定されています。この計算では，シングル・ユーザ・ワークステーションにとっては大きすぎるシステム・パラメータ値が求められる可能性があります。特に，ワークステーションに大きなメモリ・リソースが搭載されている場合は，計算される値が大きくなりすぎます。したがって，サンプル・ファイルに示すように，ユーザ負荷のデフォルト設定を変更しなければならない可能性があります。
以下の操作を行います。
$!
$! ***** SYS$COMMON:[SYSMGR]UETP_AUTOGEN.COM *****
$!
$! For initial boot only, run UETP LOAD phase and
$! reboot with AUTOGEN feedback.
$!
$ SET NOON
$ SET PROCESS/PRIVILEGES=ALL
$!
$! Run UETP to simulate a user load for a satellite
$! with 8 simultaneously active user processes. For a
$! CI connected computer, allow UETP to calculate the load.
$!
$ LOADS = "8"
$ IF F$GETDVI("PAA0:","EXISTS") THEN LOADS = ""
$ @UETP LOAD 1 'loads'
$!
$! Create a marker file to prevent resubmission of
$! UETP_AUTOGEN.COM at subsequent reboots.
$!
$ CREATE SYS$SPECIFIC:[SYSMGR]UETP_AUTOGEN.DONE
$!
$! Reboot with AUTOGEN to set SYSGEN values.
$!
$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT FEEDBACK
$!
$ EXIT
|
$!
$ NODE = F$GETSYI("NODE")
$ IF F$SEARCH ("SYS$SPECIFIC:[SYSMGR]UETP_AUTOGEN.DONE") .EQS. ""
$ THEN
$ SUBMIT /NOPRINT /NOTIFY /USERNAME=SYSTEST -
_$ /QUEUE='NODE'_BATCH SYS$MANAGER:UETP_AUTOGEN
$ WAIT_FOR_UETP:
$ WRITE SYS$OUTPUT "Waiting for UETP and AUTOGEN... ''F$TIME()'"
$ WAIT 00:05:00.00 ! Wait 5 minutes
$ GOTO WAIT_FOR_UETP
$ ENDIF
$!
|
注意: UETP は，SYSTEST というユーザ名のもとで実行しなければなりません。
コンピュータをブートすると，UETP_AUTOGEN.COM が実行されて，指定したユーザ負荷がシミュレートされ，次にフィードバック・オプション付きで AUTOGEN を実行してリブートが行われ，適切なシステム・パラメータ値が設定されます。
この章では，およそ 20 台またはそれ以上の多くのコンピュータを含む OpenVMS Cluster システムを構築する場合のガイドラインを示し，役立つプロシージャについても説明します (構成の制限については，『OpenVMS Cluster Software Software Product Description 』(SPD) を参照してください)。通常，このような OpenVMS Cluster システムには，多くのサテライトが含まれます。
この章で説明する手法は，20 台以下のコンピュータを含む一部のクラスタにとっても役立ちます。この章では，次のことについて説明します。
大規模なクラスタを新たに構築する場合，インストール時に数回 AUTOGEN を実行し，クラスタをリブートするように準備しなければなりません。クラスタに最初に追加されるコンピュータに対して AUTOGEN が設定するパラメータは，おそらく他のコンピュータを後で追加するときは適切ではありません。ブート・サーバとディスク・サーバに対して，パラメータの再調整が重要です。
この問題を解決するための 1 つの方法として，新しいコンピュータまたはストレージ・インターコネクトを追加するたびに，定期的に UETP_AUTOGEN.COM コマンド・プロシージャ ( 第 8.7.4 項 を参照) を実行して，コンピュータをリブートする方法があります。たとえば，コンピュータ，ストレージ，インターコネクトの数が 10% 増加するたびに，UETP_AUTOGEN.COM を実行します。最適な結果を得るには，最終的な OpenVMS Cluster 環境とできるだけ近い状態で，最後にプロシージャを実行する必要があります。
新しい大規模な OpenVMS Cluster を設定するには，以下の操作を行います。
| ステップ | 作業 |
|---|---|
| 1 | CLUSTER_CONFIG_LAN.COM または CLUSTER_CONFIG.COM コマンド・プロシージャを使用して，ブート・サーバとディスク・サーバを構成する ( 第 8 章 を参照)。 |
| 2 | OpenVMS Cluster 環境にとって必要なすべてのレイヤード製品とサイト固有のアプリケーションをインストールする。すべてをインストールできない場合は，できるだけ多くインストールする。 |
| 3 | 最終的な OpenVMS Cluster 環境で使用されるプロシージャとできるだけ近い状態になるように，クラスタ・スタートアップ・プロシージャを準備する。 |
| 4 | クラスタ構成コマンド・プロシージャを使用して，少数のサテライトを追加する (2〜3 台程度)。 |
| 5 | クラスタをリブートして，スタートアップ・プロシージャが予測どおりに動作することを確認する。 |
| 6 | スタートアップ・プロシージャが正しく動作することを確認した後，各コンピュータのローカル・バッチ・キューで UETP_AUTOGEN.COM を実行して，クラスタをリブートし，プロダクション環境の初期値を設定する。クラスタがリブートされると，すべてのコンピュータのパラメータの設定が妥当な設定になっているはずである。しかし，設定に問題がないかどうか確認する。 |
| 7 | サテライトを追加して，サテライトの台数を 2 倍にする。その後，各コンピュータのローカル・バッチ・キューで UETP_AUTOGEN を再実行して，クラスタをリブートし，新たに追加したサテライトに対応できるように，値を適切に設定する。 |
| 8 | すべてのサテライトが追加されるまで，上記のステップを繰り返す。 |
| 9 | すべてのサテライトが追加されたら，各コンピュータのローカル・バッチ・キューで UETP_AUTOGEN を最後にもう一度実行して，クラスタをリブートし，プロダクション環境の値を新たに設定する。 |
最適なパフォーマンスを実現するには，各コンピュータで同時に UETP_AUTOGEN を実行しないようにしなければなりません。そうすると，このプロシージャではユーザ負荷がシミュレートされますが，その値はおそらく，最終的なプロダクション環境の値より要求の厳しいものになるからです。このため，新しいコンピュータを追加するときに， UETP_AUTOGEN を複数のサテライト (少し前にパラメータを調整したサテライト) で実行するようにします。この手法を利用すると，サテライトがクラスタに追加された後，間もなく AUTOGEN を再実行しても，ほとんど設定が変化しないため，効率を向上できます。
たとえば，30 台のサテライトが追加された後，クラスタ全体をリブートすると，28 番目に追加されたサテライトに対しては，システム・パラメータ値があまり調整されません。これは，初期設定の一部としてそのサテライトが UETP_AUTOGEN を実行した後，2 台のサテライトだけがクラスタに追加されたからです。
9.2 ブートに関する一般的な考慮点
ここでは，ブートに関する 2 つの一般的な考慮点について説明します。それは，並列ブートとブート時間の最短化です。
9.2.1 並列ブート
OpenVMS Cluster のすべてのコンピュータが同時にアクティブになる状況はほとんどありませんが，クラスタのリブート時にはこのような状況が発生します。たとえば，電源障害が発生した後は，この状況が発生します。このような状況では，すべてのサテライトがオペレーティング・システムの再ロードを待っており，ブート・サーバが使用可能な状態になると，直ちに並列ブートが開始されます。このブートでは，1 つまたは複数のシステム・ディスク，インターコネクト，ブート・サーバに大きな I/O 負荷がかかります。
たとえば， 表 9_1 では，1 つのサテライトだけがブートされるときに，ミニマム・スタートアップ・プロシージャを使用して 1 つのサテライトのログインが行われるまでの， VAX システム・ディスクの I/O 動作と経過時間を示しています。 表 9-2 では， 1 つのシステム・ディスクから複数のサテライトがブートされる場合の，ブート・サーバの応答からログインまでのシステム・ディスクの I/O 動作と経過時間を示しています。これらの例で使用したディスクには， 1 秒間に 40 回の I/O 操作を実行できるキャパシティがあります。
この表に示した数字は，一般的なブート動作を示すための値であり，実際の値とは異なる可能性があります。特定のクラスタのサテライトでログインが完了するまでの時間は，サイト固有のシステム・スタートアップ・プロシージャがどの程度複雑であるかによって異なります。多くのレイヤード製品やサイト固有のアプリケーションを使用しているクラスタのコンピュータの場合は，ブート操作が完了するまでに，多くのシステム・ディスク I/O 操作を実行しなければなりません。
| システム・ディスクに対する I/O 要求の総数 | 1 秒間に実行されるシステム・ディスク I/O 操作の平均数 | ログインまでの時間 (分) |
|---|---|---|
| 4200 | 6 | 12 |
| サテライトの数 | 1 秒間に要求される I/O | 1 秒間にサービスされる I/O | ログインまでの時間 (分) |
|---|---|---|---|
| 1 | 6 | 6 | 12 |
| 2 | 12 | 12 | 12 |
| 4 | 24 | 24 | 12 |
| 6 | 36 | 36 | 12 |
| 8 | 48 | 40 | 14 |
| 12 | 72 | 40 | 21 |
| 16 | 96 | 40 | 28 |
| 24 | 144 | 40 | 42 |
| 32 | 192 | 40 | 56 |
| 48 | 288 | 40 | 84 |
| 64 | 384 | 40 | 112 |
| 96 | 576 | 40 | 168 |
表 9-2
に示した経過時間には，ブート・サーバ自体を再ロードするのに必要な時間は含まれていませんが，1 つのシステム・ディスクの I/O キャパシティがクラスタのリブート時間を制限する要素であることが示されています。
9.2.2 ブート時間の最短化
大規模なクラスタでは，適切な時間内に必要な数のノードをブートできるだけの十分なキャパシティを確保するように，注意深く構成する必要があります。 表 9-2 に示すように， 96 台のサテライトをリブートすると，I/O ボトルネックが発生する可能性があり，OpenVMS Cluster のリブート時間は数時間に及ぶ可能性があります。ブート時間をできるだけ短縮するには，以下の方法を利用します。
『Compaq OpenVMS Cluster 構成ガイド』には，コンピュータ，システム・ディスク，インターコネクトのキャパシティと構成に関するデータが示されています。
十分なシステム・ディスク・スループットを達成するには，通常，複数の手法を組み合わせる必要があります。詳細については， 第 9.5 節 を参照してください。
1 つの Ethernet だけで，大規模な OpenVMS Cluster の必要条件を満たすことができる十分な帯域幅を確保することはできません。同様に， 1 つの Ethernet アダプタだけでは，それがボトルネックになる可能性があり，特にディスク・サーバの場合はその可能性が高くなります。 表 9-3 のステップ 1 に示す手法を利用すれば，十分なネットワーク帯域幅を確保できます。
| 前へ | 次へ | 目次 | 索引 |