［Ask The Expert］VxRail v8.0リリースのすべて！

待望のVxRail 8.0 リリース！

2022年Q4に2年ぶりのメジャーバージョンとしてリリースされたvSphere 8/vSAN 8ですが、

2023年1月6日に、vSphere 8/vSAN 8 に対応する VxRail 8.0.000がリリースされました。

VxRail 8.0 の初期リリースとなる VxRail 8.0.000 はアップグレードバンドルとしての提供となっており、

現時点では工場出荷時のご提供はありませんが、別途提供されている初期化ツール（RASR or NIM）を利用することで、VxRail 8.0.000 での初期構築も可能となっております。

ただし、vSphere 8の対応CPU制限により、対応ハードウェアは14世代PowerEdgeモデル以降となっておりますので、13世代PowerEdgeモデル（E460,P470等）をお使いの環境では利用できませんことをご留意ください。

さて、Ask the Expert の初日となる本日は、VxRail 8.0 の見どころをハイライトでお伝えいたします。

vSAN 8 ESA 対応

vSAN 8 では、次世代アーキテクチャである vSAN ESA (Express Storage Architecture) が利用可能となっています。

もちろんVxRail 8.0は初期リリースにて、vSAN ESA に対応しております。

vSAN ESAは、現代のおける最新のパフォーマンス要求やストレージ機能セットに対応するために、従来のvSANアーキテクチャ（OSA:Original Storage Architecture）で採用されていた SSD/HDDを利用するデザインから、 All NVMe ベースのデザインに進化しました。VxRail においては E660NとP670NにてvSAN ESAを利用できます。

vSAN 8 OSA 対応

vSAN ESAはAll NVMeベースのデザインとなっていますので、既存のvSANクラスタでNVMeを利用していない、またはvSAN ESAでのHW要件を満たせない環境については引き続きvSAN OSAにて vSAN を利用することができます。

目立たないながらもvSAN OSAにおいても機能拡張が実装されており、運用管理性、可用性、パフォーマンスに関わる機能強化がされています。

DPU対応（vSphere Distributed Service Engine）

VxRailはDPUを利用したソリューションである、vSphere Distributed Service Engine (DSE)に対応します。

本日時点で見積もりは可能となっており、P660F/P670N/V670Fで利用可能です。

その他のVxRailの機能拡張

以下はVxRail 8.0に限ったことではありませんが、機能拡張が実装されております。

• ２ノードクラスタで内部vCenterをサポート
• Dynamic NodeのプライマリストレージとしてvVOL over FC-NVMeをサポート
• VMware Subscriptionライセンスに対応
• CloudIQの運用管理機能強化

上記以外にも今回のAsk the Expertでは、VxRail 8.0の導入やバージョンアップグレードに関する留意事項やTipsなども紹介予定です。

いただいたご質問にも丁寧に回答いたしますので、ご質問があれば遠慮なくご投稿ください！

DPU搭載VxRailでネットワークサービスを高速化！

vSphere 8 の新機能といえば何といってもvSphere Distributed Services Engine (以降vSphere DSE)です。

2023年1月17日にリリースされたVxRail 8.0.010 にて、VxRailでもvSphere DSEが利用できるようになりました。

vSphere DSEは、DPUまたはSmartNICとよばれる次世代のネットワークカードを利用し、CPU処理をDPUにオフロードすることでネットワークパフォーマンスを向上や、効率的なリソース活用を可能にするソリューションです。

vSphere DSE のソリューション詳細については、2022年11月に開催された VMware Explore 2022 Japan のセッションにて詳しく解説されており、DPUについての初歩的な説明から、vSphere DSEの魅力とセットアップ方法まで丁寧に解説されております。

まだご覧になっていない方はぜひともご覧ください。

【VMware Explore 2022 Japan セッション：NS21252】
スマート NIC・DPU って知ってる？vSphere 8 の注目機能を基礎から徹底解説！

https://vm-event.jp/evolve/ondemand/EO22665/

もしくは、英語とはなりますが 2022年9月に開催された VMware Explore 2022 in US にてDeepDiveセッションが公開されておりますので、より詳細に把握されたい方はこちらもお勧めです。

VMware Explore 2022
Project Monterey Behind the Scenes: A Technical Deep Dive

https://www.vmware.com/explore/video-library/video-landing.html?sessionid=1655951634387001wkp9&video...

vSphere DSEをVxRail観点でザックリ解説！

さて、Ask the Expert "VxRail v8.0リリースのすべて！" の3日目となる本日の投稿では、上記のリリース情報とDeepDiveセッションのご紹介に加えて、ハードウェア観点でのDPUの実装とVxRailでvSphere DSEを利用することのメリットについてご説明させていただきます。

まず、DPUがESXiからどのように管理されているかを簡単に図示してみました。

VxRailは物理的にはPowerEdgeサーバで構成されますので、PowerEdgeサーバ内でのESXiとDPUのコミュニケーションを図示しています。

• PowerEdgeサーバは通常のx86 CPUを搭載し、OSとしてESXiを稼働させてている
• PowerEdgeサーバPCIeスロットにDPUカードを搭載している
• DPUカードにはARM CPUとHWアクセラレータが搭載されている
• DPUカード上で ”ESXio” と呼ばれるDPU専用ESXi OSが稼働している
• x86 ESXi と DPU上のESXioはPCIeバスで通信する
• x86 ESXiはサーバ上のiDRACとvUSB NIC経由で通信をする
• DPU上のESXioは、NC-SI/RBTにてiDRACと通信をする（Management Interface CardとRIO Cardを経由）

上図からもわかる通り２つの管理パス（緑と黒）とI/Oパス（オレンジ）が存在します。

DPU上にESXioをインストールする際には、ESXiのインストーラーから一緒にインストールすることができますが、その際には黒線のiDRAC経由でDPU上にESXioをインストールしたり、Rebootしたりしています。

また、x86 ESXiからDPU上のESXioに対してPCIe バス経由で管理疎通（緑）が可能であり、オフロードの設定などを投入することができます。

