一种灾备中心用AI的算力负载管理方法及系统与流程

本技术属于电数字数据处理领域，尤其涉及一种灾备中心用ai的算力负载管理方法及系统。

背景技术：

1、随着信息技术的快速发展，灾备中心在保障企业数据安全和业务连续性方面发挥着关键作用。当主数据中心发生故障时，灾备中心需要迅速接管业务并进行算力负载管理。传统的算力负载管理通常采用静态资源分配或基于固定阈值的简单调度规则，在面对灾备切换时突发的算力需求时，难以实现资源的动态自适应调整，容易导致算力资源利用率降低以及业务恢复效率下降。

2、为了解决上述静态分配导致的资源利用率降低的问题，相关技术中公开了一种基于深度强化学习的数据中心资源调度方法，通过在数据中心部署深度强化学习模型，实时采集各计算节点的负载状态数据，利用人工智能模型根据当前的负载状态输出动态的算力资源调度策略，从而实现了根据实时业务负载自动分配算力资源，提升了算力负载管理的动态适应性。

3、当主数据中心因突发故障宕机时，灾备中心需要全面接管包含核心数据库、中间件以及前端应用层等多层级架构的复杂业务系统，当用户访问流量重定向至灾备中心时，相关技术会监测到前端应用层节点负载的增加，进而将算力资源优先调度给应用层节点。但是，前端应用层必须在底层数据库完成增量数据同步和状态恢复后，才能有效处理业务请求，导致在底层数据库尚未完成恢复逻辑时，前端应用层就占用了处于等待状态的算力资源，从而造成算力分配与业务节点的实际逻辑就绪状态不匹配，降低了灾备中心在业务接管过程中的算力资源利用效率。

技术实现思路

1、本技术提供了一种灾备中心用ai的算力负载管理方法及系统，用于提高灾备中心在业务接管过程中的算力资源利用效率。

2、第一方面，本技术提供了一种灾备中心用ai的算力负载管理方法，获取灾备接管业务系统的逻辑依赖拓扑图，并采集逻辑依赖拓扑图中各个业务节点的实时负载数据和就绪状态标识，就绪状态标识用于表征对应的业务节点是否具备处理业务请求的数据支撑条件；

3、基于逻辑依赖拓扑图和各个业务节点的就绪状态标识，在各个业务节点中筛选出处于未就绪状态且存在实时负载数据的阻塞节点，以及阻塞节点在逻辑依赖拓扑图中所指向的目标恢复节点；

4、通过预设负载转换函数，将阻塞节点的实时负载数据沿逻辑依赖拓扑图进行逆向映射，得到目标恢复节点的算力补偿权重；

5、将目标恢复节点的实时负载数据与算力补偿权重进行组合，生成目标调度特征；

6、将目标调度特征输入至预先训练的ai算力分配模型中，得到针对目标恢复节点的算力分配策略；

7、按照算力分配策略为目标恢复节点分配算力资源；

8、当监测到目标恢复节点的就绪状态标识更新为已就绪状态时，停止阻塞节点的实时负载数据的逆向映射，并恢复阻塞节点基于实时负载数据的算力资源分配。

9、通过获取灾备接管业务系统中逻辑依赖拓扑图和节点实时负载及就绪状态，识别出具备实时负载但因缺乏数据支撑而处于未就绪状态的阻塞节点，以及其指向的目标恢复节点。通过负载转换函数将阻塞节点积压的负载数据逆向映射，转化为目标恢复节点的算力补偿权重，并与目标恢复节点的实时负载组合生成目标调度特征，使得ai模型在分配算力时能够综合考量上游节点传导的负载压力，为目标恢复节点倾斜分配资源。目标恢复节点获得更充足的算力后能加速具备业务处理能力，进而促使阻塞节点更快满足就绪条件，就绪后即停止逆向映射并恢复正常分配。将算力资源动态向业务恢复的真正瓶颈节点集中，降低了阻塞节点的业务请求等待延迟，提高了系统在灾备接管过程中的算力资源利用效率和业务链路整体恢复速度。

10、结合第一方面的一些实施方式，在一些实施方式中，通过预设负载转换函数，将阻塞节点的实时负载数据沿逻辑依赖拓扑图进行逆向映射，得到目标恢复节点的算力补偿权重，具体包括：

11、提取阻塞节点的实时负载数据中的请求重试频次和并发排队深度；

