ad1

2022年10月6日木曜日

vSphere 8.0・vSAN 8.0 機能強化・アップデート情報

発表からだいぶ時間が経ってしまいましたが、8月末に開催された VMware Explore で最新の vSphere バージョンである vSphere 8.0、vSAN 8.0が発表、さらには従来の vRealize 製品群が VMware Aria とブランドが変更される事も発表されました。

※ 毎年晩夏に開催されていた VMware の年次イベント VMWorld が 今年から VMware Explore となりました。

覚え書きを兼ねて公式情報へのリンクと個人的に気になる部分を整理しておきます。

公式のアナウンスはこちら

vSAN 8 関連

Aria・VCF 関連

その他、公式 Blog や Tech Zone に多く記事が上がっているので上記リンクからたどってみて下さい。

今回も個人的に興味を持っている vSphere・vSAN の機能強化についてまとめました。

それぞれのページ内リンクはこちらから

vSphere のバージョンライフサイクルについて

vSphere は過去メジャーバージョンとマイナーバージョンが分かり難かった時期が長かったので、もう 8.0 !? と思う人も多いかと思います。
ESX 3.0、3.5、vSphere 4.0、4.1、5.0、5.1、5.5、6.0、6.5 と刻んできましたが、
2018 年にリリースされた vSphere 6.7 を境に、約 2 年毎にメジャーバージョンをリリースし、メジャーバージョンリリース後は半年毎に Update を Update 3 までリリースというサイクルとなっている事がリリース日を並べると分かります。


それぞれのメジャーバージョンは Enterprise Infrastructure Support として 5 年間のパッチ提供を含む General Support 期間、その後 2 年間の Technical Guidance 期間を提供しています。
徐々に階段を上がるように、少なくとも1段飛ばし2段飛ばしくらいで階段を登れば関連プロダクトの互換性を維持しながら継続的なメンテナンスができるはずです。


各バージョンの正式なライフライクル期間は以下の Lifecycle Matrix サイトで確認可能です。

これらのサイクルは今後のバージョンアップ計画などにも役立つと思いますので覚えておい損はないはずです。

また、バージョンアップ計画に関連して vSphere 8.0 に関する重要な KB が集約された Master KB が公開されています。
今後のバージョンアップ準備の際には確認必須の KB なので必ずチェックしてください。

vSphere のライセンス体系について

従来 vSphere・vSAN などの仮想化ソフトウェアのライセンスは CPU ソケット単位 (32コアを上限)の Perpetual ライセンス (パーペチュアル : 永続) でした。

今後は2022年7月から提供開始された vSphere+ / vSAN+ のインターネット上の Cloud Portal <https://vmc.vmware.com/> でライセンス管理を行う Subscription ライセンス (1/3/5年の期間ライセンス)、
2022年10月から提供開始された Term ライセンス (1/3/5年の期間ライセンス)に徐々に切り替わっていくものと思われます。

Perpetual と Subscription・Term の大きな違いとして、Perpetual は SnS (Support & Subscription) を別途購入してサポート契約していましたが、Subscription・Term は SnS 込のライセンスとなります。

また、Subscription と Term はそれぞれ CPU コア単位のライセンスとなり、1 CPU あたり最小 16コア分のライセンスが必要となるので注意が必要です。

詳細は複雑な部分もあるので別途まとめたいと思います。

vSphere 8.0 で気になる機能強化

詳細は Core Tech Zone Blog : What's New in vSphere 8 ? 参照

vSphere Distributed Services Engine

vSphere 8.0 では vSphere Distributed Services Engine (旧 Project Monterey) が実装され Smart NIC などのデータ処理ユニット (Data Processing Units :DPU) を取り込み、ESXi の追加インスタンスが DPU にインストールされることで本体の ESXi の CPU 負荷を DPU にオフロードしたワークロード処理が可能になります。

vSAN ESA も NVMe SSD、RDMA 側に処理をオフロードして ESXi の CPU リソースを利用せずに高い性能を発揮できるように進化しているので今後もこうした分散処理の仕組みは強力に取り込まれていくのだろうと思われます。

vSphere 8.0 ではまずは vDS 8.0 と NSX の組み合わせではネットワークワークロードを DPU にオフロードする事で処理性能が向上し、トラフィックの可視性向上、セキュリティ、ネットワークの分離と保護が可能になるとのこと。


