JANOG41 Wi-Fiチーム報告書3(運用監視ツールの紹介)
2018年07月10日 火曜日
CONTENTS
こんにちは、JANOG41 NOC(Wi-Fi)チームの金子です。
これまでの2回の記事（第1回｜第2回）で紹介してきたように、JANOG41 Wi-Fiチームでは会場無線LANの提供にあたりその構築・運用を行ってきました。
運用に当たってはネットワーク状況のモニタリングが必要不可欠です。これにあたりPrometheusやcactiなどOSSベースの監視ツールを活用していることはいわずもがなですが、IIJが開発している機器管理サービス SACMや、データ可視化サービス Machinistを全面的に利用しdogfoodingするというのが我々の基本方針となっています。
また YDD(やりたいこと Driven Development)、つまり運用に必要なモノ、来場者の方に見て頂きたいモノは自分たちで作るというのをモットーとしてこれまでのイベント無線LAN提供を行ってきました。今回のJANOG41でもこれに則りさまざまな取り組みを行いました。
ここでは特にJANOG41に向けて作ったあるいはブラッシュアップした自作ツールを中心に、今回の(特に見映えのする)ネットワーク運用監視ツールを紹介します。
運用・監視ツールのコンポーネント群
JANOG41 会場Wi-Fiの運用監視にあたっては以下の様なツール・サービスをコンポーネントとして用いていました。
- コミュニケーション系
- Direct およびボット (自社取り扱いサービス)
- Zello PTT Walkie Talkie (他社サービス)
- 可視化・管理系
- Machinist (自社サービス)
- netmap (自作)
- SA-W2 無線LANコントローラ(自作)
- LLDP network viewer (自作)
- 会場準備ステータスボード (自作)
- kibana + elasticsearch (OSS)
- prometheus & grafana (OSS)
- cacti/weathermap (OSS)
- smokeping (OSS)
- データソース/プロトコル
- インフラ
- IIJ GIO P2 (自社サービス)
- docker-compose → kubernetes (OSS)
データフローを図示するとコンポーネント間で以下の様なデータのやりとりを行っていました。
それぞれの内部コンポーネントは基本的にはコンテナとして起動され、その管理をkubernetesで行っています。
そのkubernetesの基盤は以下の様にIIJ GIO P2の上に構築した「イベント無線LAN監視クラウド」の上で動いています。
サーバは現地には持ち込まず、会場とIPsec VPNを張るようにしコンパクト化を図っています。
自作運用監視ツール三兄弟
前節のようにさまざまなツールを駆使して今回の会場無線LANの運用を行っています。ここではその中から自作したものに絞って3つのツールを取り上げます。
会場準備ステータスボード: 準備状況の可視化
会場準備ステータスボードは、JANOG41 会場無線LANの準備状況を分かりやすく図示・共有するためのアプリケーションです。運用監視ツールというよりは構築進捗管理ツールと呼んだ方が適切でしょうか。
このツールに関しては当日以下のツイートでも紹介させて頂きました。
Wi-Fiチームのオペレーターが、各所に散らばったスタッフとインカムで連絡を取りながら、作業の指示を出しています。スマホアプリのPTTとチャットで一斉連絡。チャットのbotと連動して進捗が画面に表示されてます。 #janog pic.twitter.com/QrSC6MQC8Y
— 堂前@IIJ (@IIJ_doumae) 2018年1月24日
世間ではチャットワーク、という言葉が登場して久しいですがこの形態のツールはイベント無線LAN構築のような時間的制約、あるいはメンバの地理的分散や移動が激しい状況にある我々にこそふさわしいツールなのではないか、と考えたのが発端です。先の記事でも紹介させていただいたように今回は「あと3時間以内にこの広い会場にケーブルを敷設してAP/SWを設置して結線してテストして提供」あるいは「会期終了から会場返却まであと2時間以内に全部撤去して撤収」しなければならないというような状況にありました。これを無事に完遂するには、チーム内でリアルタイムに情報を共有しつつそれを整理し、どこに助けが必要なのかを把握することが重要です。
会場にてメンバ同士はZello PTT Walkie Talkieを用いて音声ベースで基本的なコミュニケーションを行っています。手軽に同報通信ができるトランシーバの弱点は「情報が流れてしまう」ことですが、NOCにモデレータを配置し”情報整理役”とすることでこれをカバーしていました。しかしこれまでのイベント無線LANでの経験から、それでも聞き漏らしや問い合わせコストの増加が発生し、さらに切羽詰まってきたときに情報が錯綜する傾向にあるという知見を得ていました。こういった情報の整理にはチケットシステムがうってつけではあるのですが、こと構築・撤収作業中という時間制約のもとではチケットを閲覧・作成するゆとりはありません。
そこで着目したのがチャットサービスとチャットボットでした。スマホにインストールしたDirectアプリにて各自の状況報告を定型化、それをチャットボットが集約・広告してくれることで人力による情報整理を不要にし情報参照のコストを減らすことができました。
入力にあたっては以下の様にDirectの「セレクトスタンプ」機能を活用しています。自分が担当しているエリアを番号で選択し、作業・状況を申告するというインタフェースになっています。
申告された状況はチャットボットでとりまとめられ、状況変化は適宜発言として流れつつ、表形式で一覧することも可能になっています。
このように基本的にはチャット内で閉じているツールではありますが、これをNOCで分かり易くかつ格好良く表示したのがTwitterでも紹介させて頂いた「会場準備ステータスボード」になります。
上記のチャットボットの表と照らし合わせるとそれぞれがマップされているのが見て取れるかと思います。
netmap（仮称）: 会場内トラフィックの可視化
netmapは会場内のトラフィックを可視化するツールです。
※同名のパケットI/Oフレームワークがありますが、ここで取り上げたものはそれとは異なるツールです。”ネットワークマップ”を略して”netmap”(仮称)と呼んでいました。
会場ネットワーク内全体でトラフィックが流れていることを確認するというのはWi-Fiネットワーク運用に当たって重要な監視項目の一つです。smokepingなどにより機器の疎通監視は行っているため断が発生すればすぐに分かるようにはなっています。しかし機器に疎通はあるけれども&人がいるはずのエリアなのにトラフィックが流れていないというような状況の場合はあるいは何か疎通以上のレベルで問題が発生している可能性があります。こういった事象を見つけるためにゲートウェイでの出口トラフィックだけでなく、各エリアでのトラフィックを見ておくのが肝要です。
この手のツールとしてはグラフ(チャート)形式であればZabbixやCacti、ネットワーク図と連動するものとしてはweathermapが存在します。もちろんそれらも運用はしていたのですが、より効果的に会場内のトラフィック状況を見たいというモチベーションで作ったのがこのnetmap(仮称)になります。
cacti + weathermapでは以下の様にカラフルに、ネットワーク図に重ね合わせる形でトラフィック量を表示できます。ただしcactiの難点として、独特のUIのためこのノードとエッジが書きづらくネットワーク規模が大きい場合やベースとなるネットワーク図の変更に追従する場合に大変であること、重ね合わせるとどうしてもごちゃっとしたり見栄えを整えるのが大変になるという難点がありました。
そこで、見映えはするけれどももう少し簡単に扱える脱cactiトラフィック可視化ツールとして作ったのがnetmap(仮称)です。
netmapではネットワーク図との重ね合わせはしないものとし、基本的には左からゲートウェイ／コアスイッチ／各エリアの集約スイッチの3階層構成としています。cacti + weathermapでは比較的自由に記述できてしまい逆に統制が利きづらいところを、ツリー構造の向きを左から右に固定し階層を役割毎に限定することで見やすさを目指しました。ゲートウェイとエリアスイッチのノードにはアップロード・ダウンロードトラフィックをそれぞれパネルメータの様に表示しつつ、コアスイッチではレベルメータで同様の可視化を行っています。
上図はテンプレートのため各メーターとも0のままですが、本番では節の最初で挙げたようにMbps単位でパネルメータやレベルメータの値がアニメーションするようになっていました。内部的なデータはcactiと同じくスイッチにSNMPを用いてデータを取りに行っており、それをMachinistに送信したものをここでプロットしています。
SA-W2 無線LANコントローラ: 会場内クライアントの可視化
SA-W2無線LANコントローラは、提供している無線LANクライアントの可視化およびAPの管理を行うツールです。ここでは主に可視化関連の側面を取り上げます。
短期間でエリア間の移動が激しく行われるイベント無線LANの運用にあたっては、会場内でのAPの利用状況を把握することが肝要です。エリアにいる人数、APに接続しているクライアント数の偏り、チャネル使用率等により観測できる実際の需要に対して構成・設定のマッチングが取れているかを適宜把握するための可視化がこのために必要となります。またとあるクライアントの接続状況が悪いとの申告があった場合に、その挙動をトラッキングしトラブルシュートする必要がでてきます。先述の会場／エリア／APといった大きな括りだけではなく個々のクライアントについても注視できる、そういった機能を備えているのがこのSA-W2無線LANコントローラになります。
大きな範囲の状況としてクライアント数の偏りを分かり易く表示するために、上図のようなヒートマップ機能が存在しています。それぞれのAPの位置で、接続数が少なければ青、多くなれば赤くプロットされるようになっておりどこに集中しているのかを見ることができます。ここでは昼時のためか、メインのフェニックスホールは接続数が少なく展示スペースに集中しているのが見て取れます。
また各APの位置をクリックすることで以下の様に詳細を表示することも可能となっています。ここでは各帯域のクライアント数やチャネル使用率から混雑度を判断しチャネル設計の適切さを評価することができます。あるいは、混雑すべきエリアにもかかわらずクライアント数がいないAPでは何かトラブルが起きているのではないかなどの指標としても用いることができます。
個別のクライアントに関するトラブルシュート向けには「無線クライアント詳細」画面を作っています。ここでは個々のクライアントのAP間の遷移やトラフィック状況の表示、あるいは切断コマンドの制御が可能となっています。ローミングが上手くいっていない場合や、そもそも接続が上手くいかない場合にはこちらの画面を見つつ接続を試行しながら事象の切り分けを行いました。
その他: ダッシュボード
これまでにあげたトラフィックや無線LAN系の情報以外の情報をまとめて載せておく場所として以下の様なダッシュボードも作成していました。kibanaのように見えますがオリジナルで実装しています。
このグラフもMachinistのグラフをベースにしています。ここでは全体トラフィックやIPv4/IPv6比率、各機材のCPU使用率などを表示していました。
終わりに
ここでは主に自作ツール3つを中心に、今回のJANOG41 Wi-Fiで運用監視ツールを紹介しました。いくつかのツールについては会場のIIJブースでも展示し、様々な来場者の方にご覧頂けたようです。お越し下さった皆様ありがとうございました。
先に述べたように実際にはこの3つ以外にもさまざまなOSSあるいは自社サービスをつかったツールを動かしており、それぞれの活用に工夫をこらしています。
また、データフローの図にも掲載しましたが各トランスポート・プロトコルを併用しつつ状況把握に必要な情報の流れを設計し運用するというのもモニタリングにとって重要なタスクです。それらについては改めて別の機会で紹介できればと考えています。
