CN114860488A - 容错方法、性能校验方法、电子设备及介质 - Google Patents

容错方法、性能校验方法、电子设备及介质 Download PDF

Info

Publication number
CN114860488A
CN114860488A CN202210409828.7A CN202210409828A CN114860488A CN 114860488 A CN114860488 A CN 114860488A CN 202210409828 A CN202210409828 A CN 202210409828A CN 114860488 A CN114860488 A CN 114860488A
Authority
CN
China
Prior art keywords
container cluster
bft
replication protocol
smart
container
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.)
Granted
Application number
CN202210409828.7A
Other languages
English (en)
Other versions
CN114860488B (zh
Inventor
何志明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202210409828.7A priority Critical patent/CN114860488B/zh
Publication of CN114860488A publication Critical patent/CN114860488A/zh
Application granted granted Critical
Publication of CN114860488B publication Critical patent/CN114860488B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4498—Finite state machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Hardware Redundancy (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请提供了一种应用于容器集群的容错方法，容器集群内置有Raft复制协议，方法包括在容器集群内部署BFT‑SMaRt复制协议；根据容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议来同步容器集群内个节点的状态机状态以实现容器集群的容错。通过配置两种复制协议，并进一步确定在两种复制协议的应用场景，确保以最少的资源消耗保证最佳的容错效果，克服拜占庭错误，保证系统服务的连续性。

Description

容错方法、性能校验方法、电子设备及介质
技术领域
本发明涉及云计算领域，特别涉及一种应用于容器集群的容错方法、性能校验方法、电子设备及介质。
背景技术
Docker容器虚拟化技术因其轻量级和高效性而被泛应用于云计算环境。但是，它需要通过协调器进行充分的控制和管理。因此，云提供商正在采用开放访问的Kubernetes(K8S)平台作为容器化应用程序的标准编排器。Kubernetes是Google的一个开放项目，倡导模块化、可定制且可扩展的编排平台。为了保证托管应用程序的可用性和连续性。
在大型和/或不受控制的系统中，故障风险很高，现有的降低风险以确保服务连续性的一种方法是使用状态机复制(SMR)机制，包括使用系统的多个副本，实现为状态机，以容忍故障并保持系统的可用性。系统的每个副本都放置在不同的节点上。SMR允许一组节点对客户端发送的每个请求执行相同的指令序列。执行请求有两种方法：1)主动复制，所有节点执行请求，更新其状态机，并响应客户端。2)被动复制，只有一个节点，称为领导者，执行请求并将状态机更改转发给其他节点，然后响应客户端。为了避免复制中的不一致，节点/副本需要确保它们的状态机在响应客户端之前是相同的。状态机的这个复制问题被称为共识问题。解决共识问题所消耗的时间即为共识时间，定义为处理客户请求所需的时间。
K8S集群通常仅使用Raft复制协议，来确保副本保持相同的状态机，同时只容忍崩溃故障。它基于被动复制，其中一个节点可能是领导者、追随者或候选者。当领导者处于活动状态时，所有其他节点都设置为追随者。它们等待领导者发送的更改来更新他们的状态机。当领导者崩溃时，追随者成为候选者并触发投票选出新的领导者。跟随者需要等待一个随机时间，通常在150到300毫秒之间，然后才能转换为候选者。这就导致Raft协议的共识时间比较长，且只容忍崩溃故障，对拜占庭错误无能为力。此外，还存在另一种非拜占庭复制协议，称为DORADO协议类似于Raft协议，但需要将主节点的内存共享给工作节点中的所有实例化容器，以存储它们的状态机。这种方法可以实现比Raft更短的共识时间，但加剧了容器的隔离问题，对拜占庭错误也无能为力。
目前针对K8S容器集群抵抗拜占庭故障的研究工作较少，而在实际大规模的K8S集群中，往往会因为软件错误或恶意攻击导致机器表现出拜占庭(即随机)行为，造成集群整体的成本损耗、破坏复制协议的准确性和可用性。因此如何设计能确保集群能够抵抗拜占庭和非拜占庭故障，具有实际重要意义。
发明内容
为了解决现有技术的不足，本发明的主要目的在于提供一种应用于K8S集群的容错方法、系统、性能校验方法及电子设备，以解决现有技术的上述技术问题。
为了达到上述目的，第一方面本发明提供了应用于容器集群的容错方法，所述容器集群内置有Raft复制协议，其特征在于，所述方法包括：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
在一些实施例中，所述根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步集群内各节点的状态机状态，以实现容器集群的容错，包括：
若所述容器集群内不存在拜占庭故障，则调用Raft复制协议同步所述容器集群内各节点的状态机状态；
若所述容器集群内存在拜占庭故障，则根据所述容器集群内的崩溃故障数来调用合适的复制协议同步所述容器集群内各节点的状态机状态。
在一些实施例中，所述根据所述容器集群内的崩溃故障数来调用合适的复制协议同步所述容器集群内各节点的状态机状态，包括：
若所述容器集群内的崩溃故障数小于Raft复制协议允许的最大故障数，则根据拜占庭故障产生速率调用合适的复制协议来同步所述容器集群内各节点的状态机状态；
若容器集群内的崩溃故障数大于等于Raft复制协议允许的最大故障数，则调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
在一些实施例中，所述根据拜占庭故障产生速率来调用合适的复制协议来同步所述容器集群内各节点的状态机状态，包括：
若拜占庭故障产生速率小于预设阈值，则调用Raft复制协议来同步所述容器集群内各节点的状态机状态；
若拜占庭故障产生速率大于等于预设阈值，则调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
在一些实施例中，所述在容器集群内部署BFT-SMaRt复制协议，包括：
获取BFT-SMaRt库；
根据所述BFT-SMaRt库创建BFT-SMaRt容器镜像；
在所述容器集群主节点内实例化所述BFT-SMaRt容器镜像。
在一些实施例中，所述获取BFT-SMaRt库包括：
获取标准的BFT-SMaRt库；
根据所述容器集群主节点的参数修改标准的BFT-SMaRt库的参数。
第二方面，本申请提供了性能校验方法，所述方法包括：
创建DDoS攻击，模拟拜占庭错误；
控制容器集群内崩溃故障数，获取存在低DDoS攻击速率下的调用BFT-SMaRt复制协议的容器集群与基于Raft复制协议的容器集群的共识时间；
控制DDoS攻击速率，获取受到不同DDoS攻击速率下调用BFT-SMaRt复制协议的容器集群与调用Raft复制协议的容器集群的共识时间。
在一些实施例中，所述方法还包括：
获取受到不同DDoS攻击的速率下调用BFT-SMaRt复制协议的容器集群与调用Raft复制协议的容器集群的主节点的CPU消耗率、RAM消耗率以及可用带宽，以判断各容器集群主节点的资源消耗情况。
第三方面，本申请还提供了一种电子设备，所述电子设备包括：
一个或多个处理器；
以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
第四方面，本申请还提供了一种存储介质，所述存储介质上存储计算机程序，所述计算机程序使得计算机执行如下操作：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
本申请实现的有益效果为：
本申请提供了一种应用于容器集群的容错方法，所述容器集群内置有Raft复制协议，方法包括在容器集群内部署BFT-SMaRt复制协议；根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议来同步容器集群内个节点的状态机状态以实现所述容器集群的容错。通过配置两种复制协议，并进一步确定在两种复制协议的应用情况，确保以最少的资源消耗保证最佳的容错效果，克服拜占庭错误，保证系统服务的连续性。
进一步地，本申请还提出了一种性能校验方法，包括创建DDoS攻击，模拟拜占庭错误；控制容器集群内的故障数，获取受到低DDoS攻击速率下调用BFT-SMaRt复制协议与调用Raft复制协议的各容器集群主节点的共识时间；控制所述DDoS攻击的速率，获取受到不同所述DDoS攻击的速率下调用BFT-SMaRt复制协议与调用Raft复制协议的各容器集群主节点的共识时间以及CPU消耗率、RAM消耗率和可用带宽。本申请通过创建DDoS攻击模拟拜占庭攻击，并控制在集群内的崩溃故障数以及DDoS攻击的攻击速率，获取不同情况下的基于BFT-SMaRt复制协议和基于Raft复制协议的各容器集群的共识时间以及资源消耗以反映集群的性能变化。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，其中：
图1是本申请实施例提供的容错方法流程图；
图2是本申请实施例提供的容错系统示意图；
图3是本申请实施例提供的主节点为5的共识时间测试结果图；
图4是本申请实施例提供的主节点为7的共识时间测试结果图；
图5是本申请实施例提供的CPU消耗率测试结果图；
图6是本申请实施例提供的RAM消耗率测试结果图；
图7是本申请实施例提供的可用带宽测试结果图
图8是本申请实施例提供的电子设备结构图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
应当理解，在本申请的描述中，除非上下文明确要求，否则整个说明书和权利要求书中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。
还应当理解，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。
需要注意的是，术语“S1”、“S2”等仅用于步骤的描述目的，并非特别指称次序或顺位的意思，亦非用以限定本申请，其仅仅是为了方便描述本申请的方法，而不能理解为指示步骤的先后顺序。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。
如背景技术所述，现有技术中容器集群大多采用Raft复制协议或者Dorado协议来更新状态机，但是这两种协议并不能解决拜占庭错误，导致在存在拜占庭错误的情况下，容器集群工作效果不理想。
为解决上述技术问题，本申请提供了一种应用于容器集群的容错方法，在集群内部署BFT(Byzantine Fault Tolerance，拜占庭容错)-SmaRt(基于拜占庭容错的状态机复制方案的性能改善方案)复制协议；并规定了使用Raft复制协议和BFT-SMaRt复制协议的不同场景，确保以最低的资源消耗达到最佳的集群服务。
实施例一
本申请实施例提供了一种应用于容器集群的容错方法，具体的，如图1所示，容错过程包括：
S1、在容器集群内部署BFT-SMaRt复制协议。
具体的，BFT-SMaRt源代码较大且复杂，因此本申请选择将BFT-SMaRt库包装在Docker容器中。首先，在GitHub等平台获取开源的BFT-SMaRt库及其所有依赖项；然后根据容器集群的主节点的参数对BFT-SMaRt进行定制，使得BFT-SMaR与容器集群参数保持一致；然后创建dockerfile文件(创建镜像所有命令的文本文件)，执行dockerfile文件以生成包含BFT-SMaR复制协议的容器镜像；最后在每个容器集群的主节点中实例化包含BFT-SMaR复制协议的容器镜像及其信息。BFT-SMaRt非常适合现代硬件，例如多核系统；BFT-SMaRt在共识时间方面优于其他协议；当系统中出现拜占庭错误行为时，BFT-SMaRt能够保证复制数据的高精度。BFT-SMaRt是一个模块化、可扩展且强大的库。它能够提供一个适应性强的库来建立可靠的服务。与其他拜占庭协议不同，BFT-SMaRt协议支持副本集的重新配置，例如添加和删除节点。BFT-SMaRt为关键和可持续服务高效透明的支持。
Raft协议是容器集群中内置的复制协议，源代码不到3000行且易于用Golong编程语言进行重写，因此通常应用Golong编程语言重写Raft协议的源代码，将Raft协议配置在容器集群中。
S2、根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议来同步容器集群内各节点的状态机状态。
具体的，若容器集群内不存在拜占庭故障，则选择调用Raft复制协议同步容器集群内各节点的状态机状态；Raft复制协议与BFT-SMaRt复制协议相比，主节点之间的共识消息交换较少，因此在不存在拜占庭故障的情况下，选择Raft复制协议能够降低建立共识所需的时间，加快复制的速度。若容器集群内存在拜占庭故障，若容器集群内的崩溃故障数大于Raft复制协议允许的最大故障数，则调用BFT-SMaRt复制协议来同步容器集群内各节点的状态机状态。若容器集群内的故障数小于Raft复制协议允许的最大故障数且所述拜占庭故障产生速率小于预设阈值，则选择调用Raft复制协议来同步所述容器集群内各节点的状态机状态；由于集群内的崩溃故障数低于Raft协议允许的最大故障数，即使有额外的拜占庭故障，容器集群的运行也不会有显著退化，且在这种情况下，由于Raft复制协议的主节点之间的共识消息交换少，因而调用Raft复制协议的集群实现比调用BFT-SMaRt复制协议的集群的共识时间更短，因而在这种情况下，依旧选择调用Raft复制协议。若所述拜占庭故障产生速率大于预设阈值，则调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态；共识时间会随着拜占庭故障的攻击率的增加而增加，当攻击速率低于预设阈值时，调用Raft复制协议的集群比调用BFT-SMaRt复制协议的集群提高的服务性能略优，因为此时受攻击的节点由于其具备足够的资源而能够抵抗攻击；但是对于拜占庭故障的攻击率高于预设阈值时，由于Raft复制协议在拜占庭故障面前的脆弱性，受到拜占庭攻击的节点不能及时的相应其他节点，因此Raft复制协议触发了集群领导层的变化，因为它不再能够与当前的领导者达成共识，这种触发大大减慢了调用Raft复制协议的集群中的共识，共识时间增加；而调用BFT-SMaRt复制协议的集群能干抵抗所有的拜占庭攻击，其达成共识的速度平均是调用Raft复制协议的集群1000倍，故此时选择在容器集群内选择调用BFT-SMaRt复制协议同步各节点的状态机状态进行容错，以保证集群提供的服务的一致性。其中，上述预设阈值设定为4.25-4.5Gbps区间的任一值。
实施例二
对应上述实施例，本申请提供了一种应用于容器集群的容错系统，如图2所示，所述系统包括：
准备模块210，用于在容器集群内部署BFT-SMaRt复制协议；
处理模块220，根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
在一些实施例中，若所述容器集群内不存在拜占庭故障，则所述处理模块220还用于调用Raft复制协议同步所述容器集群内各节点的状态机状态；若所述容器集群内存在拜占庭故障，则所述处理模块220还用于根据所述容器集群内的崩溃故障数来调用合适的复制协议同步所述容器集群内各节点的状态机状态。
在一些实施例中，若所述容器集群内的崩溃故障数小于Raft复制协议允许的最大故障数，则所述处理模块220还用于根据拜占庭故障产生速率调用合适的复制协议来同步所述容器集群内各节点的状态机状态；若容器集群内的崩溃故障数大于等于Raft复制协议允许的最大故障数，则所述处理模块220还用于调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
在一些实施例中，若拜占庭故障产生速率小于预设阈值，则所述处理模块220还用于调用Raft复制协议来同步所述容器集群内各节点的状态机状态；若拜占庭故障产生速率大于等于预设阈值，则所述处理模块220还用于调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
在一些实施例中，所述准备模块210还用于获取BFT-SMaRt库；根据所述BFT-SMaRt库创建BFT-SMaRt容器镜像；在所述容器集群主节点内实例化所述BFT-SMaRt容器镜像。
在一些实施例中，所述准备模块210还用于获取标准的BFT-SMaRt库；根据所述容器集群主节点的参数修改标准的BFT-SMaRt库的参数。
实施例三
对应上述实施例一和实施例二，本申请实施例还提供了一种基于如上述实施例提供的容错方法的性能校验方法，具体包括：
K1、创建DDoS攻击；
创建用于模拟拜占庭行为的DDoS攻击(Distributed Denial of Service，分布式拒绝服务)攻击，主要采用注入“CPU Load”和“Network Flooding”的DDoS攻击。CPU Load故障是通过增加不断向集群主节点发送请求的用户数来发出的，Network Flooding攻击可以由一些主节点向其他单个主节点连续不断地发送65495字节的请求且不等待其有所响应。
K2、控制容器集群内崩溃故障数并获取在受到低DDoS攻击速率下调用不同复制协议的各容器集群主节点的共识时间。
具体的，基于Raft复制协议的容器集群在崩溃故障数低于所允许的最大故障数时，即使有额外的拜占庭故障，集群的运行也不会显著退化。而由于应用Raft协议的集群相对于应用BFT-SMaRt协议的集群在容器集群主节点之间的共识消息交换得少，故在这种场景下，应用Raft协议的容器集群实现了更短的共识时间。
K3、控制容器集群内DDoS攻击速率，获取不同DDoS攻击速率下各集群的共识时间及资源消耗情况。
具体的，采用主节点为5(n＝5)和主节点为7(n＝7)在相同攻击环境下，进行实际验证，得到图3和图4所示的实验结果(图中KmMC为应用Raft协议的k8s多主常规集群与KmMR为采用了定制化BFT-SMaRt协议的k8s多主鲁棒集群)，共识时间与DDoS攻击速率的关系表现出相同的行为，共识时间随着DDoS攻击率的增加而增加；当攻击速率低于4.25Gbps时，应用Raft协议的容器集群提供的性能略优于应用BFT-SMaRt协议的容器集群。在主节点为5的情况下，由于交换的消息数量较少，共识建立的更快；随着主节点数的增加，应用Raft协议的容器集群更容易受到DDoS攻击。根据图3和图4所示的实验结果，应用Raft协议的容器集群的性能快速下降在n＝5时为DDoS攻击速率为4.25Gbps，在n＝7时为DDoS攻击速率为4.1Gbps；然而，即使对于DDoS高攻击速率，应用BFT-SMaRt协议的容器集群也能够在合理的时间内建立共识。
图5、图6及图7展示了在受到攻击的主节点为7(n＝7)的情况下CPU、RAM和带宽的性能。根据实验结果可知，DDoS攻击速率低于4.5Gbps时，应用BFT-SMaRt协议的容器集群使用的资源与应用Raft协议的容器集群一样多或更多。这是意料之中的，因为使用BFT-SMaRt在集群中建立共识需要大量的消息交换。但是，对于攻击率4.5Gbps以上，应用BFT-SMaRt协议的容器集群和应用Raft协议的容器集群几乎是同一水平的资源利用。因为，对于攻击率4.5Gbps以上，Raft开始在集群中进行更改以恢复其稳定性，从而导致比平时更高的资源消耗。
根据上述校验结果表明，在无拜占庭故障和受控环境中(即不超过最大容许崩溃故障数)，传统的Raft复制协议是有效且稳健的。然而，在存在拜占庭故障且不完全受控的环境中，基于BFT-SMaRt协议的容器集群不仅保证了容器集群服务的连续性，且与应用Raft协议的容器集群相比，应用BFT-SMaRt协议的容器集群的资源消耗通常是稳定的，而应用Raft协议的容器集群则在拜占庭断层前崩溃。
实施例四
对应上述所有实施例，本申请实施例提供一种电子设备，包括：
一个或多个处理器；以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
其中，图8示例性的展示出了电子设备的架构，具体可以包括处理器810，视频显示适配器811，磁盘驱动器812，输入/输出接口813，网络接口814，以及存储器820。上述处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，与存储器820之间可以通过总线830进行通信连接。
其中，处理器810可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。
存储器820可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器820可以存储用于控制电子设备800执行的操作系统821，用于控制电子设备800的低级别操作的基本输入输出系统(BIOS)822。另外，还可以存储网页浏览器823，数据存储管理系统824，以及图标字体处理系统825等等。上述图标字体处理系统825就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器820中，并由处理器810来调用执行。
输入/输出接口813用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
网络接口814用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线830包括一通路，在设备的各个组件(例如处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，与存储器820)之间传输信息。
另外，该电子设备800还可以从虚拟资源对象领取条件信息数据库中获得具体领取条件的信息，以用于进行条件判断，等等。
需要说明的是，尽管上述设备仅示出了处理器810、视频显示适配器811、磁盘驱动器812、输入/输出接口813、网络接口814，存储器820，总线830等，但是在具体实施过程中，该设备还可以包括实现正常执行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。
实施例五
对应上述所有实施例，本申请实施例还提供一种计算机可读存储介质，其特征在于，其存储计算机程序，所述计算机程序使得计算机如下操作：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，云服务端，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种应用于容器集群的容错方法，所述容器集群内置有Raft复制协议，其特征在于，所述方法包括：
在容器集群内部署BFT-SMaRt复制协议；
根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步所述容器集群内各节点的状态机状态，以实现所述容器集群的容错。
2.根据权利要求1所述的方法，其特征在于，所述根据所述容器集群内的崩溃故障数及拜占庭故障产生速率，调用合适的复制协议同步集群内各节点的状态机状态，以实现容器集群的容错，包括：
若所述容器集群内不存在拜占庭故障，则调用Raft复制协议同步所述容器集群内各节点的状态机状态；
若所述容器集群内存在拜占庭故障，则根据所述容器集群内的崩溃故障数来调用合适的复制协议同步所述容器集群内各节点的状态机状态。
3.根据权利要求2所述的方法，其特征在于，所述根据所述容器集群内的崩溃故障数来调用合适的复制协议同步所述容器集群内各节点的状态机状态，包括：
若所述容器集群内的崩溃故障数小于Raft复制协议允许的最大故障数，则根据拜占庭故障产生速率调用合适的复制协议来同步所述容器集群内各节点的状态机状态；
若容器集群内的崩溃故障数大于等于Raft复制协议允许的最大故障数，则调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
4.根据权利要求3所述的方法，其特征在于，所述根据拜占庭故障产生速率来调用合适的复制协议来同步所述容器集群内各节点的状态机状态，包括：
若拜占庭故障产生速率小于预设阈值，则调用Raft复制协议来同步所述容器集群内各节点的状态机状态；
若拜占庭故障产生速率大于等于预设阈值，则调用BFT-SMaRt复制协议来同步所述容器集群内各节点的状态机状态。
5.根据权利要求1所述的方法，其特征在于，所述在容器集群内部署BFT-SMaRt复制协议，包括：
获取BFT-SMaRt库；
根据所述BFT-SMaRt库创建BFT-SMaRt容器镜像；
在所述容器集群主节点内实例化所述BFT-SMaRt容器镜像。
6.根据权利要求5所述的方法，其特征在于，所述获取BFT-SMaRt库包括：
获取标准的BFT-SMaRt库；
根据所述容器集群主节点的参数修改标准的BFT-SMaRt库的参数。
7.一种用于如权利要求1所述的容错方法的性能校验方法，其特征在于，所述方法包括：
创建DDoS攻击，模拟拜占庭错误；
控制容器集群内崩溃故障数，获取存在低DDoS攻击速率下的调用BFT-SMaRt复制协议的容器集群与基于Raft复制协议的容器集群的共识时间；
控制DDoS攻击速率，获取受到不同DDoS攻击速率下调用BFT-SMaRt复制协议的容器集群与调用Raft复制协议的容器集群的共识时间。
8.根据权利要求7所述的方法，其特征在于，所述方法还包括：
获取受到不同DDoS攻击的速率下调用BFT-SMaRt复制协议的容器集群与调用Raft复制协议的容器集群的主节点的CPU消耗率、RAM消耗率以及可用带宽，以判断各容器集群主节点的资源消耗情况。
9.一种电子设备，其特征在于，所述电子设备包括：
一个或多个处理器；
以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行权利要求1-8任一所述方法。
10.一种计算机可读存储介质，其特征在于，其存储计算机程序，所述计算机程序使得计算机执行权利要求1-8中任一所述方法。
CN202210409828.7A 2022-04-19 2022-04-19 容错方法、性能校验方法、电子设备及介质 Active CN114860488B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210409828.7A CN114860488B (zh) 2022-04-19 2022-04-19 容错方法、性能校验方法、电子设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210409828.7A CN114860488B (zh) 2022-04-19 2022-04-19 容错方法、性能校验方法、电子设备及介质

