CN113220462B - 一种基于边缘计算的集中式故障检测方法 - Google Patents

一种基于边缘计算的集中式故障检测方法 Download PDF

Info

Publication number
CN113220462B
CN113220462B CN202110592022.1A CN202110592022A CN113220462B CN 113220462 B CN113220462 B CN 113220462B CN 202110592022 A CN202110592022 A CN 202110592022A CN 113220462 B CN113220462 B CN 113220462B
Authority
CN
China
Prior art keywords
server
virtual machine
time
packet
data packet
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.)
Active
Application number
CN202110592022.1A
Other languages
English (en)
Other versions
CN113220462A (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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to CN202110592022.1A priority Critical patent/CN113220462B/zh
Publication of CN113220462A publication Critical patent/CN113220462A/zh
Application granted granted Critical
Publication of CN113220462B publication Critical patent/CN113220462B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • 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/45591—Monitoring or debugging support
    • 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

Abstract

本发明提供一种基于边缘计算的集中式故障检测方法，其包括构建分布式计算框架，建立位图机制，获取kick数据包，定期向客户端发送kick数据包，并且客户端将kick数据包从虚拟机VM中继到服务器，服务器通过计数kick数据包监控虚拟机VM的状态，将状态可见性转发到控制平面，并将bite数据包发送到VM管理器，释放因故障而崩溃的虚拟机VM，以回收故障所占用的资源。应用本发明能够及时，远程地检测任务或虚拟机故障的机制，从而快速回收这些故障所占用的资源。

Description

一种基于边缘计算的集中式故障检测方法
技术领域
本发明涉及算力网络技术领域，尤其涉及一种基于边缘计算的集中式故障检测方法。
背景技术
在传统的网络体系结构中，一般使用某些检测方法来实现故障检测，典型的代表是ICMP、BFD、OWAMP和CFM。
ICMP协议通过判断接收方是否可以通过一次ping操作成功反馈其状态来检测故障。虽然ICMP可以用于检测任何设备，但其缺点是只能进行单向故障检测，并且检测频率很低；BFD协议是一种双向检测机制，参与检测的双方都可以通过hello数据包确认对方是否仍在正常运作。BFD侧重于对相距一跳邻居设备的故障发现，而无法处理相距多跳设备的场景；OWAMP是基于TCP连接的网络性能测试协议，它不仅可以检测故障，而且可以高精度地测量网络性能。但是，OWAMP需要基于NTP的时间同步，因此需要更多的控制开销；CFM是基于数据中心方案的连接故障检测协议，它采用定期检测以在更大的范围内维持所有网络的稳定运行。但是CFM过于复杂，不适合CFN场景。
但是，所有这些故障检测方法都仅用于检测网络连接的问题，而不是检测任务执行的状态。因此，它们不能应用于CFN。
随着网络技术的发展，云计算中心取代了传统的数据中心，相关技术也在不断发展，其中包括故障检测。在云计算场景中，典型的故障检测技术是hadoop下的jobtracker或storm下的nimbus。
现有技术一(H.Zhu and H.Chen,“Adaptive failure detection via heartbeatunder Hadoop,”in 2011IEEE Asia-Pacific Services Computing Conference,2011,pp.231–238.)提出了一种通过自适应检测心跳数据包来检测任务是否可以成功完成的解决方案。它通过匹配软件的统计状态和心跳条件的反馈来判断任务的执行是否失败，然后决定采用哪种失败处理策略。但是现有技术一并未考虑网络延迟的影响，这将导致误检率的提高。
现有技术二(M.Soualhia,F.Khomh,and S.Tahar,“ATLAS:an adaptive failure-aware scheduler for Hadoop,”in 2015IEEE 34th International PerformanceComputing and Communications Conference(IPCCC),2015,pp.1–8.)提出了一种基于机器学习的故障检测方法，该方法通过检测节点的心跳反馈来判断运行状态。此外，通过调度方法，故障恢复将有序地执行。
现有技术三(O.Yildiz,S.Ibrahim,T.A.Phuong,and G.Antoniu,“Chronos:Failure-aware scheduling in shared Hadoop clusters,”in 2015IEEE InternationalConference on Big Data(Big Data),2015,pp.313–318.)提出了一种故障感知调度方法，可以避免故障造成的损失。该方法是预先预测任务是否有风险，并在任务失败时立即安排备份以进行替换，从而将故障损失降至最低。但是他们专注于优化故障恢复策略，而不是故障检测。他们的方法在云计算场景中具有一定的影响。但是，CFN场景不同于云计算场景，并且拥有异构计算资源。因此，如果节点没有足够的计算能力来提供备份，则不建议使用此方法。
现有技术四(M.Smara,M.Aliouat,A.-S.K.Pathan,and Z.Aliouat,“Acceptancetest for fault detection in component-based cloud computing and systems,”Futur.Gener.Comput.Syst.,vol.70,pp.74–93,2017.)基于验收测试的思想，设计了大规模云场景中的故障检测机制。基于匹配检测的基本思想，它可以匹配包括软件故障，黑客攻击等在内的不同故障场景，并实现了更直接的检测模型。但是他们没有考虑网络链接的影响。
但是，上述方法专注于检测软件故障，而不是网络连接故障。因此，不能应用于网络链路不稳定，时延波动范围大的CFN场景。
雾计算(A.Scirè,F.Tropeano,A.Anagnostopoulos,and I.Chatzigiannakis,“Fog-computing-based heartbeat detection and arrhythmia classification usingmachine learning,”Algorithms,vol.12,no.2,p.32,2019.)和边缘计算(Y.C.Hu,M.Patel,D.Sabella,N.Sprecher,andV.Young,“Mobile edge computing—Akeytechnology towards 5G,”ETSI white Pap.,vol.11,no.11,pp.1–16,2015.)和(X.SunandN.Ansari,“EdgeIoT:Mobile edge computing for the Internet ofThings,”IEEECommun.Mag.,vol.54,no.12,pp.22–29,2016.)的提出，扩展了云计算的功能并满足应用程序实时性和低延迟的要求。在雾计算中，通常在物联网网关或局域网的节点中处理任务。在边缘计算中，任务直接在边缘设备(例如传感器，智能手机，iPad)上处理。但是它们的两种集中式分配机制都可能导致从发起请求到任务开始处理的持续时间很长。为了解决该问题，算力网络CFN(Y.Li,“draft-li-rtgwg-cfn-framework-00-Framework ofComputeFirst Networking(CFN).”https://tools.ietf.org/html/draft-li-rtgwg-cfn-framework-00(accessed Aug.10,2020).)被提出。作为用于边缘计算的新型分布式计算框架，它采用分布式方式为任务分配计算资源，其可以在本地或远程处理任务。但是，在分布式框架中检测任务或VM故障通常需要很长时间。一方面，CFN现在处于早期阶段，还没有这样的机制来获取本地或远程计算资源的实时状态。另一方面，常规网络中的传统故障检测协议(例如BFD)主要用于检测网络设备的故障，而不是VM故障。Hadoop在云计算中的JobTracker主要用于检测本地任务故障，而不是远程检测。因此，它们不能直接应用于CFN。
算力网络(compute first networking，CFN)是最新的分布式框架，可根据计算负载和网络状态为边缘计算智能地分配计算资源。它要求实时了解本地或远程计算资源的可用状态。
边缘计算是云计算的扩展，一种流行的计算范例，其令计算设备更接近终端用户，旨在为用户提供便捷且快速的计算服务。它通过云中心来进行计算资源分配。如图1(a)所示，每当任务到达一个边缘节点时，该边缘节点就会向云中心发送资源请求。接着，云中心确定应为该任务分配哪种类型的资源(云中心的或边缘的)，并将资源分配的结果响应回复给相关的边缘节点。收到分配响应结果后，请求节点将任务卸载到目标边缘节点。但是，由于边缘和云之间的网络延迟，这种集中式分配机制可能导致从发起请求到任务开始处理所需的时间很长。因此，这实际上违反了边缘计算的设计目标(例如，快速响应)。
近来，算力网络(CFN)被提出，如图1(b)所示，以解决边缘计算中的上述问题。CFN是一种用于计算资源分配的新颖分布式框架，它可以根据计算负载和网络状态将任务动态路由到最佳计算节点。CFN平等对待边缘节点和云节点，并将它们集成到分布式计算资源池中。然后，它引入了一个新的控制平面来管理资源池，以便智能地分配资源，从而满足用户的需求。粗略地说，如果用户的请求是实时任务，则控制平面会综合考虑网络条件和可用的计算资源，智能地向用户分配邻近资源。否则，它将任务卸载到云中心进行处理。
CFN采用分布式框架为任务分配计算资源。它利用众多具有异构计算能力且在地理上分散的边缘/云节点构造一个公共计算资源池。在CFN中，一个任务可能被多个节点本地或远程地处理。这些节点之间网络连接的多样性以及由此带来的网络延迟，以及节点计算能力的巨大差异，使得监控任务的处理状态非常困难。即使我们可以监控状态，在分布式框架中检测任务或虚拟机(VM)故障通常也要花费很长时间[2]–[4]。此处，故障是指当任务或VM的程序抛出运行时异常。另一方面，CFN要求本地或远程计算资源的可用状态应实时可见，以便有效地从计算池分配资源。因此，我们需要一种能够及时，远程地检测任务或虚拟机故障的机制，以快速回收这些故障所占用的资源。
但是，CFN现在处于起步阶段，并且不提供获取本地或远程计算资源实时可用性的机制。IP网络或云计算中流行的故障检测方法也不适用于CFN。例如，IP网络中的双向转发检测协议[5]主要用于检测网络设备的故障，而不是任务或VM的故障。云计算中Hadoop的JobTracker[6]主要用于检测本地任务故障，而不是远程检测。因此，在CFN的分布式框架下，其中任务是在多个节点中本地或远程处理的，它需要一种新颖的远程故障检测设计以及时监控任务和VM的状态。
发明内容
本发明的主要目的是提供一种能够及时，远程地检测任务或虚拟机故障的机制，从而快速回收这些故障所占用的资源的基于边缘计算的集中式故障检测方法。
为了实现上述主要目的，本发明提供的一种基于边缘计算的集中式故障检测方法，包括以下步骤：
构建分布式计算框架，其中，所述分布式计算框架由控制平面和计算资源池组成，控制平面用于将资源分配给任务，计算资源池用于管理边缘/云节点的资源；建立位图机制；获取kick数据包，定期向客户端发送kick数据包，并且客户端将kick数据包从虚拟机VM中继到服务器；服务器通过计数kick数据包监控虚拟机VM的状态，将状态可见性转发到控制平面，并将bite数据包发送到VM管理器，释放因故障而崩溃的虚拟机VM，以回收故障所占用的资源；其中，服务器基于Bitmap机制，根据接收到的kick数据包连续检测故障事件。
进一步的方案中，当虚拟机启动后，客户端将在边缘/云节点的虚拟化管理平台中运行，在客户端将kick数据包从虚拟机VM中继到服务器的过程中，若一个虚拟机VM和相应的客户端被创建，由系统通知服务器开始监控虚拟机VM，并连续向控制平面报告其状态，直到该虚拟机VM被释放。
更进一步的方案中，服务器通过计数kick数据包监控虚拟机VM的状态具体包括：服务器估算从其到托管虚拟机VM的节点的平均网络延迟；服务器根据延迟设置阈值，根据该阈值启动一个计时器，并与该虚拟机VM保持时间同步；服务器执行位图机制，即持续地比较实际接收到的kick数据包和预期kick数据包的数量，以检测虚拟机VM上是否发生故障事件。
更进一步的方案中，若检测到故障事件，服务器将bite数据包发送到VM管理器，以释放该虚拟机VM，其中，bite数据包是释放/关闭VM的管理程序API方法的调用；若收到来自服务器的bite数据包，由VM管理器执行释放/关闭虚拟机VM的命令。
更进一步的方案中，阈值的设置基于服务器与受监控虚拟机VM所在的边缘/云节点之间的网络延迟。
更进一步的方案中，服务器根据延迟设置阈值包括：当创建并启动一个虚拟机VM时，服务器将通过ping数据包计算与该虚拟机VM之间的网络延迟；服务器检查延迟阈值映射表以找到合适的阈值；设置阈值并用于监控VM。可见，为Watchdog服务器设置一个阈值，以防止网络延迟对kick数据包的影响。
更进一步的方案中，建立位图机制包括：由服务器创建一个位图数组，以记录虚拟机VM的状态；对于虚拟机VM的执行时间[0，T)中的每个时间单位，由服务器执行以下两个步骤：构造位图数组；使用滑动窗口w检测故障事件。
进一步的，构造位图数组：若服务器收到在sendTime＝i时刻发出的kick数据包，判断该数据包的接收时间是否在时间[i，i+r]以内，如是，则服务器将位图数组中的第i个元素设置为1，这表示虚拟机VM在时刻i的状态是正常的；若服务器直到时刻i+r都没有收到kick数据包，将位图数组中的ith元素设置为0，这表明虚拟机VM在时刻i时发生了故障事件。
进一步的，使用滑动窗口w检测故障事件：在位图数组中设置了0和1值，并从第i个元素开始，服务器检查w个元素，若在w元素中存在一个0，则服务器检测到虚拟机VM上发生了故障事件；否则，若所有w元素的值为1，则服务器认为虚拟机VM上没有故障事件发生；其中，w个元素表示为从i到i+w-1的元素，i＝0，1，…，T-1。
进一步的，基于用户数据报协议设计kick数据包，其中，payload部分包括以下字段：
kickID：标识kick数据包的唯一ID；
vmID：发送kick数据包的虚拟机VM的唯一标识ID；
nodeID：发送kick数据包的虚拟机VM所在宿主节点的唯一标识ID；
sendTime：虚拟机VM发送kick数据包的时间。
由此可见，本发明提出一种集中式故障检测协议(CFN-Watchdog)，以提供CFN所需的可见性，可以很好地满足CFN的要求并及时回收故障所占用的资源，并显着提高系统吞吐量，有助于边缘计算的参数优化配置和设计更好的故障检测协议。
进一步的，本发明建立理论模型以分析建议的Watchdog协议的性能，考虑重要参数，包括检测阈值，任务处理时间和网络延迟，并刻画对系统吞吐量造成的误报，以及错误事件的漏检。
所以，本发明提出的故障检测协议，是一个在CFN中的集中式任务和VM故障检测协议，可远程监视边缘计算中分布式计算资源的可用状态。在协议中，许多客户端定期向连接到CFN的一个服务器报告其监视虚拟机VM的状态。受益于集中协议的快速响应特点，CFN的控制平面可以实时显示其托管资源状态，并及时回收故障所占用的资源。
附图说明
图1是现有技术一种传统边缘计算和CFN中的资源分配原理图。
图2是本发明一种基于边缘计算的集中式故障检测方法实施例分布式计算框架CFN-Watchdog协议的原理图。
图3是本发明一种基于边缘计算的集中式故障检测方法实施例中建立位图机制的原理图。
图4是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互的原理图。
图5是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互分为8种情况的原理图。
图6是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况1的原理图。
图7是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况3的原理图。
图8是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况2的原理图。
图9是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况4的原理图。
图10是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况5的原理图。
图11是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况6的原理图。
图12是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况7的原理图。
图13是本发明一种基于边缘计算的集中式故障检测方法实施例中服务器与虚拟机VM交互中出现情况8的原理图。
图14是本发明一种基于边缘计算的集中式故障检测方法实施例中T在3到12之间变化时系统吞吐量的原理图。
图15是本发明一种基于边缘计算的集中式故障检测方法实施例中当T在3到12之间变化时，FA，Det，Miss和FAErr的概率变化图。
图16是本发明一种基于边缘计算的集中式故障检测方法实施例中系统吞吐量和平均网络延迟的原理图。
图17是本发明一种基于边缘计算的集中式故障检测方法实施例中normal，FA，Det，Miss和FAErr的概率趋势，平均网络延迟在0.5到5之间变化的原理图。
图18是本发明一种基于边缘计算的集中式故障检测方法实施例中perr在0.001至0.018之间变化时的吞吐量的原理图。
图19是本发明一种基于边缘计算的集中式故障检测方法实施例中当perr从0.001增加到0.018时，FA，Det，Miss和FAErr的概率趋势图。
图20是本发明一种基于边缘计算的集中式故障检测方法实施例中Watchdog服务器的系统吞吐量和阈值的原理图。
以下结合附图及实施例对本发明作进一步说明。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明的监控程序协议是基于主从框架的，主要由两个组件组成：监控程序服务器和监控程序客户端。客户端负责将kick数据包从虚拟机VM中继到服务器。服务器负责监控VM的状态(通过计数kick数据包)，将状态可见性转发到CFN的控制平面，并及时释放因故障而崩溃的VM(通过将bite数据包发送到VM管理器)。然而，边缘计算中的各种网络延迟和网络的复杂环境影响数据包的到达(例如，kick和bite数据包)，可能导致漏检(missdetection)和误检(false alarm)，从而降低系统吞吐量。下面，将详细介绍Watchdog协议，并提出一种位图机制(bitmap mechanism)，并在服务器中引入了阈值设置以解决上述问题。
本发明的一种基于边缘计算的集中式故障检测方法，包括以下步骤：
步骤S1，构建分布式计算框架，其中，所述分布式计算框架由控制平面和计算资源池组成，控制平面用于将资源分配给任务，计算资源池用于管理边缘/云节点的资源。
步骤S2，建立位图机制；
步骤S3，获取kick数据包，定期向客户端发送kick数据包，并且客户端将kick数据包从虚拟机VM中继到服务器；服务器通过计数kick数据包监控虚拟机VM的状态，将状态可见性转发到控制平面，并将bite数据包发送到VM管理器，释放因故障而崩溃的虚拟机VM，以回收故障所占用的资源；
其中，服务器基于Bitmap机制，根据接收到的kick数据包连续检测故障事件。
当虚拟机启动后，客户端将在边缘/云节点的虚拟化管理平台中运行，在客户端将kick数据包从虚拟机VM中继到服务器的过程中，若一个虚拟机VM和相应的客户端被创建，由系统通知服务器开始监控虚拟机VM，并连续向控制平面报告其状态，直到该虚拟机VM被释放。
具体的，本实施例对算力网络(CFN)中边缘节点之间的交互逻辑进行阐述。首先，给出边缘节点中组件的概述。接下来，详细说明它们之间的交互，以分别说明边缘节点中的资源分配和任务处理。
CFN是用于边缘计算的分布式计算框架，由控制平面和统一的计算资源池组成，如图1(b)所示，控制平面负责将资源分配给任务，而计算资源池负责管理边缘/云节点的资源。控制平面由任务代理组件和VM管理器组成，如图2所示。任务代理组件缓冲任务并为任务分配资源。VM管理器创建用于任务处理的VM，并在任务完成或检测到故障后释放VM。此外，资源池由虚拟机VM和IP底层组件组成，如图2所示，并负责资源管理。VM组件包含用于执行任务的多个虚拟机VM；IP底层组件为边缘/云节点之间的通信(例如，卸载任务)提供网络资源。
当任务到达CFN中时，任务代理组件会缓冲任务。然后，任务代理组件提取此任务的资源要求，然后将可用资源查询请求发送到VM管理器。接下来，任务代理组件判断可用资源量是否足以执行任务。如果有足够的可用资源，任务代理组件将处理当前节点中的任务处理请求。否则，任务代理组件会智能地考虑网络条件和可用资源的数量，找到可以执行任务的另一个节点，然后通过IP底层组件将其卸载到目标节点。
对于任务的处理，任务代理组件首先将具有任务资源需求的VM创建请求发送到VM管理器。然后，VM管理器将启动VM，并部署任务。任务完成后，任务代理将收集任务执行的结果。最后，任务代理组件将向VM管理器发送请求，以停止并释放VM。
在本实施例中，服务器通过计数kick数据包监控虚拟机VM的状态具体包括：服务器估算从其到托管虚拟机VM的节点的平均网络延迟；服务器根据延迟设置阈值，根据该阈值启动一个计时器，并与该虚拟机VM保持时间同步；服务器执行位图机制，即持续地比较实际接收到的kick数据包和预期kick数据包的数量，以检测虚拟机VM上是否发生故障事件。
进一步的，若检测到故障事件，服务器将bite数据包发送到VM管理器，以释放该虚拟机VM，其中，bite数据包是释放/关闭VM的管理程序API方法的调用；若收到来自服务器的bite数据包，由VM管理器执行释放/关闭虚拟机VM的命令。
其中，客户端为Watchdog客户端，服务器为Watchdog服务器。
在本实施例中，Watchdog客户端是一个将kick数据包从VM中继到Watchdog服务器的进程。虚拟机VM启动后，它将在边缘/云节点的虚拟化管理平台(hypervisor)中运行。
一旦一个虚拟机VM和相应的Watchdog客户端被创建，系统就通知Watchdog服务器开始监控VM，并连续向CFN的控制平面报告其状态，直到该VM被释放。首先，服务器估算从其到托管VM的节点的平均网络延迟(例如，通过ping数据包)。其次，服务器根据延迟设置阈值r，以避免误报(即false alarm)。然后，服务器执行位图机制，即持续地比较实际接收到的kick数据包和预期kick数据包的数量，以检测VM上是否发生故障事件。一旦检测到故障事件，服务器就会将bite数据包发送到VM管理器，以释放该VM。这里，bite数据包是释放/关闭VM的管理程序API(应用程序编程接口)方法的调用。
一旦收到来自Watchdog服务器的bite数据包，VM管理器就会执行释放/关闭VM的命令。
在本实施例中，阈值的设置基于服务器与受监控虚拟机VM所在的边缘/云节点之间的网络延迟。
具体的，服务器根据延迟设置阈值包括：当创建并启动一个虚拟机VM时，服务器将通过ping数据包计算与该虚拟机VM之间的网络延迟；服务器检查延迟阈值映射表以找到合适的阈值；设置阈值并用于监控VM。可见，为Watchdog服务器设置一个阈值，以防止网络延迟对kick数据包的影响。
在本实施例中，阈值用于避免误报(false alarm)问题。引入阈值设置的原因解释如下：边缘/云环境中的网络延迟在很大范围内变化，这会影响kick数据包的到达时间(比如，kick数据包可能无法及时到达)。在这种情况下，Watchdog服务器将错误地判断有故障事件发生(即，故障事件的误报)。因此，需要为Watchdog服务器设置一个阈值，以防止网络延迟对kick数据包的影响。
阈值的设置基于Watchdog服务器与受监控VM所在的边缘/云节点之间的网络延迟。首先，当创建并启动一个VM时，Watchdog服务器将通过ping数据包估计与该VM之间的网络延迟。其次，服务器将检查延迟阈值映射表以找到合适的阈值(该表可以手动维护，也可以使用机器学习方法维护)。第三，设置阈值并用于监控VM。
在本实施例中，建立位图机制包括：由服务器创建一个位图数组，以记录虚拟机VM的状态；对于虚拟机VM的执行时间[0，T)中的每个时间单位，由服务器执行以下两个步骤：
构造位图数组：若服务器收到在sendTime＝i时刻发出的kick数据包，判断该数据包的接收时间是否在时间[i，i+r]以内，如是，则服务器将位图数组中的第i个元素设置为1，这表示虚拟机VM在时刻i的状态是正常的；若服务器直到时刻i+r都没有收到kick数据包，将位图数组中的ith元素设置为0，这表明虚拟机VM在时刻i时发生了故障事件。
使用滑动窗口w检测故障事件：在位图数组中设置了0和1值，并从第i个元素开始，服务器检查w个元素，若在w元素中存在一个0，则服务器检测到虚拟机VM上发生了故障事件；否则，若所有w元素的值为1，则服务器认为虚拟机VM上没有故障事件发生；其中，w个元素表示为从i到i+w-1的元素，i＝0,1,…,T-1。
位图(bitmap)机制用于根据接收到的kick数据包连续检测故障事件，能够减少由于网络延迟或传输错误而导致的误检(false alarm)。当需要监控一个执行任务的虚拟机VM时，Watchdog服务器首先根据一个阈值r启动一个计时器，并与该VM保持时间同步。然后，该服务器创建一个位图数组(bitmap array)以记录VM的状态。此后，对于VM的执行时间[0，T)中的每个时间单位，Watchdog服务器执行以下两个阶段。
构造位图(bitmap)数组：在构造位图(bitmap)数组时，Watchdog服务器可能会收到在sendTime＝i时刻发出的kick数据包。如果该kick数据包的接收时间在时间[i，i+r]以内，则服务器会将位图数组中的第i个元素设置为1，这表示VM在时刻i的状态是正常的。相反，如果服务器直到时刻i+r都没有收到kick数据包，它将把位图数组中的ith元素设置为0，这表明在时刻i时，VM上发生了故障事件。如图3所示，假设阈值r的值设置为2，Watchdog服务器在时刻2之后收到在时刻0发出的kick数据包，以及在时间[1,3]内接收到了在时刻1发出的kick数据包。因此，位图数组的第0个元素为0，而位图数组的第1个元素为1。
使用滑动窗口w检测故障事件：位图数组中设置了0和1值并从第i个元素开始，Watchdog服务器检查w个元素(即，从i到i+w-1的元素)，其中i＝0,1,…,T-1。如果在w元素中存在一个0，则Watchdog服务器检测到VM上发生了故障事件；否则，如果所有w元素的值为1，则Watchdog服务器认为VM上没有故障事件发生。在本实施例中，为简单起见，让滑动窗口大小等于阈值，即w＝r。如图3所示，假设边缘节点中的VM在持续T时间内执行任务，并且位图的第0个元素和第1个元素的值分别为0和1，并且滑动窗口w的值设置为2。由于在前两个元素中存在0，Watchdog服务器判断VM遇到了故障。但是，如果将第0个元素设置为1，则Watchdog服务器会认为VM正在正常运行。
进一步的，为了在CFN中支持所提的Watchdog协议，VM需要添加新功能以通过kick数据包报告其状态。在VM的生命周期中，它会定期将kick数据包发送到Watchdog客户端。此处，基于用户数据报协议(User Datagram Protocol，UDP)设计kick数据包，从而无需接收相应的确认数据包，降低了通信成本，因此适合边缘节点。其payload部分包括以下字段：
基于用户数据报协议设计kick数据包，其中，payload部分包括以下字段：
kickID：标识kick数据包的唯一ID；
vmID：发送kick数据包的虚拟机VM的唯一标识ID；
nodeID：发送kick数据包的虚拟机VM所在宿主节点的唯一标识ID；
sendTime：虚拟机VM发送kick数据包的时间。
在实际应用中，每当任务到达时，系统都会为该任务创建一个VM，然后以T个时间单位正常处理它，并在完成后最终释放VM。此外，任务的数量是无限的，且系统按顺序处理任务。为简单起见，忽略VM创建和发布的时间。Watchdog服务器与VM保持完美的时间同步，以监控VM的状态。
对于VM，如果它可以正常运行以处理任务，它将在时刻0,1,…,T-1向监控程序发送一个kick数据包，其中包括一个时间戳和一个序列号。但是，一旦VM出现错误，它将不会发送kick数据包。在此，设置每次发生VM故障(或错误)的概率为perr。
对于Watchdog服务器，它将在每次i＝0,1,…,T-1时启动阈值为r(0<r<T)的计时器，以等待kick数据包到达。假设Watchdog服务器在时刻i安装了一个计时器。如果在[i,i+r]期间收到预期的kick数据包，则表明VM正常运行。否则，它推断出VM出了问题，因此立即将bite数据包发送到VM管理器，然后释放该任务占用的资源。Watchdog服务器只发送一次bite数据包。
其中，kick或bite数据包的网络延迟遵循指数分布。
在本实施例中，考虑一个虚拟机VM，定义以下变量，如图4所示：
ξ：虚拟机的状态，其中ξ＝0表示虚拟机正常运行，ξ＝1表示虚拟机出故障。
Xi：第i个(0≤i≤T-1)kick数据包的网络延迟，即从VM在时间i发送kick数据包的时刻至该kick数据包到达Watchdog的时间段。图4给出了X0的示例。假设Xi遵循带参数λ的指数分布，即其概率函数由以下公式给出，如公式(1)：
g(x)＝ λe-λx，x≥0. (1)
Yi：第i个(0≤i≤T-r)bite数据包的网络延迟，即从Watchdog在时刻i+r发出bite数据包的那一刻起到该bite数据包到达VM管理器时刻的时间。在这里，Watchdog发送bite数据包的原因是：由于虚拟机错误或网络延迟，Watchdog没有收到预期的应该在时刻i发出的kick数据包，因此在r时间单位后触发了一个bite数据包。图4给出了Y1的示例。假设Yi也遵循带参数λ的指数分布，即其概率函数由g(x)＝λe-λx,x≥0给出。
f(y；b)：截断的指数分布的概率密度函数(PDF)，即取值在0到b之间的指数随机变量的PDF。即表示为公式(2)：
然后根据VM是否出错(ξ＝0)，kick数据包超时是否发生(Xi>r)以及bite数据包超时是否发生，将所有VM和Watchdog交互分为8种情，如图5所示
在分析每种情况下发生的概率以及VM在每种情况下消耗的时间之前，定义以下事件。
Ai：第i个kick数据包超时。
第i个kick数据包不超时。
Bi：第i个bite数据包超时，而第j个(j＝0,…,i-1)bite数据包不发送。
第i个bite数据包不超时，而第j个(j＝0,…,i-1)bite数据包不发送
通常，VM在时刻0开始执行任务，并在时刻T完成任务，此后将释放VM的资源。但是，该期间可能会发生任务或VM故障，因此Watchdog服务器可能会与Watchdog客户端进行通信，以监控任务处理或VM的状态。令表示时刻i(i＝0,1,…,T-1)发生任务或VM故障(或错误)的概率，并令Psuc表示在VM执行期间没有故障的概率。请注意，每个时刻都会以概率perr发生VM故障(或错误)。然后有/>和Psuc，如公式(3)、(4)所示：
Psuc＝(1-perr)T (4)
现在，详细阐述在本实施例出现的所有8种情况。
情况1和情况3：
在这两种情况下(如图5所示)，VM正常运行，并且正常事件(normal event)的发生使得VM由于未收到任何bite数据包，从而成功完成了任务。未收到任何bite数据包的情况有两种：1)无bite数据包发送，对应情况1；
2)bite数据包超时，对应于情况3。
情况1：无bite数据包发送。
有两种因素导致无bite数据包发送：一种是任何kick数据包都没有超时；另一种是第i个踢包有超时，但i等于或大于T-r，即i≥T-r。图6给出了该两种因素导致正常事件发生的示例。
在图6(a)中，假设VM每次从0到T-1发送kick数据包，并且它们均未超时。因此，它们中的任何一个kick数据包都不会触发Watchdog发送bite数据包，并且VM将成功完成任务。
在图6(b)中，假设VM发送第i个kick数据包，其中i＝T-r并且该kick数据包超时，这应该触发了Watchdog在阈值r单位时间后，即时刻T，发送bite数据包。但是，在时刻T及之后，VM结束并且Watchdog停止发送任何bite数据包。因此，无任何bite数据包发出以中止VM，这将导致任务成功执行。
情况3：bite数据包超时。
在这种情况下，正常事件(normal event)是因bite数据包超时而发生的。图7给出了情况3的正常事件的示例，该例子中由于第i个bite数据包的超时，Watchdog无法中止正常运行的VM，从而使得任务能够成功执行。假设VM在时刻i发送第i个kick数据包，并且该数据包超时。然后，在阈值r之后，Watchdog在[i,i+r]期间未收到预期的第i个kick数据包，因此发送第i个bite数据包尝试中止正常运行的VM。但是，该bite数据包超时，因此Watchdog无法中止VM，从而导致任务成功执行。
令Pnor表示正常事件发生的概率，可以通过以下公式(5)计算：
Pnor＝1–Pfa (5)
其中，Pfa可在情况2的末尾计算得到，并且能够通过此公式计算Pnor的原因是当没有错误发生时，只有正常事件(normal event)或误报(false alarm)事件会发生。
令Tnor表示VM的平均占用时间，即从VM开始执行任务到VM成功完成任务的时间间隔。因此，很明显Tnor＝T。
情况2：
在这种情况下(如图5所示)，VM正常运行，但是误报(false alarm)事件的发生错误地中止了正常运行的VM的执行。假设VM发送第i个kick数据包(即，在时刻i发出的kick数据包)，且由于网络延迟该数据包发生超时(即，kick数据包未能在[i,i+r]时间内到达)。此超时将导致Watchdog发送bite数据包，并且该bite数据包会及时到达VM管理器，从而错误地中止了正常运行的VM。
图8给出了情况2的示例，其中当Watchdog由于第i个kick数据包超时而错误地中止了正常运行的VM时，即误报事件发生。
令表示由于第i个kick数据包超时而导致错误报警的概率。请注意，/>是在VM正常运行的情况下的概率。
令表示VM的平均占用时间，即从VM开始执行任务到VM因异常警报而异常中止的时间间隔，该终止是由第i个kick数据包的超时触发的。请注意，/>是VM正常运行的条件下的平均值(即，等式(4)给出的概率Psuc)。
当然，kick或bite数据包的网络延迟具有概率密度函数g(x)，并注意Ai,Bi,的物理意义。现在，准备计算/>和/>
i＝0时的计算。首先计算注意A0表示第0个kick数据包超时(即X0>r)，/>表示第0个kick数据包未超时(即0+r≤0+r+Y0≤T)。当且仅当A0和/>发生时，误报事件才会因A0而发生。因此，可以如下公式(6)计算/>
然后，计算如果VM由于第0个kick数据包超时而中止，Watchdog首先等待r时间单位(其中r表示阈值)，然后发送第0个bite数据包。只要在[r,T]期间此bite数据包到达VM管理器，该管理器就会中止正常执行VM。令Y0表示该bite数据包的网络延迟，并令b0＝T-r。然后，可以按如下公式(7)计算/>/>
其中，随机变量Y0|0≤Y0≤b0遵循截断的指数分布，并且具有概率密度函数f(y0；b0)，其中b0＝T-r和f(·；·)由等式(2)给出。因此，有公式(8)：
1≤i≤T-r-1时的计算：首先计算误报事件是由于第i个kick数据包的超时而引起的。当且仅当第0到第i-1个kick数据包未超时，而第i个kick数据包超时，且第i个bite数据包未超时。根据/>相同的推导逻辑，可以如下公式(9)计算/>
接下来，计算在VM由于第i个kick包超时而中止的情况下，Watchdog在时刻i+r之后发送第i个bite数据包。只要在[i+r,T]期间此bite数据包到达VM管理器，该管理器就会中止正常执行的VM。遵循/>的相同推导，可以如下公式(10)计算/>
/>
T-r≤i≤T-1时的计算：在T-r≤i≤T-1时，误报可能会(由于第i个kick数据包的超时)可能触发Watchdog仅在时刻T或更晚的时刻发送bite数据包，因为采用了r的阈值(例如，假设kick数据包在时刻T-r发送，那么如果在[T-r,T]期间未收到该kick数据包，Watchdog仅可能在时刻T发送bite数据包)，然而在时刻T，VM将结束任务的处理，并且Watchdog将停止发送任何bite数据包。因此，有
然后，通过以下公式(11)计算Pfa：
因此，正常(normal)事件发生的概率Pnor可以表示为公式(12)：
情况4：
在这种情况下(如图5所示)，虚拟机在运行时会遇到故障(或错误)，并且检测事件(detection event)的发生能够中止该故障的虚拟机以释放其占用的资源。假设在时刻i，VM发生了故障，原本它应该在此时发送第i个kick数据包，然而由于故障导致它未能发送，因此Watchdog在[i,i+r]期间无法接收该kick数据包，从而发送了一个bite数据包，该包及时到达VM管理器并释放VM。图9给出了情况4的示例，其中当Watchdog在i时刻成功检测到VM错误并在VM结束之前释放占用的资源时，此时检测事件发生。
令为在VM结束之前Watchdog能够成功释放时刻i发生故障的VM的概率。
令为故障VM占用资源的平均时间，即从VM开始执行任务到VM管理器收到来自Watchdog的bite数据包并释放故障VM的时间间隔。
当然，kick或bite数据包的网络延迟具有概率密度函数g(x)，并且每次都会以概率perr发生VM故障(或错误)，并留意Ai,Bi,/>的含义。
然后，准备计算和/>
i＝0时进行计算：首先计算注意/>表示第0个bite数据包未超时(即0+r≤0+r+Y0≤T)。由于错误是在时刻0发生的，无任何kick数据包发出。因此，当且仅当/>发生时，才会发生检测事件。并且/>可以按如下公式(13)计算：
/>
其中，可以使用公式(3)计算。
然后，计算如果Watchdog发送第0个bite数据包以释放在时刻0出错的VM。只要第0个bite数据包在VM结束之前到达VM管理器(即[r,T])，则可以释放VM占用的资源以供其他使用。令Y0表示第0个bite数据包的网络延迟，令b0＝T-r。然后，按照/>的相同推论，可以按如下公式(14)计算/>
其中，Y0|0≤Y0≤b0是截断的指数分布的随机变量，并且具有f(y0；b0)的概率密度函数，由公式(2)给出。
0<i≤T-r-1时的计算：接下来，计算检测事件的发生是由于在时刻i，VM发生了故障，并且故障VM可以被及时释放。当且仅当第0个到第i-1个kick数据包0未超时(即)，并且第i个bite数据包(因为在[i,i+r]期间无法收到时刻i的kick数据包)没有超时(即/>)。遵循/>的相同推论，可以如下公式(15)计算/>
其中，由公式(3)给出。
接下来，计算在这种情况下，可以释放在时刻i发生故障的VM，其中Watchdog在时刻i+r之后发送第i个bite数据包。只要该bite数据包在T之前及时到达，就可以释放故障VM占用的资源。令bi＝T-r-i。然后，按照/>的相同推导，可以按如下公式(16)计算/>
/>
T-r≤i≤T-1时的计算。在这种情况下，检测事件(因在时刻i的VM错误)只会触发Watchdog在时刻T或更晚的时刻发出第i个bite数据包(即第T个bite数据包)。但是，在时刻T时，VM将终止，并且Watchdog将停止发送任何bite数据包(即，不会有第T个和之后的bite数据包发出)。因此，有
情况5：
在这种情况下(如图5所示)，VM在其运行期间的时刻i发生故障(或错误)，但是漏检事件(miss detection event)的发生使得Watchdog因第i个bite数据包超时而无法释放VM。假设在时刻i发生VM故障，该时刻VM本应该发送第i个kick数据包却因故障未能发出，其中第0个到第i-1个kick数据包未超时，以及第i个bite数据包超时(由于在[i,i+r]期间没有收到第i个kick数据包)。结果，导致在故障VM结束之前Watchdog无法释放该VM。图10给出了情况5的示例，即在时刻i发生VM故障时，由于第i个bite数据包的超时而发生漏检事件。
令表示在时间i发生错误时由于第i个bite数据包超时导致的漏检概率。注意，在这种情况下，当且仅当在时刻i上的错误可以触发第i个bite数据包发出并且该bite数据包超时，才会发生漏检事件。也就是说，由于时刻i的错误而在阈值r之后触发第i个bite数据包的时刻必须在时刻T-1或更早(即i+r≤T-1)。因此，可以获得在这种情况下，错误时刻的上限0≤i≤T-r-1，并计算/>
令表示VM的占用时间。由于漏检是Watchdog未能在VM结束之前释放该故障VM的事件，/>等于在VM上执行任务的时间T。因此，对于所有i，有/>
当然，kick或bite数据包的网络延迟具有概率密度函数g(x)，并且每次发生VM故障(或错误)的概率都是perr。现在，计算
i＝0时进行计算。首先计算请注意，B0表示由于网络延迟(即r+Y0>T)导致第0个bite数据包超时。由于错误在时刻0发生，无任何kick数据包发出。因此，当且仅当发生B0，才会发生漏检事件。则/>可以按如下公式(17)进行计算。
其中，可以由公式(3)计算。/>
0<i≤T-r-1时的计算。接下来，计算当在时刻i发生VM故障时，当且仅当第0个至第i-1个kick数据包未超时的情况下(即/>)，由于第i个bite数据包超时(即Bi)而发生漏检事件。按照与/>的推导，可以按如下公式(18)计算/>
其中，由等式(3)给出。
情况6：
在这种情况下(如图5所示)，VM在运行期间的时刻i＝T-r,T-r+1,…,T-1遇到故障(或错误)。漏检事件的发生会使Watchdog由于未发出任何bite数据包而无法释放故障的VM。假设VM在时刻0至时刻i-1均发出kick数据包，但在时刻i发生故障，其中i+r＝T，并且所有kick数据包均未超时。在这种情况下，Watchdog只能在时刻T发送第i个bite数据包。但是，根据CFN-watchdog的机制，在时刻T或其后的时刻，VM结束并且Watchdog停止发送任何bite数据包。图11给出了情况6的示例，在T-r或更晚的时间发生故障时，由于未发送任何bite数据包而发生漏检事件。
令表示由于未发送bite数据包而导致漏检事件发生的概率，其中T-r≤i≤T-1。
令表示VM的占用时间。与情况5的原因相同，有/>
当然，VM故障在每个i时刻都以perr的概率发生，并且kick数据包的网络延迟遵循指数分布，请注意的含义。在这种情况下，当且仅第0至第T-r-1个kick数据包均未超时(即/>时)，并且故障发生在时间T-r或T-r+1，...或T-1，才会发生漏检事件。现在，准备计算/>如公式(19)：/>
其中，T-r≤i≤T-1和由公式(3)给出。
情况7：
在这种情况下(如图5所示)，VM在时刻i遇到故障(或错误)，但由于发出的kick数据包超时，误报(false alarm)事件的发生在VM结束之前终止了VM的运作，该终止操作是由于故障发生时刻i之前的kick数据包超时导致的，而非因检测到时刻i发生的故障而终止的。假设在时刻i发生错误，VM发送的第i-1个kick数据包超时，这会触发Watchdog发送第i-1个bite数据包(即，Watchdog在[i-1,i-1+r]期间未收到第(i-1)个kick数据包)，而且该bite数据包未超时，因此释放了VM。图12给出了情况7的示例，该例子中发生了虚假警报(false alarm)事件，当发生VM错误时，由于第(i-1)个kick数据包超时，Watchdog将其释放而不是因为时刻i的错误。
令表示误报概率，即在时刻i发生错误时，由于在时间之前发送的任意kick数据包超时而释放了VM不是时刻i的错误，即第j个kick数据包，其中j＝0,1,…,i-1。请注意，当i＝0时，导致VM释放的原因只能是检测事件(detection event)。因此，这种情况的i下限是1，即i≥1。
令表示VM的平均占用时间，即从VM开始执行任务到故障VM被一个bite数据包释放的时间间隔，此释放由在错误时刻i之前发送的第j个kick数据包的超时触发的，其中j＝0,1,…,i-1。
当然，kick或bite数据包的网络延迟具有g(x)的概率密度函数，并留意Ai,Bi,的含义。现在，计算/>和/>
在计算之前，需要考虑与情况2相同的推论，将所有j分3种情况，即j＝0,1≤j≤T-r-1和T-r≤j≤T-1。当j＝0时，概率为/>因为仅第0个kick数据包发出。当1≤j≤T-r-1时，第0到第j-1个kick数据包均未超时，第j个kick数据包超时，因此概率为当T-r≤j≤T-1时，第j个kick数据包超时仅可能在时刻T及以后触发第j个bite数据包，然而在T或更晚的时刻，VM和Watchdog将结束，因此实际上不会发出任何bite数据包。因此，可以按以下方式计算/>
j＝0时的计算，如公式(20)。
1≤j≤T-r-1时的计算，如公式(201)：
T-r≤j≤T-1时的计算，如公式(21)：
然后，计算由于在错误时间i之前发送的任意kick数据包(即第j个kick数据包，其中j＝0,1,…,i-1)的超时导致故障VM被释放。因此，对于每个j，存在VM的平均时间占用时间，/>遵循/>的相同推导，可以按如下公式计算/>
0≤j≤T-r-1时的计算，如公式(22)。
T-r≤j≤T-1时的计算，如公式(23)。
情况4：
在这种情况下(如图5所示)，VM在时刻i遇到故障(或错误)，但是漏检事件的发生使得Watchdog由于以下原因未能释放VM：时间i之前的任意kick数据包的超时(即第j个kick数据包，0≤j≤i-1)以及相应的bite数据包超时(即第j个bite数据包)。假设在时刻i发生故障，VM发送第i-1个kick数据包，并且该kick数据包超时(即，Watchdog在[i-1,i-1+r]期间未收到该kick数据包)，触发Watchdog发送第i-1个bite数据包，但是该bite数据包超时，这将导致VM释放的失败。图13给出了情况8的示例，其中由于第(i-1)个kick数据包超时和第(i-1)个bite数据包超时，Watchdog未能释放在时刻i发生错误的VM。
令表示由于在错误时刻i之前发送的任意kick数据包的超时以及相应的bite数据包的超时而导致的漏检事件发生的概率。注意，可以触发bite数据包的条件与情况5相同(即，发出bite数据包的瑟吉欧了应该在时刻T-1或更早)。唯一的区别是bite数据包是由在时刻i之前发送的任意kick数据包的超时触发的(而不是由时刻i的故障引起)。因此，＝可以获得误差时间的上限i-1+r≤T-1，即i≤T-r。注意，当i＝0时，无任何kick数据包发出。在这种情况下，这不满足漏检事件的定义。因此，可以获得下限i≥1。
令表示在这种情况下VM的占用时间。与情况5的原因相同，
当然，kick数据包或bite数据包的网络延迟遵循指数分布，其概率密度函数为g(x)，并且每个时刻发生VM故障的概率为perr。请注意Ai和/>的含义。现在，计算/>
i＝1时进行计算。首先计算注意A0表示第0个kick数据包超时(即X0>r)，B0表示第0个bite数据包超时(即0+r+Y0>T)。仅当A0和B0都发生时，才会发生漏检事件。因此，可以如下公式(24)计算/>
其中可以通过等式(3)计算。
1<i≤T-r时进行计算。接下来，计算注意，/>是由于在错误时刻i之前发送的任意kick数据包超时和相应的bite数据包超时而导致的漏检事件的概率。需要对由于第j个kick包超时而触发的第j个bite数据包的超时发生的概率进行汇总，其中j＝0,1,…,i-1。当j＝0时，概率为P(A0∩B0)，因为仅发出了第0个kick数据包。当j≥1时，第0到j-1个kick数据包均未超时，第j个kick数据包超时，因此概率为/> 因此，可以如下公式(25)计算/>
其中，1<i≤T-r和由公式(3)给出。这里，/>可以通过以下公式(26)计算。
然后，可以计算系统吞吐量Thg，如公式(27)：
其中，分子表示虚拟机成功执行任务的平均时间；分母表示VM处理任务的平均时间，即从VM开始处理任务的时刻到VM结束处理任务的时刻的平均时间。分母包括没有错误发生时(即ξ＝0)VM处理任务的平均时间M和故障发生时(即ξ＝1)VM处理任务的平均时间N。
这里，M表示为公式(28)：
其中，情况1和情况3中详细说明了Pnor和Tnor，在情况2中说明了和/>而Psuc由公式(4)给出。
N表示为公式(29)：
其中，情况4说明了和/> 和/>分为3个子情况，分别在情况5，情况6和情况8中进行了详细说明；/>和/>在情况7中有详细介绍；/>由等式(3)给出。请注意，对于/>从1开始，是因为当i＝0(即，在时间0发生故障)时，这是一个检测事件，而不是一个误报事件。
在本实施例中，将进行广泛的仿真，以评估CFN-Watchdog设计的有效性和理论模型的准确性。
令T表示成功执行任务的时间，令表示平均网络延迟，令perr表示每次发生VM错误的概率。令Prob-Normal表示VM正常完成任务的概率，让Prob-FA表示没有错误时(即情况2)的误报(false alarm)的概率，让Prob-Det表示情况4的成功检测(detection)的概率。Prob-Miss表示情况5、6和8漏检(miss detection)的概率，而Prob-FAErr表示发生错误时的误报(false alarm)的概率(即情况7)。下面，展示了系统参数(即T，/>和perr)如何影响系统吞吐量Thg，Prob-FA，Prob-Det，Prob-Miss和Prob-FAErr。表1显示了每个仿真实验的参数设置。在这里，利用“a:b:c”模式表示参数值从a到c随着步长b的增加而增加。例如，“1:1:10”表示将参数值从1增加到10，步长为1，如表(1)。
表1.Parameter settings.
/>
图14和图15使用Table 1的设置(a)绘制了系统吞吐量和normal，FA，Det，Miss和FAErr的概率趋势图。在此仿真中，将平均网络延迟的值设置为2，错误概率perr的值设置为0.1，而Watchdog的阈值r设置为2，但是从3到12改变任务的执行时间T。
图14绘制了T在3到12之间变化时系统仿真和理论分析的吞吐量(分别由红线和黑线表示)。从该图可以看出，吞吐量随着T增加。原因如下：一方面，当将perr设置为0.1时，随着T的增加，VM上发生错误的可能性也会增加。另一方面，如果T较长，则等于Watchdog阈值的固定平均网络延迟将导致FA和FAErr的概率更高，从而中止正常运行的VM，从而降低吞吐量。
图15绘制了当T在3到12之间变化时，FA，Det，Miss和FAErr的概率变化图。从此图中，有以下观察结果。
随着T增加，normal概率降低。这是由于FA和FAErr的增加以及T增加的高概率，这意味着FA和FAErr事件都占用了整个系统运行的时间。
FA的概率先缓慢增加然后降低，而FAErr的概率随着T的增加而急剧增加。原因可以解释如下：当错误概率设置为0.1时，随着T的增加，在任务执行过程中任何时间都不会发生错误的概率将迅速下降。结果，FA的机率首先缓慢增加到最大值，然后降低，因为没有遇到错误的VM数量迅速变小。但是，将错误概率设置为0.1时，发生错误的概率几乎不会降低，并且遇到错误的VM的数量也不会改变太多。因此，FAErr的概率迅速增加。
随着T的增加，Det的概率增加而Miss的概率减小。这是因为平均网络延迟越接近CFN-Watchdog阈值，越容易出现kick数据包的网络延迟超过阈值的情况。因此，更容易触发bite数据包的发送。T越长，bite数据包就越有机会到达VM，这导致Det的概率增加而Miss的概率降低。
在表(1)的设置(b)下，图16和图17展示了系统吞吐量和normal，FA，Det，Miss和FAErr的概率。将平均网络延迟的值从0.5变化到5，同时将其余参数的每个参数保持为固定值。
图16显示系统吞吐量首先下降到最小值，然后随着平均网络延迟从0.5到5的变化而缓慢增加。下降的主要原因是FA和FAErr的概率都增加了，而FA和FAErr的可能性都增加了。增加的是两个概率均缓慢下降。这意味着FA和FAErr事件占据整个系统运行时间的时间首先增加，然后缓慢减少。
图17分别显示了normal，FA，Det，Miss和FAErr的概率趋势，平均网络延迟在0.5到5之间变化。在此图中，有以下结果。
FA和FAErr的概率均先增加，然后以的增加而降低。当平均网络延迟小于并接近阈值时，kick数据包发生超时的概率增加，这使得bite数据包的触发变得更加容易。因此，FA和FAErr的概率都首先增加。当平均网络延迟大于阈值时，即使kick数据包超时的概率较高，但bite包时发生超时的概率也较高，这降低了FA和FAErr的概率。
normal的概率先降低，然后随着的增加而缓慢增加。原因是使用固定的perr且没有错误发生时，将发生误报事件或正常事件。因此，法线的概率趋势与FA的趋势相反，FA的趋势的原因已在上面说明。
随着的增加，Det的概率降低，而Miss的概率增加。这是因为当平均网络延迟变大时，bite数据包将具有更高的网络延迟。这意味着bite数据包将晚于时间T到达VM管理器。因此，当/>增大时，检测事件发生的概率就会降低，而丢失检测事件的发生概率会更高
图18和图19绘制了normal，FA，Det，Miss和FAErr的吞吐量和概率。通过在表1中的设置(c)进行仿真和理论计算来获得这些结果。在此仿真中，设置参数T，和r，但将perr的范围从0.001变化到0.018，采用的值要比之前的实验要小得多。
图18绘制了perr在0.001至0.018之间变化时的吞吐量图。从图中可以看出，吞吐量随着perr的增加而降低。原因可以解释如下：一方面，由于每次发生VM错误的概率非常小，因此Det，Miss和FAErr的概率非常小。但是，随着perr的增加，由于接近T的高平均网络延迟导致Miss的概率增加，从而导致吞吐量下降。另一方面，当平均网络延迟/>等于阈值r时，发生虚假警报事件，这也降低了吞吐量。
图19显示了当perr从0.001增加到0.018时，FA，Det，Miss和FAErr的概率趋势。从此图，得到以下观察结果。
随着perr的增加，FA的概率会缓慢下降，因为随着perr的增加，VM上没有错误发生的概率会降低。
当perr减小时，漏检的概率增加。这是因为VM的执行过程中发生错误的概率随perr的增加以及与T和阈值r接近的平均网络延迟而增加，使得bite数据包的超时更容易发生。
Det和FAErr的概率相对较小，因为此仿真实验中采用的perr非常小。并且随着perr的增加，概率不断增加，因为发生错误的概率也随之增加。
图20绘制了系统吞吐量，其中Watchdog的阈值r在1到11之间变化，其中T＝12、和perr＝0.01，如表1的设置(d)所示。从该图可以看出，吞吐量首先增加到最大值，然后减小，并且有一个Watchdog的最佳阈值设置，即r＝2。原因可以解释如下。在固定的平均网络延迟设置为0.3的情况下，当r≤2时，吞吐量会由于虚警事件的概率降低而增加。当r>2时，吞吐量降低，因为r越大，漏检事件的概率就越高。
此外，根据上述计算，由于仿真结果与理论结果之间的平均相对误差在图14，图16，图18和图20中均低于0.4％，准确性很高。
由此可见，本发明提出一种集中式故障检测协议(CFN-Watchdog)，以提供CFN所需的可见性，可以很好地满足CFN的要求并及时回收故障所占用的资源，并显着提高系统吞吐量，有助于边缘计算的参数优化配置和设计更好的故障检测协议。
进一步的，本发明建立理论模型以分析建议的Watchdog协议的性能，考虑重要参数，包括检测阈值，任务处理时间和网络延迟，并刻画对系统吞吐量造成的误报，以及错误事件的漏检。
所以，本发明提出的故障检测协议，是一个在CFN中的集中式任务和VM故障检测协议，可远程监视边缘计算中分布式计算资源的可用状态。在协议中，许多客户端定期向连接到CFN的一个服务器报告其监视虚拟机VM的状态。受益于集中协议的快速响应特点，CFN的控制平面可以实时显示其托管资源状态，并及时回收故障所占用的资源。
需要说明的是，以上仅为本发明的优选实施例，但发明的设计构思并不局限于此，凡利用此构思对本发明做出的非实质性修改，也均落入本发明的保护范围之内。

