適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019
この記事では、ワークロードのパフォーマンスと容量のニーズを満たすためにクラスターボリュームを計画する方法 (ファイルシステム、耐障害性タイプ、サイズの選択など) に関するガイダンスを提供します。
注
記憶域スペース ダイレクトは、一般的な使用のためのファイル サーバーをサポートしていません。 ファイル サーバーまたはその他の汎用サービスを記憶域スペース ダイレクトで実行する必要がある場合は、仮想マシンで構成します。
レビュー:ボリュームとは
ボリュームは、Hyper-V 仮想マシンの VHD ファイルや VHDX ファイルなど、ワークロードに必要なファイルを配置する場所です。 ボリュームは、記憶域プール内のドライブを組み合わせて、Azure Stack HCI と Windows Server の背後にあるソフトウェア定義のストレージ テクノロジである 記憶域スペース ダイレクトのフォールト トレランス、スケーラビリティ、パフォーマンスの利点を導入します。
注
"ボリューム" という用語は、ボリュームとその下の仮想ディスクを総称するために使用し、クラスター共有ボリューム (CSV) や ReFS などの他の組み込み Windows 機能によって提供される機能を含めます。 これらの実装レベルの違いを理解することは、記憶域スペース ダイレクトを正常に計画および展開するために必要ではありません。
すべてのボリュームは、クラスタ内のすべてのサーバから同時にアクセスできます。 作成されると、すべてのサーバーの C:\ClusterStorage\ に表示されます。
作成するボリューム数の選択
ボリュームの数は、クラスター内のサーバーの数に倍数にすることをお勧めします。 たとえば、サーバーが 4 台ある場合、合計ボリュームが 4 つある方が、3 つや 5 つの場合よりも一貫したパフォーマンスが得られます。 これにより、クラスターはボリュームの "所有権" (1 つのサーバーが各ボリュームのメタデータ オーケストレーションを処理) をサーバー間で均等に分散できます。
ボリュームの総数をクラスターあたり 64 個に制限することをお勧めします。
ファイルシステムの選択
記憶域スペース ダイレクトには、新しい Resilient File System (ReFS) を使用することをお勧めします。 ReFSは、仮想化専用に設計された最高のファイルシステムであり、劇的なパフォーマンスの高速化やデータ破損に対する組み込みの保護など、多くの利点があります。 Windows Server バージョン 1709 以降のデータ重複除去を含む、ほぼすべての主要な NTFS 機能をサポートしています。 詳細については、ReFS 機能の比較表 を参照してください。
ワークロードで ReFS がまだサポートされていない機能が必要な場合は、代わりに NTFS を使用できます。
ヒント
異なるファイルシステムを持つボリュームは、同じクラスタ内に共存できます。
レジリエンシーの種類の選択
記憶域スペース ダイレクトのボリュームは、ドライブやサーバーの障害などのハードウェアの問題から保護するための回復性を提供し、ソフトウェアの更新などのサーバーのメンテナンス全体で継続的な可用性を可能にします。
注
選択できる耐障害性の種類は、使用しているドライブの種類とは無関係です。
2台のサーバーを使用
クラスター内に 2 つのサーバーがある場合は、双方向ミラーリングを使用するか、入れ子になった復元を使用できます。
双方向ミラーリングでは、すべてのデータのコピーが 2 つ (各サーバーのドライブに 1 つずつ) 保持されます。 そのストレージ効率は50%です。1 TB のデータを書き込むには、ストレージプールに少なくとも 2 TB の物理ストレージ容量が必要です。 双方向ミラーリングでは、一度に 1 つのハードウェア障害 (1 つのサーバーまたはドライブ) を安全に許容できます。
入れ子になった復元は、双方向ミラーリングを使用してサーバー間のデータの復元性を提供し、その後、双方向ミラーリングまたはミラーリング高速化パリティを使用してサーバー内に復元を追加します。 ネストは、1 つのサーバーが再起動または使用できない場合でも、データの復元力を提供します。 そのストレージ効率は、ネストされた双方向ミラーリングで 25%、ネストされたミラーアクセラレーションパリティで約 35 から 40% です。 入れ子の復元では、一度に 2 つのハードウェア障害 (2 つのドライブ、またはサーバーと残りのサーバー上のドライブ) を安全に許容できます。 このデータ回復性の向上により、2 サーバー クラスターの運用環境のデプロイでは、入れ子型の回復性を使用することをお勧めします。 詳しくは、「 入れ子になった回復性」をご覧ください。
3台のサーバーを使用
サーバーが 3 台ある場合は、フォールト トレランスとパフォーマンスを向上させるために、3 方向ミラーリングを使用する必要があります。 3 方向ミラーリングでは、すべてのデータのコピーが 3 つ保持され、各サーバーのドライブに 1 つのコピーが保持されます。 そのストレージ効率は33.3%で、1TBのデータを書き込むには、ストレージプールに少なくとも3TBの物理ストレージ容量が必要です。 3 方向ミラーリングは、 一度に少なくとも 2 つのハードウェアの問題 (ドライブまたはサーバー) に安全に耐えることができます。 2 つのノードが使用できなくなった場合、ディスクの 2/3 が使用できず、仮想ディスクにアクセスできなくなるため、記憶域プールはクォーラムを失います。 ただし、ノードがダウンし、別のノード上の 1 つ以上のディスクに障害が発生しても、仮想ディスクがオンラインのままになることがあります。 たとえば、突然別のドライブまたはサーバーに障害が発生したときに 1 つのサーバーを再起動する場合、すべてのデータは安全で継続的にアクセスできます。
4台以上のサーバーを使用
4 台以上のサーバーでは、ボリュームごとに 3 ウェイ ミラーリングを使用するか、デュアル パリティ (「イレイジャー コーディング」と呼ばれることが多い) を使用するか、ミラー アクセラレーション パリティを使用して 2 つを混在させるかを選択できます。
デュアルパリティは、3ウェイミラーリングと同じフォールトトレランスを提供しますが、ストレージ効率が向上します。 4台のサーバーがある場合、ストレージ効率は50.0%です。2 TB のデータを格納するには、ストレージ プールに 4 TB の物理ストレージ容量が必要です。 これは、7台のサーバーで66.7%に増加し、最大80.0%のストレージ効率まで続きます。 トレードオフは、パリティエンコーディングはより計算負荷が高く、パフォーマンスが制限される可能性があることです。
どの耐障害性タイプを使用するかは、環境のパフォーマンスと容量の要件によって異なります。 次の表は、各耐障害性の種類のパフォーマンスとストレージ効率をまとめたものです。
| 回復性の種類 | 容量効率 | 速度 |
|---|---|---|
| 鏡 |
三面鏡:33% 2面鏡:50% |
最高のパフォーマンス |
| ミラー加速パリティ |
ミラーとパリティの比率に依存 |
mirror よりはるかに低速ですが、デュアルパリティの最大 2 倍の速度です 大規模なシーケンシャル書き込みと読み取りに最適 |
| デュアルパリティ |
4 サーバー: 50% 16 台のサーバー: 最大 80 台の% |
書き込み時のI/OレイテンシとCPU使用率が最も高い 大規模なシーケンシャル書き込みと読み取りに最適 |
パフォーマンスが最も重要な場合
SQL Server データベースやパフォーマンスに依存する Hyper-V 仮想マシンなど、待機時間の要件が厳しいワークロードや、多数の混合ランダム IOPS を必要とするワークロードは、ミラーリングを使用するボリュームで実行してパフォーマンスを最大化する必要があります。
ヒント
ミラーリングは、他のどの回復性の種類よりも高速です。 ほぼすべてのパフォーマンス例でミラーリングを使用しています。
容量が最も重要な場合
データウェアハウスや「コールド」ストレージなど、書き込み頻度の低いワークロードは、ストレージ効率を最大化するために、デュアルパリティを使用するボリュームで実行する必要があります。 Scale-Out File Server (SoFS)、仮想デスクトップインフラストラクチャ (VDI)、または高速でドリフトするランダム IO トラフィックを大量に作成しないワークロードや、最高のパフォーマンスを必要としないその他のワークロードも、お客様の裁量でデュアル パリティを使用できます。 パリティは、ミラーリングと比較して、特に書き込み時に CPU 使用率と IO レイテンシを必然的に増加させます。
データを一括で書き込む場合
アーカイブ・ターゲットやバックアップ・ターゲットなど、大規模なシーケンシャル・パスで書き込むワークロードには、1 つのボリュームにミラーリングとデュアル・パリティを混在させることができるという別のオプションがあります。 最初にミラー部分に土地を書き込み、後で徐々にパリティ部分に移動します。 これにより、インジェストが高速化され、計算負荷の高いパリティ エンコードが長時間にわたって行われるため、大量の書き込みが到着したときのリソース使用率が削減されます。 部分のサイズを設定するときは、一度に発生する書き込みの量 (1 日あたり 1 つのバックアップなど) がミラー部分に快適に収まる必要があることを考慮してください。 たとえば、100 GB を 1 日 1 回取り込む場合は、150 GB から 200 GB のミラーリングを使用し、残りの部分にデュアル パリティを使用することを検討してください。
結果として得られるストレージ効率は、選択した比率によって異なります。
ヒント
データ インジェストの途中で書き込みパフォーマンスが急激に低下した場合は、ミラー部分が十分に大きくないか、ミラー アクセラレーション パリティがユース ケースに適していないことを示している可能性があります。 たとえば、書き込みパフォーマンスが 400 MB/秒から 40 MB/秒に低下した場合は、ミラー部分を拡張するか、3 方向ミラーに切り替えることを検討してください。
NVMe、SSD、および HDD を使用したデプロイメントについて
2 種類のドライブを使用する展開では、高速なドライブがキャッシュを提供し、低速のドライブが容量を提供します。 これは自動的に行われます – 詳細については、「 記憶域スペース ダイレクトのキャッシュについて」を参照してください。 このような導入では、すべてのボリュームは最終的に同じタイプのドライブ(キャパシティー・ドライブ)に存在します。
3 種類のドライブすべてを使用する展開では、最速のドライブ (NVMe) のみがキャッシングを提供し、2 種類のドライブ (SSD と HDD) が容量を提供します。 ボリュームごとに、ボリューム全体が SSD 層に存在するか、完全に HDD 層に存在するか、または 2 つにまたがるかを選択できます。
Von Bedeutung
SSD レベルを使用して、パフォーマンスが最も高いワークロードをオール フラッシュに配置することをお勧めします。
ボリュームのサイズの選択
Azure Stack HCI では、各ボリュームのサイズを 64 TB に制限することをお勧めします。
ヒント
ボリューム シャドウ コピー サービス (VSS) と Volsnap ソフトウェア プロバイダーに依存するバックアップ ソリューションを使用する場合 (ファイル サーバーのワークロードでは一般的)、ボリューム サイズを 10 TB に制限すると、パフォーマンスと信頼性が向上します。 新しい Hyper-V RCT API や ReFS ブロック クローニング、ネイティブ SQL バックアップ API を使用するバックアップ ソリューションは、最大 32 TB 以上で優れたパフォーマンスを発揮します。
足跡
ボリュームのサイズは、その使用可能な容量、つまり格納できるデータの量を指します。 これは、New-Volume コマンドレットの -Size パラメーターによって提供され、Get-Volume コマンドレットを実行すると Size プロパティに表示されます。
サイズは、ボリュームの フットプリント (ストレージプール上でボリュームが占める物理ストレージ容量の合計) とは異なります。 フットプリントは、その回復性の種類によって異なります。 たとえば、3 方向ミラーリングを使用するボリュームのフットプリントは、そのサイズの 3 倍です。
ボリュームのフットプリントは、ストレージプールに収まる必要があります。
リザーブ容量
ストレージプール内の一部の容量を未割り当てのままにしておくと、ドライブの障害後にボリュームを「インプレース」で修復するためのスペースが確保され、データの安全性とパフォーマンスが向上します。 十分な容量がある場合は、障害が発生したドライブを交換する前でも、即時のインプレース並列修復により、ボリュームを完全な回復性に復元できます。 これは自動的に行われます。
サーバーごとに 1 つの容量ドライブに相当する容量 (最大 4 つのドライブ) を予約することをお勧めします。 お客様のご判断でさらに予約することもできますが、この最小限の推奨事項により、ドライブの故障後に即時のインプレース並列修理が成功することを保証します。
たとえば、2 台のサーバーがあり、1 TB の容量ドライブを使用している場合は、プールの 2 x 1 = 2 TB を予約として確保します。 3 台のサーバーと 1 TB の容量ドライブがある場合は、3 x 1 = 3 TB を予約として確保します。 4 台以上のサーバーと 1 TB の容量ドライブがある場合は、4 x 1 = 4 TB を予約として確保します。
注
3 つのタイプ(NVMe + SSD + HDD)すべてのドライブを持つクラスタでは、サーバごとに 1 つの SSD と 1 つの HDD に相当するもの (それぞれ最大 4 つのドライブ) を予約することをお勧めします。
例: キャパシティ プランニング
4 台のサーバーで構成される 1 つのクラスターについて考えてみます。 各サーバーには、いくつかのキャッシュ ドライブと、容量用の 16 台の 2 TB ドライブがあります。
4 servers x 16 drives each x 2 TB each = 128 TB
記憶域プール内のこの 128 TB から 4 つのドライブ (8 TB) を確保し、ドライブの障害後に急いで交換することなくインプレース修復を実行できるようにしています。 これにより、プールに120TBの物理ストレージ容量が残り、ボリュームを作成できます。
128 TB – (4 x 2 TB) = 120 TB
たとえば、非常にアクティブな Hyper-V 仮想マシンをホストするためにデプロイメントが必要で、古いファイルやバックアップを保持する必要があるコールドストレージもたくさんあるとします。 4 つのサーバーがあるため、4 つのボリュームを作成しましょう。
仮想マシンを最初の 2 つのボリューム ( Volume1 と Volume2) に配置しましょう。 ファイルシステムとしてReFSを選択し(作成とチェックポイントを高速化するため)、回復性のために3方向ミラーリングを選択してパフォーマンスを最大化します。 他の2つのボリューム、 Volume 3 と Volume 4にコールドストレージを入れましょう。 ファイルシステムとしてNTFS(データ重複排除用)を選択し、耐障害性のためにデュアルパリティを選択して容量を最大化します。
すべてのボリュームを同じサイズにする必要はありませんが、簡単にするために、たとえば、すべてのボリュームを12 TBにすることができます。
Volume1 と Volume2 は、それぞれ 12 TB x 33.3% の効率 = 36 TB の物理ストレージ容量を占有します。
Volume3 と Volume4 は、それぞれ 12 TB x 50.0% の効率 = 24 TB の物理ストレージ容量を占有します。
36 TB + 36 TB + 24 TB + 24 TB = 120 TB
4 つのボリュームは、プールで使用可能な物理ストレージ容量に正確に収まります。 完璧です!
ヒント
すべてのボリュームをすぐに作成する必要はありません。 ボリュームはいつでも拡張したり、後で新しいボリュームを作成したりできます。
わかりやすくするために、この例では全体で 10 進数 (10 進数) 単位、つまり 1 TB = 1,000,000,000 バイトを使用します。 ただし、Windows のストレージ容量は 2 進数 (2 進数) 単位で表示されます。 たとえば、各 2 TB ドライブは、Windows では 1.82 TiB と表示されます。 同様に、128 TB のストレージ プールは 116.41 TiB と表示されます。 これは想定されています。
使用方法
ボリュームの作成を参照してください。
次のステップ
詳細については、以下も参照してください。