Toward a Smart Cloud: A Review of Fault-Tolerance Methods in Cloud Systems

Abstract

本文介绍了云计算中提出的容错方法的最新研究进展。本文将容错方法分为三类：1）反应式方法（RAMs）；2）预防性方法（PRMs）；和3）弹性方法（RSMs）。RAMs允许系统进入故障状态，然后尝试恢复系统。PRMs倾向于通过实施机制来避免错误影响系统，从而防止系统进入故障状态。另一方面，最近出现的RSMs旨在最小化系统从故障中恢复所需的时间。本文还探讨了机器学习和人工智能在RSM领域中如何发挥作用以最小化恢复时间。

Introduction

首先，介绍了云计算的概念和特点，指出云计算作为一种新型的计算模式，具有高度的可扩展性、灵活性和可靠性等优势。然而，由于云计算系统规模庞大、复杂度高，因此故障率也相应增加。因此，在云计算中实现容错是至关重要的。

接着，本文介绍了目前在云计算领域中已经提出的容错方法，并指出这些方法存在一些局限性和不足之处。

常见的容错方法被分类为三类：反应式方法（RAMs）、预防性方法（PRMs）和弹性方法（RSMs）。其中，反应式方法指的是系统在发生故障后才进行恢复；预防性方法则是通过实施机制来避免错误影响系统，从而防止系统进入故障状态；弹性方法旨在最小化系统从故障中恢复所需的时间。具体而言，反应式方法（RAMs）允许系统进入故障状态，然后尝试恢复系统；预防性方法（PRMs）倾向于通过实施机制来避免错误影响系统，从而防止系统进入故障状态；最近出现的弹性方法（RSMs）旨在最小化系统从故障中恢复所需的时间。它们常用的技术如下：

反应式方法（RAMs）：基于传统的分布式系统容错技术，如复制、检查点/重启、检测和恢复等。
预防性方法（PRMs）：主要采用监控、预测和抢占等技术。在正常操作下，PRMs不断监视系统状态，并在可能发生系统故障时立即调用避免故障的步骤。
弹性方法（RSMs）：主要采用快速恢复和自愈能力等技术。RSMs旨在最小化系统从故障中恢复所需的时间，以便尽快将系统恢复到正常状态。

而传统的反应式方法（RAMs）只能在系统发生故障后才能进行恢复，而预防性方法（PRMs）则需要消耗大量资源来避免错误发生。因此，需要进一步研究新型的容错方法来解决这些问题。

在Introduction中，作者详细描述了PRMs和RSMs之间的区别。具体而言，作者指出PRMs主要实现故障预测和避免方法，但没有学习和适应方法；而RSMs则通过不断更新模型和学习结构来适应云系统的动态变化，并根据自身计算环境特征自适应地学习和减轻PRMs的影响。因此，虽然PRMs实现了故障预测，但没有学习和适应方法；而RSMs则通过自适应地学习计算环境特征来减轻PRMs的影响，并在系统发生故障时快速恢复。

最后，本文介绍了本文所采用的研究框架，并概述了本文各个章节所涉及到的内容。

Cloud Fault Tolerance Model

故障可以是系统中发生的影响系统正常运行的任何事件。通常，故障是系统正常运行的根本损害，它们会导致错误。错误反过来会导致系统故障。容错性是衡量系统在出现故障时继续为其客户请求提供服务的能力。本文定义了四种系统错误，分别是瞬态故障（Transient Faults），间歇性故障（Intermittent Faults），永久性故障（Permanent Faults），拜占庭式故障（Byzantine Faults）：

瞬态故障（Transient Faults）：指系统中的某个组件或部件在短时间内发生故障，但之后又能够自行恢复正常工作。这种故障通常是由于电压波动、电磁干扰等原因引起的。
间歇性故障（Intermittent Faults）：指系统中的某个组件或部件在不同时间点上出现故障，但每次故障持续时间很短，并且在下一次出现之前可能会有很长一段时间没有任何问题。这种故障通常是由于松动连接、温度变化等原因引起的。
永久性故障（Permanent Faults）：指系统中的某个组件或部件发生了无法自行恢复的故障，需要进行更换或修理才能恢复正常工作。这种故障通常是由于硬件损坏、软件错误等原因引起的。
拜占庭式故障（Byzantine Faults）：指系统中的某个组件或部件出现了任意形式的错误，包括发送错误信息、篡改数据等。这种错误通常是由于恶意攻击、软件漏洞等原因引起的。

Fault Tolerance Challenges in cloud systems

云计算的特点使得云系统容错面临着以下挑战：

Heterogeneity and the lack of standards（异质性和缺乏标准）：不同硬件和操作系统供应商基于自己的架构部署云，因此可能在同一个大型云系统中部署在异构平台上的组件。这给容错解决方案的设计带来了压力，因为它们必须考虑整个容错解决方案中每个操作系统供应商的方面。因此，在设计容错解决方案时需要考虑到这些异构性和缺乏标准的挑战。
Need for automation（需要自动化）：未来是智能的，并需要自动化。随着托管云系统的虚拟机数量呈指数级增长，人类管理这些系统将变得几乎不可能。因此，需要考虑自动化来管理这些系统的容错解决方案。然而，自动化面临着缺乏通用框架（API）的挑战，这些框架可以应用于任何云系统以实现容错解决方案，并且需要进行很少的努力（即需要插入式容错）。因此，在未来的容错解决方案中，自动化将成为主要趋势。
Downtime in the clouds（云中的停机时间）：云架构由多个地理位置分布和由不同供应商管理的数据中心组成。一个数据中心的完全停机可能会影响许多组织。每个组织对云的服务级别协议（SLA）不同，容错提供商必须确保满足所有组织的SLA。因此，在设计容错解决方案时需要考虑到这些挑战。
Consideration for RPO and RTO（对 RPO 和 RTO 的考虑）：容错解决方案的目标是将恢复点目标（RPO）和恢复时间目标（RTO）都降到最低。其中，RPO是服务器故障时可能丢失的数据量，而RTO是系统在故障后重新运行所需的时间。通过使用弹性方法来不断最小化RPO和RTO，可以设计出容错解决方案。弹性方法的学习功能可以被定义为最小化RPO和RTO。因此，在设计容错解决方案时需要考虑到这些目标。
Workloads in the cloud(云计算中的工作负载):云计算中有两种工作负载类型，即云原生和云启用工作负载。云原生应用是完全使用云模型构建的应用程序，由多个服务组成，每个服务都具有弹性、韧性，并可用于组合其他应用程序。而云原生工作负载是由纯云原生应用程序生成的计算工作负载。在某些情况下，不可能将应用程序的所有组件迁移到云上，这导致应用程序的某些组件在企业内部托管，而另一些组件在云上托管。这通常被称为“云启用”。因此，在设计容错解决方案时需要考虑到这些工作负载类型的差异。在这种情况下，主动和弹性方法都应该适用于处理云原生和云活动模型的容错要求。

Fault tolerance and reliability in the clouds

虚拟化技术用于提供计算资源，然后这些资源属于许多云用户。这种资源虚拟化导致了复杂的基础架构设计，这些设计将硬件暴露在它们最初并非设计用于并导致故障的条件下。故障可能发生在硬件、系统（主机或 VM）、软件或操作员级别。云系统中的故障可能导致系统发生灾难性中断，从而影响云系统的可靠性。

云系统的可靠性是衡量云系统在预定条件下向用户提供服务的好坏程度。此类条件通常定义为 QoS，它构成云服务提供商与客户（或用户）之间合同的一部分。云系统的可靠性最终取决于承载服务的虚拟机的容错能力。一般来说，云系统中用于容错的技术涉及检查点 [4]、冗余 [3]、[7] 和网络带宽 [9]、[10] 的优化。检查点可以发生在进程级别或 VM 级别。进程或 VM 状态在执行期间不断被保存。在进程失败的情况下，执行将从检查点开始恢复，而不是从头开始。如果 VM 发生故障，VM 映像将恢复到另一台机器，并且进程从发生故障的 VM 的检查点继续。

大多数关于云系统可靠性的研究都集中在优化检查点算法和虚拟机冗余上。刘等人。 [3] 和周等人。 [4] 描述了一种冗余 VM 方法，该方法在选择一组 VM 托管服务器时考虑了网络拓扑结构，目的是最大限度地减少网络资源消耗。周等。 [5] 提出了一种减少虚拟机检查点期间使用的存储的解决方案。最后，周等人。 [5] 对增强云可靠性的研究进行了研究。在大多数情况下，云服务的采用涉及将托管在组织数据中心的现有系统迁移到云环境。由于低维护成本、高可扩展性和按使用付费模式等特性，组织被云托管的价值主张所吸引。除了节省托管成本外，此类迁移还应提高系统的整体可靠性。将一些成熟的企业系统迁移到云端并不是一个容易的决定。尽管将系统迁移到云端有明显的好处，但组织仍然必须根据为此类决策提供信息所需的科学方法做出务实的决策。此外，还需要考虑重要的考虑因素，例如系统安全性（由组织的安全策略管理）。一些系统组件最好在本地私有环境中运行。因此，需要一些指南来帮助实施最佳的云迁移结构。
邱等。 [11] 介绍了一个基于可靠性的框架（ROCloud），在考虑系统上的云迁移时，它可以用作决策制定的一部分。 ROCloud 由两种算法（ROCloud1 和 ROCloud2）组成，用于根据应用程序的结构和历史可靠性信息对其进行排名。 ROCloud1 和 ROCloud2 分别用于对普通应用程序和混合应用程序进行排名。排名结果用于自动选择要使用的最佳容错策略。该框架使用四种常见的容错策略，即 Recovery Block、N-Version Programming、Parallel 和 VM Restart。每个策略根据三个参数对每个系统组件进行排名：响应时间、资源成本和故障率。进行了实验，结果表明，仅通过过滤一些容易出错的组件并将它们移动到云中，就有了显着的改进。

Taxonomy of fault tolerance methods

在这部分中，论文详细描述了对容错方法的三个分类，即ReActive Methods (RAMs)、PRoactive Methods (PRMs)和ReSilient Methods (RSMs)。其中，每个分类用到的关键技术如下：

