Linuxでダウンタイムを避ける方法は？

Ubuntuのソフトウェアアップデートでは、再起動が必要になることがよくあります（ダウンタイムなどの副作用が発生する可能性があります）。

Ubuntuにはhttps://www.ubuntu.com/livepatchがあり、再起動せずにカーネルを更新できますが、これは有料サービスです。kspliceもありますます。

アップグレード/パッチが再起動を必要としないLinuxディストリビューション/プロセスはありますか？

（私は、高可用性（HA）のサーバを設定し、使い捨てのサーバーを持っているベストプラクティスを知っている-私はせないサービスを追いついについて尋ね、実際のサーバー上で。）

「アップグレード/パッチが再起動を必要としないLinuxディストリビューション/プロセスはありますか？」という質問に、私は何も知らず、本当に再起動不要なものがあるのか​​非常に疑っています。なぜライブパッチを適用してもすぐに使えるエクスペリエンスではないというマイケルハンプトンのコメントに加えて、ライブパッチを適用してもリブートと同じ結果にはなりません。

これを説明する逸話：最近、ある特定のユーティリティが多数のマシンでセグメンテーション違反を始めた問題を調査しました。最近アップグレードしたものが壊れているかどうかを確認するために使用していた共有ライブラリを調べてみました。lddは、それが実行可能ファイルではなかったと言いました（同じバイナリをラップトップに引っ張っても、lddは共有ライブラリの依存関係をうまく見ることができました）。gdbでステップスルーしてみました。最初の命令に到達する前にセグメンテーション違反が発生しました。

障害のタイミングを見ると、Kspliceパッチが最近適用されたことがわかりました。私はパッチをバックアウトしましたが、バイナリはセグメンテーション違反を起こさなかったので、再度追加し、再びセグメンテーション違反を始めました。同等にパッチされたカーネルでの再起動は正常に機能しました。それは、Kspliceの人々がまったく正しく適用していなかった32ビットサポート用のパッチであることが判明しました。彼らの功績として、彼らは数時間以内に修正パッチを発行し、介入なしに艦隊で正しく動作するように戻った。

別の例：Meltdown / Spectreパッチは非常に侵襲的であったため、Ubuntuカーネルチームはライブパッチを適用することは非実用的であり、ライブパッチを再度受け取る前にシステムを固定カーネルで再起動する必要があると判断しました。

KspliceシステムとCanonical Livepatchシステムの両方を備えた、多数の物理サーバーと仮想サーバーを職場で実行しています。どちらも他の多くのソフトウェアよりもはるかに信頼性が高くなっていますが、カーネルのライブパッチを当てるよりも、再起動しやすいアーキテクチャで設計されたサービスを見たいと思います。

サービスを高可用性にすることと、個々のマシンを高可用性にすることには重要な違いがあります。

ほとんどの場合、目標はサービスの可用性を高めることであり、個々のマシンの可用性はその目標を達成するための手段にすぎません。ただし、個々のマシンの可用性を改善することで目標に到達できる範囲には制限があります。

ソフトウェアを更新する必要があるためにすべてのダウンタイムをなくすことができたとしても、個々のマシンはまだ完全には利用できません。したがって、個々のマシンの可用性よりもサービスの可用性を高めるには、より高いレベルで冗長性を設計する必要があります。あなたの質問の最後の文は、少なくとも原則としてこれを知っていることを示しています。

個々のマシンが提供できるよりも可用性の高いサービスを設計すれば、個々のマシンの高可用性を実現するプレッシャーはなくなります。したがって、可用性の高いサービスの場合、再起動を避ける必要はありません。代わりに、個々のマシンの信頼性を犠牲にして節約することで、信頼性を大幅に向上させることができる他の分野に割り当てることができます。

個々のハードウェアコンポーネントが失敗した場合に、高レベルのシステムが信頼できるように設計されると、カーネルのライブパッチ適用は、利点からリスクへと変化します。

ライブパッチが適用されたマシンと最新のカーネルバージョンで起動されたマシンの動作には微妙な違いがあるため、リスクがあります。これにより、潜在的なバグが発生する可能性があり、次回のマシンの再起動時に停止する可能性があります。このリスクは、再起動することで増幅され、一部の停止を緩和する方法としてクリーンスレートが表示されます。

ある日、マシンの再起動が役立つと思われる停止が発生する可能性がありました。しかし、再起動すると、潜在的なバグに見舞われ、マシンが目的の状態に戻ることができなくなります。ライブパッチは、このような潜在的なバグが発生する唯一の方法ではありません。サービスのようなありふれたものが手動で有効にされていて、起動中に起動するように設定されていないか、起動が早すぎるように設定されているために発生する可能性があります依存関係が満たされていないために起動できません。

これらの理由により、個々のマシンを定期的に再起動することで、問題を検出し、問題が発生したときに再起動シーケンスを一時停止できるほど、可用性の高いサービスを実際に簡単に実現できます。