記憶域プール キャッシュについて
適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server 2019
重要
Azure Stack HCI が Azure Local の一部になりました。 製品ドキュメントの名前変更が進行中です。 ただし、古いバージョンの Azure Stack HCI (22H2 など) は引き続き Azure Stack HCI を参照し、名前の変更は反映されません。 詳細情報。
記憶域スペース ダイレクトは、Azure Stack HCI と Windows Server を支える基盤の記憶域仮想化テクノロジであり、組み込みのサーバー側キャッシュでコストを削減しながら記憶域のパフォーマンスを最大化できるのが特徴です。 これは、デプロイ時に自動的に構成される、大規模で永続的な、リアルタイムの読み取りおよび書き込みキャッシュです。 ほとんどの場合、手動管理は一切必要ありません。 キャッシュの動作方法は、存在するドライブの種類によって異なります。
ドライブの種類とデプロイ オプション
記憶域スペース ダイレクトは現在、次の 4 種類のドライブで動作します。
| ドライブの種類 | 説明 |
|---|---|
 |
PMem とは永続メモリを意味します。これは、低待機時間かつ高パフォーマンスの新しい種類の記憶域です。 |
 |
NVMe (Non-Volatile Memory Express) とは、PCIe バスに直接接続されたソリッドステート ドライブを指します。 一般的なフォーム ファクターは、2.5 インチU.2、PCIe Add-In-Card (AIC)、および M.2 です。 NVMe では、PMem を除いて、現在サポートされている他の種類のドライブよりも高い IOPS と I/O スループットおよび低遅延が実現します。 |
 |
SSD は、従来の SATA または SAS 経由で接続されるソリッドステート ドライブを指します。 |
 |
