間違いだらけのネットワーク作り(18) 98/03/21
記事評”Trading Up to Switches”(Data communications MAR.98)


先週に続いて高速ネットワークがコンピュータ・システムをどう変えるか、というテーマを追えないかと思っていたところData communications3月号のチェース・マンハッタン銀行の事例が眼にとまりました。Data communicationsなお、この記事で図をData comm.から引用させて貰いました。リンクを張ってみたのですが、バナー広告のCGIが悪さをするようでうまく行かなかったためです。



チェースでは96年7月時点で上図のようなシェアド・メディア型のFDDI、イーサネットを使ってトレーディング・システム用のネットワークを作っていました。ユーザ数は1000名以上、ルータのポート数250、セグメント数 約90、サーバ数 約300。サーバはトレーディング用がSUN SPARC、情報系がIBMのPCサーバ。PCサーバからスプレッド・シートをダウンロードするのに5分かかっていました。

ケミカル銀行の合併にともないトレーディング・フロアー・ネットワークをスイッチ・ベースのネットワークに更改し、パフォーマンスの向上とマネジメント、コンフィグレーションの単純化と軽減を図りました。97年7月にはレイヤ2スイッチを主体とした階層型のネットワーク(次図)が完成しました。



この結果、ルータのポート数は24、セグメント数は5以下、サーバ数は約100に統合されました。かつて5分かかっていたスプレッド・シートのダウンロードは30秒まで短縮されました。

この事例が面白いのは@スイッチによる階層型の高速ネットワークがパフォーマンスの向上だけでなく、サーバの集約によるハードの節減や運用負荷の軽減に役立つことを証明していること、Aいいことばかりでなくトラブルやその解決策についても述べられていることです。

トラブルの一つはCabletronのスイッチで複数のブロードキャストドメインを定義したところ、IPアドレスとMACアドレスの不整合が起こったこと。結局スイッチのソフトは改修せず、スイッチあたりのブロード・キャストドメインを1つにし、Cabletronは8台のスイッチを無償で提供したとのこと。

もう一つのトラブルはBayのBackbone Concentrator Node(BCN)ルータで100Mの全二重リンクを複数使おうとしたところ、それが不可能だったこと。原因はルータ内のIntelligent Link Interfaceモジュール(2本のイーサネット・インタフェースを持つ)の処理能力不足。解決策は半二重で使うこと。(ちなみにBayはこの問題を既に解決しているとのこと。)

ネットワークでは小規模であるうちは潜在している問題でも、大規模になると思いがけないトラブルとなって顕在化します。これらはその好例と言えます。

このような製品の問題に起因するトラブルはなかなか書けないものです。BayもCabletronもData communicationsの広告主なんですから。それでも読者が一番知りたいトラブル情報をありのままに書くところが立派です。



ホームページへ