Catalyst9300でapp hostingをやってみる

世の中のトレンド(特にIoT)がクラウド集中からクラウド+オンプレミスやフォグコンピューティングへ

世の中のあらゆるものがネットに接続・・・はまだしていない現在。
とはいえ、IoTの分野をはじめ、これまででは考えられない量のデバイスがネットワークに接続してきています。

それに伴ってか、数年前はクラウドへの移行がトレンドとなったことはまだ記憶に新しいと思いますが、現在はオンプレミスとのハイブリッド型、またよりクライアント側に中間のサーバとなる機器を置いて、データの集約化やクレンジングを行いクラウドと連携する「フォグコンピューティング」という概念も出てきています。

フォグコンピューティングを行うにしてもコンピューティングリソースはどう設置する？

フォグコンピューティングはクライアントに近いところにサーバを置く関係上、コンピューティングリソースをどのように設置するか？が問題となることがあります。
キャンパス/ビルレベルではなく、例えばフロア単位でサーバを設置したいとなった場合、各フロアにサーバを設置し、その上で必要なソフトウェアを動作させる・・・というアプローチでも問題ありませんが、実際にやろうとすると物理機器が増えるため、イニシャルコストもランニングコストもかかることになります。

そうだ　スイッチのCPU、使おう。

現在のエンタープライズスイッチでは、多くの機器が汎用コードを実行できるようなCPUを積んでいるのが当たり前となっています。特に一部の会社の製品ではLinuxベースのプラットフォームで動作し、汎用のマイクロサービスを実行できるものが存在します。
今回利用するCatalyst9000シリーズスイッチにもこの仕組みが備わっており、「app-hosting」という名称で実装されています。Catalyst9000シリーズスイッチはx86-64CPUを搭載し、Linuxをベースとしたシステム(OS)がスイッチ上で動作しています。
またこのCatalyst9000シリーズスイッチのapp-hosting機能では、マイクロサービス実行環境としてDocker互換の環境が用意されています。x86-64ベースのハードウェア上に用意されたDocker環境となることで、世の中で広く利用されているDockerのコンテナベースのエコシステムをCatalyst上でも動作・実行させることが可能となります。

Catalyst9000シリーズでのapp-hosting

アーキテクチャ

Catalyst9000シリーズスイッチのapp-hosting機能の概念図は以下の図1の通りです。
ベースとなるLinuxカーネルの上にIOS機能を司るデーモン(IOSd)、およびDocker実行環境が用意されており、任意のコンテナを実行できる環境が用意されています。

図1 app-hosting機能概念図

ネットワークについて

内部で仮想的に作られたブリッジを利用し、グローバルなVRF(GRT、(Global Routing Table))やManagement VRFへの接続が利用できます。またGRTへの接続はレイヤ2接続/レイヤ3接続どちらも利用することが可能です。
レイヤ2接続で利用した場合、スイッチ側のIOS-XEからは「AppGigabitEthernet」としてブリッジ側のポートがマッピングされます。
レイヤ3接続で利用した場合、スイッチ側のIOS-XEからは「VirtualPortGrouop」としてルーテッドポートとしてマッピングされます。
Management VRFへの接続を含め、内部的にどのように接続されているかをまとめたものが以下の図2になります。

図2 app-hostingネットワーク接続概念図

なおapp-hositngのユースケースとして、Cisco公式で紹介が行われているものにThousandEyesがあります。
これはエージェント型のネットワークモニタリング製品であり、クライアントに近い場所で動作しているCatalystとリモートの通信先との間でネットワークの可視化が行え、実際の通信経路に則した状況の可視化が行えます。

また大規模にコンテナをデプロイする場合、以下に記載しているような手動でのデプロイではなくDNA Centerを用いた展開を行うことが可能です。

実際にCatalyst9300でやってみた

今回のテスト環境

今回は機材として追加の拡張ストレージを搭載した状態のCatalyst9300-24Pを用意し、その上にDockerコンテナのデプロイを試してみました。詳細な機材は以下の表1の通りです。

表1　テスト用機材および利用バージョン

