基于云容错技术的云安全计算方法和装置、存储介质

1.本发明属于电气化交通领域，尤其涉及基于云容错技术的云安全计算方法和装置、存储介质。


背景技术：

2.云计算作为信息技术的一种创新服务模式，即一种it基础设施的交付和使用模式，因其可以按照用户需求提供相应的基础设施资源，同时用户“按需付费”使用对应资源而广泛地在各行各业得以应用。云计算具有超大规模、虚拟化、高可用性、通用性、高可伸缩性、按需服务等特点，可以极大地提高既有资源的利用效率。云计算凭借统一部署业务应用、集中管理数据等优势，在诸多工业控制系统和应用服务中承担核心管理和应用业务。但是云计算在整合系统资源提高资源利用率的同时，面对安全苛求业务时，传统的云计算方法需要面临原生架构导致集群管理面临单点故障的风险和设备资源动态分配造成云上应用微服务面临失效风险。因此，需要一种有效且可靠的云安全计算方法保证云计算平台的可靠性。
3.由于缺乏一种有效的云安全计算方法，传统的通用云计算技术无法满足应用可靠性、可用性、可维护性、安全性，即rams(reliability availability maintainability safety)的指标要求。为了实现云计算的rams指标需求，当前的两个主要技术难题可以总结为：
4.1)如何实现虚拟管理程序hypervisor以及底层硬件等下层依赖的失效预防及节点的恢复管理。
5.2)如何实现虚拟应用服务故障导向安全的设计理念，如何实现应用的故障管理及容错恢复措施。
6.为保障云计算平台上微服务应用的可用性，需采用一定的措施手段，对应用运行期间可能产生的故障问题进行预防、检查、消除以及恢复。从云故障管理的处理流程来看，常见的故障管理技术有故障消除、故障预测与避免以及故障容忍。故障消除的措施是提前排除故障源，在故障发生之前进行提前排查；故障预测与避免指的是在应用服务的生命周期时，对其可能产生的故障点进行实时检测或者根据实时的状态数据进行预测，并提前进行故障剪除；故障容忍强调在故障发生之后采取一定的预留手段抵消故障带来的负面效果并进行恢复。该三种技术在时域上，可先后分别执行。但是在实际的应用运行环境中，故障源及原因并不明显，并且实时的对庞大数量的故障源进行轮询检测也会极大的浪费资源。因此，提高故障容忍的响应时间以及执行效率成为云故障管理的重点，而故障容忍基本等同于故障容错。
7.但从云故障容错的激活先后顺序来看，可以分为主动和被动容错机制。被动容错机制，顾名思义，故障发生时则触发，而常见的云平台被动容错机制有故障检查、故障重启、热备温备冷备、双工以及请求重试。而主动容错机制则是根据平台状态数据，预先采取类似热迁移的措施来提前预防平台失效或者软件错误。


技术实现要素：

