基于云计算框架的OLTP类业务安全可控模型的一般性探究

李 萌

(国家药品监督管理局信息中心 北京 100044)

0 引 言

当前，新一轮信息革命正引领人类从工业文明加速向信息文明转型，全面影响和重塑经济运行、社会发展、国家治理、人民生活等各个领域，政务信息化已成为通往现代治理之路必不可少的重要依托。全面加快政务信息化创新发展，已成为推进国家治理体系和治理能力现代化建设的重要手段，对于深化行政体制改革，建设法治政府、创新政府、廉洁政府和服务型政府具有重要意义。伴随着信息技术和互联网的飞速发展，政府采用信息技术调整行政管理的形态和方式，为社会和公众提供便捷有效和高质量的服务是世界趋势，政务信息化已成为时代潮流。国家也已经把信息化上升为国家战略[1]。

2020年3月，中共中央政治局常务委员会召开会议提出，加快5G网络、数据中心等新型基础设施建设进度。“新基建”势必将推进5G、AI、大数据、云计算等业务飞速发展,未来数据中心网络需要在无损、智慧、开源等方面全面提升能力,为新一代业务应用保驾护航[2]。在当前的国际竞争格局下，知识产权自主可控十分重要，做不到这一点就一定会受制于人。习总书记在关于网信工作的系列讲话之中，强调了不止一次“加快推进国产自主可控替代计划，构建安全可控的信息技术体系”。关于网络安全信息化的一个重要指示，其中提到了要加快推进国产自主可控的替代计划，就是国产的产品进入市场要有替代能力，要有个计划去替代它，替代垄断的外国产品。政务信息化系统有着数据敏感、关乎国计民生等重大事项，不管在硬件还是软件部分都应当做好国产自主可控的替代[3]。

云计算不管是公有云还是私有云作为全新的资源服务模式起到举足轻重的作用。在药品监管领域，由于种种原因，部分物理环境下部署的OLTP应用系统，云化迁移的工作正在开展，但是遇到了许多问题[4]，物理环境和虚拟化环境的指标评估不对称导致P2V的业务架构不合理、资源申请不合理、网络设计不合理等系列问题，对整体工作量影响比较大。同时，在虚拟化环境下业务安全问题也是一个大的挑战。在这个过程中，业内其实并没有一个成熟的参考模式和考量指标[5]。尤其目前在我国加快推进国产自主可控替代的大环境下，这项工作的难度和复杂度又有提高。

1 OLTP业务系统分析

1.1 背景分析

对于OLTP业务系统，概念已经非常清晰，即联机事务处理系统(On-Line Transaction Processing)是一种以事务元作为数据处理的单位、人机交互的计算机应用系统[6]。

在政府领域，存在大量的此类系统，比如国家药品监督管理局网站管理系统、总局统一行政准入管理系统(互联网)、执业药师管理信息系统等，其最大的特点是由前台、应用、数据库共同完成，其处理快慢以及处理程度取决于数据库引擎、服务器、应用引擎。

国家药品监督管理局信息中心承担着云平台建设的相关任务和职责，云平台构建完成后，各部门只需通过在虚拟的平台上部署自己的应用，而后端的平台交给云计算中心处理，那将可以大大简化用户部署的烦琐性和维护的复杂性，也提高资源的利用率，各部门无须独立购买硬件和基础软件来部署独立的应用。各部门在部署应用系统的云化架构，需要平台侧配合来完成设计和部署。基于此，本文设计相关云化模型的评估和探究。

1.2 维度分析

OLTP的云化一般考虑以下几个维度。

维度1基础信息分析。主要考虑因素如表1所示。

表1 基础信息分析表

维度2业务负载分析。主要考虑因素如表2所示。

表2 业务负载分析表

维度3技术分析。主要考虑因素如表3所示。

表3 技术分析表

维度4风险分析。主要考虑因素如表4所示。

表4 风险分析表

维度5迁移价值分析。主要考虑因素如表5所示。

