UNIXサーバはリブートすべきでない説 225
ストーリー by hylom
でもリブートせざるを得ない状況ってあるしなぁ 部門より
でもリブートせざるを得ない状況ってあるしなぁ 部門より
あるAnonymous Coward 曰く、
「何か問題が発生したり、クリーンな環境にしたかったらリブートしろ」という神話があるそうだが、果たしてこれは本当だろうか？（本家/.記事）。
InfoWorldの記事によると、「Windowsで問題が発生したらリブートする」というのは当たり前のことだが、UNIXではそうすべきでないとのこと。何か問題が起きているのであれば、その原因は現在のシステムにあるのであって、リブート後には再現されない恐れがある。そのためリブートする前に原因を精査すべきであると指摘している。
原因究明が優先されるのは、サービス影響が無い場合だけ。 (スコア:5, すばらしい洞察)
Re:原因究明が優先されるのは、サービス影響が無い場合だけ。 (スコア:3, おもしろおかしい)
Re:原因究明が優先されるのは、サービス影響が無い場合だけ。 (スコア:2)
ですね。私が作っているプログラムは、プログラムのバージョンアップ以外の時以外は、再起動されません。半年とか１年とか動きっぱなし。
内部のシリアルカウンタは48bitになっております。秒間10000上がるとしても900年弱持つ勘定。
Re:原因究明が優先されるのは、サービス影響が無い場合だけ。 (スコア:1)
>原因究明が優先されるのは、サービス影響が無い場合だけ。
まさにそれだな。
原因究明を含めて、テスト環境やステージング環境があるわけだからね。
無停止で究明する、停止時間に影響しないという究明をする、リブートで再開できないと事前に証明するといったことがない限り、開発している連中が言っても、へのつっぱりにもならない。
「ダンプとってください」「ダンプとっても判らない場合、引責してもらえますね？」に、「はい、首を賭けて解明します」という回答を貰ったことがない。
「再起動して立ち上がらないかもしれません」「じゃ、再起動しないで今すぐにサービス再開してください」にも回答できない。
何か言うなら、それなりを示してからにして欲しいんですけどね。
問題がリブート後に再現しないのは良くない (スコア:2, 興味深い)
いや、今回の話はデバッグしてからリブートしても遅くないぞっていう話だとは思うが。
Re:問題がリブート後に再現しないのは良くない (スコア:1)
Re:問題がリブート後に再現しないのは良くない (スコア:2)
マトモなサーバ機なら、BIOSとかコンソールも遠隔操作できますよ。
問題の優先度をちゃんと考えている？ (スコア:2, すばらしい洞察)
その運用状態が「トラブったまま原因究明まで停止して良い物かどうか」で全然意味合いが違う。
WindowsだUNIXだって前に、それが何をしているのか？どの程度の重要度が有るのか？で違うだろ。
場合によってはリブートして再現しないならしないでそのまま動かし、他所で再現テストって方が良いことも珍しくない。
そのサーバー自体がすべてなのか、大きな業務の一部なのかでも変わるね。
Linux は、別だよね (スコア:2, おもしろおかしい)
どうにもならなくなるけど、ここで言う UNIX とは、別だよね。
また、samba のプロセスが 10000個ぐらいになってしまったりしたときも、
全部 kill するのは、馬鹿だよね。
エンドユーザの視点 (スコア:1, 興味深い)
>リブート後には再現されない恐れがある。
問題は解消され、かつ、二度とその問題が起こらないのであれば、
リブートするのは極めて合理的な解決策である（ｷﾘｯ
Re:エンドユーザの視点 (スコア:2, 興味深い)
Windowsの再起動すれば直る話は
要はリソース漏れなんだからマシンごと再起動すればいいよ！
っていうのが大きいと、原因はある程度認識されてると思ってる。
画面A→画面B→画面A と辿ると2度目のAでおかしくなる、みたいな場合でも
（アプリにしろOSにしろ）再起動すればゴミが消えてまた動くようになる事も多いので
とりあえず再起動するのはアリだと思う。（このツリーのサブジェクト的に考えれば）
画面Aで立ち止まって原因を調べないといけない、ってのはやはりプロの見方だし
>「二度とその問題が起こらない」と果てして言えるかしら。
そもそもエンドユーザなら何度同じことが起きても再起動するだけなので、原因はどうでもいいのでしょう。
# NT系じゃない方が主流だった時代に比べたら頻度も減ったし、1回あたりの時間も短くなっていってるし。
Re:エンドユーザの視点 (スコア:2, すばらしい洞察)
今回重要なのは、
「UNIXサーバ」をリブートする
かどうかではないのかな。
デスクトップなら、使っている自分の範囲で影響が限定できるけど、
サーバはそうはいかない。
逆にサーバを、「なんか変だからリブートするね」と毎回やられると、
悲鳴があちこちで。
# 自動アップデートにしてある Windows のファイル共有で、なんど泣かされたことか。
Re:エンドユーザの視点 (スコア:1, おもしろおかしい)
Re:エンドユーザの視点 (スコア:1)
>そして問題が解決されないばかりか悪化したり、二度と起動しなくなったり
それはそれで再構築フェーズに入るので、了解とれそうだから問題ないな。
問題解決を待って１０年前にサーバ止めたままですとかね。
原因究明を待てというのは、実際的でないことが結構あるからね。
てっきりセキュリティ的な理由かと (スコア:1, 興味深い)
ブートシーケンスに食い込んだrootkitがさまざまな痕跡を消してしまうから、的な話かと。
犯行現場は残しておけって訓話じゃなかったのか。
# ただ、「Sunのサーバは電源を落とすと上がってこない、だから電源は落とすな。」
# という言い伝えが社内にあるんだよな。
# 動き続いて安定しているHDDの不具合が露呈してしまうからだとかいう分析が・・・
Re:てっきりセキュリティ的な理由かと (スコア:4, 興味深い)
> # ただ、「Sunのサーバは電源を落とすと上がってこない、だから電源は落とすな。」
> # という言い伝えが社内にあるんだよな。
> # 動き続いて安定しているHDDの不具合が露呈してしまうからだとかいう分析が・・・
あれは、モータのトルク不足で、ベアリング古くなってくると、一度止まったHDDが再度回らなくなるってやつです。
スピンドルを手で回すとOKとか言っていた猛者がいました。
Re:てっきりセキュリティ的な理由かと (スコア:3, 参考になる)
> スピンドルを手で回すとOKとか言っていた猛者がいました。
ドライブだけ取り出し、ケーブルは接続したままで電源が入った状態で、
「手首のスナップを効かせてドライブを素早くひねる」ことで、
慣性の法則で相対的にプラッタを回転させる、という技は使ったことがあります。
慣れると結構簡単に起動させられるようになります。
#うろ覚えですが、「Quantamの80MBが鬼門」だったかな?
#Macintoshによく採用されてて、定番のトラブルような憶えが…
Re:てっきりセキュリティ的な理由かと (スコア:2, 興味深い)
#うろ覚えですが、「Quantamの80MBが鬼門」だったかな?
#Macintoshによく採用されてて、定番のトラブルような憶えが…
spin up しない時は HDD を恭しく取り出して、ドライバーのグリップで軽く３回コン！コン！コン！と叩いて元に戻せばあら不思議！！
…だったかな。
太平洋高気圧がはりだすと (スコア:2, おもしろおかしい)
Re:てっきりセキュリティ的な理由かと (スコア:3, 興味深い)
>二重化されてれば無問題
今時の性能のよい電源やコンデンサや電池なんて
だいたい二重化したものは同時に壊れる。
Re:てっきりセキュリティ的な理由かと (スコア:2, 興味深い)
そうなんですよね。
RAID 5 で安心、とかやってると、ほぼ同時に2台とんで、データ復活できず、
ってなことが、、、
良く似た現象で、1台飛んで rebuild かけている間に2台目があやしくなり、
さらに rebuild して、、、と3回ほど連続して rebuild したことが。
もしかしてエンドレスか、と疑心暗鬼でした。
Re:てっきりセキュリティ的な理由かと (スコア:2, 参考になる)
>>良く似た現象で、1台飛んで rebuild かけている間に2台目があやしくなり、
それ、恐らくHDDの問題ではないです
電源系がヘタっていて全てのHDDへの電圧降下が起こってた可能性のほうが高いです。
データリカバリ会社が口を酸っぱくして素人判断で対処せず「そのままの状態で」というのは、そういう広義なトラブルも鑑みての忠告です。
Re:てっきりセキュリティ的な理由かと (スコア:1, おもしろおかしい)
A:「ちなみにこのrebuildは何回目だ？」
B:「今回が15498回目に該当する」
Re:てっきりセキュリティ的な理由かと (スコア:1)
Re:てっきりセキュリティ的な理由かと (スコア:1, おもしろおかしい)
妊娠したから液漏れするのか？
Re:てっきりセキュリティ的な理由かと (スコア:2, おもしろおかしい)
妊娠中はまだ液漏れしてないはず。
破水したら激しく液漏れする。
Re:てっきりセキュリティ的な理由かと (スコア:2, おもしろおかしい)
Re:てっきりセキュリティ的な理由かと (スコア:1)
Re:てっきりセキュリティ的な理由かと (スコア:1)
runlevel 0ですな。
#5がpoweroffなのを知った時は衝撃だった
メモリダンプ取って再起動 (スコア:1, 興味深い)
システムの動態解析というのは、開発時のテストの時ぐらいしかやらないのでは？
どちらかというと、メモリダンプを取って、再起動というのが多いかな。死体(メモリダンプイメージ)の解析には時間をかけられるが、システムがまともに動かない時間というのは、外圧が大きすぎて、時間をかけられない為です。下手に動作を継続して、データを破壊でもされたら、余計に、復旧に時間がかかりますからね。
最近は、テラバイトクラスのメモリを積んでいて、メモリダンプを取るだけで８時間以上かかる大型システムも増えていますので、問題の種類にもよるが、再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな？
Re:メモリダンプ取って再起動 (スコア:2, 興味深い)
>メモリダンプを取って、再起動というのが多いかな。
メモリダンプを取らないという判断もあった。
三回ほどOSがフリーズしたたびに、ベンダーの言う通り、ちょっと時間かけてメモリダンプをとって提出したが「原因不明」と三回とも回答があったので「御社システムにおいて、メモリダンプは意味がないと思われる、メモリダンプ取得によって原因究明という実績がない。実績を出せる様になってから要求せよ」と伝えたら、「次回からはログ提出提出のみを依頼いたします」だとさ。
そして、メモリ容量がでかくなって、メモリダンプ取っていたら契約上許される時間でのサービス復旧は無理。
なので、方式設計レベルで「問題発生時は、メモリダンプなどの取得をせず、再起動後に取得できるログファイルなどから解明を行う。解明できる確率は低いが、これまでの実績からメモリダンプにより解明できたケースが皆無であることも考慮した」とか書かれていたりする。
>再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな？
予備系に切り替えは、デザスタリリカバリとかで、ダウンタイムがそれなりに大きくなると予想されていたりとかね。
クラスタの切り替え、だめなら再度の全再起動、それでだめなら災害対策用センターにあるシステムに火をいれつつ..とかね。
Re:メモリダンプ取って再起動 (スコア:1)
>「ログだけじゃ原因わかりませんでした」って逃げるためのような…。
で、以前はダンプがあればということで、三回ほどだしたのだが、原因不明だった、なので、今ならわかるなら、今、あの三年前の事故の報告をだしてくれないか？
出せない？じゃ、どうしたら原因究明できるんだい？ベンダーとして責任をとってね..と追いつめたお方がいますね。
で、ごめんなさいということで、筐体の無料提供、ついでにOSもDBMSもあげて(実はリプレース..ww)のコスト削減、しかも以後は再発なしとかあったりする。
>アクティブ-アクティブならまあダウンタイム減らせるでしょうがその場合
HWの問題だとわかる場合には、有効なんだけど、ソフトウェアというかアプリやDBMSがタコだと、アクティブ-アクティブだと共倒れのケースが多かったと思う。
サービスのOS間移動と戻しで戻ったケースもあるけどね。
Re:メモリダンプ取って再起動 (スコア:1, おもしろおかしい)
のんきだな (スコア:1, 興味深い)
サービスは迅速に復旧させる、原因究明もちゃんとやる
両方やらなくちゃあいけないのがエンジニアの辛い所だな
リブートどころの騒ぎではなく… (スコア:1)
ハードリセットしか手がなくなった私が通りますよ。
何?! 障害が起こった??! (スコア:1)
何をやってるんだ。UNIXは「障害が起こる前に shutdown -r now するもの」だよ?!
なんで障害が起こるまで再起動を延期するかな…
fjの教祖様
Re:何?! 障害が起こった??! (スコア:1)
起動と同時にshutdown -r nowするか。延々と再起動・再起動・再起動・…
Re:何?! 障害が起こった??! (スコア:1)
やはり障害が起こる可能性のあるシステムは立ち上げないべきじゃなイカ?
UNIXはサーバ再起動しなくても復旧できる方法は必ずある！ (スコア:1)
Re:UNIXはサーバ再起動しなくても復旧できる方法は必ずある！ (スコア:2)
Unixだと再起動しなくていいというのは、多くの場合、問題となっているプロセス/デーモンが自明で、それらの再起動でサービスを続けられるからでしょ。他のプロセスに影響を与えていることが少ない。画面(X-Window)が固まっても、シリアルなり、SSHなりでログインすれば大抵は(目先の問題は)解決する。
それと、Unixだとコマンドラインが基本で、それのGUI版があるという感じなのでコマンドラインも使いやすい。Windows版だとそれが逆だから、コンソールによる操作はイマイチ。
あと、大抵はWindowsクライアントと比較している気がする。Windowsクライアントで画面が固まってしまうとリセットするしかないことが多いが、Unix系だとクライアントでもコンソール以外にシリアルやsshでも使えるようにセットアップしていることが多いとか。
Re:Windowsでも一緒 (スコア:1)
Re:Windowsでも一緒 (スコア:1)
ええ、一緒ですね。
とにかく対処したって言うために、とりあえずリブート。
Re:Windowsでも一緒 (スコア:2, 参考になる)
>とにかく対処したって言うために、とりあえずリブート。
それ以上に明確な理由で明確に短時間での復旧する手段を提示できたら、そちらを使うだろうね。
代案なき反対が、まさに「リブートはだめ」議論の元にあるわけなんだよね。
「こういう理由／理屈でリブートせずに調べたら判ります、リブートよりサービス影響はありません」というのを具体的に示して、それで実績を積んでから発言したらよいのにね。
リブートで、少なくともその後にサービス戻りが出来た確率は、最近200回で198回。
だめだった２件はサービスのログから原因究明できてしまった。
対して、ダンプとった「おかげ」で理由がわかったのはほとんどなかった。
大概は、残っていたログから判断されたものがほとんど。
後日、再起動したサーバから取得したログで判明したのが数件あったが、リブートしてもしなくてもこれはわかったことになる。
もし、原因究明まで待っていたとしたら、「全部後日なので24h×日数のサービス停止」と「直すのにやはりリブートが必要」で、結局ダメダメな成果しかあげられないというのが結論になるんだよな。
リブートしちゃだめ、じゃ、別のより高確率かつ短時間な方法を提示しないとだめなのだが、それが出来ない癖に言う馬鹿(ソフトウェア開発系に多い)がいてるんですよね。
WinodwsとUNIXの違い (スコア:2, 参考になる)
＞それってUNIXだけでなくWindowsにも当てはまる場合もあるのでは？
Windowsには、「開いているファイルは削除／リネーム出来ない」、「実行中のファイルは改変出来ない」と云う厳しい仕様があるんで、事情が違う。
UNIXの場合は、開いているファイルを削除出来、そのファイルは、クローズされる迄の間、ディレクトリ上には存在しないがファイル自体は存在する扱いを受けて、クローズ時に自動的に消滅する。
結果、内容の違う「元」同名のファイルが複数存在し得るのが仕様。
これが、システムファイル変更時に、Windowsでは再起動が必須だが、UNIXでは必須で無い事も在る理由になって居る。
で、Windowsだと、その仕様上、再起動せずにシステムファイルを変更して調査することは困難。代わりに、「現在存在しないファイル」で実行している可能性が無い。
UNIXだと、起動したままファイルを入れ替えて挙動を調べる事が出来る代わりに、停止した瞬間に消滅するファイルで動作している可能性が在る。
従って、WindowsとUNIXでは、対処法に微妙に違いが出る訳。
特に、UNIXで起動したままのパッチは、一度サービスを停止しないと適用されない可能性が有るから、結構面倒だったりする。
-- Buy It When You Found It --
Re:ちょっと何言ってるかわからないですね (スコア:1)
>ソースを解析できるかどうかの差かなと思いました。
全員がソースを解析できるわけでもないし、ソースを解析できる人員を２４時間はりつかせるのも難しい。
逆に５分１０分のダウンや速度劣化が厳しい環境もあるわけだからね。
CPU負荷があがっちゃって、ログインすらまともにでけへんのや..という状況で「じゃ、時間かけて解析、証券取引はその間中断」とかは、普通ないと思う。
これまで調べるとかいって時間を無駄にしたことがあったりするすると、「調査用にオンライン系で時間を潰すな、ダウンタイムを極小にしろ」ということに一気に意見が傾く。
ミッションのセビリティによって、予めどうするか？を決めていたりするので、過去の実績から判断されるとかね。
ソース読んで、調べては後でやれ、情報収集できていない？じゃ、次は情報収集する機構を組み込んでおけ、ダンプとったけどわかりませんでした？じゃ、ダンプとるのは無駄な場合があるってことでパスしてダウンタイム削減しなさいとか。
Re:ちょっと何言ってるかわからないですね (スコア:1)
一応デバッグシンボルが提供されてるのでWin系でもダンプもある程度は意味が有ったりするかな？
少なくともここらへんのプロセスやらドライバが臭い位の目安には成りうるし、最悪MSに解析依頼という手もありますし。
最低限再起動前に実行中のプロセスリストやら、ハンドルリストは取ってくれるとリソースリーク系か判別しやすくなるので後が楽そうな感じ
Re:リブートよりも (スコア:2)
ですね、間違いない。
Re:復旧優先 (スコア:1)
>だから「リブートすれば復旧するの？」って話はもうさんざん出てるでしょ
じゃ、止めておけと？
Re:復旧優先 (スコア:1)
>リブートかけたらマトモに起動すらできない」っていう状態はあるわけで，「トラブったら，とりあえずリブート」って話は無いと思う．
それが、代案なき反論なんだよね。
サービス／ＯＳが停止しました、調査します、うん、調査分析対応まで５分以内にね...ができるとうれしいな。
Re:いや (スコア:1, 興味深い)
立ち上がらないマシンが少なくとも１台は見つかります。