WCSC27のPonanza ChainerのインフラとHPCチューニングの話

お酒ばっかり飲んで過ごした連休もいよいよ終わりです。(これ書き始めたのが連休中)
まともな休みになった連休は数年ぶりな気もします。

さて、少しさかのぼりますがひょんなことからGWの連休中に開催される世界コンピュータ将棋選に参加するPonanza Chainerという将棋ソフトのインフラ構築をやることになりました。
長いので以下Ponanza。

結果からいうと優勝目標で二位という結果でした。
将棋のいろいろ恐ろしいものの片りんを味わった気がします。
ちなみに自分は大会の3日前にハム将棋を初めて、当初は10枚堕ちでボロ負けしてたのが、当日にはハンデありで互角に戦えるくらいにはなりました。(しょぼ)

今回のインフラ構築作業をするまでは自分の中でコンピュータ将棋というと、スペックのいいパソコンを1、2台会場にもっていってスタンドアロンで動かすという印象があったため、最初は「なんぞ?」と思いつつ着手しました。
実際Ponanzaも手を付けるまでは数台の規模でしたし、最初はノートパソコンで動いてたとか?

他の仕事も忙しかったのでながら作業となりましたが、作業を進める中で山本さんとの会話でコンピュートリソースの殴り合いが始まり数個のプロセッサでは勝つのが難しい状況になっていることを知り、社内で余剰のサーバや部材をかき集めてPonanzaクラスタを動かすことが目的ということをしりました。

Ponanza用の計算クラスタということは言い換えれば自作のスパコンです。
結果的にPonanzaのためのHPCのインフラを社内からかき集め、限られたリソースで最大限パフォーマンスを発揮できる状態にすることが自分の仕事になりました。

クラスタはただたくさん並べてつなげばいいというわけではありません。
CPU1台でやっていた計算を複数台でやるわけですから、CPU間の通信が最大のボトルネックとなります。
これをインターコネクトといいます。
コンピュータ間で通信できればいい訳ですから、種類は様々でイーサネットやInfinibandや高度なシステムになると独自規格専用設計だったりします。
このインターコネクトにはCPUへの命令やその結果、共有メモリなど大量の通信が流れます。

昨今GPUによりFLOPS単体の性能は劇的に上がりましたが、あくまでも単体の性能の話でクラスタを構成する場合、システム全体でどの程度の性能(スループット)が出るかは、インターコネクトが大きく影響します。
なのでFLOPSだけ見てGPUが地球シミュレーターの性能を超えたとかいうのは、そうゆう見方もありだとは思いますがナンセンスだと思いますし、用途がまるっきりちがいます。

さてちょっと脱線しましたが、今回のPonanzaのインターコネクトは1Gイーサです。(これしかなかった)
おまけにスイッチがぼろPower Connectだったため、バッファ溢れが心配でラージパケットも使いませんでした。
実際は1Gの通信で間に収まるように調整して使ってもらいました。

ではHPCクラスタにおいてのインフラ屋の仕事がサーバを積んでインターコネクトで接続して終わりかというとそうではありません。
決して終わりではありません。

大事なことだから二度いいました。

インターコネクトから入ってくる通信を、適切にアプリケーションに渡して処理してもらうまでがインフラ屋の仕事です。
つまり、インターコネクトから先(手前)のNICやドライバ、カーネル、ソケットの処理にボトルネックがあり通信を取りこぼしてしまったら、いくらインターコネクトが早くてもシステムのスループットは上がりません。
また高速なインターコネクトを使うほど、通信の処理量が増えるため取りこぼしが増えやすいです。
インフラ屋はソフトウェアエンジニアには見えない通信の部分のボトルネックを特定し、改善する必要があります。

今回のPonanzaクラスタは1Gということもあり、NICやドライバ、カーネル廻りがボトルネックになることはありませんでした。(もちろんある程度チューニングは事前に実施済み)
唯一カーネルからアプリケーションのユーザソケットに渡す部分がボトルネックになりパケットの取りこぼしが大量に発生したため、スレッド数を増やして対応してもらいました。
これにより20%~30%くらい?スループットが向上しました。

