集团网络改造虚拟化数据中心系统项目建设方案模板.doc

集团网络改造虚拟化数据中心系统项目建设方案

信息化建设项目报告
——网络改造、 虚拟化数据中心系统

设计单位: 市立医疗集团信息中心
二〇一三年七月

目 录
第一章 项目概况 1
1.1 项目名称 1
1.2 项目单位 1
1.3 可行性研究报告编制单位 1
1.4 可行性研究报告编制依据 1
1.5 项目的建设内容、 目标和投资规模 1
1.5.1 建设内容 1
1.5.2 建设目标 2
1.5.3 建设规模 3
1.6 经济及社会效益 3
1.7 结论与建议 4
第二章 现状 5
2.1 项目单位概况 5
2.1.1 单位职责、 内设及下属机构、 人员编制和业务情况 5
2.1.2拟建项目与项目单位职责、 业务的关系 6
2.2信息化现状 6
2.2.1 本单位或本事域信息化建设的整体框架规划或设想 6
2.2.2现有应用系统的情况 6
2.2.3拟建项目与已有系统的关系 8
第三章 项目的需求分析 11
3.1 项目建议的背景 11
3.2 业务现状、 存在的具体问题和业务目标 11
3.3技术数据分析 13
3.3.1 传统方式与虚拟方式应用的差异性 13
3.3.2单台物理服务器配置多个虚拟服务器的性能依据 15
3.3.3存储虚拟化 19
3.3.4 双活数据中心 19
3.3.5连续数据保护 19
3.3.6 虚拟化安全防护 20
3.3.7 传统架构与虚拟化架构投入费用对比表 23
3.3.8 集团网络带宽需求测算 24
第四章 项目建设方案 31
4.1建设目标 31
4.2 建设方案 31
4.2.1网络改造方案 31
4.2.2 虚拟化双活数据中心总体架构设计 36
4.3 项目建设预期目标与现状对比 39
4.4 技术要求 41
第五章 项目实施进度和组织安排 51
5.1项目建设周期 51
5.2实施进度计划 51
5.3责任人和组织保障 51
第六章 项目风险及控制措施 53
6.1项目实施的外部风险及控制措施 53
6.2项目实施的内部风险及控制措施 53
6.3项目长期运行风险及控制措施 55
第七章 总体设备概算清单 56

第一章 项目概况
1.1 项目名称
市立医疗集团信息化建设项目
1.2 项目单位
马鞍山市市立医疗集团
1.3 可行性研究报告编制单位
马鞍山市市立医疗集团信息中心
1.4 可行性研究报告编制依据
Ø 卫生部印发的《医院信息平台技术解决方案( 试行) 》
Ø 卫生部印发的《卫生部电子病历基本架构与数据标准( 试行) 》
Ø 卫生部印发的《综合卫生管理信息平台建设指南( 试行) 》
Ø 卫生部印发的《电子病历系统功能应用水平分级评价方法及标准( 试行) 》
Ø 《马鞍山市市立医疗集团十二五信息规划报告》
1.5 项目的建设内容、 目标和投资规模
1.5.1 建设内容
1、 网络改造
2、 服务器、 存储虚拟化及虚拟化安全
1.5.2 建设目标
一、 网络改造
1) 整体内网架构建设实现星型网络三层架构, 核心层、 汇聚层、 接入层。内网实现万兆主干, 千兆到桌面, 部分影像楼宇实现万兆接入上行; 外网利旧内网设备实现千兆主干, 千/百兆到桌面。
2) 内网核心层、 汇聚层、 接入层设备均实现线路设备冗余, 主干设备实现冗余虚拟化技术。
3) 在集团数据中心实现全面的网络虚拟化, 做到计算、 存储、 网络的融合。
4) 各分支机构内部统一光纤规划建设: 实现集团各分支机构内部线路统一部署。
5) 各分支机构、 特殊部门( 医疗器械等) 网络实现VLAN划分: 根据医疗集团实际情况及信息化管理需求进行合理、 有效划分。