8.本发明的目的在于提供一种基于云容错技术的安全计算方法和装置、存储介质，以克服现有云计算平台面临的技术问题。
9.为了实现上述目的，本发明采取了如下技术方案。
10.一种基于云容错技术的云安全计算方法，采用管理容错和应用容错的双容错技术，包括以下步骤：
11.步骤s1、管理容错技术在管理节点采用主多从的容错架构，使用keepalived和haproxy实现管理节点存活自检和用户请求负载均衡，以保证管理节点工作的高可靠性；
12.步骤s2、业务节点采用动态冗余的容错安全设计维持应用微服务生命周期，业务节点通过心跳实时向管理节点反馈存活信息；
13.其中，应用微服务基于探针机制向管理节点上报生命周期，应用微服务之间通过冗余表决交换输入输出信息，保证用户数据接收及处理的安全性及正确性。
14.优选地，步骤s1中，所述管理容错技术选用一主多从架构来保证集群master管理节点的高可用性；在一主多从的架构下，主管理节点执行所有管理功能，多数从节点处于热备状态。
15.作为优选，步骤s1中，haproxy负责进行网络代理，转发用户请求以及记录统计监测对象apiserver的吞吐量、状态、启停次数；keepalived作为反向代理服务器，以双机热备方式周期性检测haproxy的运行状态。
16.作为优选，步骤s1中，所述管理容错技术采用可调权值法进行主管理节点的选举。共设定奇数个管理节点，每个管理节点获得一个身份权重，一旦某节点故障宕机或者重启，则其身份权重根据调整策略来减少或增加权值，身份权重高的继承为主管理节点。
17.作为优选，步骤s2中，所述应用容错技术采用n取二冗余原理设计应用层的安全计算平台，n大于等于2；安全计算平台由多个虚拟主机组成，其内部通过接口调用对接用户服务的输入输出并同步进行表决。所述应用容错技术采用n取二冗余的容错机制，其中n取二可以不断降级，可逐渐降级为n-1取二、n-2取二，并给予故障处理缓冲时间。在n个虚拟主机进行输入和输出表决，最先表决成功优先作为应用输出主机，避免多机向客户端输出的数据冲突。采用动态冗余的被动容错机制，保证故障状态下服务的快速恢复。通过虚拟化主机内自检以及虚拟化主机间心跳实现单一主机故障的监测，通过销毁和替换故障主机实现内部重组和容错。
18.作为优选，采用就绪探针和存活探针两种探针检测方式，实现对包含用户服务在内的安全计算平台在整个生命周期内间隔进行健康检查；其中，就绪探针负责检查虚拟主机是否启动就绪和开始正常工作，存活探针负责探查虚拟主机是否存活。
19.作为优选，在虚拟主机故障失效时会进行副本的重启以及节点迁移；当虚拟主机故障且所在节点物理资源充足时，采用docker容器技术使用镜像创建初始化的副本虚拟主机，若当重启所在的节点基础设施资源不足时，该虚拟主机将会迁移至其余存活的业务节点，实现负载均衡。
20.作为优选，在虚拟主机故障失效时，初始化的副本虚拟主机数据继承于其余虚拟主机；每个存活的虚拟主机互为内存变量存储区；其中，继承的数据信息包括：当前输出主机的通信地址、接收输出数据的客户端通信地址、用户服务相关数据、通信相关信息
21.本发明还提供一种基于云容错技术的云安全计算装置，包括：
22.管理容错模块，用于管理节点采用主多从的容错架构，使用keepalived和haproxy实现管理节点存活自检和用户请求负载均衡；
23.应用容错模块，用于业务节点采用动态冗余的容错安全设计维持应用微服务生命周期，业务节点通过心跳实时向管理节点反馈存活信息；
24.其中，应用微服务基于探针机制向管理节点上报生命周期，应用微服务之间通过冗余表决交换输入输出信息。
25.本发明还提供一种存储介质，所述存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现基于云容错技术的云安全计方法。
26.本发明具有以下技术效果：
27.1)奇数个管理节点分布式容错，可同时执行用户请求；
28.2)应用动态冗余容错，互相心跳监测；
29.3)管理节点宕机失效不影响应用运行；
30.4)应用及其依赖运行环境容器化封装，轻量，易迁移部署，重启迅速。
附图说明
31.为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
32.图1为本发明实施例的基于云容错技术的云安全计算方法的流程图；
33.图2为本发明实施例的基于云容错技术的云安全计算平台结构图；
34.图3为本发明实施例的云管容错方案示意图；
35.图4为本发明实施例的身份权值在宕机和重启情况下的调整过程示意图；
36.图5为本发明实施例的动态冗余的应用容错方法过程；
37.图6为本发明实施例的故障恢复时的数据继承时序。
具体实施方式
38.下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
39.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。
40.本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。
41.为便于对本发明实施例的理解，下面将结合附图以几个具体实施例为例做进一步的解释说明，且各个实施例并不构成对本发明实施例的限定。
42.实施例1：
43.如图1所示，本发明实施提供了一种基于云容错的云安全计算方法，包括以下步骤：
44.步骤s1、管理节点采用主多从的容错架构，使用keepalived和haproxy实现管理节点存活自检和用户请求负载均衡；
45.步骤s2、业务节点采用动态冗余的容错安全设计维持应用微服务生命周期，业务节点通过心跳实时向管理节点反馈存活信息；
46.其中，应用微服务基于探针机制向管理节点上报生命周期，应用微服务之间通过冗余表决交换输入输出信息。
47.本实施例计算方法能够优化传统的云计算方法，可以有效提高传统云计算平台或基于云计算业务的可用性和可靠性，并可以进一步提高各个基于云计算的工业控制系统可靠性和稳定性。该安全计算方法针对rams指标，解决了虚拟管理程序hypervisor和底层硬件等下层依赖的失效预防及节点的恢复管理难题，在虚拟虚拟应用服务中引入了故障导向安全的设计理念，并基于该理念实现了应用的故障管理及容错恢复措施。该安全计算方法通过管理容错和业务容错的双容错技术架构，从多维度保证了云计算平台的容错架构。同时，该安全计算方法可以大大降低传统的云计算方法面临的单点故障的风险和设备资源动态分配造成云上应用微服务面临失效风险，从而实现云计算平台可靠性、可用性等方面性能的全面提升。
48.图2为本发明实施提供的一种基于云容错技术的云安全计算平台结构图。
49.基于云容错技术的云平台架构为纵向多层分布式架构，包括分布式云管中心、分布式业务节点、虚拟主机以及抽象的物理资源池组成。
50.云管中心，对外执行处理用户请求。对内采集业务节点及其上应用微服务的状态信息，存储应用配置元数据。构成云管中心的管理节点仅干涉应用初始化的资源分配、部署节点调度、应用启动时和运行时状态采集以及故障恢复时的重建及迁移。
51.业务节点即为承载业务的物理节点，所有的应用微服务包括虚拟主机在内的运行环境及资源需求均与其具有联系。同时业务节点承载业务不具局限性，可根据用户需求进行定制。
52.虚拟主机是由server操作系统构建的应用微服务。虚拟主机依托于业务节点存在，当业务节点存活个数大于零时，虚拟主机根据资源的负载均衡在任意节点上运行。当业务节点数量为零时，所有虚拟主机无法正常工作且无法恢复直至节点修复重启。业务节点负责向虚拟主机提供物理资源，虚拟主机负责承载用户应用。虚拟主机n取二是在应用层提供主机互检和输入输出表决功能的机制，与业务节点无关
53.物理资源池是所有节点的抽象汇总，不具实体，但其包含了所有业务节点的可用
资源，其中占用资源存在于已运行的应用微服务上。通过回收及分配资源，云管中心实现物理资源池的再分配。
54.在提出的架构中，基于云容错技术的管理节点方案采用一主多从部署架构，为安全苛求应用微服务提供后勤管理保障，预防脑裂问题，实现管理异地容灾。云管中心的主管理节点的身份选举采用权值法。奇数个管理节点间通过身份权值大小推举主管理节点，并通过心跳互相确认存活。每个管理节点保存着所有节点的身份权值，一旦某一节点无法被检测到时，在其余节点记录的其身份权值将接受惩罚。奇数个管理节点可同时接收用户请求但仅有一个管理节点执行命令，满足请求的负载均衡，提升平台请求处理效率。
55.针对分布式任务节点，容错应用方案采用动态冗余的应用容错方法，维持应用微服务的生命周期以及正常运行。该容错方案以健康检查、故障重启或迁移以及数据继承作为设计机制，以安全计算和故障安全作为设计理念，以保护应用和数据以及过滤抵消应用运行错误作为设计目的，构建云上安全计算机平台。
56.在应用容错中，虚拟主机部分引入安全计算设计理念，设计n取二的方案。在n个创建的虚拟主机中，只要主机存活数目大于等于二，云平台包含其内的安全计算平台都仍能正常进行表决、应用处理。表决是为了过滤在虚拟主机上运行的应用运行时产生的错误，比如运行中止、运行异常等故障因素。表决结果的产生满足少数服从多数的原则，一旦某一主机的表决结果不等于多数主机的表决结果，该主机将进行故障重启和数据继承，恢复到具有最新变量数据的初始应用状态。
57.应用容错方案采用的平台底层机制中，健康检查负责检测和保障应用微服务的生命周期，在应用异常中止后能够根据基础镜像自行重启新的副本；故障重启或迁移机制能够在应用微服务故障后自行重启恢复，同时根据各个业务节点的资源使用情况选择合适的恢复部署的节点位置；数据继承机制能在应用重启后恢复已清空销毁的非持久化数据，即故障重启的虚拟主机向正常虚拟主机继承历史应用数据，保证故障重启的主机能继承现有正常虚拟主机的任务进度。满足故障安全的设计理念。
58.本发明实施提供的云管容错方案示意图如图3所示。
59.本实施方案在paas云平台kubernetes上进行云容错方法的设计实现，但不对具体的云平台和云计算实施方案做限制。平台管理节依赖于api server组件、scheduler组件、controller manager组件以及etcd组件，各个组件的具体功能职责为：
60.api server：负责与其他管理节点组件进行通信。是所有api操作的唯一入口，也是集群控制的入口进程；
61.scheduler：负责应用的资源分配和pod节点位置调度；
62.controller manager：负责执行平台级别的功能，如复制组件、持续跟踪工作节点、处理启动失败节点；
63.etcd：负责持久化存储集群配置。
64.平台考虑负责调度的scheduler以及负责副本控制的controller-manager的职能唯一，多个则相互冲突，故不采用多主的形式进行构建。在一主多从架构方案中，奇数个scheduler和controller-manager通过选举确认需执行职能的单位组件，避免组件冲突。而负责执行用户请求的api server在所有管理节点上同时接收用户请求，可满足云平台异地灾备的需求，即可分布式处理用户创建、删除以及查询应用的请求命令。
65.平台负责存储应用创建及初始化的配置数据的组件为etcd，该组件位于每个管理节点上或者脱离管理节点单独构建成为分布式的配置数据存储中心。
66.本发明实施提供的身份权值在宕机和重启情况下的调整过程示意图如图4所示。
67.管理容错的实现方案基于keepalived和haproxy组件方案，该方案采用基于权值法的虚拟ip漂移策略。每个节点的keepalived组件都记录所有节点的初始身份权重，权重最大的即为主管理节点。
68.keepalived通过执行脚本命令检测haproxy状态从而对每个节点的权重进行调整，当haproxy状态无法检测时，keepalived的权值减去设定惩罚值。在漂移策略中，可以通过添加权重调整的触发条件以及对应惩罚值大小，来调整权值变化过程，从而适应不同的应用部署需求。
69.本发明实施提供的动态冗余的应用容错方法过程示意图如图5所示。
70.应用容错的实现方案采用被动容错机制，当故障发生时才及时响应并且快速恢复，无需对云平台诸多的故障源包括下层硬体基础设施以及上层软体应用进行逐一检测，提高了故障处理的效率。应用容错方案包括基于健康检查的主机内自检方案、基于心跳机制的主机互检方案以及基于动态冗余的容错方式。
71.基于健康检查的主机内自检方案实现对虚拟主机的生命周期监测及管理，主要监测目标为应用是否初始化成功以及应用是否正常运行。以开源paas云平台kubernetes为例，其组件kubelet会在虚拟主机创建时同时植入就绪探针readiness probe和存活探针liveness probe。前者确定应用是否已经就绪且可以接受外部通信流量，即检测虚拟主机是否已完全启动；后者确定何时重启应用容器，即监测虚拟主机终止和死锁等故障情况，通过对虚拟主机进行健康检查实现故障重启，其重启位置可以是当前物理节点，也可以是其余物理节点。
72.基于心跳机制的主机互检方案负责主机间健康互检，仅发送心跳信息无需心跳应答，其中充当心跳信息的是每个虚拟主机的表决结果加上表决结果产生时的时间戳。在每个虚拟主机上都有一张表决表，用以收集各个虚拟主机的表决结果，该设计优势在于优先产生表决结果也会优先收集到足量其余虚拟主机的表决结果，进行优先输出，即当表决表中第一个单位为本机时，该虚拟主机允许输出，避免了多个虚拟主机同时输出占用外网网络带宽。
73.应用容错的实现方案采用动态冗余的容错方式。该方式下，通过虚拟化主机内自检以及主机间心跳实现单个或者多个主机故障的监测，通过n取二整体系统内部进行重组，销毁和替换故障主机来实现容错，无需通过资源堆砌来掩盖故障效应。
74.本发明实施提供的故障恢复时的数据继承时序示意图如图6所示。
75.本发明的数据继承机制用以解决历史可遗留数据的交接与传递，防止虚拟主机注销或者故障重启时的数据丢失问题。在虚拟主机正常工作时，表决结果一致的虚拟主机其上数据变量均相同，不同的虚拟主机可互为变量存储区域。某一故障主机可基于通信方式选择从存活的虚拟主机上继承应用内部状态信息，对内存变量进行转储，克服物理主机数据存储与应用一对一的局限性，完成数据恢复。
76.数据恢复过程如下：在相应的管理组件销毁虚拟主机容器并回收其资源至资源池后，会对虚拟主机的资源进行再分配并重新构建该应用的另一个副本。销毁旧有主机以及
构建新副本的同时，新副本主机在启动初始化时会向已存活的虚拟主机发送数据继承请求，已存活的虚拟主机在响应请求的同时会将本机上的缓冲区数据变量一并传输给新副本主机，从而达成数据继承的目的。
77.实施例2：
78.本发明还提供一种基于云容错技术的云安全计算装置，包括：
79.管理容错模块，用于管理节点采用主多从的容错架构，使用keepalived和haproxy实现管理节点存活自检和用户请求负载均衡；
80.应用容错模块，用于业务节点采用动态冗余的容错安全设计维持应用微服务生命周期，业务节点通过心跳实时向管理节点反馈存活信息；
81.其中，应用微服务基于探针机制向管理节点上报生命周期，应用微服务之间通过冗余表决交换输入输出信息。
82.实施例3：
83.本发明还提供一种存储介质，所述存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现基于云容错技术的云安全计方法。
84.以上所述的实施例仅是对本发明优选方式进行的描述，并非对本发明的范围进行限定，在不脱离本发明设计精神的前提下，本领域普通技术人员对本发明的技术方案做出的各种变形和改进，均应落入本发明权利要求书确定的保护范围内。