RAMs（反应性方法）：重点主要是系统恢复。系统的状态在恢复过程中不断保存和使用。使用的关键技术是复制、检查点和重新启动。
PRMs（主动方法）：主要关注防止系统完全中断。这些方法通过持续监控系统和进行故障预测来工作，以便在故障发生之前很好地预防故障的影响。使用的关键技术是云资源的监控、预测和重新分配。
RSMs（弹性方法）：这些方法与主动方法具有许多共同特征。 RSM 通过预测故障和实施方法来运行以避免或最小化此类故障对系统的影响。除了监控和预测之外，弹性方法还通过与托管环境交互并结合智能学习来调整（微调）系统容错能力。这是 RSM 与 PRM 显着不同的地方。

Reactive Meghods

反应性方法用于减轻故障发生后的影响。根据当前文献，用于反应式容错的关键技术包括检查点/重启、复制、SGuard、重试、自定义异常处理、任务重新提交和救援工作流。本节回顾了有关 RAM 的选定论文。

Checkpointing/Restarting

检查点/重新启动技术通过不断保存系统状态来工作，如果发生故障，作业将从最近的状态开始。这些技术适用于长时间运行的作业。以下段落将总结一些关于基于检查点的算法的论文，即[26]、[27]、[28]、[29]、[30]、[31]、[32]、[33]、[34] ]、[35]、[36]、[37]。这些论文的选择基于他们如何将检查点纳入他们的解决方案的变化。

冈村等。 [27] 提出了一种基于强化学习的动态检查点方案。这种技术在系统故障分布未知的情况下会变得很有用。首先，检查点问题被建模为半马尔可夫决策过程。其次，应用具有代表性的强化学习算法（称为 Q-learning 算法）。 Q-learning 允许构建自适应检查点方案。该算法由通过学习和交互体验适应环境的智能体组成。

穆迪等。 [29] 描述了一种新颖的多级检查点系统。这种方法旨在降低不断增长的高性能计算 (HPC) 系统的检查点成本。系统定义了一套 L checkpointing 机制。每个级别代表一个具有不同成本和弹性级别的检查点机制，最终映射到所使用的存储类型，例如本地内存、USB、远程内存、使用软件 RAID、本地 SSD 或远程文件系统。第一个级别 1 是成本最低的级别，最后一个级别 L 是成本最高的级别。较低级别采用轻量级检查点，这些检查点具有较低的开销成本，因此非常适合处理最常见的故障模式。类似地，较高级别具有昂贵的检查点成本，并且用于不太频繁的故障模式。 Scalable Checkpoint/Restart (SCR) 库用于实现系统，它可以将检查点保存到计算节点上的 RAM、Flash 或磁盘。该系统使用概率马尔可夫模型进一步建模，该模型可用于预测当前和未来系统的性能。总体结果表明，当前和未来系统的并行文件系统负载减少了两次。迪等人。 [30] 通过开发一种进一步优化级别选择的方法，进一步优化了多级检查点。此外，Di 等人。 [33] 通过优化核数不确定的系统的检查点间隔来改进多级检查点。

奥林纳等。 [32] 引入了协作检查点技术，这是一种健壮的检查点算法，由一组规则和策略组成，使检查点决策能够由应用程序、编译器和操作系统（看门人）共同做出。在这种方法中，开发人员在代码中的最佳位置插入检查点请求，编译器进一步优化这些检查点请求，看门人进行最终调用以授予或拒绝检查点。网守考虑许多系统运行时因素来授予/拒绝检查点请求，例如 CPU 负载、磁盘 I/O、网络 I/O、作业调度队列、故障事件预测和 QoS 保证。奥林纳等。 [32] 还表明协作检查点简单实用，可以应用于现有应用程序检查点机制之上。进行了许多实验，表明协作检查点优于周期性检查点。 Jangjaimon 和 Tzeng [35] 提出了一种增强的自适应增量检查点 (EAIC) 容错机制。 EAIC 旨在基于未来的云计算资源即服务 (RaaS) 模型，为托管在多核云基础设施上的多线程云应用程序提供 FT。调整后的马尔可夫模型 (AMM) 的构建是为了满足现场实例 (SI)、保留实例 (RI) 和硬件故障的需要。在 RI 中，客户购买预先配置资源（如 CPU、IO 或内存）的预留实例。对于 SI，客户可以竞标未使用的资源，而且价格通常比 RI 低得多。结果表明，应用程序运行时间和成本的显着减少都归功于多级检查点的使用。这个观察是在使用 RI 和 SI 时进行的。赵等。 [36] 提出了一种新方法，该方法确定如何使用对等检查点在云计算中提供弹性和联合可靠性优化。总的来说，这项工作 [36] 利用云实用程序的检查点技术在数据中心的资源限制下共同最大化可靠性。主要关注点对点检查点，用于提高网络资源限制下的可靠性。在正常情况下，VM 映像被发送到中央存储服务器，这可能会由于高带宽使用率而导致网络拥塞。为了缓解这个问题，点对点检查点是一种分布式方法，云运营商可以选择在具有足够带宽的对等点之间路由检查点的位置。 仿真结果表明，与随机点对点检查点和集中式检查点相比，这种方法显着提高了可靠性。 Amoon [37] 描述了一种基于检查点和复制的云计算自适应容错框架。该框架在某种意义上是自适应的，它能够选择最佳的容错方法用于客户的任务。此外，该框架还提出了一种复制算法，可以自适应地确定应用程序所需的副本数量。通过这种方式，复制仅适用于发生故障时对云有较大性能影响的虚拟机。检查点也是自适应的，检查点间隔的长度是根据虚拟机的故障概率自适应确定的。

Replication

复制技术的工作原理是复制一些系统组件，然后将这些组件同时部署到不同的资源中。该技术旨在使系统健壮，提高可用性并保证作业的执行 [9]、[26]、[38]、[39]、[40]、[41]、[42]、[43] , [44], [45], [46], [47]

Bodı k 等人。 [9] 提出了一种可用于云迁移的新算法。云迁移的一个挑战是找到一个既能满足容错又能降低带宽成本的最佳部署模型。该算法还确定了将系统组件复制到云中并实现最佳带宽和容错的最佳方式。将系统部署到云中的主要挑战之一是服务器可用性。这与可用带宽直接相关。数据中心采用本地冗余构建，可让本地服务器在维护或维修时脱机。当整个数据中心因灾难或网络设备维护而离线时，挑战就来了。这通常会导致大量服务器脱机。可用带宽与云系统的部署架构相关联。部署在一个数据中心的云系统容易出现服务器不可用、网络拥塞等各种网络故障。如果网络连接完全中断，数据中心将成为单点故障。增加部署系统的数据中心数量会直接增加带宽使用，但会显着提高容错能力。因此，在提供高容错性和减少带宽使用之间找到良好的平衡存在挑战。 这可以通过 [9] 中描述的算法来解决。 Balasubramanian 和 Garg [38] 描述了分布式系统中基于融合数据结构的故障管理解决方案，旨在处理数据崩溃和拜占庭故障。融合数据结构的设计方式使得主数据结构的恢复可以通过非常有限的复制次数来完成。融合数据结构的主要优点是节省了存储数据结构副本所需的存储空间。该技术主要适用于基于队列、栈、向量、二叉搜索树、哈希映射和哈希表等数据结构的解决方案的分布式存储。融合数据结构还大大节省了从故障中恢复所需的计算资源。

库利等人。 [39] 目前 Remus 主要基于检查点和复制。 Remus 的目标是实现一种透明的容错技术，不需要对现有的云应用程序进行任何更改。在 Remus 中，托管应用程序的虚拟机被配对成一个主虚拟机和一个辅助虚拟机。 Remus 中的复制是异步完成的。然后采用各种技术来确保主要和次要之间的异步状态复制。主 VM 的输出被缓冲并异步复制到辅助 VM。主 VM 在其状态被检查点后立即恢复执行，并且不等待辅助 VM 的确认。 Remus 结合了一种简单的磁盘缓冲技术来保持主虚拟机和辅助虚拟机的磁盘同步。在主 VM 上发出的磁盘写入立即提交到其本地磁盘，它们同时传输到辅助 VM 上的缓冲区。辅助 VM 在检查点后提交到其本地磁盘。

Castro 和 Liskov [42] 描述了拜占庭容错 (BFT) 协议。 BFT 协议主要旨在解决可靠性和保证系统的高可用性。大多数 BFT 系统对于实际实施而言过于昂贵，因此，据我们所知，到目前为止，还没有关于实施 BFT 技术的商业数据中心的报道。提供异步、分布式、客户端-服务器系统的 BFT 解决方案至少需要 $(3f+1)$ 个副本，其中一个为主，其余为备份，其中$ f $是在任何给定点可以容忍的最小故障数时间。 BFT 解决方案具有高资源消耗，这可以归因于它们处理故障的方式。 BFT 解决方案依赖于服务器状态机复制 (SMR)，其中每个副本都以相同的顺序执行相同的请求。副本使用拜占庭协议来就一组给定请求的顺序达成一致。订单达成一致后开始执行，然后使用多数表决方案选择正确的答案发送回客户端。以这种方式，在该投票阶段也可以检测到有故障的服务器。

郑等。 [46] 提出了一种基于组件排名（称为 FTCloud）的可配置容错方法。 FTCloud由两种算法组成；第一种算法使用组件执行结构并监视执行频率以构建显着组件排名。第二种算法使用这些重要组件排名以及系统设计人员输入的容错要求来识别云应用程序的重要组件。完成组件排名后，该算法会自动为重要的云组件确定最佳容错策略。最重要的观察是，通过容忍一小部分最重要组件的故障，云应用程序的可靠性得到显着提高。用于重要组件的最佳容错策略基于冗余和复制。贾瓦尔等人。 [47] 介绍了一种创新的、系统级和模块化的解决方案，用于在云中创建容错。该解决方案向应用程序开发人员隐藏了 FT 实施细节。因此，它创建了一个服务层，开发人员可以在其中请求 FT 作为服务。用户可以指定和应用所需的 FT 级别，而无需了解用于实现容错的底层技术。该解决方案假定客户端应用程序部署在虚拟机上，因此将 FT 的粒度限制为 VM 实例。具体来说，该方案利用冗余和复制来实现容错，创建多个虚拟机副本，并在出现故障时随时可用以接管。

Retry

重试技术的工作原理是简单地多次重试同一资源上的失败请求 [48]、[49]。