I/Oはオレンジ色のパスを利用し、vSphere DSEとして設定されている場合はI/O処理の一部がDPU上のCPUやHWアクセラレータにオフロードされます。

VxRailでvSphere DSEを利用するメリット

DPUを搭載した構成であっても通常のHCI VxRailと同じように優れた管理運用性を享受できます。

VxRailでvSphere DSEを利用する場合は、VxRail 8.0.010として新規に出荷する必要がありますが、
出荷時点で必要なDPUの搭載や必要な内部ケーブリングはすべて実施済みとなっています。

先の図からもわかる通り、DPUとiDRACの接続はサーバ内部にて特別なカードとケーブルの接続が必要ですが、出荷時点で既に実施されており、かつESXiとESXioもインストール済みのため、納品後にインストール作業をする必要がありません。

VxRailクラスタのデプロイも通常のVxRailと同じように実施でき、内部vCenterも利用できます。

さらにVxRailの機能によってDPUの状態を簡単に確認することができ、検知されたDPU障害を弊社に自動通報する機能もあります。

そして、もちろんVxRailの魅力であるライフサイクル管理機能によって、DPUの含めた一括アップグレードを無停止（※）で実施できるだけでなく、将来的なノード追加、拡張も標準のVxRailと同じようにスムーズに実施できます。

※vMotionとvSANストレージの可用性によって仮想マシンを停止せずにアップグレード可能

VxRailでDPUを利用する際のFAQ

最後に実際にDPU搭載VxRailを導入する際のFAQをご紹介いたします。

• 対応モデルは？
  • E660F/P670N/V670Fに対応しています。
    
• 利用できるDPUカードは？
• • Nvidia (Mellanox) Bluefield-2 (25 GbE) および、Pensando (25 GbE and 100 GbE) です。
    
• vSAN ESAと併用可能？
• • 現時点ではvSAN OSAのみをサポートしています。
    
    
    
• GPUは搭載可能？
• • V670Fをサポートしていますが、GPUとの混在はサポートしていません。
    
    
    
• 初期構築時に自動でvSphere DSEの設定もされる？
• • vSphere DSEは、NSX-Tのインストールが必須となっているため、初期構築後のDay2タスクとして有効化することができます。
  • 初期構築時にうっかりDPUをSystem vDSに割り当てないようにフィルタリングされています。
    
    
    
• LOM（2 x 1GBase-T）がなくなっている？
• • はい。通常の15GモデルVxRailではLOMとして1GBase-Tのインターフェースが付帯していましたが、DPUモデルではLOMのスロットにManagement Interface Cardが搭載されているため、LOMは付帯しておりません。
    
    
    
• LOMがなくなったことによる影響は？
• • 特殊な構成を除きVxRailのシステムトラフィックはOCP（オンボードNIC）を利用するため影響はありません。
  • LOMがなくなったことで、vmnicの採番が変わっている点はご注意ください。（vmnic0がOCPポート0）
    
    
    
• 拡張スロットに空きはある？
• • E660Fは、OCP/DPU以外にFH（x16）のスロットが1つ空いています。
  • P670N/V670Fは、OCP/DPU以外にFH(x16)が１つ、FH(x8)が２つ、LP(x16)が２つ空いています。
    
    
    
• DPUの冗長構成は可能？
• • 残念ながら初期リリースにおいてはvSphere DSEで冗長構成はサポートされておりません。
    
    
    
• 既存の15G VxRailにDPUを後付けできる？
• • 残念ながら、Management Interface CardやUARTケーブルの搭載が必要になるため現時点では新規出荷でのみDPUを利用可能です。
    
    
    
• vSphere DSEとしての制限に加えて、VxRail環境固有の制限はある？
• • 以下の構成ではDPUが利用できません
    • ストレッチクラスタ
    • 2ノードクラスタ
    • Optane memory
    • 256GB LRDIMM
    • GPU

その他ご質問やご不明点があればどしどしご質問ください！

VxRail + DPU/vSphere DSEについて何点か教えてください。

1. DPU/DSE利用する場合はクラスターの全ノードがDPUを搭載する必要があると感じましたが、理解合ってますでしょうか？
   Yesだと思っていますが、その場合、ノード間でDPUタイプ(ベンダーなど)は揃える必要ありますでしょうか？
2. ライセンス要件はどのようになりますでしょうか？
   vSphereはEnterprise Plus必要になりますでしょうか？
3. ノード障害もしくはDPU障害の際の再構成は、再設定になるのでしょうか？ それとも既存情報からリカバリーする形なのでしょうか？

ご質問ありがとうございます！

DPU/DSE利用する場合はクラスターの全ノードがDPUを搭載する必要があると感じましたが、理解合ってますでしょうか？
Yesだと思っていますが、その場合、ノード間でDPUタイプ(ベンダーなど)は揃える必要ありますでしょうか？

はい。こちらはご認識のとおりです。DSEとしてクラスタの全ノードで同一タイプのDPUを搭載する必要があります。

ライセンス要件はどのようになりますでしょうか？
vSphereはEnterprise Plus必要になりますでしょうか？

はい。vSphere Enterpriser Plustが必要になります。また、現時点ではDPUを利用するためにはNSX-Tが必要となりますので、併せてNSX-T Enterpriseが必要になります。

ノード障害もしくはDPU障害の際の再構成は、再設定になるのでしょうか？ それとも既存情報からリカバリーする形なのでしょうか？

vSphere DSEのデザインとして、DPU上のESXioへのモジュールの適用やImageのアップデートは、NSX-TとvLCMの機能にて実行されます。オフロードの設定自体は分散仮想スイッチや仮想マシンの設定として保持していますので、交換後に再設定をする必要はありません。

本日は vSAN 8.0 の新しい技術でもある vSAN Express Storage Architecture (vSAN ESA) についてご紹介したいと思います。

ちょうど一昨日ご紹介した12月に開催した 「VMware vSAN 8 Deep Dive !!! 」の Webinar コンテンツが本日公開されましたので、まずは以下のコンテンツをご紹介します。
※ 資料ダウンロードも可能になりました。

