Очистка ресурса Pacemaker / Corosync вызывает перезапуск в Ubuntu (любой версии)
У меня проблема с кластером кардиостимулятора / 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 resource cleanup 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 временно извлечен из кибера и снова вставлен. И это приводит к остановке Res2 до тех пор, пока Res1 не подтвердит состояние «запущено».
Верно, удаление истории операций ресурса - это то, как кардиостимулятор запускает повторную проверку текущего статуса.
Как я интерпретирую документацию, этого можно было бы избежать поведение, настроив ограничение порядка с помощью kind = Optional. Но я не уверен, приведет ли это к какой-либо другой незаслуженной стороне. эффекты. (например, в обратном порядке при остановке)
kind = Необязательные ограничения применяются только тогда, когда необходимо выполнить оба действия в том же переходе. Т.е. если одна проверка кластера обнаруживает, что оба Res1 и Res2 должны быть запущены, Res1 будет запущен раньше Res2. Но вполне возможно, что Res2 можно запустить в более раннем переход, при этом Res1 все еще остановлен, и начинается более поздний переход Res1. Точно так же при остановке Res2 будет остановлен первым, если потребуется обоим. должен быть остановлен.
В исходном сценарии, если ваш главный / подчиненный ресурс будет связывать только к IP-адресу после его активации kind = Optional не будет надежным. Но если ресурс master / slave привязывается к подстановочному IP-адресу, тогда порядок действительно не имеет значения - вы можете сохранить ограничение colocation и отказаться от упорядочивание.
Другой обходной путь, кажется, устанавливает зависимый ресурс на unmanaged, выполните очистку, а затем снова установите для него управляемый.
Это то, что я бы порекомендовал, если вам нужно сохранить обязательный упорядочивание.
И мне интересно, поможет ли «Сброс количества сбоев ресурсов ПК» БЕЗ выполнения каких-либо действий, если состояние не изменилось. нужно. Но я думаю, что напомню, что мы уже пробовали это время от времени и иногда такой сбойный ресурс не запускался после сбоя сброс. (Но я не уверен, и у меня еще не было времени попытаться воспроизвести.)
Нет, в более новых версиях кардиостимулятора crm_failcount --delete эквивалентен в crm_resource --cleanup. (ПК вызывает их, чтобы фактически выполнить работа)
Есть ли более глубокое понимание, которое могло бы помочь со звуком понимание этой проблемы?
Это побочный эффект текущей реализации CIB. Кардиостимулятора механизм политики определяет текущее состояние ресурса, проверяя история его работы в CIB. Очистки удаляют операцию история, таким образом делая текущее состояние неизвестным, заставляя повторное зондирование. В виде побочный эффект, любые зависимости больше не имеют ограничений выполняется до завершения повторной проверки.
Теоретически можно было бы реализовать "очистку старых сбои », который очищает счетчик сбоев ресурса и удаляет только записи в истории операций для неудачных операций, если это не меняет определение текущего состояния. Но это было бы довольно сложно, и установка ресурса неуправляемым - это простой способ обхода.
>