Sun Microsystems IPF採用撤回は大失策

**名無しさん＠お腹いっぱい。** · 2006/02/25(土) 19:39:56

かつてSunもIPFの採用を表明していたが、後になって撤回。

もしIPF版のSolarisを出していれば、
日本メーカーのIPFマシンがHP-UXやLinuxではなく、
hpのOEMマシン以外はSolaris一色になっていただろうに。

【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/

**名無しさん＠お腹いっぱい。** · 2007/05/12(土) 19:16:48

吠えるもなにもItaniumサーバがうけもつマーケットと
Sunのサーバがうけもつマーケットが全然違うんだから、
比較する意味がないじゃん。

**名無しさん＠お腹いっぱい。** · 2007/05/12(土) 21:09:59

BuggyでRockでPunkでPinkなSun営業乙ｗ

**名無しさん＠お腹いっぱい。** · 2007/05/12(土) 23:39:54

>>786 SPARC64VIが出たのでミッドレンジから上にも再進出
かつてのSunはミッションクリティカル用途ではメタメタだったからねー。

**名無しさん＠お腹いっぱい。** · 2007/05/13(日) 00:53:23

>新しい CPU でもそれほど手間はないはず。
>ないはず。
>はず。
>はず。
>はず。

**名無しさん＠お腹いっぱい。** · 2007/05/13(日) 06:41:16

富士通製CPUになって、性能も信頼性も死角無くなったな。
唯一の不安点がHAクラスタソフトだが、Oracle RACにすれば関係ないか。。。

**名無しさん＠お腹いっぱい。** · 2007/05/14(月) 03:06:21

>>786
はぁぁぁぁ?? x86 の代用になるつもりが「サーバならなんとか...」って言い訳してた
くせに、もっとさらにニッチへ逃げ込もうってか?
ま、勝手にしてくれwwwwww
>>785
図星ってことらしいぎゃはは

**名無しさん＠お腹いっぱい。** · 2007/05/14(月) 03:26:03

>>789
やっぱ、C にならないアセンブラの部分で何やってるのか知らないのかww

**名無しさん＠お腹いっぱい。** · 2007/05/14(月) 03:47:53

>>790
RAC 本当に使ったことがある？
キャッシュフュージョンのせいですげー遅くなるんだけど

**名無しさん＠お腹いっぱい。** · 2007/05/14(月) 04:56:18

そもそもRACはHAクラスタではない。

**名無しさん＠お腹いっぱい。** · 2007/05/15(火) 00:59:29

>>793
へたくそ

**名無しさん＠お腹いっぱい。** · 2007/05/15(火) 23:11:35

>>793 使い方(アプリ)によるよ。DBの設計にも大いに依存する。単純だが、
パーティションが有効なケースもある。
念のため聞くけど、ハートビートGigaだよね？

**名無しさん＠お腹いっぱい。** · 2007/05/15(火) 23:25:13

Niagara2とVictoria Falls
http://jp.sun.com/newsletters/innercircle/0705/feature1.html

**名無しさん＠お腹いっぱい。** · 2007/05/19(土) 01:30:25

Sunの好調がいよいよ確実になってきて、なおかつ、Itaniumの未来が
不透明になってきたせいなのか。Itanium厨のSun中傷書き込みが
明らかに少なくなってきたね。

**名無しさん＠お腹いっぱい。** · 2007/05/19(土) 01:35:43

ま、ちょーしこいて Ita 機買ったやつとかバカよなww

**名無しさん＠お腹いっぱい。** · 2007/05/19(土) 01:37:53

あ、まだわかんないよな、台湾のガレージメーカーとか Ita 機出すかも知れんぞ。
なんせ、すごくオープンなアーキテクチャだからなwwww
OS の選択肢も広いしーwww

**名無しさん＠お腹いっぱい。** · 2007/05/20(日) 10:21:11

>>800 そうそう。Windows 64bitもLinuxも、そして何よりもHP-UXが動く。
うらやましいよな。x86/X64と互換性無いし、PA-RISCの置き換え用途でしか
売れていないけど(しかも日本限定)

**名無しさん＠お腹いっぱい。** · 2007/05/20(日) 11:15:06

