アカウント名:
パスワード:
今どきTCP/IPスタックをサポートしていないメインフレームなんて存在しているんですか? 使えるというレベルなら1980年代から, マルチベンダー間の標準的な接続手順としても5年以上前から極々普通に使っていますよ. serviceファイルを覗いてみても, ds3270とかtnETOSといったプロプラ手順用のポートが予約されているのが分かると思います.
まあ, この上でオンラインゲームを構築するのはシステムアーキテクチャ的に無理と言ってよいでしょうが, 課金システムの様なトランザクションモニタが必要になるような局面では, メインフレームの方が(規模にもよりますが)あるいは構築が楽かもしれません.
何かメインフレームに対して限られた知識しか持っておられないようなので...
まずTCP/IPなんですが, これは他でも述べましたが, メインフレームにおいても既に「枯れた」技術となっています. 実際, メインフレームを含めた企業の基幹ネットワークの大部分はTCP/IPベースに移行しているのが現状です. 今あえてTCP/IPを使わないとしたら, IPv4では保証されないQoSが必要な場合, 工場などの旧式な設備でTCP/IPが使用できない場合, 社外(取引先等)接続でシームレスな接続を防ぐ場合程度でしょう. 問題はこのレイヤーの上のアプリケーション層の話で, そこでUNIX系に実績が有るというのに異論は有りません.
次に過負荷時のシステムの挙動がUNIX系とメインフレームで同様と思われているようですが, これは誤解です. UNIX系ではネットワーク層に対して素の状態で操作を行うことが普通ですが(これがネットワークシステムとしての柔軟性の元になっている), メインフレームでは通常はメッセージ・キューイング機構を使用したモニタを介してネットワークとの通信を行います.
ここでシステムが設計上限以上の過負荷な状態になった場合を考えてみます. まず数10%~100%程度の過負荷状態では, UNIX系では設計レスポンスよりは遅れますが, 取りあえず処理は行われて結果が返ってくると思われます. 一方メインフレームでは設計上限を超えた分についてはクライアントに対して接続不可という結果が返ってきます. ただ接続が確定した分については設計レスポンス以内で答えが返ってきます.
ここまでの状態を見れば, なるほどUNIX系の方が負荷変動に強いように思えます. ですが, 設計負荷の数倍を超える今回のFFXIの様な場合には, ちょっと様子が変わってきます.
まず, UNIX系でも古い物やLinuxの様な弱い物では安定した稼働が維持できず動作不正(リブート等も含む)が起きるようになります. 最近のSolaris, HP-UX, AIX等のエンタープライズ用途で使われるUNIXではこの様な動作不正を起こすことはありませんが, 素の状態ではレスポンスが極度に低下します. ユーザから見た場合, 待たせたあげくにtime outで接続できなかったり, 処理中に通信time outが発生して接続が切れるというような現象が頻繁に発生するようになります. 一方メインフレームの場合, 処理可能な設計上限以上の受付・多重処理は行わないので, 大部分はただちに接続不可の通知が返されます. また, 運良く接続が出来れば設計レスポンス内で処理が行われ, 結果が返ります.(ものすごく単純化した説明ですが(^_^;)
この様なメインフレームの挙動は別のスレッドで紹介されていた行列方式処理と基本的に変わりません. ただ, 使い込まれている分だけ安定性や運用上のユーティリティが揃っている分だけ有利であるとは言えます.
もちろんUNIX系だけで高信頼性システムを構築することも可能ですが, その場合メインフレームと同様なトランザクション・モニタの使用や, ピーク負荷に合わせた一見過剰とも思えるような設備が必要になるのは確かです(それでもトータルコストで安くなったりするんですが)
確かに物には使いどころが有りますが, まずその前にしなければいけないのは, システム要件を見切るということだと思います. 今回のFFXI騒動はシステム要件の見きりが甘かったか, 要件を見切った上での見切り発車なのか... どっちなんでしょうね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
え? メインフレームじゃないの? (スコア:-1, すばらしい洞察)
Re:え? メインフレームじゃないの? (スコア:0)
あと、モデレーター
何でこんなのが「すばらしい洞察」なの?
ちゃんと考えてよ
Re:え? メインフレームじゃないの? (スコア:3, 興味深い)
あるというは、有名な話ですよ。
Re:え? メインフレームじゃないの? (スコア:1)
--
Morza Dizemble
Re:え? メインフレームじゃないの? (スコア:1, 参考になる)
フロントエンド:PCサーバ 1500台
バックエンド(DB):SunFire6800 2台
とのことです。
Re:え? メインフレームじゃないの? (スコア:1)
どれがボトルネックか (スコア:0)
Re:どれがボトルネックか (スコア:1, 興味深い)
クライアントのトラフィックに重なってるね。
なんで、ここ、共用なの?
裏口からバックエンドに流せばいのに、なんのためのフロントエンドなの??
これじゃあ、手前のネットワークのトラフィックが3倍になるでしょーに
Re:どれがボトルネックか (スコア:0)
セキュリティ確保が理由かとおもわれます。
Re:どれがボトルネックか (スコア:1)
フロントエンドからクライアントに、大量のデータを転送しようとした場合、どうなるか?
だろうねぇ。
フロントエンドはサーバーにファイルを取りに行くから・・・・・。
更新ファイルサーバーだけ、別系統のftpサーバーを立てるべきだけど、さて?
Re:責任者出てこい!(おふとぴ) (スコア:0)
---
男なら辻希美( ´?`)
Re:責任者出てこい!(おふとぴ) (スコア:0)
構成は思ってたよりヘボいな。そりゃ落ちるって・・・
もちっと金かけないと。
---
男ならこずえ鈴(´Д`)ハァハァ
Re:責任者出てこい!(おふとぴ) (スコア:0)
レンダリング・ファームでの経験だけで、クラスターのスイッチそのままインターネットにつないじゃいましたってのが真相か……
メモリ8G? (スコア:0)
Re:メモリ8G? (スコア:0)
そもそもこいつに何やらせてるんだ?
Re:メモリ8G? (スコア:1)
まあ30万人規模ならDBサーバとしてはこんなものなのでは?
Javaが動くわけでもないし、Oracleで30万人だったらちょうど良いような気もします。
ちゅーか、ギガビットのイーサだとしても、フロント1000台あったら1台あたりの帯域は1Mbps?さらにバックとフロントにネットワークわけてないから、500Kbpsしかないってことか?
Re:え? メインフレームじゃないの? (スコア:0)
Re:え? メインフレームじゃないの? (スコア:1)
責任者も見れますね。
一意見に左右されやすい評価 (スコア:0)
なのに、PCサーバじゃないと思い込んでた一意見に左右されて-1まで下げられるとはね。。。
一意見じゃなくて、議論の動向を見て評価してもらいたいね。
じゃないと、こういう輩が続出してモデレートの意味がなくなる。
メインフレームという言葉だけ知ってたのね (スコア:0)
構築することの方が信じがたいがな。
バックエンドに使うにしてもフロントエンドのマシンが
メインフレームと通信しなきゃダメだから
どこかで、通信プロトコルを2way積んだマシンが必要になる。
インターネット接続でサーバ・・・
・・・メインフレームはTCPスタックが・・・
・・・Windowsは安定性が・・・・
メインフレーム上のTCP/IP (スコア:1)
今どきTCP/IPスタックをサポートしていないメインフレームなんて存在しているんですか? 使えるというレベルなら1980年代から, マルチベンダー間の標準的な接続手順としても5年以上前から極々普通に使っていますよ. serviceファイルを覗いてみても, ds3270とかtnETOSといったプロプラ手順用のポートが予約されているのが分かると思います.
まあ, この上でオンラインゲームを構築するのはシステムアーキテクチャ的に無理と言ってよいでしょうが, 課金システムの様なトランザクションモニタが必要になるような局面では, メインフレームの方が(規模にもよりますが)あるいは構築が楽かもしれません.
Re:メインフレーム上のTCP/IP (スコア:1)
欧米は小切手決済が主流なので、日本の様なATM系なシステムは実は少ないというハナシが御座いますから、これからの日本の輸出産業はメインフレーム由来のシステム構築力なーんて形で、この手のサイトの構築を請け負うってのはどうでしょーか。
実際に処理をするコンピュータのサイトは日本にあって、処理能力を売るんですよ、欧米に:-)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:メインフレームという言葉だけ知ってたのね (スコア:1, 参考になる)
もちろん裏はメインフレーム。
メリットといえば、
思いつくだけでも、
・プロジェクトに参加するエンジニアの分業化による高い専門性&経験
・ほぼ計算可能な性能設計値
・IO性能(高速で待ちの少ない接続による
各種専用サブシステムのハードウェアによる分散や
ほぼRAWなディスクアクセス等)
・計算&記憶資源集約型のデザインによる安定した性能
・ハードウェアの信頼性
とか。
ちがうのかな?
メインフレームがTCP/IPしゃべらない、というのは、
ペンティアム4はTCP/IPしゃべらない、というのと同じかなあ。
メインフレームは、将にそういう意味で汎用機なわけで。
Re:メインフレームという言葉だけ知ってたのね (スコア:1, 参考になる)
TCPスタックがないわけじゃないのは知ってるけど
TCPスタックの運用実績は、UNIXに一日の長がある。
>・IO性能(高速で待ちの少ない接続による
> 各種専用サブシステムのハードウェアによる分散や
> ほぼRAWなディスクアクセス等)
メインフレームのI/O性能はこの際(ネットワークと)問題が違うように思います
インターネットからのアクセスは、内部I/O性能より外のネットワーク性能によって制約を受けませんか?
もちろん、1台で不特定数の接続を受けるといった離れ業をするのであれば話は別でしょうが・・・
>・ほぼ計算可能な性能設計値
メインフレームは、計算できない通信量の増加に対して
対応しきれないでしょう。
計算量が決まっている環境や、安定した環境では
強いかもしれませんが、見積もれない負荷(増大)に対して
メインフレームをもう一台・・・というような使い方が
できないのがインターネット系に使えない理由。
だからメインフレームは
「計算可能なアクセス数」の閉じた通信網に接続した業務
には強いわけですが
今回のような
「予測不能なアクセス数」がきた場合はどうなっていたか・・・
という訳です。
ま、ものにはそれぞれ得意分野があるという結論でよいでしょうか?
Re:メインフレームという言葉だけ知ってたのね (スコア:1)
何かメインフレームに対して限られた知識しか持っておられないようなので...
まずTCP/IPなんですが, これは他でも述べましたが, メインフレームにおいても既に「枯れた」技術となっています. 実際, メインフレームを含めた企業の基幹ネットワークの大部分はTCP/IPベースに移行しているのが現状です. 今あえてTCP/IPを使わないとしたら, IPv4では保証されないQoSが必要な場合, 工場などの旧式な設備でTCP/IPが使用できない場合, 社外(取引先等)接続でシームレスな接続を防ぐ場合程度でしょう. 問題はこのレイヤーの上のアプリケーション層の話で, そこでUNIX系に実績が有るというのに異論は有りません.
次に過負荷時のシステムの挙動がUNIX系とメインフレームで同様と思われているようですが, これは誤解です. UNIX系ではネットワーク層に対して素の状態で操作を行うことが普通ですが(これがネットワークシステムとしての柔軟性の元になっている), メインフレームでは通常はメッセージ・キューイング機構を使用したモニタを介してネットワークとの通信を行います.
ここでシステムが設計上限以上の過負荷な状態になった場合を考えてみます. まず数10%~100%程度の過負荷状態では, UNIX系では設計レスポンスよりは遅れますが, 取りあえず処理は行われて結果が返ってくると思われます. 一方メインフレームでは設計上限を超えた分についてはクライアントに対して接続不可という結果が返ってきます. ただ接続が確定した分については設計レスポンス以内で答えが返ってきます.
ここまでの状態を見れば, なるほどUNIX系の方が負荷変動に強いように思えます. ですが, 設計負荷の数倍を超える今回のFFXIの様な場合には, ちょっと様子が変わってきます.
まず, UNIX系でも古い物やLinuxの様な弱い物では安定した稼働が維持できず動作不正(リブート等も含む)が起きるようになります. 最近のSolaris, HP-UX, AIX等のエンタープライズ用途で使われるUNIXではこの様な動作不正を起こすことはありませんが, 素の状態ではレスポンスが極度に低下します. ユーザから見た場合, 待たせたあげくにtime outで接続できなかったり, 処理中に通信time outが発生して接続が切れるというような現象が頻繁に発生するようになります. 一方メインフレームの場合, 処理可能な設計上限以上の受付・多重処理は行わないので, 大部分はただちに接続不可の通知が返されます. また, 運良く接続が出来れば設計レスポンス内で処理が行われ, 結果が返ります.(ものすごく単純化した説明ですが(^_^;)
この様なメインフレームの挙動は別のスレッドで紹介されていた行列方式処理と基本的に変わりません. ただ, 使い込まれている分だけ安定性や運用上のユーティリティが揃っている分だけ有利であるとは言えます.
もちろんUNIX系だけで高信頼性システムを構築することも可能ですが, その場合メインフレームと同様なトランザクション・モニタの使用や, ピーク負荷に合わせた一見過剰とも思えるような設備が必要になるのは確かです(それでもトータルコストで安くなったりするんですが)
確かに物には使いどころが有りますが, まずその前にしなければいけないのは, システム要件を見切るということだと思います. 今回のFFXI騒動はシステム要件の見きりが甘かったか, 要件を見切った上での見切り発車なのか... どっちなんでしょうね?
Re:メインフレームという言葉だけ知ってたのね (スコア:0)
まぁでも、
Re:メインフレームという言葉だけ知ってたのね (スコア:0)