智慧医院HIS系统存储架构升级与改造难点交流探讨总结

HIS 系统是一个覆盖医院所有业务和业务全过程的信息管理系统，是医院信息化的核心和基础。传统的 HIS 系统已经不能满足智慧医院的建设要求，需要以智慧医院建设为目标，重新进行设计和规划，对数据质量、业务流程和系统互联互通等方面进行系统化整改。同时，在 IT 基础架构方面也需要进行重新规划和建设，与升级改造后的 HIS 系统相匹配。 IT 基础架构需要具备高性能、高可靠性的同时兼具灵活性，切实满足智慧医院的建设要求。

智慧医院的建设前提是实现医院数据互联互通和信息共享，对 HIS 系统的升级改造，首先要解决数据存储问题，面临的技术挑战如下： 1 、新的存储系统采用何种架构才能满足智慧医院对 HIS 系统的要求，解决性能、可靠性和灵活性的问题？ 2 、 HIS 系统数据存储在设计过程中，应该选择集中式架构还是分布式架构？ 3 、 HIS 系统采用不同的存储架构，对数据的互联互通和共享整合有哪些影响？ 4 、智慧医院的 IT 存储架构与传统医院信息化相比有哪些特点和变化？ 5 、 HIS 系统如何帮助医院实现数据标准化和统一化？

为了帮助医疗企业 IT 从业人员在智慧医院建设的趋势下，就如何设计升级改造后的存储架构这个课题，社区组织了本次“智慧医院 HIS 系统存储架构的升级和改造”，社区力求通过本次活动能够给医疗同业带来一些实践参考经验以及方法，以助大家能够理清思路、合理决策以及科学做好自己的规划建设工作

一、智慧医院存储架构讨论

【Q 1】智慧医院的IT存储架构与传统医院信息化相比有哪些特点和变化？**

【 A1 】 zyp8365, 数据库管理员 , 广东省中医院

智慧医院在传统以 HIS 、 LIS 、 PACS 等信息化代表的系统基础上，不断在人工智能 + 医疗，互联网 + 医疗，医疗大数据等领域朝着应用多元化，服务微小化，交互网格化，数据复杂化等趋势发展。反应到存储架构，要求底层存储能支持更大体量的数据，更好的性能，更优的灵活扩展性。个人觉得，传统的信息系统应用是医院信息化的根，智慧医院应用建设是信息化的枝与叶，所以不能笼统的说到底是集中式还是分布式的存储架构更适合智慧医院的建设要求，而应该根据医院智慧化建设的所处阶段及现实需求，在智慧医院整体建设规划的框架下针对性的讨论存储的架构

【 A2 】 犹大 , 医疗解决方案高级专家 , 华为数据存储解决方案中心

华为智慧医疗的理念：

1 、服务为本，搭建开放性智慧医疗基础平台，提升患者就医体验

2 、数据融合：将分散在各医疗业务系统中的数据集中管理、挖掘、传递出更大的价值，支撑园领导层的辅助决策

3 、构建生态：华为只提供数据基础设施，希望联合伙伴，一起共同为客户提供智慧医疗整体解决方案

因此，结合华为智慧医疗的理念，华为提出了智慧医疗的双模 IT 双轮驱动架构：院内信息中心和大数据中心，共同驱动智慧医疗前行。院内信息中心是数据生产区，最终流向大数据区域；而大数据区域经过大数据计算、分析后反哺信息中心，提升辅助诊疗的能力，两个中心通过互联互通平台的统一标准进行数据融合。

针对院内信息系统，主要是以 HIS 、 LIS 、 RIS 、 EMR 等核心应用系统为主，这类系统对存储要求就是快和稳，华为提供了 OceanStor 全闪存构筑，而对于 PACS 、大数据中心等海量数据而言，低成本和高扩展是主要诉求，因此我们提供了 OceanStorage 分布式存储构筑底座，通过两个基础底座的融合，实现智慧医院的架构永固、技术数据融合和业务创新的诉求。

【 Q 2 】智慧医院是否需要脱离生产库做一个数据仓库，建议采用什么存储架构？

【 A1 】 zyp8365, 数据库管理员 , 广东省中医院

生产库是 OLTP 系统，数据仓库多为 OLAP 的系统服务的，所以两个业务场景是不一样的。当然当医院体量不大时，两个混在一起影响并不特别明显，但是如果医院体量较大，还是建议分开，独立做数据仓库。至于存储架构，还是要看实际运行的业务场景和压力状态，集中式存储架构主要瓶颈在存储控制器，当磁盘数量增加时，控制器瓶颈效应会凸现，而分布式也没有这个问题，它的问题主要在交换网络及维持数据统一管理上，扩展到多少时会出现性能指数下滑的瓶颈需要进行严格的测试。但是从数据中心，数据仓库的长期发展来说，还是建议使用分布式的架构，比较灵活易扩展

【 A2 】潘延晟，系统工程师，第十区。散人

智慧医院的基础一定是基于大数据分析的，而大数据分析的根本其实是数据仓库生产库是你医院业务运行的库。随着医院业务的不同也会有多个，但是大数据分析是要把医院中所有的业务汇总。包括病例，病人资料。财务等等的信息全部融合，这就需要将多个业务部门的生产数据库通过 ETL 汇总到数据仓库。打通所有的数据孤岛。目前数据仓库采用分布式的架构居多。在实际应用中还是要结合大数据分析系统来搭建数据仓库的存储架构。

【 Q 3 】智慧医院环境下医院信息系统“两地三中心“的灾备解决方案中对存储架构有何升级拓展和改造建议？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

不管是哪种方式的灾备解决方案，首先应该考虑医院的系统的实际体量，以及上层实际使用业务场景要求，而不是一种方案吃遍所有医院信息系统，这样不符合医院需求及成本的预期。 RTO 和 RPO 要求高的系统，可以通过两地三中心的灾备解决方案，如果要求不高的，也可以选择更加经济的灾备方案满足需求。如选择两地三中心的解决方案，应充分考虑业务需求及网络链路条件来选择复制方式 ( 是同步亦或是异步 ) ，如预算较紧，灾备端的存储可选择比生产环境低一点档次的，容量相同的存储。实施阶段，应该充分测试两地三中心的方案，测试应全面覆盖各类故障场景，形成可实际操作的应急处置文档，以备系统实际使用中遇到问题时可根据文档快速进行系统恢复

【 A2 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

“两地三中心”容灾方案中表示具备三个数据中心，即生产中心、同城灾备中心和异地灾备中心。对医院信息系统而言，同院区的双活容灾中心已是必备的要求，要求同院区的数据中心能够同时对外提供业务，即我们所说的 AA 双活，这样生产中心故障下，能做到 RPO 和 RTO 为零切换到双活中心。

如存在新院区的情况，可以考虑在新院区部署异地的灾备中心，形成两地三中心的容灾解决方案。这样即使老院区的双活中心故同时障情况下，新院区灾备中心同样可以进行业务的快速拉起。并且，随着业务和技术的发展，传统的异地灾备中心集容灾和备份与一体，不但可以做到数据中心的容灾，还可实现异地数据的备份，这样可以实现异地灾备的双重保护。

当然，具体是双活容灾还是两地三中心容灾案，还是需要根据医院的实际业务要求来定。对容灾要求更高的医院可以选择两地三中心方案，但要求不是太高，可以选择双活数据中心方案。

【 A3 】 TBTB ，技术总监 ，洪雪

同城同步复制、异地异步复制

【 Q 4 】医院 HIS 、数据中心、 BI 、集成平台等系统使用统一存储还是分别使用不同的存储？备份是否统一管理？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

这个问题主要先看医院的体量，如果体量小，一套存储能搞定，就没有必要分开，造成维护的麻烦。如果体量大，还是建议要分开，因为 HIS 和集成平台是 OLTP 的业务类型，更看中 IOPS ，建议用高端高性能高可靠的存储去承载，数据中心和 BI 是 OLAP 的业务场景，建议用大容量，扩展性较强的存储架构去承载，也非一定要分布式架构，只要符合需求即可。备份建议逻辑统一管理。针对信息不同层次 ( 物理层，数据层，应用层等 ) ，备份的需求、方式、介质等都会不一样，应统筹考虑以保障信息安全

【 A2 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

医院 HIS 、 BI 、集成平台以及备份的业务特点是不一致的，比如 HIS 、集成平台系统以结构化数据为主，要求高可靠和高性能，可以考虑集中全闪存储； 数据中心和 BI 数据量较大，对成本诉求更高，可以考虑低大容量、高扩展的存储，不管集中式还是分布式，只要符合这些要求即可；因此在条件允许的情况，可以分别使用不同的存储，但各存储之间需要进行统一的管理和运维，这样可以满足不同系统的业务诉求，各个系统之间可以更好的进行物理隔离，并且可以统一运维。

【 A3 】匿名用户，匿名用户