>>795
DBは未だにSMPでのスケールアップ頼りでクラスタリングはノウハウが行き渡っていないよね。
これはどのOSでも同じ。
すでにうまく使ってるところはあるんだけどね。
ま、SMPマシン売ってる所はもちろん利幅の大きいSMP薦めるし。

**名無しさん＠お腹いっぱい。** · 2007/05/21(月) 01:32:18

「神官」にしかチューニングできないんなら永遠に行き渡らない気がする。

**名無しさん＠お腹いっぱい。** · 2007/05/21(月) 22:39:01

銀行で10g RAC使い始めるところがあるな。
サーバベンダは渋々つきあい始めている。
自己責任でどうぞと言えない相手なんで。
そういうところから広まっていくんだろうね。
ま、それでも当面はＳＭＰ主流だろうけど。

**名無しさん＠お腹いっぱい。** · 2007/05/22(火) 00:06:28

パーティションでキャッシュフュージョン回避といっても限界あるしなあ
shared everything クラスタは難しいよなあ

**名無しさん＠お腹いっぱい。** · 2007/05/22(火) 01:15:25

更新競合が起きれば並行性が下がるから、SMPマシンでもスケールしないし。
RACでスケーラビリティを確保するのもSMPマシンもチューニングのポイントは同じだってば。
SMPマシンをCPUコア数分きっちりスケールさせられるやつがどれほどいるのだ？
そもそもCPU数を変化させて計ったことある経験持ってる人自体少ないんじゃない？

**名無しさん＠お腹いっぱい。** · 2007/05/22(火) 18:11:59

>>806
それは違う
RAC ではキャッシュの競合のオーバヘッドが発生するけど、
HAクラスタでは全く発生しない

そもそも更新競合が起きるのはどっちも同じ
起きたときのペナルティーは他サーバ間なので RAC の方が高い

同じCPUライセンス数でどっちの方が性能が出るかが問題
例えば 4CPU 2台の RAC 構成と、8CPU 2台の HA クラスタ
Oracle のライセンスのコストが占める比重が高いので、そういう比較をせざるえない

キャッシュフュージョンはパーティションである程度避けれるときもあるけど避けれないときもある
単一で絞りたいキーが一つのテーブルに2つあるときとか
例えば注文履歴の注文者IDと商品ID
ユーザの履歴画面は注文者ID、事業者側のある商品に対する購入者一覧は商品ID
どっちかは確定でオールパーティションアクセスのどつぼにはまる
マテビューとかでリアルタイム性を落として回避とかは、そもそも RAC を使わなければ良いと思えば異常な選択肢

