Назад | Перейти на главную страницу

Странный номер узла в настройке балансировщика нагрузки

У меня тут странная проблема. Я установил Corosync и Pacemaker, я использовал это руководство в качестве справочника, но я немного импровизировал при первой установке, так как я делаю это для обучения, а не следую инструкциям, как раб. Но когда я получил эту странную ошибку, я загрузил новый VPS, чтобы повторить попытку, на этот раз следуя инструкциям, как подчиненное устройство.

Вот руководство, которому я следовал, довольно хорошее оформление от Митчелла Аникаса из Digital Ocean: Как создать установку HAProxy высокой доступности с Corosync, Pacemaker и плавающими IP-адресами в Ubuntu 14.04 | digitalocean.com

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

ОС: Ubuntu Xenial Xursus (16.04.4)

totem {
  version: 2
  cluster_name: lbcluster
  transport: udpu
  interface {
    ringnumber: 0
    bindnetaddr: primary's-privateIP
    broadcast: yes
    mcastport: 5405
  }
}

quorum {
  provider: corosync_votequorum
  two_node: 1
}

nodelist {
  node {
    ring0_addr: primary's-privateIP
    name: primary
    nodeid: 1
  }
  node {
    ring0_addr: secondary's-privateIP
    name: secondary
    nodeid: 2
  }
}

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  to_syslog: yes
  timestamp: on
}

Если я сбегу sudo crm status, результат, который я получаю, выглядит так.

Last updated: Fri Apr 13 15:31:47 2018          Last change: Fri Apr 13 14:08:42 2018 by root via cibadmin on secondary<br>
Stack: corosync<br>
Current DC: secondary (version 1.1.14-70404b0) - partition with quorum<br>
3 nodes and 0 resources configured

Online: [ primary secondary ]
OFFLINE: [ sh-ps-02 ]

Я также бегу sudo crm configure show чтобы показать конфигурацию:

node 1: primary<br>
node 2: secondary<br>
node 2130706433: sh-ps-02<br>
property cib-bootstrap-options: \<br>
have-watchdog=false \<br>
dc-version=1.1.14-70404b0 \<br>
cluster-infrastructure=corosync \<br>
cluster-name=debian \<br>
stonith-enabled=false \<br>
no-quorum-policy=ignore

Почему существует странно выглядящий узел с запущенным именем вторичного узла, но не в сети, даже если в нем явно указано, что это двухузловой кластер?

Дополнение 16. Апрель 2018: Я бегал sudo corosync-cmapctl | grep members чтобы получить члены кластера, и нет никаких следов этого странного члена кластера, который отключен.

runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(x.x.82.204)
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 3
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(x.x.82.167)
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined

Я считаю, что Xenial поставляет Corosync и Pacemaker, запущенные и включенные в systemd, с corosync.conf конфигурация, которая создаст «кластер с одним узлом». Эта запись, вероятно, является именем хоста одного из ваших узлов, который был добавлен до того, как вы задали имена: primary и secondary.

Чтобы очистить его, просто удалите эту запись:

# crm node delete sh-ps-02

Боковое примечание: наименование ваших узлов primary и secondary не лучшая практика. node-a и node-b было бы лучше, поскольку любой узел в кластере должен иметь возможность действовать как «первичный» или «вторичный».