Windows Server 2016には、新しいサーバーの機能として「ストレージレプリカ」が提供されます。ストレージレプリカでは、どのようにデータを保護するのか、早速試してみました。
これまで、マイクロソフトのサーバー製品やWindows Server(のサービス)は、いくつかのレプリケーションテクノロジを提供してきました。例えば、次の表1のようなテクノロジです。
サービス/製品 | レプリケーションテクノロジ |
---|---|
ファイルサーバー | 分散ファイルシステムレプリケーション(Distributed File System Replication:DFS-R) |
Hyper-V | Hyper-Vレプリカ(Hyper-V Replica) |
SQL Server | SQL Server AlwaysOn |
Exchange Server | データベース可用性グループ(Database Availability Group:DAG) |
表1 マイクロソフトが提供してきたレプリケーションテクノロジ |
これらはアプリケーションレベルのレプリケーションテクノロジであり、ディスク障害からのデータ保護とアプリケーションの高可用性や負荷分散、迅速な復旧を可能にします。
対して、Windows Server 2016で新たに搭載される予定の「ストレージレプリカ(Storage Replica)」は、より物理ハードウエアに近い、「記憶域サービス(Storage Services)」のレイヤーでデータを保護するための“ブロックレベルのレプリケーション機能”を提供します。
Windows Server 2016の「ファイルサーバーの役割」との組み合わせで利用されることが多くなると思いますが、ファイルサーバーの役割とは関係なく動作する、単独の機能として提供されます。ストレージレプリカはWindows Server 2016の「サーバーの機能」の一つとして、オプションで有効化できます(画面1)。
また、Windows Server 2016のリファクタリング版である「Nano Server」でも、ファイルサーバーの役割(Microsoft-NanoServer-Storage-Package)が組み込まれた環境でサポートされます(画面2)。
ストレージレプリカは、「2台のサーバー間」「フェイルオーバークラスターの2つの共有ストレージ間(ストレッチクラスター)」、または「2つのフェイルオーバークラスター間」で構成し、保護対象のボリュームをブロックレベルでレプリケーションすることでデータを保護します。
レプリケーションは、レプリケーション元(ソース)とレプリケーション先(ターゲット)にそれぞれ接続された、データ用ボリュームとログ用ボリュームのペア(レプリケーショングループ、Replication Group:RG)間で、「同期(Synchronous)モード」または「非同期(Asynchronous)モード」で構成します。
なお、Windows Server Technical Preview 2の時点では、非同期モードは「2台のサーバー間のレプリケーションでのみ利用可能」という制限があります。
アプリケーションがボリュームにデータを書き込むと、ローカルのログとレプリケーション先のログにログデータが書き込まれます。同期モードの場合は、レプリケーション先のログの書き込みが終了するのを待ってから、アプリケーションに書き込み完了を通知します。一方、非同期モードでは、レプリケーションを待たずに書き込み完了を通知します。
データのディスクへの書き込みはファイルシステムのキャッシュ機能により非同期で行われますが、ログの書き込みはライトスルー(キャッシュとディスクにデータを同時に記録)で行われます。そのため、同期モードのレプリケーションは“データ損失ゼロ”を実現しますが、高速なネットワークリンクが必要になります(図1)。一方、非同期モードは、レプリケーション性能に影響されることなく即座に書き込みが完了しますが、障害のタイミングによってはデータ損失の可能性があります(図2)。
ストレージレプリカはデータの保護を目的としたものであり、2台のサーバー間、および2つのフェイルオーバークラスター間でのレプリケーションではアプリケーションについては全く考慮されていません(図3)。
ストレージレプリカによるレプリケーション中は、レプリケーション先のボリュームはマウントが解除されるため、アプリケーションやユーザーからはアクセスができない状態になります。
レプリケーションされたボリュームのデータにアクセスするには、「ストレージレプリカの設定を削除するか」「レプリケーションの方向を反転するか」のいずれかの操作を手動で行う必要があります。いずれかの操作を行うと、レプリケーションされたボリュームがマウントされ、ファイルシステムにアクセスできるようになります。
マウントされたボリュームからはデータを救出したり、レプリケーション先のサーバーにアプリケーション(ファイルサーバーの共有など)をセットアップして、マウントされたボリュームをそのまま使用してサービスを復旧したりすることもできます。ボリュームマウント後の対応については、ストレージレプリカの機能の範囲外になることに注意してください。
唯一例外となるのが、フェイルオーバークラスター内の2つの共有ストレージ間でストレージレプリカを構成する「ストレッチクラスター」です。ストレッチクラスター環境では、Hyper-Vや「スケールアウトファイルサーバー(Scale-Out File Server:SOFS)」の共有ストレージである「クラスターの共有ボリューム(Cluster Shared Volumes:CSV)」を、クラスター内の2つの共有ストレージで冗長化できます(図4)。
クラスターの共有ボリュームは、それ自体、ノード障害やメンテナンス時にもファイルアクセスを継続できるという高可用性ストレージです。ただし、共有ストレージの障害には対応できません。
ストレッチクラスターでストレージレプリカを構成すると、保護対象の共有ストレージに障害が発生するか、その共有ストレージに接続された全てのノードがダウンした場合に、レプリカデータに自動的にフェイルオーバーするようになります。クラスターの共有ボリュームへのアクセスは一時的にできなくなるため、アプリケーションの可用性には影響しますが、ストレージのフェイルオーバー後に素早くアプリケーションの復旧を開始できます。
ストレージレプリカは、本連載第19回、第20回で紹介した「記憶域スペース(Storage Spaces)」と同様、特別なハードウエアに依存しない、ソフトウエアベースのソリューションです。どちらも、マイクロソフトが「ソフトウエア定義のストレージ(Software Defined Storage:SDS)」と呼んでいる機能です。Hyper-Vによるコンピューターの仮想化、Hyper-Vネットワーク仮想化による「ソフトウエア定義のネットワーク(Software Defined Network:SDN)」に続く、SDSというわけです。
クラスター化された記憶域スペースを利用すると、共有ストレージ(または記憶域スペースダイレクトのローカルストレージ)上に3つのコピー(3方向ミラーを使用)を配置して、データを保護することができます。ストレッチクラスターまたはクラスター間のストレージレプリカと組み合わせると、さらに3つのコピーを別のサイトに配置することが可能です(画面3)。
Microsoft Azureを利用したことがある方なら、聞いたことのあるストレージ構成ではないでしょうか。Azureストレージの「ローカル冗長」ストレージは3つのコピーをローカルのデータセンターに保存し、「地理(ジオ)冗長」はさらに3つのコピーを別の地域のデータセンターに配置します。Windows Server 2016の記憶域スペースとストレージレプリカは、Azureストレージクラスの保護と高可用性をオンプレミスに実装可能にするテクノロジなのかもしれません。
ストレージレプリカの機能はまだ開発途上であり、はっきりしたことは言えませんが、Windows Server 2016の記憶域スペースとストレージレプリカは、Azureストレージと同じようなデータ保護環境を、低コストでオンプレミスに実装できるSDSソリューションとなるのではないでしょうか。
今回は、ストレージレプリカの概念についてざっと説明しました。次回は、2台のサーバー間でストレージレプリカを構成し、そのデータ保護機能を実際に試してみます。
岩手県花巻市在住。Microsoft MVP:Hyper-V(Oct 2008 - Sep 2015)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。
Copyright © ITmedia, Inc. All Rights Reserved.