OpenVMS マニュアル

第 9 章
大規模な OpenVMS Cluster システムの構築

この章では，およそ 20 台またはそれ以上の多くのコンピュータを含む OpenVMS Cluster システムを構築する場合のガイドラインを示し，役立つプロシージャについても説明します (構成の制限については，『OpenVMS Cluster Software Software Product Description』(SPD) を参照してください)。通常，このような OpenVMS Cluster システムには，多くのサテライトが含まれます。

この章で説明する手法は，20 台以下のコンピュータを含む一部のクラスタにとっても役立ちます。この章では，次のことについて説明します。

• ブート

• MOP およびディスク・サーバの可用性

• 複数のシステム・ディスク

• 共用リソースの可用性

• ホット・システム・ファイル

• システム・ディスク領域

• システム・パラメータ

• ネットワークの問題

• クラスタ・エイリアス

9.1 クラスタの設定

大規模なクラスタを新たに構築する場合，インストール時に数回 AUTOGEN を実行し，クラスタをリブートするように準備しなければなりません。クラスタに最初に追加されるコンピュータに対して AUTOGEN が設定するパラメータは，おそらく他のコンピュータを後で追加するときは適切ではありません。ブート・サーバとディスク・サーバに対して，パラメータの再調整が重要です。

この問題を解決するための 1 つの方法として，新しいコンピュータまたはストレージ・インターコネクトを追加するたびに，定期的に UETP_AUTOGEN.COM コマンド・プロシージャ ( 第 8.7.4 項 を参照) を実行して，コンピュータをリブートする方法があります。たとえば，コンピュータ，ストレージ，インターコネクトの数が 10% 増加するたびに，UETP_AUTOGEN.COM を実行します。最適な結果を得るには，最終的な OpenVMS Cluster 環境とできるだけ近い状態で，最後にプロシージャを実行する必要があります。

新しい大規模な OpenVMS Cluster を設定するには，以下の操作を行います。

最適なパフォーマンスを実現するには，各コンピュータで同時に UETP_AUTOGEN を実行しないようにしなければなりません。そうすると，このプロシージャではユーザ負荷がシミュレートされますが，その値はおそらく，最終的なプロダクション環境の値より要求の厳しいものになるからです。このため，新しいコンピュータを追加するときに， UETP_AUTOGEN を複数のサテライト (少し前にパラメータを調整したサテライト) で実行するようにします。この手法を利用すると，サテライトがクラスタに追加された後，間もなく AUTOGEN を再実行しても，ほとんど設定が変化しないため，効率を向上できます。

たとえば，30 台のサテライトが追加された後，クラスタ全体をリブートすると，28 番目に追加されたサテライトに対しては，システム・パラメータ値があまり調整されません。これは，初期設定の一部としてそのサテライトが UETP_AUTOGEN を実行した後，2 台のサテライトだけがクラスタに追加されたからです。

9.2 ブートに関する一般的な考慮点

9.2.1 並列ブート

並列ブートは，電源あるいはサイト障害が発生した後にすべてのノードが同時にリブートすることにより発生します。この結果，インターコネクト上で顕著な I/O 負荷が発生します。また，同期化に SCS トラフィックが必要とされるため，ネットワーク上の処理が増えることになります。すべてのサテライトがオペレーティング・システムをリロードしようとするので，ブートサーバが利用可能になると一斉にブートが始まり負荷が高まります。このためログインできるようになるまでに時間がかかることがあります。

9.2.2 ブート時間の最短化

大規模なクラスタでは，適切な時間内に必要な数のノードをブートできるだけの十分なキャパシティを確保するように，注意深く構成する必要があります。 96 台のサテライトをリブートすると，I/O ボトルネックが発生する可能性があり，OpenVMS Cluster のリブート時間は数時間に及ぶ可能性があります。ブート時間をできるだけ短縮するには，以下の方法を利用します。

• 注意深い構成手法
  『OpenVMS Cluster 構成ガイド』には，コンピュータ，システム・ディスク，インターコネクトのキャパシティと構成に関するデータが示されています。

• 適切なシステム・ディスク・スループット
  十分なシステム・ディスク・スループットを達成するには，通常，複数の手法を組み合わせる必要があります。詳細については， 第 9.7 節 を参照してください。