二、 虚拟化数据中心
1) 应用虚拟化技术进行现有服务器、 存储、 网络等设备的整合, 实现虚拟化数据中心智能集中式管理, 提高设备利用率, 降低设备购置和运维成本, 降低设备单点故障率; 实现业务系统动态冗余管理和应用负载均衡, 提高业务系统可用性;
2) 建立虚拟化数据中心资源池, 实现计算、 存储等资源动态分配, 建立双活数据中心, 实现同城范围的容灾, 消除计划内和计划外停机, 实现无停机机房迁移;
3) 实现持续数据保护, 提升逻辑数据的保护能力, 在一定时间范围内, 能做到恢复到任意时间点, 出现逻辑数据损坏时, 能够及时恢复, 并做到数据损失为0;
4) 经过虚拟化安全防护软件的防火墙、 病毒防护、 访问控制、 入侵检测/入侵防护、 虚拟补丁、 主机完整性监控、 日志审计等功能实现虚拟主机和虚拟系统的全面防护;
5) 使用第三方的Application HA 软件, 经过监视和控制虚拟环境中的应用程序, 实现关键业务应用程序的高可用性。
1.5.3 建设规模
项目涉及市立医疗集团下属人民医院( 三级甲等) 、 妇幼保健院( 二级甲等) 、 市中医院( 二级甲等) 、 传染病医院及集团南部诊疗园区五个医院和市立医疗集团托管的八个社区服务中心。
网络改造: 采购高性能数据中心核心交换机冗余系统、 高性能数据中心汇聚交换机冗余系统1套, 交要负责服务器及存储的万兆双活上连, 千兆/万兆接入; 根据实际需求增加汇聚及接入层交换机, 实现万兆主干, 千兆/万兆到楼层, 千兆到桌面, 双链路建设。
虚拟化数据中心: 经过采购24颗CPU或12台物理服务器授权的服务器虚拟化软件、 虚拟化安全防护软件, 20套Application HA 软件, 2台存储虚拟化设备, 1台连续数据保护设备并增购一台高性能存储设备, 综合运用虚拟化技术在信息中心主机房和南园灾备机房实现双活数据中心, 使用12台高性能物理服务器最多虚拟出90台逻辑服务器。
1.6 经济及社会效益
一、 经济效益
本项目的实施对于马鞍山市将直接和间接产生巨大的经济效益。
Ø 集中化的管控中心能够完成绝大部分的IT管理职能, 大大减少了琐碎的管理事务, 提高管理人员的生产效率;
Ø 降低总体拥有成本、 提高投资回报率;
Ø 提高服务器、 存储和网络等的资源利用率, 从而降低硬件成本, 降低运营和维护成本, 陈旧硬件和应用系统的投资保护, 提高了业务系统的可用性, 移动性和灵活性。
二、 社会效益
从绿色环保角度看, 本项目的建设能够做到 ”节能减排”, 提高运营效率, 增强系统安全性, 提升医院整体服务水平, 更好的为社会提供医疗服务。
1.7 结论与建议
本项目建设规划目标明确, 建设步骤方案合理实用, 前期准备工作考虑充分, 资金来源有保障, 各方面的建设条件都很成熟。本项目建成后不但社会效益明显( 主要体现在提高医院效率, 提升为民服务水平两个方面) , 还能够带来间接的经济效益。因此, 该项目建设不但必要, 而且可行, 应当尽快规划建设。
建议:
(1)本项目建设中应加强系统规划、 管理培训和技术维护人员的培训, 保证系统建成后的正常运营和维护。
(2)该项目建设应按照本市的有关规定, 严格进行工程项目的管理。
(3)该项目建设要加强成本控制, 有关项目建设的发包、 分包应经过公开招标、 择优选用。同时要积极运用技术经济的方法, 努力降低成本。

第二章 现状
2.1 项目单位概况
2.1.1 单位职责、 内设及下属机构、 人员编制和业务情况
马鞍山市市立医疗集团( 以下称市立医疗集团) 为市政府直属正处(县) 级事业单位, 为社会公益类事业法人单位, 承担市政府办医职能, 并由市政府授权, 负责市级公立医疗机构国有资产的投资、 管理、 运营。市立医疗集团设立管理机关, 根据职责和工作任务, 管理机关内设7个职能机构, 分别为办公室、 人力资源部、 财务部、 规划发展部、 质量与科技管理部、 党群工作部、 干部保健办公室。
市立医疗集团下辖市人民医院( 三级甲等) 、 市妇幼保健院( 二级甲等) 、 市中医院( 二级甲等) 、 开发区南部诊疗园区、 市传染病医院、 八个社区卫生服务站、 临床检验中心、 药品器械采购管理中心和信息中心等分支机构。现有职工总人数2100余人, 拥有开放病床总数1600余张。人民医院现有临床科室30个, 保健院现有临床科室8个, 中医院现有临床科室5个, 传染病医院现有临床科室3个, 开发区南部诊疗园区开设临床科室6个。组织结构图如图1所示:
总院长、 副总院长
市人民医院
市妇幼
保健院
市中医院
市传染病
医院
临床检验
中心
药品器械采
购管理中心
信息中心
财务部
人力资源部
办公室
质量与科
技管理部
办公室
党群
工作部
规划发展部
乡镇
卫生院
社区卫生
服务中心
总院长、 副总院长
市人民医院
市妇幼
保健院
市中医院
市传染病
医院
临床检验
中心
药品器械采
购管理中心
信息中心
财务部
人力资源部
办公室
质量与科
技管理部
总院长、 副总院长
市人民医院
市妇幼
保健院
市中医院
市传染病
医院
临床检验
中心
药品器械采
购管理中心
信息中心
财务部
人力资源部
办公室
质量与科
技管理部
办公室
党群
工作部
规划发展部
乡镇
卫生院
社区卫生
服务中心

