Azure Stack HCI および Windows Server クラスターのドライブを選択する
適用対象: Azure Stack HCI、バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019
この記事では、パフォーマンスおよび容量の要件を満たすドライブを選択する方法に関するガイダンスを提供します。
ドライブの種類
記憶域スペース ダイレクトは、Azure Stack HCI を支える基盤の記憶域仮想化テクノロジであり、現時点では次の 4 種類のドライブで動作します。
| ドライブの種類 | 説明 |
|---|---|
 |
PMem とは永続メモリを意味します。これは、低待機時間かつ高パフォーマンスの新しい種類の記憶域です。 |
 |
NVMe (Non-Volatile Memory Express) とは、PCIe バスに直接接続されたソリッドステート ドライブを指します。 一般的なフォーム ファクターは、2.5 インチU.2、PCIe Add-In-Card (AIC)、および M.2 です。 NVMe では、PMem を除いて、現在サポートされている他の種類のドライブよりも高い IOPS と IO スループットおよび低待機時間が実現します。 |
 |
SSD は、従来の SATA または SAS 経由で接続されるソリッドステート ドライブを指します。 |
 |
HDD は、大容量の記憶域容量を提供する、回転式の磁気ハード ディスク ドライブを指します。 |
注意
この記事では、NVMe、SSD、HDD によるドライブ構成の選択について説明します。 PMem の詳細については、「永続的なメモリの理解とデプロイ」を参照してください。
注意
単一サーバー構成では、ストレージ バス レイヤー (SBL) キャッシュはサポートされていません。 単一サーバーでサポートされるストレージの種類は、すべてフラットな単一ストレージの構成 (たとえば、すべて NVMe またはすべて SSD) のみです。
ビルトイン キャッシュ
記憶域スペース ダイレクトは、組み込みのサーバー側キャッシュを特徴とします。 これは、大容量で永続的な、リアルタイムの読み取りおよび書き込みキャッシュです。 複数の種類のドライブを使用するデプロイでは、"最速" の種類のすべてのドライブを使用するように自動的に構成されます。 残りのドライブは、キャパシティとして使用されます。
詳細については、「記憶域プール キャッシュとは」を参照してください。
オプション 1 – パフォーマンスの最大化
任意のデータに対するランダムな読み取りと書き込みで予測可能かつ一貫したミリ秒未満の待機時間を実現するか、非常に高い IOPS (1300 万以上を達成済み) または IO スループット (500 GB/秒以上の読み取りを達成済み) を実現するには、"オール フラッシュ" を選択する必要があります。
これを行うには複数の方法があります。
すべて NVMe。 NVMe のみを使用すると、最も予測可能な低待機時間を含む、比類のないパフォーマンスが得られます。 すべてのドライブが同じモデルの場合、キャッシュはありません。 耐久性の高い NVMe モデルと耐久性の低い NVMe モデルを混在させ、後者に対する書き込みをキャッシュするように前者を構成することもできます (セットアップが必要です)。
NVMe + SSD。 NVMe を SSD とともに使用すると、NVMe によって SSD への書き込みが自動的にキャッシュされます。 これにより、書き込みがキャッシュ内で結合され、必要に応じてのみデステージングされるため、SSD の消耗が軽減されます。 これにより、 NVMe に似た書き込み特性が得られる一方で、読み取りは同じく高速な SSD から直接提供されます。
すべて SSD。 NVMe のみの場合と同様に、すべてのドライブが同じモデルの場合、キャッシュはありません。 耐久性の高いモデルと耐久性の低いモデルを混在させる場合は、後者に対する書き込みをキャッシュするように前者を構成することができます (セットアップが必要です)。
注意
キャッシュなしで NVMe のみまたは SSD のみを使用する利点は、すべてのドライブから使用可能なストレージ容量を取得できることです。 キャッシュに "費やされる" 容量がないため、小規模のスケールで有用である場合があります。
オプション 2 – パフォーマンスと容量のバランスを取る
さまざまなアプリケーションやワークロードがあり、パフォーマンス要件が厳しい環境や、非常に多くのストレージ容量を必要とする環境では、大容量の HDD に対して NVMe または SSD キャッシュを使用して "ハイブリッド" にする必要があります。
NVMe + HDD。 NVMe ドライブは、読み取りと書き込みをキャッシュすることによって、その両方を高速化します。 読み取りのキャッシュにより、HDD は書き込みに集中することができます。 書き込みのキャッシュは、バーストを吸収し、必要な場合にのみ書き込みの結合とデステージングを可能にします。これは、HDD IOPS と IO スループットを最大化する、人為的にシリアル化された方法で行われます。 これにより、NVMe に似た書き込み特性が得られ、頻繁にまたは最近読み取られたデータに対して、NVMe に似た読み取り特性も得られます。
SSD + HDD。 上記と同様に、SSD は、読み取りと書き込みをキャッシュすることによって、その両方を高速化します。 これにより、SSD に似た書き込み特性と、頻繁にまたは最近読み取られたデータに対して、SSD に似た読み取り特性が得られます。
"3 つすべて" の種類のドライブ使用するという、もう 1 つ別の特殊なオプションがあります。
NVMe + SSD + HDD。 3 つすべての種類のドライブを使用する場合は、NVMe ドライブで SSD とHDD の両方に対してキャッシュが提供されます。 ここでの魅力的な点は、SSD 上にボリュームを作成し、HDD 上にボリュームを作成し、それらを同じクラスター内に並置して、すべて NVMe によって高速化できることです。 前者は "オール フラッシュ" デプロイとまったく同じであり、後者は上記の "ハイブリッド" デプロイとまったく同じです。 これは概念的には、大部分が独立した容量管理、障害および修復サイクルなどを備えた 2 つのプールを持つようなものです。
重要
SSD 階層を使用して、最もパフォーマンス要件の厳しいワークロードをオール フラッシュに配置することをお勧めします。
オプション 3 – 容量の最大化
アーカイブ、バックアップ ターゲット、データ ウェアハウス、または "コールド" ストレージなど、大容量を必要とし、書き込みの頻度が低いワークロードの場合は、キャッシュ用の小数の SSD を、容量用の多数の大容量 HDD と組み合わせる必要があります。
- SSD + HDD。 SSD は、読み取りと書き込みをキャッシュしてバーストを吸収し、SSD に似た書き込みパフォーマンスを提供し、後で HDD に対する最適化されたデステージングを行います。
重要
HDD のみを使用した構成はサポートされていません。 耐久性の低い SSD に対する耐久性の高い SSD のキャッシュはお勧めしません。
サイズに関する考慮事項
キャッシュ
各サーバーには、少なくとも 2 つのキャッシュ ドライブ (冗長性のために必要な最小値) が必要です。 容量ドライブの数は、キャッシュ ドライブの数の倍数にすることをお勧めします。 たとえば、4 台のキャッシュ ドライブがある場合、7 台や 9 台よりも 8 台の容量ドライブ (1:2 の比率) を使用した方がより一貫性のあるパフォーマンスを得ることができます。
キャッシュは、お使いのアプリケーションとワークロードのワーキング セット、つまり、それらが常にアクティブに読み取りおよび書き込みを行っているすべてのデータに対応できるようにサイズ設定する必要があります。 それを超えるキャッシュ サイズの要件はありません。 HDD を使用したデプロイでは、適正な初期構成は容量の 10% です。たとえば、各サーバーに 16 TB (4 x 4 TB HDD) の容量がある場合、サーバーあたりのキャッシュは 1.6 TB (2 x 800 GB SSD) になります。 オール フラッシュのデプロイ、特に非常に耐久性の高い SSD を使用する場合は、容量の 5% 近くから開始するのが妥当な場合があります。たとえば、各サーバーに 28.8 TB (24 x 1.2 TB SSD) の容量がある場合、サーバーあたりのキャッシュは 1.5 TB (2 x 750 GB NVMe) になります。 キャッシュ ドライブは、後でいつでも追加または削除して調整できます。
全般
サーバーあたりの合計ストレージ容量は、約 400 テラバイト (TB) に制限することをお勧めします。 サーバーあたりのストレージ容量が大きいほど、ソフトウェア更新プログラムを適用する場合など、ダウンタイムや再起動後のデータの再同期に必要な時間が長くなります。 記憶域プールあたりの現在の最大サイズは 4 ペタバイト (PB) (4,000 TB) です (Windows Server 2016 の場合は 1 PB)。
次のステップ
詳細については、次のトピックも参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示