Redis（9.2）—— 哨兵的安装和部署

上一节介绍了Redis Sentinel的基本架构，本节将介绍如何安装和部署Redis Sentinel。

9.2.1 部署拓扑结构
下面将以3个Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel进行说明，拓扑结构如图9-13所示。

具体的物理部署如表9-2所示。

9.2.2 部署Redis数据节点
9.1节提到过，Redis Sentinel中Redis数据节点没有做任何特殊配置，按照之前章节介绍的方法启动就可以，下面以一个比较简单的配置进行说明。
1.启动主节点
配置：
redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/soft/redis/data/"
启动主节点：
redis-server redis-6379.conf
确认是否启动。一般来说只需要ping命令检测一下就可以，确认Redis数据节点是否已经启动。
$ redis-cli -h 127.0.0.1 -p 6379 ping
PONG
此时拓扑结构如图9-14所示。

      图9-14 启动主节点

2.启动两个从节点
配置：
两个从节点的配置是完全一样的，下面以一个从节点为例子进行说明，和主节点的配置不一样的是添加了slaveof配置。
redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 6379
启动两个从节点：
redis-server redis-6380.conf
redis-server redis-6381.conf
验证：
$ redis-cli -h 127.0.0.1 -p 6380 ping
PONG
$ redis-cli -h 127.0.0.1 -p 6381 ping
PONG
3.确认主从关系
主节点的视角，它有两个从节点，分别是127.0.0.1：6380和127.0.0.1：6381：
$ redis-cli -h 127.0.0.1 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=281,lag=0
.................
从节点的视角，它的主节点是127.0.0.1：6379：
$ redis-cli -h 127.0.0.1 -p 6380 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
.................
此时拓扑结构如图9-15所示。

9.2.3 部署Sentinel节点
3个Sentinel节点的部署方法是完全一致的（端口不同），下面以sentinel-1节点的部署为例子进行说明。
1.配置Sentinel节点
redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
1）Sentinel节点的默认端口是26379。
2）sentinel monitor mymaster 127.0.0.1 63792配置代表sentinel-1节点需要监控127.0.0.1：6379这个主节点，2代表判断主节点失败至少需要2个Sentinel节点同意，mymaster是主节点的别名，其余Sentinel配置将在下一节进行详细说明。
2.启动Sentinel节点
Sentinel节点的启动方法有两种：
方法一， 使用redis-sentinel命令：
redis-sentinel redis-sentinel-26379.conf
方法二， 使用redis-server命令加--sentinel参数：
redis-server redis-sentinel-26379.conf --sentinel
两种方法本质上是一样的。
3.确认
Sentinel节点本质上是一个特殊的Redis节点，所以也可以通过info命令来查询它的相关信息，从下面info的Sentinel片段来看，Sentinel节点找到了主节点127.0.0.1：6379，发现了它的两个从节点，同时发现Redis Sentinel一共有3个Sentinel节点。这里只需要了解Sentinel节点能够彼此感知到对方，同时能够感知到Redis数据节点就可以了：
$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
当三个Sentinel节点都启动后，整个拓扑结构如图9-16所示。至此Redis Sentinel已经搭建起来了，整体上还是比较容易的，但是有2点需要强调一下：
1）生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。
2）Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别，只不过是添加了一些Sentinel节点对它们进行监控。

