power cycle server что это

Перезагрузка по PoE или power-cycle-ping на Mikrotik

Итак, у нас есть PoE-коммутатор/маршрутизатор Mikrotik, к которому подключены и от которого запитаны некоторые устройства, имеющие склонность к зависанию (IP-камеры, телефоны, другие маршрутизаторы и т.п.). Обладая разумной степенью ленивости, мы, конечно же, не хотим перезагружать эти устройства руками, отключая их от PoE-коммутатора, к тому же этот процесс желательно вообще автоматизировать. К счастью, разработчики из Mikrotik, вероятно, тоже склонны к разумной лени, и ввели в RouterOS 6.33 функцию power-cycle-ping. Рассмотрим ее подробнее.

Управлять power-cycle-ping можно как из консоли, так и из графического интерфейса.

Консольный вариант:

/interface ethernet poe set LAN4 power-cycle-ping-enabled=yes power-cycle-ping-address=10.20.30.40 power-cycle-ping-timeout=60s power-cycle-interval=24h

Разберемся с синтаксисом:

Графический интерфейс:

Более подробное описание синтаксиса и функционала: http://wiki.mikrotik.com/wiki/Manual:PoE-Out

Таким образом в RouterOS 6.33, помимо багфиксов, мы получили очень неплохой инструмент, упрощающий управление нашими сетевыми ресурсами.

Источник

Использование IPMI

Для удобства такие опции IPMI, как перезагрузка и выключение сервера, а также возможность перезапуска консоли выведены и на главную страницу панели управления аккаунтом.

Подключение

Реквизиты доступа

Для доступа к IPMI необходимо использовать IP-адрес и реквизиты, полученные от наших специалистов. Они также доступны на главной странице панели управления. По умолчанию мы предоставляем пользователям доступ к IPMI уровня Operator. Он позволяет выполнять все необходимые действия с сервером, однако ограничивает часть функционала в целях безопасности. При возникновении сложностей в работе IPMI, которые вы не можете решить самостоятельно, пожалуйста, свяжитесь с нашей службой поддержки.

Подключиться к интерфейсу вы можете с помощью браузера или специальной утилиты IPMI View от SuperMicro.

Веб-интерфейс

Для использования веб-интерфейса необходимо кликнуть на ссылку «Перейти в IPMI» в панели управления либо вручную ввести в адресной строке IP-адрес IPMI и указать логин и пароль доступа.

Для корректного выхода из IPMI после завершения работы используйте кнопку Logout в верхнем правом углу перед закрытием окна браузера.

IPMI View

Для использования IPMI View ее необходимо скачать и установить.

Далее необходимо указать имя сервера (произвольное) и его IP-адрес.

Чтобы сервер сохранился в настройках при следующем запуске утилиты, нажмите на значок дискеты (опция «Save configuration»).

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

Основные операции

Управление питанием

В IPMIView управление питанием располагается на вкладке IPMI Device:

Здесь вам доступны следующие опции:

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

Работа с консолью

В IPMI View перейдите на вкладку KVM Console и нажмите Launch Console, после чего консоль будет запущена.

При первом запуске, вероятно, будет выведено уведомление от системы безопасности Java:

