CN116155686B - 一种云环境下判定节点故障的方法 - Google Patents
一种云环境下判定节点故障的方法 Download PDFInfo
- Publication number
- CN116155686B CN116155686B CN202310073476.7A CN202310073476A CN116155686B CN 116155686 B CN116155686 B CN 116155686B CN 202310073476 A CN202310073476 A CN 202310073476A CN 116155686 B CN116155686 B CN 116155686B
- Authority
- CN
- China
- Prior art keywords
- event
- coroutine
- node
- events
- judging
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 72
- 238000012545 processing Methods 0.000 claims abstract description 56
- 230000008569 process Effects 0.000 claims abstract description 34
- 238000012423 maintenance Methods 0.000 claims abstract description 15
- 238000011161 development Methods 0.000 claims abstract description 10
- 230000006854 communication Effects 0.000 claims abstract description 7
- 230000007246 mechanism Effects 0.000 claims description 12
- 238000012544 monitoring process Methods 0.000 claims description 6
- 238000013508 migration Methods 0.000 claims description 5
- 230000005012 migration Effects 0.000 claims description 5
- 230000005856 abnormality Effects 0.000 claims description 4
- 238000011156 evaluation Methods 0.000 claims description 4
- 230000007613 environmental effect Effects 0.000 claims description 2
- 230000006870 function Effects 0.000 description 12
- 230000000903 blocking effect Effects 0.000 description 9
- 230000018109 developmental process Effects 0.000 description 8
- 230000009286 beneficial effect Effects 0.000 description 5
- 230000004044 response Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
- H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种云环境下判定节点故障的方法，属于云计算技术领域，基于事件驱动判定节点故障，将所有信息流抽象成特定事件，通过对事件之间的内在联系的逻辑判断，确定节点是否存在故障以及故障级别；使用协程模型，整个通信过程依据发布/订阅模式，每个协程等待特定类型的事件，同一事件可被多个协程消费，整个***的开发和维护都围绕事件生成和事件消费展开；针对节点故障判定应用场景，将处理过程划分为调度模块、请求接收模块、任务分发模块、故障判定模块、告警模块和故障处理模块，各个模块之间相对独立，通过事件实现解耦。本发明能够显著提高在大规模集群环境下快速判定节点故障的能力。
Description
技术领域
本发明涉及云计算技术领域，具体地说是一种云环境下判定节点故障的方法。
背景技术
云环境中，使用虚拟机的方式能够提供极大的便利。其优势在于，资源分配十分便利，用户能够根据实际的需要申请合适规格的虚拟机，而且可以实现资源的动态分配；在云上开发业务，能够避免传统的自建环境的诸多不便，且用户不需要考虑运维的问题，有效提高了开发效率和降低成本。
在“云”提供极大便利的同时，也给云开发和运维者带来了一些挑战，实际的“云”还是建立在物理的环境之上的，物理环境仍然可能存在各种问题或者故障。
在现有的技术中有众多高可用的方案，无论是基础的物理设施，如交换机、路由器、网卡、电源，还是软件层面的设施，例如数据库、消息队列、代理服务，都有高可用的技术存在，但是即使有这些技术存在，也无法百分百保证环境出现故障了对于用户没有影响，需要有一种保证用户层环境不受影响或者尽可能减少用户受影响时间的机制。在理想的环境下，任何的节点及其硬件都能正常稳定工作；而实际环境下，节点受机房环境、硬件质量、硬件寿命等复杂因素的影响，如果有一种机制能够在发生故障或者发生故障之前就能判断出当前节点的状态，将有助于减少资源、服务的迁移时间，提升服务质量。
发明内容
本发明的技术任务是针对以上不足之处，提供一种云环境下判定节点故障的方法，在大规模集群环境中能迅速判定出存在故障的节点以及对节点故障进行分类和定级，能够保证处理过程中不会因为存在阻塞操作导致整个处理***处于闲置状态,且能够显著提高在大规模集群环境下快速判定节点故障的能力。
本发明解决其技术问题所采用的技术方案是：
一种云环境下判定节点故障的方法，基于事件驱动判定节点故障，将所有信息流抽象成特定事件，通过对事件之间的内在联系的逻辑判断，确定节点是否存在故障以及故障级别；
使用协程模型，整个通信过程依据发布/订阅模式，每个协程等待特定类型的事件，同一事件可被多个协程消费，整个***的开发和维护都围绕事件生成和事件消费展开，在事件循环核心功能开发完成后，后续的功能开发和扩展简单；
针对节点故障判定应用场景，将处理过程划分为调度模块、请求接收模块、任务分发模块、故障判定模块、告警模块和故障处理模块，各个模块之间相对独立，通过事件实现解耦，每一个子模块负责的功能具体且单一，从编码实现的角度也相对容易。
该方法使用事件驱动作为整体的设计模式，减少***在上下文切换的开销,也避免了轮询方式对***处理资源的消耗，整体上有助于提高***处理性能。基于事件驱动判定节点故障，将所有信息流抽象成特定事件，核心的事件循环作用专一，只需要对事件进行处理，在出现特定的事件时切换处理其他事件，整个处理过程中子任务不存在阻塞等待的状态，不会存在一个子任务阻塞整个***的情况，也不存在大量线程导致的上下文切换开销，因此处理性能及响应速度相当可观，对于迅速判定节点故障起到了决定性作用。使用协程模型,整个通信过程依据发布/订阅事件机制，每一个处于非运行状态的协程必然处于等待状态，而另一方面，同一个事件可以被多个协程接收和处理，协程接收到事件后则开始执行，直到遇到阻塞事件或者主动让出执行流时，当前协程不再运行，主动权转移到事件循环，由事件循环决定下一个需要执行的协程。
优选的，所述协程模型为1：N模型，即一个核，N个协程；
使用协程作为***内部运行的最小单位，协作式处理流中只有当前协程处理到需要等待的任务时，主动让出执行流，此时主事件循环根据事件循环的事件列表中的事件，判断接下来将执行的协程。这个调度模式能很有效避免无用的切换和等待，且相比于操作***提供的进程和线程，协程非常轻量级，能够以很小的开销运行，且调度是在用户态控制的，不存在协程之间的资源竞争，因此能创建成千上万的协程而并不影响整体性能。
协程模型可以做到使用同步的语法写异步代码，在I/O密集型应用中，如果采用异步方式处理I/O请求可以实现效率的极大提升，协程本质上也是一种回调，不过编写代码不存在回调嵌套，通过对异步I/O的封装，使程序更具有可读性。协程具有轻量级的上下文切换机制，相较于操作***提供的进程线程，很容易同时运行10k以上规模的协程列表，但是进程线程是无法做到的，在这种情况下，即使不考虑***自身限制，程序的响应时间也是无法忍受的。在一般协程1:N模型中，由于始终只有一个协程占用cpu，协程在遇到阻塞型事件时主动让出cpu，执行流由调度器切换到下一个协程，整个过程中不存在协程之间资源竞争的问题，全程不用添加锁来保护临界区，大大提高执行效率。
针对故障节点判定这一具体场景，由于不需要执行大量的cpu计算，更多的应用处理时间是在执行网络I/O，而且由于1:N模型的限制可以控制程序对整个物理节点的资源消耗，不会因为程序问题导致整个节点资源被占用，所以十分适合使用协程模型来处理故障判定故障处理的应用场景。
优选的，该方法的具体实现步骤如下：
1)、创建事件循环，包含一个事件处理队列，以及协程列表；
2)、创建监听协程，该协程作为事件接收的接口，监听在固定端口上，并创建RequestDispatchEvent事件，放入事件队列中；
3)、创建请求分发协程，该协程消费RequestDispatchEvent事件，并创建一个新的协程，用于请求处理，并创建一个RequestEvent，放入事件处理队列中；
4)、创建故障判定协程，该协程消费NodeEvent事件，并且保存历史事件记录，根据事件存在的事务关系，判断节点当前的运行状态，并做出评估；根据NodeEvent事件中携带的节点信息分发到对应的处理协程中处理；
5)、创建告警协程，该协程消费AlertEvent事件，当集群存在节点异常时，将故障节点信息通知发送；
6)、主事件循环从事件队列中获取一个事件，如果是RequestDispatchEvent，则从协程列表中获取正在等待RequestEvent的协程(请求分发协程)，执行协程；
主事件循环从事件队列中获取一个事件，如果是RequestEvent，则从协程列表中获取正在等待RequestEvent的协程(请求处理协程)，执行协程；
主事件循环从事件队列中获取一个事件，如果是NodeEvent，则从协程列表中获取正在等待NodeEvent事件的协程(故障判定协程)，执行该协程。
优选的，所述监控协程，当对应的文件句柄发生变化，表示有请求出现，该协程不会立即处理请求，而是创建一个RequestDispatchEvent，并放入事件队列中。
优选的，所述故障判定协程，根据实际需求，在环境规模小的情况下，使用单个故障判定协程来对多个节点进行判定；在大规模环境下，为每一个节点创建单独的故障判定协程。
优选的，所述告警协程，故障节点信息以多种可选方式通知发送。
进一步的，故障判定完成后，通过多种分发机制将信息发送给故障运维平台，从而对节点进行服务迁移和维护工作。
本发明还要求保护一种云环境下判定节点故障的***，该***采用事件驱动编程模式，将可衡量节点当前运行状况的指标抽象为事件，通过对一段时间内接收到事件的判定逻辑，衡量节点信息，给出节点判定结果；
该***通过上述的云环境下判定节点故障的方法实现云环境下的节点故障判定。
本发明还要求保护一种云环境下判定节点故障的装置，包括：至少一个存储器和至少一个处理器；
所述至少一个存储器，用于存储机器可读程序；
所述至少一个处理器，用于调用所述机器可读程序，执行上述的方法。
本发明还要求保护计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行上述的方法。
本发明的一种云环境下判定节点故障的方法与现有技术相比，具有以下有益效果：
本方法使用事件驱动模式，将事件作为事件循环处理的核心资源，将整个***的处理能力派遣到多个功能单一的协程中去具体实现，做到了功能解耦，有助于***开发和扩展。由于同一个时刻只有同一个协程运行，且上下文的切换时机是可预期的，不需要对可能发生竞争的资源加锁，且协程相较于内核线程更为轻量，不存在线程切换的开销，在大规模环境下能显著提升并发能力和处理性能，针对节点故障判定场景，能有效缩短节点故障判定时间。
附图说明
图1是本发明实施例提供的基于事件驱动判定节点故障的示意图。
具体实施方式
下面结合附图和具体实施例对本发明作进一步说明。
针对背景技术中提出的问题，基于在不稳定的物理环境上使用虚拟化技术可以建立稳定的虚拟环境，本发明实施例提供了一种云环境下判定节点故障的方法，基于事件驱动判定节点故障，将所有信息流抽象成特定事件，通过对事件之间的内在联系的逻辑判断，确定节点是否存在故障以及故障级别；
使用协程模型，整个通信过程依据发布/订阅模式，每个协程等待特定类型的事件，同一事件可被多个协程消费，整个***的开发和维护都围绕事件生成和事件消费展开，在事件循环核心功能开发完成后，后续的功能开发和扩展简单；
使用协程作为***内部运行的最小单位,由于协作式处理流中只有当前协程处理到需要等待的任务时，主动让出执行流，这个时候主事件循环根据事件循环的事件列表中事件，判断接下来将执行的协程，这个调度模式能很有效避免无用的切换和等待，且相比于操作***提供的进程和线程，协程非常轻量级，能够以很小的开销运行，且调度是在用户态控制的，不存在协程之间的资源竞争，因此能创建成千上万的协程而并不影响整体性能。
针对节点故障判定应用场景，将处理过程划分为调度模块、请求接收模块、任务分发模块、故障判定模块、告警模块和故障处理模块，各个模块之间相对独立，通过事件实现解耦，每一个子模块负责的功能具体且单一，从编码实现的角度也相对容易。
本方法使用事件驱动作为整体的设计模式，减少***在上下文切换的开销，也避免了轮询方式对***处理资源的消耗，整体上有助于提高***处理性能。
基于事件驱动判定节点故障，将所有信息流抽象成特定事件，核心的事件循环作用专一，只需要对事件进行处理，在出现特定的事件时切换处理其他事件，整个处理过程中子任务不存在阻塞等待的状态，不会存在一个子任务阻塞整个***的情况，也不存在大量线程导致的上下文切换开销，因此处理性能及响应速度相当可观，对于迅速判定节点故障起到了决定性作用。
使用协程模型,整个通信过程依据发布/订阅事件机制，每一个处于非运行状态的协程必然处于等待状态，而另一方面，同一个事件可以被多个协程接收和处理，协程接收到事件后则开始执行，直到遇到阻塞事件或者主动让出执行流时，当前协程不再运行，主动权转移到事件循环，由事件循环决定下一个需要执行的协程。
协程模型可以做到使用同步的语法写异步代码，在I/O密集型应用中，如果采用异步方式处理I/O请求可以实现效率的极大提升，协程本质上也是一种回调，不过编写代码不存在回调嵌套，通过对异步I/O的封装，使程序更具有可读性。协程具有轻量级的上下文切换机制，相较于操作***提供的进程线程，很容易同时运行10k以上规模的协程列表，但是进程线程是无法做到的，在这种情况下，即使不考虑***自身限制，程序的响应时间也是无法忍受的。在一般协程1:N模型中(一个核，N个协程)，由于始终只有一个协程占用cpu，协程在遇到阻塞型事件时主动让出cpu，执行流由调度器切换到下一个协程，整个过程中不存在协程之间资源竞争的问题，全程不用添加锁来保护临界区，大大提高执行效率。
针对故障节点判定这一具体场景，由于不需要执行大量的cpu计算，更多的应用处理时间是在执行网络I/O，而且由于1:N模型的限制可以控制程序对整个物理节点的资源消耗，不会因为程序问题导致整个节点资源被占用，所以十分适合使用协程模型来处理故障判定故障处理的应用场景。
该方法的具体实现过程如下：
1)、创建事件循环，包含一个事件处理队列，以及协程列表；
2)、创建监听协程，该协程作为事件接收的接口，监听在固定端口上，当对应的文件句柄发生变化，表示有请求出现，该协程不会立即处理请求，而是创建一个RequestDispatchEvent，并放入事件队列中；
3)、创建请求分发协程，该协程消费RequestDispatchEvent事件，并创建一个新的协程，用于请求处理，并创建一个RequestEvent，放入事件处理队列中；
4)、创建故障判定协程，该协程消费NodeEvent事件，并且保存历史事件记录，根据事件存在的事务关系，判断节点当前的运行状态，并做出评估；根据实际需求，在环境规模小的情况下，使用单个故障判定协程来对多个节点进行判定；在大规模环境下，为每一个节点创建单独的故障判定协程；根据NodeEvent事件中携带的节点信息分发到对应的处理协程中处理，简化判定的逻辑；
5)、创建告警协程，该协程消费AlertEvent事件，目的是当集群存在节点异常时，将故障节点信息以多种可选方式通知发送；
6)、主事件循环从事件队列中获取一个事件，如果是RequestDispatchEvent，则从协程列表中获取正在等待RequestEvent的协程(请求分发协程)，执行协程；
7)、主事件循环从事件队列中获取一个事件，如果是RequestEvent，则从协程列表中获取正在等待RequestEvent的协程(请求处理协程)，执行协程；
8)、主事件循环从事件队列中获取一个事件，如果是NodeEvent，则从协程列表中获取正在等待NodeEvent事件的协程(故障判定协程)，执行该协程。
故障判定完成后，通过多种分发机制将信息发送给故障运维平台，从而对节点进行服务迁移和维护工作。
图1展示了云环境下基于事件驱动判定节点故障机制示意图。如图1所示，***采用事件循环的机制，将不同类型子任务分发到单独的协程中执行，作为一个异步非阻塞的***，处理子任务高效有序，通过对抽象事件的加工得到最终节点是否正常运行的信息，组成了运维***的重要一部分。
本方法以事件为中心，通过对事件之间的内在联系的逻辑判断最终确定节点是否存在故障以及故障级别，以方便后续对节点进行运维管理，简化了定位故障的流程，有效提高故障定位效率以及最大化提升用户服务质量。使用本方法在大规模集群环境中能迅速判定出存在故障的节点以及对节点故障进行分类和定级，采用事件驱动异步编程模型，保证处理过程中不会因为存在阻塞操作导致整个处理***处于闲置状态，且使用无锁化设计，显著提高在大规模集群环境下快速判定节点故障的能力。
本发明实施例还提供一种云环境下判定节点故障的***，该***采用事件驱动编程模式，将可衡量节点当前运行状况的指标抽象为事件，通过对一段时间内接收到事件的判定逻辑，衡量节点信息，给出节点判定结果；
该***通过上述的云环境下判定节点故障的方法实现云环境下的节点故障判定。具体实现过程如下：
1)、创建事件循环，包含一个事件处理队列，以及协程列表；
2)、创建监听协程，该协程作为事件接收的接口，监听在固定端口上，当对应的文件句柄发生变化，表示有请求出现，该协程不会立即处理请求，而是创建一个RequestDispatchEvent，并放入事件队列中；
3)、创建请求分发协程，该协程消费RequestDispatchEvent事件，并创建一个新的协程，用于请求处理，并创建一个RequestEvent，放入事件处理队列中；
4)、创建故障判定协程，该协程消费NodeEvent事件，并且保存历史事件记录，根据事件存在的事务关系，判断节点当前的运行状态，并做出评估；根据实际需求，在环境规模小的情况下，使用单个故障判定协程来对多个节点进行判定；在大规模环境下，为每一个节点创建单独的故障判定协程；根据NodeEvent事件中携带的节点信息分发到对应的处理协程中处理，简化判定的逻辑；
5)、创建告警协程，该协程消费AlertEvent事件，目的是当集群存在节点异常时，将故障节点信息以多种可选方式通知发送；
6)、主事件循环从事件队列中获取一个事件，如果是RequestDispatchEvent，则从协程列表中获取正在等待RequestEvent的协程(请求分发协程)，执行协程；
7)、主事件循环从事件队列中获取一个事件，如果是RequestEvent，则从协程列表中获取正在等待RequestEvent的协程(请求处理协程)，执行协程；
8)、主事件循环从事件队列中获取一个事件，如果是NodeEvent，则从协程列表中获取正在等待NodeEvent事件的协程(故障判定协程)，执行该协程。
故障判定完成后，通过多种分发机制将信息发送给故障运维平台，从而对节点进行服务迁移和维护工作。
本发明实施例还提供一种云环境下判定节点故障的装置，包括：至少一个存储器和至少一个处理器；
所述至少一个存储器，用于存储机器可读程序；
所述至少一个处理器，用于调用所述机器可读程序，执行上述的方法。
本发明实施例还提供一种计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行上述实施例中所述的云环境下判定节点故障的方法。具体地，可以提供配有存储介质的***或者装置，在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该***或者装置的计算机(或CPU或MPU)读出并执行存储在存储介质中的程序代码。
在这种情况下，从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此程序代码和存储程序代码的存储介质构成了本发明的一部分。
用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD+RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上下载程序代码。
此外，应该清楚的是，不仅可以通过执行计算机所读出的程序代码，而且可以通过基于程序代码的指令使计算机上操作的操作***等来完成部分或者全部的实际操作，从而实现上述实施例中任意一项实施例的功能。
此外，可以理解的是，将由存储介质读出的程序代码写到***计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的CPU等来执行部分和全部实际操作，从而实现上述实施例中任一实施例的功能。
上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。
Claims (9)
1.一种云环境下判定节点故障的方法，其特征在于，基于事件驱动判定节点故障，将所有信息流抽象成特定事件，通过对事件之间的内在联系的逻辑判断，确定节点是否存在故障以及故障级别；
使用协程模型，整个通信过程依据发布/订阅模式，每个协程等待特定类型的事件，同一事件可被多个协程消费，整个***的开发和维护都围绕事件生成和事件消费展开；
针对节点故障判定应用场景，将处理过程划分为调度模块、请求接收模块、任务分发模块、故障判定模块、告警模块和故障处理模块，各个模块之间相对独立，通过事件实现解耦；
该方法的具体实现步骤如下：
1）、创建事件循环，包含一个事件处理队列，以及协程列表；
2）、创建监听协程，该协程作为事件接收的接口，监听在固定端口上，并创建RequestDispatchEvent事件，放入事件队列中；
3）、创建请求分发协程，该协程消费RequestDispatchEvent事件，并创建一个新的协程，用于请求处理，并创建一个RequestEvent，放入事件处理队列中；
4）、创建故障判定协程，该协程消费NodeEvent事件，并且保存历史事件记录，根据事件存在的事务关系，判断节点当前的运行状态，并做出评估；根据NodeEvent事件中携带的节点信息分发到对应的处理协程中处理；
5）、创建告警协程，该协程消费AlertEvent事件，当集群存在节点异常时，将故障节点信息通知发送；
6）、主事件循环从事件队列中获取一个事件，如果是RequestDispatchEvent，则从协程列表中获取正在等待RequestEvent的协程，执行协程；
主事件循环从事件队列中获取一个事件，如果是RequestEvent，则从协程列表中获取正在等待RequestEvent的协程，执行协程；
主事件循环从事件队列中获取一个事件，如果是NodeEvent，则从协程列表中获取正在等待NodeEvent事件的协程，执行该协程。
2.根据权利要求1所述的一种云环境下判定节点故障的方法，其特征在于，所述协程模型为1：N模型；
使用协程作为***内部运行的最小单位，协作式处理流中只有当前协程处理到需要等待的任务时，主动让出执行流，此时主事件循环根据事件循环的事件列表中的事件，判断接下来将执行的协程。
3.根据权利要求1所述的一种云环境下判定节点故障的方法，其特征在于，所述监听协程，当对应的文件句柄发生变化，表示有请求出现，该协程不会立即处理请求，而是创建一个RequestDispatchEvent，并放入事件队列中。
4.根据权利要求1所述的一种云环境下判定节点故障的方法，其特征在于，所述故障判定协程，根据实际需求，在环境规模小的情况下，使用单个故障判定协程来对多个节点进行判定；在大规模环境下，为每一个节点创建单独的故障判定协程。
5.根据权利要求1所述的一种云环境下判定节点故障的方法，其特征在于，所述告警协程，故障节点信息以多种可选方式通知发送。
6.根据权利要求1所述的一种云环境下判定节点故障的方法，其特征在于，故障判定完成后，通过多种分发机制将信息发送给故障运维平台，从而对节点进行服务迁移和维护工作。
7.一种云环境下判定节点故障的***，其特征在于，该***采用事件驱动编程模式，将可衡量节点当前运行状况的指标抽象为事件，通过对一段时间内接收到事件的判定逻辑，衡量节点信息，给出节点判定结果；
该***通过权利要求1至6任一项所述的云环境下判定节点故障的方法实现云环境下的节点故障判定。
8.一种云环境下判定节点故障的装置，其特征在于包括：至少一个存储器和至少一个处理器；
所述至少一个存储器，用于存储机器可读程序；
所述至少一个处理器，用于调用所述机器可读程序，执行权利要求1至6任一所述的方法。
9.计算机可读介质，其特征在于，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行权利要求1至6任一所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310073476.7A CN116155686B (zh) | 2023-01-30 | 2023-01-30 | 一种云环境下判定节点故障的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310073476.7A CN116155686B (zh) | 2023-01-30 | 2023-01-30 | 一种云环境下判定节点故障的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116155686A CN116155686A (zh) | 2023-05-23 |
| CN116155686B true CN116155686B (zh) | 2024-05-31 |
Family
ID=86373057
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310073476.7A Active CN116155686B (zh) | 2023-01-30 | 2023-01-30 | 一种云环境下判定节点故障的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116155686B (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5961651A (en) * | 1996-04-15 | 1999-10-05 | Sun Microsystems, Inc. | Event notification in a computing system having a plurality of storage devices |
| KR20080093206A (ko) * | 2007-04-16 | 2008-10-21 | 아주대학교산학협력단 | 이벤트 모델 기반 고속 오토노믹 결합 관리 방법 |
| CN102868754A (zh) * | 2012-09-26 | 2013-01-09 | 北京联创信安科技有限公司 | 一种实现集群存储高可用性的方法、节点装置和*** |
| CN107329812A (zh) * | 2017-06-09 | 2017-11-07 | 腾讯科技（深圳）有限公司 | 一种运行协程的方法和装置 |
| CN111865695A (zh) * | 2020-07-28 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种云环境下自动故障处理的方法及*** |
| CN112346835A (zh) * | 2020-10-22 | 2021-02-09 | 上海瀚之友信息技术服务有限公司 | 一种基于协程的调度处理方法及*** |
| CN114615096A (zh) * | 2021-11-19 | 2022-06-10 | 亚信科技（中国）有限公司 | 基于事件驱动架构的电信计费方法、***及相关设备 |
| CN114942859A (zh) * | 2022-06-17 | 2022-08-26 | 武汉联影医疗科技有限公司 | 节点故障的处理方法、装置、设备、介质和程序产品 |
| CN115390920A (zh) * | 2022-09-20 | 2022-11-25 | 平安国际融资租赁有限公司 | 事件流处理方法、装置、计算机设备及存储介质 |
| CN115576683A (zh) * | 2022-09-14 | 2023-01-06 | 广东开放大学（广东理工职业学院） | 一种协程池调度管理方法、***、装置及存储介质 |
-
2023
- 2023-01-30 CN CN202310073476.7A patent/CN116155686B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5961651A (en) * | 1996-04-15 | 1999-10-05 | Sun Microsystems, Inc. | Event notification in a computing system having a plurality of storage devices |
| KR20080093206A (ko) * | 2007-04-16 | 2008-10-21 | 아주대학교산학협력단 | 이벤트 모델 기반 고속 오토노믹 결합 관리 방법 |
| CN102868754A (zh) * | 2012-09-26 | 2013-01-09 | 北京联创信安科技有限公司 | 一种实现集群存储高可用性的方法、节点装置和*** |
| CN107329812A (zh) * | 2017-06-09 | 2017-11-07 | 腾讯科技（深圳）有限公司 | 一种运行协程的方法和装置 |
| CN111865695A (zh) * | 2020-07-28 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种云环境下自动故障处理的方法及*** |
| CN112346835A (zh) * | 2020-10-22 | 2021-02-09 | 上海瀚之友信息技术服务有限公司 | 一种基于协程的调度处理方法及*** |
| CN114615096A (zh) * | 2021-11-19 | 2022-06-10 | 亚信科技（中国）有限公司 | 基于事件驱动架构的电信计费方法、***及相关设备 |
| CN114942859A (zh) * | 2022-06-17 | 2022-08-26 | 武汉联影医疗科技有限公司 | 节点故障的处理方法、装置、设备、介质和程序产品 |
| CN115576683A (zh) * | 2022-09-14 | 2023-01-06 | 广东开放大学（广东理工职业学院） | 一种协程池调度管理方法、***、装置及存储介质 |
| CN115390920A (zh) * | 2022-09-20 | 2022-11-25 | 平安国际融资租赁有限公司 | 事件流处理方法、装置、计算机设备及存储介质 |
Non-Patent Citations (1)
| Title |
|---|
| 基于Python协程技术的LAMOST控制节点分布状态采集与监视***;田园;王锋;李建;王政;赵永恒;;天文研究与技术;20180426(第04期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116155686A (zh) | 2023-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Qin et al. | Arachne:{Core-Aware} Thread Management | |
| US9916232B2 (en) | Methods and systems of distributed tracing | |
| Ghormley et al. | GLUix: a global layer unix for a network of workstations | |
| KR101400286B1 (ko) | 다중 프로세서 시스템에서 작업을 이동시키는 방법 및 장치 | |
| CN102868736B (zh) | 一种云计算监控框架设计及实现方法及云计算处理设备 | |
| US8201183B2 (en) | Monitoring performance of a logically-partitioned computer | |
| US20090132840A1 (en) | Cross-layer power management in a multi-layer system | |
| US9521004B2 (en) | Methods and systems of generating a billing feed of a distributed network | |
| US10498817B1 (en) | Performance tuning in distributed computing systems | |
| WO2021143590A1 (zh) | 一种分布式容器镜像构建调度***及方法 | |
| US20230418661A1 (en) | Decentralized resource scheduling | |
| CN115878301A (zh) | 一种数据库网络负载性能的加速框架、加速方法及设备 | |
| Machida et al. | Toward optimal virtual machine placement and rejuvenation scheduling in a virtualized data center | |
| CN116155686B (zh) | 一种云环境下判定节点故障的方法 | |
| EP3084603B1 (en) | System and method for supporting adaptive busy wait in a computing environment | |
| CN113742073B (zh) | 一种基于lsb接口的集群控制方法 | |
| CN113515356B (zh) | 一种轻量级分布式资源管理与任务调度器及方法 | |
| Nong et al. | Allocation of resources for cloud survivability in smart manufacturing | |
| Irufaan et al. | Microservice dynamic resource provision for small and medium-sized enterprises | |
| Zhang et al. | Task scheduling based on virtual machine matching in clouds | |
| Zhao et al. | Yadoop: an elastic resource management solution of yarn | |
| woon Ahn et al. | Mirra: Rule-based resource management for heterogeneous real-time applications running in cloud computing infrastructures | |
| Kaur et al. | Discovering execution of Real Time tasks in cloud computing | |
| CN117170828A (zh) | 一种面向分布式数据处理的任务编排***与方法 | |
| Lu et al. | SARN: A scalable resource managing framework for YARN |
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 |