his 采用集中式存储，提供高 iops 低延时存储空间；

其他的建议采用分布式存储， pacs 业务容量需求旺盛，分布式存储扩容平滑，医院后续需要建设智慧医疗等不可避免的需要建设大数据分析平台，分布式存储可以提供多种接口满足分析需要和提供高容量。

【 Q 5 】集中存储存放单一 HIS 数据？还是可以 LIS 数据、 EMR 数据可以一并存放？各有什么优劣？

【 A1 】 lisiqibj ，存储工程师，华为数据存储解决方案中心

可以一并存放，集中式存储可以在一台存储上划分出多个逻辑空间，映射给前端不同的应用，在应用端看起来数据是完全分开存放，互不干扰的；同时还可以结合存储端的 QoS 、缓存分区等特性，针对不同的应用划分不同的网络带宽、内存资源等等，以保障核心应用的性能平稳，所以优势是可以增加资源利用率，便于管理员做整体运维。

当然，如果医院的数据量大，就诊人数多且密集，单系统存储性能已有瓶颈，也可以将 HIS 、 LIS 等数据单独存放，优势是可以避免一套存储故障影响院内多套系统，也可分散性能压力。

根据您的描述，我们认为华为 OceanStor 免网关双活存储方案就非常适合您的业务需求，相比您现在的网关 + 存储的两层架构，华为免网关双活方案架构更精简，故障点和系统瓶颈点更少，更适合医院内多业务并存的数据存储场景。

华为目前在医疗行业有大量的双活案例，限于交流的篇幅不一定今天可以面面俱到，华为可以提供专家进行一对一技术沟通，如果需要您反馈给社区或私信华为专家联系。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

HIS 、 LIS 是同类业务， PACS 要区分数据库、应用及图像。 HIS 、 LIS 和 PACS 的数据库及应用可以放到这个集中存储上，主要的影响是，鸡蛋放到一个篮子里，当存储出现问题，会在这上面的所有系统都不行，压力会更大，优势是能充分利用存储资源， EMC+VPLEX 的双活架构比较稳定可靠，系统放在一起容易管理维护。另外， PACS 的图像数据因为比较大，除非不差钱，建议单独放到性价比更高的存储上，可以用 NAS 或对象存储均可，当然直接 FC SAN 也可以，相应的容灾，做存储复制即可

二、 HIS 系统的存储的选型问题

【 Q 6 】 HIS 系统数据存储在设计过程中，应该选择集中式架构还是分布式架构？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

HiS 系统数据存储，从目前 HIS 应用的量及范围来看，还是建议使用集中式架构。建议理由包括 :1.HIS 作为医院最核心的业务系统，尤其关注安全和高效两项指标，集中式的双机双活架构很好的满足这两项指标，而分布式的优势却发挥不出来，性能容易消耗在分布式仲裁及流量转发上，信息流非最短路径。 2. 现在的存储单机硬件性能已经十分优越，扩展性也很强，能很好满足 HiS 业务需求； 3. 从维护的角度看，集中式在医院使用率及熟悉度比分布式更高，医院维护人员更有经验也更容易维护

【 A2 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

HIS 核心存储设备中的数据是医院最重要的生产数据，其业务特点是一个相对稳态的业务，建议使用集中式架构。对医院 HIS 信息系统而言，不发生系统性风险是最基本的要求，并且性能要足够好，能够给患者提供更好的就医体验。因此对于 HIS 核心存储设备的选型，高可靠和高性能的集中式存储可以很好的满足 HIS 系统对存储的要求，例如华为 OceanStor Dorado V6 全闪存存储，在性能上通过自研的芯片，在传 - 算 - 智 - 存 - 管关键路径进行加速，采用盘控 + 芯片配合的 FlashLink 技术以保障平稳性能，并且采用了端到端的 NVMe 架构，提供业界最快的 0.1ms 时延，在可靠性上， 通过 SmartMatrix 全互联架构，容忍控制器 4 坏 3 ，甚至 8 坏 7 以及端到端 A-A 设计，确保 HIS 核心业务永远在线，以及在硬盘、架构、方案、系统等 5 级可靠设计， 为 HIS 系统提供 99.99999% 的全方位数据保护。

【 Q 7 】新的存储系统采用何种架构才能满足智慧医院对 HIS 系统的要求，解决性能、可靠性和灵活性的问题？

【 A1 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

医院 HIS 系统是医院最核心业务系统，承载着整个医院的基础工作平台，串联挂号、划价、收费、配药等全流程，大家也越来越认识到稳定和高效是 HIS 系统核心诉求，对于 HIS 而言，集中式存储是很好的选择，架构可以参考如下：

1 、 全闪架构， NVMe 架构逐步凸显
传统的 SATA 盘已逐渐不满足 HIS 存储对性能的诉求，一旦 HIS 系统建设完成，需要保证至少 5 年内上层应用不出现存储层的性能瓶颈。随着闪存技术的快速发展，目前全闪存存储已经成为各家主流存储厂商的标准配置，闪存技术日趋成熟，已经逐步成为 HIS 存储的首要选择。并且部分医院开始选择 NVMe 改良型全闪作为 HIS 存储的选型趋势，因为 NVMe 全闪相比原生的 SSD 全闪，性能和时延更优，更容易满足 HIS 对存储的高性能要求。

2 、 双活架构
当单数据中心存储故障后，可能会导致业务长时间中断，甚至数据丢失。传统的单数据中心无法保障 HIS 的稳定性，因此 AA 双活数据中心已经成为 HIS 存储的首要选择。 AA 双活存储提供了免网关的 AA 双活容灾：首先能同时提供业务， 生产中心故障下，能做到 RPO 和 RTO 为零切换到双活中心；其次因为是免网关双活，建设成本更优，无网关故障点更少。这样任意数据中心故障，都不影响 HIS 系统的稳定运行，可以确保 HIS 系统的 7*24 小时稳定运行。

3 、扩展性
当前集中式存储可靠性和灵活性都能满足后续 HIS 的扩展性，控制器和盘都能做到在线扩容，并且不影响现网业务

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

不同的存储架构有不同的优缺点，集中式的存储架构能有较高的性能和可靠性，分布式则更加灵活。 HIS 系统作为医院最核心的业务系统，对 IOPS 和业务连续性要求更高，个人建议集中式的存储架构。集中存储有更高的高可靠性，另外现在的单台存储的 IOPS 已能很好满足医院的性能要求，可扩展性和灵活性也能满足现在医院 HIS 的扩展体量

【 Q 8 】 HIS 系统采用不同的存储架构，对数据的互联互通和共享整合有哪些影响？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

个人觉得对实现的效果是没有影响的，存储架构是物理层面的问题，数据的互联互通及共享整合是数据层面的问题，物理架构的不同会影响数据互联互通及共享整合的实现方式和途径，但是最终效果是能实现的，集中式的存储架构数据提取和汇总更方便点，分布式存储架构虽然物理分散，但是都会有统一的逻辑控制中心，对接方式差不多

【 A2 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

华为提供 OceanStor 全闪存双活解决方案，不改动现网架构、数据库和医疗软件、运维方式，对 HIS 系统读写 IO 进行端到端加速，极大提升 HIS 系统的响应速度；同时采用 HyperMetro 免网关双活方案，替换原有的 VNX 存储配合 VPLEX 网关的组合双活方案。 2 台 Dorado 全闪存互为镜像，数据可以在两台全闪存之间实时同步，并能在设备故障时提供毫秒级别的快速切换，确保医疗关键业务的连续性。

由此可见不同的存储架构对客户和应用软件本身是无感知的，对数据的互联互通和共享整合没有任何影响，当然华为一直以来也在积极的参与医疗行业的标准的制订，我们会携手 HIT 厂商共同服务于广大的医院用户。

【 A3 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

对于应用层面没有太大区别，但是对于系统底层设计有区别。

传统 his 系统基本都采用集中式存储， FCsan 居多，方便本地部署，架构稳定成熟。
而一些医疗集团由于需要统筹整合各医疗分支机构，已开始探索分布式架构的系统部署方式，这在硬件层面就提出了许多新要求。高并发，易扩展，数据同步等问题促进了分布式存储的发展，也让行业看到了不同的解决方案，这对于一些多院区部署统一系统的医院来说比较重要的意义

【 Q 9 】医院建设 his 系统数据库和应用如何选择存储？

【 A1 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

医院 HIS 系统是医院最核心业务系统，承载着整个医院的基础工作平台，串联挂号、划价、收费、配药等全流程。系统卡顿会严重影响患者就医体验，业务中断会影响整个医院的正常营业，因此医院 HIS 系统对存储要求高可靠性和高性能，其选型原则如下：

1 、存储设备可靠性
HIS 核心存储设备中的数据是医院最重要的生产数据，对医院 HIS 信息系统而言，不发生系统性风险是最基本的要求。因此对于 HIS 核心存储设备的选型，其首要指标就是存储的可靠性，这里的可靠性包含了三个层面：

