EVE-NGで限界までオーバコミット検証。オプションのCPU Limit、UKSMって？

2020年4月5日2020年12月10日

皆さんはネットワークエミュレータを動作させる時、ホスト側のスペックはどのように検討していますか？

仮想ラボ環境のノード数が１台や２台程度だとあまりスペックは気にしないと思いますが、複数台で動作させるとホストのスペック不足で仮想ノードの動作が不安定になることがあります。

そこで今回はNexus9000vを最大何台までCPU/Memoryをオーバコミットさせてまともに動くものかGCP上で検証してみました。GCP上での動作＆Nexus9000vが前提とニッチな検証となっていますが。。オーバコミットさせるとこんな動作になるんだ、ぐらいの感じで読んでいただければと思います。

また検証の過程でEVE-NGのオプション「UKSM」や、仮想ノードごとに設定できる「CPU Limit」について確認しています。特にEVE-NGのエミュレーションのパフォーマンスチューニング要素として、「UKSM」は結構重要です。この辺を確認している方は少ないと思いますので(そもそも興味ある人いるのか。。)、ご参考にいただければと思います。

今回検証に使った環境はこちらです。

• EVE-NG Community版 v2.0.3-95
• Cisco Nexus9000v version 9.3.1
• GCP asia-northeast1-b
• 各スペックはテスト項目参照
• UKSM -> disable

UKSMをDisableにせよ

さて検証の話に行く前に、聞き馴染みのないUKSMについて説明しておきたいと思います。UKSMはEVENGの仮想ラボ上でデフォルトでEnableとなっている機能なのですが、もし仮想ラボ上で複数のノードを動かす際にCPUが厳しい状況になりそうであればUKSMをdisableとしてください。なぜかというと、UKSM自体がCPUリソースを結構消費してしまうからです。。

UKSMの機能は以下のとおりLinuxカーネルの機能でメモリを節約するような機能のようです。

UKSM – “Ultra KSM (kernel same-page merging) is a Linux kernel feature that allows the KVM hypervisor to share identical memory pages among different process or virtual machines on the same server.” It can be disabled globally for EVE on this page. It is recommended to keep UKSM enabled.

https://www.eve-ng.net/index.php/documentation/community-cookbook/

メモリページを異なるプロセスでシェアしてメモリを節約すると書いてあります。この説明の通りメモリを単純に節約してくれる”だけ”であれば問題ないのですが、メモリの節約にあたりUKSM自身のCPUリソースも消費されます。今回検証した環境はかなりのメモリを消費する環境です（後述の試験内容をみていただければわかります）。

その結果、UKSMのプロセスにかなりのCPUリソースを取られてしまい各N9Kvの動作が非常に不安定になってしまいました。またUKSMをdisableにするとラボのN9Kvが安定することも確認しています。

ただし環境に依存する可能性もあります。というのも、UKSMは「メモリを節約する動作」です。N9Kvは後ほどご紹介しますが、一台8GBとメモリ大食いのイメージとなります。そのためUKSMが頑張って大容量メモリを節約しようと少し目立ってUKSMがCPUリソースを消費していた可能性があります。

いずれにせよ、UKSMはメモリを節約しようとCPUリソースを利用しています。今回は特にパフォーマンスの見極め的な検証を行うのでUKSMをdisableといたしました。UKSMは以下のように、仮想ラボ上のメニューからenable or disableにすることが可能です。

公式スペック計算ツールのご紹介

もうひとつだけ紹介させてください。ご丁寧にもEVE-NGの公式サイトで仮想ラボのスペック計算ツールが公開されています。

Nodes per lab calculator
It is recommended to use the “nodes per lab calculator” to achieve best performance and avoid overloading your EVE system.
https://docs.google.com/spreadsheets/d/1J6JIXHcid_A661grBOu73rjFOeoHPhGHi9iJb1zlQpE/edit#gid=0

ツールの中身を見てみると利用可能な「イメージの推奨リソース」が登録されていて、利用するイメージの仮想ノード数を入力することで、「ホストの推奨スペック」を計算してくれます（vCPUとメモリの合計）。大きめな規模の仮想ラボを検討の際には、かなりのハイスペックマシンがはじき出されると思います。

CPUはオーバコミットしながら使うもの！？なので、どこまで必要な情報かわかりませんが、参考までに確認してみるのがよいかと思います。

検証開始！まずはNexus9000vの最小リソース要件

それではようやく本題に入っていきたいと思います。今回はGCPのインスタンス上でたくさんのNexus9000vを動作させようと思いますが、一旦Nexus9000vの要件を確認します。CCO上（こちら）にはvCPU 1-8・メモリ 8GB推奨（最小4GB)と記載あります。