• 十分なネットワーク帯域幅
  1 つの Gigabit Ethernet だけで，大規模な OpenVMS Cluster の必要条件を満たすことができる十分な帯域幅を確保することはできません。同様に， 1 つの Gigabit Ethernet アダプタだけでは，それがボトルネックになる可能性があり，特にディスク・サーバの場合はアプリケーションによる同期化で負荷が高い場合，その可能性が高くなります。この結果，SCS トラフィックが高くなります。 SCS 用のアダプタを増やすと，この種の帯域幅の制限を解決することができます。
  表 9-2 の手順 1 に示す手法を利用すれば，十分なネットワーク帯域幅を確保できます。

• 必要なレイヤード製品とデバイスだけのインストール

9.2.3 Cluster over IP におけるブートに関する一般的な考慮事項

OpenVMS クラスタは，クラスタ内の他のノードとの通信および SCS トラフィックの受け渡しに TCP/IP を使用することができます。クラスタ通信に TCP/IP を使用するためには，そのようにノードを構成する必要があります。 Cluster over IP を使用するように OpenVMS ノードを構成する方法については， 第 8.2.3.1 項 を参照してください。この機能を有効にした後，ブート初期段階で TCP/IP がロードされます。 OpenVMS エグゼクティブは，クラスタ内の他のノードと SCS メッセージを交換できるようにブート処理の早い段階で TCP/IP execlet をロードするように修正されています。この機能は，ブート時にロードされる構成ファイルも使用します。これらの構成ファイルは構成時に正しく生成されたものであることを確認してください。ブート時の注意事項を以下に示します。

• クラスタ内の他のノードと TCP/IP 接続が可能であることを確認してください。

• クラスタで使用する IP マルチキャスト・アドレスでルーティング可能なことを確認してください。

• IP ユニキャストを使用する場合，そのノードの IP アドレスがすべてのノードの PE$IP_CONFIG.DAT ファイルに登録されていることを確認してください (新しい IP アドレスのロードには MC SCACP RELOAD コマンドを使用します)。

9.3 サテライトのブート

OpenVMS Cluster のサテライト・ノードは，ブートの初期段階で 1 つの LAN アダプタを使用します。サテライトが複数の LAN アダプタを使用するように構成されている場合は，システム管理者はコンソール BOOT コマンドを使用して，ブートの初期段階でどのアダプタを使用するかを指定できます。システムが起動されたら，OpenVMS Cluster は使用可能なすべての LAN アダプタを使用します。このように柔軟性があるため，アダプタが故障したり，ネットワークで問題が発生しても，適切に対応することができます。

Alpha および Integrity クラスタ・サテライトではネットワーク・ブート・デバイスは LAN Failover Set のプロスペクティブ・メンバにはなれません。たとえば，EWA および EWB で構成される LAN Failover Set，LLA を作成した場合，システム・ブート時にアクティブにするためには， LAN デバイス EWA あるいは EWB 経由でサテライトとしてシステムをブートすることはできません。

サテライト・ノードの構成およびブートのためのプロシージャとユーティリティは，Integrity システムと Alpha システムで異なります。

9.3.1 Alpha サテライトと Integrity サーバ・サテライトの違い

Alpha サテライトと Integrity サーバ・サテライトとの相違点を 表 9-1 に示します。

表 9-1 Alpha サテライトと Integrity サーバ・サテライトの違い

	Alpha	Integrity サーバ
ブート・プロトコル	MOP	PXE(BOOTP/DHCP/TFTP)
クラッシュ・ダンプ	リモート・システム・ディスクへのクラッシュ・ダンプ，あるいはDOSD (Dump Off the System Disk) によりローカル・ディスクへのクラッシュ・ダンプが可能。	DOSD を必要とする。リモート・ディスクへのクラッシュ・ダンプは不可。
エラー・ログ・バッファ	リモート・システム・ディスクへ常に書き込む。	エラー・ログ・バッファは DOSD と同じディスクに書き込まれる。
ファイル・プロテクション	標準のシステム・ディスクと違いは無い。	すべてのロード可能 execlet が W:RE (デフォルト) で，特定のファイルはVMS$SATELLITE_ACCESS 識別子による ACL アクセスを持つ。

9.4 サテライト・ノードの構成とブート

サテライトのブートを行う場合は，以下の 表 9-2 の項目を参照してください。

表 9-2 サテライト・ブートのためのチェックリスト

