SIOS DataKeeper は、非同期および同期ミラーリング両方の方式を採用しています。SIOS DataKeeper を正しく動作させるためには同期および非同期ミラーリングの長所と短所を理解することが必要です。

同期ミラーリング

同期ミラーリングでは、書き込みごとに割り込んでソースシステム上のストレージに書き込まれると同時にターゲットボリュームへの書き込みのために、ターゲットシステムへ転送します。ローカルおよびターゲットの書き込みが完了すると、書き込み要求が完了したと認識され、制御が書き込みを開始したアプリケーションへと戻されます。ソースシステム上の永続的なビットマップファイルが更新されます。

同期ミラーのソースボリュームに対して書き込み要求が行われた場合の処理を、以下の一連のイベントで説明します。

  1. 以下の処理が並列で発生します。

a.書き込みのコピーがミラー書き込みキューに置かれます。
b.書き込みがローカルボリュームに送られて完了します。

  1. 上記の両方の処理が完了すると、書き込みは完了の状態を呼び出し元に返します。

a.ターゲットで書き込みが完了できない状態(ネットワーク伝送エラー、またはターゲットシステムでの書き込みエラー)が発生した場合、ミラー状態は [一時停止] に変更されます。ただし、呼び出し元に返されるボリューム書き込みの状態は影響を受けません。
b.ローカルボリュームの書き込み状況が呼び出し元に返されます。

この図では、書き込み要求 1 はすでに完了しています。ターゲットボリュームとソースボリュームの両方が更新されています。

書き込み要求 2 はアプリケーションから送信され、書き込みがターゲットボリュームに書き込まれようとしています。ターゲットボリュームに書き込まれると、DataKeeper はターゲットボリュームで書き込みが成功したという確認応答を送信し、並行して、書き込みがソースボリュームに対してコミットされます。 

この時点で、書き込み要求が完了し、書き込みを開始したアプリケーションに制御が戻されます。

同期ミラーリングは、ソースシステムの障害時にデータの損失が発生しないことを保証しますが、アプリケーションのパフォーマンスに影響をもたらします。ソースへの書き込みとネットワーク経由でのターゲットへの書き込みが完了するまでアプリケーションが待機する必要があるので、特に WAN または低速なネットワーク構成においてはパフォーマンスが低下します。

非同期ミラーリング

非同期ミラーリングでは、書き込みごとに割り込んで、データのコピーを作成します。このコピーはネットワークが送信可能な状態になるまでキューに入れられます。一方、元の書き込み要求はストレージデバイスへコミットされ、制御が書き込みを開始したアプリケーションへと即時に返されます。

複数のボリュームにまたがるデータ(データベースログおよびデータファイルなど)の一貫性を維持するために、いくつかのアプリケーションはそのボリュームにフラッシュリクエストを送信します。 DataKeeper は、キュー内のすべての書き込みがターゲットシステムに送信され、認識されるのを待つことによって、ミラーリング状態のミラーを持つボリューム上のフラッシュリクエストを受け取ります。このような場合にパフォーマンスが影響を受けるのを防ぐには、レジストリエントリ「 DontFlushAsyncQueue 」を設定するか、すべてのファイルを同じボリューム上に配置することを検討してください。

つまり、どの時点をとってもソースマシンからターゲットマシンへの送信を待っている書き込みトランザクションが存在することになります。しかし、ターゲットボリュームへの書き込み順序が正確なので、データの整合性は常に保たれます。万が一ソースシステムに障害が発生した場合、ターゲットシステムはキューにたまっていたすべての書き込みを受け取らないようにすることは可能ですが、ターゲットボリュームに対して送信されるデータは、有効なものとなります。

非同期ミラーのソースボリュームに対して書き込み要求が行われた場合の処理を、以下の一連のイベントで説明します。

  1. ソースシステム上の永続的なビットマップファイルが更新されます。
  1. ソースシステムは書き込みのコピーをミラー書き込みキューに追加します。
  1. ソースシステムでソースボリュームへの書き込み要求が実行され、呼び出し元に制御が返されます。
  1. キュー内の書き込みはターゲットシステムに送られます。ターゲットシステムでターゲットボリュームに対する書き込み要求が実行されて、書き込みの状況がプライマリ側に返されます。
  1. ミラーの書き込みキューが設定された制限に達すると(WriteQueueHighWater または WriteQueueByteLimit に達した場合)、動作を決定するためにミラーの「BlockWritesOnLimitReached」の設定が使用されます。 BlockWritesOnLimitReached が「0」の場合、ミラーは一時停止され、少し後に部分再同期が開始されます。 BlockWritesOnLimitReached が「1」の場合、書き込みキューに空きができるまで、書き込みは遅延します。ミラーはミラーリング状態のままですが、ネットワークの速度とリモートノードのボリュームに応じてアプリケーションのスループットが低下します。
  1. ネットワーク転送時またはターゲットシステムでのターゲットボリューム書き込み実行時にエラーが発生した場合、セカンダリ側での書き込み処理は中断されます。ここで、ミラーの状態が ミラーリング から 一時停止 に変更されます。

上の図では、2 つの書き込み要求がソースボリュームに書き込まれ、ターゲットシステムに送信するためにキューに入っています。ただし、制御はすでに書き込みを開始したアプリケーションに戻っています。

下の図では、最初の 2 つの書き込みがソースボリュームとターゲットボリュームの両方に正常に書き込まれている間に、3 つ目の書き込み要求が開始されています。ミラーリング中は、書き込み要求が時間の順にターゲットボリュームに送信されます。したがって、ターゲットボリュームはある時点で必ずソースボリュームの完全な複製となります。

ミラー一時停止

上記の通常のミラーリングプロセスが中断された場合は、ミラーの状態が ミラーリング から 一時停止 に変更されます。ソースボリュームに対するすべての変更が永続的なビットマップファイルだけでトラックされ、ターゲットシステムへは何も送信されません。

ミラー再同期

非同期または同期ミラーの中断が解決された場合は、ソースおよびターゲットの再同期が必要になり、ミラーは 再同期 状態になります。 

DataKeeper は、永続的なビットマップファイルを順次読み取ってミラーが 一時停止 中にソースボリュームで変更されたブロックを判断し、それらのブロックのみをターゲットボリュームと再同期します。この手順は、データの部分再同期と呼ばれます。 

GUI では 再同期 (ペンディング) 状態と表示される場合がありますが、これは一時的な状態であり、 再同期 状態に変更されます。

再同期中、ミラーが同期ミラーであったとしてもすべての書き込みが非同期として扱われます。ビットマップ内のダーティーとしてマークされた特定のビットが上記で説明されている部分同期の処理中にターゲットに送信されます。

フィードバック

お役に立ちましたか?

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

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

送信