今回Dockerコンテナとして動作させるアプリケーションは、上記表1にもある通り、mosquittoを利用します。
mosquittoは軽量なメッセージングプロトコルであるMQTTのブローカー(中継サーバ)であり、これをCatalyst9300上で動作させることにより、追加のコンピューティングリソースを用意しなくともローカルでMQTTプロトコルを動作させることが可能になります。
また、今回は試していませんが、設定を変更し、クラウド側にあるMQTTベースのメッセージングシステムへ連携(Catalyst9300上のmosquittoをブリッジとして動作させる)することも理論的には可能となります。

今回はMQTTのPublisherとして温湿度気圧ガスセンサ(BME680)を用いたESP32デバイスを用意し、Subscriberとして液晶を備えたESP32デバイス、スマートホーム等の機能を実現できるHome Assistantを用意し、Catalyst上に構築したMQTTブローカーであるmosquittoを利用したMQTTメッセージングシステムを構築してみます。(図3)

図3 検証環境(概念図)

Catalyst9300上で動作するコンテナ(カスタムコンテナ)を作る

Catalyst9000シリーズスイッチのapp-hostingでは、直接DockerHubからコンテナをpullする機能は備えていないため、まずは動作するコンテナイメージをUbuntu上で作成します。
Ubuntu上でmosquitto(eclipse-mosquitto)をdocker pullし、まずはubuntu上で立ち上げます。

その後、Ubuntu上でコンテナの設定を行います。今回はテスト環境で用いることもあり、ポートはデフォルトのまま、認証なしとして設定しました。

コンテナ内にデフォルトポート、認証なしのconfigが含まれていますので、コピーして利用します。(元のファイルは別名で保存しておきます)

設定が終わったらUbuntu上でcommitを行い、コンテナに対して行った変更を反映したカスタムコンテナとしてcommitしておきます。
こののち、カスタムコンテナをCatalyst9300へ送り込むためにコンテナをエクスポートしておきます。

catalyst9300のapp-hostingの設定

続いてCatalyst9300上での設定です。
まずはioxコマンドでapp-hostingを有効化します。app-hostingを利用するためにはDNA Advantageが必要なことに注意してください(併せてSmartLicenseの認証も必要となります)。

app-hostingが有効化されたのちはコンテナをインストールし、アクティベートを行います。

続いてコンテナの動作に関わる部分を設定します。
コンテナのネットワークインターフェースに関しても割り当てるIPもコマンドにて設定します。
今回はグローバルVRF(GRT)とブリッジ接続を行いたいため、ブリッジまでの経路をtrunkとして設定し、コンテナインターフェースに対してもIPアドレスの設定を行います。
また同時にコンテナの実行時に必要となるオプション（dockerコマンドのオプションに相当）もあわせて設定を行います。

設定が終了したらコンテナを動作させます。

MQTTのPublisher/Subscriberを作ってつなぐ

MQTTのブローカーができたので、次はそこにデータを投入するデバイスを作ります。
ブラウザベースなどの簡易なMQTT Publisher/Subscriber でもよいのですが、どうせならもう少し面白くデータを流す環境を作りたいため、ESP32マイコンを利用したPublisher/Subscriberを作成しました。

Publisherとして温湿度、気圧、ガスをセンサー経由で計測しその情報を送信するもの、SubscriberにはBrokerへ送信された温湿度、気圧、ガスを小型の液晶に表示するマイコンを作成し利用しています。
ESP32はマイコン単体で無線LAN接続機能を備えているため、これを接続する環境としてCT3504+AP2800の環境も併せて用意しています。またSubscriberは複数接続することも当然可能なため、ホームIoTゲートウェイとして開発されているHome Assistantでも問題なく表示されることが確認できました。

まとめ

Docker互換のコンテナ実行環境を備えたおかげで、多様に提供されているコンテナアプリケーションが動作するようになり、リソース消費が大きくないアプリケーションにおいては別途コンピューティングリソースを確保する必要が無くなりました。
多量にデバイスが接続されるIoTの世界では、エッジに近いところで情報の蓄積やクレンジングといったフォグコンピューティングに近い考え方はますます重要になると思われます。そのためのアプリケーションプラットフォームとしてCatalyst9000シリーズの機器が利用できるのは一つのメリットと言えるでしょう。アイデア次第で様々な活用方法が考えられると思います。

Linux等の上で動作するDockerの基盤と比べ、コンテナの展開と運用に多少癖があるものの、使い方次第で非常に有用な機能であると構築していて感じました。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。