HDD は、大容量のストレージ容量を低価格で提供する、回転式の磁気ハード ディスク ドライブを指します。 |
これらはさまざまな方法で組み合わせることができ、"オールフラッシュ" と "ハイブリッド" という 2 つのカテゴリに分類されます。 すべての HDD を使用したデプロイはサポートされていません。
Note
この記事では、NVMe、SSD、HDD によるドライブ構成について説明します。 永続メモリをキャッシュとして使用する方法の詳細については、「永続的なメモリの理解とデプロイ」を参照してください。
オールフラッシュ デプロイの可能性
オールフラッシュ デプロイは、ストレージのパフォーマンスを最大化することを目標としたものであり、HDD が含まれません。
ハイブリッド デプロイの可能性
ハイブリッド デプロイは、パフォーマンスと容量のバランスの調和または容量の最大化を目標としたもので、HDD が含まれます。
Note
単一サーバー構成では、ハイブリッド デプロイはサポートされていません。 単一サーバーでサポートされるストレージの種類は、すべてフラットな単一ストレージの構成 (たとえば、すべて NVMe またはすべて SSD) のみです。
キャッシュ ドライブが自動的に選択される
複数の種類のドライブがあるデプロイでは、記憶域スペース ダイレクトにより最も高速な種類のドライブが自動的にキャッシュとして使用されます。 残りのドライブは、キャパシティとして使用されます。
どの種類が "最も高速" であるかは、次の階層に従って決定されます。
たとえば、NVMe と SSD がある場合、NVMe は SSD のキャッシュとして使用されます。
SSD と HDD がある場合、SSD が HDD のキャッシュとして使用されます。
Note
キャッシュ ドライブでは、クラスターに使用可能なストレージ容量は提供されません。 キャッシュに格納されているすべてのデータは、他の場所にも格納されているか、またはデステージされると格納されます。 つまり、クラスターの未加工の合計ストレージ容量は、お使いの容量ドライブの合計のみです。
すべてのドライブが同じ種類である場合、キャッシュは自動的に構成されません。 手動で構成を行うと、耐久性の高いドライブを、同じ種類の耐久性の低いドライブのキャッシュとして使うことができます。構成方法については、「手動構成」セクションをご覧ください。
ヒント
ストレージ プール キャッシュの使用が適さない場合もあります。 たとえば、NVMe のみまたは SSD のみのデプロイでは、非常に小規模な場合は特に、キャッシュに "費やす" ドライブをなくすことで、ストレージの効率を向上させ、パフォーマンスを最大化させることができます。 同様に、小規模なリモートまたはブランチ オフィスのデプロイでは、キャッシュ ドライブのスペースが限られている場合があります。
キャッシュ動作が自動的に設定される
キャッシュの動作は、キャッシュの対象となるドライブの種類に応じて自動的に決まります。 キャッシュの対象がフラッシュ ドライブの場合 (SSD のキャッシュを NVMe に保存する場合など) には、書き込みのみがキャッシュに保存されます。 キャッシュの対象が回転ディスク ドライブの場合 (HDD のキャッシュを SSD に保存する場合など) には、読み取りと書き込みの両方がキャッシュに保存されます。
オールフラッシュ デプロイ用の書き込み専用キャッシュ
キャッシュは、オールフラッシュのシナリオで使用できます。たとえば、NVMe をキャッシュとして使用して、SSD のパフォーマンスを向上させることができます。 キャッシュの対象がオールフラッシュ デプロイの場合、書き込みのみがキャッシュに保存されます。 こうすることによって、多数の書き込みと再書き込みが結合されて、必要時にのみデステージできるため、容量ドライブの消耗が軽減され、容量ドライブへのトラフィックの累積量が減り、ドライブの寿命が延びます。 このため、耐久性に優れ、書き込みが最適化されたドライブをキャッシュとして選択することをお勧めします。 容量ドライブでは、書き込みの耐久性が低い可能性があります。
読み取りはフラッシュの寿命に大きな影響を与えず、また、SSD の読み取り待機時間は一般的に短いため、読み取りはキャッシュに保存されず、容量ドライブから直接提供されます (データが最近書き込まれ、まだデステージされていない場合を除きます)。 これにより、キャッシュを完全に書き込み専用にし、その有効性を最大限に高めることができます。
この展開では、書き込み待機時間などの書き込み特性はキャッシュ ドライブによって決まり、読み取り特性は容量ドライブによって決まることになります。 どちらも一貫性を持ち、予測可能性であり、一様です。
ハイブリッド デプロイの読み取り/書き込みキャッシュ
キャッシュの対象が HDD の場合には、読み取りおよび書き込みの両方がキャッシュに保存され、どちらにもフラッシュと同等の待機時間 (多くの場合、約 10 倍のスピード) が実現されます。 読み取りキャッシュでは、高速アクセスのために、最近の頻繁に読み取られるデータを格納し、HDD へのランダムなトラフィックを最小限に抑えることができます。 (シークと回転の遅延のため、HDD へのランダム アクセスによって発生する待機時間と損失時間は大きくなります)。書き込みは、バーストを吸収し、以前と同様に、書き込みと再書き込みを結合し、容量ドライブへの累積トラフィックを最小限に抑えるためにキャッシュされます。
記憶域スペース ダイレクトには、書き込みを非ランダム化してからデステージするアルゴリズムが実装されています。これは、ワークロード (仮想マシンなど) からの実際の I/O がランダムである場合でもシーケンシャルであるように見える IO パターンをディスクにエミュレートするためのものです。 これにより、HDD の IOPS とスループットが最大限に高められます。
NVMe、SSD、および HDD を使用するデプロイでのキャッシュ
3 種類すべてのドライブが存在する場合、NVMe ドライブは、SSD と HDD の両方にキャッシュを提供します。 この動作は、前に説明したように、SSD の場合は書き込みのみがキャッシュされ、HDD の場合は読み取りと書き込みの両方がキャッシュされます。 HDD を対象とするキャッシュの負荷は、キャッシュ ドライブ間で均等に分散されます。
まとめ
次の表は、それぞれの組み合わせの展開について、キャッシュとして使われるドライブ、容量として使われるドライブ、キャッシュ動作をまとめたものです。
| デプロイ | キャッシュ ドライブ | 容量ドライブ | キャッシュの動作 (既定) |
|---|---|---|---|
| NVMe のみ | なし (オプション: 手動で構成) | NVMe | 書き込み専用 (構成されている場合) |
| SSD のみ | なし (オプション: 手動で構成) | SSD | 書き込み専用 (構成されている場合) |
| NVMe + SSD | NVMe | SSD | 書き込み専用 |
| NVMe + HDD | NVMe | HDD | 読み取り + 書き込み |
| SSD + HDD | SSD | HDD | 読み取り + 書き込み |
| NVMe + SSD + HDD | NVMe | SSD + HDD | HDD の場合は読み取りと書き込み、SSD の場合は書き込み専用 |
サーバー側のアーキテクチャ
キャッシュはドライブ レベルで実装されます。1 台のサーバー内の個々のキャッシュ ドライブは、同じサーバー内の 1 台以上の容量ドライブにバインドされます。
キャッシュは Windows ソフトウェア定義記憶域スタックの他の部分よりも下層に位置するため、記憶域スペースやフォールト トレランスといった概念を意識する必要はありません。 これは、オペレーティング システムに提示される "ハイブリッド" (部分フラッシュ、部分ディスク) ドライブを作成していると考えることができます。 実際のハイブリッド ドライブと同様に、物理メディアの高速部分と低速部分をまたぐホット データとコールド データのリアルタイムの移動が外部から認識されることはほとんどありません。
記憶域スペース ダイレクトの回復性は少なくともサーバー レベルである (データ コピーは常に複数のサーバーに書き込まれ、サーバーごとに最大 1 つのコピーが保持される) ことから、キャッシュ内のデータにも、キャッシュに含まれていないデータと同等の回復性が与えられます。
たとえば、3 方向のミラーリングを使用する場合、データの 3 つのコピーが異なるサーバーに書き込まれ、そこでキャッシュに保存されます。 これらが後でデステージされるかどうかにかかわらず、3 つのコピーが常に存在します。
ドライブのバインドが動的である
キャッシュと容量ドライブ間のバインドには、1:1 から最大 1:12 までの任意の比率が設定されます。 これは、ドライブが追加または削除されるたびに動的に調整されます (スケールアップ時や障害の発生後など)。 つまり、必要な場合はいつでも、キャッシュ ドライブまたは容量ドライブを個別に追加できます。
容量ドライブの数は、対称とするために、キャッシュ ドライブの倍数にすることをお勧めします。 たとえば、4 台のキャッシュ ドライブがある場合は、容量ドライブが 7 台や 9 台ではなく 8 台 (1:2 の比率) の場合に、より均等なパフォーマンスが得られます。
キャッシュ ドライブの障害の処理
キャッシュ ドライブで障害が発生すると、まだステージング解除されていない書き込みはすべてローカル サーバーから失われ、(他のサーバー上の) 他のコピーだけが存在する状態になります。 他のドライブ障害が発生した場合と同様に、記憶域スペースは、残っているコピーを調べて自動的に回復できます。
一時的に、失われたキャッシュ ドライブにバインドされていた容量ドライブが異常と表示されます。 キャッシュの再バインドが (自動) 実行され、データの (自動) 修復が完了すると、再び正常として表示されます。
パフォーマンスを維持するために、サーバーあたり少なくとも 2 つのキャッシュ ドライブが必要であるのは、このようなシナリオのためです。
その後、他のドライブの交換と同様に、キャッシュ ドライブを交換できます。
注意
アドイン カード (AIC) または M.2 フォーム ファクターである NVMe を安全に交換するために、電源の切断が必要な場合があります。
他のキャッシュとの関係
Windows ソフトウェアで定義された記憶域スタックには、関連付けられていない他のキャッシュがいくつかあります。 例としては、記憶域スペースのライトバック キャッシュやクラスターの共有ボリューム (CSV) のメモリ内読み取りキャッシュなどがあります。
Azure Stack HCI では、記憶域スペースのライトバック キャッシュを既定の動作から変更することはできません。 たとえば、New-Volume コマンドレットの -WriteCacheSize などのパラメーターは使用できません。
CSV キャッシュを使用するかどうかはユーザーが自由に選択できます。 Azure Stack HCI では既定でオンになっていますが、このトピックで説明するキャッシュとは競合しません。 特定のシナリオでは、パフォーマンスを向上させることができます。 詳細については、Azure Stack HCI での CSV インメモリ読み取りキャッシュの使用に関するページを参照してください。
手動構成
ほとんどのデプロイで、手動の構成は必要ありません。 必要な場合は、以降のセクションを参照してください。
セットアップ後にキャッシュ デバイス モデルを変更する必要がある場合は、ヘルス サービスの概要に関する記事で説明されているように、ヘルス サービスのサポート コンポーネント ドキュメントを編集してください。
キャッシュ ドライブ モデルを指定する
すべて NVMe やすべて SSD の展開のようにすべてのドライブが同じ種類の展開では、書き込みに対する耐久性などの特性について、同じ種類のドライブ間の違いを Windows で自動的に識別することができないため、キャッシュは構成されません。
耐久性の高いドライブを使って同じ種類の耐久性の低いドライブをキャッシュするには、Enable-ClusterS2D コマンドレットの -CacheDeviceModel パラメーターに、キャッシュとして使用するドライブ モデルを指定します。 そのモデルのすべてのドライブがキャッシュに使用されます。
ヒント
モデルの文字列は、Get-PhysicalDiskの出力に示されるものと完全に一致させる必要があります。
例
まず、物理ディスクの一覧を取得します。
Get-PhysicalDisk | Group Model -NoElement
出力例を次に示します。
Count Name
----- ----
8 FABRIKAM NVME-1710
16 CONTOSO NVME-1520
次に、以下のコマンドを入力して、キャッシュ デバイス モデルを指定します。
Enable-ClusterS2D -CacheDeviceModel "FABRIKAM NVME-1710"
意図したドライブがキャッシュとして使用されていることを確かめるには、PowerShell で Get-PhysicalDisk を実行し、Usage プロパティが "Journal" になっていることを確認します。
手動デプロイの可能性
手動構成によって、次のデプロイが可能になります。
キャッシュの動作を設定する
キャッシュの既定の動作をオーバーライドできます。 たとえば、オールフラッシュ デプロイでも、読み取りをキャッシュするように設定できます。 既定値がワークロードに合わないことが明らかな場合を除き、動作を変更することはお勧めしません。
動作をオーバーライドするには、パラメーター -CacheModeSSD と -CacheModeHDD を指定して Set-ClusterStorageSpacesDirectコマンドレットを使用します。 CacheModeSSD パラメーターでは、SSD のキャッシュ時のキャッシュ動作を設定します。 CacheModeHDD パラメーターでは、HDD のキャッシュ時のキャッシュ動作を設定します。
Get-ClusterStorageSpacesDirect を使用して、動作が設定されていることを確認できます。
例
まず、記憶域スペース ダイレクトの設定を取得します。
Get-ClusterStorageSpacesDirect
出力例を次に示します。
CacheModeHDD : ReadWrite
CacheModeSSD : WriteOnly
次に、以下を実行します。
Set-ClusterStorageSpacesDirect -CacheModeSSD ReadWrite
Get-ClusterS2D
出力例を次に示します。
CacheModeHDD : ReadWrite
CacheModeSSD : ReadWrite
キャッシュのサイズ変更
キャッシュは、アプリケーションやワークロードのワーキング セット (任意の時点でアクティブに読み取られているデータまたは書き込まれているデータ) を格納できるサイズに設定する必要があります。
これは、ハード ディスク ドライブがあるハイブリッド デプロイで特に重要です。 アクティブなワーキング セットがキャッシュのサイズを超過した場合、またはアクティブなワーキング セットの変動が激しい場合、読み取りではキャッシュ ミスが増加し、書き込みではより積極的なステージング解除が必要となり、全体のパフォーマンスが低下します。
Windows の組み込みのパフォーマンス モニター (PerfMon.exe) ユーティリティを使用して、キャッシュ ミス率を調べることができます。 具体的には、Cluster Storage Hybrid Disk カウンター セットの Cache Miss Reads/sec を、展開の全体の読み取り IOPS と比較します。 各 "ハイブリッド ディスク" は 1 つの容量ドライブに対応します。
たとえば、4 つの容量ドライブにバインドされている 2 つのキャッシュ ドライブは、サーバーあたり 4 つの "ハイブリッド ディスク" オブジェクト インスタンスになります。
普遍的な規則ではありませんが、読み取りのキャッシュ ミスが多すぎる場合は、キャッシュのサイズが不足している可能性があるため、キャッシュ ドライブを追加してキャッシュを拡張することを検討してください。 キャッシュ ドライブまたは容量ドライブは、必要時にいつでも個別に追加できます。
次のステップ
記憶域に関する追加情報については、以下も参照してください。