У меня есть много серверов Linux (SUSE 9 и 10), используемых для запуска веб-сервисов, которые предоставляют данные в большие вычислительные сетки. В последнее время у нас возникли некоторые труднообъяснимые сбои (например, журналы оборудования и программного обеспечения не показывают никаких очевидных ошибок), и мы начинаем задаваться вопросом, является ли длительное время безотказной работы (обычно 200-300 дней) проблемой. Учитывая, что эти серверы сильно загружены, следует ли мне подумать о регулярном цикле перезагрузки?
Вы должны перезагрузиться после обновления ядра (если вы не используете KSplice), все остальное не является обязательным. Лично я перезагружаюсь ежемесячно во время периода обслуживания, чтобы убедиться, что сервер и все службы вернутся, как ожидалось. Таким образом, я могу быть достаточно уверен, что если мне придется выполнить внеплановую перезагрузку (то есть критическое обновление ядра), что система вернется в нормальное состояние. Автоматический мониторинг серверов и сервисов (например, Nagios) также помогает этому процессу (перезагрузитесь, посмотрите, как загорелся красный свет, а затем, надеюсь, все снова загорится зеленым).
P.S. если вы регулярно перезагружаетесь, вам нужно убедиться, что вы настроили свои проверки fsck (т.е. максимальное количество подключений между проверками соответствующим образом, в противном случае быстрая двухминутная перезагрузка может занять 30 минут, если сервер запускает fsck с парой терабайт данных. обычно устанавливают мой счетчик монтирования на 0 (tune2fs -c 0) и интервал между проверками до 6 месяцев или около того, а затем вручную принудительно запускают fsck каждый раз и сбрасывают счетчик.
На самом деле я перезагружаю свои серверы довольно регулярно, каждый раз, когда вносятся серьезные изменения в конфигурацию. Важно знать, что в случае возникновения чрезвычайной ситуации программное обеспечение сервера подойдет без проблем. Последнее, что вам нужно, - это оказаться в положении, когда вы пытаетесь восстановиться после сбоя, но вам приходится возиться с конфигурацией вашего сервера, потому что вы не проверили его полностью при настройке.
Серверы Linux никогда не нужно перезагружать, если вы абсолютно необходимо изменить работающую версию ядра. Большинство проблем можно решить, изменив файл конфигурации и перезапустив службу с помощью сценария инициализации.
Вам нужно следить за перезагрузками ... если вы изменили что-либо «на лету», не отразив ваши изменения в файле конфигурации службы, эти изменения не будут применены после перезагрузки.
Однако я обычно перезагружаюсь после запланированных обновлений системы. Обычно в этом нет необходимости, но я делаю их, когда никого нет в офисе, так почему бы и нет? В любом случае, когда я приступаю к обновлению, часто происходит обновление ядра.
На самом деле не требуется, обработка памяти linux отличная. Но если у вас такое время безотказной работы, вы, вероятно, используете ядра с известными уязвимостями - вы можете посмотреть это.
Я думаю, вам следует перезагрузиться, если было недавнее обновление ядра ИЛИ обновление libc. Многие вещи связаны с libc, и на самом деле невозможно полностью выгрузить эту библиотеку из памяти и заменить ее новой версией, если вы не выполните перезагрузку.
Например, даже базовые вещи, такие как / bin / ls и другие вещи в / bin, используют libc. Если вы просто запускаете консоль и используете bash, вы используете libc.
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
/lib/ld-linux.so.2 (0xb804b000)
$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
libc.so.6 => /lib/libc.so.6 (0xb7de7000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
/lib/ld-linux.so.2 (0xb7f61000)
libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)
И да, если вы измените файлы в /etc/init.d, которые каким-то образом повлияют на запуск, я бы порекомендовал перезагрузку. Вы же не хотите обнаруживать, что допустили небольшую ошибку в файле запуска, когда вам нужно быстро все снова запустить.
Если сервер не перезагружался много дней, это фактически означает, что нет никакого способа быть уверенным, что он снова заработает должным образом. Опять же, это связано с тем, что на нем могло быть изменено множество файлов конфигурации, и никто не перезагружал его долгое время, чтобы убедиться, что он появится. Также, если на сервере должно быть много обновлений, и вы долгое время не перезагружались, перезагрузитесь. перед вы применяете обновления, иначе, если есть проблема, вы не можете быть уверены, что она была вызвана ошибкой конфигурации давным-давно или новыми обновлениями, которые вы применили.
Наконец, если вы перезагрузите критически важный сервер через очень долгое время, fsck может означать, что вам придется очень долго ждать, пока он снова не заработает. Вы можете использовать tune2fs, чтобы избежать этого, но я полагаю, что рекомендуется регулярно проверять его. Вот почему вы не должны находиться в положении, когда вы зависите только от одного сервера, и если это произойдет, весь ваш сайт исчезнет. У вас должен быть еще один в режиме ожидания.
Еще одна вещь, на которую следует обратить внимание во время этого неожиданного простоя, - это посмотреть, как именно память и процессор используются и какими программами. top должен уметь определять, какие процессы являются виновниками потери ресурсов, а затем уметь управлять ими напрямую. Другая идея - инициализировать задание cron для завершения работы и перезапуска процессов по определенному расписанию.
Неплохая идея - перезагрузиться, если это было так долго, чтобы вы могли запустить проверку диска (fsck) в корневом разделе. Ваш аргумент может заключаться в том, что это помогает обеспечить целостность данных.
Правильно запущенный сервер Linux требует перезагрузки только для обновлений ядра. То же самое не всегда можно сказать о некоторых программах - например, мне иногда приходится перезапускать apache2 или mailman.
В моей инфраструктуре есть два сайта данных: альфа (где операции происходят ежедневно) и бета (сайт резервного копирования на случай, если в альфа-версии что-то пойдет не так). Хотя в настоящее время это не так, я настаиваю на том, чтобы запланировать простой на альфа-сайте каждые 6 месяцев, чтобы мы могли запускать все службы из бета-версии.
Это позволит достичь двух целей. Во-первых, это докажет, что наш сайт аварийного восстановления полностью жизнеспособен. Во-вторых, у меня будет неделя времени на то, чтобы удалить накопившийся мусор на этапе альфа.
Как бы то ни было, я не перезагружаю свои серверы так часто, как следовало бы. Я согласен с другими авторами, которые сказали, что важно знать, что ваши серверы восстановятся, когда они вам понадобятся. Вы не хотите «думать», что они будут, только чтобы узнать, что вы что-то изменили и сделали это неправильно или не задокументировали это.
Вы можете дополнительно написать несколько скриптов, которые будут проверять (насколько это возможно), будет ли текущее состояние вашей машины состоянием машины после перезагрузки.
Я имею в виду ...
/etc/init.d/* /etc/fstab /etc/mtab) имеют соответствующую запись в /etc/fstab/etc/fstab также в настоящее время установлены.Это, конечно, не полная проверка, но она снижает риск возникновения проблем после перезагрузки.
В дополнение к этому вы должны (imo) установить политику для обновлений пакетов сервера в некотором разумном порядке, скажем, 1 группа в неделю ...
Также имейте общий план, например «Все серверы будут проходить полное обновление ОС каждые 6 месяцев».
Зависит от задач, запущенных на сервере. Для некоторых виртуальных серверов мы часто используем перезагрузку вместо перезапуска apachectl, и это занимает на 5-10 секунд больше. Но некоторые тяжеловесные машины перезагружаются несколько раз в год, и за процессом следит вся команда администраторов.