一方でEVEーNG上でNexus9000v のデフォルトテンプレートは以下の機器追加画面の通りvCPU 2・メモリ 8GBとなっています。

ドキュメント通りの最小スペックvCPU 1, メモリ 4GBで動作してくれると、たくさん詰め込めそうで嬉しいのですが、実際にどこまでスペックを落として動作するかは後ほどリソース割当変更しながら確認します。

CPU limitというオプション

機器追加の画面に「CPU limit」というオプションがあります。CPU limitの効果としては以下の通りです。

CPU Limit – CPU limit is used to limit CPU overloads during the nodes run time. It acts like a smart CPU usage option. If a running node reaches 80% CPU utilization, the CPU Limit feature throttles CPU use for this node to 50% until process usage drops under 30% for a period of 1 minute.

https://www.eve-ng.net/index.php/documentation/community-cookbook/

例えばvCPUを「１」とすると、仮想ノードのプロセスはCPU使用率100%まで利用できますが、CPU limitをONにすると50%程度に制限します。vCPUが「２」だと最大200%まで利用することころを、CPU limit ONで、最大100%程度に制限するといった具合です。

EVE-NGのマニュアルを確認していくと、この設定はONにすることが推奨のようです。仕組みとしては、EVE-NGの中を見ているとLinuxカーネルのcgroupsを利用しているようです。なぜ推奨なのかON/OFFで実際のラボでどのように動作に影響を与えるかテストを通して確認してみたいと思います。

リソース変更して単体の挙動確認

では上で述べたように、Nexus9000v単体の仮想ノードをリソースを変更しながら起動して挙動を確認します。ここで最小スペックを確認してガンガン詰め込んで動かしたいと思います！

GCPインスタンスはvCPU 8・メモリ30GBと余裕のある状態で、Nexus 9000v のテンプレートリソースを変更しながら、１台起動した時の挙動を見てみましょう。

vCPU	Mem(GB)	CPU limit	Result
2	8	OFF	正常稼働（起動時間 3:45）
2	4	OFF	起動途中で必ずエラー
2	8	ON	正常稼働（起動時間 4:09）
1	8	OFF	正常稼働（起動時間 4:08）
1	8	ON	正常稼働（起動時間 7:18）

まずメモリに関しては最小要件の4GBで動かすと起動途中にエラーがでてしまい動きませんでした。。（あれN9Kvのドキュメント？）。。まあバージョンによって挙動が異なるのかもしれませんが。。7GB、6GB、、と細かく刻んで確認することもできますが、面倒だったのでとりあえず最小メモリは「8GB」と考えます（意気揚々と初めた割には気持ちが弱い）。

vCPUに関しては「1」でも正常稼働することを確認しました。起動時間を見ていると、CPUリソースが多いと起動時間が早くなります。また「vCPU 1 CPU limit ON」、すなわちvCPU「0.5」とすると、ざっくり計算通り2倍程度の起動時間で正常起動しました。「vCPU 1 CPU limit ON」が最小vCPU設定といえるでしょう。

複数台でオーバコミットさせて動かしてみる

Nexus9000vの動作する最小リソースがvCPU 1（CPU Limit ON）, メモリ 8GBと確認したところで、今度は複数台で構成してテストしてみたいと思います。テストで利用したラボ構成は以下の通りです。順調に動作するならば、最大20台まで挑戦しようと思っています。そのために下の図の仮想環境を作ってみました。壮大ですね！

ではここから、テストケースを１から５まで用意して、条件を少しずつ変えながら複数台で動かすNexus9000vの動作を確認して行きたいと思います。どこまでまともに動いてくれるでしょうか。

テスト1 – Nexus 5台、メモリオーバコミット

単体挙動でメモリはシビアということを確認しましたが、ダメもとで、ホストメモリ（GCPインスタンス） 30GB に対して、Nexus 9000v x5台 Total 40GBと、複数台のケースでメモリオーバコミットさせてみました。結果はやはり２台ぐらいは起動にコケます。。どうやってもメモリのオーバコミットはNGのようです。

テスト2 – Nexus 10台、vCPUオーバコミット

今度はホストのvCPU総数 8に対してNexus 9000v Total 10台と、vCPUのオーバコミットの挙動を確認しました。ホストメモリは170GBまで上げています。

	vCPU	Mem(GB)	CPU limit
GCP インスタンス	8	170
Nexus 9000v 10台 Total	10	80	OFF

