3倍速い赤い実験サーバー 50
ストーリー by wakatono
ソリッドステートサバイバー 部門より
ソリッドステートサバイバー 部門より
Anonymous Coward曰く、"中村正三郎のホットコーナーで紹介されているのですが、(株)イーツリーズ・ジャパンで開発されたハードウェアWebサーバーがRing Serverプロジェクトに貸与され「3倍速い赤い実験サーバー」として運用されています。実験の詳細はこちらです。
実験プロジェクトの説明によると「このハードウェアWebサーバーでは、 CPUとハードディスクをなくし、Webサーバーの機能をすべてLSIにてハードウェアとして実現しております。このため従来のCPUバスボトルネックやディスクシークによる処理遅延がまったく発生せず、高負荷時にも安定してサービスを提供することができます。」とのことです。
最高スペックの製品だと6Gbpsのアウトプットがあるとか。
これには、通常の3倍のスピードの某大佐もさぞ驚きのことでしょう。"
徹底的に物理稼動部をなくして速度を上げたという感じだが、まさかプロトコル処理も含めてハード化してしまうとは…次はJSPやASP等の動的コンテンツでもチャレンジしてほしいところだ。
asahi-net (スコア:3, 参考になる)
#so-netからasahi-netへの乗り換えを検討しているけど、まぁIDで。
Re:asahi-net (スコア:0)
Re:asahi-net (スコア:1)
tracerouteしてみたけど、やっぱりasahi-netの中でつっかえてるっぽいです。
Re:asahi-net (スコア:0)
http://hanzubon.org/tmp/asahi-net2
ちょっとソースが古いけどこっちのほうが信用できるかと。
Re:asahi-net (スコア:1)
ヘッダをパースしていない (スコア:2, 興味深い)
きちんとヘッダもパースするのはハードだけでは難しいでしょうか。
Re:ヘッダをパースしていない (スコア:0)
Re:ヘッダをパースしていない (スコア:1)
のであればヘッダのパースは要りませんが、ヘッダをパースして条件付き
リクエストをサポートしたほうが速くなるよ、と言いたかっただけです。
if-modified-sinceとかrangeとか。
プロトコル処理のハード化といえば (スコア:1)
#UDPしかないけどPICに乗せるのは職人技。
Re:プロトコル処理のハード化といえば (スコア:1)
#最小限のものしか積んでないので推奨されてないようだけど。
Re:プロトコル処理のハード化といえば (スコア:0)
プロトコル処理のハード化 (スコア:1)
Re:プロトコル処理のハード化 (スコア:0)
Re:プロトコル処理のハード化 (スコア:0)
このIC高いしソフトで処理できることをハードで作ってもあまり意味ないということでしょうね。
まぁこのICがppp+TCP/IPだったということもあるでしょうけど。ちなみにTCPの最大セッションは2です。
Re:プロトコル処理のハード化 (スコア:1)
工業用のリモートIO用チップなんて、これの数倍する石は
結構あると思うし、センサーネットワークじゃない工業用
ネットワークにはTCP/IPが使われていることも多いと思うし
なんかアレだね。 売り方が下手だったのではないかと
セイコー系ってそういうの多いんだよな....
あ、ちなみにPPP+TCP/IPじゃないバージョンも存在します。
Re:プロトコル処理のハード化といえば (スコア:0)
あれ?でもVHDLもソフトだよなーー。
検証 (スコア:1, 興味深い)
バグフィックスが困難(というか作り直し)と思われますが、
検証は十分なのでしょうか?
それをsoftware実装のサーバーにフィードバックできれば
software実装のサーバーにも良い話となるのですが。
Re:検証 (スコア:1, 参考になる)
HDLで記述していればデバッグは比較的容易になります(ソフトウェアのデバッグに比較すれば遥かに大変なんですけれどね。) ウェブサーバくらいならXilinx の SpartanIIくらいで開発&実装できるんじゃないかな。
Re:検証 (スコア:0)
検証もそうですが、更新作業も大変そうですね。
本体(または内部のボード)ごと交換して更新作業を行なうことになると思いますが、シャットダウンして電源を切らなければなりませんし、何よりも各サーバごとに固有の設定類をフラッシュメモリなどを利用して移さなければなりませんし。
Re:検証 (スコア:1, 興味深い)
書き換えが完了したら、あとはリセットするだけでしょう。
#もっとも、このシステムがJTAGでのコンフィギュレーションROM書き換えに対応してるかどうかは知らない。
LSIの作り (スコア:1)
ここでいう「LSI」って、送受信すべきデータのやり取りからHTTP、TCP、IP、datalinkまでをすべてワンチップでやるのかな? それともレイヤーごとに別々のチップを使っているんだろうか... 後者だとすると、昔あった(今は不明)functionally asymmetric multiprocessorなnfsサーバの復活のような。
でも最近のNASで、ハードウェア処理をうたい文句にしたものってあまり見ないような。その点では、HTTPよりもCIFSを乗せた方がお金になるんじゃないかなぁ。
Re:LSIの作り (スコア:1)
を使う意味があまりないと思うのは私だけですかね。
この手の分野ってそこそこのお金が取れるし、家電製品
みたいに量が出るわけでもないのだから、FPGAで1チップ
に実装してしまったほうが、チップ間の遅延やらなにやら
色々問題が起きなくて良いのと、書き換える時楽なのでは
と思います。
FMP (スコア:0)
GlassHouseに買収されてしました...
むかし (スコア:1)
私も学生時代にFPGAを使ったSMTPサーバを作ろうかと思っていました。送信だけならなんとかなるかなぁと・・・
そういえば、TCP/IPをワンチップ化した石がイスラエル辺りの会社から出ていたような気がするので、それを使えばあとはHTTPの処理だけですかね。
ワンチップWebサーバ (スコア:1)
IPic - A Match Head Sized Web-Server [umass.edu]
webACE Server [d116.com]
9pinシリアルケーブルに申し訳なさそうに
くっついてる [d116.com] のが妙に可愛い(^^;)。
Re:むかし (スコア:1)
>サーバが公開されていました。ちゃんとネットに繋がっていましたよ。アクセ
>スして閲覧できました。
これ [umass.edu]とかこれ [d116.com]
なんかの事でしょうか。
こういうのを見ると、組込み用途にもWebアプリが使えそうな気が
してきますね。:-)
Re:むかし (スコア:0)
おかげでこのはトラブル対処が楽。
アドレスさえ解れば確認・テストが直に出来るので。
#でも、サービスマンはテストせず交換したりするんだよなぁ。
Re:むかし (スコア:1)
>7セグが表示されてますし、データロガー用はデータがずらずらと見えます。
なるほど、産業用では既に存在しているのですね
私としては全ての白物家電の操作パネルがブラウザ&Webアプリで
実装される事が一般的になる日もそう遠くないのかなぁなんて妄想
しているのですが。(^^;
# 一部の携帯電話ではメールやブックマーク管理機能等で実装済かな?
Re:むかし (スコア:0)
こういうのもありますね。
Re:むかし (スコア:0)
やっぱりPICでUDP。 [titech.ac.jp]ソースあり。
現在のコンテンツ (スコア:1)
SF.jpだけでは重いという声が多かったので、Ringサーバープロジェクトさんにお願いしました。
最新のダウンロードリストは、OOo Wiki [xrea.com]にあります。
バージョン1.1のRC3も提供しています
Re:現在のコンテンツ (スコア:0)
5万ゲート (スコア:1)
Re:5万ゲート (スコア:1)
PICNIC程度のもので良いのでしたら、問題なくできると思います。
早速落ちているようですが (スコア:0)
自社のサーバが早速落ちているようですが.... 高負荷にはやはり弱いのかな?
Re:早速落ちているようですが (スコア:3, おもしろおかしい)
こりゃ管理者さんは青くなってますな(笑)
Re:早速落ちているようですが (スコア:0)
ところでサイトにある
> また、OSすら必要なく、HDDも持たないためCPUの暴走やHDDのディスクシークといったサーバ管理者が頭を痛める問題がまったく存在
Re:早速落ちているようですが (スコア:1, 興味深い)
動的に生成するページには利用できませんが、記事配信のような一方的なページでは有用ですね。まあ、この仕組みが一番有効なサイトはエロサイトでしょう。ハァハァする大量の大きな画像や動画がバリバリと....
でも、1000台のWEBサーバに相当という程の応答性はないし、頻繁にエラーになるし(時々落ちてリセットがかかっている?)、完成度としてはもう一歩といったところでしょう。
Re:早速落ちているようですが (スコア:0, オフトピック)
Re:早速落ちているようですが (スコア:0, オフトピック)
1000台のWEBサーバの目の前にして頭に稲妻が走った瞬間該当すると
サーバを手早くリセット!ですか
(稲妻) 甘い!! ポチ、ポチ、(稲妻)そこだ-、ポチ
#あのコスチューム姿で見たく無いのでAC
Re:早速落ちているようですが (スコア:1, 興味深い)
性能評価の方法がちょっと恣意的なような.... 16GBのメモリを搭載したFlatSevenと、貧弱なハードウェアのApacheを比較しても仕方ないでしょう。
今後静的コンテンツを扱うハイエンドサーバなら、Opteronマシンにメモリを大量搭載し、Linuxの同時コネクション受付け数を大きくし、Apacheのコンフィギュレーションを変更して並列度をあげてやるほうが圧倒的にコストパフォーマンスが良いなぁ。いざというとき動的なページも扱えるし。
Apacheはかなり性能が上がったよ (スコア:2, 参考になる)
最近のApacheはsendfileシステムコールを利用しているのでCPUバスボトルネックは発生しません。多分、このアイデアが出た当時には正しかったのでしょう。ただFlatSeven開発中に、汎用のハードウェアもソフトウェアも進化してしまって、当初予定していたほどの圧倒的な差をつけるのが難しくなってきてしまったんでしょうね。
Re:早速落ちているようですが (スコア:1)
http://e-trees.jp/products/web_result.html [e-trees.jp]
Re:早速落ちているようですが (スコア:1)
バナー広告は? (スコア:0)
この手の大量アクセスのあるサイトにはバナー広告が必須ですが、どうやって実現するのでしょう?実は思ったより適用でる分野が少なかったりしませんか?
Re:バナー広告は? (スコア:0)
Re:バナー広告は? (スコア:0)
ブロック崩し(テーブルテニスだっけ?)にはCPUなんか無いって言われて感動した覚えがあるんでAC
こういうのは (スコア:0)
さすがにWebサーバのような、将来はプロトコルが変る可能性があるものとか、変更の多そうなものは、ちょっと辛いんじゃないか、と思うが。
SSLアクセラレータみたいな… (スコア:0)
Ethernet→NIC→ハードウェアロジック→PCI
これからPCIスロットを持つサーバなら恩恵を受けることができるでしょうし カーネルにうまく組み込めると思います。
動的なページはCPUが処理 単純なGETならハードで処理というふうにできます。
4年も掛かって大規模なもの作るより 上記ボードを1年で作ったほうがいいと思うけど・・・
Re:SSLアクセラレータみたいな… (スコア:0)
SSLアクセラレータボード買うくらいだったらFreeBSDマシン並べてソフトウェア処理させたほうがずっとSSL処理速くて値段も