Bagaimana cara menghindari downtime dengan linux?

Pembaruan perangkat lunak yang sering ke Ubuntu memerlukan reboot (yang dapat memiliki efek samping seperti downtime).

Saya melihat Ubuntu memiliki https://www.ubuntu.com/livepatch yang memungkinkan pembaruan kernel tanpa reboot, bagaimanapun, ini adalah layanan berbayar. Ada juga ksplice .

Apakah ada distribusi / proses Linux di mana upgrade / patch tidak pernah membutuhkan reboot?

(Saya tahu menyiapkan server ketersediaan tinggi (HA) dan memiliki server sekali pakai adalah praktik terbaik - jadi saya tidak bertanya tentang menjaga layanan, tetapi pada server yang sebenarnya.)

Untuk pertanyaan Anda, "Apakah ada distribusi / proses Linux di mana upgrade / patch tidak pernah memerlukan reboot?", Saya tidak mengetahui adanya, dan saya sangat ragu bahwa akan ada yang benar-benar bebas reboot. Selain komentar Michael Hampton tentang mengapa tambalan langsung bukan pengalaman yang tidak biasa di mana pun, tambalan langsung juga tidak mencapai hasil yang sama dengan me-reboot.

Sebuah anekdot untuk mengilustrasikan ini: Saya baru-baru ini menyelidiki masalah di mana satu utilitas tertentu mulai melakukan segfault pada sejumlah besar mesin. Saya mencoba melihat perpustakaan bersama yang digunakan untuk melihat apakah ada sesuatu yang baru saja ditingkatkan telah merusaknya; ldd mengatakan itu bukan executable (walaupun ketika saya menarik biner yang sama ke laptop saya, ldd bisa melihat dependensi shared library dengan baik). Saya mencoba melangkah melalui gdb; itu segfault sebelum bahkan sampai ke instruksi pertama.

Melihat waktu kesalahan, saya menemukan bahwa patch Ksplice baru-baru ini diterapkan. Saya mundur tambalan dan biner tidak segfault, kemudian menambahkannya kembali, dan mulai segfaulting lagi. Mem-boot ulang ke kernel yang setara-patched berfungsi dengan baik. Ternyata menjadi tambalan untuk dukungan 32-bit yang belum diterapkan dengan benar oleh orang-orang Ksplice. Untuk kredit mereka, mereka mengeluarkan tambalan tetap dalam beberapa jam dan itu kembali berfungsi dengan benar pada armada kami tanpa intervensi.

Contoh lain: tambalan Meltdown / Spectre begitu invasif sehingga tim kernel Ubuntu memutuskan bahwa tambalan langsung tidak praktis dan mengharuskan orang untuk mem-boot ulang sistem mereka ke dalam kernel tetap sebelum menerima tambalan langsung lagi.

Kami menjalankan armada besar server fisik dan virtual di tempat kerja, dengan sejumlah besar sistem Ksplice dan Canonical Livepatch. Mereka berdua jauh lebih andal daripada banyak perangkat lunak lain, tapi saya masih lebih suka melihat layanan kami dirancang dengan arsitektur yang ramah-reboot daripada mengandalkan patching kernel live.

Ada perbedaan penting antara membuat layanan sangat tersedia dan membuat mesin individual sangat tersedia.

Dalam kebanyakan kasus, tujuannya adalah untuk membuat layanan tersebut sangat tersedia, dan ketersediaan masing-masing mesin hanyalah sarana untuk mencapai tujuan itu. Namun ada batasan seberapa jauh ke arah tujuan yang bisa Anda dapatkan dengan meningkatkan ketersediaan masing-masing mesin.

Bahkan jika Anda bisa menghilangkan semua downtime karena perlu memperbarui perangkat lunak, masing-masing mesin tetap tidak akan 100% tersedia. Dengan demikian untuk meningkatkan ketersediaan layanan di atas ketersediaan masing-masing mesin, Anda harus merancang redundansi di tingkat yang lebih tinggi. Kalimat terakhir dari pertanyaan Anda menunjukkan bahwa setidaknya pada prinsipnya Anda tahu ini.

Jika Anda mendesain layanan agar lebih tersedia daripada yang dapat diberikan oleh mesin individual, tidak ada tekanan lagi untuk mencapai ketersediaan tinggi masing-masing mesin. Jadi untuk layanan yang sangat tersedia tidak perlu menghindari reboot. Alih-alih, Anda dapat mengorbankan beberapa keandalan masing-masing alat berat untuk melakukan penghematan yang dapat dilakukan terhadap bidang lain di mana Anda bisa mendapatkan perolehan keandalan yang jauh lebih tinggi.

Setelah sistem tingkat tinggi dirancang untuk dapat diandalkan jika komponen perangkat keras individu gagal menambal langsung perubahan kernel dari menjadi keuntungan menjadi risiko.

Ini risiko karena bisa ada perbedaan halus antara perilaku mesin yang tambalan langsung dan mesin yang di-boot dengan versi kernel terbaru. Ini dapat menyebabkan bug laten yang dapat menyebabkan pemadaman saat mesin di-boot ulang. Risiko ini diperbesar dengan me-reboot untuk mendapatkan batu tulis yang bersih dilihat sebagai metode untuk mengurangi beberapa gangguan.

Suatu hari Anda bisa mengalami pemadaman di mana Anda pikir me-reboot mesin mungkin membantu. Tetapi ketika Anda reboot Anda terkena bug laten yang mencegah mesin kembali dalam kondisi yang diinginkan. Live patching bukan satu-satunya cara bug laten seperti itu bisa terjadi, itu bisa juga terjadi karena sesuatu yang biasa seperti layanan yang diaktifkan secara manual dan tidak pernah dikonfigurasi untuk memulai saat boot, atau telah dikonfigurasi untuk memulai terlalu dini sehingga gagal muncul karena dependensi yang tidak terpenuhi.

Karena alasan itu, layanan yang sangat tersedia mungkin sebenarnya lebih mudah dicapai dengan reboot reguler dari masing-masing mesin pada tingkat yang cukup lambat sehingga Anda dapat mendeteksi masalah dan menjeda urutan reboot setelah masalah terjadi.