Ramalingam 和 Vaswani [49] 提出了一种解决方案，该解决方案依赖于重试技术来解决由于云系统中的进程或通信故障引起的故障。在这样的环境中，失败的请求只是重试。重试机制依赖于系统的无能。 Indepotence 被描述为一个标准，使得在存在重复请求和失败的情况下从应用程序获得的结果与在没有重复请求和失败的情况下从这样的应用程序获得的结果完全相同。 Indepotence 由一种名为 FAIL 的语言形式化，该语言受云平台的影响。本质上，语言 FAIL 将流程失败、重复请求、数据和事务形式化。 FAIL 的最终目标是保证无能的云服务。这样的系统是去中心化的，不需要分布式协调。结果，这产生了一个完全分散的容错实现，它处理相同请求和进程失败的多次重试。

王等。[48]分析了重试容错技术对云服务的性能影响。这是通过构建云服务处理时间的数学模型来实现的。该模型后面是处理时间的概率分布，以分析在出现故障时重试作业的影响。还通过计算在定义的阈值下可以成功服务的请求的百分比来反映服务质量。将使用重试技术的云系统的性能与使用 FT 的检查点技术的云系统的性能进行了比较。结果表明，根据检查点方法的恢复率，重试技术的性能可能比检查点技术更好或更差。

Task Resubmission

在任务重新提交中，当检测到失败的任务时，它会重新提交到相同或不同的资源以执行 [44]。

Plankensteiner 等人。 [44] 描述了重新提交影响启发式，并用它来改进基于重新提交和复制技术的容错方法。这种方法通常用于在分布在云端的工作流系统中实现容错。改进基于引入称为重新提交影响的新算法。重新提交和复制是广泛用于分布式系统容错的基本技术。重新提交通过对失败资源或新资源重新执行单个任务来操作，这会显着增加任务完成时间。复制将同一任务的多个副本同时执行到多个资源，并且存在资源使用率高的缺点。为了在重新提交和复制之间找到平衡，该算法计算 RI（Replication Index）启发式算法，该算法用于描述重新提交任务对工作流整体执行的影响。 RI 是为每个工作流程定义的，它用于推断生成的重复次数。实验结果表明，与保守方法相比，RI 显着减少了超过 42% 的资源消耗。除此之外，RI 不会对任务完成率和整体工作流性能产生负面影响。

Custom Exception Handling

自定义异常处理包括软件开发人员将代码插入应用程序的方法，以便它可以在运行时处理特定故障 [50]。

刘等人。 [50] 提出了一个框架，用于解决通过业务流程执行语言 (BPEL) 引擎实现编排的事务性 Web 服务 (FACTS) 的容错问题。 Web服务主要用于开发现代商业应用程序。 FACTS 是六个组件的集合，即 EXTRA、WS-BPEL 设计器、规范模块、验证模块、实施模块和计划模块。 EXTRA 组件提供了一组高级异常处理策略，这些策略在标准的 WS-BPEL 内置异常和事务处理工具上运行。复合 Web 服务的容错需求通常源自业务需求。服务设计人员使用事件-条件-操作 (ECA) 规则来定义处理故障的逻辑。 ECA 规则又基于 EXTRA 模块中定义的异常策略。验证模块用于验证故障处理逻辑。它通过评估 ECA 规则必须遵守的原则来做到这一点。

Rescue Workflow

救援工作流是一种旨在解决基于工作流的系统容错的技术。即使任务失败，工作流也可以继续，直到如果不处理失败的任务就无法继续 [51]、[52]。对基于工作流的系统的容错机制更感兴趣的读者可以参考 [51]。 Hernandez 和 Cole [52] 提出了救援有向无环图（Rescue DAG），这是一种基于倒带和迁移的可靠工作流 DAG 调度机制。该机制依赖于两个关键组件，即 DAG Manager (DAGMan) 和 Rescue DAG。 DAGMan 是元调度器，它负责管理整个工作流，包括将工作流调度到计算资源上。 DAGMan 还包含容错机制。该机制执行 DAG 工作流失败部分的重新提交。当一个 DAG 的任务失败时，DAG 中的剩余任务将继续执行，直到由于 DAG 工作流中的任务依赖性而无法继续执行。在这种情况下，DAGMan 会输出一个名为 Rescue DAG 的特殊文件，其中包含有关成功任务和不成功任务的足够详细信息。然后使用 Rescue DAG 来恢复工作流。重新提交失败的任务。成功的任务不会重新执行，因此可以节省计算资源和时间。

Load Balancing

负载均衡是云系统容错和运行的关键。许多服务器在被客户端请求淹没后可能会因计算资源（CPU 或 RAM）耗尽而崩溃。为了减少此类故障，云系统必须实施负载平衡作为负载保护的第一道防线 [53]、[54]、[55]、[56]。传统的集中式负载均衡机制不适用于云系统。云系统具有高度可扩展性，它们建立在分布式服务器上，这些服务器可以托管在多个数据中心（取决于云系统的架构）。由于此类系统的规模和复杂性，无法将计算请求集中分配给服务器。蜜蜂觅食行为 [55]、有偏随机抽样 [56] 和主动聚类 [53] 是云系统最常用的负载平衡算法。分布式负载平衡算法通常具有内置机制，使它们能够协调公平地处理负载。 [54] 中介绍了这些算法的比较研究。

N-Version and Recovery Block

N-version 是一种多版本编程模型。多个功能相同的程序是由不同的团队根据同一组需求规范开发的。团队独立工作，根本不交流。 N版本的思想是基于这样一个事实，即独立开发的程序大大降低了两个或多个版本中出现类似故障的概率。恢复块 (RB) 利用输入数据的不同表示来提供设计错误的容忍度 [57]、[58]、[59]、[60]、[61]。

N-Version 最近已进入云安全 [58] 和恶意攻击（反病毒 [57]）应用程序。 [60] 中介绍了 N 版本和容错之间关系的一些一般背景。在接下来的段落中，我们将讨论一些研究工作，其中 N 版本技术已被用作云场景中容错的一部分。

彭等。 [59] 回顾了增强型 N 版本编程 (ENVP) 和扩展恢复块 (ERB) 技术。 ENVP 和 ERB 可以联合用于提高 Web 服务 (WS) 的可靠性，因此它们对提高云系统的容错能力有直接的贡献。 ENVP 和 ERB 分别是其原始对应的 N 版本 (NVP) 和恢复块容错机制的扩展。这些技术已经适用于为基于 WS 的容错系统提供支持。 NVP 通过利用多个功能等效的软件组件（或版本）提供容错能力。另一方面，RB 使用不同的输入数据表示来容忍软件设计错误。

ENVP 和 ERB 的逻辑在中间件中实现，中间件负责处理服务用户（客户端）和服务提供者（服务）之间的交互。 NVP 和 RB 都通过在中间件中引入验收测试 (AT) 组件进行了扩展。 AT 组件用于在将 WS 的输出传递给决策管理器 (DM) 之前评估其输出的正确性。实验结果表明，增加更多的 AT 组件可以提高系统的整体可靠性。

Proactive Methods

主动方法持续监控系统并进行故障预测，以便在故障发生之前很好地预防故障的影响。在监控中，系统不断地执行故障预测算法来评估系统的状态，以便采取必要的措施来防止故障。对于运行在虚拟化环境中的云系统，此类故障管理技术更多地依赖于虚拟平台提供的迁移、暂停/取消暂停功能。根据当前文献，用于主动容错的关键技术包括软件更新、自我修复、抢先迁移、监控和 SGuard。本节回顾了有关 PRM 的选定论文。

Software Rejuvenation

软件更新 (SR) 是为定期重启而设计的 [62]、[63]、[64]，它基本上涉及优雅地终止系统并重新启动它。 SR 由另外两种技术补充：1）错误计数；和 2) N 版本编程。错误计数也称为“数黑羊”。这是一种在错误发生时对错误进行计数的技术，这些错误计数的记录会被保存下来，以便它可以用于升级和加速恢复过程。

Self-Healing

自愈技术是系统的一项功能，可以自动检测、诊断和修复软件和硬件故障。此类系统由部署在多个 VM 上的多个组件组成 [65]、[66]、[67]、[68]。

Preemptive Migration

抢先迁移是虚拟化环境的一种重要方法。它提供了将程序执行从一台机器实时迁移到另一台机器的机制。此技术可防止即将发生故障的系统组件影响系统的性能。这是通过监视和将组件从即将无法在更稳定的节点上运行的节点移开来实现的 [3]、[13]、[69]、[70]、[71]、[72]、[73] , [74], [75], [76], [77], [78]。 Applying preemptive migration for proactive FT [69] 提出了一种依赖于抢先迁移的主动容错方法的体系结构。

恩格尔曼等人。 [69] 定义了一种架构，该架构将服务器作为主动 FT 的基础。该体系结构基于虚拟机（VM）的预先迁移，因此适用于云计算。此外，还提供了实施选项的分类。分类由实施所采用的监控策略定义。该架构的核心是一个反馈回路控制机制，它构成了系统健康监测的一部分。系统及其应用程序受到监控，并采取预防措施将应用程序组件从预计会发生故障的节点迁移到更健康的节点。确定了监控系统健康状况的一些挑战。其中一个关键挑战是每个解决方案目前都在使用自己的一组指标来测量和评估系统组件之间的健康和接口。需要标准指标和接口。

Nagarajan 等人。 [70] 为消息传递接口 (MPI) 应用程序的主动 FT 提供了一种自动和透明的机制。该机制将虚拟化技术与健康监控和抢先迁移相结合，以实施主动 FT 解决方案。使用了 XEN 虚拟化环境。该解决方案利用 XEN 的实时迁移功能，允许客户操作系统与其正在运行的任务一起重新定位到另一个节点。当检测到节点的健康状况恶化时，将触发迁移。抢占式迁移机制运行良好，消除了迁移开销。 MPI 任务在迁移过程中继续执行。

刘等人。 [3] 提出了一种主动协调 FT (PCFT) 解决方案，旨在为并行云系统提供容错能力。 VM 协调机制用于预测恶化的物理机 (PM)。恶化 PM 上的 VMS 迁移到最佳目标 PM。机器性能下降的预测基于对 CPU 温度的监控。该算法的复杂性在于找到一个最佳目标 PM，它必须确保效率、有效性和可扩展性要求。

Prediction

预测构成了主动容错算法的核心。提前预测故障，以便云系统有机会采取纠正措施来避免或减少故障的影响 [13]、[17]、[79]、[80]、[81]、[82] , [83], [84]。萨尔夫纳等。 [83]提供了一种通过调查的预测方法。 Tikotekar 等人提出了一个可用于评估各种 FT 方法和政策的模拟框架。 [84]。该框架非常重视使用预测组件的主动 FT。

