記憶域スペース ダイレクトのボリュームの計画Planning volumes in Storage Spaces Direct

適用対象:Windows Server 2019、Windows Server 2016Applies to: Windows Server 2019, Windows Server 2016

このトピックでは、ファイルシステム、回復性の種類、サイズの選択など、ワークロードのパフォーマンスや容量のニーズを満たすように記憶域スペース ダイレクトでボリュームを計画する方法について説明します。This topic provides guidance for how to plan volumes in Storage Spaces Direct to meet the performance and capacity needs of your workloads, including choosing their filesystem, resiliency type, and size.

チェックボリュームとはReview: What are volumes

ボリュームは、ワークロードに必要なファイル (Hyper-v 仮想マシンの VHD ファイルや VHDX ファイルなど) を配置する場所です。Volumes are where you put the files your workloads need, such as VHD or VHDX files for Hyper-V virtual machines. ボリュームでは、記憶域スペース ダイレクトのフォールト トレランス、スケーラビリティ、パフォーマンス上のメリットを活かすため、記憶域プール内のドライブが組み合わされます。Volumes combine the drives in the storage pool to introduce the fault tolerance, scalability, and performance benefits of Storage Spaces Direct.

注意

記憶域スペース ダイレクトのドキュメント全体で、"ボリューム" という用語は、クラスター共有ボリューム (CSV) や ReFS など、他の組み込み Windows 機能により提供される機能を含む、ボリュームとその下の仮想ディスクを総称して使われます。Throughout documentation for Storage Spaces Direct, we use term "volume" to refer jointly to the volume and the virtual disk under it, including functionality provided by other built-in Windows features such as Cluster Shared Volumes (CSV) and ReFS. 記憶域スペース ダイレクトを正しく計画して展開するために、これらの実装レベルの違いを理解する必要はありません。Understanding these implementation-level distinctions is not necessary to plan and deploy Storage Spaces Direct successfully.

ボリュームとはvolumes

すべてのボリュームには、クラスター内のすべてのサーバーが同時にアクセスできます。All volumes are accessible by all servers in the cluster at the same time. 作成されると、すべてのサーバーのC:\ clusterstorage @ no__tに表示されます。Once created, they show up at C:\ClusterStorage\ on all servers.

csv フォルダーのスクリーンショット

作成するボリュームの数の選択Choosing how many volumes to create

ボリュームの数は、クラスター内のサーバーの数の倍数にすることをお勧めします。We recommend making the number of volumes a multiple of the number of servers in your cluster. たとえば、4台のサーバーがある場合、3または5よりも合計4つのボリュームでパフォーマンスの一貫性が向上します。For example, if you have 4 servers, you will experience more consistent performance with 4 total volumes than with 3 or 5. これにより、クラスターはボリュームの "所有権" (1 台のサーバーが各ボリュームのメタデータ オーケストレーションを処理) をサーバー間に均等に分散できます。This allows the cluster to distribute volume "ownership" (one server handles metadata orchestration for each volume) evenly among servers.

ボリュームの合計数を次のように制限することをお勧めします。We recommend limiting the total number of volumes to:

Windows Server 2016Windows Server 2016 Windows Server 2019Windows Server 2019
クラスターあたり最大32ボリュームUp to 32 volumes per cluster クラスターあたり最大64ボリュームUp to 64 volumes per cluster

ファイルシステムの選択Choosing the filesystem

記憶域スペース ダイレクトには新しい Resilient File System (ReFS) を使うことをお勧めします。We recommend using the new Resilient File System (ReFS) for Storage Spaces Direct. ReFS は、仮想化に特化して構築された高度なファイルシステムであり、大幅なパフォーマンス向上やデータ破損に対する組み込みの保護など、多くのメリットがあります。ReFS is the premier filesystem purpose-built for virtualization and offers many advantages, including dramatic performance accelerations and built-in protection against data corruption. Windows Server のデータ重複除去、バージョン1709以降を含む、ほぼすべての重要な NTFS 機能をサポートしています。It supports nearly all key NTFS features, including Data Deduplication in Windows Server, version 1709 and later. 詳細については、「ReFS機能の比較表」を参照してください。See the ReFS feature comparison table for details.