そもそも RAC に合わせたチューニングの SE 費用でもっと高いサーバ買えるよ(w

**名無しさん＠お腹いっぱい。** · 2007/05/22(火) 23:43:32

>>806
>そもそもCPU数を変化させて計ったことある経験持ってる人自体少ない
そんなわけない。SMP構成でもRAC構成でも、ベンチマークくらいやるよ。
アプリ開発だって、最終的には実機で性能試験をするだろ。

>>807
>4CPU 2台の RAC 構成と、8CPU 2台の HA クラスタ
8CPUだとX64 Linuxではイマイチなんで、UNIXサーバになると思う。
そうなると、X64系のCPUが速いんで、4CPU 2台 RAC＝8CPU HAとはならない。
UNIXサーバだともっとCPU積まないとならない。
また、Coreに対する係数も、0.5と0.75だから。Oracleのライセンス費用で
差がついて、結果としてRACに流れるケースが多いよね。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 00:01:59

しかし、その辺のカネ勘定は Oracle がペコっとライセンス体系変えると総崩れだよな。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 00:17:41

同じ8CPUとして、RAC構成にしたときに、
4CPU×2と2CPU×4ではどっちがパフォーマンスが良くなるんだ？

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 00:43:14

>>808
客層が違うのかね
Web/AP 層は IA32 Linux になったけど、DB サーバで IA32 Linux の案件は来たことが無い
まだ、客から UNIX を指名されてる
ので、4CPU x2 RAC と 8CPU HA は概ね同じコストだったり（＾＾；

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 00:58:18

同じか？
8CPUのマシンは高いだろ。
筺体にもよるけど、86系でも500万～はするだろ。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 01:18:29

>>807
>単一で絞りたいキーが一つのテーブルに2つあるときとか
>例えば注文履歴の注文者IDと商品ID
>ユーザの履歴画面は注文者ID、事業者側のある商品に対する購入者一覧は商品ID
>どっちかは確定でオールパーティションアクセスのどつぼにはまる

そういうときにはグローバルインデックスですよ

**名無しさんお腹いっぱい** · 2007/05/23(水) 01:25:46

>>811
Linuxはファイルシステムに負荷かけるとトラブルだよ。それも時々
ハングとか一時的にスローダウンだから、解決できずに質が悪い。
ユーザはそうゆうことをしっているから、アプリサーバにはLinuxを
つかうけどDBサーバには使わないんだよ。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 01:38:51

>>810 4CPU×2。UNIXの場合な。Linuxだと微妙なライン。8CPUだと、もう無謀
>>814 もしかするとASM使えばOK？もしくはVxFSかぶせればOK？
もしくはローカルファイルシステムじゃなくてNetApp使えばOK？

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 01:44:59

>>812
つ RACライセンス

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 02:45:54

>>814
未だにext3はbug bugしてるしな。
VMの方は、一時期よりはマシになってきたけど。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 02:56:09

>>812
Oracle ライセンスの高さから言えばハード代金の占める割合なんて(ry

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 03:47:10

>>815
DB のストレージに NetApp はありえんだろ(w

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 09:26:03

>>812
Oracle ライセンスの高さから言えばOS代金の占める割合なんて(ry

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 10:31:07

Linuxといいつつその実RHELだからね。
古いのを使いつづけなきゃいかないのはつらいね。
ノウハウはメーカに個別に貯って、RHにはいかないから
あちこちで同じことの繰り返し。ご苦労様。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 11:19:30

>>819
お前は何を言っているんだ

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 20:59:38

ＬｉｎｕｘでＤＢやるならＭｉｒａｃｌｅが定番だったが大手はRHしか扱ってないので
RH+Oracleというのも近頃は見かける。Itaniumで馬鹿でかいの頼むってのも。
苦労するだろうね。
Miracleなみのノウハウが入るのは何年後になることやら。

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 22:45:54

>>819 それは「ジョーク」ですよね？ Oracle社のストレージは何を使っていると思われますかｗ

**名無しさん＠お腹いっぱい。** · 2007/05/23(水) 22:47:25

>>823 MIRACLEよりRedHatの方が多いに決まっているじゃん？？？

**名無しさんお腹いっぱい** · 2007/05/24(木) 00:30:45

oracleはPCクラスタでraqを売りたいから、共有ディスクのソリューション
としてNFS（netap)を進めている訳で、客の立場で性能を考えているわけで
はない。ディスク性能が悪ければ、さらにoracleサーバが立つしな。うは
うはだよ、オラクルは。

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 00:40:36

>>822 >>824
普通 NetApp とだけ言ったら NAS をさすもんだと思ったけど、
こういう反応をする人がいるってことは違うのかね
FC-SAN 製品を使うって話だったら NetApp と決め打ちをする必要性は0だと思うんだが

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 00:41:18

SANやiSCSIじゃなくてNFSか。
んでも、NFSだとASMと矛盾しないか？

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 00:53:50

日本の技術屋は真面目すぎて商売が下手だってことか。

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 07:59:04

>>826 I/O性能、特にランダムread/writeは悪くないよ。
シーケンシャルread/writeはネットワーク構成やチューニングによりSANと
ほぼ同等になる。性能より何より管理性が著しく向上する。バックアップ含め。
>>827 FC-SANを使うのでは意味が無い。NFSサーバを共有Diskにするから
管理性が向上する。
>>828 ASMは使わない。意味無いよね。
>>829 おれもストレージに近い所で仕事しているが、SANって面倒だろ。
全てのデータがファイルサーバ(NAS)に格納出来れば楽だなと思わない？
I/Oだけのベンチを取ってみるとNASはSANに劣るけど、アプリ(Oracle含め)
レベルのベンチではほとんど変わらなかったりする。
以前は、OracleのデータをRAWで扱うのが主流だったよね。でも、ファイル
システムを使う方が楽なので、性能差・機能差・安定性に大きな差が無く
なっていると分かってからは、みんなそちらに流れた。SANとNASも同じ
状況になるのではないかと。ノード追加やバックアップ、リカバリがすごく
楽になるから。
問題は、NASがまだ高い事だなぁ。

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 13:59:54

>>830
営業乙。

DB＋NASなんてありえない。

NetAppは使えるって宣伝しているけど性能全然でていない。
ある客が騙されてシステム組んだけど性能問題になってNetAppに
逃げられた後に泣きついてきた。結局NASは別の用途に回してスト
レージはFCになったけどな。

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 17:32:23

>>831
大変ですね＾＾

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 21:57:23

>>831 たった一例で全てを語れると考えているとは驚き。
おれは逆の事例を知っているよ。FAS800シリーズからStorEdgeに変えたら
I/Oがボトルネックになったって話。世代が異なるストレージ同士だった
ので信じられなかったけどな。

RACと同じでさぁ。Oracle on NASはノウハウが必要な構成だからね。
ストレージ設計もそうだが、Oracle側のチューニングも必要。
ノウハウ以前に、FAS270使っていたり、300GB 10000rpmのディスク7本位で
RAID組んでいたりしたら笑うしかないけど。性能出るわけが無い。
イニシャルコストで言えば、NASは割高。貧乏なユーザには向きません。
StorEdge3510FCや6140 1台分程度の予算しかないなら、NASは考えない方が無難。

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:08:46

DB+NASが信じられない人って。今でもいるんだねー。
ちょっと前は珍しい構成だったが、もう誰も驚かなくなったよ。
DB+iSCSIの方が珍しくないかい？ MS-SQLやMS-Exchangeのデータ領域をCIFSの
先に置くわけにいかないんで、Win2003では普通かも分からんが。
ところで話は変わるが、MS-SQL＋CIFSが使えない理由は、キャッシュ機能を
OFFに出来ないからだと理解している。
とすればSFUでNFS使ったらどうだろう？ NFSの先にSQLのデータを置くわけよ。
SFU NFSクライアントでは性能出ないか？？

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:12:05

http://jp.sun.com/back/2007/0523/feature/
リモートリプリケーションのソフトもオープンソースになるんだな。
プアマンズSRDF or TrueCopyってか？

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:21:49

ZFSでデータのコピーを複数持てる。これ、面白い。
http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:22:33

こんな風に動くみたい。

# zfs create -o copies=1 zwimming/single
# zfs create -o copies=2 zwimming/dual
# zfs create -o copies=3 zwimming/triple
# cp -rp /usr/share/man1 /zwimming/single
# cp -rp /usr/share/man1 /zwimming/dual
# cp -rp /usr/share/man1 /zwimming/triple
# zfs list -r zwimming
NAME USED AVAIL REFER MOUNTPOINT
zwimming 48.2M 310M 33.5K /zwimming
zwimming/dual 16.0M 310M 16.0M /zwimming/dual
zwimming/single 8.09M 310M 8.09M /zwimming/single
zwimming/triple 23.8M 310M 23.8M /zwimming/triple

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:33:22

痛nium

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 22:35:49

>>837
ここへ書いて、さらに解説してくれるとうれしいかも。
[次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ]
ttp://pc11.2ch.net/test/read.cgi/unix/1146631270/

**名無しさん＠お腹いっぱい。** · 2007/05/24(木) 23:05:50

いわゆるRAIDセット(RAID5、RAID6)はzpoolコマンドで作成されるわけだが、
上記のデータコピーはzfsコマンドで作成されるファイルシステム単位で
設定できるのが便利。

diskが12本あるとして、大きな器をzpoolコマンドで作成
# zpool create mypool raidz2 c1t0d0 c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0

重要なデータは、以下で設定した置き場所。/mypool/mirrofsにファイルを
置くと、データが二重に保持されます。
# zfs create -o copies=2 mypool/mirrorfs
例えは良くないですが、冗長度的には、RAID1+6の様な感じになります。

RAID6で十分だと思うファイルの置き場所は、
# zfs create -o copies=1 mypool/singlefs
に書けば良いのです。

**名無しさん＠お腹いっぱい。** · 2007/05/25(金) 05:07:39

要は SAN がまともに組め無い低脳だから、
コストパフォーマンスの悪い NAS を使ってますと
了解

RAC にしても RAC on NAS にしてもチューニングすればと言う人が
現れたけど、SE工数かけてチューニングしても性能を出すって
技術フェチが満足を得るだけでコストパフォーマンスがないじゃん。
客にとっては最悪だな。コスト意識持てよ。

**名無しさん＠お腹いっぱい。** · 2007/05/25(金) 05:12:28

あと、多目的ストレージなら SAN は管理性が悪いは同意だけど
DB のストレージという単目的なのに管理性で問題が出るのは理解に苦しむ。
NAS に逃げる前に何か考えるべきことがあるんじゃないの?
技術蓄積せずに adhoc 対応しているからそんなことになるんだと思うよ。

別に NetApp を使ったことが無いわけではないからね。
むしろ、SAN/NAS 共存の方が多い。
念の為。

**名無しさん＠お腹いっぱい。** · 2007/05/25(金) 07:45:24

>>841-842 えーと。何か良く分かっていないみたいね。

**名無しさん＠お腹いっぱい。** · 2007/05/25(金) 09:12:52

>>843
具体的な指摘無しに dis るのは負けを認めているようなもんだぞ(w

**名無しさん＠お腹いっぱい。** · 2007/05/25(金) 09:23:55

勝ち負けの問題だったのか？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 00:06:55

10GEther接続のNAS(あるのか？)でも4G FCにかなわないと思うがどうか？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 00:07:46

知識、経験の問題でしょう。自社でベンチ取った事もないで使えないと
ほざくとはね。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 01:17:26

価格以外は良く設計されたSANに遠く及ばない。

**名無しさんお腹いっぱい** · 2007/05/26(土) 03:27:33

NetAppの性能は良くても、クライアント側のシステム
負荷が高くて、すぐにサチっちゃうよ。400Mbyte/sも
だしたら1core分ぐらいをOSが使っちゃうぜ。FCは全く
OSのオーバーヘッドないのにさあ。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 09:56:54

いやいや、低負荷で高速にNASを使うすごいテクニックがあるのかも知れない。
将来的には。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 12:52:49

400MByte/secってバッチ処理？ OLTPでそんなに帯域使うの？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:10:26

最近のクライアントは400MByte/sec出るんですね。
どう言うネットワーク構成？
やっぱり10G積んでんの？ Gigabit 4本位でチャネルですか？

ストレージも400MB/sec出せるものはなかなか無いと思うのですが、どこの
製品ですか？
3510FCにOSのddコマンドで負荷をかけた時は150MB/sec未満。SANRISEも
9500のレンジではそんなもんでした。2コントローラActive-Active構成が
取れる3510の方が性能面では勝っていたケースも多かったです。
4G FCモデルはまだ試していませんが。

シェルフ1本のRAID5構成でしか試験していないからなぁ。シェルフ3本位
使えば性能リニアに上がるのかな。
でかい構成はSymmetrixしか触ったこと無いのですが、こちらはシーケン
シャル性能は意外と低くて200MB/sec位でしたね。PowerPathでFC 1本
落とすと半分の性能に。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:12:56

Sunが開発した新しい10G NICを使うと、ホストに負荷をかけずにワイヤスピード
出ると言う話ですが。本当なんだろうか。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:18:01

どんなに小さく遅いストレージでもNASじゃいずれ困りますよって営業にいってもらうとそりゃそうだってことになるな。
客のおれが言うんだからNASでDB組めというITの人はいないのか？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:31:11

>>853
10GEtherはInfiniBandのようなオフロードをする。
TCPのチェックサムをハード補助するような気休めオフローディングではなく、
リモートDMAによってカーネル空間を経由しないで相互のユーザ空間で転送を
行うのでやたら早い。

SDP（Socket Direct Protocol; SocketライブラリコールをRDMAに変換する）上で
ISCSIをやるIserというのがずいぶんと前から提唱されてるけど現物は見たこと無い。
まだしばらくはFCだろうね。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:33:32

>>854 気になるんならGoogleでOracle on NASやっている会社を検索して
ベンチマーク結果でも見せてもらうんだね。大抵のSIerはNASやってりゃ
SANもやっている。NetAppに聞いたら信用ならんけどw 日立、EMC、
NetAppやっている、DBに強いSIerに聞くんなら信用できるでしょ。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 13:35:32

>>855 PCサーバのNICですか？シーケンシャルで何Mbit/sec出ました？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 14:40:59

>>854
CTCでもNTTDでもOracle on Netappは普通にやってるよ。
むしろ推奨のはず。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 15:48:13

DBグリッド、DB仮想化の観点でシステムを組むと、SANよりもNASが適当
だと言う事は周知だと思うんだけど。とは言え、Oracle社が提唱・実践
してから市場に広まるまでが長かったみたいだ。Oracle on NASに関して
知識・経験が無い人が、昔のイメージで語ってしまうのは無理の無い話
かもしれない。

Linuxを用いたNAS&DB管理ソフト利用システムの提供で提携(NTTDATA 2003/5)
http://www.intellilink.co.jp/topics/03-05-20.html
http://www.nttdata.co.jp/release/2003/052001.html

C-ONEソリューション(CTC 2005/2)
http://www.ctc-g.co.jp/new_htm/out_n2005_02/20050207_oy4.html

DB Pool(CTC 2005/10)
http://www.ctc-g.co.jp/new_htm/out_n2005_10/20051013_kt1.html
http://www.oracle.co.jp/news_owa/NEWS/news.news_detail?p_news_code=1472

NSGRANDIR(NS-Sol 2007/3)
http://www.ns-sol.co.jp/release/2007/pre_070319a.html
http://www.nssol-together.com/solution/sol68/sol_nsgrandir.html

DODAI-L(アシスト 2007/5)
http://www.ashisuto.co.jp/corporate/info/news/1183838_1217.html
http://www.ashisuto.co.jp/solution/dodai/stack/dodai_l/

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 16:22:43

NTT DATAやCTCはトラブル起きたら供給元に責任なすりつけて
逃げ出すのが得意だからね。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 16:30:50

なにを言っているのやら。Bugや製造不良は供給元(メーカ)しか直せないじゃん。
ここで話題になっていたOracle、NetAppに関しては特に。
そうすっとHiRDBとSANRISEですかね。Symfoware＋ETERNUSも魅力かも。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 16:33:31

Symfoware + ETERNUS... あんなもん二度と使わん。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 16:40:03

OracleはLinuxと組み合わせる良いRAIDがないからNASを選ぶ。
CTC、NTTDはSAN組ませたらメーカに負けるからNASを選ぶ。
信頼性ではUNIX+SANに劣るシステムと理解して安価で導入し
たいなら悪い選択肢ではない。

それだけの話。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:05:21

>OracleはLinuxと組み合わせる良いRAIDがないからNASを選ぶ
論理破綻していますよ？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:09:37

SAN用FC-RAIDってことで。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:26:53

>>863 ここまで来ると、あー言えば上祐って感じですね

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:37:04

それはむしろNAS営業側だろう。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:37:18

>>863=865? CTC/NTT-Dの方は事実は知らんが論理的には間違っていないが、Oracleの方はそもそもストレージ作っていない。良いRAID(SAN)がないから
NASを選ぶって、論理的におかしくない？
結局の所、SANかNASかと言う議論は、システムの要件による。
固定的なシステム構成ならばSANの方が安いし高性能。DB統合や仮想化、
バックアップ、DRを考えるとNASの方が運用楽だったり、トータルコストが
低かったりする。
また、性能面でも、OLTP的な使い方であればNASが問題なるケースは少ないよ。
このスレでだれかが、400Mbyte/sで1core死ぬよみたいな発言もあったけど
8Kbyte位の小さなデータをランダムにやり取りしている中では数十Mbyte/sが
せいぜいだと思う。どんな環境で使われているんでしょうか。聞いてみたいです。DWH？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:44:22

ここから始まったんだな。
で、DB＋NASは普通にあるし。性能に関してもDBの使い方とシステムの
組み方次第。ここまでは問題無いよね？

831 ：名無しさん＠お腹いっぱい。：2007/05/24(木) 13:59:54
>>830
営業乙。

DB＋NASなんてありえない。

NetAppは使えるって宣伝しているけど性能全然でていない。
ある客が騙されてシステム組んだけど性能問題になってNetAppに
逃げられた後に泣きついてきた。結局NASは別の用途に回してスト
レージはFCになったけどな

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:44:33

>>868
Linux用のSAN関連製品が他のプラットフォームと比較して劣っているから
SANを選択しにくいという事実がある。

> DB統合や仮想化、バックアップ、DRを考えるとNASの方が運用楽だったり
いや、それはどうかと・・・。設計が楽なの認めるけど。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:47:55

これも変だな。余程大規模環境ならば、ともかく。SANまともに組めないから
NAS使うと言う人はいないと思う。

841 ：名無しさん＠お腹いっぱい。：2007/05/25(金) 05:07:39
要は SAN がまともに組め無い低脳だから、
コストパフォーマンスの悪い NAS を使ってますと
了解

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:50:32

＞で、DB＋NASは普通にあるし。性能に関してもDBの使い方とシステムの
＞組み方次第。ここまでは問題無いよね？

「組み方次第」の後が問題なのがわからんのか？
組み方次第で何とかなるって言うなら嘘。
組み方次第で何とかなる場合もあるっていうなら問題なし。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:50:47

>>870 NetAppを想定して言っているのだが、運用は楽じゃないだろうか。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:55:38

>>872 DBの使い方→DBの使われ方と修正させてください。
性能面で、どんな環境でも使えるとの意味で書いたのではないです。
使用するアプリケーションによっては、十分、NASで行けるよね？の意味です。
だから、DB＋NASがあり得ないと言うのは。。。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:57:22

>>871
SANは難しいって思っている連中がNASを押す場合は実際にあるよ。
そういう場合はNASでもトラブル発生したりするけどな。

>>873
いや、SANの運用が苦になるとは限らんという事だが、そういう発想し
か出来んという事は、お前さんが良く出来たSANに触れた事がないだ
けなんじゃないのか？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 17:58:15

えっと、Sun がイタプロセッサーファミリーなどという恥ずかしい名前のアーキテクチャを
採用しなかったこと、Sun の未来、Itaププの末期にいずれも関係なさそうなので
適宜趣旨にあった場所へ移動してくれないかこのどうでもいい SAN/NAS 論争。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:00:34

EMC CLARiXとかSymmetrixとか使っていて思うんだけど。
ストレージのレプリケーション機能を安価にIPベースで出来るように実装して
欲しい。FC to IPのゲートウェイにかかる費用がバカになんないんだよな。
普通にRAIDコントローラにネットワークポートと機能をつけてくれないかな。
ローエンドのFCスイッチにつけてくれるとか。
同じフロアならいいんだけど、遠隔だとねぇ。かと言ってVVRみたいな、ソフト
ベースのものはあんまし使いたくない(偏見)

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:03:05

Itaniumの未来が急速にやばくなってきて、Ita厨が書き込んでくれなくなった。
それで、話題が飛んでしまうのだと思う。

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:04:30

Itanium。10年は笑えるな。あわれw

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:07:21

SunもNCRと組んでTradataにもSolaris載せようとしたんだけどね。
やめて正解だったわ

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:08:18

eがぬけた

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:12:44

Tukwilaまでもたずに消えるか？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:14:14

2007年において、IPFとIntel Xeonのプラットフォームは共通化され、IPFのプラットフォーム・コストは大幅に引き下げられると、intelの人達が言って
いたんだけど。どこまで共通化されたの？

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:19:39

インターコネクトは CSI という名称だけど別ものらしいぜ。ほんま笑かすww
つーか、x86 部隊がいやがらせしてるのかもな。わざとかもよ?

**名無しさん＠お腹いっぱい。** · 2007/05/26(土) 18:24:21

Intel が x86 とは別にエンタープライズへ行くとしても、もう Ita はないだろ。
コストがかかり過ぎる。