記憶域スペース ダイレクトに向けた入れ子の回復性
適用対象: Azure Stack HCI、バージョン 22H2 および 21H2。Windows Server 2022 および Windows Server 2019
入れ子の回復性は、Azure Stack HCI と Windows Server の記憶域スペース ダイレクトの機能です。 これにより、2 サーバー クラスターは、ストレージの可用性を失うことなく同時に複数のハードウェア障害に耐えられます。そのため、ユーザー、アプリ、および仮想マシンを中断することなく継続して実行することができます。 この記事では、入れ子の回復性のしくみについて説明し、利用を開始するための詳細な手順を示して、よく寄せられる質問に答えます。
始める前に
入れ子の回復性について検討すべき場合:
- クラスターで次のオペレーティング システムのいずれかが実行されている: Azure Stack HCI バージョン 21H2、Azure Stack HCI バージョン 20H2、Windows Server 2022、または Windows Server 2019
- クラスターのサーバー ノードがちょうど 2 台である。
入れ子の回復性を使用できない場合:
- お使いのクラスターが Windows Server 2016 で実行されている、または
- クラスターのサーバー ノードが 1 台だけである、またはサーバー ノードが 3 台以上ある。
入れ子の回復性を使用する理由
入れ子の回復性を使用するボリュームは、従来の双方向ミラーリングの回復性とは異なり、複数のハードウェア障害が同時に発生した場合であってもオンラインに留まりアクセスすることができます。 たとえば、2 つのドライブで同時に障害が発生した場合、またはサーバーが停止してドライブに障害が発生した場合、入れ子の回復性を使用しているボリュームは、オンラインに留まりアクセスすることができます。 ハイパーコンバージド インフラストラクチャでは、これによってアプリと仮想マシンのアップタイムが増加します。ファイル サーバーのワークロードであれば、これはユーザーにとって、ファイルへのアクセスが中断されないことを意味します。
トレードオフは、入れ子の回復性では従来の双方向ミラーリングよりも容量効率が低いという点です。つまり、使用できる領域がわずかに少なくなります。 詳細については、以下の「容量の効率性」セクションを参照してください。
しくみ
このセクションでは、記憶域スペース ダイレクトに向けた入れ子の回復性の背景と、2 つの新しい回復性オプションとそれらの容量効率について説明します。
着想の源: RAID 5+1
RAID 5+1 は、入れ子の回復性について理解するのに役立つ背景となる、確立された形式の分散型記憶域の回復性です。 RAID 5+1 では、各サーバー内で、任意の単一ドライブの損失から保護するために、RAID 5 (すなわち "シングル パリティ") によってローカルの回復性が提供されます。 次に、2 台のサーバー間で、いずれかのサーバーの損失から保護するために、RAID 1 (すなわち "双方向ミラーリング") によっていっそうの回復性が提供されます。
回復性オプション
Azure Stack HCI と Windows Server の記憶域スペース ダイレクトには、ソフトウェアで実装された 2 つの回復性オプションが用意されており、特別な RAID ハードウェアは必要ありません。
入れ子の双方向ミラー。 各サーバー内では双方向ミラーリングによってローカルの回復性が提供され、次に、2 台のサーバー間での双方向ミラーリングによっていっそうの回復性が提供されます。 これは基本的に 4 方向ミラーであり、各サーバーには異なる物理ディスクに配置された 2 つのコピーがあります。 入れ子の双方向ミラーリングでは、書き込みはすべてのコピーに対して行われ、読み取りは任意のコピーから行われることで、優れたパフォーマンスが提供されます。
入れ子のミラーリングによって高速化されたパリティ。 上記の画像の入れ子の双方向ミラーリングを、入れ子のパリティと組み合わせます。 各サーバー内では、ほとんどのデータのローカル回復性は、双方向ミラーリングを使用する新しい最近の書き込みを除き、単一のビットごとのパリティ計算によって提供されます。 次に、サーバー間の双方向ミラーリングによって、すべてのデータに対するいっそうの回復性が提供されます。 ボリュームへの新しい書き込みは、各サーバー上の個別の物理ディスクにある 2 つのコピーのミラー部分に対して行われます。 各サーバーでボリュームのミラー部分がいっぱいになると、最も古いデータが変換され、バックグラウンドでパリティ部分に保存されます。 結果として、ボリュームのデータは双方向ミラーまたは単一のパリティ構造で各サーバーに格納されます。 これはミラー高速パリティのしくみと似ていますが、ミラー高速パリティでは、クラスターと記憶域プールに 4 台のサーバーが必要であり、別のパリティ アルゴリズムが使用される点が異なります。
容量の効率性
容量の効率性とは、使用できる領域と、ボリュームの専有領域との比率です。 これは、回復性に起因する容量のオーバーヘッドを表わすもので、選択する回復性オプションによって異なります。 単純な例として、回復性のないデータの格納は、100% の容量効率です (1 TB のデータが占める物理記憶領域の容量は 1 TB です)。一方で、双方向ミラーリングの効率は 50% です (1 TB のデータが占める物理記憶領域の容量は 2 TB です)。
入れ子の双方向ミラーでは、すべての 4 つのコピーが書き込まれます。 これは、1 TB のデータを格納するには、4 TB の物理記憶領域容量が必要であることを意味します。 単純であることは魅力的ですが、25% という入れ子の双方向ミラーの容量効率は、記憶域スペース ダイレクトの回復性オプションの中で最低です。
入れ子のミラーリングによって高速化されたパリティでは、およそ 35 - 40% の、より高い容量効率が実現されます。この数字は、各サーバーの容量ドライブの数と、ボリュームに対して指定したミラーとパリティの組み合わせという、2 つの要因によって決まります。 次の表に、一般的な構成の調査結果を示します。
サーバーごとの容量ドライブ数 10% のミラー 20% のミラー 30% のミラー 4 35.7% 34.1% 32.6% 5 37.7% 35.7% 33.9% 6 39.1% 36.8% 34.7% 7+ 40.0% 37.5% 35.3% 完全な計算の例を次に示します。 2 台のサーバーそれぞれに 6 つの容量ドライブがあり、10 GB のミラーと 90 GB のパリティで構成される 100 GB のボリュームを 1 つ作成するとします。 サーバーローカルである双方向ミラーの効率は 50.0% であり、10 GB のミラー データは、各サーバーに格納するために 20 GB 占めることを意味します。 両方のサーバーに対してミラーリングされて、合計の専有領域は 40 GB となります。 サーバーローカルの単一パリティの効率は、この場合、5/6 = 83.3% なので、90 GB のパリティ データは、各サーバーに格納するために 108 GB 占めることを意味します。 両方のサーバーに対してミラーリングされて、合計の専有領域は 216 GB となります。 したがって合計の専有領域は、[(10 GB/50.0%) + (90 GB/83.3%)] × 2 = 256 GB であり、全体の容量効率は 39.1% になります。
従来の双方向ミラーリング (約 50%) と、入れ子のミラーリングによって高速化されたパリティ (最大 40%) の容量効率はあまり変わらないことに注目してください。 要件によっては、容量効率が若干低下しても、記憶域の可用性が大幅に向上する効果が十分得られる可能性があります。 ボリュームごとの回復性を選択すると、同じクラスター内で、入れ子の回復性ボリュームと従来の双方向ミラー ボリュームを混在させることができます。
入れ子の回復性ボリュームを作成する
以下のセクションで説明するように、PowerShell で使い慣れた記憶域コマンドレットを使用して、入れ子の回復性を備えたボリュームを作成できます。
手順 1: ストレージ層テンプレートを作成する (Windows Server 2019 のみ)
WindowsServer 2019 では、ボリュームを作成する前に、New-StorageTier コマンドレットを使用して新しいストレージ層テンプレートを作成する必要があります。 これは一度だけ行う必要があります。その後は、作成するすべての新しいボリュームでこれらのテンプレートを参照できます。
注意
Server 2022、Windows Azure Stack HCI 21H2、または Azure Stack HCI 20H2 を実行している場合は、この手順をスキップできます。
容量ドライブの -MediaType を指定し、必要に応じて任意の -FriendlyName を指定します。 他のパラメーターは変更しないでください。
たとえば、容量ドライブがハード ディスク ドライブ (HDD) の場合は、管理者として PowerShell を起動し、次のコマンドレットを実行します。
NestedMirror 層を作成するには:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4
NestedParity 層を作成するには:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk
容量ドライブがソリッド ステート ドライブ (SSD) の場合は、代わりに -MediaType を SSD に設定し、-FriendlyName を *OnSSD に変更します。 他のパラメーターは変更しないでください。
ヒント
Get-StorageTier によって層が正常に作成されたことを確認します。
手順 2: 入れ子になったボリュームを作成する
New-Volume コマンドレットを使用して新しいボリュームを作成します。
入れ子の双方向ミラー
入れ子の双方向ミラーを使用するには、
NestedMirror層テンプレートを参照し、サイズを指定します。 例:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB容量ドライブがソリッド ステート ドライブ (SSD) の場合は、
-StorageTierFriendlyNamesを*OnSSDに変更します。入れ子になったミラー加速パリティ
入れ子のミラーリングによって高速化されたパリティを使用するには、
NestedMirrorとNestedParityの両方の層テンプレートを参照し、ボリュームの部分ごとに 1 つのサイズを指定します (最初がミラー、2 番目がパリティの 2 つ)。 たとえば、入れ子になった双方向のミラーが 20% で入れ子になったパリティが 80% の 500 GB ボリュームを 1 つ作成するには、次を実行します。New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB容量ドライブがソリッド ステート ドライブ (SSD) の場合は、
-StorageTierFriendlyNamesを*OnSSDに変更します。
手順 3: Windows Admin Center で続行する
入れ子になった回復性を使用するボリュームは、次のスクリーンショットのように、明確なラベル付けを使用してWindows Admin Centerに表示されます。 作成されたら、記憶域スペース ダイレクトの他のすべてのボリュームと同様に、Windows Admin Center を使用してそれらを管理し、監視することができます。
省略可能: キャッシュ ドライブまで拡張する
入れ子の回復性を使用すると、既定の設定で、複数の容量ドライブが同時に失われたり、1 台のサーバーと 1 つの容量のドライブが同時に失われたりする状況から保護されます。 この保護を キャッシュ ドライブに拡張するには、もう 1 つの考慮事項があります。キャッシュ ドライブは、多くの場合、複数の容量ドライブに対して読み取りと書き込みのキャッシュを提供するため、他のサーバーがダウンしたときにキャッシュ ドライブの損失を許容できる唯一の方法は、キャッシュの書き込みではなく、パフォーマンスに影響します。
このシナリオに対処するため、記憶域スペース ダイレクトには、2 台構成のサーバー クラスターで 1 台のサーバーがダウンしたら自動的に書き込みキャッシュを無効にして、サーバーが復帰したら書き込みキャッシュを再度有効にするオプションが用意されています。 パフォーマンスに影響を与えずにルーチンを再開できるように、書き込みキャッシュはサーバーが 30 分間停止されるまで無効にされません。 書き込みキャッシュが無効にされると、書き込みキャッシュの内容は容量デバイスに書き込まれます。 この後のサーバーでは、オンライン サーバーに障害が発生したキャッシュ デバイスがあっても問題ありません。ただし、キャッシュ デバイスで障害が発生した場合、キャッシュからの読み取りが遅れたり失敗したりする可能性があります。
注意
すべてのキャッシュ (単一メディア タイプ) 物理システムの場合、2 サーバー クラスター内の 1 つのサーバーがダウンしている場合に、書き込みキャッシュの自動無効化を検討する必要はありません。 これは、HDD を使用している場合にのみ必要なストレージ バス レイヤー (SBL) キャッシュでのみ考慮する必要があります。
(省略可能) 2 サーバー クラスター内の 1 つのサーバーがダウンしたときに書き込みキャッシュを自動的に無効にするには、管理者として PowerShell を起動し、次を実行します。
Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"
True に設定すると、キャッシュの動作は次のようになります。
| 状況 | キャッシュの動作 | キャッシュ ドライブの損失に耐えられるか |
|---|---|---|
| 両方のサーバーが稼働 | 読み取りと書き込みをキャッシュする、完全なパフォーマンス | はい |
| サーバーがダウン、最初の 30 分間 | 読み取りと書き込みをキャッシュする、完全なパフォーマンス | いいえ (一時的) |
| 最初の 30 分間の後 | 読み取りのみキャッシュする、パフォーマンスが影響を受ける | はい (キャッシュが容量ドライブに書き込まれた後) |
よく寄せられる質問
入れ子の回復性についてよく寄せられる質問とその回答を紹介します。
既存のボリュームを、双方向ミラーと入れ子の回復性の間で変換できますか?
いいえ、ボリュームの回復性の種類を変換することはできません。 Azure Stack HCI、Windows Server 2022、Windows Server 2019 の新しい展開では、どの回復性の種類がニーズに最適であるかを事前に決定してください。 Windows Server 2016 からアップグレードする場合は、入れ子の回復性を持つ新しいボリュームを作成し、データを移行してから、古いボリュームを削除することができます。
複数の種類の容量ドライブを使用して、入れ子の回復性を利用できますか?
はい、上記の手順 1 で、各層の -MediaType を指定するだけです。 たとえば、同じクラスター内に NVMe、SSD、HDD がある場合、NVMe ではキャッシュを提供し、後者 2 つでは容量を提供します。NestedMirror 層を -MediaType SSD に、NestedParity 層を -MediaType HDD に設定します。 この場合、パリティ容量の効率は、HDD ドライブの数にのみ左右されます。また、各サーバーには、少なくとも 4 つのディスクが必要です。
3 台以上のサーバーで入れ子の回復性を使用できますか?
いいえ、クラスターにちょうど 2 台のサーバーがある場合にのみ、入れ子の回復性を使用します。
入れ子の回復性を使用するには、いくつのドライブが必要ですか?
記憶域スペース ダイレクトに必要なドライブの最小数は、サーバー ノードごとに容量ドライブ 4 台です。また、サーバー ノードごとにキャッシュ ドライブ 2 台です (存在する場合)。 これは Windows Server 2016 から変更されていません。 入れ子の回復性に関するその他の要件はありません。また、予約容量の推奨事項も変更されていません。
入れ子の回復性を使用していると、ドライブの交換方法は変わりますか?
いいえ。
入れ子の回復性を使用していると、サーバー ノードの置き換え方法は変わりますか?
いいえ。 サーバー ノードやそのドライブを置き換えるには、次の順序に従います。
- 役目を終えたサーバー内のドライブを廃止します
- クラスターに、新しいサーバーとそのドライブを追加します
- 記憶域プールが再調整されます
- 役目を終えたサーバーとそのドライブを削除します
詳細については、サーバーの削除に関する記事を参照してください。