У меня проблема с кластером кардиостимулятора / corosync (2 узла) на Ubuntu (12.04 / 14.04 / 16.04 и 18.04) и не смогли найти никого, кто бы описал эту проблему. Есть два ресурса: res_ip (виртуальный IP) и res_apache (apache2). Это всего лишь примеры ресурсов. Проблема возникает с любыми сопутствующими / размещенными ресурсами.
Res_apache совмещен с res_ip, чтобы apache всегда запускался на «активном» сервере, который доступен через виртуальный ip. Бывают случаи, когда res_ip выходит из строя и перезапускается, что приводит к перезапуску res_apache (как и ожидалось), оставляя счетчик отказов позади.
Проблема: Попытка очистить ресурс res_ip (crm очистка ресурсов res_ip) вызывает res_apache (который зависит от res_ip) для перезапуска, и я не знаю почему.
Эта же команда в CentOS не вызывает прерывания работы веб-приложения. Команда очищает только счетчик отказов.
Прикрепленный node1_corosync.log.extract.txt показывает, что res_ip распознается как остановился (строка 951) и, следовательно, перезапускается зависимый res_apache. Команда очистки запускается примерно в это время (15:18:17), поэтому я предполагаю, что проверка, запущен ли ресурс, инициируется командой очистки. Он просто не должен находиться в состоянии «остановлено» и, следовательно, не перезапускать зависимый ресурс res_apache.
Опять же, я должен указать, что я вижу эту проблему во всех выпусках Ubuntu, но не в CentOS, и тип ресурса не имеет значения.
У кого-нибудь есть идеи, почему это происходит (и происходит только в Ubuntu)?
Файлы журнала и конфигурация: https://1drv.ms/u/s!Av4S568oLfJmgZtQ6pcE40FOKN8yDg?e=IOHKX8
(вы должны быть в рассылке любого программного обеспечения (вы пробовали его?), которое вы действительно используете, и сначала ищете и предлагаете помощь!) Ниже приводится выдержка из списка рассылки clusterlab, ответы от ребят из Redhat (хотя это может отличаться от от версии кластера к версии) ........
Когда я вызываю «очистку ресурсов ПК Res1», это приведет к прерыванию обслуживания на стороне Res2 (т.е. остановит Res2…). Мое - неподтвержденное - предположение заключалось в том, что кардиостимулятор сначала определит текущее состояние ресурса (ов) с помощью вызывает монитор, а затем решает, нужно ли выполнить какие-либо действия. Но, читая файлы журнала, я бы понял, что Res1 временно удален из cib и снова вставлен. И это приводит к остановке Res2 до тех пор, пока Res1 не подтвердит состояние «запущено».
Правильно, удаление истории операций ресурса - это то, как кардиостимулятор запускает повторную проверку текущего состояния.
Поскольку я интерпретирую документацию, этого можно было бы избежать, настроив ограничение порядка с помощью kind = Optional. Но я не уверен, приведет ли это к каким-либо другим незаслуженным побочным эффектам. (например, в обратном порядке при остановке)
kind = Необязательные ограничения применяются только тогда, когда оба действия необходимо выполнить в одном переходе. Т.е. если в результате проверки одного кластера выясняется, что необходимо запустить и Res1, и Res2, Res1 будет запущен раньше Res2. Но вполне возможно, что Res2 может быть запущен в более раннем переходе, при этом Res1 все еще остановлен, а более поздний переход запускает Res1. Точно так же при остановке Res2 будет остановлен первым, если необходимо остановить оба.
В вашем исходном сценарии, если ваш главный / подчиненный ресурс будет связываться с IP только после его активации, kind = Optional не будет надежным. Но если главный / подчиненный ресурс привязывается к IP-адресу с подстановочными знаками, то порядок действительно не имеет значения - вы можете сохранить ограничение colocation и отказаться от упорядочивания.
Другой обходной путь, похоже, устанавливает зависимый ресурс как неуправляемый, выполняет очистку, а затем снова устанавливает его как управляемый.
Это то, что я бы порекомендовал, если вам нужно соблюдать обязательный порядок.
И мне интересно, сработает ли «Сброс счетчика сбоев ресурсов ПК» БЕЗ каких-либо действий, если изменение состояния не требуется. Но я думаю, что напомню, что мы уже пробовали это время от времени, и иногда такой сбойный ресурс не запускался после сброса счетчика сбоев. (Но я не уверен и еще не успел попытаться воспроизвести.)
Нет, в более новых версиях кардиостимулятора crm_failcount --delete эквивалентен crm_resource --cleanup. (ПК вызывает их для выполнения работы)
Есть ли более глубокое понимание, которое могло бы помочь в правильном понимании этой проблемы?
Это побочный эффект текущей реализации CIB. Механизм политики Pacemaker определяет текущее состояние ресурса, проверяя его историю операций в CIB. Очистка удаляет историю операций, тем самым делая текущее состояние неизвестным, что вызывает повторное зондирование. В качестве побочного эффекта любые зависимости больше не удовлетворяют свои ограничения до завершения повторного зондирования.
Теоретически было бы возможно реализовать опцию «очистки старых сбоев», которая очищала бы счетчик сбоев ресурса и удаляла бы только записи его истории операций для сбойных операций, если это не меняет определение текущего состояния. Но это было бы довольно сложно, и сделать ресурс неуправляемым - простой обходной путь.
>