CN115396291A - 一种基于kubernetes托管的redis集群故障自愈方法 - Google Patents
一种基于kubernetes托管的redis集群故障自愈方法 Download PDFInfo
- Publication number
- CN115396291A CN115396291A CN202211013863.3A CN202211013863A CN115396291A CN 115396291 A CN115396291 A CN 115396291A CN 202211013863 A CN202211013863 A CN 202211013863A CN 115396291 A CN115396291 A CN 115396291A
- Authority
- CN
- China
- Prior art keywords
- redis
- redis cluster
- healing
- server
- self
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 38
- 230000002159 abnormal effect Effects 0.000 claims abstract description 14
- 238000001514 detection method Methods 0.000 claims abstract description 12
- 230000008569 process Effects 0.000 claims description 7
- 230000006399 behavior Effects 0.000 claims description 5
- 230000002035 prolonged effect Effects 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 claims description 3
- 230000005856 abnormality Effects 0.000 claims description 2
- 238000007405 data analysis Methods 0.000 claims description 2
- 230000005012 migration Effects 0.000 description 5
- 238000013508 migration Methods 0.000 description 5
- 239000012634 fragment Substances 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000012886 linear function Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 235000008113 selfheal Nutrition 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
Abstract
本发明公开了一种基于kubernetes托管的redis集群故障自愈方法，包括以下步骤：请求耗时检测：异常检测器模拟用户侧的记录请求访问redis集群，并判定请求耗时是否正常；故障自愈：当请求耗时异常时，进行故障自愈操作。通过本发明，实现了多种常见场景下redis集群的故障自愈，同时在保障用户访问redis集群的可用性以及连续性同时，最大可能的保障了集群的容量不退化，耗时平稳。
Description
技术领域
本发明涉及计算机存储技术领域，尤其涉及一种基于kubernetes托管的redis集群故障自愈方法。
背景技术
对于redis(Remote Dictionary Server，即远程字典服务)数据库的自愈，以往关注的大多是高可用性，一般场景是：redis主库发生故障的时候，基于预先设定的主从切换方案，或者redis cluster(redis数据库集群)内部的容错机制进行故障修复，但这些都仅仅只是应对实例挂掉的高可用方案，不属于自愈方案(实例挂掉的情况下，虽然做了主从切换，保证了业务访问的连续性，但实际并未真正解决容量风险或者副本缺少的风险)。另外，redis集群的自愈，不仅仅只是主从切换，还存在容量、网络等故障或者风险下的自愈，目前业界对这些缺乏系统性的配套自愈解决方案。
发明内容
为此，本发明提供了一种基于kubernetes托管的redis集群故障自愈方法，能够很好的解决上述问题。redis集群故障自愈后，确保了和异常发生前的redis集群各组件实例数一致，保障了用户访问耗时无异常，且整体集群容量不退化，副本数不减少。
为实现本发明之目的，采用以下技术方案予以实现：
一种基于kubernetes托管的redis集群故障自愈方法，包括以下步骤：
请求耗时检测：异常检测器模拟用户侧的记录请求访问redis集群，并判定请求耗时是否正常；
故障自愈：当请求耗时异常时，进行故障自愈操作。
所述的redis集群故障自愈方法，其中：
异常检测器按照预定频次和范围对redis集群发送读写请求，模拟用户侧的访问行为；
异常检测器将获得的探测数据，通过资源服务器持久化到etcd存储系统中，然后由控制器进行数据分析。
所述的redis集群故障自愈方法，其中：
如果是异常检测器到路由服务器耗时高，但是异常检测器到中间件代理服务器的耗时正常，则说明可能是路由服务器到中间件代理服务器的耗时变长，或者路由服务器因为负载原因导致响应不及时。
所述的redis集群故障自愈方法，其中：
i)如果多个机房内的异常检测器到路由服务器的耗时都异常偏高，则进一步判定对应路由服务器pod内进程CPU的利用率，如果一定周期内CPU的利用率超过预定值，则对路由服务器进行扩容操作。
所述的redis集群故障自愈方法，其中还包括以下步骤：异常检测器监测每个node的负载。
所述的redis集群故障自愈方法，其中还包括以下步骤：异常检测器监测redis集群的容量水位。
所述的redis集群故障自愈方法，其中还包括以下步骤：异常检测器检测集群出现耗时是否由用户的慢查询导致。
所述的redis集群故障自愈方法，其中还包括以下步骤：异常检测器进行实例异常的故障检测。
一种基于kubernetes托管的redis集群故障自愈系统，包括异常检测器、资源服务器、etcd存储系统、控制器和调度器，其中，所述系统用于执行如上所述的redis集群故障自愈方法。
一种计算机可读存储器，，存储有处理器可执行指令，当所述指令被处理器执行时，使处理器执行如上所述的方法。
附图说明
图1为基于kubernetes托管的redis集群故障自愈系统结构示意图；
图2为rdis集群示意图。
具体实施方式
下面结合附图1-2，对本发明的具体实施方式进行详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。所述实施方式是示例性地，仅用于解释本发明，而不能理解为对本发明的限制。显然，本发明所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本说明书中描述的“一种实施方式”或“一些实施方式”等意味着在本发明的一个或多个实施方式中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
如图1所示，本发明的基于kubernetes托管的redis集群故障自愈系统包括异常检测器(detector)、资源服务器(kube-apiserver)、etcd存储系统、控制器(redis-k8s-controller)，调度器(kube-scheduler)。
其中，异常检测器用于检测网络、机器负载、redis-server，router-server等的健康状态等；资源服务器用于与etcd直接交互，提供Kubernetes系统的接口等；etcd存储系统用于存储系统数据；控制器用于控制redis集群。
如图2所示，redis集群主要包括：redis-metaserver(redis集群元数据服务器)，router-server(redis集群中的消息路由服务器)，redis-server(redis集群中的数据存储服务器),redis-sentinel(哨兵模块)。其中，Router-server架设在redis-server上面一层，起着消息路由转发的作用，Redis-server处理完结果后会返回给router-server，然后router-server再将结果返回给用户层。
本发明的基于kubernetes托管的redis集群故障自愈方法包括：
1、Detector模拟用户侧的记录请求以访问redis集群，并判定请求耗时是否正常：
1.1Detector以服务守护进程(daemonset)的方式运行在机房中的每个node节点(该node节点既可以是物理机也可以是虚拟机)当中，并且确保Detector至少是在双机房甚至多机房部署，确保detector探测的是多条不同链路，便于最后汇聚结果作出最终决策。
1.2每个机房内的Detector，按照一定频次和范围(例如5秒/次，由全局10％的Detector执行耗时探测请求)，去对redis集群的router-server(redis集群中的消息路由服务器)以及redis-server(redis集群中的数据存储服务器)发送读写请求，模拟用户侧的访问行为。
1.3Detector将得到的探测数据，通过资源服务器持久化到etcd存储系统当中，然后由控制器(redis-k8s-controller)感知并进行数据分析和汇总，由此判断是redis-server处理速度变慢了，还是router-server和redis-server之间传输耗时变长了。
a)如果detector到router-server耗时高，但是detector到redis-server的耗时正常，则说明可能会是router-server到redis-server的耗时变长，或者router-server因为负载原因导致响应不及时：
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％以下，且耗时恢复正常，才停止扩容行为(自愈完成)。
ii)如果detector到router-server耗时偏高只存在于单个机房，可采取本地分流的方式进行尝试性故障自愈操作，即判断是否存在与所述异常单个机房距离接近的机房，例如同处于一个建筑物，或者同处于一个内部网段，或者同处于一个城市等，如果存在，则将访问异常机房的部分流量引导到与其距离较近的机房，如果异常机房耗时恢复正常，则完成自愈，如果耗时仍然偏高，则继续以下的步骤：
除了判断单机房的router-server pod内进程CPU利用率以外：
(1)detector还会发起ping的ICMP报文到这批router-server所在的机器(即detector发起ping的ICMP报文到在同一个redis集群中detector到router-server耗时高的所在机房内的所有router-server)，如果一半以上的机器ping耗时时间超过正常值，则判定为耗时异常波动；
(2)并且同时会在后台执行路由追踪(traceroute)命令，用于辅助判断到达各路由器(router-server)的时间，如果一半以上机器的到达时间超过正常值，则判定为耗时异常波动；
(3)在后台调用响应时间监测组件(tcprstat)，监听router-server端口，判断router-server返回给detector的报文返回时间，如果一半以上的机器返回时间超过正常值，则判定为耗时异常波动。
若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所承载(自愈完成)，被销毁后的资源由资源池回收。
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进行排序：
1)排名越靠前的pod越会优先被redis-k8s-controller发起驱逐迁移。
2)优先迁移router-server pod：考虑到router-server本身无状态，redis-k8s-controller会在资源池中挑选较为空闲的资源池，由kube-scheduler将router-serverpod迁移至此。
3)次优迁移redis-server pod：redis-server会有master以及slave角色，这里会优先迁移redis-slave(从redis服务器)pod，最后才是考虑迁移redis-master(主redis服务器)pod：
a)迁移redis-slave的步骤：redis-k8s-controller向对应redis集群中的router-server发起控制命令，对应router-server中会下线该redis-slave，以至于读请求不会再路由到该redis-slave。接着redis-k8s-controller会选取其他合适的资源(例如：CPU负载不高(比如30％CPU利用率以下)且物理内存使用率<30％)，最终由kube-scheduler将实例迁移至此。
b)迁移redis-master步骤：redis-k8s-controller会对哨兵模块(redis-sentinel)下发故障转移(failover)命令，最终由redis-sentinel执行主从切换操作，此时待迁移的redis-master已经降级为redis-slave角色，然后参考上述a)的操作完成迁移动作。
4)直到迁移完一定数量的pod后，原有node的load avg负载以及剩余pod CPI指标及上下文切换恢复正常水平，则说明自愈完成。
3、除了耗时检测以及负载检测以外，detector还会监测redis集群的容量水位。初始状态下每个redis pod默认request为5GB(软限制),limit为10GB(硬限制)，当detector通过kubernetes的核心指标监控器(metrics server)感知到redis pod的内存超过request值的时候，则说明当前redis集群存储容量存在风险，则会做如下判断和操作：
1)Detector会判定redis集群各实例的内存是否都超过了pod的Request值：
a)如果只是个别pod的request的容量超限，说明redis集群存在数据倾斜，即：这部分容量超限的分片存在大key(即该key对应的value很大)，detector把这部分异常信息通过Kube-apiserver记录到etcd后，redis-k8s-controller会主动触发后台任务，对这部分pod中的redis-slave进行大key分析：
i)如果redis集群配置了key过期策略(如lru-volatile)，则redis会尝试将遍历到的(配置了TTL)已到生存周期的大key进行主动删除操作，至此删除完对应数据后，容量降低到request值之下(自愈结束)。
ii)如果redis集群没有配置key过期策略(no-eviction)，则redis-k8s-controller不做任何操作，而是以短信/邮件方式附带大key分析报告，一并通知到redis运维人员进行人工接入处理。
b)如果对应各个pod的容量都超限，则说明需要扩容，此时的操作会是redis-k8s-controller在可用资源池中扩容新的redis pod，然后给redis-metaserver-hot(元数据主服务器)发起迁移命令，最终由redis-metaserver-hot底层完成集群扩容后，将扩容结果通过kube-apiserver持久化到etcd当中，然后redis-k8s-controller感知到扩容完成，并再次检查redis集群中各个分片的容量是否低于request值，如果是则自愈结束，如果否则继续执行扩容操作，直到redis集群中各个分片的容量都低于request值。
4、针对detector检查到集群出现耗时变长，但实际是由部分用户的慢查询导致的情况(例如：detector到router-server耗时不高，而到redis-server耗时高，则说明大概率是用户侧慢查询导致出现这种情况)，则redis-k8s-controller会判定持续周期，如果只是较为短暂的波动，则不会做任何操作，如果持续大于一定时长，则执行以下操作：
1)对于局部读热点而言，redis-k8s-controller会扩容对应分片下的redis-slave pod来尝试分摊对应读流量(尝试自愈)。
例如一个redis集群有3个分片，但是用户读请求大部分都路由到其中某个分片上，这种场景就叫做局部读热点。
分摊读流量的方式包括：扩redis-slave pod(纵向扩容)，同时router-server的拓扑配置联动变更。“自愈”的判定主要判断耗时大小即可，耗时恢复至常态则可以理解为自愈结束。
2)如果上述方案仍然解决不了或者应对的是局部写热点场景，则将此部分信息以短信/邮件方式推送到redis运维人员进行介入处理。
可选的，本发明还提供了实例异常的故障自愈方法，如下：
1、对于redis-server pod或者router-server pod异常挂掉，或者node宕机，亦或是detector到pod之间的访问不可达，将会采取如下操作：
1)对于单个router-server pod异常，则redis-k8s-controller联动kube-scheduler直接在可用资源池中部署一个新的pod，并下线旧的pod(自愈结束)。
2)对于单个redis-master pod异常，则会先由redis-sentinel完成对应的主从切换，然后再由redis-k8s-controller联动kube-scheduler完成kube-slave pod部署，并下线旧的pod(自愈结束)。
3)对于单个redis-slave异常，redis-k8s-controller会对其进行屏蔽，然后启动(spawn)出新的redis-slave pod后，再下线旧的pod(自愈结束)。
2、对于metaserver的异常挂掉或者其它原因导致访问不通，这里的处理机制为：
1)针对Metaserver-pod-hot：如果metaserver半数以上可用，则会在剩余metaserver-pod-standby(备选或从metaserver-pod)中，选举一个权重较高的作为新的metaserver-pod-hot，并且由redis-k8s-controller联动kube-scheduler部署一个新的metaserver-pod-hot，并下线旧的pod(自愈结束)。
2)针对metaserver-pod-standby：不影响正常metaserver集群运转，只需要由redis-k8s-controller联动kube-scheduler部署一个新的metaserver-pod-hot，并下线旧的pod(自愈结束)。
根据本公开一个实施方式，提供了一种计算机可读存储介质。本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。为此，本申请实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任意一种基于kubernetes托管的redis集群故障自愈方法的步骤。
其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等，更具体来说，可包括静态随机存取存储器(Static Random-Access Memory，SRAM)和动态随机存取存储器(Dynamic Random AccessMemory，DRAM)等具体类别。
由于该存储介质中所存储的指令，可以执行本申请实施例所提供的任意基于kubernetes托管的redis集群故障自愈方法的步骤，因此，可以实现本申请实施例所能实现的有益效果，详见前面的实施例，在此不再赘述。以上各个操作的具体实施可参见前面的实施例，在此也不再赘述。
通过本发明，实现了多种常见场景下redis集群的故障自愈(例如：耗时变慢、容量不足、实例挂掉等)；同时在保障用户访问redis集群的可用性以及连续性同时，最大可能保障了集群的容量不退化，耗时平稳。
以上，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭示如上，然而并非用以限定本发明，任何本领域技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容做出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简介修改、等同变化与修饰，均仍属于本发明技术方案的范围内。
Claims (10)
1.一种基于kubernetes托管的redis集群故障自愈方法，其特征在于包括以下步骤：
请求耗时检测：异常检测器模拟用户侧的记录请求访问redis集群，并判定请求耗时是否正常；
故障自愈：当请求耗时异常时，进行故障自愈操作。
2.根据权利要求1所述的redis集群故障自愈方法，其特征在于：异常检测器按照预定频次和范围对redis集群发送读写请求，模拟用户侧的访问行为；
异常检测器将获得的探测数据，通过资源服务器持久化到etcd存储系统中，然后由控制器进行数据分析。
3.根据权利要求2所述的redis集群故障自愈方法，其特征在于：
如果是异常检测器到路由服务器耗时高，但是异常检测器到中间件代理服务器的耗时正常，则说明可能是路由服务器到中间件代理服务器的耗时变长，或者路由服务器因为负载原因导致响应不及时。
4.根据权利要求3所述的redis集群故障自愈方法，其特征在于：
i)如果多个机房内的异常检测器到路由服务器的耗时都异常偏高，则进一步判定对应路由服务器pod内进程CPU的利用率，如果一定周期内CPU的利用率超过预定值，则对路由服务器进行扩容操作。
5.根据权利要求1所述的redis集群故障自愈方法，其特征在于还包括以下步骤：异常检测器监测每个node的负载。
6.根据权利要求1所述的redis集群故障自愈方法，其特征在于还包括以下步骤：异常检测器监测redis集群的容量水位。
7.根据权利要求1所述的redis集群故障自愈方法，其特征在于还包括以下步骤：异常检测器检测集群出现耗时是否由用户的慢查询导致。
8.根据权利要求1所述的redis集群故障自愈方法，其特征在于还包括以下步骤：异常检测器进行实例异常的故障检测。
9.一种基于kubernetes托管的redis集群故障自愈系统，包括异常检测器、资源服务器、etcd存储系统、控制器和调度器，其特征在于，所述系统用于执行如权利要求1-8任一项所述的redis集群故障自愈方法。
10.一种计算机可读存储器，其特征在于，存储有处理器可执行指令，当所述指令被处理器执行时，使处理器执行根据权利要求1至8中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211013863.3A CN115396291A (zh) | 2022-08-23 | 2022-08-23 | 一种基于kubernetes托管的redis集群故障自愈方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211013863.3A CN115396291A (zh) | 2022-08-23 | 2022-08-23 | 一种基于kubernetes托管的redis集群故障自愈方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115396291A true CN115396291A (zh) | 2022-11-25 |
Family
ID=84121685
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211013863.3A Pending CN115396291A (zh) | 2022-08-23 | 2022-08-23 | 一种基于kubernetes托管的redis集群故障自愈方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115396291A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115994045A (zh) * | 2023-02-22 | 2023-04-21 | 深圳计算科学研究院 | 一种基于共享存储数据库集群的事务托管方法及装置 |
| CN116204286A (zh) * | 2022-12-21 | 2023-06-02 | 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) | 一种支持拓扑感知的Kubernetes调度方法 |
Citations (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4242751A (en) * | 1978-08-28 | 1980-12-30 | Genrad, Inc. | Automatic fault-probing method and apparatus for checking electrical circuits and the like |
| US20030187853A1 (en) * | 2002-01-24 | 2003-10-02 | Hensley Roy Austin | Distributed data storage system and method |
| CN1464397A (zh) * | 2002-06-10 | 2003-12-31 | 联想(北京)有限公司 | 系统进程的保护方法 |
| CN101136790A (zh) * | 2006-09-01 | 2008-03-05 | 中兴通讯股份有限公司 | 以太网交换机集群管理的自动化测试系统及方法 |
| CN105407011A (zh) * | 2015-10-26 | 2016-03-16 | 贵州电网公司信息通信分公司 | 一种it基础平台监控指标采集系统及采集方法 |
| US20180091586A1 (en) * | 2016-09-26 | 2018-03-29 | Linkedin Corporation | Self-healing a message brokering cluster |
| CN110704223A (zh) * | 2019-09-16 | 2020-01-17 | 苏宁云计算有限公司 | 一种数据库单节点异常的恢复系统和方法 |
| CN111459698A (zh) * | 2020-03-31 | 2020-07-28 | 国网电力科学研究院有限公司 | 一种数据库集群故障自愈方法及装置 |
| CN112328372A (zh) * | 2020-11-27 | 2021-02-05 | 新华智云科技有限公司 | 一种kubernetes节点自愈方法和系统 |
| CN112749064A (zh) * | 2021-01-21 | 2021-05-04 | 北京明略昭辉科技有限公司 | 一种软件应用服务故障预测及故障自愈的方法及系统 |
| CN113422692A (zh) * | 2021-05-28 | 2021-09-21 | 作业帮教育科技（北京）有限公司 | 一种K8s集群内节点故障检测及处理方法、装置及存储介质 |
| CN114020509A (zh) * | 2021-10-29 | 2022-02-08 | 济南浪潮数据技术有限公司 | 工作负载集群的修复方法、装置、设备及可读存储介质 |
| CN114116288A (zh) * | 2021-11-24 | 2022-03-01 | 北京百度网讯科技有限公司 | 故障处理方法、装置及计算机程序产品 |
| CN114244687A (zh) * | 2021-12-20 | 2022-03-25 | 中国电信集团系统集成有限责任公司 | 基于AIOps网络故障自愈可操作性判断方法 |
| CN114385453A (zh) * | 2022-01-13 | 2022-04-22 | 平安付科技服务有限公司 | 数据库集群异常处理方法、装置、设备及介质 |
| CN114553747A (zh) * | 2022-02-22 | 2022-05-27 | 度小满科技(北京)有限公司 | redis集群的异常检测方法、装置、终端及存储介质 |
-
2022
- 2022-08-23 CN CN202211013863.3A patent/CN115396291A/zh active Pending
Patent Citations (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4242751A (en) * | 1978-08-28 | 1980-12-30 | Genrad, Inc. | Automatic fault-probing method and apparatus for checking electrical circuits and the like |
| US20030187853A1 (en) * | 2002-01-24 | 2003-10-02 | Hensley Roy Austin | Distributed data storage system and method |
| CN1464397A (zh) * | 2002-06-10 | 2003-12-31 | 联想(北京)有限公司 | 系统进程的保护方法 |
| CN101136790A (zh) * | 2006-09-01 | 2008-03-05 | 中兴通讯股份有限公司 | 以太网交换机集群管理的自动化测试系统及方法 |
| CN105407011A (zh) * | 2015-10-26 | 2016-03-16 | 贵州电网公司信息通信分公司 | 一种it基础平台监控指标采集系统及采集方法 |
| US20180091586A1 (en) * | 2016-09-26 | 2018-03-29 | Linkedin Corporation | Self-healing a message brokering cluster |
| CN110704223A (zh) * | 2019-09-16 | 2020-01-17 | 苏宁云计算有限公司 | 一种数据库单节点异常的恢复系统和方法 |
| CN111459698A (zh) * | 2020-03-31 | 2020-07-28 | 国网电力科学研究院有限公司 | 一种数据库集群故障自愈方法及装置 |
| CN112328372A (zh) * | 2020-11-27 | 2021-02-05 | 新华智云科技有限公司 | 一种kubernetes节点自愈方法和系统 |
| CN112749064A (zh) * | 2021-01-21 | 2021-05-04 | 北京明略昭辉科技有限公司 | 一种软件应用服务故障预测及故障自愈的方法及系统 |
| CN113422692A (zh) * | 2021-05-28 | 2021-09-21 | 作业帮教育科技（北京）有限公司 | 一种K8s集群内节点故障检测及处理方法、装置及存储介质 |
| CN114020509A (zh) * | 2021-10-29 | 2022-02-08 | 济南浪潮数据技术有限公司 | 工作负载集群的修复方法、装置、设备及可读存储介质 |
| CN114116288A (zh) * | 2021-11-24 | 2022-03-01 | 北京百度网讯科技有限公司 | 故障处理方法、装置及计算机程序产品 |
| CN114244687A (zh) * | 2021-12-20 | 2022-03-25 | 中国电信集团系统集成有限责任公司 | 基于AIOps网络故障自愈可操作性判断方法 |
| CN114385453A (zh) * | 2022-01-13 | 2022-04-22 | 平安付科技服务有限公司 | 数据库集群异常处理方法、装置、设备及介质 |
| CN114553747A (zh) * | 2022-02-22 | 2022-05-27 | 度小满科技(北京)有限公司 | redis集群的异常检测方法、装置、终端及存储介质 |
Non-Patent Citations (4)
| Title |
|---|
| K8S技术圈: "Kubernetes 故障检测和自愈工具", Retrieved from the Internet <URL:https://www.qinglite.cn/doc/27996476726fd77cc> * |
| TATSUHIRO CHIBA等: "ConfAdvisor: A Performance-centric Configuration Tuning Framework for Containers on Kubernetes", 《2019 IEEE INTERNATIONAL CONFERENCE ON CLOUD ENGINEERING (IC2E)》 * |
| 倪冬云等: "基于大数据分析的信息系统故障自动修复方法", 电子设计工程, no. 10, 20 May 2020 (2020-05-20) * |
| 肖安: "大规模容器云平台稳定性闭环解决方案的设计与实现", 《万方数据库》 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116204286A (zh) * | 2022-12-21 | 2023-06-02 | 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) | 一种支持拓扑感知的Kubernetes调度方法 |
| CN116204286B (zh) * | 2022-12-21 | 2023-12-12 | 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) | 一种支持拓扑感知的Kubernetes调度方法 |
| CN115994045A (zh) * | 2023-02-22 | 2023-04-21 | 深圳计算科学研究院 | 一种基于共享存储数据库集群的事务托管方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3518110B1 (en) | Designation of a standby node | |
| CN115396291A (zh) | 一种基于kubernetes托管的redis集群故障自愈方法 | |
| US11320991B2 (en) | Identifying sub-health object storage devices in a data storage system | |
| US11886731B2 (en) | Hot data migration method, apparatus, and system | |
| CN110224871B (zh) | 一种Redis集群的高可用方法及装置 | |
| CN104036043B (zh) | 一种mysql高可用的方法及管理节点 | |
| US20120197822A1 (en) | System and method for using cluster level quorum to prevent split brain scenario in a data grid cluster | |
| JP2007279890A (ja) | バックアップシステム及びバックアップ方法 | |
| JP2011128967A (ja) | 仮想計算機の移動方法、仮想計算機システム及びプログラム | |
| US20160306710A1 (en) | Method and system for recovering virtual network | |
| CN112948128A (zh) | Target端的选择方法、系统及计算机可读介质 | |
| US20180097701A1 (en) | Method for processing virtual machine cluster and computer system | |
| JP5855724B1 (ja) | 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム | |
| CN109582459A (zh) | 应用的托管进程进行迁移的方法及装置 | |
| CN111935244B (zh) | 一种业务请求处理系统及超融合一体机 | |
| CN107357800A (zh) | 一种数据库高可用零丢失解决方法 | |
| CN111181780A (zh) | 基于ha集群的主机池切换方法、系统、终端及存储介质 | |
| Mahjoubi et al. | LBFT: Load Balancing and Fault Tolerance in distributed controllers | |
| CN111988347B (zh) | 跳板机系统的数据处理方法和跳板机系统 | |
| CN112887367B (zh) | 实现分布式集群高可用的方法、系统及计算机可读介质 | |
| CN110377487A (zh) | 一种处理高可用集群脑裂的方法及装置 | |
| CN105959145A (zh) | 一种适用高可用性集群的并行管理服务器的方法及系统 | |
| JP2011209811A (ja) | 仮想マシンシステムおよび仮想マシン配置方法 | |
| CN111400285A (zh) | mySQL数据分片处理方法、装置、计算机设备和可读存储介质 | |
| CN110445803A (zh) | 一种异构云平台的业务平滑迁移方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |