一种边缘计算数据备份容灾的方法及装置

1.本发明涉及灾备领域，具体涉及一种边缘计算数据备份容灾的方法及装置。


背景技术：

2.灾备行业起源于70年代，是指利用科学的技术手段和方法，提前建立系统化的数据应急方式以应对灾难发生，包括数据备份和系统备份，业务连续规划、人员架构、通信保障、危机公关，灾难恢复规划、灾难恢复预案、业务恢复预案、紧急事件响应等。
3.备份(backup)：能够防止系统出现操作失误或系统故障而导致数据丢失的情况发生，及时将数据从备份端恢复至生产系统，在各种容错技术发达的当下，数据备份仍然是作为不可替代的基石般的存在。
4.容灾(disastertolerance)：在灾难发生的情况下，保证生产系统的数据尽量少丢失，更重要的就是业务系统的不间断运行。
5.现在的备份容灾技术存在如下缺点：
6.1.现有当边缘数据备份容灾时，一般是通过边缘端和中央云端直接进行计数据备份恢复，边缘向云端进行容灾备份时将会消耗大量的带宽和计算。
7.2.边缘计算设备本身就需要很强的容错兼容性，设备的异构化，所以边缘设备在异构的硬件设备和架构上，边缘设备的存储容量和资源规格各不相同，随着更新迭代，异构和不同规格的边缘端设备会越来越多，容灾和备份目前存在很大的资源消耗。
8.3.在现有边缘向云端进行容灾备份中，若边缘和云端之间的主干网络不通信，数据备份和恢复无法进行。


技术实现要素：

