前へ | 次へ | 目次 | 索引 |
図 11-3 のようにシステム・ディスクを配置すると,ブート時間と LAN の利用率を下げることができます。
図 11-3 共通環境におけるマルチ・システム・ディスク
図 11-3 は,マルチ・システム・ディスクの OpenVMS Cluster です。
この構成におけるマルチ・システム・ディスクと,LAN セグメントの分割使用形態は,効率的でタイミングの良いブート・シーケンスを可能にします。
11.2.4 OpenVMS Cluster システムの分割
第 10.7 節 に示すワークステーション・サーバの例で,障害後の OpenVMS Cluster のリブートは比較的簡潔です。これはサーバ当たりのサテライト数が少ないためです。ただし, 図 11-3 に示す大規模な OpenVMS Cluster 構成のリブートは慎重に計画する必要があります。この項で説明する OpenVMS Cluster の分割とシステム・ディスクの配置により,ブート時間を大幅に節約できます。OpenVMS Cluster を分割すると,LAN セグメントのサテライトの利用率も低下し,サテライト・パフォーマンスが向上します。
この OpenVMS Cluster のディスクには, 表 11-2 に示すように決められた機能があります。
ディスク | 内容 | 目的 |
---|---|---|
共通ディスク | OpenVMS Cluster 全体のすべての環境ファイル | SYSUAF.DAT,NETPROXY.DAT,QMAN$MASTER.DAT などの環境ファイルは,ブート時に,サテライトを始めすべてのノードがアクセスできます。これにより,サテライト・ブート・サーバは,システム・ファイルとサテライトまでのルート情報だけを扱うことで済むようになります。
共通環境を作成し,すべてのシステム・ディスクのパフォーマンスを強化する方法については, 第 11.3 節 を参照してください。 |
システム・ディスク | Alpha 1,Alpha 2,Alpha 3 のシステム・ルート | サーバ・システムのパフォーマンスの強化。書き込み処理をする環境ファイルをこのシステム・ディスクから取り除き,このディスクをできるだけ読み込み専用にします。ディスクは,スタートアップ時に,SYLOGICALS.COM にクラスタ規模でマウントできます。 |
サテライト・ブート・サーバのシステム・ディスク | サテライト用のシステム・ファイルまたはルート | Alpha 1,Alpha 2,Alpha 3 に関連付けられたシステム・ディスクを解放し,サテライトのサービス専用とし,各 Ethernet セグメントの全 LAN トラフィックを分割します。 |
ページ・ディスクとスワップ・ディスク | 1 つ以上のシステムのページ・ファイルとスワップ・ファイル | システム・ディスクの I/O 処理を削減し,システム・ディスクの領域をアプリケーションとシステム・ルートに開放します。 |
図 11-3 に示す構成用のブート・シーケンスでは,共通ディスクのファイルをサテライトがアクセスできるよう,LAN Ethernet セグメントをブートする前に,ノード Alpha 1,Alpha 2,Alpha 3 がすべてブートされているか確認してください。サテライトが Alpha 1,Alpha 2,Alpha 3 のシステム・ディスクからブートしないよう, Ethernet-to-FDDI (10/100) ブリッジで MOP(Maintenance Operations Protocol) のフィルタリングを可能にしておきます。この OpenVMS Cluster をブートする順序は,次のとおりです。
関連項目: 拡張 LAN については, 第 10.7.6 項 を参照してください。
11.2.5 まとめ:シングル・システム・ディスク対マルチ・システム・ディスク
表 11-3 を参考に,全体のシステム・ディスクとマルチ・システム・ディスクのどちらを使用するか決定してください。
シングル・システム・ディスク | マルチ・システム・ディスク |
---|---|
システム・ディスクのファイルにアクセスするまでの待機時間が長くなることがある。 | 長く待たなくてもシステム・ディスクをファイルにアクセスでき,プロセッサ・パフォーマンスが高速である。 |
シングル・リソースの競合が多い。 | シングル・リソースの競合が少ない。 |
サテライトのブート時間が長い。 | サテライトのブート時間が短い。 |
管理するシステム・ディスクは 1 つだけである。 | 複数のシステム・ディスクを管理しなければならない。 |
システム管理がシンプルである。 | システム・パラメータやファイルのクラスタ規模での調整など,システム管理が複雑である。 |
ハードウェアとソフトウェアの経費が経済的である。 | ハードウェアとソフトウェアにより多くの経費がかかる。特にディスクをシャドウ化した場合。 |
シングル・システム・ディスクの管理には時間と経験があまり要求されないためシステム管理の経費が経済的である。 | マルチ・システム・ディスクの管理にはより多くの時間と経験が要求されるためシステム管理により多くの経費が要求される。 |
処理上のニーズに合わせて,共通環境とマルチ環境のどちらかを選択します。前者では,環境ファイルがクラスタ規模で共用され,後者では,クラスタ規模で共用されるファイルと,一定の OpenVMS Cluster メンバだけがアクセスできるファイルに分かれます。
以下に示すのは,最も頻繁に使用および操作される OpenVMS Cluster環境ファイルです。
SYS$SYSTEM:SYSUAF.DAT
SYS$SYSTEM:NETPROXY.DAT
SYS$SYSTEM:VMSMAIL_PROFILE.DATA
SYS$SYSTEM:NETNODE_REMOTE.DAT
SYS$MANAGER:NETNODE_UPDATE.COM
SYS$SYSTEM:RIGHTSLIST.DAT
SYS$SYSTEM:QMAN$MASTER.DAT
関連項目: これらのファイルの管理方法についての詳細は,『Compaq OpenVMS Cluster システム』を参照してください。
11.3.1 共通環境
共通 OpenVMS Cluster 環境は,OpenVMS Cluster の全ノードで共通な操作環境です。共通環境は,システム・ファイルを共通バージョンで使用できるため,マルチ環境より簡単に管理できます。環境は,以下のようにセットアップします。
最もシンプルで経済的な環境は, 図 11-1 に示すすべての環境ファイルを搭載した 1 つのシステム・ディスクだけで,OpenVMS Cluster に対応する方法です。この方法の長所は,以下のとおりです。
すべてのノードが同じシステム・ディスクを共用する OpenVMS Cluster の場合,ほとんどの共通環境ファイルは SYS$SYSTEM ディレクトリに配置します。
ただし,環境ファイルを別のディスクに移動して,OpenVMS Cluster のパフォーマンスを強化することもできます。一般に,環境ファイルの処理はシステム・ディスクの処理の 80% を占めるため,常駐ディスクを分散させればシステム・ディスクの負担が減ります。 図 11-3 は,分割された共通ディスクの例です。
SYSUAF.DAT などの環境ファイルを別の共通ディスクに移動すると,SYSUAF.DAT は, SYS$SYSTEM:SYSUAF.DAT のデフォルト・パスでは見つからなくなります。
関連項目: OpenVMS Cluster の全ノードが新しい場所にある SYSUAF.DAT にアクセスできるようにする方法については,『Compaq OpenVMS Cluster システム』を参照してください。
11.3.3 マルチ環境
マルチ環境は,ノードによって異なります。個々のノードやノード・サブセットは以下の目的でセットアップします。
図 11-4 は,マルチ環境の例です。
図 11-4 マルチ環境 OpenVMS Cluster
図 11-4 のマルチ環境 OpenVMS Cluster は,2 つのシステム・ディスクからなります。1 つは VAX ノード用であり,他の 1 つは Alpha ノード用です。共通ディスクには,各ノードやノード・グループ用の環境ファイルがあります。 OpenVMS Cluster システム管理者は,一般にシンプルなシングル (共通) 環境を好みますが,すべてのノードがリソースを共用するわけではないマルチ環境の作成時には環境ファイルの多重化が必要です。環境は,それぞれユーザが実行するタスクの種類と使用するリソースに応じて多様化でき,その構成にはさまざまなアプリケーションをインストールできます。
4 個の DSSI ノードのそれぞれが専用のページ・ディスクとスワップ・ディスクを持ち, DSSI インターコネクト上の Alpha システムと VAX システム・ディスクにおけるページ処理とスワップ処理の負荷を軽減しています。DSSI インターコネクト上のディスクはすべてシャドウ化され,障害の発生時にもディスクを保護することができます。
11.4 その他のマルチ環境の手法
この節では,複数のSYSUAF.DAT ファイルや複数のキュー・マネージャの使用方法など,その他のマルチ環境の手法について説明します。
11.4.1 複数の SYSUAF.DAT ファイルの使用
ほとんどの OpenVMS Clusterは,1 つのユーザ権限 (SYSUAF.DAT) ファイルで管理しますが,複数のユーザ権限ファイルを利用すれば,ユーザがアクセスできるシステムを限定することができます。この方法では,すべてのシステムのアクセスを必要とするユーザには複数のパスワードが必要になります。
複数の SYSUAF.DAT ファイルを運用する場合は,セキュリティに気をつけてください。 OpenVMS VAX および OpenVMS Alpha オペレーティング・システムでは,複数のセキュリティ・ドメインをサポートしていません。
関連項目: SYSUAF.DAT エントリなど,シングル・セキュリティ・ドメイン内では同一でなければならないフィールドの一覧については,『Compaq OpenVMS Cluster システム』を参照してください。
Alpha システムでは,多くのプロセス割り当て量が必要なため,システム管理者は複数の SYSUAF.DAT ファイルを用意して対応することがあります。しかし,これは最適な解決方法とは言えません。複数の SYSUAF.DAT ファイルを作成するのは,ノードによって環境を変えるためであり,プロセス割り当て量を増やすのが本来の目的ではありません。プロセス割り当て量を増やす方法としては,SYSUAF.DAT ファイルを 1 つとし, SYSUAF.DAT ファイルで指定したプロセス割り当て量を無効にするシステム・パラメータを使用して Alpha システムのリソースを管理する方法をお勧めします。
11.4.2 複数のキュー・マネージャの使用
OpenVMS Cluster におけるバッチ・トランザクションとプリント・トランザクションの数が多すぎて混雑している場合,複数のキュー・マネージャを実装してバッチとプリントの負荷をノード間に分散させることができます。
OpenVMS Cluster には,QMAN$MASTER.DAT ファイルを 1 つずつ配置します。複数のキュー・マネージャは,複数の*.QMAN$QUEUES ファイルと *.QMAN$JOURNAL ファイルで定義します。キュー・マネージャ・ファイルの各ペアを別々のディスクに配置します。 QMAN$MASTER.DAT ファイルにアクセスが集中するようであれば,半導体ディスクに常駐させて,OpenVMS Cluster が処理できるバッチ・トランザクションとプリント・トランザクションの数を増やします。たとえば,バッチ・キューとプリント・キューに別々のキュー・マネージャを作成できます。
関連項目: 複数のキュー・マネージャの実装例とコマンドについては,『Compaq OpenVMS システム管理者マニュアル (上巻)』を参照してください。
11.5 クォーラムの手法
OpenVMS Cluster システムは,クォーラム・アルゴリズムを利用してストレージのアクセスを同期します。クォーラム・アルゴリズムとは,OpenVMS Cluster システムでリソースを共用する方法を "決定する(ボートする)" 多数のOpenVMS Cluster メンバが存在するかどうかを確かめる数学的手法です。接続マネージャは,動的な値としてクォーラムを計算し,OpenVMS Cluster メンバの大半が機能しているときにだけ処理を実行します。
クォーラム・ボーツを決定する要素は次のとおりです。
各 OpenVMS Cluster システムには,クォーラム・ディスクを 1 つだけ配置できます。クォーラム・ディスクはシャドウ・セットのメンバにはできませんが,システム・ディスクにすることはできます。
接続マネージャは,"クォーラム・ディスク・ウォッチャ"からクォーラム・ディスクの情報を入手します。クォーラム・ディスク・ウォッチャは,クォーラム・ディスクとの間にアクティブな直接接続を持つ,任意のシステムです。
11.5.1 クォーラム手法のオプション
クォーラム・ディスクには,少なくとも直接接続を持つシステムが 2 つ必要です。これによってシステムのどちらかに障害が発生しても,クォーラム・ディスク・ボーツにアクセスできます。
クォーラム手法を検討するにあたり,どのような障害状況のときに OpenVMS Cluster の処理を続行するかを決めておく必要があります。 表 11-4 は,その 4 つのオプションを示したものです。
手法のオプション1 | 説明 |
---|---|
"予想"最高ノード数が残っていれば,処理を続行する。 | すべてのノードにボーツを与え,クォーラム・ディスクは使用しません。この手法では,ノードが 3 個以上必要です。 |
(3 つ以上のノードの内) ノードが 1 つでも残っていれば,処理を続行する。 | この手法では,クォーラム・ディスクが必要です。
全システムのボーツ合計数より 1 つ少ない値までクォーラム・ディスクのボーツ数を増やすと (また,EXPECTED_VOTES システム・パラメータの値も同じだけ増やす),ノードが 1 つだけのクラスタをクォーラム・ディスク・ウォッチャとして実行できます。この場合,ボーツ・システムの過半数になるまで待たなくても OpenVMS Cluster システムを利用できます。 |
(2 ノード OpenVMS Cluster) ノードが 1 つでも残っていれば,処理を続行する。 | 各ノードとクォーラム・ディスクにボーツを与えます。
2 ノード OpenVMS Cluster は,特別な事例です。クォーラム・ディスクを確立すると, 2 ノード OpenVMS Cluster の可用性を強化できます。このような構成では,クォーラム・ディスクまたは 1 ノードが故障してもクォーラムを維持し運用を続行することができます。この場合,両方のノードが,両方ともクォーラム・ディスク・ウォッチャになるように, (CI,DSSI,SCSI,または Fibre Channel によって) ストレージに直接接続される必要があります。 |
OpenVMS Cluster の重要ノードが 1 つでも処理を続行する。 | 一般に,この手法では,サーバにはボーツが与えられ,サテライトには与えられません。 3 つ以上のサーバがあり,クォーラム・ディスクがないことが前提です。 |
関連項目: クォーラム・ディスク管理の詳細については,『Compaq OpenVMS Cluster システム』を参照してください。
前へ | 次へ | 目次 | 索引 |