記憶域スペースダイレクトのための入れ子になった回復性Nested resiliency for Storage Spaces Direct

適用対象: Windows Server 2019Applies to: Windows Server 2019

入れ子になった回復性は、Windows Server 2019 の記憶域スペースダイレクトの新機能であり、2台のサーバーからなるクラスターが記憶域の可用性を失うことなく同時に複数のハードウェア障害に耐えられるようにします。そのため、ユーザー、アプリ、および仮想マシンは中断することなく実行されます。Nested resiliency is a new capability of Storage Spaces Direct in Windows Server 2019 that enables a two-server cluster to withstand multiple hardware failures at the same time without loss of storage availability, so users, apps, and virtual machines continue to run without disruption. このトピックでは、そのしくみについて説明します。また、作業を開始するための詳細な手順について説明し、よく寄せられる質問に回答します。This topic explains how it works, provides step-by-step instructions to get started, and answers the most frequently asked questions.

前提条件Prerequisites

緑のチェックマークアイコン。 次の場合は、入れ子になった回復性を考慮しますConsider nested resiliency if:

  • クラスターで Windows Server 2019 が実行されているそしてYour cluster runs Windows Server 2019; and
  • クラスターには、2つのサーバーノードがあります。Your cluster has exactly 2 server nodes

赤色の X アイコン。 次の場合、入れ子になった回復性は使用できません。You can't use nested resiliency if:

  • クラスターで Windows Server 2016 が実行されているもしくはYour cluster runs Windows Server 2016; or
  • クラスターに3つ以上のサーバーノードがあるYour cluster has 3 or more server nodes

入れ子になった回復性の理由Why nested resiliency

入れ子になった回復性を使用するボリュームは、従来の双方向のミラーリングの回復性とは異なり、同時に複数のハードウェア障害が発生した場合でもオンラインでアクセスできます。Volumes that use nested resiliency can stay online and accessible even if multiple hardware failures happen at the same time, unlike classic two-way mirroring resiliency. たとえば、2つのドライブで障害が発生した場合、またはサーバーが停止してドライブに障害が発生した場合、入れ子になった回復性を使用するボリュームはオンライン状態を維持し、アクセスすることができます。For example, if two drives fail at the same time, or if a server goes down and a drive fails, volumes that use nested resiliency stay online and accessible. ハイパー集約型インフラストラクチャでは、アプリと仮想マシンの稼働時間が増加します。ファイルサーバーのワークロードの場合、ユーザーのファイルへのアクセスが中断されないことを意味します。For hyper-converged infrastructure, this increases uptime for apps and virtual machines; for file server workloads, this means users enjoy uninterrupted access to their files.

ストレージの可用性

トレードオフとは、入れ子になった回復性が従来の双方向ミラーリングよりも容量効率が低いことを意味します。つまり、使用可能な領域がわずかに少なくなります。The trade-off is that nested resiliency has lower capacity efficiency than classic two-way mirroring, meaning you get slightly less usable space. 詳細については、以下の「容量の効率性」セクションを参照してください。For details, see the Capacity efficiency section below.

方法How it works

インスピレーション: RAID 5 + 1Inspiration: RAID 5+1

RAID 5 + 1 は、入れ子になった回復性を理解するのに役立つ背景を提供する、確立された分散記憶域の回復性の形式です。RAID 5+1 is an established form of distributed storage resiliency that provides helpful background for understanding nested resiliency. RAID 5 + 1 では、各サーバー内で、1つのドライブの損失から保護するために、RAID 5 (またはシングルパリティ) によってローカルの回復性が提供されます。In RAID 5+1, within each server, local resiliency is provided by RAID-5, or single parity, to protect against the loss of any single drive. 次に、2台のサーバー間で、いずれかのサーバーの損失から保護するために、RAID 1 または双方向のミラーリングによってさらに回復性が提供されます。Then, further resiliency is provided by RAID-1, or two-way mirroring, between the two servers to protect against the loss of either server.

RAID 5 + 1

2つの新しい回復性オプションTwo new resiliency options