vSphere / vSAN オンラインセミナー#56 VMware vSAN 8 Deep Dive !!!
https://juku-jp.vmware.com/video/vsphere-vsan-os-056/

vSphere / vSAN オンラインセミナー#55 何が変わった？待望のメジャーバージョン VMware vSAN 8 を解説!
https://juku-jp.vmware.com/video/vsphere-vsan-os-055/

上記サイトの資料をダウンロードしていただけると分かるのですが、まぁかなりのボリュームの内容を1時間ぶっ続けで話してますのでかなりの情報量となっています…
詳しくはこれらに目を通して、となってしまうのですが取っ掛かりが合ったほうが良いので今回は vSAN ESA のポイント、特に「 vSAN ESA の IO 性能は激烈に向上してるよ！」ということを簡単にご紹介します。

vSAN OSA と vSAN ESA の違い

従来の vSAN (vSAN OSA) と新しい vSAN ESA の何が違うの？
というのは以下のイラストでご説明しています。

大きなポイントは4つ

1. vSAN データストアの単位は従来と同じくvSphere クラスタ単位でデータストア化
2. 従来のキャッシュ・キャパシティの階層ドライブのディスクグループ構成ではなく ESXi ホスト単位のシングル Tier のストレージプール構成
3. ストレージプールは vSAN ESA 向けに認定された All NVMe SSD (DWPD 3 以上、TLC セル)で構成
4. vSAN 用ストレージネットワークは 25Gb 以上

ここに並べた項目だけでも、All NVMe で 25Gb ネットワーク ！？ ということでかなり高性能な構成が前提となっている事がわかります。

お客様からよく相談される点として、「従来の vSAN は無くなるの？」「従来の vSAN は vSAN ESA にアップデート出来るの？」というご質問があります。

vSAN ESA はハードウェア構成からアーキテクチャがまるっと刷新されたため既存 vSAN （vSAN OSA）を vSAN ESA へアップグレード(インプレースアップグレード)はサポートされず、
新規で vSphere 8.0 / vSAN 8.0 を導入いただく際にご利用いただける vSAN の "オプション" の一つとなります。

既存環境からのワークロードの移行は、既存クラスタの隣に新規に vSAN ESA クラスタを導入し、クラスタ間で vMotion などで VM 移行をしていただけます。

従来の vSAN でも十分高いストレージ性能を出せておりましたが、今回の vSAN ESA は更に超高 IO ・低遅延 IO を利用出来るように、最新のストレージハードウェアに合わせて vSAN ソフトウェアアーキテクチャが刷新されたのが今回の一番のアップデートとなります。

vSAN ESA はより高速な IO を提供するための上位 vSAN オプションであり、vSAN OSA も今後も提供されますので、要件・用途に応じて適材適所に選ぶことが可能です。

vSAN ESA の内部的なデータ可用性・容量効率性・IO 性能の両立について

vSAN ESA は All NVMe が前提となり、従来の SAS/SATA ドライブを利用した場合と異なり IO Queue が劇的に拡大し、より高並列・高速・低遅延な IO を前提とするストレージに進化しました

それを実現するためのアーキテクチャも刷新され、NVMe ドライブそれぞれの内部を Performance-Leg と Capacity-Leg と Meta Data  の領域として使う仕組みになりました。

※ キャッシュドライブが不要になったので、その分のドライブスロットもキャパシティを兼務する NVMe ドライブに利用できるようになり ESXi ホスト毎の容量効率も向上しています。

この Performance-Leg と Capacity-Leg  が vSAN ESA の性能と可用性を高いレベルで両立する要の技術となります。

仮想マシンから発行された IO は、まずは FTT で指定した可用性レベルに基づき RAID1 (Miror) で P-Leg に書き込まれ、その後非同期で C-Leg に RAID 5/6 のフルサイズのストライプ幅で書き込まれます。

イメージとしては vSAN OSA のキャッシュ・キャパシティの2層に近い仕組みですが、高 IO 帯域と 高 IO Queue を持つ NVMe ドライブの内部に2つの領域を保持し、データを効率よく処理します。

この仕組はアニメーションを含めた説明があったほうがわかりやすいので、詳細については冒頭に記載した VMware vSAN 8 Deep Dive !!! を参照願います。

従来の vSAN OSA で RAID5/6 などの Erasure Coding を利用すると、外部ストレージの RAID5/6 と同じく書き込み IO 毎に Erasure Coding のパリティ計算をしていましたので、パリティ計算時の所謂 Write Penalty が発生するので性能面で RAID1 と比べると劣化を考慮する必要がありました。

vSAN ESA では P-Leg と C-Leg で構成される 2層構造が C-Leg に書き込む際の RAID5/6 でのフルストライプ書き込みを行うことで、IO 毎のパリティ計算を排除し、RAID のフルストライプ分のデータが P-Leg に蓄積されたタイミングで C-Leg にフルストライプ書き込みを行います。

これにより、vSAN ESA では RAID 5/6 の容量効率を得ながら、書き込み IO 性能は RAID1 と同じく低遅延・高速な処理が可能になりました。 

ちなみに RAID1 構成を利用する場合も P-Leg と C-Leg は使われますが、上の図にあるように必ず一部はズレて合計で奇数台の ESXi にデータが配置される仕組みになるので vSAN OSA で存在していた Witness Object は不要となりました。(2Node Cluster や Stretched Cluster では Witness Appliance は利用) 

もう一つ、vSAN ESA では高い性能を発揮しつつ、ESXi ホストの CPU 処理を削減する仕組みを実装しました。

それは圧縮・暗号化・チェックサム計算など vSAN OSA ではデータを格納する前に各 ESXi ホストで CPU を利用して処理していた各種データサービスを、
vSAN ESA では仮想マシンが稼働する ESXi ホストで、仮想マシンから IO を受け取ったタイミングで "その ESXi ホストで一度だけ" まずは圧縮 → 圧縮して削減されたデータを暗号化 → チェクサム計算を行い、その後に各 ESXi ホストに圧縮済みデータを配送する仕組みを実装しました。

