記憶域プール キャッシュについて

適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019

Azure Stack HCI と Windows Server の背後にある基本的な記憶域仮想化テクノロジである記憶域スペース ダイレクトには、コストを削減しながら記憶域のパフォーマンスを最大化するための組み込みのサーバー側キャッシュが備わっています。 It's a large, persistent, real-time read and write cache that is configured automatically upon deployment. ほとんどの場合、手動管理は必要ありません。 キャッシュのしくみは、存在するドライブの種類によって異なります。

ドライブの種類と展開オプション

記憶域スペース ダイレクトは現在、次の 4 種類のドライブで動作します。

ドライブの種類	Description
	PMem refers to persistent memory, a new type of low latency, high performance storage.
	NVMe (Non-Volatile Memory Express) refers to solid-state drives that sit directly on the PCIe bus. 一般的なフォーム ファクターは、2.5 インチ U.2、PCIe Add-In-Card (AIC)、M.2 です。 NVMe は、PMem を除く現在サポートされている他の種類のドライブよりも低い待機時間で、より高い IOPS と I/O スループットを提供します。
	SSD refers to solid-state drives, which connect via conventional SATA or SAS.
	HDD refers to rotational, magnetic hard disk drives, which offer vast storage capacity at a low cost.

これらはさまざまな方法で組み合わせることができ、"オールフラッシュ" と "ハイブリッド" の 2 つのカテゴリに分類されます。 すべての HDD を使用したデプロイはサポートされていません。

オールフラッシュストレージ展開の可能性

オールフラッシュデプロイは、ストレージのパフォーマンスを最大化することを目的としており、HDD は含まれません。

ハイブリッド展開の可能性

ハイブリッド展開は、パフォーマンスと容量のバランスを取るか、容量を最大化することを目的としており、HDD も含まれます。

キャッシュ ドライブが自動的に選択される

複数の種類のドライブを使用する展開では、記憶域スペース ダイレクトでは、キャッシュに最も高速な種類のすべてのドライブが自動的に使用されます。 残りのドライブは記憶容量として使用されます。

"最速" の型は、次の階層に従って決定されます。

たとえば、NVMe と SSD がある場合、SSD の NVMe キャッシュです。

SSD と HDD がある場合、SSD は HDD のためのキャッシュとして機能します。

すべてのドライブが同じ種類の場合、キャッシュは自動的に構成されません。 You have the option to manually configure higher-endurance drives to cache for lower-endurance drives of the same type – see the Manual configuration section to learn how.

キャッシュ動作が自動的に設定される

キャッシュの動作は、キャッシュ対象のドライブの種類に基づいて自動的に決定されます。 フラッシュ ドライブのキャッシュ (SSD の NVMe キャッシュなど) の場合、書き込みのみがキャッシュされます。 ディスク ドライブのローテーション用にキャッシュする場合 (HDD の SSD キャッシュなど)、読み取りと書き込みの両方がキャッシュされます。

オールフラッシュ環境の書き込み専用キャッシュ

キャッシュはオールフラッシュ シナリオで使用できます。たとえば、NVMe をキャッシュとして使用して SSD のパフォーマンスを向上させることができます。 オールフラッシュ デプロイのキャッシュでは、書き込みのみがキャッシュされます。 これにより、多くの書き込みと書き換えがキャッシュ内で結合され、必要に応じてのみデステージされ、容量ドライブへの累積トラフィックが減少し、有効期間が長くなるため、容量ドライブの摩耗が軽減されます。 For this reason, we recommend selecting higher-endurance, write-optimized drives for the cache. 容量ドライブの書き込み耐久性は合理的に低い場合があります。

読み取りがフラッシュメモリーの寿命に大きな影響を与えないため、そしてSSDが常に低い読み取り待ち時間を提供するため、読み取り操作はキャッシュされず、容量ディスクから直接処理されます（データが最近書き込まれ、まだデステージされていない場合を除く）。 これにより、キャッシュを完全に書き込み専用にすることができ、その有効性が最大化されます。

これにより、書き込み待機時間などの書き込み特性がキャッシュ ドライブによって決まりますが、読み取り特性は容量ドライブによって決まります。 どちらも一貫性があり、予測可能で、均一です。

ハイブリッド展開の読み取り/書き込みキャッシュ