常にシステムのどこがボトルネックになるかということを意識して調べると自然と身につくと思います。(ドヤ)

またちょっと別の話になりますが、今回のPonanzaクラスタは東京と石狩の2か所の拠点で構成されています。
当初はこの拠点間を1Gbpsで通信したいという要件がありました。
東京と石狩は距離がありますが、1Gbpsで通信することは可能です。
ここは単純に通信のスループットとレイテンシの話になりますが、土管が1Gbpsでレイテンシが20msくらいなので、1Gbpsのデータが20msかかって届くという考えになります。

具体的には送信側は1秒間に130Mbyteを何も考えずに送りつづけます、受信側は受信し続ければ実現可能です。
結局この話はなくなりましたが、当初はきっちり1G使い切るTCPチューニングを考えていました。
一般的なTCPの輻輳制御アルゴリズムは衛星離島も含む広域の通信に特化しているため、安定性を優先してスループットを犠牲にしています。
雑な図をかいてみました。

この輻輳制御によって効率的に安定して通信できるわけですが、通信品質がよく安定している相手であれば、輻輳制御そのものは必要ありません。
むしろスロースタートなど輻輳制御機構によってスループットが低下します。
きっちり1Gbps使える回線という前提で、1Gbpsのウィンドウサイズで常に通信するというチューニングができます。

今回の大会に向けて実際どこをどうチューニングしたかまで書くと長くなるので、とりあえず今回はこの辺で。
気が向いたらふわっと書きます。

というわけで将棋クラスタの方々がここを見るかわかりませんが、個人的な今回の意気込みは。
技巧がAWSつかってるから、オンプレ職人の手によるチューニングの恐ろしさをみせてやるぜ!」って感じだったけど、異次元から差し込まれましたねw

来年もぜひとも挑戦したいと思います。
コンピュータ将棋でインフラエンジニアが必要な時代になったんですねえ…。

インフラ屋がシングルモードファイバを扱うときに知っておくといいこと

東京はだいぶ暖かくなりましたね。
ぼちぼち試される大地で試用される期間も3か月が過ぎ、春の到来とともに終了を迎え全力モードです。
(普通に東京勤務ですけど)

前回のWDMネタでもさらっと書きましたが、建屋間の接続は距離が長く、マルチモードファイバ(MMF)での接続は伝送損失が多すぎて不向きです。
必然的にシングルモードファイバ(SMF)になりますが、自分は今までSMFを扱った経験はベンダに言われた通りの構成で購入して、電話しながら言われた通りに接続したことしかありませんでした。
今回は自社の設備 + 自分が設計をする必要があったため、構成への不安と知識不足を感じて軽く学習しなおしました。
(物理的につなげるためだけにコネクタの形状と芯のサイズくらいしか調べた事がなかった)

SMFはMMFより扱いが難しかったり、種類が多かったり複雑ですが、要点さえ押さえてしまえばMMFとさほど変わりません。
ずらずらと書いていくのでさくっと覚えて帰って(?)いただければと思います。
※初心者のチラ裏なので間違ってるかもしれません!

出力されるレーザーは不可視で高出力
まずは安全性にかかわる重要なことです。
初期の通信用ファイバで利用されていた波長は可視光帯が利用されていました。
今でもその印象を漠然と持っている方もいると思いますが、可視光での通信は伝送損失が大きすぎるため、現在では通信用には使われていません。
波長の特性や利便性から可視光より波長が長い赤外線が利用されています。
日暮れに赤が遠くまで伝送されて夕焼けになるように、さらに長い波長の赤外線はより遠くに伝送されます。

