さて、ある個所にトラフィックが集中していることが分かったとして、どのような対処の方法があるでしょうか。SalesNetを事例にとって、考えてみましょう。
SalesNetの事例
SalesServer1へのトラフィックが非常に多いことが判明。SalesServer1は部署のファイルサーバだが、SalesServer1に保存されている製品のカタログに対するアクセスが、部署外からのアクセスを含め、非常に多いことが分かった。頻繁に起こるわけではないが、新製品販売時などでアクセスが集中した際には、部署のほかの業務が継続できないほど、SalesServer1のレスポンスが悪化する
当初は課内での利用を想定していたファイルサーバの1つの機能であっても、あるとき気が付いてみたら、課内からのアクセスよりも課外からのアクセスが非常に多くなっていた、ということは、よくあることですね。
部門の業務を最優先と考えれば、とりあえずほかの部門や課からのアクセスに対して制限をかけることもやむを得ないかもしれません。しかし、有用な情報はどんどんと外部へ向けて発信していくべきことですから、ネットワーク管理者としては何とかしてこの状況を解決する必要性に迫られることでしょう。
原因の切り分けと対処
ではまず、「レスポンスが悪い」原因の切り分けをしましょう。レスポンス悪化の原因としては、主に次の3つが考えられます。
●サーバの負荷
パフォーマンス・モニタでCPUの利用率、メモリの利用率、キャッシュの利用率、ディスクの利用率などを観察してみましょう
●ネットワークの負荷
パフォーマンス・モニタや、ネットワークモニタで帯域使用率（ユーティリゼーション）などを観察してみましょう
●クライアントの負荷
サーバの負荷と同様です
ここで、サーバの負荷が高い、と判明した場合には、パフォーマンス・モニタでの計測結果に基づき、次のような対策をとることになるでしょう。
●サーバを機能ごとに分割する
ファイルサーバとプリントサーバを兼用しているサーバの負荷が高い場合、ファイルサーバとプリントサーバをそれぞれ別のサーバに分けることで、それぞれの負荷を下げることが可能です
●サーバをより高性能なものへ変更する
CPUパフォーマンスが問題の場合は、有効です
●メモリを増やす
特に、同時接続のユーザー数が多い場合は、メモリが足りなくなる場合が多いです
●HDDをより高性能なものへ変更する
HDDがボトルネックの場合は、RAIDシステムを導入する、インターフェイスをより高速なものに変更する、などの対処が有効です
などの対策が考えられますね。クライアントの負荷が高い、と判明した場合も、ほぼ同様です。
では、ネットワークの負荷が高い、と判明したときはどうしたらよいでしょうか。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のトラフィックは部課内で閉じることができます。
SalesServer1へのアクセスの大半が、1課、もしくは、営業部外から、というトラフィックパターンであれば、この対処により非常によい効果が見込めます。SalesServer1へ多数のアクセスがあったとしても、2課、3課への影響をなくすことができるからです。
ただし、SalesServer1へのトラフィックが多いとき、1課内のほかの通信は阻害されたままです。また、SaleeServer1へのトラフィックが2課や3課からも多数ある場合は、あまり効果が見込めません。
【対策-2】対策-1に加えて、SalesServer1をSHUB1へ移動する
SalesServer1をSHUB1へと直結することにより、SalesServer1とほかの部課との通信が発生しても、1課内の通信には影響がなくなります。ただし、SalesServer1のトラフィックが多いときに、1課からSalesServer1へのアクセスは改善されない可能性は高いです。
【対策-3】対策-2に加えて、SalesServer1とSHUB1間の帯域をUPする
対策-2の状況を改善するためには、SalesServer1とSHUB1間の帯域をより広帯域になるよう変更することが考えられます。例えば、SalesServer1のネットワークカードを10Mbits/sから100Mbits/sのNICに変更すれば、これまでの約10倍のトラフィックを受け付けることが可能になります。
ここでの注意点としては、10Mbits/sから100Mbits/sへNICを変更した場合、サーバの処理能力も上げる必要があるということです。10倍の処理を受け付けるネットワーク帯域を確保したとしても、サーバが10倍の処理を実行することができなければ、サーバの処理待ち行列が膨大になってしまうでしょう。ボトルネックが今度はサーバになり、レスポンスは改善されない結果となる可能性が高いですね。
サーバとスイッチング・ハブ間のレスポンスを上げる対策としては、上記に挙げたより広い帯域幅のNICを使用すること以外に、次のような対処が考えられます。
サーバとスイッチング・ハブ間を全二重にする
スイッチング・ハブと端末の間は、通常、「半二重」という通信方式を採用しています。これまでの章で、10BASE-Tや100BASE-TXでは「ツイスト・ペア」というケーブルを使用することを説明しましたが、そのペア線は全部で8本あり、10BASE-Tや100BASE-TXではそのうち4本を使用します。さらにその4本の内訳は、受信用が2本、送信用が2本です。
イーサネットはなぜ「半二重」通信なのか？
イーサネットは通常、半二重である、という話をしましたが、これはどういうことでしょうか。通常、通信は、行きと帰りがあって初めて成立しますが、半二重というのは行きと帰りが同時にはできない方式のことをいいます。いってみれば、糸電話のようなものです。糸電話も、片方の人が話している間は、他方の人は話すことができないからです。
全二重というのは、半二重とは違い、片方の人が話している間も、他方の人が話をすることができる通信方式です。一般の電話はこの方式になっていますね。2人で同時に話をすることも可能ですよね。
イーサネットはもともと、1本の線で通信を行う方式からスタートしています。この線は直径1cm強という太い銅線でできています。これは、「Thick
Net」といい、「10BASE-5」という規格です。バックボーン回線として黄色のThick Netのケーブルが張り巡らされているところもあるでしょう。
Thick Netのケーブルには、まさに1本の銅線が通されています。1本の銅線には1つの信号しか通すことができないため、1つの端末が通信をしている間は、ほかの端末は通信を行うことができません。同時に複数の端末が通信を行った場合は、信号が混じり合ってしまい、正しいデータとして送受信されなくなってしまうからです。これを制御する仕組みが、「CSMA/CD」であることは、前編で紹介したとおりです。CSMA/CD方式により、ある時点で通信を行っている端末が1台であることを保証できるようになっているわけです。
さて、このイーサネット上に端末が2台だけある場合を考えてみましょう。この場合でも、端末Aが端末Bにデータを送信している間は、端末Bは端末Aにデータを送信することはできません。これが、イーサネットは半二重である、ということです。
では、ツイスト・ペアを使用した10BASE-Tや100BASE-TXの場合はどうでしょうか。ハブと端末の間は4本の銅線で接続されており、受信用と送信用は別の線で接続されています。このため、原理的には受信と送信を同時に行うことは可能なはずですね。10BASE-Tや100BASE-TXは、ケーブル上では受信と送信が別に分けられていますが、イーサネットであるがために、送信と受信は、どちらか片方に制限されています。
ただし、1セグメントに端末が1台である、という制約が可能な場合は、ハブと端末の間は全二重で通信することも可能です。1セグメントに端末が1台、という制約が果たせる構成としては、リピータハブではなく、ブリッジやスイッチング・ハブである必要があります。
全二重通信を行うための条件
全二重の通信を行うためには、スイッチング・ハブと端末のNICの両方が、全二重モードをサポートしている必要があります。スイッチング・ハブの設定は、管理コンソールなどでポートごとに全二重モードを指定できる機器が多いです。PCのNICの設定は、ネットワークのプロパティなどで変更することが可能です。このようなスイッチング・ハブとイーサネットカードを使用している際は、この全二重モードを試してみるのもよいでしょう。
全二重に置き換えた際の効果
見込まれる効果としては、全二重であるために、送信と受信を分けて考えれば、原理的には帯域幅が2倍に膨らむということです。10Mbits/sの場合は20Mbits/sに、100Mbits/sの場合は200Mbits/sの通信が可能になるわけですね。ただしこれは、送信トラフィックと受信トラフィックが両方とも多量にある、という場合にだけ効果が出ます。例えば、頻繁に利用されるファイルサーバなどは、効果が見込めるでしょう。ファイルの保存、ファイルの読み出しともに、ほぼ同程度あると考えられるからです。
注意が必要なのは、端末、ハブともに、全二重に対応したフロー制御方式（802.3x）に対応している必要があることです。対応していなくても通信は可能ですが、ネットワークが混雑した場合、もしくは、PCの処理が追いつかない場合に、ネットワークのデータ送信を抑制することができず、データの損失が多発する可能性があるためです。
複数のNICを利用して、複数のセグメントに対応する
サーバへのネットワーク帯域幅を上げるもう1つの工夫としては、サーバに複数のNICを装着する、という方法があります。例えば、複数の100Mbits/sのNICを装着すれば、装着した数だけ、帯域を増やすことが可能です。1つのコンピュータに複数のNICを装着した状態を、デュアルホームと呼び、デュアルホームのコンピュータを、デュアルホームホスト、もしくは、デュアルホームコンピュータと呼びます。
負荷分散を行うロードバランシング
複数のNICをサーバに装着した場合、それぞれのNICをどのネットワークに接続するかは、十分に検討しなくてはなりません。また、サーバへの接続経路が複数ある、このような場合に、WINSやDNSがデュアルホームコンピュータを認識し、複数のネットワークカードに適時適切にトラフィックを振り分けるように稼働しなくてはなりません。このように同等な機能を持ったサーバやネットワークなどの資源を、適時適切にトラフィックを分配する機能を、一般的に、負荷分散（ロードバランシング）と呼びます。
SalesNetを例にすると、SalesServer1へのネットワーク負荷が高い、という問題を解決するためには、SalesServer1に3つのNICを装着し、すべてをSHUB1へ別々に接続する、という方法が考えられます。このような構成をとったときの期待効果としては、すべてのトラフィックをなるべく均等に、3本のケーブルに分散させる、ということです。こうすることで、SalesServer1への接続は、デュアルホーム化する前に比べて約3倍の帯域を確保できることになります。
サンプルのネットワーク構成を例にした場合
このような接続が期待どおりに実施されるためには、次のような仕組みが必要になります。
通常PCがサーバへ接続する際には、IPアドレスではなく、名前で指定するでしょう。例えば、「SalesServer1」がネットワーク上でのサーバの名前ですね。SalesNetがNetBEUIプロトコルを使用せずにNetBTを使用してサーバへの接続を行う構成になっているとすれば、PCがサーバにアクセスするためには、SalesServer1のIPアドレスが必要になります。Windowsのネットワーク上の名前を解決する仕組みは非常に複雑なのですべては解説しませんが、代表的な（そして推奨されている）方式として、「WINS」というネームサーバを構成することが多いでしょう。WINSサーバは、ネットワーク上のPCの名前とIPアドレスのマッピングテーブルを管理しています。このため、WINSサーバにSalesServer1のIPアドレスを問い合わせれば、「192.168.2.10」というIPアドレスを返答してくれます。
いま、SalesServer1には3つのNICが接続されているため、WINSサーバには、3つのIPアドレスが登録されることになります。PCからの要求に対して、WINSサーバは3つのIPアドレスを返答します。PCはその3つのアドレスの中で、通常は一番適したIPアドレスを選択するアルゴリズムとなっています。
今回のSalesNetの例では、SalesServer1の3つのNICは、PCから見ればすべて同じ優先順位となるため、その場合は、ランダムにIPアドレスが採用されるようになっています。このランダム性がどの程度のランダムかは検証していませんが、ある程度均等に3つのアドレスが採用されることになるでしょう。
DNSを用いた負荷分散
上記の例はWINSで説明しましたが、TCP/IP上のネームサービスにはもう1つ、DNSが存在します。SalesNetでは、WINSとDNSが併存の環境となっているため、DNSでも同様な負荷分散の仕組みが必要です。Windows
2000のDNSには、ラウンドロビンという方式が実装されており、サーバからIPアドレスを返答するときに、要求があるたびに返す値を順に変えていきます。これにより、単純な負荷分散はこの仕組みだけで構築することが可能になります。ラウンドロビン方式はすべてのDNSに装備されているとは限らないので、上記のような構成をとる際はあらかじめ調査をする必要があるでしょう。
Windows 2000にはさらに、「ロードバランシングサービス」と呼ばれる、負荷分散のためのサービスが提供されています。これは、負荷分散に加え、高可用性を実現するための仕組みで、1つのバーチャルIPアドレスで複数のホストにトラフィックを分散することが可能になります。
【対策-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への集中的なトラフィックを分散することが可能です。製品カタログへのアクセスが営業部以外からの方が多いのであれば、製品カタログへのアクセスが集中しているときでも、課へのトラフィックの影響はかなり軽減されると考えられます。
まとめ
幾つかの方法を紹介しました。皆さんのネットワークはさらに複雑な要因が絡み合っていると考えられるため、実際には、今回紹介した対策の組み合わせ、もしくは、もっと違う方法になるかもしれないですね。
まずは、トラフィックの現状を押さえるところからスタートして、来るべき障害や、ネットワークトラフィックの高騰に備えていきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.