これにより、従来は分散されたデータ毎にデータサービスの処理で CPU が消費されていたところを仮想マシンが稼働する ESXi ホストで1度処理するだけでよくなり、転送データ量も削減され、クラスタ全体で高レベルで効率化されました。

この CPU 負荷を抑える仕組とあわせて、そもそもの IO 処理性能がホスト CPU に依存せず ドライブレベルで高い処理性能の NVMe SSD 、そしてオプションでありますが vSAN ネットワークに RDMA (NVMe over Fabric) を利用できれば、ESXi ホストの CPU 負荷を劇的に下げ、効率よく仮想マシン側にリソースを割くことが可能です。

今回も長文になってしまいましたが、vSAN ESA はどう性能向上を果たしたか？という観点でアーキテクチャをご紹介させていただきました。
圧縮・暗号化などのデータサービスについての詳細は次回以降でご紹介したいと思います。

VxRail 8へのバージョンアップグレードのコツとヒント！

Ask the Expert "VxRail v8.0リリースのすべて！" もう5日目です！

一週目は新しい機能についての説明が盛りだくさんでしたので、本日は少し軽めな内容にしたいと思います。

VxRail 8（vSphere8/vSAN8）は2年ぶりのメジャーバージョンリリースになりますので、バージョンアップグレード作業についてご心配をされている方も少なからずいらっしゃるかと思います。

安心してください！

バージョンアップグレードといえばVxRailの恩恵を最も感じられるイベントであり、それは今回のVxRail 8へのアップグレードでも同様です。

アップグレードに必要な準備

まずは準備段階のご説明です。

長年VxRailをご愛顧いただき、VxRail 4.xの時代からご利用いただいているお客様にとっては見知った内容も多いかと思います。

①VxRail 8.0.000 へバージョンアップ可能な既存バージョンを確認しましょう

VxRail 8.0.000へバージョンアップ可能な既存のバージョンについては、リリースノートからご確認頂けます。

リンク先のページをご覧いただければわかる通り、VxRail 4.7/7.0のほぼすべてのバージョンからVxRail 8.0.000にアップグレードすることができます。

唯一の例外として、VxRail 7.xの最新バージョンである 7.0.410からはアップグレードができないため、その場合は将来の8.xリリースを待つ必要があります。

また、現時点ではインターネットアップグレードには対応しておりませんので、ローカルアップグレードにて実施する必要があります。
とはいえ、ほとんどのお客様は普段からローカルアップグレードで実施されていますので、その点は特に影響はないかと思います。

もし、直接アップグレードに対応していない VxRail 4.5.xをご利用中の場合でも、多段アップグレードをすることでVxRail 8.0.000にアップグレードすることが可能です。

②VxRail 8.0.000 に対応したハードウェアモデルを確認しよう

初日の投稿でも触れていますが、VxRail 8に対応したハードウェアモデルは14世代PowerEdge以降のVxRailモデルとなっています。

具体的には以下のモデルは未対応です。

・Quanta ハードウェアモデル（VxRail 60~280およびG410。すでにサポート終了）

・13世代PowerEdgeモデル（VxRail E460/F, P470/F, S470, V470）

15世代のPowerEdgeモデルを利用するVxRailハードウェアはすべてVxRail 8に対応していますが、

14世代のPowerEdgeモデルを利用している場合のみ追加の注意事項があります。

14世代PowerEdgeモデルのVxRailはTPMと呼ばれる内部パーツとしてTPM1.2とTPM2.0の2つのパターンが存在します。

残念ながらTPM1.2はVxRail 8に対応しておりませんが、TPM1.2をBIOS画面で無効化することによりアップグレードが可能となります。

③アップグレードパッケージファイルをダウンロードしよう

VxRailのアップグレードパッケージファイルはサポートサイトからダウンロードできます。

最近のVxRailは様々なお客様要件や環境に対応するために複数のパッケージファイルを提供しています。以下の表に従って必要なファイルをダウンロードしてください。

④ライセンスの準備

VxRail 8にバージョンアップするためには、ライセンスもバージョンアップする必要があります。

今回のvSphereのメジャーバージョンリリースによってライセンスのバージョンも変わるため、既存のVxRailで利用していたライセンスをそのままVxRail 8で利用することはできません。

しかし、 VxRail  8 (vSphere 8)にバージョンアップした直後は60日間の評価ライセンスが有効になります。そのため、仮にライセンスを準備できていなかったとしても即座に問題が発生するわけではありませんのでご安心下さい。

今回のVxRail ８へのバージョンアップに関連して、vSphere、vSAN、vCenterの３つ のライセンスで対応が必要です。

VxRail環境のvSphere（ESXi）のライセンスについては、お客様にて管理されているものとなりますので、VMware Customer Connect にお客様のアカウントでログインしてライセンスをバージョンアップして下さい。そして、新しいライセンスキーをVxRailへ再適用する必要があります。

vSANライセンスについては、VxRailのEmbedded License（VxRail 4.5.x以前）と、OEMライセンス（VxRail 4.7.x以降）によって対応が異なります。

VxRail 4.5以前に導入し、Embedded Licenseの場合は、VxRailのUpgradeの際に自動でライセンスが書き換わりますので、ライセンス関連の事前準備や当日の作業は不要となります。

VxRail 4.7以降で導入し、OEMライセンス利用の場合は、ライセンスはお客様管理となりますので、VMware Customer ConnectからvSANライセンスをバージョンアップして頂き、VxRailに適用する必要があります。

vCenterライセンスに関しては、内部 vCenterを利用されている場合は、Embedded Licenseとなりますので事前準備や当日のライセンス関連作業は不要です。

外部vCenter構成の場合は、vCenterそのもののバージョンアップおよびライセンス管理はお客様にて実施頂く作業となります。

まとめると以下のようになります。

⑤その他の関連ソリューションやコンポーネントとの互換性を確認

vSphere7 リリースの時もそうでしたが、初期リリースにおいては既存で利用中のソリューションが対応していない場合があります。

VxRail環境でよくつかわれているけれども、現時点（2023/01/20)で vSphere8 未対応となっている代表的なコンポーネントやソリューションは以下です。

