日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:OpenVMS Cluster システムの管理の概要
第 2 章:OpenVMS Cluster の概念
第 3 章:OpenVMS Cluster インターコネクト構成
第 4 章:OpenVMS Cluster オペレーティング環境
第 5 章:共用環境の準備
第 6 章:クラスタ・ストレージ・デバイス
第 7 章:クラスタ・キューの設定と管理
第 8 章:OpenVMS Cluster システムの構成
第 9 章:大規模な OpenVMS Cluster システムの構築
第 10 章:OpenVMS Cluster システムの保守
付録 A :クラスタ・システム・パラメータ
付録 B :共通ファイルの作成
付録 C :クラスタのトラブルシューティング
付録 D :LAN 制御のためのサンプル・プログラム
付録 E :LAN 制御のためのサブルーチン
付録 F :NISCA プロトコルのトラブルシューティング
付録 G :NISCA トランスポート・プロトコル・チャネル選択および輻輳制御
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本

OpenVMS
OpenVMS Cluster システム


目次 索引

第 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 を設定するには,以下の操作を行います。

ステップ 作業
  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 つの一般的な考慮点について説明します。それは,並列ブートとブート時間の最短化です。

OpenVMS Cluster のすべてのコンピュータが同時にアクティブになる状況はほとんどありませんが,クラスタのリブート時にはこのような状況が発生します。たとえば,電源障害が発生した後は,この状況が発生します。このような状況では,すべてのサテライトがオペレーティング・システムの再ロードを待っており,ブート・サーバが使用可能な状態になると,直ちに並列ブートが開始されます。このブートでは,1 つまたは複数のシステム・ディスク,インターコネクト,ブート・サーバに大きな I/O 負荷がかかります。

たとえば, 表 9-1 では,1 つのサテライトだけがブートされるときに,ミニマム・スタートアップ・プロシージャを使用して 1 つのサテライトのログインが行われるまでの, VAX システム・ディスクの I/O 動作と経過時間を示しています。 表 9-2 では, 1 つのシステム・ディスクから複数のサテライトがブートされる場合の,ブート・サーバの応答からログインまでのシステム・ディスクの I/O 動作と経過時間を示しています。これらの例で使用したディスクには, 1 秒間に 40 回の I/O 操作を実行できるキャパシティがあります。

この表に示した数字は,一般的なブート動作を示すための値であり,実際の値とは異なる可能性があります。特定のクラスタのサテライトでログインが完了するまでの時間は,サイト固有のシステム・スタートアップ・プロシージャがどの程度複雑であるかによって異なります。多くのレイヤード製品やサイト固有のアプリケーションを使用しているクラスタのコンピュータの場合は,ブート操作が完了するまでに,多くのシステム・ディスク I/O 操作を実行しなければなりません。

表 9-1 1 台の VAX サテライトのシステム・ディスクの I/O 動作とブート時間の例
システム・ディスクに対する I/O 要求の総数 1 秒間に実行されるシステム・ディスク I/O 操作の平均数 ログインまでの時間 (分)
4200 6 12

表 9-2 複数の VAX サテライトの場合のシステム・ディスクの I/O 動作とブート時間の例
サテライトの数 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 構成ガイド』には,コンピュータ,システム・ディスク,インターコネクトのキャパシティと構成に関するデータが示されています。

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

  • 十分なネットワーク帯域幅
    1 つの Ethernet だけで,大規模な OpenVMS Cluster の必要条件を満たすことができる十分な帯域幅を確保することはできません。同様に, 1 つの Ethernet アダプタだけでは,それがボトルネックになる可能性があり,特にディスク・サーバの場合はその可能性が高くなります。 表 9-3 のステップ 1 に示す手法を利用すれば,十分なネットワーク帯域幅を確保できます。

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



9.3 サテライトのブート

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 の項目を参照してください。

表 9-3 サテライト・ブートのためのチェックリスト
ステップ 操作
1 ディスク・サーバ LAN アダプタを構成する。

OpenVMS Cluster システムでは,ディスクをサービスするための動作によって LAN にかなりの量の I/O トラフィックが発生するため,ブート・サーバとディスク・サーバはクラスタ内で帯域幅の最も広いアダプタを使用しなければならない。また, LAN アダプタ間で負荷を分散するために,サーバは 1 つのシステムで複数の LAN アダプタを使用することもできる。

十分なネットワーク帯域幅を提供するには,以下の方法を利用する。

  • 十分な帯域幅を持つネットワーク・アダプタを選択する。

  • トラフィックを分けて,合計帯域幅を増やすためにスイッチを使用する。

  • MOP およびディスク・サーバで複数の LAN アダプタを使用する。

  • スイッチまたはより高速な LAN を使用し,低速 LAN セグメントに展開する。

  • 複数の個別ネットワークを使用する。

  • 十分なパワーを備えたコンピュータを選択し,複数のサーバ・ノードを構成して負荷を共用することで,十分な MOP およびディスク・サーバの CPU キャパシティを提供する。

2 MOP サーバ・ノードとシステム・ディスク・サーバ・ノード (Alpha または VAX) がクラスタ・メンバとしてまだ構成されていない場合は, 第 8.4 節 の説明に従って,クラスタ構成コマンド・プロシージャを使用して,各 VAX ノードまたは各 Alpha ノードを構成する。複数のブート・サーバとディスク・サーバを使用して,可用性を向上し,複数のクラスタ・ノードに I/O トラフィックを分散する。
3 ディスクをサービスするために追加メモリを構成する。
4 OpenVMS Cluster にブートする各サテライトに対して, Alpha ノードまたは VAX ノードでクラス構成プロシージャを実行する。



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

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


>>> BOOT LAN-adapter-device-name 

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

会話型ブートを実行しなければならない場合は,以下の表に示すコマンドを使用します。

システム 操作
Alpha システム Alpha システム・コンソール・プロンプト (>>>) に対して,以下のコマンドを入力する。
>>> b -flags 0,1 eza0

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

  • システム・ルート番号

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

  • 会話型ブート・フラグ

    "1" は,ブートを会話方式で行わなければならないことを示す。

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

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

VAX システム VAX システム・コンソール・プロンプト (>>>) に対して,ブート・コマンドに完全なデバイス名を指定する。
>>>B/R5=1 XQB0

正確な構文は,システムの種類に応じて異なる。システムのハードウェア・ユーザ・ガイドを参照。

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

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

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



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

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

システム 操作
Alpha システム SHOW CONFIG コンソール・コマンドを使用して,追加アダプタの LAN アドレスを確認する。
VAX システム 以下の方法を使用して,追加アダプタの LAN アドレスを確認する。

  • コンソール・コマンド SHOW ETHERNET を入力する。

  • 以下のコマンドを使用して,READ_ADDR プログラムをブートする。
    >>>B/100 XQB0
    
    Bootfile:READ_ADDR


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項