图1 市立医疗集团组织架构
2.1.2拟建项目与项目单位职责、 业务的关系
马鞍山市市国家公立医院改革的试点城市之一, 既是机遇也是责任, 既肯定了既有的改革工作, 也对未来发展提出了更高的要求。为了保证已取得的改革成果持续有效并满足以信息化手段助力医改的要求, 市立医疗集团紧紧围绕”打造集团化数字医院平台”这一目标, 积极开展”以病人为中心”的各项信息化项目建设。为进一步贯彻国家”十二五”期间卫生信息化建设规划, 今年集团将继续推进信息化基础设施建设, 完善集团网络架构体系, 重点建设以云技术为基础架构的虚拟化数据中心, 进一步提升公立医院的竞争力和可持续发展能力, 为人民群众提供优质就医服务, 推动医疗卫生事业快速健康发展。
2.2信息化现状
2.2.1 本单位或本事域信息化建设的整体框架规划或设想
市立医疗集团卫生信息化建设工作总的指导思想是, 以服务和服从于”管办分开、 政事分开”及”区域医疗资源重组”为核心内容的”马鞍山模式”的医疗卫生体制改革与发展为宗旨, 以思路创新、 机制创新、 工作创新为动力, 以促进医疗卫生服务能力和管理水平的提高为目标, 以病人为中心, 以”服务患者、 服务临床”为宗旨, 以建立智能型数字化医院为方向, 整合信息资源, 综合运用现代信息技术, 稳步实效地推进集团信息化建设。充分利用信息技术提高集团现代化管理水平和竞争实力, 提升医疗服务质量, 为集团科学化、 规范化发展及各项工作的正常运转提供信息化方面的有力保障, 全面推进卫生信息化建设健康、 可持续发展。
2.2.2现有应用系统的情况
市立医疗集团现有信息系统30多个, 使用了40多台物理服务器, 6台性能各异的存储设备, 随着应用系统的不断增多和应用集成的要求, 还需要近20台的服务器, 具体情况见表1。

表1 市立医疗集团信息系统一览表
序号
项目名称
实施时间
服务器及容灾情况
1
集团HIS系统

现使用10台服务器实现双机热备、 双存储, 未实现异地备份, 如需实现异地备份机制还需2台服务器。
集团LIS系统

门诊电子病历系统
.09
门诊排队叫号系统
.12
集团”一站式服务”平台
.11
集团”一卡通”系统
.12
集团临床路径管理系统
.6
2
病案管理系统
.08
使用1台服务器, 2台低端存储。
历史病案翻拍查阅系统
.10
3
集团住院电子病历( EMR)
.09
使用了3台服务器, 实现双机热备, 共享一台vnx5100存储。
电子病历质控服务器
.9
4
集团数据集成平台( SOA)
.3
使用了6台服务器, 实现了双机热备, 共享一台vnx5100存储。
集团运营管理系统( HRP)
.3
集团药品配送管理系统
.9
财务管理软件
.3
5
集团影像存档与传输系统( PACS)
.10
使用了8台服务器, 实现了双机热备, 共享一台vnx5100存储。
6
集团合理用药管理系统
.9
1台单独服务器
7
健康体检管理系统
.05
2台服务器, 1台独立低端存储。
8
门诊移动输液管理系统
.11
1台单独服务器
9
集团住院医师规范化培训管理系统
.05
1台单独服务器
10
干部保健管理系统
.03
1台单独服务器
11
百信源内网管理软件
.6
1台单独服务器
12
网络版杀毒软件
.11
1台单独服务器
内网及时通讯软件
.1
13
手术麻醉与ＩＣＵ系统
在建项目
需服务器６台, 无存储空间。
14
机房及网络IT运维系统
.11
1台单独服务器
15
各业务系统所需应用服务器

预计需5台, 当前均与其它业务系统共用。
16
HQMS医疗数据上报系统
筹建项目
需1台单独服务器
17
医疗信息发布平台
.3
1台单独服务器
18
医学数字图书馆
.11
1台单独服务器, 内置大容量硬盘
19
办公OA系统
.12
1台单独服务器
20
集团网站
.8
1台单独服务器
21
社区综合信息管理系统
筹建项目
预计需要3台服务器
22
测试服务器