Cormac さんの Blog などもわかりやすいのでオススメ。

vSphere with Tanzu : Tanzu Kubernetes Grid 2.0

Tanzu 周りのアップデートは普段あまり触れてないので公式情報に任せます...

Lifecycle Management : ライフサイクル管理

vSphere 7.0 から実装された vSphere Lifecycle Manager (vLCM) Image 管理 が何点か強化されています。

強化されているポイントとしてはアップデート適用前の事前ステージングの実施(非メンテナンスモード状態でのステージングを行い、ESXi ホストのメンテナンスウィンドウの短縮化)、
複数のメンテナンスモード下の ESXi ホストへの並列パッチ適用などがあるようです。

vLCM Baseline の Deprecated (非推奨化)

しかし、元々の機能であった vSphere Update Manager の機能を引き継いだ vLCM Baseline 管理は vSphere 8 が最後のサポートバージョンとなるようです。

今後は vLCM Image で管理していくことが推奨されるようですが、ESXi ホストの BIOS/UEFI/Firmware 管理も行う場合にはクラスタ内のサーバーモデルを統一する必要があります。
混在環境で運用する場合は ESXi Bundle と Driver の管理で運用する必要があります。


※ 2022年9月現時点では vLCM Image は vSphere Replication などはサポートされないため、vSAN + SRM との組み合わせで vSphere Replication を使う予定がある場合は vLCM Baseline で導入する必要があります。
一度 vLCM Image を設定してしまうと vLCM Baseline に戻すことはできず、クラスタの再作成が必要となるので要注意です。

vCenter のバックアップ・リストア機能の改善

vSphere 8.0 ではクラスタの状態を vCenter だけでなく ESXi ホスト内の分散 Key-Value ストアに格納しておくことで vCenter Server Appliance のリストア時に vCenter とクラスタの状態を一致させデータ・構成のロスのないリストアが可能になるとのこと。

リストア時に前回バックアップ時点以降に変更が発生した箇所が消えてしまったり、削除した情報や VM がゴーストとして復活してしまうなど過去にありましたがそうした点も本機能で改善されそうです。

vSphere Configuration Profiles 

また、Technical Preview 機能として vSphere Configuration Profiles が実装されました。
機能としては vSphere+ で Cloud Portal で管理される vCenter の Desired State Profile に似ており、クラスタ単位で ESXi の構成情報を管理・監視し、設定のズレなどを追跡して修正することが可能になります。


従来のホストプロファイルの進化版のようですが、使い勝手は良さそうです。
ただし、まだ vDS 環境はサポートされないようで vSS 構成のみなのですぐに使いものになるかというとそうではないようです。

AI & ML

GPU などのハードウェアサポートも大幅に強化され、vGPU は vSphere 7.x の 4 vGPU から vSphere 8.0 では 8 vGPU へ 2 倍の拡張、パススルーデバイスは vSpehre 7.x の最大 8 から vSphere 8.0 では 32 へと大幅に拡張されました。

vSphere Distributed Services Engine の DPU サポートと同じく従来以上に ESXi の CPU 負荷をオフロードしてより高い性能を VM に提供できるようになります。

vSphere 8.0 では ESXi ホスト内の同一 PCIe スイッチ配下の GPU や NIC をデバイスグループとしてハードウェアアクセラレータの統合管理が可能になるようです。

Device Virtualization Extensions (DVX)

次世代仮想ハードウェアデバイス : Device Virtualization Extensions (DVX) が登場し DRS、HA、Snapshot (メモリ・ディスク)、VM Suspend など従来の DirectPath IO を利用した VM では利用できなかった機能が DVX では可能となります。


vMotion の強化

vMotion の強化についても Core Tech Zone にいくつか記事が公開されました。

vMotion Notification (vMotion 通知) 

vSphere 7.0 の時の vMotion の強化は大容量メモリを搭載して高負荷なモンスター VM の以降を短時間で実施するような強化でしたが、
vSphere 8.0 ではより遅延センシティブなアプリケーションを動作させる VM 向けに vMotion 実行の最終段階でのメモリ転送・RARP によるネットワーク経路切替の瞬停 (Stun) を今まで以上に極小化する強化が入りました。

