« October 2004 | Main | December 2004 »

November 22, 2004

コンテンツプロバイダーのネットワーク費用はかなり安くできる

通信の世界には上りと下りがあるのは言うまでもないですよね。この上りと下り、一般的にコンテンツプロバイダー側では上り(ユーザへのレスポンスパケット)が圧倒的に多く、下り(ユーザからのリクエストパケット)が少ない。それに対してユーザ側では上り(サーバへのリクエスト)が少なく、下り(サーバからのレスポンス)が圧倒的に多い。

 

これを通信業者の目から見たマクロの世界で考えてみましょう。コンテンツプロバイダー側に近いところの線を提供している通信業者は一般的に(コンテンツプロバイダーから見て)下りがスカスカです。逆にユーザ側に近いところの線を提供している通信業者は一般的に(ユーザから見て)上りがスカスカです。これは何を意味するか。ユーザ側に近いところの線を提供している業者は、(ユーザから見て)上りがスカスカなので、この部分を埋めてくれるコンテンツプロバイダーと契約すれば追加費用なしに売り上げを増やせると考えるわけです。

 

世の中コンテンツプロバイダーの数と比較したら圧倒的に一般ユーザのほうが多いです。そう考えるとほとんど全ての通信業者の(ユーザから見て)上りがスカスカな状況です。となるとコンテンツプロバイダーとしたら完全に買い手市場なわけで、この原理をしっかり理解して価格交渉に臨めばネットワーク費用をかなり安く押さえることができそうです。

| | Comments (0) | TrackBack (0)

November 17, 2004

社内ネットワークに認証スイッチや検疫LANを導入しよう

会社が小さかった頃は社内セキュリティをしっかりしようとして、個人ノートPCの持ち込みをいちいちチェックし、その都度IPを発行していました。しかし会社規模が急に大きくなるとその作業だけでかなりの負担になってきたのでDHCP公開することにしてしまいました。そうなると予想通り社外の人間(来訪者)がノートPCをつないだり、アンチウィルスソフトの入っていないノートPCを持ち込む人を制限できなかったりするようなことが起こるようになります。かつそういったことが全くログに残らないという大きな問題が生じました。

【認証スイッチと検疫LANとは何か?】
そんなときに雑誌で見て「いいなぁ」と思ったのに認証スイッチと検疫LANというものがあります。認証スイッチとはLANにつなげる際、認証スイッチにて認証を済ませないとLANに接続できないというもの。検疫LANとはセキュリティポリシーに適合するクライアントPCだけを社内LANに接続可能にするソリューションです。これらは情報システム部員の負担をかなり軽減してくれそうな魅力的なソリューションであります。

■参考
http://www.hitachi-cable.co.jp/infosystem/extreme/case/interview8.stm
http://www2.hitachi-cable.co.jp/apps/hnews.nsf/0/c4718c71dfdd991b49256e930016fd57?OpenDocument
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20041028/151841/

| | Comments (2) | TrackBack (2)

November 12, 2004

HTTP圧縮を実現するアプライアンスサーバ

サーバ設定変更でHTTP圧縮を実現するのは結構大変です。Apacheであればmod_gzipインストール、IISであればIISの圧縮機能設定やISAPI追加等の必要があります。これらの設定は概してとても面倒で、HTTP圧縮の威力はよくわかるものの、システム管理者としては極力楽にそれを実現したいと思うわけです。そこで今回はHTTP圧縮を実現するアプライアンスサーバをいくつかご紹介しましょう。

【HTTP圧縮アプライアンスサーバの仕組み】
通常のネットワーク構成ではロードバランサーの下にWEBサーバをぶら下げる構成を取ります。HTTP圧縮アプライアンスサーバを導入する場合は、WEBサーバからの戻りパケットがアプライアンスサーバを通るように構成します。すなわち戻りパケットをWEBサーバから受け取り、アプライアンスサーバがデータを圧縮してクライアントに返すわけです。とってもお手軽です。

【販売しているHTTP圧縮アプライアンスサーバ】
現在販売されているものを簡単に調べてみました。ハードウェアタイプのものとソフトウェアタイプのものがあります。

