Кластер кардиостимулятора: использование групп ресурсов для моделирования ролей узлов

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

В моем кластере есть разные роли, такие как:

  • индексация (узлы с 1 по 4)
  • представление (узлы 1 и 2)
  • архив (узлы 3 и 4, в идеале предпочтительный узел 3)
  • потребление (узлы 3 и 4, в идеале предпочитая узел 4)

Ресурсы, которые я определил, включают три плавающих IP-адреса (это роль отправки) и две системные службы. (Плавающие IP-адреса являются наиболее важной частью; остальное программное обеспечение выполняет свою собственную кластеризацию.)

Я пытаюсь следовать https://www.unixarena.com/2015/12/rhel-7-pacemaker-cluster-resource-group-management.html/, но я уверен, что мои ожидания от группы ресурсов может вписаться в реальность.

В настоящее время ресурс ПК выглядит следующим образом:

# pcs resource
 Resource Group: submission
     reception_ip_general   (ocf::heartbeat:IPaddr2):   Started node1
     reception_ip_networking    (ocf::heartbeat:IPaddr2):   Started node1
     reception_ip_esx   (ocf::heartbeat:IPaddr2):   Started node1
 Resource Group: archive
     archive-writer-avro    (systemd:archiver@avro):    Started node3
     archive-writer-syslog  (systemd:archiver@syslog):  Started node3

Пока еще нет никаких ограничений, и просто повезло, что ресурс оказался там, где он есть (например, я видел один из плавающих IP-адресов на узле 4)

Чтобы уточнить, чего я хочу достичь:

  • receive_ip_general должен работать на node1 xor node2
  • Параметр receive_ip_networking должен выполняться на узле 1 или на узле 2
  • receive_ip_esx должен работать на node1 xor node2
  • Архив-Автор-Avro должен работать на узле 3 xor узел4
  • Архив-писатель-системный журнал должен запускаться на узле 3 или на узле 4

Я думаю, что мне нужно то, что:

  • позволяет мне определить группу "представление" узлов
  • позволяет мне помещать ресурсы в группу "представление"
  • задайте ограничение местоположения так, чтобы узлы1 и узлы2 были теми, которые размещают вещи в группе "отправки".

Или, возможно, я должен искать:

  • определить атрибуты узла, чтобы каждый узел имел атрибуты, установленные так, чтобы узел1 мог иметь атрибут submission_role=1, index_role=1
  • задайте ограничения местоположения так, чтобы ресурс придерживался узлов с их соответствующим атрибутом.

Я уверен, что это должно быть довольно просто, но пока что ни одна из документации, с которой я столкнулся, кажется, не моделирует это, и я почти уверен, что группы ресурсов ведут меня по садовой дорожке.

Спасибо за вашу помощь, Кэмерон

Обновления

атрибут узла ПК

Я играл с атрибутами узла и до сих пор получил следующее:

# pcs node attribute
Node Attributes:
 node1: indexing_role=1 submission_role=1
 node2: indexing_role=1 submission_role=1
 node3: archive_role=1 consumption_role=1 indexing_role=1
 node4: archive_role=1 consumption_role=1 indexing_role=1

И ограничения выглядят так:

# pcs constraint location reception_ip_general rule score-attribute=submission_role defined submission_role

Выход:

# pcs constraint
Location Constraints:
  Resource: archive-writer-avro
    Constraint: location-archive-writer-avro
      Rule: score-attribute=archive_role
        Expression: defined archive_role
  Resource: archive-writer-syslog
    Constraint: location-archive-writer-syslog
      Rule: score-attribute=archive_role
        Expression: defined archive_role
  Resource: reception_ip_esx
    Constraint: location-reception_ip_esx
      Rule: score-attribute=submission_role
        Expression: defined submission_role
  Resource: reception_ip_general
    Constraint: location-reception_ip_general
      Rule: score-attribute=submission_role
        Expression: defined submission_role
  Resource: reception_ip_networking
    Constraint: location-reception_ip_networking
      Rule: score-attribute=submission_role
        Expression: defined submission_role
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:

