医疗行业超融合架构解决方案-架构方案设计篇

1 设计概要

综合需求分析篇（注：本文前篇为《医疗行业超融合架构解决方案——需求分析篇》，可点击标题阅读，也可以直接阅读本篇架构方案设计篇），结合目前医疗行业数据中心的演进方法论及最佳实践，建议采用分步分批的建设方式，使用扩展能力强，功能丰富的超融合基础架构方案，来满足医院业务系统高可靠性、高可用性、业务连续性、数据安全、数据备份、数据及应用容灾的需求。

建议未开始基于超融合架构建设数据中心的医院，采用分期建设的方法和设计思路。

数据中心第一期建设，需要对现有业务系统进行深入调研，分析各个业务系统的需求和特点，将适合部署到超融合的系统进行统一梳理资源需求，建设基于超融合架构的数据中心，然后对业务系统资源进行整合。整合后的资源要求能通过超融合系统自带的管理软件，结合医院现有云管理平台进行统一管理，实现在一个界面完成对全院所有资源的管理、分配和运维分析等操作。

数据中心第二期建设，在管理上，需要实现高度自动化的业务部署和运维。在建设上，可以开展网络SDN和NFV等系统的建设，这些也都是超融合系统建设的一部分。即使用通用的硬件服务器+软件就可以实现数据中心需要的大部分IT功能，不需要额外再采购专用设备。SDN可以让网络具有可编程能力，包括能力开放、控制面和数据面解耦，以及集中控制等。NFV就是网络功能的虚拟化，利用通用的硬件平台和虚拟化技术，取代现在的专用网络设备，例如负载和路由等传统网络设备。SDN和NFV是两个关系密切，但又相对独立，都可以让超融合系统的网络变得更加开放、敏捷和聪明。

通过超融合系统的建设，最终可以实现全软件定义的数据中心。有效整合服务器、存储和网络等资源，最大效率的利用硬件设备，满足新的医疗信息系统各项业务的性能需要。同时还可以对数据中心硬件设备进行有效管理和监控，降低运维和管理成本。

2 设计原则

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

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

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

2、遵循医疗行业标准

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

3、提高资源利用率

现已经部署了大量的服务器，资源使用率低是较突出的一个问题。要充分发挥超融合架构的这一最大的特点，在保证性能的前提下进行合理设计。在同一设备中合理分配计算、存储和网络等虚拟化资源，最大程度的提高服务器设备的利用率。

4、系统扩展性

在超融合架构中，可以进行横向灵活扩展，使医院的IT基础架构成为一个动态、灵活、具有弹性的IT基础架构。要考虑在医疗业务系统实时运行过程中，计算资源和存储资源的同时动态调整和扩展的问题，避免对现有生产系统产生影响。

5、安全可用性

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

3 超融合架构总体设计

超融合架构在数据中心，以软件定义为解决方案，使用通用的X86服务器+虚拟化软件建设计算、分布式存储和网络等资源池，极大地简化了数据中心的基础架构。而且通过软件定义资源池为分布式架构，可以实现无单点故障、无单点瓶颈、横向自动弹性扩展、性能线性增长等能力。

在物理层，可以选择通用的X86服务器和交换机。在软件定义层，可以根据现有数据中心虚拟化的使用情况，结合未来数据中心的发展技术路线和方向，选择合适的虚拟化软件，例如VMware vSphere、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个节点，比较方便管理，性能上也比较可靠。

存储容量的配置需要根据原有业务的容量进行定量分析后得出。例如：原有存储配置100TB SATA磁盘，那么超融合架构也需要配置同样的资源，避免浪费。为了保证数据的冗余性和可靠性，通常分布式存储都是多副本的，而且以3副本最为常见，所以在配置物理容量时，需要将实际数据融量至少乘以3倍，而且大部分分布式存储系统都是以SSD磁盘作为缓存使用，这部分SSD的存储容量是不能计算在内的。

现有虚拟化系统环境类型决定了超融合产品的实施策略和实施路线，因为不是所有的超融合产品都支持全部的虚拟化层软件。例如VMware就不支持KVM，无法直接进行迁移。如果采用支持KVM的超融合系统，那么原有的VMware虚拟机就需要进行迁移转换后，才可以在基于KVM的超融合系统上运行。