一是存储设备器件可靠性，包含了主要器件的冗余性设计，支持热插拔等。二是存储设备整机的可靠性，包含了整体硬件架构是否支持多控制器，是否支持控制器四坏三甚至八坏七。三是对于各灾备特性的支持，包含存储层双活以及两地三中心的支持度，双活仲裁机制是否可以保证常见故障场景下业务的连续性和数据不丢失。

2 、存储设备高性能
对 HIS 系统而言，一旦建设完成，需要保证至少 5 年内上层应用不出现存储层的性能瓶颈，随着闪存技术的快速发展，目前全闪存存储已经成为各家主流存储厂商的标准配置，闪存技术日趋成熟。就闪存技术而言，目前市场上的全闪存主要包含了原生全闪存和改良型全闪存两大类：原生全闪存即是针对全闪存介质全新研发的存储操作系统，这类存储的特点是可以最大限度发挥出全闪存介质的高性能的特点，但是对传统的存储容灾特性支持度较弱；改良型全闪存即在原先高端混合存储的基础上对存储操作系统做一定的改良，从存储 IO 路径和存储协议等方面去做修改适配，在不影响原有存储特性基础上，尽可能发挥出全闪存的性能优势。因此对医院 HIS 存储而言，建议采用改良型的全闪存，这样可以更好保证 HIS 系统的性能。

3 、后期运维支持力度
对于 HIS 核心系统存储，采购和交付只是存储生命周期的很少一部分，交付后的运维工作才是运维人员最主要的工作，这里就需要存储产品好运维、易运维，需要存储厂商在运维保障上提供足够的支持，因此在运维这块需要考虑实际运维人员的技术能力、新产品的学习成本、厂商本地化服务能力等。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

HIS 建设数据库和应用的架构选择应分开，数据库可以选择如双机双活全闪存储，存储底层也可以建设 CDP 及其他备份一体机的方式，保障数据的备份，数据库层面通过 RAC 、 dataguard 等保护方式，做好数据逻辑层面的保护。如果体量大，预算又足够，数据库服务器建议用物理机。

应用服务器，建议搭建私有云，如 vsphere 等 , 通过虚拟化平台的 HA ，保障应用服务器的高可用，另外应用服务器的部署、更新等操作都极为方便， vmware 有很多适配的备份软件和工具，都能很好的对虚机进行快速备份和恢复，也极大的保障了应用服务器的安全性。

【 A3 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

我们单位正好面临更换全套 his 系统，谈谈设计架构：
His DB 部分：
1 、高性能四路服务器（高主频 CPU 选型取向， 1T 内存） 3 台安装 vsphere 系统组成虚拟化，配置多块万兆网卡及 32GHBA 卡
2 、配置双引擎共四控存储网关，配置 infinity band 做网关互联，配置小型 ups 规避 infinity band 卡的掉电风险
3 、配置 2 台全闪存储双活
4 、数据库在虚拟化层上搭建 rac ，存储 rdm ，裸磁盘映射给虚机，主机上的网卡设备映射给虚机做心跳线，剩余的空间做 VMFS 丢给虚拟化备用
5 、虚机调配置非常方便，虚拟化层可迁移，有 HA ，做 RP4M 等 CDP 也方便，针对虚拟化的监控 VROP ，针对虚拟化的备份 Veeam 都通用。

His 应用部分：
1 、 6 节点全闪 vsan ，缓存盘采用 NVME 傲腾盘
2 、 CPU 选型选择多核心的类型，单节点 512G 内存
3 、全院已有多套虚拟化集群，统一 VC 管理，互相打通， veeam 灾备， cdp 部署，延伸集群的建设都非常方便，可维护性极高。

【 A4 】匿名用户

极高性能使用物理机 + 全闪存双活， 2 台或多台物理机搭建 oracle rac 集群，存储做双活。一般日均接诊量低于 5000 人的医院，可以考虑虚拟化或者超融合。

【 Q 10 】 HIS 的数据存储问题？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

值得提出的是，如果想系统越可靠，相应的系统架构的复杂性会越高。系统可靠性问题应该从存储、服务器、数据库、应用等多个层面去统筹考虑。楼主数据库是 sqlserver ，得看数据库版本，首先建议先将数据库升级到 sqlserver2014 等较为稳定的版本，然后可以使用 sqlserver 可用性组等双机双活等技术实现高可靠，就不用借用 ROSE 等第三方双机软件来实现。
其次要说明的是双机架构主要是防止物理层故障导致的高可用危机，对于数据逻辑故障，还要通过 mirror ，数据库备份等数据备份还原机制来实现。

针对数据安全性，如勒索病毒问题，应该秉持着防止病毒能入侵，入侵后不能造成破坏，破坏后能恢复，恢复后能吸取教训完善漏洞的宗旨来构建我们的信息安全体系，而不应该仅从数据安全的角度来考虑，所以包括入侵检测，防火墙，杀毒软件，数据库备份还原、堡垒机、规章制度等网络、数据、主机、行为等多维度全面的去统筹信息安全建设防止信息安全的木桶短板效应

【 A2 】 lisiqibj ，存储工程师，华为数据存储解决方案中心

HIS 系统存储的是医院的核心数据，如何平衡系统的安全性、性能、架构的精简性是很多医院用户关心的问题，如采用 Rose 软件做主机端的高可用虽然可以补齐部分数据库本身特性，但势必会增加系统复杂性。

建议主机端使用新版 SQL server 自带的双机组件，实现上层服务器、数据的高可用；存储端我们推荐采用华为 OceanStor Dorado 全闪双活 2.0+ 解决方案，该方案可同时解决数据逻辑性错误和非逻辑性错误的问题，基本可以解决绝大多数的数据存储风险问题。

华为 OceanStor Dorado 全闪双活 2.0+ 方案架构如下：

1. 生产业务配置存储双活保护，单套存储设备故障业务不中断
2. 在生产存储与灾备存储之间配置数据复制，实现远端容灾保护
3. 在其中一台生产存储中配置 HyperCDP 连续保护副本（以 Dorado 为例），生产存储提供双活和秒级数据连续保护能力
4. 与灾备存储上配置 HyperSnap 副本保护，灾备存储同时提供容灾和备份保护的能力。
5. 解决方案通过华为灾备管理软件 BCManager 提供容灾可视化、容灾管理、数据保护等策略配置和一键式操作能力
   最终实现效果：仅需三台存储，在不增加网关和其他额外硬件的情况下，即可实现双活、远程复制、秒级连续数据保护功能，极大提高 HIS 系统数据安全性。

【 Q 11 】 HIS 系统高可用？

【 A1 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

对于问题中的双活读写性能以及脑裂等问题，再谈一下华为双活的实现方式，希望对问题解答能有帮助：
1 、华为双活方案针对通过 FastWrite 功能对阵列间数据传输进行了协议级优化，应用 SCSI 协议的 First Burst Enabled 功能，将写数据的链路传输交互次数减少一半。
正常的 SCSI 流程中，写 I/O 在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。利用 FastWrite 功能，优化写 I/O 交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，将跨站点写 I/O 交互次数减少一半。通过协议的优化，能降低双活的读写时延，进一步提升双活性能；
2 、其次，华为双活方案是基于免网关实现的，不用单独建设网关就可以进行双活的部署，这样首先建设成本降低了，再者少了网关的交交互，双活性能相比网关双活能进一步提升 30% 。
3 、 最后，针对脑裂问题，当提供双活 LUN 的两套阵列之间的链路故障时，阵列已经无法实时镜像同步，此时只能由其中一套阵列继续提供服务。为了保证数据一致性， 华为双活通过仲裁机制决定由哪套存储继续提供服务。华为双活提供了两种仲裁模式：
1 ）静态优先级模式
2 ）仲裁服务器模式

配置双活 Pair 前，需要配置双活域，双活域为逻辑概念，包括需要创建双活关系的两套存储阵列和仲裁服务器。每个双活 Pair 创建时均要选择双活域，每个双活域只能同时应用一种仲裁模式，当双活域已添加仲裁服务器，且仲裁服务器与两端双活阵列任意一端链接正常时，双活域自动协商为仲裁服务器模式，否则切换至默认的静态优先级模式。

仲裁服务器模式比静态优级模式具备更高的可靠性，可保证在各种单点故障场景下，业务连续运行。因此，华为双活方案推荐采用仲裁服务器模式。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

