3行まとめ：VCF 9.1のvSANは既定構成から設計判断へ進む
このテーマをもう少し広げて見るなら、VCF 9.1でvSANネットワークを設計前に確認する：10GbE、VMkernel、MTU/vmkpingの実務ポイント と VCF 9.1 Protection and Recoveryを導入前に確認する：vSAN Snapshots、Clean Room、CrowdStrike連携の実務ポイント も合わせて確認してください。Storage PolicyやStretch Clusterを見直す前提として、vSANトラフィック、MTU、VMkernelの設計確認につなげられます。
- 11. 既定構成
まずは既定のvSAN Storage Policyで足りるVMと、要件を分けて見るVMを切り分けます。
- 22. Storage Policy
可用性、容量効率、性能を一つの評価軸に混ぜず、ワークロードごとに必要条件を確認します。
- 33. Stretch Cluster
高可用性の機能名だけで判断せず、Availability Zone、同数ホスト、Witness、復旧手順を確認します。
- 44. VCF Operations
Health、Capacity、Performanceを変更前から見て、設計変更の影響を追える状態にします。
VCF 9.1のvSANは、新機能名よりも確認順をそろえることで運用設計に落とし込みやすくなります。
VCF 9.1でvSANを使うときは、既定のvSAN Storage Policyをそのまま使う範囲と、業務要件に合わせてポリシーを分ける範囲を先に切り分けます。
Stretch Clusterは「高可用にする機能」とだけ見ると危険です。2つのAvailability Zone、同数ホスト、管理ドメインの順序、Witness、監視まで確認してから設計します。
VCF Operationsでは、Health、Capacity、Performanceを変更前から見ておきます。容量効率やAuto RAID 6のようなVCF 9.1のvSAN新機能も、対象範囲と運用確認を分けて読むことが大切です。
2026年6月12日、VMware Cloud Foundation Blogに「Modernize with Virtualized Storage」が掲載され、同記事はVCF 9.1更新を反映したものとして公開されています。これは「vSANを入れたあと、どこまで設計を見直すべきか」という需要シグナルとして重要です。ただし本記事では、ブログの主張だけでなく、Broadcom News、Broadcom TechDocs、vSphereのStorage Policy Based Management資料を合わせて確認します。
この記事で扱う問いは、vSANの新機能を全部覚えることではありません。既定構成で始めたVCF環境を、いつ、どの順番で、どこまで見直すかです。VCF 9.1全体の移行や自動化を整理したい場合は、公開済みのVCF 9.1でIaCを始める前に確認する実務ポイントも合わせて見ると、SDDC Manager APIや運用手順との接続がしやすくなります。
まず「既定のvSAN」で足りる範囲を切り分ける
一般的な保護で運用を始められ、特別な性能制約や容量効率の要件がまだ明確でないVMです。
復旧目標、業務重要度、容量コスト、I/O傾向が明確で、既定値のままでは説明しにくいVMです。
VMオーナー、運用担当、バックアップ担当、監視担当の認識をそろえてから変更範囲を決めます。
なぜ既定のままにするのか、なぜ専用ポリシーに分けるのかを変更記録として残します。
既定構成は出発点です。要件が見えてきたVMだけを分けると、ポリシーの増えすぎを防ぎやすくなります。
VCFでvSANを使い始めると、ストレージがソフトウェア定義になり、VM単位でポリシーを扱えるようになります。とはいえ、vSANを使っていることと、自社ワークロードに合わせたストレージ設計が終わっていることは同じではありません。
2026年6月12日のVCF Blogは、VCFのvSAN導入を「出発点」として扱い、既定導入だけではプラットフォームが持つ多くの機能や能力を構成するものではない、という趣旨を示しています。ここを読み違えると、既定構成を過小評価するか、反対に既定構成で何でも足りると思い込むかのどちらかに寄りがちです。
VCFのvSAN導入は出発点であり、設計完了ではない
既定のvSAN Storage Policyは、多くの環境で最初に使いやすいバランスを持ちます。2026年6月12日のブログでは、既定ポリシーの例として単一障害への耐性に触れ、1台のホスト障害時にもVMデータの副本がvSAN datastore上に残り、VMware HAが検知した場合にVMを起動できる趣旨が説明されています。
ここで大事なのは、既定ポリシーが悪いという話ではないことです。むしろ、運用開始時の標準ポリシーとしては扱いやすい。ただし、全VMが同じ可用性、同じ容量効率、同じ性能要件を持つわけではありません。業務システム、開発環境、VDI、AI推論基盤、KubernetesのPersistent Volumeでは、失敗時に許容できる範囲が違います。
根拠
Broadcom TechDocsのStorage Policy Based Managementは、SPBMをVMの要求とストレージ能力を対応づけるためのポリシーフレームワークとして説明しています。vSANだけでなく、Virtual VolumesやI/O filterなども含む抽象化の仕組みです。つまり、vSANの設定画面を触る話に閉じず、VM側の要求からストレージを選ぶ考え方として読む必要があります。
注意点
既定構成を見直すときは、保護レベルを上げることだけを目的にしないほうが安全です。保護を強くすれば、容量消費や再同期時の影響も変わります。反対に容量効率だけを追うと、復旧時の余裕や監視の読み方が弱くなることがあります。
既定Storage PolicyでよいVM、分けるべきVM
最初に分けるべきなのは、VMの重要度ではなく、ストレージ要件の違いです。重要度が高いVMでも、更新頻度が低くバックアップで十分なものがあります。反対に、開発用途でも、短時間の停止が検証作業全体を止める場合があります。
確認の入口は、次のように置くと実務で使いやすくなります。
| 見る観点 | 既定ポリシーで始めやすい例 | 専用ポリシーを検討する例 |
|---|---|---|
| 可用性 | 単一障害への耐性で足りる一般VM | サイト障害、複数障害、厳しい復旧目標があるVM |
| 容量効率 | 容量消費が予測しやすいVM | スナップショット、重複排除、圧縮の影響を分けたいVM |
| 性能 | 多少のレイテンシ変動を許容できるVM | IOPSや低遅延の条件を明示したいVM |
| 監視 | 標準アラートで十分なVM | SLA、部署別課金、プロジェクト別容量管理が必要なVM |
| 変更管理 | 定期メンテナンスで変更できるVM | 変更時間帯、戻し手順、承認が厳しいVM |
確認項目
VMの業務重要度、RTO/RPO、単一障害で足りるか、容量効率の優先度、性能制限やIOPS制御の必要性、バックアップやレプリケーション設計との関係を並べます。ここで「重要だから全部強くする」と決めると、容量と運用が読みにくくなります。
評価基準
まずは、VMを3つから5つ程度の役割に分けるくらいが扱いやすいです。たとえば「標準」「高可用」「容量効率優先」「性能確認必須」「例外管理」のように、運用チームが名前で意味を思い出せる単位にします。これは上限値ではありません。ポリシー名を見ただけで、誰が何を守りたいのか分かる状態を目標にします。
Storage Policyは可用性、容量効率、性能を同じ表で見ない
可用性、容量効率、性能は互いに影響します。単純な優劣ではなく、ワークロード単位の条件差として扱います。
VCF 9.1のvSANを読むとき、Auto RAID 6、圧縮強化、グローバル重複排除、Cyber Recovery向けvSAN storage cluster、RWX file volume supportなど、複数の新機能が目に入ります。どれも重要ですが、導入判断の記事で全部を同じ重さで扱うと、読者は「結局どこから見ればよいのか」を失います。
Storage Policyの見直しでは、可用性、容量効率、性能を同じ表に詰め込みすぎないほうが読みやすいです。それぞれ判断の単位が違うからです。
SPBMでVM要求とストレージ能力を対応づける
SPBMは、VMが必要とするストレージ特性と、ストレージ側が提供できる能力を対応づける仕組みです。vSANを使う場合は、障害許容、RAID、容量効率、性能関連の条件を、VM Storage Policyとして扱います。
この考え方を置くと、vSANの設計は「クラスタ全体で一つの正解を決める作業」ではなくなります。VMやアプリケーションの単位で、どの保護、どの容量効率、どの性能条件を必要とするかを分けていく作業になります。
根拠
Broadcom TechDocsのSPBM説明は、SPBMを単一の統合コントロールプレーンとして説明し、vSAN、Virtual Volumes、I/O filtersなどが提供するデータサービスを抽象化するとしています。このため、記事ではSPBMをvSAN専用の小技ではなく、VM要求をストレージ能力へ翻訳する入口として扱います。
注意点
SPBMを使うと、ポリシーを増やしたくなります。ただし、ポリシーが増えるほど、容量内訳、適用漏れ、例外、変更履歴を追う負荷も増えます。Storage Policyを設計する段階で、VCF OperationsやvSphere側でどう監視するかも決めておく必要があります。
FTT、RAID、容量効率の変更はワークロード単位で考える
Broadcom TechDocsのvSAN 9.1 New Featuresでは、vSAN ESA Auto RAID 6、圧縮の改善、vSAN ESA Global Deduplicationなどが説明されています。Auto RAID 6は、手動選択を減らし、データ保護を強める方向の機能として示されています。グローバル重複排除は、クラスタワイドかつポストプロセスの設定として説明され、暗号化との関係にも触れています。
ただし、ここから「VCF 9.1なら容量効率が必ず大きく改善する」と短絡しないほうがよいです。データの重複率、ワークロードの書き込み特性、暗号化、スナップショット、バックアップ、再同期、監視項目によって、見え方は変わります。
条件
Auto RAID 6や重複排除、圧縮強化を記事で扱うときは、対象がvSAN ESAなのか、既存クラスタでどう確認するのか、どのリリースノートに記載があるのかを分けます。既存のOSA構成、vSAN storage cluster、vSAN compute clusterを同じ条件で語らないようにします。
上振れと下振れ
容量効率機能は、うまくはまれば調達コストや容量逼迫を和らげます。一方で、削減率を一般化すると危険です。読者が見るべきなのは、削減率の数字ではなく、変更前後の容量、再同期、レイテンシ、アラートを同じ期間で比較できるかです。
ポリシーを増やしすぎると運用が読みにくくなる
Storage Policyを増やすこと自体は悪くありません。問題は、増やした理由が残っていないことです。名前だけが似たポリシーが並び、どれが本番向けで、どれが検証向けで、どれが例外用なのか分からなくなると、障害時の判断が遅れます。
| ポリシー設計で残す項目 | 理由 |
|---|---|
| ポリシー名 | 運用者が用途を思い出せる名前にする |
| 対象VMまたはVMグループ | 適用漏れと誤適用を防ぐ |
| 変更理由 | 可用性、容量効率、性能、監査のどれを狙ったか残す |
| 容量影響 | 保護レベル変更後の消費を追えるようにする |
| 監視項目 | Health、Capacity、Performanceのどこを見るか決める |
| 戻し方 | 変更失敗時に元へ戻す条件を決める |
確認項目
ポリシー名、対象VM、変更履歴、容量内訳、アラート、適用漏れ、コンプライアンス状態を確認します。ポリシー別の容量内訳を見られるなら、変更前後の比較を残します。
評価基準
ポリシーの数を減らすことだけを目標にしません。運用者が説明できないポリシーを減らすことを目標にします。説明できるポリシーなら、複数あっても管理できます。説明できないポリシーは、少数でも障害時に迷いを生みます。
Stretch Clusterは「強い可用性」より先に前提条件を確認する
- 11. 守る障害を決める
ホスト障害、クラスタ内障害、Availability Zone障害のどれに備えるのかを先に明確にします。
- 22. サイト条件を確認する
2つのAvailability Zone、同数ホスト、ネットワーク、遅延、帯域の前提を確認します。
- 33. 管理ドメインを確認する
管理ドメインとワークロードドメインの順序、Witnessの配置、運用責任を整理します。
- 44. ポリシーと監視を合わせる
Stretch化に合わせてStorage Policy、アラート、復旧確認、切り戻し手順を同時に見直します。
Stretch Clusterは可用性を強める選択肢ですが、前提条件がそろわない場合は別の冗長化設計を検討します。
vSAN Stretch Clusterは、可用性を高める選択肢として魅力があります。2026年6月12日のVCF Blogでも、vSAN Stretched Clustersは追加の可用性レベルを提供し、複数のAvailability Zoneを環境に取り込むことで障害範囲を小さくし、アプリケーション可用性を高める助けになると説明されています。
ただし、Stretch Clusterは「入れれば安心」という機能ではありません。守りたい障害、サイト間の前提、管理ドメイン、Witness、監視、復旧手順がそろって初めて意味を持ちます。
Stretch Clusterで守りたい障害を明確にする
Broadcom TechDocsの「Stretching vSAN Clusters in VMware Cloud Foundation」は、ワークロードドメインのvSANクラスタをリージョン内の2つのAvailability Zoneにまたがって伸長できると説明しています。また、いずれかのAvailability Zoneがダウンした場合のフェイルオーバーを考えるため、両Availability Zoneには同数のホストが必要だと説明しています。
この前提は、記事本文で必ず残したいポイントです。サイトをまたぐという言葉だけを見て、片方に少しだけホストを足す設計と混同すると、フェイルオーバー時の見積もりが崩れます。
根拠
TechDocsでは、vSAN ESA/OSA、vSAN compute、vSAN storageのStretchに触れ、SDDC Manager APIを使った既存クラスタの伸長や新規vSAN compute stretch cluster作成の説明があります。つまり、Stretch Clusterは設計概念だけでなく、VCFの管理面とAPI操作を伴う作業です。
条件
両Availability Zoneで同数ホストを確保できるか、Witnessをどこに置くか、サイト間ネットワークが要件を満たすか、障害時にどちらのサイトを優先するかを先に決めます。単一ラック障害を想定するのか、サイト障害を想定するのかでも、設計は変わります。
管理ドメインとワークロードドメインの順序を確認する
Stretch Clusterを検討するときに見落としやすいのが、管理ドメインの順序です。TechDocsでは、ワークロードドメインのクラスタをStretchする前に、デフォルト管理ドメインのvSphereクラスタをStretchする必要があるという趣旨が示されています。これは、管理面とワークロード面を分けずに考えると、後半で効いてくる条件です。
VCF 9.1で運用全体を見直す場合、VCF 9.1でNVMe Memory Tieringを有効化する前に確認する実務ポイントのようなホスト単位の変更も同時に出てきます。Stretch Clusterの検討とホスト更新を同じメンテナンス枠に詰め込むと、障害時の切り分けが難しくなります。
注意点
管理ドメインを先に見るという話は、単なる手順順序ではありません。VCF Operations、SDDC Manager、NSX、vCenter、Witness、ネットワーク監視が、障害時にどこで動くかを確認する話です。ここを飛ばしてワークロードだけをStretch化すると、障害時に管理画面や自動化の前提が崩れる可能性があります。
確認項目
対象クラスタ種別、SDDC Manager APIの利用、Witnessの配置、サイト間ネットワーク、障害時の運用手順、復旧後の再同期、Stretch解除や拡張の手順を確認します。APIでの操作を扱うなら、誰が実行し、どの変更記録を残すかも決めます。
Stretch化はStorage Policyと監視を同時に見直す
Stretch Clusterを入れても、VMごとのポリシー、HA/DRS、バックアップ、レプリケーション、容量監視が整理されていなければ、可用性の説明が曖昧になります。特にStorage Policyは、Stretch後のVM配置や保護の考え方と結びつきます。
評価基準
Stretch Clusterの評価は、構成図がきれいかどうかではなく、障害時の判断表があるかで見ます。どのVMをどちらのAvailability Zoneで守るのか、どのVMは標準ポリシーのままにするのか、どのアラートが出たらどの担当者が動くのか。そこまで残っていれば、Stretch Clusterは運用に乗せやすくなります。
VCF Operationsではヘルス、容量、性能を変更前から見ておく
監視は変更の後始末ではなく、Storage PolicyやStretch Clusterを安全に評価するための前提です。
vSANの設計変更は、変更後に監視を始めると遅いです。Storage Policyを変える前、Stretch Clusterを検討する前、容量効率機能を評価する前に、VCF OperationsとvSphere側で現在の状態を見ておく必要があります。
2026年6月12日のVCF Blogは、vSANのHealth、Capacity、Performanceを確認する流れに触れ、VCF Operationsのダッシュボードが管理能力を高めると説明しています。VCF Operationsは、旧Aria Operationsの文脈を引き継ぐ運用面の入口として読むと分かりやすいです。
vSAN Healthで設定変更前の正常性を確認する
Storage PolicyやStretch Clusterの前に、まずvSAN Healthで警告や既知の問題を確認します。異常を抱えたまま保護レベルやトポロジを変えると、変更作業そのものが問題なのか、元からあった問題が表面化したのか分からなくなります。
根拠
2026年6月12日のブログでは、vSANクラスタを選ぶことでHealthとCapacityの概要を確認でき、vSAN Healthに進むとテスト内容と状態を詳細に見られると説明されています。CapacityではStorage Policyごとの容量使用を確認できる趣旨も示されています。
確認項目
クラスタヘルス、ディスクグループまたはデバイス状態、ネットワーク、オブジェクト状態、再同期、警告、既知のアラートを確認します。障害対応中のクラスタで設計変更を始めないための入口です。
Capacityはポリシー別の内訳で見る
容量を見るときは、全体の空き容量だけでは足りません。Storage Policyごとにどの程度消費しているか、保護レベル変更でどれだけ増減するか、スナップショットや重複排除、圧縮の評価がどこに出るかを分けます。
この観点は、FinOpsやコスト可視化ともつながります。VCF Operationsで容量やコストをどう読むかを深めるなら、公開済みのVCF Operationsでオンプレ本番運用を見直す実務ポイントも参考になります。
注意点
容量効率の評価は、1回の画面確認では終わりません。業務ピーク、バックアップ、スナップショット、再同期、メンテナンス後の挙動を見る必要があります。導入直後の数字だけを根拠に、次のクラスタへ横展開しないほうが安全です。
評価基準
変更前後で比較できる形にします。画面キャプチャ、CSV、監視ダッシュボード、月次レビューのいずれでも構いません。大切なのは、同じ指標を同じ粒度で見続けることです。
Performanceは「遅いかどうか」ではなく変更影響を見る
Performanceは、体感が遅いかどうかだけで判断しません。Storage Policy変更、Stretch化、重複排除、圧縮、再同期が、どの時間帯に、どのVMグループへ影響したかを確認します。
確認項目
レイテンシ、IOPS、スループット、輻輳、再同期時の影響、ピーク時間帯、ポリシー変更前後の差分を見ます。アプリケーション側のログや監視とも照合できると、ストレージだけに責任を寄せすぎずに済みます。
下振れ
vSAN ESAの新機能や容量効率機能は、環境により見え方が変わります。性能への影響が小さい環境もあれば、ワークロード特性により慎重な検証が必要な環境もあります。記事では性能値を断定せず、ベースラインを取ることを実務ポイントにします。
導入前チェックリストで設計判断を止める
VMごとの要件、変更対象、影響範囲、例外VM、命名ルールを確認します。
Availability Zone、同数ホスト、Witness、ネットワーク、復旧手順、責任分界を確認します。
Health、Capacity、Performance、アラート、変更前の基準値を確認します。
変更後の確認方法、問題が出た場合の戻し方、関係者への連絡順を確認します。
チェックリストは作業を止めるためではなく、変更の目的と戻し方を同時に説明できる状態にするためのものです。
vSANの見直しは、勢いで進めると範囲が広がります。Storage Policyを触り、Stretch Clusterを検討し、VCF Operationsのダッシュボードを作り、容量効率機能も見たくなる。だからこそ、導入前チェックリストで一度止めて、変更の目的と戻し方を同じ紙面に残します。
ここでは、設計会議や変更審査に持ち込む前に残しておきたい項目を整理します。
Storage Policyを変える前のチェック
| 確認項目 | 見る理由 |
|---|---|
| 対象VM | 変更対象と例外VMを分ける |
| 現在のポリシー | 既定ポリシーからの差分を把握する |
| 業務要件 | 可用性、容量効率、性能の優先順位を決める |
| 容量影響 | 保護レベル変更後の消費を見積もる |
| 変更タイミング | 再同期やピーク時間帯を避ける |
| 戻し方 | 変更失敗時の判断を早くする |
| 監視項目 | Health、Capacity、Performanceのどこを見るか決める |
確認項目
Storage Policyを変える前に、VMオーナー、運用担当、バックアップ担当、監視担当の認識を合わせます。ポリシー変更はストレージ担当だけの作業に見えますが、影響はアプリケーション側へ出ることがあります。
Stretch Clusterを検討する前のチェック
| 確認項目 | 見る理由 |
|---|---|
| Availability Zoneの対称性 | 同数ホストの前提を確認する |
| 管理ドメイン | 先にStretchすべき管理面を確認する |
| Witness | 配置、接続、障害時の見え方を確認する |
| サイト間ネットワーク | 遅延、帯域、分断時の挙動を見る |
| SDDC Manager API | 操作方法、権限、記録を決める |
| 拡張と解除 | 将来のホスト追加やUnstretchを見込む |
| 復旧手順 | 障害後の再同期と確認を決める |
確認項目
Stretch Clusterは、DRの代わりではありません。バックアップ、レプリケーション、サイバーリカバリ、手動復旧手順と役割を分けます。VCF 9.1のvSAN関連新機能にはCyber Recovery向けのvSAN storage clusterも含まれるため、可用性と復旧性を混ぜずに読むことが必要です。
VCF Operationsで見るべきチェック
| 確認項目 | 変更前に残すもの |
|---|---|
| Health | 既存アラートと正常性 |
| Capacity | 全体容量とポリシー別消費 |
| Performance | レイテンシ、IOPS、スループット |
| アラート | 担当者、通知先、優先度 |
| ベースライン | 変更前の観測期間とピーク時間帯 |
| 変更後観測 | 何日または何サイクル見るか |
| 判断会議 | 横展開する条件と止める条件 |
確認項目
監視は「見れば分かる」ではなく、「どの数字なら進めるか、どの数字なら止めるか」を決めて初めて使えます。VCF Operationsで見える値を、設計判断の言葉に直すところまでが準備です。
まとめ：vSANを使うかではなく、どう運用に乗せるかを決める
- Step 1
既定のStorage Policyで足りるVMと、専用ポリシーを検討するVMを分けます。
- Step 2
SPBMでVM要求とストレージ能力を対応づけ、可用性、容量効率、性能を別々に確認します。
- Step 3
Stretch Clusterは、Availability Zone、同数ホスト、管理ドメイン、Witnessを確認してから検討します。
- Step 4
VCF OperationsでHealth、Capacity、Performanceを変更前から見て、継続的に説明できる状態にします。
この順番で確認すると、vSANを単なるストレージ機能ではなくVCF 9.1の運用設計として扱いやすくなります。
VCF 9.1のvSANは、Private Cloud基盤の中でかなり重要な位置を占めます。BroadcomのVCF 9.1公式発表も、AIとKubernetes nativeなPrivate Cloud、統合されたセキュリティ、AMD/Intel/NVIDIAを含む混在コンピュートのサポートを前面に出しています。そこにvSANの容量効率、可用性、運用監視が重なります。
ただ、導入判断では新機能名よりも順番が大切です。まず既定のStorage Policyで足りる範囲を分ける。次に、SPBMでVM要求とストレージ能力を対応づける。Stretch Clusterは、Availability Zone、同数ホスト、管理ドメイン、Witness、復旧手順を確認してから検討する。最後に、VCF OperationsでHealth、Capacity、Performanceを変更前から見ておく。
この順番であれば、vSANを単なるストレージ機能ではなく、VCF 9.1の運用設計として扱いやすくなります。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「Modernize with Virtualized Storage」
https://blogs.vmware.com/cloud-foundation/2026/06/12/modernize-with-virtualized-storage/
- VMware Cloud Foundation Blog「Optimize, Modernize and Protect Your Private Cloud Storage with vSAN in VCF 9.1」
https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing_vsan_in_vcf_9-1/
- Broadcom News「Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI」
https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1
- Broadcom TechDocs「vSAN 9.1 New Features」
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes/what-s-new/whats-new-vsan.html
- Broadcom TechDocs「Stretching vSAN Clusters in VMware Cloud Foundation」
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/building-your-private-cloud-infrastructure/stretching-clusters.html
- Broadcom TechDocs「Storage Policy Based Management in vSphere」
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/storage-policy-based-management-in-vsphere.html