(FF0) 127.0.0.1

Home » Отказоустойчивый кластер » Построение 2-х нодового Master/Slave кластера PostgreSQL на базе Corosync Pacemaker

Построение 2-х нодового Master/Slave кластера PostgreSQL на базе Corosync Pacemaker

Технология построения 2-х нодового кластера многократно описана в интернете.

Предлагаемые 2-х нодовые конфигурации Master/Slave кластера обладают существенным недостатком.

При пропадании управляющего линка, происходит promote на реплике. Поскольку обе ноды “думают”, что соседняя нода отвалилась (сбой), то у нас появляются две ноды в режиме Master и с двумя плавающими виртуальными IP. По-другому это называется split-brain. При появлении пропавшего линка, эти мастера начинают вести себя непредсказуемо, не говоря уже об активном сетевом оборудовании, для которого появление 2-х одинаковых ip-адресов с разными мак-адресами на разных портах может привести к отключению этих портов (в лучшем случае). Как видно, отказоустойчивость в данном случае сводится на нет.

Указанного недостатка лишена 3-х нодовая конфигурация, где третья нода выступает в качестве голосующего узла. В совокупности с настроенным fencing и stonith, эта схема позволяет выключать или отправлять в перезагрузку ту ноду из связки Master-Slave, на которой произошел сбой.

Решение с 3-х нодовым кластером более дорогостоящее. Для решения требуется как минимум два железных сервера с функцией IPMI или ILO для фенсинга (выключения-перезагрузки), в качестве голосующего узла (третьей ноды) может выступать виртуальная машина.

Но что делать, если Заказчик или босс не желает тратиться на третий сервер (и нет возможности поднять виртуалку) или настаивает на виртуальных машинах?

В описании ПО Corosync Pacemaker есть малодокументированная возможность использования вычисления “веса” (score) каждой ноды.

Если происходит сбой, решение о перемещении ресурсов (в нашем случае – виртуальных IP и ) ПО кластера принимает на основе весов каждой ноды. И там, где больший вес, тот сервер считается “живее”, на него переносятся ресурсы.

Как определить, какая из двух нод живее, а значит, и какой из двух мастеров имеет право на дальнейшее существование, а какой надо остановить?

Как уже упоминалось выше, в 3-х нодовой схеме на это решение влияет голосующий узел.

В 2-х нодовой схеме можно использовать ресурс Pacemaker’а – Ping. Например, пинговать СХД или коммутатор. Это может быть любое устройство, подключенное к сети, лишь бы оно было рядом и между ним и нодой не было промежуточных устройств.

Ниже описание решения, которое позволяет построить отказоустойчивый   Master-Slave кластер PostgreSQL на 2-х нодах.

Исходные данные:

ОС – CentOS 7.3

PostgreSQL 9.5

Нода1: pgsql-01

интерфейс для управления ens4, ip 10.2.2.1

интерфейс для реплики ens8, ip 10.3.3.1

Нода2: pgsql-02

интерфейс для управления ens4, ip 10.2.2.2

интерфейс для реплики ens8, ip 10.3.3.2

Перемещаемые ресурсы:

Роль Master PostgreSQL

vip-master 10.2.2.3/29

vip-slave 10.3.3.3/29

Внешнее устройство, доступное для ping:

Виртуалка, СХД или коммутатор – ip 10.2.2.6

Команды для Pacemaker:

pcs cluster cib pgsql_cfg
pcs -f pgsql_cfg property set no-quorum-policy=”ignore”
pcs -f pgsql_cfg property set stonith-enabled=”false”
pcs -f pgsql_cfg resource defaults resource-stickiness=”500″
pcs -f pgsql_cfg resource defaults migration-threshold=”1″

pcs -f pgsql_cfg resource create vip-master IPaddr2 ip=”10.2.2.3″ nic=”ens4″ cidr_netmask=”29″ \
op start timeout=”60s” interval=”0s” on-fail=”restart” \
op monitor timeout=”60s” interval=”10s” on-fail=”restart” \
op stop timeout=”60s” interval=”0s” on-fail=”block”

pcs -f pgsql_cfg resource create vip-rep IPaddr2 ip=”10.3.3.3″ nic=”ens8″ cidr_netmask=”29″ meta migration-threshold=”0″ \
op start timeout=”60s” interval=”0s” on-fail=”stop” \
op monitor timeout=”60s” interval=”10s” on-fail=”restart” \
op stop timeout=”60s” interval=”0s” on-fail=”ignore”

pcs -f pgsql_cfg resource create pgsql pgsql pgctl=”/usr/pgsql-9.5/bin/pg_ctl” \
psql=”/usr/pgsql-9.5/bin/psql” pgdata=”/var/lib/pgsql/9.5/data/” \
rep_mode=”sync” node_list=”pgsql-01 pgsql-02″ restore_command=”cp /var/lib/pgsql/9.5/pg_archive/%f %p” \
primary_conninfo_opt=”keepalives_idle=60 keepalives_interval=5 keepalives_count=5″ master_ip=”10.3.3.3″ restart_on_promote=’false’ \
op start timeout=”60s” interval=”0s” on-fail=”restart” \
op monitor timeout=”60s” interval=”4s” on-fail=”restart” \
op monitor timeout=”60s” interval=”3s” on-fail=”restart” role=”Master” \
op promote timeout=”60s” interval=”0s” on-fail=”restart” \
op demote timeout=”60s” interval=”0s” on-fail=”stop” \
op stop timeout=”60s” interval=”0s” on-fail=”block” \
op notify timeout=”60s” interval=”0s”

pcs -f pgsql_cfg resource create pingCheck1 ping name=”default_ping_set” host_list=”10.2.2.1 10.2.2.2 10.2.2.6″ multiplier=”111″ \
op start timeout=”60s” interval=”0s” on-fail=”restart” \
op monitor timeout=”20s” interval=”2s” on-fail=”restart” \
op stop timeout=”60s” interval=”0s” on-fail=”ignore” \
–clone

pcs -f pgsql_cfg resource master msPostgresql pgsql master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
pcs -f pgsql_cfg resource group add master-group vip-master vip-rep
pcs -f pgsql_cfg constraint colocation add master-group with Master msPostgresql INFINITY
pcs -f pgsql_cfg constraint order promote msPostgresql then start master-group symmetrical=false score=INFINITY
pcs -f pgsql_cfg constraint order demote msPostgresql then stop master-group symmetrical=false score=0

pcs -f pgsql_cfg constraint location add L_ping_vip1 msPostgresql pgsql-01 100
pcs -f pgsql_cfg constraint location add L_ping_vip2 msPostgresql pgsql-02 100

pcs -f pgsql_cfg constraint location msPostgresql rule role=slave score=-INFINITY default_ping_set eq 111

Далее на двух нодах:

pcs cluster start

Загрузка правил в кластер из созданного файла pgsql_cfg:

pcs cluster cib-push pgsql_cfg

продолжение следует

Тэги поста ,,,