ad1

2020年12月7日月曜日

新しくなった VMware Tools のサポートポリシーとダウンロード方法

※ 本投稿は先日の "vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版"  から VMware Tools の項を抜粋しております。

VMware Tools のサポート状況の確認方法

従来は vSphere ESXi や Workstation などにバンドルされる VMware Tools のバージョンを利用して、母艦のサポートライフサイクルに合わせて運用される事が多かったと思いますが、
2020年11月より VMware Tools 自体も VMware Product LifeCycle Matrix に明確にサポート期間が掲載されるようになりました。
可能な限りサポート期間中のバージョンで運用しましょう。
2020年12月時点ではバージョン 10.1.x 以降が General Support となります。

サポートされるバージョンの VMware Tools の入手

現在は ESXi に Bundle される前のより新しいバージョンの VMware Tools もどんどん My VMware で提供されています。
それらは以下の URL からリリースノートの情報含めて入手可能なので必要に応じて入手してください。
My VMware からは各ゲスト OS 用のバイナリの他に、ESXi にバンドルされる VMware Tools を更新するための VIB ファイルも用意されています。
Update Manager や LifeCycle Manager を利用する or ESXCLI で ESXi に含まれる VMware Tools を更新する事が可能です。

VMware Tools の公式ドキュメント

公式ドキュメントとして、2020年12月現在 以下の URL にて Ver 10.x 以降のリリースノート、ユーザーガイドが公開されています。

VMware Tools のその他のバイナリ入手先

各バージョンの ESXi に Bundle される VMware Tools は My VMware 以外にも以下のリポジトリからも入手可能です。
それぞれのパッケージがどの vSphere ESXi に対応しているのか、Build 番号含めて確認が以下のリストで可能です。


2020年12月6日日曜日

vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版

 ここ数年、様々なお客様環境のアセスメントを実施して、現状の課題と改善案を説明してきた中で vSphere 仮想化基盤のサイジングに関する考慮点や、性能を最大限かつ安定的に発揮する構成、設計についてディスカッションする機会が多くありました。

vSphere のベストプラクティスを挙げていくとキリがありませんが、それらの中で特にサーバーやストレージの物理のデザインにも関連した内容で頻繁に紹介してきたもの集めてみました。(本投稿の内容は基本的に公式のガイドに沿ったデザインの内容ですが、一部個人の経験に基づく内容もありますのでご了承ください)。