Claims (6)

1.一种基于边缘计算的集中式故障检测方法，其特征在于，包括：
构建分布式计算框架，其中，所述分布式计算框架由控制平面和计算资源池组成，控制平面用于将资源分配给任务，计算资源池用于管理边缘/云节点的资源；
建立位图机制，具体包括：由服务器创建一个位图数组，以记录虚拟机VM的状态；
对于虚拟机VM的执行时间[0，T)中的每个时间单位，由服务器执行以下两个步骤：
构造位图数组；
使用滑动窗口w检测故障事件；
获取kick数据包，定期向客户端发送kick数据包，并且客户端将kick数据包从虚拟机VM中继到服务器；其中，bite数据包是释放/关闭VM的管理程序API方法的调用；基于用户数据报协议设计kick数据包，其中，payload部分包括以下字段：kickID：标识kick数据包的唯一ID；vmID：发送kick数据包的虚拟机VM的唯一标识ID；nodeID：发送kick数据包的虚拟机VM所在宿主节点的唯一标识ID；sendTime：虚拟机VM发送kick数据包的时间；
服务器通过计数kick数据包监控虚拟机VM的状态，将状态可见性转发到控制平面，并将bite数据包发送到VM管理器，释放因故障而崩溃的虚拟机VM，以回收故障所占用的资源；
其中，服务器基于Bitmap机制，根据接收到的kick数据包连续检测故障事件；
其中，构造位图数组包括：若服务器收到在sendTime＝i时刻发出的kick数据包，判断该数据包的接收时间是否在时间[i，i+r]以内，如是，则服务器将位图数组中的第i个元素设置为1，这表示虚拟机VM在时刻i的状态是正常的；
若服务器直到时刻i+r都没有收到kick数据包，将位图数组中的ith元素设置为0，这表明虚拟机VM在时刻i时发生了故障事件；
使用滑动窗口w检测故障事件：在位图数组中设置了0和1值，并从第i个元素开始，服务器检查w个元素，若在w元素中存在一个0，则服务器检测到虚拟机VM上发生了故障事件；
否则，若所有w元素的值为1，则服务器认为虚拟机VM上没有故障事件发生；
其中，w个元素表示为从i到i+w-1的元素，i＝0,1,…,T-1。
2.根据权利要求1所述的集中式故障检测方法，其特征在于：
当虚拟机启动后，客户端将在边缘/云节点的虚拟化管理平台中运行，在客户端将kick数据包从虚拟机VM中继到服务器的过程中，若一个虚拟机VM和相应的客户端被创建，由系统通知服务器开始监控虚拟机VM，并连续向控制平面报告其状态，直到该虚拟机VM被释放。
3.根据权利要求1所述的集中式故障检测方法，其特征在于：
服务器通过计数kick数据包监控虚拟机VM的状态具体包括：服务器估算从其到托管虚拟机VM的节点的平均网络延迟；服务器根据延迟设置阈值，根据该阈值启动一个计时器，并与该虚拟机VM保持时间同步；服务器执行位图机制，即持续地比较实际接收到的kick数据包和预期kick数据包的数量，以检测虚拟机VM上是否发生故障事件。
4.根据权利要求3所述的集中式故障检测方法，其特征在于：
若检测到故障事件，服务器将bite数据包发送到VM管理器，以释放该虚拟机VM；
若收到来自服务器的bite数据包，由VM管理器执行释放/关闭虚拟机VM的命令。
5.根据权利要求3所述的集中式故障检测方法，其特征在于：
阈值的设置基于服务器与受监控虚拟机VM所在的边缘/云节点之间的网络延迟。
6.根据权利要求5所述的集中式故障检测方法，其特征在于：
服务器根据延迟设置阈值包括：
当创建并启动一个虚拟机VM时，服务器将通过ping数据包计算与该虚拟机VM之间的网络延迟；
服务器检查延迟阈值映射表以找到合适的阈值；
设置阈值并用于监控VM。
CN202110592022.1A 2021-05-28 2021-05-28 一种基于边缘计算的集中式故障检测方法 Active CN113220462B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110592022.1A CN113220462B (zh) 2021-05-28 2021-05-28 一种基于边缘计算的集中式故障检测方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110592022.1A CN113220462B (zh) 2021-05-28 2021-05-28 一种基于边缘计算的集中式故障检测方法

