SIOS DataKeeperは、NetRAIDデバイスを作成して保護します。NetRAIDデバイスはRAID1のデバイスであり、下図に示すようにローカルのディスクまたはパーティション、およびネットワークブロックデバイス（NBD）で構成されます。
LifeKeeperで利用可能なファイルシステムは、その他すべてのストレージデバイスと同様に、NetRAIDデバイスにマウントできます。この場合、ファイルシステムは複製されたファイルシステムと呼ばれます。LifeKeeperは、NetRAIDデバイスと複製されたファイルシステムの両方を保護します。
ファイルシステムは、DataKeeper [リソース階層を作成することにより作成されます。NetRAIDデバイスを別のサーバーに拡張するとNBDデバイスが作成され、2台のサーバー間にネットワーク接続が確立されます。NBD接続が確立されるとただちに、SIOS DataKeeperがデータの複製を開始します。
nbd-client プロセスがプライマリーサーバーで実行され、バックアップサーバーで動作している nbd-server プロセスと接続します。
同期（および再同期）
DataKeeperリソース階層は作成されてから拡張されるまでの間、デグレードモードです。つまり、データはローカルのディスクまたはパーティションにのみ書き込まれます。階層をバックアップ（ターゲット）システムに拡張すると、SIOS DataKeeperが2つのシステム間でデータを同期し、以降の書き込みはすべてターゲットに複製されます。どの時点でもデータが「非同期」になった場合（システムまたはネットワークの障害が発生した場合）、SIOS DataKeeperはソースとターゲットのシステムでデータを自動的に再同期します。インテントログ（ビットマップファイル）を使用するようにミラーが設定されている場合、SIOS DataKeeperはインテントログを使用して非同期のデータを特定するので、全体の再同期は不要です。インテントログ（ビットマップファイル）を使用するようにミラーが設定されていない場合は、データ複製の中断後に全体の再同期が実行されます。
標準ミラーの構成
最も一般的なミラーの構成では、下図に示すように2台のサーバーがあり、各サーバーのローカルのディスクまたはパーティションとの間にミラーが確立されます。サーバー1は、ミラーソースを持つプライマリサーバーです。サーバー2は、ミラーターゲットを持つバックアップサーバーです。
N+1 Configuration
前述した標準ミラーの構成の変形として一般的に使用される構成では、クラスター内にある2台以上のサーバーが共通のバックアップサーバーにデータを複製します。この場合は、下図に示すように、各ミラーソースがバックアップサーバーの個別のディスクまたはパーティションに複製する必要があります。
複数ターゲットの構成
適切なLinuxのディストリビューションとバージョン2.6.7以降のカーネルと共に使用した場合、下図に示すように、SIOS DataKeeperは、プライマリーサーバーの1つのディスクまたはパーティションから複数のバックアップシステムにデータを複製することもできます。
特定のソースのディスクまたはパーティションを最大7つのミラーターゲットに複製でき、各ミラーターゲットは別のシステムに存在する必要があります。つまり、ソースのディスクまたはパーティションを、同一ターゲットシステム上にある複数のディスクまたはパーティションにミラーリングすることはできません。
このタイプの構成では、LifeKeeperのカスケーディングフェイルオーバー機能を使用でき、保護するアプリケーションとそのデータに対して複数のバックアップシステムを提供できます。
ミラーリングの開始時にすべてのターゲットに完全再同期されるのを回避するには、クラスター内の残りのターゲットを再接続する前に、まず前のソースのビットマップをマージする必要があります。 9.3.2以前のバージョンでは、ミラーリングの開始時に前のソースが利用できなかった場合は、各ターゲットに対して完全再同期が自動的に行われます。 9.3.2 からは、ミラーがシステム上で起動されると、ターゲットに接続する前に、前のソースがクラスターに参加するのを待ちます。前のソースがクラスターに参加すると、そのビットマップがマージされ、すべてのターゲットが部分的な再同期で参加できるようになります。ミラーが停止し、ターゲットが同期中の場合、ミラーを起動してターゲットに複製するために前のソースは必要ありません。前のソースがクラスターへの再参加に利用できない場合は、「mirror_action fullresync」コマンドを使用して、ターゲットを完全再同期で手動で再同期することができます。 /etc/default/LifeKeeper の変数 LKDR_WAIT_FOR_PREVIOUS_SOURCE_TIMEOUT によって、再同期の動作が決まります。（詳細は「DataKeeper パラメーターリスト 」を参照）。
SIOS DataKeeper リソース階層
以下の例に、LifeKeeper の GUI に表示される典型的な DataKeeper リソース階層を示します。
リソース datarep-ext3-sdr は NetRAID リソースであり、親リソース ext3-sdr はファイルシステムリソースです。本書の以降の部分では、「DataKeeperリソース」は両方のリソースを合わせたものを指すことに注意してください。ファイルシステムリソースはNetRAIDリソースに依存するので、NetRAIDリソースに対する動作はその上にあるファイルシステムにも影響します。
フェイルオーバーのシナリオ
フェイルオーバーのシナリオ － 2 ノード
以下の4つの例で、SIOS DataKeeper を使用するフェイルオーバーで何が起きるかを説明します。これらの例では、LifeKeeper for Linuxクラスターは、サーバー1（プライマリーサーバー）とサーバー2（バックアップサーバー）の2台のサーバーで構成されます。
シナリオ1
サーバー1からサーバー2へのミラーが正常に完了し、その後サーバー1が動作不能に陥る。
結果: フェイルオーバーが発生します。サーバー2 がプライマリーサーバーの役割を担当し、サーバー1が再び動作可能になるまでデグレードモード（バックアップなし）で動作します。サーバー1が再び動作可能になると、SIOS DataKeeper がサーバー2からサーバー1への再同期を開始します。2.6.18以前のカーネルでは、全体の再同期が実行されます。2.6.19以降のカーネル、またはRed Hat Enterprise Linux 5.4の2.6.18-164以降のカーネル（またはRed Hat 5.4以降の利用可能な派生カーネル）では、部分的な再同期が実行されます。つまり、ソースとターゲットにあるビットマップファイルに記録された変更部分についてのみ同期が必要です。
注記: SIOS DataKeeperは、現在ミラーソースとして動作しているサーバーに以下のフラグをセットします。
$LKROOT/subsys/scsi/resources/netraid/$TAG_last_owner
サーバー1がサーバー2にフェイルオーバーすると、このフラグがサーバー2にセットされます。このため、サーバー1が動作を再開すると、SIOS DataKeeperはこの最終オーナフラグをサーバー1から削除します。その後、サーバー2からサーバー1にデータの再同期を開始します。
シナリオ2
シナリオ1で、サーバー2（プライマリーサーバーである状態）が、サーバー1（この時点ではバックアップサーバー）との再同期中に動作不能になる。
結果: 再同期プロセスが正常に完了しなかったので、データが破損している可能性があります。この結果、LifeKeeperはDataKeeperリソースをサーバー1にフェイルオーバーしません。サーバー2が動作可能になった場合にのみ、LifeKeeperはサーバー2でDataKeeperリソースをサービス中（ISP）にします。
シナリオ3
サーバー1（プライマリー）とサーバー2（ターゲット）の両方が動作不能になる。サーバー1（プライマリー）が最初に動作可能になる。
結果: サーバー1は、DataKeeperリソースをin serviceにしません。この理由は、停止してからオンラインに戻ったソースサーバーは、ターゲットと通信できないからです。ソースサーバーは以下のタグをセットします。
$LKROOT/subsys/scsi/resources/netraid/$TAG_data_corrupt
これは、正しくない方向へのデータ同期を防止する安全策です。この場合、サーバー1でミラーを強制的にオンラインにする必要があります。つまり、サーバー1の data_corrupt フラグを削除し、リソースを in service にします。ミラーを強制的にオンラインにする を参照してください。
注記: $TAG_data_corrupt フラグを削除する前に、サーバー1が最終のプライマリーサーバーであることを確認する必要があります。サーバー1が最終のプライマリーサーバーでない場合、データが破損する可能性があります。これは、 last_owner フラグの有無で確認できます。
シナリオ4
サーバー1（プライマリ）とサーバー2（ターゲット）の両方が動作不能になる。サーバー2（ターゲット）が最初に動作可能になる。
結果: LifeKeeperは、サーバー2のDataKeeperリソースをISPにしません。サーバー1が動作可能になると、LifeKeeper サーバー1のDataKeeperリソースをISPにします。
フェイルオーバーのシナリオ － 3ノード
次の例は、SIOS DataKeeper を使用した場合にフェイルオーバー中に何が起こるかを示しています。この例では、LifeKeeper for Linuxクラスターは、サーバー1（プライマリーサーバー）、サーバー2（バックアップサーバー）、およびサーバー3（バックアップサーバー）の3つのサーバーで構成されています。
サーバー1（優先順位1）がサーバー2（優先順位10）およびサーバー3（優先順位20）への複製を正常に完了した後、サーバー1 は動作不能になります。
結果： フェイルオーバーは、2番目に優先順位の高いサーバー2で行われます。サーバー2 は、プライマリーサーバーの役割を引き継ぎます。 v9.3.2以前のバージョンでは、サーバー3は完全再同期化とともにミラーに追加されます。 v9.3.2では、サーバー2はサーバー1（前のサーバー）がクラスターに戻るのを待ってからサーバー3 への複製を再開します。これにより、サーバー1 のビットマップとサーバー2 のビットマップをマージして、サーバー1 とサーバー3 の両方に部分的に再同期することができます。サーバー1 がクラスターに再接続するのを待っている間、LifeKeeper GUIはサーバー3 のステータスを「Out of Sync (Wait for Previous Source)」として表示します。サーバーが接続されていない間、サーバー1 のステータスは「Unknown」になり、最初に接続されたときにGUIのステータスに「Out of Sync」と表示されます。ミラーのプロパティページは、それを「Out of Sync (Previous Source)」として識別します。
サーバー1が再接続すると、そのビットマップがマージされて再同期が開始され、その時点でステータスは「Resyncing」と表示されます。
再同期が完了するとステータスは「Target」に更新され、サーバー3はそのステータスを「Resyncing」に変更して再同期を開始します。
注記： SIOS DataKeeperはミラーソースを追跡するために以下のフラグを設定します。
$LKROOT/subsys/scsi/resources/netraid/$TAG_last_owner
$LKROOT/subsys/scsi/resources/netraid/$TAG_source
$TAG_last_owner フラグは、現在ミラーソースとして機能しているシステム上にあり、 $TAG_source フラグには、ローカルノードがミラーの一部であった最後の時点でソースだったシステムの名前が含まれています。
サーバー1がサーバー2にフェイルオーバーすると、サーバー2に $TAG_last_owner フラグが設定されます。サーバー2 の $TAG_source フラグは、サーバー1を前のソースとして識別します（これには、サーバー1とサーバー3への部分的な再同期を実行するために必要なビットマップが含まれています）。サーバー1が復旧すると、SIOS DataKeeper はサーバー1から $TAG_last_owner フラグを削除します。次にサーバー2 はサーバー1 からのビットマップをマージし、サーバー2からサーバー1へのデータの再同期を開始します。サーバー1が復旧すると、SIOS DataKeeperはサーバー1から $TAG_last_owner フラグを削除します。次にサーバー2はサーバー1のビットマップをマージし、サーバー2からサーバー1へのデータの再同期を開始します。サーバー1への再同期が完了すると、サーバー1の $TAG_source フラグがサーバー2の名前で更新されます。サーバー1が同期された後、サーバー2はサーバー3へ同じ再同期を実行します。サーバー3の $TAG_source フラグは、サーバー2の名前で更新されます。
このトピックへフィードバック