瓦莱等人。 [13] 描述了主动容错的通用框架。该框架基于故障预测，主要目标是避免故障。当检测到故障时，系统会使用底层虚拟化平台的故障管理功能，例如暂停/取消暂停或迁移进程或整个虚拟机节点。故障预测器利用计算节点上的本地信息来预测当前发生故障的概率，故障预测器定期分析本地系统日志，如果检测到异常行为则产生告警事件。进行了两个实验，作为证明该框架在进行迁移时对计算开销的有效性的一部分。第一个实验是使用 XEN 虚拟化平台完成的，并测量了虚拟机占用空间对迁移成本的影响。影响是根据虚拟机内存与总迁移时间（以秒为单位）的函数来衡量的。第二个实验中，使用专为评估容错策略而设计的模拟器进行 [84]。发现模拟结果与使用 XEN 的物理实验结果一致，得出的结论是该框架减少了计算开销。

平托等人。 [17] 通过结合预测来增强 Hadoop 集群中的容错能力。预测是使用支持向量机 (SVM) 模型实现的。 SVM 是具有相关学习算法的监督学习模型，这些算法分析用于分类和回归分析的数据。 SVM 分类器托管在监控 PC 上，以对系统故障进行智能预测。标准的 Hadoop 架构包括一个级别的容错，其中作业从故障节点重新安排到网络中的其他节点。这会导致效率低下，因为它可能需要重新处理已经完成的子任务。 SVM 预测模型用于更早地预测故障，以便更早地做出重新安排工作的决策。此外，还结合了强化学习模块以消除误报，从而显着增强集群的容错能力。

哥斯达等人。 [79]描述了一种基于预测的主动容错解决方案，可以有效地避免内存错误。该解决方案源于一项观察，即检查点/重启可能无法有效地处理以千万亿次级执行的高性能计算中的内存故障。这种方法嵌入到操作系统中。它的工作原理是向操作系统公开可纠正的错误信息，迁移页面并使故障内存脱机以避免应用程序崩溃。对内存错误模式进行分析，并使用可纠正的错误模式来预测可能发生故障的内存。在 IBM 的 Blue Gene/Q (BG/Q) 系统上运行的 Linux 上实现了一个原型，该系统是一个 HPC 系统。

Monitoring (Feedback Loop)

监控主要用于补充其他主动算法。它用于监视正在运行的应用程序上的一组状态变量。状态变量被过滤并通过反馈循环机制 [14]、[85] 提供给策略管理器。

Egwutuoha 等人。 [14] 描述了一种主动技术，它依赖于监控为云中的 HPC 提供 FT。这种 FT 技术的框架最初是由 Egwutuoha 等人提出的。 [85]。根据这项研究，超过 50% 的 HPC 系统故障是由处理器、硬盘驱动器、集成电路插槽和内存引起的。强调了与被动方法相比，HPC 计算中主动容错的优势。与主要基于检查点和重启的反应式容错方法不同，主动容错避免了从检查点重启，因此降低了运营成本和能源消耗。 Egwutuoha 等人。 [14] 主要关注 MPI 应用程序。 MPI 应用程序实际上是在不同 CPU 或 VM 上并行运行的应用程序，它们通过消息传递交换数据来进行通信，例如 GROMACS 系统 [89]。 Egwutuoha 等人。 [14] 采用回避方法来容忍错误。这是通过结合使用系统日志和健康监控设施来实现的。系统日志提供有关可靠性、可用性和可服务性的信息，而健康监控则以硬件和软件的状态为主。 [14] 中提出的主动 FT 解决方案的架构由四种类型的模块组成：1）带有 lm 传感器的节点监控模块；2）故障预测器；3）主动容错策略模块； 4) 控制器模块。 [14] 还提出了容错算法的框架和一些结果的定量分析。结果表明，通过实施此 FT 模型可显着节省成本。节省的主要原因是由于立即放弃故障节点而节省了运营成本。

Park等。 [90] 描述了一种监控技术，可以作为移动云计算中容错的一部分应用。虽然Park等人。 [90] 没有描述完整的容错技术，它提供了一种监控技术，该技术对于在移动云计算中实现 FT 非常有用。移动云计算被描述为移动计算和云计算的结合。在移动云计算的背景下，云计算是通过移动设备提供的。移动设备上的遗留问题似乎已被克服，这些问题包括电池寿命短和 CPU 性能低下。该论文确定了在移动云计算中使用移动设备的两类，即作为接口的移动设备和作为资源的移动设备。大多数工作以前都是使用移动设备作为界面进行的，最近的趋势是使用移动设备作为托管云服务的资源。使用移动设备作为资源面临着大多数与移动性相关的问题。其中包括由于无线连接不稳定导致的波动性、电源限制、低网络带宽以及由于频繁的位置变化导致的切换问题。因此，资源监控是在移动云计算中实现可靠的资源调度和容错技术的关键。一种资源监控技术，需要收集和分析有关每个参与资源状态的动态信息并确保稳定性。 Park等。 [90] 提出了一种基于马尔可夫链的监控技术，旨在监控和分析资源状态。 主要目的是解决移动设备的波动性对容错问题的影响。

SGuard

SGuard 是一种基于回滚和恢复的技术，用于实时视频流。它对视频流的影响要小得多 [18]。

权等人。 [18] 向 SGuard 展示了一个弹性容错方法的示例，该方法由反应性故障技术（即检查点、回滚、恢复和复制）的合并形成。 SGuard 是一种相对较新的技术，用于处理部署在多个集群中的分布式流处理引擎 (SPE) 中的故障。这种部署模型类似于基于云的服务。这种方法使用回滚/恢复技术来实现容错。在系统运行时，SGuard 在流服务运行时异步执行检查点。故障服务器根据最近的检查点回滚和恢复。故障服务器的检查点、回滚和恢复是异步发生的，不会造成任何服务中断。检查点状态保存在分布式文件系统 (DFS) 上，例如 GFS、HDFS 或 Amazon EC2。 SGuard 能够处理软件故障和硬件崩溃。为了掩盖故障，SGuard 进一步采用了复制技术。 SPE 的状态在多个服务器上复制，这些服务器被分类为主要或次要。因此，SGuard 为实时视频流提供了一种破坏性较小的容错解决方案。

Resilient

弹性方法使系统能够在出现故障时继续为客户端请求提供服务，并在可接受的时间段内快速恢复。故障可能是设备故障、停电或中断造成的。通常，弹性系统由组件组成，这些组件负责实现在出现故障时继续响应客户端的能力、系统状态的监控、学习和适应系统的能力。 Colman-Meixner 等人。 [91] 对应用于云架构不同层的弹性技术进行了全面调查。系统监控组件对于密切关注系统状态以及检测和预测即将发生的故障至关重要。弹性系统的目标是通过最大化系统的可用性来最小化系统的整体停机时间。学习组件负责优化故障恢复，它通过使用环境参数来实现这一点，并使用它们来改进下次发生故障时的处理。这样，系统就能够从环境中学习并调整其容错机制。

容错机制的适应通常涉及部署最佳资源以使系统避免完全中断。系统可以在出现故障之前或之后按时动态地添加或删除容量。本质上，弹性方法是通过将用于 RAM 和 PRM 的技术与通过与环境交互学习的能力相结合并适应容错 [19]、[20]、[21]、[22] 、 [23]、[24]、[25]形成的。本节回顾了有关 RSM 的选定论文。

Machine Learning Approaches

机器学习带来了容错的智能方式。云系统能够通过与其环境交互来学习，并相应地调整其故障处理策略。强化学习似乎是 FT 领域中最常用的技术 [19]、[20]、[21]、[22]、[23]、[24]、[25]、[39]、[86]。本节中审查的大多数论文可能不会直接链接到云计算。然而，我们寻求确定信息来源，其中机器学习，特别是强化学习已被用于实施或提高系统的容错能力。这些想法可以很容易地扩展到云环境中。

董等人。 [86] 为基于优先级队列和动态路由的云提出了一种高度弹性的容错解决方案。该解决方案得到云敏捷性的进一步支持，即动态地动态配置或取消配置额外的云资源的能力。使用分类方法，云服务请求被分成高优先级请求和低优先级请求，并分别映射到高优先级队列和低优先级队列。分布式动态队列用于卸载本地和远程云节点上的请求。队列技术（例如 Rabbit MQ）增加了将请求移交到远程托管的云服务器上进行处理的能力。动态路由监视优先级队列上的负载，当优先级队列上的负载增加时，它会发出在远程站点上提供额外服务的信号。较低优先级队列（可以容忍高延迟的队列）上的服务请求被移交给辅助服务器处理。该解决方案在后端包括一个数据复制层，用于同步主从服务之间的数据，以便它们可以独立运行。

许等。 [20] 提出了 FT 的统一强化学习（URL）解决方案。 URL 是一种机器学习技术，用于为云计算自动配置 VM 和设备。 VM 是托管云系统的各种组件的虚拟机。这些设备可以是任何基于 VM 的软件包，例如 Apache 或 Tomcat Web 设备。 VM 和设备都有大量的配置值。配置这些值以获得最佳性能和可用性的过程很容易出错。在论文 [20] 中，描述了两个强化学习智能体，即 VMAgent 和 App-Agent。 VM-Agent 用于重新配置 VM，App-Agent 用于重新配置设备。每个智能体的行为都使用马尔可夫决策过程 (MDP) 建模。每个智能体的状态被描述为 VM 或设备的配置参数向量。由于系统的工作负载需求会随着时间的推移而变化，因此 URL 的目标是找到能够为给定工作负载产生最佳性能的良好配置。

吴等。 [21] 建议使用顺序共享学习 (OSL) 来增强弹性和 FT。 OSL 是一种用于作业调度的鲁棒多智能体强化学习 (MARL) 方法。尽管最初是为网格计算设计的，但 OSL 中的思想也可以应用于云计算。 OSL 具有高度可扩展性。 OSL 由在智能体之间迭代交换的轻量级和线性效用表组成。实用程序表用于跟踪处理计划作业的系统资源的效率。 OSL 需要非常少的网络通信带宽，智能体只交换作为每个智能体学习算法输入的效用表。 Scheduler Agent 由两个主要组件组成，即 Actor 和 Learner。 Actor 接收要调度的作业，它在队列中缓冲作业（作业缓冲区）并跟踪当前正在运行的作业（提交的作业列表）。 Leaner 收到共享效用表，它使用提交的作业列表中的信息来学习处理当前作业的资源的新分数。分数被更新，效用表被传递到网格中的相邻节点。这种方式可确保最佳性能和最可靠的资源处理作业，从而增强系统的弹性和容错能力。

