ad1

2024年4月26日金曜日

VMware by Broadcom サブスクリプションライセンスのカウント方法と注意点

2023年11月に VMware が Broadcom に買収され、ライセンスが大幅に変更となっています。

年末からここ数ヶ月で多数のアップデートが入ったことでネット上の情報を見ているといくつか古いまま情報もありますので、公式情報を元に確認できているライセンスの「考え方」や「カウント方法」をまとめます。

※ 本投稿では vSphere Foundation (VVF) と Cloud Foundation (VCF) のコアライセンスについてまとめていますが、その他の Add-on ライセンスについては別途整理する予定です。

Broadcom の会社として変更となるライセンスに関する背景や方針は以下の公式 Blog にて説明されているのでこちらを参照願います。

色々と変更となる点で皆様思うところはあるかと思いますが、価格・販売に関しては担当営業の方、またはパートナー様にお問い合わせください。

※ 記事内のいくつかの VMware 公式サイトリンクは 5/6 以降に新しい Broadcom 側のシステムに切り替わりが予定されております。5/6 以降で判明した新しいリンクへは順次変更をかける予定ですのでリンク切れの際はご容赦ください。

以下、長文なので見出しへのリンクを追加しておきます。

従来の VMware ライセンスと新しい VMware by Broadcom ライセンスの違い
今後のシングルライセンスキー(ソリューションキー)について
適切なライセンス数サイジングのためにアセスメントの活用

従来の VMware ライセンスと新しい VMware by Broadcom ライセンスの違い

従来の永続ライセンス (Perpetual License) と vSphere+ や VCF+ などの従来のサブスクリプションと、新しい VMware by Broadcom のサブスクリプションライセンスは似ている部分と全く異なる部分があります。

従来のライセンスは全て販売終了となり、今後は新しい VMware by Broadcom としてのライセンス (vSphere Foundation や Cloud Foundation など)に切り替わります。

新旧ライセンスのざっくりした比較

ライセンス単位

新しいライセンスの一番の違いとして、従来は CPU 単位 (1CPU 辺り 32 コア単位) に1ライセンスでカウントしていたものが、サーバーに搭載される物理 CPU が持つ物理コア数によりライセンスがカウントされます。

このコア単位ライセンスは 1 CPU あたり最小 16 コアが必要となります。

サポート・アップグレード権 (Support & Subscription : SnS)

従来は製品ライセンス (永続ライセンス)と、有期のサポート・サブスクリプション (SnS) が別売りされており、サポートを受ける場合や製品利用中にアップグレードをする場合などは有効な SnS が製品ライセンスと紐づいている必要がありました。

新しいライセンスはサブスクリプション方式となり、製品ライセンスとサポートがセットになったサブスクリプションライセンスで提供されます。

また、従来と同じくアップグレード権と同じく、サポートされる下位バージョンへのダウングレード権も有効なサブスクリプションを保持している場合は提供されます。

新しいサブスクリプションライセンスは従来通り "ライセンスキー"を使用

2022年から2023年の短い期間でしたが、従来製品群でも VMware はラブスクリプションライセンスを提供しており、vSphere+ や VCF+ などインターネットに接続して VMware がサービスとして提供する Cloud Console (クラウドコンソール) でライセンスの管理、払い出しを行う仕組みもありました。

この vSphere+ や VCF+ ではライセンスキーを利用しないキーレスサブスクリプションとして提供されていましたが、今回の新しいサブスクリプションは従来の永続ライセンスと同様にライセンスキーを利用します。

若干の違いとして従来のライセンスキーと若干異なる仕組み "ソリューションキー" があり、プロダクトごとに様々なライセンスキーを用意するのではなく、シンプルに1つのキーで VMware 基盤を管理するように変わっていきます。これについては後述します。

2024年4月現在、従来の永続ライセンスと同様に Customer Portal でライセンスの払い出しやサポートされる過去バージョンへのダウングレードなどもサポートされています。

※ 私自身の Customer Connect アカウントに紐づく新ライセンスを持ってないので実際の操作はまだ体験できず...

ただし、従来の永続ライセンスとはカウント方法含めた仕組みが異なるため、既存クラスタへのホスト追加時に Customer Connect におけるライセンスキーのマージ操作などは行えないので注意が必要です。

既存クラスタ (永続ライセンス利用) 環境へのホスト追加 (新サブスクリプション適用)時の条件・考慮点は別途公開資料が用意された時点でそれに基づき後述します。

インターネット接続要件