・GPU

・RP4VM

・CloudLink

・NSX-V

その他、VxRailと関連して利用しているサードパーティソリューションがある場合は提供元にvSphere8/vSAN8との互換性をご確認ください。

⑥手順書を生成しよう

Dell製品の多くは運用で必要となる手順をSolveOnlineという手順書生成サイトにて提供しております。

https://solve.dell.com/

※利用に際しサポートアカウントの登録が必要となります

SolveOnlineにログインできましたら、VxRail Applianceを選択いただき、下図のように VxRail Procedure -> Upgrade -> Software Upgrade Proceduresを選択いただきます。

その後はお使いの環境に合わせて対話式に選択肢を選んでいくだけで簡単に手順書を生成できます。

※手順書の生成過程で既知の不具合等についてのメッセージ確認をする必要がありますので必ずお目通しください。

いつもと違う手順に注意！

あとは手順書通りに進めてアップグレードをするだけです。

細かいバージョンアップグレード手順の割愛させていただきますが、進めていく中でいつもと違う手順が存在していることにお気づきになると思います。

① vCenterをアップグレードしよう！（外部vCenter構成のみ）

外部vCenterサーバは先にアップグレードをしておく必要があります。

外部vCenterを先にvCener8にアップグレードした場合、KB#000182936の対応が必要になりますが、こちらはパートナー以上の限定公開となっているため、

テクニカルサポートまでご連絡をお願いいたします。

※内部vCenterの場合は事前のアップグレードは不要です

② Temporary IPの入力（内部vCenter構成のみ）

手順中の以下の入力項目のことです。

Temporary IP は、vCenter Serverのメジャーアップグレードのたびに必要となる入力項目です。

vCenter Serverのマイナーアップグレード（アップデート）の場合は、ISOファイルをマウントしてソフトウェアパッケージを更新する流れなのですが、メジャーアップグレードの場合は新規にvCenter Server VMを作成し、既存のvCenter Serverからデータマイグレーションをする形になります。

その際に、旧vCenterから新vCenterにTCP/IPでデータ送信が必要となるため、一時的に割り当てるIPアドレスをここで指定する必要があります。（同サブネット必須）

ちなみにですが、VxRail ManagerもVxRail 8へのアップグレードの際に同じように新規VMを作成してデータマイグレーションをしていますが、Temporary IPは利用しません。

どのようにデータをコピーしているのかはまたの機会でのご説明ということで今回は割愛させていただきますが、よりシンプルにアップグレードができるという点が素晴らしいですね！

③ vCenter management account username/passwordの入力

上図のTemporary IPの下に、vCenter management accountについての入力項目があります。

この入力項目は過去のVxRail アップグレード手順に登場したことがなく、今回限りの留意事項となります。

ここで指示しているvCenter management accountとというのは、VxRail Managerが内部的な処理で利用するためのアカウントで、初期構築時のパラメータとして指定します。

そんなアカウントに覚えがない！、というお客様も多いかもしれませんが、普段はご利用しないアカウントなのでそれが普通です（笑)。

導入時にご記入いただいたパラメータシートに必ず記載がありますので見返していただければ確認できます。

内部vCenter構成の場合はvCenter ServerのOSユーザとして作成されるため、@localosドメインに作成されています。

一方で外部vCenter構成の場合は、@localosドメインに限らず、お客様にドメイン（@vsphere.localなど）で作成されているはずです。

実は、vSphere 8において、内部vCenter構成で利用されている@localosドメインが将来的に廃止になることアナウンスされました。

そのため、廃止にされる前に先に@localosドメインから別のドメインのアカウントに変更する必要があるため、新しいアカウントのユーザ@ドメイン名とパスワードの入力をこのタイミングで求められています。（例：vxrailmgmt@vsphere.localなど）

外部vCenterの場合は@localosを利用しているとは限りませんので、既存で@localos ドメイン以外を利用している場合は入力は不要です。

まとめると以下です。

アップグレードはデル・テクノロジーズにお任せ！

「VxRailのアップグレードは普通のvSphereクラスタやvSAN Ready Nodeと比べると簡単かもしれないけど、不慣れな人には十分難しい」、というのがお客様の本音かと思います（手順書も英語ですし）。

VxRailのアップグレードの魅力は、自動化によって簡単に実施できるというだけではありません。なんと、お客様に代わってデル・テクノロジーズの専任エンジニアがリモートアップグレードを実施するサービスがあります。

このサービスは通常の保守契約に付帯しており、回数制限なく完全無償で提供されています。

現在VxRail 4.5.xや4.7.xを利用していて既にソフトウェア標準サポート期間が終了してしまった、、、というお客様もご安心ください！ソフトウェア標準サポート終了後も保守契約が有効である限り、同サービスを無償でご利用いただけますので、このタイミングでぜひともアップグレードをご検討ください。

VxRail アップグレードの魅力

2016年にVxRailがリリースされてから今年で7年目となります。

技術の進化や時代の移り変わりとともに、VxRailも様々な変化を経験してきましたが、

VxRailアップグレード機能とサービスの魅力は色褪せることなく、さらなる進化を続けています。

今回はVxRail 8へのアップグレードをテーマにご説明しましたが、VxRail 8に限らずアップグレードに関するご質問があれば、遠慮なくご投稿ください！

Ask the Expertは来週も続きます！

前回 vSAN ESA は CPU の負担を減らして IO 性能を向上させる、といったご紹介をさせていただきました。

この辺りをもう少し詳細にご紹介します。

従来の vSAN OSA では以下の図のように、仮想マシンから発行された IO はストレージポリシーに指定された FTT・RAID レベルに応じてデータを格納している各 ESXi ホストに分散され、それぞれの ESXi で 重複排除・圧縮・暗号化・チェックサム計算が行われます。

そのため、IO の数が多いほど、RAID で分散されるデータが多いほどに各 ESXi ホストでの処理が増え、特に RAID5/6 などの場合は パリティ計算による Write Penalty もあるため書込負荷が高いと RAID1 に比べると遅延も大きくなりがちでした(これは従来のストレージも同じですね)。