表5 价值分析表

经验总结看来，对以上5个维度指标和因素的OLTP类业务适合云化，对于有特殊条件的业务系统应该遵循以下原则。

1.3 特殊条件评估原则

有以下特殊条件的业务系统不建议云化处理，本文所描述云化的概念是指基础硬件经过hypervisor层资源管理调度的虚拟机或者提供的裸金属物理机服务(Bare Metal Server，BMS)。

条件1：特殊硬件依赖，比如非云化的硬件密码机、硬件网关类设备。

条件2：实时性要求特别高，比如实时数据采集类、直播视频中流媒体转发类服务。

条件3：大型数据库，比如数据库表数高于200、分布式数据库、交易量高于1 000笔每秒、有复杂的数据库逻辑、有存储过程、有较强的约束条件。

条件4：部分一体机应用。

2 云化评估核心模型的设计

2.1 云化构造的一般描述

云化构造的过程不是简单地把物理环境的应用系统按照资源1 ∶1搬迁到云平台上，而是充分考虑到业务系统的访问压力、网络带宽、资源利用情况、运维管理、应用开发语言、应用所依赖的操作系统、中间件、数据库等因素，重新设计云环境下的软件和应用架构及网络模型，重新考虑各类安全防护手段和策略，以满足应用系统的正常访问和资源利用的最大化，降低固定资产和人力资源的投资。

2.2 核心模型的设计

根据经验，业务应用在云计算环境下设计以下几类模型。

Type 1：简单模式。

本模式为简单模式，总体特点是简单业务架构，单VPC，应用架构为三层架构，分为Web层、应用层和DB层。

每层中单独划分子网和子网掩码，在不同的子网进行访问时，考虑用VFW和安全组等方式进行南北向和东西向流量的防护。架构如图1所示。

图1 Type 1模型

Type 2：中等模式1。

本模式为通用型应用业务类，总体特点是业务架构每层都采用VPC单独划分和隔离，应用架构为三层架构，分为Web层、应用层和DB层三大类VPC，每个VPC内部根据不同的业务逻辑可以划分多个子网网段。通常来讲，在复杂的应用系统中，应用逻辑是由多个子系统或者子模块来完成，相互之间有较强的交互关系和数据同步。不同的子系统或者子模块用不同的子网网络来承载，保证安全性，在后续弹性扩容的时候，也容易根据DHCP来合理规划私网地址，确保子网空间的可用性和可规划性。

VPC之间访问和交互考虑用VFW来隔离，VFW和安全组方式进行南北向和东西向流量的防护。架构如图2所示。

图2 Type 2模型

Type 3：中等模式2。

本模式为重载应用业务类，总体特点是业务架构每层都采用VPC单独划分和隔离，应用架构同样为三层架构，分为Web层、应用层和DB层三大类VPC，每个VPC内部根据不同的业务逻辑可以划分多个子网网段。

与Type 2相类似的是，不同的子系统或者子模块用不同的子网网络来承载，保证安全性，在后续弹性扩容的时候，也容易根据DHCP来合理规划私网地址，确保子网空间的可用性和可规划性。

与Type 2不同的是，有些重载型业务应用不适合用虚拟机来承载，因此考虑用裸金属物理机，物理机和虚拟机的差别这里不再赘述。同时，随着重载业务上云，这些业务系统的重要性也不言而喻，对虚拟机的高可靠要求也越来越高，对于一些核心应用来说，采用HA的技术来保证虚拟机的高可靠，从而来保证业务系统的高可靠用性，满足一定的SLA约束。

同样地，VPC之间访问和交互考虑用VFW来隔离，VFW和安全组方式进行南北向和东西向流量的防护，BMS作为一种资源的服务统一纳管到云平台，按照DCHP的模式来分配所需的子网空间和具体的IP地址。具体架构如图3所示。

图3 type 3模型

Type 4：复杂模式。

本模式为非单DC复杂业务类，总体特点是业务通过不同的数据中心(DC)来保证业务的连续性。在某单个数据中心内部，应用架构同样为三层架构，分为Web层、应用层和DB层三大类VPC组，每个VPC内部根据不同的业务逻辑可以划分多个子网网段。

具体架构如图4所示。

图4 type 4模型

在跨数据中心的链路中考虑3个层次的问题：(1) Web层，通过负载均衡设备来完成对于解析后的目的地址的分配，保证按照不同的区域来就近解析相关目的地址；(2) 应用层，通过自身做应用的集群，可以把应用的状态数据实时或者非实时地同步到对端数据中心，对端数据可以提供近实时的数据服务；(3) DB层，通过数据库软件的集群的复制功能，把数据库数据同步到对端数据中心数据库软件中，这个过程需要底层网络时延的保障，具体的时延要求要根据应用系统的重要性和核心性进行设计。

3 基于国产CPU安全可控的软件适配移植构建过程

3.1 安全可控的认知

数字化进程的飞速发展和近十年互联网产业的发展都清晰地验证了一个事实，不同的产业阶段对IT基础架构和计算能力提出不同的挑战和要求。新应用、新技术、新架构是未来数字化转型的关键，计算平台的创新是数字化转型的基石。

当前，信息安全、自主可控也已上升为国家战略，自主可控计算机是构建自主可控信息系统的基础。而芯片产业是计算机系统和整个信息产业的核心部件和基石，也是国家信息安全的最后一道屏障，芯片高度依赖进口使得整个国家安全受到严重威胁。

芯片的自主可控是整个信息产业自主可控的基础，自主可控芯片将重塑ICT产业新格局，构建平行计算平面[7]。目前，我国服务器芯片自主研发有以下几个方向[8]：

Alpha架构:代表有申威。

ARM(Advanced RISC Machine)架构：代表有华为、飞腾等。

MIPS架构：代表有龙芯。

X86架构：代表有海光、兆芯等。

Power架构：代表有中晟宏芯。

3.2 业务安全可控的适配流程

本文以华为ARM架构芯片鲲鹏920[9]为例来阐述特定的业务系统在进行安全可控的适配一般流程。流程如下：

Step1分析业务系统的软件技术栈。

Step2确定如下指标信息：

1) x86架构的芯片/服务器；

2) 操作系统；

3) 操作系统相关驱动；

4) 编译器；

5) JDK；

6) 软件依赖组件；

7) 开源软件；

8) 商用软件；

9) 自研软件。

Step3对于指标的前8项，获取到支持ARM架构的软件、硬件、相应的版本号，若没有对应ARM版本，则考虑更换为相同功能的ARM对应版本软件；对于指标9，执行以下代码修改适配流程。

Step4判断自研软件的计算机编程语言类型，如果是编译型语言(如C、C++等)，转向Step 6；如果是解释型语言(如Java和Python等)，则继续下一步动作。

Step5判断是否存在编译型类库的情况，如果不存在相关类库，则可以直接使用；否则做类库的移植后，重新打包，转向Step 9。

Step6判断是否为Linux软件，如果不是Linux软件，则可能面临极大的代码改动量，并且有移植不成功的风险；如果是Linux软件，则继续下一步动作。

Step7判断是否存在x86的汇编代码，如有，则统一替换成基于ARM的汇编代码，继续下一步动作。

Step8检查是否存在代码修改点，如有，则修改成基于ARM的版本；如没有，则继续下一步。

Step9重新编译。

应用业务系统基于国产化CPU指令集的适配性迁移是一项比较复杂的工程[10]，以上是迁移适配的一般性流程，同时要考虑到迁移工作量和所用人时等因素开展此项工作。

4 核心模型的网络规划构建

云内部网络访问是一个比较复杂的过程，涉及到安全防护和业务流量的设计，因此需要一个通用的网络模型来规划，防止出现业务网络的规划导致内部网络安全防护性较差。根据本文引出的云化业务模型，构建的统一网络模型如图5所示。

图5 统一网络模型

其中，主要网络流向有以下几个方向，在设计网络中，需要重点考虑：

网络流向1：VPC内部相同子网之间的二层访问。通过安全组访问，典型代表场景有Web集群服务之间的通信。

网络流向2：VPC内部不同子网之间的三层访问。典型代表场景有Web集群服务与应用各类逻辑之间的通信。

网络流向3：不同VPC之间的三层访问，通过VFW虚拟防火墙访问，典型代表场景有Web集群服务或者应用各类逻辑与DB集群服务之间的通信。

网络流向4：虚拟机与物理设备之间的三层访问。也属于跨VPC之间的通信，通过VFW虚拟防火墙访问，典型代表场景有Web集群服务或者应用各类逻辑与第三方硬件或者软件集群服务如认证网关等之间的通信。

网络流向5：VPC虚拟机与第三方资源池之间的三层或者二层跨DC访问。在三层场景下，通过接入路由器接入到云资源池，对于有Vlan网络，配置明细路由；对于VXlan网络，通过VPN的方式进入云网络隧道，完成网络路由的互通；在二层场景下，通过接入或者核心交换机，配置VXlan隧道，实现与VPC的二层互通通信。

网络流向6：外部网络的访问。外部的访问一般在业务平面较多，出口与云最外侧防火墙互联，实现外部网络与云的业务VPC之间的访问。

网络流向7：专网网络的访问。专网部分一般分为业务流量和管理流量，在网络对接上与云的专网网络接入交换机对接，实现专网网络流量的互通，管理流量经由管理交换机实现对接。

5 云化实例分析

5.1 现状描述和分析

某业务系统15台x86架构的物理机部署(Web和应用层、DB层3层架构)，CPU使用率长期持续在5%以下，内存使用率长期持续在10%以下，服务器操作系统为Linux Enterprise 6.4 64 bit，中间件为weblogic，开发语言为Java、Python，数据库是MySQL。在业务访问方面：每年特定时间段会出现业务访问的高峰，并发峰值每秒约在4 000新建连接，业务访问中有附件(标准图片)的上传和下载。

在业务出现访问高峰时，系统经常性出现瘫痪等，页面响应非常缓慢，响应时间在8～10 s左右。通过持续观察可以发现，某几台服务器CPU和内存使用率在98%以上，历史上多次临时扩容服务器，但是未能解决该业务访问问题。

故障出现时，某几台服务器的资源使用率出现较高情况，其他的大部分服务器使用率在较低水平，未出现其他异常情况。排除网络攻击后，可以初步得出结论：此系统整体架构设计不合理，使得某个或者某几个流程成为整个业务系统的瓶颈，可以调整软件部署架构来消除瓶颈。同时考虑国产化相关技术要求，重新设计云化软件部署架构。

5.2 技术评估和云化架构设计

根据对业务系统的分析，本实例业务具备以下特点：

(1) 标准x86架构。

(2) 无特殊绑定硬件。

(3) 实时性要求不是特别高。

(4) 业务不同时段负载波动特别大。

(5) 业务增长不确定较高。

(6) 没有大型分布式数据库。

(7) 没有小型机应用。

(8) 开发语言、中间件、数据库、操作系统评估可以迁移。

根据本文前几部分的评估论述，本业务系统适合部分云化，具备国产化适配的条件。

设计整体架构如图6所示。

图6 业务总体架构

架构具体描述：

注：整体流量防护请参考2.2节核心模型的设计Type3网络模型。以下仅描述本实例相关部分。

Web层：采用全虚拟化部署方案，设立VPC1，在内部划分两个独立子网，完成两个前台无状态业务界面的资源承载，前端挂载软件负载均衡服务，实现对访问2个逻辑的七层负载分担。同时设计自动弹性扩展服务，当节点出现CPU高于60%或者内存高于60%的时候会通过虚拟机镜像自动拉起一定数量的虚拟机提供服务。