以前提供されていた vSphere+ や VCF+ ではライセンスの払い出し・管理のためにインターネット接続が必須要件でしたが新しいサブスクリプションは従来の永続ライセンスと同じくライセンスキーを利用するため、ライセンス認証にインターネットへの接続要件は2024年4月時点ではありません。

代表的な製品例

従来の vSphere / vCenter / vSAN / NSX / Aria の個別製品毎に別の製品型番やエディションが無数に存在していたライセンス体系から、VMware vSphere Foundation (VVF)、VMware Cloud Foundation (VCF) などを軸としたライセンス体系に大きく変更されています。

小規模環境向けには vSphere Essential Plus や vSphere Standard もサブスクリプションライセンスで提供されますが、エンタープライズ企業での利用は基本的に上記 VCF または VVF と Add-on ラインセンスになります。

パッケージングは Broadcom (VMware) の William Lam さんの Blog にまとまっているので参照願います。

新しいライセンスのルールが知りたいときに参照するドキュメント

公式情報は VMware Product Guide に各製品ごとに記載されています (本投稿時は 2024年2月版)。

本投稿後半のライセンスのルールの詳細はこの Product Guide とその他 KB や公式 Blog やリリースノートに沿って説明します。

その他、契約関連の公式情報は以下も参照願います。 ※ EULA は 2024年4月時点では旧 VMware の内容のままですが、5月以降に恐らく更新されるとは思います。

Broadcom パートナーポータルにもライセンス関連のガイド、FAQ がアップされているのでアクセス可能なパートナーの方は参照願います。

アップロードされている資料のうち、VMware Cloud Foundation & vSphere Foundation Pricing and Packaging Overview、及び VCF Pricing and Packaging FAQ にライセンスに関する情報がまとまっています。

新しいコアライセンスのカウント方法・カウント対象

VVF / VCF のライセンスに必要となるコア数のカウント方法は以下2つの KB にて説明されており、既存環境のライセンス更新であれば vCenter に対して KB 95927 添付の PowerShell スクリプトを実行することで確実に必要ライセンス数をカウントすることが可能です。

また、新規環境を前提としている場合、KB 92426 添付の PowerShell スクリプトにクラスタを構成するハードウェア情報を記した CSV を読み込むことで必要なライセンス数を出力する事が可能です。

以下は KB に準拠してカウント方法とカウント対象を説明します。

コアライセンスは CPU に搭載された「物理コア数」に対してカウントされ、物理 CPU 1つに対して最小 16コアのサブスクリプションライセンスキーが消費されます。

例えば 1CPU 12コアの CPU を搭載したサーバーに ESXi をインストールしてライセンスを適用すると 16コア分のライセンスが消費されます。

その代わり、従来の永続ライセンスでは 1CPU ライセンス 32コアまでの制約があり、例えば 36コアや 48コアの CPU では 2 CPU ライセンスを消費していましたが、サブスクリプションライセンスでは物理コア数分を適用します。


コア数のカウントは「物理コア」に対して行うため、BIOS/UEFI でコアを無効化にしたり、Intel SST-PP のように CPU のプロファイルごとに有効なコア数と動作周波数の組み合わせを設定できる機能がありますが、設定上無効にした場合であってもライセンスは物理 CPU が搭載する物理コアに対して必要となるのでご注意願います。

※ ただしシステム上は BIOS/UEFI で無効化したコアを現時点の vSphere は認識できないためライセンスの消費はアクティブなコアのみでカウントされますので、vCenter や VCF のライセンス管理画面上、ライセンスが「余っているように見えてしまう」可能性があるのでご注意ください。

これらの説明は KB 95927 及び Product Guide に記載されています。

2024年4月版 Product Guide の VMware Cloud Foundation Division Products >  vSphere Foundation 及び VMware Cloud Foundation の General License Notes ↓

Customer must purchase at least 16 Core licenses for each Processor on which Customer runs the Software. All Physical Cores on the Processor must be licensed, subject to a minimum of 16 Core licenses per physical Processor. 

2024年2月14日更新の KB 95927 記載の注意書き↓

VCF and VMware vSphere Foundation require core licenses for all physical CPU cores on each CPU running the software. In the event users disable physical CPU cores in the BIOS settings or other means, the script may produce inaccurate results. As such, all physical CPU cores should be activated on each CPU when running the script.

VVF / VCF ライセンスに含まれる vCenter の扱い

新しいサブスクリプションライセンスには 1 コアライセンスあたり 1 vCenter インスタンスを利用する権利が付属しています。その代わり従来は別売りだった vCenter ライセンスは SnS とともに販売終了となりました。

