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 の名前で更新されます。
このトピックへフィードバック