http://www.macnica.net/redline/
http://www.takachiho-kk.co.jp/products/networking/prod/netscaler/
http://www.ashisuto.co.jp/prod/detail.php?A=83
http://www.ashisuto.co.jp/prod/quix/web/gaiyo01.php
http://www.zend.co.jp/products/zps/

■参考
http://nosa.cocolog-nifty.com/sanonosa/2004/09/http.html

| | Comments (0) | TrackBack (0)

November 10, 2004

L4スイッチはDSR構成にすべし

大規模サイトではL4スイッチをDSR(Direct Server Return)構成で組むことはもはや常識です。しかし国内には大規模サイトが少ないためかDSR構成についての情報が不足しているのが現状です。L4スイッチを扱っているベンダーさんもDSR構成でネットワークを構築したという例をほとんど聞かないとのことです。そこで今回はDSR構成の紹介とメリット&デメリットをご紹介します。

 

【一般的な構成とDSR構成の違い】 一般的な構成ではスイッチとサーバの間にL4スイッチを挟み込む構成を取ります。それに対してDSR構成ではスイッチに直接L4スイッチを接続します。
DSR1.gif

 

これを踏まえてパケットの流れを見てみましょう。一般的な構成では行きのパケットがL4スイッチを流れサーバに到達し、帰りのパケットもL4スイッチを流れていきます。それに対してDSR構成では行きのパケットはL4スイッチを通りますが、帰りのパケットはサーバから直接スイッチを通っていきます。
DSR2.gif

 

DSRの詳しい設定方法はL4スイッチのベンダーさんに譲るとして、1つ注意としてはサーバのNICにVIPをIPアドレスとしたloopbackを必ず設定してください。以下設定例です。(netmask、network、broadcastの設定値も注意です)


DEVICE=lo:0
IPADDR=172.16.0.120
NETMASK=255.255.255.255
NETWORK=172.16.0.120
BROADCAST=172.16.0.120
ONBOOT=yes
NAME=loopback:0


 

【DSR構成のメリット】 DSR構成のメリットは3点あります。

 

①L4スイッチがネットワークトポロジーから独立することによりネットワーク構成が比較的自由になる 一般的な構成ではスイッチとサーバの間にL4スイッチを挟まなければならないという制約がありました。これはサーバ構成を変更するときやL4スイッチが故障した時にいちいちネットワーク構成まで変更しなければなりませんでした。その制約がDSR構成ではなくなります。図のように基本的にどのスイッチにL4スイッチを接続してもロードバランシングが可能です。
DSR3.gif

 

 

②リクエスト量に対するL4スイッチのキャパシティが増える 通常WEBサーバではin-boundとout-boundのトラフィックに圧倒的な差があります。通常WEBサーバは数バイトのリクエストに対して数10~数100kバイトのレスポンスを返すからです。一般的な構成の場合L4スイッチが上りも下りもトラフィックを処理します。例えばin-boundが20Mbpsでout-boundが120Mbpsだとしましょう。L4スイッチが100MのFastEtherポートを持っていた場合、in-bound側はまだ80Mbpsも余裕があるのに、out-bound側の20Mbpsの不足のためポートをギガビット化しなければなりません。図を見てください。上図は一般的構成の場合、下図はDSR構成の場合です。DSR構成ではin-bound量とout-bound量がほぼイコールになります。out-bound量が大幅に節約できたことによりリクエスト量に対するL4スイッチのキャパシティが大幅に増えることになります。
DSR4.gif

 

DSR5.gif

 

 

③ポート数が1ポートで良い 一般的な構成ではL4スイッチにたくさんのスイッチかもしくはたくさんのサーバを接続するためポート数がたくさん必要になります。しかしポート数が多いL4スイッチは非常に高価なので通常はL4スイッチの下にL2スイッチをぶらさげそこにサーバを取り付ける構成を取ります。それに対してDSR構成では上位スイッチに1ポートだけ取り付ければよいので非常に経済的です。(無論ニ重化やトランキングをする場合はもっと必要ですけど)

 

 

【DSR構成のデメリット】 一件良いことずくめのDSR構成ですがこれまで様々な実験や実稼動を経験してきてDSR構成にはいろいろなクセがあることがわかっています。そのクセを自分のものにしない限りは安心して本番系に投入できないかもしれないですね。デメリットは3つあります。

 

