Як уникнути простоїв з Linux?

Часто для оновлення програмного забезпечення для Ubuntu потрібні перезавантаження (які можуть мати такі побічні ефекти, як час простою).

Я бачу, що Ubuntu має https://www.ubuntu.com/livepatch, який дозволяє оновлювати ядро ​​без перезавантажень, однак це платна послуга. Також є ksplice .

Чи є дистрибутиви / процеси Linux, де оновлення / виправлення ніколи не потребують перезавантаження?

(Я знаю, що налаштування серверів із високою доступністю (HA) та наявність одноразових серверів - найкраща практика - тому я не прошу про те, як підтримувати сервіс, а на фактичних серверах.)

На ваше запитання "Чи існують дистрибутиви / процеси Linux, де оновлення / патчі ніколи не потребують перезавантаження?", Я не знаю жодного, і я дуже сумніваюся, що коли-небудь знайдуться справді без перезавантаження. На додаток до коментаря Майкла Хемптона про те, чому виправлення "патч" не є вичерпним досвідом, патч "live" також не дає такого ж результату, як перезавантаження.

Анекдот для того, щоб проілюструвати це: я нещодавно досліджував проблему, коли одна конкретна утиліта почала сегментацію на великій кількості машин. Я спробував розглянути спільні бібліотеки, які раніше використовував, щоб побачити, чи щось порушено нещодавно оновлене; ldd сказав, що це не виконується файл (навіть коли я тягнув той самий двійковий файл до свого ноутбука, ldd міг добре бачити залежність від спільної бібліотеки). Я спробував переступити через нього в gdb; воно зафіксувалося перед тим, як потрапити до першої інструкції

Переглядаючи терміни несправності, я виявив, що нещодавно застосовано патч Ksplice. Я створив резервну копію виправлення, і двійковий файл не сегментувався, потім додав його знову, і він знову почав сегментувати. Перезавантаження на еквівалентно виправлене ядро ​​спрацювало чудово. Це виявилося патчем для 32-бітної підтримки, яку люди Ksplice застосували не зовсім коректно. На їхню честь, вони видали фіксований патч протягом декількох годин, і він знову працював правильно на нашому флоті без втручання.

Інший приклад: патчі Meltdown / Spectre були настільки інвазивними, що команда ядра Ubuntu вирішила, що живий патч непрактичний і вимагає від людей перезавантажувати свої системи у фіксованому ядрі, перш ніж знову отримувати живі патчі.

Ми працюємо з великим парком фізичних і віртуальних серверів на роботі з великою кількістю систем Ksplice і Canonical Livepatch. Вони обидва були набагато надійнішими, ніж багато іншого програмного забезпечення, але я все одно вважаю, що наші сервіси створені з зручною для перезавантаження архітектурою, ніж покладатися на живу виправлення ядра.

Існує важлива відмінність між тим, щоб зробити послугу високодоступною і зробити індивідуальну машину високо доступною.

У більшості випадків мета - зробити послугу високодоступною, а наявність окремих машин є лише засобом для досягнення цієї мети. Однак існує обмеження в тому, наскільки далеко до мети ви можете досягти, покращуючи доступність окремих машин.

Навіть якщо ви зможете зняти всі простої через необхідність оновлення програмного забезпечення, окремі машини все одно не будуть доступні на 100%. Таким чином, щоб збільшити доступність послуги вище наявності окремих машин, ви повинні розробити надмірність на більш високому рівні. Останнє речення вашого запитання показує, що ви принаймні в принципі це знаєте.

Якщо ви проектуєте послугу, яка буде доступнішою, ніж можуть поставляти окремі машини, більше немає тиску для досягнення високої доступності окремих машин. Таким чином, для високодоступних послуг не потрібно уникати перезавантажень. Натомість ви можете пожертвувати деякою надійністю окремих машин, щоб заощадити, які можна досягти в інших сферах, де ви можете отримати набагато більші виграші в надійності.

Після того, як система високого рівня стане надійною у випадку відмови окремих апаратних компонентів, жива виправлення ядер змінюється від переваги до стану ризику.

Це ризик, оскільки можуть бути незначні відмінності між поведінкою машини, яка була виправлена ​​в режимі реального часу, і машини, завантаженої з новітньою версією ядра. Це може ввести приховану помилку, яка може спричинити аварію при наступному перезавантаженні машини. Цей ризик посилюється перезавантаженням, щоб отримати чистий аркуш як метод зменшення деяких відмов.

Одного разу у вас може виникнути аварія, де ви думаєте, що перезавантаження машини може допомогти. Але під час перезавантаження ви потрапляєте на приховану помилку, що запобігає поверненню машини в потрібному стані. Виправлення в прямому ефірі - не єдиний спосіб, коли може статися така прихована помилка, вона також може статися через щось настільки приземлене, як послуга, яка була ввімкнена вручну і ніколи не налаштована для запуску під час завантаження, або налаштована для запуску занадто рано, щоб вона не з'являється через незадоволених залежностей.

З цих причин високодоступний сервіс може бути легше досягти регулярними перезавантаженнями окремих машин досить повільною швидкістю, що ви можете виявити проблеми та призупинити послідовність перезавантажень, коли проблеми не трапляються.