| 前へ | 次へ | 目次 | 索引 |
この章では，およそ 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 のリブート時間は数時間に及ぶ可能性があります。ブート時間をできるだけ短縮するには，以下の方法を利用します。
OpenVMS Cluster のサテライト・ノードは，ブートの初期段階で 1 つの LAN アダプタを使用します。サテライトが複数の LAN アダプタを使用するように構成されている場合は，システム管理者はコンソール BOOT コマンドを使用して，ブートの初期段階でどのアダプタを使用するかを指定できます。システムが起動されたら，OpenVMS Cluster は使用可能なすべての LAN アダプタを使用します。このように柔軟性があるため，アダプタが故障したり，ネットワークで問題が発生しても，適切に対応することができます。
サテライト・ノードの構成およびブートのためのプロシージャとユーティリティは，Alpha システムの場合も VAX システムの場合も同じであるか，またはわずかに異なるだけです。詳細については， 第 9.4 節 を参照してください。
さらに，VAX ノードは Alpha サテライトを MOP ロードすることができ，Alpha ノードは VAX サテライトを MOP ロードすることができます。クロスアーキテクチャ・ブートについては，
第 10.5 節 を参照してください。
9.4 サテライト・ノードの構成とブート
サテライトのブートを行う場合は，以下の 表 9-3 の項目を参照してください。
| ステップ | 操作 |
|---|---|
| 1 | ディスク・サーバ LAN アダプタを構成する。
OpenVMS Cluster システムでは，ディスクをサービスするための動作によって LAN にかなりの量の I/O トラフィックが発生するため，ブート・サーバとディスク・サーバはクラスタ内で帯域幅の最も広いアダプタを使用しなければならない。また， LAN アダプタ間で負荷を分散するために，サーバは 1 つのシステムで複数の LAN アダプタを使用することもできる。 十分なネットワーク帯域幅を提供するには，以下の方法を利用する。
|
| 2 | MOP サーバ・ノードとシステム・ディスク・サーバ・ノード (Alpha または VAX) がクラスタ・メンバとしてまだ構成されていない場合は， 第 8.4 節 の説明に従って，クラスタ構成コマンド・プロシージャを使用して，各 VAX ノードまたは各 Alpha ノードを構成する。複数のブート・サーバとディスク・サーバを使用して，可用性を向上し，複数のクラスタ・ノードに I/O トラフィックを分散する。 |
| 3 | ディスクをサービスするために追加メモリを構成する。 |
| 4 | OpenVMS Cluster にブートする各サテライトに対して， Alpha ノードまたは VAX ノードでクラス構成プロシージャを実行する。 |
サテライトをブートするには，以下のコマンドを入力します。
>>> BOOT LAN-adapter-device-name |
この例で，LAN-adapter-device-name には，有効な LAN アダプタ名を指定します。たとえば，EZA0 や XQB0 を指定できます。
会話型ブートを実行しなければならない場合は，以下の表に示すコマンドを使用します。
ブートが失敗した場合は，以下の操作を行います。
デフォルト・ブート・アダプタを変更するには，代替 LAN アダプタの物理アドレスが必要です。このアドレスを使用して，MOP サーバの DECnet または LANCP データベースのサテライトのノード定義を更新して，サテライトが認識されるようにします ( 第 9.4.4 項 を参照)。
| システム | 操作 |
|---|---|
| Alpha システム | SHOW CONFIG コンソール・コマンドを使用して，追加アダプタの LAN アドレスを確認する。 |
| VAX システム | 以下の方法を使用して，追加アダプタの LAN アドレスを確認する。
|
| 前へ | 次へ | 目次 | 索引 |