Атрибуты узла для победы!

Настройка атрибутов узла, чтобы я мог смоделировать предпочтения между ролями узла 3/4

# pcs node attribute 
Node Attributes:
 node1: indexing_role=1 submission_role=1
 node2: indexing_role=1 submission_role=1
 node3: archive_role=2 consumption_role=1 indexing_role=1
 node4: archive_role=1 consumption_role=2 indexing_role=1


# pcs status
Cluster name: mycluster
Stack: unknown
Current DC: node1 (version unknown) - partition with quorum
Last updated: Wed Aug 15 12:19:45 2018
Last change: Wed Aug 15 12:18:20 2018 by root via crm_attribute on node1

4 nodes configured
5 resources configured

Online: [ node1 node2 node3 node4 ]

Full list of resources:

 reception_ip_general   (ocf::heartbeat:IPaddr2):   Started node1
 reception_ip_networking    (ocf::heartbeat:IPaddr2):   Started node2
 reception_ip_esx   (ocf::heartbeat:IPaddr2):   Started node1
 archive-writer-avro    (systemd:archiver@avro):    Started node3
 archive-writer-syslog  (systemd:archiver@syslog):  Started node3

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Переведите узел 3 в режим ожидания, и он перейдет к узлу 4.

# pcs node standby node3

# pcs resource
 reception_ip_general   (ocf::heartbeat:IPaddr2):   Started node1
 reception_ip_networking    (ocf::heartbeat:IPaddr2):   Started node2
 reception_ip_esx   (ocf::heartbeat:IPaddr2):   Started node1
 archive-writer-avro    (systemd:archiver@avro):    Started node4
 archive-writer-syslog  (systemd:archiver@syslog):  Started node4

Выведите узел 3 из режима ожидания, и он вернется к узлу 3

# pcs resource
 reception_ip_general   (ocf::heartbeat:IPaddr2):   Started node1
 reception_ip_networking    (ocf::heartbeat:IPaddr2):   Started node2
 reception_ip_esx   (ocf::heartbeat:IPaddr2):   Started node1
 archive-writer-avro    (systemd:archiver@avro):    Started node3
 archive-writer-syslog  (systemd:archiver@syslog):  Started node3

Круто, давайте попробуем уровень представления, который имеет равный счет. Когда мы переходим к "узлу ожидания ПК1", я вижу, что все движется к узлу 2. Когда я "штучный нестандартный узел 1", он остается на узле 2, а когда я "штучный резервный узел 2", все переходит на узел 1.

Если я перехожу на узел 1 и узел 2, то все перемещается на узел 3 и узел 4, а затем возвращается к узлу 1/2, когда я их не выполняю.

1 ответ

Хорошо, так что я сам понял это.

Способ сделать это - использовать атрибуты узла:

  1. Создайте атрибут узла для каждой роли в вашем кластере. Команды, такие как:

    pcs node attribute node1 submission_role=1 index_role=1

  2. Значение атрибута будет использовано для оценки. Команды, такие как:

    pcs node attribute node3 archive_role=2 consumption_role=1 index_role=1

    pcs node attribute node4 archive_role=1 consumption_role=2 index_role=1

  3. Создайте ограничение местоположения, которое применяется к хостам, для которых определен атрибут, и использует значение этого атрибута для оценки. Команды, такие как:

    pcs constraint location archive-writer-avro rule score-attribute=archive_role defined archive_role

  4. Тест с использованием таких команд, как pcs node standby node1, pcs node unstandby node1 а также watch pcs resource

  5. Отрегулируйте атрибуты узла, чтобы варьировать вес (вы должны иметь возможность использовать отрицательные значения для представления избегания, а не предпочтения).

Обратите внимание, что значения, которые я использовал, вероятно, не самые лучшие; возможно 100 будет лучше, чем 1.

В любом случае спасибо за людей, обдумывающих мой вопрос.

Ура, Кэмерон

Другие вопросы по тегам