医院存储方式选型?

我院已于去年建设了医院信息系统集成平台,我们建设的模式是单纯的集成平台,没有建集成平台+私有云,因此,我们还是采用传统的集中存储模式。虽然,从目前看,这种集中存储对于系统的稳定性、安全性、数据的一致性还是能满足我们医院现有业务的需求,但是我们所关注的是,随成医院业务...显示全部

我院已于去年建设了医院信息系统集成平台,我们建设的模式是单纯的集成平台,没有建集成平台+私有云,因此,我们还是采用传统的集中存储模式。虽然,从目前看,这种集中存储对于系统的稳定性、安全性、数据的一致性还是能满足我们医院现有业务的需求,但是我们所关注的是,随成医院业务的扩展,我们现有的这种模式是否适合分布式存储?

收起
参与22

查看其它 4 个回答wuke的回答

wukewuke售前技术支持SmartX超融合

医院的需要什么类型的存储,是根据数据类型来分的,总体来看,需要落盘存储的数据大致可以分成两大类:

  1. 核心数据库以及核心数据仓库数据,比如HIS数据库,CDR数据仓库等
  2. 半结构化或非结构化数据,如PACS数据,办公文件数据等

两大类数据对存储的需有所区别,下面分开讲解:

  1. 核心数据库以及核心数据仓库数据,这里即可以包括HIS等传统医院核心业务的数据,也包括CDR等中间库,主题库等数据仓库类的的数据,基本是以行或列格式存储的结构化数据,核心数据库算是OLTP类业务,和核心数据仓库算是OLAP类业务,虽然两者的要求是有区别的,但需要的底层存储往往都需要提供较高的IOPS,以及稳定的性能,此外也需要保障足够的可用性,因为HIS数据库是医院最核心业务的支撑,如果出现停机,会造成后果不堪设想的后果。出于可用性,稳定性和性能的考虑,医院在从前,往往选择冗余SAN交换机+独立SAN存储进行支撑,且等级要求高的医院,也做了存储级的灾备或双活以保证数据和业务的安全。在从前,这种架构很好的支撑业务的发展,但随着时间的发展,这种架构也遇到了各种问题:

(1).由于独立存储的特点,采购往往采用“提前采购”的方式,即一次规划就计划3-5年的数据使用量以及性能需求,一次性的前期投入,这种方法一次性投入的成本高,且很难预估准确未来几年的发展情况,往往有投资浪费

(2).相反的情况是,采购独立存储时,预估不足,导致容量或者性能瓶颈。如果是容量瓶颈则需要扩容硬盘空间,而传统磁盘阵列往往的经营模式是扩容时价格比较高,结果就导致了后续使用成本高;如果是性能不足,如果硬盘少导致硬盘通道少进而导致性能不足的话需要扩展更多的硬盘,不但需要停机调整业务,扩容的成本也很高,如果传统存储的瓶颈发生在磁盘阵列控制器上,就更麻烦,因为好多中端存储的磁盘控制器是很难扩展的,导致了性能瓶颈一直存在难以解决,如果是高端磁盘阵列,往往需要采用增加控制器的方式进行性能扩容,这时候扩容的成本又居高不下,经过再三考虑,往往不得不重新采购新的存储,这又牵扯到了数据迁移的时间与风险,也消耗人手。

(3).部分医院出于需要更高等级的业务可用性,往往做了存储阵列级别的容灾备份或者双活,但这样的成本非常高,因为需要至少两套的独立磁盘阵列和对应的授权以及服务费,这也导致了医院只能在最核心的业务上实现存储双活或存储灾备保护,很多也是很关键的业务,比如电子病历等,因为受制与成本太高,导致没有高可用保护,存在单点故障影响业务可用性,甚至可能导致数据损坏的风险。

(4)服务器,虚拟化,存储,存储双活,数据库双活分开管理,管理很复杂。如有管理配置表维护不慎,则可能引发管理风险,管理的效率也低,而且随着医院的发展,IT系统也越来越复杂,需要IT管理人员投入更多的精力支撑业务发展,医院本来管理IT的人手就不,人手不足的情况就会越来越明显,不论什么存储,只要是和主机,虚拟化分开管理的,哪怕是独立的分布式SAN存储,都会遇到这样的问题。

基于以上原因,目前越来越多的医院,放弃了采购传统的SAN存储,而采用无单点故障的,自带数据多副本功能的,可按需投资在线扩容的,无传统SAN存储控制器性能瓶颈分布式块存储(如SmartX的ZBS分布式快存储),对传统存储进行替换。而且,从各级医院实际的落地案例看,医院往往更多也并不是采用存储单独替换的方式进行存储基础架构的建设,而是把服务器,虚拟化,SAN交换,SAN存储四者的更新合并到一起,选择用带有分布式块存储功能超融合方案,逐步的进行连带上述四个部分的整体基础架构转型。超融合是采用通用多台x86服务器组成集群,加上超融合系统里自带的的分布式存储软件以及虚拟化软件,将x86服务器上的硬盘作为存储资源池,将x86服务器作为计算资源池,进行整体的,分步的超融合转型,因为这么做的话,上述的四大问可以同时得到解决:

