Как избежать простоев с Linux?

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

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

Существуют ли дистрибутивы / процессы Linux, где обновления / исправления никогда не требуют перезагрузок?

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

На ваш вопрос: «Существуют ли дистрибутивы / процессы Linux, где обновления / исправления никогда не требуют перезагрузок?», Я ничего об этом не знаю, и я очень сомневаюсь, что когда-нибудь будут такие, которые действительно не требуют перезагрузки. В дополнение к комментарию Майкла Хэмптона о том, почему исправление в реальном времени не является готовым решением, исправление в реальном времени также не дает того же результата, что и перезагрузка.

Анекдот, чтобы проиллюстрировать это: я недавно исследовал проблему, когда одна конкретная утилита начала segfaulting на большом количестве машин. Я попытался просмотреть общие библиотеки, которые он использовал, чтобы увидеть, не сломалось ли что-то недавно обновленное; ldd сказал, что это не исполняемый файл (хотя когда я вытащил тот же самый двоичный файл на свой ноутбук, ldd мог видеть зависимости разделяемой библиотеки просто отлично). Я попытался пройти через это в GDB; он вышел из строя еще до того, как добрался до первой инструкции.

Глядя на время ошибки, я обнаружил, что недавно был применен патч Ksplice. Я отказался от патча, и бинарный файл не перешел на segfault, затем добавил его обратно, и он снова начал segfaulting. Перезагрузка на эквивалентно исправленное ядро ​​работала нормально. Это оказался патч для 32-битной поддержки, который ребята из Ksplice применили не совсем корректно. К их чести, они выпустили исправленную заплатку в течение нескольких часов, и она вернулась к правильной работе на нашем автопарке без вмешательства.

Другой пример: исправления Meltdown / Spectre были настолько инвазивны, что команда ядра Ubuntu решила, что оперативное исправление нецелесообразно, и потребовала, чтобы люди перезагрузили свои системы в исправленное ядро, прежде чем снова получать живые исправления.

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

Существует важное различие между высокой доступностью услуги и высокой доступностью отдельной машины.

В большинстве случаев цель состоит в том, чтобы сделать сервис высокодоступным, а доступность отдельных машин является лишь средством достижения этой цели. Однако есть предел того, насколько далеко вы можете достичь цели, улучшая доступность отдельных машин.

Даже если вы можете устранить все простои из-за необходимости обновления программного обеспечения, отдельные машины все равно не будут доступны на 100%. Таким образом, чтобы увеличить доступность сервиса выше доступности отдельных машин, вы должны спроектировать избыточность на более высоком уровне. Последнее предложение вашего вопроса показывает, что по крайней мере в принципе вы это знаете.

Если вы разрабатываете услугу, которая будет более доступной, чем отдельные машины, вам больше не нужно будет добиваться высокой доступности отдельных машин. Таким образом, для высокодоступных сервисов нет необходимости избегать перезагрузок. Вместо этого вы можете пожертвовать некоторой надежностью отдельных машин, чтобы сэкономить средства, которые могут быть направлены на другие области, где вы можете получить гораздо более высокий прирост надежности.

Как только система высокого уровня спроектирована так, чтобы быть надежной в случае сбоя отдельных компонентов оборудования, исправление ядра в реальном времени превращается из преимущества в риск.

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

Однажды у вас может произойти сбой, когда вы думаете, что перезагрузка машины может помочь. Но когда вы перезагружаетесь, вы получаете скрытую ошибку, которая не позволяет машине вернуться в нужное состояние. Активное исправление не единственный способ, которым может происходить такая скрытая ошибка, она может также произойти из-за чего-то такого, как обычная служба, которая была включена вручную и никогда не была настроена на запуск во время загрузки, или была настроена на слишком ранний запуск, так что она не подходит из-за неудовлетворенных зависимостей.

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