基于多资源池的医疗数据中心建设实践

基于多资源池的医疗数据中心建设实践[url=]高彭彭[/url][url=]贺兰县人民医院信息中心[/url][url=] 引言

随着“5G+”、“互联网+健康医疗”、智慧医疗等技术的不断发展融合，医院各项业务的正常运行对信息系统的依赖程度也越来越高。通过信息化手段进一步提高系统可用性和稳定性，实现数据中心的节能减排[1]，有效降低中心运营成本，建设无单点故障和瓶颈、“永远在线”、可灵活扩展的医疗数据中心是所有医院管理者的努力目标和方向。

1 概述

自20世纪90年代以来，医院信息化经历了以财务收费为核心的医院管理信息化阶段、以临床业务系统建设为支撑的应用驱动阶段和目前以建设数据仓库、临床数据中心（CDR）、医院信息平台的互联互通导向阶段[2]。以数据科学为核心，整合资源服务临床、科研和决策过程，提高医院的科学化、规范化及精细化水平，正在成为当前医院信息化发展的重要方向。

某医院是当地最大的非营利综合医院，从2010年开始信息化建设。目前全院信息系统包含HIS、LIS、EMR、OA、PEIS、HRP、院感等在内共25个系统、75个子模块。数据库主要有Oracle、SQL Server、My SQL、DB2等，月新增数据容量≥1T，目前总容量为21TB。终端硬件超过500个，服务器和存储设备近40台。因为前期信息化处于分散投入、分批建设模式，导致硬件品牌有14个，其中存储品牌4个，安全设备品牌6个，服务器品牌5个。核心业务通过VMware存储双活技术进行冗余，通过Oracle RAC和Data Guard技术进行数据库的负载均衡和容灾备份。

2 医院数据中心建设需求和目标

随着国家强基层战略和分级诊疗政策的不断深入，医院新技术新业务的应用与开展，该院为进一步满足辖区内城乡居民的就医需求，分别新购MRI、CT、DR、彩超、电子胃肠镜和腹腔镜等多台设备，日数据增长量呈爆炸式增长。智慧病区、移动护理、移动查房、质控系统、院感平台等业务模块的紧密上线，也对计算存储资源需求呈指数增长，对数据中心基础设施的扩展性提出了极大的挑战。

基于以上，医院计划新建以持续发展的临床业务需求为导向，以动态扩展为特征，结合分布式存储和虚拟化云安全的基础属性，打造具有前瞻性和未来云化升级基础的数据中心架构。

建设目标：(1)无单点故障和无单点瓶颈；(2)“永远在线”的业务系统；(3)跨软/硬组建的深度分析能力；(4)中心资源全面软件定义；(4)运维管理方便快捷。

3 多资源池化数据中心建设实践3.1 医院数据中心架构选型

传统医院信息技术发展路线正逐渐从物理部署方式向云化转型，其实施路径大致上分为物理部署、虚拟化、云化（资源整合）与全面云化（业务敏捷）这个过程。本次数据中心项目建设是医院数字化转型的关键工程，将现有的虚拟化烟囱整合为资源池，实现统一管理、共享使用，简化数据中心基础架构，为以后基于业务敏捷的云化架构打下坚实的基础。

超融合架构技术是在一个设备单元内同时具有云计算、网络、数据存储等资源，结合虚拟化技术，包括SSD缓存加速、重复数据消除、数据压缩[3]、多副本存储保证等业务连续性的一系列元素，最终形成一个统一的资源池型框架。超融合架构在数据中心中承担着计算资源池和分布式存储资源池的作用[4]，极大简化了数据中心基础架构，同时以软件定义和多副本存储方式，实现业务系统无单点故障、无单点瓶颈，具备随时分配、随时扩展、性能线性增长的能力。

3.2 建设案例概述3.2.1 超融合集群规划原则

超融合整体架构如图1所示，其集群规划原则如下：

⑴同一个集群尽可能使用同类型服务器，硬件资源尽可能相同，尤其是CPU型号；

⑵规划集群规模考虑资源冗余，CPU、内存和存储资源需额外规划10%-20%的资源；

⑶考虑到资源冗余和集群高可用性，单集群的节点数量要求最少四台。

[url=][/url]

图1 超融合整体架构 [url=]下载原图[/url]

3.2.2 虚拟机计算资源需求计算

按照医院未来业务发展，在不考虑图形资源消耗处理的情况下，非核心业务平均每个虚拟机需要资源为：四个v CPU,32GB内存，则25个业务系统需要100个v CPU和800GB内存资源。核心业务EMR和HIS，需要至少一台应用服务器和两台数据库服务器做负载，每台服务器规划计算资源16v CPU和64GB内存，因此按照现有业务计算共需148v CPU和1T内存。

考虑10%-20%的冗余度，本项目超融合平台最佳配置为192v CPU,2304GB内存，考虑冗余节点，实际超融合平台单节点配置CPU 48核，内存576GB，五台服务器做超融合集群。

3.2.3 虚拟机存储资源需求计算

虚拟机硬盘需求总量=v DISK*每个虚拟机需求数量，按照40个虚拟机设计，平均每个虚拟机规划需要800GB硬盘，则需要32TB。