在物理网络资源的定量分析上，也需要考虑新的超融合系统的网卡性能和数量，如果原有系统环境全部为双链路万兆网络，那么新组建的超融合网络也必须是双链路万兆网络。而且网段数量至少要增加两个，一个内部通讯网络和一个管理网络。网卡同时也需要增加两块。

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

5.1 物理架构图

图：超融合架构物理架构方案

物理架构图描述：

基于超融合架构的数据中心，在网络上采用扁平化二层网络架构（核心层、接入层），使用网络虚拟化技术，核心交换机承担着核心层和汇聚层的双重任务。

扁平化方式降低了网络复杂度，简化了网络拓扑，提高了转发效率。二层网络架构中，采用虚拟集群和堆叠技术，解决链路环路问题，提高了网络可靠性。核心交换机设置VLAN的IP地址，接入交换机划分VLAN，做二层转发。

在逻辑上，超融合架构不改变原有医院生产中心网络架构。原有设备网络、服务器、存储和安全等设备可以继续利旧使用。

针对新购买的超融合设备，需要单独设立二个安全域，分别为超融合系统安全区和超融合系统利旧资源区，分别部署新采购的和利旧的超融合服务器设备。为了保证传统业务的可靠的运行，需要与传统架构区的设备进行安全隔离，但是都处于内网，是可以互相访问的，不影响系统的正常访问和运行。为了保障内网的数据安全和网络安全，外网用户访问仍需要通过VPN授权才可以访问内网数据，通过DMZ区访问web服务。

超融合架构物理机一般为机架服务器。同时融合计算和存储资源，提供虚拟化资源。每台服务器配置1块2端口的10GE网卡。通过万兆接入交换机和核心交换机进行连接。配置2个千兆网络，一个连接生产网络，一个连接管理网络。

超融合架构物理机存储系统采用分布式架构，通常配置有SSD+HDD或者全闪存磁盘的模式。可以根据数据存储需要进行配置。对于超融合系统的存储，要求支持多副本存储、数据本地化、热点数据自动分层。另外，可以根据需求选择在线重删、压缩、快照、克隆、同/异步备份和跨地域远程数据容灾等高级功能。

5.2 计算资源规划

计算资源是通过对x86服务器CPU虚拟化来实现的，根据现有虚拟化环境，可选择VMware vSphere、MicroSoft Hyper-v或KVM等Hypervisor，通过虚拟化技术组建计算资源池，为业务系统的虚拟机提供不同的服务质量和能力。以VMware为例，可提供HA高可用、FT容错、vMotion在线迁移和DRS资源动态负载均衡等能力。

计算资源的规划需要根据历史业务对资源的需求推导出需要新采购的超融合服务器的数量。包括迁移场景需要的服务器数量和新建场景需要的服务器数量。如果没有可供利旧的服务器，那么这两个部分相加，就是全部的计算资源总量。

迁移场景和新建场景由于维度不一样，统计出的服务器数量可能也会有所偏差，通常需要综合进行考量评估，建议以服务器数量多的数值做为参考。

5.2.1 迁移场景服务器数量规划

这里借鉴并提供华为的服务器数量估算方法论做为参考，为简化计算过程，所有管理、计算和存储虚拟化软件节点的CPU资源开销按照10%进行计算，内存资源开销按照每台物理机100GB进行估算。

注：CPU和内存的开销需要按照预计采购的超融合系统进行修正。

5.2.1.1 从计算服务器CPU维度进行估算

使用SPECint2006 Rate进行折算，SPEC值可在http://www.spec.org/cgi-bin/osgresults查到。

单服务器需要计算能力=物理服务器的SPECCPU使用率/（1-CPU冗余度）

（1）现有旧物理服务器计算能力折算方法：

所有n台原服务器CPU能力折算值x=服务器1的SPEC值CPU使用率1/(1-CPU冗余度)

+ 服务器2的SPEC值CPU使用率2/(1-CPU冗余度)

+ …..

+ 服务器n的SPEC值CPU使用率n/(1-CPU冗余度)

（2）部署虚拟化平台的物理服务器的CPU能力计算方法：

