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

    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).

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

    Во-вторых, может возникнуть проблема с отмонтированием файловых систем. Считается, что достаточно «убить» все процессы, и отмонтировать диск будет легко — его же никто не использует. Но, это, мягко говоря, не так. Вот потенциальные методы «прибить 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-розетку
    Поделиться публикацией
    Комментарии 82
      0
      Спасибо, как всегда хорошая статья. О 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
      Т.е. на машине-мамке в случае отвала фс подложить одноразово файлик с именем машины и удаленная машина перегрузится(главное не забыть удалить этот файл).
        0
        Это называется watchdog.

        В софте: http://linux.die.net/man/8/watchdog
        В ipmi: https://www.ibm.com/support/knowledgecenter/linuxonibm/liaai.ipmi/liaaiipmiwatchdog.htm
          0
          спасибо, про watchdog я в курсе. но это не то же самое, что я предложил.
          так рассуждая, можно всю вашу статью сократить до «reboot, если не помогло, то правильно настроенный watchdog сам потом перезагрузит машину.»
            0
            Ребут приходится делать руками потому что неожиданно, плюс надо понять, какой. reverse-sysrq — это и есть вотчдог, только в форме однострочника и зависящий от работоспособности кучи компонент. Что делать, если wget уйдёт в D+ и не вернётся?
              0
              ну так и тут так же — руками. подложить руками файл на удаленном сервере, чтобы локальная машина поняла, что надо перегрузиться.
              а почему он должен уйти в D? он один раз считался с диска при запуске и бесконечно долго работает в цикле.
              разве что в начальном сообщении я не предусмотрел -O /dev/null.

                0
                он один раз считался с диска при запуске и бесконечно долго работает в цикле.
                Он каждый раз запускается заново, а останется ли он в файловом кэше на момент очередного запуска — вопрос
                  0
                  --tries inf

                  я полагал, что wget будет бесконечно долго с этой опцией ломиться на сервер, пока не получит 200, однако это не так. ну, значит надо какой-то другой бинарь использовать, сути не меняет.
                    0
                    Вы все предполагаете, что wget вам вернёт что-то. А он может умереть навсегда не завершаясь даже по kill -9. TASK_UNINTERRUPTIBLE и всё такое.
        0
        Давно-давно читал, что reboot использовать не кошерно, а надо использовать 'shutdown -r'.
        В чем же тогда разница между reboot и 'shutdown -r'?
          +1
          Насколько я знаю, с точки зрения самого ребута, никакой. shutdown просто позволяет его (ребут) запланировать и разослать с помощью wall сообщение на все терминалки о предстоящем ребуте.
            +1
            reboot использовать не кошерно, а надо использовать 'shutdown -r'

            Это справедливо для FreeBSD, при неаварийной перезагрузке нужно использовать shutdown -r
            При этом сначала быдет выполняться /etc/rc.shutdown для корректного завершения процессов.
            При reboot просто всем пошлётся sigterm, подождёт (по дефолту вроде 30 сек), потом sigkill
              0
              кусочек 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.
              +8
              Добавлю, что на машинах с UEFI есть возможность вызвать перезагрузку вызовом gRT->ResetSystem(), который не зависит от ядра и может выполнить даже power cycle reset, при условии, что БП не завис намертво. Доступен сервис на любой системе и без IPMI, но как достучаться до UEFI RT Services из ОС — вопрос отдельный.
                +1
                Вопрос: кто передаёт управление коду UEFI? Он же на локальном (основном) процессоре исполняется? Если ядро в этот момент сильно занято философией, оно может call/jmp туды и не сделать.
                  +1
                  Может, никто не спорит. Сделан этот сервис в первую очередь для того, чтобы предоставить абстракцию от конкретного способа выполнить этот самый Reset, а то этих способов за 30 лет развития архитектуры x86 накопилось столько, что не знаешь, за какой хвататься, и какие еще работают (IO port 0xCF9), какие уже 10 лет устаревают (IO port 0x92), а какие наконец-то устарели совсем (IO port 0x64).
                    –1
                    Вы уходите в программистские вопросы. Внутри всё это приводит к отправке RST по всем шинам, какие есть. После этого сам компьютер ребутится. Воткнутые HBA — уже под вопросом, хотя чаще всего, да. HBA посылают RST по шинам, и вот тут-то вот есть полная свобода этот rst игнорировать.

                    У админов на этот случай есть расширенный набор костылей — ipmi, розетки, etc. А чтобы echo b> /proc/sysrq-trigger не сработало для ребута самого хоста — я такого в реальной жизни даже и не припомню.
                      +1
                      Зато я видел пару раз, хоть и не на серверах. Чтобы выполнить перезагрузку, ядро должно знать, как это делается на конкретном железе, и иногда это знание его подводит в случае, если железо новое, странное или просто глючное.
                      Вот тут хорошо видно, как на x86 происходит перезагрузка: сначала пробуем ACPI Reset, не вышло — KB Reset, не получилось и это — EFI Reset (вышеупомянутый сервис), не вышло и это — CMOS Reset, затем PCI Reset, не случился и он — сбрасываем IDT и инициируем отладочное прерывание INT3, а если и это не помогло — пробуем все снова. Редкая нормальная система переживет такое не перезагрузившись, но я могу предстваить пару конфигураций, которые все-таки смогли бы. Вот поэтому Runtime-сервис и ввели, чтобы не угадывать, какой ресет у нас сегодня работает, а какой вместо ресета зависает намертво, как это происходит на BayTrail и KB Reset'ом иногда.
                        0
                        Тыг я и говорю, это разные задачи. В ядре задача «таки убедить сервер ребутнуться», а у админа задача «чтобы оно перестало глючить». Даже если мы через ACPI с первой попытке центральную часть системы ребутнули, это не означает, что процессор в enclosure, через которые HBA видит диски, захочет переинициализироваться. Может, у неё там важный таймаут всё никак не истечёт. Или прерывание за прерывание запнулось.
                          0
                          Опять не же согласен. Из моей практики самые неприятные для перезагрузки устройства — клиентские хреновины на FPGA. Продолжительность ресета у них непредсказуемая, а на сам сигнал они реагируют как хотят. Не успел проинициализироваться — отвалился от PCIe. В результате приходится городить разные костыли вплоть до POST-таймаутов и многоканальных вотчдогов, все для того, чтобы «перестало глючить».
                            0
                            Ну, это тоже. Но если между «клиентской хреновиной» и компьютером простой шнурок (scsi, fc, etc), то перезагрузка при ребуте сервера может быть только добровольной. Проблема в том, что архитектурно jbod'ы считаются частью сервера, а по сути — отдельные компьютеры без какого-либо доступа к фирмвари (внутри enclosure) и возможности передёрнуть питание/послать аппаратный reset.
                          0
                          Огромное спасибо вам за комментарий. Я как-то не задавался вопросом, как в ядре вызывается reboot и поэтому относился к зависанию старенького ASUS K80N при попытке уйти в перезагрузку как к неизбежному злу. После передачи ядру параметра reboot=p ноутбук стал перезагружаться нормально.
                  0
                  Замечание: кажующееся правильным в этой ситуации „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“.
                    0
                    Это возможно только если есть доступ к локальной консоли. Автор же рассматривает случай, когда локального доступа нет. В таком случае команда S может вызвать зависание этой консоли, т.к. ядро попытается засинхронизировать ФС отвалившегося диска. Так что и консоли больше не станет, и ребут не произойдет.
                      +2
                      Ещё хуже, оно может начать общаться с умирающим контроллером и окончательно зависнуть. Например, устроив CMB storm или ещё что-то такое.
                        0
                        Да, IPMI с выделенным NIC — наше все.
                        0
                        «Нажимать» на SysRq можно удаленно через /proc/sysrq-trigger, о чем и сказано в статье ))
                      0
                      ipt_SYSRQ опасная штука, я смотрю. Используете на проде? Как правильно чтобы никто посторонний не добрался?
                        0
                        Там же пароль можно задать. Не опаснее, чем ssh server sudo reboot
                          0
                          Там на сайте написано, что оно уязвимо к реплэй атакам.
                            0
                            Значит пароль нужно менять на случайный при старте системы, и сообщать наружу новый.
                        0
                        Контроллер BMC, реализующий IPMI, может управляться снаружи более непосредственным способом, чем ipmitool (например, через упомянутую веб-морду). Из статьи не очень понятно, зачем для описанной задачи к нему тянуться таким сложным путём, через умирающую систему.
                          0
                          Открытие веб-морды всегда такое мучительное. Кроме того, оно не всегда тривиальное (например, необходимость подключаться к VPN, искать логин-пароль, выяснять IP-адрес IPMI'я для _ДАННОГО_СЕРВЕРА_ — мы все знаем, как важно их не перепутать, но риск всё равно остаётся). Локальный ipmi надёжнее и проще. Если работает. Если нет — сваливаемся на сложный путь.
                          0
                          Спасибо за статью.
                          Исправьте пожалуйста DRAC на iDRAC.
                          Или можно DRAC/iDRAC, а то Dell обидится.
                            +1
                            Не с эргономикой racadm'а обижаться на пользователей.
                            0
                            Спасибо за годную статью.
                            Можете уточнить, shutdown -r действует аналогично reboot?

                            И про halt и init 6 в статье ни слова, к сожалению.
                              0
                              Это всё примерно одно и то же (кроме того, что halt не перезагружает, а останавливает машину).
                                0
                                Про shutdown -r был ниже комментарий, что так правильно в FreeBSD делать. Собственно, у меня опыт начинался именно с неё, поэтому и запоминалось.
                              0
                              masterkit.ru/shop/smarthome/usb/1319335 и никаких корявых ipmi ;)
                                0
                                Эм… Я понимаю шутку, но я с трудом себе такое представляю в серверной среде.
                                  0
                                  это не шутка, это недорогая замена брендовым power control. есть подобные устройства, чуть дороже, уже в корпусе, но суть та же.
                                    0
                                    Коммутируемые токи 2 А — маловато будет.
                                      0
                                      кхм, 220*2=440Вт, нет? у меня нода с i7-4790/24GB/SSD + IB (к storage) потребляет в пике не больше 100Вт.
                                        0
                                        440Вт — на практике, большинство современных серверов жрут меньше. Для интереса, первый попавшийся лабораторный R530, занятый «ничем» — 210Вт, 0.9А, при historical peak — 279Вт. А это всё-таки довольно жирнющий сервер с 8 SSD'ами в рейде. Для «самосерверов» на базе десктопных процов с 2-4 жёстких диска — более чем достаточно.
                                          0
                                          Практика — очень растяжимая штука. У одних нормой является сервер с парой 2620 с двумя дисками, у других — пара 2690 с 16 модулями памяти, у третьих «гробики» на несколько десятков хардов.

                                          Но для большинства неспецифических применений подойдет, наверное. Главное — чтобы оно не дохло само.
                                          0
                                          Да дело даже не в 2А-ом токе. Доверять управление сервером электромеханической релюшке (включенной в другой сервер?) можно только если уж совсем ничего ценнго на управляемом сервере нет.
                                          Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.
                                            0
                                            а что не так с электромеханическим реле?
                                              0
                                              Контакты могут залипнуть. Не сталкивались с глючащими UPS'ами?
                                              Ограничение 2А по току можно обойти навесив цепочкой твердотельное реле с интересующими характеристиками.
                                                0
                                                я лично не сталкивался. и люди все еще продолжают пользовать UPS'ы, вроде? штуки типа IMPI _кажутся_ мне менее надежными…
                                                  0
                                                  IPMI. И это очень, очень, очень хорошая штука для экстренного управления сервером. Собственно, принципиальная разница между серверной платформой, даже начального уровня, и производительным десктопом — как раз именно этот BMC, позволяющий удалённо решить самые неприятные проблемы.

                                                  И если посчтитать, во что обойдётся малому бизнесу простой, связанный с выездом админа, всегда получается, что дешевле доплатить за серверную платформу. Даже с учётом глюков этих ваших BMC. Для крупных бизнесов могут быть детали — там где у тебя кластер 100 нод с автоматической балансировкой, бывает не так важно следить за каждой отдельной нодой. Но в этом случае BMC с интерфейсом IPMI предлагает отличную реализацию STONITH — автоматизацию контроля исключительного доступа к ресурсам (т.н. fencing), и опять же дополнительная плата за эту штуку в сервере может быть рентабельной.
                                                    0
                                                    Чисто формально, у крупного бизнеса всё в ДЦ, а в ДЦ есть дежурная смена. Это не отменяет удобств от IPMI, конечно.
                                                  0
                                                  Лично я сталкивался один раз за всю жизнь. Упс хороший, апс тысячник, не срабатывал только автотрансформатор для повышенного/пониженного напряжения в сети. Если всё отрубалось насовсем, отлично питал от батарей. За ремонт просили 5000р. Мы поставили перед ним недорогой электронный стабилизатор за 1000р и так эта парочка служит верой и правдой уже больше пяти лет.

                                                  Впрочем, после какого-то времени реле в упсе перестало глючить, но всё равно этому упсу я уже не доверяю.
                                                    0
                                                    Простых APC'шек с дефектами реле повидал уйму, 1000\1500 штук 5-7 точно. Это реально распространенная проблема.
                                                  +2
                                                  проблем 2:
                                                  — перегорание обмотки
                                                  — залипание контактов
                                                  Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
                                                  PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.
                                                    0
                                                    спасибо. а что используется на брендовых девайсах?
                                                      0
                                                      На самом деле даже бренды типа kramer и сейчас используют электромеханические реле, но это скорее дань долгосрочным договорным обязательствам. Исключением могут служить ртутные герконы.
                                                      В остальном, если не крично сопротивление замкнутой контактами цепи, альтернативы твердотельным реле нет.
                                                      0
                                                      Внезапно: как часто такое реле будет срабатывать IRL?
                                                        0
                                                        Бывает и часто. У нас был случай(именно по этому реле) когда из-за программной ошибки оно должно было сработать около 5000 раз за 16 дней (попало на праздники и не могли попасть в помещение где стояла станция). Но, судя по логам, перезагрузки прекратились (контакты залипли) на ~1500 сработках. При этом по заявлению производителя цифры сработок даже не в 5-м порядке.
                                                        Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?
                                                          0
                                                          «зачем доверять production сервер» фигулинке под usb? Как минимум, что-то сетевое, не?
                                                            0
                                                            «зачем доверять production сервер» фигулинке под usb?

                                                            Не только под usb. Те самые перезагрузки постом выше вызваны устройством включенным в LPT, но при этом забыли учесть в какое состояние переходит lpt при перезагрузке. В итоге рекурсивно перезагружали сами себя.
                                                            Как минимум, что-то сетевое, не?

                                                            Не обязательно. Зависит от бюджета и задачи.
                                            0
                                            Для кровавого ентерпрайза есть готовые брендонутые решения — PDU
                                            http://www.42u.com/power/rack-pdu/apc-rack-pdu.htm — как пример
                                              0
                                              не вопрос, есть, пользую подобные регулярно, но чуть дороже оне ;)
                                                0
                                                Ну оно конечно дорого-бохато, но больше плюшек + надежность получше (если конечно забыть про «лехендарити реляябилить [censored]» продукцию) + гарантия и т.д. Ставить такое в «одна стройка гдето в каморке с китайским сплитом» не очень разумно, но в масштабах «сириоус бизнесс» — почему бы и нет?
                                                  0
                                                  в упор не понимаю такой огромной стоимости. Ну никак.

                                                  сделать такую электронику самому оказывается где-то в районе 2000р и сразу с вайфаем
                                                    0
                                                    Большинству людей не нужна железка, а нужно решение проблемы. С красивой презентацией, девушкой, ответившей «Ваш звонок очень важен, перевожу вас на специалиста», бухгалтерскими документами и NBD-заменой проблемного оборудования.
                                                      0
                                                      Ну оно не только умеет «вкл-выкл» делать, оно ещё графики потребляемой мощности умеет строит, интегрируется в структуру датацентра нажатием пары кнопок, позволяет реализовать тот самый power budget и т.д., ну и ещё +100-200% за бренд нейм.
                                                        0
                                                        Насчёт «интеграции парой кнопок» — это вы сильно преуменьшаете. В остальном — да.
                                                          0
                                                          Ну иногда случается вариант «воткнули, поставили галочку „Enable c001 pdu4u“, всё заработало». У меня это было с KVMами от avocent, подрубили PDU, сказали квму, что он там есть, на этом настройка завершилась, весь софт её понял и добавил приятных кнопочек.
                                                +4
                                                Вставлю пять копеек на тему ребута: в Debian Jessie до недавнего времени был баг [2]. Если SWAP переполнен, то машина при перезагрузке висела на «Reached target Shutdown». Лечится обновлением systemd до 215-17+deb8u4 (сейчас лежит в репозитории).
                                                Если кто-то ещё не обновился — есть повод.
                                                  0
                                                  Серьёзненько. Спасибо.
                                                  0
                                                  А про «как ВЫКЛЮЧИТЬ сервер? И как его потом включить?» у Вас статьи случайно нет на подходе?

                                                  Имел как-то неск шкафов серверов на двух больших бесперебойниках (вся сеть большого вуза плюс все его внешние сервисы (в т.ч. почта и все сайты всех подразделений) плюс куча вобще непойми чего) — и решал задачку — как их выключать при «конце света», что бы наиболее значимые сервисы работали как можно дольше, и главное — что бы это всё без проблем назад поднималось при появлении питания в любой момент последовательности их гашения. и соотв в какой последовательности их поднимать, и как перескакивать с середины последовательности «подъёма» или «гашения» назад в нужную точку последовательости соотвественно «гашения» или «подъёма».
                                                  В общем, электричество меня победило (через конидционер), и крупный ВУЗ остался без сайта в разгар приёмной кампании на где-то лишние сутки, чем могло бы быть при сидении человека в серверной круглосуточно (вуз сам при этом был обесточен, т.е. ко мне претензий никаких) (ну и без леса доменов на пару часов после начала рабочего понедельника тоже понервничал народ… особо что оказалось что туда же наблюдение периметра было завязано (не само, а дамп) )

                                                  (Впрочем мне самому сейчас это совершенно не актуально, но вы умеете писать «закрывая проблему»)
                                                    +5
                                                    Вообще, у всех уважающих себя серверов есть в биосе указание, что делать при появлении питания.

                                                    Как бы это сделал я:

                                                    на одном сервере включил бы «включаться по появлению питания», на остальных «не включаться после появления питания». На этом «одном» был бы скрипт, который по ipmi включал/выключал остальные сервера (сам ipmi ест мало). Если «один» звучит ненадёжно, пусть два.

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

                                                    А для энтерпрайза оно есть готовое — «стойки с power budget». Внутри стойки задаются приоритеты, и если сервера вылетают за budged, то гасятся самые ненужные (малоприоритетные). Дальше просто: пропал основной ввод — понижаем power budged. Появился — повышаем.
                                                      0
                                                      Ок, спасибо, если вы только сейчас про эту задачку задумались — то не надо, там много подводных граблей разных, которые обычно обходят подальше повышением надёжности питания, что бы в ситуацию «свет есть/нет» с хаотичным периодом от минут до неск.часов всю неделю — не попадать.
                                                      И это правильно — плохую инфраструктуру надо исправлять, а не подлаживаться к ней, изобретая УАЗики… Отменяю вопрос.
                                                      0
                                                      del
                                                        0
                                                        Обычно в «больших бесперебойниках» есть SNMP-карта. При инсталяции должны были бы подключены в сеть и настроены. К слову ими же можно и передернуть питание в крайнем случае. Если же UPS простые, то можно использовать управление через MOXA NPort — асинхронные сервера RS-232 в Ethernet
                                                          0
                                                          Даже небольшие ИБП обычно отдают питание ветками через C20, так что лучше обзавестись управляемым PDU (чтобы не дёргать всю стойку).
                                                        +1
                                                        Баги в прошивке блоков питания исправляют, их нужно прошивать.

                                                        Там ещё дурная процедура обновления — сервер выключается на 10 минут не подавая признаков жизни и трогать его в это время нельзя, иначе придётся звонить в поддержку для замены БП.
                                                          +2
                                                          Добавлю свои 5 копеек. Есть еще интересные решения из мира кластеров, представляют собой многоуровневый внешний watchdog, в документации чаще всего обозначаются как fencing/stonith. Принцип работы такой, внешний сервер/сервера проверяют доступность группы подконтрольных серверов по некоторому сценарию, если сценарий вызывает сбой посылается команда аппаратного ребута, если сервер не вышел на связь втечении установленного таймера, посылается команда ребута через IPMI, снова проблема (повис IPMI — привет iDrac6 и ранее с систематическими подвисаниями, а также пламенный привет supermicro), команда идет на управляемую розетку которая передернет блоки питания, снова ничего, помечаем сервер полностью дохлым и запускает сценарий поднятия замены из горячего списка не занятых серверов. На практике очень спасают от дальней дороги или судорожного поиска адекватных рук в какой-нибудь заднице мира с изолированной крупной площадкой. Послал в ребут полудохлый сервер, если через 15 минут не вернулся, ну и хрен с ним, при плановом обслуживании инженеры разберутся что с ним было, а на замене уже крутится его копия.
                                                            0
                                                            Хорошая информация, молодец, побольше бы таких инфа Спасибо
                                                              0
                                                              Спасибо. Вроде всё где-то известно, ничего кардинально нового, но вот так собрано и разжевано — это очень полезно.
                                                                +1
                                                                Была раз ситуация с «отвалившимся» диском. SSH-консоль работала, а далее… ну что-то работало, что-то нет. Нужно было или получать доступ до железа «ногами», или рискнуть и ребутнуть сервер, в надежде что диск оживет, а там уже дальше думать.
                                                                reboot -f не получался, так как ФС отвалилась, и работало только то, что в кэше уже. Пришлось скачать бинарник reboot'a с соседнего сервера и запустить его. Не помню, чем получилось, wget-ом или scp (кто-то из них был в кэше), но в общем повезло в тот раз. И диск даже ожил, удалось все скопировать, и позже, в рабочее время, поменять диски.

                                                                Второй интересный случай был: стояло 2 сервера в одном помещении.Один начал периодически фризиться, причем проблема с железом была. Пока запустили канитель с закупкой нового сервера, старый продолжал работать. Но хотелось бы его ребутать в случае фриза без посещения его посреди ночи ногами.

                                                                Решение: подключил управление ИБП от сервера А к серверу В, а управление сервера В — к серверу А. Сервер В периодически пинговал сервер А, и если не было ответа — давал команду ИБП на power cycle. При этом перегружался сервер А. Получилось вроде IP-розетки.
                                                                  0
                                                                  Классическая ситуация для echo b >/proc/sysrq-trigger
                                                                    0
                                                                    Абсолютно согласен, но тогда я еще не знал, что так можно :)

                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                Самое читаемое