Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Спасибо, как всегда хорошая статья. О 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
Т.е. на машине-мамке в случае отвала фс подложить одноразово файлик с именем машины и удаленная машина перегрузится(главное не забыть удалить этот файл).
Еще подумал, в самых запущенных случаях можно сделать reverse-sysrq(особенно когда не в одной сети с машиной или машина за натом) — запускать скрипт в бесконечном цикле, например, while true; do sleep 60; wget --tries inf http://domain.tld/reboot/$HOSTNAME && echo b > /proc/sysrq-trigger; done
Т.е. на машине-мамке в случае отвала фс подложить одноразово файлик с именем машины и удаленная машина перегрузится(главное не забыть удалить этот файл).
Это называется watchdog.
В софте: http://linux.die.net/man/8/watchdog
В ipmi: https://www.ibm.com/support/knowledgecenter/linuxonibm/liaai.ipmi/liaaiipmiwatchdog.htm
В софте: http://linux.die.net/man/8/watchdog
В ipmi: https://www.ibm.com/support/knowledgecenter/linuxonibm/liaai.ipmi/liaaiipmiwatchdog.htm
спасибо, про watchdog я в курсе. но это не то же самое, что я предложил.
так рассуждая, можно всю вашу статью сократить до «reboot, если не помогло, то правильно настроенный watchdog сам потом перезагрузит машину.»
так рассуждая, можно всю вашу статью сократить до «reboot, если не помогло, то правильно настроенный watchdog сам потом перезагрузит машину.»
Ребут приходится делать руками потому что неожиданно, плюс надо понять, какой. reverse-sysrq — это и есть вотчдог, только в форме однострочника и зависящий от работоспособности кучи компонент. Что делать, если wget уйдёт в D+ и не вернётся?
ну так и тут так же — руками. подложить руками файл на удаленном сервере, чтобы локальная машина поняла, что надо перегрузиться.
а почему он должен уйти в D? он один раз считался с диска при запуске и бесконечно долго работает в цикле.
разве что в начальном сообщении я не предусмотрел -O /dev/null.
а почему он должен уйти в D? он один раз считался с диска при запуске и бесконечно долго работает в цикле.
разве что в начальном сообщении я не предусмотрел -O /dev/null.
он один раз считался с диска при запуске и бесконечно долго работает в цикле.Он каждый раз запускается заново, а останется ли он в файловом кэше на момент очередного запуска — вопрос
Давно-давно читал, что reboot использовать не кошерно, а надо использовать 'shutdown -r'.
В чем же тогда разница между reboot и 'shutdown -r'?
В чем же тогда разница между reboot и 'shutdown -r'?
Насколько я знаю, с точки зрения самого ребута, никакой. shutdown просто позволяет его (ребут) запланировать и разослать с помощью wall сообщение на все терминалки о предстоящем ребуте.
reboot использовать не кошерно, а надо использовать 'shutdown -r'
Это справедливо для FreeBSD, при неаварийной перезагрузке нужно использовать shutdown -r
При этом сначала быдет выполняться /etc/rc.shutdown для корректного завершения процессов.
При reboot просто всем пошлётся sigterm, подождёт (по дефолту вроде 30 сек), потом sigkill
кусочек 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.
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.
Добавлю, что на машинах с UEFI есть возможность вызвать перезагрузку вызовом gRT->ResetSystem(), который не зависит от ядра и может выполнить даже power cycle reset, при условии, что БП не завис намертво. Доступен сервис на любой системе и без IPMI, но как достучаться до UEFI RT Services из ОС — вопрос отдельный.
Вопрос: кто передаёт управление коду UEFI? Он же на локальном (основном) процессоре исполняется? Если ядро в этот момент сильно занято философией, оно может call/jmp туды и не сделать.
Может, никто не спорит. Сделан этот сервис в первую очередь для того, чтобы предоставить абстракцию от конкретного способа выполнить этот самый Reset, а то этих способов за 30 лет развития архитектуры x86 накопилось столько, что не знаешь, за какой хвататься, и какие еще работают (IO port 0xCF9), какие уже 10 лет устаревают (IO port 0x92), а какие наконец-то устарели совсем (IO port 0x64).
Вы уходите в программистские вопросы. Внутри всё это приводит к отправке RST по всем шинам, какие есть. После этого сам компьютер ребутится. Воткнутые HBA — уже под вопросом, хотя чаще всего, да. HBA посылают RST по шинам, и вот тут-то вот есть полная свобода этот rst игнорировать.
У админов на этот случай есть расширенный набор костылей — ipmi, розетки, etc. А чтобы echo b> /proc/sysrq-trigger не сработало для ребута самого хоста — я такого в реальной жизни даже и не припомню.
У админов на этот случай есть расширенный набор костылей — ipmi, розетки, etc. А чтобы echo b> /proc/sysrq-trigger не сработало для ребута самого хоста — я такого в реальной жизни даже и не припомню.
Зато я видел пару раз, хоть и не на серверах. Чтобы выполнить перезагрузку, ядро должно знать, как это делается на конкретном железе, и иногда это знание его подводит в случае, если железо новое, странное или просто глючное.
Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.
Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.
Тыг я и говорю, это разные задачи. В ядре задача «таки убедить сервер ребутнуться», а у админа задача «чтобы оно перестало глючить». Даже если мы через ACPI с первой попытке центральную часть системы ребутнули, это не означает, что процессор в enclosure, через которые HBA видит диски, захочет переинициализироваться. Может, у неё там важный таймаут всё никак не истечёт. Или прерывание за прерывание запнулось.
Опять не же согласен. Из моей практики самые неприятные для перезагрузки устройства — клиентские хреновины на FPGA. Продолжительность ресета у них непредсказуемая, а на сам сигнал они реагируют как хотят. Не успел проинициализироваться — отвалился от PCIe. В результате приходится городить разные костыли вплоть до POST-таймаутов и многоканальных вотчдогов, все для того, чтобы «перестало глючить».
Ну, это тоже. Но если между «клиентской хреновиной» и компьютером простой шнурок (scsi, fc, etc), то перезагрузка при ребуте сервера может быть только добровольной. Проблема в том, что архитектурно jbod'ы считаются частью сервера, а по сути — отдельные компьютеры без какого-либо доступа к фирмвари (внутри enclosure) и возможности передёрнуть питание/послать аппаратный reset.
Огромное спасибо вам за комментарий. Я как-то не задавался вопросом, как в ядре вызывается reboot и поэтому относился к зависанию старенького ASUS K80N при попытке уйти в перезагрузку как к неизбежному злу. После передачи ядру параметра reboot=p ноутбук стал перезагружаться нормально.
Замечание: кажующееся правильным в этой ситуации „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“.
Это возможно только если есть доступ к локальной консоли. Автор же рассматривает случай, когда локального доступа нет. В таком случае команда S может вызвать зависание этой консоли, т.к. ядро попытается засинхронизировать ФС отвалившегося диска. Так что и консоли больше не станет, и ребут не произойдет.
ipt_SYSRQ опасная штука, я смотрю. Используете на проде? Как правильно чтобы никто посторонний не добрался?
Контроллер BMC, реализующий IPMI, может управляться снаружи более непосредственным способом, чем ipmitool (например, через упомянутую веб-морду). Из статьи не очень понятно, зачем для описанной задачи к нему тянуться таким сложным путём, через умирающую систему.
Открытие веб-морды всегда такое мучительное. Кроме того, оно не всегда тривиальное (например, необходимость подключаться к VPN, искать логин-пароль, выяснять IP-адрес IPMI'я для _ДАННОГО_СЕРВЕРА_ — мы все знаем, как важно их не перепутать, но риск всё равно остаётся). Локальный ipmi надёжнее и проще. Если работает. Если нет — сваливаемся на сложный путь.
Спасибо за статью.
Исправьте пожалуйста DRAC на iDRAC.
Или можно DRAC/iDRAC, а то Dell обидится.
Исправьте пожалуйста DRAC на iDRAC.
Или можно DRAC/iDRAC, а то Dell обидится.
Спасибо за годную статью.
Можете уточнить, shutdown -r действует аналогично reboot?
И про halt и init 6 в статье ни слова, к сожалению.
Можете уточнить, shutdown -r действует аналогично reboot?
И про halt и init 6 в статье ни слова, к сожалению.
masterkit.ru/shop/smarthome/usb/1319335 и никаких корявых ipmi ;)
Эм… Я понимаю шутку, но я с трудом себе такое представляю в серверной среде.
это не шутка, это недорогая замена брендовым power control. есть подобные устройства, чуть дороже, уже в корпусе, но суть та же.
Коммутируемые токи 2 А — маловато будет.
кхм, 220*2=440Вт, нет? у меня нода с i7-4790/24GB/SSD + IB (к storage) потребляет в пике не больше 100Вт.
440Вт — на практике, большинство современных серверов жрут меньше. Для интереса, первый попавшийся лабораторный R530, занятый «ничем» — 210Вт, 0.9А, при historical peak — 279Вт. А это всё-таки довольно жирнющий сервер с 8 SSD'ами в рейде. Для «самосерверов» на базе десктопных процов с 2-4 жёстких диска — более чем достаточно.
Да дело даже не в 2А-ом токе. Доверять управление сервером электромеханической релюшке (включенной в другой сервер?) можно только если уж совсем ничего ценнго на управляемом сервере нет.
Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.
Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.
а что не так с электромеханическим реле?
Контакты могут залипнуть. Не сталкивались с глючащими UPS'ами?
Ограничение 2А по току можно обойти навесив цепочкой твердотельное реле с интересующими характеристиками.
Ограничение 2А по току можно обойти навесив цепочкой твердотельное реле с интересующими характеристиками.
я лично не сталкивался. и люди все еще продолжают пользовать UPS'ы, вроде? штуки типа IMPI _кажутся_ мне менее надежными…
IPMI. И это очень, очень, очень хорошая штука для экстренного управления сервером. Собственно, принципиальная разница между серверной платформой, даже начального уровня, и производительным десктопом — как раз именно этот BMC, позволяющий удалённо решить самые неприятные проблемы.
И если посчтитать, во что обойдётся малому бизнесу простой, связанный с выездом админа, всегда получается, что дешевле доплатить за серверную платформу. Даже с учётом глюков этих ваших BMC. Для крупных бизнесов могут быть детали — там где у тебя кластер 100 нод с автоматической балансировкой, бывает не так важно следить за каждой отдельной нодой. Но в этом случае BMC с интерфейсом IPMI предлагает отличную реализацию STONITH — автоматизацию контроля исключительного доступа к ресурсам (т.н. fencing), и опять же дополнительная плата за эту штуку в сервере может быть рентабельной.
И если посчтитать, во что обойдётся малому бизнесу простой, связанный с выездом админа, всегда получается, что дешевле доплатить за серверную платформу. Даже с учётом глюков этих ваших BMC. Для крупных бизнесов могут быть детали — там где у тебя кластер 100 нод с автоматической балансировкой, бывает не так важно следить за каждой отдельной нодой. Но в этом случае BMC с интерфейсом IPMI предлагает отличную реализацию STONITH — автоматизацию контроля исключительного доступа к ресурсам (т.н. fencing), и опять же дополнительная плата за эту штуку в сервере может быть рентабельной.
Лично я сталкивался один раз за всю жизнь. Упс хороший, апс тысячник, не срабатывал только автотрансформатор для повышенного/пониженного напряжения в сети. Если всё отрубалось насовсем, отлично питал от батарей. За ремонт просили 5000р. Мы поставили перед ним недорогой электронный стабилизатор за 1000р и так эта парочка служит верой и правдой уже больше пяти лет.
Впрочем, после какого-то времени реле в упсе перестало глючить, но всё равно этому упсу я уже не доверяю.
Впрочем, после какого-то времени реле в упсе перестало глючить, но всё равно этому упсу я уже не доверяю.
проблем 2:
— перегорание обмотки
— залипание контактов
Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.
— перегорание обмотки
— залипание контактов
Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.
спасибо. а что используется на брендовых девайсах?
Внезапно: как часто такое реле будет срабатывать IRL?
Бывает и часто. У нас был случай(именно по этому реле) когда из-за программной ошибки оно должно было сработать около 5000 раз за 16 дней (попало на праздники и не могли попасть в помещение где стояла станция). Но, судя по логам, перезагрузки прекратились (контакты залипли) на ~1500 сработках. При этом по заявлению производителя цифры сработок даже не в 5-м порядке.
Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?
Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?
«зачем доверять production сервер» фигулинке под usb? Как минимум, что-то сетевое, не?
«зачем доверять production сервер» фигулинке под usb?
Не только под usb. Те самые перезагрузки постом выше вызваны устройством включенным в LPT, но при этом забыли учесть в какое состояние переходит lpt при перезагрузке. В итоге рекурсивно перезагружали сами себя.
Как минимум, что-то сетевое, не?
Не обязательно. Зависит от бюджета и задачи.
Для кровавого ентерпрайза есть готовые брендонутые решения — PDU
http://www.42u.com/power/rack-pdu/apc-rack-pdu.htm — как пример
http://www.42u.com/power/rack-pdu/apc-rack-pdu.htm — как пример
не вопрос, есть, пользую подобные регулярно, но чуть дороже оне ;)
Ну оно конечно дорого-бохато, но больше плюшек + надежность получше (если конечно забыть про «лехендарити реляябилить [censored]» продукцию) + гарантия и т.д. Ставить такое в «одна стройка гдето в каморке с китайским сплитом» не очень разумно, но в масштабах «сириоус бизнесс» — почему бы и нет?
в упор не понимаю такой огромной стоимости. Ну никак.
сделать такую электронику самому оказывается где-то в районе 2000р и сразу с вайфаем
сделать такую электронику самому оказывается где-то в районе 2000р и сразу с вайфаем
Большинству людей не нужна железка, а нужно решение проблемы. С красивой презентацией, девушкой, ответившей «Ваш звонок очень важен, перевожу вас на специалиста», бухгалтерскими документами и NBD-заменой проблемного оборудования.
Ну оно не только умеет «вкл-выкл» делать, оно ещё графики потребляемой мощности умеет строит, интегрируется в структуру датацентра нажатием пары кнопок, позволяет реализовать тот самый power budget и т.д., ну и ещё +100-200% за бренд нейм.
Вставлю пять копеек на тему ребута: в Debian Jessie до недавнего времени был баг [2]. Если SWAP переполнен, то машина при перезагрузке висела на «Reached target Shutdown». Лечится обновлением systemd до 215-17+deb8u4 (сейчас лежит в репозитории).
Если кто-то ещё не обновился — есть повод.
Если кто-то ещё не обновился — есть повод.
А про «как ВЫКЛЮЧИТЬ сервер? И как его потом включить?» у Вас статьи случайно нет на подходе?
Имел как-то неск шкафов серверов на двух больших бесперебойниках (вся сеть большого вуза плюс все его внешние сервисы (в т.ч. почта и все сайты всех подразделений) плюс куча вобще непойми чего) — и решал задачку — как их выключать при «конце света», что бы наиболее значимые сервисы работали как можно дольше, и главное — что бы это всё без проблем назад поднималось при появлении питания в любой момент последовательности их гашения. и соотв в какой последовательности их поднимать, и как перескакивать с середины последовательности «подъёма» или «гашения» назад в нужную точку последовательости соотвественно «гашения» или «подъёма».
В общем, электричество меня победило (через конидционер), и крупный ВУЗ остался без сайта в разгар приёмной кампании на где-то лишние сутки, чем могло бы быть при сидении человека в серверной круглосуточно (вуз сам при этом был обесточен, т.е. ко мне претензий никаких) (ну и без леса доменов на пару часов после начала рабочего понедельника тоже понервничал народ… особо что оказалось что туда же наблюдение периметра было завязано (не само, а дамп) )
(Впрочем мне самому сейчас это совершенно не актуально, но вы умеете писать «закрывая проблему»)
Имел как-то неск шкафов серверов на двух больших бесперебойниках (вся сеть большого вуза плюс все его внешние сервисы (в т.ч. почта и все сайты всех подразделений) плюс куча вобще непойми чего) — и решал задачку — как их выключать при «конце света», что бы наиболее значимые сервисы работали как можно дольше, и главное — что бы это всё без проблем назад поднималось при появлении питания в любой момент последовательности их гашения. и соотв в какой последовательности их поднимать, и как перескакивать с середины последовательности «подъёма» или «гашения» назад в нужную точку последовательости соотвественно «гашения» или «подъёма».
В общем, электричество меня победило (через конидционер), и крупный ВУЗ остался без сайта в разгар приёмной кампании на где-то лишние сутки, чем могло бы быть при сидении человека в серверной круглосуточно (вуз сам при этом был обесточен, т.е. ко мне претензий никаких) (ну и без леса доменов на пару часов после начала рабочего понедельника тоже понервничал народ… особо что оказалось что туда же наблюдение периметра было завязано (не само, а дамп) )
(Впрочем мне самому сейчас это совершенно не актуально, но вы умеете писать «закрывая проблему»)
Вообще, у всех уважающих себя серверов есть в биосе указание, что делать при появлении питания.
Как бы это сделал я:
на одном сервере включил бы «включаться по появлению питания», на остальных «не включаться после появления питания». На этом «одном» был бы скрипт, который по ipmi включал/выключал остальные сервера (сам ipmi ест мало). Если «один» звучит ненадёжно, пусть два.
Дальше вопрос в программировании логики сигналов от упсов.
А для энтерпрайза оно есть готовое — «стойки с power budget». Внутри стойки задаются приоритеты, и если сервера вылетают за budged, то гасятся самые ненужные (малоприоритетные). Дальше просто: пропал основной ввод — понижаем power budged. Появился — повышаем.
Как бы это сделал я:
на одном сервере включил бы «включаться по появлению питания», на остальных «не включаться после появления питания». На этом «одном» был бы скрипт, который по ipmi включал/выключал остальные сервера (сам ipmi ест мало). Если «один» звучит ненадёжно, пусть два.
Дальше вопрос в программировании логики сигналов от упсов.
А для энтерпрайза оно есть готовое — «стойки с power budget». Внутри стойки задаются приоритеты, и если сервера вылетают за budged, то гасятся самые ненужные (малоприоритетные). Дальше просто: пропал основной ввод — понижаем power budged. Появился — повышаем.
Ок, спасибо, если вы только сейчас про эту задачку задумались — то не надо, там много подводных граблей разных, которые обычно обходят подальше повышением надёжности питания, что бы в ситуацию «свет есть/нет» с хаотичным периодом от минут до неск.часов всю неделю — не попадать.
И это правильно — плохую инфраструктуру надо исправлять, а не подлаживаться к ней, изобретая УАЗики… Отменяю вопрос.
И это правильно — плохую инфраструктуру надо исправлять, а не подлаживаться к ней, изобретая УАЗики… Отменяю вопрос.
del
Обычно в «больших бесперебойниках» есть SNMP-карта. При инсталяции должны были бы подключены в сеть и настроены. К слову ими же можно и передернуть питание в крайнем случае. Если же UPS простые, то можно использовать управление через MOXA NPort — асинхронные сервера RS-232 в Ethernet
Баги в прошивке блоков питания исправляют, их нужно прошивать.
Там ещё дурная процедура обновления — сервер выключается на 10 минут не подавая признаков жизни и трогать его в это время нельзя, иначе придётся звонить в поддержку для замены БП.
Добавлю свои 5 копеек. Есть еще интересные решения из мира кластеров, представляют собой многоуровневый внешний watchdog, в документации чаще всего обозначаются как fencing/stonith. Принцип работы такой, внешний сервер/сервера проверяют доступность группы подконтрольных серверов по некоторому сценарию, если сценарий вызывает сбой посылается команда аппаратного ребута, если сервер не вышел на связь втечении установленного таймера, посылается команда ребута через IPMI, снова проблема (повис IPMI — привет iDrac6 и ранее с систематическими подвисаниями, а также пламенный привет supermicro), команда идет на управляемую розетку которая передернет блоки питания, снова ничего, помечаем сервер полностью дохлым и запускает сценарий поднятия замены из горячего списка не занятых серверов. На практике очень спасают от дальней дороги или судорожного поиска адекватных рук в какой-нибудь заднице мира с изолированной крупной площадкой. Послал в ребут полудохлый сервер, если через 15 минут не вернулся, ну и хрен с ним, при плановом обслуживании инженеры разберутся что с ним было, а на замене уже крутится его копия.
Хорошая информация, молодец, побольше бы таких инфа Спасибо
Спасибо. Вроде всё где-то известно, ничего кардинально нового, но вот так собрано и разжевано — это очень полезно.
Была раз ситуация с «отвалившимся» диском. SSH-консоль работала, а далее… ну что-то работало, что-то нет. Нужно было или получать доступ до железа «ногами», или рискнуть и ребутнуть сервер, в надежде что диск оживет, а там уже дальше думать.
reboot -f не получался, так как ФС отвалилась, и работало только то, что в кэше уже. Пришлось скачать бинарник reboot'a с соседнего сервера и запустить его. Не помню, чем получилось, wget-ом или scp (кто-то из них был в кэше), но в общем повезло в тот раз. И диск даже ожил, удалось все скопировать, и позже, в рабочее время, поменять диски.
Второй интересный случай был: стояло 2 сервера в одном помещении.Один начал периодически фризиться, причем проблема с железом была. Пока запустили канитель с закупкой нового сервера, старый продолжал работать. Но хотелось бы его ребутать в случае фриза без посещения его посреди ночи ногами.
Решение: подключил управление ИБП от сервера А к серверу В, а управление сервера В — к серверу А. Сервер В периодически пинговал сервер А, и если не было ответа — давал команду ИБП на power cycle. При этом перегружался сервер А. Получилось вроде IP-розетки.
reboot -f не получался, так как ФС отвалилась, и работало только то, что в кэше уже. Пришлось скачать бинарник reboot'a с соседнего сервера и запустить его. Не помню, чем получилось, wget-ом или scp (кто-то из них был в кэше), но в общем повезло в тот раз. И диск даже ожил, удалось все скопировать, и позже, в рабочее время, поменять диски.
Второй интересный случай был: стояло 2 сервера в одном помещении.Один начал периодически фризиться, причем проблема с железом была. Пока запустили канитель с закупкой нового сервера, старый продолжал работать. Но хотелось бы его ребутать в случае фриза без посещения его посреди ночи ногами.
Решение: подключил управление ИБП от сервера А к серверу В, а управление сервера В — к серверу А. Сервер В периодически пинговал сервер А, и если не было ответа — давал команду ИБП на power cycle. При этом перегружался сервер А. Получилось вроде IP-розетки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как перезагрузить сервер?