9.本发明的目的在于：针对上述存在的问题，提供一种边缘计算数据备份容灾的方法及装置，高效的利用边缘动态存储能力，在不增加多余的存储设备的前提下，利用边缘云体系中现有的计算/存储/网络资源，实现边缘近端的数据备份和容灾实现，成本低廉，收益成本可控，并且减轻了中央云的备份同步压力。
10.本发明的技术方案如下：
11.本发明一种边缘计算数据备份容灾的方法，包括：将边缘端及其临近边缘端之间建立感知，形成灾备协同网络，并接入中央云；临近边缘端监听边缘端的运行状态，接收边缘端的数据备份和恢复请求；
12.当检测到边缘端状态运行正常，周期性数据备份同步，近端广播资源信息；
13.当检测到边缘端状态运行异常，即发生故障或者需要数据资源，或者需要新增数据模型等服务时；由当前边缘端更新模型或者数据分片的数据校验码向临近边缘端进行广播，并报告给中央云；若临近边缘端存在所需要的服务，直接向当前边缘端进行服务同步和数据备份，完成以后向当前边缘端的边缘进行广播同步。
14.进一步的，中央云监听并收集边缘端上报的边缘端点状态信息；分析并评估边缘
端的异常，备份边缘端的数据资源信息，若边缘端数据丢失下发数据到边缘端点，并开始进行数据备份恢复；核算边缘端异常问题，记录边缘端设备同步的详细事件和评估报告。
15.进一步的，当边缘端或临近边缘端数据压力或算力负载过高时，将数据同步给中央云计算。
16.进一步的，当边缘端发起计算请求时，若临近边缘端不具备计算任务所需要的模型时，向中央云进行计算卸载请求。
17.进一步的，边缘端异常后，进行边缘端异常修复，当检测到边缘端异常修复以后，临近边缘端记录并同步异常边缘端故障前的数据资源，并广播当前边缘端的资源数据。
18.进一步的，边缘端状态运行异常检测方法：通过自身状态字段和临近边缘的网络通信检测；若网络断开或者边缘端的状态记录显示异常，则直接判断边缘端异常。
19.进一步的，边缘端之间灾备协同网络建立以后，边缘网络同步资源信息，对于单副本的计算模型，需要根据同步策略进行合理的分配和同步，保证在网络范围内保证三副本数据，并且跨边缘端分配。
20.本发明一种边缘计算数据备份容灾的装置，包括中央云，中央云分别连接边缘端以及至少一个的其临近边缘端；边缘端和临近边缘端之间相互感知，以及数据备份和同步；
21.所述中央云，用于监听并收集边缘端上报的边缘端点状态信息，定位边缘异常状态报告，分析并评估边缘端的异常，备份边缘端的数据资源信息，制定异常修复方案，若边缘端数据丢失由云端下发到边缘端点，并开始进行数据备份恢复；核算边缘端异常问题，记录边缘端设备同步的详细事件和评估报告；
22.所述边缘端，用于边缘状态自检，在检测到边缘端发生故障，或者需要数据资源，或者新增数据模型时，由边缘端更新模型或者数据分片的数据校验码向临近边缘端进行广播，并报告给中央云；
23.所述临近边缘端，用于监听边缘端的运行状态，接收边缘端数据备份和恢复的请求；若边缘端状态运行正常，周期性数据备份同步，近端广播资源信息；若监听到边缘端存在异常，上报边缘端出现异常，记录异常边缘端的备份数据分布；在异常边缘端修复以后，临近边缘端记录并同步异常边缘端故障前的数据资源并广播当前边缘端的资源数据。
24.进一步的，所述临近边缘端设置的数量有2-5个。
25.进一步的，边缘端和临近边缘端之间通过广播进行数据同步或由中央云下发建立隧道进行链接通信。
26.综上所述，由于采用了上述技术方案，本发明的有益效果是：
27.1、本发明中边缘端设备不再独立存在，而是将边缘端作为组织团体进行相互协作，彼此互为数据分片备份。
28.2、本发明提供了一种近端边缘备份的可行性方案，随着技术的发展，边缘存储的容量扩展，打破传统的云边容灾备份的机制，边缘向云端进行容灾备份时将会消耗大量的带宽和计算存储资源，近端边缘备份相当于增加了一层数据缓存层，减少云边同步频率同时保证数据有效备份。
29.3、本发明在无法预期的意外灾害发生时，因为近端设备可以通过有限距离的通信设备进行数据交换，所以即使主干网络不通信，周边的边缘计算备份任务同样可以进行数据备份恢复。
附图说明
30.本发明将通过例子并参照附图的方式说明，其中：
31.图1是现有数据备份容灾系统的架构图。
32.图2是本发明一种边缘计算数据备份容灾的装置的架构图。
33.图3是本发明一种边缘计算数据备份容灾的方法流程图。
34.图4是实施例中边缘端备份初始状态图。
35.图5是实施例中边缘端备份同步状态图。
36.图6是实施例中边缘端发生异常状态图。
37.图7是实施例中边缘端同步恢复状态图。
具体实施方式
38.本说明书中公开的所有特征，或公开的所有方法或过程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合。
39.本说明书(包括任何附加权利要求、摘要)中公开的任一特征，除非特别叙述，均可被其他等效或具有类似目的的替代特征加以替换。即，除非特别叙述，每个特征只是一系列等效或类似特征中的一个例子而已。
40.下面结合实施例对本发明的特征和性能作进一步的详细描述。
41.如图1所示，现有数据备份容灾系统包括现场层、边缘层和云计算层；其中现场层和边缘层之间通过现场总线或工业以太网连接，边缘层和云计算层之间通过以太网连接。边缘层包含智能感知、智能计算、数据分析、实时控制和过程优化等功能。云计算层进行全局调度和智能决策。边缘层向云计算层进行容灾备份。
42.如图2所示，本发明公开一种边缘计算数据备份容灾的装置，包括中央云，以及与中央云通信的至少两个边缘端，在一些实施例中设置有边缘端a、边缘端b和边缘端c，分别具有存储资源、计算资源和网络资源的功能；其中一个边缘端为另一个边缘端的临近边缘端；边缘端和临近边缘端之间相互感知，以及数据备份和同步。边缘端和临近边缘端之间主要通过广播进行数据同步，随着ipv6技术的应用与推广，边缘端的范围可能会有扩大，基于不同区域的备份需求也可由中央云下发建立隧道进行链接通信。
43.中央云，用于监听并收集边缘端上报的边缘端点状态信息，定位边缘异常状态报告，分析并评估边缘端的异常，备份边缘端的数据资源信息，制定异常修复方案，若边缘端数据丢失由云端下发到边缘端点，并开始进行数据备份恢复；核算边缘端异常问题，记录边缘端设备同步的详细事件和评估报告。如果边缘设备因为数据压力或者算力无法承载时，将数据同步给中央云端，计算任务同步给中央云计算；边缘设备发生故障时，将故障节点的数据分片，同步到相邻的边缘端。
44.边缘端，用于边缘状态自检，在检测到边缘端发生故障，或者需要数据资源，或者新增数据模型时，由边缘端更新模型或者数据分片的数据校验码向临近边缘端进行广播，并报告给中央云。
45.临近边缘端，用于监听边缘端的运行状态，接收边缘端数据备份和恢复的请求；若边缘端状态运行正常，周期性数据备份同步，近端广播资源信息；若监听到边缘端存在异常，上报边缘端出现异常，记录异常边缘端的备份数据分布；在异常边缘端修复以后，临近
边缘端记录并同步异常边缘端故障前的数据资源并广播当前边缘端的资源数据。
46.当边缘端通过网络隧道建立彼此的感知时，边缘端彼此进行灾备，原则上感知边缘端数量应该在《2,6》之间，既以当前边终端为中心，临近边缘端进行数据备份一般需要》＝1,但是边缘端数量需要控制在5个以内，至少存在一个可以备份的对象才能建立备份的最小要求，过多的备份参与体会影响效率并增大管理难度，将是一种无效的数据信息冗余；优选临近边缘建议维持在2-5个，可以实现有效的数据备份。
47.如图3所示，本发明公开一种边缘计算数据备份容灾的方法，包括：
48.故障边缘端的流程：进行边缘状态自检，
49.s1：边缘发生故障，即无法和中央云通信、数据上传，或者需要某种数据资源(比如算法模型)，或者新增某种数据模型时；
50.s2：由当前边缘端更新模型或者数据分片的数据校验码向临近边缘端进行广播，并报告给中央云；
51.s3：如果临近边缘端存在所需要的服务，直接向临近边缘端进行服务同步和数据备份，完成以后向临近边缘端进行广播同步，每个边缘维护临近服务分布资源表；
52.s4：核对临近边缘端的数据差异，通过校验码区分，因为边缘端运行的服务很多时候会一致的，所以如果数据一致可以只进行校验码的记录，实际数据3-4分布在边缘系统即可，无需所有节点都保存全量的数据。
53.正常边缘端流程：边缘状态同步，
54.s10：监听边缘端的运行状态，接收数据备份和恢复的请求；
55.s20：如果临近边缘端状态运行正常，周期性数据备份同步，近端广播资源信息；
56.s30：监听临近边缘端设备存在异常，上报临近边缘出现异常，记录异常端的备份数据分布；
57.正常边缘端还同步异常边缘端可以接收的数据编码；通过md5编码标识数据资源，相同只进行记录，不同的数据进行同步容量报告；接收异常节点的可溶的分片数据信息；当满足灾备同步，记录备份数据的总表和自身作为分片端备份数据的分表；灾备数据备份，立即同步上报检测结果；
58.s40：异常边缘修复以后，临近边缘端设备记录并同步异常边缘端故障前的数据资源并广播当前边缘端的资源数据。
59.中央云流程：
60.s100：边缘端检测程序，监听并收集边缘端上报的边缘端点状态信息；
61.s200：分析并评估边缘端的异常，备份边缘端的数据资源信息，如果边缘端数据丢失由云端下发到边缘端，并开始进行数据备份恢复；
62.s300：核算边缘端异常问题，记录边缘端设备同步的详细事件和评估报告。
63.中央云进行边缘端状态异常的核对记录；边缘端周边检测信息汇总，智能定位边缘异常状态报告；触发边缘节点异常告警，扩容资源进行数据备份。分析异常原因，制定修复方案；记录异常边缘端问题，同步更新边缘状态到各个边缘；汇总异常节点分片备份数据，用于恢复和还原；进入资源核对表；数据异常灾备恢复总结。
64.在实施例中，采用的备份策略：
65.如图4所示为备份初始态，多个边缘端的边缘资源统计成边缘资源表。
66.如图5所示为备份同步态，边缘端之间互相备份，具体包括：
67.a.边缘端相对独立时，无任何交互，临近边缘端不相互感知彼此，当终端发起计算请求时，如果当前边缘端不具备计算任务所需要的模型时，会向中央云进行计算卸载请求；
68.b.当边缘端通过网络隧道建立彼此的感知时，边缘端彼此进行灾备，原则上感知边缘终端数量应该在《1,6》之间，既以当前终端为中心，感知临近边缘终端至少2个边缘或最多5个边缘端，这样可以有效的形成灾备协同网络，协同至少需要1个同伴，最多6个是因为过多的边缘端协作会影响效率并增大管理难度；
69.c.边缘网络建立以后，六度边缘网络同步资源信息，对于单副本的计算模型，需要根据同步策略进行合理的分配合同步，保证在网络范围内保证三副本数据，并且跨边缘端分配。
70.边缘端的备份策略由边缘端整体的状态决定，随着边缘端压力负载过高时，同步周期将会缩短；无论正常或是异常，边缘端向中央云同步是一种常态化的备份策略。
71.异常检测：如图6所示，
72.a.当前边缘发生异常故障或者物理损坏，其他边缘端检测状态为失联，主动向中央云上报异常边缘节点；
73.b.将异常边缘资源表封存，并周期检测异常边缘节点是否恢复上线。
74.同步恢复：如图7所示，
75.a.边缘端设备损坏，设备上的数据丢失，更新替代设备上线，用于恢复边缘端；
76.b.边缘端恢复以后，临近边缘端同步资源路由到当前设备，通过边缘记录的资源信息，主动发起数据同步请求，将之前丢失的数据信息从临近边缘快速的同步回来，无需向中央云发起资源同步。
77.在实施例中，边缘端状态检测，主要由临近边缘端进行监听，中央云进行整体状态汇总，和健康状态评测。边缘端都存在边缘端的健康状态记录，判断边缘端是否正常，主要由自身状态字段和临近边缘的网络通信检测，如果网络断开或者边缘端的状态记录显示异常，则直接判断边缘端异常。例如kubeedge或者k3s，都会集存储容量，系统内存，cpu压力进行健康状态的记录，随着硬/软件发展，相应检测指标也会逐渐增多和完善。
78.边缘状态同步包含两种方式：当前边缘端如果出现问题，中央云会发送临近边缘端状态信息，同时边缘端如果还可以进行心跳检测在通讯允许的范围内向临近边缘端进行状态同步。边缘端的异常可能包含边缘端物理或者网络的损坏，因此单一的状态同步不能很好的保证服务，所以需要两种方式。
79.与现有方案相比，本方案提出一种基于近端备份和恢复的方法，高效的利用了边缘动态存储能力，在不增加多余的存储设备的前提下，利用边缘云体系中现有的计算/存储/网络资源实现边缘近端的数据备份和容灾实现，成本低廉，收益成本可控，并且减轻了中央云的备份同步压力。
80.在边边协同的过程中，彼此临近边缘的数据备份也是一种同步云端的参考，如果临近边缘端已经存在多副本备份，并且中央云也存在了备份数据，则不用向中央云进行备份。
81.边缘端同临近边缘端互为数据备份载体，中央云会有备份数据的映射表记录数据备份信息，如果备份同步的数据已经在中央云存在则不用再次同步，边缘端向中央云请求
获取备份信息，如果中央云已经存在，则不用进行同步，存在不定期同步检测机制，是否同步备份视具体情况而定。
82.以上所述实施例仅表达了本技术的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术技术方案构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。