的确，每一种 HIS 高可用的方案都有自己的优缺点，主要看医院的取舍问题。本地 SSD ，这种方式成本低，实现方便，单台服务器就能实现，但是弊端是容灾只能通过数据层面去实现，而且单机稳定性较差，现在的 HIS 系统，只要是稍微有一些体量的都不建议使用。存储镜像复制的方式，这个是传统的容灾方式，可以实现 RPO=0 ，但是因为需要做容灾主机切换，所以 RTO 不等于 0 ，但是相对于单机来说，存储作为经过多年信息化锤炼的产品，稳定性比单机 SSD 更好，数据安全性更高，磁盘管理功能更多，如快照，精简等。存储双活在稳定性和安全性也比存储复制的更高，但是也因为对接设备更多，更复杂，成本也更高，实际操作维护更复杂，当然会出现楼主所说的诸如脑裂和链路的问题，但是不能因噎废食，这些问题每个存储厂家也有比较好的解决方案，针对上层应用来说是透明的。性能上楼主顾虑影响不大。

而且值得提出的是，我们考虑 HIS 高可用的时候不能仅仅停留在存储层面，而应该在数据层面，应用层面，充分考虑 HIS 系统的各类风险去规划我们的容灾备份架构，如楼主上述所说的各种方式，都只是针对物理主机或存储故障的应对方案，当数据误删除或其他逻辑故障也没有办法解决，所以要考虑诸如 CDP ，数据层面的数据库 dataguard 等备份方式，或者是其他的定期备份等，以应对 HIS 存在的各类风险

【 Q12 】在医院预算有限的情况下在搭建整体 his 系统时如何选择高性价比存储系统，主要看中哪些性能参数？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

HIS 是 io 密集型的系统，选择存储时首先要关注存储的 IOPS ，第二个要关注存储的内存和 CPU 处理能力，第三个要看存储的盘数和转速，盘越多越好，第四个是容灾如复制，快照许可等软件支持度。

【 A2 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

HIS 系统对医院的重要性不言而喻，性能和可靠性是关键。针对性能， SSD 全闪是趋势，但考虑中小型医疗机构， IOPS 要求不像大型医院这么高，并且预算有限，可以考虑使用 SSD+NL-SAS ，通过 SSD 加速也能满足中小型医院的 IOPS 性能。针对可靠性，这一点必须要保证，一个是阵列内的可靠性，比如控制器要能做到四坏三，器件冗余等，另外一个是阵列间的可靠性，免网关 AA 双活可以有效的保证。

【 A3 】匿名用户

HIS 系统大部分为 C/S 架构的应用，其中数据库应用大部分客户采用的是 Oracle 数据库。 HIS 系统属于 IO 密集型的应用，对内存的大小和磁盘的 IOPS 要求都比较高， HIS 系统的性能要求和医院的日就诊量有关，在 HIS 系统进行资源配置时磁盘性能和内存大小需要进行合理规划和配置才能保障业务系统的正常稳定运行。 HIS 系统涉及到医院日常运营的各个流程，因此 HIS 系统对可靠性要求极高，不允许出现异常中断的情况。 HIS 系统的数据库大部分为 Oracle 数据库，部分为 SQL Server 数据库。

故选择存储时需要兼顾安全性和性能，存储双活必选，存储集群需要考虑到整体的延时和 iops ，以一个日均接诊量 1w 人的大型三甲医院的 his 系统为例，其需要 8000 个 iops ，存储访问延时低于 5ms 。

【 Q13 】 HIS 系统要不要上云？ HIS 上云的与本地传统架构在应用、备份、容灾上有那些优缺点？

【 A1 】 nightdxl ，智能存储解决方案 , 华为数据存储解决方案中心

医院 HIS 系统的本地传统构架，应用相对独立，备份和容灾主要依赖于本次采购的硬件自身的数据安全性设计，譬如双活、 3DC 等方案，以及 RAID2.0+ 等特性，而云方面则基本上取决于所采用云所提供的相应云服务；云上的扩展性更好，数据共享和大数据分析等方面有先天性优势，但私密性略逊于本地传统架构。医院对于 HIS 系统数据保密性要求更高，对多院区、多医院数据共享没有很高要求的场景，本地传统构架更合适，对于互联网医院、多方 HIS 数据分享有较多需求，对数据私密性没有非常高要求的场景， HIS 上云会更加便捷。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

个人不太建议 HIS 系统上云。主要是基于如下几个方面的考虑： 1. 每一种 IT 的技术解决方案都有它的适用范围，从来没有一个放之四海而皆准的解决方案，要不成本，要不技术复杂度，要不维护复杂度等，要根据实际的业务系统需求来统筹考虑，云作为新的信息生态的确为我们信息化提供了很多以前无法想象的解决方案和途径，但是单 HIS 而言，是不适合的，因为 HIS 作为医院的核心业务系统，其最重要的考虑指标是高可靠和高性能要求，但是云主要以其简单，方便，灵活见长，所以传统 HIS 不适合云的生态 ( 当然以后 HIS 开发微服务化后则还需要观察 ) 。 2. 如果 HIS 上云后， HIS 系统的最重要的瓶颈在于医院内部与云之间的网络链路的互联的问题，当然可以通过冗余链路等方式做好应急备份，但是继续现在运营商光纤铺设的管路现状 ( 与市区多类线缆交汇，容易因为其他线缆的维护导致光纤的中断 ) ，所以不建议上云。 3. 从快速系统业务恢复需求的角度，因为上云后，系统的设备维护权在运营商或其指定的维护商身上，如果系统故障，虽然有合同要求 24 小时及时响应，但是实际可能系统回复的时间会加长，不像本地架构时能快速响应和恢复。

至于上云后和传统的架构在备份，容灾和应用的差别，其实差别不大，主要是云的备份容灾更简单易用的区别

【 Q14 】″云″存储能够安全解决智慧 His 面临的大数据带来的物理存储设备的压力？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

医院存储压力较大主要是 PACS 影像图片，如果医院有超算平台的，相关的基因数据等也是医院存储压力来源。这个压力主要是成本的压力和维护管理的压力。云存储能缓解一部分压力，鉴于鸡蛋不能放在一个篮子里的原则，医院将数据放到云存储上后，不可避免的也要在本地存一份备份，云存储及本地备份之间的同步关系等，也需要相关机制去验证和确认。什么时候解决了这部分的担忧和顾虑，或有很好的解决途径或办法，云存储也就能比较快的在医疗行业推广开来。目前的存储技术架构尚能支持医院现有 IT 发展要求，但是值得提出的是，云存储及云计算以后也必将是日后发展的方向，但是具体的落地方式和推进计划，还是需要根据不同医院，不同业务的要求具体去拟定

【 A2 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

对医院来说，存储压力最大的业务往往是 pacs 业务，因为 pacs 影像资料同时有合规性存储时间要求，也有较高的科研价值，所以一般来说医院不会主动删除历史文件。

那么这无限增长的数据何处存放就成了非常大的问题，由于存量数据越来越多，众多医院也从 fc-san 的传统块存储阶段、集中式 nas 存储阶段、分布式 nas 阶段逐步走向了本地存储 + 云存储结合的方式。

思路如下：

1 、需要供临床、科研部门频繁调用的热数据需要高性能本地存储支持，则可以采用 nas 架构的高性能存储，至于集中式还是分布式则看业务整体架构来定。

2 、若干年以上的冷数据必须永久保留，但本地建立存储池则开销过大，部分可以上云，使用云存储来保存合规性要求的“ DICOM 源文件”部分，本地只留存压缩文件保存在低速存储区。

3 、这样既避免了云存储故障可能带来的数据丢失问题，也大大缓解了本地存储池的建设压力。

【 A3 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

云是弹性的，大数据如果流量很大，可以弹性扩容，而且云也支持灾备，所以从容量和安全性两方面都能满足。热数据一般都会放在本地集中式或分布式本地存储里，有一些政策法规要求保存的数据，一般会放到云存储里的冷存储里。随着时间的推移，清除老的数据，循环存储，降低成本。

【 Q15 】 是否能使用超融合架构部署的虚拟化平台代替传统物理机 rac 的 his 系统数据库部署方式 ?

【 A1 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

传统的物理机 rac 架构，大多数都是服务器 + 存储的方式，基于这种架构的 IT 基础设施，价格和运维成本比较高。而超融合架构是近年来新型的架构，基于计算虚拟化和分布式存储，以应对业务和数据的增长，超融合架构很好的将计算、存储、网络、虚拟化等不同的模块进行了全融合，灵活性和扩展性都非常好。

对于医院 HIS 系统，业务以稳态为主，其业务要求是足够的稳定性和突出的性能，对存储大 IO 的高吞吐量，和小 IO 的低延时和数据的强一致性都有较高的标准和明确要求。

因此，对于医院 HIS 系统建设，超融合架构无法完全代替传统的架构，但可以进行二者之间的整合，以超融合 + 集中式存储的方式进行建设：针对计算，可以采用超融合架构，将计算、网络、虚拟化进行融合部署；针对存储，还是采用传统的集中式存储建设，可以发挥集中式存储在稳定、可靠的优势。这样，既可以发挥计算侧超融合灵活、扩展和极简运维的优势，又可以发挥存储侧在可靠性和性能的优势，可以非常匹配对 HIS 这种以稳态业务为主的系统。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

