あなたのLANは健康ですか? 現状改善から一歩進んだ構築術まで
特集:基礎から学ぶネットワーク構築
篠原光太郎
2001/5/19
| Part 7 トラフィックの傾向と対策 |
さて、ある個所にトラフィックが集中していることが分かったとして、どのような対処の方法があるでしょうか。SalesNetを事例にとって、考えてみましょう。
■SalesNetの事例
|
当初は課内での利用を想定していたファイルサーバの1つの機能であっても、あるとき気が付いてみたら、課内からのアクセスよりも課外からのアクセスが非常に多くなっていた、ということは、よくあることですね。
部門の業務を最優先と考えれば、とりあえずほかの部門や課からのアクセスに対して制限をかけることもやむを得ないかもしれません。しかし、有用な情報はどんどんと外部へ向けて発信していくべきことですから、ネットワーク管理者としては何とかしてこの状況を解決する必要性に迫られることでしょう。
■原因の切り分けと対処
ではまず、「レスポンスが悪い」原因の切り分けをしましょう。レスポンス悪化の原因としては、主に次の3つが考えられます。
●サーバの負荷
パフォーマンス・モニタでCPUの利用率、メモリの利用率、キャッシュの利用率、ディスクの利用率などを観察してみましょう●ネットワークの負荷
パフォーマンス・モニタや、ネットワークモニタで帯域使用率(ユーティリゼーション)などを観察してみましょう●クライアントの負荷
サーバの負荷と同様です
ここで、サーバの負荷が高い、と判明した場合には、パフォーマンス・モニタでの計測結果に基づき、次のような対策をとることになるでしょう。
●サーバを機能ごとに分割する
ファイルサーバとプリントサーバを兼用しているサーバの負荷が高い場合、ファイルサーバとプリントサーバをそれぞれ別のサーバに分けることで、それぞれの負荷を下げることが可能です●サーバをより高性能なものへ変更する
CPUパフォーマンスが問題の場合は、有効です●メモリを増やす
特に、同時接続のユーザー数が多い場合は、メモリが足りなくなる場合が多いです●HDDをより高性能なものへ変更する
HDDがボトルネックの場合は、RAIDシステムを導入する、インターフェイスをより高速なものに変更する、などの対処が有効です
などの対策が考えられますね。クライアントの負荷が高い、と判明した場合も、ほぼ同様です。
![]() |
| 図15 SalesNetのネットワーク構成(図版をクリックすると拡大表示します) |
では、ネットワークの負荷が高い、と判明したときはどうしたらよいでしょうか。SalesNetでは、「192.168.2.1」セグメントのトラフィックが飽和状態になっていることが分かりました。3つの課が使用している「192.168.2.1」セグメントは、4つのハブで構成されていますが、すべてのトラフィックがすべての課で共有される構成になっています。つまり、PCからSalesServer1へ通信が行われると、その間はほかのすべての通信ができない状態になる、ということです。
このような場合、とるべき対策としては、「集中しているトラフィックを分離する」ということです。集中しているトラフィックを分離することができれば、そのほかのトラフィックを解放することができます。SalesNetの場合は、SalesServer1へのトラフィックを分離することを検討するべきでしょう。幾つかの対策を順に考えてみましょう。
■【対策-1】HUB1をスイッチング・ハブへ変更する(SHUB1と名称変更)
HUB1はSalesNetの部課をつなぐ親ハブです。HUB4/HUB5/HUB6は、HUB1を起点にスター型に接続されています。このHUB1をスイッチング・ハブに変更すると、部課内の1対1のトラフィックは部課内で閉じることができます。
|
|
| 図16 SalesNetの部課同士を接続している親のハブをスイッチングハブに変更する |
SalesServer1へのアクセスの大半が、1課、もしくは、営業部外から、というトラフィックパターンであれば、この対処により非常によい効果が見込めます。SalesServer1へ多数のアクセスがあったとしても、2課、3課への影響をなくすことができるからです。
ただし、SalesServer1へのトラフィックが多いとき、1課内のほかの通信は阻害されたままです。また、SaleeServer1へのトラフィックが2課や3課からも多数ある場合は、あまり効果が見込めません。
■【対策-2】対策-1に加えて、SalesServer1をSHUB1へ移動する
SalesServer1をSHUB1へと直結することにより、SalesServer1とほかの部課との通信が発生しても、1課内の通信には影響がなくなります。ただし、SalesServer1のトラフィックが多いときに、1課からSalesServer1へのアクセスは改善されない可能性は高いです。
|
|
| 図17 アクセスが頻発する「SalesServer1」を親のスイッチングハブに直結することにより、1課内のトラフィックと切り分ける |
■【対策-3】対策-2に加えて、SalesServer1とSHUB1間の帯域をUPする
対策-2の状況を改善するためには、SalesServer1とSHUB1間の帯域をより広帯域になるよう変更することが考えられます。例えば、SalesServer1のネットワークカードを10Mbits/sから100Mbits/sのNICに変更すれば、これまでの約10倍のトラフィックを受け付けることが可能になります。
ここでの注意点としては、10Mbits/sから100Mbits/sへNICを変更した場合、サーバの処理能力も上げる必要があるということです。10倍の処理を受け付けるネットワーク帯域を確保したとしても、サーバが10倍の処理を実行することができなければ、サーバの処理待ち行列が膨大になってしまうでしょう。ボトルネックが今度はサーバになり、レスポンスは改善されない結果となる可能性が高いですね。
サーバとスイッチング・ハブ間のレスポンスを上げる対策としては、上記に挙げたより広い帯域幅のNICを使用すること以外に、次のような対処が考えられます。
|
■【対策-4】SalesServer1を「192.168.1.1」セグメントへ移動する
「192.168.1.1」セグメントは、SalesNet全体で共有されるサーバを集中して接続しているセグメントです。部門で管理しているサーバのセキュリティ管理と、営業部外からのトラフィックが部門内のトラフィックに影響しないようにとの考慮のもと、このような構成をとっています。
SalesServer1を「192.168.1.1」セグメントへ移動すれば、SalesServer1へのトラフィックを部課内のトラフィックから分離することができ、SalesNetのほかのサーバと同様な管理体制をとることも可能です。
ただし、この対処が有効なのは、SalesServer1へのトラフィックの多くが、営業部以外からのトラフィックの場合です。第1課からのアクセスがほとんどの場合は、効果が出ないばかりか、第1課からSalesServer1へのアクセス経路にルータが追加されるため、レスポンスはさらに悪くなる可能性があります。
また、部門外からのアクセスが集中する際、SalesNetのほかの共有サーバ(SalesFS/SalesPDCなど)へのアクセスも阻害される可能性があるので、注意が必要です。
■【対策-5】SalesServer1の製品カタログをSalesFSに移動する
ネットワーク的な解決策ではありませんが、トラフィックを分離するために、マシンの配置を変えることも時には必要になるでしょう。例えば、SalesServer1の製品カタログをSalesFSに移動することで、SalesServer1への集中的なトラフィックを分散することが可能です。製品カタログへのアクセスが営業部以外からの方が多いのであれば、製品カタログへのアクセスが集中しているときでも、課へのトラフィックの影響はかなり軽減されると考えられます。
■まとめ
幾つかの方法を紹介しました。皆さんのネットワークはさらに複雑な要因が絡み合っていると考えられるため、実際には、今回紹介した対策の組み合わせ、もしくは、もっと違う方法になるかもしれないですね。
まずは、トラフィックの現状を押さえるところからスタートして、来るべき障害や、ネットワークトラフィックの高騰に備えていきましょう。
| Index | |
| 特集:基礎から学ぶネットワーク構築 | |
| Part
1 あなたのLANは大丈夫? ・こんなトラブルを経験したことはありませんか? |
|
| Part
2 ネットワークの健康状態のチェックポイント ・ネットワークの管理はちゃんとできているか? ・ネットワークの構成を把握し、問題点はないか? |
|
| Part
3 トラブル予防は現状の把握から ・まずは自分のネットワークの現状を知ろう ・ネットワーク構成図を描く手順 ・ネットワーク構成の棚卸 |
|
| Part
4 ネットワーク構成の見直しで状態改善 ・まずは配線の状態をチェック -ケーブルは規格を満たしているか? -ケーブル長は規格内に収まっているか? -ケーブルはきちんとした状態で保護されているか? ・基本的なネットワーク機器の構成を理解する -ハブのカスケード段数は規格内に収まっているか? -ルータ/スイッチ/ハブは特性を理解して配置されてる? |
|
| Part
5 トラフィック計測で見直すネットワーク構成 ・ネットワークトラフィックを理解する ・トラフィックのパターン分析 |
|
| Part
6 Windows標準ツールを使ったトラフィック計測 ・ネットワークのトラフィックを観察してみる ・スイッチングハブ環境でのトラフィックの計り方 ・サーバのトラフィックの計り方 ・トラフィックの傾向分析 ・さらに細かいトラフィックの計り方 ・ネットワーク・モニタリング・ソフト紹介 |
|
| Part 7 トラフィックの傾向と対策 ・原因の切り分けと対処方法 -集中しているトラフィックを分離すべきか? -ネットワークの帯域を抜本的に強化すべきか? -その他、ケーススタディを例に紹介 |
|
| 「Master of IP Network総合インデックス」 |
TechTargetジャパン
- 「ネットワーク仮想化」がもたらすもの (2012/5/25)
キャリアイーサネット網で展開されているVPNサービスをSPBに置き換えると、どんな変化が起こるのか - 「Meteor」で来れ、1億総Webアプリ開発者の時代 (2012/5/16)
文系人間の筆者でも、「これならWebアプリ開発、できるかも」と思わせてくれるフレームワーク、Meteorの可能性を予想してみたい - ついに来た? 「真のIPv4アドレス在庫枯渇」 (2012/5/14)
IANAやAPNIC/JPNICが管理するIPv4アドレスの在庫が枯渇してから1年。いま、水面下で「真の枯渇」が始まりつつあります - SLB-PTでWebサーバをさくっとIPv6対応に (2012/4/26)
いくつか存在するIPv6移行ソリューションの中から、SLB-PTを用いて、さくっとWebサーバをv6対応させる方法を説明
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -




