アカウント名:
パスワード:
個人的には、「少なくともOracle RACを勘定系で動かせる程度にはLinuxは安定している」というOracleの判断なのかな、と思います。ま、RedHatというよりOracleの手腕に期待かな。
あと、個人的にはJRockIt on Linuxで行く点に注目してます。サポートの観点からはベンダーを揃えるのは正解だと思います。しかし、実績という観点では、JRockItも買収前から考えれば結構長いですから安定しているのかもしれませんが、ユーザーベースから考えれば圧倒的にSunJDKの事例が多いので、果たしてJRockItが十分枯れているのかに興味があります。
#Sun JDK+Weblogicだと、未だにHotSpot Internal Errorに悩まされることがあるので...
でも、バッチ処理に、EJBを使う意義が今ひとつ見えてきませんよね。中間ファイルを残していれば、こけたときにそのステップから流せばいいんですから(懐かしい)、何もいちいちEJBでトランザクションを起こしてRDBMSにインサート、アップデートする必要があるとは思えません。それより、64bitVMでヒープを思いっきり大きくとり、メモリ上でソート、マージなど各種データ操作を極力行い、ディスクアクセスを減らすほうがよっぽど効果的だと思いますが。マスタのデータ長を500バイトだとしても、1000万件で5GBですよね。ソートの一時領域とか考えても、今の水準だったら、余裕でメモリ上に展開できるはずです。
RACだと1ノード障害=縮退 とならざるを得ないから、結局トランザクション集中で連鎖障害になっちまうんでねーの?という話かと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
LinuxよりもRACのほうがポイント? (スコア:2, 興味深い)
個人的には、「少なくともOracle RACを勘定系で動かせる程度にはLinuxは安定している」というOracleの判断なのかな、と思います。ま、RedHatというよりOracleの手腕に期待かな。
Re:LinuxよりもRACのほうがポイント? (スコア:2, 興味深い)
あと、個人的にはJRockIt on Linuxで行く点に注目してます。サポートの観点からはベンダーを揃えるのは正解だと思います。しかし、実績という観点では、JRockItも買収前から考えれば結構長いですから安定しているのかもしれませんが、ユーザーベースから考えれば圧倒的にSunJDKの事例が多いので、果たしてJRockItが十分枯れているのかに興味があります。
#Sun JDK+Weblogicだと、未だにHotSpot Internal Errorに悩まされることがあるので...
でも、バッチ処理に、EJBを使う意義が今ひとつ見えてきませんよね。中間ファイルを残していれば、こけたときにそのステップから流せばいいんですから(懐かしい)、何もいちいちEJBでトランザクションを起こしてRDBMSにインサート、アップデートする必要があるとは思えません。それより、64bitVMでヒープを思いっきり大きくとり、メモリ上でソート、マージなど各種データ操作を極力行い、ディスクアクセスを減らすほうがよっぽど効果的だと思いますが。マスタのデータ長を500バイトだとしても、1000万件で5GBですよね。ソートの一時領域とか考えても、今の水準だったら、余裕でメモリ上に展開できるはずです。
Re:LinuxよりもRACのほうがポイント? (スコア:1, 参考になる)
RACは確かに投資に対して最大限の性能を出すかもしれないけど、
そもそも実績がまだまだ少ないこと、
そして、障害時に性能がダウン(2台稼動なら50%)することがネック。
勘定系のように稼働中のトランザクション数が常に多く、
かつ性能がダウンすることがイコールQueueが増加する(タイムアウトできない)システムの場合、
HAの方が投資は多くなるけど、障害時の安定稼動に繋がるんだけどね。
1台ダウン→もう1台にトランザクションが殺到→もう1台もそのままダウン
と言うシナリオを考えると、RACは怖くて使えないね。
HAならダウンしても同じ性能なので、
切り替えによるオーバーフローは考慮しなくて良いし、実績もある。
新技術だから優れているわけではなくて、
その技術を適材適所に配分することがSIerの腕の見せ所だと思うけど。
#だからこそCOBOLが未だに残っているわけで。
つか、勘定系ではなく基幹系に導入では?
勘定系と基幹系は全然別物だと思うけど…。
Re:LinuxよりもRACのほうがポイント? (スコア:0)
Re:LinuxよりもRACのほうがポイント? (スコア:1)
いやいやそうでなくて。
RACだと1ノード障害=縮退 とならざるを得ないから、結局トランザクション集中で連鎖障害になっちまうんでねーの?という話かと。
それよりn:1とかn:nのHA構成にして1ノードコケても処理能力は変わらないようにした方がいいですよね。
スタンバイノードは常時は遊んじゃうけど仕方がない。
-- sun burst.
Re:LinuxよりもRACのほうがポイント? (スコア:1)
Re:LinuxよりもRACのほうがポイント? (スコア:1)
いや、そんな設計では組まないでしょうな普通。
>いくら何でも、数台の余裕を見越しての編成ぐらいは期待して良いと思いますね。
そう信じたいところです。
最低限、(余裕率を見越した必要台数+1台)でRAC組めばいい話なんで。
で #368388 のAC氏の
>そして、障害時に性能がダウン(2台稼動なら50%)することがネック。
に対する #368404 のAC氏
>HA構成で一台で捌ける程度なら、ハナからRACなんて使わないと思いますが。
というふうに2台を1:1のHAで使うのでなくて、コストかかるけどもう1台導入して2:1のHAにすれば、2台のRACに比べて障害時の性能ダウンがない、という話かと。
RACの信頼性は誰か識者の方お願い…。
-- sun burst.
Re:LinuxよりもRACのほうがポイント? (スコア:0)
一応、検証やってる、おっちゃんが
「やっと、お客に自身をもって勧められる」
とは言ってたよ。
・・って、アンタ、パラレルサーバの提案書いっつも書いてたじゃん。って思ったけど。
ちゃんとスケールもするみたいだし、割とまともみたいね。
Re:LinuxよりもRACのほうがポイント? (スコア:0)
要するに、何を期待してRACを導入するかで効果が全然違う。
(個人的な)RACの最大の利点は「セッションを引き継げる」ところ。
HAだとダウンしたサーバに繋がっていたセッションは当然落とされるが、
RACの場合はそのセッションをそのままもう1台が引き継いでくれる。
つまり、アプリケーション側で障害時のセッション切れを意識しなくても、
障害時の切り替えがスムーズに行くってことやね。
逆にセッションが切れても良いなら普通にHAで組んだ方が
Re:LinuxよりもRACのほうがポイント? (スコア:0)
>これがハッキリしないとベンダに面白いように騙されますな。(w
わかんなかったら、一番高いオプションを勧められますね。ひひひ。
なんでもできる、魔法のプロダクトなんて無いことは
冷静になったらわかるんですけどね・・・
Re:LinuxよりもRACのほうがポイント? (スコア:0)
それ自体が既にどうかという気もするのですが。
RACってHAで言うところの待機系のノードを用意することはできないんでしょうか?
まさかそんなことはないと思うのですが。。
要するに、障害時に待機系からリソースを回せればいいわけでしょ?
Re:LinuxよりもRACのほうがポイント? (スコア:0)