9.2.4 配置优化
了解每个配置的含义有助于更加合理地使用Redis Sentinel，因此本节将对每个配置的使用和优化进行详细介绍。Redis安装目录下有一个sentinel.conf，是默认的Sentinel节点配置文件，下面就以它作为例子进行说明。
1.配置说明和优化
port 26379
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#sentinel auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>
port和dir分别代表Sentinel节点的端口和工作目录， 下面重点对sentinel相关配置进行详细说明。
（1）sentinel monitor
配置如下：
sentinel monitor <master-name> <ip> <port> <quorum>
Sentinel节点会定期监控主节点，所以从配置上必然也会有所体现，本配置说明Sentinel节点要监控的是一个名字叫做<master-name>，ip地址和端口为<ip><port>的主节点。<quorum>代表要判定主节点最终不可达所需要的票数。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息，有关这部分是如何实现的，将在9.5节介绍。
例如某个Sentinel初始节点配置如下：
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
当所有节点启动后，配置文件中的内容发生了变化，体现在三个方面：
·Sentinel节点自动发现了从节点、其余Sentinel节点。
·去掉了默认配置，例如parallel-syncs、failover-timeout参数。
·添加了配置纪元相关参数。
启动后变化为：
port 26379
daemonize yes
logfile "26379.log"
dir "/opt/soft/redis/data"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
#发现两个slave节点
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381
#发现两个sentinel节点
sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada74124140d6f53
sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a61a8e39ae031192f1feae7eb5b2be
sentinel current-epoch 0
<quorum>参数用于故障发现和判定，例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。
对于<quorum>设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为Sentinel节点的一半加1。同时<quorum>还与Sentinel节点的领导者选举有关，至少要有max（quorum，num（sentinels）/2 + 1）个Sentinel节点参与选举，才能选出领导者Sentinel，从而完成故障转移。例如有5个Sentinel节点，quorum=4，那么至少要有max（quorum， num（sentinels） /2 + 1） = 4个在线Sentinel节点才可以进行领导者选举。
（2）sentinel down-after-milliseconds
配置如下：
sentinel down-after-milliseconds <master-name> <times>
每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，<times>（单位为毫秒）就是超时时间。这个配置是对节点失败判定的重要依据。

优化说明：down-after-milliseconds越大，代表Sentinel节点对于节点不可达的条件越宽松，反之越严格。条件宽松有可能带来的问题是节点确实不可达了，那么应用方需要等待故障转移的时间越长，也就意味着应用方故障时间可能越长。条件严格虽然可以及时发现故障完成故障转移，但是也存在一定的误判率。

运维提示
down-after-milliseconds虽然以<master-name>为参数，但实际上对Sentinel节点、 主节点、 从节点的失败判定同时有效。
（3） sentinel parallel-syncs
配置如下：
sentinel parallel-syncs <master-name> <nums>
当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销。图9-17展示parallel-syncs=3和parallel-syncs=1的效果，parallelsyncs=3会同时发起复制，parallel-syncs=1时从节点会轮询发起复制。
（4） sentinel failover-timeout
配置如下：
sentinel failover-timeout <master-name> <times>

failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段：
a）选出合适从节点。
b）晋升选出的从节点为主节点。
c）命令其余从节点复制新的主节点。
d）等待原主节点恢复后命令它去复制新的主节点。
failover-timeout的作用具体体现在四个方面：
1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。
2）在b）阶段时，如果Sentinel节点向a）阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过failover-timeout时，则故障转移失败。
3）在b）阶段如果执行成功，Sentinel节点还会执行info命令来确认a）阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failovertimeout时，则故障转移失败。

4）如果c）阶段执行时间超过了failover-timeout（不包含复制时间），则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从节点去同步最新的主节点。

（5）sentinel auth-pass
配置如下：
sentinel auth-pass <master-name> <password>

如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。

（6）sentinel notification-script
配置如下：
sentinel notification-script <master-name> <script-path>
sentinel notification-script的作用是在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。
例如在/opt/redis/scripts/下配置了notification.sh，该脚本会接收每个Sentinel节点传过来的事件参数，可以利用这些参数作为邮件或者短信报警依据：
#!/bin/sh
#获取所有参数
msg=$*
#报警脚本或者接口，将msg作为参数
exit 0
如果需要该功能，就可以在Sentinel节点添加如下配置（<mastername>=mymaster）：
sentinel notification-script mymaster /opt/redis/scripts/notification.sh

例如下面就是某个Sentinel节点对主节点做了主观下线（有关主观下线的概念将在9.5节进行详细介绍）后脚本收到的参数：