12、基于请求重试频次计算负载有效性衰减系数；

13、将并发排队深度与负载有效性衰减系数进行乘积运算，得到阻塞节点的有效负载压力值；

14、遍历逻辑依赖拓扑图，确定阻塞节点与目标恢复节点之间的拓扑路径距离；

15、将有效负载压力值和拓扑路径距离输入至预设负载转换函数中进行距离衰减计算，得到目标恢复节点的算力补偿权重。

16、通过提取阻塞节点实时负载中的请求重试频次和并发排队深度，并基于请求重试频次计算负载有效性衰减系数，再将其与并发排队深度相乘，过滤了因网络波动或频繁无效重试导致的虚假高负载现象，获得了能真实反映节点积压程度的有效负载压力值。进一步遍历逻辑依赖拓扑图确定节点间的拓扑路径距离，将有效负载压力值和拓扑路径距离结合进行距离衰减计算，考量了在复杂依赖链路中距离越远对目标节点产生的实际算力补偿需求越弱的客观事实。该方案使得计算出的算力补偿权重更加精确地量化了阻塞节点对目标恢复节点的真实迫切需求程度，提高了算力补偿权重计算的准确度，降低了因负载失真或拓扑距离较远造成的无谓算力浪费。

17、结合第一方面的一些实施方式，在一些实施方式中，将目标恢复节点的实时负载数据与算力补偿权重进行组合，生成目标调度特征，具体包括：

18、提取目标恢复节点的实时负载数据在计算维度、存储维度和网络维度的资源利用率；

19、比对计算维度、存储维度和网络维度的资源利用率，以确定目标恢复节点的瓶颈资源维度；

20、通过预设跨节点资源映射矩阵，将算力补偿权重投影至瓶颈资源维度，以将标量形式的算力补偿权重转换为多维度的资源需求补偿向量；

21、将多维度的资源需求补偿向量与目标恢复节点的实时负载数据进行张量特征向量拼接，得到拼接特征矩阵；

22、对拼接特征矩阵进行归一化处理，生成目标调度特征。

23、通过采用上述技术方案，分别提取目标恢复节点在计算、存储和网络维度的资源利用率进行比对，确定了该节点当前制约业务处理的瓶颈资源维度。利用预设跨节点资源映射矩阵，将原本单一标量形式的算力补偿权重定向投影至对应的瓶颈资源维度上，转换为多维度的资源需求补偿向量，使得算力补偿能够针对性地弥补节点最薄弱的资源短板。随后将该资源需求补偿向量与实时负载数据进行张量特征向量拼接并做归一化处理，生成了融合多维负载和定向补偿信息的目标调度特征。提高了调度特征对节点各维度资源真实紧缺状态的表征精度，从而提高了ai模型后续进行算力调度时对不同维度资源分配的精细化程度，降低了在非瓶颈维度上的资源无效囤积风险。

24、结合第一方面的一些实施方式，在一些实施方式中，提取阻塞节点中积压的历史业务请求，并解析各个历史业务请求携带的业务操作类型；

25、按照业务操作类型对历史业务请求进行分类，并在各个分类中抽取预设数量的业务请求，构建与阻塞节点对应的真实业务探测集；

26、将阻塞节点的算力资源划分为探测基础算力和业务解锁算力；

27、通过探测基础算力将真实业务探测集中的请求发送至目标恢复节点，并监测目标恢复节点针对不同业务操作类型请求的处理成功率反馈；

28、比对各项业务操作类型的处理成功率反馈与预设健康基线，确定处于微观状态异常的受限业务类型，以及处于微观状态正常的可用业务类型；

29、暂停向阻塞节点中属于受限业务类型的积压请求分配业务解锁算力；

30、根据属于可用业务类型的积压请求的数据量，将对应的业务解锁算力分配至阻塞节点。

31、通过提取阻塞节点积压的历史业务请求进行分类，抽取真实请求构建业务探测集，并将算力划分为探测基础算力和业务解锁算力，利用少量基础算力发送真实业务探测请求，在不引发大规模无效调用的前提下，精准试探目标恢复节点对具体业务类型的实际处理能力。通过监测不同业务操作类型的处理成功率并比对健康基线，在微观层面区分出受限业务类型与可用业务类型。暂停向受限类型的请求分配业务解锁算力，防止了因盲目下发请求而导致的持续处理失败与资源空耗，同时依据可用类型的积压数据量精准分配解锁算力以保障可用业务的顺利执行。提高了灾备系统在节点状态不稳定期间的算力调度细粒度，降低了因盲目分配造成的无效算力损耗率，提高了可用业务请求的实际处理效率。

