アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
さぁて (スコア:1, 興味深い)
Re:さぁて (スコア:1, 参考になる)
呼を維持したままのバージョンアップって交換系には必須だからねぇ．
まだ，実験段階だろうけど．
Re:さぁて (スコア:1, 参考になる)
すべてのハードウェアは2重化されているので、
呼を維持したままでも予備系の電源を落としてすっかり入れ替えることができる。
片方が終わったら予備／運用を切り替えてもう一方の入れ替え。
Re:さぁて (スコア:1)
ソフト更新で予備系を止めると言うことは、運用系障害発生時に予備系に切り替えることが出来なくなると言うことです
呼を維持したままできるとは言え、数分止まれば新聞沙汰の交換系はその交換作業時の障害を懸念し極力敬遠されるのであ？
小さな修正
Re:さぁて (スコア:0)
Re:さぁて (スコア:1)
２－３命令のバグ修正(できればパッチ)と、大規模改修(普通予備系止めてファイル更新)と同一手順って事はないでしょう
修正規模と危険性を考慮してどっちでやるか選んでませんか？
小規模修正時の場合は、系切り替え&切り替え作業時中の障害発生対応ができない
Re:さぁて (スコア:0)
正>小規模修正時の場合は、系切り替え&ファイル更新中の障害発生対応ができない&作業時間の長いファイル更新(FUP)を
以上に訂正
#訂正のみなのでAC
Re:さぁて (スコア:0)
ハードを二重化しても2つのシステムが同時に落ちる危険性は0ではない。
障害発生の確率はゼロには出来ない。コストと危険性をはかりにかけて、折り合うところで妥協する。
現状は二重化されたシステムが同時に障
Re:さぁて (スコア:1)
>また、予備系メンテナンスの間に運用系が障害を起こす可能性も非常に低いということで、無視される。
いや、だからその予備系の停止時間を短くする&なくすためのパッチでしょ？
数時間かかる&改修影響が大きい全FUPより、数分で終わる&改修箇所が極小のパッチのが良い場合も有るって事を言いたいんだけど...
まぁパッチは小手先の技術でもあるので、パッチの作成品質と作業時間の予備系停止時間の危険度を測りにかけて全部FUPで更新するようになったのかなぁ～と思ったんだけど、実際はどうなんかねぇ(苦笑)
#実際やってるしと言ったACと同一じゃないかもしれないことはわかっているので疑問系(苦笑)
Re:さぁて (スコア:1)
>また、予備系メンテナンスの間に運用系が障害を起こす可能性も非常に低いということで、無視される。
「非常に低いけど、その危険性すら極力極小に持って行く努力」をしていたのが交換機系のNTTだったんだけど、体質変わったのかな？
でもそれならLinuxに盛り込んだパッチ機能は開発すらしないだろうし
まぁACさんたちがNTT関係者の中の人って保証はないんだけどね
Re:さぁて (スコア:0)
もとからそんな体質ではないですよ（苦笑）
障害発生率も目標値をきめてそれをクリアしている仕様なら
Re:さぁて (スコア:1)
いやそれならこの機能なんで作ったんでしょうね
すべて２系統FUPでやるなら、データーの不整合&パッチの品質維持を考えるとこの機能無駄なわけで(苦笑)
多重化出来ないサーバーの為と言う事も考えられますがパッチの性質上、FUPより危険な部分も存在します
その危険性をわかってない人が、逆にシングルなマシンでパッチを使うのは復旧手段がない分結構リスキーに思えます
判定分直す位なら問題ないとは思いますが、このツール関数ごと変更ですから、データーの取り扱い変更を含めた無茶なパッチを作成しそうな気も....
#無論そのデーターが該当関数で閉じて居れば問題ないんですけどね
#しかしこのツール、関数自体の入出力が変わった場合、呼び元の処理のパッチも全部作成するのかな？