На прошлой неделе было довольно много комментариев по поводу статья на слэшдоте о том, нужно ли когда-нибудь перезагружать машины Unix (или Linux). Многие из комментаторов упомянули, что у них есть машины с временем безотказной работы в несколько лет.
Насколько я понимаю, Linux-боксы необходимо довольно часто перезагружать, чтобы применить исправления ядра, особенно связанные с безопасностью (например, ac1db1tch3z эксплойт). Запуск uname -r после «yum update kernel», кажется, показывает, что старое ядро не загружается до перезагрузки.
У меня вопрос: как эти боксы обеспечивают бесперебойную работу в течение нескольких лет, учитывая это? Несколько возможных решений, о которых я подумал
Разумны ли какие-либо из этих объяснений, или я чего-то не понимаю? Есть ли другой способ свести к минимуму два десятка перезагрузок, необходимых за последние два года?
Одно из решений - использовать ksplice.
Если вы используете ядра Ubuntu или CentOS, вы можете подписаться на сервис ksplice.com, где за небольшую плату они предоставят вам специальные образы ядра, которые можно использовать для исправления работающего ядра. Для большинства обновлений перезагрузка не требуется. Довольно проста в использовании и настройке.
Если у вас есть особый опыт, вы можете использовать патчи ksplice для создания собственных включенных ядер без подписки на службу или для нестандартных ядер.
У меня были серверы с периодом безотказной работы более 1 года. Не лучшая практика, потому что с точки зрения безопасности сервер ... некоторые из этих серверов были мастерами баз данных, и мы не могли позволить себе простои.
Я думаю, что безопасность должна быть главной заботой, но есть некоторые реальные ограничения. Если у вас есть роскошный патч, перезагрузите его при необходимости. Не беспокойтесь о времени безотказной работы, лучше перестраховаться.
Я бы посоветовал всегда перезагружать сервер после серьезного обновления, чтобы убедиться, что он снова заработает, вы не хотите попадать в ситуацию после неожиданной перезагрузки.
В нашем магазине существует довольно хорошая политика в отношении установки исправлений / перезагрузки. Важность обеспечения безопасности перевешивает статистику времени безотказной работы. У нас есть регулярная процедура установки исправлений, которая помогает нам не попасть в ситуацию «Плохие вещи».
Наш переход к кластерным вычислениям помог обеспечить бесперебойную работу важных вещей, и работа по настройке определенно того стоила.
Если время безотказной работы имеет значение для обслуживания клиентов, вам следует обратить внимание на балансировку нагрузки и кластеризацию. Вы можете поддерживать безопасную и избыточную среду, а также время безотказной работы.
Если вы жертвуете безопасностью ради права хвастовства, вы, вероятно, оказываете медвежью услугу своим клиентам.
Я думаю, что единственный раз, когда нужно перезагружать Linux-машину, это заменить ядро. У меня есть несколько машин, работающих более 2 лет, но я обслуживаю их по принципу «Если не сломалось, не чини», и именно так я добиваюсь безотказной работы. Конечно, если ваши серверы подвержены внешним угрозам, вам необходимо периодически применять исправления безопасности, а для некоторых из них потребуется новое ядро. Я не знаю, как сделать это надежно без перезагрузки машины. Здесь могут быть некоторые уловки, но есть большая вероятность, что вы поставите под угрозу стабильность в процессе, и вам нужно будет перевести машину в однопользовательский режим. Технически вы достигнете времени безотказной работы, но машина не будет доступна конечным пользователям в это время, так в чем смысл?
Если время безотказной работы действительно критично для вас, вас может заинтересовать некоторая форма решения HA / кластеризации, когда вы можете перезагрузить один узел кластера, не влияя на доступность всей системы. В противном случае просто перезагрузитесь.
Минимизация времени простоя более важна, чем минимизация перезагрузок. подобно Самир сказал, что не успевать за обновлениями ядра - это плохо. У меня есть возможность иметь балансировщики нагрузки (в основном потому, что большая часть того, что делает мой работодатель, находится в облаке), поэтому мы выполняем скользящие обновления - что позволяет мне обновлять AppServer-1, вытаскивать его из балансировщика нагрузки, перезагружаться, делать убедитесь, что все в порядке, скажите LB: «Хорошо, чувак, AS-1 готов!», затем продолжите работу с остальными машинами.
Чем меньше вы установили, тем меньше вероятность, что вам понадобится что-то исправлять. Сведение к минимуму вашей установки (или, как мне нравится думать: поверхности атаки) может иметь большое значение. Это касается не только пакетов, но и конфигураций ядра. В наши дни большинство дистрибутивов скомпилированы со всеми возможными модулями, что далеко не оптимально. Пользовательские ядра могут быть проблематичными в обслуживании, но они также могут окупиться, поскольку вы точно знаете, что там, и еще больше снижаете вероятность необходимости исправления.
(Раскрытие информации: я работаю в Canonical)
В частности, для Ubuntu Canonical теперь предлагает исправления ядра в реальном времени 16.04.
При этом используется технология live patching в исходном ядре Linux, начиная с версии 4.0.