基于模糊逻辑的云容错负载均衡

云平台中用于自适应容错管理的模糊负载均衡器

摘要

为了在云环境中实现高可靠性、可用性和性能，需要采用一种容错方法来有效处理故障。在大多数现有研究中，主要关注的是基于显式规范的解决方案，这给应用程序开发者带来了较大的工作量，并导致系统缺乏灵活性。我们提出了一种用于容错管理的模糊作业分发器（负载均衡器），以降低用户层面的管理复杂度。该方法旨在通过对可用资源公平分配用户作业请求，从而 reduce系统中 fault occurrences的可能性。在我们的自适应方法中，系统通过根据处理节点（即虚拟机（VM））的可靠性来分发 incoming 作业请求，以应对可能导致故障的异常情况。虚拟机的可靠性是一个随其生命周期动态变化的可变参数。该方法已在 OpenStack 上实现，并进行了对比分析。实验结果表明，与其他负载均衡算法相比，该方法显著减少了故障的发生。

关键词 ：负载均衡 · Job分配器 · Fault容差 · Fuzzy逻辑 · Cloud计算 · Anomaly检测 · OpenStack

1 引言

云计算通过一个抽象化、虚拟化、动态可扩展且可配置的计算资源池，提供大规模分布式计算环境。然而，由于硬件或软件的不可靠性，故障作为影响云计算服务高可用性的主要障碍，是不可避免的。云服务提供商需要提供容错功能，以克服系统故障的影响，并在故障发生后仍能正确地继续运行其功能。目前，已提出了多种容错模型[1,6,8]，这些模型通常要求应用程序开发者根据云平台特有的特性来配置和操作云软件，以确保可靠运行。此类方法的主要缺点和局限性在于需要应用程序开发者需要具备相关知识和经验，才能在现有的容错框架中配置和集成应用程序。这一困难主要源于：（i）云平台的高度复杂性；（ii）用户可获得的底层云基础设施信息较少。这导致云架构缺乏透明度和灵活性，并给应用程序开发者带来过多负担。因此，迫切需要一种可靠且自动的容错管理系统，无需用户进行应用程序的配置和集成。高效的作业分发器（负载均衡器）有助于消除过载等可能导致系统故障的关键状况，并旨在提升系统性能，使系统更加可靠和具备容错能力。此外，作为服务层的一部分，它从用户的角度提升了云基础设施的透明度。近年来，智能方法在云作业分发和负载均衡方面受到了广泛关注。模糊理论[24],作为一种著名的人工智能方法，具有多种特性，使其适用于控制问题[12]。对我们而言，它能够将多个可能相互冲突的选项——无论是来自自动化（机器）学习方法产生的多个选项，还是由不同专家提供的意见——融合为一个可有效执行的单一决策。[3]。

本文提出了一种模糊作业分配技术，通过在系统当前可用资源之间合理分配用户作业请求负载，并结合异常和故障检测，来确保容错性。通过监控系统当前状态和作业分配的公平性，我们计算每个资源的优先级值，并努力避免导致系统故障的过载问题。一旦检测到异常，该算法将指示系统对行为异常的虚拟机应用故障恢复机制。

2 容错：相关工作与定位

容错（FT）是指系统即使在存在内部故障的情况下也能正确执行其功能的能力。容错的目的是提高系统的可靠性。故障恢复机制使系统能够在检测并确认导致故障的故障和异常后，纠正受损状态并恢复到已知安全状态。容错技术可分为三大类 [6]：(i) 冗余技术，(ii) 负载均衡策略，以及 (iii) 容错策略。

冗余

是通过提供系统组件（如硬件和软件）的复制来提高系统的可靠性。硬件冗余技术利用额外硬件组件。所有冗余硬件并行执行相同任务，并可通过多数表决技术 [18] 实现故障检测和屏蔽。

基于负载均衡的容错策略

是通过使用软件模型进行负载均衡来提升容错能力的方法。在这种情况下，负载调度组件将所有传入的作业请求分发到可用资源中。例如，亚马逊EC2 使用弹性负载均衡（ELB）来控制如何处理传入请求。基本上，在此背景下，它试图 reduce通过在可用资源之间合理分配用户作业请求，降低系统中故障发生的可能性。

