間違いだらけのネットワーク作り(130) 2000/05/27
「MRTGとProbe」

今年の情報化研究会、夏のイベントは松山に決めました。  先週のこの記事を読んだ松山の会員C子さんが、「今年の夏は是非、松山で」というメールをくれたからです。  Cさんのお誘いなら誰も反対しません。  道後温泉も、俳句教室も好評だった前回。 さて、今年の味付けはどうするか。

MRTGとProbe

ここのところ大規模ネットワークのコンサルティング(もちろん有償)をいくつかさせていただいています。  ネットワークの企画・設計で最も大切なのは現行ネットワークのトラヒック分析。

そこで2月の土曜研究会で取り上げたMRTGが役に立っています。  また、講師で話していただいた波多さんが独自に開発したツールも使わせてもらっています。 これらのツールは天気概況ならぬ「ネットワーク概況」を把握するには十分なツールです。

リンクごとのトラヒック流量を時系列的に簡単につかめるためピーク時の特定や、リンクの回線利用率の把握が容易です。 波多さんのツールはルータのCPU使用率やメモリ使用率をいとも簡単に調べられます。

ただ、これらの簡単ツールの限界も実際設計に使おうとすると良く分かりました。  MRTGは現在のネットワークのトポロジーを前提としてリンク毎にトラヒック流量を把握します。  しかし、新しいネットワークの企画・設計というのは当然、トポロジーの見直しも必要。

新ネットワークのトポロジーがどうあるべきか? と検討はじめた瞬間、「MRTGだけでは駄目だ」というのは分かることです。 要は、「どんなトラヒックが」、「どこからどこへ」、「どれだけ」流れているかつかめなければ、最適なトポロジーは検討しようがありません。

そこでProbeの登場となります。  感激しますね。 その情報量の多さに。  その利用の簡単さに。 高いことだけが欠点。  ここに書くわけには行きませんが、楽しくなるほど発見があります。  これで新ネットワークの検討もシッカリできるというもの。

ということで、2月の土曜研究会ではProbeを扱っているベンダーの方に対して、「一般のユーザにProbeなんて難しいだけで不要じゃないですか?  MRTGで十分でしょう。」といった自分がProbeファンになってしまいました。 でも、普通のユーザには必要性が低いし、日常的に必要なものではない、とは今でも思っています。

ネットワーク管理を対症療法的にするにはMRTGは十分でしょう。  「ここのリンクが詰まっているから帯域を増やそう」、「レスポンスが遅いというから回線を太くしよう」といった受動的なネットワーク管理でよしとするならProbeなんて不要ですね。  でも、そんなんじゃあ少なくともコンサルティングにはなりません。

さあ、そろそろ午前6時30分。 実はこれから羽田に出かけます。 4月京都研究会以来の「朝飯前のホームページ作り」でした。
 
 
 

ホームページへ