2 つのサイト (以下の図を参照) 間における複数の共有ストレージ環境で、各サイトの各サーバは、そのサイトのサーバ間で共有されているストレージへアクセスすることが可能です。DataKeeper のミラーが作成されると、各サイトの 1 つのサーバがミラーのエンドポイントとして指定されます。

( 注記: N は、1 から N までの数字を表しています。例: 4×1 は、4 つのサーバがディスクのレプリケーションを共有していて、そのうちの 1 つが別のサイトへレプリケーションしているということを表しています。)

以下の例では、DataKeeper のミラーがサイト A からサイト B へ X: ボリュームをレプリケートするよう作成されています。

サイト A でストレージを共有しているストレージは 3 つのサーバです。それらのサーバは以下の状態にあります。

  • S1 - 現在ミラーのソースです。
  • S2 - 共有ソース (ロックされています)。
  • S3 - 共有ソース (ロックされています)。

S1 はミラーのソースなので、S2 および S3 を共有のソースシステムとして参照します。これらのサーバは現在ミラーのソース側でボリュームへのアクセス権を共有していますが、ミラーのソースとして定義されていないので、ボリュームにアクセスすることはできません( 注記: S2 のユーザは、「 アクセスが拒否されました 」といった旨のメッセージを見ることになります)。

サイト B でストレージを共有しているのは 3 つのサーバです。

  • T1 - 現在ミラーのターゲットです (プライマリのターゲットとしてロックされています)。
  • T2 - 共有ターゲット (ロックされています)。
  • T3 - 共有ターゲット (ロックされています)。

これらは、現在 T1 と定義されているターゲットボリュームへのアクセス権を共有しています。T2 および T3 は共有のターゲットシステムとして参照されます。ターゲットボリュームへのファイルシステムへのアクセスは 3 つの全システムでロックされています。

WSFC クラスタの 6 つの全サーバおよび WSFC が保護するすべてのリソースは、この時点では S1 でアクティブまたは「オンライン」です。

このレプリケーションの初期構成において、どのサーバが「テイクオーバ」にふさわしいか、そしてどのサーバがアクティブサーバになるのかを理解しておくことが重要です。DataKeeper ミラーの正しい用例において、以下のルールが適用されます。

  1. 共有ソースサーバ (S2、S3) へのスイッチオーバは可能です。
  1. 現在のターゲットサーバ (T1) へのスイッチオーバは可能です。
  1. 共有ターゲットサーバ (T2、T3) へのスイッチオーバは不可能です。ただし、これらのサーバをスイッチオーバするためには 2 つの手順があります。
  • はじめに、ターゲット T1 へスイッチオーバさせます。
  • その後、T2 または T3 のどちらかのサーバにスイッチオーバすることが可能です。

共有ソースサーバへのスイッチオーバ

例では、S2 または S3 がアクティブサーバで、ミラーのソースとなることができます。保護されたリソースを S2 へ切り替える場合は、S2 がミラーの新しいソースになり、T1 がミラーのターゲットとしてとどまります。

  1. 初期のミラー構成: S1 → T1
  1. 操作: S2 へスイッチオーバ (WSFC でリソースをオンラインにしてください)
  1. 最終結果: S2 → T1

現在のターゲットシステムへのスイッチオーバ

例では、保護されたリソースを T1 へスイッチオーバさせることで、効果的にミラーの方向を入れ替え T1 をミラーの新しいソースにし、S1 がミラーのターゲットになります。

  1. 初期のミラー構成: S1 → T1
  1. 操作: T1 へスイッチオーバ (WSFC でリソースをオンラインにしてください)
  1. 最終結果: T1 → S1

共有ターゲットシステムへのスイッチオーバ

この操作は許可されていません。スイッチオーバに失敗します。ただし、上記の注意事項のように、2 つの手順を実行することにより、スイッチオーバが可能になります。

  1. 初期のミラー構成: S1 → T1
  1. 操作: T1 へスイッチオーバ (WSFC でリソースをオンラインにしてください)
  1. 中間構成: T1 → S1
  1. 操作: T2 へスイッチオーバ (WSFC でリソースをオンラインにしてください)
  1. 最終結果: T2 → S1

フェイルオーバ

現在のソースシステムに障害が発生した場合またはリソース障害がグループ全体の障害を引き起こした場合においては、フェイルオーバクラスタはリソースグループのクラスタの別ノードへのフェイルオーバを試みます。以下の事項がフェイルオーバに影響する要因となります。

  • ノード障害 vs リソース障害
  • リソースグループに対して優先オーナーリストが設定されている場合 vs 優先オーナーリストが設定されていない場合
  • 有効な所有者
  • Windows 2008 vs Windows 2008 R2

以下の記事では、フェイルオーバクラスタがどのようにしてノードをフェイルオーバさせるかを決定しているかについて記述されています。

blogs.msdn.com/b/clustering/archive/2009/08/11/9863688.aspx

重要 : N x N 構成では、DataKeeper は共有ソースシステムまたはターゲットシステムのどれにでもフェイルオーバすることをサポートします。フェイルオーバクラスタにて適切でないシステム (共有ターゲットシステムのうちの 1 つ) でグループをオンラインにしようと試みると、その操作は失敗します。フェイルオーバクラスタは、別のノードでオンライン操作を継続し、フェイルオーバが適したシステムで実行されると最終的に成功となります。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信