ReFS がまだサポートしていない機能がワークロードに必要な場合、代わりに NTFS を使うことができます。If your workload requires a feature that ReFS doesn't support yet, you can use NTFS instead.

ヒント

ファイル システムの異なるボリュームが同じクラスター内に共存することができます。Volumes with different file systems can coexist in the same cluster.

回復性の種類の選択Choosing the resiliency type

記憶域スペース ダイレクト内のボリュームには、ドライブやサーバーの障害などのハードウェアの問題から保護し、ソフトウェア更新などのサーバー メンテナンス時に継続的な可用性を確保できる回復性が備わっています。Volumes in Storage Spaces Direct provide resiliency to protect against hardware problems, such as drive or server failures, and to enable continuous availability throughout server maintenance, such as software updates.

注意

どの回復性を選ぶかは、使うドライブの種類とは関係ありません。Which resiliency types you can choose is independent of which types of drives you have.

サーバーが 2 台の場合With two servers

クラスター内に2つのサーバーがある場合は、双方向のミラーリングを使用できます。With two servers in the cluster, you can use two-way mirroring. Windows Server 2019 を実行している場合は、入れ子になった回復性を使用することもできます。If you're running Windows Server 2019, you can also use nested resiliency.

双方向のミラーリングでは、すべてのデータのコピーが2つ保持されます。各サーバーのドライブに1つのコピーがあります。Two-way mirroring keeps two copies of all data, one copy on the drives in each server. 記憶域の効率性は 50% で、1 TB のデータを書き込むには、記憶域プールに少なくとも 2 TB の物理記憶域容量が必要です。Its storage efficiency is 50%—to write 1 TB of data, you need at least 2 TB of physical storage capacity in the storage pool. 双方向のミラーリングでは、一度に1つのハードウェア障害が発生する可能性があります (1 台のサーバーまたはドライブ)。Two-way mirroring can safely tolerate one hardware failure at a time (one server or drive).

双方向ミラー

入れ子になった回復性 (Windows Server 2019 でのみ利用可能) では、双方向のミラーリングを使用するサーバー間でデータの回復性が提供されます。その後、双方向のミラーリングまたはミラーアクセラレータパリティを使用するサーバー内に回復性が加わります。Nested resiliency (available only on Windows Server 2019) provides data resiliency between servers with two-way mirroring, then adds resiliency within a server with two-way mirroring or mirror-accelerated parity. 入れ子にすると、1台のサーバーが再起動または使用できなくなった場合でも、データの復元が可能Nesting provides data resilience even when one server is restarting or unavailable. そのストレージ効率は、入れ子になった双方向ミラーリングでは 25%、入れ子になったミラーアクセラレータパリティでは約 35-40% です。Its storage efficiency is 25% with nested two-way mirroring and around 35-40% for nested mirror-accelerated parity. 入れ子になった回復性では、同時に2つのハードウェア障害が発生する可能性があります (2 台のドライブ、またはサーバーと残りのサーバーのドライブ)。Nested resiliency can safely tolerate two hardware failures at a time (two drives, or a server and a drive on the remaining server). この追加のデータ回復性により、Windows Server 2019 を実行している場合は、2台のサーバークラスターの運用環境のデプロイで、入れ子になった回復性を使用することをお勧めします。Because of this added data resilience, we recommend using nested resiliency on production deployments of two-server clusters, if you're running Windows Server 2019. 詳細については、「入れ子になった回復性」を参照してください。For more info, see Nested resiliency.

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

サーバーが 3 台の場合With three servers