これは vMotion Notification (vMotion 通知) という新しい機能で実装され、VMware Tools を介して極低遅延性が求められる VM 向けの追加の詳細設定が可能となります。
※ アプリケーションは、VMware Tools vmtoolsd コマンド ライン ユーティリティを使用して通知を登録する必要があります

vMotion 通知を有効にする場合は対象 VM 毎に詳細設定 vmOpNotificationToAppEnabled を True で追加します。

vMotion 通知が有効になった VM は DRS の対象から除外されますが、vLCM でメンテナスする際など ESXi がメンテナンスモードになる際には vMotion で他の ESXi に vMotion されます。

vMotion 実行までの猶予時間は詳細設定 vmOpNotificationToApp.Timeout に秒単位で設定する必要があります。デフォルトは 0 です。

vMotion 通知を利用するためには仮想ハードウェアバージョンは 20 以上、VMware Tools は 11 以降がインストールされている必要があります。

vSphere vMotion Unified Data Transport

vMotion のもう一つの改善として、パワーオフ VM の移行時に従来は vMotion ネットワークではなく NFC (Network File Copy) プロトコルを設定した VMkernel NW でデータ移行が行われ、これが非常に遅いという問題がありました。

vSphere 8.0 ではパワーオフ VM の転送に Unified Data Transport (UDT) プロトコルを新たに利用するようになりました。

従来の NFC と vMotion の性能の違い

  • NFC (Network File Copy)
    • シングルスレッドプロセス
    • 同期入出力
    • ピーク性能 1.3 Gbps
  • vSphere vMotion
    • 高度に最適化されたマルチスレッド プロセス
    • 非同期入出力
    • ピーク性能 80Gbps

UDT は NFC と vMotion の良いところをあわせたプロトコルで、NFC を制御チャネルとして使用し、データ転送を vSphere vMotion プロトコルにオフロードして、パフォーマンスとスループットを大幅に向上させます。

UDT の有効化は vSphere 8.0 以降で vmk の設定で "Provisioning" を有効にするだけです。


※ vMotion 専用の TCP/IP スタックを使用する場合、同じ vmk でプロビジョニング サービスをアクティブ化することはできず、別の vmk を使用する必要があります。

Intel Scalable I/O Virtualization (Intel SIOV) の vMotion 対応

vSphere 8.0 では Intel SIOV を実行する ESXi ホストと VM の vMotion がサポートされる様になりました。※ SR-IOV と SIOV、名前と機能が似ているので紛らわしいのですが、SR-IOV ではないのでご注意。

ストレージの強化

vSAN 8.0 以外にもストレージに関連する強化、特に NVMe over Fabrics (NVMe-oF) に関して発表されています。

NVMe-oF の強化では 256 の NameSpace のサポートと 2K のパスのサポート、MVNe over FC での Clustered VMDK の WSFC サポート、また VVOL 3.0 / VASA 4.0 とそれによる VVOL の NVMe-oF 対応などが発表されています。

また、SPBM で VMFS6 をクラウドネイティブストレージ向けに提供する機能が発表されています。 
詳細は上記の Core Tech Zone Blog を参照してください。

ゲスト OS とワークロードの強化

仮想ハードウェア バージョン 20

仮想ハードウェア バージョン 20 では上記の vGPU 4、パススルーデバイス 32、DVX のサポートなど最新の機能を利用できるようになります。

まだ vSphere 8.0 が GA されていないため公式ドキュメントや KB の情報は HW Ver.20 については追記されていませんが以下のサイトなどで機能の上限、互換性が確認できるようになります。

Windows 11 の大規模展開サポート

Windows 11 では vTPM を構成する必要があり、そのままクローンで展開するとTPM シークレットが複製されるため、セキュリティ リスクが発生する可能性がありました。
vSphere 8.0 では vTPM デバイスは、クローンまたは展開操作中に自動的に置き換えられるほか、vTPM のデフォルトのクローン動作を設定する vpxd.clone.tpmProvisionPolicy 詳細設定が追加されます。

また、vSphere の強化では有りませんが、Windows 11 バージョン 2H22 から PVSCSI ドライバと VMXNET3 ドライバが Windows 側に Inbox で含まれるようになり、Windows Update を経由した更新も受け取れるようになります。

これにより Windows 11 で推奨される PVSCSI と VMXNET3 の仮想デバイスを持った状態の新規インストールにおいても追加ドライバの適用や VMware Tools のインストールを待たずに初期からネットワークに接続可能になります。

