Преимущества и препятствия регулярных перезагрузок сервера [закрыто]

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

каковы мнения людей, положительные и отрицательные моменты, касающиеся политики?

8 ответов


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

кто-то не потрудился настроить критическую службу для автоматического запуска при загрузке. Или порядок предоставления услуг неправильный. Или кто-то обновил библиотеки, добавил/удалил программное обеспечение и т. д. и исполняемый файл больше не работает (он был запущен со старыми библиотеками и продолжен используя их; теперь он получает динамическую ошибку компоновщика). Или оказывается услуга зависит от B и обслуживания B зависит от службы (упс).

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

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


Это глупая политика.

вот почему:

  • Если вам нужно перезагрузить сервер еженедельно (и каким-то образом это добавляет стабильности вашей инфраструктуры), вы покрываете реальную проблему с сервером или его программным обеспечением. Утечка памяти? Плохой водитель? Решение этих проблем заключается в исправить их, не прикрывайте их ленивой политикой.

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

  • серверы баз данных кэшируют много информации в ОЗУ. При перезагрузке сервера этот кэш становится пустым и очень холодным. Предполагая, что у вас есть типичный шаблон использования, холодный пустой кэш приведет к низкой производительности для пользователей при попытке их запросов после перезагрузки. Это мая также увеличьте время, необходимое для выполнения некоторых типов обслуживания, таких как резервные копии, потому что диск может потребоваться чтобы получить доступ больше.

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

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

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


извиняюсь за то, что отряхнул старую нить.

Я думаю, что все упускают суть, особенно жесткая перезагрузка? Я лучше продам своего коммодора! Никс админ.

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

но если он там, вы можете использовать его.

лично я думаю, что квартальная перезагрузка очень хорошая идея-это может дать вам голову на проблемы (аппаратное и программное обеспечение), и, как наиболее дальновидно другой плакат указал, делает вас в курсе изменений, которые предотвращают плавный запуск, которые становятся очевидными только после перезагрузки. Вместо того, чтобы ситуация возникла после отключения питания 4hr, когда вы берете еще 2 часа, чтобы поднять свою коробку, становится очень неловко....

есть и другие плюсы..

  • Он получает управление раньше перезагружается, и у вас есть их уверенность, когда вам действительно нужна перезагрузка (например, физически перемещая ее). Если вы никогда не перезагрузите коробку, ваш менеджер будет чертовски нервничать, когда вы говорите, что она нуждается в перезагрузке после 4yrs и без простоя.

  • вы сами привыкаете к перезагрузкам и знаете, что может\не так, когда он отключен.

  • вы знаете, сколько времени занимает перезагрузка, поэтому, когда он возвращается и занимает 10 минут дольше, чем обычно, вы прямо в бревна.

  • Если завтра вас сбивает автобус, есть текущая (не 4yr старая) документация о том, что происходит при перезагрузке (предполагая, что вы хороший администратор и записываете вещи)

  • перезагрузка 30 минут в квартал хорошо вписывается в 99.9% uptime SLA.

  • наконец, он очищает пресловутую паутину.

чтобы ответить на некоторые вопросы против регулярных перезагрузка..

  • тот, кто скрывает плохой драйвер\утечку памяти и т. д., веселый. Как вы знаете, что это утечка памяти\плохой драйвер, если вы не перезагрузите сервер? Не только это, но что, если вам не удастся исправить это в запланированное время простоя? Если у вас есть еженедельное запланированное окно, это не проблема! Попробуй еще раз на следующей неделе....

  • система уведомлений - если у вас есть запланированное окно, вы можете установить запланированное исключение. Если ваш software\script этого не делает, тогда я предлагаю современное программное обеспечение\лучшее написание скриптов.

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

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

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

Edit:

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

перезагрузка как метод решения проблемы на сервере-плохой sysadmin. Ничего не изучается, и это тратит драгоценное время людей и (справедливо) понижает мнение руководства о вас.

моя точка зрения

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

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


наши серверы-все серверы Linux на работе, и мы никогда не перезагружаемся и не имели никаких проблем. Я согласен, что это хак в лучшем случае, и я также думаю, что это, вероятно, имеет какое-то отношение к первому ответу, который люди всегда дают при поддержке Windows: "вы перезагрузили компьютер?"

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

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


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

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

Я помню делая это для серверов в ферме Citrix, в конце концов они перезагружались каждую ночь с полусложным скриптом, ожидающим выхода пользователей из системы, блокировкой Логинов на определенных серверах, а затем перезагрузкой бесплатных. Причиной было старое клиентское приложение 16bit 4GL, от которого мы просто не могли избавиться, что имело тенденцию разорвать общую отзывчивость пользователей после нескольких дней работы.

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


это хак действительно, но это может быть самый эффективный Хак. Это проблема типа 80:20, где вы можете решить 80% проблемы с 20% усилий. Если вы можете пережить время простоя или время простоя стоит вам меньше, чем на самом деле исправление основной причины, то это хорошее решение. Мне лично не нравится, но это только потому, что это не чистое решение.


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

несмотря на то, что серверы должны работать "24x7", они действительно отключены по крайней мере на несколько минут каждый день.

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