赤外線は人間の目では見えないため、リンクアップしないからといってうっかりのぞき込むと高出力の赤外線レーザーにより眼に深刻なダメージを負うことがあります。
数百メートル~数キロのトランシーバはクラス1相当の出力が大半なため、人体に破壊的な影響を与えるものはほぼないと思いますが、扱いには気を付けましょう。
人に向けたりもしちゃだめですよ。

トランシーバモジュールの選び方
SMFで利用できる波長は技術改善により徐々に拡張されてきました。
現在では1260nmから1625nmまでが定義されています。
それぞれ利用開始時期によりバンドとして区別されています。詳細はぐぐるとすぐ出てきます。
波長が長いほど遠くまで届きやすい性質を持ちますが、その分高性能なトランシーバが必要になり価格があがります。
価格と必要とされる伝送距離のバランスで適度なモジュールを選択します。

以下は具体的な例です。

今回の自分の要件はSMF OS2ファイバで300メートルの伝送でした。
一般的にOS2ファイバの伝送損失は0.2dBm/km ~ 0.4dBm/kmくらいです。
途中パッチパネルを三か所挟むので中継の損失を多めに見て1dBm x3とします。
パッチやファイバなどの損失量についてはメーカーのカタログにのっています。

ここまでで予想される伝送損失は全体で-3.2dBm程度ですので、出力から受信まで3.2dBm減衰しても300メートル届くトランシーバモジュールを選定します。
見やすいのでJuniperのサイトから引用させてもらいます。

比較するとMMF ~300m、SMF 10km~ という自分でサンプルに選んでおいて微妙なラインナップですが、EX-XFP-10GE-LRが適正です。
スペックシートの中から重要な項目をいくつか抜き出します。

Fiber count Dual 2芯(Tx/Rx)
Transmitter wavelength 1310 nm Oバンド
Minimum launch power –8.2 dBm 動的な最低出力
Maximum launch power 1 dBm 動的な最大出力
Minimum receiver sensitivity –18 dBm 最低受信レベル
Maximum input power 0.5 dBm 最高受信レベル
Distance 10 km 最大伝送距離

このスペックシートにどう-3.2dBmを反映させるかがキモです。
赤外線の受光素子は人間の目と同様に明るすぎる光は受信できません。
最悪の場合は受光素子が壊れます。
例えるなら人の目で太陽を直視するようなものだとおもってみてください。

近年のトランシーバはこのような一方的な高出力に対して対策がされており、出力側が動的にレーザーの出力を調整します。
スペックシートを見るとわかると思いますが、最大受信可能レベルが0.5dBmに対して、最低出力が-8.2dBmとなっいます。
同一のメーカーであれば、ほぼ送信側の最低出力が受信側の最高出力をうわまらないよう設計されています。
※仮にレーザーが強すぎる場合は、アッテネータという減衰機を利用することでレベルを減衰させることができます。(トランシーバが壊れたら手遅れですが…)

今回の場合だと、出力側の-8.2dBm ~ 1dBm から 3.2dBmを引いたレベルが、受信側の-18dBm ~ 0.5dBmの範囲に収まっているので、トランシーバー間のネゴシエーションによって適切なレベルに調整され、通信できるということになります。

SMFは劣化する
SMFは主な材質として石英が使われています。
時間とともに石英ガラス中の欠陥と、ファイバの被覆等から発生する水素が反応しOH基となります。
このOH基が赤外線を吸収する特性により伝存損失が発生します。
影響される波長は場合により様々ですが、SMFで利用しているバンドは広範囲で多からず少なからず影響を受けます。
特に影響を受けるのが、Eバンド帯の1360nm ~ 1460nmです。

しかし近年ではファイバの技術革新により、水素による伝送損失の影響はほぼないと言っていいレベルまで低減されています。
ただ予想される伝送損失がシビアな場合だと、使ってる最中に僅かなながらでも経年劣化で最低受信強度を下回ってしまうかもしれません。
また古いファイバの場合、世代的に水素劣化への耐性の低いものが使われていたりするかもしれません。

またこの水素劣化の影響は波長ごとに異なるため、実際に使用する波長に対応したパワーメーター(テスター)を用意しないと、問題が発生していることが分かりません。

