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