アカウント名:
パスワード:
預金者に知られたら、ベンダーを見極める目が無かった、と謝るんじゃないですかね。
ベンダーは単独なのか複数なのか教えていただけますか?
複数ベンダーのWindows系サーバで毎日障害が起こるというのは 地理的な問題があるんじゃないかと想像します。
WindowsOSがミッションクリティカルな業務に向いていない という結論を出すには、弱いかなと思います。
最も問題なのは、各ベンダーの舵取りを上手く出来て いない点ではないでしょうか。
ミッションクリティカル業務でWindowsOSを使っており、 実現出来てるので「儲けたいだけ」なんていうのは 少し乱暴のように感じます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
実績言うと (スコア:0)
その次にWindows
次にLinux系かソラリス系です。
とはいえここさいきんでいうとWindowsの信頼性が
あります。
Re:実績言うと (スコア:3, 興味深い)
「障害記録」など というカテゴリがノーツ上に作られ
日々、管理されています。
窓系サーバが出張ってきてから8年あまり
障害記録に窓系サーバの障害が載らなかった日は
ただの一日も ありません。
障害時の対応コストが いくら安い と言っても
毎日 障害を起こしているようでは駄目でしょう。
もともと TCOに優れている という売り文句で
サブシステム化(窓系サーバ導入)が進んでいますが
各々のサブシステムが毎日 止まって障害復旧まで
実務が滞る状況を鑑みると下手なコスト削減が
サービス低下を招いているとしか思えてなりません。
実際問題、うちで使われている汎用機の維持費の
数倍が毎年、サブシステムを導入したベンダーに
消えていると聞かされた時には 目の前に立ち並ぶ
サーバーラックをハンマーで叩き壊したくなりました
こんな実態、預金者に知られたら
なんて説明すりゃいいんですかね?
全部「仕様ですから」で納得してくれるなら
どんどん導入してもらいたいですけど
#これ以上、書くとバレるのでAC
Re:実績言うと (スコア:1)
預金者に知られたら、ベンダーを見極める目が無かった、と謝るんじゃないですかね。
ベンダーは単独なのか複数なのか教えていただけますか?
複数ベンダーのWindows系サーバで毎日障害が起こるというのは
地理的な問題があるんじゃないかと想像します。
Re:実績言うと (スコア:1, 参考になる)
多分、ベンダーにとって鴨なんでしょう。
すぐ直したら保守費用取れないので、わざと止まるようにしているのですよ。
以前クソベンダにそんなことされました。
Re:実績言うと (スコア:1, 参考になる)
複数です。現段階で書けるのは
サブシステムの数は
窓系-24システム
UNIX系-6システム
ベンダーは、概ね各システム毎に異なります。
お互いの連携の悪さに加え能力不足が祟り
度重なる更改を繰り返した結果、
同じサービスを提供するが為に新旧システムが
同居するという摩訶不思議な状況に陥ってる区画も存在してます。
運用に携わり10年
「窓系サーバがミッションクリティカルな業務に向いているか?」
と聞かれたら
「向いているワケが無い、それはベンダーが儲けたいだけのビジネスモデルだ」
と即答できるようになりました。
しかし、10年も居て この程度ですから窓の存在って
本当に技術者の能力を低下させるのに打って付けの
環境だと思います。
#ベンダー名 だせ、と言われても さすがに出せないので
代わりにコンサルしてるのはフューチャーです
と晒してみるAC
Re:実績言うと (スコア:1)
WindowsOSがミッションクリティカルな業務に向いていない
という結論を出すには、弱いかなと思います。
最も問題なのは、各ベンダーの舵取りを上手く出来て
いない点ではないでしょうか。
ミッションクリティカル業務でWindowsOSを使っており、
実現出来てるので「儲けたいだけ」なんていうのは
少し乱暴のように感じます。
Re:実績言うと (スコア:0)
Re:実績言うと (スコア:0)
新旧システム混在も移行計画のずさんさの気がします。
コンサルの言う事だけ聞いて、システム毎にベンダー丸投げという姿勢ではおっしゃるような状況になるでしょうねw
WindowsやLinuxでミッションクリティカルシステムを動かそうと思ったこと無いのでAC
Re:実績言うと (スコア:0)
10年無駄にした金で、ベンダー絞って作り直したほうが良かったね。
Re:実績言うと (スコア:0)
自分(の会社)のベンダーを見る目が足りなかった事を悔いてください。せいぜい。
# Windows系7/24システム2年連続稼働中の知ってるのでAC
規模も考えたら? (スコア:1, 興味深い)
トラブルとどっちが信頼性あるんでしょうね?
余談ですが、NT4.0で1万時間以上稼働しているシステムを見た
ことがありますが、CPU時間の大小がひっくり返っていました。
(タスクマネージャにて)
そこまで無停止で使われるとは思っていなかったのでしょうが
やはりそれくらいでは馬脚を現して欲しくないものです。
Re:規模も考えたら? (スコア:1, 興味深い)
一年に一台止まる可能性があるならば、365台あれば、一日一台止まりますので、2000台で、一日一台ならば、5.5年に一台が一度止まる可能性があるという程度で、2000台ものシステムでその率ならば、かなり良いのでは?と思いますが。
Re:規模も考えたら? (スコア:0)
># Windows系7/24システム2年連続稼働中の知ってるのでAC
に対して、
>1台のシステム2年無停止と、2000台のシステムで1日1件の
>トラブルとどっちが信頼性あるんでしょうね?
と言ってるんですから、2000台の方が信頼性があると言ってるんですよ。
Re:規模も考えたら? (スコア:0)
その「1万時間を越えていた」というのが、1万2千に到達していたかどうかは知りませんが、もしかして497日越えていたのでは?
Re:規模も考えたら? (スコア:1)
497日問題がありましたけど、パッチは出てますね。
Linuxにも似たような問題があるのですか?
初耳なのでどういうものなのかぜひ知りたいです。
#自宅のFreeBSDはuptime 829日になるけど特に問題出てないな。
Re:規模も考えたら? (スコア:3, 参考になる)
> 初耳なのでどういうものなのかぜひ知りたいです。
この問題があまり騒がれていないこと自体、Linuxがミッションクリティカルな分野にそれほど導入されていないという証拠のひとつになるのでしょうか? 現実にはLinuxにも497日問題はあります。
とりあえずjiffies 497で検索してみるといいでしょう。
WindowsやLinuxに限ったことではないですが、32bitOSにはシステムタイマーに32bit幅の変数を使っているものが多いです。システムタイマーが10ms単位でカウントアップする場合、497日でカウンタがラウンドアップしますから、これらを参照していながらラウンドアップを考慮していないソフトは、497日でたいていこけます。
Linuxの場合、カーネル2.4までは32bitのjiffiesしかありません。jiffiesはハードウェアドライバ類で参照されることが多いので、これがラウンドアップすると、カーネルパニックとなる可能性がかなり高いです。
まぁ、どう異常をきたすかは、ドライバしだいですけど。単にひとつのI/Oが失敗するのか、タイマー待ちのまま固まるか、あるいは暴走するか、予想できません。
カーネル2.6以降だと、64bit幅を持つjiffies_64も新設されています。このためカーネルレベルでは問題は解消されているはずです。
ただし、仮にカーネルが2.6以降でも、使っているドライバ類がカーネル2.4以前のコードベースを使っている場合には、やっぱり異常をきたす可能性があります。
そもそもカーネル2.6は、リリース後まだ497日経過していません。なので、仮に問題があるとしても、それがわかるまでにはまだ半年以上の間があります。
Re:規模も考えたら? (スコア:0)