一斉起動で１、２台は正常に立ち上がらず。。何度かトライすると全台起動しました。CPUリソース不足で少し不安定です。コンソールでTopを実行し各プロセスを見ても不安定

テスト3 – Nexus 10台、CPU limit ON

テスト２の条件から仮想ノードのCPU limitをONに変更して挙動を確認してみました。

	vCPU	Mem(GB)	CPU limit
GCP インスタンス	8	170
Nexus 9000v 10台 Total	10	80	ON

テスト２とほぼかわらずの結果。コンソールでN9Kvを見るとTimeoutのメッセージで起動にコケていました。しかしコンソールから各プロセスをTopで確認すると、先ほどより安定して各プロセスにCPUリソースが回っていることを確認

テスト4 – Nexus 15台

どんどん仮想ノードを詰め込んでNexus15台とします。

	vCPU	Mem(GB)	CPU limit
GCP インスタンス	8	170
Nexus 9000v 15台 Total	15	120	ON

一斉起動すると５台ぐらい正常に立ち上がってきません。しかし何度かトライすると全台起動します。これは起動時の使用CPUリソースの分散につながっているためと思われます

テスト5 – Nexus 20台

今回のテストの最大構成となります。Nexus20台構成となります。

	vCPU	Mem(GB)	CPU limit
GCP インスタンス	8	170
Nexus 9000v 20台 Total	20	160	ON

一斉起動してもほとんどのノードで起動失敗してしまいます。タイムアウトエラーが頻発していたので、やはりCPUリソースが絶対的に不足していようです。「10台起動 -> 安定 -> 5台起動 -> 安定 ->5台起動」のように段階的に立ち上げ、各ノード起動時のフルCPU利用状況を分散させると、どうにか全台稼働しました。

最大構成でオペレーションは可能なのか？

段階的な立ち上げでなんとか全20台立ち上がりましたが、このようなギリギリの環境で立ち上げたこともありまともにオペレーションできるか不安がありました。そこで全台でIPv6 OSPFを回して見ましたが、これが意外に問題なく動作してくれました。相互にPing疎通も確認できましたし、CLIのレスポンスも概ね問題ありません。とはいえ、やはりギリギリの状況なことは変わりなく、プロセスのCPU使用率は以下の画面の通りでLoad averageは30越え。。

インスタンスのCPU使用率は以下のグラフの通り。

時系列を追ってみますと、15:25頃は15台で安定稼働させている状態でCPUにはまだ少し余裕あります。しかし15:40ごろから残り５台を投入し、全20台環境での稼働となると、ほぼ100%張り付き状態となりました。今回の条件だと20台が限界のようです。よく頑張ったよEVE-NG、というかGCPインスタンス。。

まとめ

結果としてvCPU 8、メモリ170GBというGCPのインスタンス上で、Nexus9000vが20台なんとか動くことを確認することができました！

仮にオンプレ環境で同等スペックを準備できるか考えてみると、vCPU8は最近のちょっと高いノートPCでもなんとかなりそうですが、メモリ170GBはワークステーションレベルじゃないと厳しいかもしれません。

うーん、、vCPUで頑張って16コアぐらいもたせて、UKSMをenableとするとメモリはもう少し減らしても動くかもしれませんが。。会社に1Uサーバが転がってなくて、結構な台数動かす必要があればホストの調達にGCPは手軽でいいですね（インスタンスコストが経費で落とせればなお！）。

今回の検証結果からの個人的メモは以下の通りです。

• デフォルトenableのUKSMはメモリ節約機能だがCPUパフォーマンスに影響あり。CPUリソースが厳しいときはDisableにしたほうがよい
• メモリのオーバコミットはNG（UKSMをenableとすることでオーバコミットできるかもしれません。今回は未検証）
• CPU limitは全体の安定稼働のためにONが効果的
• CPUリソースに関しては少しぐらいオーバコミット可能だが、仮想ノードの起動時はCPU負荷が高くオーバコミット時の複数一斉起動は結構キツイ（CPUリソースが足りなすぎで起動時にタイムアウトの発生とともにリブートを繰り替えす）
• 仮想ノードの段階起動でCPU負荷分散させることで、たくさん仮想ノードを起動できる。ただし時間はかかる
• 起動さえしてしまえばある程度はオペレーション可能

段階起動することでかなりのオーバコミットが実現できそうですが、起動に倍以上時間がかかるのは個人的にきついです。サーバ系のイメージはVMののりでオーバコミットさせても問題ないと思いますが、QEMU系仮想アプライアンスのオーバコミットは無茶できないですね。

以上、オーバコミットテストでした！