vTPM の扱いなど、詳細が上記の Windows 11 Support on vSphere にまとまっているので VDI などで Win11 を利用する場合には参照してください。

遅延センシティブ VM 向けの Hyper-threading (ハイパースレッディングによる高遅延感度) 設定

従来の VM の高遅延感度設定に加えて仮想ハードウェアバージョン 20 からはハイパースレッディングによる高遅延感度設定がサポートされました。

この機能により (恐らく) 従来の CPU スケジューリングよりも厳密に VM に割り当てられたペアとなる vCPU が物理側の HT とリンクして処理されるのでは無いかなと思われます。


従来の高遅延感度設定と同じく、HT 高遅延感度を有効にした場合も VM に割り当てる CPU とメモリはオーバーコミットなく 100％ 予約されますのでリソース消費量に注意が必要です。


簡素化された仮想 NUMA 構成

vSphere 8.0 と仮想ハードウェアバージョン 20 の組み合わせでは仮想 NUMA のトポロジと構成が vSphere Client UI で設定可能になります。

API による vSphere とゲスト間のデータ共有

ゲスト OS と vSphere 管理間で VMware Tools を介して vSphere REST API を用いてメタデータの受け渡しを行う vSphere DataSets が提供されます。

William Lam さんの Blog で詳細が説明されていたので共有します。

vSphere DataSets も仮想ハードウェアバージョン 20 と VMware Tools 11.3 以上が前提となります。

個人的に GA されたら最優先で試してみたい機能の一つです。

デフォルトのセキュリティ強化

信頼されていないバイナリの実行防止

ESXi 8.0 では起動オプションの execInstalledOnly がデフォルトで有効となり、信頼された VIB を介してインストールされていないバイナリは実行されなくなるようです。

※ vSphere 7.0 までは 3rd Party の互換性のためデフォルトで execInstalledOnly は無効でした。従来利用できていたコンポーネントが利用できなくなった場合はこの設定を確認する必要がありそうです。

ESXi は、許容レベルによって管理される VIB の整合性チェックを実行します。VMkernel.Boot.execInstalledOnly 設定を使用して、ホストにインストールされている有効な VIB から発信されたバイナリのみを実行するように ESXi に指示できます。この設定をセキュア ブートと組み合わせると、ESXi ホストで実行されるすべてのプロセスが署名され、許可され、想定されるようになります。デフォルトでは、vSphere 7 のパートナーとの互換性のために、VMkernel.Boot.execInstalledOnly 設定は無効になっています。この設定を有効にすると（可能な場合）、セキュリティが向上します。ESXi の詳細オプションの構成の詳細については、https://kb.vmware.com/kb/1038578 の VMware のナレッジベースの記事を参照してください。

最近は vSphere を介在するマルウェアの報告も増えていますので、セキュアブートや execInstalledOnly の設定などで仮想化基盤も保護していく必要性が増しています。

その他、以下のようなセキュリティ強化が図られています。

  • vSphere 8.0 では TLS 1.2 のみサポート、TLS 1.0 と 1.1 は削除
  • SSH 接続のデフォルトタイムアウト (ESXi 7.x まではタイムアウトなしでした)
  • サンドボックス化されたデーモン
  • TPM 1.2 モジュールの廃止 (TPM 2.0 のみサポート)

vSphere 8.0 以降でサポートされなくなるハードウェア

ESXi 7.0 をインストールする時点で既に警告が出ているものとなりますが、vSphere 8.0 では Sandy Bridge / Ivy Bridge / Haswell などの CPU は非サポートとなり、Broadwell もデスクトップ用やワークステーション用の Broadwell-DT や Broadwell-H は非サポートとなります。

基本的に Intel であれば Broadwell-EP (E5-26**v4 など)、Scalable Processor 世代以降、AMD であれば EPYC 以降がサポートされる前提になります。

あと、地味ですが vSphere 8.0 以降で Intel Cascade Lake 以降、AMD Rome 以降の CPU を利用する場合は Legacy BIOS はサポートされず、UEFI のみがサポートとなります。(そもそも CPU/サーバーハードウェアが BIOS をサポートしていない) 

vSphere 7.0 でも同様でしたが ESXi の USB/SD カードブートは非推奨であり、より厳密に OS-Data 領域は SSD や HDD などの耐久性の高い領域への配置が必須となるため新規で USB/SD カードへ ESXi をインストールするメリットはなくなります。

