Кардиостимулятор: переместите ресурс, не добавляя “предпочесть” строку в конфигурации

Одним из решений является удаление этих cli-preferограничений вручную, прежде чем вы попытаетесь вернуться назад, или (, если вас не волнуют неактивные ограничения, остающиеся вокруг ), добавьте период времени, например, 5 минут:

crm resource migrate r0 node2 PT5M

Через 5 минут правило перестает действовать (, и r0может вернуться обратно ), но оно по-прежнему отображается.

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

О радости.

Все это сводилось к использованию migrateкоманд с целевыми узлами или без них. Из текущей документации cli черезcrm resource help migrate:

If the destination node is left out, the resource is migrated by creating a constraint which prevents it from running on the current node. For this type of constraint to be created, the force argument is required.

В прошлом это также можно было сделать без force, а когда вы запускали кластер из двух -узлов -(, два узла никогда не составляли правильный кластер, но не будем здесь отвлекаться ),вы закончили с утверждением в config запуска кардиостимуляторов, явно говорящим, что он не должен работать на узле, на котором он работал, когда была запущена команда migrate, поэтому кардиостимулятор заставит его перейти на другой узел.

Если вы запустили crm resource migrate, вы получили оператор location cli-...в конфигурации кардиостимулятора. Есть два типа таких утверждений, которые можно довольно легко проверить:

crm configure show | grep -e cli-prefer -e cli-ban

Для серьезного бизнеса приведенная выше команда также должна быть частью проверки мониторинга nagios/icinga/whatever, поскольку эти ручные ограничения никогда не должны присутствовать в текущей конфигурации в долгосрочной перспективе.

Если вы снова мигрировали обратно на другой узел, вы получали еще одно такое утверждение, помечая последний узел ТАКЖЕ как «не -работающее» расположение ресурса. Если бы вы в конечном итоге все ваши узлы «эмигрировали» таким образом... ваш ресурс, о котором идет речь, никуда не запустился бы, и вам не повезло, что, вероятно, является причиной того, что этот вопрос был задан в первую очередь.

Решение заключалось в том, чтобы ВСЕГДА иметь после команды crm resource migrateкоманду crm resource unmigrateпри пропуске целевых узлов, чтобы потом не выстрелить себе в ногу.

Однако если вы всегда указываете целевой узел, все это не имеет значения:

При повторном запуске crm resource migrate RESOURCE NODE/ pcs resource move RESOURCE NODEоператор cli-prefer...в конфигурации кардиостимулятора корректируется, так что не беспокойтесь.

Таким образом, вы можете запускать crm resource migrate/ pcs resource moveстолько раз, сколько захотите, не сталкиваясь с проблемами, связанными с невозможностью запуска ресурсов.

Чтобы избавиться от любого из этих ручных ограничений для ресурса, в частности, запустите одно из этих:

crm resource unmigrate RESOURCE
crm resource clear RESOURCE

pcs resource clear RESOURCE

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