Как перезагрузить windows server 2019

Обновлено: 28.06.2024

Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду 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).

Что может пойти не так при «обычном ребуте»? Ну, во-первых, какой-то из процессов-демонов может начать «тупить» — см выше.

fallocate /fs/swap -l 1G;mkswap /fs/swap; swapon /fs/swap
dd if=/dev/sda of=/fs/image; kpartx /fs/image
losetup --find --show /fs/image

Чем это чревато? Неотмонтированной файловой системой. Systemd в этой ситуации пытается-пытается, да и бросает (неотмонтированную файловую систему). То есть reboot в этой ситуации будет ОЧЕНЬ долгим, но всё-таки пройдёт. Но это если umount вернёт ошибку.

А бывает так, что umount не может завершить операцию из-за того, что что-то не доступно. Например, файл на nfs-сервере. Если какой-то процесс обратится к такому файлу, то его завершить нельзя (даже с помощью kill -9). И в этой ситуации 'reboot' просто завесит сервер. Опять же, наиболее типовые места у systemd „прикрыты“, но вероятность наткнуться на TASK_UNINTERRUPTIBLE ('D' в ps aux) всё равно можно.
Что делать? Можно перезагрузиться без синхронизации файловых систем и завершения чего-либо reboot -f. Но он тоже может повиснуть. Про причины ниже, а пока про последствия: все процессы не остановлены и умирают мгновенно, tcp сессии не закрыты, дисковые кеши не сброшены. Однако, ядро всё-таки выполняет какие-то движения в районе ребута (и, возможно, часть кешей будет сброшена). Главное же — в процессе ребута будет задействована большая часть ядра. И это означает, что если ядру поплохело, то мы можем и не вернуться обратно.

Вторая, крайне неприятная ситуация: проблемы с файловой системой на / (в корне). Любая попытка сделать ls, grep, и даже 'reboot' вызывает либо зависание консоли, либо ошибку. По той же категории проходят проблемы с libc (включая её удаление), когда на попытку 'reboot' говорят о проблеме линковки и отказываются что-то делать. Или, мы достигли лимита на число pid'ов и все они в 'D' стейт. или ещё какая-то гадость того же калибра, идущая по категории „серверу плохо“.

Бывает так, что на сервер осталась открыта только одна консоль (а вторая уже не открывается). Почему? Потому что кто-то что-то подхимичил с драйвером дисков. Или рейд-контроллером. Или ещё чем-то, после чего от '/' остаются только воспоминания в дисковом кеше. Это означает, что у нас есть только команды bash'а (встроенные), которые выполняются без запуска новых процессов.

Существует метод перезагрузки, который не требует выполнения каких-либо исполняемых файлов (т.е. чтения с отсутствующего диска). Это (от рута): echo b >/proc/sysrq-trigger . Файл sysrq-trigger позволяет „нажать“ любую кнопку из SysRq комбинаций (аварийные кнопки ядра). В том числе и SysRq-b, то есть аварийный „reboot“. Часто бывает так, что после нажатия enter даже не успевает появиться перевод строки — сервер уже в ребуте до того, как syscall вернулся. Это самое сильное из софтового, что есть для ребута.
Замечание: кажующееся правильным в этой ситуации „sync, reboot“, т.е. SysRq-s, SysRq-B это ошибка, т.к. после SysRq-S, ядро может попытаться начать общаться с пустым множеством, и, потенциально, упасть в панику или отломать вам последнюю из доступных консолей. Если делается аварийный ребут — он должен быть аварийным

Это всё работает, если у вас есть консоль на сервер. А если логин виснет и открытой консоли нет? Есть модуль 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'ы, то до них эта команда не доходит. Но, всё-таки, это очень добротный и хороший ребут.

Если ядру совсем поплохело, то команду можно выполнить и удалённо (ipmitool -H ipmi.server.local chassis power cycle)

Ещё одна сложная ситуация — когда завис ipmi. Если система при этом более-менее жива, то можно „перезагрузить ipmi“: ipmitool mc reboot hard . После этого можно будет сделать power cycle для шасси. Звучит странно, но я несколько раз в жизни „вытаскивал“ сервер в нормальный ребут именно такой последовательностью. (После mc reboot hard надо дать пару минут на загрузку BMC).

Следующая точка „боли“ — это зависающие блоки питания. Да, такое бывает. Баги в прошивке блоков питания исправляют, их нужно прошивать. Разумеется, любые мягкие ребуты (такие как ipmi power cycle) в этой ситуации не работают. Нужно либо физически тыкать кабель, либо передёргивать питание удалённо. В этой ситуации помогает IP-розетка.

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

Перезагрузить через командную строку