また、TPM 1.2 モジュールも非サポートとなり、vSphere 8.0 では TPM 2.0 のみをサポートしますので TPM 1.2 が利用されている環境はご注意ください。(恐らくサポートされる CPU 世代的に問題はないはずです)

vSphere 8.0 の HomeLab 向けの Update

William Lam さんの Blog でも既にいくつか紹介されていますが、ESXi 7.0u3f のインストールイメージから NUC 10 などに搭載される NIC Intel i219 用のドライバが標準で組み込まれました。

NUC 11、NUC 12 など最新の NUC では引き続き Flings の NIC Driver が必要なのでご注意ください。

vSAN 8.0 で気になる機能強化

vSAN 8.0 では全く新しい vSAN アーキテクチャ "vSAN Express Storage Architecture (vSAN ESA)" と、従来の vSAN アーキテクチャにおける Write Buffer 600GB から 1.6TB への上限拡大という2点が大きな強化点となります。

※ 実際は vSAN ESA に関連してかなりの数の新しい機能が並んでいますし、vSAN 7.0 ～ 7.0u3 で多くの追加機能が実装され、それらは vSAN ESA でも利用可能なものが殆どとなります。

vSAN Express Storage Architecture (vSAN ESA)

vSAN 8.0 では初期バージョンの vSAN 5.5 リリース時から採用されていた Cache SSD + Capacity Drive (SSD or HDD) の 2 層の組み合わせから進化した
All NVMe Capacity Drive を利用した 1 層アーキテクチャ vSAN Express Storage Architecture (vSAN ESA) が登場しました。

それに伴い従来型の 2 層アーキテクチャの vSAN は "vSAN Original Storage Architecture (vSAN OSA) " と呼び分けられる様になります。


vSAN ESA は従来の 2 Tier デザインの置き換えではなく、更に高 IO 性能・低遅延性を求めるワークロード向けの上位オプションとなります。

vSAN ESA を利用するための前提条件

VMware vSAN Design Guide や vSAN Frequently Asked Questions (FAQ) が徐々に更新され情報が整理されてきていますので GA 前ですが前提条件を整理します。

  • サポートされるサーバーは ESA 向けの vSAN Ready Node のみ ( vSAN 8.0 GA 後に vSAN HCL に掲載)
    ※ 従来のような BYO でコンポーネントを揃える vSAN は ESA では公式サポートはされないようです
  • 構成される SSD は vSAN HCL で ESA 向けに認証された TLC NMVe SSD
    • vSAN Ready Node として従来のように AF4 ~ AF8 で定義され、AF４ が ESXi あたり 4 SSD で構成されるので実質的に最小 4 ドライブ構成からサポートされる (実際はより少ない本数でも動くはず)
  • ネットワークは 25Gb * 2 以上、推奨は RDMA の利用
    • RDMA を利用する事で ESXi の CPU 利用率を下げ、TCP/IP 変換の無駄を省きより低遅延、高速な IO が可能になる
  • vSAN Advanced、vSAN Enterprise エディションで ESA をサポート
  • 新規デプロイ必須 (vSAN 7.x 以前の OSA からのインプレースアップグレードは不可)

vSAN ESA でサポートされる機能

従来の vSAN の管理機能は一部を除き一通り vSAN ESA でも利用可能で、新たに vSAN ESA として以下の機能を実装しています。

  • 圧縮 (デフォルトで有効、SPBM で VM 事に解除が可能)
  • 暗号化 (クラスタレベルで実施)
  • ESA 用の新しいネイティブスナップショット
  • 再同期トラフィック制御のためのアダプティブネットワークトラフィックシェーピング

vSAN ESA でサポートされない機能

また GA 時点では以下の機能は vSAN ESA では利用できず、vSAN OSA のみでの提供となるので注意が必要です。

  • HCI Mesh
  • vSAN ファイルサービス
  • 重複排除 (デフォルトで VM 毎に無効化可能な圧縮は有効)
  • VMDK 毎のポリシー制御 (ESA では VM 毎のポリシー制御)
  • 有効化された暗号化の再度の無効化
  • Durability components (耐久性コンポーネント : vSAN 7.0u2 からサポートされるホスト障害・コンポーネント障害時に書き込みデータの差分を別の場所に保存する機能)