Farivar 和 Ahmadabadi [19] 提出了两种策略，可用于设计鲁棒且自适应的容错控制 (FTC) 系统。尽管 FTC 与云系统没有直接关系，但可以为云系统数据中心借鉴和实施机器学习（尤其是强化学习）和神经网络（NN）的思想和方式。 [22] 中考虑了在基于执行器的系统中使用 NN 进行容错控制的类似方法。故障是由一些执行器和传感器产生的，这些执行器和传感器可以安装在典型的云数据中心中以监控各个方面，例如入侵和温度。传感器可以扩展到包括软件定义的传感器，这些传感器可以监控各种软件定义的指标，例如流量或系统负载。定义了两种 FTC 策略。第一个策略涉及一个智能观察器，用于监视未知数量的非线性系统。第二种策略是基于强化学习，它结合了一些未知的非线性故障系统和非线性控制理论来保证系统的稳定性和鲁棒性。这种非线性系统可以建模为负责托管云系统的服务器基础设施。进行了模拟，结果证实上述 FTC 策略表现良好。此外，对于执行器故障，强化学习被发现比神经网络表现更好。同样，神经网络在基于传感器的故障上的表现优于强化学习。

Forster 和 Murphy [23] 提出了到多个接收器的反馈路由 (FROMS)，这是一种基于强化学习的无线传感器网络 (WSN) 的基于机器学习的多播路由范例。这是通过将 WSN 中的多播路由建模为强化学习问题来实现的。尽管 WSN 不被视为与云计算直接相关，但有一种观点认为，连接不良的网络中的最终用户设备可以形成一个动态的 WSN 并使用它来访问云服务。在这种情况下，WSN 的容错解决方案可以通过使 WSN 更加健壮来帮助解决云系统的容错问题。 FROMS 基本上是 WSN 的路由协议。 FROMS 的优势包括在不同服务器条件下灵活地优化路由，例如路由长度、电池电量、故障后恢复以及对接收器移动性的支持。这些声明作为 [23] 中获得的实验结果的一部分得到了支持。

Wang 和 Usher [24] 描述了 RL 在基于智能体的计算中的应用。 RL 通常用于授权自主智能体学习选择适当的行动，通过与环境交互来实现其目标。动作的选择取决于要解决的问题。尽管与容错没有直接联系，Wang 和 Usher [24] 将 RL 应用于制造系统中的计算智能体。著名的 RL 算法 Q-Learning 用于使机器智能体能够学习普遍接受的调度规则，这依赖于先前定义的最佳调度规则。 RL 的这种应用可用于云计算中的容错。由于云计算包括许多不同类型的计算智能体，它们通过 Internet 访问服务。需要解决连接问题，尤其是在移动网络上。可以应用 Q-Learning 算法，使智能体能够根据可用网络接入点列表始终选择最可靠的 Internet 连接。

Chen 和 Marculescu [25] 提出了一种在线分布式强化学习 (OD-RL) 算法，用于在功率限制下提高多核系统的性能。 OD-RL 算法基于动态电压频率缩放 (DVFS) 技术以节省功率。大多数托管云服务的数据中心都部署在基于多核 (CPU) 系统的服务器基础设施中，因此 OD-RL 适用于云端。强化学习用于学习在 CPU 级别控制电压/频率 (VF) 的最佳策略。定义了用于在更粗粒度全局级别管理功率预算级别的最大化-最大方法。我们更感兴趣的是 RL 在更细粒度 CPU 级别的应用。实验结果表明，OD-RL 可显着节省电能、提高吞吐量和能效。

Fault Induction

Limoncelli [87] 描述了术语反脆弱性以及故障诱导方法在谷歌和亚马逊等大公司中对 FT 的应用。早在 2000 年代初，亚马逊就开始使用故障感应方法。这是通过一个名为 GameDay 的程序完成的。 GameDay 是一个程序，旨在通过在给定时间故意使系统出现重大故障来提高弹性，以发现系统之间的缺陷和依赖关系。 GameDay 测试类似于组织中的消防演习。 GameDay 行动不仅关注计算机系统，还包括对软件和人员（暗示业务流程）的测试，目的是让他们为应对实际灾难事件做好准备。 GameDay 演习模拟了一场真实的灾难，因此参与者可以包括组织各个级别的工作人员 [87]。 GameDay 现象已被谷歌和亚马逊等大型组织积极使用。 GameDay 测试可以重复。只有在重复测试时一切正常时，GameDay 练习才被标记为成功。这种技术的部分成果是使组织能够从失败中学习。使用 GameDay 方法已经取得了显着的成果。

Strengths and Weaknesses

在本节中，我们将回顾容错方法的优缺点。传统方法的优点和缺点在文献中得到了很好的研究，这些包括 [26]、[12] 和 [31]。因此，在这篇评论中，我们将介绍机器学习特定方法的优缺点，因为这是一个新兴领域。

越来越多地使用云计算导致系统复杂性和规模呈指数级增长。这最终将导致传统的容错方法不再有效和可行的状态。因此，需要替代方法来处理云中的资源管理、安全性和能源效率等容错问题。本研究中审查的论文评估了各种机器学习算法，这些算法对云容错有不同的贡献。

机器学习提供了能够处理大量数据并不断学习和调整系统的工具和算法。 ML 由三个主要类别组成，即监督学习、无监督学习和强化学习 (RL)。 RL更适合实现控制优化类型的解决方案。因此，RL 是实现容错的首选 [19]、[23]、[92]。

通常，RL 算法分为两大类，即基于模型和无模型的方法 [93]。基于模型的方法使用智能体与环境（云）交互的经验构建世界模型。该模型用于学习价值函数。无模型方法直接从与环境的交互中估计价值函数。每个班级都有不同的长处和短处。基于模型的方法的关键优势在于，在大多数情况下，他们找到了与环境交互较少的良好价值函数，因此通常被视为产生更好的性能，这被称为数据效率 [93]。然而，这是有代价的，基于模型的方法通常需要更多的计算资源。无模型方法的主要优势在于它们需要更少的计算资源，因此它们可以支持比基于模型的方法大得多的表示，这被称为计算效率。无模型算法的另一个优势在于它们是可扩展的，它们随着代表环境的特征数量线性增长 [93]。

RL 的最终目标是学习用于管理智能体行为的最优策略。 RL 系统由许多智能体组成，这些智能体通过一些涉及与环境交互的反复试验的经验来学习。 RL 智能体通过最大化从动作价值函数获得的奖励来不断适应环境。智能体学习从每个系统状态采取的最佳行动。 RL 适用于状态数量极大、结构复杂的系统，因此适用于云系统。然而，此类系统的一个弱点是需要大量的计算资源，尤其是存储和内存。

一些著名的机器学习工具已与 RL 算法一起使用，包括 Q-Learning、人工神经网络 (ANN)、朴素贝叶斯、随机森林和深度学习 [15]。接下来我们看看使用每种容错解决方案的方法的优点和缺点。

Q-Learning 是一种无模型方法，主要用于通过学习每个状态-动作转换的最佳 Q 因子来找到最佳策略。它主要应用于任何具有有限状态的马尔可夫决策过程[20]。 Q-Learning 的关键优势在于它是无模型的，而且实施起来非常直接。 Q-Learning 的主要弱点是跟踪每个 Q-factor 所需的存储量，尤其是当状态-动作对的数量增长太大时。

人工神经网络可用于补充 Q-Learning。当状态值对的数量太大并且因此不能有效地存储在 Q 因子列表中时，将应用 ANN。因此，给定动作的所有 Q 因子都存储在一个网络中。然而，训练 ANN 来表示 Q 因子可能既复杂又耗时。

支持向量机是最近应用于强化学习的数据挖掘工具的一个例子，特别是在需要分类或回归时 [94]。 SVM 的优势包括高水平的预测准确性，即使在训练示例包含错误时它们也能发挥作用。在弱点方面，SVM 需要很长的训练时间，学习到的函数很难理解，因为它以权重表示。

朴素贝叶斯是一种基于贝叶斯定理的分类器，它是基于模型的，可以与强化学习一起使用。它在模型不完全已知且存在不确定性的情况下很有用。朴素贝叶斯的主要优势在于它被认为是快速、健壮的并且可以处理不完整的模型。朴素贝叶斯可以处理非常大的数据集，并且优于许多其他复杂的分类器。朴素贝叶斯的一个主要弱点是它依赖贝叶斯定理，该定理假定所有属性（特征）都是独立的。这样的假设可能导致简单地忽略预测中属性相关性的影响。

深度强化学习是深度神经网络与 RL 的应用。当状态-动作对的数量变得太大时，这特别有用。不是为每个状态-动作对存储 Q 因子，而是使用深度神经网络来存储每个动作的 Q 因子，这些网络也称为深度 Q 网络 (DQN) [95]。这种方法的关键优势在于能够处理大数据，从而使 RL 能够扩展到以前难以解决的问题领域 [96]。同时，他们的主要弱点与训练时间有关。

随机森林是基于树的分类结构，已与 RL 一起使用。基于树的算法的优势包括显着减少分类错误（高度准确）和降低计算资源负载 [97]。它们可以处理相当大的特征变量，并且在大型数据库上非常有效。在大多数报道中，随机森林为学习函数近似提供了更好的收敛性 [97]。在弱点方面，随机森林会遇到由过度生长的树木引起的过度拟合问题。交叉验证可用于解决过度拟合问题 [98]。

Emerging directions

根据作为本研究的一部分审查的论文（见表 2），很明显，目前有大量的容错解决方案仍然主要基于被动和主动方法。在云系统的背景下，这些方法的性能、灵活性和可扩展性仍有待证明。对于其中一些方法，不确定它们将如何在部署在分布式和异构云平台上的系统上工作。当前的方法不可扩展，需要某种形式的手动干预才能顺利运行和配置，因此，我们建议云中容错的未来将基于自动化。

