適用対象: Azure Stack HCI、バージョン 22H2 以降。Windows Server 2022 および Windows Server 2019
入れ子になった回復性は、Azure Stack HCI および Windows Server の 記憶域スペース ダイレクト の機能です。 これにより、2 サーバー クラスターは、記憶域の可用性を失うことなく複数のハードウェア障害に同時に耐えられるため、ユーザー、アプリ、および仮想マシンは中断することなく引き続き実行されます。 この記事では、入れ子になった回復性のしくみについて説明し、開始するための手順を説明し、よく寄せられる質問に回答します。
開始する前に
次の場合は、入れ子になった回復性を検討してください。
- クラスターは、Azure Stack HCI バージョン 22H2 以降、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 の記憶域スペース ダイレクトには、特殊な RAID ハードウェアを必要とせずに、ソフトウェアに実装された次の 2 つの回復性オプションが用意されています。
入れ子の双方向ミラー。 各サーバー内では、ローカルの回復性は双方向ミラーリングによって提供され、その後、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 のパリティで構成される 1 つの 100 GB ボリュームを作成するとします。 サーバーローカル双方向ミラーは 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 のみ)
Windows Server 2019 では、ボリュームを作成する前に、 New-StorageTier コマンドレットを使用して新しいストレージ層テンプレートを作成する必要があります。 これを行う必要があるのは 1 回だけであり、作成するすべての新しいボリュームでこれらのテンプレートを参照できます。
注
Windows Server 2022、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 つのサイズを指定します。 たとえば、500 GB のボリュームを 1 つ作成するには、双方向の入れ子ミラーを 20%、入れ子パリティを 80% で設定して、次を実行します。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 からアップグレードする場合は、入れ子になった回復性を持つ新しいボリュームを作成し、データを移行してから、古いボリュームを削除できます。
複数の種類の容量ドライブで、入れ子の回復性を使用できますか?
はい。上記の-MediaType で、各レベルのを適宜指定するだけです。 たとえば、NVMe、SSD、HDD が同じクラスター内にある場合、NVMe はキャッシュを提供し、後者の 2 つでは容量を提供します。 NestedMirror 層を -MediaType SSD に設定し、 NestedParity 層を -MediaType HDD に設定します。 この場合、パリティ容量の効率は HDD ドライブの数のみに依存し、サーバーごとに少なくとも 4 台が必要です。
3 つ以上のサーバーで入れ子になった回復性を使用できますか?
いいえ。クラスターに 2 台のサーバーがある場合にのみ、入れ子になった回復性を使用します。
ネストされた冗長性を使用するには、いくつのドライブが必要ですか?
記憶域スペース ダイレクトに必要なドライブの最小数は、サーバー ノードごとに 4 つの容量ドライブと、サーバー ノードごとに 2 つのキャッシュ ドライブ (存在する場合) です。 これは、Windows Server 2016 から変更されていません。 入れ子構造の回復性に関する他の要件はなく、予約容量の推奨事項も変更されていません。
階層化された回復性によって、ドライブの交換の仕組みは変わりますか?
いいえ。
入れ子の回復性を使用していると、サーバー ノードの交換方法は変わりますか?
いいえ。 サーバー ノードとそのドライブを交換するには、次の順序に従います。
- 送信サーバーのドライブをインベントリから削除する
- 新しいサーバーとそのドライブをクラスターに追加する
- 記憶域プールが再調整されます
- 送信サーバーとそのドライブを削除する
詳細については、 サーバーの削除 に関する記事を参照してください。