容错策略可分为主动和被动策略。主动容错的原则是通过预防措施避免从错误和故障中恢复，并主动用其他正常组件替换疑似异常的组件。相比之下，被动容错策略则是在发生故障后进行恢复。

被动容错

以不同的方式实现。首先，检查点定期记录系统状态，允许从最近的检查点重新启动失败的任务，而不是从头开始。张等人[26]提出了一种用户级检查点策略。该方法的主要缺点是成本，在大量虚拟机镜像的情况下，存储空间和恢复过程的开销非常显著。[25]提出了一种基于检查点的异步容错方法，通过在幸存节点上保留数据，以期在没有检查点开销的情况下加速丢失数据的恢复。

其次，复制在不同的资源上运行多个任务副本。在主动模型中，所有副本以相同的顺序接收请求。在被动模型中，一个作为主节点的副本接收请求，所有其他副本与主副本进行交互。为满足平台即服务云中的可靠性需求，文献[16]提出了一种基于拜占庭容错协议（BFT）自动协调容错应用的框架。文献[19]提出了一种基于检查点/重放技术的容错方法，用于实时计算，以减少在云基础设施上的服务时间。另一种反应式方法是作业迁移，即将失败的任务迁移到另一个资源。任务重新提交也被广泛使用：将失败的任务重新提交到同一资源或不同的资源。

主动容错

可以分为两种重要类型：
软件再生 ：在每次再生间隔[10]时立即终止应用程序，并以干净的状态重新启动。
抢占式迁移 ：依赖于反馈环控制机制，即持续监控和分析。它会迁移表现出异常行为且可能即将发生故障的应用程序部分[7,20]。在[17],中提出了一种基于粒子群优化（PSO）的主动协同容错（PCFT）方法，以最小化总体传输开销和网络资源消耗。在[5],中提出了一种基于自适应选择容错策略的虚拟机部署模型，用于云应用。在[14]中提出了一种用于计算系统中故障管理的预测控制方法。在当前大多数云平台中，(i) 检查点技术，即在无故障执行期间定期记录和捕获系统恢复状态的过程，以及(ii) 复制，即复制任务的过程，是最常见的容错策略。复制策略的缺点是成本较高，即包含多个副本的设备需要更高的开销。检查点技术的优点是不需要大量的硬件冗余。然而，检查点策略的主要缺点是执行检查点所需的时间开销。

所提出方法的定位。通常，由于使用容错策略而导致的时间开销可能会对资源性能产生负面影响。在本研究中，为了减少时间开销并在系统生命周期内提高资源利用率，我们将负载均衡作为中央控制器功能，采用主动容错策略[11,13]并提出一种用于容错管理的模糊负载均衡器。

所提出的框架考虑了多个目标：（i）资源CPU利用率，（ii）作业请求分配的公平性，以及（iii）每个资源的故障率历史。我们的解决方案结合了软件再生等主动技术与抢占式迁移。

3 容错管理系统

在云基础设施中设计容错机制即服务的第一步是定义系统的工作方式。

3.1 自适应异常与故障管理框架

通常，客户端作业部署在虚拟机实例中。系统的容错特性应通过一个核心服务来实现，该服务以透明方式应用一致的容错机制。为此，我们定义了一个容错控制器作为基础模块，用于监控当前系统状态并执行容错机制。这使得我们能够在虚拟化层控制和处理用户应用程序的硬件故障，而非在应用程序本身中进行。所提出的容错方法被编码并运行于该控制器内部。此外，我们的解决方案还使用了另外两个模块，即作业分发器和异常/故障检测器组件。作业分发器负责根据当前请求负载、每个资源的优先级和权重值，将客户端作业请求分配到资源池中的一组计算资源上。异常/故障检测器负责监控资源，以检测可能导致故障和服务器崩溃的异常。当该模块检测到故障后，可应用恢复机制。在此背景下，节点故障的检测和恢复机制的应用均无需对用户应用程序进行任何修改即可集成容错方法。