サーバーが 3 台の場合は、3 方向ミラーリングを使って、フォールト トレランスとパフォーマンスを向上させてください。With three servers, you should use three-way mirroring for better fault tolerance and performance. 3 方向ミラーリングでは、すべてのデータのコピーが 3 つ保持されます (各サーバーのドライブ上にコピー 1 つずつ)。Three-way mirroring keeps three copies of all data, one copy on the drives in each server. その記憶域の効率は 33.3% です。つまり、1 TB のデータを書き込むには、記憶域プールに少なくとも 3 TB の物理的な記憶域の容量が必要になります。Its storage efficiency is 33.3% – to write 1 TB of data, you need at least 3 TB of physical storage capacity in the storage pool. 3 方向ミラーリングでは、一度に少なくとも 2 件のハードウェア問題 (ドライブやサーバー) に安全に対処できます。Three-way mirroring can safely tolerate at least two hardware problems (drive or server) at a time. 2つのノードが使用できなくなった場合、記憶域プールはクォーラムを失います。これは、ディスクの2/3 が使用できず、仮想ディスクがアクセスできなくになるためです。If 2 nodes become unavailable the storage pool will lose quorum, since 2/3 of the disks are not available, and the virtual disks will be unaccessible. ただし、ノードがダウンし、別のノード上の1つまたは複数のディスクで障害が発生し、仮想ディスクがオンラインのままになる場合があります。However, a node can be down and one or more disks on another node can fail and the virtual disks will remain online. たとえば、あるサーバーを再起動しているときに別のドライブやサーバーで突然障害が発生した場合、すべてのデータの安全性が保たれ、アクセスし続けることができます。For example, if you're rebooting one server when suddenly another drive or server fails, all data remains safe and continuously accessible.

3 方向ミラー

サーバーが 4 台以上の場合With four or more servers

4つ以上のサーバーがある場合は、3方向ミラーリングを使用するか ("消去コード" と呼ばれることも多い)、各ボリュームに対して、2つのパリティをミラーアクセラレータパリティとミックスするかを選択できます。With four or more servers, you can choose for each volume whether to use three-way mirroring, dual parity (often called "erasure coding"), or mix the two with mirror-accelerated parity.

デュアル パリティでは、3 方向ミラーリングと同じフォールト トレランスが実現されますが、記憶域の効率はより優れています。Dual parity provides the same fault tolerance as three-way mirroring but with better storage efficiency. 4台のサーバーで、記憶域の効率性は 50.0% です。 2 TB のデータを格納するには、記憶域プールに 4 TB の物理記憶域容量が必要です。With four servers, its storage efficiency is 50.0%—to store 2 TB of data, you need 4 TB of physical storage capacity in the storage pool. サーバーが 7 台の場合、記憶域の効率は 66.7% に上昇し、記憶域の効率は最大 80.0% まで上昇します。This increases to 66.7% storage efficiency with seven servers, and continues up to 80.0% storage efficiency. ただし、トレードオフとしてパリティ エンコーディングは負荷が高く、パフォーマンスが低下する可能性があります。The tradeoff is that parity encoding is more compute-intensive, which can limit its performance.

デュアル パリティ

どの回復性の種類を使うかは、ワークロードのニーズに応じて判断してください。Which resiliency type to use depends on the needs of your workload. 回復性の種類ごとに最適なワークロードと、各回復性の種類のパフォーマンスと記憶域の効率をまとめた表を次に示します。Here's a table that summarizes which workloads are a good fit for each resiliency type, as well as the performance and storage efficiency of each resiliency type.

