日本-日本語

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

OpenVMS マニュアル


HP OpenVMS
OpenVMS Cluster システム


目次 索引

第2章 OpenVMS Cluster の概念

この章では,OpenVMS Cluster システムの設計と実装の理解に役立つように,その基本アーキテクチャについて説明します。

2.1 OpenVMS Cluster システムのアーキテクチャ

図 2-1 では, OpenVMS Cluster システム・アーキテクチャのプロトコル・レイヤを,下から順に,通信メカニズムからシステム・ユーザに至るまで示しています。これらのプロトコル・レイヤには以下のものが含まれます。

  • ポート

  • システム通信サービス (SCS)

  • システム・アプリケーション (SYSAP)

  • その他のレイヤード・コンポーネント

図 2-1 OpenVMS Cluster システム・アーキテクチャ


  注意
OpenVMS の 3 つのアーキテクチャですべてのインターコネクトがサポートされるわけではありません。 CI,DSSI,および FDDI インターコネクトは Alpha および VAX システムでサポートされます。 Memory Channel および ATM インターコネクトは Alpha システムでのみサポートされます。



アーキテクチャの最下位レベルでは,デバイス間の接続が通信ポートおよび物理パスとして提供されます。ポート・レイヤには,以下のいずれかのインターコネクトを含むことができます。

  • LAN

    • Ethernet (Fast Ethernet,Gigabit Ethernet および 10 Gb Ethernet)

  • MEMORY CHANNEL

  • SAS

  • SCSI

  • Fibre Channel

各インターコネクトは,プロセッサ・ノードに接続されるポート (アダプタとも呼びます) によってアクセスされます。たとえば,Fibre Channel インターコネクトは Fibre Channel ポートによってアクセスされます。

2.1.2 SCS レイヤ

SCS レイヤでは,各論理パスを介して,データグラム,メッセージ,およびブロック転送の形式で,基本的な接続管理および通信サービスが提供されます。 表 2-1 は,これらのサービスについて説明しています。

表 2-1 通信サービス
サービス 配布の保証 使用方法
データグラム
1 パケットに収まるあるいはそれ未満の情報 データグラムの配布は保証されない。データグラムは紛失する可能性があり,重複したり,順序が入れ替わって配布される可能性がある。 紛失しても重大な問題にならない状態メッセージと情報メッセージ

独自の信頼性プロトコル (DECnet あるいは TCP/IPなど) を保有するアプリケーション

メッセージ
1 パケットに収まるあるいはそれ未満の情報 メッセージの配布が保証され,順番どおりに到着することも保証される。各パケットで仮想サーキット・シーケンス番号が使用される。 ディスクの読み込み/書き込み要求
ブロック・データ転送
ローカル・プロセスあるいはシステムの仮想アドレス空間と他のノードのアドレスとの間での連続データのコピー(すなわち読み取りあるいは書き込み)。個々の伝送は 2 32-1 バイト未満,あるいはそのホストの物理メモリの制約より制限される。ブロック・データは,リモート DMA 転送方式。 ブロック・データの配布は保証される。送信ポートと受信ポートおよびポート・エミュレータが協調動作して,転送をデータ・パケットに分割し,すべてのパケットが正しく送信され,受信され,適切な宛先バッファに格納されることを保証する。ブロック・データ転送は,転送サイズの点でメッセージと異なる。 ディスクの読み込み/書き込み要求に関連するデータの移動のために,ディスク・サブシステムおよびディスク・サーバで利用。大規模ロック・ツリーのファスト・マスタリング。大規模 ICC メッセージの伝送。

SCS レイヤは,ポートの種類に応じて,ハードウェアとソフトウェアの組み合わせまたはソフトウェアのみで実装されます。SCS は OpenVMS Cluster 内の接続を管理し, 仮想サーキットという共通のトランスポートを介して,システム・アプリケーション間でメッセージを多重化します。仮想サーキットは,2 つ 1 組の SCS ポートおよびその仮想サーキットで多重化される SCS 接続の間に存在します。

2.1.3 システム・アプリケーション (SYSAP) レイヤ

OpenVMS Cluster アーキテクチャの次のレイヤは, SYSAP レイヤで構成されます。このレイヤは,たとえばディスクやテープへのアクセスやクラスタ・メンバシップの制御などの機能を提供する複数のシステム・アプリケーションで構成されます。SYSAP には以下のコンポーネントがあります。

  • 接続マネージャ

  • MSCP サーバ

  • TMSCP サーバ

  • ディスクおよびテープ・クラス・ドライバ

これらのコンポーネントについては,この章の後半で詳しく説明します。

