Tanzuを動かす前提条件として

VMware Cloud Foundation(略してVCF)は、所謂「プライベートクラウドを自動構成する」機能でありまして、VMware上の機能をフル活用していろんな機能を実装します。特にVMware NSX-T Datacenterの機能を駆使してSDN(?)的なものが構成できるというのが大きな特徴のように思えます。

vSphere7.0から、Tanzuと呼ばれるKubernetesエンジンを稼働可能なコンテナインフラストラクチャを組むことが出来るようになりました。が、このTanzuを利用するには、その環境内にワークロード管理ライセンスを包括したESXiライセンスが必要で、どうやらこのライセンスを適用するにはVCFを構成した上での環境が必要そうです。

実際にお仕事で使うのかどうかはさておき、知っておくには越したことはないなということで、VCF環境の組み立てに挑みました。
しかしながらどうにも前提情報が無く、苦労したので備忘録として情報を残す次第です。取り扱う内容としては

• VCFを組む前提構成とは？
• VCFを組む上ではまったポイントは？

と言うところが述べられたらなと思ってます。

後述しますが、結果的にVCF環境を構成することは出来ませんでした。この辺りも合わせて述べたいと思います。

VMware Cloud Foundationを構成するには

まず、最低限以下の構成が必要です。

まずもって、事前にESXiサーバを構成する必要があります。必要な要素としては、上図にも示していますが、

• 管理用のインタフェースとしてvmnic0に必要な設定を実装
• vmnic1を接続するスイッチに対してMTU1600以上の設定が必要(9000Bytesが推奨されるのかな？）
• 時刻同期の設定が必要
• 名前解決の設定が必要（正引きだけじゃだめ。逆引きもないとVerificationで撥ねられるよ）
• VSANを使用する想定の下、1ノードあたり2台以上のCapacity層が必要

という感じの構成が必要になってきます。そして後はCPUとメモリ。これは予想外にそれなりの対応が必要です。

ざっくり組み方

VCFは実に面白い構築手順を持っていて、

• CloudBuilderと言うアプライアンスを構成する
  • 4vCPU 4GB RAMの構成でデプロイメントされる
  • どうやら関連パッケージソフトウェア全てを丸抱えしてるらしく、パッケージ容量が20GBもある
• CloudBuilderのWebGUIへアクセスし、以下の流れで自動構成を指示する
  • 所定のExcel様式をダウンロードする
  • Excel様式に必要なパラメータを入力する（このとき、VCFのライセンスキーは空にしておくこと。入れるとバグでエラーになる）
  • パラメータシートをアップロードする
  • Verify処理が行われ、通過すれば構築フェーズに入る
  • 数時間程度コトコト煮込む

という感じになります。すると、vCenter構成から順次自動的にデプロイメント処理が行われて、気づけばいつの間にかプライベートクラウドが出来てるじゃないか！という感じになります。
EMCが販売しているVxRAILとかだとより安全性を高めるため、vCenterの実装が少々特殊になっているようで、VxRAILを展開対象にする場合は別メニュー、別パラメータシートが用意されているようです。んまー、Excel様式で設定シートが必要であり、それをアップロードすることで児童厚生が可能になるというのは何とも面白い仕組みだなーと思ってます（MS嫌いな人には苦痛かもしれませんが）。

こちらはパラメーターシート

実はCPUとメモリ構成もとっても重要

VCFは以下のものを配備してくれます。

• vCenterサーバ(Small以上）
• NSX-T環境
  • NSX-T管理サーバ兼コントローラ(3ノードクラスタ構成)
  • NSX-T管理下の分散スイッチ（vMotionセグメント・FTセグメント・VSANセグメントも合わせて構成）
  • NSX-T Edgeノード
• NSX-T環境などを統括するSDDC Manager
• VSANストレージ及び必要となるVSANストレージポリシー
  • ハイブリッド構成の場合はRAID1構成に縛られる
  • オールフラッシュ構成の場合はRAID5/6をイレイジャーコーディングで実現することが可能

ここで、NSX-T環境を構成するためにそれなりのCPUを構成する必要があります。
というのも、NSX-Tコントローラの負荷が半端ないからです。

上図はNested環境でNSX-Tコントローラを動かしたときの状況です。ここで動いているのはVCF環境ではなく、単独のNSX-T環境を構成しようと試みたときの状態で、VSAN File service ApplianceとNSX-Tコントローラ以外は動かしてません。にも拘わらず、CPUは8割程度を消費し、メモリは16GBをフルに消費しました。留めに言うと、VSANのファクトチェックがうまく動かないぐらいの悲鳴をこのノードは上げておりまして、こりゃあかんな・・と思った次第です。

当然nested元のESXi物理サーバも負荷上昇し（というか、殆どのリソースを食い尽くして）、ファンの音がでかくなってました。そのぐらいNSX-Tを動かすのはそれなりのハードウェア能力的なパワーを必要とします。

今回使用している環境はIvy Bridge Xeon E5-2430 v2をHT有効、12スレッドのウチ8スレッドをEVC(Sandy Bridge Generation)で動かしてる状態になるので、実際の負荷はもう少し低いのだろうとは思うのですが、正直言ってHaswell-EPぐらいのプロセッサが本来必要ではないかなと感じました。Sandy Bridge-EP/ENでも、最上位のプロセッサであればギリギリ対応できるかもしれませんが、VMwareリソース管理上の観点から、少しクロックは高めのプロセッサを選択した方が良いように思います。

プロセッサ能力・メモリ容量が足りないとどうなる？

ずばり、「NSX-Tコントローラを導入するところで延々失敗リトライを繰り返して、最終的にはエラー終了する」となります。

このとき、何が起きていたかというと以下のような流れになっています。

問題になっているのは2番目の工程です。実はNSX-Tコントローラの構造上、内部では相当数のJavaプロセスが動作します。Javaプロセスはリソース不足となってしまうとそのプロセスは容易にダウンします。結局の所、CPU遅延が持続したり、メモリ不足が発生すると起動したいプロセスが状態維持できずにダウンするんで、延々と起動しては落ちる状態を繰り返します。そして最終的に構成できないと分かったCloudBuilderはそのノードは構成失敗と見なしてノードを削除し、再デプロイするんです。

しかし、プロセッサがそもそも力不足な我が家では何度デプロイしようと状況は変わらず、結果的に1ノードだけしかまともに構成できずに他のサーバは軒並み失敗し、VCF構成はかなわなかった・・・という感じになりました。

また、NSX-Tを単独導入するにしても、ExtraSmall(2vCPU/8GB)では処理が出来ずにNSX-Tコントローラを構成することは出来ず、E5-2430v2ベースだとHTありで8vCPU、HTなしで4vCPU、そしてメモリは16GB以上が必須であることがよく分かりました。DDR4を使用するようなHaswell-EPやBroadwell-EPだとExtraSmallな構成でもOKなのかもしれません。

何にしてもこのままじゃ悔しいだけなので

リベンジはしたいなーと思ってます。ただ、それなりのCPUが必要とも分かったので、その上で取り組む必要があるかなーと思います。
恐らく推測ですが、TanzuはNSX-TをCNIに見立てて動作するKubernetes環境なのではないかなと。その時のCNIの動きは知りたいし、ぶっちゃけコンテナ部分はどうレイヤリングして動くのかが分かりませんので、そこら辺を意識しながら触りたいなーと思ってます。

OpenShift Enterpriseはなかなかにしんどかったです。それより楽な製品であることを祈りながらって感じです。