回復性の種類Resiliency type 容量の効率Capacity efficiency 速度Speed ワークロードWorkloads
ミラーMirror 33% を示すストレージの効率性
3方向ミラー:33%Three-way mirror: 33%
双方向ミラー:50%Two-way-mirror: 50%
100% を示すパフォーマンス
最高のパフォーマンスHighest performance
仮想化されたワークロードVirtualized workloads
データベースDatabases
その他の高パフォーマンスワークロードOther high performance workloads
ミラーリングによって高速化されたパリティMirror-accelerated parity 約 50% を表示するストレージの効率性
ミラーとパリティの比率に依存Depends on proportion of mirror and parity
約 20% のパフォーマンス
ミラーよりもはるかに低速ですが、デュアルパリティと比べて最大2倍の速度で動作します。Much slower than mirror, but up to twice as fast as dual-parity
大規模なシーケンシャル書き込みと読み取りに最適Best for large sequential writes and reads
アーカイブとバックアップArchival and backup
仮想デスクトップインフラストラクチャVirtualized desktop infrastructure
デュアルパリティDual-parity 約 80% を表示するストレージの効率性
4台のサーバー:50%4 servers: 50%
16台のサーバー: 最大 80%16 servers: up to 80%
約 10% のパフォーマンス
書き込み時の CPU 使用率 & 最大の i/o 待機時間Highest I/O latency & CPU usage on writes
大規模なシーケンシャル書き込みと読み取りに最適Best for large sequential writes and reads
アーカイブとバックアップArchival and backup
仮想デスクトップインフラストラクチャVirtualized desktop infrastructure

パフォーマンスが最も重要な場合When performance matters most

SQL Server データベースやパフォーマンスが重視される Hyper-V 仮想マシンなど、待ち時間要件が高いワークロードまたは混合ランダム IOPS を必要とするワークロードは、パフォーマンスが最大限に高めるため、ミラーリングを使うボリュームで実行してください。Workloads that have strict latency requirements or that need lots of mixed random IOPS, such as SQL Server databases or performance-sensitive Hyper-V virtual machines, should run on volumes that use mirroring to maximize performance.

ヒント

ミラーリングは、他の種類の回復性よりも高速です。Mirroring is faster than any other resiliency type. Microsoft では、パフォーマンスが重要なほぼすべての例でミラーリングを使っています。We use mirroring for nearly all our performance examples.

容量が最も重要な場合When capacity matters most

データ ウェアハウスや "コールド" 記憶域など、書き込み頻度が低いワークロードは、記憶域の効率を最大限に高めるため、デュアル パリティを使うボリュームで実行してください。Workloads that write infrequently, such as data warehouses or "cold" storage, should run on volumes that use dual parity to maximize storage efficiency. 従来型のファイル サーバー、仮想デスクトップ インフラストラクチャ (VDI)、高速ドリフト ランダム IO トラフィックを多く生成しないワークロード、最高のパフォーマンスを必要としないワークロードなど、他の特定のワークロードでも、各自の判断でデュアル パリティを使うことができます。Certain other workloads, such as traditional file servers, virtual desktop infrastructure (VDI), or others that don't create lots of fast-drifting random IO traffic and/or don't require the best performance may also use dual parity, at your discretion. パリティでは、特に書き込みにおいて、必然的にミラーリングと比較して CPU 使用率と IO 待機時間が上昇します。Parity inevitably increases CPU utilization and IO latency, particularly on writes, compared to mirroring.

データが一括で書き込まれる場合When data is written in bulk

アーカイブ対象やバックアップ対象などの大規模なシーケンシャル パスで書き込むワークロードの場合、Windows Server 2016 の新しいオプションとして、1 つのボリュームにミラーリングとデュアル パリティを混在させることができます。Workloads that write in large, sequential passes, such as archival or backup targets, have another option that is new in Windows Server 2016: one volume can mix mirroring and dual parity. 書き込みはまずミラーリングされた部分に行われ、徐々にパリティ部分に移行していきます。Writes land first in the mirrored portion and are gradually moved into the parity portion later. これにより、負荷の高いパリティ エンコーディングを長時間実行できるようになるため、大規模な書き込み時に取り込みが高速化されてリソース使用率が低下します。This accelerates ingestion and reduces resource utilization when large writes arrive by allowing the compute-intensive parity encoding to happen over a longer time. 各部分のサイズを設定する場合、一度に発生する書き込みの量 (毎日行うバックアップ 1 回分のサイズなど) がミラーリング部分に十分に収まるようにしてください。When sizing the portions, consider that the quantity of writes that happen at once (such as one daily backup) should comfortably fit in the mirror portion. たとえば、1 日に 1 回 100 GB を取り込む場合は、ミラーリング用に 150 GB ~ 200 GB を使い、残りをデュアル パリティに使うことを検討してください。For example, if you ingest 100 GB once daily, consider using mirroring for 150 GB to 200 GB, and dual parity for the rest.