Windows Server 2019 の記憶域スペースダイレクトには、ソフトウェアに2つの新しい回復性オプションが用意されており、特別な RAID ハードウェアは必要ありません。Storage Spaces Direct in Windows Server 2019 offers two new resiliency options implemented in software, without the need for specialized RAID hardware:

  • 入れ子になった双方向ミラー。Nested two-way mirror. 各サーバー内では、双方向のミラーリングによってローカルの回復性が提供され、その後、2つのサーバー間で双方向のミラーリングによって回復性が提供されます。Within each server, local resiliency is provided by two-way mirroring, and then further resiliency is provided by two-way mirroring between the two servers. 基本的には4方向ミラーで、各サーバーに2つのコピーがあります。It's essentially a four-way mirror, with two copies in each server. 入れ子になった双方向ミラーリングは、妥協のないパフォーマンスを実現します。書き込みはすべてのコピーに送信され、読み取りは任意のコピーから取得されます。Nested two-way mirroring provides uncompromising performance: writes go to all copies, and reads come from any copy.

    入れ子になった双方向ミラー

  • 入れ子になったミラーアクセラレータパリティ。Nested mirror-accelerated parity. 入れ子になった双方向ミラーリングを、上記の入れ子になったパリティと結合します。Combine nested two-way mirroring, from above, with nested parity. 各サーバー内では、ほとんどのデータのローカル回復性は、2方向ミラーリングを使用する新しい最近の書き込みを除き、単一のビットごとのパリティ演算によって提供されます。Within each server, local resiliency for most data is provided by single bitwise parity arithmetic, except new recent writes which use two-way mirroring. その後、すべてのデータの回復性をさらに向上させるには、サーバー間の双方向のミラーリングを使用します。Then, further resiliency for all data is provided by two-way mirroring between the servers. ミラーアクセラレータパリティの動作の詳細については、「ミラーアクセラレータパリティ」を参照してください。For more information about how mirror-accelerated parity works, see Mirror-accelerated parity.

    入れ子になったミラーアクセラレータパリティ

容量の効率Capacity efficiency

容量の効率は、ボリュームフットプリントに使用できる領域の比率です。Capacity efficiency is the ratio of usable space to volume footprint. 回復性に起因する容量のオーバーヘッドについて説明し、選択した回復性オプションによって異なります。It describes the capacity overhead attributable to resiliency, and depends on the resiliency option you choose. 単純な例として、回復性のないデータの格納は100% の容量効率に優れています (1 TB のデータは 1 tb の物理ストレージ容量を必要とします)。一方、双方向のミラーリングは50% の効率が高くなります (1 TB のデータでは物理ストレージ容量が 2 TB になります)。As a simple example, storing data without resiliency is 100% capacity efficient (1 TB of data takes up 1 TB of physical storage capacity), while two-way mirroring is 50% efficient (1 TB of data takes up 2 TB of physical storage capacity).

  • 入れ子になった双方向ミラーは、4つのコピーを書き込みます。つまり、1 tb のデータを格納するには、4 tb の物理ストレージ容量が必要です。Nested two-way mirror writes four copies of everything, meaning to store 1 TB of data, you need 4 TB of physical storage capacity. シンプルさは魅力的ですが、入れ子になった双方向ミラーの容量効率が25% になっているのは、記憶域スペースダイレクトの回復性オプションの中で最も低いものです。Although its simplicity is appealing, nested two-way mirror's capacity efficiency of 25% is the lowest of any resiliency option in Storage Spaces Direct.

  • 入れ子になったミラーアクセラレータのパリティは、最大で 35%-40% の容量効率を実現します。これは、各サーバーの容量ドライブの数と、ボリュームに対して指定したミラーとパリティの組み合わせによって異なります。Nested mirror-accelerated parity achieves higher capacity efficiency, around 35%-40%, that depends on two factors: the number of capacity drives in each server, and the mix of mirror and parity you specify for the volume. 次の表は、一般的な構成の参照を示しています。This table provides a lookup for common configurations:

    サーバーあたりの容量ドライブCapacity drives per server 10% ミラー10% mirror 20% ミラー20% mirror 30% ミラー30% mirror
    44 35.7%35.7% 34.1%34.1% 32.6%32.6%
    55 37.7%37.7% 35.7%35.7% 33.9%33.9%
    66 39.1%39.1% 36.8%36.8% 34.7%34.7%
    7 +7+ 40.0%40.0% 37.5%37.5% 35.3%35.3%

    注意

    興味をお持ちの場合は、完全な数学の例を次に示します。If you're curious, here's an example of the full math. 2台のサーバーそれぞれに6つの容量ドライブがあり、10 gb のミラーと 90 GB のパリティで構成される 1 100 GB のボリュームを作成するとします。Suppose we have six capacity drives in each of two servers, and we want to create one 100 GB volume comprised of 10 GB of mirror and 90 GB of parity. サーバーローカル双方向ミラーは50.0% の効率を実現します。つまり、10 GB のミラーデータは、各サーバーに格納するのに 20 GB かかります。Server-local two-way mirror is 50.0% efficient, meaning the 10 GB of mirror data takes 20 GB to store on each server. 両方のサーバーにミラー化され、合計フットプリントは 40 GB です。Mirrored to both servers, its total footprint is 40 GB. サーバーローカルの単一パリティ (この場合は 5/6 = 83.3% 効率)。つまり、90 GB のパリティデータは、各サーバーに格納するために 108 GB を必要とします。Server-local single parity, in this case, is 5/6 = 83.3% efficient, meaning the 90 GB of parity data takes 108 GB to store on each server. 両方のサーバーにミラー化され、合計フットプリントは 216 GB です。Mirrored to both servers, its total footprint is 216 GB. 総フットプリントは [(10 GB/50.0%) + (90 GB/83.3%)] × 2 = 256 GB であり、全体的な容量の効率39.1 を最大にしたものになります。The total footprint is thus [(10 GB / 50.0%) + (90 GB / 83.3%)] × 2 = 256 GB, for 39.1% overall capacity efficiency.