手順	操作
1	ディスク・サーバ LAN アダプタを構成する。 OpenVMS Cluster システムでは，ディスクをサービスするための動作によって LAN にかなりの量の I/O トラフィックが発生するため，ブート・サーバとディスク・サーバはクラスタ内で帯域幅の最も広いアダプタを使用しなければならない。また， LAN アダプタ間で負荷を分散するために，サーバは 1 つのシステムで複数の LAN アダプタを使用することもできる。 十分なネットワーク帯域幅を提供するには，以下の方法を利用する。 十分な帯域幅を持つネットワーク・アダプタを選択する。 トラフィックを分けて，合計帯域幅を増やすためにスイッチを使用する。 MOP およびディスク・サーバで複数の LAN アダプタを使用する。 スイッチまたはより高速な LAN を使用し，低速 LAN セグメントに展開する。 複数の個別ネットワークを使用する。 十分なパワーを備えたコンピュータを選択し，複数のサーバ・ノードを構成して負荷を共用することで，十分な MOP およびディスク・サーバの CPU キャパシティを提供する。
2	MOP サーバ・ノードとシステム・ディスク・サーバ・ノードがクラスタ・メンバとしてまだ構成されていない場合は， 第 8.4 節 の説明に従って，クラスタ構成コマンド・プロシージャを使用して，各 Alpha ノードを構成する。複数のブート・サーバとディスク・サーバを使用して，可用性を向上し，複数のクラスタ・ノードに I/O トラフィックを分散する。
3	ディスクをサービスするために追加メモリを構成する。
4	OpenVMS Cluster にブートする各サテライトに対して， Alpha ノードでクラス構成プロシージャを実行する。

9.4.1 1 つの LAN アダプタからのブート

サテライトをブートするには，以下のコマンドを入力します。

>>> BOOT LAN-adapter-device-name

この例で，LAN-adapter-device-name には，有効な LAN アダプタ名を指定します。たとえば，EZA0 や XQB0 を指定できます。

会話型ブートを実行しなければならない場合は， Alpha システム・コンソール・プロンプト (>>>) に対して以下のコマンドを入力します。

>>> b -flags 0,1 eza0

この例で，-flags は flags コマンド・ライン修飾子を表しており，値は以下のいずれかである。

• システム・ルート番号
  "0" は，システム・ルート [SYS0] からブートするようにコンソールに指示する。サテライト・ノードをブートする場合は，ブート・ノードのネットワーク・データベースからシステム・ルートが取り込まれるため，この指定は無視される。

• 会話型ブート・フラグ
  "1" は，ブートを会話方式で行わなければならないことを示す。

引数 eza0 は，ブートのために使用する LAN アダプタである。

最後に，このブート・コマンド・ラインにロード・ファイルが指定されていないことに注意する必要がある。サテライト・ブートの場合，ロード・ファイルは DECnet または LANCP データベースのノード記述の一部である。

ブートが失敗した場合は，以下の操作を行います。

• 構成で認められていて，ネットワーク・データベースが正しく設定されている場合は，別の LAN アダプタを使用してブート・コマンドを再入力します ( 第 9.4.4 項 を参照)。

• サテライト・ブートの問題の解決方法については， 付録 C.2.5 項 を参照してください。

9.4.2 デフォルト・ブート・アダプタの変更

デフォルト・ブート・アダプタを変更するには，代替 LAN アダプタの物理アドレスが必要です。このアドレスを使用して，MOP サーバの DECnet または LANCP データベースのサテライトのノード定義を更新して，サテライトが認識されるようにします ( 第 9.4.4 項 を参照)。追加する LAN アダプタを見つけるには SHOW CONFIG コマンドを使用します。

9.4.3 複数の LAN アダプタからのブート (Alpha のみ)

Alpha システムでは，ブートのために複数の LAN アダプタを使用することで，可用性を向上できます。これは，MOP サーバおよびディスク・サーバへのアクセスが異なる LAN アダプタを介して可能になるからです。複数のアダプタ・ブートを使用するには，以下の表に示す操作を実行します。

手順	操作
1	追加 LAN アダプタの物理アドレスを取得する。
2	これらのアドレスを使用して，一部の MOP サーバの DECnet または LANCP データベースに格納されているノード定義を更新して，サテライトが認識されるようにする ( 第 9.4.4 項 を参照)。
3	サテライトが DECnet データベースにすでに定義されている場合は，手順 4 を実行する必要がない。サテライトが DECnet データベースに定義されていない場合は， Alpha ネットワーク・データベースに SYS$SYSTEM:APB.EXE ダウンライン・ロード・ファイルを指定する。
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 を参照)。

---

目次

索引