※ 本投稿は vExperts Advent Calendar 2020 の 12/6 分を担当しております。
非常に長文ですが、オンプレミス環境の vSphere クラスタデザインの参考にしていただければ幸いです。

    vSphere クラスタ 鉄板構成のための Tips

    個人的にインフラをデザインする上で重要なのは「バランス」「N+1 の余裕」「100% 使い切らない」「定期的なメンテナンス(パッチ当て)が出来る」だと思っています。
    vSphere 4.x が出た 2010 年頃はいろいろとサイジングの Tips などセミナーなどで情報をよく見掛けましたが、最近は当たり前になってしまった面もあり見掛ける機会が少ない気もします。
    あたらめて今公開されている情報から Tips をご紹介します。

    vSphere パフォーマンスベストプラクティス

    vSphere の設計をする上で必読と言ってよいドキュメントです。
    パフォーマンスを最大限に発揮するためのドキュメントは以前より以下の様なホワイトペーパーが公開されており、vSphere / Storage / Network 様々な観点の推奨がされています。


    基本はこれらに沿っていただくのがベストですが、英語で情報量が多いのでポイントを絞ってご紹介します。
    ※ 4つ目の CPU Scheduler のドキュメントは少し古いものですが、ESXi ホストと VM の CPU の使われ方についての詳細が解説されております。内容はこの後解説します。

    ESXi ホストの設定(BIOS・ESXi パフォーマンス設定)

    サーバーの BIOS 設定に関しては各サーバーメーカーが vSphere 用のガイドを出している事が多いのでそれを準拠していただきますが、
    基本は「ハードウェアアシスト機能は全て有効化」「Hyper Threading / Turbo Boost は有効化」「パワーマネージメントは OS 制御」で揃えます。
    ESXi ホスト間でこの BIOS 設定が揃っていないとクラスタに組み込めなかったり(EVC 設定が揃わず)、ホスト毎の VM 性能が異なってしまうなどのリスクが生じます。

    ハードウェアアシスト機能は BIOS 設定で有効にする

    • Intel VT-x や AMD-V などの CPU 仮想化機能
    • Intel EPT や AMD RVI などの MMU 仮想化機能
    • Intel VT-d や VMD IOMMU などのデバイスパススルー機能

    Hyper Threading、Turbo Boost も BIOS 設定で有効にする事が推奨

    • ESXi・VMkernel は Hyper Threading に最適化されて CPU をスケジューリングされ、実際に処理性能も数10%以上向上
    • VM に割り当てた vCPU へのリソース割り当ても論理 CPU が多いほど柔軟で優位
    • Turbo Boost、C1E、C-States の設定も BIOS 設定で有効化する(制御は ESXi 側で実施)
    この様な設定含めて、さらには各ホストのリソースはなるべく均等に配置され、ESXi ホスト間で極端なアンバランスがない事が推奨されます。
    メモリの枚数、配置や PCIe 拡張スロットの配置など、各物理 CPU をバランスよく利用できる構成が重要です。


    ※ 近年の Side-Channel アタックなどの脆弱性に対する考慮事項、ガイドラインも パフォーマンスベストプラクティスに詳細が記載されておりますので、各バージョンにおける考慮事項の確認をお勧めします。

    BIOS のパワーマネージメントの設定は OS 制御が推奨

    • ESXi 側からのパワー制御の機能を利用するためには BIOS 側で「OS Controlled Mode」に相当する設定、C1E、C-States を有効に設定し、ESXi 側の電源管理を「バランシング済み」に設定する事で省電力機能を有効利用できます
    • 遅延にセンシティブなシステムの場合は、BIOS 側でパワー制御を「High Performance」、C1E、C-States を無効化する、または ESXi 側の電源管理を「高パフォーマンス」にする事で、C1E、C-States などを利用しなくなり、ハードウェア性能を安定提供します(その場合は Turbo Boost は動作しない)
    パワーマネージメントは BIOS と ESXi の双方の設定を合わせる事が推奨されますので、導入時に必ず BIOS 側の設定も確認してください。

    想定している性能が出ない、省電力が働かないという際にはこれらの見直しが必須です。

    使わないハードウェアは取り外すか BIOS 側で無効化する

    • 使う予定のない DVD-ROM、COMポート、未使用 NIC、未使用 HBA/RAID カード、不要な USB コントローラ等のデバイスは取り外す、または BIOS から無効化します
      不要な制御を無くすことでメモリを解放し、セキュリティと性能の向上につながります(微小ですが)
    • 自宅ラボに NUC などを利用して検証用の仮想化基盤を作る際も、Wifi や Bluetooth、Micro-SD スロットなど ESXi では利用しないデバイスは BIOS から無効にします

    VM の設定、サイジングの考慮

    VM に割り当てる vCPU、vRAM、vDisk の設定・サイジングにもいくつかポイントがあります。
    パフォーマンスベストプラクティスの中から汎用的に適用できる CPU やメモリの考え方を中心にご紹介します。

    VM に割り当てる仮想ハードウェアは最小限に

    既定の設定で VM を作成すると仮想フロッピードライブ、仮想 USB コントローラ、仮想シリアルポートなど、VM として普段利用しないものが含まれるので、使う予定がないものは削除します。

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

    仮想ハードウェアのバージョンは、古いバージョンの環境で動かす可能性がない限り、なるべく最新に近いバージョンにする事が推奨されます。
    例えば vSphere 7.0 の環境の VM は General Support が終了している vSphere 6.0 の環境に移行する事はほぼないと思いますので vSphere 6.5 以降をサポートするバージョン 13 以降に設定します。

    仮想ハードウェアのバージョンを上げるのは VM の再起動が必要ですがいつでも更新できますので様子を見ながら適切なバージョンに更新してください。

    物理 CPU と NUMA、vNUMA の話

    現在の x86 サーバは NUMA アーキテクチャを採用し、vSphere ESXi は NUMA に最適化された CPU スケジューラを提供しています。vSphere 5.x 以降では NUMA をまたがって vCPU を配置する vNUMA の機能を実装しているため、多くの vCPU を搭載する VM もサポートされる様になりました。
    一般的なイメージ図では物理の配置は以下の様になり、それぞれの CPU に均等にメモリが配置される事が推奨されます(最近の Intel Scalable Processor シリーズでは CPU 辺り メモリは 6 チャネル、それぞれ 2 スロット配置される事が多いので、1 CPU 辺り 6 の倍数でメモリを挿す事が推奨されます)。


    それぞれの CPU の内部では、物理 Core とそれぞれの Core が Hyper Threading で論理的に分割されて見えてきます。

    VM の vCPU は通常はこの Hyper Threading で論理的に分割された Core を1つの vCPU として割り当てられます。

    CPU スケジューリングに関する詳細な情報は以下のドキュメントにまとまっているので興味のある方は参照してください。

    物理 CPU Core と vCPU の割り当ての関連性

    VM に割り当てる vCPU は少なすぎると 100% に張り付いて処理が滞りますし、多すぎても CPU スケジューリングの遅延につながります。
    また、Hyper Threading が有効な ESXi 上では VM に割り当てる vCPU 数は偶数で設定する事が推奨されます。
    ※ 一番左のオレンジの vCPU を持つ VM の例だと、物理 1 Core から切り出された Thread の1 つのみが利用されている形となり、もう一つの Thread が利用されていません(余ったThread 単位で別の VM からアクセスされる事はないため)


    VM の性能の観点では単一の NUMA Node に収まる vCPU 数であることが CPU キャッシュの、メモリアクセスの速度の最小化の観点で推奨されます。
    ※ 多数の vCPU を持つ VM を動かすのであれば、物理の CPU もそれに見合った Core 数のものを選ぶ。

    物理 CPU Core に対して、それを上回る vCPU を割り当てた VM の場合、デフォルトではVM の起動時に NUMA をまたがって均等に vCPU が分散される vNUMA が構成されます。
    また、Hyper Threading が有効な環境における vNUMA は物理 CPU Core 数で配置が計算されるので、以下の様に 1 つの NUMA に 16 Thread ある場合でも 12 vCPU の仮想マシンの場合は vNUMA で構成されます。


    また、片方の NUMA に寄せたい場合は VM の詳細設定からカスタマイズする事が可能です : numa.vcpu.preferHT = true

    vNUMA は VM が起動したときの ESXi ホストの CPU、VM の構成情報に応じて自動的に最適配置され、vMotion など ESXi ホスト間を移動した場合もその構成は維持されます。
    その為、クラスタ内の ESXi ホストで CPU Core 数が異なりすぎるものが混在したアンバランスの状態では vMotion 後に最適な状態ではない可能性があるためご注意下さい。

    vCPU は必要性能と物理 CPU に見合った適切な数を割り当てる

    初期の ESX (2.x) の頃は Strict Co-Scheduling と呼ばれる、VM に割り当てた複数の vCPU (vSMP) 間の CPU 割り当てが全て同時に行われる仕組みでしたが、
    ESX 3.x 以降では Relaxed Co-Scheduling と呼ばれる、VM に割り当てた vCPU 間で CPU 処理が必要とされるもののみにリソースを割り当てる柔軟な(アイドル状態の vCPU には割り当てない)仕組みになりました。

    但し、これは複数の vCPU を割り当てた VM がそれほど CPU を利用していない時の処理であって、対象の VM の CPU 利用率が高く vCPU 間の同期処理が必要な場合には VM 割り当てた全ての vCPU に CPU が割り当てられるタイミングまで CPU 待ち状態となります。

    下のイラストの例では、グレーの vCPU を持つ VM が他の VM が先に CPU を利用しているので割り当てを待っている (CPU Ready と Co-Stop) イメージです。


    CPU Ready や CPU CO-Stop など CPU の割り当て待ちが増えて来た時の影響については次で説明しますが、メモリの割り当て含めてオーバーコミットできるからと使う予定のない vCPU・メモリを VM に割り当てておくことはメリットがない上にデメリットを引き起こす事となるので、適切なリソースを割り当てることがポイントです。

    どれくらいが適切か、分からない場合は Live Optics を使ったアセスメントや、vRealize Operations Manager の導入を検討してみて下さい。
    Live Optics を利用したアセスメントについては以下に以前投稿した記事がありますので参考にしてください。
    また、vCenter の パフォーマンスチャートや PowerCLI で取得する Get-Stat の各数値、ESXTOP などの CPU 指標(特に CPU Ready / Co-Stop など)を観察する事で、CPU の割り当てが適切かどうかを調べる事が可能です。
    VM が期待通りに動いていないな?と思ったときは早めにこれらをチェックしてください。

    ESXi ホストの CPU 負荷の上限について

    一般的に物理 CPU の利用率が 80% を超えると VM の CPU Ready の値も増加し、90% を超えると VM 性能が低下します。
    これら性能低下は vCPU 数の多い VM 程影響を受けるので、サイジングの際は現在の利用率をアセスメントなどで把握したうえで CPU モデルを選定する事が推奨されます。

    下のグラフはだいぶ前に検証したものですが、ベンチマークツール DVDStore を利用して、1 ESXi ホスト辺りの負荷 VM の数を増やしていき、スコアの上昇と CPU 利用率の関係を調べた際のグラフとなります。
    ESXi ホストの CPU 負荷が 80% 前後からスコアの上昇確度が低くなり(VM 辺りの性能処理の低下)90% 前後ではスコアが上がったり下がったりと安定しない状況が確認できます。 
    この様に、ESXi ホストの CPU 利用率が 80% を超えると VM の性能が十分に発揮できなくなり、vCPU 数の多い VM ほどこのような CPU 待ちの影響を受けやすくなるので、サイジングの際はご注意下さい。
    ※ ストレージ IO やネットワーク IO の頻度が高い VM は VMkernel 側の処理で CPU 利用率が高まりますので、サイジングの際は VM のリソースだけではなく、VMkernel の処理の考慮も重要です。

    vRAM も適切な容量を割り当てる

    近年は Guest OS やアプリケーションに大容量メモリの要件が増え、メーカーのカタログ推奨値に沿って非常に大容量の vRAM を VM に割り当てる機会が増えました。
    しかしながら、ホストのメモリリソースが足りないと問題視される基盤をアセスメントしてみると実際に VM の中のメモリの使われ方に問題があり、「アクティブメモリ」が「割り当て済みメモリ」の 10% 以下といった事が多々あります。
    そのような VM のゲスト OS 内でのメモリの使われ方を確認すると、大半がファイルキャッシュ・バッファとして消費されていますので、キャッシュアクセスの頻度が少ないシステムでは無駄にメモリが消費されてしまう結果となります。

    ※ アクティブメモリはゲスト OS 内の free コマンドなどでも確認できます。

    アセスメントを実施する中で多くの環境では CPU には余裕があるがメモリがひっ迫している、という状況が確認できます。

    Live Optics や vRealize Operations Manager などのツールを使う事で VM 内部のメモリの使われ方も可視化する事が出来るので、アセスメントによる利用状況の棚卸は重要です。

    ESXi ホストのメモリ利用率の上限について

    vSphere ESXi はメモリのオーバーコミットが可能なので ESXi ホストのメモリ搭載量よりも多くのメモリを VM に割り当てる事が可能です。
    しかし、上記に記した様にゲスト OS の中では割り当てメモリの余りをどんどんファイルキャッシュなどで消費していきますので、気付いたらあっという間にメモリを食いつぶしてしまうという事になります。
    そして、割り当てメモリより消費メモリが多くなるとバルーニングが発生し、VM の性能低下が起きやすくなります。


    メモリサイジングについてはなるべくオーバーコミットさせず、VM のメモリの総容量が ESXi ホストのメモリ総容量に達しないようにサイジングを推奨します
    一般的には、ESXi ホストの障害やメンテナンス時の VM の退避先容量(HAリソース)を考慮して、N+1 や N+2 の余裕をもって ESXi ホストを構成します。
    クラスタのホスト台数によりますが、各 ESXi ホストのメモリ上限は 80% ~ 90% を前提にサイジングする事が安全です。

    vDisk は基本は Thin vDisk で作成する

    以前は性能を考慮して vDisk は Thick とする事がありましたが、最近はデータストアの All Flash 化や重複排除ストレージの普及で Thick のメリットが薄れてきました。
    また、vSAN や NFS データストアなどは基本的に Thin で vDisk を扱いますので、基本的に Thin vDisk で作成する事がお勧めです。
    ※ 一部アプリケーション側の要件で Thick vDisk が必須とされる場合はアプリケーションの推奨に従ってください。

    vNIC は可能な限り VMXNET3 を利用

    vNIC はデフォルトでは e1000e となる事が殆どですが、推奨される vNIC のタイプは VMXNET3 であることが殆どです。
    作成する VM に推奨される vNIC のタイプは VMware Compatibility Guide (Guest OS) を確認すると確認できます。

    以下は ESXi 7.0u1 における Windows Server 2019 の VCG の情報ですが、デフォルトの e1000e はサポートされていますが、推奨は VMXNET3 であることが確認できます。

    仮想ストレージコントローラは PVSCSI を利用

    VM が利用する仮想ストレージコントローラも VCG から適切なものを確認し、割り当てます。
    最近の Guest OS では PVSCSI (VMware Paravirtual SCSI) が推奨される事が多いので、これらも作成時にデフォルトから推奨に変更します。
     
    以下は ESXi 7.0u1 における Windows Server 2019 の VCG の情報ですが、推奨は PVSCSI であることが確認できます。


    VMware Tools のサポートバージョンにも注意

    2020年11月より VMware Tools 自体も VMware Product LifeCycle Matrix に明確にサポート期間が掲載されるようになりました。
    可能な限りサポート期間中の新しいバージョンで運用しましょう。


    2020年12月時点ではバージョン 10.1.x 以降が General Support となります。


    各バージョンの ESXi に Bundle される VMware Tools は My VMware 以外にも以下のリポジトリからも入手可能です。

    それぞれのパッケージがどの vSphere ESXi に対応しているのか、Build 番号含めて確認が以下のリストで可能です。

    また、現在は ESXi に Bundle される前のより新しいバージョンの VMware Tools もどんどん My VMware で提供されています。
    それらは以下の URL からリリースノートの情報含めて入手可能なので必要に応じて入手してください。

    その他の VM の詳細カスタマイズ

    今回ご紹介している設定考慮以外にも多くの詳細カスタマイズ、チューニングの方法が vSphere パフォーマンスベストプラクティスには紹介されていますので、適宜ご参照ください。

    基本は N+1 のサイジング(HA リソースの確保)と 80% を上限としたリソースサイジングを推奨

    VM の CPU、メモリの項でも説明を書きましたが各 ESXi ホストのリソース利用率は CPU、メモリとも 80% を上限としてサイジングするのがお勧めです。
    一般的には ESXi ホストの障害やメンテナンス時の総リソース低下を考慮して、1 ~ 2 台のESXi ホストが停止しても VM のリソースが確保できるサイジング(N+1 や N+2 の考え方)で余剰分の ESXi ホストをクラスタに用意します。

    ただ、vSphere クラスタの設定で通常時 HA 専用のフェールオーバーホストとして VM を配置しない設定も可能ですが、他の ESXi ホストのリソースがひっ迫しているのに余裕のある ESXi ホストが余っているのはもったいないです。

    なるべく HA 専用フェールオーバーホストとしてではなく、DRS などで負荷を均等にしつつ、HA 時のリソースはしっかり確保できるように HA アドミッションコントロールなどの設定を有効活用する事をお勧めします。


    HOL でパフォーマンスチューニングを試してみる

    オンデマンドでいつでも誰でも VMware の様々な製品操作を試す事が出来る VMware Hands-On Lab (HOL) でここまで紹介した VM の詳細設定や vNUMA などのチューニング、バルーニングの挙動確認、CPU 過負荷状態のテストのグラフで紹介した DVDStore を利用したベンチマークツールの使い方などを学ぶことが出来ます。

    ご興味ある方は試してみて下さい(以下は 2021 年版の HOL の関連コースです)。
    Lab の提供が終了した古いコースのドキュメントもプロダクト名やキーワードでフィルタしながら入手可能なので調べものの際にお勧めです。

    お勧めのネットワークの設計・設定の推奨

    私自身、サーバー・ストレージを得意とするエンジニアなのでここでは設定の確実さと安定性を重視した個人的な推奨を記します。

    ネットワーク種類の選択 10G or 25G ? RJ45 or SR ?

    最近の x86 サーバーはオンボードで 10G BASE-T * 4 ポートを選べたり、エンタープライズ向けの 10G BASE-T ポートを搭載したスイッチの価格と消費電力も下がってきたので 10G BASE-T (RJ45 コネクタ + Cat6a 以上) を採用される事が増えています。

    しかし、たまに 10G BASE-T NIC の発熱や低品質な LAN ケーブルによるネットワーク障害(パケロスやエラーなど)が聞こえてきます。
    10G BASE-T をフルレートで使う場合、それなりの機器側の発熱と高品質なケーブルの考慮が必要なので排熱設計やケーブル品質には細心の注意を払ってください。
    特にサーバー背面の LAN ケーブルが多く束ねられていて排熱が滞っている場合や、急角度で LAN ケーブルを折り曲げた事でノイズが発生してネットワークでエラーが検知される事もありますので取り回しにもご注意下さい。

    SFP モジュールや DAC、AOC を利用した 10G-SR の方がコストは嵩みますが、光ファイバケーブルの高い安定性や取り回しの良さ、低発熱のメリットがあるのでガンガンに IO が流れる様な使い方の場合は 10G-SR、25G-SR の利用をお勧めしています。

    今、個人的に機器設計から提案できるのであれば、10G-SR * 4 ポート か 25G-SR * 2 ポートのどちらかで組みたいなと思います。

    25G 以上が必須な用途

    vSAN で All NVMe、特に Intel Optane などの超高速ドライブをフル活用した IO を期待する場合は 25G 以上でストレージネットワークを組む事を推奨します。
    また、その場合は JumboFrame (MTU 9000) を利用する事で、ストレージ負荷による CPU利用率の高騰を抑えられるので、必ず JumboFrame と組み合わせて利用してください。

    iSCSI や NFS などのネットワークストレージの用途でも同様の事が言えます。

    vDS と NIOC は活用したい

    vSphere Standard のみの環境では利用できませんが、vSphere Enterprise Plus (vSphere for Desktop) や、vSAN、NSX の各ライセンスには vDS (分散仮想スイッチ) の利用権があります。

    ESXi ホスト台数が少ない場合は  vSS (標準仮想スイッチ) でも事足りてしまいますが、
    クラスタの規模が中規模以上の場合は vDS の利用が強く推奨されます。

    特に、10G や 25G で物理ネットワークの本数が集約され、VLAN でネットワークを切って運用する場合、それぞれのネットワークの用途・重要性に合わせて NIOC (Network IO Control) 、ネットワークリソースプールで帯域の優先制御がシステムの安定性の向上に役立ちます

    また、LACP や Port Mirror なども vDS でサポートされますので高度なネットワークの用途が求められる場合は vDS が必須となります。vSphere 7.0 が対応する vDS 7.0 からは NSX-T での利用がサポートされます。

    NIOC の設定画面

    トラフィックのタイプやネットワークリソースプールに対してトラフィックの優先制御(シェア値設定)や予約、制限設定が可能です。


    ※ vDS を複数のバージョンのvCenter、クラスタで利用する際は、vMotion の相互互換性の観点でなるべく vDS のバージョンを揃えておくことを推奨します。

    安定性重視なら vDS + NIOC で基本の Active - Standby 構成

    10G * 2 or 4 ポートや 25G * 2 ポート の構成で、管理ネットワーク・VM ネットワーク・vMotion ネットワーク・vSAN ネットワークなど、様々な用途・要求帯域のトラフィックを集約する場合、VMkernel・ポートグループ毎に VLAN を割り当てて設定しますが、
    この際に vDS + NIOC を利用する事で確実で安定したネットワーク構成が組めます。

    その際に、vSAN や vMotion の様な高い帯域を求められるネットワークは NIOC のシェア値を高く設定し、チーミング設定で Active - Standby の構成をポートグループでテレコに持たせることをお勧めする事が多いです。

    ※ ポートグループ毎にアップリンク(物理NIC)の Active - Standby を明示的に指定


    以下、二つほど vDS の組み方の例を紹介します。

    シンプルな 2NIC 構成で集約

    用途毎に Active - Standby をテレコに構成する事で、以下の例では通常時は vSAN トラフィックや vMotion トラフィックは必ず片側の ToR スイッチで折り返してサーバー間で処理され、スイッチ間の渡り(ISL)を通る事がないのでシンプルな管理が可能です。


    NIOC の設定は、vSAN トラフィックを 100、その他のネットワークの合計を 100 とする事で、片方のネットワークが断となり片側に寄せられた場合でも、vSAN トラフィックには全体の半分のシェア値が割り当てられるので、ネットワークの片系障害時にも帯域を優先的に確保する事が出来ます。

    4 NIC 構成でネットワーク用途で Teaming を分離

    4 ポート以上で組める場合は、負荷の高い vSAN や vMotion を別の vDS や ToR スイッチに分けて通常の VM ネットワークと分けるデザインも可能です。


    よりネットワーク負荷の分散を制御したい場合には Active - Active のデザインも当然サポートされ、ToR スイッチで LACP などを組む事が出来る場合はそれらの利用も可能です。

    VMware Validated Design にもこれらの推奨デザインが紹介されていますので併せて参照ください。

    ネットワークの MTU 設定(Jumbo Frame)の推奨は?

    vSAN、iSCSI、NFS などネットワークストレージを利用し、その IOPS が非常に多く負荷が高い場合は JumboFrame を利用する事で ESXi ホストの CPU 利用率上昇を抑える事が可能です。
    ※ ストレージネットワークの場合、JumboFrame で IOPS の Max を上げるというよりは CPU 負荷を下げる効果の方が顕著です。

    過去の経験上、Intel Optane SSD などを利用して All NVMe vSAN を構成し、25G・40G ネットワークで性能検証した際は最大負荷を掛けた際の CPU 負荷を大幅に減らし、結果として IOPS の上限も上がった事がありました。
    高い性能を考慮する場合は予め JumboFrame の利用を前提とした方が良いです。

    また、NFV 用途などで高スループットのトラフィックを捌く際にも JumboFrame の設定は有効に働きます。
    ※ 効果は IO サイズによっても異なりますので、環境に合わせた判断が必要です。

    JumboFrame (MTU 9000)を有効にする場合は End to End (vNIC・VMkernel、仮想スイッチ、ネットワーク機器)で揃える必要があるので、ESXi ホストの追加や故障による交換時など設定漏れが無いように注意してください。

    お勧めのデータストアのデザイン、設定

    外部ストレージ構成時のデータストアデザイン

    RAID や Pool 設計、FC ストレージ利用時のゾーニング設計や NFS ストレージ利用時のコントローラタイムアウトの設計など、ストレージの設計ポイントを挙げていくとキリがないので、今回はデータストアの容量と数に関して、および ESXi ホストからストレージへの接続パスパスについてのみ記します。

    データストアのサイズと数の考慮

    多くの外部ストレージは複数のコントローラで冗長化され、バックエンドの LUN や ファイルシステムを双方のコントローラからアクセスできる仕組みを備えています。
    しかし、ハイエンドモデルでは Active - Active で同時に 2 つのコントローラから LUN へ IO を捌く事が可能でも、ミッドレンジのストレージでは実際にはどちらかのコントローラが LUN のオーナーとなり、通常時の IO は片方のコントローラが捌くといった事が一般的です。
    NFS データストアを利用する場合も同様で、どちらかのコントローラ(NFSサーバ)が NFS のファイルシステムをマウントして提供するのが一般的です。

    その場合、大容量のデータストアを 1 つだけで構成すると片方のコントローラが普段は使われない事となります。


    クラスタの負荷分散と同じく、ストレージコントローラも IO の負荷が偏り、CPU 利用率が高騰すると IO 遅延にもつながりますので、なるべく IO が分散できるようにデータストアを構成する事が推奨されます。


    全体の容量や VM の数にもよりますが、1コントローラ 1データストアだと拡張時や何等か設計不都合で再作成が必要となった時、障害発生時のインパクトも大きくなるので用途に合わせて 4 つ以上でデザインすると良いかと思います。


    1つのデータストアの容量は、過去の VMFS の制限などから 2TB 前後で切る設定がよく見られますが、VAAI による IO 処理のオフロードやストレージの大容量化に伴い 20TB を超えるデータストアも珍しくありません。
    ストレージレプリケーションの対象がデータストア単位だったり、データストア毎に性能要件を設定する等実際の運用ポリシーにデータストアの数や容量は依存しますので、適宜コントローラの負荷バランスをとった配置設計で組んでいただく事が推奨されます。

    重複排除ストレージの考慮

    最近は重複排除・圧縮をサポートするストレージが一般的となり、vSphere 上の利用ストレージ利用率と、ストレージ上で管理される重複排除後の利用率に差が生じ、データストアのサイジング・容量のオーバーコミットが難しくなってきました。

    従来方式のデータストアでは Thinprovisioning のデータストアを作成した場合も、この差は吸収が難しいため、vSAN や VVOL などポリシーベースのストレージアーキテクチャの利用を最近はお勧めしています。


    ストレージとの接続・パスの管理

    FC・iSCSI データストアではマルチパスによる IO の分散とパスの冗長化、NFS データストアでは NIC チーミングによるパスの冗長化を図りますが、導入時・運用中とも必ず意図した設計通りのパスが設定されているか必ず確認してください。

    一般的な FC・iSCSI などブロックストレージでのデータストア設計であれば以下の様に 1 つのデータストアに対して、ESXi ホストからは 4 つのパスが ラウンドロビンで設定されている事が推奨となります。

    結線イメージ
    パスの本数

    パスの数が異なっている場合は間のスイッチにおけるゾーニング設定や VLAN 設定に間違いがある可能性があるので、必ず全 ESXi ホスト、全データストアで均一にパスが通っているかを確認してください(一括確認には PowerCLI などを利用すると便利です)。

    また、マルチパスの場合はパスの切り替わりのポリシーも想定と違う値が設定されていると性能や可用性に影響が出るので、必ず以下のベストプラクティスや KB の注意点を確認してください。

    vSphere Storage Best Practice

    ストレージに関しては vSphere Performance Best Practice 以外にも以下の様なガイドライン、KB が案内されています。
    各ストレージメーカーがリリースしている vSphere 向けの設計ガイドと合わせて参照してください。
    また、FC・iSCSI などのブロックストレージではパス設計とともに IO の分散設計(現在多くはラウンドロビン + 1 IO 切り替わりを推奨)、iSCSI ポートバインディングの考慮について質問されますので、以下 KB を参照先として記します。

    vSAN 構成時のデザイン

    vSAN クラスタのデザインについては以前に以下の記事をまとめております。
    また、以下の KB、Cloud Platform Tech Zone のドキュメントも非常に有用ですから参照くださ。

    お勧めのクラスタ設計・設定・運用

    その他様々な設計要素がありますが、いくつか抑えておいていただきたいポイントをご紹介します。

    vSAN 上に vSAN 自体を管理する vCenter を配置する場合のポイント

    vCSA on vSAN は今では一般的な構成となっておりますが、考慮しておくと便利な設計ポイントをご紹介します。

    ホストグループ・仮想マシングループと DRS アフィニティ・アンチアフィニティルールの活用

    vCSA on vSAN に限った事ではありませんが、DRS が有効なクラスタでは VM はクラスタ内のホストに自由に分散されます。
    しかし一部の VM は特定のホストに配置したい、特定の VM はこのホストには配置しない、といった設定が必要な時があります。

    vCSA on vSAN の場合、例えば計画停電運用などでクラスタを全シャットダウンした際、次回起動時に「vCSA がどこの ESXi ホストで動いていたか確認し忘れた」と言った時は全 ESXi ホストにどの VM が配置されているか、Host Client や CLI でチェックして vCSA を探す必要があります

    こうした面倒を嫌って DRS を使わなかったり、DRS を「手動」設定で運用する方もいらっしゃいますが、やはり負荷分散の機能は非常に有用なので可能な限り DRS による分散は強く推奨します。

    DRS を使いつつ特定の VM と特定の ESXi ホストを結びつける運用では vSphere が機能として持つホスト・仮想マシングループと DRS アフィニティ・アンチアフィニティルールが利用できます。
    DRS で全自動の分散をしつつ、特定の VM を特定の ESXi ホストに配置したり、特定の ESXi ホストへ移動を禁止する等のルールを設定する事が可能です。

    DRS アフィニティルールを利用する事で、vSphere クラスタの全シャットダウンを行った後の再起動時も、vCSA などの管理 VM がどこの ESXi ホストに登録されているか特定できるのでメンテナンス時の手間がなくなります。

    実際の vSphere Client の UI では、各クラスタの「設定」にある「仮想マシン/ホストグループ」「仮想マシン/ホストルール」から設定します。


    仮想マシングループの設定(対象 VM を指定)

    ホストグループ設定(対象 ESXi ホストを指定)

    DRS アフィニティルールの設定


    DRS アフィニティルールは非常に柔軟なクラスタ運用を可能にするポリシー設定なので活用をお勧めします。
    ※ DRS が有効でない、または vSphere Standard など DRS がない環境では DRS アフィニティルールに基づく VM の自動的な vMotion による移動は制御できませんが、
    vSphere Standard でも ホストグループ・仮想マシングループの作成とルールの設定自体は行えます
    この場合、VM の起動時にルールで許可されていない ESXi ホストでは VM の起動が禁止され、また手動で vMotion する場合も弾かれるので、特定の ESXi ホストに対してアプリケーションのライセンスなどが有効化され、VM と実行される ESXi ホストの一致が必須の場合などには有効な手段となります。

    管理ネットワーク用 vDS 非バインドポートグループ常設を推奨

    vDS は vCenter がシャットダウン状態でも設定したポリシーで稼働し続けますが、vCenter がシャットダウン状態では設定変更や、新規 VM に新たなネットワークポートをアサインする事が出来なくなくなります。

    vCenter 自体が自分自身を管理する vDS に管理ネットワークを接続している場合、vCSA が破損し、新規で vCSA をデプロイし vDS に接続しようとしてもネットワーク接続に失敗してしまう問題が発生します。

    こうした管理 VM の障害発生時に臨時で利用するための「短期-バインドなし(Ephemeral Binding)」という種類の vDS ポートグループがあります。
    vCenter 自体が vDS 配下にある場合で、クラスタが vDS のみで構成されている場合は必ず「短期-バインドなし(Ephemeral Binding)」のポートグループを管理ネットワーク用 VLAN の設定で準備しておいてください。

    「短期-バインドなし(Ephemeral Binding)」 については以前記事を書いておりますので以下も参照してください。

    vCenter と ESXi の構成情報、DB バックアップ

    vCSA 6.5 以降の vCenter は管理画面(VAMI)からファイルベースで DB のバックアップが可能で、かつ現在のバージョンでは vCSA のイメージバックアップは非推奨とされ、ファイルベースの DB バックアップは vSphere 仮想化基盤の運用では必須となります。

    vCenter 7.0 では、SMB/NFS/SFTP など様々な出力先に定期的なバックアップを取得するジョブがサポートされています。
    少なくとも設定変更やパッチ適用等 vCenter で管理イベントが行われる際には DB のバックアップを取得する事が推奨されます。
    また、ESXi ホストも従来からコンフィグバックアップがサポートされています。
    ESXi ホストで取得したバックアップは「取得時と同じ Build バージョンにしかリストアできない」仕様があるので、ESXi ホストのパッチ適用の前後では必ずバックアップを取得しておいてください。
    KB にもある様に、PowerCLI で Get-VMHostFirmware を利用して取得する事も可能なので、全ホストを同時に一括でバックアップする事も可能です。

    2020年11月30日月曜日

    vSAN Ready Node の選び方とカスタマイズ

    vSAN Ready Node のカスタマイズについて質問される事が時々あるのですが、まだまだ 「vSAN Ready Node = ガイドに載った構成で導入するもの」という認識が多い様です。
    実際は、多くのパーツは性能要件、用途に応じてカスタムする事が出来ますし、各サーバーメーカーの見積もりツールなどでも、Ready Node 型番のモデルから幅広くコンポーネントのカスタムが出来る事がほとんどです。

    ※ 今回は2年前の VMware 公式ブログのネタと VMware Japan vSAN 担当 小佐野さんが書いたブログからのアップデート内容を中心に、現時点の情報を整理しておきたいと思います。

    最所に結論

    vSAN Ready Node のコンポーネントは要件・用途に応じて IO Controller 以外の殆どのコンポーネントは VMware HCL に掲載されているものであれば「変更可能」です。

    極端な例では、vSAN Ready Node にこだわらなくても HCL に掲載のあるコンポーネントを組み合わせて Build Your Own で手組で構成を組んだものも vSAN としてサポートされますし、一部のお客様では実際にその様に HCL に掲載されている機器を組み合わせて用途に合わせたスペシャル構成を組む方もいらっしゃいます。

    個人的には vSphere Update Manager (vUM) や vSphere Lifecycle Manager (vLCM) の連携を考えると vSAN Ready Node をベースに組んでいただく事を強く推奨します。 
    ※ 各サーバーメーカーの構成ガイド・見積もりツールや、サポートにより変更可能なコンポーネントは異なりますので詳細はハードウェアメーカーのガイドを参照してください。

    初めに vSAN Ready Node Sizer で基本の構成サイジング

    2020年9月に更新された vSAN Ready Node Sizer はきちんと前提情報を入れればかなり明確なサイジング結果を出してくれます。
    まずは vSAN Ready Node Sizer を活用してベースのサイジングをしてみて下さい。
    vSAN Ready Node Sizer ではサイジング結果をもとにベースとなる各メーカーの vSAN Ready Node の構成を提示してくれますので、これを実際の要件に合わせてカスタムしていきます。

    vSAN Ready Node の変更可能なコンポーネント

    詳細は 以下のKB 「vSAN ReadyNode で変更できるものとできないものについて (52084)」にて説明されています。
    上記 KB を見て頂ければわかると思いますが、明確に変更できないものとして指定されているコンポーネントは IO Controller (HBA、RAIDカードなど) SAS Expanderストレージプロトコルの変更(SAS → NVMe、SAS → SATA 等ドライブインターフェースの個別変更)変更不可とされています。

    ※ vSAN Ready Node で選ばれている IO Controller は Queue Depth が深く高い IO 負荷に耐えられるモデルで、Firmwear・Driver なども各 vSphere バージョンで迅速に開発され HCL の追従がしっかりしているので、vSAN を構成するコンポーネントとして非常に重要なものとなり、その為変更不可とされています。

    SAS → SATA などドライブのモデル・プロトコルを変更したい場合はどうする?

    ストレージプロトコルを変更したい場合などは、同じサーバー筐体をベースとした別構成の vSAN Ready Node がだいたいどのメーカーのモデルにも用意されていますので、vSAN HCL の中で出力されるモデルを変える事で結果として変更対応は可能です。

    例えば、Dell のラックマウントサーバ(PowerEdge シリーズ)で、vSAN 7.0u1 をサポートしている最新の Intel Xeon Scalable Processor に対応した All Flash vSAN モデルを vSAN HCL サイトで確認すると2020年11月時点で50件あります。

    中身を見ていくと、例えば PowerEdge R640 をベースにしたモデルも、AF-4、AF-6、AF-8 などの各目安の指標で数パターンずつ、All NVMe モデル、NVMe + SAS モデル、All SAS モデル、NVMe + SATA モデル、SAS + SATA モデルなど各プロトコルの組み合わせが用意されています。
    このため、1つのモデルのプロトコルを変更するのではなく、予めメーカーが認証取得している別のプロトコルタイプのモデルを選んでカスタマイズする事が出来ます。

    ドライブ本数、ディスクグループ構成の変更は?

    ドライブ構成の変更は vSAN Ready Node Sizer でも各種容量、ディスクグループ構成の指定で元々サイジングに合わせて構成が作成されますので、それをさらに変更していただく事も問題ありません。
    また、サーバーメーカーによっては同じタイプ・容量のドライブでも vSAN HCL で認証取得している複数の製造元のラインナップを揃えている場合がありますので、ドライブ製造元を変更していただく事も可能です。

    安定性や性能を考慮した vSAN ドライブ構成の選び方は以前以下の記事にまとめておりますので参照ください。

    CPU、メモリなどの構成変更は?

    その他のCPU、メモリ、ネットワークや、vSAN を構成する SSD、HDD などのドライブ類の本数、容量は用途に応じて HCL に掲載のある同等以上のモデルに構成を変更する事が可能です。

    CPU など、クロック数を減らしてコアを増やすなど、どこまでが同等以上かが判断しにくい部分もありますが、性能という観点では SPEC CINT2017 rate などのベンチマークスコアなども参考にすると良いかと思います。
    SPEC Int のベンチマークデータを利用した CPU の世代間での性能比較の方法については以下の方法を以前記事にまとめております。
    各サーバーメーカーの構成ガイドや見積もりツールにもよりますが、
    かなり柔軟に CPU モデルの変更やメモリ容量の変更は可能とされています。

    vSphere Lifecycle Manager (vLCM) がサポートするモデルはどれ?

    vSphere 7.0 から実装された vSphere Lifecycle Manager (vLCM) をサポートするモデルは vSAN HCL (vSAN Ready Node モデル) から "vSAN ReadyNode の追加機能" > "vLCM Capable Ready Node" を選択して検索すると表示されます。


    2020年11月時点、vSAN 7.0u1 でサポートされる vLCM Capable Ready Node は、Dell、HPE、Lenovo の各社が提供する最新世代の vSAN Ready Node となります。


    2020年10月9日金曜日

    vSphere 7.0u1 の vSphere Clustering Service (vCLS) 停止方法

     vSphere 7.0u1 から DRS などのクラスタの管理機能が vCLS (vSphere Cluster Services)  に割り当てられ、クラスタを作成すると自動的に vCLS の vApp が展開されます。

    詳細は以下の vSphere Blog を参照ください。
    vSphere 7 Update 1 – vSphere Clustering Service (vCLS)
    https://blogs.vmware.com/vsphere/2020/09/vsphere-7-update-1-vsphere-clustering-service-vcls.html

    DRS を利用しない場合や、Home Lab などでリソースが限られる時には無効にしたいと思いますのでその手順をご紹介します。

    本手順は KB : vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 (80472) に沿って実施しますが、vCenter の詳細設定での構成パラメータは安易に変更を加えると動作に影響が出たり、一度追加すると vSphere Client では削除できず vCSA 内の vpxd.cfg ファイルを直接修正しなければならないため慎重に設定値を確認してください

    また、この vCLS ですが、vSAN クラスタ・vSAN データストア上に vCLS の軽量 VM が展開される場合にはクラスタのシャットダウンの際に今回ご紹介する手順が必要となりますので、併せて以下の KB も参照ください。

    ※ 2021/1/9 追記 : 
    vCLS の有効無効の操作を PowerCLI で行う方法を以下に記しました。予めスクリプトを組んでおく事で計画停止時などの作業効率化になると思います。

    Home Lab 環境での不要な vCLS の止め方

    共有データストアを持たないクラスタや単一ホストでクラスタを構成した場合でも vCLS はデプロイされるようです。
    そして
    "機能「bad_requirement:hv.capable」が 0 でしたが、少なくとも 1 である必要があります。 仮想マシンの起動に失敗しました。 モジュール「FeatureCompatLate」のパワーオンに失敗しました。"
    "クラスタ PCL のクラスタ エージェント仮想マシン vCLS (1) の設定が無効です (vCLS)"
    の様なエラーを吐き続けますのでちょっと鬱陶しいです...

    また、vCLS を利用する DRS を有効にしない場合でも vCLS はデプロイされますので、これを止めたいと思います。
    ※ DRS を利用する場合や HA 時の適切な配置をコントロールする場合には vCLS は必須ですので無効化しないでください。

    https://kb.vmware.com/s/article/80472 の "Retreat Mode" の設定を参照します。

    vCLS を停止する vSphere クラスタを vSphere Client 上で選択し、URL に含まれるクラスタドメイン ID を確認します。
    domain-c<number>
    などとなっています。

    vCenter の詳細設定 --> 設定の編集を開きます。

    KB の内容を確認し、構成パラメータ "config.vcls.clusters.domain-c<number>.enabled" を "false" で追加します。余計な文字やスペースが含まれない事を再確認してください。
    私のクラスタでは確認した URL の ID から "config.vcls.clusters.domain-c8.enabled" となりました。

    設定を保存すると即時 vCLS が停止、削除されます。


    ※ 再び DRS を使う場合などで vCLS を立ち上げる場合は値を true に変更します。

    以上、簡単ですが vCLS の無効化方法です。

    2020年10月6日火曜日

    SPEC のベンチマーク情報を利用した CPU 世代間性能比較

    IT インフラのアセスメントなどの後、次期のサーバー選定時に比較参考となる CPU の世代間・モデル間の性能差がどのくらいあるのかよく聞かれるのですが、
    私が良く使う SPEC (Standard Performance Evaluation Corporation) のベンチマークスコアを利用した比較方法をご紹介します。

    この方法を10数年前から利用していますが、実際のシステムの移行前後の CPU 利用率でみると割と現実的な数値が確認出来ています。
    SPEC からダウンロードした CSV のスコア値を整形し Excel などで簡易のサイジングシートを作る事で比較が容易になります。

    私は以下の様な形で Excel シートのプルダウンで CPU のモデルを選ぶとそれぞれのスコア比較を行い、ホスト台数や利用率の前提を式に追加すればクラスタとしてのリソースがどれくらいあるかを可視化する事が出来る様にしています。
    ※ あくまで私個人の比較用の手法なので公式のサイジング方法ではありません。参考情報としてご活用ください。


    SPEC (Standard Performance Evaluation Corporation) について

    SPEC (Standard Performance Evaluation Corporation) は様々なサーバー、ストレージ、アプリケーションのベンチマークテスト結果を公開、またベンチマークテストのためのツールを提供している非営利団体です。

    様々なスコアが公開されていますが、CPU の性能比較の観点では、「SPEC CPU 2017」 と 「SPEC CPU 2006」が非常に多くの機器のスコアで比較できるのでこれらを利用します。

    それぞれのベンチマークの結果にも複数スコアがありますが、仮想化統合などで多くの仮想マシンの処理を集める用途であれば整数演算のスループット(SPECint_rate) が指標として適切と思われるので私はそれを利用しています。
    • SPEC CPU20xx Integer Speed (SPECint) : 整数演算の処理速度
    • SPEC CPU20xx Integer Rate (SPECint_rate) : 整数演算のスループット
    • SPEC CPU20xx Floating Point Speed (SPECfp) : 浮動小数点演算の処理速度
    • SPEC CPU20xx Floating Point Rate (SPECfp_rate) : 浮動小数点演算のスループット

    SPECint2017 と SPECint2006 のスコアの入手

    私は同じサーバーブランドでスコアが登録されている Dell の PowerEdge シリーズの結果を利用しています。
    ※ 特定ブランドで揃えた方が後々の正規表現を利用した整形でも楽です。

    スコアは以下のサーチメニューの URL から細かい条件でフィルタ出来ます。

    Dell の PowerEdge で絞り込む場合は上記の Simple Search から「System」"Matches "「PowerEdge 」とすれば PowerEdge で測ったスコアが検索できます(SPECint2006 で 2,200 件近く、SPECint2017 で 1,000 件近いスコアが出力されます)。


    出力された結果を CSV 形式でダウンロードします(Dowonload as CSV をクリック)


    ダウンロードした CSV を開くと以下の様なフォーマットとなり、私はこれを整形して、CPU のモデル、動作クロック数、コア数、ソケット数 と Baseline スコアを整理して比較の元としています。
    ※ Baseline にしている理由は Result が 0 のものも多数あるためです。この辺りは個人的な考えなので参考まで。

    System 列にはサーバーモデル、CPU モデル、動作クロック数が記載されていますのでこれを適宜正規表現などを利用して列に分けるように整形します。ここは型が決まっている様で決まっていないので面倒ですし、動作クロック数が間違っている事が多々あるので正確な数値は Intel 社のサイトから各世代・各 CPU モデルの仕様比較が出力できるので公式情報を確認します。

    面倒かもしれませんが、私は VSCode や秀丸など正規表現で置換できるエディタを使って整形しています。
    また、 SPEC 上に登録されている記載が全て同じルールで掲載されているわけではなく、たまにイレギュラーもありますので、それらは個別に修正します。量が多い場合は Excel のテーブル形式のフィルタやピボットテーブルなど利用すると確認が捗ります。


    再度 CSV → Excel にデータを貼り付けると以下の様なシートにまとまります。
    まとめると分かりますが、同じ CPU モデルでもソケット数が違ったり、スコアも微妙に違います。
    私は CPU 毎(ソケット毎)の Baseline の数値の平均値をピボットテーブルなど算出して利用します。


    SPECint2017 と SPECint2006 のスコアの調整

    SPECint2017 と SPECint2006 ではベンチマークに利用するツールのバージョンが異なるため、スコアの値も異なり、過去の CPU のレポートは SPECint2017 には無いものが大半です。

    また、同じ CPU でも SPECint2017 と SPECint2006 では基準が異なるため、数値としてだいたい 9~10 倍のスコアの差があり、私は同じ基準でスコア比較するために SPECint2017 と SPECint2006 の両方にスコアのある Skylake 世代の CPU 搭載サーバなどでその差(比率)の平均を確認し、SPECint2017 のスコアを控えめに約 9 倍して大体のスコアを揃えています。

    SPECint2017_rate のスコア


    SPECint2006_rate のスコア

    CPU モデル毎にピボットテーブルでまとめると、微妙にクロック数が違ったり、登録されているコア数などが異なっているのでそれらは手修正してください。


    数値は同じ CPU であればだいたいどのメーカーのハードウェアでも近い数値なので細かいところはこだわらずに比較条件がそろっていれば良いかと思います。

    CPU 性能比較シートの完成

    最終的には以下の様なピボットテーブルにまとめ、

    2006 と 2017 の数値を x9 して別テーブルにて計算して、選んだ CPU モデルに応じて Index と Match 関数で SPEC のスコアを引いてサイジング比較できるようにします。

    シートを分けて余計な情報をマスクすれば完成です。
    CPU のコストや消費電力(TDP)の項目があるとさらに細かな分析が可能になります。
    ※ CPU のコストは各メーカーが公開しているサーバー構成ガイドなどから集められます。



    IT インフラの更改時にどのくらいのリソースを用意するべきか、アセスメントなどの結果をもとによりリーズナブルな機器選定に役立つと思いますので参考にしていただけると幸いです。






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