医疗行业超融合方案设计Word文档下载推荐.docx

医疗行业超融合方案设计Word文档下载推荐.docx

《医疗行业超融合方案设计Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《医疗行业超融合方案设计Word文档下载推荐.docx（21页珍藏版）》请在冰豆网上搜索。

SDN可以让网络具有可编程能力，包括能力开放、控制面和数据面解耦，以及集中控制等。

NFV就是网络功能的虚拟化，利用通用的硬件平台和虚拟化技术，取代现在的专用网络设备，例如负载和路由等传统网络设备。

SDN和NFV是两个关系密切，但又相对独立，都可以让超融合系统的网络变得更加开放、敏捷和聪明。

通过超融合系统的建设，最终可以实现全软件定义的数据中心。

有效整合服务器、存储和网络等资源，最大效率的利用硬件设备，满足新的医疗信息系统各项业务的性能需要。

同时还可以对数据中心硬件设备进行有效管理和监控，降低运维和管理成本。

2设计原则

在方案设计中我们将遵循以下总体原则：

1、以医院业务需求为导向

超融合架构最终还是要为医疗业务服务的，因此在架构设计上一定要以医疗业务的需求为导向，充分考虑非功能需求，例如系统的重要程度、安全要求、业务连续性等。

2、遵循医疗行业标准

医院大部分业务系统都是面向社会和公众的，在医院基础架构建设时，应符合国际、国家、医疗卫生行业标准、规范和医院自身的发展规划。

3、提高资源利用率

现已经部署了大量的服务器，资源使用率低是较突出的一个问题。

要充分发挥超融合架构的这一最大的特点，在保证性能的前提下进行合理设计。

在同一设备中合理分配计算、存储和网络等虚拟化资源，最大程度的提高服务器设备的利用率。

4、系统扩展性

在超融合架构中，可以进行横向灵活扩展，使医院的IT基础架构成为一个动态、灵活、具有弹性的IT基础架构。

要考虑在医疗业务系统实时运行过程中，计算资源和存储资源的同时动态调整和扩展的问题，避免对现有生产系统产生影响。

5、安全可用性

业务系统的高可用性和安全性是医院业务得以持续运行的保障。

在超融合架构设计中，应该以软件定义技术为主，结构超融合的分布式架构的特点，解决系统单点故障问题和性能瓶颈等问题，在满足业务系统可用性的同时保证医院系统运行安全和数据安全。

3超融合架构总体设计

超融合架构在数据中心，以软件定义为解决方案，使用通用的X86服务器+虚拟化软件建设计算、分布式存储和网络等资源池，极大地简化了数据中心的基础架构。

而且通过软件定义资源池为分布式架构，可以实现无单点故障、无单点瓶颈、横向自动弹性扩展、性能线性增长等能力。

在物理层，可以选择通用的X86服务器和交换机。

在软件定义层，可以根据现有数据中心虚拟化的使用情况，结合未来数据中心的发展技术路线和方向，选择合适的虚拟化软件，例如VMwarevSphere、KVM或Hyper-v等，尽量和生产中心保持一致，方便业务的转换和迁移。

如果选择开源类产品路线，尽量选择稳定可靠的产品，不要轻易尝试新出的和不成熟的开源虚拟化产品。

在管理层，大多数商业的超融合产品都会提供一套通过简单、方便的管理界面，实现对数据中心基础设施资源的管理。

但是数据中心如果已经有一套云管理平台，要考虑新采购的超融合系统和已有云管理平台的对接问题。

尽可能使用一套云管理平台，必要时需要进行二次开发，避免出现多套管理系统，多个云管理平台。

使用一套云管界面对整个数据中心进行统一的监控、管理和运维。

超融合架构总体设计如下图：

具体设计如下：

一、搭建超融合系统平台。

在数据中心机房新建一套超融合系统集群，并对医院现有的业务系统进行评估，按照评估结果，将适合的业务系统和数据迁移至超融合平台，打破原有竖井式的纵向扩展架构。

