使用Keepalived和MaxCtrl搭建MaxScale高可用集群

mariadb maxscale 是一个数据库代理，为应用程序提供了数据库负载均衡和查询路由的功能。如果使用基础的配置，maxscale有单点风险。可以使用Keepalived和MaxCtrl实施一个更有弹性的MaxScale高可用集群。

keepalived是一个提供了高可用和负载均衡功能的路由软件。它包含很多强悍的功能，这篇教程主要基于2台运行了maxscale的机器提供一套基于IP容灾的教程，如果主服务器挂掉，从服务器会接受所有新的连接，从而接管主服务器的职责。这里有一份《基于Ubuntu 14.04、keepalived搭建简单的容灾系统》

这篇文章介绍了搭建2个MaxScale来监控1个数据库集群，其中包含2个主机、1个客户机，他们在同一个局域网中。架构见下图

 

在这个架构中，两个Keepalived节点在网络中广播他们自己的状态以便监听互相的状态。如果一个节点没有收到另一个节点的状态信息，会通知VIP，从而变为master，因此，可以通过开关Keepalived服务来上下线一个maxscale节点。如果当前master节点被下线了（例如：把网线拔掉），剩下的节点会很快被选为master节点，VIP会直接把请求路由到这个节点。任何路由到之前master节点的请求会被断掉。如果以前的master节点再次上线后，VIP会把新的请求重新路由过来。MaxScale并不知道这发生的一切，两个MaxScale都正常地运行着，监控着后端的数据库服务器。因为客户端是通过VIP连接数据库的，只有配置在VIP中的及其才能接受请求。两个MaxScale和后端数据库服务是通过真实的IP进行通信的而不是通过VIP。

配置

MaxScale并不需要特别的配置才能和Keepalived一起运行，它只需要运行在他们自己的主机中。如果你只是想把改动同步到两个MaxScale实例中，那你只需要很简单的配置。另外，两个实例的配置都应该是相同的，对于客户端来说也是这样。推荐在service段中的“version_string”中设置不同的值，因为这样会在日志中打印连接到这个节点的客户端的信息。

[Read-Write Service]

type=service

router=readwritesplit

version_string=PrimaryMaxScale

...

在主节点的Keepalived中应该作如下配置

vrrp_instance VI_1 {

state MASTER

    interface eth0

    virtual_router_id 51

    priority 150

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass mypass

    }

    virtual_ipaddress {

        192.168.1.123

    }

}

必须把state设置为master，virtual_router_id 和auth_pass也必须指定。interface配置使用哪个网卡，这取决于操作系统，但一般配置为eth0或者enp0s12f3。在不同的keepalived实例中配置不同的priority将决定哪个节点是master，不过不同实例不要配置相同的priority，这个例子中备份服务器可以配置为149、148等等值。advert_int用来设置当前节点向其他keepalived节点广播的时间间隔，1秒是一个比较合理的设置。

       每一个Keepalived节点必须要指定VIP，在局域网中不能相同，下面是备份节点keepalived.conf-file的例子

vrrp_instance VI_1 {

   state MASTER

   interface eth0

   virtual_router_id 51

   priority 100

   advert_int 1

   authentication {

   auth_type PASS

     auth_pass mypass

   }

   virtual_ipaddress {

     192.168.1.123

   }

}

一旦Keepalived服务运行起来，会打印keepalived的状态日志

Aug 11 10:27:59 maxscale2 Keepalived_vrrp[27369]: VRRP_Instance(VI_1) Received higher prio advert

Aug 11 10:27:59 maxscale2 Keepalived_vrrp[27369]: VRRP_Instance(VI_1) Entering BACKUP STATE

Aug 11 10:27:59 maxscale2 Keepalived_vrrp[27369]: VRRP_Instance(VI_1) removing protocol VIPs.

MariaDB MaxScale健康检查

下面讲一下MaxScale的健康检查。要确定MaxScale在主机上运行良好，必须设置一个检查脚本。如果这个脚本返回一个error值，Keepalived节点将认为它挂了，就不会再向它广播状态信息。同时其他节点将通过VIP声明自己是master节点。下面是一个primary 节点的脚本配置例子

vrrp_script chk_myscript {

    script "/home/scripts/is_maxscale_running.sh"

    interval 2 # check every 2 seconds

    fall 2 # require 2 failures for KO

    rise 2 # require 2 successes for OK

}