急需3台以上服务器。
2.2.3拟建项目与已有系统的关系
当前集团在用的业务系统有三十多个, 只有少数几个核心系统实现了双机热备, 数据异地容灾还没有有效的建立起来, 许多重要的业务系统还是单机运行模式, 有着很大的安全隐患; 业务系统的管理也面临着很大的压力, 由于部分服务器使用已达5年, 服务器硬件的稳定性越来越差, 故障恢复时间也比较长。
当前使用的服务器数量40多台, 存储6台, 没有形成有效的集中管理机制, 造成大量的服务器作为备机闲置, 同时少数核心服务器负载过重, 存储空间整体上不够用而局部存储空间大量闲置的问题等, 按照原有的方式还需要20台以上服务器才能基本满足业务发展需求。根据集团实际情况和业务发展的需要, 拟建立虚拟化数据中心, 构建基于云技术的虚拟化平台, 经过简化业务基础架构创立更动态、 更灵活的虚拟化双活数据中心, 提高业务敏捷性, 消除计划内和计划外停机; 应用虚拟化技术进行服务器、 存储、 网络的整合从而实现业务系统灾备、 高效的管理和成本的节约。
2.2.4现有网络、 设备以及其它信息资源情况

一、 网络
从上面整理的网络拓扑图中能够看出, 当前医疗集团网络分为四个层次: 边界接入层, 核心层, 汇聚层, 接入层。主干均采用光纤线路, 实现千兆主干, 百兆到桌面。集团内各分支机构经过光纤专线连接, 实现了互联互通、 独立的物理内、 外网络。
边界接入层: 边界接入层主要功能为对外提供安全的数据访问, 如与农合、 医保、 银行、 医药公司等的数据交换;
核心层: 核心交换机采用一台模块化交换机, 经过千兆光纤连接到汇聚交换机;
汇聚层: 汇聚层设备采用的是千兆系列交换机;
接入层: 接入层设备采用的是百兆端口接入交换机。

二、 远程连接
在内部网上, 暂时未提供任何外部远程连接, 因此院内业务均需在院内完成; 在集团层面, 能够直接访问外部网;

三、 服务器、 存储及网络设备
集团的服务器主要以PC服务器为主, 主要作用是作为各应用系统的中央数据服务器, 集团内的很多小型信息系统采用普通PC机作为服务器;
Ø 核心交换机: 1台
Ø 汇聚交换机: 12
Ø 接入交换机: 100
Ø 服务器: 40台
Ø 存储6台: EMC-5100 1台、 EMC -240 2台、 EMC-120 1台、 HP低端存储2台

四、 操作系统
集团内使用的电脑主要使用Windows操作系统。在内网, 主要使用北信源内网管理软件来对所有的内网机器进行管理, 同时使用金山毒霸杀毒软件来完成内网系统的杀毒。

五、 数据库
使用了DB2、 Oracle、 MS SQL Server、 MySQL数据库管理系统。
六、 桌面系统
集团内主要采用Windows系统作为桌面操作系统。

七、 信息安全
完整的信息安全机制应该从技术手段和行政手段两个角度入手: 在技术手段上, 集团采用内外网物理隔离的方法来保证内部诊疗信息的安全, 同时在内网使用了网络管理软件, 以防止不合法的访问。

八、 容灾备份系统
HIS、 LIS 实现了完整的双机热备机制, EMR、 PACS、 SOA、 HRP实现了双机热备, 可是数据都运行在一台EMC5100存储上, 没有实现数据备份机制。所有系统尚未实现异地容灾。

