一、智慧医院存储架构探讨
【Q1】智慧医院的IT存储架构与传统医院信息化相比有哪些特点和变化？
【 A1 】 zyp8365 广东省中医院 数据库管理员：
智慧医院在传统以 HIS 、 LIS 、 PACS 等信息化代表的系统基础上，不断在人工智能 + 医疗、互联网 + 医疗、医疗大数据等领域朝着应用多元化、服务微小化、交互网格化、数据复杂化等趋势发展。反应到存储架构，要求底层存储能支持更大体量的数据、更好的性能、更优的灵活扩展性。
【 Q2 】智慧医院环境下医院信息系统“两地三中心“的灾备解决方案中对存储架构有何升级拓展和改造建议？
【 A1 】 zyp8365 广东省中医院 数据库管理员：
不管是哪种方式的灾备解决方案，首先应该考虑医院的系统的实际体量，以及上层实际使用业务场景要求，而不是一种方案吃遍所有医院信息系统，这样不符合医院需求及成本的预期。RTO 和 RPO 要求高的系统，可以通过两地三中心的灾备解决方案，如果要求不高的，也可以选择更加经济的灾备方案满足需求。如选择两地三中心的解决方案，应充分考虑业务需求及网络链路条件来选择复制方式 ( 是同步亦或是异步 ) ，如预算较紧，灾备端的存储可选择比生产环境低一点档次的，容量相同的存储。实施阶段，应该充分测试两地三中心的方案，测试应全面覆盖各类故障场景，形成可实际操作的应急处置文档，以备系统实际使用中遇到问题时可根据文档快速进行系统恢复。
【 A2 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
“两地三中心”容灾方案中表示具备三个数据中心，即生产中心、同城灾备中心和异地灾备中心。对医院信息系统而言，同院区的双活容灾中心已是必备的要求，要求同院区的数据中心能够同时对外提供业务，即我们所说的 AA 双活，这样生产中心故障下，能做到 RPO 和 RTO 为零切换到双活中心。
如存在新院区的情况，可以考虑在新院区部署异地的灾备中心，形成两地三中心的容灾解决方案。这样即使老院区的双活中心故同时障情况下，新院区灾备中心同样可以进行业务的快速拉起。并且，随着业务和技术的发展，传统的异地灾备中心集容灾和备份于一体，不但可以做到数据中心的容灾，还可实现异地数据的备份，这样可以实现异地灾备的双重保护。
当然，具体是双活容灾还是两地三中心容灾案，还是需要根据医院的实际业务要求来定。对容灾要求更高的医院可以选择两地三中心方案，但要求不是太高，可以选择双活数据中心方案。
【 Q3 】医院 HIS 、数据中心、 BI 、集成平台等系统使用统一存储还是分别使用不同的存储？备份是否统一管理？
【 A1 】 zyp8365 广东省中医院 数据库管理员：
这个问题主要先看医院的体量，如果体量小，一套存储能搞定，就没有必要分开，造成维护的麻烦。如果体量大，还是建议要分开，因为 HIS 和集成平台是 OLTP 的业务类型，更看重 IOPS ，建议用高端高性能高可靠的存储去承载，数据中心和 BI 是 OLAP 的业务场景，建议用大容量，扩展性较强的存储架构去承载，也非一定要分布式架构，只要符合需求即可。备份建议逻辑统一管理。针对信息不同层次 ( 物理层，数据层，应用层等 ) ，备份的需求、方式、介质等都会不一样，应统筹考虑以保障信息安全。
【 A2 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
医院 HIS 、 BI 、集成平台以及备份的业务特点是不一致的，比如 HIS 、集成平台系统以结构化数据为主，要求高可靠和高性能，可以考虑集中全闪存储；数据中心和 BI 数据量较大，对成本诉求更高，可以考虑低大容量、高扩展的存储，不管集中式还是分布式，只要符合这些要求即可；因此在条件允许的情况，可以分别使用不同的存储，但各存储之间需要进行统一的管理和运维，这样可以满足不同系统的业务诉求，各个系统之间可以更好的进行物理隔离，并且可以统一运维。
【 A3 】annoym 系统工程师：
HIS 采用集中式存储，提供高 iops 低延时存储空间。其他的建议采用分布式存储， PACS 业务容量需求旺盛，分布式存储扩容平滑，医院后续需要建设智慧医疗等不可避免的需要建设大数据分析平台，分布式存储可以提供多种接口满足分析需要和提供高容量。
【 Q4】集中存储存放单一 HIS 数据？还是可以 LIS 数据、 EMR 数据可以一并存放？各有什么优劣？
【 A1 】 zyp8365 广东省中医院 数据库管理员：
HIS 、 LIS 是同类业务， PACS 要区分数据库、应用及图像。HIS 、 LIS 和 PACS 的数据库及应用可以放到这个集中存储上，主要的影响是，鸡蛋放到一个篮子里，当存储出现问题，会在这上面的所有系统都不行，压力会更大，优势是能充分利用存储资源。另外， PACS 的图像数据因为比较大，除非不差钱，建议单独放到性价比更高的存储上，可以用 NAS 或对象存储均可，当然直接 FC SAN 也可以，相应的容灾，做存储复制即可。
【 A2】 lisiqibj 华为数据存储解决方案中心 存储工程师：
可以一并存放，集中式存储可以在一台存储上划分出多个逻辑空间，映射给前端不同的应用，在应用端看起来数据是完全分开存放，互不干扰的；同时还可以结合存储端的 QoS 、缓存分区等特性，针对不同的应用划分不同的网络带宽、内存资源等等，以保障核心应用的性能平稳，所以优势是可以增加资源利用率，便于管理员做整体运维。
当然，如果医院的数据量大，就诊人数多且密集，单系统存储性能已有瓶颈，也可以将 HIS 、 LIS 等数据单独存放，优势是可以避免一套存储故障影响院内多套系统，也可分散性能压力。
二、 HIS 系统的存储的选型问题探讨
【 Q5 】 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% 的全方位数据保护。
【 Q6】 HIS 系统采用不同的存储架构，对数据的互联互通和共享整合有哪些影响？
【 A1 】 zyp8365 广东省中医院 数据库管理员：
个人觉得对实现的效果是没有影响的，存储架构是物理层面的问题，数据的互联互通及共享整合是数据层面的问题，物理架构的不同会影响数据互联互通及共享整合的实现方式和途径，但是最终效果是能实现的，集中式的存储架构数据提取和汇总更方便点，分布式存储架构虽然物理分散，但是都会有统一的逻辑控制中心，对接方式差不多。
【 A2 】 wuliangy 浙江省肿瘤医院 信息工程部工程师：
对于应用层面没有太大区别，但是对于系统底层设计有区别。
传统HIS系统基本都采用集中式存储， FCSAN居多，方便本地部署，架构稳定成熟。
而一些医疗集团由于需要统筹整合各医疗分支机构，已开始探索分布式架构的系统部署方式，这在硬件层面就提出了许多新要求。高并发，易扩展，数据同步等问题促进了分布式存储的发展，也让行业看到了不同的解决方案，这对于一些多院区部署统一系统的医院来说比较重要的意义。
【 A3 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
华为提供 OceanStor 全闪存双活解决方案，不改动现网架构、数据库和医疗软件、运维方式，对 HIS 系统读写 IO 进行端到端加速，极大提升 HIS 系统的响应速度；同时采用 HyperMetro 免网关双活方案，替换原有的 VNX 存储配合 VPLEX 网关的组合双活方案。2 台 Dorado 全闪存互为镜像，数据可以在两台全闪存之间实时同步，并能在设备故障时提供毫秒级别的快速切换，确保医疗关键业务的连续性。
由此可见不同的存储架构对客户和应用软件本身是无感知的，对数据的互联互通和共享整合没有任何影响。
【 Q7】医院建设 HIS 系统数据库和应用如何选择存储？
【 A1】 zyp8365 广东省中医院 数据库管理员：
HIS 建设数据库和应用的架构选择应分开，数据库可以选择如双机双活全闪存储，存储底层也可以建设 CDP 及其他备份一体机的方式，保障数据的备份，数据库层面通过 RAC 、 dataguard 等保护方式，做好数据逻辑层面的保护。如果体量大，预算又足够，数据库服务器建议用物理机。
应用服务器，建议搭建私有云，如 vsphere 等 , 通过虚拟化平台的 HA ，保障应用服务器的高可用，另外应用服务器的部署、更新等操作都极为方便， vmware 有很多适配的备份软件和工具，都能很好的对虚机进行快速备份和恢复，也极大的保障了应用服务器的安全性。
【 A2 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
医院 HIS 系统是医院最核心业务系统，承载着整个医院的基础工作平台，串联挂号、划价、收费、配药等全流程。系统卡顿会严重影响患者就医体验，业务中断会影响整个医院的正常营业，因此医院 HIS 系统对存储要求高可靠性和高性能，其选型原则如下：
1 、存储设备可靠性
HIS 核心存储设备中的数据是医院最重要的生产数据，对医院 HIS 信息系统而言，不发生系统性风险是最基本的要求。因此对于 HIS 核心存储设备的选型，其首要指标就是存储的可靠性，这里的可靠性包含了三个层面：
一是存储设备器件可靠性，包含了主要器件的冗余性设计，支持热插拔等。二是存储设备整机的可靠性，包含了整体硬件架构是否支持多控制器，是否支持控制器四坏三甚至八坏七。三是对于各灾备特性的支持，包含存储层双活以及两地三中心的支持度，双活仲裁机制是否可以保证常见故障场景下业务的连续性和数据不丢失。
2 、存储设备高性能
对 HIS 系统而言，一旦建设完成，需要保证至少 5 年内上层应用不出现存储层的性能瓶颈，随着闪存技术的快速发展，目前全闪存存储已经成为各家主流存储厂商的标准配置，闪存技术日趋成熟。就闪存技术而言，目前市场上的全闪存主要包含了原生全闪存和改良型全闪存两大类：原生全闪存即是针对全闪存介质全新研发的存储操作系统，这类存储的特点是可以最大限度发挥出全闪存介质的高性能的特点，但是对传统的存储容灾特性支持度较弱；改良型全闪存即在原先高端混合存储的基础上对存储操作系统做一定的改良，从存储 IO 路径和存储协议等方面去做修改适配，在不影响原有存储特性基础上，尽可能发挥出全闪存的性能优势。因此对医院 HIS 存储而言，建议采用改良型的全闪存，这样可以更好保证 HIS 系统的性能。
3 、后期运维支持力度
对于 HIS 核心系统存储，采购和交付只是存储生命周期的很少一部分，交付后的运维工作才是运维人员最主要的工作，这里就需要存储产品好运维、易运维，需要存储厂商在运维保障上提供足够的支持，因此在运维这块需要考虑实际运维人员的技术能力、新产品的学习成本、厂商本地化服务能力等。
【 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
2 、 CPU 选型选择多核心的类型，单节点 512G 内存
3 、全院已有多套虚拟化集群，统一 VC 管理，互相打通， veeam 灾备， cdp 部署，延伸集群的建设都非常方便，可维护性极高。
【 A4 】annoym：
极高性能使用物理机 + 全闪存双活， 2 台或多台物理机搭建 Oracle Rac 集群，存储做双活。一般日均接诊量低于 5000 人的医院，可以考虑虚拟化或者超融合。
【 Q8】 HIS 系统要不要上云？HIS 上云的与本地传统架构在应用、备份、容灾上有那些优缺点？
【 A1】 zyp8365 广东省中医院 数据库管理员：
个人不太建议 HIS 系统上云。主要是基于如下几个方面的考虑：
1. 每一种 IT 的技术解决方案都有它的适用范围，从来没有一个放之四海而皆准的解决方案，要不成本，要不技术复杂度，要不维护复杂度等，要根据实际的业务系统需求来统筹考虑，云作为新的信息生态的确为我们信息化提供了很多以前无法想象的解决方案和途径，但是单 HIS 而言，是不适合的，因为 HIS 作为医院的核心业务系统，其最重要的考虑指标是高可靠和高性能要求，但是云主要以其简单，方便，灵活见长，所以传统 HIS 不适合云的生态 ( 当然以后 HIS 开发微服务化后则还需要观察 ) 。
2. 如果 HIS 上云后， HIS 系统的最重要的瓶颈在于医院内部与云之间的网络链路的互联的问题，当然可以通过冗余链路等方式做好应急备份，但是继续现在运营商光纤铺设的管路现状 ( 与市区多类线缆交汇，容易因为其他线缆的维护导致光纤的中断 ) ，所以不建议上云。
3. 从快速系统业务恢复需求的角度，因为上云后，系统的设备维护权在运营商或其指定的维护商身上，如果系统故障，虽然有合同要求 24 小时及时响应，但是实际可能系统回复的时间会加长，不像本地架构时能快速响应和恢复。
至于上云后和传统的架构在备份、容灾和应用的差别，其实差别不大，主要是云的备份容灾更简单易用的区别。
【 A2 】 nightdxl 华为数据存储解决方案中心 架构师：
医院 HIS 系统的本地传统构架，应用相对独立，备份和容灾主要依赖于本次采购的硬件自身的数据安全性设计，譬如双活、 3DC 等方案，以及 RAID2.0+ 等特性，而云方面则基本上取决于所采用云所提供的相应云服务；云上的扩展性更好，数据共享和大数据分析等方面有先天性优势，但私密性略逊于本地传统架构。医院对于 HIS 系统数据保密性要求更高，对多院区、多医院数据共享没有很高要求的场景，本地传统构架更合适，对于互联网医院、多方 HIS 数据分享有较多需求，对数据私密性没有非常高要求的场景， HIS 上云会更加便捷。
三、集成平台存储选型问题探讨
【 Q9 】集成平台 IT 存储架构应如何选择？集中式架构和分布式架构优劣势体现在哪些方面？
【 A1】 zyp8365 广东省中医院 数据库管理员：
集中式架构优点是稳定可靠，维护方便，缺点是当存储扩展到一定容量或规模的时候会出现控制器瓶颈，性能会下降。分布式架构优点是扩展灵活，缺点是依赖以太网络作为数据交换网络稳定性略差，性能主要消耗在维持数据一致性和副本等上，扩展规模与实际性能的关系需要严格的测试。
集成平台是采用集中式还是分布式，主要看如下：1. 医院的体量。2. 后续发展预期。3. 医院 IT 技术人员技术能力。鉴于现在信息发展状态，预算足够，个人建议混合结构，数据类放传统集中式，应用类放分布式。当然，从来没有一个通吃的解决方案，选择什么架构还是要根据医院实际情况与需求来确定。
【 A2 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
平台的存储构架选型，具体还是要根据平台自身的建设规模和后续扩展性来选择。
集中式系统架构的最大的特点部署结构非常简单，因为无需考虑如何对服务进行多节点的部署、也就不用考虑各节点之间的分布式协作问题了，但是，因为采用了单机部署，所有的功能都集成到了主服务器上，对于服务器的性能要求很高，性能也不好。带来的问题有系统大而复杂、难以维护和发生单点故障、扩展性差等问题。发生单点故障还可能造成整个系统或整个网络的瘫痪。优点也显而易见，便于维护，操作简单。在规模不大的情况下，部署方便，结构相对简单啊，成本相对较低，但后期如果扩容需求增大，由于竖向堆砌的特性，则很大可能会演化成高烟囱构架，造成成本高昂。
分布式系统是一个硬件或软件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统，即分布式就是一群独立于计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多， CPU 、内存、存储资源等就越多，能够处理的并发访问量也就越大，可以很方便的横向扩容，成本优势也会凸现出来。分布式空间上计算机随意分布，计算机之间没有主次之分。系统资源为所有计算机共享，多台计算机协调完成一个共同任务，系统内任意两台计算机可以互相通信交换信息。
【 Q10 】 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 的级别，非常适合于核心系统的老旧存储更新替换。数据在线迁移的项目都要具体分析，华为可以提供专家进行一对一技术沟通，如果需要可以反馈给社区或私信华为专家联系。
【 Q11 】新老存储兼容问题如何解决？
【 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 等，都可以做到数据的无缝迁移；如果旧存储还未到报废期，还可以使用，又希望新存储接管旧存储 ( 做存储虚拟化 ) ，则主要实现方式有虚拟化网管或者存储虚拟化方式，这个时候就要看旧存储在不在虚拟化网关或者新存储的兼容列表中，如果不在也做不了接管。但是个人建议，因为存储更新换代比较快，鉴于木桶短板效应，不太建议用新存储虚拟化接管旧存储。
五、存储技术应用类问题探讨
【 Q12】 OceanStor 全闪存与其他传统存储厂商闪存相比，性能如何？有哪些优缺点？
【 A1 】 chenmingfu 宁夏银行股份有限公司 基础架构组长：
OceanStor 存储闪存盘上采用去全局磨损均衡技术，将业务负载均衡到所有 SSD 上，并且采用华为专利的反磨损均衡技术，避免多盘集体失效，在部件级构建了极高的可靠性；
在架构级层面， OceanStor 存储 Dorado 系列高端全闪存的 SmartMatrix 架构采用前后端全联接设计和全对称的 A-A 控制器设计，可以实现控制器 8 坏 7 的极端情况和 100% 的负载均衡；
在产品层面，硬件上可容忍 9 级抗震，软件上可容忍 3 盘同时失效，基于硬件重构和软件深度优化实现单套设备的极致可靠
在方案层面， OceanStor 存储 Dorado 系列全闪存还采用了免网关的双活方案，减少了故障节点，降低了系统布置的复杂度。
【 Q13 】华为免网关双活与传统的基于存储网关双活相比有哪些优势？
【 A1 】犹大 华为数据存储解决方案中心 医疗解决方案高级专家：
传统的基于网关的双活，需要额外在存储上层部署单独的网关，这种方式首先增加了网关建设成本，其次也额外增加了故障点，网关故障会导致双活异常，第三增加了网关和存储的通信路劲，双活时延会增加。
采用华为免网关双活存储建设方案，建设成本降低，网关故障点会减少，并且双活时延会进一步降低，这些都是免网关双活存储带来的独特价值。当前华为所有存储的双活设计都是按照免网关进行设计的， 并且主流存储厂商都逐步在往免网关双活进行演进。
【 Q14 】在如何兼顾性能和成本的情况下，将 NAS 存储融入到 Vsphere 应用 +FCsan 存储架构中去？
【 A3】 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 基本上通吃一切以太网。
六、智慧医院软件类问题探讨
【 Q15 】 HIS 系统如何帮助医院实现数据标准化和统一化？
【 A1】 zyp8365 广东省中医院 数据库管理员：
现在医院信息化的实际情况是鉴于业务专业性或采购或政策等不同原因导致不同业务购买的不同厂家的信息系统，而不同厂家的信息系统因为标准不统一形成信息孤岛。如何将这些孤岛互通互联起来，可以通过 HIS 抑或是集成平台将各个业务系统串联起来。但是不管是哪种方式，都要通过数据的标准化和统一化才能实现。数据的标准化和统一互化，最重要的是整个医院要统一数据字典，包括人事，科室，检验，检查，诊断，耗材，部位，药品等，只有梳理完成这些字典，并形成一套字典的维护技术规范和流程，才能做好数据的统一和标准化。
【 Q16 】智慧 HIS 如何解决精准预约床位问题？
【 A1】 zyp8365 广东省中医院 数据库管理员：
按照楼主说的，预约系统和 HIS 之前的同步方式是通过后台 job 或计划任务去做同步的，如果要实现精准的预约床位，主要有两种方式实现：第一种是，在预约的时候通过日期判断，如果是前一天或更前的，按照现有系统流程，如果是预约今天的，封装查询 HIS 系统床位数据语句，再更新预约系统床位数据，完成预约，这种方式的好处是有预约的时候才会去查 HIS ，缓解了接口的压力，但是缺点是，如果预约的时候 HIS 有床位更新，可能会有脏数据，如果在查询 HIS 时预约系统有问题也可能产生分布式事务锁。第二种是，预约系统和 HIS 根据床位信息做实时同步接口， HIS 系统的床位有任何更新，都推送给预约系统，以更新预约系统床位信息，可以避免上述问题，但是相对来说接口压力会比较大。主要看院方的取舍问题，综合考虑预约系统和 HIS 系统的业务。
【 Q17 】 医院集成平台消息交互标准如何选择？
【 A1】 zyp8365 广东省中医院 数据库管理员：
1 、 目前 《国家医疗健康信息医院 互联互通标准化成熟度测评》是目前乃至日后一段时期内的一个常态化的信息化建设评价标准 ，个人建议还是要以 《国家医疗健康信息医院 互联互通标准化成熟度测评》标准为依据，而其它的国际标准作为参考。国家有的，按国家的，国际有的参考国际的，都没有的，参考厂家或自行拟定，等国家的出台后再进行对标对照。
2 、集成平台上线时，就应该定好对接的原则、方式和流程等标准，而且对接的顺序也应该先易后难，先异步后同步的实施方式，积累经验后再向实时复杂的业务对接扩展。而且不管是多大还是多小的一个对接，应该都要有对接负责人去统筹安排和盯紧对接的相关事宜，不然对接将无序开展。
3 、主数据包括人员、科室、诊疗项目、药品、诊断、耗材、部位等等，主数据的建设包括两部分工作内容：主数据的梳理和主数据的系统对接；两者可以并行做。主数据梳理应找到该主数据的干系部门和科室，如检验诊疗项目的主数据，应找医院的医务、检验科、审计科等相关科室一起理顺数据类型、定好梳理规则，并确定好后续主数据上线后的维护流程，并且着手去梳理主数据；同时，要求厂家如 HIS 、检验的厂家、平台的厂家，一起协调接口的开发、测试等工作，过程中要特别重视测试的工作，要进行业务全流程的测试，如 HIS 通过新的主数据的开单、收费、发送给检验系统后检验系统执行、出报告，回传结果等，也要做好边界值等的测试，保证测试全面。另外值得提出的是，在上述两部分工作都做好后，应该拟订好上线计划，分成存量数据和增量数据的上线，存量数据可逐步推进，先推进若干项目，稳定后再逐步更新所有，增量部分则商量好各相关系统的上线要求和计划，分步有序开展。另外，一定要重视后续主数据上线后的维护流程、人员的拟定和确立，而且要严格执行，不然后续数据更改无需，又会导致数据的混乱。
联系客服
