Сравнительное моделирование алгоритмов обработки команд управления состоянием сервера в ПО BMC

Введение

Программное обеспечение контроллера управления платформой (Baseboard Management Controller, BMC) получает команды, от которых зависит состояние сервера. Принятие запроса, запуск операции и подтверждение её результата происходят в разные моменты; Redfish предусматривает асинхронные задачи для наблюдения за выполнением [1]. В OpenBMC управление состояниями BMC, шасси и хоста разделено между компонентами [2]. Здесь рассматривается один логический объект – сервер, чтобы изолировать правила допуска команд от особенностей оборудования.

Повторная доставка запроса может привести к повторному воздействию. Семантика HTTP не разрешает считать автоматический повтор любой неидемпотентной операции безопасным [3]. Учёт идентификатора и результата известен как способ подавления повторного исполнения [4], но сам по себе не определяет поведение при занятом исполнителе. Цель работы – сравнить сочетания очереди и учёта идентификаторов при одной и той же входной нагрузке. Для такого сравнения необходимо задать общий путь команды от поступления до подтверждения результата, а затем менять только правило её допуска.

1. Модель обработки команды

Запрос в модели содержит идентификатор клиента, идентификатор запроса и операцию ON, OFF или REBOOT. Обработчик сначала решает, допустить ли запрос при текущей занятости, затем передаёт команду единственному исполнителю и сохраняет результат. Ответ о принятии команды не равен подтверждению смены состояния: между ними может находиться ожидание в очереди и сам переход. Для ожидающей команды допустимость проверяется при извлечении, поскольку состояние сервера за время ожидания могло измениться.

Для всех сравниваемых алгоритмов заданы одни и те же переходы. Начальное устойчивое состояние – ON. Команда ON переводит OFF через STARTING в ON за 5u; OFF переводит ON через STOPPING в OFF за 3u; REBOOT переводит ON через RESTARTING в ON за 8u. Здесь u – условная единица времени, не приравненная к секунде. ON при ON и OFF при OFF завершается как успешный NOOP без нового перехода, а REBOOT при OFF возвращает INVALID. Это подмножество операций Reset в схеме Redfish ComputerSystem [5].

Одновременно выполняется не более одного перехода. Если подтверждение не получено через 12u от запуска, результат временно обозначается UNKNOWN и выполняется сверка ещё 2u. В сценарии сверка всегда подтверждает целевое состояние; исполнитель освобождается через 14u от запуска. UNKNOWN означает отсутствие подтверждения у контроллера, а не отдельный режим питания. Таким образом, задержка ответа зависит и от ожидания исполнителя, и от времени получения результата; правила ожидания определяются сравниваемыми алгоритмами.

2. Алгоритмы допуска и учёта повторов

На описанном исполнителе можно по-разному обработать поступление команды во время перехода. Первый выбор – поставить её в очередь либо сразу вернуть BUSY. Второй – проверить идентификатор и вернуть уже известный статус либо трактовать доставку как новую. Таблица 1 показывает четыре сочетания этих решений. Названия алгоритмов относятся к модели, а не к штатным режимам OpenBMC.

Таблица 1

Политики обработки запросов

Для FIFO_DEDUP ключом служит пара (client_id, request_id). Новый ключ регистрируется со статусом PENDING до добавления в очередь. Повтор с той же операцией получает текущий или сохранённый итоговый статус без нового запуска; тот же ключ с другой операцией даёт ID_CONFLICT. При извлечении команды проверяется состояние сервера, затем результат, включая INVALID, записывается в историю. CHECK и DEDUP отклоняют новую команду при занятости; BUSY и ранний INVALID в историю DEDUP не попадают, поэтому повтор может быть принят позднее.

Порядок допуска FIFO_DEDUP приведён в алгоритме 1. Проверка ключа выполняется до добавления в очередь, поэтому зарегистрированный повтор ожидающей команды не создаёт второй элемент. После завершения перехода обработчик записывает окончательный результат в историю.

Алгоритм 1. Допуск запроса в FIFO_DEDUP:

1. Сформировать ключ k = (client_id, request_id).
2. Если k уже есть в истории с другой операцией, вернуть ID_CONFLICT.
3. Если k уже есть с той же операцией, вернуть сохранённый статус.
4. Иначе записать (k, операция, PENDING) и поставить команду в очередь.
5. При освобождении исполнителя проверить допустимость: записать INVALID, завершить NOOP либо запустить переход.
6. После завершения перехода заменить PENDING окончательным результатом.

В рамках одного процесса с неизменной историей такой порядок исключает повторный запуск по одному ключу. Он не обеспечивает однократное физическое воздействие после аварии между фиксацией истории и выполнением команды. Новый идентификатор выражает новое намерение, даже если операция совпадает. Чтобы сравнить последствия этих правил, все четыре алгоритма далее получают одинаковые последовательности запросов и повторов.

3. Методика вычислительного эксперимента