容错控制器从Ceilometer和资源池中计算节点的当前状态收集信息。Ceilometer组件提供遥测服务，用于在OpenStack中收集计量数据（我们使用该服务进行实现[2]）。然后，容错控制器决定如何修改资源池中每个节点的优先级和权重值，以减少未来的异常行为。作业分发器根据每个资源的权重值分发提交的作业。在系统生命周期中，故障检测器模块检测系统中的异常和故障发生，并向故障节点发送恢复机制信号。请注意，图1中每个模块都有其自身的一套功能属性。

我们的异常检测框架旨在主动预防或检测故障：（i）检测可能导致故障的异常不良性能下降（作为一种具体异常）；（ii）识别异常性能下降的症状和根本原因，以采取适当的纠正措施，此处采用模糊任务分配；（iii）管理症状 （异常行为的外部表现）与根本原因（导致性能下降的原因）之间的关系和依赖性；（iv）通过对已识别故障应用恢复机制，并从验证结果中学习，以改进未来的故障检测，并通过权重和优先级调整持续优化部署和集成过程。以下步骤遵循MAPE-K控制循环框架[12],执行（见图1）：

– M监控 ：异常/故障检测。此步骤使用 Ceilometer 从控制器收集数据，对这些数据进行结构化处理，以提供可用于检测数据中混淆行为的序列表示。

– Analysis ：异常识别与诊断。为了能够识别并诊断故障根本原因，我们在异常检测步骤中标记序列表示。该步骤的主要要点是明确故障之间的依赖关系和关联关系，估计故障类型（故障强度等级或异常在受管资源内的分散程度），并区分故障（真实异常诊断）与噪声（虚假异常诊断）。这种区分基于为每一项分配数值来确定。

– P规划与E执行 ：异常恢复。在识别和诊断故障后，应用恢复机制来纠正故障并消除其影响。故障消除的目的是将受影响组件从序列呈现中隔离，并将传入请求委派给另一个组件，或选择替代方案用于修复。此步骤与容错控制器虚拟机相连，以重新分配受影响组件的新权重，从而能够根据其新权重存储已验证路径。

此外，恢复验证会评估之前步骤在检测故障方面的有效性，其中可以考虑不同类型的故障（如与CPU相关的故障、与内存相关的故障、与磁盘相关的故障和与虚拟机相关的故障）。通过测量延迟、吞吐量和响应时间，来推断故障隔离后被测组件的性能。验证结果将被推送回云中（资源池）。

为了从资源池中的计算节点收集状态信息，我们在检测过程中使用三个不同的时间窗口。Δt1指定 Ceilometer 组件对资源的指定计量器执行更新的时间间隔。 Δt2是容错控制器机器使用的采样间隔，而Δt3用于向故障检测器组件发送周期性更新。通常，时间间隔 Δt2和 Δt3与Ceilometer间隔参数成正比，即 Δt1，如图2所示。例如，如果 Δt1= 10 s，则 Δt2和 Δt3的值可以分别为 10 分钟和 1 小时。

3.2 OpenStack

对用户而言，一个重要的特性是服务正常运行时间。为了实现高云可用性并提高服务等级目标（SLO）的满足度，需要采用高效的容错策略。与传统的手动配置方法相比，我们提出了一种利用active和runtime监控来实现容错的方法。该方法由多个相互独立的模块组成，这些模块分别工作，以处理传入的作业请求负载并在目标系统中执行容错。

为了实现容错控制器并展示其在 开放IaaS解决方案中的特性，我们选择了开源OpenStack IaaS平台。它包含通过数据中心控制处理、存储和网络资源硬件池的组件。用户可以通过基于Web的仪表板、命令行工具或 RESTful API进行管理。图3展示了 OpenStack核心服务。(1) Neutron 是一个用于管理 (2) Nova 是用于部署和管理虚拟机的计算引擎；(3) Glance 支持磁盘和服务器镜像的发现、注册和交付；(4) Ceilometer 提供遥测服务以收集计量数据； (5) Keystone 提供用户/服务/端点的认证和授权；(6) Heat 是用于编排云应用运行所需基础设施的服务。

