トップページ⇒unix
1001コメント297KB

だまれ小僧！お前にサンが救えるか

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001名無しさん＠お腹いっぱい。NGNG
まあね、JAVAとかいろいろあったし
サーバーも最近はIBMに押され気味だし・・・
0878名無しさん＠お腹いっぱい。05/03/13 01:42:36
>>874
性能はともかくものすごく売れてるのは間違いない
087987405/03/13 02:24:33
いや、(性能は普通と思うんだが)売れてるのか?って聞きたかった。
Dellのマシンによく載ってるのは知ってるけど。
0880名無しさん＠お腹いっぱい。05/03/13 02:51:12
Solaris x86&Sun Studio 10+Opteronよりも
Linux&Eclipse+Intel compiler 8.1+EM64T Xeonの方が将来ありそう
0881名無しさん＠お腹いっぱい。05/03/13 02:57:31
>>880
だまれ小僧！
>>879
ttp://pcweb.mycom.co.jp/news/2005/02/09/002.html
64ビット対応Xeonは最初の6カ月で100万個を出荷し、
2004年第4四半期では32ビット対応製品の出荷台数より上回ったという。
2005年第1四半期の出荷ではXeonの80%が64ビット対応になる予定としている。
0882名無しさん＠お腹いっぱい。05/03/13 03:00:07
同社によれば、EM64T搭載の64ビットXeonは、発表から8カ月で、
出荷個数が200万個に達したとしている
ttp://pcweb.mycom.co.jp/news/2005/02/15/006.html
0883名無しさん＠お腹いっぱい。05/03/13 03:34:00
Xeonって速いのか？
Opteronの方が性能よさげだけどどうなの？
0884名無しさん＠お腹いっぱい。05/03/13 03:39:51
動作速度よりもIntelのブランドやサーバ独自の耐障害性とか
いろいろ見るべきところあるから
値段とかサポートなんかも
0885名無しさん＠お腹いっぱい。05/03/13 03:49:23
CPUだけで耐障害性が変わるのか？
Opteron搭載サーバーはSUN、HP、IBMとも出してるわけだが
特にラックマウントサーバーのような高密度の実装をする場合は
消費電力が少ないOpteronの方が有利だと思うけど
0886名無しさん＠お腹いっぱい。05/03/13 03:51:44
>>883
プロセッサ自体は現時点で圧倒的にOpteronの方がいい。
EM64Tは64bitで動かすと遅くなることもままある。
EM64T enableなXeonも実際は32bit OSで動かしてる所が多いようだ。
0887名無しさん＠お腹いっぱい。05/03/13 03:53:44
サーバ独自の耐障害性って書いたろ？目開けてちゃんと嫁
0888名無しさん＠お腹いっぱい。05/03/13 04:02:51
SUN、HP、IBMが出してるOpteron搭載サーバーにはサーバー独自の耐障害性はないってこと？
0889名無しさん＠お腹いっぱい。05/03/13 04:04:02
>>885
CPU変ればチップセットも変る。メモリやIOとの相性もあるし。
でもまぁ実際の所はIntelのリベートが大きいんじゃないのかな。
Xeon買ってくれたらceleronくれるとか。
blade serverでOpteronが有利なのは事実。
次のOpteronはCnQも付けるようだし。
サーバーでquietは変だからPowerNowという名前だけど。
0890名無しさん＠お腹いっぱい。05/03/13 04:05:26
Xeonって速いのかって問いに対して、
いろいろ評価ポイントはあるって答え自体がトンチンカンなんだよ
「見るべきところ」の重要な要素として速度があるんじゃねーか
0891名無しさん＠お腹いっぱい。05/03/13 04:11:09
F1と軽自動車
日本一週したらどっちが勝つ？
0892名無しさん＠お腹いっぱい。05/03/13 04:11:40
メモリやI/Oの相性問題ってサーバーはパソコンじゃないんだから
メーカーが動作保障したのを購入すればいいんじゃないの？
0893名無しさん＠お腹いっぱい。05/03/13 04:13:07
>>891
F1に相当する信頼性の低いプロセッサは市販されてません
0894名無しさん＠お腹いっぱい。05/03/13 04:17:25
アホくさ
>CPUだけで耐障害性が変わるのか？
これに突っ込んだんじゃン
バカみたいなことイッテンナヨ
Xeonが売れてるか売れてないかって話してんのに
速いからXeonが売れてると思ってんのかYO
noconaのベンチマークが欲しけりゃTomのところでもどこでも逝ってこい
0895名無しさん＠お腹いっぱい。05/03/13 04:19:20
>>892
サーバーはパソコンじゃないから問題になるんですよ。
要求される信頼性が桁2つ以上違う。
0896名無しさん＠お腹いっぱい。05/03/13 04:24:45
売れ線のIAサーバはパソコンに毛が生えたようなもんだし
Sunのローエンドも似たり寄ったり
要求される信頼性は鯖のロールやシステム構成によって違う罠
0897名無しさん＠お腹いっぱい。05/03/13 04:26:15
SUNやIBMやHPが発売してるOpteronサーバーはそんなに信頼性が低いのか？
それに高信頼性を追及したサーバーはPCサーバーでも高額になるんじゃないの？
0898名無しさん＠お腹いっぱい。05/03/13 04:29:10
そりゃ求められる信頼性による罠
メモリやCPUのホットスワップって可能か>Op
付加価値付いてもRISC鯖より安いよね
0899名無しさん＠お腹いっぱい。05/03/13 05:04:10
まあ、少なくとも現状、そういう高い価格が付いてること自体が
非IAなサーバマシンの価値を証明しているよね(循環論法)
0900名無しさん＠お腹いっぱい。05/03/13 05:18:52
付加価値はともかくSPARC入れた時点で割高だけどね
ニッチだが仕方ないが
基本的にその手の機能ってチップセット側に持たせるから
メモリコントローラをオンダイにしたOpは
そっち方向の発展はちと辛そうだなと
0901名無しさん＠お腹いっぱい。05/03/13 05:19:35
ま、だからこそSunがパートナーに選ぶべき相手だったとは言える
0902名無しさん＠お腹いっぱい。05/03/13 07:29:28
はっきりいってIA Serverの方がSunより安定していると思うよ。
これは大手であればメーカーを問わず。
0903名無しさん＠お腹いっぱい。 05/03/13 07:40:46
>>大手であればメーカーを問わず
V20, V40は品質悪すぎ
0904名無しさん＠お腹いっぱい。05/03/13 11:54:29
>>903
禿同。
あれで、アノ値段はぼったくりすぎ。
初期不良で即交換だったし…。
0905名無しさん＠お腹いっぱい。05/03/13 13:34:32
>>902
詳しく
0906名無しさん＠お腹いっぱい。05/03/13 15:22:57
OSとCPUを一緒に提供できるのがSunの強みなんてscottが
いってたけど、それだけだろ。
これら以外の相性は最悪！
NIC, Storageあたりなんてよせあつめじゃねーか！
だいたい、障害原因の調査に2ヶ月もかけて、NTFとはなにごとじゃ！！
0907名無しさん＠お腹いっぱい。05/03/13 15:32:22
Sunのストレージを買うヤシは負け組
0908名無しさん＠お腹いっぱい。05/03/13 16:17:44
某大学、60TB以上入れたんだけど、大丈夫だろうか。
中の人、インプレきぼん。
0909名無しさん＠お腹いっぱい。05/03/13 16:21:48
最上位は、Hitachi製だから、まあええんちゃう？
15xxとか買うのは確かに負け組みだな（ｗ
0910名無しさん＠お腹いっぱい。05/03/13 18:13:21
最上位は、SANRISEなので差別化要素ゼロ。
どこからでも買える。
ローエンドは、dothill。中間ラインはMaxtrat系にpirusを使うだけ。