（7） sentinel client-reconfig-script
配置如下：
sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script的作用是在故障转移结束后，会触发对应路径的脚本，并向脚本发送故障转移结果的相关参数。和notification-script类似，可以在/opt/redis/scripts/下配置了client-reconfig.sh，该脚本会接收每个Sentinel节点传过来的故障转移结果参数，并触发类似短信和邮件报警：
#!/bin/sh
#获取所有参数
msg=$*
#报警脚本或者接口， 将msg作为参数
exit 0
如果需要该功能，就可以在Sentinel节点添加如下配置（<mastername>=mymaster）：
sentinel client-reconfig-script mymaster /opt/redis/scripts/client-reconfig.sh
当故障转移结束，每个Sentinel节点会将故障转移的结果发送给对应的脚本，具体参数如下：
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
·<master-name>：主节点名。
·<role>：Sentinel节点的角色，分别是leader和observer，leader代表当前Sentinel节点是领导者，是它进行的故障转移； observer是其余Sentinel节点。
·<from-ip>：原主节点的ip地址。
·<from-port>：原主节点的端口。
·<to-ip>：新主节点的ip地址。
·<to-port>：新主节点的端口。
例如以下内容分别是三个Sentinel节点发送给脚本的， 其中一个是leader，另外两个是observer：
mymaster leader start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380
有关sentinel notification-script和sentinel client-reconfig-script有几点需要注意：
·<script-path>必须有可执行权限。
·<script-path>开头必须包含shell脚本头（ 例如#！ /bin/sh） ， 否则事件发生时Redis将无法执行脚本产生如下错误：
-script-error /opt/sentinel/notification.sh 0 2
·Redis规定脚本的最大执行时间不能超过60秒，超过后脚本将被杀掉。
·如果shell脚本以exit 1结束，那么脚本稍后重试执行。如果以exit 2或者更高的值结束，那么脚本不会重试。正常返回值是exit 0。

·如果需要运维的Redis Sentinel比较多，建议不要使用这种脚本的形式来进行通知，这样会增加部署的成本。

2.如何监控多个主节点
Redis Sentinel可以同时监控多个主节点，具体拓扑图类似于图9-18。配置方法也比较简单，只需要指定多个masterName来区分不同的主节点即可，例如下面的配置监控monitor master-business-1（10.10.xx.1：6379）和monitor master-business-2（10.10.xx.2：6379）两个主节点：
sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel down-after-milliseconds master-business-1 60000
sentinel failover-timeout master-business-1 180000
sentinel parallel-syncs master-business-1 1
sentinel monitor master-business-2 10.16.xx.2 6380 2
sentinel down-after-milliseconds master-business-2 10000
sentinel failover-timeout master-business-2 180000
sentinel parallel-syncs master-business-2 1

3.调整配置
和普通的Redis数据节点一样，Sentinel节点也支持动态地设置参数，而且和普通的Redis数据节点一样并不是支持所有的参数，具体使用方法如下：
sentinel set <param> <value>
表9-3是sentinel set命令支持的参数。

有几点需要注意一下：
1）sentinel set命令只对当前Sentinel节点有效。
2）sentinel set命令如果执行成功会立即刷新配置文件， 这点和Redis普通数据节点设置配置需要执行config rewrite刷新到配置文件不同。
3）建议所有Sentinel节点的配置尽可能一致，这样在故障发现和转移时比较容易达成一致。
4）表9-3中为sentinel set支持的参数，具体可以参考源码中的sentinel.c的sentinelSetCommand函数。
5）Sentinel对外不支持config命令。

9.2.5 部署技巧
到现在有关Redis Sentinel的配置和部署方法相信读者已经基本掌握了，但在实际生产环境中都有哪些部署的技巧？本节将总结一下。
1）Sentinel节点不应该部署在一台物理“机器”上。
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现Sentinel节点集合真正的高可用，请勿将Sentinel节点部署在同一台物理机器上。
2）部署至少三个且奇数个的Sentinel节点。
3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。有关Sentinel节点如何判断节点失败，如何选举出一个Sentinel节点进行故障转移将在9.5节进行介绍。
4）只有一套Sentinel，还是每个主节点配置一套Sentinel？
Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点，也就意味着部署拓扑可能是图9-19和图9-20两种情况。


                                                                              图9-20 多套Sentine节点集合
那么在实际生产环境中更偏向于哪一种部署方式呢，下面分别分析两种方案的优缺点。
方案一：一套Sentinel，很明显这种方案在一定程度上降低了维护成本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进行管理就可以了。但是这同时也是它的缺点，如果这套Sentinel节点集合出现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响。

方案二：多套Sentinel，显然这种方案的优点和缺点和上面是相反的，每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点也很明显，每套Redis Sentinel都是彼此隔离的。

运维提示
如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用方案一、否则一般建议采用方案二。