最終的な記憶率の効率は、選んだ比率によって決まります。The resulting storage efficiency depends on the proportions you choose. 例については、このデモをご覧ください。See this demo for some examples.

ヒント

データインジェストの途中で書き込みパフォーマンスが急激に低下した場合は、ミラーの部分が十分でないか、ミラーアクセラレータのパリティがユースケースに適していないことを示している可能性があります。If you observe an abrupt decrease in write performance partway through data ingestion, it may indicate that the mirror portion is not large enough or that mirror-accelerated parity isn't well suited for your use case. たとえば、書き込みパフォーマンスが 400 MB/秒から 40 MB/秒に低下した場合は、ミラーの部分を拡張するか、3方向ミラーに切り替えることを検討してください。As an example, if write performance decreases from 400 MB/s to 40 MB/s, consider expanding the mirror portion or switching to three-way mirror.

NVMe、SSD、HDD を使った展開についてAbout deployments with NVMe, SSD, and HDD

2 種類のドライブが展開に存在する場合、速い方のドライブがキャッシングに使用され、遅い方のドライブがデータ格納用として使用されます。In deployments with two types of drives, the faster drives provide caching while the slower drives provide capacity. これは、自動的に行われます。詳しくは、「記憶域スペース ダイレクトのキャッシュについて」をご覧ください。This happens automatically – for more information, see Understanding the cache in Storage Spaces Direct. このような展開では、最終的にすべてのボリュームが同じ種類のドライブ (データ格納用ドライブ) が存在することになります。In such deployments, all volumes ultimately reside on the same type of drives – the capacity drives.

3 種類のドライブがすべて存在する展開の場合、最も速いドライブ (NVMe) だけがキャッシュに使用され、残りの 2 種類のドライブ (SSD と HDD) がデータ格納用として使用されます。In deployments with all three types of drives, only the fastest drives (NVMe) provide caching, leaving two types of drives (SSD and HDD) to provide capacity. ボリュームごとに、すべて SSD 階層に配置する、すべて HDD 階層に配置する、または 2 つの階層にまたがって配置するかを選ぶことができます。For each volume, you can choose whether it resides entirely on the SSD tier, entirely on the HDD tier, or whether it spans the two.

重要

SSD 階層を使って、パフォーマンスを最も重視するワークロードをオールフラッシュに配置することをお勧めします。We recommend using the SSD tier to place your most performance-sensitive workloads on all-flash.

ボリュームのサイズの選択Choosing the size of volumes

各ボリュームのサイズは次のように制限することをお勧めします。We recommend limiting the size of each volume to:

Windows Server 2016Windows Server 2016 Windows Server 2019Windows Server 2019
最大 32 TBUp to 32 TB 最大 64 TBUp to 64 TB

ヒント

ファイルサーバーのワークロードに共通するように、ボリュームシャドウコピーサービス (VSS) と Volsnap ソフトウェアプロバイダーに依存するバックアップソリューションを使用する場合は、ボリュームサイズを 10 TB に制限すると、パフォーマンスと信頼性が向上します。If you use a backup solution that relies on the Volume Shadow Copy service (VSS) and the Volsnap software provider—as is common with file server workloads—limiting the volume size to 10 TB will improve performance and reliability. 新しい Hyper-V RCT API、ReFS のブロックの複製、ネイティブ SQL バックアップ API を使うバックアップ ソリューションは、最大 32 TB 以上で適切に動作します。Backup solutions that use the newer Hyper-V RCT API and/or ReFS block cloning and/or the native SQL backup APIs perform well up to 32 TB and beyond.

