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

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

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

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

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

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

Обновляет

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

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

# 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:

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

Корректировка атрибутов узла, чтобы я мог смоделировать предпочтения между ролями node3 / 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

Перевести node3 в режим ожидания, и он переместится на node4

# 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

Вывести node3 из режима ожидания, и он вернется в 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 node3
 archive-writer-syslog  (systemd:archiver@syslog):  Started node3

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

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

0
задан 15 August 2018 в 03:32
1 ответ

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

Это можно сделать с помощью атрибутов узла:

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

    шт. Атрибут узла node1 submission_role = 1 index_role = 1

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

    атрибут узла ПК node3 archive_role = 2 потребление_роль = 1 index_role = 1

    атрибут узла ПК node4 archive_role = 1 потребление_role = 2 index_role = 1

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

    количество ПК ограничение расположение архив-писатель-avro правило score-attribute = archive_role defined archive_role

  4. Тестирование с использованием таких команд, как ПК, резервный узел узла1 , ПК, резервный узел узла, узел1 и смотреть ресурсы ПК

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

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

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

Ура, Кэмерон

0
ответ дан 5 December 2019 в 05:25

Теги

Похожие вопросы