У меня два балансировщика нагрузки HA (hollywood
и wolfman
) под управлением Corosync и Pacemaker. В eth1
интерфейсы подключены к WAN, а eth0
взаимодействует с локальной сетью, используя виртуальный IP-адрес в качестве шлюза для внутренних серверов. В eth1
IP из hollywood
является xxx.xxx.195.45
, а eth1
IP из wolfman
является xxx.xxx.195.46
. В bindnetaddr
в Corosync есть xxx.xxx.195.32
, то же самое, что и сетевой адрес WAN, а порт Corosync по умолчанию 5405
.
Соответствующие правила IP-таблиц на обоих серверах:
*filter
--flush
:INPUT DROP
--append INPUT --protocol udp --destination-port 5404 --jump ACCEPT
--append INPUT --protocol udp --destination-port 5405 --jump ACCEPT
Кажется, эта настройка работает нормально, но сначала я добавил --in-interface eth1
и --source xxx.xxx.195.46
к wolfman
, и --source xxx.xxx.195.45
к hollywood
. В большинстве случаев это работало, но перезагрузка пассивного балансировщика иногда приводила к прерыванию связи между балансировщиками нагрузки, записывая эти ошибки в системный журнал:
[TOTEM] Totem не может сформировать кластер из-за сбоя операционной системы или сети. Наиболее частая причина появления этого сообщения - неправильная настройка локального брандмауэра.
Таким образом, похоже, что либо мое упрощенное убеждение, что весь трафик Corosync находится непосредственно между двумя балансировщиками нагрузки, либо eth1
неправильно, или что-то другое вызывает проблему.
Я хочу заблокировать порт 5404/5405
в IPTables до кластера. Что мне нужно сделать, чтобы это произошло?
Редактировать: corosync.conf
как просили. Все это Ubuntu по умолчанию, кроме bindnetaddr
.
# Please read the openais.conf.5 manual page
totem {
version: 2
# How long before declaring a token lost (ms)
token: 3000
# How many token retransmits before forming a new configuration
token_retransmits_before_loss_const: 10
# How long to wait for join messages in the membership protocol (ms)
join: 60
# How long to wait for consensus to be achieved before starting a new round of membership configuration (ms)
consensus: 3600
# Turn off the virtual synchrony filter
vsftype: none
# Number of messages that may be sent by one processor on receipt of the token
max_messages: 20
# Limit generated nodeids to 31-bits (positive signed integers)
clear_node_high_bit: yes
# Disable encryption
secauth: off
# How many threads to use for encryption/decryption
threads: 0
# Optionally assign a fixed node id (integer)
# nodeid: 1234
# This specifies the mode of redundant ring, which may be none, active, or passive.
rrp_mode: none
interface {
# The following values need to be set based on your environment
ringnumber: 0
bindnetaddr: xxx.xxx.195.32
mcastaddr: 226.94.1.1
mcastport: 5405
}
}
amf {
mode: disabled
}
service {
# Load the Pacemaker Cluster Resource Manager
ver: 0
name: pacemaker
}
aisexec {
user: root
group: root
}
logging {
fileline: off
to_stderr: yes
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
tags: enter|leave|trace1|trace2|trace3|trace4|trace6
}
}
При использовании многоадресной связи (по умолчанию для Corosync) трафик IGMP должен быть разрешен, а пакеты Corosync могут быть разрешены с правилами, которые намного более конкретны, чем в другом ответе. Достаточно следующих правил (при условии, что OUTPUT
цепочка не блокирует трафик):
iptables -A INPUT -p igmp -i $corosync_interface -j ACCEPT
for src_addr in $ip_addr_self $ip_addr_partner1 $ip_addr_partner2; do
iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_self \
-p udp --source-port $(($corosync_port - 1)) \
--destination-port $corosync_port -j ACCEPT
iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_mcast \
-p udp --source-port $(($corosync_port - 1)) \
--destination-port $corosync_port -j ACCEPT
done
В этом примере предполагается, что определены следующие переменные:
$corosync_interface
: сетевой интерфейс, который используется Corosync.$ip_addr_self
: IP-адрес, к которому Corosync привязывается локально (указывается как bindnetaddr
в corosync.conf
)$ip_addr_partner1
, $ip_addr_partner2
: IP-адреса других узлов Corosync - можно добавить больше, если в кластере более трех узлов.$ip_addr_mcast
: многоадресный адрес, используемый для Corosync (указанный как mcastaddr
в corosync.conf
)$corosync_port
: порт (назначения), используемый Corosync (указанный как mcastport
в corosync.conf
)На одном узле, где интерфейс, используемый Corosync, является портом, который является членом моста Open vSwitch, некоторые из многоадресных пакетов были получены на интерфейсе моста вместо того, который имел IP-адрес. Поэтому мне пришлось добавить дополнительное правило, разрешающее многоадресные пакеты на этом интерфейсе:
for src_addr in $ip_addr_self $ip_addr_partner1 $ip_addr_partner2; do
iptables -A INPUT -i $bridge_interface -s $src_addr -d $ip_addr_mcast -p udp --source-port $(($corosync_port - 1)) --destination-port $corosync_port -j ACCEPT
done
Если OUTPUT
chain не принимает пакеты по умолчанию, необходимо добавить правила, разрешающие трафик IGMP и позволяющие отправлять пакеты Corosync:
iptables -A OUTPUT -p igmp -o $corosync_interface -j ACCEPT
for dst_addr in $ip_addr_self $ip_addr_mcast $ip_addr_partner1 $ip_addr_partner2; do
iptables -A OUTPUT o $corosync_interface -s $ip_addr_self -d $dst_addr \
-p udp --source-port $(($corosync_port - 1)) \
--destination-port $corosync_port -j ACCEPT
done
По умолчанию Corosync использует многоадресную рассылку IP для связи между узлами:
mcastaddr: 226.94.1.1
mcastport: 5405
Либо настройте свой брандмауэр, чтобы разрешить многоадресный трафик:
# iptables -A INPUT -p igmp -j ACCEPT
# iptables -A INPUT -m addrtype --dst-type MULTICAST -j ACCEPT
# iptables -A INPUT -p udp -m state --state NEW -m multiport --dports 5404,5405 -j ACCEPT
или переключитесь на одноадресная передача.