在尝试解决其中一些挑战时，我们开始看到基于智能体的云计算的出现作为解决自主云问题的一种手段 [99]。因此，我们认为基于智能体的解决方案（包括强化学习）是云中自主容错的新兴方向。智能体是一个功能齐全的计算节点，能够独立做出决策并通过合作、协调和协商与其他智能体进行交互[99]。我们正在见证基于智能体的自动化在云的各个核心方面的出现，例如资源分配 [100]、[101]、作业/任务调度 [102]、[103] 和容错 [104]。此外，我们将继续看到高级机器学习技术（例如深度学习）的开发和应用，以支持基于智能体的自动化方法、硬件和基础设施监控 [105]、[106]、[107]、[108]、[ 109] 和弹性缓存 [110] 对自主容错有直接影响。

以下段落回顾了最近的一些论文，其中研究了与云计算和容错相关的基于智能体的计算和强化学习范例.

Sim [99] 介绍了基于智能体的云计算的概念，并解释了如何将基于智能体的计算范式应用于云计算基础设施和资源的管理。根据 Sim [99]，基于智能体的云计算涉及构建云的服务发现、服务协商和服务组合功能。服务发现由 Cloudle 实现，Cloudle 是一个基于智能体的云服务搜索引擎。进一步表明，基于智能体的协商机制可用于实现服务协商和云商务。此外，基于智能体的协作问题解决技术被证明可以解决自动化云服务组合的问题。实验结果表明，使用基于智能体的云计算自动化方法，智能体在协商云资源方面取得了很高的利用率和成功率。智能体也可以通过自主选择 Cloudle 机制支持的服务来成功组合云服务。

阿拉伯内贾德等人。 [101] 描述了另一种自动化方法，其中 RL 可用于自动化云中的动态资源分配问题。目标是实施一个云管理解决方案，该解决方案根据系统工作负载的波动进行自适应和自动缩放。强化学习用于决定何时添加或删除资源，同时仍然保证商定的系统 SLA。使用模糊逻辑方法。比较了两种基于模糊逻辑的动态学习策略，即模糊 SARSA 学习 (FSL) 和模糊 Q 学习 (FQL)。这两种方法都能够处理不同的工作负载模式，例如突发性和周期性工作负载。此外，FSL 和 FQL 能够按需交付资源，同时降低运营成本并避免违反 SLA。

Dal ılia 和 Coutinho [104] 提出了一种基于自主和强化学习的解决方案，以解决机会主义网格系统中复制和检查点之间的平衡问题。这些机会网格系统被定义为通过使用非专用计算资源的空闲处理能力动态形成的低成本和大型计算网格。此类非专用资源可以在地理上分布在许多不同的管理域中，并且此类资源随机加入和离开网格。因此，需要不断地监测和检测网格形成事件并及时做出反应。 RL 用于自动调整用于在检查点和复制之间切换的阈值。使用 RL，切换决策基于网格中计算节点的数量和可靠性。实验结果表明，该方法能够学习在复制和检查点之间切换的最佳阈值。

Conclusion

本文回顾了在分布式或云系统中实现容错的各种方法。我们将容错方法分为三大类：1）反应性方法； 2) 主动方法； 3）弹性方法。反应式和主动式方法主要基于传统的容错方法，如复制、检查点、重试、监控和抢占式迁移。

其中一些方法已在一定程度上用于实现云系统的容错。例如，大多数使用虚拟化技术的数据中心都依赖于抢占式迁移来处理由服务器中断引起的故障。这些传统方法有局限性。首先，它们基于固定的逻辑并以其实现定义的特定方式处理故障。因此，它们缺乏处理未来可能出现的新故障的能力。其次，这些实现在做出处理故障的决策时只考虑固有的系统属性。对可能影响系统性能（例如温度、功率和天气）的外部或环境属性的考虑非常有限。

由于计算的未来正在向云迁移，系统将面临传统容错方法无法处理的故障。因此，需要开发能够通过与运行环境的交互来学习和适应的系统。此类系统将需要使用机器学习方法作为其容错解决方案的一部分。正如我们在本文中所见，机器学习已被用于创建容错解决方案。然而，机器学习主要用作整体容错解决方案的一个子组件。一些解决方案主要使用机器学习来使用一组定义的变量进行预测。在其他应用中，机器学习已被用于管理硬件故障。这样的系统又是固定的并且不够动态以处理未来和未知的故障。

需要通过定义可在云环境中用于处理故障的可重用框架，将机器学习的应用进一步扩展到容错。这样的框架将被称为智能云。智能云的主要组成部分将是任何一组相互关联的智能体，并通过与它们将在其中执行的环境交互来学习如何处理故障。作为此的直接结果，这些智能体将有权做出连接决策，从而使他们也能够最佳地利用能源。

本文将未来的研究方向归于自动化。

Reference