3.3 作业分配策略

单个计算资源在缺乏足够任务调度器的情况下，很容易出现重载或欠载。然而，在虚拟机层面上导致进程失败的主要原因是过载。作业分发器策略可分为两大类：（i）静态方法将负载平均分配给所有可用资源。它们不考虑系统的当前状态，可能导致系统负载过重或欠载。（ii）动态方法通过监控系统的当前状态来管理负载，旨在实现更高效的负载分配。作业分发器的主要目标是通过高效利用资源来提升系统性能。最常见的作业分发器/控制器策略包括：

– 轮询（RR） ：在此策略中，顾名思义，作业以轮询方式分配给所有服务器。RR不考虑分配给资源的作业数量、CPU利用率等因素。相反，它将所有资源视为相等，并将流量平均分配。这是实现起来最简单的策略。

– 加权轮询（WRR） ：它是 RR策略的扩展，其中资源根据其给定的权重值接收作业。每个资源都可以被分配一个权重。与权重较低的资源相比，权重较高的资源会优先接收新的作业请求，并且获得更多的作业。

– 动态加权轮询（DWRR） ：由于 RR和 WRR是静态的作业分配策略，必须预先了解后续的作业请求，在某些情况下，即使存在空闲资源，已经过载的资源仍会持续接收更多作业请求。通过考虑每个资源的实时信息和指标（如当前 CPU利用率），DWRR采用动态权重分配来避免过载，并提高整个系统的吞吐量。DWRR策略会定期为资源重新分配新的权重值。

3.4 模糊逻辑

模糊逻辑 [24]是一种利用语言描述来刻画复杂系统的有效技术。语言变量是指其值为自然语言中词语的变量。例如，“负载” 是一个语言变量，其值可以是 “重”、“中等”、“轻” 等。模糊逻辑系统（FLS）的架构由多个组件组成，如图4所示：

模糊化模块将系统的输入（即精确数值）转换为模糊集合。规则（知识库）模块存储由专家提供的或其他来源学习到的 如果‐那么规则。推理引擎通过对输入和 如果‐那么规则进行模糊推理，模拟人类的推理过程。

规则；Def uzzification 模块将推理引擎获得的模糊集转换为精确值。隶属函数（MF）是一条曲线，用于定义输入空间中的每个点如何被映射到 0到1之间的隶属度（或隶属程度）。在模糊逻辑系统中，隶属函数被用于模糊化模块和去模糊化模块，以将非模糊的输入值映射为模糊语言术语，反之亦然。例如，图5(a) 显示了一条从未加载 系统到高度加载系统的平滑变化曲线。该曲线被称为隶属度函数（μ）。两个系统在某种程度上都处于繁忙状态，但其中一个明显比另一个更不繁忙。模糊逻辑的一个重要特征是，一个值可以同时属于多个集合。隶属度函数有不同的形式。例如，根据图5(b)，CPU利用率值可同时被视为“正常”和“繁忙”，但具有不同的隶属度。最常见的隶属度函数类型为三角形、梯形和高斯形状。

在模糊逻辑系统中，构建规则库以控制输出变量。模糊规则是语言型的 如果‐那么结构，其一般形式为“如果A则B”，其中A和B是包含语言变量的命题。例如，如果负载较高且目标为中等，则指令为减少。

3.5 模糊容错管理

模糊控制基于可用的启发式知识，为动态过程设计控制器提供了一种解决方案。图1前面展示了我们的容错框架的整体概述。来自资源池的结果是每个可用资源的当前权重值和优先级值。此外，从Ceilometer收集两个预定义区间之间 CPU利用率的任何变化。容错控制器的输出是修改后的权重值，该值决定在下一个区间内分配给资源的任务请求应增加还是减少。

