アカウント名:
パスワード:
>何か問題が起きているのであれば、その原因は現在のシステムにあるのであって、リブート後には再現されない恐れがある。
それってUNIXだけでなくWindowsにも当てはまる場合もあるのでは?なぜUNIXだけリブートする前に原因調査をしろという話しになってるのか理解できないUNIX・Windows問わずどんなシステムでも問題が起きたらリブートする前に状態を確認するべきではないのか?
>それってUNIXだけでなくWindowsにも当てはまる場合もあるのでは?Windowsには、「開いているファイルは削除/リネーム出来ない」、「実行中のファイルは改変出来ない」と云う厳しい仕様があるんで、事情が違う。
UNIXの場合は、開いているファイルを削除出来、そのファイルは、クローズされる迄の間、ディレクトリ上には存在しないがファイル自体は存在する扱いを受けて、クローズ時に自動的に消滅する。結果、内容の違う「元」同名のファイルが複数存在し得るのが仕様。
これが、システムファイル変更時に、Windowsでは再起動が必須だが、UNIXでは必須で無い事も在る理由になって居る。
で、Windowsだと、その仕様上、再起動せずにシステムファイルを変更して調査することは困難。代わりに、「現在存在しないファイル」で実行している可能性が無い。UNIXだと、起動したままファイルを入れ替えて挙動を調べる事が出来る代わりに、停止した瞬間に消滅するファイルで動作している可能性が在る。従って、WindowsとUNIXでは、対処法に微妙に違いが出る訳。特に、UNIXで起動したままのパッチは、一度サービスを停止しないと適用されない可能性が有るから、結構面倒だったりする。
一応Windowsでも再起動無してシステムファイル変更することは可能(ただしカーネル除く)
NECがその辺のノウハウ持ってた(る?)はず。
>Windowsには、「開いているファイルは削除/リネーム出来ない」、「実行中のファイルは改変出来ない」と云う厳しい仕様があるんで、事情が違う。
これ出来ませんか?「実行中のEXEをリネームしして新しいEXEを配置」なら、少なくともWindows XP、Windows 2003で何度かやったことがあります。ファイルシステムによるのかな?どちらもNTFSでした。
今Windows7で実行中のEXEをリネームして見ましたが、普通に出来ました。これもNTFS。
私も最初そう思ったんですが、ソースを解析できるかどうかの差かなと思いました。オープンソースなソフトウェアならWindows版でも解析可能ですけど、OS内部になると無理ですし。
>ソースを解析できるかどうかの差かなと思いました。
全員がソースを解析できるわけでもないし、ソースを解析できる人員を24時間はりつかせるのも難しい。逆に5分10分のダウンや速度劣化が厳しい環境もあるわけだからね。CPU負荷があがっちゃって、ログインすらまともにでけへんのや..という状況で「じゃ、時間かけて解析、証券取引はその間中断」とかは、普通ないと思う。
これまで調べるとかいって時間を無駄にしたことがあったりするすると、「調査用にオンライン系で時間を潰すな、ダウンタイムを極小にしろ」ということに一気に意見が傾く。
ミッションのセビリティによって、予めどうするか?を決めていたりするので、過去の実績から判断されるとかね。
ソース読んで、調べては後でやれ、情報収集できていない?じゃ、次は情報収集する機構を組み込んでおけ、ダンプとったけどわかりませんでした?じゃ、ダンプとるのは無駄な場合があるってことでパスしてダウンタイム削減しなさいとか。
そこまでクリティカルなシステムだったら、多重化されてません? サービスは予備系に切り替えて継続、トラブルが起きた方は原因究明につながりそうなデータ取り終えるまで活かしておく、とか。いや実際、リブートで正常復帰するかどうか読めないのに、5分10分のダウンタイムさえ厳しい、なんて運用なら、予備系無しじゃやってられん、とは思うけど。
>そこまでクリティカルなシステムだったら、多重化されてません?
多重化しつつ、落とすべき側をノータッチで稼働させるという環境は持ってないんだよね。
>トラブルが起きた方は原因究明につながりそうなデータ取り終えるまで活かしておく、とか。
ネットワークケーブルとリソース用のストレージのFCをぶち抜くというのが、事前に決まっていたらそうすることも出来るでしょうが、はたして、ネットワークケーブル/ストレージ物理強制切断しても、解明できるか?という問いにベンダーも開発も「できません」という回答だったりするんだよな。
> 多重化しつつ、落とすべき側をノータッチで稼働させるという環境は持ってないんだよね。
まあ、切り替えた時点でネットワーク上のやりとりは遮断されるってとこは止むを得ないですね。それで障害解明に支障は出るかもしれないけれど、サービス中断させられないのなら仕方ない。その状態でもプロセスが残っていてくれればゼロよりは役に立つかも、程度の話です。
いきなり物理切断という話になるのは、想定しているレイヤが違うのかなあ。私の環境だとディスパッチ部分の設定変更で切り替えられることがほとんどですが。フロントエンドやミドルのサーバはローカルキャッシュ以外に状態を持ってないですし、ストレージ系もwarm standbyに同じ内容がレプリケートされているので設定切り替えだけです。一時的に片肺飛行になるのが怖いっちゃ怖いですが。
ディスパッチャ自身が応答不能になる、というケースはあり得ますね。私は体験したことないけど。
サービス最優先のシステムって該当プロセス再起動(またはプロセス群再起動)→復旧不可→予備系への切り替えって段階を踏む物が結構あると思うので、その時点ですでに解析は難しいかもしれませんね全くそのままの状態で保存はまずあり得ないだろうし
冗長化したハードの上でVM動かしてサービス提供してるようなシステムなら現状保存してフリーズできるのかな?ただあれはまだ速度の問題がなー
>ネットワーク上のやりとりは遮断されるってとこは止むを得ないですね
ついでにストレージ関係のNASとかFCとかもね。調査のためにそれをつないでおいてくれ..とか馬鹿を言う「調査したけどだめだった実績多数」エンジニアが多いんですよね。
で、ストレージも調査用に多重化したりするわけですが、RACだとそれが元で混乱というか負荷高騰の経験があったりして、「単純におかしくなったのを再起動」が手順上では第一候補になっていたりする。
>一時的に片肺飛行になるのが怖いっちゃ怖いですが。
サービスレベルの定義では、「待機系の健常性を含めた全体をもって、正常運用とする」があったりする。正常運用は計画停止とか計画フェイルオーバとか以外のウィンドウで求められていたりするからね。以前、サービスが動いているだけをSLAでやっていたら、ダウンした系の調査と修理時間が長引いて顧客の不評を買ったとかもある。
>ディスパッチャ自身が応答不能になる、というケースはあり得ますね。私は体験したことないけど。
どこまでサービスを維持できるか?という問題なんだけど、SLAを含めて、多重障害時のサービス停止すると明示しているから、それはそれで(サービスは停止するが)契約上では受容可能だそうだ。サービスが停止する2重障害のマトリックス図、どれとどれが逝っちゃうとサービス停止(がありえる)とか、書いたことある。
>冗長化したハードの上でVM動かしてサービス提供してるようなシステムなら>現状保存してフリーズできるのかな?
たしか、出来たと記憶しています。ただし、VM上での移管があるために、完全な不具合状況の確保というわけにもいかない。
一応デバッグシンボルが提供されてるのでWin系でもダンプもある程度は意味が有ったりするかな?少なくともここらへんのプロセスやらドライバが臭い位の目安には成りうるし、最悪MSに解析依頼という手もありますし。
最低限再起動前に実行中のプロセスリストやら、ハンドルリストは取ってくれるとリソースリーク系か判別しやすくなるので後が楽そうな感じ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
ちょっと何言ってるかわからないですね (スコア:0)
>何か問題が起きているのであれば、その原因は現在のシステムにあるのであって、リブート後には再現されない恐れがある。
それってUNIXだけでなくWindowsにも当てはまる場合もあるのでは?
なぜUNIXだけリブートする前に原因調査をしろという話しになってるのか理解できない
UNIX・Windows問わずどんなシステムでも問題が起きたらリブートする前に状態を確認するべきではないのか?
WinodwsとUNIXの違い (スコア:2, 参考になる)
>それってUNIXだけでなくWindowsにも当てはまる場合もあるのでは?
Windowsには、「開いているファイルは削除/リネーム出来ない」、「実行中のファイルは改変出来ない」と云う厳しい仕様があるんで、事情が違う。
UNIXの場合は、開いているファイルを削除出来、そのファイルは、クローズされる迄の間、ディレクトリ上には存在しないがファイル自体は存在する扱いを受けて、クローズ時に自動的に消滅する。
結果、内容の違う「元」同名のファイルが複数存在し得るのが仕様。
これが、システムファイル変更時に、Windowsでは再起動が必須だが、UNIXでは必須で無い事も在る理由になって居る。
で、Windowsだと、その仕様上、再起動せずにシステムファイルを変更して調査することは困難。代わりに、「現在存在しないファイル」で実行している可能性が無い。
UNIXだと、起動したままファイルを入れ替えて挙動を調べる事が出来る代わりに、停止した瞬間に消滅するファイルで動作している可能性が在る。
従って、WindowsとUNIXでは、対処法に微妙に違いが出る訳。
特に、UNIXで起動したままのパッチは、一度サービスを停止しないと適用されない可能性が有るから、結構面倒だったりする。
-- Buy It When You Found It --
Re:WinodwsとUNIXの違い (スコア:1)
一応Windowsでも再起動無してシステムファイル変更することは可能(ただしカーネル除く)
NECがその辺のノウハウ持ってた(る?)はず。
Re: (スコア:0)
>Windowsには、「開いているファイルは削除/リネーム出来ない」、「実行中のファイルは改変出来ない」と云う厳しい仕様があるんで、事情が違う。
これ出来ませんか?
「実行中のEXEをリネームしして新しいEXEを配置」なら、少なくともWindows XP、Windows 2003で何度かやったことがあります。
ファイルシステムによるのかな?どちらもNTFSでした。
今Windows7で実行中のEXEをリネームして見ましたが、普通に出来ました。これもNTFS。
Re: (スコア:0)
Re: (スコア:0)
私も最初そう思ったんですが、ソースを解析できるかどうかの差かなと思いました。
オープンソースなソフトウェアならWindows版でも解析可能ですけど、OS内部になると無理ですし。
Re:ちょっと何言ってるかわからないですね (スコア:1)
>ソースを解析できるかどうかの差かなと思いました。
全員がソースを解析できるわけでもないし、ソースを解析できる人員を24時間はりつかせるのも難しい。
逆に5分10分のダウンや速度劣化が厳しい環境もあるわけだからね。
CPU負荷があがっちゃって、ログインすらまともにでけへんのや..という状況で「じゃ、時間かけて解析、証券取引はその間中断」とかは、普通ないと思う。
これまで調べるとかいって時間を無駄にしたことがあったりするすると、「調査用にオンライン系で時間を潰すな、ダウンタイムを極小にしろ」ということに一気に意見が傾く。
ミッションのセビリティによって、予めどうするか?を決めていたりするので、過去の実績から判断されるとかね。
ソース読んで、調べては後でやれ、情報収集できていない?じゃ、次は情報収集する機構を組み込んでおけ、ダンプとったけどわかりませんでした?じゃ、ダンプとるのは無駄な場合があるってことでパスしてダウンタイム削減しなさいとか。
Re: (スコア:0)
そこまでクリティカルなシステムだったら、多重化されてません? サービスは予備系に切り替えて継続、トラブルが起きた方は原因究明につながりそうなデータ取り終えるまで活かしておく、とか。
いや実際、リブートで正常復帰するかどうか読めないのに、5分10分のダウンタイムさえ厳しい、なんて運用なら、予備系無しじゃやってられん、とは思うけど。
Re:ちょっと何言ってるかわからないですね (スコア:1)
>そこまでクリティカルなシステムだったら、多重化されてません?
多重化しつつ、落とすべき側をノータッチで稼働させるという環境は持ってないんだよね。
>トラブルが起きた方は原因究明につながりそうなデータ取り終えるまで活かしておく、とか。
ネットワークケーブルとリソース用のストレージのFCをぶち抜くというのが、事前に決まっていたらそうすることも出来るでしょうが、はたして、ネットワークケーブル/ストレージ物理強制切断しても、解明できるか?という問いにベンダーも開発も「できません」という回答だったりするんだよな。
Re: (スコア:0)
> 多重化しつつ、落とすべき側をノータッチで稼働させるという環境は持ってないんだよね。
まあ、切り替えた時点でネットワーク上のやりとりは遮断されるってとこは止むを得ないですね。それで障害解明に支障は出るかもしれないけれど、サービス中断させられないのなら仕方ない。その状態でもプロセスが残っていてくれればゼロよりは役に立つかも、程度の話です。
いきなり物理切断という話になるのは、想定しているレイヤが違うのかなあ。私の環境だとディスパッチ部分の設定変更で切り替えられることがほとんどですが。フロントエンドやミドルのサーバはローカルキャッシュ以外に状態を持ってないですし、ストレージ系もwarm standbyに同じ内容がレプリケートされているので設定切り替えだけです。一時的に片肺飛行になるのが怖いっちゃ怖いですが。
ディスパッチャ自身が応答不能になる、というケースはあり得ますね。私は体験したことないけど。
Re:ちょっと何言ってるかわからないですね (スコア:1)
サービス最優先のシステムって
該当プロセス再起動(またはプロセス群再起動)→復旧不可→予備系への切り替え
って段階を踏む物が結構あると思うので、その時点ですでに解析は難しいかもしれませんね
全くそのままの状態で保存はまずあり得ないだろうし
冗長化したハードの上でVM動かしてサービス提供してるようなシステムなら
現状保存してフリーズできるのかな?
ただあれはまだ速度の問題がなー
Re:ちょっと何言ってるかわからないですね (スコア:1)
>ネットワーク上のやりとりは遮断されるってとこは止むを得ないですね
ついでにストレージ関係のNASとかFCとかもね。
調査のためにそれをつないでおいてくれ..とか馬鹿を言う「調査したけどだめだった実績多数」エンジニアが多いんですよね。
で、ストレージも調査用に多重化したりするわけですが、RACだとそれが元で混乱というか負荷高騰の経験があったりして、「単純におかしくなったのを再起動」が手順上では第一候補になっていたりする。
>一時的に片肺飛行になるのが怖いっちゃ怖いですが。
サービスレベルの定義では、「待機系の健常性を含めた全体をもって、正常運用とする」があったりする。
正常運用は計画停止とか計画フェイルオーバとか以外のウィンドウで求められていたりするからね。
以前、サービスが動いているだけをSLAでやっていたら、ダウンした系の調査と修理時間が長引いて顧客の不評を買ったとかもある。
>ディスパッチャ自身が応答不能になる、というケースはあり得ますね。私は体験したことないけど。
どこまでサービスを維持できるか?という問題なんだけど、SLAを含めて、多重障害時のサービス停止すると明示しているから、それはそれで(サービスは停止するが)契約上では受容可能だそうだ。
サービスが停止する2重障害のマトリックス図、どれとどれが逝っちゃうとサービス停止(がありえる)とか、書いたことある。
Re:ちょっと何言ってるかわからないですね (スコア:1)
>冗長化したハードの上でVM動かしてサービス提供してるようなシステムなら
>現状保存してフリーズできるのかな?
たしか、出来たと記憶しています。
ただし、VM上での移管があるために、完全な不具合状況の確保というわけにもいかない。
Re:ちょっと何言ってるかわからないですね (スコア:1)
一応デバッグシンボルが提供されてるのでWin系でもダンプもある程度は意味が有ったりするかな?
少なくともここらへんのプロセスやらドライバが臭い位の目安には成りうるし、最悪MSに解析依頼という手もありますし。
最低限再起動前に実行中のプロセスリストやら、ハンドルリストは取ってくれるとリソースリーク系か判別しやすくなるので後が楽そうな感じ