vSAN ESA の仕組み

vSAN ESA では組み込まれる NVMe SSD を従来の vSAN FS ではなく、新しい vSAN LFS (ログ構造ファイルシステム) でフォーマット・構成し、より高速に・より効率よくデータを処理できるようになります。


特徴的なのは、RAID5・RAID6 などの Erasure Coding の場合でも RAID1 と同等の IO 性能を発揮することができるように、書き込み処理を一旦 Performance Leg 領域にミラーリングで書き込み、IO が一定数蓄積された段階で Capacity Leg にフルストライプでデータを書き込み・更新する方式を取ります。

これにより従来は RAID5 であれば 1 回の書き込み毎にパリティ計算のために 2 回の読み込み、2回の書き込みで 4 IO、RAID6 であれば 1 回の書き込み毎にパリティ計算のために 3 回の読み込み、3 回の書き込みで 6 IO のいわゆる Write Penalty が発生していましたが、
vSAN ESA では Erasure Coding のパリティ含めたストライプでまとめて書き込むのでパリティ計算のための読み込み・書き込みの処理を 1 回でまとめて行えるようになります。 


vSAN ESA でも従来どおり各ドライブは独立したファイルシステムで構成され、それぞれに Meta-Data / Performance-Leg / Capacity-Leg の領域を保持しています。

これらは従来の vSAN-FS ではなく、vSAN-LFS (Log-structured File System : ログ構造ファイルシステム) で構成されます。


vSAN ESA では RAID5 / RAID6 を利用した場合においてもパリティ計算の Write Penalty を極小化するためそれぞれの VM の FTT 定義に応じて、Performance-Leg と Capacity-Leg のそれぞれでデータを配置します。

Performance-Leg から Capacity-Leg にデータをでデステージする仕組みは vSAN 7.0u3 で実装された Strided Writes に似ていますが、Strided Writes は RAID の 1MB のチャンクが RAID5 なら3つ分(3MB)以上、RAID6 なら4つ分以上(4MB) 以上の書き込みサイズのときにのみ有効となる機能でした。

vSAN ESA は必ず Performance-Leg にデータを一定ためたタイミングで RAID 幅に合わせてフルストライプでデータを Capacity-Leg に書き込みますので常に書き込み性能を高く維持します。


vSAN ESA と vSAN OSA の処理の比較

従来の vSAN OSA の場合、VM から取り込まれたデータのチェックサム・圧縮・暗号化などの操作を各 ESXi ホストが Cache -  Capacity の IO の流れの中で実施していました。


vSAN ESA ではこれらのデータ処理を VM から取り込んだ際に1度だけ VM が稼働する(オーナーの) ESXi にて処理を行い、その後各 ESXi ホストに分散配置し、チェックサムも最初に計算済みの CRC を再利用して RAID チャンクにフルストライプで非同期に実行するので CPU リソースを大幅に削減し、無駄な IO 処理の回数を削減する事が可能になりました。

※ NetApp の NVRAM でデータをキャッシュして WAFL でディスクに RAID-DP で書き込む動きにも似ているな、と思います。


vSAN ESA での RAID5 方式

ESA では従来どおり、RAID1 のミラーリング、RADI5 / RAID6 の Erasure Coding をサポートしますが、RAID 5 のみ ESXi ホスト台数に応じてデータとパリティの割合が可変します。

クラスタの ESXi ホスト台数が 3台 ~ 5台のときは 2D + 1P の RAID5 (2+1)、
クラスタの ESXi ホスト台数が 6台以上のときは 4D + 1P の RAID5 (4+1) で構成されます。

これは可能な限り N+1 のホスト台数をクラスタに保持して 1 ホストをスペアとして利用できるように調整する考えのためです。

※ RAID6 のときは 4D + 2P の RAID6 (4+2) で従来と同じです。

新しいネイティブスナップショット

従来の vSAN Snapshot は vsanSparse を採用しつつも基本的には vSphere の REDO ログベースのスナップショットで、ベースディスクとデルタディスクのチェーン構造でした。

vSAN ESA の新しいスナップショットはログ構造化ファイルシステムに B-Tree を使用した効率的なルックアップテーブルを使用します。


新しいネイティブスナップショットは従来以上にスナップショットを保持している状態での IO 劣化を排除し、またスナップショットの作成・削除時の IO Stun 時間を極小化しアプリケーションへの影響を最小にすることができるとのことです。