Publications (2)

Publication Number Publication Date
CN113220462A CN113220462A (zh) 2021-08-06
CN113220462B true CN113220462B (zh) 2024-02-06

Family

ID=77099161

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110592022.1A Active CN113220462B (zh) 2021-05-28 2021-05-28 一种基于边缘计算的集中式故障检测方法

Country Status (1)

Country Link
CN (1) CN113220462B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116257361B (zh) * 2023-03-15 2023-11-10 北京信息科技大学 无人机辅助的易故障移动边缘计算资源调度优化方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6973560B1 (en) * 1999-07-16 2005-12-06 Lamarck, Inc. Fault tolerant and combinatorial software environment system, method and medium
KR20160028247A (ko) * 2014-09-03 2016-03-11 주식회사 케이티 클라우드 서버 관리 방법, 이를 수행하는 클라우드 서버 관리 장치 및 클라우드 서비스 관리 시스템
CN110780974A (zh) * 2019-09-10 2020-02-11 杭州电子科技大学 一种移动边缘计算环境下面向工作流的容错调度方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102447723B (zh) * 2010-10-12 2015-09-09 运软网络科技(上海)有限公司 客户端虚拟化架构
CN102346460B (zh) * 2011-05-27 2013-11-13 运软网络科技(上海)有限公司 一种基于事务的服务控制系统及其控制方法
JP6354901B2 (ja) * 2014-10-06 2018-07-11 日本電気株式会社 仮想マシンの故障検知および回復用管理システム
US10552267B2 (en) * 2016-09-15 2020-02-04 International Business Machines Corporation Microcheckpointing with service processor
US10417102B2 (en) * 2016-09-30 2019-09-17 Commvault Systems, Inc. Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic
US11016798B2 (en) * 2018-06-01 2021-05-25 The Research Foundation for the State University Multi-hypervisor virtual machines that run on multiple co-located hypervisors

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6973560B1 (en) * 1999-07-16 2005-12-06 Lamarck, Inc. Fault tolerant and combinatorial software environment system, method and medium
KR20160028247A (ko) * 2014-09-03 2016-03-11 주식회사 케이티 클라우드 서버 관리 방법, 이를 수행하는 클라우드 서버 관리 장치 및 클라우드 서비스 관리 시스템
CN110780974A (zh) * 2019-09-10 2020-02-11 杭州电子科技大学 一种移动边缘计算环境下面向工作流的容错调度方法