ここで問題となるのが、既存の永続ライセンス環境で利用していた vCenter の SnS が終了してしまったらサポートはどうなるのか？ということですが、
新しいサブスクリプションはそれぞれ従来の vSphere 環境や VCF 環境の拡張・更新に利用可能で、サブスクリプションに含まれる vCenter ライセンスキーを既存の永続ライセンスの  vCenter ライセンスの更新に利用したり、新規に展開したサブスクリプション vCenter 配下に有効な SnS を持つ永続ライセンスの vSphere ESXi を展開することがサポートされます。

詳細は Product Guide に記載されています。

2024年4月版 Product Guide の VMware Cloud Foundation Division Products >  vSphere Foundation 及び VMware Cloud Foundation の vCenter Server に関する記載 ↓

  • vSphere Foundation の vCenter Server に関する記載


VMware vCenter Server. Customers are entitled to VMware vCenter Standard solely for management of this VMware vSphere Foundation license or any perpetual license that holds an active subscription to VMware Support and Subscription Services. 

  • Cloud Foundation の vCenter Server に関する記載


VMware vCenter Server. Customer is entitled to VMware vCenter Standard solely for management of this VMware Cloud Foundation license or any perpetual license that holds an active subscription to VMware Support and Subscription Services. 

ただし、注意が必要なのはそれぞれのサブスクリプションに含まれる vCenter Server で管理できるのは VVF の vCenter なら VVF か有効な SnS を持つ永続ライセンスの vSphere、VCF の vCenter なら VCF か有効な SnS を持つ永続ライセンスの VCF 環境と記載されていることです。

つまり、VVF と VCF ライセンスを同一 vCenter 環境内で混在利用することは (技術的には可能だが) 不可ということです。

SDDC Manager を用いて展開した VCF のインスタンスの中に VVF ライセンスでクラスタを組み込むのは当然不可ですが、SDDC Manager を利用せず、手組で vCenter を展開してクラスタを組む従来の方法の場合は混在が出来そうなものですが、新しいサブスクリプションではライセンスの制約として不可とされているようです。

これは今後のシングルライセンスキー (ソリューションキー) での運用とも関連するので後述します。

VVF / VCF ライセンスキーの適用可能範囲

vSphere Foundation (VVF) は vSphere Enterprise Plus、vCenter、Aria Suite Standard (Aria  Operations と Aria Operations for Logs) が含まれ、
Cloud Foundation (VCF) は vSphere Enterprise Plus、vCenter、vSAN TiB (vSAN Enterprise)、NSX、Aria Suite Enterprise (全ての Aria 機能) が含まれます。


それぞれ今後はシングルライセンスキー (ソリューションキー)で提供されますが、後方互換のためにそれぞれバラバラのライセンスキーで払い出すこと(ライセンスのダウングレード権含む)も現時点で可能です。

そのため1つの VVF / VCF ライセンスに含まれる製品ライセンスキーを別の環境にバラして使うこはサポート上不可となります。

1つのサブスクリプションライセンスに含まれる各機能・ライセンスは同一のインスタンス内 (同一 SDDC Manager 配下、または同一 vCenter 配下)で利用する必要があるのでご注意ください。

vSAN TiB のカウント方法

従来の Perpetual vSAN ライセンスは CPU 単位、vSAN+ などの旧サブスクリプションでは CPU コア単位でカウントされていましたが、新サブスクリプションでは VVF / VCF に Add-on する TiB 単位の容量ライセンスとなります。

容量の対象となるのはキャパシティ層ドライブの合計値で、vSAN OSA の場合はキャッシュ層ドライブの容量はライセンス対象外です。

VCF に含まれる vSAN TiB と vSAN TiB Add-on ライセンスのカウント方法

VCF には 1 コアライセンスあたり 1 TiB の vSAN 容量ライセンスが含まれます。
例えば 16 コア CPU を 2 基搭載する物理サーバーであれば 32 コアの VCF ライセンスを適用し、vSAN も 32 TiB が利用可能です。

足りない容量分は vSAN TiB Add-on で追加が可能です。

VCF ライセンス利用時に1台の vSAN ノードに搭載されたドライブ容量で vSAN TiB 容量が余る場合は、SDDC Manager インスタンス内や vCenter インスタンス内の別のドメイン、別のクラスタに vSAN TiB ライセンスを集約して利用する事が可能です (vSAN Max や vSAN Disaggregation での利用)。