第三章 项目的需求分析
3.1 项目建议的背景
卫生部等五部委颁布的《关于公立医院改革试点的指导意见》, 在全国范围内确定了17个试点城市, 马鞍山市位列其中。特别要指出的是, 此次《指导意见》明确提出了信息化建设对于医疗改革的重要性, 要求研究制订医疗机构内部信息管理的规定和标准, 充分利用现有资源逐步建立医疗机构之间的互联互通机制, 构建便捷、 高效的集团医院信息平台, 与区域卫生信息平台连接、 以电子病历和医院管理为重点的集团医院信息化网络, 支持马鞍山市推进公立医院改革工作, 促进公立医院改革目标的实现。
依据《中共中央国务院关于深化医药卫生体制改革的意见》和《基于健康档案的区域卫生信息平台建设指南》, 配合卫生部印发的《电子病历基本规范( 试行) 》和《医院信息平台技术解决方案( 试行) 》, 结合马鞍山市卫生事业发展实际情况, 构建”健康马鞍山”的发展需要, 在”十二五”期间, 利用五年时间, 以市民健康管理为核心, 加快建设市立医疗集团信息化建设, 经过网络改造、 虚拟化数据中心和移动医护应用临床信息系统等项目的上线, 实现各医疗机构临床工作效率的提升, 医政管理能力的提升, 实现集团内医疗卫生行政部门、 医疗卫生服务机构的互联互通、 资源共享; 促进集团内卫生资源在信息化条件下的优化组合, 实现各类医疗数据更好的对接, 做到共享卫生和信息资源, 增强防疫监控、 慢病管理、 应急处理和救治能力。
3.2 业务现状、 存在的具体问题和业务目标
3.2.1业务现状
市立医疗集团使用电信运营商的裸光纤将几家医院的网络连接在一起, 在整个集团层面形成统一的内部网以及统一的外部网, 所有的医院信息化业务如HIS、 LIS等均在内部网使用, 同时为了保证内部网的数据安全, 内部网与外部网之间采用物理隔离; 中心机房内网一台千兆核心交换机, 接入层交换机为低端产品, 不支持三层交换, 单链路, 单点故障风险突出; 无网络分析软件; 内网在一个B类网段内, 没有进行VLAN划分。内外网数据交换主要经过移动硬盘、 U盘等移动存储设备进行, 效率和安全性较差, 无网闸设备; 医保、 农合、 银行等系统接入设置了硬件防火墙, 无防病毒网关, 外网WEB应用软件无WEB应用防护设备。
市立医疗集团数据中心当前以X86服务器为主, 运行着三十多个应用系统。当前x86服务器数量四十余台, 其中大部分服务器负载非常小, 没有达到充分利用的状态。不同服务器之间配置、 性能和负载差别较大, 还有些设备已十分陈旧, 可靠性低, 性能较差, 急需更新。存储系统, 包括1台EMC VNX5100存储、 2台EMC CX4-210用StorageFoundation做2+2集群; 1台EMC CX4-120存储部署在备份机房, 用BackupExec做远程备份。随着系统的不断增多, 信息系统的维护工作给信息中心带来了很大的压力; 随着应用的深入, 新系统不断地增多, 如果采用购买新机器的方式支撑应用系统发展, 必然造成极大的运算资源和资金的浪费; 原有的一些系统由于负载的增加和系统优化的需要, 必须进行负载均衡和容灾备份, 而采用购买新设备的方式, 显然有些耗费过大。基于上述情况, 决定采用以虚拟方式实现IT系统的简化。
3.2.2 存在的具体问题
集团各医院间的网络连接为单链路, 中心机房只有一台千兆核心交换机, 接入层交换机为低端产品, 不支持三层交换和客户端绑定, 单点故障风险十分突出; 缺少网络监控和分析软件, 排除网络故障困难; 内网在一个B类网段内, 没有进行VLAN划分, 网络风暴和管理难度大。
服务器性能低下, 部分服务器都是很久以前采购的服务器, 服务器已经过保, 且很多业务开始并未考虑双机热备, 服务器的性能和稳定性已经得不到保障。利用效率低下, 由于每种业务运行都有高峰和低谷的周期, 服务器不得不分别按照峰值配备, 大量时间运行空闲, 再加上可靠性考虑分别配置双机, 不得不牺牲更多的计算资源。运维成本居高不下, 由于服务器数量越来越多, 对数据中心的空间、 网络、 耗电、 制冷等消耗越来越大, 成本越来越高。由于多个系统用多台存储这种分散式结构要求在单个系统层次上频繁地进行性能调节和资源调节。在维护和支持上会造成额外的财务、 运营和业务费用。同时, 分散式结构也难以实现容灾和可用性。管理复杂, 响应速度滞后, 每个业务系统的服务器的安装、 升级、 维护, 以及高可用性和灾难备份没有统一的管理手段, 只能因系统而异, 管理难度大, 无法响应业务系统的要求。随着医院信息化的发展, HIS系统, LIS系统, PACS系统等重要系统对安全性, 可靠性的要求越来越高。硬件设备数量越来越多、 硬件设备利用率越来越低、 维护与运营成本越来越高、 设备占用空间越来越大。面对上述问题, 我们必须采取措施对现有IT系统进行全面改造。
3.2.3业务目标
基于上述情况, 必须采取措施对现有网络和信息系统进行全面改造, 采用虚拟化技术实现信息系统的简化, 以达到以下业务目标:
全面的网络虚拟化, 计算、 存储、 网络的融合, 实现万兆主干, 千兆到楼层, 百兆/千兆到桌面, 实现内网物理链路热备份, 节点交换机采用双链路; 现全路由组网模式, 内网所有交换机均支持三层交换, 在接入层实现VLAN划分, 三层交换、 端口控制和访问控制等放入接入层交换机上实现。
应用虚拟化技术进行现有服务器、 存储、 网络等设备的整合, 降低设备单点故障率, 提高设备利用率; 建立虚拟化数据中心资源池, 实现资源动态分配, 提高数据中心的可扩展性, 使用虚拟化技术对现有IT资源进行整合, 使用12台双路服务器虚拟出90台逻辑服务器, 确保今后一段时间内不需要购置新的服务器;结合第三方HA软件, 采用虚拟化架构实现业务系统的高可用性、 系统容错、 灾难恢复等; 实现业务系统动态冗余管理和应用负载均衡; 实现数据集中备份与还原, 提高数据安全水平; 应用虚拟化技术实现异地容灾, 消除计划内和计划外停机; 实现无停机机房迁移; 实现虚拟化数据中心智能集中式管理, 降低设备购置和运维成本。