vrrp_instance VI_1 {

    state MASTER

    interface wlp2s0

    virtual_router_id 51

    priority 150

    advert_int 1

    authentication {

    auth_type PASS

       auth_pass mypass

    }

    virtual_ipaddress {

       192.168.1.13

    }

    track_script {

      chk_myscript

    }

}

is_maxscale_running.sh参见下面的内容。脚本使用MaxAdmin连接本地运行的MaxScale并查询服务列表。使用一个合理的时间来设置timeout命令，脚本发现如果MaxScale挂了、卡住了、或者负载太大就不会再接受连接了。只需要简单的检查就可以确定MaxScale的运行状态。

#!/bin/bash

fileName="maxadmin_output.txt"

rm $fileName

timeout 2s maxadmin list servers > $fileName

to_result=$?

if [ $to_result -ge 1 ]

then

    echo Timed out or error, timeout returned $to_result

    exit 3

else

    echo MaxAdmin success, rval is $to_result

    echo Checking maxadmin output sanity

    grep1=$(grep server1 $fileName)

    grep2=$(grep server2 $fileName)

   

    if [ "$grep1" ] && [ "$grep2" ]

    then

        echo All is fine

        exit 0

    else

        echo Something is wrong

        exit 3   

    fi

fi

Aug 11 10:51:56 maxscale2 Keepalived_vrrp[20257]: VRRP_Script(chk_myscript) failed

Aug 11 10:51:57 maxscale2 Keepalived_vrrp[20257]: VRRP_Instance(VI_1) Entering FAULT STATE

Aug 11 10:51:57 maxscale2 Keepalived_vrrp[20257]: VRRP_Instance(VI_1) removing protocol VIPs.

Aug 11 10:51:57 maxscale2 Keepalived_vrrp[20257]: VRRP_Instance(VI_1) Now in FAULT state

MaxScale 主动\被动模式设置

MariaDB MaxScale2.2.2引入了主从复制集群管理的一些特性（容灾、路由、重新接入）。如果运行了多个MaxScale，只能使用其中一个来修改主从复制集群的设置。这个节点应该设置为master Keepalived，MaxScale并不知道Keepalived的状态，但MaxCtrl（MaxAdmin的替代品）可以设置MaxScale实例为被动模式。如果MaxScale设置为被动模式，他将不参与容灾、路由、重新加入。在Keepalived配置文件中设置一个notify脚本，它用于接受党Keepalived的状态改变时的事件。

...

  virtual_ipaddress {

    192.168.1.13

  }

  track_script {

    chk_myscript

  }

  notify /home/scripts/notify_script.sh

...

Keepalived调用这个脚本的时候会传入3个参数，在这个例子中，我们只是用第三个参数STATE          

#!/bin/bash

TYPE=$1

NAME=$2

STATE=$3

OUTFILE=/home/user/state.txt

 

case $STATE in

 "MASTER") echo "Setting this MaxScale node to active mode" > $OUTFILE

              maxctrl alter maxscale passive false

              exit 0

              ;;

 "BACKUP") echo "Setting this MaxScale node to passive mode" > $OUTFILE

              maxctrl alter maxscale passive true

              exit 0

              ;;

 "FAULT")  echo "MaxScale failed the status check." > $OUTFILE

              maxctrl alter maxscale passive true

              exit 0

              ;;

    *)     echo "Unknown state" > $OUTFILE

              exit 1

              ;;

esac

脚本把当前状态记录在一个文本文件中，并设置MaxScale的工作模式。如果是FAULT则会把MaxScale设置为被动模式

如果所有的MaxScale\Keepalived实例都设置了相同的notify脚本，只设置一个MaxScale节点为主动模式。可以通过maxctrl来查询MaxScale实例的工作模式，如下，查询的MaxScale的工作模式为“active”

 

[vagrant@maxscale1 ~]$ maxctrl show maxscale

┌──────────────┬────────────────────────────────┐

│ Version      │ 2.2.2                                                  │

├──────────────┼────────────────────────────────┤

.

.

.

├───────────────────────────────────────────────┤

│ Parameters   │ {                                                      │

│              │ "libdir": "/usr/lib64/maxscale",                       │

│              │ "datadir": "/var/lib/maxscale",  

.


│              │ "passive": false,                                      │

│              │ "query_classifier": ""                                 │

│              │ }                                                      │