这个主要看医院体量。首先来看看两种方式的优缺点吧。不管是超融合还是传统的方式，其实还是分为存储层，主机层，唯一的区别主要是超融合主要是主机和存储物理融合在一起了，另外就是互联的网络从传统的 FC 换成了以太网络，冗余方式从传统的复制，双活， raid 等方式改成了副本方式。从个人的实际经验来说，超融合的成本并不会比传统的低，硬件的成本，上层分布式存储软件许可，虚拟化许可等都需要购买，另外还有一个比较重要的，因为副本与原来的 raid 的方式不一样，除了 raid1 ， raid 只需要牺牲一块或几块磁盘就可以实现冗余，而副本的方式是直接可用容量只是物理容量的二分之一或三分之一。超融合有它的优势，如，相对来说，对上层应用客户，底层是完全透明的，部属方便，有虚拟化的优势，适合一虚多的业务场景，传统的架构则稳定性更强，适合多虚一的场景。个人建议如果医院体量大，联系还是沿用传统架构的方式构建 rac ，不用经过虚拟化层。如果体量不大， iops 不高，可以用超融合的方式来实现

【 A3 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

可以，这对中小型医疗机构， 从投入成本的角度来讲也是好的选择。

传统数据库在硬件架构上往往采用物理机 rac+ 光交 + 共享存储的模式，有些会采用存储双活以保证数据，而这种架构实施运维成本较高，排查问题不易，投入成本较高。

但是这种架构存储路径短，可靠性较高，在同档次配置水平上性能更优。

超融合架构在医疗行业的兴起大约在 2017 年前后，拿 vsan 举例，好处是显而易见的。

使用 SSD 作为缓存盘，大大提高了虚拟化环境所能提供的 io 性能，磁盘延时也更低，分布式存储架构，池化的资源，整体易于统一管理，对于预算不充足的医疗机构是不错的选择。

而缺点也同时存在，第一是分布式存储毕竟有一些计算开销，使用双副本或者多副本以保证 HA 的同时也大幅度降低了可用空间，软件 license 价格较高。

【 A4 】匿名用户

当然可以，目前国内主流厂商的虚拟化皆为 kvm ，其对于性能的损耗已经是比较小了，即同样配置的一台虚拟机性能相差不到 5% 。

选择用虚拟化部署 his 数据库有几个优点：

1 、易运维； 2 、为医院云化数据中心做准备； 3 、成本低

缺点：

1 、多了一层虚拟化，对性能有损耗； 2 、虚拟化层故障点；

实际应用场景：

1 、三甲等大型医院， his 采用 2 台物理机搭建 rac 集群，存储使用全闪存双活，其他平台如 lis 、 pacs 、集成平台等使用虚拟化或超融合；

2 、二级医院可全平台采用虚拟化。

三、集成平台存储选型问题

【 Q16 】集成平台 IT 存储架构应如何选择？集中式架构和分布式架构优劣势体现在哪些方面？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

集中式架构优点是稳定可靠，维护方便，缺点是当存储扩展到一定容量或规模的时候会出现控制器瓶颈，性能会下降。分布式架构优点是扩展灵活，缺点是依赖以太网络作为数据交换网络稳定性略差，性能主要消耗在维持数据一致性和副本等上，扩展规模与实际性能的关系需要严格的测试。

集成平台是采用集中式还是分布式，主要看如下： 1. 医院的体量。 2. 后续发展预期。 3. 医院 IT 技术人员技术能力。鉴于现在信息发展状态，预算足够，个人建议混合结构，数据类放传统集中式，应用类放分布式。当然，从来没有一个通吃的解决方案，选择什么架构还是要根据医院实际情况与需求来确定。

【 A2 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

平台的存储构架选型，具体还是要根据平台自身的建设规模和后续扩展性来选择。

集中式系统架构的最大的特点部署结构非常简单，因为无需考虑如何对服务进行多节点的部署、也就不用考虑各节点之间的分布式协作问题了，但是，因为采用了单机部署，所有的功能都集成到了主服务器上，对于服务器的性能要求很高，性能也不好。带来的问题有系统大而复杂、难以维护和发生单点故障、扩展性差等问题。发生单点故障还可能造成整个系统或整个网络的瘫痪。优点也显而易见，便于维护，操作简单。在规模不大的情况下，部署方便，结构相对简单啊，成本相对较低，但后期如果扩容需求增大，由于竖向堆砌的特性，则很大可能会演化成高烟囱构架，造成成本高昂。

分布式系统是一个硬件或软件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，即分布式就是一群独立于计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多， CPU 、内存、存储资源等就越多，能够处理的并发访问量也就越大，可以很方便的横向扩容，成本优势也会凸现出来。分布式空间上计算机随意分布，计算机之间没有主次之分。系统资源为所有计算机共享，多台计算机协调完成一个共同任务，系统内任意两台计算机可以互相通信交换信息。

【 Q17 】 医院集成平台存储选型问题？是选择集中式还是分布式？

【 A1 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

如何选型，具体还是要根据平台自身的建设规模和后续扩展性来选择。

集中式系统架构的最大的特点部署结构非常简单，因为无需考虑如何对服务进行多节点的部署、也就不用考虑各节点之间的分布式协作问题了，但是，因为采用了单机部署，所有的功能都集成到了主服务器上，对于服务器的性能要求很高，性能也不好。带来的问题有系统大而复杂、难以维护和发生单点故障、扩展性差等问题。发生单点故障还可能造成整个系统或整个网络的瘫痪。优点也显而易见，便于维护，操作简单。在规模不大的情况下，部署方便，结构相对简单啊，成本相对较低，但后期如果扩容需求增大，由于竖向堆砌的特性，则很大可能会演化成高烟囱构架，造成成本高昂。

分布式系统是一个硬件或软件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，即分布式就是一群独立于计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多， CPU 、内存、存储资源等就越多，能够处理的并发访问量也就越大，可以很方便的横向扩容，成本优势也会凸现出来。分布式空间上计算机随意分布，计算机之间没有主次之分。系统资源为所有计算机共享，多台计算机协调完成一个共同任务，系统内任意两台计算机可以互相通信交换信息。

【 A2 】刘东， it 技术咨询顾问，东软集团

医院集成平台主要考虑的是存储的性能、稳定性和可靠性，选择集中式还是分布式主要还是看具体的业务场景。

1 、集中式存储主要用于对数据一致性要求比较敏感的系统，例如数据库和数据仓库等应用。以医院集成平台为例，大部分医院的集成平台数据库为 ORACLE 数据库，国产数据库和分布式式数据库应用的还比较少。对于 ORACLE 数据库来说，集中式存储是比较合适的。而且大部分传统的集中式存储都具备双活和高可用特性“即当主机发生故障时，备机可在不需人工干预的情况下秒级自动启动，消息在备机中继续运行，当主机修复后，消息会转回主机中继续处理”；对于存储的性能、稳定 性和可靠性也都比较符合集成平台数据库服务的数据存储需求。

2 、分布式存储，这类存储设备主要是可以进行灵活扩展，初期投入成本也相对比较低，可以支持块、对象和文件等多种数据存储类型。对于 医院集成平台来说最适合私有云存储服务。通常医院集成平台由数据库服务器 + 私有云服务器组成，对于私有云服务这一块业务，使用分布式存储还是比较合适的，兼具灵活性和高可扩展行，可以为集成平台提供灵活的数据存储服务。

3 、如果医院希望统一存储架构，使用一套存储系统，那么在存储选型时，就需要考虑不同产品之间的差异了。例如集中存储既可以用于数据库也可以用于云服务，但是在选型的时候需要选择扩展能力和灵活性都比较强的集中存储设备。如果选择分布式存储架构，那么首先要考虑分布式存储是否可以支持 ORACLE 等数据库，因为并不是所有的分布式存储都能很好的支持数据库服务。

【 A3 】 jakeyyu ，系统架构师，三甲医院

目前的应用还主要集中在集中式存储上，分布式存储有其独特的优势，但是根据业务使用需求来说，目前以 SOA 服务模式为主的医院应用软件，集中式存储能够满足其对业务性能和数据库性能的需求。而目前对于微服务等技术的推广，分布式存储对于微服务技术也有一定的支持，如果未来微服务等技术或者新兴的应用技术在医院系统进行规模化的应用，或许采取分布式存储也是一种选择。

【 A4 】潘延晟，系统工程师，第十区。散人

两种存储类型各有各的有点。就目前的技术发展而言，两种技术的方向性也很明确。集中存储主要应用于高 IO 的环境，如核心数据，而分布式存储则在海量文件的存储上比较有优势。

医疗系统也好。其他的行业也好目前其实都不一定要局限在莫一种架构上。而是应该看你的应用需求。随着业务的扩展，系统功能的不断细分，，可能将来会是多个平台架构并存的架构。如果资金紧张，那就看目前的业务最重要的是那部分。最适合哪种存储。