3.3技术数据分析
3.3.1 传统方式与虚拟方式应用的差异性
序号
分项
传统架构
虚拟架构
1
管理节点
90台
12台
2
故障节点
90台
12台
3
承载应用
如果按照每台服务器承载一种应用, 则为90种, 考虑到一台服务器上适当部署多个应用, 能够到承载150种应用
按照每台服务器虚拟6~8台虚拟机的话, 能够实现90台以上的逻辑服务器, 能够轻松实现独立承载150种应用。
4
可扩展性
传统架构不具备可扩展性, 如果需要扩展, 必须对硬件设备进行升级。而根据ITC的统计报告,
具有较强扩展性, 能够根据系统检测的日志记录, 分析所有设备的负载状况, 并根据负载状况进行调整, 及时调整每台虚拟机( 对应于传统架构的每台服务器) 的资源配置( CPU、 内存、 磁盘容量等)
5
动态资源分配
不能进行动态的资源调配, 每台物理服务器实际配置如何, 则其资源就固定为多少, 不能及时的更改, 必须重新购买。
虚拟架构能够实现动态的资源分配, 实现用户按照应用来规划IT架构而不是按照硬件来规划IT
6
可用性
传统架构如果不单独购买第三方容灾软件, 是无法实现高可用的功能的, 而且容灾软件是按照容灾的节点来计算费用, 维护起来, 技术人员的培养成本较高
虚拟架构本身就具有高可用的功能, 不需要额外购买第三方的容灾软件, 能够直接上线服务器之间的集群, 任何一台服务器出现故障, 其上的应用均可被其它集群内里面的服务器接管
7
安全性
传统方式需要借助安全管理软件才能实现安全的防护
采用虚拟架构的部署, 在整个架构的部署上就具有安全性, 管理IP与应用IP分层, 同时虚拟架构本身带有内置防火墙, 用户的权限也具有分级控制的功能, 能够实现多个层面的安全控制, 也不需要增加额外的成本
8
可管理性
传统架构需要管理员到达机房进行单个节点的维护和管理, 如果要在控制台集中控制, 则必须购买KVM系统, 会产生额外的费用, 而且, 在进行人员权限控制时, 无法根据不同的人进行分级别管理
虚拟架构能够做到统一管理中心对所有的虚拟机管理, 用户架构好系统后永远不需要再进机房直接对硬件设备进行操作, 用户只需要在本机经过管理中心加密传输进行管理, 能够实现传统方式的所有操作
9
应用负载
传统方式实现应用负载是借助第三方的负载软件加上服务器来实现
虚拟架构同样能够实现传统方式的应用负载, 而且更加方便, 每一台虚拟机就对应原来的一台物理服务器, 在传统方式上可实现的应用负载架构同样能够在虚拟架构上部署, 同时虚拟架构还能够讲所有的虚拟机变成模板部署, 处于静态方式, 如果任何虚拟机出现问题, 能够及时用备用机器代替, 实现的时间也就是一份钟, 而传统的方式则需要重新调试机器上的有关设置, 至少需要半天的时间。
3.3.2单台物理服务器配置多个虚拟服务器的性能依据
根据统计, 对于传统的服务器应用方式, 一般服务器的平均利用率在5-15%之间, 而采用虚拟架构整合后, 服务器的平均利用率可达到60%-80%。我们以此统计数据为基础, 来估算一下一台高配置的服务器能够支持的虚拟机的数量。为了有一个可比较的参考性能值, 我们选定SPEC CPU 的CINT Rates值做为性能参考依据, SPEC CPU 的CINT Rates考察的是服务器多CPU情况下的整数运算能力。首先, 如果采用传统的单台物理服务器部署应用的方式, 假定全部使用一台双路双核Intel Xeon 3.16(X5460) GHz CPU的服务器, 从SPEC官方网站上, 可查得其CINT Rates的结果为12.5。按照一般服务器的利用率情况, 假定平均单台服务器利用率在10%左右, 则一个应用环境实际消耗掉12.5*10%=1.25个CINT Rates值。为了进行服务器虚拟化整合, 我们假设配置3台IBM 3650 M3服务器, 从SPEC官方网站上, 可查得其CINT Rates的结果为33。服务器采用虚拟化整合后, 利用率可达到60%-80%, 我们按照保守的60%来计算, 则整合后的服务器共消耗掉33*60%=19.8个CINT Rates值。于是, 我们能够计算出, 一台IBM的两路服务器, 能够配置出19.8/1.25=15个相当于双路双核的服务器效率能力的虚拟机, 而这已经是很保守的计算了。在实际应用中, 很多时候, 完全能够按照一个CPU能够配置6~8台相同CPU处理能力的虚拟机来计算。