应用层：采用全虚拟化部署方案，设立VPC2，在内部划分三个独立子网，分别完成身份认证、接口和交换三个业务的资源承载，前端挂载软件负载均衡服务，实现对访问3个逻辑的七层负载分担。同时设计自动弹性扩展服务，当节点出现CPU高于60%或者内存高于60%的时候会通过虚拟机镜像自动拉起一定数量的虚拟机提供服务。

DB层：采用物理机部署方案，考虑到统一管理和运营资源，物理机采用BMS服务的资源纳管方式。同时设立VPC3，在内部划分独立子网。数据库物理机采用软件集群的方式部署，对外提供virtual-ip负载分担和保证读、写一致性。也可以采用独立物理机部署方案，以专线VPN的方式接入到与云平台Vxlan网络，实现与云的overlay3层路由网络通信。

5.3 国产化适配设计

根据国产化适配流程和原则，进行以下适配和迁移：

开发语言：Java和Python类应用系统参考本文论述的两种语言的移植方法和流程。

中间件：由Weblogic适配为东方通中间件。

数据库：由MySQL替换成Huawei GaussDB。

操作系统：由Linux Enterprise 6.4 64 bit适配为中标麒麟操作系统。

云平台：适配国产云平台。

服务器：由x86架构服务器适配成Huawei Taishan系列服务器。

5.4 改造效果

通过云化模型的技术评估和改造，确定物理服务器数量为3台，进行虚拟化部署，考虑到20%的冗余资源量。云化后服务器减少比为80%。云化前服务器利用率5%，改造后资源利用率在60%左右，资源利用率提升55百分点。同时，投入成本降低80%以上。

国产化部分的性能对比有相关硬件厂商进行单点测试，本文只对资源层面进行对比测试。对所部署的环境进行整体压力测试，按照经验，压力测试采用逐步提升到并发峰值为4 000每秒，观测相关对应变化。

在具体的压力测试实验下，CPU资源均化使用率、弹性扩展与压力测试数值的对应曲线如图7所示。

图7 资源均化使用率、弹性扩展与压力测试数值对应曲线

5.5 效果分析和比对

目前业内OLTP业务在进行云化迁移的时候并没有统一的方法和流程。大都是各个项目或者云平台运营方根据关注点进行设计，关注点主要集中在迁移成本、资源使用量、业务的连续性，没有对整体的架构和流程及SLA进行有效设计。

这种情况存在以下很多问题：(1) 业务和数据迁移过程不清晰，情况严重直接导致业务访问中断。(2) 资源评估不准确，过大导致成本上升，过小导致业务无法正常运行。(3) 云环境下业务架构没有优化，只是物理环境的简单复制，失去了使用云的很多优势，也不能消除掉物理环境下的业务瓶颈。(4) 业务的架构没有得到优化，导致云环境下业务细粒度的安全防护无法有效实施，出现安全紧急事件后无法快速有效地定位和阻断。(5) 国产化的要求更是加大了业务迁移的时间复杂度和空间复杂度。

本文基于云计算框架提出的迁移评估模型和流程，以及针对国产化的适配作为一个整体体系是对OLTP业务云化迁移的技术性参考和流程的梳理，从改造效果看，能够有效地解决暴露的问题。

6 结 语

当前政务OLTP业务系统在云化迁移过程中存在一系列问题，尤其是要满足国家国产自主安全可控的安全要求。本文基于云计算框架对此类业务的云化迁移进行了模型分析和评估，得出了一般性指标的考量，提出了4种核心业务模型，并在此基础上重点基于国产CPU核心指令集构建了安全可控的业务适配和迁移过程，形成了一套体系化云化迁移安全可控的评估模型。

经过实际业务的验证与分析，4种核心模型、网络流量模型及国产化适配流程有较高的应用性和有效性，在业务迁移过程中有较强的指导和借鉴意义。