Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между 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).
Что может пойти не так при «обычном ребуте»? Ну, во-первых, какой-то из процессов-демонов может начать «тупить» — см выше.
Во-вторых, может возникнуть проблема с отмонтированием файловых систем. Считается, что достаточно «убить» все процессы, и отмонтировать диск будет легко — его же никто не использует. Но, это, мягко говоря, не так. Вот потенциальные методы «прибить fs гвоздями так, чтобы не отмонтировалось:
- 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
Это всё работает, если у вас есть консоль на сервер. А если логин виснет и открытой консоли нет? Есть модуль 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-розетка.
Выглядит это примерно так (фрагмент панели управления для servers.com/servers.ru):
Очевидно, в этих условиях ребут пройдёт по очёнь жёсткому сценарию, но точно пройдёт.
Заключение
Краткая выжимка
| Нормальная работа | reboot |
| проблемы с софтом | reboot -f |
| проблемы с ядром/маунтами/libc | echo b>/proc/sysrq-trigger |
| проблемы с ядром/маунтами/libc и нет открытой консоли | ipt_SYSRQ (надо подготовить заранее) |
| проблемы с ядром/железом | ipmitool chassis power cycle |
| проблемы с ядром/железом без открытой консоли | ipmitool -H ipmi.server.local chassis power cycle |
| проблемы с автономной периферией/БП/ipmi | ребут через IP-розетку |
Комментарии (79)
pessom
21.04.2016 12:02Давно-давно читал, что reboot использовать не кошерно, а надо использовать 'shutdown -r'.
В чем же тогда разница между reboot и 'shutdown -r'?
amarao
21.04.2016 12:08+1Насколько я знаю, с точки зрения самого ребута, никакой. shutdown просто позволяет его (ребут) запланировать и разослать с помощью wall сообщение на все терминалки о предстоящем ребуте.
simpleadmin
21.04.2016 13:17+1reboot использовать не кошерно, а надо использовать 'shutdown -r'
Это справедливо для FreeBSD, при неаварийной перезагрузке нужно использовать shutdown -r
При этом сначала быдет выполняться /etc/rc.shutdown для корректного завершения процессов.
При reboot просто всем пошлётся sigterm, подождёт (по дефолту вроде 30 сек), потом sigkill
wsf
21.04.2016 14:17кусочек man reboot:
When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call itself and directly reboots the system. Otherwise this simply invokes the shutdown(8) tool with the appropriate arguments.
CodeRush
21.04.2016 12:28+8Добавлю, что на машинах с UEFI есть возможность вызвать перезагрузку вызовом gRT->ResetSystem(), который не зависит от ядра и может выполнить даже power cycle reset, при условии, что БП не завис намертво. Доступен сервис на любой системе и без IPMI, но как достучаться до UEFI RT Services из ОС — вопрос отдельный.
amarao
21.04.2016 14:18+1Вопрос: кто передаёт управление коду UEFI? Он же на локальном (основном) процессоре исполняется? Если ядро в этот момент сильно занято философией, оно может call/jmp туды и не сделать.
CodeRush
21.04.2016 14:27+1Может, никто не спорит. Сделан этот сервис в первую очередь для того, чтобы предоставить абстракцию от конкретного способа выполнить этот самый Reset, а то этих способов за 30 лет развития архитектуры x86 накопилось столько, что не знаешь, за какой хвататься, и какие еще работают (IO port 0xCF9), какие уже 10 лет устаревают (IO port 0x92), а какие наконец-то устарели совсем (IO port 0x64).
amarao
21.04.2016 15:37-1Вы уходите в программистские вопросы. Внутри всё это приводит к отправке RST по всем шинам, какие есть. После этого сам компьютер ребутится. Воткнутые HBA — уже под вопросом, хотя чаще всего, да. HBA посылают RST по шинам, и вот тут-то вот есть полная свобода этот rst игнорировать.
У админов на этот случай есть расширенный набор костылей — ipmi, розетки, etc. А чтобы echo b> /proc/sysrq-trigger не сработало для ребута самого хоста — я такого в реальной жизни даже и не припомню.CodeRush
21.04.2016 16:02+1Зато я видел пару раз, хоть и не на серверах. Чтобы выполнить перезагрузку, ядро должно знать, как это делается на конкретном железе, и иногда это знание его подводит в случае, если железо новое, странное или просто глючное.
Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.amarao
21.04.2016 16:05Тыг я и говорю, это разные задачи. В ядре задача «таки убедить сервер ребутнуться», а у админа задача «чтобы оно перестало глючить». Даже если мы через ACPI с первой попытке центральную часть системы ребутнули, это не означает, что процессор в enclosure, через которые HBA видит диски, захочет переинициализироваться. Может, у неё там важный таймаут всё никак не истечёт. Или прерывание за прерывание запнулось.
CodeRush
21.04.2016 16:22Опять не же согласен. Из моей практики самые неприятные для перезагрузки устройства — клиентские хреновины на FPGA. Продолжительность ресета у них непредсказуемая, а на сам сигнал они реагируют как хотят. Не успел проинициализироваться — отвалился от PCIe. В результате приходится городить разные костыли вплоть до POST-таймаутов и многоканальных вотчдогов, все для того, чтобы «перестало глючить».
amarao
21.04.2016 16:27Ну, это тоже. Но если между «клиентской хреновиной» и компьютером простой шнурок (scsi, fc, etc), то перезагрузка при ребуте сервера может быть только добровольной. Проблема в том, что архитектурно jbod'ы считаются частью сервера, а по сути — отдельные компьютеры без какого-либо доступа к фирмвари (внутри enclosure) и возможности передёрнуть питание/послать аппаратный reset.
lovecraft
29.04.2016 07:10Огромное спасибо вам за комментарий. Я как-то не задавался вопросом, как в ядре вызывается reboot и поэтому относился к зависанию старенького ASUS K80N при попытке уйти в перезагрузку как к неизбежному злу. После передачи ядру параметра reboot=p ноутбук стал перезагружаться нормально.
lovecraft
21.04.2016 12:51Замечание: кажующееся правильным в этой ситуации „sync, reboot“, т.е. SysRq-s, SysRq-B это ошибка, т.к. после SysRq-S, ядро может попытаться начать общаться с пустым множеством, и, потенциально, упасть в панику или отломать вам последнюю из доступных консолей. Если делается аварийный ребут — он должен быть аварийным
А то иногда так хочется сделать, как рекомендуют в википедии:
Экстренную перезагрузку стоит проводить, зажав клавиши Alt + SysRq и с интервалом в 2-3 секунды нажать последовательно: R E I S U B
unRaw (перехватить управление клавиатурой, неактуально для удаленного сервера),
tErminate (послать SIGTERM всем процессам),
kIll (послать SIGKILL всем процессам, которые не смогли завершиться предыдущей командой),
Sync (синхронизировать файловые системы),
Unmount (перемонтировать файловые системы в режим «только чтение»),
reBoot. (и напоследок, совершить перезагрузку)
Эта последовательность явно безопаснее с точки зрения сброса кэшей, чем SysRq-B, но приведет к проблемам, если завис HBA и кэш сбрасывать уже некуда ) Так что, видимо, если подозрение на проблемы с контроллером, бэкплейном и т.п., то SysRq-B или power cycle, а если «просто чего-то тормозит, надо перезагрузиться — то „R E I S U B“.xalkin
21.04.2016 14:58Это возможно только если есть доступ к локальной консоли. Автор же рассматривает случай, когда локального доступа нет. В таком случае команда S может вызвать зависание этой консоли, т.к. ядро попытается засинхронизировать ФС отвалившегося диска. Так что и консоли больше не станет, и ребут не произойдет.
lovecraft
21.04.2016 16:01«Нажимать» на SysRq можно удаленно через /proc/sysrq-trigger, о чем и сказано в статье ))
ComodoHacker
21.04.2016 13:41ipt_SYSRQ опасная штука, я смотрю. Используете на проде? Как правильно чтобы никто посторонний не добрался?
amarao
21.04.2016 14:19Там же пароль можно задать. Не опаснее, чем ssh server sudo reboot
akrupa
22.04.2016 10:14Там на сайте написано, что оно уязвимо к реплэй атакам.
merlin-vrn
22.04.2016 12:19Значит пароль нужно менять на случайный при старте системы, и сообщать наружу новый.
vadimr
21.04.2016 14:12Контроллер BMC, реализующий IPMI, может управляться снаружи более непосредственным способом, чем ipmitool (например, через упомянутую веб-морду). Из статьи не очень понятно, зачем для описанной задачи к нему тянуться таким сложным путём, через умирающую систему.
amarao
21.04.2016 14:20Открытие веб-морды всегда такое мучительное. Кроме того, оно не всегда тривиальное (например, необходимость подключаться к VPN, искать логин-пароль, выяснять IP-адрес IPMI'я для _ДАННОГО_СЕРВЕРА_ — мы все знаем, как важно их не перепутать, но риск всё равно остаётся). Локальный ipmi надёжнее и проще. Если работает. Если нет — сваливаемся на сложный путь.
Orky
21.04.2016 14:21Спасибо за годную статью.
Можете уточнить, shutdown -r действует аналогично reboot?
И про halt и init 6 в статье ни слова, к сожалению.
bzzz00
21.04.2016 14:22masterkit.ru/shop/smarthome/usb/1319335 и никаких корявых ipmi ;)
amarao
21.04.2016 14:23Эм… Я понимаю шутку, но я с трудом себе такое представляю в серверной среде.
bzzz00
21.04.2016 14:24это не шутка, это недорогая замена брендовым power control. есть подобные устройства, чуть дороже, уже в корпусе, но суть та же.
Alexey_Meyev
21.04.2016 15:57Коммутируемые токи 2 А — маловато будет.
bzzz00
21.04.2016 16:00кхм, 220*2=440Вт, нет? у меня нода с i7-4790/24GB/SSD + IB (к storage) потребляет в пике не больше 100Вт.
amarao
21.04.2016 16:02440Вт — на практике, большинство современных серверов жрут меньше. Для интереса, первый попавшийся лабораторный R530, занятый «ничем» — 210Вт, 0.9А, при historical peak — 279Вт. А это всё-таки довольно жирнющий сервер с 8 SSD'ами в рейде. Для «самосерверов» на базе десктопных процов с 2-4 жёстких диска — более чем достаточно.
Alexey_Meyev
21.04.2016 16:25Практика — очень растяжимая штука. У одних нормой является сервер с парой 2620 с двумя дисками, у других — пара 2690 с 16 модулями памяти, у третьих «гробики» на несколько десятков хардов.
Но для большинства неспецифических применений подойдет, наверное. Главное — чтобы оно не дохло само.
simpleadmin
21.04.2016 16:08Да дело даже не в 2А-ом токе. Доверять управление сервером электромеханической релюшке (включенной в другой сервер?) можно только если уж совсем ничего ценнго на управляемом сервере нет.
Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.bzzz00
21.04.2016 18:14а что не так с электромеханическим реле?
TheRaven
21.04.2016 18:24Контакты могут залипнуть. Не сталкивались с глючащими UPS'ами?
Ограничение 2А по току можно обойти навесив цепочкой твердотельное реле с интересующими характеристиками.bzzz00
21.04.2016 18:26я лично не сталкивался. и люди все еще продолжают пользовать UPS'ы, вроде? штуки типа IMPI _кажутся_ мне менее надежными…
merlin-vrn
22.04.2016 12:30IPMI. И это очень, очень, очень хорошая штука для экстренного управления сервером. Собственно, принципиальная разница между серверной платформой, даже начального уровня, и производительным десктопом — как раз именно этот BMC, позволяющий удалённо решить самые неприятные проблемы.
И если посчтитать, во что обойдётся малому бизнесу простой, связанный с выездом админа, всегда получается, что дешевле доплатить за серверную платформу. Даже с учётом глюков этих ваших BMC. Для крупных бизнесов могут быть детали — там где у тебя кластер 100 нод с автоматической балансировкой, бывает не так важно следить за каждой отдельной нодой. Но в этом случае BMC с интерфейсом IPMI предлагает отличную реализацию STONITH — автоматизацию контроля исключительного доступа к ресурсам (т.н. fencing), и опять же дополнительная плата за эту штуку в сервере может быть рентабельной.amarao
22.04.2016 14:16Чисто формально, у крупного бизнеса всё в ДЦ, а в ДЦ есть дежурная смена. Это не отменяет удобств от IPMI, конечно.
merlin-vrn
22.04.2016 12:24Лично я сталкивался один раз за всю жизнь. Упс хороший, апс тысячник, не срабатывал только автотрансформатор для повышенного/пониженного напряжения в сети. Если всё отрубалось насовсем, отлично питал от батарей. За ремонт просили 5000р. Мы поставили перед ним недорогой электронный стабилизатор за 1000р и так эта парочка служит верой и правдой уже больше пяти лет.
Впрочем, после какого-то времени реле в упсе перестало глючить, но всё равно этому упсу я уже не доверяю.TheRaven
22.04.2016 14:16Простых APC'шек с дефектами реле повидал уйму, 1000\1500 штук 5-7 точно. Это реально распространенная проблема.
simpleadmin
21.04.2016 18:34+2проблем 2:
— перегорание обмотки
— залипание контактов
Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.bzzz00
21.04.2016 18:35спасибо. а что используется на брендовых девайсах?
simpleadmin
21.04.2016 18:48На самом деле даже бренды типа kramer и сейчас используют электромеханические реле, но это скорее дань долгосрочным договорным обязательствам. Исключением могут служить ртутные герконы.
В остальном, если не крично сопротивление замкнутой контактами цепи, альтернативы твердотельным реле нет.
amarao
21.04.2016 19:06Внезапно: как часто такое реле будет срабатывать IRL?
simpleadmin
21.04.2016 19:25Бывает и часто. У нас был случай(именно по этому реле) когда из-за программной ошибки оно должно было сработать около 5000 раз за 16 дней (попало на праздники и не могли попасть в помещение где стояла станция). Но, судя по логам, перезагрузки прекратились (контакты залипли) на ~1500 сработках. При этом по заявлению производителя цифры сработок даже не в 5-м порядке.
Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?amarao
21.04.2016 19:33«зачем доверять production сервер» фигулинке под usb? Как минимум, что-то сетевое, не?
simpleadmin
21.04.2016 19:46«зачем доверять production сервер» фигулинке под usb?
Не только под usb. Те самые перезагрузки постом выше вызваны устройством включенным в LPT, но при этом забыли учесть в какое состояние переходит lpt при перезагрузке. В итоге рекурсивно перезагружали сами себя.
Как минимум, что-то сетевое, не?
Не обязательно. Зависит от бюджета и задачи.
JerleShannara
21.04.2016 19:57Для кровавого ентерпрайза есть готовые брендонутые решения — PDU
http://www.42u.com/power/rack-pdu/apc-rack-pdu.htm — как примерbzzz00
21.04.2016 19:58не вопрос, есть, пользую подобные регулярно, но чуть дороже оне ;)
JerleShannara
21.04.2016 22:57Ну оно конечно дорого-бохато, но больше плюшек + надежность получше (если конечно забыть про «лехендарити реляябилить [censored]» продукцию) + гарантия и т.д. Ставить такое в «одна стройка гдето в каморке с китайским сплитом» не очень разумно, но в масштабах «сириоус бизнесс» — почему бы и нет?
merlin-vrn
22.04.2016 12:33в упор не понимаю такой огромной стоимости. Ну никак.
сделать такую электронику самому оказывается где-то в районе 2000р и сразу с вайфаем
TaHKucT
22.04.2016 13:01Большинству людей не нужна железка, а нужно решение проблемы. С красивой презентацией, девушкой, ответившей «Ваш звонок очень важен, перевожу вас на специалиста», бухгалтерскими документами и NBD-заменой проблемного оборудования.
JerleShannara
22.04.2016 15:25Ну оно не только умеет «вкл-выкл» делать, оно ещё графики потребляемой мощности умеет строит, интегрируется в структуру датацентра нажатием пары кнопок, позволяет реализовать тот самый power budget и т.д., ну и ещё +100-200% за бренд нейм.
amarao
22.04.2016 16:10Насчёт «интеграции парой кнопок» — это вы сильно преуменьшаете. В остальном — да.
JerleShannara
22.04.2016 18:24Ну иногда случается вариант «воткнули, поставили галочку „Enable c001 pdu4u“, всё заработало». У меня это было с KVMами от avocent, подрубили PDU, сказали квму, что он там есть, на этом настройка завершилась, весь софт её понял и добавил приятных кнопочек.
devpreview
21.04.2016 16:23+4Вставлю пять копеек на тему ребута: в Debian Jessie до недавнего времени был баг [2]. Если SWAP переполнен, то машина при перезагрузке висела на «Reached target Shutdown». Лечится обновлением systemd до 215-17+deb8u4 (сейчас лежит в репозитории).
Если кто-то ещё не обновился — есть повод.
impetus
21.04.2016 20:03А про «как ВЫКЛЮЧИТЬ сервер? И как его потом включить?» у Вас статьи случайно нет на подходе?
Имел как-то неск шкафов серверов на двух больших бесперебойниках (вся сеть большого вуза плюс все его внешние сервисы (в т.ч. почта и все сайты всех подразделений) плюс куча вобще непойми чего) — и решал задачку — как их выключать при «конце света», что бы наиболее значимые сервисы работали как можно дольше, и главное — что бы это всё без проблем назад поднималось при появлении питания в любой момент последовательности их гашения. и соотв в какой последовательности их поднимать, и как перескакивать с середины последовательности «подъёма» или «гашения» назад в нужную точку последовательости соотвественно «гашения» или «подъёма».
В общем, электричество меня победило (через конидционер), и крупный ВУЗ остался без сайта в разгар приёмной кампании на где-то лишние сутки, чем могло бы быть при сидении человека в серверной круглосуточно (вуз сам при этом был обесточен, т.е. ко мне претензий никаких) (ну и без леса доменов на пару часов после начала рабочего понедельника тоже понервничал народ… особо что оказалось что туда же наблюдение периметра было завязано (не само, а дамп) )
(Впрочем мне самому сейчас это совершенно не актуально, но вы умеете писать «закрывая проблему»)amarao
21.04.2016 20:46+5Вообще, у всех уважающих себя серверов есть в биосе указание, что делать при появлении питания.
Как бы это сделал я:
на одном сервере включил бы «включаться по появлению питания», на остальных «не включаться после появления питания». На этом «одном» был бы скрипт, который по ipmi включал/выключал остальные сервера (сам ipmi ест мало). Если «один» звучит ненадёжно, пусть два.
Дальше вопрос в программировании логики сигналов от упсов.
А для энтерпрайза оно есть готовое — «стойки с power budget». Внутри стойки задаются приоритеты, и если сервера вылетают за budged, то гасятся самые ненужные (малоприоритетные). Дальше просто: пропал основной ввод — понижаем power budged. Появился — повышаем.impetus
21.04.2016 23:28Ок, спасибо, если вы только сейчас про эту задачку задумались — то не надо, там много подводных граблей разных, которые обычно обходят подальше повышением надёжности питания, что бы в ситуацию «свет есть/нет» с хаотичным периодом от минут до неск.часов всю неделю — не попадать.
И это правильно — плохую инфраструктуру надо исправлять, а не подлаживаться к ней, изобретая УАЗики… Отменяю вопрос.
Rumlin
27.04.2016 10:56Обычно в «больших бесперебойниках» есть SNMP-карта. При инсталяции должны были бы подключены в сеть и настроены. К слову ими же можно и передернуть питание в крайнем случае. Если же UPS простые, то можно использовать управление через MOXA NPort — асинхронные сервера RS-232 в Ethernet
navion
28.04.2016 17:00Даже небольшие ИБП обычно отдают питание ветками через C20, так что лучше обзавестись управляемым PDU (чтобы не дёргать всю стойку).
navion
22.04.2016 00:13+1Баги в прошивке блоков питания исправляют, их нужно прошивать.
Там ещё дурная процедура обновления — сервер выключается на 10 минут не подавая признаков жизни и трогать его в это время нельзя, иначе придётся звонить в поддержку для замены БП.
RicoX
22.04.2016 09:02+2Добавлю свои 5 копеек. Есть еще интересные решения из мира кластеров, представляют собой многоуровневый внешний watchdog, в документации чаще всего обозначаются как fencing/stonith. Принцип работы такой, внешний сервер/сервера проверяют доступность группы подконтрольных серверов по некоторому сценарию, если сценарий вызывает сбой посылается команда аппаратного ребута, если сервер не вышел на связь втечении установленного таймера, посылается команда ребута через IPMI, снова проблема (повис IPMI — привет iDrac6 и ранее с систематическими подвисаниями, а также пламенный привет supermicro), команда идет на управляемую розетку которая передернет блоки питания, снова ничего, помечаем сервер полностью дохлым и запускает сценарий поднятия замены из горячего списка не занятых серверов. На практике очень спасают от дальней дороги или судорожного поиска адекватных рук в какой-нибудь заднице мира с изолированной крупной площадкой. Послал в ребут полудохлый сервер, если через 15 минут не вернулся, ну и хрен с ним, при плановом обслуживании инженеры разберутся что с ним было, а на замене уже крутится его копия.
ctapnep
26.04.2016 21:27Спасибо. Вроде всё где-то известно, ничего кардинально нового, но вот так собрано и разжевано — это очень полезно.
lolipop
Спасибо, как всегда хорошая статья. О ipt_SYSRQ не знал, а про ipmitool chassis power cycle с локалхоста даже и не задумывался.
Еще подумал, в самых запущенных случаях можно сделать reverse-sysrq(особенно когда не в одной сети с машиной или машина за натом) — запускать скрипт в бесконечном цикле, например, while true; do sleep 60; wget --tries inf http://domain.tld/reboot/$HOSTNAME && echo b > /proc/sysrq-trigger; done
Т.е. на машине-мамке в случае отвала фс подложить одноразово файлик с именем машины и удаленная машина перегрузится(главное не забыть удалить этот файл).
amarao
Это называется watchdog.
В софте: http://linux.die.net/man/8/watchdog
В ipmi: https://www.ibm.com/support/knowledgecenter/linuxonibm/liaai.ipmi/liaaiipmiwatchdog.htm
lolipop
спасибо, про watchdog я в курсе. но это не то же самое, что я предложил.
так рассуждая, можно всю вашу статью сократить до «reboot, если не помогло, то правильно настроенный watchdog сам потом перезагрузит машину.»
amarao
Ребут приходится делать руками потому что неожиданно, плюс надо понять, какой. reverse-sysrq — это и есть вотчдог, только в форме однострочника и зависящий от работоспособности кучи компонент. Что делать, если wget уйдёт в D+ и не вернётся?
lolipop
ну так и тут так же — руками. подложить руками файл на удаленном сервере, чтобы локальная машина поняла, что надо перегрузиться.
а почему он должен уйти в D? он один раз считался с диска при запуске и бесконечно долго работает в цикле.
разве что в начальном сообщении я не предусмотрел -O /dev/null.
TaHKucT
lolipop
я полагал, что wget будет бесконечно долго с этой опцией ломиться на сервер, пока не получит 200, однако это не так. ну, значит надо какой-то другой бинарь использовать, сути не меняет.
amarao
Вы все предполагаете, что wget вам вернёт что-то. А он может умереть навсегда не завершаясь даже по kill -9. TASK_UNINTERRUPTIBLE и всё такое.