When caching for HDD, both reads and writes are cached, to provide flash-like latency (often ~10x better) for both. 読み取りキャッシュには、高速アクセスのために、および HDD へのランダム トラフィックを最小限に抑えるために、最近頻繁に読み取られたデータが格納されます。 (シークと回転の遅延のため、HDD へのランダム アクセスによって発生する待機時間と損失時間は大きくなります)。書き込みは、バーストを吸収し、以前と同様に、書き込みと書き換えを結合し、容量ドライブへの累積トラフィックを最小限に抑えるためにキャッシュされます。

記憶域スペース ダイレクトは、書き込みをステージング解除する前に、書き込みをデランダム化するアルゴリズムを実装します。これにより、ワークロードから実際の I/O (仮想マシンなど) がランダムである場合でも、順次と思われるディスクへの IO パターンがエミュレートされます。 これにより、HDD の IOPS とスループットが最大化されます。

NVMe、SSD、HDD を使用したデプロイでのキャッシュ

3 種類のドライブがすべて存在する場合、NVMe ドライブは SSD と HDD の両方にキャッシュを提供します。 動作は上で説明したように、SSD に対して書き込みのみがキャッシュされ、読み取りと書き込みの両方が HDD 用にキャッシュされます。 HDD のキャッシュの負荷は、キャッシュ ドライブ間で均等に分散されます。

Summary

次の表は、キャッシュに使用されるドライブ、容量に使用されるドライブ、および各デプロイの可能性に対するキャッシュ動作をまとめたものです。

Server-side architecture

キャッシュはドライブ レベルで実装されます。1 つのサーバー内の個々のキャッシュ ドライブは、同じサーバー内の 1 つまたは複数の容量ドライブにバインドされます。

キャッシュは Windows ソフトウェア定義記憶域スタックの残りの部分を下回っているため、記憶域スペースやフォールト トレランスなどの概念を認識する必要もありません。 これは、オペレーティング システムに表示される "ハイブリッド" (一部のフラッシュ、一部のディスク) ドライブを作成すると考えることができます。 実際のハイブリッド ドライブと同様に、物理メディアの高速部分と低速部分の間のホット データとコールド データのリアルタイムの移動は、外部にはほとんど見えません。

記憶域スペース ダイレクトの回復性が少なくともサーバー レベルであることを考えると (つまり、データ コピーは常に異なるサーバーに書き込まれます。サーバーごとに最大 1 つのコピー)、キャッシュ内のデータは、キャッシュにないデータと同じ回復性を利用します。

たとえば、3 方向ミラーリングを使用する場合、データの 3 つのコピーが異なるサーバーに書き込まれ、そこでキャッシュに格納されます。 後でデステージされるかどうかにかかわらず、常に 3 つのコピーが存在します。

ドライブ バインドは動的です

キャッシュ ドライブと容量ドライブの間のバインドには、1:1 から 1:12 以降までの任意の比率を使用できます。 スケールアップ時や障害発生後など、ドライブが追加または削除されるたびに動的に調整されます。 つまり、必要に応じて、キャッシュ ドライブまたは容量ドライブを個別に追加できます。

容量ドライブの数は、対称性のためにキャッシュ ドライブの数の倍数にすることをお勧めします。 たとえば、キャッシュ ドライブが 4 台の場合、7 または 9 よりも 8 つの容量ドライブ (1:2 の比率) でさらに高いパフォーマンスが得られます。

キャッシュ ドライブの障害の処理

キャッシュ ドライブが失敗すると、まだデステージされていない書き込みはすべて ローカル サーバーに失われます。つまり、他のコピー (他のサーバー内) にのみ存在します。 他のドライブ障害の後と同様に、記憶域スペースは、残っているコピーを確認することで自動的に回復できます。

しばらくの間、失われたキャッシュ ドライブにバインドされていた容量ドライブは異常に見えます。 キャッシュの再バインドが発生し (自動)、データの修復が完了 (自動) すると、正常と表示され再開されます。

このシナリオでは、パフォーマンスを維持するために、サーバーごとに少なくとも 2 つのキャッシュ ドライブが必要です。

その後、他のドライブの交換と同様に、キャッシュ ドライブを交換できます。

他のキャッシュとの関係

Windows ソフトウェア定義ストレージ スタックには、他にも関連のないキャッシュがいくつかあります。 たとえば、記憶域スペースのライトバック キャッシュとクラスター共有ボリューム (CSV) のインメモリ読み取りキャッシュがあります。

Azure Stack HCI では、記憶域スペース ライトバック キャッシュを既定の動作から変更しないでください。 For example, parameters such as -WriteCacheSize on the New-Volume cmdlet shouldn't be used.