①DSR構成時の内部の動きが理解しにくい サーバのloopback設定が鍵になるのはなんとなく理解していただいたと思いますが、L4スイッチ内でどのように動いているのか等100%完全に理解できないところが気持ち悪いところです。

 

②上位L3スイッチにサーバのMACアドレスが残ってしまうことがある DSR構成にしてしばらくはきちんとロードバランスされていても時間が経つと特定サーバにロードが偏ってきてしまう場合はおそらくこれです。我々の調査ではどうやらLinux Kernel2.4の場合この現象が起こるようです。Linux Kernel2.6にすれば大丈夫っぽいですが、応急処置として上位L3スイッチのMACテーブルをstaticに書くという方法もあります。

 

③全WEBサーバにloopback設定をする必要がある サーバ台数が少ないサイトはよいですが、うちのように600台以上サーバがあるだけでなく、OSだけでも5~6種類、バージョンも千差万別なサイトではかなり大変です。テストしながら少しずつ適用していったのでたぶん1年近くかかったのではないかな・・・。

 

■他の関連記事
Windows serverでDSRを行う方法

 

■参考文献
http://www.cisco.com/japanese/warp/public/3/jp/solution/slbguide/slb_03.shtml

 

 

PS: CISCOのアイコンライブラリーをクリップ素材として使わせてもらいました。

| | Comments (9) | TrackBack (1)

November 05, 2004

HTTPヘッダー研究その4: IISのHTTPヘッダーを書き換えよう

IISのHTTPヘッダーを書き換える方法は、apacheのそれと比べて情報源がかなり限定されていて調べるのに大変苦労しました。それだけにここでその方法を書いてしまうのはちょっと惜しい気持ちもあるのですが、まあ隠しても仕方ないので書いてしまいます。(この書き込みが役に立たれたら是非コメント欄に書き込んでください・・・)

基本的にIISでHTTPレスポンスヘッダーを書き換えるためにはISAPIフィルタリングアプリケーションをIISに登録する必要があります。

【HTTPヘッダーを自由自在に書き換える方法】
HTTPヘッダーを自由自在に書き換えられる無料のISAPIアプリは残念ながらみつかりませんでした。しかし有料ではservermaskという強力なものがあります。

servermaskは不要なHTTPヘッダーを消したり書き換えたりする機能の他に、HTTPヘッダー的に他のWEBサーバに化けるという機能もあります。HTTPヘッダーいじりが本当に自由自在にできるので便利です。価格は1サーバライセンス99.95ドル。サーバ台数が少ないサイトでは有効ではないでしょうか。(うちはサーバ台数が多すぎて無理です・・・)


【HTTPヘッダーの製品情報を隠蔽する】
製品情報の隠蔽、すなわちServerName部分だけ隠蔽するだけだったら無料のISAPIが2つ存在します。

1つめはマイクロソフト社が提供するURLSCANツールを入れる方法です。

まずはインストールしましょう。次に設定ファイルを変更します。設定ファイル

c:\WINNT\system32\inetsrv\urlscan\urlscan.ini

の中で「RemoveServerHeader=1」として、urlscan.exeを実行し、IISを再起動することで適用されます。ただしURLSCANツールはHTTPヘッダーの書き換えのためにあるというよりは不正アクセスの防御のために作られたツールです。適用の前にはURLSCANの仕組みをよく理解しておくことが必要です。特に[AllowExtensions]に.aspを追加し、[DenyExtensions]で.aspを削除しておかないとASP言語の実行がされなくなります。使い方を間違えるととても危険なツールです。


もう1つはMoIISProtectをISAPIに追加する方法です。

MOIISProtectをISAPIフィルタに登録するだけでIIS製品情報が非表示になります。これは簡単で便利です。
MOIISProtect.gif


【HTTPヘッダーのETag情報を隠蔽する】
最後にETag情報だけを隠蔽するためのETagFixというISAPIアプリを紹介します。これは試してないですが、多分予想通りの働きをしてくれるものと思われます。無料だそうです。

| | Comments (0) | TrackBack (2)

« October 2004 | Main | December 2004 »