У меня есть три узла и три виртуальных IP-адреса в одной подсети. Не имеет значения, какой адрес назначен какому узлу. IP-адреса являются общедоступными. Узлы являются балансировщиками нагрузки, которые распределяют веб-запросы по нескольким внутренним системам.
Если все три узла находятся в сети, три адреса будут сбалансированы на трех узлах, так что каждый узел будет иметь ровно один адрес.
Если только два из них. узлы находятся в оперативном режиме, один узел имеет один адрес, а другой - два адреса.
Если только один узел подключен к сети, у него есть все три адреса.
Это отлично работает с этой конфигурацией ресурсов:
primitive IP_10 ocf:heartbeat:IPaddr2 params ip="x.x.x.10" cidr_netmask="24" nic="eth1" primitive IP_11 ocf:heartbeat:IPaddr2 params ip="x.x.x.11" cidr_netmask="24" nic="eth1" primitive IP_12 ocf:heartbeat:IPaddr2 params ip="x.x.x.12" cidr_netmask="24" nic="eth1"
Теперь самое главное в том, что у меня есть один шлюз по умолчанию (xxx1), который необходимо настроить на каждом узле после назначения одного из IP-адресов. Очевидно, что невозможно настроить шлюз по умолчанию до назначения адреса.
Первое, что я попробовал, это настроить второй ресурс для каждого адреса, ocf: heartbeat: Route:
primitive default_gw_1 ocf:heartbeat:Route params destination="default" device="eth1" gateway="x.x.x.1" primitive default_gw_2 ocf:heartbeat:Route params destination="default" device="eth1" gateway="x.x.x.1" primitive default_gw_3 ocf:heartbeat:Route params destination="default" device="eth1" gateway="x.x.x.1"
, а затем объединить эти ресурсы в группы:
group net_10 IP_10 default_gw_1 group net_11 IP_11 default_gw_2 group net_12 IP_12 default_gw_3
Это работает до сих пор, шлюз по умолчанию устанавливается правильно после присвоение адреса. В случае аварийного переключения все по-прежнему работает, как ожидалось. Этот пример показывает возможное распределение ресурсов после того, как Node1 перешел в автономный режим:
Node1: offline Node2: net_10, net_11 Node3: net_12
Проблемы возникают, когда Node1 возвращается в онлайн. Затем один из ресурсов на узле 2, например net_10, будет перенесен на узел 1. Теперь менеджер ресурсов ocf: heartbeat: Route остановлен на Node2, удаляет шлюз по умолчанию и фактически прекращает доступ к Node2, поскольку у него больше нет шлюза по умолчанию. Таким образом, оставшийся адрес на узле 2 (net_11) больше недоступен.
Затем я попытался исправить диспетчер ресурсов ocf: heartbeat: Route, чтобы запретить удаление маршрута. Кажется, это работает, но кажется очень некрасивым.
Я полагаю, что для этого должно быть лучшее решение. Как я могу настроить так, чтобы шлюз по умолчанию оставался установленным на узле, пока этому узлу назначен хотя бы один IP-адрес?
(Pacemaker 1.1.7 в Debian Wheezy)
Это может быть поздно, но на всякий случай, если кто-то еще может извлечь из этого выгоду.
В этом случае вы должны создать только один GW, а затем клонировать его на всех ваших узлах. В приведенном ниже примере демонстрируется этот сценарий с использованием синтаксиса pcs
.
pcs cluster setup --name MyCluster node1 node2 node3 --start
pcs cluster cib cluster_cfg
pcs -f cluster_cfg property set stonith-enabled="false"
pcs -f cluster_cfg resource create IP_10 ocf:heartbeat:IPaddr2 ip="x.x.x.10" cidr_netmask="24" nic="eth1"
pcs -f cluster_cfg resource create IP_20 ocf:heartbeat:IPaddr2 ip="x.x.x.11" cidr_netmask="24" nic="eth1"
pcs -f cluster_cfg resource create IP_30 ocf:heartbeat:IPaddr2 ip="x.x.x.12" cidr_netmask="24" nic="eth1"
pcs -f cluster_cfg resource create default_gw ocf:heartbeat:Route destination="default" device="eth1" gateway="x.x.x.1"
pcs -f cluster_cfg resource clone default_gw globally-unique="true"
pcs -f cluster_cfg constraint order IP_10 then default_gw-clone
pcs -f cluster_cfg constraint order IP_20 then default_gw-clone
pcs -f cluster_cfg constraint order IP_30 then default_gw-clone
pcs -f cluster_cfg constraint colocation add IP_10 with IP_20 -1
pcs -f cluster_cfg constraint colocation add IP_10 with IP_30 -1
pcs -f cluster_cfg constraint colocation add IP_20 with IP_30 -1
pcs cluster cib-push cluster_cfg