CSV キャッシュを使用するかどうかは、ユーザーが選択できます。 Azure Stack HCI では既定でオンになっていますが、このトピックで説明されているキャッシュと競合することはありません。 特定のシナリオでは、パフォーマンスを向上させることができます。 詳細については、「 Azure Stack HCI で CSV インメモリ読み取りキャッシュを使用する」を参照してください。

Manual configuration

ほとんどのデプロイでは、手動構成は必要ありません。 必要な場合は、次のセクションを参照してください。

セットアップ後にキャッシュ デバイス モデルを変更する必要がある場合は、「ヘルス サービスの概要」の説明に従って、 Health Service のサポート コンポーネント ドキュメントを編集します。

キャッシュ ドライブ モデルの指定

すべてのドライブが同じ種類 (オール NVMe デプロイやオール SSD 展開など) のデプロイでは、Windows では同じ種類のドライブ間で書き込み耐久性などの特性を自動的に区別できないため、キャッシュは構成されません。

To use higher-endurance drives to cache for lower-endurance drives of the same type, you can specify which drive model to use with the -CacheDeviceModel parameter of the Enable-ClusterS2D cmdlet. そのモデルのすべてのドライブがキャッシュに使用されます。

Example

まず、物理ディスクの一覧を取得します。

Get-PhysicalDisk | Group Model -NoElement

出力例を次に示します。

Count Name
----- ----
    8 FABRIKAM NVME-1710
   16 CONTOSO NVME-1520

次に、キャッシュ デバイス モデルを指定して、次のコマンドを入力します。

Enable-ClusterS2D -CacheDeviceModel "FABRIKAM NVME-1710"

You can verify that the drives you intended are being used for caching by running Get-PhysicalDisk in PowerShell and verifying that their Usage property says "Journal".

手動デプロイの可能性

手動構成を使用すると、次の展開が可能になります。

キャッシュの動作を設定する

キャッシュの既定の動作をオーバーライドできます。 たとえば、オールフラッシュデプロイでも読み取りをキャッシュするように設定できます。 既定値がワークロードに合わないと確信している場合を除き、動作を変更することはお勧めしません。

To override the behavior, use Set-ClusterStorageSpacesDirect cmdlet and its -CacheModeSSD and -CacheModeHDD parameters. The CacheModeSSD parameter sets the cache behavior when caching for SSD. The CacheModeHDD parameter sets cache behavior when caching for HDD.

You can use Get-ClusterStorageSpacesDirect to verify the behavior is set.

Example

まず、記憶域スペース ダイレクトの設定を取得します。

Get-ClusterStorageSpacesDirect

出力例を次に示します。

CacheModeHDD : ReadWrite
CacheModeSSD : WriteOnly

次に、以下を実行します。

Set-ClusterStorageSpacesDirect -CacheModeSSD ReadWrite

Get-ClusterS2D

出力例を次に示します。

CacheModeHDD : ReadWrite
CacheModeSSD : ReadWrite

キャッシュのサイズ設定

キャッシュは、アプリケーションとワークロードのワーキング セット (任意の時点でアクティブに読み取りまたは書き込まれるデータ) に合わせてサイズ設定する必要があります。

これは、ハード ディスク ドライブを使用したハイブリッド展開で特に重要です。 アクティブなワーキング セットがキャッシュのサイズを超えた場合、またはアクティブなワーキング セットのドリフトが速すぎる場合は、読み取りキャッシュ ミスが増加し、書き込みを積極的に解除する必要があり、全体的なパフォーマンスが低下します。

Windows の組み込みのパフォーマンス モニター (PerfMon.exe) ユーティリティを使用して、キャッシュ ミスの割合を調べることができます。 具体的には、クラスター 記憶域ハイブリッド ディスク カウンターセットのキャッシュ ミス読み取り/秒を、デプロイの全体的な読み取り IOPS と比較できます。 各 "ハイブリッド ディスク" は、1 つの容量ドライブに対応します。

たとえば、4 つの容量ドライブにバインドされた 2 つのキャッシュ ドライブは、サーバーごとに 4 つの "ハイブリッド ディスク" オブジェクト インスタンスになります。

ユニバーサルルールはありませんが、読み取りが多すぎるとキャッシュが不足している可能性があるため、キャッシュを拡張するためにキャッシュ ドライブを追加することを検討する必要があります。 キャッシュ ドライブまたは容量ドライブは、必要に応じて個別に追加できます。

Next steps

ストレージに関するその他の知識については、以下も参照してください。

• 障害耐性とストレージ効率
• クラスターとプール クォーラム