SunのR&Dって、企業買収だけか？
0911名無しさん＠お腹いっぱい。05/03/13 18:30:54
2chで営業するSun日本法人社員がいるスレはここですか？
0912名無しさん＠お腹いっぱい。05/03/13 19:04:09
Sun KK
【酸欠】⇒「アムロの親父」の項を見よ。
0913名無しさん＠お腹いっぱい。05/03/13 20:07:14
http://www.fetica.com/unix.swf
0914名無しさん＠お腹いっぱい。05/03/13 20:07:41
アムロの親父に失礼だ(#ﾟДﾟ)ｺﾞﾙｧ!!
最後は…だったがガンダムを送り出した偉大な人だぞ。
KKは最初から最後をむかえるまで腐りっぱなしだぞ。
0915名無しさん＠お腹いっぱい。05/03/13 20:27:49
ナイヤガラ量産の暁には！！
0916名無しさん＠お腹いっぱい。05/03/13 20:37:32
＞＞910
Pirusには期待してる。virtualizationをミドルレンジで搭載してるのはSunだけだよ。
しかもPirusの下に他社のストレージを入れ込めれば、ストレージ全体をシンプルにできる。これは凄いことだ。
0917名無しさん＠お腹いっぱい。05/03/13 21:01:13
>>907
SGIのストレージ買うよりはマシだろが
0918名無しさん＠お腹いっぱい。05/03/13 21:02:00
>>906
なんか時代錯誤なユーザがいますね(ﾌﾟｹﾞﾗ
0919名無しさん＠お腹いっぱい。05/03/13 21:16:57
Sgiのストレージ（ｗ
マジ受けた
0920名無しさん＠お腹いっぱい。05/03/13 21:18:17
>906
一緒に提供する = 相性がいい、というわけではないからね。
NTF = No Trouble Found
再現性なし、というやつだね。ご愁傷様。
でも二ヶ月は早かったね。うちがHPに頼んだときは半年かかってＮＴＦだったよ
0921名無しさん＠お腹いっぱい。05/03/13 23:44:08
いま明かされる、グーグル・データセンターの秘密
http://japan.cnet.com/news/media/story/0,2000047715,20081099,00.htm
0922名無しさん＠お腹いっぱい。05/03/14 06:42:20
>>921
googleはオンライン処理は多分検索のみなのでPC数千台を使用し
た分散システムでDBを構築できる。
通常の会社の業務処理は一般にはオンライントランザクションで
書きこみが発生するので分散できない。大規模DBサーバ１台に
まとめるしかない。
0923名無しさん＠お腹いっぱい。05/03/14 11:50:37
Oracle10gって凄いの？？
0924名無しさん＠お腹いっぱい。05/03/14 12:58:38
そこでSunの出番ですよ？
0925名無しさん＠お腹いっぱい。05/03/14 14:11:10
他社がプレゼン時の引き立て役に?
0926名無しさん＠お腹いっぱい。05/03/14 14:17:53
V40zと10gでスケールしますぅ
0927名無しさん＠お腹いっぱい。05/03/14 21:42:23
>>925
一歩間違えば詐欺だよな＜Sunのプレゼン
0928名無しさん＠お腹いっぱい。05/03/14 23:52:03
IBMの営業のほうが役者が２枚も３枚も上
0929名無しさん＠お腹いっぱい。05/03/15 01:04:55
あと下手うった案件を逃げるのもうまいよね。
だから儲かるんだよな。









残された下請けは悲惨ですが…
0930名無しさん＠お腹いっぱい。05/03/15 02:09:20
ttp://www.itmedia.co.jp/enterprise/articles/0502/24/news073.html
こういう類のネガティブキャンペーンってどう？
netappが優秀なのはともかく
>4CPU（750MHz）のモジュールで何と800万円
これってあからさまに出るの広告記事だよな
動いてるものをスケールアップできるんだから安全牌なのに
じゃあIA鯖で同数CPU積んで幾らになるか見積もり取ってみろってーの
結局落ち着いた構成ならdellの替わりにv20zで問題ないだろって
0931名無しさん＠お腹いっぱい。05/03/15 02:35:01
最近負荷がかかる時間帯にFFの調子が悪くなるようになった
原因はこれか！って、誰かが日記で書いてなかったっけ？
読んだ覚えはあるんだけど見つからない…
0932名無しさん＠お腹いっぱい。05/03/15 03:13:38
>>930
Dellでも良ければv20z選びたくないわ
0933名無しさん＠お腹いっぱい。05/03/15 03:24:33
http://66.102.7.104/search?q=cache:hRmBRmegrtsJ:live19.2ch.net/test/read.cgi/ogame/1109254232/-100+%22%2Bwww.itmedia.co.jp/enterprise/articles/0502/24/news073.html%22&hl=ja
DellよりはHPにして欲しい元Compaqのヤツ
このURLでググればいろいろ面白い記事でてくるよ（ｗ
0934名無しさん＠お腹いっぱい。05/03/15 04:31:02
てゆうか、OracleのDBをNFS経由でアクセスって、
ちょっとでも性能とか負荷耐性とかを気にする
用途だとありえない構成だよね。
誰だよこんな構成提案した奴。

SunFire 2台だったのがたった1年でIAサーバ8台に
増加しているのは、I/O性能がちゃんと出てないん
だろうな。
0935名無しさん＠お腹いっぱい。05/03/15 14:19:25
チューニングでDBのホットスポットを回避するってどうやるんだろうね>netapp
本番環境で実験させて貰えてベンダは大喜びだろうけど
0936名無しさん＠お腹いっぱい。05/03/15 14:30:54
SunってDebianの開発パートナーでもあったのか。
知らなかった。
しかもNiagaraのチームはDebian使ってるんだって？
0937名無しさん＠お腹いっぱい。05/03/16 00:41:37
特集：Solaris 10はLinux攻勢の切り札となるか――前編
http://www.itmedia.co.jp/enterprise/articles/0503/15/news050.html
0938名無しさん＠お腹いっぱい。05/03/16 01:01:50
>>937
これはとんでもない提灯記事。ZFSやlinuxとのバイナリ互換性など、まだできて
いないものをsolaris10の特長としてあげている。
こんな記事を書かせるから信用を失うのだ＞サン
0939名無しさん＠お腹いっぱい。05/03/16 01:02:56
ナイヤガラ量産の暁には！！
0940名無しさん＠お腹いっぱい。05/03/16 01:16:17
Chicago18 でも聴いてるとしよう
0941名無しさん＠お腹いっぱい。05/03/16 01:31:10
>>939
OSがLinuxになってるわけか
0942名無しさん＠お腹いっぱい。05/03/16 02:28:58
Microsoft Solarisになって第二の黄金期を・・
0943名無しさん＠お腹いっぱい。05/03/16 02:53:57
心理テストです。

3人が溺れています。あなたは一人しか助けることができません。
次のうち誰を助けますか？

1. Sun
2. Solaris
3. SPARC
0944名無しさん＠お腹いっぱい。05/03/16 02:55:59
誰も助けない
0945名無しさん＠お腹いっぱい。05/03/16 03:41:57
>>934
NetAppの場合Localディスクアクセスに匹敵するのを知らんのか。
今時DASやFC-SANにこだわる香具師は負け組。
0946名無しさん＠お腹いっぱい。05/03/16 06:02:54
EMCもそうだよ。
もちろん速度だけ見れば割高だけど、速度だけじゃあねえ。

ファイルシステムは、I/O高不可の場合、
ディスクアクセスが最大のボトルネックなので、
ギガイーサをトランクすれば、遠隔ファイルシステムであることの損失は極めてわずか。
一方優れたファイルサーバのサービスの優秀さと言ったら…
0947名無しさん＠お腹いっぱい。05/03/16 07:17:02
>>945
この場合、NAS へのアクセスはせいぜい Gigabit Ether でしょ？
とするとトランクしてたとしてもバンド幅は120MB/s×N。
SCSIバス1本にも劣る性能しか実測では出ないんじゃない？
それにNetAppがいくら優秀でも、NFSクライアント側にそれについて
いくだけの性能がでなきゃ意味がない。この場合、N対1で使うわけ
じゃないんだから。
もっともDellだと、どちらにせよすぐにI/Oバスネックになりそうな
気がするが。
0948名無しさん＠お腹いっぱい。05/03/16 07:44:51
新スレ用意しておきました。

http://pc5.2ch.net/test/read.cgi/unix/1110926614/

0949名無しさん＠お腹いっぱい。05/03/16 09:24:46
高負荷の DBの場合、I/O性能を高めるために、Direct I/O を
用いて直接DMAを行ない、CPU能力を消費しないようにするのが
当たり前。DASやFC-SANでDirect I/Oを使えば、実際、その
通りになる。
しかし、NFSのようにネットワーク系のデバイスドライバを
経由する場合、データ書き込みはともかく読み込みでは、
どうしてもCPUによるメモリコピーを行なわざるを得ない。
その分、I/O能力はどうしても落ちる。
>>945あたりは、そういうギリギリのレベルのチューニングの
ことを理解してないんじゃないかな。
0950名無しさん＠お腹いっぱい。05/03/16 09:41:04
>>947
だからRACと相性がいいんじゃないの？
Dell複数台にNetAppでRACを構築していたぞ、このまえのOWで。
0951名無しさん＠お腹いっぱい。05/03/16 09:44:39
>>949

from 最強ハイエンドストレージ列伝

信じる信じないは別として、、、

Oracle 10gでは、ネットワーク・ファイル・システム（NFS）もファイル・システム内の
Direct I/Oをサポートするようになりました。「Oracle 10gでは、パッチを適用しなくても、
データベース内で直接Direct I/Oがサポートされます。」とCoekaert氏は述べています。
「これでパフォーマンスが大幅に向上します。特に、NFSではすべてが高速になります。
これは、NFSでRACを実行する場合に非常に効果的です。」Coekaerts氏によると、
シングル・ノードでは、OSのファイル・システム・キャッシュにデータをキャッシュする
必要がなく、Oracleのキャッシュ・アルゴリズムを使用できるため、Direct I/Oの有益性が
さらに高まります。

参照 http://www.oracle.co.jp/technologies/linux/special/top4.html
0952名無しさん＠お腹いっぱい。05/03/16 10:20:10
>>951
LinuxのNFSは、書きこみについては、zero copy が
できるようになったけど、読み込みについては、必ず
1回コピーが生じるよ。
ネットワークから読み込んだパケットにはヘッダが
Ethernetヘッダ、IPヘッダ、UDP/TCP ヘッダ、それに
SunRPC のヘッダと多段についていて、これらをはぎと
らないとNFS経由でOracleに渡すことはできない。
ここでどうしても1回コピーが生じることになる。
(書き込み時は DMA descriptor でメモリをかき集める
ことができるので問題ない)

だから、その記事は、書き込みの zero copy のことを
言ってるだけだよ。
読み込みで限界性能を得ようと思うと、メモリコピーが
避けられないから、NASでは、DASやFC-SANにかなわない
はず。
0953名無しさん＠お腹いっぱい。05/03/16 10:49:23
> LinuxのNFSは、書きこみについては、zero copy が
> できるようになったけど、読み込みについては、必ず
> 1回コピーが生じるよ。

おっとっと、実はここ誤解していた。すまん。
Linux の NFS で zero copy ができるようになったのは、
NFS サーバー機能に関してだけみたいだな。
NFS サーバーが、ネットワークに書き込むとき (すなわち
NFS クライアントが、NFS read オペレーションを発行した
場合) に zero copy になっただけか。
(ネットワークからの読み込みで zero copy ができないの
は上に書いた通り)

今回の場合、NFS のサーバの役割をするのは NetApp で
あって Dell は NFS クライアントに過ぎないので、結局
読み書きともに必ず 1回以上はメモリコピーをしている
ことになるんだろう。これでは DAS や FC-SAN にはかなわんよ。
0954名無しさん＠お腹いっぱい。05/03/16 11:00:53
> Linux の NFS で zero copy ができるようになったのは、
> NFS サーバー機能に関してだけみたいだな。

さらに訂正。Linux 2.5.70 の時点で、NFS クライアント
側についても zero copy が入ったようだ。(ただし、もちろん
送信処理のみ)
結局、953 は不要で、952 そのままで正しかったようだ。
0955名無しさん＠お腹いっぱい。05/03/16 11:11:41
あと、>>951の記事は、zero copy のことを言ってるんじゃ
なくて、O_DIRECT で page cache をバイパスする話をして
るのかもしれんな。Oracle がキャッシュしているデータを
さらに page cache に持つのは無駄だからな。
その場合、write だけじゃなくて read の性能にも関係する
が、どちらにせよ >>952 の理由から、DASやFC-SANにかなう
まい。
0956名無しさん＠お腹いっぱい。05/03/16 11:45:15
限界性能を気にするシステムってどれほどあるのかな？
むしろ、バックアップや増設を考えると、NASでRACを
構築するほうがメリットがでかいと思うのだが。。

EMCで構築を考えていたが、NetAppも検討してみるか。。
0957名無しさん＠お腹いっぱい。05/03/16 11:46:10
>>943
とりあえず Sunに止めを刺す
0958名無しさん＠お腹いっぱい。05/03/16 11:56:01
DASやFC-SANなら、高負荷時にもI/O要求や応答が失われる
心配はないけど、NASだと負荷がかかると(NAS側は大丈夫
でも)NFSクライアント側がパケットを落す危険があるから、
性能だけじゃなくて、高負荷時の安定性にも難があるんじゃ
ない？
それにDBの場合、SANでもバックアップや増設の手間は
たいして変わらん気がするが。
0959名無しさん＠お腹いっぱい。05/03/16 15:45:10
>>943
SPARC
0960名無しさん＠お腹いっぱい。05/03/16 15:45:17
スレ住民の仕事内容が垣間見える流れでした
0961名無しさん＠お腹いっぱい。05/03/16 15:46:19
>>943
見てみぬ降りをして、Javaと駆け落ちします。
0962名無しさん＠お腹いっぱい。05/03/16 16:31:52
NetAppの工作員が紛れこんでるような希ガス
0963名無しさん＠お腹いっぱい。05/03/16 19:05:06
http://blogs.sun.com/roller/page/jonathan
http://blogs.sun.com/roller/page/ako/
http://blogs.sun.com/roller/page/chats/
http://blogs.sun.com/roller/page/akihito

毎日更新して欲しい、内容は評価する。
0964名無しさん＠お腹いっぱい。05/03/16 19:16:40
>>963
ブログでまで、SunグリッドとIBMグリッドの比較やってる
さすが社長さん、必死だな
0965名無しさん＠お腹いっぱい。05/03/16 19:52:26
このスレがDat堕ちする可能性なのど考えてもみなかったよ。
0966名無しさん＠お腹いっぱい。05/03/16 20:48:41
Sun Grid
一瞬、オオと思うが、よく考えてみると数百ドルで数GHzのPCが手に入る今
そんなややこしい事するかね。
数GHz以上のパワーが欲しけりゃBeowulfする方がイイ。

OpenSource Solaris
コミュニティのない今、オプソしても何のメリットもない。
CobaltやSuSE(x86 Linux)を受け入れられなかったツケが今きてる。

Honeycomb
ストレージ2大勢力の切り崩しは無理。
CPUもおぼつかないのにいらん事に金使うな。
0967名無しさん＠お腹いっぱい。05/03/16 21:27:51
Beowulfのような特定組織内のクラスタを安全にInternet全体に
広げたものがGridの筈だが?
0968名無しさん＠お腹いっぱい。05/03/16 22:05:35
従量制のグリッドコンピューティングサービスに対してと意味で受け取ってクレ。
0969名無しさん＠お腹いっぱい。05/03/16 22:28:15
Sun、Javaのライセンス条件を緩和へ
http://www.itmedia.co.jp/enterprise/articles/0503/16/news026.html
0970名無しさん＠お腹いっぱい。05/03/17 00:19:33
>>952
クロック1GHz程度のsparcならメモリコピー性能は1Gbyte/s程度はでる。
なのに、100Mbyte/sのTCPの転送をすると1GHzのCPUを使い切ってしまうのは
何故か？よく考えてみよう。メモリコピーはボトルネックではない。TCP/IP
のプロトコル処理そのものがボトルネック。
うそだとおもうのなら、TCPの転送をしながらlockstat -kIW -D 20で
カーネルのプロファイリングを調べてみるのがよい。
0971名無しさん＠お腹いっぱい。05/03/17 00:20:55
最近はNICで処理してますけどね─
0972名無しさん＠お腹いっぱい。05/03/17 00:53:06
結局NASだと、TCPとかそういう余分なものを経由するので
イクナイと。で、あの構成提案したのはダレ？ Dell？
0973名無しさん＠お腹いっぱい。05/03/17 01:09:20
Linuxを例にしてNFS時のcopyを議論していたけど、
SANでもLinuxで動かすのかい?
0974名無しさん＠お腹いっぱい。05/03/17 09:55:17
アプリケーションからIP層をスルーしてethernetのようなデータリンク層で
直接やりとりするようになると早くなるの？ど素人な質問ですみません。
0975名無しさん＠お腹いっぱい。05/03/17 10:10:36
Direct Access Storage (IDEとかSCSIとか)もFibreChannelも、
カーネルから見るとEthernetじゃなくて、ブロックデバイスに
見えるの。だから、そもそもネットワーク処理のためのオーバー
ヘッドは全然かからないし、プロトコルヘッダの処理も要らな
いから、メモリの中身を直接ディスクとの間でDMAできるの。

Ethernetのようなネットワークデバイスの場合、ヘッダをつけ
足したり、取り除いたり、解釈したり、チェックサムを計算し
たりなどなど、やることがずっと多い。

まあ最近はTCPぐらいなら、ハードウェアがやってくれる場合も
多いけど(TCP Segment Offloading)、NFSを使おうと思うと、
SunRPCとかNFSとか、さらに上位層のヘッダがあるので、結局
効率ではDASやFCにかなわない。
0976名無しさん＠お腹いっぱい。05/03/17 10:27:14
ネットワーク経由ストレージ接続したところで、
本当に性能が気になるならばそれ専用セグメント作りたくなるのが
世の常人の常と思うので・・・

結局、設備投資的にはFCカード増設するのと何ら変わらなくなるんでわ？

※なんちゃって環境だったら変わるだろうけれども
0977名無しさん＠お腹いっぱい。05/03/17 10:43:05
最近のCPUで、TCP overhead を気にする必要があるのか？
昔のSunマシンならともかく。。。
そんなのサーバがしょぼいっていっているようなもんじゃないのか？
おまけにNASで専用セグメントつくっても、圧倒的に
SANよりやすいじゃねーか！
FC SWなんて高すぎ。おまけにSANでヘテロな環境構築できねーよ。
現実的に。一社でチンいつするならべつだが。
ヘテロなSANでまともにサポートできるとこあんのか？
レス数が950を超えています。1000を超えると書き込みができなくなります。