テレメトリの先を行く”What Just Happened™”
以下の当社技術コラムでも少々触れておりますが、本稿では””What Just Happened™”（WJH）とは何か？他のネットワーク監視・解析機能との違いは？といった点にフォーカスし、纏めています。
SNMPとテレメトリ
さて、昨今ネットワークシステムにおけるリアルタイムな監視・解析の可視化の必要性が高まっています。当然ながら、そのためには基となるデータのリアルタイム取得が必要となります。
従来よりネットワーク監視可視化の手法として、SNMP（Simple Network Management Protocol）が広く用いられてきました。SNMPは、SNMPマネージャとSNMPエージェント間での通信プロトコルで、SNMPマネージャから送信されるSNMPコマンドは、管理情報の識別子OID（Object Identifier）を含んでおり、SNMPエージェントはこの識別子に対応した管理情報をSNMPマネージャにレスポンスします。しかし、この OID の情報のやり取りはリクエストベースとなるため、その度に処理の負荷がかかります。また、ネットワーク機器の数が増えたり、リアルタイム性を求めてリクエスト→レスポンスというポーリングの間隔を狭めることは、更にネットワーク機器の負荷を増大させるため、結果としてリアルタイムなデータ取得は現実的ではなくなります。
そのため、SNMPに代わってリアルタイムな情報取得に適した「テレメトリ」と一般的に呼ばれる手法が確立されており、各ネットワーク機器ベンダーによる実装も進められています。
しかしながらリアルタイム性を高める一方、一般的なテレメトリにおいては、ネットワークポートカウンタ、統計的なパケットサンプリング、ホップバイホップのINTデータ等を収集することで大量のデータが生成されますが、正常なデータプレーン情報まで取得するため情報過多となりやすく、問題発生時には管理者が監視ツールで時間をかけて分析し、問題の根本原因を突き止めなくてはなりません。
WJHと一般的なデータプレーンテレメトリとの違い
対してWJHの場合、データプレーン異常イベントのみを取り出すことで、情報量は大幅に減らし、異常イベントに関連する情報を一度に出力するため、DWH で関連付けして検索する必要がありません。
以下、WJHの機能の仕方を示す概念図です。
パケット処理におけるイベントについて、5タプル情報とイベント(例えば、パケットドロップ)をレポートする仕組みで、incoming, buffering, queue, egress におけるイベント(ACL, drop, timer)を検出し出力します。メラノックス自社開発スイッチASIC「Spectrum 」には、パケットを廃棄する際、廃棄理由をエンコードしてメタデータとしてパケットヘッダに付与しCPUへ送る機能があります。
その結果、一般的なデータプレーンテレメトリと比して次のような大きな差を生むことで、管理者やユーザの負荷、ダウンタイムの大幅な低減に貢献します。
このWJHはSpectrum ASICを搭載するSN2000シリーズ以降のモデルに標準搭載される機能ですので、追加のライセンス費用等は不要です。
具体的な活用例
実際にWJHがどのように機能するか、一例を挙げてみます。
スイッチ”spine3”とスイッチ”leaf1”の間でパケットドロップが発生した場合、
以下右側の枠内にパケットドロップの理由が”VLAN filtering”であることが明示されています。
このように、トラブルシューティングするべき内容をピンポイントで確認することができます。
異常イベント理由の通知
“Reason”としてWJHが通知できる異常イベントの理由は以下にリストされているものがありますが、随時拡張されています。
当社のお客様からは、「現時点で他社のテレメトリ機能と比較するとWJHは一歩リードしている。他社のテレメトリ機能はあくまでネットワーク情報のリアルタイム収集までにとどまっており、WJHのような根本的な原因の推察などは行われていない。」という声もいただいています。
WJHはメラノックススイッチOS”Onyx”のバージョン3.7.1120から実装されておりますので、お手持ちのSN2000/SN3000シリーズで是非お試しの上、その効果をご体験ください！
尚、今後はCumulus Linux、switchdev、SONiCの各OS搭載時においてもサポートされる予定です。
サーヴァンツインターナショナル㈱
小池