32、结合第一方面的一些实施方式，在一些实施方式中，通过探测基础算力将真实业务探测集中的请求发送至目标恢复节点，并监测目标恢复节点针对不同业务操作类型请求的处理成功率反馈，具体包括：

33、将当前业务操作类型对应的真实业务探测集划分为预热探测子集和验证探测子集；

34、基于探测基础算力，向目标恢复节点发送预热探测子集，以触发针对当前业务操作类型的依赖链路冷启动，并丢弃目标恢复节点针对预热探测子集返回的初始响应状态数据；

35、在经过预设缓冲延时后，基于探测基础算力向目标恢复节点发送验证探测子集；

36、采集目标恢复节点针对验证探测子集返回的业务响应状态码，并基于业务响应状态码计算业务操作类型的处理成功率反馈。

37、通过将真实业务探测集划分为预热探测子集和验证探测子集，利用预热探测子集先行触发目标恢复节点针对当前业务操作类型的依赖链路冷启动，并主动丢弃其初始响应状态数据，排除了节点在从休眠或冷备状态刚苏醒时因资源尚未完全就绪而产生的异常波动数据干扰。在经过预设缓冲延时使得业务链路进入稳定运行状态后，再基于探测基础算力发送验证探测子集，并据此计算业务操作类型的处理成功率反馈。避免了因链路冷启动带来的短暂处理失败被误算作节点的实际业务处理能力，提高了节点业务处理成功率评估的准确度，降低了因初始不稳定造成的业务就绪状态误判率。

38、结合第一方面的一些实施方式，在一些实施方式中，在根据属于可用业务类型的积压请求的数据量，将对应的业务解锁算力分配至阻塞节点之后，方法还包括：

39、解析受限业务类型的业务执行拓扑，提取受限业务类型在目标恢复节点侧对应的底层依赖组件集合；

40、在阻塞节点利用业务解锁算力持续向目标恢复节点发送可用业务类型对应的积压请求的过程中，旁路监听目标恢复节点针对各个可用业务类型所生成的内部组件调用轨迹及对应的组件运行状态反馈；

41、将底层依赖组件集合与采集到的各项内部组件调用轨迹进行跨维度映射比对，筛选出受限业务类型与可用业务类型之间存在重合调用的交集组件；

42、在确定各个交集组件完全覆盖底层依赖组件集合，且各个交集组件在组件运行状态反馈中均呈现正常响应状态的情况下，判定受限业务类型的微观运行环境已隐式恢复就绪；

43、将处于隐式恢复就绪的受限业务类型的状态标记转换为可用业务类型；

44、为可用业务类型的积压请求分配对应的业务解锁算力，以解除受限业务类型的算力分配暂停状态。

45、通过解析受限业务类型的业务执行拓扑提取其底层依赖组件集合，并在系统持续发送可用业务请求的过程中，旁路监听目标恢复节点的内部组件调用轨迹及组件运行状态。通过跨维度映射比对筛选出可用业务与受限业务重合调用的交集组件，在交集组件完全覆盖受限业务的底层依赖且均呈现正常响应状态时，直接判定受限业务类型的微观运行环境已隐式恢复就绪。利用可用业务在实际运行中产生的底层组件状态反馈，间接验证了受限业务的底层运行环境，避免了对受限业务反复进行主动探测，降低了业务状态探测过程中的额外算力开销与网络占用，提高了系统对受限业务恢复就绪状态感知的敏捷性，进而缩短了受限业务的业务积压时间。

46、结合第一方面的一些实施方式，在一些实施方式中，将底层依赖组件集合与采集到的各项内部组件调用轨迹进行跨维度映射比对，筛选出受限业务类型与可用业务类型之间存在重合调用的交集组件，具体包括：

47、解析底层依赖组件集合中各个底层依赖组件的调用属性，提取受限业务类型对各个底层依赖组件的业务操作权限需求，构建包含组件标识维度与权限需求维度的组件需求矩阵；

48、从采集到的各项内部组件调用轨迹中，提取可用业务类型对各个被调用组件的实际执行操作类型；

49、以组件标识维度为基准，将被调用组件与组件需求矩阵进行实体映射对齐，以找出存在实体共用的目标组件；