2.1.4 他のレイヤード・コンポーネント

OpenVMS Cluster システム・アーキテクチャの一番上には,広範囲にわたる OpenVMS コンポーネント・レイヤがあります。このレイヤには,以下のコンポーネントが含まれています。

  • Volume Shadowing for OpenVMS

  • 分散ロック・マネージャ

  • プロセス制御サービス

  • 分散ファイル・システム

  • レコード管理サービス (RMS)

  • 分散キュー・マネージャ

ボリューム・シャドウイング以外のコンポーネントについては,この章の後半で詳しく説明します。 Volume Shadowing for OpenVMS については, 第 6.6 節 を参照してください。

2.2 OpenVMS Cluster ソフトウェアの機能

OpenVMS Cluster の通信およびリソース共用機能を実装する OpenVMS Cluster ソフトウェア・コンポーネントは, OpenVMS Cluster のすべてのコンピュータで常に実行されます。 1 台のコンピュータで障害が発生しても,コンポーネントは他のコンピュータで実行されているため, OpenVMS Cluster システムは操作を続行できます。

2.2.1 機能

以下の表は,OpenVMS Cluster の通信およびリソース共用機能と,各機能を実行するコンポーネントを示しています。

機能 コンポーネント
クラスタ・メンバシップの規則に従って OpenVMS Cluster コンピュータが相互に通信するようにする。 接続マネージャ
他の OpenVMS Cluster コンポーネント, OpenVMS 製品,他のソフトウェア製品で実行される機能の同期をとる。 分散ロック・マネージャ
ディスクとファイルを共用する。 分散ファイル・システム
ディスクに直接アクセスできないノードから,そのディスクを利用できるようにする。 MSCP サーバ
テープに直接アクセスできないノードから,そのテープを利用できるようにする。 TMSCP サーバ
キューを使用可能にする。 分散キュー・マネージャ



2.3 クラスタ・メンバシップの整合性の確保

接続マネージャは,OpenVMS Cluster システムのコンピュータがクラスタ・メンバシップの規則に従って相互に通信できるようにします。

OpenVMS Cluster システム内のコンピュータは,ディスクやファイルへのアクセスなど,さまざまなデータやシステム・リソースを共用します。リソースの整合性を確保するのに必要な調整を行うために,各コンピュータはクラスタ・メンバシップに関する明確な情報の記録を管理しておかなければなりません。

2.3.1 接続マネージャ

接続マネージャは,最初のメンバ・システムがブートされるときに OpenVMS Cluster を作成し,クラスタ状態遷移中にコンピュータがクラスタに追加されたり削除される際にクラスタを再構成します。接続マネージャの全体的な役割は以下のとおりです。

  • 分断の防止 ( 第 2.3.2 項 を参照)

  • OpenVMS Cluster システム内でアクティブなノードおよび非アクティブなノードの追跡

  • リモート・ノードへのメッセージの配布

  • ノードの削除

  • 分散ロック・マネージャなど,他のソフトウェア・コンポーネントが共用リソースへのアクセスの同期をとれるようにするための,可用性の高いメッセージ・サービスの提供



2.3.2 クラスタ分断

接続マネージャの最大の目的は, クラスタ分断を防止することです。クラスタ分断とは, OpenVMS Cluster を構成する既存のノードが, 2 つ以上の独立したクラスタに分割される状態のことです。

分散ロック・マネージャは,複数の OpenVMS Cluster システムによる共用リソースへのアクセスを調整することはできないため,クラスタ分断が発生すると,データ・ファイルが壊れる可能性があります。このため接続マネージャは,クォーラム・アルゴリズムを使用してクラスタの分断を防止します。

2.3.3 クォーラム・アルゴリズム

クォーラム・アルゴリズムは,OpenVMS Cluster システムでリソースを共用できるように,OpenVMS Cluster の大多数のメンバがクラスタ内に存在するかどうかを判断するための数学的な手法です。 クォーラム (定足数)とは,そのクラスタが機能するために必要とする票 (vote) の数です。クォーラムは,クラスタ分断を防止するために接続マネージャが計算する動的な値でもあります。接続マネージャは,OpenVMS Cluster を構成する大多数のメンバが機能している場合のみ,処理の実行を認めます。

2.3.4 システム・パラメータ

クォーラム・アルゴリズムで実行される演算では,VOTES と EXPECTED_VOTES の 2 つのシステム・パラメータが重要です。以下の表で,これらのパラメータについて説明しています。