假设部署虚拟化平台的单个物理服务器的SPEC值为y，单物理服务器的总逻辑核数为z。

虚拟化服务器的数量 N = x/(y90%),结果向上取其整数即可。如果数量≤3，那么至少配置3台。

举例：

比如40台型号为：Dell Inc. PowerEdge 2950 x64-based PC Intel(R) Xeon(R) CPU E5420 @2.50GHz, 2493 Mhz, 4 Core(s), 4 Logical Processor(s) 8.00GB的服务器的实际平均CPU使用率为30%。查表http://www.spec.org/cgi-bin/osgresults

获取其SPEC值为118。假定虚拟化后的目标CPU能力冗余度30%。

x = 40（11830%/（1-30%））=2022.857

若最终选择Intel Xeon E5-4610，同样查http://www.spec.org/cgi-bin/osgresults ，得到其SPEC值为883。服务器共48逻辑核，部署所有管理、计算和存储虚拟化软件节点的CPU资源开销为10%。

虚拟化服务器的数量N=2022.857/(88390%)=2.545，虚拟化服务器的数量为3台。

5.2.1.2 从计算服务器内存维度进行估算

直接使用内存使用量进行计算。

单计算服务器实际需要的内存（虚拟化后）=现有物理服务器的内存内存使用率/（1-内存冗余度）

（1）现有物理服务器内存折算方法：

所有n台原服务器内存折算值 x = 现有服务器1的内存值内存使用率1/(1-内存冗余度)

+现有服务器2的内存值内存使用率2/(1-内存冗余度)

+ …..

+现有服务器n的内存值内存使用率n/(1-内存冗余度)

（2）所需虚拟化服务器的内存计算方法：

假设虚拟化后的单个服务器的内存值为 z。部署所有管理、计算和存储虚拟化软件节点的内存资源开销为100GB。虚拟化后的服务器实际能给虚拟机用的内存y=z-100GB，每台至少配置100GB以上，建议配置256GB。

虚拟化服务器的数量 N = x/y，结果向上取其整数即可。如果数量≤3，那么至少配置3台。如果数量太多，请增加单台服务器的内存容量。

举例：

假定原服务器的内存大小为8G，内存使用率为20%，共40台。虚拟化后的目标内存冗余度为40%

x =40（ 820%/（1-40%））=106.7GB

假定Intel Xeon E5-4610配置256GB内存（要求必须大于100GB），则实际可用的内存为：

y=z-100GB

=256GB-100GB

=156GB

从内存容量上看，需要纯计算节点的个数：

虚拟化服务器的数量 N = x/y=106.7GB/156GB=0.684，虚拟化服务器的数量为3台。

5.2.2 新建场景服务器数量规划

这里借鉴并提供华为的服务器数量估算方法论做为参考，为简化计算过程，所有管理、计算和存储虚拟化软件节点的CPU资源开销按照10%进行计算，内存资源开销按照每台物理机100GB进行估算。

注：CPU和内存的开销需要按照预计采购的超融合系统进行修正。

5.2.2.1 根据CPU资源需求维度估算

适用于对虚拟化后使用虚拟机规格（CPU、内存、磁盘、网卡）、虚拟机的数量都有清晰认识的场景，能够规划出各类虚拟机的规格和所需的数量：

总vCPU数=预计部署的每台VM虚拟机的vCPU数量的总和

注：vCPU是衡量一台虚拟机计算能力的主要指标，类似物理服务器的CPU。vCPU核数类似服务器CPU的核数（core）。一个利用率100％的vCPU的处理能力等于物理CPU一个超线程的处理能力。

1、根据计算能力总需求估算

CPU总物理核数=roundup（总vCPU数/单核超线程数/CPU利用率）

2、估算所需的服务器数量

