Продление минимального времени между IPMI-операциями в OpenStack Ironic

by itisgood

В установках OpenStack, основанных на TripleO, развертывание узлов Overcloud координируется так называемым модулем Ironic, который был разработан в целом для развертывания ОС на серверах.

Существует ряд драйверов интерфейса IPMI (Intelligent Platform Management Interface), поддерживаемых Ironic, таких как pxe_ilo для HP Proliant Gen8 +, pxe_drac для DELL 12G +, ipmi для общих серверов и т. Д. В случае универсального драйвера ipmi установлен сценарий Ironic, который установлен на undercloud (или директор OSP) использует командную строку Linux ipmitool для отправки сообщений IPMI узлам Overcloud для управления ими во время развертывания TripleO.

Во время развертывания TripleO модуль Ironic работает на каждом узле, загружает образ ядра и устанавливает ОС, затем перезагружает каждый узел, а когда узел сообщает, что он запущен и перезагружен после перезагрузки, развертывание считается выполненным.

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

Ниже я представляю раздел ipmi по умолчанию из файла /etc/ironic/ironic.conf для выпуска Pike:

[ipmi]
#command_retry_timeout = 60
retry_timeout = 15
#min_command_interval = 5

Когда я развертываю выпуск RDO TripleO Pike в своей среде, состоящий из старых серверов Oracle Sun Fire X4270, серверов HP Proliant Gen5 и Gen6, я замечаю, что по умолчанию Ironic настройки серверы HP Proliant Gen6 и Gen5 отвечают на отправляемые сообщения IPMI от underloud и off, а затем начинаются без каких-либо проблем.

Однако серверы Oracle Sun Fire X4270 после закрытия никогда не поднимаются.

В файле журнала Ironic /var/log/ironic/ironic-conductor.log я вижу, что серверы получают действительное сообщение «power on» IPMI:

...
2018-07-11 23:55:15.259 1433 DEBUG oslo_concurrency.processutils [req-903e4775-419f-48ef-b42a-504dee9c2eff 3f7f46753ff54c509c34070fc992355c 325bf08fee894f6a83ad5fd288b1226d - default default] CMD "ipmitool -I lanplus -H 192.168.2.13 -L ADMINISTRATOR -U admin -R 12 -N 5 -f /tmp/tmpfw1WUj power on" returned: 0 in 0.264s execute /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:404
2018-07-11 23:55:15.262 1433 DEBUG ironic.common.utils [req-903e4775-419f-48ef-b42a-504dee9c2eff 3f7f46753ff54c509c34070fc992355c 325bf08fee894f6a83ad5fd288b1226d - default default] Execution completed, command line is "ipmitool -I lanplus -H 192.168.2.13 -L ADMINISTRATOR -U admin -R 12 -N 5 -f /tmp/tmpfw1WUj power on" execute /usr/lib/python2.7/site-packages/ironic/common/utils.py:75
2018-07-11 23:55:15.263 1433 DEBUG ironic.common.utils [req-903e4775-419f-48ef-b42a-504dee9c2eff 3f7f46753ff54c509c34070fc992355c 325bf08fee894f6a83ad5fd288b1226d - default default] Command stdout is: "Chassis Power Control: Up/On
" execute /usr/lib/python2.7/site-packages/ironic/common/utils.py:76
2018-07-11 23:55:15.265 1433 DEBUG ironic.common.utils [req-903e4775-419f-48ef-b42a-504dee9c2eff 3f7f46753ff54c509c34070fc992355c 325bf08fee894f6a83ad5fd288b1226d - default default] Command stderr is: "" execute /usr/lib/python2.7/site-packages/ironic/common/utils.py:77
...

… но вскоре после того, как я вижу ошибки тайм-аута, этот конкретный узел не запустился через 60 секунд:

# tail -f /var/log/ironic/ironic-conductor.log
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall Traceback (most recent call last):
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall   File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 141, in _run_loop
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall     idle = idle_for_func(result, watch.elapsed())
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall   File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 338, in _idle_for
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall     % self._error_time)
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall LoopingCallTimeOut: Looping call timed out after 47.48 seconds
2018-07-11 23:56:59.059 1433 ERROR oslo.service.loopingcall
2018-07-11 23:56:59.061 1433 ERROR ironic.conductor.utils [req-577784b3-ef60-4068-9693-795a0f43f37a - - - - -] Timed out after 60 secs waiting for power power on on node 63fde05d-d96c-4ad0-8f5a-7c4a6221bd5b.: LoopingCallTimeOut: Looping call timed out after 47.48 seconds
2018-07-11 23:56:59.153 1433 ERROR ironic.drivers.modules.agent_base_vendor [req-577784b3-ef60-4068-9693-795a0f43f37a - - - - -] Error rebooting node 63fde05d-d96c-4ad0-8f5a-7c4a6221bd5b after deploy. Error: Failed to set node power state to power on.: PowerStateFailure: Failed to set node power state to power on.
2018-07-11 23:56:59.156 1433 DEBUG ironic.drivers.modules.agent_client [req-577784b3-ef60-4068-9693-795a0f43f37a - - - - -] Executing agent command log.collect_system_logs for node 63fde05d-d96c-4ad0-8f5a-7c4a6221bd5b _command /usr/lib/python2.7/site-packages/ironic/drivers/modules/agent_client.py:62

Похоже, для серверов Sun Fire X4270 интервалы между «отключением питания» и «включением» сообщений IPMI слишком коротки из-за их более длительного времени выключения.

Когда сообщение «power on» отправляется на сервер, сервер все еще отключается и игнорирует сообщение.

Изменение значения параметра min_command_interval до 15 секунд зафиксировало проблему на Sun Fire X4270. Раздел ipmi в файле /etc/ironic/ironic.conf после изменений:

 

[ipmi]
#command_retry_timeout = 60
retry_timeout = 15
min_command_interval = 15

Теперь у серверов достаточно времени, чтобы завершить работу и дождаться сообщения «IP-соединение» от Underloud.

You may also like

Leave a Comment