(1)首先基础架构的管理得到极大简化,超融合不需要独立的SAN交换机和SAN存储,往往就一个界面,各种资源一目了然,管理效率极大提升的同时,也极大的降低了管理的风险,解放了双手;(

(2)超融合是可以基于节点扩展的,计算或存储资源不足时,可以线性在线扩展节点进超融合集群即可,无需停机,无需数据迁移,在线扩容,且一些品牌如SmartX的数据可以自动均衡至新扩节点,整个过程高效且低风险,同时,可线性扩展就意味着可以按需投资,不用一次先规划5年的资源了,完全可以在需要时再进行超融合集群,保护了投资

(3)以SmartX超融合为例,超融合自带的ZBS分布式块存储软件具备了多数据副本的能力,数据被切块且生成2-3个副本(几个副本看实际业务选择,重要的业务副本就多)到了多个节点,数据就具备了高可用性,一个节点出现故障时,业务虚拟机可以在3分钟内,自动漂移至完好的节点上运行,且过程是自动的,数据无丢失,相当于基于超融合支撑的所有主机,都自动的具备了高可用能力,这就扩大了业务高可用的覆盖面,使得所有业务都具备高可用的能力,此外超融合也支持远程灾备与双活,投资的性价比很高。

至于超融合的性能和可用性能否支持医院的核心业务,目前超融合SmartX已经具备众多的医院案例,从大型三甲医院到二级医院,均有使用超融合,Smart X超融合有有大三甲医院案例,分别把HIS的核心数据库,CDR数据仓库,电子病历,集成平台等核心业务系统以及对应的oracle数据库承载在Smart X超融合上,且性能优异,使用多年没出过什么问题,SmartX超融合作作为中国金融行业的超融合软件占有率第一名,其超融合提供的安全性,而可用性,性能和稳定性也是金融核心生产级的,完全可以做到统一支撑三甲医院到二级医院的全部业务,包括核心业务,综合业务,内网和外网的所有业务,都可以通过超融合进行安全,高效的统一承载。

  1. 至于半结构化或非结构化数据,如PACS数据,办公文件数据等,存储的需求往往更多的体现在PACS数据上,因为数据增量非常快且往往需要长期保存,因此往往也是出于成本以及无单点故障,管理便捷的类似的考虑,采用软件定义的分布式的NAS存储进行存储,而且细分的话,PACS数据还可以进一步细分成,三年内的热/温数据,以及三年以上的冷数据,两者的需求又有不同,热/温数据因为被访问的次数更多,因此需要的是较高的存储吞吐量,因此对存储的性能往往是有更高需求的,这个部分的软件定义分布式存储成本相对较高,而且同样对服务器资源有较高要求;而冷数据更多关注的是长期保存,数据不丢失,因此追求的往往是高性价比且安全的存储数据,性能放到次要考虑,只需要的时候能把数据较快的找回来即可,因此往往会考虑性价比优异的大SATA盘+可线性扩展的软件定义分布式NAS存储。也有少数医院将这部分数据归档到成本更低的对象存储,需要时将这部分数据通过接口将所需PACS数据调回至热/温层的分布式NAS存储进行使用,但使用对象存储目前还未成为主流,原因很简单,因为往往对象存储的接口是rest等接口,应用不做开发的话没法直接调用,往往需要再有个温热层的分布式NAS存储作为缓冲,这种方式被厂商绑定的可能性更高,因此多数医院还是使用软件定义的,低成本的分布式NAS存储存储冷的PACS数据。

由于正好热/温层PACS数据对服务器资源的需求也比较高,因此一些医院干脆选择一步到位,直接用带分布式存储功能的超融合直接承载了近三年的PACS数据,并将三年以上的冷PACS数据放至软件定义的,低成本的,独立的分布式NAS存储资源池上,SmartX就有这样的三甲医院的案例,以上回答了医院不同类型的数据需要什么样的存储,以及医院在实际建设中,往往会选择什么样的方案。至于存储介质,一般HIS系统和数据库若需要较高的IOPS,则可根据情况选择全闪的存储;若IOPS不是很高,则可以选择SSD+SAS盘的混合盘配置,用SSD进行加速;至于NAS,一般以大容量SATA/NL-SAS盘为主,对于PACS近期的热数据,为了保证访问的性能,可以考虑SSD+SAS或 SSD+NL-SAS两种配置的存储介质。

软件开发 · 2022-08-10
浏览688

回答者

wuke
wuke0010
售前技术支持SmartX超融合
擅长领域: 存储灾备超融合

wuke 最近回答过的问题

回答状态

  • 发布时间:2022-08-10
  • 关注会员:7 人
  • 回答浏览:688
  • X社区推广