前回は、Windows Server 2016の新機能「ストレージレプリカ」の概要を説明しました。今回は、2台のサーバー間で実際にストレージレプリカを構成し、データ保護機能を試してみます。
前回は、Windows Server 2016で新たに搭載される予定の「ストレージレプリカ(Storage Replica)」について、どのような機能なのか、何ができるのかを簡単に紹介しました。今回は、Windows Server Technical Preview 2を実行する2台のサーバー間でストレージレプリカをセットアップし、その機能を試してみます。
ストレージレプリカはこれから登場する全く新しいテクノロジであり、Windows Server Technical Preview 2の時点では機能制限や既知の問題が多く存在します。実際に試す場合は、以下のドキュメントの特に「Storage Replica:Frequently Asked Questions」および「Storage Replica:Known Issues」をよく確認することをお勧めします。また、可能であれば、物理コンピューターの物理ハードディスクではなく、Hyper-Vなどの仮想マシン環境で試すことをお勧めします。
以下の図1は、筆者が用意した2台のサーバー間(ソースサーバーとターゲットサーバー)のストレージレプリカのシステム構成です。
図1の通り、2台のサーバー間でストレージレプリカを構成するには、ソースサーバー側に「保護対象のデータ用のディスク(ボリューム)」の他に、もう1つ「ログ用のディスク」が必要になります。また、ターゲットサーバー側には、レプリケーション先となるソースサーバーと“同一サイズ、同一セクターサイズのデータ用ディスクとログ用ディスクのセット”が必要です(画面1)。ログサイズは最初1GBから構成可能ですが、ログ用ディスクは少なくとも8GB以上のサイズである必要があります。
データ用ディスクとログ用ディスクは、ローカル固定ディスクでも、iSCSIやファイバチャネルなどのSAN(Storage Area Network)のLUN(Logical Unit Number:論理ユニット番号)ボリュームでも構いません。仮想マシンで評価する場合は、仮想ハードディスク(Hyper-Vの場合はVHDやVHDX)で簡単に準備することができます。
前回説明した通り、2台のサーバー間および2つのフェイルオーバークラスター間のストレージレプリカは、データ保護が目的であり、上位アプリケーションの種類や可用性については別に考慮する必要があります。
今回、ソースサーバーでは保護対象のデータ用ディスクを「ファイルサーバーの役割」で共有フォルダーとして公開していることを前提に話を進めます。
データ用ディスクとログ用ディスクは、ソースサーバーとターゲットサーバーの両方で、GUIDパーティションテーブル(GPT)ディスクとして初期化し(MBRは不可)、NTFSまたはReFS形式(ソースとターゲットで一致させること)でフォーマットした上で、同じドライブ文字を割り当てておきます。また、ソースサーバーのデータ用ディスクには、サンプルデータを格納しておきました(画面2)。それ以外の3つのディスクは全て空の状態です。
ストレージレプリカを構成するには、ソースサーバーとターゲットサーバーの両方に、新しいサーバーの機能である「Storage Replica」と関連する管理ツールをインストールする必要があります。必要な機能は、「サーバーマネージャー」の「役割と機能の追加ウィザード」を使用してインストールできます。Windows PowerShellからインストールするには、次のコマンドレットを実行します。
Install-WindowsFeature -Name Storage-Replica -IncludeManagementTools
2台のサーバー間および2つのフェイルオーバークラスター間のストレージレプリカでは、Windows PowerShellでストレージレプリカを構成、管理します。Windows PowerShellは苦手という方もいると思いますが、そんなに難しくはありません。
まず、ソースサーバーで次のように「Test-SRTopology」コマンドレットを実行して、ストレージレプリカの構成の検証テストを実施します。
Test-SRTopology -SourceComputerName vnext-sv01 -SourceVolumeNames D: -SourceLogVolumeName L: -DestinationComputerName vnext-sv03 -DestinationVolumeNames D: -DestinationLogVolumeName L: -DurationInMinutes 5 -IntervalInSeconds 1 -ResultPath C:¥temp
「Test-SRTopology」コマンドレットを実行すると、ソースサーバーとターゲットサーバーのリモート管理、レプリケーションに使用されるSMB(Server Message Block)プロトコルの接続性、データ用ディスクとログ用ディスクのサイズおよびセクターサイズの検証が行われます。
また、「-DurationInMinutes」と「-IntervalInSeconds」パラメーターに指定した時間と頻度で対象ディスクのパフォーマンス情報が収集されます。検証テストの結果リポートは、「-ResultPath」パラメーターで指定したパスに「TestSrTopologyReport.html」というファイル名で出力されます(画面3)。
パフォーマンス情報を収集する際には、ソースサーバーのデータ用ディスクに、ディスクI/O負荷ツールなどを利用して、実際の利用で想定されるI/O負荷をかけることが重要です。データ用ディスクにアクセスがなければ、有益なパフォーマンスリポートは生成されません。このパフォーマンステストの結果リポートにより、必要なログサイズを見積もったり、ネットワークのボトルネック問題を発見したりすることができます。
なお、Windows Server Technical Preview 2を既定のインストールオプション(従来のServer Coreインストール)または、もう1つのインストールオプションである「with local admin tools」(従来の最小サーバーインターフェース)でインストールした場合、Webブラウザーはインストールされないため、サーバー上でリポートを参照することができません。「Internet Explorer(IE)11」および「Microsoft Edge」は、サーバーグラフィックシェル(Server Graphical Shell)の機能を追加することでインストールできますが、Webブラウザーがある別のPCにリポートファイルをコピーして参照するのが手っ取り早いでしょう。
2台のサーバー間でストレージレプリカをセットアップするには「New-SRPartnership」コマンドレットにソースサーバー、ソースサーバーのレプリケーショングループ名、データ用ディスク、ログ用ディスク、ターゲットサーバー、ターゲットサーバーのレプリケーショングループ名、データ用ディスク、ログ用ディスク、ログサイズを指定してストレージレプリカのパートナーシップを作成します。
以下のコマンドレットの例では、ログサイズを8GBとしましたが、どの程度のサイズにすればよいかは前述の「Test-SRTopology」コマンドレットの結果リポートから判断すればよいでしょう(表1、画面1)。
New-SRPartnership -SourceComputerName vnext-sv01 -SourceRGName rg01 -SourceVolumeName D: -SourceLogVolumeName L: -DestinationComputerName vnext-srv03 -DestinationRGName rg02 -DestinationVolumeName D: -DestinationLogVolumeName L: -LogSizeInBytes 8GB
対象 | パラメーター | 対象名 |
---|---|---|
ソースサーバー | -SourceComputerName | vnext-sv01 |
ソースサーバーのレプリケーショングループ名 | -SourceRGName | rg01 |
ソースサーバーのデータ用ディスク | -SourceVolumeName | D: |
ソースサーバーのログ用ディスク | -SourceLogVolumeName | L: |
ターゲットサーバー | -DestinationComputerName | vnext-srv03 |
ターゲットサーバーのレプリケーショングループ名 | -DestinationRGName | rg02 |
ターゲットサーバーのデータ用ディスク | -DestinationVolumeName | D: |
ターゲットサーバーのログ用ディスク | -DestinationLogVolumeName | L: |
ログサイズ | -LogSizeInBytes | 8GB |
表1 「New-SRPartnership」コマンドレットで指定するパラメーターの例 |
また、この例では、「同期モード」のストレージレプリカがセットアップされています。「非同期モード」でセットアップするには、さらに「-ReplicationMode Asyncronous」パラメーターを追加します。
「New-SRPartnership」コマンドレットを実行してストレージレプリカのパートナーシップを作成すると、ターゲットサーバーからデータ用ディスクのマウントが解除され、そのディスクに対してソースサーバーのデータ用ディスクの初期レプリケーションが始まります(画面5)。
レプリケーションの状態は、「Get-SRGroup」コマンドレットで確認できます。また、初期レプリケーションの開始と完了、レプリケーションの状態はイベントログの「Microsoft-Windows-StorageReplica」ログでも確認できます。
Get-SRGroup
または
(Get-SRGroup).replicas
レプリケーションが有効になっている間、ターゲットサーバー側のマウント解除されたデータ用ディスクには、ソースサーバー側で書き込まれたデータがブロックレベルでレプリケーションされて反映されます。同期モードのストレージレプリカでは、ターゲットサーバーへのログへの書き込みが終了してから、ソースサーバー側のアプリケーションに書き込み完了が通知されるため、ファイルシステムレベルでデータ損失ゼロが実現されます。
結果的にターゲットサーバーのデータ用ディスクは、ソースサーバーのデータ用ディスクの最新の複製が維持されます。この複製はマウントされないことで、意図しないデータ破損から保護されます。複製であるデータ用ディスクにアクセスしてデータを復旧するには、レプリケーションの方向を反転させるか、ストレージレプリカのパートナーシップを削除してレプリケーションを無効化します。
レプリケーションの方向を反転させるには、ターゲットサーバー側で「Set-SRPartnership」コマンドレットを次のように実行します。
Set-SRPartnership -NewSourceComputerName vnext-sv03 -SourceRGName rg02 -DestinationComputerName vnext-sv01 -DestinationRGName rg01
これにより、ターゲットサーバーが新しいソースサーバーとなり、データ用ディスクがマウントされます。一方、これまでのソースサーバーはターゲットサーバーに切り替わり、データ用ディスクのマウントが解除され、逆方向のレプリケーションが有効になります(画面6)。
ここで注意してほしいのは、ストレージレプリカがアプリケーションの可用性については何もしないということです。旧ソースサーバー側で共有フォルダーを設定していた場合、レプリケーションを反転させると、ソースサーバー側の共有フォルダーは使用できなくなります。一方、ターゲットサーバー(新しいソースサーバー)側では、マウントされたデータ用ディスクに対してデータの読み書きをできるようになりますが、データの復旧や共有フォルダーの復旧のために必要な操作を管理者が手動で行う必要があります。
レプリケーションを無効化する場合は、ソースサーバー側で「Remove-SRPartnership」コマンドレットを実行してパートナーシップを削除し、ソースサーバーとターゲットサーバーの両方で「Remove-SRGroup」コマンドレットを実行してレプリケーショングループを削除します。
Get-SRPartnership | Remove-SRPartnership
Get-SRGroup | Remove-SRGroup
Get-SRGroup | Remove-SRGroup
同じフェイルオーバークラスター内の2つの共有ストレージ間でレプリケーションを行う「ストレッチクラスター」のストレージレプリカ構成は、「フェイルオーバークラスターマネージャー」のGUI(Graphical User Interface)を使用して構成することが可能です(画面7)。
また、ストレッチクラスターでは、手動または自動フェイルオーバーでソースとターゲットを切り替えて、レプリケーションを反転させることができます(画面8)。これによりクラスター上で動作する高可用性アプリケーションは、最小限のダウンタイムでストレージへのアクセスを再開できます。
以上のように、ストレッチクラスターのストレージレプリカでは、データの保護に加えて、アプリケーションとストレージの可用性向上を実現できます。
岩手県花巻市在住。Microsoft MVP:Hyper-V(Oct 2008 - Sep 2015)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。
Copyright © ITmedia, Inc. All Rights Reserved.