经过上面的计算, 我们完全能够经过在12台两路服务器上创立多达90个的虚拟服务器的方式, 来完成传统方式需要90台双路双核服务器才能完成的工作, 用户在降低成本的方式, 还大大减少了环境的复杂性, 降低了对机房环境的需求, 同时具有更灵活稳定的管理特性。
采用虚拟架构相比于传统单台服务器部署单一应用方式的另外一个好处是, 能够充分满足不同应用对系统资源的不同要求, 如有的应用只需要一个3.0 GHz CPU, 512MB的内存就能够很好的运行, 而有的高访问率、 高吞吐量的应用则需要2个甚至是4个双核的CPU, 16GB的内存才能保证稳定的运行, 在传统方式下, 往往不可能针对每一种应用来采购服务器, 而是用一种或几种标准配置的服务器来统一采购, 这样, 势必会造成某些应用资源富裕, 而另一些应用面临资源紧张的情况, 且应用之间不能互相调配资源。采用虚拟架构后, 由于每个虚拟机所需使用的系统资源都是由虚拟架构软件统一调配, 这种调配能够在虚拟机运行过程中在线的发挥作用, 使得任何一个应用都能够有充分保证的资源来稳定运行, 同时, 该应用在此时用不到的资源又能够被其它更需要资源的应用临时借用过去, 最大限度的提高了整体系统的资源利用率。
3.3.3虚拟化HA集群功能存在的不足

如上图所示, 上图中左边是生产服务器, 右边是备用服务器。当左边生产服务器硬件故障后, 虚拟化HA集群功能能快速的将该主机上虚拟机迅速的切换到备用主机。分析虚拟化HA集群功能集群存在以下问题:
1、 所有虚拟化HA集群构架内的切换都不能防止虚拟机OS的不可还原故障。由于虚拟化HA集群功能有别于传统HA构架, 在传统HA构架内永远有多余1个OS实例运行, 而在虚拟化HA集群功能内永远只有1个OS实例。若虚拟机 OS发生不可还原的故障, 则在虚拟机 HA构架内, 无论如何切换皆无法启动此虚拟主机, 也就造成应用无限期中断。
2、 单纯的虚拟化 HA软件仅考虑ESX/ESXi物理机停机或者虚拟机停机, 并未考虑虚拟机内应用的故障或者构成虚拟机内应用的关键部件故障。同时, 虚拟化HA也未对于中大型虚拟环境系统的容灾切换。容灾切换一般牵涉到多个虚拟环境的切换关联。如下表
业务可持续需求
业务可持续需求发生频率
VMware 自有集群管理功能
应用程序故障切换
最高
不支持
同一系统内应用程序的有序启动
最高
不支持
管理人员误操作导致的故障
高
不支持
配置变更
高
不支持
系统当机
高
满足
网卡故障切换
高
不支持
存储故障切换
中
不支持
虚拟机故障切换
中
满足
物理主机故障切换
高
满足
数据中心灾难
低
部分满足
经过上面的表格, 我们能够看到虚拟化 HA主要是对ESX所在地物理主机故障进行监控, 而对每个虚拟机内部应用是无法监控的。在实际生产中数据中心管理人员也发现大量的应用故障虚拟化软件根本不去切换, 将小故障变成了长时间无法恢复业务的大故障。从上述的对比能够看出, 虚拟机 HA只能满足基本的系统当机切换要求, 虚拟化数据中心迫切需要一种针对”端到端”的高可用解决方案, 来弥补虚拟机 HA的不足。
3、 第三方的应用程序HA解决方案, 经过前文所述, 虚机 HA的缺陷就是无法监控虚拟机内部应用, 而应用故障是发生频率最高的故障, 经过与虚机 HA进行集成解决这一缺陷。 Application HA负责监控虚拟机内部应用然后与虚机HA进行联动。

