こんにちは、 TAM の中田です。
今回は VMware Aria Operations for Networks を使用した、通信障害のトラブルシュート例をご紹介します。
◼︎はじめに：Aria Operations for Networks について
昨今のデータセンターではネットワークの仮想化やマイクロセグメンテーションが進み、システムの通信に異常があった際にどのサーバ間の通信に異常があったのか、経路上のどこに問題があるのか、そもそもどのような経路で通信が行われているのか、物理的に見えないものを調査することになり、運用がますます複雑になっています。
このような仮想ネットワークを可視化し、監視やトラブルシューティングを手助けする製品が Aria Operations for Networks です。
機能が多彩な一方、使い方が分からないというお声を頂くことも多いため、今回は参考として、通信障害の事後調査での使い方をご紹介したいと思います。
◼︎通信障害の事後調査での活用
突然ですが、「昨晩xx:xx頃、某サービスで通信エラーが発生していた。現在は復旧しているがネットワークに異常がなかったか調べて欲しい。」
このような問い合わせを受けた際、インフラの運用チームではどのようなトラブルシュートが可能でしょうか。
リアルタイムな障害や再現性がある場合は疎通確認やパケットキャプチャを仕込むことも出来ますが、事後調査では障害発生時のサーバやネットワーク機器のアラート有無を確認し、何も異常が見つからなかった時、それ以上の調査には何か特別なツールが必要です。
そこでAria Operations for Networks では以下のことが可能です。
- 過去に遡ってトラフィックを分析する
3rd party製の物理ネットワーク機器を含めたデバイスからトラフィック情報をキャプチャ、デフォルトで30日間データを保持しており、リアルタイムなトラフィック状況だけでなく、過去に遡って当時の通信量、再送率、遅延状況などを解析をすることが可能です。 - アプリケーションごとに通信を分析する
例えばwebサーバ、Appサーバ、DBサーバ等の特定のサービスで使われている仮想マシンのグループを「アプリケーション」という単位であらかじめ登録しておくと、そのアプリケーションに関連する通信のみをフィルタして分析することが可能です。
アプリケーションの定義方法も手動でやるものからAIによる自動検出までいくつか方法がございますので、詳しくは製品ドキュメントをご参照ください。
今回は上記の機能を組み合わせ、以下のようなアプローチで調査をしてみます。
- トラフィックの分析
そのアプリケーションによる通信のうち再送率やRTTが高騰していた通信の有無を確認する
例）192.168.1.10 -> 192.168.100.10 [port:2049] において再送率が高いことが判明 - 他の通信との比較
該当の通信と同じネットワーク経路を使用する他の通信を分析
例）192.168.1.0/24 -> 192.168.100.0/24 の他の通信における再送率を比較
→再送率が高い通信が他にない場合、該当アプリケーション側の問題でありネットワークインフラが原因ではないという推定が可能
では実際の画面を添えて実施してみます。
◼︎トラフィックの分析
「昨晩xx:xx頃、某サービスで通信エラーが発生していた」とのことなので、 Aria Operations for Networks に登録したアプリケーション名を使って当時の通信状況を確認します。
Aria Operations for Networks には様々な機能が搭載されていますが、該当機能の画面に遷移せずとも、「クエリ」を実行することで必要な情報だけを迅速に出力することが可能です。
たとえば画面上部の検索窓に以下のクエリを入力します。
Average TCP Retransmitted Packet Ratio and Median TCP RTT and Network Rx Rate and Network Tx Rate of Application ‘アプリケーション名’ between April 13 22:00 and April 13 22:30
これで、4/13 22:00-22:30 の時間帯における、指定したアプリケーションの、TCPパケットの平均再送率、TCP RTT中央値、 NW送信速度、 NW受信速度を一度に表示することができます。
※「between April 13 22:00 and April 13 22:30」の部分を変更して別の時間帯と比較することも有効です
ここでの分析で「TCPパケットの平均再送率が通常より上がっていた」という結果が得られたとします。
アプリケーションは事前定義した仮想マシンのグループなので、この中でどの仮想マシン通信の再送率が高かったのか調べます。
以下のクエリで、指定したアプリケーション名/時間帯における通信を、TCPパケットの平均再送率の高い順番にソートして出力します。
Flow where Application = ‘アプリケーション名’ order by TCP Retransmission Ratio between April 13 22:00 and April 13 22:30
再送が発生していた通信のソース IP アドレス、宛先 IP アドレス、宛先ポート、プロトコルの情報が得られます。
◼︎他の通信との比較
問題となるアプリケーション通信の情報が得られたので「同じ経路を利用している他の通信はどうだったのか？」調査します。
ここまでの調査結果を元に、問題の通信と同じ送信元と宛先のネットワークアドレス間（ここでは192.168.1.0/24 -> 192.168.100.0/24）における、他の通信の状態を以下のクエリで出力します
TCP Retransmission Ratio of Flow where Source Subnet Network = ‘192.168.1.0/24′ and Destination Subnet Network = ‘192.168.100.0/24′ order by TCP Retransmission Ratio between April 13 22:00 and April 13 22:30
問い合わせのあったアプリケーションによる通信では、総トラフィック量 1023.3 KB に対して TCP の再送率は最大11.3%です。
二つめに表示されている仮想マシン通信は、このアプリケーションとは無関係ですが同じ経路を使用しています。
この通信の総トラフィック量は 112.7 GB に対して TCP の再送率は0%でした。
本番環境ではより多くの通信と比較する必要があるかと思いますが、該当時間帯、同じ経路を使ってるなかで「TCP の再送を行なっている通信が問題のアプリケーションによるものだけである」ことが判明しました。
この結果より、ネットワークインフラ側に異常があった可能性は低く、通信エラーの原因は OS レイヤ以上にあるものと推察できます。
逆に、他のフローでも再送率が高騰しているようであれば、仮想マシンではなく経路上に原因があることが推察できます。
◼︎補足
今回、クエリの構文に関する解説は割愛しましたがクエリに「help」と入力すると、他にどのようなクエリが実行可能なのか、構文例が多数ご覧いただけますのでご参考にしてください。
また、今回は例としてTCPのパケット再送率のメトリックで調査を進めましたが、パケットのロス率やトラフィックレート等、クエリに利用できるメトリックは他にもございます。
障害発生時にどのメトリックを確認すべきか、あらかじめ環境ごとに検討しておくことをお勧めします。
使えるメトリックについては各バージョンの製品ドキュメントをご参照いただくか、先述の「help」クエリの「サポートされるプロパティ」タブにて「メトリック」タグをフィルタすることでもご確認いただけます。
◼︎最後に
今回はトラブルシュート時の使い方の一例をお届けしましたが、Aria Operations for Networks ではこの他にも様々なトラブルシュート機能やセキュリティ強化を図る監視機能がございます。
また、バージョンが上がるたび新機能や新メトリックが実装されて、活用の幅がさらに広がっているため、仮想ネットワークの運用高度化を志向されているお客様はぜひご利用ください。
本記事を含めて、弊社製品の活用に関してご不明点・ご相談事項ございましたら、担当 TAM までご連絡ください。
