Instalacja oraz konfiguracja DRBD i Pacemaker – budowa klastra niezawodnościowego (część 4)

W poprzedniej części artykułu o konfiguracji DRBD i Pacemaker ożywiliśmy DRBD . W tej części przejdę już do konfiguracji Pacemaker-a, czyli oprogramowania które zagwarantuje nam automatyczne przełączenie pracy na drugi serwer w przypadku awarii pierwszego.

Zakładam, że na opisywanych węzłach będą uruchomione standardowe zasoby, czyli serwer WWW oraz baza danych . W moim przypadku będą to nginx oraz mysql.

Na początku powinniśmy usunąć wszystkie skrypty startowe używanych przez nas aplikacji, ponieważ ich uruchamianiem od tego momentu będzie zajmował się pacemaker. Robimy to wydając polecenia (dla przypomnienia – wszystkie komendy wykonujemy na obu serwerach):

sudo update-rc.d -f mysql remove

sudo update-rc.d -f nginx remove

sudo update-rc.d -f drbd remove

Przystępujemy do instalacji pakietu pacemaker.

apt-get install pacemaker

W tym momencie, na jednym z serwerów możemy wprowadzić konfigurację węzłów. Przechodzimy do edycji poleceniem:

crm configure edit

Otworzy się edytor, gdzie możemy wkleić poniższą zawartość:

node serwer1 \
        attributes standby=”off”
node serwer2 \
        attributes standby=”off”
primitive DRBD ocf:linbit:drbd \
        params drbd_resource=”mirror” \
        op monitor interval=”120s” \
        op start interval=”0″ timeout=”240s” \
        op stop interval=”0″ timeout=”100s”
primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 \
        params ip=”192.168.0.3″ nic=”eth0:0″ broadcast=”192.168.0.255″ \
        op monitor interval=”10s” \
        meta is-managed=”true”
primitive FAILOVER-SRC ocf:heartbeat:IPsrcaddr \
        params ipaddress=”192.168.0.3″
primitive MOUNT ocf:heartbeat:Filesystem \
        params device=”/dev/drbd0″ directory=”/mnt/drbd” fstype=”ext4″
primitive MYSQL upstart:mysql \
        op start interval=”0″ timeout=”120s” \
        op stop interval=”0″ timeout=”120s” \
        op monitor interval=”10s” \
        meta target-role=”Started”
primitive NGINX lsb:nginx \
        op monitor interval=”30s” \
        meta target-role=”Started”
primitive PING-NET ocf:pacemaker:ping \
        params dampen=”5s” multiplier=”100″ host_list=”8.8.8.8″ \
        op monitor interval=”60s” timeout=”60″ \
        op start interval=”0″ timeout=”60s” \

        op stop interval=”0″ timeout=”60s”

        primitive resMON ocf:pacemaker:ClusterMon \
        operations $id=”resMON-operations” \
        op monitor interval=”180″ timeout=”20″ \
        params extra_options=”–mail-to <admin@mail.com> –mail-from <root@mail.com>”
group MIRROR-CLUST FAILOVER-ADDR MOUNT FAILOVER-SRC MYSQL NGINX
ms DRBD-DATA DRBD \
        meta master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true” target-role=”Started”
clone PING-NET-CLONE PING-NET
location connected_node MIRROR-CLUST \
        rule $id=”connected_node-rule” -inf: not_defined pingd or pingd lte 0
location master-prefer-serwer1 FAILOVER-ADDR 25: serwer1
colocation MIRROR-CLUST_on_DRBD inf: MIRROR-CLUST DRBD-DATA:Master
order MIRROR-CLUST_after_DRBD-DATA inf: DRBD-DATA:promote MIRROR-CLUST:start
property $id=”cib-bootstrap-options” \
        dc-version=”1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c” \
        cluster-infrastructure=”openais” \
        expected-quorum-votes=”2″ \
        stonith-enabled=”false” \
        no-quorum-policy=”ignore” \
        start-failure-is-fatal=”false” \
        last-lrm-refresh=”1349255559″
rsc_defaults $id=”rsc-options” \
        resource-stickiness=”100″ \
        migration-threshold=”3″

O co w tym wszystkim chodzi ? W pliku konfiguracyjnym zostały zdefiniowane nasze węzły oraz zasoby, które mają być uruchamiane na tych węzłach. Adres 192.168.0.3 to alias adresu IP serwera, który tworzony jest na węźle podstawowym –  dzięki temu oba nasze serwery zawsze będą widziane pod tym samym IP – 192.168.0.3 .

Adres admin@mail.com to oczywiście nasz adres email. Na ten adres będziemy dostawać wszystkie alerty od pacemaker-a . Należy pamiętać, że w grupie: FAILOVER-ADDR MOUNT FAILOVER-SRC MYSQL NGINX zasoby będą uruchamiane w kolejności od lewej do prawej, czyli np. jeżeli coś się stanie z mysql to serwer www się nie uruchomi.

Status naszego klastra możemy sprawdzić poleceniem:

crm status

W każdej chwili możemy też wyłączyć jeden z naszych węzłów poleceniem:

crm node standby

i ponownie włączyć poleceniem:

crm node online

To już ostatni artykuł cyklu na temat konfiguracji DRBD i Pacemaker. Jeżeli ktoś ma jakieś pytania proszę o ich dodawanie w komentarzu.