Bagaimana cara menghindari downtime dengan linux?


13

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.)


1
Apakah server ber-AC berfungsi sebagai mesin yang tidak perlu reboot? Lagi pula, jika tidak ada yang bisa mengaksesnya, Anda tidak perlu me-reboot-nya? ;) - Sebagai contoh, server pemantauan pada pembangkit listrik tenaga nuklir, yang hanya membunyikan alarm jika ada sesuatu yang salah. (Ya saya sadar ini kemungkinan akan menjadi sistem khusus daripada server acak, tetapi saya menggunakan contoh ini hanya untuk menunjukkan bahwa ada saat-saat me-reboot untuk 'pembaruan keamanan' mungkin merupakan ide yang sepenuhnya cerewet.
djsmiley2k TMW

3
@ djsmiley2k Itulah salah satu kasus di mana mesin yang Anda tidak pernah reboot masih tidak memberikan Anda ketersediaan yang cukup. Sebaliknya Anda membutuhkan redundansi.
kasperd

@kasperd ok, jadi sekelompok mesin tidak pernah reboot?
djsmiley2k TMW

3
@ djsmiley2k Jawaban saya atas pertanyaan tersebut sudah mengemukakan alasan saya menganggap sekelompok mesin yang di-reboot satu per satu agar lebih andal daripada yang tidak pernah Anda reboot.
kasperd

2
Apa yang membuat Anda berpikir menghindari downtime sistem individual lebih disukai?
warren

Jawaban:


12

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.


30

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.


Saya menyukai deskripsi risiko Anda; "patched vs booted dengan kernel terbaru" .. Namun, Anda tidak menjawab pertanyaan saya .. yang dapat saya ulangi, apakah ada distro linux yang disertakan dengan 'livepatch' out-of-the-box?
user75126

@ user75126 Saya melihatnya sebagai fitur yang lebih sesuai untuk mesin klien daripada untuk server. Selain itu, menanyakan distribusi mana yang mendukungnya, itu seperti pertanyaan rekomendasi produk. Bagi saya itu terdengar seperti dua alasan mengapa mengulangi pertanyaan seperti itu akan menjadikannya di luar topik untuk situs ini.
kasperd

3
@ user75126 Oracle Ksplice memiliki uji coba gratis, dan tingkat gratis untuk desktop Ubuntu dan Fedora (hanya, tetapi mereka tidak benar-benar menegakkan ini). Masalahnya adalah bahwa membuat tambalan langsung sulit untuk diotomatisasi, dan bahkan bagian yang dapat diotomatisasi juga memakan waktu. Membuat tambalan ini adalah operasi yang relatif padat karya, dan masuk akal bagi perusahaan untuk mengenakan biaya untuk itu. Saya melihat ke dalam apa yang diperlukan untuk membuat tambalan langsung sendiri, dan langsung keluar dari sana. Saya tidak punya waktu seperti itu di hari saya.
Michael Hampton

12
@ user75126 Benar-benar praktik buruk di situs ini untuk mengubah judul dan isi pertanyaan dengan cara yang membatalkan jawaban yang ada. Jika Anda ingin mengajukan pertanyaan yang berbeda, maka ajukan pertanyaan yang berbeda.
Greg Schmit

2
@ user75126 Terima kasih. Saya membaca pertanyaan Anda, dan saya pikir itu bukan jawaban untuk itu. Saya hanya berkomentar mengapa ini adalah layanan berbayar.
Michael Hampton
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.