はじめに
本記事ではIBM Turbonomic v8.7.3（2022年11月リリース）にてサポートされた Hybrid Support の概要と実際の導入例などをご紹介します。
"Hybrid Support"とは？
まずTurbonomicの導入方式には以下の4パターンがあり、これまで、SaaS版の利用に際しては、オンプレのVMware環境への接続が出来ないという制限がありましたが、今回、v8.7.3以降でこのハードルを越えるソリューションの提供が始まりました。この構成をSaaS版の"Hybrid Support"と呼んでいます。
SaaS（外部インターネット環境）からオンプレのVM環境への接続方式は？
一般的にオンプレのVMware環境については、外部インターネットからの通信は当然遮断されているかと思います。（セキュリティの観点からも、例え特定のネットワークポートであってもInbound方向へは解放されないという運用は、極めて一般的かと思います。）
一方で、オンプレから外部インターネットへの特定ポートのOutbound通信は許可されるかと思いますので、今回はその範囲内でソリューションを提供するものになります。
具体的には以下図の様に、オンプレ環境内に一つブリッジとなる "Turbo SaaS Client" という仮想マシンを立てて頂き、このSaas Clientからの外部向け特定ポートの通信のみを許可頂くことになります。
導入手順
- 許可が必要になるネットワークポート番号や、導入手順の詳細はこちらのマニュアルをご参照下さい。
- インストールに必要となるOVAは、実はオンプレ向Turbonomicのインストールに用いられるOVAがそのまま利用可能です。（初期コンフィグの作成コマンドが t8cClientInstall.sh に変わるのみ）
SaaS Clientの要求スペック
- 例えば、約5000台の仮想マシンの管理に対して 8CPU/32GBメモリ割り当てが推奨となります。（検証等でお試し頂く分にはここまで割り当て無くても動作可能です）
導入後の状態
オンプレに導入頂いたSaaS Client上は以下のpodが起動していることが確認頂けます。
kubectl get podの出力結果
NAME READY STATUS RESTARTS AGE
mediation-netapp-66654c467c-f67ll 1/1 Running 0 3m47s
mediation-pure-6b86fbfbf7-2hmdv 1/1 Running 0 3m47s
mediation-ucs-5c49577fc-k8ssc 1/1 Running 0 3m42s
mediation-vcenter-6fbdc997c7-87m8c 1/1 Running 0 3m38s
mediation-vcenterbrowsing-557fd5f899-tmsjd 1/1 Running 0 3m40s
skupper-router-7dbdf79c79-z8g98 2/2 Running 0 3m37s
skupper-service-controller-76fcd64f6c-dcslb 1/1 Running 0 3m37s
skupper-site-controller-5f7fd46b-b5dln 1/1 Running 0 3m57s
t8c-client-operator-controller-manager-5c45fbb96f-6hc9h 1/1 Running 0 77m
こちらをご覧頂くと想像つくかもしれませんが、このSaaS Clientは主に2つの機能を担っています。
- いくつかのオンプレ向けのターゲットに対する mediation （情報収集・中継）機能
- skupper を用いて、このSaaS Client上のKubernetesクラスタを、Turbonomic SaaS ServerのKubernetesクラスタと接続。
※なお、そもそもとなりますが、オンプレ環境のTurbonomic自体は OVAで仮想マシンとして導入 されますが、内部的には k8sを用いた多数のマイクロサービスで構成された一つのアプリケーション となっています。
従い、オンプレ向けのTurbonomicのインストール用OVAを使って、その中の一部の機能のみを起動させる事で、こういった形でSaaS Clientとして動作させる事が可能な作りとなっています。
mediationとskupperについて少し補足させて頂きます。
mediationとは？
Turbonomicによる管理対象の情報収集は、それぞれ専用の mediation と呼ばれるpodがその機能を担っています。（例えば、vCenterであればvCenter専用のmediationが、netappに対してはnetapp専用のmediationが存在）
こういった形で機能を一定レベルで分割する事により、もともとほぼ使われないサービスを停止しておくことで、余計なリソースの消費を抑えています。このあたりもTurbonomicの設計思想に近いものがありますね！
なお、上記例ではnetapp/pure/ucs/vcenter向けのmediationのみが起動しておりますが、実際にはこちらのページに記載の通り、他にも数多くのオンプレリソースを管理対象として有効化する事も可能です。（また、逆に使用しないmediationは停止しておくことも可能）
skupperとは？
skupperはKubernetesのマルチクラスタのアプリケーション間通信を実現するオープンソースとなります。
なお、今回のSaaS Clientでなぜk8sのマルチクラスタ間の通信が必要なのか？というところですが、これは上記記載の通り、Turbonomicの実態はもともとk8sの名前空間上に構成されたアプリケーションとなっておりますので、skupperを用いる事で SaaS Client上のk8sクラスタ と Saas Server上のk8sクラスタ を連携させている事になります。
その結果、 SaaS Client上のmediation podが、あたかもクラウド上のSaaS Server上の一部であるかのように利用できる 事になりますので、これが今回の Hybrid Support のミソになっています。
※なお、Kubernetesクラスタ間の通信を実現する方法として、他にもSubmarinerやIstioなどがありますが、今回の様に、オンプレ環境からの通信としてNATやファイヤウォール越えの対応が必要となる場合には、skupperがその威力を発揮しています。
まとめ
如何でしょう、実装としては非常にシンプルで、これまでSaaS版のTurbonomicからは到達出来なかったオンプレ環境の管理対象に対して、Kubernetesで利用可能なskupperを用いてその接続を可能にした形となります。（何か特別に新しい実装を行ったわけではなく、信頼性のある既存の機能を用いて製品機能を拡張しています）
また、単にSaaSとオンプレ環境とのネットワーク接続をブリッジするだけではなく、一定のmediation機能をオンプレ側で有効にし、効率の良い情報収集を実現している点 、更に、 必要に応じてユーザー自身がその対象を増やす事が可能 になっている点も興味深い実装ではないでしょうか。
以上、今回は、v8.7.3で実装された "Hybrid Support" についてご紹介させて頂きました。また、何か有用な新機能などありましたらこちらでご紹介させて頂ければと思います :)