一种基于原子性软设施进行节点部署的方法

技术领域

本发明涉及一种容器化技术，是一种操作系统层虚拟化技术领域，具体涉及一种基于原子性软设施进行节点部署的方法。

背景技术

目前采用虚拟化技术(例如，KVM、Xen、hyper-v等)和容器化及容器编排技术(例如，LXC、LXD、Docker、Kubernetes、K3S等)作为业务应用的运行载体，并且已经在数据中心、边缘计算等场景中得到了大量的验证和应用，但面临如下的问题：

1)目前数据中心节点和边缘节点(物理机、虚拟机)的搭建采用逐层构建的方式，即分别搭建服务器、操作系统、虚拟化层、业务应用。每一层的搭建均有较高的技术门槛，专业性极强，一线的使用人员基本不具备完整构建的能力，尤其在遇到故障时，无法自行解决，故需要采用一种简单有效的方式降低对一线人员的技术要求，简化安装和管理操作流程。

2)在搭建数据中心节点和边缘节点的过程中，需要对每一层进行持续的修改，每层的修改往往都是独立的，如：系统升级、配置修改、补丁更新等。出现问题时也会产生临时修复和调整。持续的更改会使得节点的配置越来越不同，难以复制。在运行过程中，也将持进行节点的修改，而后一次的修改往往难以完全兼顾前一次的修改，这会导致后续的修改可能会产生意想不到的副作用。最终会使得节点处于“未知状态”，独特而脆弱。

3)在灾难发生时，由于节点的独特性而难以快速重新构建等效的节点。即使是最好的情况，节点有全部的修改记录，但由于节点的配置是在上线后才确定并且可能持续变化，这导致难以进行事先的故障演练。故需要一种具备一定的故障自愈能力，并且可以进行事先故障演练、快速替换的方案，从而保障节点在短时间内即可恢复使用，整体业务不中断。

容器技术是一种虚拟化技术，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中的应用之外，基本不需要消耗额外的系统资源。

K8S技术是一种调度、编排容器的技术，业务应用以容器的形式，可利用K8S的技术特性实现业务应用的服务发现和调度、负载均衡、服务故障自愈、服务弹性扩容高级特性。但K8S自身由管理节点和业务节点组成，其核心进程有etcd、apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy，各个进程独立运行，用户需要维护所有的进程。

目前数据中心中采用的分层技术方案，即服务器、操作系统、虚拟化层、业务应用完全分层，由不同的人员维护。其逻辑结构如图1。

部署方式是分步安装，即由专业工程师分别安装操作系统、虚拟化层、业务应用，需各领域的多位工程师协作才可完成整个系统的安装部署，具体步骤如下：

①准备服务器，例如，由硬件工程师准备好服务器硬件，接入电源线路、网络线路、存储线路等，使硬件具备启动的条件。

②准备操作系统，例如，由系统工程师在服务器上安装操作系统，配置网络，挂载存储盘，文件系统分区，使操作系统具备使用的条件。

③准备虚拟化层，例如，由容器工程师在操作系统上安装容器运行时(如docker)，安装K8S，并进行软件参数的调整，使虚拟化环境具备运行条件。

④部署业务应用，由应用工程师针对现有环境的基本情况，调整业务应用的各项部署参数，导入业务数据，并确认业务应用运行正常，最终交付用户使用。

目前部署方式的缺点在于：

1)技术门槛高

硬件、操作系统、K8S和业务应用的能力，其中任何一层出现问题，即使有专门的操作使用手册，也因为其专业性和复杂性，造成一线人员难以按照操作手册进行解决。很多情况下不同层之前相互影响，问题是综合产生的，更加大了部署和维护难度。需要有一套一体化的解决方案。

2)节点的频繁更新，很难有效兼容和记录，最终导致节点的独立性和脆弱性。需要保持节点的可复制性和状态的确定性。

3)现有的技术方案难以快速构建等效环境，难以做到事前演练，难以形成应急预案，业务连续性难以保障。需要在更新、故障时保障业务连续性。

4)交付和故障恢复速度慢

采用现有分层结构和分步安装方案，交付时需各个层级的技术人员配合一步一步进行安装部署，发生故障时也需要各个层级的技术人员进行层层恢复，由于各层的过程分离，且较为复杂，最终的交付时间除了安装过程自身耗时以外，与整个流程中各环节的配合默契程度和操作人员操作熟练程度，以及技术水平有很大关联；故障恢复时间与之相同。

发明内容

