VCF9.1 の新機能を眺めていて気付いたことは、派手な新規追加よりも「これまで諦めていた構成が使えるようになった」項目の多さです。
VCF9.1 の新機能から、個人的に注目している3つ — メモリ階層化の改善、ZTP、vSAN 関連 について、まとめました。
Memory Tiering 機能向上
ソフトウェアミラーリング
VCF 9.0 ではNVMe階層の冗長化にハードウェアRAID(Tri-ModeコントローラかIntel VROC)が必須でしたが、9.1ではvSphereネイティブのソフトウェアミラーリングを導入し、RAIDコントローラが不要になりました。
設定の簡素化
VCF 9.0 は別々の手順だったNVMeパーティション作成と機能有効化が、9.1ではvSphere Configuration Profilesの単一画面に統合され、パーティションは自動作成、ホスト再起動も不要(メンテナンスモードのみ)となりました。
Memory Tiering 有効ホストでの VM 電源投入制約の解消
VCF 9.0 では、メモリ階層化を有効化したホスト上で一部の VM プロファイルが電源投入できないという制約がありました。9.1 ではこの制約が解消され、セキュリティ VM、低レイテンシ VM、Fault Tolerance VM を含むすべての VM が電源投入可能になっています。ただし、これらのうち一部は階層化の対象にはならず、DRAM のみで動作します。電源投入自体が可能になったことで、対象 VM 専用のホストを切り分けて運用する必要がなくなりました。
【9.0 → 9.1 の差分】メモリ階層化ホストでの VM 電源投入制約
9.0：セキュリティ VM／低レイテンシ VM／FT VM などが電源投入不可。専用ホストの分離が必要だった
9.1：制約撤廃。すべて電源投入可能
注意：電源投入可 ≠ 階層化対象。一部の VM は引き続き階層化に参加しない
効果：これらの VM のためだけにホストを分ける必要がなくなった
Zero Touch Provisioning
VCF 9.1のZero Touch Provisioning(ZTP)は、ネットワーク経由でベアメタルのESXホストを自動的に起動・インストール・クラスタ登録まで完結させる、Auto Deployの後継となるプロビジョニング機能です。製品上は「vSphere Elastic Provisioning(エラスティックプロビジョニング)」とも呼ばれます。サーバ電源投入から、ベアメタルのブート、ESXインストール、クラスタ登録までをネットワーク越しに自動化し、エッジ拠点でのローカル作業を不要にすることが可能です。
ZTPは 既存のvSphere Auto Deployの基盤の上に構築されており、より新しいブートプロトコル技術であるUEFI HTTP/S Bootを使い、Secure BootやTPMといった最新サーバ構成をサポートします。従来のAuto Deployとの最大の違いはブートの仕組みです。
- ZTPは外部のTFTPサーバを必要としない。UEFIブートURLをvCenterに向くよう構成し、ネットワーク越しにホストを起動する
- iPXEブートローダーとTFTPサーバの代わりに、BRS(Boot Resource Service)がブートファイルを提供、またはAuto Deployルールで定義されたブートイメージURLを使う
- UEFIに静的IPを設定できない場合のみDHCPサーバが必要(=構成によってはDHCPすら不要)
つまり、従来の「PXE + TFTP + DHCP」という旧来のネットワークブート一式から脱却し、「UEFI HTTPS Boot + BRS」というセキュアな方式に置き換えたのがZTPです。ZTPは下層ハードウェアにHTTPSブートサポートが存在することが前提になる点には注意が必要です。
| 比較項目 | Auto Deploy（レガシー方式） | ZTP / vSphere Elastic Provisioning |
|---|---|---|
| ステータス | vSphere 9.x（VCF 9.0）で非推奨、将来のメジャーリリースで削除予定Deprecated | VCF 9.1 / VVF 9.1 で導入された後継機能 |
| ブート方式 | PXE / iPXE によるネットワークブート | UEFI HTTPS Boot（BRS が提供する単一ブート URL） |
| 使用ポート | 6501（iPXE ブート） |
443（一般的な HTTPS ポート） |
| 外部サービス依存 | 外部 TFTP サーバが必要、DHCP も必要 | TFTP 不要。UEFI 側に静的 IP を設定できれば DHCP も不要 |
| 内部コンポーネント | Auto Deploy サービス + Image Builder | BRS（Boot Routing Service：単一ブート URL）＋ NBS（Network Boot Service：イメージ/構成の配信） |
| セキュリティ | 従来型ファームウェア構成が前提 | Secure Boot / TPM といった最新のサーバ構成をサポート |
| 構成の適用方法 | Host Profiles | vSphere Configuration Profiles（VCP）または vLCM desired image |
| イメージ/構成の決定 | Deploy Rule（イメージプロファイル / ホストプロファイルを直接指定） | Deploy Rule で選択したクラスタロケーションにより決定。VCP 未完成のクラスタへはデフォルト構成で参加も可能 |
| VCP 連携 | — | VDS ブートストラップ、ホスト固有属性の自動抽出。自動リメディエーションは既定で無効 |
| 対応 ESX バージョン | 従来からの各バージョン | ESXi 8.0 Update 3 以降のホストをプロビジョニング可能 |
| 移行ルール | ローカルディスクなし（ディスクレス）なら継続利用可 | ローカルディスクありのホストは ZTP へ移行必須必須 |
vSAN関連
Auto-RAID
従来、ストレージポリシーは VM ごとに保護レベルやデータ配置を細かく指定できる反面、「結局どのポリシーが最適なのか」という悩みを利用者に残していました。vSAN 8 U1 の Auto-Policy Management はクラスタ特性に応じた既定ポリシーを自動生成するものでしたが、あくまで従来型ポリシーの上に乗った推奨エンジンにすぎませんでした。
9.1 では vCenter Server 上に「vSAN ESA Auto RAID Policy」という単一のポリシーが置かれ、クラスタのサイズや種別を問わず全 9.1 クラスタを制御します。このポリシー自体は保護レベルの明示的な設定を持たず、クラスタ種別やホスト数といった特性を検知して最適値を適用します。クラスタ種別ごとに何十・何百とポリシーを作る必要がなくなります。
ホストの追加・削除といった構成変更にも自動追従します。単一ホストからクラスタを立ち上げる場面でも、従来必要だった Force provisioning なしで VM を作成でき、ホストを足していけば自動的に適切なイレージャコーディングへ移行します。
リモートデータストア
OSAからESAへのアクセス
従来のvSAN OSA（Original Storage Architecture）クラスターが、最新のvSAN ESA（Express Storage Architecture）のデータストアをリモートマウントできるようになりました。
リモートデータストア（HCI Mesh）は、コンピュートを提供する側（クライアントクラスター）が、ストレージを提供する側（サーバークラスター）の vSAN データストアをネットワーク越しにマウントする仕組みです。今回、クライアント側が OSA のままでも、サーバー側の ESA データストアをマウントできるようになりました。OSA クラスターを ESA へ移行せずに ESA 側の容量を利用できる、という移行期に効く緩和です。
リモートデータストア構成における転送中データ暗号化（DiT）のサポート
リモートデータストア（ストレージクラスタ）間の「転送中データの暗号化（Data-in-Transit encryption）」がサポートされました。
これまでのバージョン（VCF 9.0など）では、リモートデータストア構成において、サーバークラスター側で書き込む際の Data-at-Rest（保存データ暗号化）はサポートされていましたが、クライアント⇔サーバー間を流れる Data-in-Transit（転送中データ暗号化）は、リモートデータストア構成では対象外という制限がありました。つまり「ディスク上は暗号化されるが、クラスター間の vSAN ネットワークを流れるデータは平文」という状態です。今回これがサポートされたことで、保存時・転送時の両方が保護され、コンプライアンス要件（暗号化必須の環境）でも HCI Mesh 構成がとれるようになります。
HCI Meshの歴史
HCI Meshの歴史をバージョンごとに、時系列で整理しました。
