一种基于kubernetes托管的redis集故障自愈方法与流程
1.本发明涉及计算机存储技术领域，尤其涉及一种基于kubernetes托管的redis集故障自愈方法。
背景技术：
2.对于redis(remote dictionary server，即远程字典服务)数据库的自愈，以往关注的大多是高可用性，一般场景是：redis主库发生故障的时候，基于预先设定的主从切换方案，或者redis cluster(redis数据库集)内部的容错机制进行故障修复，但这些都仅仅只是应对实例挂掉的高可用方案，不属于自愈方案(实例挂掉的情况下，虽然做了主从切换，保证了业务访问的连续性，但实际并未真正解决容量风险或者副本缺少的风险)。另外，redis集的自愈，不仅仅只是主从切换，还存在容量、网络等故障或者风险下的自愈，目前业界对这些缺乏系统性的配套自愈解决方案。
技术实现要素：
3.为此，本发明提供了一种基于kubernetes托管的redis集故障自愈方法，能够很好的解决上述问题。redis集故障自愈后，确保了和异常发生前的redis集各组件实例数一致，保障了用户访问耗时无异常，且整体集容量不退化，副本数不减少。
4.为实现本发明之目的，采用以下技术方案予以实现：
5.一种基于kubernetes托管的redis集故障自愈方法，包括以下步骤：
6.请求耗时检测：异常检测器模拟用户侧的记录请求访问redis集，并判定请求耗时是否正常；
7.故障自愈：当请求耗时异常时，进行故障自愈操作。
8.所述的redis集故障自愈方法，其中：
9.异常检测器按照预定频次和范围对redis集发送读写请求，模拟用户侧的访问行为；
10.异常检测器将获得的探测数据，通过资源服务器持久化到etcd存储系统中，然后由控制器进行数据分析。
11.所述的redis集故障自愈方法，其中：
12.如果是异常检测器到路由服务器耗时高，但是异常检测器到中间件代理服务器的耗时正常，则说明可能是路由服务器到中间件代理服务器的耗时变长，或者路由服务器因为负载原因导致响应不及时。
13.所述的redis集故障自愈方法，其中：
14.i)如果多个机房内的异常检测器到路由服务器的耗时都异常偏高，则进一步判定对应路由服务器pod内进程cpu的利用率，如果一定周期内cpu的利用率超过预定值，则对路由服务器进行扩容操作。
15.所述的redis集故障自愈方法，其中还包括以下步骤：异常检测器监测每个node
的负载。
16.所述的redis集故障自愈方法，其中还包括以下步骤：异常检测器监测redis集的容量水位。
17.所述的redis集故障自愈方法，其中还包括以下步骤：异常检测器检测集出现耗时是否由用户的慢查询导致。
18.所述的redis集故障自愈方法，其中还包括以下步骤：异常检测器进行实例异常的故障检测。
19.一种基于kubernetes托管的redis集故障自愈系统，包括异常检测器、资源服务器、etcd存储系统、控制器和调度器，其中，所述系统用于执行如上所述的redis集故障自愈方法。
20.一种计算机可读存储器，，存储有处理器可执行指令，当所述指令被处理器执行时，使处理器执行如上所述的方法。
附图说明
21.图1为基于kubernetes托管的redis集故障自愈系统结构示意图；
22.图2为rdis集示意图。
具体实施方式
23.下面结合附图1-2，对本发明的具体实施方式进行详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。所述实施方式是示例性地，仅用于解释本发明，而不能理解为对本发明的限制。显然，本发明所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
24.在本说明书中描述的“一种实施方式”或“一些实施方式”等意味着在本发明的一个或多个实施方式中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
25.如图1所示，本发明的基于kubernetes托管的redis集故障自愈系统包括异常检测器(detector)、资源服务器(kube-apiserver)、etcd存储系统、控制器(redis-k8s-controller)，调度器(kube-scheduler)。
26.其中，异常检测器用于检测网络、机器负载、redis-server，router-server等的健康状态等；资源服务器用于与etcd直接交互，提供kubernetes系统的接口等；etcd存储系统用于存储系统数据；控制器用于控制redis集。
27.如图2所示，redis集主要包括：redis-metaserver(redis集元数据服务器)，router-server(redis集中的消息路由服务器)，redis-server(redis集中的数据存储服务器),redis-sentinel(哨兵模块)。其中，router-server架设在redis-server上面一层，起着消息路由转发的作用，redis-server处理完结果后会返回给router-server，然后
router-server再将结果返回给用户层。
28.本发明的基于kubernetes托管的redis集故障自愈方法包括：
29.1、detector模拟用户侧的记录请求以访问redis集，并判定请求耗时是否正常：
30.1.1detector以服务守护进程(daemonset)的方式运行在机房中的每个node节点(该node节点既可以是物理机也可以是虚拟机)当中，并且确保detector至少是在双机房甚至多机房部署，确保detector探测的是多条不同链路，便于最后汇聚结果作出最终决策。
31.1.2每个机房内的detector，按照一定频次和范围(例如5秒/次，由全局10％的detector执行耗时探测请求)，去对redis集的router-server(redis集中的消息路由服务器)以及redis-server(redis集中的数据存储服务器)发送读写请求，模拟用户侧的访问行为。
32.1.3detector将得到的探测数据，通过资源服务器持久化到etcd存储系统当中，然后由控制器(redis-k8s-controller)感知并进行数据分析和汇总，由此判断是redis-server处理速度变慢了，还是router-server和redis-server之间传输耗时变长了。
33.a)如果detector到router-server耗时高，但是detector到redis-server的耗时正常，则说明可能会是router-server到redis-server的耗时变长，或者router-server因为负载原因导致响应不及时：
34.i)如果是多个机房内的detector到router-server的耗时都异常偏高，则进一步判定对应router-server pod内的进程cpu的利用率，如果一定周期内cpu的利用率持续大于80％，则说明负载过高，需要对router-server进行扩容操作，此时redis-k8s-controller会自动触发扩容行为，按照一定步长维度，扩容router-server pod模块(例如按照多机房，如双机房各扩容10％的比例逐次扩容，然后每扩容一次，比对一下进程cpu利用率，并且判断detector到router-server的耗时)，只有当router-server的平均cpu利用率降低到50％以下，且耗时恢复正常，才停止扩容行为(自愈完成)。
35.ii)如果detector到router-server耗时偏高只存在于单个机房，可采取本地分流的方式进行尝试性故障自愈操作，即判断是否存在与所述异常单个机房距离接近的机房，例如同处于一个建筑物，或者同处于一个内部网段，或者同处于一个城市等，如果存在，则将访问异常机房的部分流量引导到与其距离较近的机房，如果异常机房耗时恢复正常，则完成自愈，如果耗时仍然偏高，则继续以下的步骤：
36.除了判断单机房的router-server pod内进程cpu利用率以外：
37.(1)detector还会发起ping的icmp报文到这批router-server所在的机器(即detector发起ping的icmp报文到在同一个redis集中detector到router-server耗时高的所在机房内的所有router-server)，如果一半以上的机器ping耗时时间超过正常值，则判定为耗时异常波动；
38.(2)并且同时会在后台执行路由追踪(traceroute)命令，用于辅助判断到达各路由器(router-server)的时间，如果一半以上机器的到达时间超过正常值，则判定为耗时异常波动；
39.(3)在后台调用响应时间监测组件(tcprstat)，监听router-server端口，判断router-server返回给detector的报文返回时间，如果一半以上的机器返回时间超过正常值，则判定为耗时异常波动。
40.若cpu利用率异常，则仍然采集1.3-a-i步骤中的扩容方式解决；若cpu利用率正常，但满足1.3-a-ii中的任意一个条件：即出现在一定周期内耗时异常波动的情况，则说明是网络侧导致，此时redis-k8s-controller会尝试屏蔽该单机房的router-server，确保上游流量在此期间，不再转发到该异常单机房的router-server，而是都会路由(转发切换)到正常机房的router-server。屏蔽以及转发切换完成后，redis-k8s-controller会在资源池当中，尝试选取一批和之前异常router-server不同的路由器下的机器(当然，该机器是其他机房的机器)，然后进行网络链路耗时探测，如果正常，则会在此批不同的机器下部署新的router-server，然后销毁之前被屏蔽的router-server，流量由会由这批新的router-server所承载(自愈完成)，被销毁后的资源由资源池回收。
41.2、detector还会监测每个node的负载，如某个节点node的负载平均值(load avg)出现上涨趋势(例如，以最近15分钟内的load avg的采样数据拟合成一个线性函数，通过判断其斜率变化以确定是否是上涨趋势)，并且对应机器(即node对应的物理机或者虚拟机)上的各redis-server pod以及router-server pod的上下文切换频次变高，并且性能指标(cpi指标)也处于上升波动趋势(上述指标的采集都由detector完成)，则说明此node上混部的实例已经较多，存在资源互相竞争的风险，此时redis-k8s-controller会对此node上的进程利用率大于20％的redis-server pod/router-server pod进行排序：
42.1)排名越靠前的pod越会优先被redis-k8s-controller发起驱逐迁移。
43.2)优先迁移router-server pod：考虑到router-server本身无状态，redis-k8s-controller会在资源池中挑选较为空闲的资源池，由kube-scheduler将router-server pod迁移至此。
44.3)次优迁移redis-server pod：redis-server会有master以及slave角，这里会优先迁移redis-slave(从redis服务器)pod，最后才是考虑迁移redis-master(主redis服务器)pod：
45.a)迁移redis-slave的步骤：redis-k8s-controller向对应redis集中的router-server发起控制命令，对应router-server中会下线该redis-slave，以至于读请求不会再路由到该redis-slave。接着redis-k8s-controller会选取其他合适的资源(例如：cpu负载不高(比如30％cpu利用率以下)且物理内存使用率《30％)，最终由kube-scheduler将实例迁移至此。
46.b)迁移redis-master步骤：redis-k8s-controller会对哨兵模块(redis-sentinel)下发故障转移(failover)命令，最终由redis-sentinel执行主从切换操作，此时待迁移的redis-master已经降级为redis-slave角，然后参考上述a)的操作完成迁移动作。
47.4)直到迁移完一定数量的pod后，原有node的load avg负载以及剩余pod cpi指标及上下文切换恢复正常水平，则说明自愈完成。
48.3、除了耗时检测以及负载检测以外，detector还会监测redis集的容量水位。初始状态下每个redis pod默认request为5gb(软限制),limit为10gb(硬限制)，当detector通过kubernetes的核心指标监控器(metrics server)感知到redis pod的内存超过request值的时候，则说明当前redis集存储容量存在风险，则会做如下判断和操作：
49.1)detector会判定redis集各实例的内存是否都超过了pod的request值：
50.a)如果只是个别pod的request的容量超限，说明redis集存在数据倾斜，即：这部分容量超限的分片存在大key(即该key对应的value很大)，detector把这部分异常信息通过kube-apiserver记录到etcd后，redis-k8s-controller会主动触发后台任务，对这部分pod中的redis-slave进行大key分析：
51.i)如果redis集配置了key过期策略(如lru-volatile)，则redis会尝试将遍历到的(配置了ttl)已到生存周期的大key进行主动删除操作，至此删除完对应数据后，容量降低到request值之下(自愈结束)。
52.ii)如果redis集没有配置key过期策略(no-eviction)，则redis-k8s-controller不做任何操作，而是以短信/邮件方式附带大key分析报告，一并通知到redis运维人员进行人工接入处理。
53.b)如果对应各个pod的容量都超限，则说明需要扩容，此时的操作会是redis-k8s-controller在可用资源池中扩容新的redis pod，然后给redis-metaserver-hot(元数据主服务器)发起迁移命令，最终由redis-metaserver-hot底层完成集扩容后，将扩容结果通过kube-apiserver持久化到etcd当中，然后redis-k8s-controller感知到扩容完成，并再次检查redis集中各个分片的容量是否低于request值，如果是则自愈结束，如果否则继续执行扩容操作，直到redis集中各个分片的容量都低于request值。
54.4、针对detector检查到集出现耗时变长，但实际是由部分用户的慢查询导致的情况(例如：detector到router-server耗时不高，而到redis-server耗时高，则说明大概率是用户侧慢查询导致出现这种情况)，则redis-k8s-controller会判定持续周期，如果只是较为短暂的波动，则不会做任何操作，如果持续大于一定时长，则执行以下操作：
55.1)对于局部读热点而言，redis-k8s-controller会扩容对应分片下的redis-slave pod来尝试分摊对应读流量(尝试自愈)。
56.例如一个redis集有3个分片，但是用户读请求大部分都路由到其中某个分片上，这种场景就叫做局部读热点。
57.分摊读流量的方式包括：扩redis-slave pod(纵向扩容)，同时router-server的拓扑配置联动变更。“自愈”的判定主要判断耗时大小即可，耗时恢复至常态则可以理解为自愈结束。
58.2)如果上述方案仍然解决不了或者应对的是局部写热点场景，则将此部分信息以短信/邮件方式推送到redis运维人员进行介入处理。
59.可选的，本发明还提供了实例异常的故障自愈方法，如下：
60.1、对于redis-server pod或者router-server pod异常挂掉，或者node宕机，亦或是detector到pod之间的访问不可达，将会采取如下操作：
61.1)对于单个router-server pod异常，则redis-k8s-controller联动kube-scheduler直接在可用资源池中部署一个新的pod，并下线旧的pod(自愈结束)。
62.2)对于单个redis-master pod异常，则会先由redis-sentinel完成对应的主从切换，然后再由redis-k8s-controller联动kube-scheduler完成kube-slave pod部署，并下线旧的pod(自愈结束)。
63.3)对于单个redis-slave异常，redis-k8s-controller会对其进行屏蔽，然后启动(spawn)出新的redis-slave pod后，再下线旧的pod(自愈结束)。
64.2、对于metaserver的异常挂掉或者其它原因导致访问不通，这里的处理机制为：
65.1)针对metaserver-pod-hot：如果metaserver半数以上可用，则会在剩余metaserver-pod-standby(备选或从metaserver-pod)中，选举一个权重较高的作为新的metaserver-pod-hot，并且由redis-k8s-controller联动kube-scheduler部署一个新的metaserver-pod-hot，并下线旧的pod(自愈结束)。
66.2)针对metaserver-pod-standby：不影响正常metaserver集运转，只需要由redis-k8s-controller联动kube-scheduler部署一个新的metaserver-pod-hot，并下线旧的pod(自愈结束)。
67.根据本公开一个实施方式，提供了一种计算机可读存储介质。本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。为此，本技术实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本技术实施例所提供的任意一种基于kubernetes托管的redis集故障自愈方法的步骤。
68.其中，该存储介质可以包括：只读存储器(rom，read only memory)、随机存取记忆体(ram，random access memory)、磁盘或光盘等，更具体来说，可包括静态随机存取存储器(static random-access memory，sram)和动态随机存取存储器(dynamic random access memory，dram)等具体类别。
69.由于该存储介质中所存储的指令，可以执行本技术实施例所提供的任意基于kubernetes托管的redis集故障自愈方法的步骤，因此，可以实现本技术实施例所能实现的有益效果，详见前面的实施例，在此不再赘述。以上各个操作的具体实施可参见前面的实施例，在此也不再赘述。
70.通过本发明，实现了多种常见场景下redis集的故障自愈(例如：耗时变慢、容量不足、实例挂掉等)；同时在保障用户访问redis集的可用性以及连续性同时，最大可能保障了集的容量不退化，耗时平稳。
71.以上，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭示如上，然而并非用以限定本发明，任何本领域技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容做出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简介修改、等同变化与修饰，均仍属于本发明技术方案的范围内。
