皆様は、「DataKeeper」という製品をご存知でしょうか。
DataKeeperとは、稼働中のサーバのデータを、リアルタイムで待機系に複製（ミラーリング）し、止めないシステム運用を実現するソフトウェアです。
クラスタノード間でボリュームをミラーリングし、あたかも共有ストレージのように扱うことが可能になります。クラスタリングソフトウェアであるLifeKeeperやWindowsのWSFC（Windows Server Failover Clustering）と連携することにより、高可用性を実現しつつ、データの冗長性を確保することが可能となります。
本記事では、DataKeeperの機能や特徴を解説し、どのような状況で活用していくかについて紹介していきます。
DataKeeperの基本機能・主な特長
基本機能
DataKeeperは、稼働系と待機系のローカルディスク上のボリュームをレプリケーションの技術で同期し、
それらのボリュームを論理的な共有ディスクのように扱い、LifeKeeperおよびWSFCとも連携する機能が特徴です。
DataKeeperの構成イメージ
サーバ毎に接続されたローカルディスク上のボリュームをレプリケーションし、
ミラーボリュームを作成することで、共有ディスクとして扱うことが可能となります。
障害発生時には LifeKeeper と連携してLifeKeeperが監視・フェイルオーバーを実行し、
DataKeeperがデータレプリケーションを担い、論理共有ディスク上のデータをそのまま待機系に引き継ぎます。
主な特徴
■ブロックレベルのリアルタイム・レプリケーション
同期／非同期に対応しており、WAN向け最適化や圧縮も備え、レイテンシー環境でも帯域効率よく複製します。帯域制御とパフォーマンスについては、ファイル単位ではなく「ブロックレベル」となるため、高速での転送が可能となります。
同期に使うネットワーク帯域を調整できるため、業務ネットワークへの影響を最小限に抑えられます。
■WSFCとネイティブ連携
DataKeeper VolumeをWSFCのリソースとして扱い、クラスタ側の制御に自然統合することができます。
Windows標準のクラスタ機能（WSFC）が、DataKeeperのボリュームを「物理ディスクリソース」として認識し、SQL Serverやファイルサーバの冗長化をする際、使い慣れた WSFC の管理画面で運用できるため、学習コストを増やさずに導入できます。
■クラウド/仮想/物理を横断
AWS/Azure/GCPやVMware、オンプレ物理で同じ考え方で設計・展開が可能となります。
AWSやAzureでは、オンプレミスのような「共有ストレージ（SAN）」をマウントしてクラスタを組むのが難しい、または高価なマネージドサービスが必要となりますが、
DataKeeperを使えば、ローカルディスク同士を同期させるだけでクラスタを組むことが可能です。
■コスト最適化
共有ストレージが不要となり、OSからは「共有ディスク」として認識されるため、アプリケーション側の対応が不要、コストを抑えることができます。
では、これらの特徴が実際の現場でどのように役立つのか、シチュエーションごとに DataKeeper の活用イメージを紹介します。
シチュエーション別、DataKeeperの活用事例
1) クラウド移行を検討中の情シス（AWS）
- 前提：既存オンプレで SQL Server FCI や ファイルサーバクラスタ を利用中
AWS に移行しても ダウンタイムを極小化した高可用性（HA） 構成 を維持したい - 課題： AWS では、共有ディスク構成が直接使えない/FSx for Windows（共有ファイルサービス）が割高/ マルチAZをまたいだ共有ストレージ提供が制約多い、という背景がある
- 解決：DataKeeper を使うことで、各ノードのローカル EBS（ディスク）上のボリュームをブロック単位で同期し、
共有ディスクなしでも WSFC）を構築可能。またマルチAZまで柔軟に拡張可能となります。AWS に「オンプレ同等の可用性構成」を持ち込めます。 - 構成イメージ(AWS)：マルチAZの SQL Server FCI/ファイルサーバ にLifeKeeper + DataKeeper を導入した構成各ノードはローカル EBS を利用
DataKeeper が ブロックレベルで EBS を同期（Sync/Async）
LifeKeeper/WSFC によりAZ 障害時は自動フェイルオーバー
➡ 共有ディスクが不要なため、AWS の制約（共有ストレージ/コスト）を解消できます
2) 共有ストレージのコストや仕様で悩むエンジニア
- 前提：オンプレ/仮想環境で NAS/SAN などの共有ストレージ を利用している
- 課題：共有ストレージは高コスト、専用スキルや運用の複雑性、SPOFが気になる。
- 解決：DataKeeperは既存のローカルストレージを活用し、SPOFを排除。
SSD/フラッシュも活かせるため性能面でも優位。
アレイ依存のレプリケーションに比べ、コスト効率の高いHA/DRが構築可能。 - 構成イメージ：Azure：ASCS/ERSやDBのWSFCを共有ディスク不要で内部LB・クォーラム設計のガイダンスに沿い、DataKeeperで共有相当を実現。
➡コストを下げつつ、ストレージの複雑性・制約をすべて解消できます
他方式とのDataKeeperの比較
具体的な活用イメージをご紹介しましたが、他方式と比べてどこが優れているのか？も気になるポイントです。
代表的な方式との比較を整理してみます。
| 比較対象 | DataKeeper導入のメリット | DataKeeper導入のデメリット |
| vs クラウド共有ストレージ（FSx/Azure Files等） | ・コスト最適化（従量課金を排除） ・マルチAZ対応 ・ローカルI/Oで性能が安定 ・局所レイテンシ低減の余地 |
・レプリケーション帯域の確保が必要
・ローカルディスク障害時の運用が発生 ・一般的に2ノード中心 |
| vs S2D （Storage Spaces Direct） |
・WSFC＋既存ディスクで即構成 ・クラウド横断で利用可能 ・専用NIC/ハード不要 ・学習コストが低い |
・スケールアウトストレージ機能なし
・大規模分散用途には不向き ・ソフトウェアライセンス費用が発生 |
| vs SQL Server Always On（AG） | ・DB以外も保護可能 ・SEでFCIが作れライセンス最適 ・アプリ改修不要 ・フェイルオーバーが単純 |
・読み取り専用レプリカ不可 ・全ボリュームレプリケーション ・AGにあるDBレベル機能を持たない |
比較を踏まえて理解が深まったところで、
実際の相談でよくいただく質問もまとめておきます。
よくある質問（FAQ）
Q1. レプリケーションは同期／非同期を切り替えられますか？
A. はい。ブロックレベルで同期／非同期を選択でき、切り替えも可能です。
Q2. SQL Server Standard EditionでもFCIを構築できますか？
A. 可能です。DataKeeper＋WSFCで共有ディスク相当を提供できるため、Standard EditionでもFCIを構成できます。
Q3. ネットワーク障害でノード間の通信が切断された場合、再同期はどうなりますか？
A. フル同期のやり直しは不要です。通信が途絶えた際、DataKeeperはレプリケーションを一時停止し、変更されたブロック箇所（差分）だけを内部のビットマップメモリに記録し続けます。ネットワーク復旧後は、その差分データのみが自動的に再同期（部分再同期）されるため、システムへの負荷を最小限に抑えて正常な状態に復帰できます。
Q4. DataKeeperでレプリケーションできないデータはありますか？
A. はい。Cドライブなどの「OSシステム領域（システムボリューム）」はレプリケーションの対象外となります。また、DataKeeperはドライブ（ボリューム）単位でのブロック同期を行うため、「特定のファイルやフォルダだけ」を指定して同期することも仕様上できません。
まとめ
DataKeeperでは、AWSやAzure等のクラウド・オンプレを問わず、同じアーキテクチャ思想で設計・展開・運用できるのが強みであることをお伝えいたしました。
LifeKeeper連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。
詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。
