XXXX人民医院数据中心建设方案
XXXX人民医院数据中心建设方案
目录
一、需求分析 (4)
1.1目前数据中心现状 (4)
1.2需求汇总 (5)
二、数据中心建设规划技术方案 (6)
第一阶段数据中心建设基础架构规划 (7)
2.1、建设超融合架构数据中心 (8)
2.1.1现有业务系统分类 (9)
2.1.2中心机房超融合虚拟化平台建设 (9)
2.1.3超融合虚拟化平台实施规划 (12)
2.1.3.1机柜冗余设计 (12)
2.1.3.2NTP时间服务 (12)
2.1.3.3命名规则 (12)
2.1.3.4虚拟化主机配置表 (15)
2.1.3.5物理主机网络端口规划 (17)
2.1.3.6虚拟机创建规划 (17)
2.1.3.7模板配置 (17)
2.1.3.8数据副本数量选择 (18)
2.1.4超融合架构介绍 (18)
2.1.5虚拟化软件的选择 (24)
2.1.6虚拟化平台虚拟机安全 (24)
2.1.7 业务系统迁移方法 (28)
2.1.8 系统培训及知识转移 (30)
2.2、业务系统整合 (31)
2.2.1中心机房业务系统整合 (31)
2.2.2东区机房业务系统整合 (33)
2.2.3脑科机房HIS系统整合 (33)
2.2.4脑科机房其他系统整合 (33)
2.3、虚拟化平台灾备系统建设 (34)
2.3.1容灾系统基本概念和指标 (34)
2.3.2容灾建设的工作内容 (35)
2.3.3灾难备份/恢复方案应该具备的特点 (36)
2.3.4现有系统环境分析 (37)
2.3.5容灾系统设计 (37)
2.4、建设数据中心统一备份平台 (39)
2.4.1利用超融合平台的优势进行本地备份 (39)
2.4.2使用备份一体机进行统一冷备份 (40)
2.5、超融合系统的技术优势 (46)
2.5.1横向扩展优势 (48)
2.5.2性能优势 (49)
2.5.3可靠性 (50)
2.5.4易于部署 (50)
2.5.5集中管理 (51)
2.5.6自动故障恢复 (53)
2.6、建设数据中心统一云管理平台 (53)
2.8、项目预算清单 (56)
首先非常感谢XXX人民医院对的信任。也希望凭借自身多年在各个行业的云平台建设以及容灾项目实施中的项目管理、基础架构咨询、技术实现的经验，协助XXX人民医院建设高效可靠的IT基础架构系统，成功地完成新建数据中心的咨询和实施，降低XXX人民医院业务系统的运营风险。
一、需求分析
在“互联网+”时代，传统行业模式被极大颠覆，极致、高效的客户体验成为各行业关注的焦点；坚持以人为本，全面提升医疗信息化水平，增强医院综合就医能力，建立以患者为中心的医院诊疗服务系统和管理系统，成为开展智慧医疗和智慧医院建设的重大挑战！
随着XXX市人民医院业务的增长，对于IT信息系统的要求不仅仅是满足业务系统的正常要求。而且在数据的安全性，数据的分层管理、备份、远程灾备等方面也提出更高的要求。
1.1目前数据中心现状
XXX人民医院目前共有三个机房，分别是中心机房、东区机房和脑科机房。其中中心机房规模最大，共有45台服务器设备，东区机房共有7台设备，脑科机房共有11台设备。中心机房已经建立了比较完整的数据中心基础架构支撑平台，HIS核心数据库部署在中心机房，采用东软的解决方案，数据库运行环境是Oracle 10g，运行在安腾架构的Rx9800上，中心机房其他服务器设备以HP 388和580，以及Lenovo RD 630为主。PACS系统一套6节点的Isilon存储和3节点容灾存储，专门存放非结构化的影像数据。
东区机房是中心机房的灾备机房，包括2台HP 388G7、2台HP 580G7、1台HP rx2600和2台Lenovo RD 630，其中rx2600是核心HIS数据库的备机。脑科机房是较为独立的系统，拥有独立的HIS系统，采用东华的解决方案，以HP DL388G7
和DL580G7为主。三个机房中设备启用时间在2007-2013年左右，大部分已经不在质保期，并且除关键业务外，其余业务系统无本地高可用和容灾保护。同时各个业务系统相对独立，各自具备单独的服务器、存储、网络资源，部分服务器和存储系统已经不在保修范围或停产，原有平台竖井式架构搭建，随着时间的累计，架构越来越复杂，且存在资源浪费的现象，运维和管理的难度也逐渐增大。
1.2需求汇总
针对此次数据中心建设，我们仔细分析了医院三个机房现有业务系统的IT 架构，结合新建院区数据中心建设，概括汇总需求如下：
?大部分业务系统设备启用时间在2007-2013年左右，大部分已经不在质保
期，且很多设备已经快达到设备寿命，软件版本过低，存在版本更新的需求，系统运维依赖第三方厂商，系统运维存在隐患，因此存在系统更新换代的需求。
?数据中心各业务系统相互独立，当系统规模大时，一旦出现业务系统需要
更新的情况，每个业务系统均需要进行更新操作，中心机房现有40多个业务系统，将会产生大量的操作，给运维人员带来巨大的压力，增加系统风险，因此存在系统加快业务更新响应速度的需求。
?由于在系统层面现有数据采用竖井式架构，在存储层面，采用统一存储架
构，系统横向扩展性已经快接近瓶颈，随着新业务的上线，系统复杂度大幅增加。即使继续采用竖井式架构也将面临如何整合数据的难题，因此存在降低系统复杂度的需求。
?各业务系统独立的设计导致在设计容灾系统时需要对各业务系统分别考
虑，如果采用软件层的解决方案，会造成系统复杂度提升，如果采用存储层的解决方案，会大幅提升系统建设成本，因此存在全系统保护的需求。
?现有中心机房和脑科机房的HIS系统存在整合需求。
?医院新的数据中心将在一年后开始建设，存在统一规划分步分批建设的需
求。
?目前绝大部分系统都采用传统竖井式架构，亟需更加灵活、扩展能力强的
架构。
?能够满足核心业务系统数据本地高可用，无论发生计划内或计划外异常情
况，业务不中断，最大化确保业务持续运行，同时保证数据安全。
?本地分级存储：实现数据分级管理，使存储资源得到最有效的利用，不同
级别不同成本的资源为不同价值和要求的数据服务，提高资源的利用率。
构建统一、合理的、高可扩展的基础架构。
?目前核心HIS数据库尚无数据备份，因此系统存在本地数据备份需求。
?在本地高可用建设的基础上，建设跨机房的容灾系统，实现同城应用级别
灾备；能够实现“从无到有、从有到优、统筹规划、分步实施”，不仅仅考虑防止物理灾难风险，同时要能够防止逻辑灾难风险；
?灾备系统尽可能采取简单、成熟、高效的技术实现手段；
?最大化程度利旧原有数据中心服务器、存储等资产，保护已有投资。二、数据中心建设规划技术方案
综合以上现状分析，结合数据中心建设方法论及最佳实践，建议采用分步分批的建设方式，使用扩展能力强，功能丰富的超融合基础架构方案，来满足医院业务系统高可靠性、高可用性、业务连续性、数据安全、数据备份、数据及应用容灾需求。
建议XXX人民医院的数据中心建设采用三步走的设计建设思路，数据中心第一期建设超融合架构数据中心，进行业务系统的整合，并对核心业务的应用系统也进行整合，可选同时搭建灾备系统平台。第二期建设多种类型的虚拟化平台并通过统一的云管理平台进行管理，并建设多站点之间的灾备系统。第三期建设医院大数据平台，并在云平台上搭建SDN软件定义网络解决方案。
第一阶段数据中心建设基础架构规划
本次数据中心建设基础架构规划如下：
图1：基础架构规划拓扑
1）建设超融合基础架构平台，在中心机房建设一套超融合集群，并对现有系统进行评估，将除HIS、PACS等核心业务系统外的其他系统都迁移至超融合平台，打破原有竖井式架构的束缚，并将原来运行这些业务系统的设备进行淘汰，解决现有机房设备达到使用寿命而存在的潜在隐患，降低整体能耗成本。
2）进行业务系统集中整合，目前XXX人民医院核心HIS数据库仍然运行在安腾架构的rx9800小型机环境中，并使用Oracle 10g的RAC方案，由于Oracle 和Redhat早已停止了对安腾架构的支持，现有的核心HIS数据库面临极大的隐患，同时不同机房中的HIS系统采用不同的软件解决方案，因此建议新数据中心的建设规划中，将HIS系统进行整合迁移测试，此部分工作量比较大，可以分阶段实施。
3）搭建灾备系统，在脑科机房搭建超融合灾备平台，与中心机房超融合平台共同构建互备的虚拟化灾备系统，两个机房超融合平台上运行的系统数据以主备方式进行读写，当一个机房存储设备发生故障时，数据存储动态切换到灾备机房，确保核心数据安全性和业务连续性。
4）建设统一的数据备份平台，目前中心机房的核心HIS数据库尚没有数据备份，在进行HIS系统整合后，建立统一的核心业务系统数据备份平台，使核心业务系统不仅有本地高可用保护，还有数据备份保护能够在故障时实现快速的数据恢复。
以下分别阐述各部分的技术方案。
2.1、建设超融合架构数据中心
设计原则
在方案设计中我们将遵循以下总体原则：
以业务需求为导向
技术架构最终是为业务服务的，因此技术架构的设计一定要以业务的需求为导向，充分考虑非功能需求，例如系统的重要程度、安全要求、业务连续性等。
提高资源利用率
现已经部署了大量的服务器，资源使用率低是较突出的一个问题，因此在项目中，提高资源利用率成为一个重要的任务。
动态扩展性
在IT发展趋势中，动态基础架构已经成为IT基础架构的发展方向。使IT基础架构成为一个动态、灵活、具有弹性的IT基础架构，同时在IT实时地运营过程可进行灵活的资源动态调整。资源扩展要体现在计算资源和存储资源的同时扩展。
高可用性
应用系统的高可用性是保障服务等级的重要因素，在架构设计中应该以软件定义为主，借助软件的分布式架构满足高可用性要求，实现系统架构和平台架构的无单点故障、无单点瓶颈问题，保障新一代的业务系统健壮性。
安全性
在系统设计中，安全性是一个非常重要的问题。在架构中需要考虑到虚拟化架构内外部
的安全，包括数据安全等问题，以保证整个系统长期安全稳定的运行。
2.1.1现有业务系统分类
建议数据中心所有服务器分区分域部署，并在用户网络和数据中心网络中间实施合理的安全防护，例如部署硬件的防火墙并设置相应的安全策略。
针对现有医院系统进行梳理，可以将医院系统分为六大类，分别是核心业务系统应用、核心HIS数据库、医疗信息系统、行政后勤系统、安全运维系统和PACS系统，其中PACS系统由于新购Isilon，将保持原有架构以避免投资浪费。
除核心HIS数据库外，其他四大类系统都将迁移至超融合平台，以最大程度提高系统的使用率。目前中心机房现有系统共45个，除核心HIS数据库和PACS 外，其他业务系统共有37个左右，为提高系统可用性，设计4-5个业务系统运行在一台超融合节点上，因此如果所有非核心业务系统迁移，建议配置8个超融合节点满足需求。同时东区机房的业务系统也迁移至中心机房超融合平台上，由于东区机房系统体量较小，因此不需额外添加超融合节点。
从存储容量上看，除核心HIS数据库和PACS系统外，其余系统数据量约为14TB，因此可选择8个HX5510超融合节点，96TB裸容量，整个集群可用容量为48TB(RF2),每增加一个节点相应增加计算资源和存储资源，不同类型的节点可以并存在同一集群。系统迁移至超融合平台后的数据中心耗电量大幅下降，超融合集群每年的耗电量约为3万度，每年将节省20多万电费。
2.1.2中心机房超融合虚拟化平台建设
超融合架构在数据中心中承担着计算资源池和分布式存储资源池的作用，极大地简化了数据中心的基础架构，而且通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力；在虚拟化层可以自由选择Hypervisor的品牌，包括VMware vSphere、MicroSoft Hyper-v和KVM；而且通过简单、方便的管理界面，实现对数据中心基础架构层的计算、存储、虚拟化等资源进行统一的监控、管理和运维。超融合基础架构形成的计算资源池和存储资源池直接可以被云计算平台进行调配，服务于OpenStack、Cloud Foundry、Docker、Hadoop等IAAS、PAAS平台，对上层的业
务系统等进行支撑。同时，分布式存储架构简化容灾方式，实现同城数据双活和异地容灾。现有的超融合基础架构可以延伸到公有云，可以轻松将私有云业务迁到公有云服务。
新的中心机房拓扑图如下所示：
图3：超融合基础架构图
基于超融合技术搭建虚拟化集群，用于承载核心业务系统和支撑系统。
方案超融合节点配置如下：
Lenovo HX 5510超融合系统，软硬件一体出厂预装，三年原厂服务，每节点配置2颗 E5 2630 V4处理器，256 GB DDR4内存，可扩展到768GB，配置1块64GB SSD作为虚拟化层安装部署空间，2块480GB SSD硬盘作为读写缓存及热点数据存储空间，6块2TB热插拔硬盘，8个节点可用容量48TB（两份副本存储），12Gb SAS RAID卡，2块双端口万兆光口，冗余电源；
支持数据本地化、热点数据自动分层、在线重删、压缩、快照、克隆、支持多种虚拟化平台。通过软件方式自动将本计算存储一体化服务器及其它计算存储一体化服务器中的所有节点的本地磁盘空间整合成一个整体存储空间提供给虚拟化软件使用（实现传统架构中集中存储的功能），单节点故障时不会影响整个存储空间的使用且数据不会发生错误或丢失。软件自动将经常访问的数据放在
SSD磁盘上，而将不常用的数据放在SATA磁盘上，无需手工干预；节点优先使用本地SSD磁盘进行IO吞吐，多数据副本:可以实现数据保留2份甚至3份，充分保护数据，当发生硬件失效时不会影响数据正常访问；
不使用Raid技术：不使用传统的Raid技术保护数据，避免由于磁盘故障导致整个Raid组性能降级，从而影响业务正常运行。
提供内存、SSD、SATA不同性能层面的重复数据删除功能，并且使用几k到十几k的粒度保证重复数据删除的效率和效果。
具备跨地域的远程数据容灾能力。支持同步、异步等多种容灾方式，在线集群伸缩，一键升级。
超融合系统对网络设备的要求：每个节点提供2个或4个万兆以太网光纤接口，每节点同时标配4个千兆以太网接口，后端万兆和千兆网络冗余配置，建议千兆网络用于管理网络，网络采用两层架构，下图为推荐的网络拓扑图：
2.1.3超融合虚拟化平台实施规划
2.1.
3.1机柜冗余设计
推荐将8个超融合节点分别部署到4个机柜中，每个机柜部署两个节点，最大化做到故障域的隔离。每个机柜双路供电，实现真正的供电冗余。
2.1.
3.2NTP时间服务
对于虚拟化平台，时钟同步是容易被忽略的一个问题，严重的可能会影响业务系统操作系统及数据层面的一致性，因此建议在此次项目中配置时钟服务器，一般有两种做法，第一种是在超融合系统或集群之外部署一套基于Redhat linux 的NTP服务器，作为整个集群的时间源，第二种是部署单独的NTP网络服务器设备。
2.1.
3.3命名规则
创建数据中心，并在数据中心中创建文件夹，在文件夹中创建群集，将ESXi 主机加入到群集中，在群集中根据应用需求创建各种应用池，该应用的虚拟机运行在这个池中。
数据中心命名规划
vCenter中的数据中心架构的规划
数据中心架构以下可以划分多个文件夹，文件夹可以包括多个群集，每个群集可以包括多台虚拟化主机，根据应用的实际需求，来划分资源池，每个资源池可以包括多个虚拟机。
VMware vCenter 可以将所有 VMware ESX 主机及其虚拟机组织到群集和资源池中，从而大大简化了资源管理工作。群集是虚拟基础架构管理中的一个新概念，它不仅具有多个主机服务器的强大功能，还可以方便地管理单个实体。由多台独立主机聚合形成的群集将资源集中在一起，具有内在的高可用性，可显著降低管理工作的复杂性。现在，虚拟机部署可从单个 VMware ESX 主机扩大到群集范围，这样虚拟机便可使用群集中的所有资源。vCenter 可以为虚拟机选择最适合的主机，并可以在情况发生变化时在群集内部移动虚拟机。
根据VMware vSphere技术白皮书的建议，由于本虚拟化服务器平台vCenter Server监控的主机的个数是三台，所以配置vCenter Server的规格如下。
vCenter/SQL服务器规格
vCenter Server的安装部署，需要安装部署在windows Server 2008 R2的操作系统上，并且安装部署VMware vCenter Server5.1和SQL Server 2008 R2版本。
vCenter/SQL服务器安装
用户角色权限管理（可选）
通过对管理员的角色分类，让不同角色的管理员只赋予他们管理自己职责内环境的权限。建议将虚拟平台的管理员分为以下几个等级：
ESXi主机命名规范
esxi+“数字”.“域名”，如https://www.sodocs.net/doc/897300450.html,；
ESXi主机的本地数据存储命名规范：
esxi+“数字”+local，如esxi01local；
ESXi主机用户名口令：
每台虚拟主机，在安装vSphere的过程中都需要创建密码，用户名是root 初始口令为：P@ssword.
2.1.
3.4虚拟化主机配置表
以下是每台虚拟化主机的配置信息，包括主机的名称，根用户名为root，口令P@ssword，主机的服务编号，物理机所属的群集，本地磁盘的命名，物理服务器在机柜的位置；假设每台主机有4个千兆网口，4个万兆网口，八块网卡命名为vmnic0 vmnic1 vmnic2 vmnic3 vmnic4 vmnic5 vmnic6 vmnic7，并在这,八块网卡组成的标准虚拟交换机上创建PortGroup：Management Network、VMnetwork、VMotion。
2.1.
3.5物理主机网络端口规划
2.1.
3.6虚拟机创建规划
虚拟机创建根据业务需求，合理分配资源：
1.CPU数量满足需求的前提下越少越好
2.内存可以根据需求自动调整，建议设定预留值
3.磁盘选择Thin模式，集群可以挂载共享裸设备，但会影响快照功能
4.网络尽量选择万兆交换机接口
5.每台虚拟机都要安装VMware tools。
由于虚拟机数量多，为提供运维的效率，建议医院对所有虚拟机进行统一管理，包括虚拟机名称，CPU、内存资源，磁盘容量，网络标签等信息，建议如下：
业务名VM名称主机名称CPU 内存磁盘网络说明
XX业务Ip地址-系统
-业务名称
LCRM-HX-
01
2*2 4GB x GB
Vlan
x
2.1.
3.7模板配置
根据业务系统所使用的操作系统版本，在虚拟化平台中配置几个常规典型模板配
置，包括Windows、Linux等，实现虚拟机的快速部署。
模板编号模板名称操作系统密码应用程序
2.1.
3.8数据副本数量选择
根据预先定义好的业务系统的关键级别，可以基于超融合系统continer级别实现可选两副本或三副本的数据安全保护。
2.1.4超融合架构介绍
超融合基础架构（Hyper-Converged Infrastructure，或简称“HCI”）是指在同一套单元设备中不仅仅具备计算、网络、存储和服务器虚拟化等资源和技术，而且还包括备份软件、快照技术、重复数据删除、在线数据压缩等元素，而多套单元设备可以通过网络聚合起来，实现模块化的无缝横向扩展（scale-out），形成统一的资源池。HCI是实现“软件定义数据中心”的终极技术途径。HCI类似Google、Facebook等互联网数据中心的大规模基础架构模式，可以为数据中心带来最优的效率、灵活性、规模、成本和数据保护。使用计算存储超融合的一体化平台，替代了传统的服务器加集中存储的架构，使得整个架构更清晰简单。
图4：数据中心4.0
新一代数据中心建设包含众多信息化应用的实施，与此相对应，机房服务器和存储设备也必将大量使用，并且随着后期应用扩充和服务扩容，服务器和存储设备的投入必然越来越庞大。一方面，管理硬件基础设施的压力和成本会不断增大；另一方面，由于应用的多样性，服务器和存储难于有效整合，服务器的资源使用都远低于其实际的处理能力，计算能力和存储容量难以充分利用。
实施虚拟化/云计算数据中心，可以有效整合服务器及存储资源，形成计算资源池，根据新一代数据中心各项应用的实际需要动态分配计算资源，最大效率的利用现有服务器及存储设备，并对数据中心硬件设备进行有效管理和监控。
超融合架构在数据中心中承担着计算资源池和分布式存储资源池的作用，极大地简化了数据中心的基础架构，而且通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力；在虚拟化层可以自由选择Hypervisor的品牌，包括VMware vSphere、MicroSoft Hyper-v和KVM；而且通过简单、方便的管理界面，实现对数据中心基础架构层的计算、存储、虚拟化等资源进行统一的监控、管理和运维。超融合基础架构形成的计算资源池和存储资源池直接可以被云计算平台进行调配，服务于OpenStack、Cloud Foundry、Docker、Hadoop等IAAS、PAAS平台。同时，分布式存储架构简化容灾方式，实现同城数据双活和异地容灾。现有的超融合基础架
构可以延伸到公有云，可以轻松将私有云业务迁到公有云服务。
图5：超融合市场领导者
计算资源层面：
超融合系统的计算资源池是通过x86服务器虚拟化来实现的，可以支持VMware vSphere和Nutanix Acropolis平台提供的KVM等Hypervisor，如图6。在虚拟化Hypervisor层形成计算资源池，为业务系统的虚拟机提供不同的服务质量和能力，包括了高可用(High Availability)、容错(Fault Tolerant)、在线迁移(Live Migration/vMotion)、资源动态负载均衡(Distributed Resource Scheduler)等虚拟化的特性。同时可以支持业务虚拟机在不同的Hypervisor之前进行迁移，也就是V2V的能力，例如从vSphere迁移到KVM等。
图6：超融合架构计算资源池（x86服务器虚拟化）