VMwareを使用したHCI（ハイパーコンバージドインフラストラクチャー）の設計概要について記載します。
仮想環境を簡単に導入できる案内がされており、実際導入やリプレースは「なるほど簡単だ」と感じますが初期設計は思いの他、ヘビーな作業だと感じています。
言い訳になりますが、可能な限りサーバメーカを調べて汎用的な注意事項を書いていますが、すべてのモデルやメーカーに共通するほど調べ上げた自信はありません。
このため、詳細設計ではSIerなどのパートナに確認してください。
VMware HCIのメリットについては以下の通りです。
・設置作業の簡易化
基盤構成するサーバを、セットアップ/テスト済の状態で送付されるので、構築にかかる役務作業を軽減できます。費用に見返りがあるかどうかは構築ベンダによるため確証は持てません。
・可用性
サーバ、電源ユニット、ディスクドライブ、ネットワーク経路などの主なコンポーネントを冗長化することで、容易に単一障害点によるシステムの停止リスクを回避できますが、これはHCIというよりレガシーなオンプレミスと比べた仮想化の利点になります。またvSphereを使用することでホストレベルでのフェールオーバー機能(vSphere HA)、ネットワーク経路の冗長化(vSphere NIC Teaming)が使用できます。
・拡張性
システムが稼働するサーバは1クラスタあたり3台から最大64台まで拡張できます。また、サーバのCPU種類とメモリ容量、ストレージに搭載されるディスクドライブの種類と数量は要件に応じて選択が可能です。
vSAN（SDSの一種）を使用してESXiホストの内蔵ディスクを仮想化することで、1つの共有ストレージ(データストア)を構成します。これによりスケールアップ・スケールアウトなどの柔軟なストレージ拡張が可能になります。データストアはx86サーバの内蔵ディスクで構築できるため外部ストレージは不要ですが、実効容量のサイジングが難しいのと、数100TBクラスの大規模ストレージを組みたい場合にSSDでもディスク本数が足りないことが想定され、ストレージ容量がHCIの導入の鍵になる気がしています。
ストレージ拡張のためにサーバ台数を増やすのはHCIのデメリットになるかと思います。
HCIのデメリットは所々の制限になります。
例えば、最大64台のサーバで構成できますが、3台以上である制限があります。
2台で構成する方法もありますが冗長性の問題から推奨できない感がします。
RAID６を構成にする場合には６ノード以上が必要だったり、さらに最低３ノードは同一のハードウェア構成の必要があるベンダーもあります。このような仕様上の制限があり、初期設計の段階でわからないために右往左往しましたので、私の理解している範囲で設計のヒントをまとめようと思っています。
オンプレミスで仮想環境を作成する案件ですと、事情がありクラウドサービスを積極的に採用できない案件が多く、それ故にハードウェアを段階的に導入することも難しいことが予想されます。償却期間の5年程度の利用を導入時に見込めと言う感じですね。
保守期間５年、長くても７年位の保証期間（しかも段階的に保守費用が上がる）にハードウェアを追加増設することは割とハードルが高い思いをしています。稟議書を通すという作業がです。
社内システムですと固定資産の管理も情報システム部が財務部と連携して行うこともあり、増設作業とIT以外のスキルも必要なため大変です。
CPU
オーバーコミットはvCPU数×２を目安にする（絶対でないが破綻した経験もない）。
個人な経験ですが、LAMP環境や社内システムで使用した実績では上記をベースラインにすると失敗が少ないと思っています。
データベースサーバ、認証サーバなど、パフォーマンスを落としたくない仮想サーバがある場合に固定でvCPUを割り当てる方針にしています。
仮想化に移行するサーバのリソース監視がされていてCPU、メモリ、ディスク、ネットワークの使用率が記録されていれば有用なので活用しましょう。
CPUのサイジングを数値を用いて簡易に行う方法は次の通りです。
サンプルの環境はIntel Xeon E5-2650 v3を使用していますが、このCPUは10コア20スレッドのCPUです。このCPUがESXiでどのように認識されているかというと、10CPUs× Intel Xeon E5-2650 v3 2.3Ghzと認識されています。
つまり、10個の2.3Ghz CPUがあると認識しています。もちろん仮想サーバに割当可能なCPUは20でスレッド数になります。スレッドは2.3Ghzで動作するのか半分の1.15Ghzで動作するのかは置いておいても、コアとクロックと現在のCPU利用率から必要なCPUが計算できます。仮想サーバに割り当てるCPUは偶数を使用することが推奨されています。奇数を割り当てても、余った論理CPU（スレッド）は他の仮想サーバが使うことが無いため非効率になります。
ESXiのCPUリソース表記も使用コア数ではなく使用クロック（MHzやGHz）表記になります。
| 移行対象 | CPUコア数 | 現在のクロック数 | 平均CPU利用率 | 必要なCPUクロック数 |
| サーバA | 1 | 2.0Ghz | 50% | 1.00Ghz |
| サーバB | 1 | 1.8Ghz | 25% | 0.45Ghz |
| サーバC | 1 | 2.6Ghz | 40% | 1.04Ghz |
| サーバD | 2 | 2.0Ghz | 20% | 0.8Ghz |
| 計 | 5 | – | – | 3.29Ghz |
| 以降先 | CPUコア数 | CPUクロック数 | 最大CPU利用率 | 必要なCPUクロック数 |
| ESXiホスト | 4 | 2.0Ghz | 80% | 6.4Ghz |
数字で見せることを要求される場合、上表の感じにまとめています。
「こんな感じで空きがあるんで、ESXiに統合しても問題なさそうです」って言う感じです。
メモリ
メモリがオーバーコミットすると、スワップをディスクに作る可能性があるため、オーバーコミットを前提で設計することはお勧めしません。単純に対象サーバの最大使用量のメモリ容量を積み上げています。
メモリはCPUやディスクと比較して仮想化しても、どうにもならないケースが多く、処理のボトルネックになり易いため必要な容量を搭載しておきましょう。有効なのはメモリの共有化位でしょうか。
特に大規模な夜間バッチやスパイクが予想されるWebシステムを仮想化基盤にある場合にはメモリは潤沢にあった方がいいです。
オールフラッシュにしてもスワップされたりメモリバルーンを作成されると処理速度が落ちてしまいます。
ネットワーク
1Gbpsではなく10Gbpsまたは25Gbpsで設計します。
ストレージに使用されるSDS（vSAN）は筐体間で物理ディスクを共有しいるため、ネットワークが簡単にボトルネックになります。最低でも10Gbpsを推奨します。
ストレージがオールフラッシュの場合には10Gbps以上の帯域が必須になります。
SAN（FC）ストレージからのシステム移行では25Gbpsがパフォーマンス上、必要になるかと思います。HCIのノード間のディスクはネットワークを使用して論議的に管理されていますので、ネットワーク帯域の圧迫はディスクのパフォーマンスに影響します。
また、ネットワークカードの発熱過多でスループットが落ちた経験があるので、実績のあるカードがお勧めです。
ストレージ
図示すると下図の感じになるかと思います。
すべてのストレージがSSDのオールフラッシュとHDDとSSDを混在させたハイブリットがありますが、オールフラッシュを選択した方が無難だと思います（推奨します）。
HDDでSATAやニアラインを中心にできるシステムならともかくSASでは１本辺りの容量が900GB程度なので容量が足りなくなる可能性があります。ディスク容量よりCPU性能が求められるシステムなら良いと思いますが・・・。
ファイルサーバやデータベースサーバなどストレージ量が増えそうなサーバは別のサーバ（ハードウェア）を用意する考えもわからなくはないですが、HCIでオペレーションを一元化することにより柔軟なシステムにすることにはならないです。素直に3層仮想化でSANストレージのボリュームを別にディスク設定した方が効率は良いと思います。
バックアップサーバや過去データ保存用のサーバなど非機能要件に対応するサーバはHCIで運用するのは難しいこともあるかと考えますが、HCIを導入するなら機能を実行するサーバはHCIに乗せることを推奨します。
vSANは複数サーバの内蔵ディスクをまとめて一元管理（vSANデータストア）します。
キャッシュディスク層：キャッシュ用のSSDは常に書き込みが発生するためDWPD(Drive Writes Per Day)の数値が大きいディスク（書き込み用SSDなど）を使用します。使用する容量が600GB程度と限定され、余った領域を循環的に使用することでSSDの寿命を長くします。オールフラッシュ構成の場合、キャッシュディスクは100％書き込み用途で使用されるため、ディスクグループのSSDより寿命が短くなります（ハイブリットは書き込み30％、読み込み70％）。
また、ディスクグループ単位で物理SSDが1本必要になりハイブリット構成でもキャッシュディスクはSSDを使用することが推奨されています。上図の場合、1物理サーバ辺りディスクキャッシュ用SSDが3本必要になります。
キャパシティ層：いわゆる実効容量（ストレージ容量）になります。RAIDコントローラやサーバのバックプレーンの関係か正確にわかりませんが、1サーバで1ディスクグループ、SSD25本構成はできません。7本程度のSSDでまとめて1グループ構成となります。但しサーバメーカやSSDの種類（SATA、SAS、PCIe、M.2）により構成できるディスクグループの数やグループを構成するSSDの容量、本数が変化します。
vSANの可用性
vSANでは可用性ポリシーを FTT (Failures To Tolerate)といい、仮想サーバのデータを多重化することで可用性が向上できます。また多重化されたデータを監視するため、Witness（ウィットネス：証人）データが必要になります。Witnessはサーバデータでは無いのでデータ領域（vmdk）のように大きなファイルではありません。
| FTTレベル | 多重化数 | 制限 |
| 0 | 0 | 無 |
| 1 | 2重化 | 3ノード（ホスト）以上が必要 |
| 2 | 3重化 | 5ノード（ホスト）以上が必要 |
| 3 | 4重化 | 7ノード（ホスト）以上が必要 |
FTTごとに保存されるデータは下図の感じです。
FTT1以上は Witnessが必要になります。
FFT1で Witnessは1、FFT2で Witnessは2、FTT3で Witnessは3作成されます。
図が見にくくなるので、FTT3のイメージが記載できませんでした。
vSANの標準はミラーリングなので、FFT１でもSSDがもったいないと思われることがあるかもしれません。そもそもSSDはHDDに比べて故障率が低いため、RAID5やRAID6にあたる機能がほしいところですが、ちゃんとあります。
但し、RAID5は4ノード以上、RAID6は6ノード以上が必要になり、かつオールフラッシュでのみ実装が可能です。ハイブリットはミラーリングのみ構成可能となります。
ディスクでRAID5を構成する場合、一般的に最低3本、RAID6なら4本が必要最低本数になりますが、vSANでは4ノード（RAID5）、6ノード（RAID6）になります。プレゼンで指摘されたことがありますが、RAID5は1ノードが停止してい稼働し続ける、RAID6は2ノードが停止しても稼働し続けるのに必要な最低ノード数（仕様）という説明をしました。
RAID5はFTT1、RAID6はFTT2になります。
FTT1のミラーリングと実行容量を比較するとRAID5、RAID6は消費容量は節約されます。
同一のディスクグループと本数で構成した場合、実効容量は以下のようになります。
ミラーリング：FFT1 実効容量50％
RAID5：FFT1実効容量75％
RAID6：FFT2実効容量65％
なお、vSANストレージの総容量の約30％は開けておくことが推奨されています。ストレージ使用率80％を超ええるとストレージのパフォーマンスが悪化し出します。
どのディスクフォーマットにせよ空容量が少なくなるとディスクがボトルネックになる感はあります。
ご参考まで