アカウント名:
パスワード:
何かメインフレームに対して限られた知識しか持っておられないようなので...
まず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, すばらしい洞察)
メインフレームという言葉だけ知ってたのね (スコア:0)
構築することの方が信じがたいがな。
バックエンドに使うにしてもフロントエンドのマシンが
メインフレームと通信しなきゃダメだから
どこかで、通信プロトコルを2way積んだマシンが必要になる。
インターネット接続でサーバ・・・
・・・メインフレームはTCPスタックが・・・
・・・Windowsは安定性が・・・・
Re:メインフレームという言葉だけ知ってたのね (スコア:1, 参考になる)
もちろん裏はメインフレーム。
メリットといえば、
思いつくだけでも、
・プロジェクトに参加するエンジニアの分業化による高い専門性&経験
・ほぼ計算可能な性能設計値
・IO性能(高速で待ちの少ない接続による
各種専用サブシステムのハードウェアによる分散や
ほぼRAWなディスクアクセス等)
・計算&記憶資源
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)
まぁでも、