ワンダーラボ - ねっとみえ〜る LanMap - FAQ - 20セグメントの場合

ねっとみえ〜る LanMap シリーズ Q&A集
 20セグメントの場合 Icon

Note: Written in Japanese, shift JIS code.
Last modified: Nov. 10, 2005

質問

セグメント数 20個、端末数 1000 台程度のネットワークの場合、 具体的には ねっとみえ〜る LanMap シリーズ をどのような形で導入すればよいのですか？

回答

以下で、構成例をいくつかご紹介します。 必要に応じて、マルチセグメント監視に関する説明もあわせてお読みください。

なお、端末数 1000台ほどとのことですが、特に問題なく管理できると思われます ねっとみえ〜る LanMap/Multi (および リモートオプション)は、 10 セグメント規模のネットワークの監視に実際に使用されています。 (ただし、1000台分の端末データを処理するためのメモリが必要ですので、 メモリ搭載量が極端に少ないパソコンを用いるのは無理がありますが。)

以下の説明では、

と略記します。

構成例 1L - Multi x 1 + Lite x 19

この構成では

配置します。 各 Lite は、それぞれのセグメントの活動状況を監視し、監視情報を Multi に送信します。

これは、最も安価な構成です。単純に製品単価を合計すると

Multi 96,000 x 1 + Lite 12,000 x 19 = 324,000 円(税別)
となります。実際には、ボリュームディスカウントが適用されますので、この数字よりも安くなります (正確な見積り価格については、order@wonder-lab.co.jp へお問い合わせください)。

この構成を用いる場合は、Multi を載せるパソコンは、十分に高性能 (高速CPU; 大量メモリ搭載)である必要があります。Multi は、

等の処理を、すべて並行して実行する必要があるからです。 高性能パソコンを用意するコストまで考慮すると、下記「構成例2L」または「構成例3L」のほうが 総合的には安価で、かつ、安定的な動作が期待できるソリューションとなる可能性もあります。

また、この構成を用いる場合は、

ことをお勧めします。 各 Lite が短い間隔で情報を送信すると、Multi が受信処理に忙殺され、その他の処理を十分におこなえない可能性があるためです。 セグメントが20を超えて増加するようなら、下記「構成例 3L」(n = 2以上) を採用するほうが望ましいでしょう。

なお、Lite は、TCP/UDP ポート別のトラフィックや接続状況を監視する機能を備えておりません。 これらの監視が必要な場合は、Lite ではなくPro をベースにした「構成例1P」をご利用ください。

構成例 1P - Multi x 1 + Pro x 19

「構成例 1L」とほぼ同様ですが、Lite のかわりに Pro を用います。

この構成では

配置します。 各 Pro は、それぞれのセグメントの活動状況を監視し、監視情報を Multi に送信します。

Multi 用に高性能パソコンが必要であること、各Proの送信間隔を長めに設定するほうがよいことについては「構成例 1L」と同様です。

各セグメントの監視に Pro を用いていますので、TCP/UDP ポート別のトラフィックや接続状況の監視を行なうことができます。

構成例 2L - Multi x 1 + Lite x 20

構成例 2P - Multi x 1 + Pro x 20

この構成では、すべてのセグメントに Lite または Pro を配置します。

特に、管理者がいるセグメントでは (Lite/Pro とは別のパソコンに)Multi を配置します。 そして、 Multi は、自セグメントの監視をおこなわず、Lite/Pro からの受信処理に専念する ように設定します。 こうすると、Multiは

という処理のみおこなうことになりますので、「構成例1L/1P」ほどの高性能パソコンを必要としません。 ただし、「1L/1P」と比較すると、余分にもう 1台のパソコンを必要とすることになります。

20 個のセグメントを 1 台の Multi で監視する場合、(パソコンの確保が可能であれば)「1L/1P」よりも、この「2L/2P」の構成のほうが望ましいと思います。 この構成例では、Multi は 20台の Lite/Pro からの受信処理をおこなうため、 「構成例 1L/1P」と同様、

ことをお勧めします。 また、セグメントが20を超えて増加するようなら、 下記「構成例 3L/3P」(n = 2以上) を採用するほうが望ましいでしょう。

Lite をベースにした「構成例2L」は、TCP/UDP ポート別のトラフィックや 接続状況を監視することができません。これらの監視が必要な場合は、 Pro をベースにした「構成例2P」をご利用ください。

構成例 3L - Multi x n + Lite x (20 - n)

構成例 3P - Multi x n + Pro x (20 - n)

これは、20 セグメントをいくつかのグループにわけて管理する方法です。

まず、20 のセグメントをいくつかの (この数を n とします)グループに分割します。 一般には、n=2〜5グループに分けて、各グループは3〜10個のセグメントをふくむ程度が適切でしょう。

  1. 各グループごとに、
    • どれか1セグメントにMulti を配置し、
    • 残りの各セグメントには Lite または Pro を配置します。
    そして、各 Lite/Pro は、グループ内のMulti へ監視情報を送信するように設定します。
  2. 各グループにひとつずつ配置された n個の Multi のうち、
    • どれかひとつ (総管理者が使用する Multi) を「センターMulti」とし、
    • その他の (n - 1)個の Multi を「中継Multi」として使用します。
    そして、中継 Multi は、自分が収集／受信した情報をセンターMulti へ送信するように設定します。

以上のように設定すると、

センターMultiへ集積されることになります。

この構成例は、Multi が多い分、導入コストが高価になりますが、各 Multi の (正確には、各 Multi が動作している Windows OS の) 受信処理の負荷が低いため、 「構成例 1L/1P」 「構成例 2L/2P」 と比較すると、より安定した OS の動作が期待できます。

この構成例は、ネットワークの拡張(セグメント数の増加)への対応も容易です。 「構成例 1L/1P」「構成例 2L/2P」の場合、セグメント数の増加はただちに Multi の負荷増大につながりますが、この「構成例 3L/3P」の場合は、 セグメント数の増加にあわせて Multi を増やすことにより、各Multiの負荷を 一定に押えて動作の応答性・安定性を維持することができます。

なお、

当面は「構成例 1L」または「2L」を導入し、後にMultiを追加して「3L」へ移行する
…ということも可能です (同様に、「1P」「2P」から「3P」への移行も可能です)。

さらに、この構成例では、中継Multi ごとに情報の監視操作を おこなうことができます。ネットワーク全体が複数の部署にわかれていて、 各部署ごとに責任者がいるような体制の場合に、有効に利用できるでしょう。

Lite をベースにした「構成例3L」は、TCP/UDP ポート別のトラフィックや 接続状況を監視することができません。これらの監視が必要な場合は、 Pro をベースにした「構成例3P」をご利用ください。

This page was created by Wonder Lab.