【 A5 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

高性能（ IOPS ）的情况下，还是集中式存储不是更好，这类型存储更加容易通过堆盘（ SSD/NVME SSD ）等来大幅度抬高存储整体性能，无论是 4K 随机读写的速度还是延时都可以得到大幅度提升。

而分布式存储目前医院的主要应用场景还是在 pacs 的海量文件存储和类型基因测序这种单个文件较大（ 3G-5G ）的情况。

抛开应用纯谈存储的集中式还是分布式意义不大，分布式架构往往需要数据库、应用、中间件等整体支持才能发挥出作用。

【 A6 】 zyp8365 ，数据库管理员，广东省中医院

医院互联互通是近些年医院信息化建设的重点，医院的集成平台的重要性与医院的核心业务 HIS 是同一级别的。集成平台是高 IOPS 的 OLTP 系统，需要存储具有高性能，高可靠。其实只要满足这个需求，是集中还是分布均可。但是一直架构上来说，集中式的对集成平台会更好一些，因为集中式单台存储的性能已十分优越，双活架构也能很好满足高可靠的需求，相比之下，分布式架构虽然也有一定的性能和稳定性，但是性能容易消耗在中间数据转发，仲裁及维护数据一致性上，当高 IOPS 时容易出问题

四、存储架构在建设、迁移、升级及共存时的稳定和安全性问题

【 Q17 】 如何在建设医疗数据湖时，从集中式架构平滑过渡到分布式架构？

【 A1 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

医疗数据湖场景，是典型的分布式场景，一开始选型就不应当考虑集中式方案，这是两套不同的构架，问题中的“平滑过渡”，更多应该指的是数据迁移方面的过渡，理论上集中式产品有可以和分布式产品进行异步复制的潜力。

【 A2 】程老师，医疗信息化技术架构师，华为数据存储解决方案中心

首先可以了解一下当前用集中式架构建设的“数据湖”是不是只是一套数据存储平台。

“数据湖”本身是一个比较新的概念，医院行业的体量比较少，所以数据湖在当前医疗，医院行业建设的还是比较少。当前国内也仅仅信息化走的比较好的一些大型三甲医院在规划，建设自己的大数据平台。可以可能您提的这个问题，是不是指的是从原有的集中式存储中讲数据迁移到分布式存储内？有专门的数据迁移工具。

【 A3 】 zyp8365 ，数据库管理员，广东省中医院

个人觉得从集中式架构到分布式架构，最好的方式是搭建好整个硬件体系平台后，再通过数据层面的迁移的方式去平滑过渡，数据迁移的方式要根据数据库类型，应用类型针对性的形成迁移方案，并对方案在测试环境中进行完善的全面的测试，从而优化方案后便于执行

【 Q18 】如何使用哪种工具转移数据存储平台而使其稳定安全化？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

这类工具有很多，比如 oracle 自带的 ASM ， dataguard 或者 goldengate ， sqlserver 自己的 mirror 等，数据存储平台主要用数据层的迁移工具，会更稳定，更安全

【 A2 】 jakeyyu ，系统架构师，三甲医院

首先不是做产品和公司推销，就单纯迁移的效果来看，国内有一些厂家做的非常不错，比如我们曾经使用过的迪斯杰的产品，对于 oracle 数据的迁移非常不错，可以和 oracle 自带的程序相媲美，目前据我所知，他们的产品线也从 oracle 做到主流的几种数据库上了

【 Q19 】 his 核心升级存储怎么在线升级？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

主要看你的 HIS 架构是怎么样的，单单提供老存储型号很难给出建议。要看贵单位的 HIS 实际运行在什么服务器上？什么操作系统上？什么数据库上？ HIS 是两层？还是三层？数据迁移有很多方式，可以存储层面上做存储 lun 的复制，但是前提是新旧存储之间可以进行复制或者可以通过第三方存储网关如 (vplex ， SVC 或者可支持存储虚拟化的存储如 HDS 的高端存储 ) ，但是这个也需要操作系统进行相关的识别磁盘及拉起磁盘及数据的一系列操作，动作比较大，需要进行严格的操作测试。还可以通过数据层进行数据迁移，比方说，如果你的数据库是 oracle ，你可以通过 dataguard 的方式进行数据切换，如果你的版本在 10g 及以上，可以通过 ASM 的做不用停机的数据迁移。当然也可以通过应用层去做迁移，写应用脚本，当然这个更加复杂了。所以还是要看贵医院的实际场景，最好是通过数据层面去做迁移，代价更小，更有实操性，停机时间更短。当然，不管是什么方式，建议在实际操作前，应做严格且全面的测试，形成可操作的迁移脚本和方案。

【 A2 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

核心系统的存储升级替换，一般情况下可以考虑的数据迁移方案类型很多。比如采用 Oracle 数据库的情况下，可以从数据库层面通过 DataGuard 、 ASM rebalance 等方法实现，但这要求对数据库非常熟悉，过程中需要通过大量的脚本完成，比较复杂而且迁移速度也比较一般。还有一种非常常见的方法是通过存储设备厂商提供的数据迁移能力来实现。通常同一家厂商同系列之间的存储设备可以做到在不中断业务的情况下完成存储间数据迁移，而华为的 OceanStor Dorado V6 全闪存系列存储异构虚拟化迁移方案除了可以实现从华为其他集中式存储中进行无中断数据迁移之外，还可以支持从其他多家厂商，包括 IBM DS 系列的存储中无中断的进行数据迁移，整个迁移过程都不需要停止业务系统，图形化工具自动化操作，迁移带宽甚至可以达到 GB/s 的级别，非常适合于核心系统的老旧存储更新替换。数据在线迁移的项目都要具体分析，华为可以提供专家进行一对一技术沟通，如果需要可以反馈给社区或私信华为专家联系。

【 Q20 】在多平台架构并存的存储架构下，如何做好核心数据与海量存储共存交互，即新老数据中间的数据转发？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

首先不管存储底层有复杂，在数据层逻辑层，医院要建立统一的数据中心，汇集所有医院数据，这样方便上层数据利用，通过数据中心实现新老数据转发

【 Q21 】新老存储兼容问题？

【 A1 】潘延晟，系统工程师，第十区。散人

兼容性的问题是多数都会出现的。特别是新老设备年代跨度特别大的时候。这种问题就会更加明显。新的存储有更快的接口方式和速率，也就迫使相关的服务器和光交换也随之调整。继而引发一系列的变更，

存储升级，因为保存的是核心数据。所以往往在更换上要更加小心，我的建议是。首先做好完整的备份计划，有了备份和应急的预案，才能够放手去做。之后。评估整套系统中的业务情况。看看是否可以连通旧服务器一通升级，这样可以搭建全新的环境，迁移业务和数据。然后吧原来 的旧设备作为备用和测试，如果服务器比较新。只打算更换旧存储。也可以是先让一部分服务器带起新的存储。将数据同步迁移后。在吧旧存储替下。相对这样的方式稳妥一点。，

【 A2 】 nightdxl ，智能存储解决方案，华为数据存储解决方案中心

不同品牌之间的一定会存在或大或小的兼容性问题，同一品牌不同系列的新老存储也会一定程度上存在兼容性问题，以华为存储为例：

集中式存储， Scale-out 方面，控制器等硬件上 OceanStor Dorado v3 、 OceanStor v5 、 OceanStor Dorado v6 之间互不兼容；双活方面， v3 、 v5 、 v6 之间不可以组建双活，但是 v3 和 v5 之间支持异步复制，各个系列内部，双活不做限制，理论上 5300 和 18500 都可以组建双活，但是除非极其特殊情况（设备故障，抢救业务）完全不建议这样操作，会对性能和稳定性带来很大不确定性，推荐同级别同型号产品组建双活；盘片方面，我们 OceanStor Dorado v3 、 OceanStor v5 的盘之间，部分盘片可以兼容通用，要根据具体型号而定，而 OceanStor Dorado v6 由于采用的全新设计， v6 的盘和 v3 、 v5 均不兼容。

分布式存储，我们已经成熟多年的 OceanStor 9000 和新款 OceanStor 100D 之间，在组网上，和业界主流保持一致，不支持混合组网，所有节点选型要求一致；但盘体基本上都可以通用，扩容和利旧都很方便；后续会推出新一代 OceanStor Pacific 容量密集型存储和 OceanStor Atlantic 性能密集型存储将会采用我司专有硬件，性能上会有较大提升，盘体和之前的 OceanStor 9000 / 100D 大多数情况下不兼容。

【 A3 】 zyp8365 ，数据库管理员，广东省中医院

存储的新旧兼容应该从以下几个方面去考虑 :

1. 新旧存储使用的业务是否一样？还是有部分重叠

2. 新存储是否要接管旧存储？