针对上述技术问题，本发明技术方案将操作系统、虚拟化层、业务应用作为一个整体，统一安装、统一更新、统一恢复，形成原子性软设施。主要流程包括：原子性软设施的制作、原子性软设施的部署、原子性软设施的更新、原子性软设施的备份及恢复。在原子性软设施的基础上增加硬件，可形成原子性硬设施。

本发明提出一种基于原子性软设施进行节点部署的方法，包括如下步骤：

S1进行原子性软设施的制作，根据原子性软设施描述文件将操作系统、虚拟化层、业务应用集成一个原子性软设施安装包；

S2，原子性软设施的部署，一个节点使用一套原子性软设施的安装包，在节点上启动原子性软设施安装包，安装操作系统、配置网络和主机参数、自动安装虚拟化层、自动安装业务应用；

S3对原子性软设施进行更新；

S4对原子性软设施进行备份及恢复。

进一步地，所述原子性软设施描述文件用于描述安装包中操作系统、虚拟化层、业务应用采用的技术、版本、架构、特征。

进一步地，所述原子性软设施安装包结构包括：操作系统、虚拟化层、业务应用及所需的其他依赖软件。

进一步地，所述虚拟化层可在操作系统安装时，自动进行安装，包括但不限于脚本、操作系统预装方式；业务应用层可基于虚拟化层，自动进行安装、配置，包括但不限于脚本、快照方式。

进一步地，所述S1原子性软设施安装包的制作是按照原子性软设施描述文件的要求，获取对应软件形成原子性软设施安装包的过程，在原子性软设施安装包制作过程中从原子性软设施描述文件中拉取描述文件，和从软件库拉取依赖的软件，最后制作成原子性软设施安装包。

进一步地，原子性软设施安装包制作应具备如下的技术特点：

1)支持设置文件系统分区只读；

2)文件系统快照，支持对分区做快照，可通过快照进行系统回滚，以恢复数据；

3)事物更新操作：事物更新不影响当前正在运行的操作系统，重启后可进入新的快照。

进一步地，所述S2原子性软设施的部署具体包括：

在数据中心节点和边缘节点的搭建时，可由一线人员进行原子性软设施部署，专业工程师无需到现场，进行二线指导即可；原子性软设施安装包的部署模式包括但不限于刻录为光盘在物理机上部署，作为虚拟镜像在虚拟机、云主机上部署。

进一步地，所述S3原子性软设施的更新需要重新安装原子性软设施的安装包，针对集群部署的模式，可进行滚动更新升级，不影响业务的正常访问。

进一步地，所述S4原子性软设施的备份具体包括：

备份可分为三层：操作系统、虚拟化层、业务数据的备份。

进一步地，操作系统的备份主要应对操作系统级别的可修复故障，虚拟化层的备份主要包含部署在集群中所有的业务应用的元数据，主要应对误操作删除了部署的业务应用，更改了业务应用的配置，或者是虚拟化层自身的故障；业务数据的备份主要是备份业务应用正常运行所需的数据，包括但不限于数据库备份。

本发明相对现有技术的优势在于：

1)数据中心和边缘节点建设中更高的一致性和可靠性，以及更简单，更可预测的部署过程。

2)节点可被替换性强，避免单点影响，从而保证了整体的稳定性。

3)更容易无缝地向基础架构添加更多相同的节点来简化水平扩展。

4)节省人力成本。

安装过程得到极致简化，其故障恢复流程改变为重装不修，屏蔽了复杂的技术细节，降低了使用人员的技术门槛，一线人员使用其进行安装和维护成为可能，因此无需为其配备大量的二线支持工程师，从而节省人力成本。

5)提升业务连续性。

借助虚拟化层提供的隔离机制，同一个业务应用可以有多个副本同时运行，多个副本同时提供服务，具备高可用和负载均衡的功能，其中某个副本故障时，不影响应用模块的功能。借助虚拟化层的故障自愈特性，故障的副本可在第一时间进行自愈操作，无需人工干预。

借助文件系统快照和事务更新机制可通过快照进行回滚，以恢复数据。

借助原子性软设施的滚动更新模式，可保障在更新、恢复时的业务连续性。

6)便捷运维和恢复。

借助只读特性和事物更新特性，可避免因误操作和篡改导致的系统不可用，系统在运维过程中省去版本控制等诸多麻烦。系统出现问题，也可通过便捷的恢复操作恢复到可用的快照；如果系统彻底故障，亦可使用原子性软设施安装包快速重新安装，一体化恢复。