Publications (2)

Publication Number Publication Date
CN114860488A true CN114860488A (zh) 2022-08-05
CN114860488B CN114860488B (zh) 2024-07-05

Family

ID=82631529

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210409828.7A Active CN114860488B (zh) 2022-04-19 2022-04-19 容错方法、性能校验方法、电子设备及介质

Country Status (1)

Country Link
CN (1) CN114860488B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110302449A1 (en) * 2010-06-03 2011-12-08 Microsoft Corporation Collection ordering for replicated state machines
CN110535680A (zh) * 2019-07-12 2019-12-03 中山大学 一种拜占庭容错方法
CN111338857A (zh) * 2020-02-11 2020-06-26 安徽理工大学 一种拜占庭容错共识协议
US20210026843A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Byzantine fault tolerance that supports heterogeneous clients

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110302449A1 (en) * 2010-06-03 2011-12-08 Microsoft Corporation Collection ordering for replicated state machines
CN110535680A (zh) * 2019-07-12 2019-12-03 中山大学 一种拜占庭容错方法
US20210026843A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Byzantine fault tolerance that supports heterogeneous clients
CN111338857A (zh) * 2020-02-11 2020-06-26 安徽理工大学 一种拜占庭容错共识协议

Also Published As

Publication number Publication date
CN114860488B (zh) 2024-07-05

