Часто обновления программного обеспечения для Ubuntu требуют перезагрузки (что может иметь побочные эффекты, такие как простои).
Я вижу, что в Ubuntu есть https://www.ubuntu.com/livepatch который позволяет обновлять ядро без перезагрузки, однако это платная услуга. А также есть ksplice.
Существуют ли дистрибутивы / процессы Linux, в которых обновления / исправления не требуют перезагрузки?
(Я знаю, что настройка серверов высокой доступности (HA) и использование одноразовых серверов - это лучшие практики, поэтому я не спрашивают о поддержании работоспособности службы, но на реальных серверах.)
Существует важное различие между обеспечением высокой доступности сервиса и высокой доступностью отдельной машины.
В большинстве случаев цель состоит в том, чтобы сделать сервис высокодоступным, а доступность отдельных машин - только средство для достижения этой цели. Однако есть предел того, насколько далеко вы можете достичь цели, улучшая доступность отдельных машин.
Даже если вы сможете сократить время простоя из-за необходимости обновления программного обеспечения, отдельные машины все равно не будут доступны на 100%. Таким образом, чтобы повысить доступность услуги по сравнению с доступностью отдельных машин, вам необходимо разработать резервирование на более высоком уровне. Последнее предложение вашего вопроса показывает, что по крайней мере в принципе вы это знаете.
Если вы проектируете услугу так, чтобы она была более доступной, чем может предоставить отдельная машина, больше не будет необходимости добиваться высокой доступности отдельных машин. Таким образом, для высокодоступных сервисов нет необходимости избегать перезагрузки. Вместо этого вы можете пожертвовать некоторой надежностью отдельных машин, чтобы сэкономить, которая может быть направлена в другие области, где вы можете получить гораздо больший выигрыш в надежности.
Как только система высокого уровня спроектирована так, чтобы быть надежной в случае отказа отдельных аппаратных компонентов, оперативное исправление ядер превращается из преимущества в риск.
Это риск, потому что могут быть тонкие различия между поведением машины, на которую были внесены исправления, и машины, на которой была загружена новейшая версия ядра. Это может привести к скрытой ошибке, которая может вызвать сбой при следующей перезагрузке машины. Этот риск усугубляется перезагрузкой, чтобы все было с чистого листа, которое рассматривается как способ смягчить некоторые простои.
Однажды у вас может произойти сбой, и вы думаете, что перезагрузка машины может помочь. Но при перезагрузке вы сталкиваетесь с скрытой ошибкой, не позволяющей машине вернуться в желаемое состояние. Живое исправление - не единственный способ возникновения такой скрытой ошибки, это также может произойти из-за чего-то столь обыденного, как служба, которая была включена вручную и никогда не была настроена для запуска во время загрузки, или была настроена для запуска слишком рано, так что она не появляется из-за неудовлетворенных зависимостей.
По этим причинам высокодоступный сервис может быть легче достичь с помощью регулярных перезагрузок отдельных машин с достаточно медленной скоростью, чтобы вы могли обнаруживать проблемы и приостанавливать последовательность перезагрузок, как только проблемы действительно возникают.
На ваш вопрос: «Существуют ли дистрибутивы / процессы Linux, в которых обновления / исправления никогда не требуют перезагрузки?», Я не знаю ни о каком, и очень сомневаюсь, что когда-либо будут такие, которые действительно не требуют перезагрузки. В дополнение к комментарию Майкла Хэмптона о том, почему установка исправлений в реальном времени нигде не является стандартной, установка исправлений в реальном времени также не дает того же результата, что и перезагрузка.
Пример, иллюстрирующий это: я недавно исследовал проблему, при которой одна конкретная утилита запускала segfaalt на большом количестве машин. Я попытался посмотреть на общие библиотеки, которые он использовал, чтобы увидеть, не сломалось ли что-нибудь недавно обновленное; ldd сказал, что это не исполняемый файл (даже несмотря на то, что когда я загрузил тот же двоичный файл на свой ноутбук, ldd мог видеть зависимости разделяемых библиотек без проблем). Я пробовал пройти через это в GDB; он потерпел неудачу еще до того, как дошел до первой инструкции.
Посмотрев на время возникновения неисправности, я обнаружил, что недавно был применен патч Ksplice. Я отказался от патча, и двоичный файл не вышел из строя, затем добавил его обратно, и он снова начал сегментировать. Перезагрузка на ядро с аналогичным исправлением работала нормально. Оказалось, что это был патч для 32-битной поддержки, который люди из Ksplice применили не совсем правильно. К их чести, они выпустили исправленный патч в течение нескольких часов, и он вернулся к правильной работе на нашем флоте без вмешательства.
Другой пример: патчи Meltdown / Spectre были настолько агрессивными, что команда разработчиков ядра Ubuntu решила, что установка исправлений в реальном времени непрактична, и потребовала от людей перезагрузки своих систем в исправленное ядро перед повторным получением исправлений в реальном времени.
У нас работает большой парк физических и виртуальных серверов с большим количеством систем Ksplice и Canonical Livepatch. Оба они были намного более надежными, чем многие другие программы, но я все же предпочел бы видеть наши сервисы, разработанные с удобной для перезагрузки архитектурой, чем полагаться на исправления ядра в реальном времени.