7)快速交付。

极大的减少人员现场实施的时间和难度，缩短交付周期，甚至可以将原子性软设施直接交付，由用户自行部署。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图做简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术的数据中心采用分层技术方案的逻辑结构示意图；

图2是本申请的实施例提供的原子性软设施安装包结构示意图；

图3是本申请的实施例提供的原子性软设施安装包制作流程示意图；

图4是本申请的实施例提供的原子性软设施的部署流程示意图；

图5是本申请的实施例提供的原子性软设施升级前架构示意图；

图6是本申请的实施例提供的原子性软设施升级第一节点架构示意图；

图7是本申请的实施例提供的原子性软设施升级第一节点后架构示意图；

图8是本申请的实施例提供的原子性软设施升级第二三节点架构示意图；

图9是本申请的实施例提供的原子性软设施升级第二三节点后架构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明技术方案主要流程包括：原子性软设施的制作、原子性软设施的部署、原子性软设施的更新、原子性软设施的备份及恢复。在原子性软设施的基础上增加硬件，可形成原子性硬设施。

1.原子性软设施的制作

原子性软设施的制作是根据原子性软设施描述文件将操作系统、虚拟化层、业务应用集成为一个安装包，其格式包括但不限于ISO。

1)原子性软设施描述文件

原子性软设施描述文件用于描述安装包中操作系统、虚拟化层、业务应用采用的技术、版本、架构、特征等。

2)原子性软设施安装包结构

原子性软设施安装包组成结构如下图2所示。

原子性软设施安装包含操作系统、虚拟化层(包括但不限于KVM、Xen、hyper-v、LXC、LXD、Docker、Kubernetes、K3S等)、业务应用以及所需的其他依赖软件。其中，虚拟化层可在操作系统安装时，自动进行安装，方法包括但不限于脚本、操作系统预装等方式。业务应用层可基于虚拟化层，自动进行安装、配置，方法包括但不限于脚本、快照等方式。

3)原子性软设施安装包制作

如图3所示，原子性软设施安装包的制作是按照原子性软设施描述文件的要求，获取对应软件形成原子性软设施安装包的过程，分为3个步骤：

第一步：拉取原子性软设施描述文件。描述文件是对一次安装部署内容的格式化表达，如某次安装部署需要使用microos操作系统，使用docker和K3S作为容器虚拟化基座，承载某业务软件app，那么格式化表达如图3右上原子性软设施描述文件所示。描述文件描述了各组件的名称、类型，版本、适配架构等信息。

第二步：根据原子性软设施描述文件的要求从软件库中拉取相应软件。软件库使用模块化设计，将各组件的软件进行模块化管理，以实现软件快速组装。软件库中的模块包括软件运行程序文件、配置文件、部署脚本等。根据原子性描述文件从软件库中拉取相应的软件。如拉取了K3S作为容器调度软件，则K3S模块中包含了K3S的二进制部署文件、配置文件、部署脚本等。

第三步：根据原子性软设施描述文件和拉取的软件制作组装出原子性软设施安装包。将拉取到的软件库中的各模块进行组装，包含操作系统、虚拟化层、业务应用等不同层级的软件。在制作的过程中，串联起各个模块的部署脚本，使其能够通过一次操作完成整个原子性软设施的安装。同时在串联组装的过程中，设置文件系统只读分区、开启文件系统快照功能。组装后的原子性软设施安装包为一个归档的压缩文件，如图3中原子性软设施安装包中所示，包含了部署任务的名称、版本、安装环境架构等信息。

原子性软设施安装包制作应具备如下的技术特点：

①文件系统只读：操作系统的根分区(/)下所有文件只读，在运行时用户或程序无法对该目录下的任何文件做修改，可以防止根分区文件篡改或误操作；支持设置分区copy-on-write模式，例如，用户对/etc的修改只限于当前的快照。

②文件系统快照：支持对分区做快照，系统安装完成即获得第一个快照，后续可人工或自动触发快照。当系统出现故障，例如人为误操作修改或删除了/etc分区中的文件，可通过快照进行系统回滚，以恢复数据。

③事物更新操作：对操作系统根分区的修改，如安装新的软件包、修改文件等，必须通过事物更新方式进行，无法直接操作。事物更新具备原子性，要么全部成功，要么全部失败，事物更新会触发快照。事物更新不影响当前正在运行的操作系统，重启后可进入新的快照。

2.原子性软设施的部署