※ 一つ前の項で書いたように、VCF サブスクリプションに含まれるライセンスをバラして別環境で利用する事はサポートされず、vSAN TiB に関しても全く異なる環境の別 VCF インスタンスに余った vSAN TiB ライセンスだけの流用、別の VVF クラスタに VCF に含まれる vSAN TiB ライセンスの流用は不可です。

TiB と TB の違いについて

HDD や SSD の容量の表記はメーカーが利用する容量の単位 (GB や TB) と、実際にコンピュータが認識する単位 (GiB や TiB)で違いがあります。

メーカー表記は SI 接頭辞(10のべき乗)で乗数 1000 毎に KB、MB、GB、TB、PB と単位が上がりますが、
コンピュータは2進数(2のべき乗)で 1024 (2の10乗)毎に KiB、MiB、GiB、TiB、PiB と単位が上がります。
※ 詳細は Wikipedia : 2進接頭辞 参照

例えば 1.92 TB (1,920,000,000,000 Byte)と仕様に書かれた SSD の場合、実際にコンピュータが認識するのは 1.746 TiB (1.92 * 1024^4) となり、
TB → TiB の変換で約 9％ ほど少ない値となります。

クラスタの vSAN 容量をざっくり計算する際には以下で計算します。

  • キャパシティドライブ TB 容量 x 本数 x サーバー台数 x 0.909 = 合計 TiB 容量

ただし、vSphere はもちろん Windows などでも画面上の UI で GiB や TiB と表示されることはほぼなく、画面上は GB や TB の単位のまま表示されるため

「64GB の SD カードをパソコンでフォーマットしたら 59.6 GB と表示される！容量詐欺だ」

という IT に詳しくない方が陥るトラップがあるのでご注意ください。

以下は実際の vSphere Client の UI で vSAN で利用している SSD を 372.53 GB や 3.49 TB と表示していますが、実際の物理 SSD の容量は 400 GB と 3.84 TB の SSD が搭載されており、本来の表記単位はそれぞれ 372.53 GiB や 3.49 TiB が正しい単位です。


実際に必要となる容量を実機環境を元に調べる場合は KB 95927 や KB 96426 に含まれる PowerShell スクリプトで確認することが可能です。

また、vSAN ReadyNode Sizer <https://vsansizer.esp.vmware.com/> ではサイジング時の容量を TB 表記と TiB 表記を切替える事が可能です。

以下の画面の様に右上の TB | TiB 切り替えを行うことで、容量の前提となる Raw Capacity に必要となる容量が表示されますので確実なサイジングが行えます。

既存 vSAN クラスタから KB 95927 添付の PowerShell モジュールで必要ライセンスを確認してみる

KB 95927 に添付ファイルとしてアップロードされている PowerShell モジュールを利用して既存環境のライセンス更新時に必要となるライセンス数を簡単に確認できます。

手順は KB に記載されていますが、Import-Module で FoundationCoreAndTiBUsage.psm1を取り込み、オプションを付けて Get-FoundationCoreAndTiBUsage を実行するだけです。

以下の例では、かなり古い Xeon E5-2620 v3 (6コア) CPU を 2 基搭載し、 3.84 TB (3.49 TiB) の SSD を 2 本ずつ搭載した ESXi ホストが4台あるクラスタの例です。

単純計算では、CPU あたり最小 16 コアライセンスが必要なので合計 8 CPU で 128 コアライセンス、3.84 TB x 2 本 x 4 ESXi = 30.72 TiB = 27.92 TiB = 28 TiB ライセンス が必要となります。

オプションに VCF を指定した場合


クラスタで利用している vSAN RAW 容量が少ないので VCF に含まれる vSAN TiB ライセンスだけでお釣りが出るので、-100 TiB と表示されています。

オプションに VVF を指定した場合


vSAN クラスタの RAW 容量を満たす必要容量分の vSAN TiB Add-on のライセンス数が表示されます。

VCF の場合も VVF の場合もざっくり計算した結果と同じ数値が出力されているので正しいことが分かります。

VVF に付属する 100GiB のトライアルライセンスの使い方

vSphere Foundation は vSphere 8.0u2b 以降で 1 コアあたり 100 GiB のトライアル vSAN 容量ライセンスが含まれます。

VVF は 1 CPU あたり最小 16 コアが必要となるので、100 GiB x 16 ≒ 1.6 TiB が利用可能です (GiB → TiB で単位が変わるので厳密には 1.563 TiB)。

