BIG-IP+VDI環境におけるVDI最適化パックの導入ついて
ついこの間、VDI最適化パックの導入について検討する機会がありましたので、その時の調査結果をまとめていきたいと思います。
VDI最適化パック
音声、ビデオ、デスクトップ共有の表示をリダイレクトし、仮想インフラに悪影響を与えたり、ネットワークに負荷をかけたりすることなく、VDI上でTeamsなどを使ってWeb会議を行うためのものとなります。
導入する環境
F5社のBIG-IP APMとVMware社のVDIを組み合わせたVDI環境。
以下の図のように、外からアクセスする場合はBIG-IP APMを通ってからVDIにつながる環境です。
検討開始
さて、導入するにあたってまずはVDI最適化パックの要件を確認する必要があります。
調べてみると、TCPポート 9427を使用するとのこと。
あれ、もしかしてマルチメディアリダイレクト（MMR）を使ってる？ってことでVMwareの頼りになる人に問い合わせしてみる。
すると、詳細な情報はなかったけどその可能性が高いとのこと。
じゃあBIG-IPでMMRってできたっけ？ってことで今度はF5社に問い合わせ。
するとBIG-IPではMMRをサポートしていないと。
えー、、、マジか。。。
そこからどうしようってことで、実現可能な構成を考えてみる。
考えついたのはBIG-IPとVDIの間にUnified Access Gateway（UAG）を挟んで実現する方法。
外部→BIG-IP→UAG→Connection Serverって流れですね。
こうすると認証はUAGで行うことになるのでBIG-IPのAPM機能は使わないことになってしまう。
BIG-IPはUAGに通信を振り分けるロードバランサーの役割だけになってしまうのでもったいないなぁと思いつつ、最適化パックを入れるためには致し方ない犠牲かと。というかこれしか思いつかなかった。
結局この後いろいろあって、VDI最適化パックの導入はなくなったんですけどね。
いつかBIG-IPでMMRサポートされないかなぁ。
vSphere7.0 update2 リリース
2021年3月9日にvSphere7.0 update2がリリースされました。
今回はU2の新機能についてまとめたいと思います。
AIと開発者向けインフラストラクチャの提供
- NVIDIA GPU とマルチインスタンス GPU の幅広いサポート
- NSX Advanced Load-Balancer Essentials を含む
- Kubernetes Supervisor は最新の Kubernetes1.19 リリースで更新される
- プライベートレジストリをサポート
インフラとデータのセキュリティ強化
- vSphere Native Key Provider で暗号化と高度なセキュリティを有効に
- AMDのvSphere ポッド用の機密コンテナは使用中の最新アプリケーションを保護
- vSphere セキュリティ構成ガイド、製品監査ガイド、および FIPS 検証により、セキュリティとコンプライアンスの監査が容易に
その他、一部古い機能の廃止やセキュリティ強化、バグフィックス等が含まれています。
Kubenetesについてはいずれ勉強したいと思っているんですが、ハードルが高くてなかなか触ろうと思えないんですよね。
何かいい教材ないかなー
vEXPERT 2021を受賞しました
vEXPERT 2021を受賞しました。
これで3年連続となります。
今年は社外活動も積極的にできればと思いますが、どうなることやら。
4年連続で受賞できるよう頑張ります！
Flashのサポートが終了します
Flashのサポートが2020年12月末で終了します。
それに伴ってvCenter 6.5以前などのバージョンアップが必要となり、現在対応に追われている方も多いかと思います。
正式は対応方法はもちろんバージョンアップなのですが、なんとか時間稼ぎ延命することができないかと調べてみた結果を書いていきたいと思います。
VMwareのKBによると、やはりFlashのUIの使用は推奨しないと書いてありますね。
https://kb.vmware.com/s/article/78589?lang=ja
ただ、一時的な回避策も書いてあるようです。
方法は上記URLのページにも書いてありますが、Flashのホワイトリスト（mms.cfg）に登録しておくこと。
ただし、この手法で回避するにはエンタープライズ版のFlashがインストールされている必要があります。
ブラウザにインストールされているFlashではできないので注意。
その他の方法としては、ブラウザの自動アップデートを無効にしておくという方法もあるようですが、調べてみると2021/1/12を迎えるとアップデートをしていなくても自動でブロックされてしまうといった情報もありますので、この方法では回避できなさそうですね。
とはいえ1/12までは大丈夫そう？ではあるので短い期間ではありますがそれまでにバージョンアップができるかというところでしょうか。
いずれにしても、上記の方法はあくまでも回避策ですのでやはりちゃんとバージョンアップしないといけないですね。
皆様も年の暮れでお忙しいところだと思いますが、しっかりとした計画のもとVMware環境のバージョンアップをちゃんと行っていきましょう。
vSphere 7 Update 1公開！Tanzuが変わりました
2020/10/7に公開されたvSphere 7 Update 1と一緒にTanzuにも変更が加えられましたので、今回はそれを書いていきたいと思います。
・VMware Tanzuについて
VMware TanzuはVMworld 2019で発表されたソリューションで、VMware環境でコンテナを稼働させることができる、というものです。
発表された当初は今後のインフラストラクチャの世界がアプリケーションまで広がるということで期待されていましたが、なかなかどうして技術的なハードルが高いこともあるのか、あまり普及は進んでいないように見受けられます。
・Tanzuの変更点
そんなTanzuですが、これまで導入するにはVMware Cloud Foundation（VCF）の購入が必須だったのがvSphere 7 Update 1では不要になりました。
また、NSXも必要なくなったということなので、技術的なハードルはぐっと下がったのではないかと思います。
また、名称も「vSphere with Tanzu」に改められました。
導入のハードルは下がったように思えますが、なかなか導入することによってどんなメリットがあるのかが分かりにくいのもTanzuの課題なのかなとも思います。
それを理解してもらうのが私たちの仕事といわれるとそれまでなのですが、多くの企業にVMwareのコンテナを導入するに至るまでのハードルはまだまだ高いのが現状なのではないでしょうか。
NSX ALBのSplunk連携
今回はNSX ALBのメトリックをSplunkで取得できるようにしてみたときのことを書いていきたいと思います。
まず構成はこんな感じ。
NSX ALBのContorller Clusterからオンプレ上に構築してあるSplunkのHeavy Forwarderを経由して、Splunk Cloudにログを送信します。
・NSX ALB側の設定
NSX ALBのNotification設定でSyslog Serverの設定を行います。
ただ、Splunkに連携する場合のログフォーマットをJSONにする必要があったのですがGUIの画面上だとフォーマットの設定項目はありません。
なのでControllerのCLIでフォーマットをJSONにしたSyslogの設定を入れる必要があります。
設定は以下のページを見て設定。
Supported Syslog Formats
こんな感じで設定してみました。
FormatがSYSLOG_JSONになっています。
Syslogの設定ができたら、NSX ALBのAlert Actionで作成したSyslogを使用するように設定して、NSX ALB側の設定はこれで終了です。
・Splunk Heavy Forwarderの設定
次に、Splunk Heavy ForwarderでNSX ALBからログを受け取るように設定します。
まずHeavy ForwarderにAviVantageのAdd-onをインストール。
そして、NSX ALB側のSyslog設定の通り、UDP 514で受け取るように以下のように設定します。
このとき、Source Typeにはavi:eventsを設定します。
以上でHeavy Forwarderの設定は終了です。
Splunk Cloudへの連携設定をしていない場合は適宜設定してください。
・Splunk Cloudの設定
Splunk CloudにはAviVantageのアプリケーションをインストールしておきます。
すると、AVI用のダッシュボードがトップページ作成されるのでそちらを確認。
Heavy Forwarderからログが連携されていれば以下のようにデータが見れるようになっています。
ただ、画面上部の色分けされて数字が書いてある部分がなにをやっても数字が変化しません。
どうやらログがちゃんと見れていないっぽい？
そんな時は該当箇所をクリックするとサーチコマンドがどうなっているのかが確認できます。
確認するとこのような画面になるのですが、(index=* AND sourcetype=avi:events) controller=* severity=INFO tenant=* というコマンドでサーチしているらしく、引っかからずに0件になっていますね。
ただ、「controller=*」を除外してサーチすると引っかかるのでログは送られてはいるらしい。
どうやらSplunkの収集方法に問題がありそうな感じがしますね。
この辺りはSplunk側に修正依頼をだしつつ、改修待ちって感じでしょうか。
とりあえずSplunk Cloudにログ連携はできるようになったので一安心。
NSX ALBのCLIでJSON形式のSoslog設定を作成しないといけないのが面倒だったので、GUI上で選択できるようにしてもらえるとありがたいですね。
NSX ALB Service Engineのメモリサイジング
今回はService Engineのメモリサイジングについて調べた内容をメモ程度に書いていきたいと思います。
Service Engineが通信のロードバランスを行う際、いくつまでの同時接続数を処理できるかを左右するのはメモリの容量となります。
そのため、Service Engineをデプロイする際、本番サービスでどの程度の同時接続数が発生するのかを事前に考慮し、その数を処理できるだけのメモリを割り当てておかなければなりません。
1. Service Engineに設定可能なメモリ容量
Service Engineでサポートされるメモリ容量は1～128GB
※AviVantageでは最小でも2GB以上を設定するよう推奨しているようです。
2. メモリサイジングの考え方
AviVantageによると、Service Engine（SE）で処理可能な同時接続数は以下の式で計算できます。
処理可能な同時接続数 = （（SEのメモリ容量 － 500MB － （100MB×vCPU数）） × 接続パーセンテージ）÷ 1接続あたりのメモリ容量
SEのメモリ容量はそのままService Engineに設定したメモリの容量ですね。
500MBというは、SEが稼働するために使用されるベースのメモリ容量です。
そして、Service EngineはvCPU毎に100MBのメモリを割り当てるため、それらの分をメモリ容量から引いたものが接続を処理するためのメモリ容量となります。
接続パーセンテージというのは、Service Engineに設定された接続を処理するための共有プールのパーセンテージのことです。
Service Engineでは接続を処理するためのメモリ容量を共有メモリプールとして保持し、それをConnectionsとBuffersの2つのコンポーネントに分割しています。
この２つのコンポーネントが使用するメモリの容量はService Engineの「接続メモリの割合」という項目で増減させることができます。
この割合はそれぞれに最低10%を割り当てる必要がありますので、どちらかを100%にすることはできません。
また、設定は新しく作成されるService Engineだけに適用され、既存のService Engineには適用されないので注意。
この中のConnectionsが接続を処理するための項目で、Buffersはパケットをキューに入れておくための容量です。
Buffersは、例えば【クライアント】-【Service Engine】-【サーバ】という構成の中で、クライアントとService Engine間のネットワークで遅延が発生しているが、Service Engineとサーバの間では遅延が発生していない場合、サーバからクライアントへの応答をService Engineがバッファ領域に溜めて少しずつ応答を返していくという動作をするために必要な容量となります。
ですので、Service Engineのメモリ容量は、同時接続の処理量だけでなく、Buffer分も含めて考えなければなりません。
1接続あたりのメモリ容量は異なるレイヤー毎の1つあたりの通信量となります。
例えば、こちらはAviVantageが示している標準的なメモリ消費量です。
L4：10KB（0.01MB）
L7：20KB（0.02MB）
L7+SSL：40KB（0.04MB）
1接続あたりこれだけのメモリを消費しますので、どのレイヤーの通信をロードバランスするのかも事前に考慮する必要があります。
以上がService Engineのメモリサイジングの考え方となります。
仮に、50%の接続パーセンテージで8vCPU、8GBのService Engineで、L4の通信をロードバランスする場合、処理可能な同時接続数は以下のようになります。
（（8000 － 500 －（100×8））× 0.5 ÷ 0.01 = 335,000
接続パーセンテージについては実際の環境で使ってみてどの程度にするかを考えていかなければならないので、運用の中で少しずつ修正していく必要はありそうですね。
Service Engineのメモリサイジングの考え方でした。
