Глава 9. Диагностика и решение конфликтов в кластере

Конфликты в кластере довольно сложно идентифицировать, так как он содержит множество индивидуальных систем. Но существует несколько стандартных ситуаций, понимание причин возникновения которых значительно облегчит работу.
В этой главе рассматриваются наиболее распространенные причины конфликтов и методы их решения. За дополнительной информацией обратитесь к базе знаний или к официальному представителю службы поддержки Red Hat. Если проблемы связаны с GFS2, обратитесь к руководству GFS2.

9.1. Изменения конфигурации не вступают в силу

При изменении конфигурации кластера необходимо передать изменения всем узлам.
Ниже приведен список изменений, не требующих перезапуска кластера после передачи изменений его узлам.
  • Удаление узла из кластера за исключением случаев, когда общее число узлов уменьшилось до двух.
  • Добавление узла в кластер за исключением случаев, когда число узлов стало больше двух.
  • Изменение параметров журналирования.
  • Добавление, изменение и удаление служб высокой готовности и компонентов виртуальных машин.
  • Добавление, изменение и удаление кластерных ресурсов.
  • Добавление, изменение и удаление запасных доменов.
Остальные операции требуют перезагрузки кластера. Примеры:
  • Добавление и удаление параметра two_node из файла конфигурации.
  • Переименование кластера.
  • Изменение таймеров corosync и openais.
  • Добавление, изменение и удаление эвристических методов определения кворума диска, изменение таймеров кворума, изменение кворумного диска. Для применения изменений потребуется перезапустить qdiskd.
  • Изменение режима central_processing для rgmanager. Для применения изменений потребуется перезапустить rgmanager.
  • Изменение адреса многоадресной рассылки.
  • Изменение режима передачи с многоадресной рассылки UDP на одноадресную и наоборот.
Кластер можно перезапустить с помощью Conga, ccs и инструментов командной строки.