曹凯:基于SDN的双活HCI超融合架构在医疗信息化建设中的应用

发布时间:2022-03-23
浏览次数:

前言

  医疗信息化具有数据量庞大、数据安全等级高、高可靠性等特点。SDN通过集中面板来控制复杂网络拓扑中的网络流量,提供了全面自动化服务、中央策略控制功能下发和内建安全性,比以往更轻松地扩展和增强数据中心能力,将超融合基础架构中的网络功能虚拟化,帮助超融合系统连接或管理内部流量、数据中心通信和数据中心外的网络,实现基于SDN的跨数据中心超融合双活数据中心,该方案可以更小颗粒度进行横向扩展。通过该架构系统的实际搭建与实施应用,验证了技术可行性和成熟度。

  硬件架构发展历程

  近10年间,医疗信息化与其他行业信息化的发展类似,大致经历了四个阶段:分散式架构、整合式架构、虚拟化架构以及超融合架构。随着用户对应用的可用性、存储性能、存储容量等要求的提高,高度整合式的数据中心架构逐渐变成主流,数据中心的存储设备由直连存储演变为集中式的共享存储模式,服务器通过HBA卡、SAN交换机、FC线缆与存储设备连接,这种架构的推出,有效地提高了存储可用性、利用率、存储设备的可管理性。

  四种硬件架构中,分散式架构基本已被淘汰,整合式架构目前仍用于运算性能要求高的业务场景中,例如HIS系统。本文接下来主要对传统SAN架构虚拟化与超融合架构虚拟化进行对比分析。

微信图片_20220323095640.jpg

图1 医疗信息化硬件架构

  传统SAN架构虚拟化与HCI超融合架构的对比

  随着虚拟化技术的发展使用,数据中心内的服务器体量规模逐渐减少,物理空间占用率高等问题得到缓解,但随之而来的是虚拟机数量的急剧膨胀与参数超配。消耗巨大存储空间的同时,也使得整个虚拟化架构看上去不协调,存储架构臃肿。传统存储虚拟化架构中SAN存储阵列型号必须在存储网关兼容性列表内,同时随着使用年限的增加,运算、存储品牌型号繁多,造成的维保与运维压力逐年递增。传统存储设备受限于其架构,在纵向及横向扩展能力方面缺乏灵活性。

表1 传统SAN架构虚拟化与超融合架构的区别

微信图片_20220323095642.jpg

微信图片_20220323095645.jpg

图2 传统SAN架构虚拟化与HCI超融合内部架构对比

  基于SDN实现HCI超融合架构双活方案

  通过跨数据中心的SDN技术构建满足核心系统双活要求的大二层网络,为医院构建双活数据中心建立坚实基础。下图为医院的数据中心SDN网络逻辑架构图:

微信图片_20220323095647.jpg

图3 基于SDN网络的HCI超融合架构图

  对于承载医院核心系统的超融合平台而言,要满足跨数据中心的业务连续性的技术要求,需要底层网络具备足够的灵活性、可靠性,同时能够保障在站点级别故障发生时,可以快速恢复业务系统,在保障业务连续性的同时,满足医疗行业政策监管需求。

  构建医院超融合架构双活数据中心,主要参考了如下医疗行业规范和标准。

  《医院信息互联互通标准化成熟度测评方案》

  《电子病历系统应用水平分级评价标准(试行)》(2018版)

  《医院智慧服务分级评估标准体系(试行)》(2019版)

  《网络安全等级保护测评高风险判定指引》

  传统虚拟化与超融合架构结合具体应用场景的对比

  本次性能对比测试方案为:选取两家国内排名相近、门诊量/住院量相仿的医院中,运行同类业务的Oracle虚拟化服务器进行对比,出于安全方面考虑,两家医院以医院A与医院B代指,其中医院A使用的是HCI超融合集群,医院B使用的传统SAN架构虚拟化,测试机器为一台办理同类业务的Oracle(NO RAC)服务器,分别导出24小时内的AWR(Automatic Workload Repository)报告进行性能分析,报告截图如下:

微信图片_20220323095649.jpg

微信图片_20220323095655.jpg

微信图片_20220323095658.jpg

图4 医院A的AWR报告截图

微信图片_20220323095702.jpg

微信图片_20220323095704.jpg

  

图5 医院B的AWR报告截图

  首先我们可以直观地看到,两家医院的Host服务器的硬件配置差距明显,从CPU和内存配置来看,采用HCI超融合方案的医院A优于传统虚拟化架构的医院B。接下来我们从Oracle运行情况来看。

  (1)redo size

  redo size主要是用了衡量数据库记录变更的频繁程度,医院A和医院B的transactions基本一致的情况下,医院A的redo size为106683.6(bytes),医院B为130927.1(bytes),该数值越大,往往会产生对LGWR写日志以及和Arch归档,上述两种情形会对I/O造成压力,从数值上看,医院B在规模相当负载下的运行状况显得比较繁忙。

  (2)DB Time

  医院A为16核心CPU,Elapsed总共为1439.89*16=23038.24(mins),DB Time为990.96(mins),指CPU花费990.96分钟在处理Oracle非空闲等待和运算上(比方逻辑读),DB Time与Elapsed的比值为0.043。同理,医院B该比值为0.185,该数值代表Oracle数据库的繁忙程度,数值越高说明数据库越繁忙,从该数值看出医院A数据库的资源更充足,在应对业务高峰和突发高峰时运行更平稳一些。

  (3)DB CPU占比及log file sync(日志文件同步)单次平均等待时间

  医院A的DB CPU占比为57%,log file sync单次平均等待时间为2.64ms,医院B的DB CPU占比为70.4%,log file sync单次等待时间为3.94ms,从以上数据能看出,医院A的CPU消耗指数及日志文件同步单次平均等待时间都优于医院B。

  (4)Db file sequential read、db file scattered read 单次平均等待时间

  医院A 较医院B在db file sequential read、db file scattered read 等指标上有很大的下降,db file sequential read总的等待时间从6482s下降为3844s,db file scattered read总的等待时间从1521s下降为383s,从以上数据能看出,医院A的较大数据量的读带宽要远优于医院B。

  通过对HCI超融合架构及传统SAN架构虚拟化运行的相同业务的Oracle虚拟服务器的性能对比后能清晰直观地看出超融合在底层IO、CPU性能调用等方面的优势。

  小结

  超融合架构在数据中心承担着计算资源池和分布式存储资源池的作用,极大地简化了数据中心的基础架构,而且通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力,同时简化了数据中心双活实现的复杂度,运维侧的压力得到大幅降低,业务系统的连续性得到更好的保障。

  另外,超融合平台支持丰富的数据服务,包括块存储服务、NAS存储服务等,同时具备重复数据删除和压缩功能,可以实现很好的存储效率。

  对于关键业务数据库的管理,可以通过数据库引擎实现一键式部署常用的数据库高可用,如Oracle RAC,SQL Server Alwayson等,并基于超融合自身的存储技术实现关键业务数据库的持续数据保护,一键式数据库配置和数据副本管理服务,管理员能够随时配置、克隆、刷新、备份和恢复数据库,使用自动化服务取代耗时且复杂的数据库操作,可以将资源更多的聚焦于核心业务,免除DBA工作的各种烦恼,期待将来能更多的利用创新技术,辅助信息化的支撑和建设。

  作者简介

微信图片_20220323095707.jpg

  曹凯,山东大学齐鲁医院信息网络中心,Nutanix NCP认证工程师,CISP注册信息安全工程师,山东省医学会医学信息学分会委员。