Дискретно-событийный симулятор генерирует по 300 исходных запросов от четырёх клиентов и передаёт одну входную трассу каждому алгоритму. Интервалы между поступлениями распределены экспоненциально с интенсивностью λ запросов на u; команды ON, OFF и REBOOT выбираются с вероятностями 0,3; 0,3 и 0,4. С вероятностью p через 10u поступает один повтор с тем же ключом; вероятность f задаёт задержанное подтверждение. Так различия результатов обусловлены правилом обработки, а не разными входными потоками. Параметры четырех основных сценариев приведены в таблице 2.

Таблица 2

Основные сценарии моделирования

Для каждой пары «сценарий – политика» выполнено 50 прогонов с начальными значениями генератора 1000–1049, всего 800 прогонов. Отдельно исследованы шесть значений λ от 0,01 до 0,40 при p = 0,30 и f = 0 (ещё 1200 прогонов). После последнего поступления обрабатываются все ожидающие события: оценивается конечный поток из 300 запросов, а не стационарный режим бесконечной очереди. Время поиска в истории, объём памяти и реакция клиента на BUSY приняты вне модели.

Показатели вычисляются для исходных идентификаторов. S = 100Nусп/N – доля запросов с успешным результатом, включая NOOP; E = (100/N)Σmax(aᵢ−1, 0) – число лишних запусков на 100 запросов, где aᵢ – число запусков по ключу i; L – средняя задержка от первого поступления до первого успеха среди успешных запросов. B – доля BUSY среди всех доставок, поэтому её знаменатель отличается от S. Показатели сначала вычисляются в каждом прогоне, затем усредняются по 50 прогонам. Выполнены также семь детерминированных проверок правил обработки. Совместное чтение S и L позволяет отличить короткий ответ от обслуживания большей части запросов.

4. Сравнение результатов

В S0 история не меняет показатели соответствующего базового алгоритма. В S1 FIFO_DEDUP устраняет 6,19 лишнего запуска на 100 запросов при почти неизменной задержке: 3,82u у FIFO и 3,71u у FIFO_DEDUP. При повышенной нагрузке S2 различия становятся заметнее (табл. 3).

Таблица 3

Результаты сценария S2, средние по 50 прогонам

В S2 FIFO_DEDUP снизил L с 14,63u до 8,35u относительно FIFO (на 42,9%) и исключил лишние запуски. Средний максимум очереди сократился с 16,84 до 8,74, а парный 95%-й интервал разности задержек составил от −7,46 до −5,10u. Сокращение очереди согласуется с тем, что повтор зарегистрированного ключа больше не создаёт отдельное ожидающее задание.

При этом S равна 79,62% против 81,54% у FIFO. FIFO_DEDUP сохраняет итоговый INVALID по ключу, а алгоритм без истории может обработать повтор после изменения состояния. Состав успешно обслуженных запросов поэтому различается, и снижение L нельзя трактовать как ускорение каждого одинакового запроса. CHECK и DEDUP дают ещё меньшую задержку среди успешных запросов, но в S2 их доля S составляет лишь 52,21% и 54,98%. В сценарии задержанного подтверждения S3 FIFO_DEDUP сохраняет E = 0 при L = 5,55u.

Четыре сценария показывают отдельные режимы, но не форму зависимости между ними. На рисунке интенсивность λ изменяется при неизменных p = 0,30 и f = 0. Отрезки отражают приближённые 95%-е интервалы среднего по 50 прогонам при фиксированных параметрах модели.

Рис. Задержка успешных запросов и их доля при изменении λ

При λ = 0,40 задержка достигает 175,48u для FIFO и 71,90u для FIFO_DEDUP: устранение повторов замедляет рост очереди, но не устраняет перегрузку. У FIFO_DEDUP доля S остаётся 79,62% в этой серии, поскольку порядок уникальных команд не меняется и все ожидающие события обрабатываются после окончания поступления. У CHECK и DEDUP при той же интенсивности S падает до 37,95% и 40,71%. Сравнение задержки отдельно от успешной доли скрывало бы этот эффект.

5. Интерпретация и применение

График показывает цену ожидания: очередь обслуживает больше запросов, но её длина растёт; ранний отказ ограничивает задержку принятой части потока, уменьшая её долю. Практический результат – исполняемый прототип FIFO_DEDUP и правило регистрации ключа до очереди с сохранением результата. В проверках повтор ожидающей команды возвращал PENDING без второй постановки, а повтор REBOOT не вызывал нового запуска. Если очередь нежелательна и клиент обрабатывает BUSY, возможна политика DEDUP. Срок хранения ключа и повтор после INVALID требуют отдельного правила интерфейса.

Оценки получены при условных длительностях 3u, 5u и 8u, неограниченных очереди и истории, а также всегда успешной сверке из UNKNOWN. Для реализации нужны правила ограничения очереди, отмены команд и восстановления после перезапуска, включая согласование истории с аппаратным воздействием. Перевод модельных задержек в секунды требует измерений на целевой платформе.

Заключение

Сравнение четырёх политик показало, что учёт идентификаторов можно совместить с ожиданием в очереди. В сценарии S2 FIFO_DEDUP исключил повторные запуски и снизил задержку успешных запросов с 14,63u до 8,35u, однако успешная доля составила 79,62% против 81,54% у FIFO из-за иной семантики повторного INVALID. Результат позволяет выбирать правила допуска и проверять их на воспроизводимых трассах.