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 сесії не закриті, дискові кеши не скинуто. Однак, ядро все-таки виконує якісь рухи в районі ребута (і, можливо, частина кешей буде скинута). Головне ж - в процесі ребута буде задіяна велика частина ядра. І це означає, що якщо ядру поплохело, то ми можемо і не повернутися назад.
Буває так, що на сервер залишилася відкрита тільки одна консоль (а друга вже не відкривається). Чому? Тому що хто-то что-то подхимичиться з драйвером дисків. Або рейд-контролером. Або ще чимось, після чого від '/' залишаються тільки спогади в дисковому кеші. Це означає, що у нас є тільки команди bash'а (вбудовані), які виконуються без запуску нових процесів.
Існує метод перезавантаження, який не вимагає виконання будь-яких виконуваних файлів (тобто читання з відсутнього диска). Це (від рута): echo b> / proc / sysrq-trigger. Файл sysrq-trigger дозволяє "натиснути" будь-яку кнопку з SysRq комбінацій (аварійні кнопки ядра). У тому числі і SysRq-b, тобто аварійний "reboot". Часто буває так, що після натискання enter навіть не встигає з'явитися новий рядок - сервер вже в ребут до того, як syscall повернувся. Це найсильніше з софтового, що є для ребута.
Зауваження: кажующееся правильним в цій ситуації "sync, reboot", тобто SysRq-s, SysRq-B це помилка, тому що після SysRq-S, ядро може спробувати почати спілкуватися з порожнім безліччю, і, потенційно, впасти в паніку або відламати вам останню з доступних консолей. Якщо робиться аварійний ребут - він повинен бути аварійним
Це все працює, якщо у вас є консоль на сервер. А якщо логін висне і відкритої консолі немає? Є модуль ipt_SYSRQ. дозволяє виконати sysrq запити щодо отримання певного мережевого пакету (точніше, за правилом iptables). Працює цілком в ядрі, тобто від FS не залежить. До нього ж додається команда send_sysrq.
сторож для сторожа
Можна було б подумати, що на цьому "все", але бувають ще більш неприємні зависання. Наприклад, зависла мережева карта. І звичайний reboot (в т.ч. через sysrq) не допомагає. Другим прикладом таких поганої ситуації буває зависання enclosure, яка залипнула на поганому диску і ігнорує всі bus reset. Перезавантаження начебто все скидає, а диски недоступні.
У цьому випадку нам потрібен power cycle (включити / виключити). Фізично бігати до сервера не цікаво, так що можна подивитися на можливості сучасних серверів: IPMI. Це встренний мікрокомп'ютер, що дозволяє управляти "великим" комп'ютером. Він зазвичай називається IPMI, DRAC, iLO, etc.
Інтрес нас команда: ipmitool chassis power cycle. Вона більш вимоглива до працездатності системи (повинні бути завантажені модулі ядра, сам ipmitool повинен успішно запуститися, ipmi повинен бути робочим і т.д.). Але зате вона дозволяє пересмикнути по харчуванню всіх. Точніше, майже всіх - якщо у сервера є jbod'и, то до них ця команда не доходить. Але, все-таки, це дуже добротний і хороший ребут.
Якщо ядро зовсім стало погано, то команду можна виконати і віддалено (ipmitool -H ipmi.server.local chassis power cycle)
Наступна точка "болю" - це зависающие блоки живлення. Так, таке буває. Баги в прошивці блоків живлення виправляють, їх потрібно прошивати. Зрозуміло, будь-які м'які ребут (такі як ipmi power cycle) в цій ситуації не працюють. Потрібно або фізично тикати кабель, або пересмикувати харчування віддалено. У цій ситуації допомагає IP-розетка.
Виглядає це приблизно так (фрагмент панелі управління для servers.com/servers.ru):
Очевидно, в цих умовах ребут пройде по очёнь жорсткого сценарію, але точно пройде.