フットプリントFootprint

ボリュームのサイズとは、使用可能な容量、つまり格納可能なデータの量を指します。The size of a volume refers to its usable capacity, the amount of data it can store. これは、New-Volume コマンドレットの -Size パラメーターにより示され、Get-Volume コマンドレットを実行すると Size プロパティに表示されます。This is provided by the -Size parameter of the New-Volume cmdlet and then appears in the Size property when you run the Get-Volume cmdlet.

サイズは、ボリュームのフットプリントとは異なります。フットプリントは、記憶域プールにおいてボリュームが占める物理的な記憶域の最大容量です。Size is distinct from volume's footprint, the total physical storage capacity it occupies on the storage pool. フットプリントは、その回復性の種類によって異なります。The footprint depends on its resiliency type. たとえば、3 方向ミラーリングを使うボリュームのフットプリントはサイズの 3 倍です。For example, volumes that use three-way mirroring have a footprint three times their size.

ボリュームのフットプリントは、記憶域プールに収まる必要があります。The footprints of your volumes need to fit in the storage pool.

サイズとフットプリントの違い

容量の予約Reserve capacity

記憶域プール内の一部の容量を未割り当てのままにすると、ドライブで障害が発生した後、ボリューム領域が "インプレース" で修復され、データの安全性とパフォーマンスが向上します。Leaving some capacity in the storage pool unallocated gives volumes space to repair "in-place" after drives fail, improving data safety and performance. 容量が十分ある場合、インプレースの即時並行修復を行うと、障害が発生したドライブを交換する前でもボリュームが完全回復状態になります。If there is sufficient capacity, an immediate, in-place, parallel repair can restore volumes to full resiliency even before the failed drives are replaced. これは自動的に行われます。This happens automatically.

サーバー (ドライブが最大 4 台) あたりドライブ 1 台分に相当する容量を予約することをお勧めします。We recommend reserving the equivalent of one capacity drive per server, up to 4 drives. 各自の判断でさらに多く予約することができますが、この最小推奨容量で、ドライブの障害発生後インプレースの即時並行修復が正常に行われます。You may reserve more at your discretion, but this minimum recommendation guarantees an immediate, in-place, parallel repair can succeed after the failure of any drive.

予約

たとえば、サーバーが 2 台あって容量が 1 TB のドライブを使っている場合、2 x 1 = 2 TB のプールを予約として取っておきます。For example, if you have 2 servers and you are using 1 TB capacity drives, set aside 2 x 1 = 2 TB of the pool as reserve. サーバーが 3 台あって容量が 1 TB のドライブを使っている場合、3 x 1 = 3 TB を予約として取っておきます。If you have 3 servers and 1 TB capacity drives, set aside 3 x 1 = 3 TB as reserve. サーバーが 4 台以上あって容量が 1 TB のドライブを使っている場合、4 x 1 = 4 TB を予約として取っておきます。If you have 4 or more servers and 1 TB capacity drives, set aside 4 x 1 = 4 TB as reserve.

注意

3 種類のドライブ (NVMe + SSD + HDD) がすべてあるクラスターでは、サーバー (それぞれドライブが最大 4 台) あたり SSD + HDD 1 台分に相当する容量を予約することをお勧めします。In clusters with drives of all three types (NVMe + SSD + HDD), we recommend reserving the equivalent of one SSD plus one HDD per server, up to 4 drives of each.

例:容量計画Example: Capacity planning

サーバーが 4 台存在するクラスターが 1 つあるとします。Consider one four-server cluster. 各サーバーには、いくつかのキャッシュ ドライブと、データ格納用に 16 台の 2 TB ドライブがあります。Each server has some cache drives plus sixteen 2 TB drives for capacity.

4 servers x 16 drives each x 2 TB each = 128 TB

