前へ | 次へ | 目次 | 索引 |
3 台のコンピュータで構成されるクラスタがあり,各コンピュータの VOTES パラメータが 1 に設定され, EXPECTED_VOTES パラメータが 3 に設定されているとします。接続マネージャはクラスタ・クォーラム値を動的に計算して, 2 という値を求めます (つまり,(3 + 2)/2)。この例では, 3 台のコンピュータのうち,2 台のコンピュータでクォーラムが構成されるので,3 台目のコンピュータが存在しなくても,他の 2 台は稼動できます。1 台のコンピュータだけでクォーラムを満たすことはできません。したがって,3 台の OpenVMS Cluster コンピュータをパーティションに分割して, 2 つの独立したクラスタとして実行することはできません。
2.3.7 クォーラム・ディスク
クラスタ・システム管理者はディスクを クォーラム・ディスクとして指定できます。クォーラム・ディスクは,クラスタのボーツの総数に 1 票を追加するための,仮想クラスタ・メンバとして動作します。クォーラム・ディスクを設定することで,2 つのノードで構成されるクラスタの可用性を向上できます。このような構成では,クォーラム・ディスクまたは 1 台のノードで障害が発生しても,クォーラムを維持することができるため,操作を続行できます。
注意: クォーラム・ディスクは,2 つのノードで構成される OpenVMS Cluster システムのみに設定するようにしてください。 3 つ以上のノードを含む構成では,クォーラム・ディスクは必要ではなく,お勧めもしません。
たとえば,多くのサテライト (ボーツ数は 0 ) と,サテライトをダウンライン・ロードする 2 つの非サテライト・システム (それぞれボーツ数が 1) から成る OpenVMS Cluster 構成について考えてみましょう。クォーラムは以下のように計算されます。
(EXPECTED VOTES + 2)/2 = (2 + 2)/2 = 2 |
クォーラム・ディスクがないため,どちらか一方の非サテライト・システムがクラスタから削除されると,ボーツの総数が 1 になってしまうので,クラスタ・クォーラムを満たすことができません。クォーラムが復元されるまで,クラスタ全体で動作が実行されなくなります。
しかし,構成にクォーラム・ディスクが含まれており (クラスタのボーツの総数に 1 票を加算),各ノードで EXPECTED_VOTES パラメータが 3 に設定されている場合,いずれか一方のノードがクラスタから削除されても,クォーラムはまだ 2 になります。この場合,クォーラムは以下のように計算されます。
(EXPECTED VOTES + 2)/2 = (3 + 2)/2 = 2 |
規則: 各 OpenVMS Cluster システムには,クォーラム・ディスクを 1 つだけ含むことができます。少なくとも 1 台のコンピュータがクォーラム・ディスクに直接 (サービスを介してではなく) 接続されていなければなりません。
関連項目: クォーラム・ディスクを有効にする方法についての詳細は, 第 8.2.4 項 を参照してください。クォーラム・ディスクの削除については,
第 8.3.2 項 を参照してください。
2.3.8 クォーラム・ディスク・ウォッチャ
コンピュータをクォーラム・ディスク・ウォッチャとして有効にするには,以下のいずれかの方法を使用します。
方法 | 手順 |
---|---|
CLUSTER_CONFIG.COM プロシージャを実行する。
( 第 8 章 を参照) |
プロシージャを起動し,以下の操作を実行する。
プロシージャは入力された情報を使用して,DISK_QUORUM および QDSKVOTES システム・パラメータの値を更新する。 |
OpenVMS インストール・プロシージャからクラスタにクォーラム・ディスクが含まれているかどうか質問されたら,YES と応答する。
( 第 4 章 を参照) |
インストール・プロシージャで,以下の操作を実行する。
プロシージャは,入力された情報を使用して, DISK_QUORUM および QDSKVOTES システム・パラメータの値を更新する。 |
MODPARAMS または AGEN$ ファイルを編集する。( 第 8 章 を参照) | 以下のパラメータを変更する。
|
ヒント: 1 つのクォーラム・ディスク・ウォッチャだけがクォーラム・ディスクに直接アクセスできる場合は,ディスクを削除し,そのボーツ数をノードに与えます。
2.3.9 クォーラムの指定の規則
クラスタのボーツの総数でカウントされるクォーラム・ディスクのボーツ数に関しては,以下の条件を満たさなければなりません。
ヒント: クォーラム・ディスクのボーツ数を両方のシステムからのボーツの総数より 1 だけ少なくなるように増加すれば (さらに EXPECTED_VOTES システム・パラメータの値を同じ数だけ増加すれば),1 つのノードだけでクラスタをブートし,稼動させることができます。
2.4 状態遷移
OpenVMS Cluster の状態遷移は,コンピュータが OpenVMS Cluster システムに追加される場合やシステムから削除される場合に発生し,クラスタがクォーラム・ディスクの状態の変化を認識したときにも発生します。接続マネージャはこれらのイベントを制御し,クラスタ全体でデータの整合性を維持します。
状態遷移の期間とユーザ (アプリケーション) に与える影響は,状態遷移が発生した理由,システム構成,使用しているアプリケーションによって異なります。
2.4.1 メンバの追加
すべての遷移は 1 つ以上のフェーズを通過しますが,通過するフェーズの数は,OpenVMS Cluster にメンバを追加したために状態遷移が発生したのか,現在のメンバで障害が発生したのかに応じて異なります。
表 2-2 では,新しいメンバを追加することによって発生した状態遷移のフェーズを説明しています。
フェーズ | 説明 |
---|---|
新しいメンバの検出 | ブート・シーケンスの初期段階で,OpenVMS Cluster システムのメンバになりたいコンピュータは,クラスタへの追加を求めるメッセージを現在のメンバに送信する。メンバシップ要求を受信した最初のクラスタ・メンバは,新しいコンピュータの代言者として機能し,そのコンピュータをクラスタに含むようにクラスタの再構成を提案する。新しいコンピュータがブートされている間,アプリケーションに影響はない。
注意: ノードの EXPECTED_VOTES の値が,計算されたボーツ数より大きなクォーラムになるように再調整され,OpenVMS Cluster の動作が停止される場合は,接続マネージャは,そのコンピュータが OpenVMS Cluster システムに追加されることを許可しない。 |
再構成 | OpenVMS Cluster にコンピュータが追加されたために,構成が変化する場合は,現在のすべての OpenVMS Cluster メンバは,構成が変更されている間に新しいコンピュータとの通信を確立しなければならない。通信が確立された後,新しいコンピュータのクラスタへの追加が許可される。場合によっては,ロック・データベースが再構築される。 |
表 2-3 では,現在の OpenVMS Cluster メンバの障害によって発生する状態遷移のフェーズを説明しています。
原因 | 説明 | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
障害の検出 | このフェーズの期間は,障害の原因と,障害がどのような方法で検出されたかに応じて異なる。
通常のクラスタ操作では,あるコンピュータから別のコンピュータに送信されたメッセージは,受信時に確認される。
|
||||||||||||||||||
修復の試行 | OpenVMS Cluster メンバに対する仮想サーキットが切断されると,パスを修復しようという試みが行われる。修復の試行は, PAPOLLINTERVAL システム・パラメータに指定された間隔で続行される (システム管理者は,それぞれの条件に適合するようにこのパラメータの値を調整できる)。修復できない場合は,修復できないほどパスが破壊されているものと解釈される。その場合,すべてのコンピュータが相互に通信し,通信できないコンピュータが OpenVMS Cluster から削除されるように, OpenVMS Cluster システムを再構成するための手順を実行しなければならない。 | ||||||||||||||||||
再構成 | クラスタ・メンバがシャットダウンされるか,または障害が発生すると,クラスタを再構成しなければならない。残りのコンピュータのいずれかがコーディネータとして機能し,他のすべてのクラスタ・メンバとの間でメッセージを交換して,メンバ数とボーツ数を最大に維持できるように,最適なクラスタ構成が判断される。このフェーズでは,すべてのユーザ (アプリケーション) の動作が停止される。このフェーズは通常 3 秒未満で終了するが,実際の時間は構成に応じて異なる。 | ||||||||||||||||||
OpenVMS Cluster システムの回復 | 回復には以下のステージが含まれるが,一部のステージは並列に実行できる。
|
||||||||||||||||||
アプリケーションの回復 | 状態遷移がアプリケーション・ユーザに与える影響を評価する場合,アプリケーション回復フェーズにジャーナル・ファイルの再実行,回復ユニットのクリーンアップ,ユーザの再ログインなどの動作が含まれることを考慮する。 |
2.5 OpenVMS Cluster のメンバシップ
LAN で使用される OpenVMS Cluster システムでは,複数の独立した OpenVMS Cluster システムが同じ拡張 LAN に共存できるようにするためと,登録されていないコンピュータが不正にクラスタにアクセスできないようにするために,クラスタ・グループ番号とクラスタ・パスワードが使用されます。
前へ | 次へ | 目次 | 索引 |