根据当前状态，模糊控制器计算两个区间之间权重值的变化，并将该变化作为自适应权重值发送给作业分发模块，以供资源在下一个区间使用。基于上一个区间内CPU利用率的变化以及加载到资源的作业请求，模糊容错控制器确定新的 val用于下一个区间内每个可用资源的权重和优先级的值 .

如前所述，模糊控制器中的模糊化模块和去模糊化模块（图4）在内部使用语言变量和值进行工作。输入的数值由模糊化模块测量并转换为相应的语言变量值，而去模糊化模块则执行相反的操作。根据语言输入值，接口模块选择要应用的适当规则，并生成语言输出值。模糊化模块和去模糊化模块均使用隶属函数将数值转换为语言值，反之亦然。隶属函数将每个数值映射到介于0和1之间的隶属度（确定性水平）（0表示完全不确定，1表示完全确定）。图6表示我们的隶属函数，其中x轴代表CPU利用率值，y轴代表隶属度。根据可能的CPU利用率水平（该指标表示处理器核心的繁忙程度），本文中表示资源利用率水平的语言变量被划分为四个等级：空闲、正常、繁忙 和非常繁忙。为了确定每个语言变量的边界值，我们从多位云应用管理领域的专家处收集了所需数据，并对每个变量取所有回复的平均值。

我们的模糊容错控制器采用以下异常识别规则，这些规则有助于识别可能的故障，并作为响应进行作业分配和权重/优先级调整：

– 当某个资源的CPU利用率在预定义时间段内超过给定阈值时，该资源被定义为过载。在这种情况下，模糊控制器根据该资源当前的CPU使用水平，确定其负载权重和优先级参数的适当值。通过调整权重值，作业分发器将减少发送到此资源的作业请求，直到其CPU使用率进入安全模式。– 当资源的CPU使用率在给定时间窗口内变为较低值时，即发生欠载情况，这意味着该资源需要执行的作业数量较少且大部分时间处于空闲模式。此时，模糊控制器会修改并提高空闲资源的权重和优先级值，使其从作业分发器接收更多的作业请求，从而降低其他节点上可能发生故障的风险。

异常管理通过以下两种方式发生。首先，过载是一种异常，被视为可能发生故障的征兆，即性能退化是导致故障的根本原因，而欠载是一种异常，表明可以通过将负载分配给当前节点来减少其他地方可能发生的故障。其次，异常框架的另一个假设是，不正确的权重和优先级会对故障发生产生负面影响。每个资源的输入作业负载由其权重和优先级值决定。因此，为了实现对用户作业请求的公平分配并避免过载/低载情况，我们的模糊控制器有责任根据加载到资源的作业请求、故障率历史以及目标资源的CPU利用率变化来调整这些参数。通过这种方式，应用了主动抢占式迁移容错策略。

4 实现

我们在OpenStack中实现了一个所提出的基于模糊逻辑的容错控制器原型。该模糊容错控制器基于一个基于模糊逻辑的反馈控制环，它持续监控资源利用率 （使用Ceilometer），并在每个间隔检查周期触发控制器。

根据每种可用资源的利用率值，模糊控制器模块在异常情况下识别适当的负载权重值。在我们的实现中，我们假设一个或多个虚拟机实例作为资源池的成员。我们使用一种最小化的Linux发行版，即专为在OpenStack等云平台上用作测试镜像而设计的cirros镜像。每个实例（VM）接收一个作业请求并执行该请求。在实验中，我们将不同用户提交的所有作业请求均视为CPU密集型。为了通过模糊逻辑控制器控制和管理可用资源的权重值，我们增加了一个额外的VM资源，该资源充当容错控制器，并定期决定和重新分配权重值。对于容错控制器，由于无法在cirros镜像中安装任何附加软件包，我们选用了一台运行基于 Linux Ubuntu的镜像的虚拟机。图7展示了在OpenStack中实现的系统。所创建的作业分发器将用户作业请求分发到一组资源，即资源池上。作业分发器控制器虚拟机中用于评估的策略（对我们提出的模糊控制器与另外两种传统方法的比较）总结于表1中。