Also Published As

Publication number Publication date
CN113220462A (zh) 2021-08-06

Similar Documents

Publication Publication Date Title
US9225615B2 (en) Method for managing network and for providing service QoS
US20210006484A1 (en) Fault detection method, apparatus, and system
EP2197179B1 (en) Apparatus and method for fast detection of communication path failures
US10965546B2 (en) Control of network nodes in computer network systems
US7152180B2 (en) Configurable reliable messaging system
EP1697843B1 (en) System and method for managing protocol network failures in a cluster system
EP3739784B1 (en) Data packet sending method and related device
US9921902B2 (en) System and method for providing a watchdog timer to enable collection of crash data
EP3724761B1 (en) Failure handling in a cloud environment
EP3198468A1 (en) Dynamic data management
CN108476430A (zh) 用于在高吞吐量无线网络上控制发送的装置和方法
CN113678415A (zh) 用于优化数据通信的系统
CN113220462B (zh) 一种基于边缘计算的集中式故障检测方法
Tam et al. Intelligent massive traffic handling scheme in 5G bottleneck backhaul networks
Mehra et al. Network load balancing in software defined network: A survey
Liang et al. A novel CFN-Watchdog protocol for edge computing
CN109450794A (zh) 一种基于sdn网络的通信方法及设备
US20230336470A1 (en) Methods and systems for predicting sudden changes in datacenter networks
Khalid et al. Analysis of transmission control protocol incast over large-scale HPC clusters
CN111813615B (zh) 一种应用系统事务异常处理方法
WO2022178831A1 (zh) 一种无线资源调度方法和设备
Gopalakrishnan et al. Djenne: Dependable and Decentralized Computation for Networked Embedded Systems
WO2023183038A1 (en) Determining and implementing adaptive retries in core network nodes
CN117896445A (zh) 多网络协议切换传输方法、装置、电子设备及存储介质
Sou et al. K-Test: An Analytical Model for Measurement-Based Server Selection Based on Response Time

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