如果新存储的业务场景是新的，独立的，则不需要考虑兼容性的问题，新存储独立使用；如果新存储和旧存储有业务交集，存储的兼容性也不是最重要的关注指标，主要看服务器与存储之间的适配情况，不管服务器是否新换，一定要保证服务器与新存储之间的对接是可以的 ( 主要针对 FC SAN 的 HBA 卡的速率 ) ，这个才是系统迁移最重要的兼容要求，因为系统在存储间的迁移可以通过数据层面去操作，如 oracle 的 ASM 等，都可以做到数据的无缝迁移；如果旧存储还未到报废期，还可以使用，又希望新存储接管旧存储 ( 做存储虚拟化 ) ，则主要实现方式有虚拟化网管或者存储虚拟化方式，这个时候就要看旧存储在不在虚拟化网关或者新存储的兼容列表中，如果不在也做不了接管。但是个人建议，因为存储更新换代比较快，鉴于木桶短板效应，不太建议用新存储虚拟化接管旧存储

五、存储技术应用类问题

【 Q22 】 oceanstor 全闪存与其他传统存储厂商闪存相比，性能如何？有哪些优缺点？

【 A1 】 chenmingfu ，基础架构组长 ，宁夏银行股份有限公司

OceanStor 存储闪存盘上采用去全局磨损均衡技术，将业务负载均衡到所有 SSD 上，并且采用华为专利的反磨损均衡技术，避免多盘集体失效，在部件级构建了极高的可靠性；

在架构级层面， OceanStor 存储 Dorado 系列高端全闪存的 SmartMatrix 架构采用前后端全联接设计和全对称的 A-A 控制器设计，可以实现控制器 8 坏 7 的极端情况和 100% 的负载均衡；

在产品层面，硬件上可容忍 9 级抗震，软件上可容忍 3 盘同时失效，基于硬件重构和软件深度优化实现单套设备的极致可靠

在方案层面， OceanStor 存储 Dorado 系列全闪存还采用了免网关的双活方案，减少了故障节点，降低了系统布置的复杂度。

【 Q23 】华为免网关双活与传统的基于存储网关双活相比有哪些优势？

【 A1 】犹大，医疗解决方案高级专家，华为数据存储解决方案中心

传统的基于网关的双活，需要额外在存储上层部署单独的网关，这种方式首先增加了网关建设成本，其次也额外增加了故障点，网关故障会导致双活异常，第三增加了网关和存储的通信路劲，双活时延会增加。

采用华为免网关双活存储建设方案，建设成本降低，网关故障点会减少，并且双活时延会进一步降低，这些都是免网关双活存储带来的独特价值。当前华为所有存储的双活设计都是按照免网关进行设计的， 并且主流存储厂商都逐步在往免网关双活进行演进。

【 A2 】 wzpystcdc ，研发工程师，某公司

独立网关可以接管其他兼容品牌存储

【 Q24 】在如何兼顾性能和成本的情况下，将 Nas 存储融入到 Vsphere 应用 +FCsan 存储架构中去？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

首先，要确定的是 NAS 走的是以太网，如果要把 NAS 融入 FC-SAN 上，应该在采购的时候就做好规划，采购支持 NAS 的存储，有一些存储自身就支持 NAS 协议，有一些需要加装 NAS 机头。当然，还有一个很重要的问题就是选配相应的网络接口，现在常用的有 1GB ， 10GB ， 40GB 的的网卡，在存储采购的时候就要规划好，用哪种接口，建议使用 10GB 的，当然相应的，也要根据 vsphere 的应用情况增配相应的交换机，甚至要改造医院的核心网络带宽。这个都是需要考虑的。

NAS 融入到 vsphere ，基本是没问题的软件层面是支持的，关键是 exsi 物理主机上要配置与存储相应速率的网卡，而且要考虑冗余，只要硬件配置，软件均能适配。

另外值得提出的是， NAS 主要相比 FC SAN 来说配置简单一些，使用灵活些，所以要选好实际应用场景，根据实际需求评估好实际融入的方式和方案

【 A2 】 raphlgu ，项目经理 ，旭升

下面都是血的代价 :-)

1 、建议使用 IPSAN 替代 NFS 。

2 、存储网络务必使用 10Gbps ， 1Gbps 绝对不要考虑，即使多条 1Gbps 链路聚合，提升效果也不明显。条件好的话可以考虑使用 40Gbps 。存储网络尽量使用单独交换机，尽量不要挤在核心交换机上。

3 、磁盘数量越多越好。 40 块 6TB 性能要好于 20 块 12T 的性能。如果使用大容量 SATA 磁盘务必使用非叠瓦盘。 NAS 设备自带 SSD 缓存，如果没有 vSAN 这样的搭配，纯粹 ESXi ，效果很一般。

最后， FCSAN 绝对是第一考虑。速度而言即使 8GBps 的 FCSAN 也比 10Gbps 的 IPSAN 好 " 很多 " 。稳定性而言，目前主流的 16Gbps FCSAN 基本上通吃一切以太网。

【 Q25 】 存储使用 RDM 裸磁盘映射方式还是使用 VMFS 方式，各自的优缺点有哪些？

【 A1 】 wuliangy ，信息工程部工程师，浙江省肿瘤医院

个人支持对虚拟化层上搭建 rac 这种新方式进行探索。

在 2019 年以前，数据库 rac 的普遍搭建方式是物理机 + 光交 + 存储（双活）的方式，原因有几方面：

1 、 oracle 并不承认虚拟化上搭建的 rac ，一旦出现问题， oracle 不提供服务

2 、该模式已经过时间的检验，稳定可靠

3 、虚拟化上搭建毕竟经过了一层虚拟化层，开销是个疑问

4 、许多医疗机构可能使用的是小型机 rac ，对于 X86 的信任度并没有这么的高

但是在进入 2020 年后，至少在浙江区域有越来越多的机构开始尝试虚拟化上搭建数据库了，甚至采用 rac over vsphere 来做，原因如下：

1 、 2019 年 9 月开始 oracle 和 VMware 互认， 400 可以直接形成 case 了，从商务上得到了原厂的认可

2 、 X86 主机的性能、稳定性已经提高到了一个较高的级别，单机的计算性能就完全能承载大型机构的数据库压力

3 、许多大型医疗机构在 his DB 之外还有诸如 lis emr pacs 集成平台等核心业务数据库，若数据库采用虚拟化部署则可以更高效利用硬件资源

4 、全闪存储，全闪超融合硬件的价格下降带来了很多的可能性，实测虚机 rac 的 io 和延时完全满足要求

而回到主问题， RDM 和 VMFS 的方式，对于虚拟化来说，一种是裸设备映射，存储路径短，更高效，一种是虚拟化的文件格式。但是如今的全闪存储在性能上已经达到较高水平，实测下来已无大区别，如若想要使用 VM 的特性的，那建议都用 VMFS 挂载，或者折中，数据库虚机使用 RDM ，最大程度利用性能，剩余存储资源则 VMFS 丢给虚拟化，高效利用。

【 A2 】 zyp8365 ，数据库管理员，广东省中医院

首先，个人不太建议在虚拟化平台搭建数据库 rac 。因为虚拟化平台是为充分利用服务器的计算和内存资源而提供的一种一虚多的云计算解决方案，能很好解决信息 IT 的烟囱式发展方式，数据库 rac 最主要是实现如下两个目标 : 双机高可靠和业务负载均衡。虚拟化平台本身就是多台服务器组成的，本身就有 HA 的机制，另外虚拟化平台本身的虚机保护的方式有很多，如 vmware 的 Ft( 虽然有 CPU 限制 ) ，也有连续数据保护的机制如 RP4VM ，以及很多备份还原的途径和方式能实现高可靠，不需要依赖 rac 的方式，如果想实实在在做容灾应该考虑 dataguard 的方式。另外再说业务负载均衡，也更不应该在虚拟化平台来实现， rac 多虚一和虚拟化平台一虚多本身就是矛盾的，所以不建议这样操作，两台物理机去做更好。而且还有一个比较重要的原因是 oracle 数据库的 rac 虽然理论上可以通过虚拟化平台来实现，但是不建议这样做，因为经过了一层虚拟化层，如果出问题不好排查，而且信息流非最优。回到楼主的问题，其实 RDM 和 VMFS 最重要的区别就是 RDM 是直通，而 VMFS 是经过虚拟化层，用的虚拟化平台的文件系统格式。优缺点就是 RDM 的方式，数据直接到磁盘，路径最短速度更快，但是因为没有经过虚拟化平台，管理麻烦，用不到平台的一些高级功能，但是 VMFS 就是刚好相反，数据要通过虚拟化平台的解析后才到后端磁盘，所以路径更长速度相对慢，但是管理简单方便，能使用虚拟化平台对磁盘的一些高级功能

【 A3 】赵海，技术经理，大连