图7显示了所提出的模糊容错方法的完整过程。首先，容错控制器从作业分发器、Ceilometer 和资源池中成员的当前状态（可用资源）收集信息，然后根据情况确定资源的适当负载权重值，以调整异常情况。例如，如果某个资源过载，控制器会判定进入该资源的作业负载应减少，因此它会为该资源重新分配一个新的权重值，以减少提交的作业请求。所提出的模糊逻辑控制器在容错控制器机器内部编码并运行。

对于所提出算法中的一些参数，例如当前虚拟机实例数量或工作负载，我们需要调用OpenStack API。例如，命令nova list可显示正在运行的实例列表。该API是一个RESTful接口，允许我们向服务管理器发送URL请求以执行命令。由于无法直接在容错控制器机器内部访问OpenStack API，我们使用了流行的命令行工具cURL与多个OpenStack API进行交互。cURL使我们能够从命令行或shell脚本发送和接收HTTP请求与响应，从而可以直接使用OpenStack API。在图8中，展示了使用cURL调用OpenStack API的过程。首先，我们通过向OpenStack身份服务传递凭据（用户名和密码）来请求认证令牌。在从 Keystone接收到认证令牌后，用户可将该认证令牌与计算服务API端点结合，发送HTTP请求并接收输出结果。我们在容错控制器机器内部执行 OpenStack API，并收集所需的输出。通过结合这些设置，我们能够将模糊逻辑方法作为OpenStack中容错管理的控制器来运行。

云平台中用于自适应容错管理的模糊负载均衡器

5 实验对比

评估旨在展示我们的模糊逻辑控制器在容错管理方面相较于其他作业分配策略的有效性。

5.1 实验设置与基准测试

在我们的实验中，所提出的模糊逻辑方法被实现为完整的可运行系统，并在 OpenStack平台上进行了测试。实验中考虑的可用资源数量设置为4个虚拟机。术语“作业负载”指的是用户请求到达。作业负载定义为用户提交需要由作业分发器处理的作业请求序列。为了评估我们提出的方法，我们考虑了多种不同的负载情况。在每种负载场景中，都有一组由各个用户提交的作业请求。每个用户提交的作业请求都被视为CPU密集型作业。在每种负载场景下，作业执行的持续时间由Poisson Distribution设定。我们执行了多个负载场景，整个实验的总持续时间为2周。

为了评估所提出的方法并在目标系统中生成/管理故障，我们使用了一个故障检测虚拟机（如图1所示）作为单一系统故障模型。通过从Ceilometer收集有关每个可用虚拟机当前状态的信息，故障检测器能够检测资源是否进入异常状态（过载/欠载）。根据定义的时间窗口内资源的当前CPU利用率，故障检测模块可检测目标资源是否在一段时间内处于过载状态，并向该目标资源发送恢复信号。为简化此处的故障恢复过程，我们将硬件再生视为恢复的容错策略。

此外，我们将所提出的模糊容错方法与另外两种算法进行了比较，即 Equal-W和 cpuutil-W，如表1所示。在 Equal-W方法中，每个可用资源以循环方式接收作业请求，而不考虑资源指标（如CPU利用率和容错），即所有资源具有相同的权重值（W）。相比之下，cpuutil-W方法通过监控资源CPU利用率来调整权重值动态分配权重值，并根据权重值按比例分发作业请求。还有其他关于负载均衡策略的研究[4,15,23],旨在改进资源响应时间等目标，在监控设置方面类似，但在容错的分析和执行策略配置上有所不同。

技术	策略	权重值 ∀ ri, rj ∈ RP | W(rj)=	权重值 ∀ ri, rj ∈ RP | W(rj)=	权重值 ∀ ri, rj ∈ RP | W(rj)=
等权重作业分配器 (Equal-W)	资源接收作业请求以循环方式而不考虑资源指标，如CPU利用率和容错 , i.e.,所有资源具有相同的权重值 (W)	W(ri) ∀ rj ∈ RP | W	W(ri) ∀ rj ∈ RP | W	(rj) =
最低CPU利用率加权作业分配器 (cpuutil-W)	资源的权重基于其CPU利用率，并且作业请求按权重比例进行分发	与权重成比例值。较高的值将分配给CPU利用率较低的资源	100 − cpuutil(rj,Δt2) ∀ rj ∈ RP | W(rj) =	til(rj,Δt2) W(rj) =
模糊加权作业分配器 (Fuzzy-W)	资源权重值是由模糊容错控制器根据当前CPU利用率和历史权重值得出的资源的值	Fuzzy(rj,Δt2)	Fuzzy(rj,Δt2)	Fuzzy(rj,Δt2)