一方の vSAN ESA では前回ご紹介したように、仮想マシンが稼働する ESXi ホストで IO を受け取ったらその場で圧縮(デフォルト有効) -> 暗号化(オプション) -> チェックサム計算(デフォルト有効)を行い、その後データを各 ESXi ホストに転送します。

結果として、圧縮済みのデータを暗号化するので、(暗号化が有効であれば)暗号化計算のための CPU 負荷も減り、チェックサムも計算してから各 ESXi ホストに圧縮されたデータを転送するのでネットワークの帯域も節約できます。

※ vSAN ESA の初期リリースバージョンでは圧縮がデフォルトで有効となりますが、重複排除機能は今後のリリースでの提供となります。

また、RAID 5/6 を選択した場合でも仮想マシンは RAID1 相当の IO 性能 (IO遅延)でサービス提供が可能です。
それを以下の様な階層的な処理で実現しています。

ここでも上記で記した仮想マシンが稼働する ESXi ホストでデータサービスの処理を行い、その後各ホストに展開するという動きがメリットとして活躍しています。

All NVMe のシングルティアで構成されていますが、内部的に性能を加速するために毎回の RAID 5/6 の際のパリティ計算を排除し、P-Leg に書き込まれたデータがある程度たまった時点で、RAID 幅に応じたフルストライプの書き込みを一気に行うことで、毎回のパリティ計算を排除し、1回でまとめて処理を完了させています。

これらの新しい機構は、従来以上に IO デバイスとしての性能が格段に向上している NVMe ドライブをフルに使うためには CPU をもっと効率的に使うためにソフトウェアも大幅に進化した結果となります。

そもそも NVMe ドライブは従来の SCSI をベースとした SAS/SATA ドライブと異なり IO Queue、Queue Depth が格段に広がっている上に、各 NVMe ドライブが HBA・RAID カードに相当する IO Controller を内蔵しているので NVMe ドライブ自体が IO 処理時の CPU 負荷の削減にも寄与しています。

また、vSAN ESA に先行して、vSAN 7.0u2 からサポートされた RDMA (NVMe over Fabric : RoCE v2) に vSAN ネットワークは対応しており、高 IOPS を捌くために必要だった ESXi ホストの CPU を利用した TCP/IP 負荷を RDMA 対応の NIC にオフロードする事も可能になっています。

vSAN OSA 環境で先行して RDMA ネットワークを採用されたラクス様の VxRail での性能検証事例を前回ご紹介した vSphere / vSAN オンラインセミナー#55 何が変わった？待望のメジャーバージョン VMware vSAN 8 を解説! の後半にて解説しているので興味ある方はぜひ御覧ください。