RDM: 裸磁盘方式，一般用于 Oracle RAC 的虚拟机场景。

VMFS ：虚拟文件系统方式，可用于大部分的虚拟机磁盘场景。

在 VMware 的环境当中没什么要支持 RDM 方式呢？其实最主要的目的在于支持多虚拟机磁盘共享，而且对读写性能有要求的场景，例如 Oracle RAC 。如果用了这种方式，那么 VMware 本身的一些特性也就没了，比如说虚拟机的漂移，比如说对于磁盘 IO 的控制参数等。另外给云环境的运维带来很多麻烦，比如说批量的迁移碍于某台服务器上的 RDM 而没有办法批量执行迁移等等类似的事情。

一般情况下，我们在 VMware 平台上用虚拟机实现的一些业务场景，其实更多的还是考虑其灵活性及高可用性。如果从性能角度来考虑，就算我们用了 RDM 的方式，其实性能瓶颈还是有的，在于 VM 。所以如果是重量型 OLTP 业务，我们还是考虑物理机做资源池来支撑 RAC 的方式比较合理，哪怕是通过 12C 的方式去实现物理机组成的 DB 资源池。如果实在想把数据库搬运到 VMware 平台上的 VM 里，建议你选择一些不重要的，负载不是很高的，数据量不是很大的这类数据库，也不用做什么 RAC 。

如果是其他的业务场景，就更没必要用 RDM 方式去代替 VMFS 了。

六、智慧医院软件类问题

【 Q26 】 HIS 系统如何帮助医院实现数据标准化和统一化？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

现在医院信息化的实际情况是鉴于业务专业性或采购或政策等不同原因导致不同业务购买的不同厂家的信息系统，而不同厂家的信息系统因为标准不统一形成信息孤岛。如何将这些孤岛互通互联起来，可以通过 HIS 抑或是集成平台将各个业务系统串联起来。但是不管是哪种方式，都要通过数据的标准化和统一化才能实现。数据的标准化和统一互化，最重要的是整个医院要统一数据字典，包括人事，科室，检验，检查，诊断，耗材，部位，药品等，只有梳理完成这些字典，并形成一套字典的维护技术规范和流程，才能做好数据的统一和标准化

【 Q27 】智慧 His 要能解决精准预约床位问题？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

按照楼主说的，预约系统和 HIS 之前的同步方式是通过后台 job 或计划任务去做同步的，如果要实现精准的预约床位，主要有两种方式实现： 1. 在预约的时候通过日期判断，如果是前一天或更前的，按照现有系统流程，如果是预约今天的，封装查询 HIS 系统床位数据语句，再更新预约系统床位数据，完成预约，这种方式的好处是有预约的时候才会去查 HIS ，缓解了接口的压力，但是缺点是，如果预约的时候 HIS 有床位更新，可能会有脏数据，如果在查询 HIS 时预约系统有问题也可能产生分布式事务锁。第二种是，预约系统和 HIS 根据床位信息做实时同步接口， HIS 系统的床位有任何更新，都推送给预约系统，以更新预约系统床位信息，可以避免上述问题，但是相对来说接口压力会比较大。主要看院方的取舍问题，综合考虑预约系统和 HIS 系统的业务

【 Q28 】 智慧 His 要能解决精准预约床位问题？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

按照楼主说的，预约系统和 HIS 之前的同步方式是通过后台 job 或计划任务去做同步的，如果要实现精准的预约床位，主要有两种方式实现： 1. 在预约的时候通过日期判断，如果是前一天或更前的，按照现有系统流程，如果是预约今天的，封装查询 HIS 系统床位数据语句，再更新预约系统床位数据，完成预约，这种方式的好处是有预约的时候才会去查 HIS ，缓解了接口的压力，但是缺点是，如果预约的时候 HIS 有床位更新，可能会有脏数据，如果在查询 HIS 时预约系统有问题也可能产生分布式事务锁。第二种是，预约系统和 HIS 根据床位信息做实时同步接口， HIS 系统的床位有任何更新，都推送给预约系统，以更新预约系统床位信息，可以避免上述问题，但是相对来说接口压力会比较大。主要看院方的取舍问题，综合考虑预约系统和 HIS 系统的业务

【 Q29 】 医院集成平台消息交互标准如何选择？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

1 、 目前 《国家医疗健康信息医院 互联互通标准化成熟度测评》是目前乃至日后一段时期内的一个常态化的信息化建设评价标准 ，个人建议还是要以 《国家医疗健康信息医院 互联互通标准化成熟度测评》标准为依据，而其它的国际标准作为参考。国家有的，按国家的，国际有的参考国际的，都没有的，参考厂家或自行拟定，等国家的出台后再进行对标对照。

2 、集成平台上线时，就应该定好对接的原则、方式和流程等标准，而且对接的顺序也应该先易后难，先异步后同步的实施方式，积累经验后再向实时复杂的业务对接扩展。而且不管是多大还是多小的一个对接，应该都要有对接负责人去统筹安排和盯紧对接的相关事宜，不然对接将无序开展。

3 、主数据包括人员、科室、诊疗项目、药品、诊断、耗材、部位等等，主数据的建设包括两部分工作内容：主数据的梳理和主数据的系统对接；两者可以并行做。主数据梳理应找到该主数据的干系部门和科室，如检验诊疗项目的主数据，应找医院的医务、检验科、审计科等相关科室一起理顺数据类型、定好梳理规则，并确定好后续主数据上线后的维护流程，并且着手去梳理主数据；同时，要求厂家如 HIS 、检验的厂家、平台的厂家，一起协调接口的开发、测试等工作，过程中要特别重视测试的工作，要进行业务全流程的测试，如 HIS 通过新的主数据的开单、收费、发送给检验系统后检验系统执行、出报告，回传结果等，也要做好边界值等的测试，保证测试全面。另外值得提出的是，在上述两部分工作都做好后，应该拟订好上线计划，分成存量数据和增量数据的上线，存量数据可逐步推进，先推进若干项目，稳定后再逐步更新所有，增量部分则商量好各相关系统的上线要求和计划，分步有序开展。另外，一定要重视后续主数据上线后的维护流程、人员的拟定和确立，而且要严格执行，不然后续数据更改无需，又会导致数据的混乱

【 Q30 】 医院信息化项目中的管理问题？

【 A1 】 zyp8365 ，数据库管理员，广东省中医院

1 、医院 IT 项目不管多大或小，都应该严格按照信息系统项目管理方法去进行管理，院方要有项目负责人居中统筹协调厂商与临床、厂商与第三方对接厂商、厂商与项目之间的关系，管理好整个项目需求、进度、质量和风险问题。不管知名与否，厂商本质是逐利的企业，其最终的目标是项目验收收款，院方的最重要目标是通过该项目建设使得医院在该项目领域信息化提升一个水平。目标的差异会导致矛盾的产生，在实际项目运行中，项目负责人应找到甲乙双方的利益契合点，如通过项目建设完善厂商的信息化产品，通过项目建设提供厂商的建设经验和示范案例以利其推广等，充分调动厂商的积极性，另外院方在对厂商及项目管理中应使用 X 理论，极少数厂商是符合 Y 理论的，要在项目管理中充分利用好合同工具（前期采购、需求及合同拟定时要认真仔细）。另外值得提出的是，每个医院的实际业务流程及需求不一样，信息系统项目实际在医院落地或多或少都是需要修改，在前期采购沟通时，就应该从厂家对院方需求的理解度、实际的开发实施经验、项目开展后实际能投入的人员及技术能力等，都要做全面的了解，部分如人员配备（如开发人员、实施人员等的数量）等可纳入合同中。

2 、每个企业都有其擅长的领域，不可能一个企业能做完医院所有的系统，如果说可以，顶多这个企业是一个总包商，把不熟悉的领域分包给了其他的公司。个人建议，系统建设的厂家不要太多，做集成和数据对接的时候会特别复杂；可以选择一些知名的企业来为合作伙伴，如集成平台建设中，但是要研究透其实施技术底层的稳定性和整体项目实施的方式、复杂度等，实施的案例，实际走访一下案例医院的应用情况等，从而为选择提供借鉴。

3 、当然并不是所有的需求都是合理的。项目负责人一定要做好需求的管理，要理解需求提出方的真正意图，要对需求进行基线管理，并对需求进行从提出、确认、验证等的闭环的精细化管理，确定需求基线后，要做好变更管理。

4 、项目验收不等于人人都说满意。项目实施验收，不太可能做到人人都说满意，因为项目的实施必然或多或少会涉及到现有医院流程的改造。我们信息化项目实施并不是把现有的流程电子化和信息化，而是根据我们该领域的信息化发展需求，通过该信息化项目的实施，改造重组优化我们现有的医院业务流程，使得医院业务流、数据信息流能统一符合我们该项目建设的预期。只要符合该预期，并且合同所要求的条款都符合要求，即可签字验收。