a 资源池包含可用资源。b 资源 rj 在之前时间窗口 Δt2 内的平均 CPU利用率。c 基于之前时间窗口 Δt2 内 CPU利用率的资源 rj 的权重值。

5.2 对比指标

我们测量了每种执行场景下整个时间段内云环境的性能。用于比较的指标包括：

– CPU利用率 ：作为跨云资源管理中考虑的关键指标，它是时间的函数，表示在特定时间段内CPU忙于处理工作的时长比例，以百分比形式报告。如果 CPU利用率在持续时间段内超过高阈值（例如80%），则会出现CPU异常。

– 故障率 ：表示每种场景下实验期间经历的总故障次数。它被广泛用于表示目标系统的稳定性和可靠性。

5.3 结果与讨论

图9显示了在实验中通过比较各算法在每个可用资源上获得的CPU利用率指标 （cpu util）的分布情况。对于所有虚拟机，我们的方法（Fuzzy-W）获得了更优的分布范围， cpuutil-W始终排名第二， Equal-W排名最后。更宽的 CPU使用率分布范围表明作业请求负载在所有可用资源之间实现了更公平的分配。公平性基于每个资源的CPU利用率定义，旨在避免长时间的CPU过载。在此背景下，公平性代表了云服务提供的服务质量，并试图避免因主机过载而导致的服务等级协议（Service Level agreement）违规。通过为负载作业请求分配使用动态权重和优先级值， Fuzzy-W和 cpuutil-W算法均试图克服导致系统故障的过载异常情况。

)

在图11(a)、(b)和(c)中，柱状图表示所比较的算法在所有可用资源中的 CPU利用率的百分比频率，即分别为Equal-W、 cpuutil-W和 Fuzzy-W。

5.4 有效性比较

图10显示了在多种工作负载场景下，实验过程中各个资源因故障导致的重发起生次数的分布情况。如前所述，与 Equal-W相比， Fuzzy-W和 cpuutil-W方法具有更好的CPU使用率分布（见图11）。然而，由于 Fuzzy-W中CPU利用率分布更高，在故障检测器的每个时间间隔内，其CPU利用率的平均值较低，并且显示出重启发生次数显著减少。

6 结论

我们提出了一种新的基于模糊逻辑的负载均衡器，用于IaaS云平台中的容错。该方法采用模糊逻辑策略，在异常情况下作为主动策略，为每个可用资源分配权重和优先级值。通过监控系统的当前状态，该方法试图调整每个资源的权重值，以实现以下目标：（i）公平的任务分配；（ii）避免导致系统故障的过载等异常情况；（iii）提高整个系统的吞吐量。系统的过载可能导致性能下降，从而增加故障率和服务等级协议违规。同时，欠载也被处理，以减少其他位置的异常。

所提出的方案中，用于选择适当权重值的分配机制基于模糊逻辑系统 (FLS)和作为输入的收集的计量数据。通过考虑每个资源的实时信息和收集的指标，实现了更高效的负载分配，并减少了系统中故障的发生。该方案在开源 IaaS平台OpenStack中进行了编码和实现，以验证其实际有效性，并基于重要指标进行评估，包括实验过程中各个资源的CPU利用率分布和故障率。实验结果表明使用模糊方法，所提出的方法在考虑上述所有指标时均优于其他策略，尤其是在故障率参数方面，这是本文的主要目标。

我们计划将该解决方案应用于基于容器的虚拟化 [9,21]以构建边缘‐云管理平台 [22]在未来。