ND Insights 活用術: Delta Analysis によるトラブルシューティングと影響範囲の特定

[Daijiro Kido]

※この記事には Cisco 非公式の情報が含まれます。製品のご利用にあたりましては必ず公式なドキュメント、ガイド、データシートなどを参照いただき、本記事との差異がある場合は公式の情報を優先して下さい。

※本記事はドキュメント投稿時、または、更新時時点の情報に基き掲載されています。最新の情報は掲載時点から変更されている場合がありますので、製品のご利用にあたっては必ず最新の公式の情報をご参照ください。

• 活用シナリオ
• 課題
• NDIの活用

NDI version: 6.0.2 , ACI

活用シナリオ

不特定ユーザにて経理アプリケーションへのアクセス不可/パフォーマンス低下が発生していたことが判明し、ネットワーク管理者にてトラブルシューティングが必要な状況。

• 8:30 PM 頃から経理アプリケーション (Financial-Lite-App) のパフォーマンス低下を確認
• アプリケーションチームが調査したところ、見積もりサービスシステム(Quote Services)で異常が発生していたことを確認
• 調査開始時点でアプリケーションパフォーマンスに異常が発生していないことを確認
• 原因の特定だけではなく、影響を受けたユーザ数とその詳細が知りたい

課題

• 単純な通信断と比較して、限定された条件下でしか発生しない通信断のほうが原因特定が難しい
• トラブル発生時点にさかのぼって、そのトラブルの影響を受けた通信や、影響範囲を特定するにはどうしたらよいか
  • 一般的にトラブルが深刻であればあるほど復旧が優先され、通信断発生中の詳細なログ等が残っているケースが少ない
• 過去のトラブル発生時点にさかのぼって、その前後の状態変化や構成変化を把握するにはどうしたらよいか
• 正しい設定を誤った個所に適用してしまったようなケースで発生するトラブルについては、エラー等の異常として検知することが難しい (意図した動作かどうかは判断できない)
  
  

NDIの活用

通信トラブル原因の特定

• Flow 分析より問題の通信 (EPG: Quote Services) には Policing Drop が発生していたことがわかる
  (Policing Drop = 過剰な通信量を保護する目的で、設定した通信量を超えたパケットをドロップする)
  参照 = 
  
  

  ポイント	Policing による通信断は、一定レートまでは正常に通信できてしまうため、パケットドロップの対象やタイミングがランダムに発生し、問題発生傾向の絞り込みが非常に困難になるケースがある。このような問題が誤設定によって発生した場合、従来のトラブルシューティング方法では特定が難しい。

トラブルの影響範囲の特定

• Anomaly の詳細確認
  Flow に関する Anomaly から Policing に関連するものを抽出する
  
  
  
• トラブル発生時間の割り出し
  Anomaly をダブルクリックし詳細を開く。
  State 情報から問題の Anomaly は 8:03 PM から 55 分間発生していたことが特定できる。
  
  
  
• 影響範囲の特定
  Estimated Impact から、この問題により少なくとも 100 flow ( 100 ユーザ) 以上が影響を受けたことがわかり、View Report からこの Anomaly の影響範囲を確認することができる。
  今回の Policing Drop により影響を受けたフロー (アプリケーションユーザ)が以下のように表示される。
  
  
  

Delta Analysis による原因分析

• Delta Analysis の実行
  Delta Analysis によって、ND Insights が一定間隔で自動保持するネットワーク全体のスナップショットを比較することが可能。
  今回はこの問題を引き起こした原因を分析するため、問題が発生した 8:03 前後のすべての変化を Delta Analysis により抽出する。
  ここでは 7:52 と 8:52 のスナップショットを比較分析する。
  
  

  ポイント	ND Insights はデフォルト動作として、15 分間隔でネットワーク全体のスナップショットを取得する。このスナップショットにはネットワーク全体の状態や構成情報が含まれる。

• Policy Delta 分析
  Policy Delta 分析により、比較対象の2つのスナップショット間での構成変更の違いを簡単に抽出することができる。
  ここでは問題が発生している QuoteServices の EPG に関連して Demo という名前の DPP (Policing) が設定されてしまっていることがわかり、これにより問題のアプリケーション通信に影響があったと判断することができる。
  このように時間帯さえ絞り込めれば Delta Analysis により、問題発生前後の変化を即座に特定可能。
  
  
  
  

  ポイント	上記の例では admin ユーザが設定変更しており、誰がどういう目的で誤設定をしてしまったのかを特定しにくい。複数の管理者や、自動化ツール、Dev/Ops によりネットワークを構成変更する環境下では変更元を迅速に特定するためにも、設定変更ユーザーアカウントは細かく分けることが推奨される。