記憶域プール内のこの 128 TB から、障害後ドライブを急いで交換しなくてもインプレースの修復が行われるように 4 台のドライブ (つまり 8 TB) を取っておきます。From this 128 TB in the storage pool, we set aside four drives, or 8 TB, so that in-place repairs can happen without any rush to replace drives after they fail. こうすると、ボリュームを作成可能な 120 TB の物理容量がプール内に残ります。This leaves 120 TB of physical storage capacity in the pool with which we can create volumes.

128 TB – (4 x 2 TB) = 120 TB

展開でかなりアクティブな Hyper-V 仮想マシンをホストする必要があるが、コールド記憶域 (保持する必要がある古いファイルやバックアップ) も多くあるとします。Suppose we need our deployment to host some highly active Hyper-V virtual machines, but we also have lots of cold storage – old files and backups we need to retain. サーバーが 4 台あるため、ボリュームを 4 つ作成しましょう。Because we have four servers, let's create four volumes.

仮想マシンは、最初の 2 つのボリューム (Volume1 および Volume2) に置きます。Let's put the virtual machines on the first two volumes, Volume1 and Volume2. ファイルシステムとして ReFS を選び (すばやい作成とチェックポイントのため)、パフォーマンスを最大限に高めるため回復性として 3 方向ミラーリングを選びます。We choose ReFS as the filesystem (for the faster creation and checkpoints) and three-way mirroring for resiliency to maximize performance. コールド記憶域は、別の 2 つのボリューム (Volume 3 および Volume 4) に置きます。Let's put the cold storage on the other two volumes, Volume 3 and Volume 4. ファイルシステムとして NTFS を選び (データ重複除去のため)、容量を最大限に大きくするため回復性としてデュアル パリティを選びます。We choose NTFS as the filesystem (for Data Deduplication) and dual parity for resiliency to maximize capacity.

すべてのボリュームを同じサイズにする必要はありませんが、簡潔にするため、たとえばすべてのボリュームを 12 TB にすることができます。We aren't required to make all volumes the same size, but for simplicity, let's – for example, we can make them all 12 TB.

Volume1Volume2は、それぞれ 33.3% の効率で 12 TB 専有するため、記憶域の合計容量は 36 TB になります。Volume1 and Volume2 will each occupy 12 TB x 33.3% efficiency = 36 TB of physical storage capacity.

Volume3Volume4は、それぞれ 50.0% の効率で 12 TB 専有するため、記憶域の合計容量は 24 TB になります。Volume3 and Volume4 will each occupy 12 TB x 50.0% efficiency = 24 TB of physical storage capacity.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

4 つのボリュームは、プール内で使用できる物理的な記憶域の容量とまったく同じになります。The four volumes fit exactly on the physical storage capacity available in our pool. よくできました。Perfect!

例

ヒント

すべてのボリュームをすぐに作成する必要はありません。You don't need to create all the volumes right away. ボリュームはいつでも拡張できますし、新しいボリュームを後で作成することもできます。You can always extend volumes or create new volumes later.

簡潔にするため、この例を通じて 10 進法の単位を使っています (つまり、1 TB = 1,000,000,000,000 バイト)。For simplicity, this example uses decimal (base-10) units throughout, meaning 1 TB = 1,000,000,000,000 bytes. しかし、Windows の記憶域の数量は 2 進法の単位で表示されます。However, storage quantities in Windows appear in binary (base-2) units. たとえば、2 TB の各ドライブは Windows では 1.82 TiB と表示されます。For example, each 2 TB drive would appear as 1.82 TiB in Windows. 同様に、128 TB の記憶域プールは 116.41 TiB と表示されます。Likewise, the 128 TB storage pool would appear as 116.41 TiB. これは正常な動作です。This is expected.

使用方法Usage

記憶域スペース ダイレクトのボリュームの作成」をご覧ください。See Creating volumes in Storage Spaces Direct.

関連項目See also