パラメータ 説明
VOTES コンピュータがクォーラムに対して提示する票(vote)の数 (固定値) を指定する。システム管理者が各コンピュータで VOTES パラメータの値を設定することも,あるいはオペレーティング・システムに以下のようなデフォルトの値を設定させることもできる。

  • サテライト・ノードの場合,デフォルト値は 0。

  • その他のコンピュータの場合,デフォルト値は 1。

VOTES システム・パラメータの値が 0 以外の各 Integrity サーバまたは Alpha コンピュータは, 投票メンバ (voting member)であると解釈される。

EXPECTED_VOTES OpenVMS Cluster メンバが保有しているすべての VOTES パラメータ値の合計を指定する。これを 初期値として,そのクラスタの 正しいクォーラム値 (正常稼働時のクォーラム値) が算出される。システム管理者は,サテライトも含めてクラスタ内でアクティブな各 Integrity サーバまたは Alpha システムで,このパラメータを設定しなければならない。



2.3.5 クラスタの票数の計算

クォーラム・アルゴリズムによる動作は以下のとおりです。

手順 動作
1 OpenVMS Cluster 内のノードがブートされると,接続マネージャは存在するすべてのシステムで設定されている EXPECTED_VOTES の中から最大値を使用して,以下の計算式で 推定クォーラム値を求める。
Estimated quorum = (EXPECTED_VOTES + 2)/2 | Rounded down

2 状態遷移時 (ノードがクラスタに参加またはクラスタから外れた時,あるいはクォーラム・ディスクが認識された時) に,接続マネージャは,以下のいずれか値のうち最大の値をクラスタ・クォーラム値として動的に計算する。

  • 現在のクラスタ・クォーラム値 (最後のクラスタ遷移中に計算された値)。

  • 手順 1 で説明した推定クォーラム値。

  • 次の式で計算された値。
    QUORUM = (VOTES + 2)/2 | Rounded down
    
    ここで,VOTES システム・パラメータは,すべてのクラスタ・メンバが保有している全票数。

注意: クォーラム・ディスクについては, 第 2.3.8 項 を参照。

3 接続マネージャは,クラスタの票数をクラスタ・クォーラム値と比較して,以下の条件をもとに,実行すべき動作を判断する。

条件 動作
クラスタの票の総数がクォーラム値に等しいか,それ以上である。 OpenVMS Cluster システムは引き続き処理を続行する。
クラスタの現在の票数がクォーラム値より小さい (クラスタからのコンピュータの削除のため)。 票の総数がクォーラム値以上になるように十分な票数が追加されるまで (つまり,十分な数のコンピュータが OpenVMS Cluster に追加されるまで),残りの OpenVMS Cluster メンバは,すべてのプロセス動作を停止し,クラスタ・アクセスが可能なディスクおよびテープに対するすべての I/O 操作を停止する。

注意: あるノードが OpenVMS Cluster システムから削除されても,接続マネージャはクラスタ・クォーラム値を小さくしません。接続マネージャが行うのはクラスタ・クォーラム値の増加だけで,シャットダウン時に REMOVE NODE オプションが選択されない限り,クラスタ・クォーラム値を減少させることはありません。システム管理者は, 第 10.11.2 項 の手順に従って,この値を減少させることができます。

2.3.6 例

3 台のコンピュータで構成されるクラスタがあり,各コンピュータの VOTES パラメータが 1 に設定され, EXPECTED_VOTES パラメータが 3 に設定されているとします。接続マネージャはクラスタ・クォーラム値を動的に計算して, 2 という値を求めます (つまり,(3 + 2)/2)。この例では, 3 台のコンピュータのうちいずれか 2 台のコンピュータでクォーラムが構成されるので,3 台目のコンピュータが存在しなくても他の 2 台は稼動できます。 1 台のコンピュータだけでクォーラムを構成することはできません。したがって,3 台の OpenVMS Cluster コンピュータを分断して, 2 つの独立したクラスタとして実行することはできません。

2.3.7 サブクラスタの選択

通信障害が発生した場合,次のような 2 とおりのサブクラスタの比較検討が行われ,最適なサブクラスタを選択して引き続き処理が継続されます。

  1. 票数が最も多いサブセット

  2. 票数が同じ場合は次のとおり:

    • ノード数が最も多いサブセット

    • ノード数も同じ場合は OpenVMS に任せられるが, SCS システム ID 値の比較をもとに 2 つのサブセットのうち 1 つを確定的に選択します。



2.3.8 クォーラム・ディスク

クラスタ・システム管理者は 1 つのディスクを クォーラム・ディスクとして指定できます。クォーラム・ディスクは,クラスタの票の総数に 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 項 を参照してください。


目次 索引

プライバシー ご利用条件・免責事項