この容量設定の根拠は恐らくですが、vSAN ESA Ready Node Profile の最小構成である ESA-AF-0 が 1CPU (16コア) 、1.6TB SSD 1本の最小構成で設定されており、

PoC 用途などで最小構成の機器を利用する際に

  • 1CPU (16コア) 構成であれば 1.6 TB の SSD 1本
  • 2CPU (32コア) 構成であれば 1.6 TB の SSD 2本

の最小構成環境では VVF のライセンスに含まれる 100GiB トライアル vSAN ライセンスのみで vSAN ESA を組める前提の容量として設定されたのだと思われます。

※ このライセンスはあくまでもトライアル用ということで追加の vSAN TiB Add-on ライセンスとの併用は出来ません。また、VCF に含まれる vSAN TiB と異なり、別のクラスタに余った 100GiB 容量を集約して利用する事も不可です。

サブスクリプション コアライセンスのダウングレードと既存クラスタの拡張について

新しいサブスクリプションで提供されるソリューションキーは、及び vSAN TiB は vSphere 8.0u2b、VCF 5.1.1 以降でサポートされ、以前のバージョン (8.0u2b 未満、7.0.x、6.7.x ) で利用する場合はライセンスキーを Customer Connect でダウングレードします。

この際、コアライセンス、及び TiB ライセンスはそのまま CPU ライセンスに変換されます。

  • 16 コアライセンス → 16 CPU 分 vSphere ライセンス
  • 16 TiB ライセンス → 16 CPU 分 vSAN ライセンス

上記のように変換されるため大幅に数量が増えて払い出されてしまいますので、利用時は本来購入した数量前提で利用していただく必要があります。あくまでも新規サブスクリプションは対象ハードウェアの CPU コア数と vSAN TiB RAW 容量が前提となるためこれを超えた利用はライセンス違反となるのでご注意ください。

※ vSphere 6.x へのダウングレードも 2024年4月で可能ですが、既に開発・サポートが終了していますので新しいサブスクリプションライセンスを適用した場合でも通常サポートは受けられません (別途延長サポート契約が必要)。

既存永続ライセンスキーとダウングレードしたサブスクリプションライセンスキーの結合は不可

ライセンスキーは適用するクラスタの CPU 数などに応じて複数のキーを結合したり、分割することが従来から可能で、これは新しいサブスクリプションキー (ソリューションキー、コンポーネントキー) でもサポートされます。

ただし、従来の CPU 単位の永続ライセンスと、新しいコア単位 または TiB 単位のサブスクリプションキーをダウングレードして生成された CPU 単位のライセンスキーを結合することは出来ません。


既存永続ライセンスが適用されたクラスタの拡張にダウングレードしたサブスクリプションキーを利用する

1つ前の図のように、新しいサブスクリプションキーと既存の永続ライセンスキーが結合出来ない場合、vSAN ライセンスのようにクラスタに対して1つのキーしか割り当てられない仕組みの場合は拡張出来ないんじゃないか？という声が多くありました。

当初は既存の永続ライセンスのクラスタ拡張は新しいサブスクリプションでは行えない、という非常に問題のある状態だったのですが、2024年3月時点でこの条件が緩和され、

「既存拡張対象クラスタの永続ライセンス(vSphere / vSAN / VCF) の SnS が有効期限内の場合はダウングレードしたライセンスキーで環境全体のキーの切り替えが可能」

となりました。条件としては以下の2つとなります。

  • 追加ホスト分のコアライセンス、または vSAN Add-on ライセンスをそれぞれ CPU ライセンスに変換 (ダウングレード) した際の「合計 CPU ライセンス数」がクラスタ全体の CPU 数を超えている事
  • 既存の永続ライセンスが有効な SnS を保持している事 (SnS 終了後はサブスクリプションで更新)

下の例では既存 4 ホストの vSAN クラスタに 2 ホストを追加拡張したい場合に、2ホスト分のサブスクリプションをダウングレードすることでサポートされる拡張が可能です。


クラスタ拡張後のイメージは以下の様になります。

既存のホスト分に割り当てられていた SnS が有効な永続ライセンスキーをダウングレードしたライセンスキーで置き換える形を取ります。


※ vSphere ESXi 自体はライセンスキーをマージせずに追加ホストにのみにダウングレードしたサブスクリプションキー (CPU) を割り当てる事も可能ですが、上図では分かりやすく vSphere と vSAN をダウングレードしたサブスクリプションキーをあてたイメージにしています。