従来の双方向ミラーリングの容量効率 (約50%)および入れ子になったミラーアクセラレータパリティ (最大40%)の違いはあまりありません。Notice that the capacity efficiency of classic two-way mirroring (about 50%) and nested mirror-accelerated parity (up to 40%) are not very different. 要件によっては、容量の効率が若干低くなると、記憶域の可用性が大幅に向上する可能性があります。Depending on your requirements, the slightly lower capacity efficiency may be well worth the significant increase in storage availability. ボリュームごとの回復性を選択すると、同じクラスター内で、入れ子になった回復性ボリュームと従来の双方向ミラーボリュームを混在させることができます。You choose resiliency per-volume, so you can mix nested resiliency volumes and classic two-way mirror volumes within the same cluster.

トレードオフ

PowerShell での使用法Usage in PowerShell

PowerShell で使い慣れた記憶域コマンドレットを使用して、入れ子になった回復性を備えたボリュームを作成できます。You can use familiar storage cmdlets in PowerShell to create volumes with nested resiliency.

手順 1: 記憶域階層テンプレートを作成するStep 1: Create storage tier templates

まず、New-StorageTier コマンドレットを使用して新しい記憶域階層テンプレートを作成します。First, create new storage tier templates using the New-StorageTier cmdlet. この操作は一度だけ行う必要があります。作成したすべての新しいボリュームでこれらのテンプレートを参照できます。You only need to do this once, and then every new volume you create can reference these template. 容量ドライブの -MediaType と、必要に応じて任意の -FriendlyName を指定します。Specify the -MediaType of your capacity drives and, optionally, the -FriendlyName of your choice. 他のパラメーターは変更しないでください。Do not modify the other parameters.

容量ドライブがハードディスクドライブ (HDD) の場合は、管理者として PowerShell を起動し、次のように実行します。If your capacity drives are hard disk drives (HDD), launch PowerShell as Administrator and run:

# For mirror
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirror -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4

# For parity
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParity -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk 

容量ドライブがソリッドステートドライブ (SSD) の場合は、代わりに -MediaTypeSSD に設定します。If your capacity drives are solid-state drives (SSD), set the -MediaType to SSD instead. 他のパラメーターは変更しないでください。Do not modify the other parameters.

ヒント

Get-StorageTierを使用して、階層が正常に作成されたことを確認します。Verify the tiers created successfully with Get-StorageTier.

手順 2: ボリュームを作成するStep 2: Create volumes

次に、New-Volume コマンドレットを使用して新しいボリュームを作成します。Then, create new volumes using the New-Volume cmdlet.