新しいネイティブスナップショットも従来どおり VADP バックアップや vSphere Replication・SRM との連動は可能となります。

また、従来の vSAN スナップショットでは FTT で指定した可用性を下回っているとスナップショットの取得ができなくなりましたが、新しいネイティブスナップショットではオブジェクトが可用性低下状態もスナップショットの取得が可能になります。
これは地味にバックアップ処理の継続性などにも寄与するので大きな改善だと思います。

ポリシーベースの圧縮機能

従来の圧縮は vSAN データストア全体で有効化されましたが vSAN ESA では SPBM で VM 毎に制御可能です。※ デフォルトで有効

圧縮は 4KB のブロックサイズで実施され、VM が稼働する ESXi ホストで圧縮し、圧縮されたデータが各 ESXi に配置されるため CPU 処理・ネットワーク負荷を従来以上に抑える事が可能となりました。

適応型ネットワーク帯域制御

vSAN 6.7 で実装された Parallel Resync (並列再同期) と Adaptive Resync (適応型再同期) により vSAN のデータ再構成時のトラフィックシェーピングは遅延制御で VM 側の IO 負荷が高いときには再同期 IO を全体の 20% に抑える動きをしていました。

vSAN ESA では All NVMe で構成されるため仕様上 IO Queue / Queue Depth が非常に多くほぼデバイスレートの IO が ESXi ホスト間でやり取りされます。

これにより vSAN ESA は再同期処理が非常に高速で実施される事になりますが、その IO がバーストトラフィックとなるリスクもあるため、vSAN ESA においても VM 側の IO を優先する制御が備わっており、それが Adaptive Network Traffic Shaping (適応型ネットワーク帯域制御) です。

適応型ネットワーク帯域制御 においても再同期トラフィックが VM 側の IO を枯渇させないように 20% を上限に制御します。当然、VM 側の IO がない場合は再同期 IO を利用できる限り流します。

vSAN Original Storage Architecture (vSAN OSA) の強化点

vSAN Cache Write Buffer 有効容量の拡大 (600GB → 1.6TB へ)

また、従来型の 2 層アーキテクチャでの All Flash vSAN 時の Cache SSD のバッファ領域としての実効容量 600GB の上限が大きく上昇し上限が 1.6 TB となります。

Write Buffer の有効なアクティブ領域が増えたことで得られるメリットとして以下が考えられます。

  • バージョンアップすることで既存環境も性能向上
    • Write Buffer の増加により、600GB を超えるキャッシュ層 SSD を利用している場合は今まで以上に大量の書き込み IO を受け止める事が可能となるので IO 安定性の向上、Write 性能の Max 値の上昇が見込める
    • ※ 但し構成によってはシステムメモリの消費が DG あたり最大 5GB 増えるので注意
  • ミドルレンジの SSD の積極的な利用が可能に
    • 耐久性の高い(高価な) DWPD 10 以上 の Write Intensive SSD ではなく、中容量の DWPD 3〜5 の Mix Use SSD クラスの SSD を利用して高い性能と耐久性を両立したコストパフォーマンス向上
  • 構成の選択肢が拡大
    • Mix Use SSD、1TB 以上の中容量 SSD の選択肢の拡大によるキャッシュ層 SSD の選択肢の増加

ただし、既存環境を vSAN 8.0 にバージョンアップしたでもデフォルト設定は上限が 600GB のままです。

1.6TB まで拡大するためには各 ESXi の詳細設定値 LSOM.enableLargeWb を "1" に設定する必要があります(再起動などは不要)

CLI で設定する場合は esxcfg-advcfg -s 1 /LSOM/enableLargeWb 
※ デフォルトは "0" 、現在の設定値を確認する場合は −g を指定

詳細は以下 KB を参照してください。

従来のバージョンでの Cache SSD の使われ方については以前まとめておりますので以下を参照願います。

→ vSAN キャッシュ層 SSD の Write Buffer 領域の ”600GB” サイズの仕様について


その他

その他、vSAN 8.0 では既存の vSAN 機能の多くが改善、強化されるようです。

詳細は GA 後のリリースノートで確定情報を確認しつつ本ページに更新を加えたいと思います。




時刻:
ラベル: , , , , , , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)

過去30日でアクセスの多い投稿