余談ですが赤外線が吸収や反射される特性が、赤外線分光法という解析方法に利用されています。

パワーメーターを用意する
上記でもさらっと書きましたが、トランシーバを接続したNW機器でもレベルを取得できますが、あくまでファイバーとトランシーバで利用している状態のレベルです。
ファイバ単体で特定の波長での終端同士の純粋な減衰率を計測するためにパワーメーターがあるといいでしょう。

まあ軽くまとめると。

・利用する波長の特性を理解する
・しっかり減衰率を計算する&実際に計測する
・SMFは高価なため距離が長い場合は多重化の検討を

うわ超てきとー!

40Gの延伸が案外面倒だったのとWDMが神がかってた

明けましておめでとうございます(遅
本年も糞ブログをものすごく細々と書いていこうと思ってはいます。

いきなり記事の話題が飛びますが、いろいろあって去年の12月でSEをやめました。
1月から試される大地が主戦場なインフラ屋(?)として働いてます。
雪もいっぱいあるし、食べ物もナチュラルにおいしいし、ラリー屋には最高です。
なのでいきなりこうゆうネタふりです。

さて、試される大地で自分が主に利用しているデータセンタは自社運営のため、割と自由に使うことができます。
ただし自社とはいえファシリティ的には物理的な制約は当然あり、好きに壁に穴をあけたり地面を掘ったりできないので、なにかやろうとしたら既存設備や機器の仕様を考慮しつつ、関係各部署との調整が必要になります。

サービスとして利用しているデータセンタのように、依頼したら頼んだものが出てくるとか、サービスメニューにないから無理とかはありません。
その分データセンタの通常運用から外れる部分や仕様が確定していない事項に関しては、上記問題をクリアしてなんとかする必要があります。

そしてまだ入社後間もないですが、担当しているサービスの需要を見越して、増床したスペースに新規でサーバのためのネットワークを引き回すことになりました。

使用するインターフェイスはQSFP+が4本だけですが、さすがは北の大地の平原に建つデータセンタだけあって、距離にして2次元のどんぶり勘定だけで200メートルを超えています。
QSFP+は名前の通りで10GのSFP+を4本束にしてパラレルに通信できるようにしたものです。
つまり4本(QSFP+) x4(SFP+) x2(2芯)となり、実は32本もファイバーを消費します。
200メートル x 32本なので合計6400メートルです。
6キロもファイバー買ったらエラいコストです。
地区戦のラリーだとちょうどいいSSの距離くらいですね。

またエンドトゥエンドで一本のケーブルを引くわけではなく、途中でパッチパネルを挟むので、構築もエラい手間がかかる上にオペミスも誘発しますし、減衰とQSFP+のパラレル通信によるエラーも心配です。

軽く図で書きます。

40gsfpp
まあまあ、ありえないですね。
40Gでも近場だと一本のケーブルとして意識せず使えますが、距離があくとこうなっちゃいます。

当然のごとく同じ問題を抱えている人は全世界にいるので対策もあり、光の波長を変換して少ない本数のファイバーで多重に送信するWDMを利用したり、40Gを2芯のファイバーで利用できるトランシーバーがあります。
なんと1芯で双方向通信をしつつ多重化できるWDMも存在します。(両方から異なる波長に分けて照射するらしい)

あとは既存の設備(シングルなのかマルチなのか、パッチのつなぎとか距離など)で何等かの手段で多重化すれば本数が減ってすっきりして問題は解決します。

と、ここまでは現在自分の目の前にある問題ですが、これ以外の用途でもWDMさんは有能です。

光伝送装置自体は以前から存在は知っていたんですが、DC内のみの取り回ししか経験したことがなかったため、実は何に使うのかはよくわかっていませんでした。(おぃぃ)
100Gの伝送装置をDC内の他のテナントが利用しているのを見かけたこともありましたが、つなげるために必要なONUくらいのノリでなんでこんなごっついのが必要なのか深く考えた事がありませんでした。(長らくスループットよりかレイテンシ厨だったので…)

大体WDMの役割としては以下の感じでしょうか。

  • 1本のファイバーに通す波長を多重化してスループットを向上させる
  • 複数組み合わせると拠点間なんちゃってインテリジェントL2スイッチみたいに使える、常に1対1である必要はない

たとえば既設の10Gを40Gにしようとおもった場合、10Gを追加で3本敷設できないとなった場合、波長を多重化することによって既存のファイバーを利用してそのまま40Gを流すことができます。
使用例はこれだけではなく既設の設備の入り口と出口にWMDをつけるだけで倍以上のトラフィックが流せるので、バックボーンからDCやサーバルーム間まであらゆる場面で使えると思います。

データセンタが古く芯数や設備の問題で増速ができない、とお悩みの場合はぜひ波長の多重化を検討してみてください。
今は安くていいものがそこそこあるそうです。(噂話だけ聞いたのでこれから調べる)

ただレイテンシ厨としては変調がある分若干遅くなるのかな?という考えは残ります。

今までせいぜい10Gまでしか使ったことなかったし、ラック間までしかつないだことなかったしまじ北の大地鬼畜。

Nutanixの構成を考える時に知っておくといいかもしれないこと

普段Nutanixの構成を組むうえで普段考えてることを軽く説明としてまとめました。
ある程度要件をベンダーに伝えれば構成を組んでくれますが、自分のようにお客さんに直接セールスする場合は、聞き取りからNutanixを組み合わせるための知識が必要ですので。
間違いがあったら指摘お願いします。

このエントリーを書いている時点でざっくりと思いつくかぎり以下のとおりです。

– CPUリソース
– メモリリソース
– ストレージキャパシティ
– フラッシュ領域
– 筐体冗長性(Blockawareness)
– ハードウェアの冗長性

CPUリソース

ハイパーバイザにもよりますが、事前にリソースのサンプリングができる場合はVMwareのクロック足し算方式を使います。
この場合問題となるのはNutanixのCVMのオーバーヘッドの見積りです。
NutanixのCVMは設定上8コアをアサインする為(実際は8コアリソースをフルに使うわけではない)、従来のコア数分割方式を使うと相当のリソースに余りが発生してしまいます。
CVMが実際に消費するリソースはシステム全体の数パーセントと言われています。
またハイパーバイザのタスクスケジューラがすべてのCPUタスクを一度ばらすため、コア数固定のvCPU割り当ての考え方はナンセンスとしか言いようがありません。

脱線しましたが、多めに見積もってもCVMのオーバーヘッドはシステム全体の10%も見ておけば十分です。
実際に検証したところ、VDI100クライアントをNX3460の1ノードにフルのワークロードをかけた場合のCVMのリソース消費量は2GHz前後でした。
24コア2プロセッサーモデルT/Bなしで見積もり、2.4GHz * 24 = 総量57.6GHzなので大体10%前後という考えはあっていました、
あとはHV自体のオーバーヘッドを引けば実際にユーザVMが使えるCPUリソースが算出できます。
また極端に特定のCVMにワークロードがかかる場合は別ノードのCVMにバイパスして負荷分散することも可能です。

メモリリソース

これもまずCVMのオーバーヘッドを考慮します。
実際にCVMにアサインされたメモリをオーバーヘッドとします。
メモリは全体から見るとそんなに高いものではないので、最低でも全スロット16Gモジュールにしています。
もしメモリ不足が発生した場合、ハイパーバイザのメモリ圧縮やスワップアウトが発生して、CVMのインライン処理のパフォーマンスに影響が出てしまいます。

ストレージキャパシティ

Nutanixは内部的にキャシュ領域やCVMのオーバーヘッドがあるため容量の計算方法が複雑です。
一般的には公式のサイジングツールを利用します。
またBOMといって構成情報をそのままエクスポートできるので、ベンダーに構成の相談をする場合などに重宝します。
https://services.nutanix.com/

ストレージ容量の構成は単純に必要なキャパシティ容量のHDD/SSDを搭載していくだけです。
ファイルサーバなどストレージ用途等で極端に大きなキャパシティ容量が必要な場合は、HDDを大量に搭載できる(ただしユーザVMが動かせない)NX-6035Cなどヘビーストレージモデルも検討してください。

フラッシュ領域

DB用途などフラッシュのI/Oになるべく乗せたいという要望があると思います。(オールフラッシュモデルもありますが)
NutanixはエクステントストアというSSDとHDDのハイブリットで構成された、永続的にデータを保存する領域があります。
CVMは以下の階層で書き込み処理を実行します。

ローカルのSSD->ローカルのSSD2個目->クラスタ内ノードのSSD->HDD

SSDのエクステントストアがフルになると、設定された容量分だけHDDエクステントストアにデータをマイグレーションしSSDエクステントストアの空き容量を確保します。
またマイグレーションされたデータは常にモニタリングされ、必要に応じて移動されます。

SSDエクステントストアのサイズはの先程のNutanix Sizerで確認することができます。

リードについてはユニファイドキャッシュという透過的に動作するメモリとSSDからなるキャッシュ層があります。
ただ永続的ではないので、エクステントストアの容量で単純に計算したほうがトラブルがないでしょう。

ちなみにエクステントストアのSSDはパフォーマンス層やホットティア、HDDはキャパシティ層やコールドティアと呼ばれています。

筐体冗長性(Blockawareness)

Nutanixには筐体故障からデータを保護するBlockawarenessという機能があります。
RF2では1ブロック、RF3では2ブロックの故障まで保証されます。
ただし、故障発生時にデータの再配置が自動で実行されるため、再構成が完了後であればストレージの容量に余裕があれば、さらに追加で故障してもデータは保護されます。(CPUリソースは減っていきますが…)

Blockawareness構成の組み方ですが、クラスタ内の1ブロックに搭載されているノードの最大数の2倍の数が他ブロックにあることが必要です。(RF2の場合)
必要な条件がそろった時点で自動でBlockawarenessとなります。

少ないノード数でクラスタを構成する場合は、1ブロック1ノードや2ノードモデルを採用するとBlockawareness構成を組みやすくなります。
どのみち日本は100Vが主流なので、1ブロック2ノードモデルが最適かと思います。
参考ですが、必要となる電圧は「Hardware Administration and Reference」に書いてあります。

ハードウェアの冗長性

従来のインフラ基盤を運用してきたエンジニアはまずこの概念を変えないといけません。
なぜならNutanixで冗長化されているハードウェアコンポーネントは電源ユニットのみです。
ディスクはRAIDではありませんし、メモリミラーリングも使用しません。

Nutanixはソフトウェアによるミラーリングや、ノードのクラスタリングでデータを保護しています。
クラスタノード間でデータを複製するため、仮にノードが1台故障(たとえばハイパーバイザがインストールされたSATA DOMの死亡とか)したところでデータは消失しません。
これがNutanixは最低3ノード必要といわれる理由です。

RAIDなどノード単体に頼った冗長化を個別に実施してしまうと利用効率が低下します。
逆にNutanixはクラスタを構成するノード数が増えれば増えるほど、RAID構成と比較して利用効率が向上していきます。
セールスエンジニアは顧客から聞かれることが多い質問なので、概念を理解し説明できるようになっておいた方が有利です。

いろいろ書きましたが実際触って考えて悩んでみるのが一番早いと思いました。
Nutanixはいいぞ

ハイパーコンバージド製品(Nutanix)をエンタープライズで使って思ったこと

だいぶご無沙汰しています。

とある案件をきっかけに、社内ではNutanix & Azure屋が定着してしまいました。
オンプレ自作の魂の結晶のような働き方をしていましたが、環境が変われば人間変わるもんだなと思いました。

さて、昨今Nutanixを皮切りに各社からリリースされブームが巻き起こっている「ハイパーコンバージド」と称されるアプライアンス類ですが、ブームに半して個人的に心配していることがあります。

それはハイパーコンバージドと呼ばれているコンセプトを理解せず、「コストが安い」「拡張性がある」「ハイブリット構成が作りやすい」など、メリットや機能面ばかり押し出していて、本来目指すべきであるゴールを考えている人(考えられる人)がまだまだ少ない点です。
ついでにNutanixに限って言えば、アーキテクチャを理解してる(できる)人も少ないです。まあこれはエンタープライズな現場にいるせいかも。

でまあ、例えば以下のような矛盾を指摘します。

・コストが安い
別に安くないし、同じ容量で安いストレージならソフトウェア + IAサーバとかでよければいっぱいある。
有名なところだと例えばRAIDIXとか。
そうじゃないねん。

・拡張性がある
スケールアウト型のストレージなんていっぱるあるがな。

・ハイブリットなクラウド構成が作りやすい
これは同意。でパブリッククラウド使えるの?

あと勘違いで多いのが、クラスタで「CPUとメモリを共有できる」というのも多いです。
Nutanixに限って言えばあくまでストレージです。
CPU、メモリは物理ホスト上のみでしか展開できません。

ものすごーーーい複雑にできてるものを簡単に見せてるので、アーキテクチャや概念を理解しないままではミスマッチしか起こしません。
自分は日本のIT業界の歴史からこの懸念をすごい持っています。
とりあえず仮想化だけしておけばええやろ、みたいな。

では現場レベル、設計や運用者からみたハイパーコンバージドとはなんなのか。

自分は、「ソフトウェアの実装によるハードウェアレイヤーを抽象化すること」と説明しています。
自前で持つパブリッククラウドに近い感じですね。
実際ものの値段みた感じNutanixの大半ってソフトウェアと保守費用だと思います。

ハードウェアの抽象化って、うちのグループの某部隊もそうですが、物理コアとvCPUの数合わせるとか、ストレージの容量をLUNのパーティショニングで決めるとかやってる人々には、異次元の世界なんですね。
自分は仮想化を日本型と欧米型の二種類に勝手に分類しています。

日本型は仮想化するにも関わらず、大事なことだから2回と補足をつけて言いますが、VMwareのサイジングガイドなんぞ無視して、物理コア = vCPUという分けのわからないサイジング方式が根付いてるため、仮想化するコスト的なメリットが薄いです。
実際リソースはだだあまりしています。
(ライフサイクル運用が楽になるだろとかは後述)

上記日本型に対して欧米型は「リソースのプール化」が目的です。

欧米型はだだあまりしているリソースをプール化して有効活用してしゃぶりつくそう、というのが目的です。
これがハードウェアを物理の制限から解放する物理リソースのプール化です。
自分はこれを真の仮想化のメリットととらえています。

なので、日本のエンタープライズSEが好んで実行しているリソース分割型の手法では、そもそもハイパーコンバージドという考え方はマッチしません。

随時必要な時に必要な、CPU、メモリ、ストレージを足していって無限に拡張できる、これがハイパーコンバージドの目的と自分は考えます。

実際現場でみていると、ハイパーコンバージドとリソースプール化の概念をもっているSEは出会ったことがありません。

予算が組めないよーっておっしゃる人もいると思いますが、以下の2パターンどちらがいいと思いますか?社風もあわせて考えてみてください。

・一括で予算を決めて5年間はなにがあっても走り切る、そしてその後また同じ大規模リプレース後基盤移行作業
・1年ごとに予算を決めて小さい規模で拡張とリプレースをし続ける、基盤自体の移行作業は不要

という残業して帰ってきて疲れてかいた駄文でした。
Nutanixはいいぞ。(すくなくとも自分にはあってる)

あと仮想化にまかせた冗長化は微妙だからアプリレベルでも確保したほうがいいよ!