入れ子になった双方向ミラーNested two-way mirror

入れ子になった双方向ミラーを使用するには、NestedMirror 層テンプレートを参照し、サイズを指定します。To use nested two-way mirror, reference the NestedMirror tier template and specify the size. 次に、例を示します。For example:

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirror -StorageTierSizes 500GB

入れ子になったミラーアクセラレータパリティNested mirror-accelerated parity

入れ子になったミラーアクセラレータのパリティを使用するには、NestedMirror 層と NestedParity 層の両方のテンプレートを参照し、ボリュームの各部分に1つずつ、2つのサイズを指定します (ミラーの最初、パリティ 2)。To use nested mirror-accelerated parity, reference both the NestedMirror and NestedParity tier templates and specify two sizes, one for each part of the volume (mirror first, parity second). たとえば、20% の入れ子になった双方向ミラーと80% の入れ子になったパリティである 1 500 GB ボリュームを作成するには、次のように実行します。For example, to create one 500 GB volume that's 20% nested two-way mirror and 80% nested parity, run:

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirror, NestedParity -StorageTierSizes 100GB, 400GB

手順 3: Windows 管理センターで続行するStep 3: Continue in Windows Admin Center

入れ子になった回復性を使用するボリュームは、次のスクリーンショットのように、明確なラベル付きでWindows 管理センターに表示されます。Volumes that use nested resiliency appear in Windows Admin Center with clear labeling, as in the screenshot below. 作成されると、記憶域スペースダイレクトの他のボリュームと同じように、Windows 管理センターを使用してそれらを管理および監視できます。Once they're created, you can manage and monitor them using Windows Admin Center just like any other volume in Storage Spaces Direct.

省略可能: キャッシュドライブに拡張するOptional: Extend to cache drives

入れ子になった回復性は、既定の設定を使用して、複数の容量ドライブが同時に失われたり、1台のサーバーと1つの容量のドライブが同時に失われたりするのを防ぎます。With its default settings, nested resiliency protects against the loss of multiple capacity drives at the same time, or one server and one capacity drive at the same time. この保護をキャッシュドライブに拡張するには、追加の考慮事項があります。多くの場合、キャッシュドライブは複数の容量ドライブに対して読み取りと書き込みのキャッシュを提供するため、他のサーバーがダウンしているときにキャッシュドライブの損失を許容できるようにする唯一の方法は、書き込みをキャッシュするのではなく、パフォーマンスに影響To extend this protection to cache drives has an additional consideration: because cache drives often provide read and write caching for multiple capacity drives, the only way to ensure you can tolerate the loss of a cache drive when the other server is down is to simply not cache writes, but that impacts performance.

このシナリオに対処するために、記憶域スペースダイレクトには、2台のサーバークラスター内の1台のサーバーがダウンしたときに書き込みキャッシュを自動的に無効にするオプションが用意されています。サーバーがバックアップされたら、書き込みキャッシュを再び有効にすることができます。To address this scenario, Storage Spaces Direct offers the option to automatically disable write caching when one server in a two-server cluster is down, and then re-enable write caching once the server is back up. パフォーマンスに影響を与えずにルーチンの再起動を許可するために、サーバーが30分間停止するまで、書き込みキャッシュは無効になります。To allow routine restarts without performance impact, write caching isn't disabled until the server has been down for 30 minutes. 書き込みキャッシュを無効にすると、書き込みキャッシュの内容が容量デバイスに書き込まれます。Once write caching is disabled, the contents of the write cache is written to capacity devices. その後、サーバーはオンラインサーバーで障害が発生しているキャッシュデバイスを許容できます。ただし、キャッシュデバイスで障害が発生した場合、キャッシュからの読み取りが遅れるか、失敗する可能性があります。After this, the server can tolerate a failed cache device in the online server, though reads from the cache might be delayed or fail if a cache device fails.

この動作を設定する (省略可能) には、管理者として PowerShell を起動し、次のように実行します。To set this behavior (optional), launch PowerShell as Administrator and run:

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"

Trueに設定すると、キャッシュの動作は次のようになります。Once set to True, the cache behavior is:

