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