Similar Documents

Publication Publication Date Title
US10356214B2 (en) Composing monolithic applications based on multi-container applications
JP5298763B2 (ja) 仮想システム制御プログラム、方法及び装置
EP1840741A1 (en) Device, method, and computer program product for accessing a non-native application executing in a virtual machine environment
CN104408071A (zh) 一种基于集群管理器的分布式数据库高可用方法及系统
US9143394B2 (en) System and method for graph based K-redundant resiliency for IT cloud
EP3869336A1 (en) Method and apparatus for processing development machine operation task, device and storage medium
JP2014522052A (ja) ハードウェア故障の軽減
US11456914B2 (en) Implementing affinity and anti-affinity with KUBERNETES
CN105357042B (zh) 一种高可用集群系统及其主节点和从节点
CN111147274B (zh) 为集群解决方案创建高度可用的仲裁集的系统和方法
US11271895B1 (en) Implementing advanced networking capabilities using helm charts
CN113204353B (zh) 一种大数据平台组件部署方法及装置
CN111669284A (zh) OpenStack自动化部署方法、电子设备、存储介质及系统
CN113515408A (zh) 一种数据容灾方法、装置、设备及介质
WO2023093127A1 (zh) 一种监控集群的方法、装置及电子设备
CN114679380A (zh) 边缘集群的创建方法和相关装置
CN115454333A (zh) 云计算平台与存储系统的对接方法及装置
CN112000735A (zh) 一种数据处理方法、装置、系统
CN111510480A (zh) 一种请求发送方法、装置以及第一服务器
US8621260B1 (en) Site-level sub-cluster dependencies
US11494184B1 (en) Creation of transportability container files for serverless applications
US9836342B1 (en) Application alerting system and method for a computing infrastructure
CN114760192A (zh) 容器切换方法及节点设备
CN114860488B (zh) 容错方法、性能校验方法、电子设备及介质
CN111355605A (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
GR01 Patent grant
GR01 Patent grant