状況Situation キャッシュの動作Cache behavior キャッシュドライブの損失を許容できるか。Can tolerate cache drive loss?
両方のサーバーが稼働していますBoth servers up キャッシュの読み取りと書き込み、完全なパフォーマンスCache reads and writes, full performance Yes
サーバーダウン、最初は30分Server down, first 30 minutes キャッシュの読み取りと書き込み、完全なパフォーマンスCache reads and writes, full performance いいえ (一時的)No (temporarily)
最初の30分後After first 30 minutes キャッシュ読み取りのみ、パフォーマンスに影響するCache reads only, performance impacted はい (キャッシュが容量ドライブに書き込まれた後)Yes (after the cache has been written to capacity drives)

よく寄せられる質問Frequently asked questions

双方向ミラーと入れ子になった回復性の間で既存のボリュームを変換することはできますか。Can I convert an existing volume between two-way mirror and nested resiliency?

いいえ、回復性の種類の間でボリュームを変換することはできません。No, volumes cannot be converted between resiliency types. Windows Server 2019 の新しい展開では、ニーズに最も適した回復性の種類を事前に決定します。For new deployments on Windows Server 2019, decide ahead of time which resiliency type best fits your needs. Windows Server 2016 からアップグレードする場合は、入れ子になった回復性を持つ新しいボリュームを作成し、データを移行してから、古いボリュームを削除することができます。If you're upgrading from Windows Server 2016, you can create new volumes with nested resiliency, migrate your data, and then delete the older volumes.

複数の種類の容量ドライブで入れ子になった回復性を使用できますか。Can I use nested resiliency with multiple types of capacity drives?

はい、上記の手順 1で、それぞれのレベルの -MediaType を指定するだけです。Yes, just specify the -MediaType of each tier accordingly during step 1 above. たとえば、同じクラスター内の NVMe、SSD、HDD では、NVMe はキャッシュを提供し、後者の2つは容量を提供します。 NestedMirror レベルを -MediaType SSD に、NestedParity レベルを -MediaType HDDに設定します。For example, with NVMe, SSD, and HDD in the same cluster, the NVMe provides cache while the latter two provide capacity: set the NestedMirror tier to -MediaType SSD and the NestedParity tier to -MediaType HDD. この場合、パリティ容量の効率は HDD のドライブの数によってのみ異なります。また、サーバーごとに少なくとも4つのディスクが必要です。In this case, note that parity capacity efficiency depends on the number of HDD drives only, and you need at least 4 of them per server.

入れ子になった回復性を3台以上のサーバーで使用できますか。Can I use nested resiliency with 3 or more servers?

いいえ。クラスターにサーバーが2つだけある場合は、入れ子になった回復性のみを使用します。No, only use nested resiliency if your cluster has exactly 2 servers.

入れ子になった回復性を使用するには、何個のドライブが必要ですか。How many drives do I need to use nested resiliency?

記憶域スペースダイレクトに必要なドライブの最小数は、サーバーノードあたり4台の容量ドライブと、サーバーノードあたり2つのキャッシュドライブ (存在する場合) です。The minimum number of drives required for Storage Spaces Direct is 4 capacity drives per server node, plus 2 cache drives per server node (if any). これは、Windows Server 2016 から変更されていません。This is unchanged from Windows Server 2016. 入れ子になった回復性に関する追加の要件はありません。また、予約容量の推奨事項も変更されません。There is no additional requirement for nested resiliency, and the recommendation for reserve capacity is unchanged too.

[回復性の入れ子になっている場合、ドライブの交換方法を変更しますか?]Does nested resiliency change how drive replacement works?

いいえ。No.

回復性を入れ子にすると、サーバーノードの交換のしくみが変わりますか。Does nested resiliency change how server node replacement works?

いいえ。No. サーバーノードとそのドライブを置き換えるには、次の順序に従います。To replace a server node and its drives, follow this order:

  1. 発信サーバーのドライブをインベントリから削除するRetire the drives in the outgoing server
  2. 新しいサーバーとそのドライブをクラスターに追加します。Add the new server, with its drives, to the cluster
  3. 記憶域プールが再調整されるThe storage pool will rebalance
  4. 発信サーバーとそのドライブを削除するRemove the outgoing server and its drives

詳細については、サーバーの削除に関するトピックを参照してください。For details see the Remove servers topic.

関連項目See also