vSAN OSA でも RDMA を有効化するだけで劇的に CPU 負担が下がり、TCP/IP の処理が無くなる事で IO の低遅延化が劇的に実現できたことが確認できましたので、vSAN ESA と RDMA を組み合わせたら更に強烈なストレージ環境が出来上がるのではないかと期待しています。
※ まだ VMware Japan 含めて検証環境で用意できていないので、もし vSAN ESA + RDMA 環境の PoC するよ、という方いらっしゃいましたらお誘いください(^^; ベンチマーク負荷テストのお手伝いさせていただきます♡

ということで、今日は如何にして ESXi ホストの CPU 負荷を下げ、効率的に NVMe の高い性能を引き出すか、という観点で最適化された vSAN ESA のパフォーマンスについてご紹介しました。

次回は vSAN ESA のサイジング(容量・オーバーヘッド)に関連してご紹介したいと思います。

今日のネタは昨年末に vExperts Advent Calendar 用のコンテンツとして作った Blog からいくつか vSAN ESA に関するサイジングの考え方をご紹介します。

元の記事は以下となります。

• vSAN データストアの容量サイジングの考え方 (vSAN 6.7 / vSAN 7.0 / vSAN 8.0)
  https://kwmtlog.blogspot.com/2022/12/vsan-capacity-consumption.html
  
  

サイジングツールのご紹介

上記の Blog 記事や vSphere / vSAN オンラインセミナー#55 VMware vSAN 8 Deep Dive !!! でも紹介していますが、vSAN Ready Node Sizer (以下 vSAN RN Sizer) が12月に vSAN ESA 対応版として刷新されました。

ざっくりサイジング、オーバーヘッドの確認は vSAN RN Sizer の Quick Sizer (Reverse Sizer) 機能で確認ができますので、まずは電卓代わりにこちらをご活用ください。

Quick Sizer の UI も以前と比べてだいぶ改善されて使いやすくなったと思います。

※ 宣伝

新しい vSAN RN Sizer の使い方について、2023年2月15日に Webinar を予定しています。
ご興味ある方は https://juku-jp.vmware.com/seminar/1387-online_230215/ からぜひご登録をお願いします。

ちなみに VxRail は VxRail 専用で VxRail Sizing Tool  がありますが、こちらも 2022年12月16日に vSAN ESA 対応したバージョンがリリースされており、構成作成途中でちゃんと選べる様になりました。

vSAN OSA / vSAN ESA のサイジング・オーバーヘッドの考え方

本題のサイジングに関して、こちら Blog にも記しましたが重要なポイントなのでこちらにもあらためて記します。

vSAN をサイジングする際に以前は空き容量 20% 〜 30% を考慮するスラックスペース (Slack Space) という考え方でした。

一部の公式ドキュメントにはこの記載が残っていて紛らわしいのですが、現在 (正確には vSAN 7.0u1 以降) はスラックスペースという考え方・用語は利用しておらず、より明確な言葉で vSphere Client からも確認できる様になっています。

それが以下の 操作の予約 : (Operations Reserve : OR)  と ホスト再構築の予約 : (Host Rebuild Reserve : HRR) です。

• 操作の予約 : (Operations Reserve : OR) - 必須
  vSAN のシステム用領域 (メタデータやポリシー変更などシステム処理で利用される領域) - 物理 (RAW) 容量の 10% が予約される
  
• ホスト再構築の予約 : (Host Rebuild Reserve : HRR) - 任意
  ESXi ホストが1台停止した場合でも仮想マシンデータが再構築 (リビルド) 出来る様に1 ESXi 分の容量を予め予約 - N 台の ESXi で構成された vSAN クラスタの場合は全体の 1/N の容量が予約される
  ※ 最小構成台数の vSAN (3台構成や 2Node vSAN) では HRR は設定できますが実際は意味がないので通常は無効とする
  
  

現在のバージョンの vSAN (VxRail を含む) は、必須のオーバーヘッドは全体の 10% の容量の OR と、任意のホスト障害時を考慮した HRR が仮想マシンのデータ保存用とは別に確保しておく容量のオーバーヘッドとなります。
ESXi ホスト台数によって HRR の容量は変わってきますので 4 台 〜 6台 の vSAN クラスタでは HRR 含めて 25% 〜 30% の空き容量、10台以上であれば 20% 以下の空き容量でカバーできる、そのくらいのざっくりサイジングで OK です。

※ 詳細は上記の Blog または公式の VMware vSAN Design Guide https://core.vmware.com/resource/vmware-vsan-design-guide 参照。

ご利用のシステムによっては 2〜3 ESXi ホストが停止した際にも容量を確保しておきたい、といった場合があります。
HRR は 1 ESXi ホスト障害を前提としたサイジングになりまので、そうした場合は任意の閾値でアラートを設定できますのでホスト台数に応じた数値を設定して運用で調整してください。

※ この新しい考え方だと vSAN の利用率が 80% を超える事があります。「vSAN の利用率が 80% を超えると強制リバランスが起きて良くないと聞いたんだけど？」と言った質問も今コミュニティや VMTN で頻繁に質問が上がるので Blog 側に回答を用意しておりますので参照願います。

• vSAN の利用率が 80% を超えると強制リバランスが起きて良くないと聞いたんだけど？

基本の容量オーバーヘッドの考え方は vSAN OAS / vSAN ESA ともに上記の OR と HRR を確保しておくことで同じですが、vSAN ESA  では若干の追加の考慮点があります。

ここで考慮する必要があるのが、各 NVMe ドライブに格納される vSAN ESA  のメタデータ・Performance-Leg・Capacity-Leg の領域の使われ方です。

詳細は VMware Core Tech Zone にて紹介されていますが、英語の記事なのでここではわかりやすい図でご説明します。

• Capacity Overheads for the ESA in vSAN 8
  https://core.vmware.com/blog/capacity-overheads-esa-vsan-8
  

先程の vSphere Client の UI で表示される OR・HRR の図で説明すると以下のようなオーバーヘッドの考慮が必要です。

上記図でお伝えしたい考慮ポイントはメタデータ = OR で 10% と HRR の 1/N ESXi ホスト分の容量の他、vSAN ESA のファイルシステム上のオーバーヘッド LFS オーバーヘッドが "書き込まれたデータ量の 13%" が必要となるということです。

"書き込まれたデータ量" なので圧縮後に NVMe ドライブに格納された容量がカウントされ、Performance-Leg のオーバーヘッドもこの中で考慮されています。

LFS オーバーヘッドの 13% が大きいようにも見えますが、全体としてはキャッシュ専用のドライブは不要であること、圧縮のアーキテクチャが大幅に改善されて圧縮率が上がっていることなど、全体としてのインパクトは薄まりますのでご安心を。

これら含めたサイジング時の考慮点、机上計算では考慮漏れが起きる可能性もありますので、 ぜひ最初にご紹介した vSAN / VxRail の Sizer を活用して、机上の計算をツールで確認する(その逆も)感じで適切なサイジングでリーズナブル & コストパフォーマンスの良い基盤導入につなげていただければと思います。

皆さん、

2週間にわたってエキスパートにてんこ盛りの情報を提供いただきました！おお！っという情報がいっぱいですよね！

さて、これからは貴方の番です。エキスパートにどんどん質問してエキスパートをてんてこ舞いさせてください。

本当は先週末にもう一本投稿しようとしていたのですが本業が期末対応でドタバタしていたので改めて vSAN 8.0 のアップデート、vSAN OSA でのキャッシュドライブの扱いの仕様変更についてご紹介します。

vSAN 8.0 OSA では従来の All Flash vSAN のキャッシュ層 SSD の内部的なアクティブ領域の上限 600GB の仕様が限定解除され、1.6TB まで拡大されました。

これが意味する事は、より大容量のキャッシュ層領域を確保することが可能で、大量の書込み処理を受け入れられる様になったことと、近年中容量の Mix Use クラスの SSD をキャッシュ層に利用するシーンが増えてきましたがその際により多くの有効領域を利用可能になるなど、メリットが多数あります。

※ 詳細は以下の VMware Core Tech Zone でも紹介されています。

• Increased Write Buffer Capacity for the vSAN 8 Original Storage Architecture
  https://core.vmware.com/blog/increased-write-buffer-capacity-vsan-8-original-storage-architecture
  

SSD の耐久性指標や性能、容量についてはちょうど先週末に質問スレッドが立っていたので以下スレにて情報共有しておりますので合わせてご確認ください。

• VXRAILに搭載するSSDの種類について
  
  
  

有効キャッシュ領域が増えた = 性能 UP 間違いない、というのが一般的な見方でそれはあっています。
であれば既存クラスタもさっそくラージキャッシュを有効化しよう！となりますが、ちょっと手順が必要なのと、その手順でディスクグループ再作成というデータ移行を伴う作業が発生するため、その手順をご紹介します。

VxRail の場合は Solve の手順書に沿って実施していただきますが、vSAN 側の KB と内容はほぼ同じなのでここでは vSAN をベースとした手順でご紹介します。

バッファ論理容量拡大の詳細手順は以下 KB を参照

• Support for large cache tier capacity (> 600GB, upto 1.6TB) in VSAN (89485)
  https://kb.vmware.com/s/article/89485

1. 各 ESXi にて以下コマンドを実行するか、UI の詳細設定で LSOM.enableLargeWb を "1"  に設定する

• 有効化 :    esxcfg-advcfg -s 1 /LSOM/enableLargeWb
• 設定確認 : esxcfg-advcfg -g /LSOM/enableLargeWb

※ デフォルトは "0" で無効状態

2. 有効後、ディスクグループの再構成を順に実施

この手順が裏でデータ移行がノード間で発生するのでガンガンに IO が発生している状況下で行うと、再構成に長時間を要する可能性があるので注意が必要です。

ディスクグループの再作成自体は ESXi ホストをメンテナンスモードに移行して、ディスクグループの設定画面から1つずつ「全データ移行 + 再作成」を実行していきます。

※ 全データ移行は ESXi ホストのメンテナンスモード投入時に実行するのでも大丈夫です。

クラスタ内のディスクグループを順々に実施して頂き、全台完了すれば完了です。

ちなみに VxRail 8.0 で新規導入時にラージキャッシュを有効化しておきたい場合も、LSOM.enableLargeWb を "1"  に設定する必要があり、クラスタに組み込む前の VxRail ホストに CLI で設定投入しておく必要があります(※詳細は Solve の手順書を参照)

既存環境はディスクグループ再作成必要なのか、、、と作業を躊躇されてしまうかもしれません。
そもそも論となりますが、このラージキャッシュの有効化は Must ではありません。

既存でキャッシュ層に WI SSD 800GB を利用している場合、600 GB がアクティブなキャッシュ層領域として活用されていますが、残りの 200 GB も SSD 全体をウェアレベリングのための領域として活用されていますので無駄にはなっていません。

※ ウェアレベリング = IO が SSD の全データ領域のセルに満遍なく書き込まれてセル寿命を均等に消費し SSD を長寿命化する機能

今現在、600GB のキャッシュ層アクティブ領域で性能問題がなく十分に低遅延で高い IO を捌けているのであれば、そのままの利用を推奨します。

逆にラージキャッシュを推奨したいシーンとしては、キャッシュ層に MU SSD 1600GB やそれ以上の大容量 SSD を利用している場合、より多くのキャッシュ層を確保する事で巨大な Write IO のスパイクも吸収することが出来るメリットにつながるので、
新規で中容量以上の MU SSD をキャッシュ層に採用する場合は有効化してそのメリットを享受するのが良いと考えております。

参考情報として、この年末年始の各バージョンのリリースに合わせて、久しぶりに日本語化されたドキュメントもいくつか公開されていたのでご紹介します。

• Dell VxRail 8.0.x 管理ガイド
• Dell VxRail 8.0.x リリース ノート
• Dell VxRail 7.0.x 管理ガイド
• Dell VxRail 7.0.x リリースノート

各種 VxRail に限らず Dell 製品のベストプラクティスや設計ガイドは Dell InfoHub にて公開されているので、vCenter 設計ガイドや Network 設計ガイドは以下を参照

• Dell Technologies Info Hub > VxRail

それぞれサポートサイトへのログイン無しで閲覧できますが、日本語版は更新が古い場合があるので最新情報は英語版をサポートサイトでチェックする事をお奨めします。

※ VxRail 7.0 の管理ガイドは以前公開された版ですが、せっかくなので併せてリンクを置いておきます。

いつもお世話になっております。

VxRail 8.0のご説明ありがとうございます。
まだ理解が完全に追いついていないところももあり、
ご質問＆ご確認させていただきたく
よろしくお願いいたします。

■vSAN ESAについて
・vSAN ESAの内部的な流れについて、
まとめますと以下の理解でよいでしょうか？

1.仮想マシンからIOが来ると、仮想マシンが
搭載されているESXiホスト上で、
圧縮→圧縮データを暗号化→チェックサム計算を
行う(データサービス層)

2.圧縮や暗号化、チェックサム計算を行った
データをRAIDレベルに応じて、そのESXIホストと
別のESXiホストのとあるNVMe SSDの
Pwerformance leg領域に書き込み。(FTT1、RAID5は
計2台のホストに書き込み、RAID6は計3台のホストに
書き込み)この時点でホストヘはAckを返す。

3.ある程度NVMe SSDのPwerformance leg領域に
書き込みがたまった段階でRAIDレベルに応じて、
各ESXiのNVMe SSDのCapacity leg領域に書き込み。

・1台のNVMe SSDのどの領域をPwerformance legで
使用してどの領域をCapacity legとして使用するかは
vSANソフトウェアが論理的に制御している、
という理解でよいでしょうか？
その場合SSDのPwerformance leg領域に割り当てられる
容量はいくつでしょうか？

・ESAではRAID5やRAID6でも従来のFTT1(RAID1)と
同じレベルのパフォーマンスがでるような記載が
ありましたが、そういう意味であればESAではもう
FTT1を使うメリットはない理解でよいでしょうか？
あえてFTT1をつかうメリットがあればご教示ください。

・各RAID構成ごとの最低台数につきまして、
RAID5(2+1)はホスト3～5台、RAID5(4+1)はホスト6台以上、
RAID6(4+2)はホスト7台以上との理解ですが正しいでしょうか？

また、RAID5やRAID6のストライブ幅は上記固定で、例えば
RAID5(3+1)といった構成や、ホスト6台以上でRAID5(2+1)と
いった構成はできないのでしょうか？

・ESAのクラスタでもホスト間でメモリの容量が
違っていたりCPUが違っていたりNVMe SSDの本数が
違っていたりとアンバランスな構成でもサポートは
されるのでしょうか？
(もちろんクラスタ内は全て同一構成が推奨なのは
理解しております)

・ESAのクラスタで、1台のホストで障害が発生した
ときは、OSAと同じ動きでよいでしょうか？
(4ノード以上であれば60分待機した後にリシンク。
3ノード構成であればリシンクは起こらない)

■vSAN OSAについて
All FlashモデルのCache SSDがディスクグループ
あたり1.6TBまで使用できるようになったようですが、
これに伴いHybridモデルのようにraw容量の10%以上の
搭載が推奨などの基準はできたりするのでしょうか？

質問が多くて恐縮ですが、よろしくお願いいたします。