50、比对目标组件对应的实际执行操作类型与业务操作权限需求，并在实际执行操作类型具备的权限层级大于或等于业务操作权限需求时，将该目标组件判定为符合深度运行环境要求的交集组件。

51、通过解析受限业务类型对底层依赖组件的业务操作权限需求构建组件需求矩阵，并从可用业务类型的内部组件调用轨迹中提取实际执行操作类型，以此为基础找出实体共用的目标组件。进一步将目标组件对应的实际执行操作类型所具备的权限层级与受限业务的业务操作权限需求进行比对，仅在实际执行权限层级大于或等于需求权限层级时，才将该目标组件判定为符合深度运行环境要求的交集组件。该方案充分考量了不同业务对同一底层组件在操作权限上的差异，避免了因可用业务仅成功执行了低级别权限调用而误判高级别权限依赖环境也已就绪的情况，提高了交集组件及微观运行环境判定的严密性，降低了因底层权限环境未达标而过早解除算力分配暂停所引发的二次处理失败风险。

52、第二方面，本技术实施方式提供了一种灾备中心用ai的算力负载管理系统，该灾备中心用ai的算力负载管理系统包括：一个或多个处理器和存储器；存储器与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，一个或多个处理器调用计算机指令以使得系统执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

53、第三方面，本技术实施方式提供一种计算机可读存储介质，包括指令，当上述指令在系统上运行时，使得上述系统执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

54、第四方面，本技术实施方式提供一种计算机程序产品，当计算机程序产品在系统上运行时，使得系统执行如第一方面中任一可能的实现方式描述的方法。

55、本技术实施方式中提供的一个或多个技术方案，至少具有如下技术效果或优点：

56、1、本技术提供了一种灾备中心用ai的算力负载管理方法，通过获取灾备接管业务系统中逻辑依赖拓扑图和节点实时负载及就绪状态，识别出具备实时负载但因缺乏数据支撑而处于未就绪状态的阻塞节点，以及其指向的目标恢复节点。通过负载转换函数将阻塞节点积压的负载数据逆向映射，转化为目标恢复节点的算力补偿权重，并与目标恢复节点的实时负载组合生成目标调度特征，使得ai模型在分配算力时能够综合考量上游节点传导的负载压力，为目标恢复节点倾斜分配资源。目标恢复节点获得更充足的算力后能加速具备业务处理能力，进而促使阻塞节点更快满足就绪条件，就绪后即停止逆向映射并恢复正常分配。将算力资源动态向业务恢复的真正瓶颈节点集中，降低了阻塞节点的业务请求等待延迟，提高了系统在灾备接管过程中的算力资源利用效率和业务链路整体恢复速度。

57、2、本技术提供了一种灾备中心用ai的算力负载管理方法，通过提取阻塞节点积压的历史业务请求进行分类，抽取真实请求构建业务探测集，并将算力划分为探测基础算力和业务解锁算力，利用少量基础算力发送真实业务探测请求，在不引发大规模无效调用的前提下，精准试探目标恢复节点对具体业务类型的实际处理能力。通过监测不同业务操作类型的处理成功率并比对健康基线，在微观层面区分出受限业务类型与可用业务类型。暂停向受限类型的请求分配业务解锁算力，防止了因盲目下发请求而导致的持续处理失败与资源空耗，同时依据可用类型的积压数据量精准分配解锁算力以保障可用业务的顺利执行。提高了灾备系统在节点状态不稳定期间的算力调度细粒度，降低了因盲目分配造成的无效算力损耗率，提高了可用业务请求的实际处理效率。

58、3、本技术提供了一种灾备中心用ai的算力负载管理方法，通过解析受限业务类型的业务执行拓扑提取其底层依赖组件集合，并在系统持续发送可用业务请求的过程中，旁路监听目标恢复节点的内部组件调用轨迹及组件运行状态。通过跨维度映射比对筛选出可用业务与受限业务重合调用的交集组件，在交集组件完全覆盖受限业务的底层依赖且均呈现正常响应状态时，直接判定受限业务类型的微观运行环境已隐式恢复就绪。利用可用业务在实际运行中产生的底层组件状态反馈，间接验证了受限业务的底层运行环境，避免了对受限业务反复进行主动探测，降低了业务状态探测过程中的额外算力开销与网络占用，提高了系统对受限业务恢复就绪状态感知的敏捷性，进而缩短了受限业务的业务积压时间。