[1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “A view of cloud computing,” Commun. ACM, vol. 53, no. 4, pp. 50–58, Apr. 2010.

[2] A. Abid, M. T. Khemakhem, S. Marzouk, M. B. Jemaa, T. Monteil, and K. Drira, “Toward antifragile cloud computing infrastructures,” Procedia Comput. Sci., vol. 32, pp. 850–855, 2014.

[3] J. Liu, S. Wang, A. Zhou, S. Kumar, F. Yang, and R. Buyya, “Using proactive fault-tolerance approach to enhance cloud service reliability,” IEEE Trans. Cloud Comput., vol. PP, no. 99, p. 1, 2017, doi: 10.1109/TCC.2016.2567392.

[4] A. Zhou, S. Wang, B. Cheng, Z. Zheng, F. Yang, R. N. Chang, M. R. Lyu, and R. Buyya, “Cloud service reliability enhancement via virtual machine placement optimization,” IEEE Trans. Serv. Comput., vol. 10, no. 6, pp. 902–913, Nov. 2017.

[5] A. Zhou, S. Wang, Z. Zheng, C. H. Hsu, M. R. Lyu, and F. Yang, “On cloud service reliability enhancement with optimal resource usage,” IEEE Trans. Cloud Comput., vol. 4, no. 4, pp. 452–466, Oct. 2016.

[6] S. Ananth and A. Saranya, “Reliability enhancement for cloud services—A survey,” in Proc. Int. Conf. Comput. Commun. Inform., Jan. 2016, pp. 1–7.

[7] J. W. Lin, C. H. Chen, and J. M. Chang, “QoS-aware data replication for data-intensive applications in cloud computing systems,” IEEE Trans. Cloud Comput., vol. 1, no. 1, pp. 101–115, Jan. 2013.

[8] Z. Qiu and J. F. Prez, “Enhancing reliability and response times via replication in computing clusters,” in Proc. IEEE Int. Conf. Comput. Commun., Apr. 2015, pp. 1355–1363.

[9] P. Bodık, I. Menache, M. Chowdhury, P. Mani, D. A. Maltz, and I. Stoica, “Surviving failures in bandwidth-constrained datacenters,” in Proc. ACM SIGCOMM Conf. Appl. Technol. Archit. Protocols Comput. Commun., 2012, pp. 431–442.

[10] J. Liu, S. Wang, A. Zhou, F. Yang, and R. Buy, “Availabilityaware virtual cluster allocation in bandwidth-constrained datacenters,” IEEE Trans. Serv. Comput., vol. PP, no. 99, p. 1, 2017, doi: 10.1109/TSC.2017.2694838.

[11] W. Qiu, Z. Zheng, X. Wang, X. Yang, and M. R. Lyu, “Reliabilitybased design optimization for cloud migration,” IEEE Trans. Serv. Comput., vol. 7, no. 2, pp. 223–236, Apr. 2014.

[12] P. K. Patra, H. Singh, and G. Singh, “Fault tolerance techniques and comparative implementation in cloud computing,” Int. J. Comput. Appl., vol. 64, no. 14, pp. 37–41, Feb. 2013.

[13] G. Vallee, K. Charoenpornwattana, C. Engelmann, A. Tikotekar, C. Leangsuksun, T. Naughton, and S. L. Scott, “A framework for proactive fault tolerance,” in Proc. 3rd Int. Conf. Availability Rel. Secur., Mar. 2008, pp. 659–664.

[14] I. Egwutuoha, S. Chen, D. Levy, B. Selic, and R. Calvo, “A proactive fault tolerance approach to high performance computing (HPC) in the cloud,” in Proc. Int. Conf. Cloud Green Comput., Nov. 2012, pp. 268–273.

[15] Z. Amin, H. Singh, and N. Sethi, “Review on fault tolerance techniques in cloud computing,” Int. J. Comput. Appl., vol. 116, no. 18, pp. 11–17, Apr. 2015.

[16] G. P. Sarmila, N. Gnanambigai, and P. Dinadayalan, “Survey on fault tolerant—Load balancing algorithms in cloud computing,” in Proc. Int. Conf. Electron. Commun. Syst., Feb. 2015, pp. 1715–1720.

[17] J. Pinto, P. Jain, and T. Kumar, “Hadoop distributed computing clusters for fault prediction,” in Proc. Int. Comput. Sci. Eng. Conf., Dec. 2016, pp. 1–6.

[18] Y. Kwon, M. Balazinska, and A. Greenberg, “Fault-tolerant stream processing using a distributed, replicated file system,” Proc. VLDB Endowment, vol. 1, no. 1, pp. 574–585, Aug. 2008.

[19] F. Farivar and M. N. Ahmadabadi, “Continuous reinforcement learning to robust fault tolerant control for a class of unknown nonlinear systems,” Appl. Soft Comput., vol. 37, pp. 702–714, 2015.

[20] C.-Z. Xu, J. Rao, and X. Bu, “URL: A unified reinforcement learning approach for autonomic cloud management,” J. Parallel Distrib. Comput., vol. 72, no. 2, pp. 95–105, 2012.

[21] J. Wu, X. Xu, P. Zhang, and C. Liu, “A novel multi-agent reinforcement learning approach for job scheduling in grid computing,” Future Generation Comput. Syst., vol. 27, no. 5, pp. 430–439, 2011.

[22] L. Liu, Z. Wang, and H. Zhang, “Adaptive NN fault-tolerant control for discrete-time systems in triangular forms with actuator fault,” Neurocomput., vol. 152, pp. 209–221, 2015.

[23] A. Forster and A. L. Murphy, “FROMS: A failure tolerant and mobility enabled multicast routing paradigm with reinforcement learning for WSNs,” Ad Hoc Netw., vol. 9, no. 5, pp. 940–965, 2011.

[24] Y.-C. Wang and J. M. Usher, “Application of reinforcement learning for agent-based production scheduling,” Eng. Appl. Artif. Intell., vol. 18, no. 1, pp. 73–82, 2005.

[25] Z. Chen and D. Marculescu, “Distributed reinforcement learning for power limited many-core system performance optimization,” in Proc. Des. Autom. Test Eur. Conf. Exhib., 2015, pp. 1521–1526.

[26] R. Jhawar and V. Piuri, “Chapter 1—Fault tolerance and resilience in cloud computing environments,” in Cyber Security and IT Infrastructure Protection, J. R. Vacca, Ed. Boston, MA, USA: Syngress, 2014, pp. 1–28.

[27] H. Okamura, Y. Nishimura, and T. Dohi, “A dynamic checkpointing scheme based on reinforcement learning,” in Proc. IEEE Pacific Rim Int. Symp. Depend. Comput., Mar. 2004, pp. 151–158.

[28] L. Bautista-Gomez, S. Tsuboi, D. Komatitsch, F. Cappello, N. Maruyama, and S. Matsuoka, “FTI: High performance fault tolerance interface for hybrid systems,” in Proc. ACM/IEEE Int. Conf. High Perform. Comput. Netw. Storage Anal., 2011, pp. 32:132:32.

[29] A. Moody, G. Bronevetsky, K. Mohror, and B. R. D. Supinski, “Design, modeling, and evaluation of a scalable multi-level checkpointing system,” in Proc. ACM/IEEE Int. Conf. High Perform. Comput. Netw. Storage Anal., 2010, pp. 1–11.

[30] S. Di, L. Bautista-Gomez, and F. Cappello, “Optimization of a multilevel checkpoint model with uncertain execution scales,” in Proc. ACM/IEEE Int. Conf. High Perform. Comput. Netw. Storage Anal., 2014, pp. 907–918.

[31] D. Singh, J. Singh, and A. Chhabra, “High availability of clouds: Failover strategies for cloud computing using integrated checkpointing algorithms,” in Proc. Int. Conf. Commun. Syst. Netw. Technol., May 2012, pp. 698–703.

[32] A. J. Oliner, L. Rudolph, and R. K. Sahoo, “Cooperative checkpointing: A robust approach to large-scale systems reliability,” in Proc. ACM Annu. Int. Conf. Supercomput., 2006, pp. 14–23.

[33] S. Di, M. S. Bouguerra, L. Bautista-Gomez, and F. Cappello, “Optimization of multi-level checkpoint model for large scale HPC applications,” in Proc. IEEE Int. Parallel Distrib. Process. Symp., May 2014, pp. 1181–1190.

[34] B. Mohammed, M. Kiran, K. M. Maiyama, M. M. Kamala, and I.-U. Awan, “Failover strategy for fault tolerance in cloud computing environment,” Softw.: Practice Experience, vol. 47, no. 9, pp. 1243–1274, 2017.

[35] I. Jangjaimon and N. F. Tzeng, “Effective cost reduction for elastic clouds under spot instance pricing through adaptive checkpointing,” IEEE Trans. Comput., vol. 64, no. 2, pp. 396–409, Feb. 2015.

[36] J. Zhao, Y. Xiang, T. Lan, H. H. Huang, and S. Subramaniam, “Elastic reliability optimization through peer-to-peer checkpointing in cloud computing,” IEEE Trans. Parallel Distrib. Syst., vol. 28, no. 2, pp. 491–502, Feb. 2017.

[37] M. Amoon, “Adaptive framework for reliable cloud computing environment,” IEEE Access, vol. 4, pp. 9469–9478, 2016.

[38] B. Balasubramanian and V. K. Garg, “Fault tolerance in distributed systems using fused data structures,” IEEE Trans. Parallel Distrib. Syst., vol. 24, no. 4, pp. 701–715, Apr. 2013.

[39] B. Cully, G. Lefebvre, D. Meyer, M. Feeley, N. Hutchinson, and A. Warfield, “Remus: High availability via asynchronous virtual machine replication,” in Proc. USENIX Symp. Netw. Syst. Des. Implementation, 2008, pp. 161–174.

[40] W. Zhao, P. Melliar-Smith, and L. Moser, “Fault tolerance middleware for cloud computing,” in Proc. IEEE Int. Conf. Cloud Comput., Jul. 2010, pp. 67–74.

[41] T. Wood, R. Singh, A. Venkataramani, P. Shenoy, and E. Cecchet, “ZZ and the art of practical BFT execution,” in Proc. ACM EuroSys Conf. Comput. Syst., 2011, pp. 123–138.

[42] M. Castro and B. Liskov, “Practical byzantine fault tolerance and proactive recovery,” ACM Trans. Comput. Syst., vol. 20, no. 4, pp. 398–461, Nov. 2002.

[43] P. Costa, M. Pasin, A. Bessani, and M. Correia, “Byzantine faulttolerant MapReduce: Faults are not just crashes,” in Proc. IEEE Int. Conf. Cloud Comput. Technol. Sci., Nov. 2011, pp. 32–39.

[44] K. Plankensteiner, R. Prodan, and T. Fahringer, “A new fault tolerance heuristic for scientific workflows in highly distributed environments based on resubmission impact,” in Proc. IEEE Int. Conf. e-Sci., Dec. 2009, pp. 313–320.

[45] A. Zhou, S. Wang, C.-H. Hsu, M. H. Kim, and K.-S. Wong, “Network failure-aware redundant virtual machine placement in a cloud data center,” Concurrency Comput.: Practice Experience, vol. 29, no. 24, 2017, Art. no. e4290.

[46] Z. Zheng, T. C. Zhou, M. R. Lyu, and I. King, “Component ranking for fault-tolerant cloud applications,” IEEE Trans. Serv. Comput., vol. 5, no. 4, pp. 540–550, Oct.–Dec. 2012.

[47] R. Jhawar, V. Piuri, and M. Santambrogio, “Fault tolerance management in cloud computing: A system-level perspective,” IEEE Syst. J., vol. 7, no. 2, pp. 288–297, Jun. 2013.

[48] C. Wang, L. Xing, H. Wang, Z. Zhang, and Y. Dai, “Processing time analysis of cloud services with retrying fault-tolerance technique,” in Proc. IEEE Int. Conf. Commun. China, Aug. 2012, pp. 63–67.

[49] G. Ramalingam and K. Vaswani, “Fault tolerance via idempotence,” SIGPLAN Notices, vol. 48, no. 1, pp. 249–262, Jan. 2013.

[50] A. Liu, Q. Li, L. Huang, and M. Xiao, “Facts: A framework for fault-tolerant composition of transactional web services,” IEEE Trans. Serv. Comput., vol. 3, no. 1, pp. 46–59, Jan. 2010.

[51] J. Yu and R. Buyya, “A taxonomy of scientific workflow systems for grid computing,” ACM SIGMOD Rec., vol. 34, no. 3, pp. 4449, Sep. 2005.

[52] I. Hernandez and M. Cole, “Reliable DAG scheduling on grids with rewinding and migration,” in Proc. ICST Int. Conf. Netw. Grid Appl., 2007, pp. 3:1–3:8.

[53] F. Saffre, R. Tateson, J. Halloy, M. Shackleton, and J. L. Deneubourg, “Aggregation dynamics in overlay networks and their implications for self-organized distributed applications,” Comput. J.,vol.52,no. 4, pp. 397–412, Jul. 2009.

[54] M. Randles, D. Lamb, and A. Taleb-Bendiab, “A comparative study into distributed load balancing algorithms for cloud computing,” in Proc. IEEE Int. Conf. Adv. Inf. Netw. Appl. Workshops, Apr. 2010, pp. 551–556.

[55] M. Randles, A. Taleb-Bendiab, and D. Lamb, “Scalable selfgovernance using service communities as ambients,” in Proc. World Conf. Services-I, Jul. 2009, pp. 813–820.

[56] O. Rahmeh, P. Johnson, and A. Taleb-Bendiab, “A dynamic biased random sampling scheme for scalable and reliable grid networks,” INFOCOMP J. Comput. Sci., vol. 7, no. 4, pp. 1–10, 2008.

[57] J. Oberheide, E. Cooke, and F. Jahanian, “CloudAV: N-version antivirus in the network cloud,” in Proc. USENIX Conf. Secur. Symp., 2008, pp. 91–106.

[58] J. Oberheide, K. Veeraraghavan, E. Cooke, J. Flinn, and F. Jahanian, “Virtualized in-cloud security services for mobile devices,” in Proc. ACM Workshop Virtualization Mobile Comput., 2008, pp. 31–35.

[59] K.-L. Peng, C.-Y. Huang, P.-H. Wang, and C.-J. Hsu, “Enhanced N-version programming and recovery block techniques for web service systems,” in Proc. ACM Int. Workshop Innovative Softw. Develop. Methodologies Practices, 2014, pp. 11–20.

[60] A. Avizienis, “The N-version approach to fault-tolerant software,” IEEE Trans. Softw. Eng., vol. 11, no. 12, pp. 1491–1501, Dec. 1985.

[61] P. Hosek and C. Cadar, “VARAN the unbelievable: An efficient N-version execution framework,” in Proc. ACM Int. Conf. Archit. Support Program. Languages Operating Syst., 2015, pp. 339–353.

[62] R. Hanmer, “Software rejuvenation,” in Proc. ACM Conf. Pattern Languages Programs, 2010, pp. 21:1–21:13.

[63] M. Melo, J. Araujo, R. Matos, J. Menezes, and P. Maciel, “Comparative analysis of migration-based rejuvenation schedules on cloud availability,” in Proc. IEEE Int. Conf. Syst. Man Cybern., Oct. 2013, pp. 4110–4115.

[64] F. Xin-Yuan, X. Guo-Zhi, Y. Ren-Dong, Z. Hao, and J. Le-Tian, “Performance analysis of software rejuvenation,” in Proc. Int. Conf. Parallel Distrib. Comput. Appl. Technol., Aug. 2003, pp. 562–566.

[65] R. Angarita, M. Rukoz, M. Manouvrier, and Y. Cardinale, “A knowledge-based approach for self-healing service-oriented applications,” in Proc. ACM Int. Conf. Manage. Digit. EcoSyst., 2016, pp. 1–8.

[66] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,” Comput., vol. 36, no. 1, pp. 41–50, Jan. 2003.

[67] S. Dobson, R. Sterritt, P. Nixon, and M. Hinchey, “Fulfilling the vision of autonomic computing,” Comput., vol. 43, no. 1, pp. 3541, Jan. 2010.

[68] S. George, D. Evans, and L. Davidson, “A biologically inspired programming model for self-healing systems,” in Proc. ACM Workshop Self-Healing Syst., 2002, pp. 102–104.

[69] C. Engelmann, G. Vallee, T. Naughton, and S. Scott, “Proactive fault tolerance using preemptive migration,” in Proc. Euromicro Int. Conf. Parallel Distrib. Netw.-Based Process., Feb. 2009, pp. 252–257.

[70] A. B. Nagarajan, F. Mueller, C. Engelmann, and S. L. Scott, “Proactive fault tolerance for HPC with Xen virtualization,” in Proc. ACM Annu. Int. Conf. Supercomput., 2007, pp. 23–32.

[71] F. Hao, T. V. Lakshman, S. Mukherjee, and H. Song, “Enhancing dynamic cloud-based services using network virtualization,” in Proc. ACM Workshop Virtualized Infrastructure Syst. Archit., 2009, pp. 37–44.

[72] T. Wood, K. K. Ramakrishnan, P. Shenoy, and J. van der Merwe, “CloudNet: Dynamic pooling of cloud resources by live wan migration of virtual machines,” ACM SIGPLAN Notices, vol. 46, no. 7, pp. 121–132, Mar. 2011.

[73] P. Lu, A. Barbalace, and B. Ravindran, “HSG-LM: Hybrid-copy speculative guest OS live migration without hypervisor,” in Proc. ACM Int. Syst. Storage Conf., 2013, pp. 2:1–2:11.

[74] G. Dhiman, G. Marchetti, and T. Rosing, “vGreen: A system for energy-efficient management of virtual machines,” ACM Trans. Des. Autom. Electron. Syst., vol. 16, no. 1, pp. 6:1–6:27, Nov. 2010.

[75] T. Knauth and C. Fetzer, “VeCycle: Recycling VM checkpoints for faster migrations,” in Proc. ACM Annu. Middleware Conf., 2015, pp. 210–221.

[76] J. Li, C. Pu, Y. Chen, V. Talwar, and D. Milojicic, “Improving preemptive scheduling with application-transparent checkpointing in shared clusters,” in Proc. ACM Annu. Middleware Conf., 2015, pp. 222–234.

[77] A. Polze, P. Troger, and F. Salfner, “Timely virtual machine migration for pro-active fault tolerance,” in Proc. IEEE Int. Symp. Object/ Component/Service-Oriented Real-Time Distrib. Comput. Workshops, Mar. 2011, pp. 234–243.

[78] Y. Zhong, J. Xu, Q. Li, H. Zhang, and F. Liu, “Memory state transfer optimization for pre-copy based live VM migration,” in Proc. IEEE Workshop Adv. Res. Technol. Ind. Appl., Sep. 2014, pp. 290–293.

[79] C. H. A. Costa, Y. Park, B. S. Rosenburg, C.-Y. Cher, and K. D. Ryu, “A system software approach to proactive memory-error avoidance,” in Proc. IEEE Int. Conf. High Perform. Comput. Netw. Storage Anal., 2014, pp. 707–718.

[80] A. Gainaru, F. Cappello, M. Snir, and W. Kramer, “Fault prediction under the microscope: A closer look into HPC systems,” in Proc. IEEE Int. Conf. High Perform. Comput. Netw. Storage Anal., 2012, pp. 77:1–77:11.

[81] O. Hannache and M. Batouche, “Probabilistic model for evaluating a proactive fault tolerance approach in the cloud,” in Proc. IEEE Int. Conf. Service Operations Logistics Informat., Nov. 2015, pp. 94–99.

[82] R. Rajachandrasekar, X. Besseron, and D. K. Panda, “Monitoring and predicting hardware failures in HPC clusters with FTBIPMI,” in Proc. IEEE Int. Parallel Distrib. Process. Symp. Workshops PhD Forum, May 2012, pp. 1136–1143.

[83] F. Salfner, M. Lenk, and M. Malek, “A survey of online failure prediction methods,” ACM Comput. Surveys, vol. 42, no. 3, pp. 10:1–10:42, Mar. 2010.

[84] A. Tikotekar, G. Vallee, T. Naughton, S. Scott, and C. Leangsuksun, “Evaluation of fault-tolerant policies using simulation,” in Proc. IEEE Int. Conf. Cluster Comput., Sep. 2007, pp. 303–311.

[85] I. Egwutuoha, S. Chen, D. Levy, and B. Selic, “A fault tolerance framework for high performance computing in cloud,” in Proc. IEEE/ACM Int. Symp. Cluster Cloud Grid Comput., May 2012, pp. 709–710.

[86] T. Tung, S. Y. Chaw, Q. Xie, and Q. Zhu, “Highly resilient systems for cloud,” in Proc. IEEE Int. Conf. Web Serv., Jun. 2012, pp. 678–680.

[87] T. Limoncelli, “Resilience engineering: Learning to embrace failure,” Commun. ACM, vol. 55, no. 11, pp. 40–47, Nov. 2012.

[88] A. Benso and P. Prinetto, Eds., Fault Injection Techniques and Tools for Embedded Systems Reliability Evaluation. Berlin, Germany: Springer, 2003.

[89] H. J. C. Berendsen, D. V. D. Spoel, and R. V. Drunen, “GROMACS: A message-passing parallel molecular dynamics implementation,” Comput. Phys. Commun., vol. 91, pp. 43–56, 1995.

[90] J. Park, H. Yu, K. Chung, and E. Lee, “Markov chain based monitoring service for fault tolerance in mobile cloud computing,” in Proc. IEEE Workshops Int. Conf. Adv. Inf. Netw. Appl., Mar. 2011, pp. 520–525.

[91] C. Colman-Meixner, C. Develder, M. Tornatore, and B. Mukherjee, “A survey on resiliency techniques in cloud computing infrastructures and applications,” IEEE Commun. Surveys Tuts.,vol.18,no.3, pp. 2244–2281, Jul.–Sep. 2016.

[92] H. Li and S. Venugopal, “Using reinforcement learning for controlling an elastic web application hosting platform,” in Proc. ACM Int. Conf. Autonomic Comput., 2011, pp. 205–208.

[93] R. S. Sutton and A. G. Barto, Reinforcement Learning : An Introduction. Cambridge, MA, USA: MIT Press, 1998.

[94] T. G. Dietterich and X. Wang, Support Vectors for Reinforcement Learning. Berlin, Germany: Springer, 2001, pp. 600–600.

[95] Y. Li, “Deep reinforcement learning: An overview,” CoRR, vol. abs/1701.07274, 2017, http://arxiv.org/abs/1701.07274

[96] K. Arulkumaran, M. P. Deisenroth, M. Brundage, and A. A. Bharath, “Deep reinforcement learning: A brief survey,” IEEE Signal Process. Mag., vol. 34, no. 6, pp. 26–38, Nov. 2017, doi: 10.1109/MSP.2017.2743240.

[97] A. Paul and D. P. Mukherjee, “Reinforced random forest,” in Proc. ACM Indian Conf. Comput. Vis. Graph. Image Process., 2016, pp. 1:1–1:8.

[98] P. Domingos, “A few useful things to know about machine learning,” Commun. ACM, vol. 55, no. 10, pp. 78–87, Oct. 2012.

[99] K. M. Sim, “Agent-based cloud computing,” IEEE Trans. Serv. Comput., vol. 5, no. 4, pp. 564–577, Oct.–Dec. 2012.

[100] K. M. SIM, “Agent-based approaches for intelligent intercloud resource allocation,” IEEE Trans. Cloud Comput., vol. PP, no. 99, p. 1, 2016, doi: 10.1109/TCC.2016.2628375.

[101] H. Arabnejad, C. Pahl, P. Jamshidi, and G. Estrada, “A comparison of reinforcement learning techniques for fuzzy cloud autoscaling,” in Proc. IEEE/ACM Int. Symp. Cluster Cloud Grid Comput., May 2017, pp. 64–73.

[102] D. Cui, Z. Peng, X. Jianbin, B. Xu, and W. Lin, “A reinforcement learning-based mixed job scheduler scheme for grid or IaaS cloud,” IEEE Trans. Cloud Comput., vol. PP, no. 99, p. 1, 2017, doi: 10.1109/TCC.2017.2773078.

[103] L. Wang and E. Gelenbe, “Adaptive dispatching of tasks in the cloud,” IEEE Trans. Cloud Comput., vol. 6, no. 1, pp. 33–45, Jan. 2018, doi: 10.1109/TCC.2015.2474406.

[104] A. Dalılia and L. R. Coutinho, “A fault tolerance approach based on reinforcement learning in the context of autonomic opportunistic grids,” in Proc. Int. Conf. Autonomic Auton. Syst., 2014, pp. 11–17.

[105] J. F. Murray, G. F. Hughes, and D. Schuurmans, “Machine learning methods for predicting failures in hard drives: A multipleinstance application,” J. Mach. Learn. Res., vol. 6, 2005, Art. no. 816.

[106] Y. Zhao, X. Liu, S. Gan, and W. Zheng, “Predicting disk failures with HMM- and HSMM-based approaches,” in Proc. Int. Conf. Adv. Data Mining. Appl. Theoretical Aspects, 2010, pp. 390–404.

[107] B. Zhu, G. Wang, X. Liu, D. Hu, S. Lin, and J. Ma, “Proactive drive failure prediction for large scale storage systems,” in Proc. IEEE Symp. Mass Storage Syst. Technol., 2013, pp. 1–5.

[108] Y. Wang, Q. Miao, E. Ma, K.-L. Tsui, and M. Pecht, “Online anomaly detection for hard disk drives based on Mahalanobis distance,” IEEE Trans. Rel., vol. 62, no. 1, pp. 136–145, Mar. 2013.

[109] J. Li, X. Ji, Y. Jia, B. Zhu, G. Wang, Z. Li, and X. Liu, “Hard drive failure prediction using classification and regression trees,” in Proc. IEEE/IFIP Int. Conf. Depend. Syst. Netw., 2014, pp. 383–394.

[110] X. Qin, W. Zhang, W. Wang, J. Wei, H. Zhong, and T. Huang, “On-line cache strategy reconfiguration for elastic caching platform: A machine learning approach,” in Proc. IEEE Annu. Comput. Softw. Appl. Conf., Jul. 2011, pp. 523–534.