 |
|||||||||
 |
|||||||||
|
|||||||||
|
| イーサネット・フレーム・サイズとLinux アプリのネットワーク・パフォーマンス |
| Q： System i に Linux LPAR パーティションをいくつか作成し、これらを使用して他のシステムからデータを収集しています。収集したデータの操作は、非常に多量の入出力を必要とする処理によって夜間に行います。仮想 LAN インターフェースのデフォルトのイーサネット・フレーム・サイズを 1,500 バイトから 9,000 バイト (いわゆる「ジャンボ」フレーム) に変更するだけで、この夜間処理の速度が 4 倍に向上することが分かりました。System i には 100BaseT 物理インターフェースが備わっていますが、Linux 間のトラフィックはこれらのインターフェースを使用しないことが分かったので、最大フレーム・サイズを試してみました。最初の夜はすべてうまくいきましたが、次の日にユーザーから苦情が来ました。Linux アプリケーションのネットワーク・パフォーマンスが非常に遅くなったというのです。フレーム・サイズを 1,500 に戻すことで昼間のパフォーマンスは復旧しましたが、夜間の処理はやはり低速になることが分かりました。あちらを立てればこちらが立たずなのでしょうか?  A： あちらもこちらもしっかり両立させることができます。夜間にジャンボ・サイズのフレームを使用しても大丈夫です。要領としては、昼間に Linux アプリケーションを使用するユーザーがアクセスする物理ネットワークに合わせて、仮想ネットワークを調整します。 お分かりのように、フレーム・サイズを増やすと、仮想ネットワーク上でのネットワーク・パフォーマンスを飛躍的に改善できます。次の日に問題が起こった理由は、わずか 100 Mbps で稼働する物理イーサネットが、ジャンボ・フレームを処理できないことにあります。このため、ジャンボ・フレームは扱いやすい 1,500 バイトのチャンクに分割されます。残念なことに、このフラグメント化の作業には i5/OS と宛先ホスト・システムの両方で時間とメモリーが費やされます。ユーザーがパフォーマンスの低下を感じたのはこのためです。 LPAR 間トラフィック用に 1 つと、外部との通信用に 1 つ、つまり 2 つの仮想ネットワーク (または VLAN) を作成することで、この問題を回避できます。Dr. I ドクターのお勧めとして、既存の VLAN については 1,500 バイトのフレーム・サイズに戻し、ジャンボ・パケット・トラフィック用に第 2 の VLAN を作成して、9,000 バイトのフレームを使用するように Linux VLAN インターフェースを構成してください。VLAN2 には完全に分離した IP サブネットを使用するように注意してください。夜間の Linux アプリケーションは、LPAR 間の通信にこのサブネットを使用するようになります。物理 LAN 上の装置はこのサブネットに到達する方法について情報を持っていないので、ジャンボ・フレーム・インターフェースを通過することはありません。それぞれの VLAN のパフォーマンスが最適化されます。 |
 |
| ↑このページのトップへ |
| ISA サーバーが接続するLAN と WAN の両スイッチ・ポートに問題が生じた |
|
Q： ロード・バランシング構成で Microsoft の Internet Security and Acceleration (ISA) Server 2004 を実行する 1 対の Windows サーバーによって、ネットワーク境界を制御しています。大量の SSL トランザクションを処理しているのですが、ISA サーバーは暗号化のワークロードを適切に分散しながら、ISA サーバーのいずれかが故障した場合のために緊急フェイルオーバー機能も備えています。しかし、ISA サーバーが接続する LAN と WAN の両方のスイッチ・ポートに問題が生じていることに気が付きました。SSL 接続のレベルが低いときでも、これらのポートには大量のトラフィックが流れています。スニッファーを接続した後、パケットは ISA サーバーに関係ないことが分かりました。これらのパケットは、LAN 上の他の装置に送られるべきものです。これはどういうことでしょうか?スイッチは、このようなトラフィックの混合を防止するものだと思っていたのですが。
A：スイッチは通常、トラフィックを分離して、各ポートがそのポートに接続した装置宛てのパケットのみを伝送するようにします。しかし、この規則が破られる場合が 2 つあります。ポートのリンク状態が変更されたとき (例えば、ダウンからアップへ)、およびポートに着信した MAC アドレスが、そのポートの MAC アドレス・テーブル項目でないことをスイッチが検出したときです。一部のスイッチでは、こうしたイベントが発生すると、スイッチの MAC アドレス・テーブルを無効化し、ブロードキャスト・モード (すべてのパケットをすべてのポートに送信する) に戻ります。これは、スイッチがそれぞれの宛先 MAC アドレスごとにポートのロケーションを再学習するまで行われます。 通常、これらのイベントは両方ともほとんど起こらないので、ブロードキャスト・トラフィックはあまり生じません。障害のあるイーサネット・ポートが、アップとダウンの間で変動し続けていると、MAC アドレス・テーブルが常に無効化されてブロードキャスト・ストームを引き起こすことがあります。このような問題は、ISA サーバーのような 1 対の装置が、着信トラフィックのバランスを取るために MAC アドレス・スプーフィングを使用する場合にも起こりえます。一部のイーサネット・スイッチ (特に Cisco) は、2 つの異なるポートに同じ MAC アドレスが現れるとうまく動作せず、その結果ご質問のようなブロードキャスト・ストームが生じます。 |
|
| ↑このページのトップへ |
 |
 BELLDATA, Inc. Copyright reserved. |