目的を明らかにする
自分が何のデータを必要としているのかを明らかにするために、目的をはっきりさせる。目的はS+Vで記述する。
Sは場所＋サービス + 情報の種類とする。場所はネットワークが提供しているサービスの地域とする。ネットワークは一箇所だけではないがなるべく絞り込むとレポートで情報を取得しやすい。サービスはエンドユーザーが実際に使っているアプリケーション、例えば、ファイル転送、メール、ウェッブなどがある。情報の種類はトラフィックボリューム、スピード、遅延、影響する機器。
- 東京のトラフィックボリューム
- 大阪のファイル転送のスピード
- APJ全体のトラフィックの種類
- 日本でウェッブ接続に影響するサーバー
Vは調査するきっかけによる。
- 知りたい
- 遅い
- 障害が発生している
カスケードプロファイラの基本
カスケードプロファイラでまず頭に入れておくことはレポートタイプ。レポートは細かく分かれているのでこれを理解しないと、必要に応じたレポートを作るまでに時間がかかる。
ダッシュボードからレポート
ダッシュボードからのレポートはコンテントブロックと呼ばれ、以下の種類がある。主に全体的な傾向をつかむのに利用できる。
この中でTop xxxxは現在プロファイラで対象となっているすべての監視対象となっている機器からのTop 10を取得できるの長期的傾向から改善策の提案や、短期的な全体情報を提供するのには向いている。ただしTopであり監視対象がすべてであるために特定問題の解決には向かない。
Watchedは機器をフィルタできるので特定機器の情報を取得するのに利用できる。
１つのダッシュボードではTop xxxを表示、２つめ以降のダッシュボードは地域別にWatchedを作成しておくと便利。
ダッシュボードの内容は以下にする。
- 全体トラフィックボリュームの傾向
- ホスト別トラフィック Top 10
- ポート別トラフィック Top 10
- アプリケーション別トラフィック Top 10
- アプリケーションサーバー別トラフィック Top 10 (これはホスト→アプリケーションの組み合わせ)
- フロー別トラフィック Top 10 (ピアツーピアでのトラフィック）
ただし地域別のメニューでは以下しか利用できないことに注意する。例えば地域別ポート別の情報はコンテンツブロックでは取得できない。
- Watched Hosts
- Watched Hosts Group
- Watched Network Device
- Watched Network Device Interfaces
コンテンツブロックから監視機器をクリックすることで以下の情報を取得できる。
- トラフィックボリューム
- アプリケーション/ポート別トラフィック
- Qos別トラフィック
レポートメニューからのレポート
レポートメニューからは４つの作成方法が選択できる。最初の３つはそれぞれホスト、インタフェース、アプリケーションでフィルタリングできる。４つめのメニューはAdvancedであり、より細かくレポートのパラメータを設定できる。
- ホスト： ホストでレポートをフィルタリングする。問題が発生しているホストが明らかであるときに利用する。
- インタフェース: 情報を取得しているインタフェースでフィルタリングする。問題が発生しているセグメントはわかっているが、ホストやアプリケーションについて情報が得られない時に利用する。
- アプリケーション：アプリケーション・ポートによりフィルタリングする。問題が発生しているサービスが明らかになっているときに利用する。
レポートの出力フォーマットには以下が利用できる。
大まかにアプリケーション/プロトコル、ホスト、ピア、ネットワーク、QoSに別れている。
選択するレポートの種類は現在利用できる情報と、知りたい情報により異なってくる。実際に起きる問題からレポートの選択方法を説明する。
問題 東京オフィスでネットワークトラフィックが全体的に遅い
この問題ではまずトラフィック全体からアプリケーション・ホストにブレークダウンして問題があるトラフィックを識別する必要がある。
利用できる情報は東京オフィスであるから、Riverbed Steelheadの機器名がわかる。ここではTokyo_RSHとする。
- ネットワークデバイス名でコンテンツブロックからデバイスの基本情報を取得する。
この作業でトラフィックボリュームが判明する。明らかにトラフィックが平常時より増えているなら、ボリュームによりトラフィックが増えていることがわかる。次にアプリケーション別のトラフィックを見て、特定のアプリケーションが帯域を占有していないかを確認する。
全体的なトラフィックが増えていないにもかかわらずネットワークパフォーマンスが遅い場合には特定のアプリケーションで障害が起きている可能性があるので、この場合もアプリケーション別トラフィックを見る。
注目すべきトラフィックは以下である。
- ボリュームが大きいトラフィック
- Ｐ２Ｐなど会社では利用しないアプリケーション
- ストリーミング
- マルチキャスト
問題 IPフォンでノイズが混じったりつながらない
一時的にＩPフォンが使えない時には２つの理由が考えられる。
- 全体的なトラフィックから影響を受けている
- Voipトラフィックのボリュームが大きくQoSでもさばけない
- QoSが正しく設定されていない
一番目の問題は問題1の手順で分析を進める。
２番目はVoip関連のトラフィックを洗い出す必要がある。ここで問題となるのがVoipに関係するホストとポートが明確になっていないためにトラフィックの絞り込みができないことだ。明らかにすべきトラフィックは２つある。
- Voip制御トラフィック
- Voip音声トラフィック
制御用トラフィックはPABXサーバーとの通信であるから、該当ロケーションで利用しているPABXのIPアドレスを取得する。このIPアドレスをHosts/Hosts Groupに指定する。
関連するサーバーの洗い出し
Hosts with Applicationを指定することで関連するサーバーを取得できる。洗い出したサーバーはすべてのパラメータに戻してあげることで、PABXに関連するサーバーを洗い出すことができる。
ポートの洗い出し
サーバーを洗い出したら、レポートタイプをApplication with Portに変更する。これでPABXで使用されうポートをすべて取得できる。ポートを洗い出したら、アプリケーションパラメータにこれらのポートを入力してトラフィックを確認する。
問題 QoSトラフィックが適切なDSCPで流れているかを確認する。
VoipではQoSを設定してパケットを流す。このDSCPが適切な値でないと、ノイズがまじったり、会話が切断される。このような問題が起きた時に意図しているQoSで流れているかを確認する。
わかっている情報は以下である。
- PABXサーバー
- クライアントIPフォンのIPアドレス
まずトラフィック全体でどのようなDSCPが設定されているかを確認する。AdvancedレポートからDSCP with Interfacesでレポートを流す。
この結果トラフィックに流れているDSCP一覧を取得できる。ここからインターフェースと知りたいDSCPを絞り込み、レポートのパラメータに設定する。
これで該当ロケーションのDSCP値ごとにトラフィック状況を取得できる。見るべきポイントとしては
- 予想していたDSCPでトラフィックが存在しているか。
- Default以外のDSCPはすべて予期している値か。
- ボリュームが適切か。