3.3.3存储虚拟化
市立医疗集团数据增长速度非常之快, 而管理数据能力的提高速度总是远远落在后面。经过存储的虚拟化, 屏蔽硬件差异性, 实现后端存储可靠性和可用性, 实现跨异构阵列的数据迁移, 能够简化频繁迁移的难度、 复杂程度。支持跨站点数据迁移和定位, 能够实现站点阵列和虚拟数据的迁移, 提升双数据中心或多数据中心的可用性及灵活性。将存储资源虚拟成一个”存储池”, 把许多零散的存储资源整合起来, 从而提高整体利用率, 同时降低系统管理成本。能够对整合起来的存储池进行划分, 以最高的效率、 最低的成原来满足各类不同应用在性能和容量等方面的需求。
3.3.4 双活数据中心
结合虚拟服务器和虚拟存储技术, 实现双活数据中心。两个数据中心均运行日常应用, 一方面, 某一数据中心在出现灾难时, 不需要进行切换, 另一个数据中心自动接管应用, 不会造成停顿, 消除RTO, 免除切换的各项复杂操作, 不会因为切换而造成各种风险, 另一方面, 也完全消除了计划性停机。利用存储虚拟化技术实现分布式联合, 跨数据中心透明地移动和共享工作负载( 包括整个虚拟机) 、 整合数据中心, 以及优化资源利用率。把应用、 数据从物理资源中解放出来, 所有的资源变成按需分配可付资源, 应用加数据是按需求来挑选需要使用的资源并可实现跨地域的流转, 实现两个数据中心的数据整合。
3.3.5连续数据保护
传统的备份手段一般备份时间间隔长, 数据丢失量大, 恢复速度也很慢, 这些问题无法满足医院HIS、 LIS等在线系统的要求。而连续数据保护将注意力从备份转向了恢复。连续数据保护是数据保护领域的一项重大突破。在过去, 各种数据保护解决方案都将主要精力放在定期的数据备份上。可是, 在定期备份状态下却又会产生像备份时间窗口、 打开的文件及数据库的保护以及备份操作过程对业务系统的影响等问题。今天, CDP已经使数据保护全面改观, 而且将注意力的焦点从备份转向了恢复。CDP能够为重要数据中的变化提供连续的保护, IT管理员根本不需要考虑备份的问题。当灾难发生时, 基于CDP的解决方案能够迅速恢复到任何一个需要的还原点, 从而为用户提供更大的灵活性。
利用CDP技术在主机房及灾备机房之间建立镜像卷, 这样即使主机房出现灾难状况, 容灾机房依然能够保证数据的安全; CDP除镜像卷外, 还有日志卷, 这样, 如果出现诸如病毒、 误操作、 非法篡改等造成的逻辑数据, 利用CDP方式, 能够回滚到任意时间点( 在日志空间许可范围内) , 避免了传统的备份每天只能够备份一次, 数据损失量大的问题。这样就解决了本地的高可用, 又解决了逻辑数据保护问题。
3.3.6 虚拟化安全防护
虚拟服务器基础架构除了具有传统物理服务器的风险之外, 同时也会带来其虚拟系统自身的安全问题。新安全威胁的出现自然就需要新方法来处理。虚拟化环境内存在的几点安全隐患:
1、 虚拟机之间的互相攻击
由于当前使用传统的防护模式, 导致主要的防护边界还是位于物理主机的边缘, 从而忽视了同一物理主机上不同虚拟机之间的互相攻击和互相入侵的安全隐患。
2、 随时启动的防护间歇
由于将大量使用服务器虚拟化技术, 让IT服务具备更高的灵活性和负载均衡。但同时, 这些随时由于资源动态调整关闭或开启虚拟机会导致防护间歇问题。如, 某台一直处于关闭状态的虚拟机在业务需要时会自动启动, 成为后台服务器组的一部分, 但在这台虚拟机启动时, 其包括防病毒在内的所有安全状态都较其它一直在线运行的服务器处于滞后和脱节的地位。
3、 系统安全补丁安装
当前虚拟化环境内仍会定期采用传统方式对阶段性发布的系统补丁进行测试和手工安装。虽然虚拟化服务器本身有一定状态恢复的功能机制。但此种做法仍有一定安全风险。无法确保系统在测试后发生的变化是否会因为安装补丁导致异常。集中的安装系统补丁, 前中后期需要大量人力, 物力和技术支撑, 部署成本较大。
4、 防病毒