结合超融合v SAN虚拟存储多副本设计原则，则整个超融合平台磁盘需要裸容量64TB。按照20%冗余度设计，需要至少配置76TB总硬盘容量（5个节点），平均到每个节点则配置为19TB(8块2.4TB SAS硬盘）。

超融合平台采用5节点组成超融合集群，为医院全院信息系统业务提供高性能的计算、存储资源，并满足业务连续性和高可用要求。

3.2.4 网络资源需求计算

网络资源在规划时充分考虑未来云化架构的扩展性，利用虚拟网络技术简化系统运维。在本次项目中，内网核心交换机是两台华为Cloud Engine 16804，通过40GE光纤链路聚合提高核心层的网络可用性，同时实现负载均衡。数据中心网络系统采用Vx Lan和SDN技术将网络的控制层和数据转发层相分离，实现网络的快速部署和流量监测的可视化，可以第一时间定位故障点的同时，虚拟端口组技术也有效提高数据传输效率。

3.3 基于多资源池数据中心规划

与传统的按照各类基础设施进行逻辑资源池的划分不同，基于多资源池数据中心规划如图2所示，以业务和区域职能将数据中心划分为内网计算存储资源池、外网应用资源池、桌面云资源池、安全资源池和容灾备份资源池共五大资源池，形成一个绿色、高效、一体化的医院数据中心整体架构。

[url=][/url]

图2 基于多资源池数据中心架构 [url=]下载原图[/url]

3.3.1 内网计算存储资源池

承载内网核心业务数据，采用5台x86物理服务器，每台2颗24核CPU、576G内存和23TB存储（含3.84TB SSD固态硬盘做缓存盘，19.2TB SAS硬盘做容量盘）。内网计算存储资源池可创建虚拟机40-50台，存储均采用多副本和分布式技术，有效保证高峰时访问并发量和业务连续性。即使其中某一台物理服务器出现故障，超融合架构会通过VMotion功能自动将应用漂移至其他服务器，在整个过程中，业务不会中断，终端用户几乎没有感知。

3.3.2 外网应用资源池

随着“互联网+健康医疗”、智慧医院建设和移动支付等便民惠民举措的不断推进，大量内部应用系统需要对外和互联网侧作数据交互。为保障医疗数据安全，通常使用网闸做区域网络内的安全隔离。在互联互通需求日益增多的当前，传统购置物理服务器做前置的方式一方面无法满足灵活扩展和应用冗余，另一方面随着前置服务器规模的扩大，不仅资源浪费，维护和管理也越来越困难。

本次项目建设在互联网侧采用4节点超融合平台，统一外网应用场景，综合前置服务器对计算存储资源性能要求不高的特点，采取利旧升级方式，改造目前在用服务器，形成外网应用的虚拟集群化管理，实现服务器资源的整合。

3.3.3 桌面云资源池

桌面云目前主要分RDV、IDV和VDI三种，不同的架构模型有各自的优势和应用场景。桌面云技术将硬件虚拟化和桌面化，达到按需分配、集中管理的效果和模式。结合医疗行业背景，在本次项目中选择VDI平台构建一站式桌面云资源池。采用两台高性能服务器，组建总容量达80核、512G内存的主备桌面云资源池。在医院内网环境内，使用ARM架构下的瘦终端，接入桌面云系统，获得与传统PC一致的使用体验，不同科室不同业务部门灵活地分配资源配置，实现终端高可用和高可靠性[5]。

3.3.4 安全资源池

安全资源池基于软件定义技术将数据中心架构所需要的各项安全能力统一集成到通用的硬件资源设施中。摒弃传统的物理安全设备堆叠，采用虚拟安全资源池的方式，实现包括访问控制、IPS入侵防御、WAF防护、网页防篡改、安全审计、漏洞扫描等在内的各类安全组件。灵活配置、按需开启，有效提升基础资源利用率。在近几年来国内外信息安全事件层出不穷的大背景下，虚拟安全资源池升级与扩展也具有得天独厚的优势，有效的简化运维和提高安全管理效率，完成安全配置的自动化部署和统一管理。

3.3.5 容灾备份资源池

由于医院业务的特殊性，任何人为或自然因素所导致的应用或系统中断、丢失，都会造成巨大的经济损失[6]，因此一套完整的容灾备份体系是医院信息化建设中需要重点考虑和规划的。本次项目在本院区结合Oracle RAC和Data Guard等技术实现数据库快速切换和灾难性恢复，同时本地与云端的双活主备机制，将数据中心和云端业务实时同步并实现秒级切换。在本地机房出现网络或灾难性服务故障时，终端用户访问自动切换至云端，整个过程无需人工操作，业务不受任何影响。云端灾备资源池通过万兆光纤专线和本地数据中心直连，PRO和RTO趋向于零，支持任意时间节点的数据回退，实现对信息系统数据、应用等整体容灾备份。

4 结束语

基于多资源池的医疗数据中心建设可以极大的满足医院在目前“互联网+健康医疗”、移动医疗和网络安全的发展需要，是传统医疗行业在未来信息化建设发展中的有效尝试和实践，同时也实现了应用部署敏捷化、运维自动化和统一管理的要求，有效提升全院业务系统性能，保障了医院的业务连续性和稳定性。

[/url]