В этом случае вам необходимо внести IP-адрес IPMI (как по протоколу http://, так и https://) в исключения безопасности в настройках Java (подробная инструкция доступна на сайте Java). После вы сможете запустить консоль.

Особенности работы с консолью:

При возникновении проблем в работе консоли в первую очередь попробуйте выполнить ее перезапуск. Это можно сделать из вашей панели управления аккаунтом по кнопке «IKVM reset». Если проблема сохранится, свяжитесь с нами.

Подключение образа

При работе с консолью вы можете подключить образ ISO с вашего локального компьютера.

В открывшемся окне:

В поле «Статус» должно отобразиться сообщение об успешном подключении образа, после чего окно Virtual Storage можно закрыть. Далее необходимо перезагрузить сервер.

Иногда может потребоваться изменить порядок загрузки в BIOS сервера, чтобы загрузиться с ISO-образа. Это можно сделать так же, как при обычном физическом подключении к серверу.

Мониторинг

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

Источник

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

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

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

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

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

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

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

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

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

Выглядит это примерно так (фрагмент панели управления для servers.com/servers.ru):

Очевидно, в этих условиях ребут пройдёт по очёнь жёсткому сценарию, но точно пройдёт.

Источник

IPMI ― обзор технологии

Что такое IPMI

Аббревиатура IPMI расшифровывается как Intelligent Platform Management Interface (интеллектуальный интерфейс управления платформой). Через IPMI можно удаленно подключиться к серверу и управлять его работой:

IPMI хорош тем, что перечисленные выше функции доступны вне зависимости от работы процессора, BIOS или операционной системы (ОС) управляемой платформы. Например, можно удаленно перезагрузить сервер, если зависла ОС, или поискать причину выхода из строя CPU в журнале системных событий. Управлять можно даже выключенным сервером ― достаточно того, что сервер подключен к электрической сети.

После того как сервер смонтировали и подключили к сети, инженеры Selectel настраивают BIOS и IPMI. Дальше можно выйти из шумной серверной и продолжить настраивать оборудование удаленно. Как только первоначальная настройка закончена, клиенты Selectel могут управлять работой выделенных серверов и серверов произвольной конфигурации через IPMI.

Историческая справка

Первую версию спецификации IPMI v1.0 разработали совместно компании Intel, Dell, NEC и Hewlett-Packard в 1998 году. На практике обнаружились уязвимости и недостатки, которые исправили в последующих версиях IPMI v1.5 и v2.0.

Компании устанавливают свои цены на предоставляемую технологию. Если стоимость реализации IPMI увеличивается, цена аренды сервера растет, так как напрямую зависит от стоимости расходников.

Решения производителей отличаются между собой:

Хотя производители предоставляют измененный и доработанный IPMI, реализация его архитектуры остается схожей. Разберемся, из чего состоит технология, опираясь на официальную спецификацию компании Intel.

Базовые компоненты любого IPMI

Контроллеры управления

В центре архитектуры — «мозг» IPMI, микроконтроллер BMC (Baseboard Management Controller). Через него как раз и происходит удаленное управление сервером. По сути, BMC ― это отдельный компьютер со своим программным обеспечением и сетевым интерфейсом, который распаивают на материнской плате или подключают как плату расширения по шине PCI management bus.

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

К BMC можно подключить дополнительные контроллеры управления (Management Controllers, MCs), чтобы расширить возможности базового управления. Например, в то время как основная система управляется функциями BMC, MCs подключаются для мониторинга различных подсистем: резервных источников питания, RAID-накопителей, периферийных устройств.

MCs поставляются самостоятельными платами, отдельными от центрального BMC, поэтому их также называют Satellite Controllers. Дополнительных контроллеров может быть несколько, а вот центральный BMC — один.

К BMC контроллеры подключаются через интерфейс IPMB (Intelligent Platform Management Bus ― шина интеллектуального управления платформой). IPMB ― это шина на основе I2C (Inter-Integrated Circuit), по которой BMC перенаправляет команды управления к различным частям архитектуры:

Кроме передачи команд на BMC можно настроить автоматическое выполнение действий контроллером с помощью следующих механизмов:

Энергонезависимое хранилище

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

К реализации SEL есть обязательные требования:

Сообщение о событии несет в себе информацию из областей SDR Repository и FRU Info.

Записи SDR — это данные о типах и количестве сенсоров, их возможности генерировать события, типы показаний. SDR также содержат записи о количестве и типах устройств, подключенных к IPMB. Записи SDR хранятся в области памяти, которая называется SDR Repository (Sensor Data Records Repository).

Записи FRU содержат информацию о серийных номерах и моделях деталей различных модулей системы — процессора, платы памяти, платы ввода-вывода, контроллерах управления.

Информация FRU может предоставляться через MC (командами IPMI) либо через доступ к чипам энергонезависимой памяти SEEPROM (Serial Electrically Erasable Programmable Read Only Memory), подключенным по шине Private Management Bus. По этой шине контроллеры общаются через низкоуровневые I2C-команды с устройствами, которые не поддерживают IPMI-команды.

Практическое применение

Допустим, клиент жалуется на зависания сервера, но в логах операционной системы всё в порядке. Смотрим SEL ― видим ошибки по одной из планок оперативной памяти с указанием информации о слоте, в котором она находится. Меняем ― сервер начинает работать как часы.

Выше мы разобрали основные модули архитектуры IPMI. Теперь обратимся к структуре передаваемых команд и посмотрим, по каким интерфейсам происходит удаленное подключение.

Структура IPMI-команд

IPMI передает сообщения в формате запрос-ответ. Запросы — это команды. Команды инициируют действия и устанавливают значения. Формат запрос-ответ делает возможным одновременное общение нескольких контроллеров по одной шине.

Сообщения IPMI содержат базовый набор полей, единый для всех команд:

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

Интерфейсы удаленного доступа

В начальной версии IPMI удаленная консоль подключалась к модулю BMC через последовательный интерфейс (Serial Interface). Спецификация IPMI v2.0 базируется на использовании сетевого интерфейса (LAN Interface).

Интерфейс LAN предоставляется через выделенный сетевой порт BMC со своим IP-адресом. При передаче через LAN сообщения IPMI проходят несколько этапов инкапсуляции:

Последовательный интерфейс для подключения удаленной консоли к BMC уже не используется, однако он нужен для реализации двух функций:

Serial-over-LAN нужен для взаимодействия с компонентами системы, которые понимают только последовательный интерфейс общения. Еще можно из консоли сервера посылать команды напрямую к устройствам сервера (чипам, картам, дискам и так далее). SoL реализован так, чтобы работать совместно с функцией Serial Port Sharing.

Сеанс и аутентификация

Для LAN и последовательного интерфейса началу передачи IPMI-сообщений предшествует установление сеанса, в ходе которого формируются пакеты данных IPMI Session.

Установление сеанса ― это аутентификация конкретного пользователя. Сеанс должен быть активирован перед началом передачи IPMI-сообщений по следующему алгоритму:

Доступ к BMC можно заблокировать, отправив одновременно множество запросов об активации сеанса, тогда все ресурсы будут использоваться для отслеживания сессий, требующих активации. Чтобы предотвратить возможную атаку, в реализации BMC рекомендуется применять алгоритм LRU (Last Recently Used). Алгоритм утверждает ID сеанса для наиболее раннего запроса активации сеанса. Например, удаленная консоль запускается через браузер в noVNC-сессии. Если открыть несколько вкладок с запущенными сессиями, текстовый ввод будет доступен в наиболее ранней открытой вкладке.

Когда IPMI становится недоступен

IPMI помогает восстановить работоспособность сервера при его сбое. Однако может случиться так, что становится недоступна система удаленного управления. Сбои в работе IPMI можно разделить на четыре категории:

IPMI на практике

Управлять сервером по IPMI можно через веб-браузер, утилиты, предоставляемые производителями, и утилиты с открытым исходным кодом.

Веб-интерфейс у каждой реализации IPMI свой, но принцип доступа остается одинаковым:

Возможности веб-интерфейса также реализованы в графической утилите Supermicro IPMIView:

Чтобы управлять оборудованием через Linux-консоль, устанавливается соответствующая утилита (например, Ipmitool для локального и удаленного управления или IPMICFG для локального). Далее при помощи консольных команд добавляется IPMI-устройство и конфигурируется BMC.

Клиентам Selectel доступен IPMI для выделенных серверов и серверов произвольной конфигурации. IPMI реализован в виде KVM-консоли, которая запускается в noVNC-сессии через панель управления. Для этого в карточке с информацией о сервере надо нажать на значок консоли в правом верхнем углу:

Консоль открывается в браузере и подстраивается под размер экрана. При желании консоль можно использовать даже через телефон или планшет.

Сессия прерывается, если выйти из панели.

Заключение

IPMI ― это полностью автономный компонент серверной платформы, который не зависит ни от операционной системы, ни от BIOS, ни от CPU сервера.

Благодаря IPMI, затраты на обслуживание серверных систем сокращаются, а жизнь системных администраторов становится проще. Нет необходимости постоянного присутствия рядом с оборудованием ― его работа контролируется удаленно по сети.

В этой статье мы рассмотрели основные компоненты IPMI. Однако детали технологии обширны. Талантливые разработчики, опираясь на спецификацию, могут создавать свое IPMI-оборудование и open-source инструменты, попутно устраняя недостатки текущей спецификации и открывая новые возможности удаленного управления.

Источник

IPMI: настройка и удаленное управление серверами Supermicro

Не так давно, мне удалось поработать с новыми для меня серверами Supermicro удаленное управление которыми осуществляется с помощью интерфейса IPMI. В данной статье я постараюсь раскрыть основные моменты в настройки IPMI на серверах Supermciro, покажу основные пункты меню интерфейса IPMI, а также расскажу о дополнительных утилитах, командах и способах мониторинга сервера с помощью ipmi.

Первичная настройка IPMI консоли и знакомство с интерфейсом

Настройка IPMI начинается с настройки IP адреса интерфейса, который нужно указать в BIOS. Если сервер установлен в офисе, это может быть серый IP-адрес, если же ваше оборудование размещается в ДатаЦентре, то наверняка вы используете белый статический IP-адрес.

На серверах Supermicro в BIOS можно попасть, нажав кнопку “Del” при загрузке сервера, я не буду заострять на этом внимание и сразу перейду к интерфейсу самого BIOS.

Как видите на скриншоте, я вошел в пункт меню IPMI и активировал возможность конфигурации Lan для интерфейса (Update IPMI Lan Configuration=Yes, Configuration Address Source = Static), указал IP-адрес, маску подсети и основной шлюз.

Применить настройки можно нажав кнопку F4, после чего произойдет перезагрузка сервера.

Если вы все сделали правильно, то введя в браузере, указанный для интерфейса IPMI IP, у вас откроется авторизация:

Теперь пройдем по основным моментам.

У меня iso образы ОС хранятся на сервере Samba в той же подсети что и интерфейсы IPMI серверов. Я указываю адрес сервера Samba, путь к образу установочному ISO с ОС, после чего монтирую ISO образ и приступаю к установке операционной системы.

Консоль в целом удобная, но после установки ОС, для работы с сервером я обычно использую ssh клиенты. Иногда есть моменты когда, это невозможно, например если у вас не работает или еще не настроена сеть на сервере или же имеются какие-то проблемы с доступом. Именно тогда на помощь и приходит Remote Console.

После этого, Remote Console работает исправно.

Управление сервером через утилиту IPMICFG от SuperMicro

Для управления серверами через IPMI компания SuperMicro разрабатывает собственную утилиту IPMICFG.

Скачать файл IPMICFG можно с помощью команды:

На момент публикации файл был с таким названием, я рекомендую заходить на репозиторий SuperMicro по ссылке ftp://ftp.supermicro.com/utility/IPMICFG/ и копировать url актуального файла.

Распакуем скачанный файл в директорию которой находимся:

Далее создаем символическую ссылку для удобства запуска утилиты:

Теперь мы можем запускать утилиту с помощью команды ipmicfg (символической ссылки). Рассмотрим базовые возможности утилиты ipmicfg.

Разберем основные команды:

Вы можете изменить IP адрес, маску и шлюз интерфейса IPMI:

Создать нового пользователя IPMI и его пароль:

С помощью утилиты делаем следующее:

Тем самым мы создали пользователя test с паролем 123456 и привилегиями администратора.

Список пользователей IPMI и их привилегии в системе можно вывести командами:

Как уже видите на скриншоте, пользователь test создан.

Чтобы изменит (сбросить) пароль пользователя IPMI, исползайте команду:

И приведу еще пару примеров использование данной утилиты:

Мониторинг железа на сервере SuperMicro через IPMI и утилиту IPMICFG

Мониторинг сервера SuperMicro через IPMI

Для удобства просмотра, можно менять категории отображения датчиков, например, температуры:

Или датчики напряжения:

Так как в данный момент на нашем сервере нет проблем, ни с температурой, ни с напряжением, все датчики находятся в зеленой зоне. Если на сервере поднимается температура или есть проблемы с напряжением, зеленые прямоугольники будут окрашиваться в красный цвет, что послужит сигналом для проверки вашего сервера.

Мониторинг с помощью утилиты ipmicfg

Проверка состояния блоков питания:

Посмотреть температуру процессора можно командой:

Так же можно проверить в каком режиме работают вентиляторы и изменить режим, если это необходимо.

Проверка состояния и конфигурации вентилятора

Информация о версии и прошивке IPMI:

При выводе мы видим, что есть дополнительные столбцы, в которых отображена информация о лимитах нижнего и верхнего пределов.

Так же существует еще не малое количество утилит, которые можно использовать для мониторинга и автоматизировать этот процесс, например, с nagios. В данный момент заострять на этом внимание мы не будем, так как цель статьи рассказать основные моменты в работе с IPMI. Если вас заинтересует тема мониторинга, вы можете оставить свои пожелания и возможно в дальнейшем мы осветим и эту тему. Надеюсь, данная статья окажется для вас полезной!

Источник