この拡張方法は VCF もサポートされ、既存ワークロードドメインのクラスタを拡張するときなどにダウングレードしたライセンスの CPU 数が既存と追加分をカバーできる際には置き換えが可能です。

この置き換えは、既存環境のエディションが VCF Standard や Advanced など下位の場合でも、新しい VCF サブスクリプションが Enterprise 相当のエディションに該当しますが Enterprise 相当の新しい VCF ライセンスをダウングレードしたキーを利用することが可能です。※ ただし、既存の下位エディションがサポートする機能までの利用が可能な紳士協定となるようです。

これらダウングレードライセンスを利用した拡張サポートなど、条件が多岐にわたる為、詳細情報は公式サイトの情報を参照していただく必要がありますが、2024年4月時点ではパートナー向けのパートナーポータル <https://partnerportal.broadcom.com/group/partner-portal/vmware>  で資料公開 (VMware Cloud Foundation & vSphere Foundation Pricing and Packaging Overview, 及び VCF Pricing and Packaging FAQ) されていますので、アクセス権のあるパートナーの方はご確認願います。

今後のシングルライセンスキー(ソリューションキー)について

新しいサブスクリプションライセンスキーに対応した vSphere 8.0u2b 及び VCF 5.1.1 以降では、従来の様な各プロダクト毎 (vCenter、ESXi、Aria、NSX) にライセンスキーを適用する方法から、1つのライセンスキー (ソリューションキー)を vCenter や SDDC Manager に登録すると配下のコンポーネントにライセンスが等しく適用される方式が利用可能になります。

※ vSAN のみコアカウントではなく TiB 容量ライセンスなので別ライセンスキーを適用します。


上記公式ブログのイメージ図にあるように、ソリューションキーを vCenter に適用するとそのキーが VVF なのか VCF なのかをキーに含まれる属性で判断し、そのライセンスに含まれるコンポーネントをライセンスをアクティブにします。

※ この仕組みが上記で説明した VVF と VCF のライセンスキーを同一インスタンスの中に混在が出来ない事の背景になると考えられます。

グリーンフィールド展開 (新規環境へのライセンス適用) 、及びブラウンフィールド展開(既存環境へのライセンス適用) ともに詳細な手順は上記 KB 97303 にて解説されています。

また、2024年4月時点では英語版のみですが、公式ドキュメントページにもソリューションキーの扱いについて説明がされています。

vSphere Foundation (VVF) におけるキーの扱いについて

Cloud Foundation (VCF) におけるキーの扱い

適切なライセンス数サイジングのためにアセスメントの活用

従来は様々なプロダクトごとに Standard < Advanced < Enterprise などのエディションがあり無数の組み合わせが可能でしたが、基本的に今後は従来の最上位 (Enterprise / Enterprise Plus) 相当の機能レベルの製品が1つの基盤 (Foundation) 製品として提供される形態となります。

下位エディションを利用していた環境や、単一製品のみを利用していた環境ではライセンス価格が値上りとなる場合があるかと思います。

価格については営業担当者やパートナー様と調整していただくしか無いのですが、今後はライセンス数が基本は物理コア数単位 (vSAN は TiB 容量単位) となるため、大きすぎる CPU コアや利用しないストレージ容量がライセンスコストを増やす要因になることがあるかと思います。

その際は既存環境に対するアセスメントを実施することで本当に必要なリソース量を正しく把握し、適切なハードウェア構成に適切ライセンス数を組み合わせて利用が可能となります。

アセスメントについては私は無償で利用可能な Live Optics を頻繁に利用しており、昨年以下の記事にもアセスメントで把握可能な様々な事項をまとめて紹介していますので参考にしていただければ幸いです。

多くの環境でほとんど CPU が使われていないのに多いコア数を搭載した上位 CPU を利用ししたり、予備機扱いのホストがクラスタに存在したり、活用しきれていないリソースが多くの環境で見受けられます。適切なサイジングをアセスメントを通して実施していただくことでライセンスコストもリーズナブルなものになるはずです。

特に、VVF / VCF では vSphere Enterprise Plus 相当以上となるため DRS など負荷分散機能が標準で活用可能です。ハードウェアの無駄を省き、ソフトウェアで制御された自動運用を導入することで基盤の運用コストを適切に下げられる効果も見込めます。


以上、雑多に書き出してみましたが 2024/5/6 に予定される Day 2 システム切り替え後に新しく判明した URL、Knowledge を適宜差し込み更新していきます。

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

0 件のコメント:

コメントを投稿

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

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