物理服务器数量=roundup{[(CPU总物理核数/(服务器CPU个数CPU物理核数）90%]（1+服务器冗余率）}

结果向上取其整数即可。如果数量≤3，那么至少配置3台。

举例：

假定总vCPU的数量为100，服务器冗余率设定为30%，CPU利用率不超过70%，部署所有管理、计算和存储虚拟化软件节点的CPU资源开销为10%，拟定选择的超融合服务器为2颗12核心处理器2线程处理器。那么：

CPU总物理核数=roundup（总vCPU数/单核超线程数/CPU利用率）

= roundup（100/2/0.7）

=72

物理服务器数量为=roundup{[(72/(212）90%]（1+30%）}

= roundup{4.3}

物理服务器数量：需要5台。

5.2.2.2 根据内存资源需求维度估算

1、内存总需求

总内存=预计部署的每台VM虚拟机的内存数量的总和

注：内存大小是指虚拟机内存的最大规格值。

2、根据内存总需求估算

根据内存资源需求估算的服务器数量= roundup[(总内存/（单服务器内存容量-100GB）（1+服务器冗余率）]

结果向上取其整数即可。如果数量≤3，那么至少配置3台。如果数量太多，请增加单台服务器的内存容量。

举例：

假定总内存的数量为360GB，服务器冗余率设定为30%，部署所有管理、计算和存储虚拟化软件节点的内存资源开销为100GB，拟定选择的超融合服务器为256GB内存（至少100GB以上）。

物理服务器数量=roundup[(总内存/（单服务器内存容量-100GB）（1+服务器冗余率）]

=roundup[(360GB/（256GB-100GB）*（1+30%）]

=roundup[3]

物理服务器数量：需要3台

5.3 存储资源规划

超融合系统架构提供的存储资源，都是基于分布式的文件系统，可以将一组集群内的节点组成一个统一的分布式存储平台。对于业务系统来说，就是一个集中的共享式存储，与任何其他集中式存储阵列一样工作，由超融合存储系统管理模块对分布式存储进行管理。

超融合分布式存储系统的配置规划，需要根据历史业务对资源的需求推导出需要新采购的超融合服务器的硬盘数量。包括迁移场景需要的硬盘数量和新建场景需要的硬盘数量。如果没有可供利旧的服务器，那么这两个部分相加，就是全部的计算资源总量。为了减小不必要要的服务器数量，单盘尽量选择1.2TB或1.8TB产品。当然，为了使用更多的硬盘提升分布式存储性能，还需要综合考量。

以上除了需要提前确认好数据容量以外，还需要注意以下几点：

1、分布式存储架构以可以提供传统集中式存储的能力，包括块存储、文件存储和对象存储等。但并不是所有的超融合系统都能提供以上的存储能力。由于分布式存储的数据一致性不是很好，所以有些超融合系统提供的块存储服务是不能够安装ORACLE这类数据库应用的，即使能安装，效果也不会很好，性能会比较低。需要官方给出可安装的测试报告或者兼容性测试报告。

2、是否需要超融合存储系统提供快照、克隆、压缩和重复数据删除等传统集中式存储的特性。由于超融合系统也是近几年刚刚兴起，对于这类高级特性不如传统集中式存储支持的好，如果需要某种高级特性，需要提前对超融合厂商的相关存储产品进行调研，做好POC测试。

3、分布式存储资源池的组成通常为SSD+HDD的架构，SSD作为缓存盘，提升整个系统的性能。而且有的厂商要求严格的资源配比，以VSAN为例，需要1块SSD+最多6块HDD为一个逻辑磁盘组（VMware计划增加到最多7块）。而且1台物理主机最多只能有5个磁盘组。所以物理磁盘不能随意配置，需要根据超融合厂商的技术要求进行合理配置，避免资源浪费。当然也有的超融合厂商支持全闪存的架构，甚至可以使用PCI-E的SSD缓存卡进行加速，只是在成本上比较贵。

4、超融合的节点的硬盘数量会影响整个分布式存储系统的性能。如果超融合系统只有最少的3个节点，那么分布式存储系统的性能上基本上是无法超越传统集中式架构存储的，只有尽可能多的配置节点数量和硬盘数量，才有可能达到甚至超越传统集中式存储的性能。

5.3.1 迁移场景存储容量规划

这里借鉴并提供华为的存储容量估算方法论做为参考。由于IOPS不太容易评估，为简化计算过程，只考虑容量的计算。对于分布式存储的性能规划，建议通过POC测试进行，理论和实际往往差距较大。

容量计算：

基础数据：总的有效容量=x，磁盘标称容量=z，磁盘空间利用率=q，副本数=k

总的硬盘数量=roundup[总的有效容量/(zq)k]（向上取整）

举例：

假定现有需要迁移的数据，总计20000GB，预计购买的超融合服务器每台的磁盘标称容量z=1200GB，磁盘空间利用率q=0.95，副本数k=3.

按容量计算，硬盘数量为：

则利用上述公式：

总的硬盘数量= roundup[20000/(1200GB0.95)3]

总的硬盘数量= roundup[20000/(1140)*3] 

总的硬盘数量= roundup[52.633] 

总的硬盘数量为53块硬盘，每块盘容量至少为1200GB。

如果要加入SSD固态硬盘做热点迁移和自动分层，需要按照超融合系统要求的比例，购买SSD固态硬盘。

5.3.2 新建场景存储容量规划

这里借鉴并提供华为的存储容量估算方法论做为参考。由于IOPS不太容易评估，为简化计算过程，只考虑容量的计算。对于分布式存储的性能规划，建议通过POC测试进行，理论和实际往往差距较大。

1、存储总容量需求

类型i系统盘容量=系统盘空间×VM数量；

系统盘总容量=∑类型i系统盘容量

类型i数据盘容量=数据盘空间×VM数量；

数据盘总容量=∑类型i数据盘容量

2、根据存储总需求估算

根据存储空间计算所需的硬盘数量：

总的硬盘数量=roundup[(系统盘总容量+数据盘总容量）副本数k/单盘容量z/磁盘容量利用率q]

举例：

假定现有虚拟机VM数量为100个，每个操作系统占用30GB空间，每个虚拟机数据盘空间需求为50GB。预计购买的超融合服务器每台的磁盘标称容量z=1200GB，磁盘空间利用率q=0.95，副本数k=3.

系统盘总容量=30GB100=30000GB

数据盘总容量=50GB100=50000GB

按容量计算，硬盘数量为：

总的硬盘数量=roundup[(30TB+50TB）3/1.2TB/0.95]

= roundup[80tb*3/1.2TB/0.95]

= roundup[210.53]

总的硬盘数量为211块硬盘，每块盘容量至少为1200GB。

如果要加入SSD固态硬盘做热点迁移和自动分层，需要按照超融合系统要求的比例，购买SSD固态硬盘。

5.4 网络资源规划

5.4.1 组网策略

在超融合的架构中，多台虚拟机之间是共享网络的，为了方便管理，一般采用虚拟交换机来配置和管理网络，虚拟交换机可在数据中心级别提供集中和聚合的虚拟网络，从而简化并增强虚拟机网络。在虚拟交换机的网络划分上，仍然可以采用VLAN的方式划分不同的子网，实现不同子网段的安全和隔离。

除了虚拟交换机，还可以通过Overlay的方式来构建大二层和实现业务系统之间的租户隔离，通过NFV实现网络中的所需各类网络功能资源（包括基础的路由交换、安全以及应用交付等）按需分配和灵活调度，从而实现超融合架构中的网络虚拟化。这类功能同时需要客户的物理交换机支持SDN的管理方式，如果是一些老旧设备，可能无法实现，需要购置新的交换机设置。

5.4.2 网络拓扑

在每个单节点的物理机上，需要提供以下网络端口：

万兆光口：至少1个

千兆电口：至少2个

下图为推荐的网络拓扑图：

图：超融合架构网络拓扑

在每个超融合物理节点上有多种网络需求，包括生产网络、数据交换网络、管理网络、生产网络等，因此每个物理节点建议配置多块网卡，并保证每个节点通过两条万兆或千兆链路分别连接两台交换机，保证网络设备和链路的冗余度。

网络设计建议如下：

1、生产网络（原有生产网络，同时也是客户机和虚拟化服务器之间的网络通讯）

可采用双链路千兆以太网络，如果原有双链路万兆网络，那么可以继续延用。当用户的客户机访问虚拟服务器时，通过生产网络可分流后端存储流量并且进行隔离。

2、数据交换网（X86物理服务器之间的内部通讯网络）

至少采用双链路万兆光纤网络，由于分布式存储数据交换和虚拟机之间的通讯都需要占用大量的网络带宽，当发生密集的写IO时，万兆网络能保证提供足够带宽满足节点之间的IO同步流量。建议单独配置1块万兆网卡。

3、管理网络（管理X86物理服务器节点）

可采用双链路千兆以太网络，主要用于节点管理。建议单独配置1块千兆网卡，实现管理网络与业务网络、存储网络分离。可以最大限度保证管理的灵活性和安全性。

5.5 安全和备份规划

超融合系统的设计还需要考虑安全设计。

首先，在物理安全上，建议将超融合节点分别部署到3个不同的机柜中，每个机柜部署1个节点，最大化做到故障域的隔离。每个机柜双路供电，实现真正的供电冗余。

其次，要考虑满足国家等保的要求还有医疗客户自身的安全需求。在安全产品的部署上，可以延用原有的安全设备，也可以选择支持安全虚拟化的超融合产品。例如深信服超融合产品，可以集成集成分布式防火墙、4-7层虚拟防火墙、虚拟数据库审计等虚拟安全组件，并结合深信服安全产品，帮助客户构建从边界安全、平台安全、数据安全到应用安全的全方位安全防护体系，并利用安全可视化，对安全事件全过程进行安全保障：事前漏洞评估，事中全方位防护，事后持续威胁检测。

超融合架构可以提供跨数据中心的容灾及应用级高可用解决方案。超融合架构具备面向数据的备份及恢复机制，以更经济的方式实现数据的安全存储和管理，并结合负载均衡、虚拟化软件层高可用机制，提供了应用层面的跨数据中心业务连续性访问能力。

大部分超融合系统都可以提供基于虚拟机快照的方式将更新数据异步复制到远端的超融合系统集群中。如果有容灾建设的需求，需要提前规划好容灾复制模式，选择合适的双向复制、一对多复制或者多对一的数据复制模式。

传统的备份方式通过网络传输备份数据，需要特定的备份窗口以免影响业务正常运行。超融合产品备份可以与传统的备份策略互补，既能保证对于重要的虚拟机进行高频次备份又不会占用额外的网络带宽。

例如：对于普通虚拟机可以使用传统的备份方式每周进行全备，将备份数据备份到外部存储中，同时使用超融合自带的备份管理系统进行每天甚至每12小时的备份，数据直接保留在存储上以便快速恢复。对于比较重要的虚拟机可以使用传统备份每周全备、每天增量的方式，将备份数据备份到外部存储中，同时使用超融合自带的备份管理系统进行每2小时甚至每小时的备份，数据直接保留在存储上以便快速恢复。

6 云管理平台设计

基于超融合架构的云计算并不简单等同于传统架构的虚拟化，而是综合运用虚拟化、标准化和自动化等一系列技术对医院的信息化进行全面优化。因此搭建面统一的云管理平台还是非常有必要的。

在一些最佳实践中，医院信息中心已经从一个成本中心变成一个可以交付有形价值和差异化能力的核心部门。在这场IT价值的变革中，云计算的作用至关重要，可以让医院降低对IT的一次性投入的同时，还可以根据业务变化动态调整资源，以快速响应业务需求。

如果已经有了云管理平台，那么需要考入如何将超融合系统整合到云平台中，可以利用超融合厂商的工具与现有云管进行集成或者邀请原有云管厂商进行二次开发集成。这些是需要在选择超融合架构之前必须要考虑的一个问题，否则后期管理起来非常困难，还会增加很多的管理成本。

6.1 主要功能

云管理平台是面向云计算领域的通用云管理环境，在动态数据中心构建及运维过程中提供全方位、多层次的管理及监控能力，基于云环境实现应用的快速部署及资源的弹性供应，通过简化管理极大地降低成本、提高效益。通过集中式的资源管理模式整合虚拟化数据中心的计算、存储和网络资源，并通过自助式门户以随需即取的方式提供用户申请、配置和使用。

云计算管理平台可以根据超融合系统资源构建统一的资源池，并能实现对资源池的创建、修改、删除等管理功能。

云管理平台要求能够屏蔽虚拟化平台异构性。因为原有数据中心的虚拟化系统很有可能是异构的，或者新采购的超融合系统虚拟化也有可能与原有虚拟化系统不同，所以要求云管理平台能够支持主流的虚拟化平台包括VMware、Xen、KVM、XenServer、RHEV，PowerVM等，简化管控复杂度，提供集中式监管多虚拟化平台资源，对资源进行精细化管理、自动化运维，提供集中、统一监控运维管理平台，降低数据中心运维成本。

云计算管理平台主要功能如下：

门户管理、资源管理、资源申请审批管理、资源调度和分配管理、运维与监控管理、故障告警管理、权限管理、用户管理、计费管理、安全管理、能耗管理、接口管理、统计报表和系统管理。

图 云计算管理平台功能架构图

6.2 资源使用与管理

超融合系统在建设完成后，其资源主要由云管理平台进行统一管理。

建议采用以下两种模式，进行资源的使用与管理。

模式一：部门具备一定的信息化能力（如：医院信息中心及分院信息管理部门等）。一次性申请批量资源，由云管理平台管理部门经过审批分析后，批准并分配资源，之后，使用者在部门内部进行个人资源申请、审批，具备了“自治管理”能力；而通过流程控制和资源监控，达到“集中管控”的效果。

模式二：部门不具备信息化能力（如：医院骨科、眼科等业务科室），如果有资源需求，就会向云管理平台管理部门提交申请，经过审批分析后，批准或驳回申请，动态分配及收回资源。

7 超融合架构建设难点分析

7.1 信息孤岛治理

7.1.1 产生背景和原因

在医疗行业传统数据中心，每个业务系统建设都是一套硬件设备对应一套应用的建设模式，因此产生了越来越多的“信息孤岛”。随着系统逐步增加，这种烟囱式IT架构的问题逐渐暴露出来，如分散式管理复杂、机房设备多、利用率低等。

超融合平台项目建设的初衷是把这些系统的数据业务打通，在底层形成计算和存储的资源池，针对不同的业务动态提供按需划分的能力。但是，实际上的情况是，医疗用户在部署了超融合系统以后，会出现更多的“信息孤岛”。

在数据中心层面：所有的超融合方案都是分布式存储，也必须是分布式存储，不会支持数据中心中原有传统的集中式存储，而且大多数医疗用户也不可能在短期内更换原有的服务器和存储等设备，最终的结果就是，数据中心被分裂成两个彼此独立分散的“信息孤岛”。

在业务应用层面：目前超融合系统通常仅支持一种或多种虚拟化环境，例如VMware超融合架构仅支持VMware vSphere，不支持KVM。而华为和H3C等超融合方案基本都不支持Hyper-V虚拟化。每种虚拟化环境都有各自的优势，很多情况下用户可能要部署多套超融合环境。还有一点就是不同超融合平台之间无法整合和互操作，举个例子：如果一个医院买了DELLEMC的VxRail超融合平台，那么以后扩容不能再买其他超融合产品进行扩容，只能继续选择VxRail超融合产品，如果选择其他超融合产品进行扩容，结果就是又多了几个新的“信息孤岛”。

7.1.2 解决方案

在医疗行业客户考虑转向超融合架构之前，必须充分的认识到新架构的变化带来的诸多问题。由于超融合架构是一种全新的架构，短期内不可能完全替代传统的数据中心，所以信息孤岛问题是必然存在的，需要在管理上提升认识，充分考虑现有业务的需求，进行平衡考量，对现有数据中心的老旧设备和新的超融合设备进行统一管理，综合运维。在超融合产品的选择上，要结合现有的业务部署环境、虚拟化环境并结合数据中心的未来发展进行认真考量，不能有以往采购硬件设备时那种以价格优先的选择方法。必须充分对现有业务系统进行调研，需要哪种虚拟化平台，尽量选择支持异构虚拟化的超融合产品，而且超融合产品的选型决定了未来数据中心的发展方向，是走商业化产品路线还是开源产品路线，都需要考虑清楚。如果仅以价格便宜作为优先考虑方案，那么可能会导致适用性差，扩展受限等问题，而且日后可能还会产生更多的信息孤岛。

7.2 超融合系统性能优化和节点管理

7.2.1 产生背景和原因

超融合架构的优点是易于扩展和部署，按需扩容。通常采用X86硬件平台+软件定义技术实现计算、存储、网络等功能的统一。软件定义屏蔽了以往异构设备的复杂性，实现完全分布式，去中心化，系统不存在任意单点故障。超融合通常3节点起配，并且可以扩容到数十节点。超融合节点中的计算能力、存储性能和容量是同步扩容的，但是却无法满足现实中单项能力的扩展。

在计算性能方面，大部分超融合产品都是基于2U的X86服务器，CPU数量通常为1-2颗，单个虚拟机的性能最大只能达到单个节点的70%（超融合系统本身和分布式存储要占用30%的计算性能），而且不能像超算那样，利用所有节点进行统一计算。在这条件下，高性能应用可能不太适合部署，而且性能会受限于单台节点的性能。

在存储性能方面，在传统存储集中式系统中，由于其物理I/O路径较短，通常为机头控制器后端再挂载磁盘组。而且采用Raid等数据保护算法比基于分布式存储的副本数据保护模式，在计算开销上小很多。在分布式存储中，至少由3台服务器组成，通常使用3副本模式。一个I/O通过网络，需要在多个副本服务器上进行处理，而且每个副本都有数据一致性检查算法，这些操作都将增加I/O的时延。分布式存储系统的数据一致性会引发另外一个性能问题。数据一致性可以理解为应用程序运行的数据状态与最终写入到磁盘中的数据状态是否一致。在数据库等OLTP高并发业务场景下，数据一致性的保障可大大提高系统的可靠性和容错性，避免数据出错。传统存储是集中式缓存管理，集群中所有节点均不维护本地缓存，而是所有节点共享访问一个集中存放的缓存，数据在缓存中只有一份副本，不会出现多份副本，具有天然的缓存一致性。分布式存储因为每个节点都有自己独享的缓存，存在多个副本，需要一个特殊过程来维护缓存一致性。通常需要采用低时延的高速网络来实现缓存协议流量，最终实现任意关联分布式缓存一致性。带来的问题是副本之间的强一致特性导致只要有一个副本响应稍慢，整个I/O的时延将增加，导致性能下降。

为了提升超融合平台的性能，需要不断的增加节点数量。但是节点数量的增加又会导致管理上的问题。集群达到一定规模后，其复杂性就会非线性增加，在管理上变的更加困难，硬件故障率也会大幅度增加，所以并不是超融合系统的群集越大越好。如果为了性能而不断增加群集规模，还会产生均衡问题。因为超融合架构所有的计算和存储资源都是均衡分布的，在扩容或者是节点设备故障时，都会发生计算和存储资源的均衡迁移，虽然这个过程可以设定为非繁忙时段静默完成，但是如果变动很大，那么均衡的过程会非常漫长，在没有足够调整资源的情况下，会触发强制均衡，对正常的业务产生影响。

7.2.2 解决方案

在计算性能方面，在进行超融合产品部署前，需要根据医院自身业务的性能需求，选择合适的部署方案。例如：对于性能要求较高的大型OLTP数据库服务器，可以考虑单独部署在4路或8路的物理服务器上，不要部署在超融合系统中。超融合系统仅适合部署小型的或者对性能要求不高的数据库。

在存储性能方面，如果需要将传统的集中式存储数据迁移到超融合的分布式存储中，要考虑性能问题。提前做好I/O性能测试，避免性能不足。通常来讲，如果一台中高端存储设备，迁移到超融合系统中，要获取相同性能，至少要有10个以上的节点，而且要配置SSD闪存。在考虑数据迁移之前，传统存储的自动精简配置、快照、克隆、重复数据删除、数据加密和数据压缩等高级特性也需要考虑进去，这些通常是超融合架构的分布式存储所不具备的。

在管理方面，超融合虽然架构简化了IT架构，但是如果不考虑实际需求，盲目扩展，反而会增加数据中心的复杂性。从超融合产品的角度讲，其内部技术和链接配置更加复杂，为了性能不断的增加节点数量，如果出现故障，问题的跟踪调试和分析诊断也变得更加困难。建议在进行超融合架构规划时，不要只设定一个超融合群集，而是要根据业务类型或者性能分别创建不同的超融合群集，而且尽可能的控制单个群集的规模数量。

这就是针对医院完整的医疗行业超融合解决方案。