HIS/PACS等核心业务数据库系统不建议做迁移，由于其对物理机性能要求比较高，而且有数据一致性要求。

而目前市场上各个厂商的超融合系统的分布式存储对数据库支持能力不同，为了保证HIS/PACS等核心业务数据库的性能和数据的实时性，需要对选定的超融合系统做更详细的POC测试，确定满足条件后再进行迁移。

二、对原有设备进行淘汰和利旧整合。

建议淘汰的设备：

服役超过5年以上的服务器，不建议继续使用，可以进行淘汰处理，避免潜在的安全隐患，同时还可以降低整体能耗成本。

利旧整合的设备：

可以利旧整合的服务器主要有两种解决方案。

首先，可以用于开发测试，但是需要注意的是，对于这部分资源最好单独建设一个资源分区，不要和生产资源混合在一个资源池里，做好安全隔离，避免互相影响。

其次，可以选择部分性能比较好，未过保修期（通常服务器保修年限为三年）且具有整合价值的服务器，然后部署超融合系统，加入到超融合系统群集当中。

但是仍然建议单独设计一个资源池，不要与新采购的超融合系统混用一个资源池，同样做好安全隔离。

因为老旧的服务器，即使部署了相同超融合系统软件，由于其CPU型号比较旧，而且型号不统一，很难和新采购的超融合系统设备相互兼容，不建议部署在一个资源池。

三、建立统一的云管理平台。

云管理平台主要负责对资源的管理、弹性调度以及操作维护等综合管理功能，是云平台管理的核心，在同一个web界面提供云资源管理、云运维管理和云服务管理的功能。

在采购新的超融合系统以后，要求必须能够和现有的云管理平台兼容，能够进行二次开发和对接。

或者直接采用超融合系统的云管理整合原有的虚拟化资源，但是绝不能同时出现多个云管理平台，这样非常不利于资源的统一管理和调配，给医院的信息化管理带来很大的困难。

云资源管理负责云平台资源虚拟化和资源分配，将物理资源（计算、存储、网络等）转换成可动态调整的虚拟资源，供虚拟机使用，提供高可用性的弹性虚拟机，保障业务系统的连续性与虚拟机的安全隔离。

云运维管理可以实现物理设备、虚拟设备、应用系统的集中监控、管理维护自动化与动态化。

云服务管理对外的主要工作是实现用户管理、集群管理、业务模板管理、虚拟机管理、虚拟机发放、统一硬件管理、告警、监控等功能。

4超融合架构业务设计

医院业务系统分析主要是对现有医院业务系统进行梳理，对医院的业务系统进行评估和分类，选择适合部署在超融合系统之上的系统。

主要包括以下几个方面的工作：

1、对业务系统进行分析，选择适合迁移到超融合架构的应用。

建议优先从非核心的系统开始尝试部署，然后逐渐扩展到其他核心业务系统。

2、评估并计算系统资源的使用量，包括计算、存储、网络和安全资源等。

3、根据分析出的需要迁移的业务系统资源量，评估现有机房的物理环境和网络环境，是否能够满足迁移后的超融合系统部署需要。

4、针对超融合系统的性能需求和扩展能力的需求进行设计，为选择适合的超融合架构梳理依据。

4.1业务迁移分析

医院业务系统主要分为四大类，分别是：

1、行政管理系统。

包括人事管理系统，财务管理系统，后勤管理系统，药库管理系统，医疗设备管理系统，门诊、手术及住院预约系统，病人住院管理系统等。

2、医疗管理系统。

也是核心业务系统，主要包括门诊、急诊管理系统（HIS），影像文件系统（PCAS）、病案管理系统，医疗统计系统，血库管理系统等。

3、决策支持系统。

包括医疗质量评价系统，医疗质量控制系统等。

4、各种辅助系统。