在数据中心节点和边缘节点的搭建时，可由一线人员进行原子性软设施部署，专业工程师无需到现场，进行二线指导即可。

原子性软设施安装包的部署模式包括但不限于刻录为光盘在物理机上部署，作为虚拟镜像在虚拟机、云主机上部署。

图4所示为原子性软设施的部署流程，具体过程为：安装操作系统、配置网络和主机参数、自动安装虚拟化层、自动安装业务应用。

3.原子性软设施的更新

原子性软设施部署之后所有的配置都已经固化，不应该再进行修改。如需修改，则需要重新制作原子性软设施新版本的安装包，进行原子性软设施的更新。

原子性软设施的更新需要重新安装原子性软设施的安装包，针对单节点部署的情况，会带来服务的停机。针对集群部署的模式，可进行滚动更新升级，不影响业务的正常访问。

以三节点集群部署模式为例，说明原子性软设施由v1版本更新到v2版本的过程：

1)升级前，三节点都提供v1版本的服务，其架构如图5所示。

2)利用虚拟化层屏蔽了业务应用与节点的绑定，可以将第一个节点上服务调整到二三节点上运行，此时第二三节点提供v1版本服务，停止第一节点，其架构如图6所示。

3)更新第一个节点的原子性软设施：在第一个节点上安装新的原子性软设施安装包，完成后，其上将自动启动业务应用。此时第一个节点为独立的集群，运行v2版本服务；第二三节点为一个独立的集群，运行v1版本服务。其架构如图7所示。

4)二三节点更新原子性软设施：停止二三节点，在二三节点上安装新的原子性软设施安装包，其架构如图8所示。

5)二三节点更新完成，加入到第一个节点的集群中。此时三个节点都在新的集群中，都提供v2版本服务，其架构如图9所示。

4.原子性软设施的备份及恢复

原子性软设施的备份可分为三层：操作系统、虚拟化层、业务数据的备份。

操作系统的备份主要应对操作系统级别的可修复故障，如误操作删除了操作系统的软件，或者更改为错误的配置。

虚拟化层的备份主要包含部署在集群中所有的业务应用的元数据，主要应对误操作删除了部署的业务应用，更改了业务应用的配置，或者是虚拟化层自身的故障。

业务数据的备份主要是备份业务应用正常运行所需的数据，包括但不限于数据库备份。

原子性软设施，遇到可修复故障时，可利用备份进行恢复；遇到不可修复的故障时，则需要重装节点或替换新节点进行恢复。其过程与更新过程类似，区别在于安装的仍旧是原来版本的原子性软设施。

利用原子性软设施，可以快速模拟搭建生产环境，进行事前的灾备演练，形成预案。

本发明技术方案的关键点是：

1)将操作系统、虚拟化层、业务应用作为一个整体，统一安装、统一更新、统一恢复，形成原子性软设施。

2)利用原子性软设施描述文件可以灵活的制作适应不同架构，采用不同技术选型的原子性软设施。

3)原子性软设施安装包制作应具备如下的技术特点：

①文件系统只读：操作系统的根分区(/)下所有文件只读，在运行时用户或程序无法对该目录下的任何文件做修改，可以防止根分区文件篡改或误操作；支持设置分区copy-on-write模式，例如，用户对/etc的修改只限于当前的快照。

②文件系统快照：支持对分区做快照，系统安装完成即获得第一个快照，后续可人工或自动触发快照。当系统出现故障，例如人为误操作修改或删除了/etc分区中的文件，可通过快照进行系统回滚，以恢复数据。

③事物更新操作：对操作系统根分区的修改，如安装新的软件包、修改文件等，必须通过事物更新方式进行，无法直接操作。事物更新具备原子性，要么全部成功，要么全部失败，事物更新会触发快照。事物更新不影响当前正在运行的操作系统，重启后可进入新的快照。

4)现有分层架构和分步安装方式并没有提供相对简化的安装部署方式，原子性软设施的部署大大简化了部署过程。并且原子性软设施的部署都是基于验证和版本控制的安装包来执行的，部署不依赖于先前的状态，因此不会失败。

5)原子性软设施的更新保持节点的状态始终可知、可复制，不会因频繁的改动使得节点处于“未知可知”状态。集群式的更新模式可以轻松实现蓝绿部署或滚动更新，这意味着业务应用无需中断。

6)原子性软设施可进行备份，具备一定的故障自愈能力，并且可以进行事先故障演练，形成应急预案，从而保障节点在短时间内即可恢复使用，整体业务稳定。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。