Что будет если перезагрузить сервер
Как перезагрузить сервер?
Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.
Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.
В этой статье: что мешает серверу перезагрузиться и как ему помочь.
Начнём с теории ребута.
При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.
Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.
Новые системы инициализации (собственно, не стесняемся — остался только systemd) дают некий таймаут (обычно 120 или 180 секунд) на сохранение данных, после чего завершают процесс силком. Помимо остановки демонов, отмонтируются файловые системы (то есть скидываются все блочные кеши), останавливаются iscsi target’ы (тоже с скидыванием кеша), и т.д. и т.п. При том, что время шатдауна получается неопределённо долгим, оно всё таки конечно. Плюс, есть хоть какая-то надежда на правильное завершение всех демонов, скидывание файловых кешей и т. д.
Таким образом, на здоровой системе правильный ответ на вопрос «как перезагрузиться» — выполнить команду reboot. В ряде случаев — даже единственный правильный (поправка: если в графическом интерфейсе сделать «reboot», то desktop environment будет думать, что это ребут аварийный — для перезагрузки из графического режима надо использовать «reboot» в интерфейсе DE).
Что может пойти не так при «обычном ребуте»? Ну, во-первых, какой-то из процессов-демонов может начать «тупить» — см выше.
Чем это чревато? Неотмонтированной файловой системой. Systemd в этой ситуации пытается-пытается, да и бросает (неотмонтированную файловую систему). То есть reboot в этой ситуации будет ОЧЕНЬ долгим, но всё-таки пройдёт. Но это если umount вернёт ошибку.
Вторая, крайне неприятная ситуация: проблемы с файловой системой на / (в корне). Любая попытка сделать ls, grep, и даже ‘reboot’ вызывает либо зависание консоли, либо ошибку. По той же категории проходят проблемы с libc (включая её удаление), когда на попытку ‘reboot’ говорят о проблеме линковки и отказываются что-то делать. Или, мы достигли лимита на число pid’ов и все они в ‘D’ стейт. или ещё какая-то гадость того же калибра, идущая по категории „серверу плохо“.
Бывает так, что на сервер осталась открыта только одна консоль (а вторая уже не открывается). Почему? Потому что кто-то что-то подхимичил с драйвером дисков. Или рейд-контроллером. Или ещё чем-то, после чего от ‘/’ остаются только воспоминания в дисковом кеше. Это означает, что у нас есть только команды bash’а (встроенные), которые выполняются без запуска новых процессов.
ipt_sysrq
Это всё работает, если у вас есть консоль на сервер. А если логин виснет и открытой консоли нет? Есть модуль ipt_SYSRQ, позволяющий выполнить sysrq запросы по получению определённого сетевого пакета (точнее, по правилу iptables). Работает целиком в ядре, т.е. от FS не зависит. К нему же прилагается команда send_sysrq.
сторож для сторожа
Можно было бы подумать, что на этом „всё“, но бывают ещё более неприятные зависания. Например, зависла сетевая карта. И обычный reboot (в т.ч. через sysrq) не помогает. Вторым примером таких плохой ситуации бывает зависание enclosure, которая залипла на плохом диске и игнорирует все bus reset. Перезагрузка вроде бы всё сбрасывает, а диски недоступны.
В этом случае нам нужен power cycle (включить/выключить). Физически бегать к серверу не интересно, так что можно посмотреть на возможности современных серверов: IPMI. Это встренный микрокомпьютер, позволяющий управлять „большим“ компьютером. Он обычно называется IPMI, DRAC, iLO, etc.
Интресующая нас команда: ipmitool chassis power cycle. Она более требовательна к работоспособности системы (должны быть загружены модули ядра, сам ipmitool должен успешно запуститься, ipmi должен быть рабочим и т.д.). Но зато она позволяет передёрнуть по питанию всех. Точнее, почти всех — если у сервера есть jbod’ы, то до них эта команда не доходит. Но, всё-таки, это очень добротный и хороший ребут.
Следующая точка „боли“ — это зависающие блоки питания. Да, такое бывает. Баги в прошивке блоков питания исправляют, их нужно прошивать. Разумеется, любые мягкие ребуты (такие как ipmi power cycle) в этой ситуации не работают. Нужно либо физически тыкать кабель, либо передёргивать питание удалённо. В этой ситуации помогает IP-розетка.
Выглядит это примерно так (фрагмент панели управления для servers.com/servers.ru): 
Очевидно, в этих условиях ребут пройдёт по очёнь жёсткому сценарию, но точно пройдёт.
Зачем нужно перезагружать контроллеры домена раз в месяц
Для оптимальной производительности и безопасности контроллеров домена службы каталогов Active Directory требуется их регулярное обслуживание. Наше новое руководство поможет вам максимально эффективно настроить работу ваших контроллеров домена при обслуживании запросов аутентификации и авторизации.
Active Directory предоставляет сервисы аутентификации и авторизации. Работоспособная среда Active Directory позволяет эффективно работать другим службам.
Ранее в руководстве по проверке работоспособности Active Directory (Active Directory Health Check Server Tutorial) мы рассмотрели 2 важных вопроса связанных с проверкой надлежащей работы службы каталогов: «Реплицированная топология Active Directory» и «Подсети не связанные с сайтами Active Directory». Мы рассказали о преимуществах использования сетевой топологии по сравнению с «ячеичстой топологией», а также предложили скрипт в PowerShell, который вы можете использовать для получения информации о количестве сайтов, связанных по ссылке AD.
Сегодня мы объясним, для чего нужно перезагружать хотя бы раз в месяц контроллеры доменов и как можно использовать скрипт Power Shell для получения информации об аптайме контроллеров домена. Скрипт будет представлен ниже.
Важно понимать, что контроллеры домена предназначены для обеспечения критически важных сервисов аутентификации и авторизации и постоянно находятся в работе. Поэтому их необходимо перезагружать ежемесячно, либо в специально отведенный для обслуживания временной промежуток согласно вашим стандартам проверки работоспособности системы.
Перед тем как рассмотреть скрипт Power Shell для получения информации об аптайме контроллеров домена, давайте определимся с тем, зачем нам необходимо перезагружать контроллеры домена. Есть две веские причины, которые необходимо учитывать при принятии решения о перезагрузке. Рассмотрим их:
Несмотря на то, что в новых версиях операционных систем для серверов Windows Server 2012 R2 и Windows Server 2016 функция восстановления памяти реализована автоматически, всё же рекомендуется перезагружать доменные контроллеры, что в свою очередь может помочь решить проблемы утечки памяти, которые операционная система не может автоматически решить.
Меняем ITDynamicPacks. Прописываем имя главного домена в AD forest name. Получаем перечень всех доменных контроллеров и главного домена Active Directory, прописав команду, указанную ниже, результат сохраняется в файле C:\Temp\DCList.TXT file:
Копируем полный скрипт указанный ниже в файл PS1 и исполняем в PowerShell окне
Когда завершится исполнение скрипта по всем контроллерам домена, будет сформирован отчет в DCUpTimeReport.CSV файле в папке C:Temp folder как показано на следующем скриншоте:
Как можно увидеть из отчета, скрипт даёт возможность получить информацию об аптайме каждого контроллера домена, указанную в C:\Temp\DCList.TXT файле. А отчет о том, сколько дней доменный контроллер не перезагружался можно увидеть в графе «Days Not Rebooted».
Приведенный выше скрипт является частью «Теста контроллеров домена на аптайм» Dynamic Pack, который доступен для использования с Active Directory Health Profiler. Данный тест может быть проведен как для одного, так и для множества доменов AD и вы можете увидеть результаты теста в консоли Active Directory Health Profiler как показано на скриншоте ниже:
Вывод
Мы подробно рассмотрели две ключевые причины перезагрузки контроллеров домена. Основной целью данной перезагрузки является своевременное обслуживание контроллерами домена запросов на аутентификацию и авторизацию, а также максимальная безопасность посредством своевременных обновлений систем безопасности.
Предложенный PowerShell скрипт поможет вам поддерживать работоспособность контроллеров домена на должном уровне, для этого вам раз в месяц их необходимо перезагружать.
Как перезагрузить сервер?
Способ перезагрузки Dedicated зависит от того, есть ли связь с удаленным сервером. В статье расскажем о двух основных методах: программном и аппаратном. Разберемся, как перезагрузить сервер, который идет на контакт (через консоль). И как перезапустить сервер, который не отвечает (через IPMI).
Вам стоит перезагружать сервер, если:
Перезагрузка сервера может вызвать потерю данных. Чтобы этого не произошло, завершите все работающие программы и не начинайте перезагрузку до окончания установки или удаления ПО.
Различают программную и аппаратную перезагрузку.
Программная перезагрузка
Программная перезагрузка подойдет для решения локальных проблем. Например, когда несколько программ работает неверно или без обновления системы не будут закончены установка/удаление ПО. Программная перезагрузка выполняется вводом нескольких команд в консоли или командной строке. Однако этот метод сработает, только если сервер доступен.
Как перезагрузить Linux-сервер через консоль?
Чтобы запустить программную перезагрузку сервера через консоль, достаточно подключиться к серверу под root-пользователем и ввести одну из трех команд:
Подробнее в статье Как перезагрузить сервер Linux. Если вас интересует вопрос, как перезапустить сервер Windows, читайте дальше.
Как перезагрузить Windows-сервер через командную строку?
Windows-серверы перезагружаются аналогично серверам с Linux.
Подключитесь к серверу под root-пользователем и введите команду.
Также можно воспользоваться стандартной оболочкой PowerShell. Просто введите командлет.
Restart-Computer имя компьютера
Если программная перезагрузка пошла не по плану, попробуйте воспользоваться аппаратным способом.
Аппаратная перезагрузка
Аппаратная перезагрузка применяется, когда сервер находится вне зоны доступа. В этом случае можно прибегнуть в перезагрузке по питанию (физическому перезапуску оборудования). Для этого необязательно ехать в ДОЦ, можно удаленно воспользоваться IPMI. Этот интерфейс используется для доступа к питанию настройкам BIOS сервера. В нем вы можете управлять конфигурацией сервера.
Как перезагрузить сервер удаленно с помощью IPMI/KVM
Рассмотрим перезагрузку через IPMI на примере интерфейса renter.ru.
Чтобы перезагрузить сервер аппаратно, авторизуйтесь в личном кабинете. Перейдите в раздел “Товары/Услуги“ — “Выделенные серверы”. Выберите нужный сервер и нажмите Перейти.
В новой вкладке откроется панель DCI. Перейдите в раздел “Серверы”, выделите зависший сервер или другой сервер, который хотите перезагрузить. Нажмите иконку KVM (“Перейти к интерфейсу IPMI S6560”):
В интерфейсе IPMI перейдите во вкладку “Remote Control”. В списке слева выберите пункт “Power Control”. Установите переключатель напротив Reset Control и нажмите Perform Action:
Сервер будет перезагружен. Если аппаратная перезагрузка не решила проблем, обратитесь в техническую поддержку renter.ru.
Нужен надежный и недорогой выделенный сервер?
Выделенные серверы по низким ценам! Переходи и выбирай свой!
Как часто нужно перезагружать серверы Windows?
Немного предыстории: у нас есть несколько серверов Windows (2003, 2008) для нашего отдела. Мы подразделение ИТ, поэтому мы управляем своими собственными серверами. Из четверых из нас здесь я единственный с небольшим знанием ИТ. (Обратите внимание на «небольшое количество».) Мой начальник говорит, что серверы необходимо перезапускать хотя бы раз в неделю. Я не согласен. Наш ИТ-отдел говорит, что из-за того, что она постоянно перезагружает их, по этой причине наши жесткие диски выходят из строя и на них отключаются источники питания. (Это случилось с несколькими нашими серверами пару раз за последние четыре года, и совсем недавно.)
Итак, вопрос: как часто все перезагружают свои серверы Windows? Есть ли отраслевой стандарт или рекомендация? Правильно ли говорит наш ИТ-отдел, потому что мы перезапускаем, поэтому у нас проблемы с оборудованием? (Мне нужна причина, если я собираюсь изменить ее мнение!)
Мой босс говорит, что серверы нужно перезапускать хотя бы раз в неделю
Я категорически не согласен. С хороших дней [NT, кто-нибудь?] Microsoft добилась больших успехов в плане стабильности и времени безотказной работы. Жаль, что консенсус в сфере ИТ-поддержки не изменился вместе с этим.
Как часто все перезагружают свои серверы Windows?
Есть ли отраслевой стандарт или рекомендация?
Правильно ли говорит наш ИТ-отдел, потому что мы перезапускаем, поэтому у нас проблемы с оборудованием?
Серверы Windows необходимо ежемесячно перезагружать, если вы применяете исправления. Вы применяете патчи, верно? Правильно?
Я дам альтернативный ответ для очень конкретного случая. Достижения последних 2-3 лет, возможно, изменили это, но если у вас интенсивно используются серверы TS или Citrix, на которых запущено много интерактивных приложений (например, Office), было бы неплохо делать еженедельные перезагрузки в нерабочее время, просто начать с чистого листа для таких ресурсов, как застрявшие сеансы, использованная куча рабочего стола и т. д. Если вы правильно настроили свою ферму и сделали перезагрузку, даже если у вас мало времени использования, пользователи не должны подвергаться воздействию.
Конечно, это обычные перезагрузки серверов, но они используются как настольные компьютеры.
Это скорее политический и психологический вопрос, чем технический.
По моему опыту, некоторые люди, которые работали с некоторыми из более старых версий Windows, поняли, что им нужно еженедельные перезагрузки, и они сохранили эту философию в своем маленьком уголке (они, кажется, никогда не замечают, когда хотя перезагрузка пропущена, когда они в отпуске). Если у вас нет очень нестабильных систем и приложений, они больше не основаны на реальности.
С другой стороны, частые перезагрузки могут катализировать аппаратный сбой, но вряд ли причина его возникновения.
Я ни в коем случае не эксперт в данной области, но в зависимости от того, какие службы у вас запущены, некоторые могут быть подвержены переполнению при определенных функциях синхронизации, таких как timeGetTime () и getTickCount ().
TimeGetTime имеет 32-битный результат, который равен количеству миллисекунд с момента запуска компьютера. Это максимально около 49,7 дней.
Я имел обыкновение перезагружать все свои серверы Windows каждую неделю, и, безусловно, было время, когда это требовалось. В эти дни я перезапускаю их только тогда, когда это требуется для обновления. Конечно, это означает, что они все равно перезапускаются каждые несколько недель.
Для наших клиентов с контрактами на обслуживание мы устанавливаем обновления и ежемесячно перезагружаем их серверы. У этих клиентов гораздо меньше неприличных проблем с сервером, порядка 1/5 от числа проблем, которые не перезагружаются регулярно.
Для тех, кто говорит, что перезагрузка вызывает преждевременный аппаратный сбой, было время, когда перезагрузка жестких дисков и систем была потенциальной проблемой. Однако сегодня жесткие диски и другие компоненты рассчитаны на тысячи циклов запуска и остановки. Если ваше серверное оборудование слабое, вы бы предпочли знать об этом в контролируемое время, когда вы готовы быстро решить проблему, или в случае случайного сбоя с вызовом в середине рабочего дня с сообщением о том, что отдел не работает?
Я чувствую, что нет никаких недостатков в регулярных ежемесячных перезапусках, в то время как преимущества очевидны и проверены с течением времени.
Я сетевой администратор в компании, которая работает на нескольких серверах Windows 2003 2008. Я перезагружаю серверы ежемесячно, обычно не дожидаясь дольше 3 месяцев, так как очень важно не работать в течение этого короткого периода времени.
Определение только Windows может быть слишком широким для принятия разумного решения. Фактически, вы примете более правильное решение, если рассмотрите службы, роли и функции, которые вы запускаете на компьютере с Windows (например, веб-службы, серверы баз данных и т. Д.).
Качество и поведение сторонних приложений и веб-сервисов, запущенных на конкретном сервере, может указывать на необходимость более / менее частого перезапуска хост-компьютера Windows, чем на других машинах без них.
На самом деле некоторые сторонние приложения ( не идеально разработанные; ну, конечно, никто не идеален! ) Могут не выпустить израсходованные системные ресурсы, такие как память, блокировки и сокеты, изящно и своевременно. Это, например, может удерживать некоторые сбойные приложения, службы или драйверы [при повторном запуске ] в состоянии ожидания или в начальном состоянии, которые нельзя легко исправить без перезагрузки.
На практике приложения, работающие с дисковым вводом-выводом, сетью и памятью при высокой и загруженной рабочей нагрузке и с низкими доступными системными ресурсами, могут привести к зависанию, нестабильности или перегрузке вашей машины Windows, что может привести к ее перезапуску.
Если вам приходится запускать такие неисправные приложения или обслуживать больше пользователей, чем типичная емкость вашего аппаратного / программного обеспечения, или вы вынуждены размещать несовместимые службы на одной физической машине, вы можете прийти к такому решению, что вам следует перезагрузить Windows периодически. В этом случае вы можете настроить период перезапуска, прослушивая жалобы пользователей на скорость сервера!