如医疗情报检索系统，医疗数据库系统等。

以上业务系统，除了核心HIS和PACS数据库外，其实大部分系统都适合迁移至超融合系统，对于业务系统的最终选择，还是需要分析其运行和使用的现状，可以按照以下情况进行判断。

1、原有业务系统运行在物理机上，且物理机的资源利用率非常低。

建议尽快迁移到超融合架构上，可以最大程度提高医院信息系统的灵活性和设备使用率。

迁移成功的前提是，原有业务系统的开发商需要能够提供必要的支持，否则迁移部署和验证可能会有些困难。

2、原有业务系统运行在物理机上，且物理机的资源利用率非常高。

通常核心业务系统的数据库属于这一类的应用，不建议迁移到超融合平台之上，否则性能问题会是个极大的挑战。

3、原有业务系统运行在虚拟机上，且虚拟机软件的类别、版本和预期采购超融合系统基本保持一致。

对于这类应用，迁移是非常容易的，只需要将虚拟机直接迁移到超融合平台上就好，不会存在太多的障碍，可以完全加入到迁移的名单中。

4、原有业务系统运行在虚拟机上，且虚拟机软件的类别、版本和预期采购超融合系统完全不一致。

对于这类应用，迁移可能会有些麻烦，要看是否能够找到合适的V2V迁移转换工作。

否则就需要在超融合系统上重新部署，然后再迁移数据。

如果要将这类应用加入到迁移名单中，需要提前做好POC测试工作。

4.2业务资源分析

在超融合平台实施前，必须根据现有需要迁移的业务进行资源分析，确定超融合系统设备的资源使用量。

主要分析的内容是对现有业务系统的计算、存储等性能进行分析。

最终得出超融合系统的规划配置内容，包括超融合集群数量、容量规划、性能、应用需求等，可以指导超融合系统实施策略和实施路线规划。

分析的主要内容可以参考下表的示例进行统计：

通过最终的超融合系统资源需求统计，可以得出超融合系统的CPU、内存和存储容量，然后选择合适的超融合节点数量和群集规模。

CPU的数量通常决定了超融合系统的节点数量和群集规模。

超融合系统通常都是一台2U高的X86服务器。

高密度的X86服务器，每台可以提供2-4个Node（节点）的资源。

每个节点通常为1-2颗CPU+可选容量的内存（CPU核心数量和内存容量可以根据需求来进行选择）。

从技术上讲，有些厂商的超融合系统是不限制单个群集的节点规模数量的，但是最佳实践是一般单个群集不建议超过64个节点，比较方便管理，性能上也比较可靠。

存储容量的配置需要根据原有业务的容量进行定量分析后得出。

例如：

原有存储配置100TBSATA磁盘，那么超融合架构也需要配置同样的资源，避免浪费。

为了保证数据的冗余性和可靠性，通常分布式存储都是多副本的，而且以3副本最为常见，所以在配置物理容量时，需要将实际数据融量至少乘以3倍，而且大部分分布式存储系统都是以SSD磁盘作为缓存使用，这部分SSD的存储容量是不能计算在内的。

现有虚拟化系统环境类型决定了超融合产品的实施策略和实施路线，因为不是所有的超融合产品都支持全部的虚拟化层软件。

例如VMware就不支持KVM，无法直接进行迁移。

如果采用支持KVM的超融合系统，那么原有的VMware虚拟机就需要进行迁移转换后，才可以在基于KVM的超融合系统上运行。

在物理网络资源的定量分析上，也需要考虑新的超融合系统的网卡性能和数量，如果原有系统环境全部为双链路万兆网络，那么新组建的超融合网络也必须是双链路万兆网络。

而且网段数量至少要增加两个，一个内部通讯网络和一个管理网络。

网卡同时也需要增加两块。

5超融合架构物理资源规划

5.1物理架构图

图：

超融合架构物理架构方案

物理架构图