Перезагружать через командную строку мы будем Windows Server 2008 R2, но данная инструкция подойдет как и для 2012 R2 так и для любой клиентской ОС хоть от Windows 7 до Windows 10. В начале мы рассмотрим классическую cmd, открываем ее (Как открыть командную строку читайте тут). Для перезагрузки используется вот такая команда.

-r - означает перезагрузка

-t - время равное 0

У вас начнется моментально перезагрузка Windows.

Синтаксис утилиты shutdown

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

Z:\>shutdown
Использование: shutdown [/i | /l | /s | /r | /g | /a | /p | /h | /e] [/f]
[/m \\компьютер][/t xxx][/d [p|u]xx:yy [/c "комментарий"]]

Для удобства можно создать ярлык в котором можно вставить данную команду, или же создать cmd или bat файл для удобства. Так же я данную возможность использовал в mmc консоли. Помимо того что можно перезагрузить через командную строку, есть возможность сделать тоже самое и через PowerShell.

Как перезагрузить сервер через PowerShell

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

Или для нескольких

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

Из-за корпоративной природы Windows Server пользователи обычно более технически подкованы и заинтересованы в подробностях, касающихся производительности. Одна из тех интересных вещей, которые нужно знать, это как проверить время последней перезагрузки на Windows Server или как запланировать перезагрузку. Мы обязательно проинструктировали вас об этом ниже.

Windows Server: как запланировать перезагрузку

1. Используйте журнал системных событий

Вы можете использовать журнал системных событий, чтобы узнать, когда была последняя перезагрузка Windows Server. Эта процедура довольно проста, так как единственное важное — выделить одно событие.

Выполните следующие действия, чтобы узнать, когда была последняя перезагрузка с помощью утилиты System Event Log:

Откройте Event Viewer из меню «Пуск».
В крайнем правом окне выберите « Создать пользовательский вид» .
В раскрывающемся меню «Журнал» выберите « Журналы Windows» .
Под <Все идентификаторы событий> добавьте только 6009 .
Создайте собственный вид.
Теперь вы можете видеть, сколько раз ваш компьютер перезагружался с момента установки системы, что является отличной функцией.

2. Используйте командную строку

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

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

3. Запланируйте перезагрузку с запланированными задачами

Если вы заинтересованы в автоматизации последовательности перезагрузки, вы можете сделать это, создав запланированное задание. Если вы не знакомы с ним, вот как запланировать перезагрузку на Windows Server с помощью утилиты запланированных задач:

Откройте « Запланированные задачи» из меню «Пуск».
Выберите Добавить новую запланированную задачу и нажмите Далее .
На экране выбора программы перейдите к C: WINDOWSSystem32shutdown.exe .
Выберите shutdown.exe и назовите задачу shutdown .
Выберите частоту отключения .
Выберите время и день, когда произойдет запланированная перезагрузка.
Введите свои административные учетные данные и подтвердите.
Теперь установите флажок « Открыть дополнительные параметры», когда я нажимаю «Готово» и нажимаю « Готово» .
Наконец, когда появляется новое окно, скопируйте и вставьте следующую команду и замените команду по умолчанию:
C: WINDOWSsystem32shutdown.exe -r -f -t 01
Выберите Применить, и все готово.
Позже вы можете проверить, когда в последний раз происходила перезагрузка Windows Server, с помощью одного из первых двух шагов.

Имеем Windows Server 2012 R2. Задача - автоматически перезагружать сервер каждый понедельник в 5 утра. Приступаем.

Запускаем Планировщик заданий, создаём в нём папку "reboot":

Делаем Create Basic Task. Запускается мастер:

Указываем Name, Description:

Выбираем период Weekly. Next:

Указываем начало - ближайший понедельник 5 утра. Ставим галку Monday. Next:

Выбираем Start a program. Next:

В Program/script: пишем:

В Add arguments (optional):

/r - перезагрузка,
/f - принудительное закрытие всех приложений,
/t 90 - время ожидания до начала перезагрузки 90 сек,
/d p:0:0 - причины перезагрузки для журнала. В данном случае, мы указали: p - запланированная перезагрузка, 0:0 - "Other (planned)",
/c комментарий в свободной форме длинной не более 512 символов. Комментарий будет показываться юзерам 90 секунд. За это время можно отменить перезагрузку командой shutdown.exe /a.

Список параметров и причин перезагрузки можно посмотреть shutdown.exe /?

Мастер не доделали, кликаем Finish. Создаётся задача - редактируем её.

Ставим Run whether user is logged on or not. Добавим галку Run with highest privileges. Ok:

Нас попросят ввести имя пользователя, от имени которого будет выполняться задание. И пароль. Готово:

Сам пока не проверял результатов. В ближайший понедельник посмотрим.

Две недели прошло - шедулер нормально перезагружает сервер по понедельникам.

Читайте также: