设计单位：市立医疗集团信息中心
二〇一三年七月
目 录
第一章 项目概况
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 本单位或本领域信息化建设的整体框架规划或设想
市立医疗集团卫生信息化建设工作总的指导思想是，以服务和服从于“管办分开、政事分开”及“区域医疗资源重组”为核心内容的“马鞍山模式”的医疗
卫生体制改革与发展为宗旨，以思路创新、机制创新、工作创新为动力，以促进医疗卫生服务能力和管理水平的提高为目标，以病人为中心，以“服务患者、服务临床”为宗旨，以建立智能型数字化医院为方向，整合信息资源，综合运用现代信息技术，稳步实效地推进集团信息化建设。充分利用信息技术提高集团现代化管理水平和竞争实力，提升医疗服务质量，为集团科学化、规范化发展及各项工作的正常运转提供信息化方面的有力保障，全面推进卫生信息化建设健康、可持续发展。
市立医疗集团现有信息系统30多个，使用了40多台物理服务器，6台性能各异的存储设备，随着应用系统的不断增多和应用集成的要求，还需要近20台的服务器，具体情况见表1。
表1 市立医疗集团信息系统一览表
序号 项目名称 实施时间 服务器及容灾情况 1 2 3 4 集团HIS系统 集团LIS系统 门诊电子病历系统 门诊排队叫号系统 集团“一站式服务”平台 集团“一卡通”系统 集团临床路径管理系统 病案管理系统 历史病案翻拍查阅系统 集团住院电子病历（EMR） 电子病历质控服务器 集团数据集成平台（SOA） 集团运营管理系统（HRP） 集团药品配送管理系统 财务管理软件 集团影像存档与传输系统（PACS） 集团合理用药管理系2000年 2004年 2010.09 2010.12 2011.11 2010.12 2010.6 2001.08 2008.10 2011.09 2011.9 2011.3 2011.3 2011.9 2011.3 2011.10 2011.9 现使用10台服务器实现双机热备、双存储，未实现异地备份，如需实现异地备份机制还需2台服务器。 使用1台服务器，2台低端存储。 使用了3台服务器，实现双机热备，共享一台vnx5100存储。 使用了6台服务器，实现了双机热备，共享一台vnx5100存储。 5 6 使用了8台服务器，实现了双机热备，共享一台vnx5100存储。 1台单独服务器 统 7 8 9 10 11 12 13 14 15 16 17 健康体检管理系统 门诊移动输液管理系统 集团住院医师规范化培训管理系统 干部保健管理系统 百信源内网管理软件 网络版杀毒软件 内网及时通讯软件 手术麻醉与ＩＣＵ系统 机房及网络IT运维系统 各业务系统所需应用服务器 HQMS医疗数据上报系统 医疗信息发布平台 2009.05 2011.11 2012.05 2009.03 2009.6 2012.11 2013.1 在建项目 2012.11 筹建项目 2011.3 2009.11 2008.12 2008.8 筹建项目 2台服务器，1台独立低端存储。 1台单独服务器 1台单独服务器 1台单独服务器 1台单独服务器 1台单独服务器 需服务器６台，无存储空间。 1台单独服务器 预计需5台，目前均与其他业务系统共用。 需1台单独服务器 1台单独服务器 1台单独服务器，内置大容量硬盘 1台单独服务器 1台单独服务器 预计需要3台服务器 急需3台以上服务器。 18 医学数字图书馆 19 办公OA系统 20 集团网站 社区综合信息管理系21 统 22 测试服务器 目前集团在用的业务系统有三十多个，只有少数几个核心系统实现了双机热备，数据异地容灾还没有有效的建立起来，许多重要的业务系统还是单机运行模式，有着很大的安全隐患；业务系统的管理也面临着很大的压力，由于部分服务器使用已达5年，服务器硬件的稳定性越来越差，故障恢复时间也比较长。
目前使用的服务器数量40多台，存储6台，没有形成有效的集中管理机制，造成大量的服务器作为备机闲置，同时少数核心服务器负载过重，存储空间整体上不够用而局部存储空间大量闲置的问题等，按照原有的方式还需要20台以上服务器才能基本满足业务发展需求。根据集团实际情况和业务发展的需要，拟建立虚拟化数据中心，构建基于云技术的虚拟化平台，通过简化业务基础架构创建更动态、更灵活的虚拟化双活数据中心，提高业务敏捷性，消除计划内和计划外
停机；应用虚拟化技术进行服务器、存储、网络的整合从而实现业务系统灾备、高效的管理和成本的节约。
一、 网络
从上面整理的网络拓扑图中可以看出，目前医疗集团网络分为四个层次：边界接入层，核心层，汇聚层，接入层。主干均采用光纤线路，实现千兆主干，百兆到桌面。集团内各分支机构通过光纤专线连接，实现了互联互通、独立的物理内、外网络。
边界接入层：边界接入层主要功能为对外提供安全的数据访问，如与农合、医保、银行、医药公司等的数据交换；
核心层：核心交换机采用一台模块化交换机，通过千兆光纤连接到汇聚交换机；
汇聚层：汇聚层设备采用的是千兆系列交换机； 接入层：接入层设备采用的是百兆端口接入交换机。 二、 远程连接
在内部网上，暂时未提供任何外部远程连接，所以院内业务均需在院内完成；在集团层面，可以直接访问外部网；
三、 服务器、存储及网络设备
集团的服务器主要以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 业务现状、存在的具体问题和业务目标
市立医疗集团使用电信运营商的裸光纤将几家医院的网络连接在一起，在整个集团层面形成统一的内部网以及统一的外部网，所有的医院信息化业务如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 2 分项 管理节点 故障节点 传统架构 90台 90台 虚拟架构 12台 12台 如果按照每台服务器承载一种应用，则为903 承载应用 按照每台服务器虚拟6~8台虚拟机的话，可以实现90台以上的逻种，考虑到一台服务器辑服务器，可以轻松实现独立承载150种应用。 上适当部署多个应用，可以到承载150种应用 具有较强扩展性，可以根据系统检测的日志记录，分析所有设备传统架构不具备可扩展性，的负载状况，并根据负载状况进如果需要扩展，必须对硬件行调整，及时调整每台虚拟机（对设备进行升级。而根据ITC应于传统架构的每台服务器）的的统计报告， 资源配置（CPU、内存、磁盘容量等） 不能进行动态的资源调配，每台物理服务器实际配置虚拟架构可以实现动态的资源分如何，则其资源就固定为多配，实现用户按照应用来规划IT少，不能及时的更改，必须架构而不是按照硬件来规划IT 重新购买。 传统架构如果不单独购买虚拟架构本身就具有高可用的功第三方容灾软件，是无法实能，不需要额外购买第三方的容现高可用的功能的，而且容灾软件，可以直接上线服务器之灾软件是按照容灾的节点间的集群，任何一台服务器出现来计算费用，维护起来，技故障，其上的应用均可被其他集4 可扩展性 5 动态资源分配 6 可用性 术人员的培养成本较高 群内里面的服务器接管 7 安全性 传统方式需要借助安全管理软件才能实现安全的防护 采用虚拟架构的部署，在整个架构的部署上就具有安全性，管理IP与应用IP分层，同时虚拟架构本身带有内置防火墙，用户的权限也具有分级控制的功能，可以实现多个层面的安全控制，也不需要增加额外的成本 虚拟架构可以做到统一管理中心对所有的虚拟机管理，用户架构好系统后永远不需要再进机房直接对硬件设备进行操作，用户只需要在本机通过管理中心加密传输进行管理，可以实现传统方式的所有操作 虚拟架构同样可以实现传统方式的应用负载，而且更加方便，每一台虚拟机就对应原来的一台物理服务器，在传统方式上可实现的应用负载架构同样可以在虚拟架构上部署，同时虚拟架构还可以讲所有的虚拟机变成模板部署，处于静态方式，如果任何虚拟机出现问题，可以及时用备用机器代替，实现的时间也就是一份钟，而传统的方式则需要重新调试机器上的有关设置，至少需要半天的时间。 8 可管理性 传统架构需要管理员到达机房进行单个节点的维护和管理，如果要在控制台集中控制，则必须购买KVM系统，会产生额外的费用，而且，在进行人员权限控制时，无法根据不同的人进行分级别管理 9 应用负载 传统方式实现应用负载是借助第三方的负载软件加上服务器来实现 根据统计，对于传统的服务器应用方式，通常服务器的平均利用率在5-15%之间，而采用虚拟架构整合后，服务器的平均利用率可达到60%-80%。我们以此统计数据为基础，来估算一下一台高配置的服务器能够支持的虚拟机的数量。为了有一个可比较的参考性能值，我们选定SPEC CPU2006的CINT2006 Rates值做为性能参考依据，SPEC CPU2006的CINT2006 Rates考察的是服务器多CPU情况下的整数运算能力。首先，如果采用传统的单台物理服务器部署应用的方式，假定全部使用一台双路双核Intel Xeon 3.16(X5460) GHz CPU的服务器，从SPEC官方网站上，可查得其CINT2006 Rates的结果为12.5。按照一般服务器的利用率情况，假定平均单台服务器利用率在10%左右，则一个应用环境实际消耗掉
12.5*10%=1.25个CINT2006 Rates值。为了进行服务器虚拟化整合，我们假设配置3台IBM 3650 M3服务器，从SPEC官方网站上，可查得其CINT2006 Rates的结果为33。服务器采用虚拟化整合后，利用率可达到60%-80%，我们按照保守的60%来计算，则整合后的服务器共消耗掉33*60%=19.8个CINT2006Rates值。于是，我们可以计算出，一台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.4 双活数据中心
结合虚拟服务器和虚拟存储技术，实现双活数据中心。两个数据中心均运行日常应用，一方面，某一数据中心在出现灾难时，不需要进行切换，另一个数据中心自动接管应用，不会造成停顿，消除RTO，免除切换的各项复杂操作，不会因为切换而造成各种风险，另一方面，也完全消除了计划性停机。利用存储虚拟化技术实现分布式联合，跨数据中心透明地移动和共享工作负载（包括整个虚拟机）、整合数据中心，以及优化资源利用率。把应用、数据从物理资源中解放出来，所有的资源变成按需分配可付资源，应用加数据是按需求来挑选需要使用的资源并可实现跨地域的流转，实现两个数据中心的数据整合。
传统的备份手段通常备份时间间隔长，数据丢失量大，恢复速度也很慢，这些问题无法满足医院HIS、LIS等在线系统的要求。而连续数据保护将注意力从备份转向了恢复。连续数据保护是数据保护领域的一项重大突破。在过去，各种数据保护解决方案都将主要精力放在定期的数据备份上。但是，在定期备份状态
下却又会产生像备份时间窗口、打开的文件及数据库的保护以及备份操作过程对业务系统的影响等问题。今天，CDP已经使数据保护全面改观，并且将注意力的焦点从备份转向了恢复。CDP可以为重要数据中的变化提供连续的保护，IT管理员根本不需要考虑备份的问题。当灾难发生时，基于CDP的解决方案可以迅速恢复到任何一个需要的还原点，从而为用户提供更大的灵活性。
利用CDP技术在主机房及灾备机房之间建立镜像卷，这样即使主机房出现灾难状况，容灾机房依然能够保证数据的安全；CDP除镜像卷外，还有日志卷，这样，如果出现诸如病毒、误操作、非法篡改等造成的逻辑数据，利用CDP方式，可以回滚到任意时间点（在日志空间许可范围内），避免了传统的备份每天只能够备份一次，数据损失量大的问题。这样就解决了本地的高可用，又解决了逻辑数据保护问题。
3.3.6 虚拟化安全防护
虚拟服务器基础架构除了具有传统物理服务器的风险之外，同时也会带来其虚拟系统自身的安全问题。新安全威胁的出现自然就需要新方法来处理。虚拟化环境内存在的几点安全隐患：
1、虚拟机之间的互相攻击
由于目前使用传统的防护模式，导致主要的防护边界还是位于物理主机的边缘，从而忽视了同一物理主机上不同虚拟机之间的互相攻击和互相入侵的安全隐患。
2、随时启动的防护间歇
由于将大量使用服务器虚拟化技术，让IT服务具备更高的灵活性和负载均衡。但同时，这些随时由于资源动态调整关闭或开启虚拟机会导致防护间歇问题。如，某台一直处于关闭状态的虚拟机在业务需要时会自动启动，成为后台服务器组的一部分，但在这台虚拟机启动时，其包括防病毒在内的所有安全状态都较其他一直在线运行的服务器处于滞后和脱节的地位。
3、系统安全补丁安装
目前虚拟化环境内仍会定期采用传统方式对阶段性发布的系统补丁进行测试和手工安装。虽然虚拟化服务器本身有一定状态恢复的功能机制。但此种做法
仍有一定安全风险。无法确保系统在测试后发生的变化是否会因为安装补丁导致异常。集中的安装系统补丁，前中后期需要大量人力，物力和技术支撑，部署成本较大。
4、防病毒软件对资源的占用冲突导致AV（Anti-Virus）风暴
传统杀毒软件在防护效果上可以达到安全标准，但如从资源占用方面考虑存在一定安全风险。由于每个防病毒客户端都会在同一个物理主机上产生资源消耗，并且当发生客户端同时扫描和同时更新时，资源消耗的问题会愈发明显。严重时可能导致ESX服务器宕机。
通过以上的分析是我们了解到虽然传统安全设备可以物理网络层和操作系统提供安全防护，但是虚拟环境中新的安全威胁，例如：虚拟主机之间通讯的访问控制问题，病毒通过虚拟交换机传播问题等，传统的安全设备无法提供相关的防护，针对虚拟环境需要全新的信息安全防护方案，通过病毒防护、访问控制、入侵检测/入侵防护、虚拟补丁、主机完整性监控、日志审计等功能实现虚拟主机和虚拟系统的全面防护，并满足信息系统合规性审计要求,采用基于虚拟化的安全解决方案，构建虚拟化平台的基础架构多层次的综合防护。
5、病毒防护防护
传统的病毒针防护解决方案都是通过安装Agent代理程序到虚拟主机的操作系统中，在整合服务器虚拟化后，要实现针对病毒的实时防护，同样需要在虚拟主机的操作系统中安装防病毒Agent程序，但是服务器虚拟化的目的是整合资源，最大化的发挥服务器资源的利用率，而传统的防病毒技术需要在每个虚拟主机中安装程序，例如：一台服务器虚拟6台主机，传统方法将Agent需要安装6套，并且在制定扫描任务就需要消耗虚拟主机的计算资源，这种方式并没有达到节约计算资源的效果，反而增加了计算资源的消耗，并且在病毒库更新是带来更多的网络资源消耗。
针对虚拟化环境提供创新的方法解决防病毒程序带来的资源消耗问题，通过使用虚拟化层相关的API接口实现全面的病毒防护。具体如下： 6、针对虚拟系统，实现底层无代理病毒防护
针对虚拟系统中通过接口实现针对虚拟系统和虚拟主机之间的全面防护，无需在虚拟主机的操作系统中安装Agent程序，即虚拟主机系统无代理方式实现实
时的病毒防护，这样无需消耗分配给虚拟主机的计算资源和更多的网络资源消耗，最大化利用计算资源的同时提供全面病毒的实时防护。 7、访问控制
传统技术的防火墙技术常常以硬件形式存在，用于通过访问控制和安全区域间的划分，计算资源虚拟化后导致边界模糊，很多的信息交换在虚拟系统内部就实现了，而传统防火墙在物理网络层提供访问控制，如何在虚拟系统内部实现访问控制和病毒传播抑制是虚拟系统面临的最基本安全问题。基于虚拟技术的防火墙提供全面基于状态检测细粒度的访问控制功能，可以实现针对虚拟交换机基于网口的访问控制和虚拟系统之间的区域逻辑隔离，同时支持各种泛洪攻击的识别和拦截。
8、入侵检测/防护
同时在主机和网络层面进行入侵监测和预防，是当今信息安全基础设施建设的主要内容。然而，随着虚拟化技术的出现，传统的入侵监测工具可能没法融入或运行在虚拟化的网络或系统中，像它们在传统企业网络系统中所做的那样。
需要对虚拟交换机允许交换机或端口组运行在“混杂模式”，这时虚拟的IDS传感器能够感知在同一虚拟段上的网络流量。除了提供传统IDS/IPS系统功能外，还提供虚拟环境中基于政策的（policy-based）监控和分析工具，使流量监控、分析和访问控制更精确，还能分析网络行为，为虚拟网络提供更高的安全性。
9、虚拟补丁防护
随着新的漏洞不断出现，为系统打补丁上疲于应付，等待安装重要安全补丁的维护时段可能是一段艰难的时期。另外，操作系统及应用厂商针对一些版本不提供漏洞的补丁，或者发布补丁的时间严重滞后，还有最重要的是，如果IT人员的配备不足，时间又不充裕，那么系统在审查、测试和安装官方补丁更新期间很容易陷入风险。
通过虚拟补丁技术完全可以解决由于补丁导致的问题，通过在虚拟系统的接口对虚拟主机系统进行评估，并可以自动对每个虚拟主机提供全面的漏洞修补功能，在操作系统没有安装补丁程序之前，提供针对漏洞攻击的拦截。虚拟补丁功能既不需要停机安装，也不需要进行广泛的应用程序测试。虽然此集成包可以为IT人员节省大量时间。
10、完整性审计
针对系统支持依据基线的文件、目录、注册表等关键文件监控和审计功能，当这些关键位置为恶意篡改或感染病毒时，可以提供为管理员提供告警和记录功能，从而提供系统的安全性。
11、日志审计和报表功能
提供全面的系统日志和详尽的报告功能，除了记录自身的各功能日志外，还可以将虚拟主机操作系统日志结合自身日志进行统一的统计和分析，日志系统还可以生成符合国际相关安全规范的报表。通过对日志进行分析可以让管理员跟踪IT基础设施的活动，评估服务器数据泄密事件是否发生、如何发生、何时发生、在何处发生的有效方法。
3.3.7 传统架构与虚拟化架构投入费用对比表
传统架构与虚拟化架构投入成本对比表
首次购买硬件成本：按80台中档次双路服务器计算 传统方式 虚拟化方式 虚拟化方式节约资金 增加40台物3*40=120万 理服务器(按HP380计算) 现有12台高性90万 能服务器扩内存+虚拟化软件可实现90台逻辑服务器。 40台服务器25万 需要增配2现有设备可满足 0 25万 30万 个48口千兆电口交换机插板，增配4个24口san交换机以及光模块和光纤跳线等。 40台服务器20万 需要2台KVM 增加的用电40台1000瓦： 费用（按照140台*1.0千瓦年计算） *24小时*365天*1年*0.56元/度≈20万 空调费用（空20*40%=8万 调耗电费用为服务器耗电的40%） 合计： 193 90 103 0 8万 0 20万 无需KVM 0 20万 总结：虚拟化方式第一年比传统方式节约：100万元，以后每年电费及管理维护费用至少可以节约30万元以上。 3.3.8 集团网络带宽需求测算
1、人民医院PACS系统对带宽与设备的需求分析
1） 此部分主要分析人民医院中各影像设备同时向PACS服务器存储数据时对网络带宽的占用情况。需要接入PACS 网络的设备见下表：
人民医院各影像系统中不同设备次/人传输的数据量统计表
DICOM 接口标检查数日数据数据量（次/设备名称 型号 准(是否支持人次/量 量 人） worklist) 天 512Mbit Avanto DICOM3.0（支4-5GBy西门子 1 80 （按5G计1.5T 持） te 算） 64排LIGHT DICOM3.0（支GE 1 40 4GByte 819 Mbit VCT 持） HISPEED DICOM3.0（不双排CT 1 100 2GByte 164 Mbit NX/I 支持） 血管造影系DICOM3.0（支FD20 1 4 2GByte 4096 Mbit 统 持） 5591 Mbit 共计： 数据量(次/人)计算方法：数据量(次/人)＝日数据量×1024×8÷（检查人次/天）。若在影像中心部署万兆上行，千兆下行接入层交换机，网络延迟如下表所示：
千兆带宽到影像设备/万兆上行的网络延迟统计表
DICOM 接口标设备名称 型号 准(是否支持worklist) Avanto DICOM3.0（支西门子 1.5T 持） 64排LIGHT DICOM3.0（支GE VCT 持） HISPEED DICOM3.0（不双排CT NX/I 支持） 血管造影系DICOM3.0（支FD20 统 持） 万兆上行的传输的延迟： 检查数据量 工作站 数人次/（次/宽延迟量 天 人） (秒) 1 1 1 1 80 40 100 4 512Mbit 0.73 秒 819 Mbit 1.17 秒 164 Mbit 0.23 秒 4096 Mbit 5591 Mbit 5.85 秒 0.80 秒 延迟计算方法：工作站(到接入交换机数据传输的)延迟为：数据量（次/人）÷千兆带宽的实际传输能力；万兆上行数据传输延迟为：总数据量÷万兆带宽的
实际传输能力。分析如下：考虑在影像中心配置一台千兆下行，万兆上行的接入交换机，现有的H3C 1526百兆下行的交换机已不能满足数据转发的要求，H3C S1526在同时传输数据时，将达到近8秒的延迟，并会出现网络拥塞现象，网络会产生流量停滞、延迟、丢包，TCP全局同步等，将严重影响网络的正常业务开展。假设在未来的3－5年内数据量增加2倍，传输的数据达到11182Mbit，万兆上行的延迟达到1.6秒的情况下。建议现在至少部署两条万兆上行链路，这样即解决了网络中可能出现的延迟、拥塞现象，又考虑到链路的可靠性和可扩展性以及其它应用系统对带宽的使用。
人民医院住院病房调用PACS图像时的分析，此部分主要考虑住院楼工作站在调取影像时，PACS系统对带宽，网络延迟的影响。
西门子 Avanto 医院名称 住院层楼 1.5T 带宽 延迟 GE 双排CT 血管造影系统 FD20 带宽延(Mbit) 迟(秒) 64排LIGHT HISPEED VCT NX/I 带宽延迟带宽延(Mbi(秒) (Mbit) 迟(秒) 数 (Mbit) (秒t) ) 住院18人18432.63 29484 4.21 5904 0.147421.07 病房层 2 84 56 民 楼 医2号病4层 4096 0.59 5120 0.76552 0.94 1312 0.32764.68 5.8院 房楼 19 8 8190 1.17 1640 0.4096老干5部病层 房楼 共计 27648 平均带宽 平均延迟 3 23 0 5 3.95 44226.00 6.32 88561.221131.60 .00 27 84 75479 Mbit 10.79秒 带宽计算方法：各设备影像数据量×（楼层数×工作站数），各设备影像数据量:见表1中数据量（次/人）；楼层数：见表1.3中层数；工作站数：按2个计算；例：以住院病房楼采用西门子Avanto 1.5T为例，其数据量在调取时数据量大小是：512×18×2=18432Mbit。延迟计算方法：带宽÷实际传输带宽，实际传输带宽：万兆按7000Mbit计算。分析：带宽占用最大的是血管造影系统FD20，最小的是双排CT。到极端情况下，当各住院病房楼同时调用血管造影系统，将占用221.184Gbit带宽；各住院楼同时调用流量最小的双排CT，将占用近9G带宽。同时调用PACS系统时的平均带宽为75.479 Gbit。PACS各系统对带宽的占用超过万兆10G的2－22倍，在设计带宽时，如果带宽比传输的数据量小，将导致网络堵塞。考虑到实际情况下，同时调用数据的可能性非常小，因此建议在汇聚层到核心层链路部署4－8条万兆链路。
汇聚交换机到接入交换机采用万兆/千兆带宽网络延迟（秒）见下表：
西门子 Avanto 1.5T GE 双排CT 血管造影系统 FD20 64排LIGHT HISPEED NX/I VCT 数据量（次/人） 万兆 千兆 512 Mbit 0.59 秒 5.85秒 819 Mbit 0.93秒 9.33秒 168 Mbit 0.19秒 1.92秒 4096 Mbit 4.68秒 46.81秒 计算方法：（设备影像数据量×工作站数）÷实际传输带宽；各设备影像数据量：数据量（次/人）；工作站数：按8个计算（按每个交换机负责4个楼层计
算）；实际传输带宽：万兆按7000Mbit计算，千兆按700Mbit计算。
分析：汇聚交换机到接入交换机建议采用两条万兆，在保证带宽的同时，又保证链路的可靠性。接入交换机采用千兆到工作站，双万兆到汇聚交换机。
接入交换机采用千兆/百兆带宽网络延迟（秒）见下表：
西门子 Avanto 1.5T GE 双排CT 血管造影系统 FD20 64排LIGHT HISPEED NX/I VCT 数据量（次/人） 千兆带宽延迟 百兆带宽延迟 512 Mbit 816 Mbit 164 Mbit 4096 Mbit 0.73秒 1.17秒 0.24秒 5.85秒 7.31秒 11.66秒 2.40秒 58.51秒 计算方法：设备影像数据量÷实际传输带宽；各设备影像数据量:见表中数据量（次/人）；实际传输带宽：千兆按700Mbit计算，百兆按70Mbit计算。 2）人民医院网络设备选型：汇聚交换机的选型：应具备足够多的万兆接口，以满足汇聚交换机与接入交换机、核心交换机万兆连接，汇聚交换机可通过插卡方便扩展千兆、万兆、存储等业务接口。如考虑到网络设备的可靠性和带宽的利用率，建议配置两台汇聚交换机，通过虚拟化技术将两台汇聚交换机虚拟成一台交换机，并将多条物理链路通过链路捆绑技术虚拟成一条逻辑链路；接入交换机的选择：满足千兆到桌面，万兆上行，线速转发，支持安全认证功能，全SNMP功能等；
2、妇幼保健院PACS系统带宽与设备的需求分析
1）此部分主要分析妇幼保健院中各影像设备同时向PACS服务器存储数据时对网络带宽的占用情况。需要接入PACS 网络的设备见下表：
DICOM 接口数设备名称 型号 标准(是否支量 持worklist) 检查日数数据量（次人次据量 /天 /人） DICOM3.0; 富士 （放）CR CR-IR 356 支持1 worklist （放）乳腺Alpha RT 独立仪器设1 钼靶 备 立仪器设（放）床边 南京普朗 独1 备 （内）电子奥林巴斯 胃肠 V70 （黑白）西门子 G20 （彩）百胜 DU4 （彩）GE LG3 泰胜彩超、B 超 （彩）3000系列 （彩）飞利浦 HD7 （彩）飞利浦 HD9 （彩）飞利浦 IU22 共计： DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist DICOM3.0; 支持worklist 1 1 1 2 1 1 1 1 60 25 2 120MB/日 50MB/日 4MB/日 16Mbit 16Mbit 16Mbit 80Mbit 1.07 Mbit 1.33 Mbit 3.67 Mbit 3.33 Mbit 2次/周510MB/人/次 次 100 400MB/月 30 40 10 40 40 15 150MB/月 550MB/台/月 便携式不统计 500MB/月 1G/月 6.83 Mbit 1G/月 18.20 Mbit 162.43Mbit 计算方法：数据量(次/人)＝日数据量÷（检查人次/天）×8 或 数据量(次/人)＝月数据量÷30÷（检查人次/天）×8
分析：千兆上行链路，百兆下行已能满足目前业务要求。假设未来在妇幼保健院影像中心引入其它数据量较大影像设备，如血管造影系统等，将极大的增加数据量的传输，建议部署全千兆，可扩展万兆上行的交换机，并考虑接入交换机的认证、安全、管理等特性，以满足未来业务发展的需求。 2）妇幼保健院住院病房调用PACS图像时的分析
妇幼保健院住院楼房楼8层，儿童医学中心房楼3层，共计11层，按每层2个工作站同时调用PACS系统中数据量最大的（内）电子胃肠设备，共传输的数据量为80×11×2=1760Mbit。目前一条千兆链路无法满足PACS系统要求，至
少应部署两条链路实现负载均衡。若在未来数据量增加2倍或引入其它数据量较大影像设备，建议汇聚交换机到核心交换机采用一至两条万兆链路，汇聚交换机到接入交换机可部署千兆链路，以后可扩展为万兆链路。 妇幼保健院网络设备选型
汇聚交换机的选型：应具备足够多的万兆接口，以满足汇聚交换机与接入交换机、核心交换机万兆连接，汇聚交换机可通过插卡方便扩展千兆、万兆、存储等业务接口。如考虑到网络设备的可靠性和带宽的利用率，建议配置两台汇聚交换机，通过虚拟化技术将两台汇聚交换机虚拟成一台交换机，并将多条物理链路通过链路捆绑技术虚拟成一条逻辑链路；接入交换机的选择：满足千兆到桌面，万兆上行，线速转发，支持安全认证功能，全SNMP功能等； 3、中医院PACS系统带宽与设备的需求分析 1）中医院影像中心存储PACS图像时的分析
此部分主要分析中医院各影像设备同时向PACS服务器存储数据时对网络带宽的占用情况。需要接入PACS 网络的设备见下表： 设备名称 型号 CR 数量 检查人次/天 日数据量 20 2 9 0.2GB 0.1GB 0.2GB 数据量（次/人） 10.24 Mbit 51.20 Mbit 22.76 Mbit 84.20 Mbit AGFA5146/100 1 1 1 CT/e 数字胃肠 NAX500RF CT 共计： 计算方法：数据量(次/人)＝日数据量÷（检查人次÷天）×8，千兆上行链路，百兆下行已能满足目前业务要求。
分析：假设未来在中医院影像中心引入其它数据量较大影像设备，如血管造影系统等，将极大的增加数据量的传输，建议部署全千兆，可扩展万兆上行的交换机，并考虑接入交换机的认证、安全、管理等特性，以满足未来业务发展的需求。
2）中医院住院病房调用PACS图像时的分析
中医院住院楼房楼共计7层，按每层2个工作站同时调用PACS系统中数据量最大的数字胃肠 NAX500RF，共传输的数据量为51.20×7×2=716.8Mbit。目前一条千兆链路勉强满足PACS系统要求，建议至少应部署两条链路实现负载均衡。若在未来数据量增加2倍或引入其它数据量较大影像设备，建议汇聚交换机到核心交换机采用一至两条万兆链路，汇聚交换机到接入交换机可部署千兆链
路，以后可扩展为万兆链路。
4、南部园医院PACS系统带宽与设备的需求分析 1）南部园区医院影像中心存储PACS图像时的分析
设备情况：医院现有数字放射医学成像设备共4台，年检查量约1.8万人次。年数据生产量：医院年影像数据量约为0.5TB。放射科医师情况：现有医师人数共5人，共需放射科医生工作站约4台。根据设备情况，可计算出平均每台设备每天的传输数据量是(0.5×1024×1024÷4÷365) ×8=2873Mbit。放射科医生工作站通过千兆连接到接入交换机，传输2873Mbit需要延迟约4.2秒。假设接入交换机通过千兆连接到汇聚交换机，同时传输4份2873Mbit大小的数据量需要延迟16.8秒。假设接入交换机通过万兆连接到汇聚交换机，同样的数据需要1.68秒。因此建议开发区医院影像中心部署万兆上行，千兆下行接入交换机。
2）南部园区医院住院病房调用PACS图像时的分析
开发区康复中心房楼2层，住院房楼6层，共计8层，按每层2个工作站同时调用PACS系统中数据2873Mbit，共传输的数据量为2873×8×2=45968Mbit=45.968Gbit。考虑到实际同时调用图像的可能性非常小，建议部署2－4条万兆链路实现负载均衡。
5、传染病医院PACS系统带宽与设备的需求分析 1）传染病医院影像中心存储PACS图像时的分析
此部分主要分析中医院各影像设备同时向PACS服务器存储数据时对网络带宽的占用情况。需要接入PACS 网络的设备见下表： 设备名称 型号 CR DICOM 接口标数检查日数据数据量（次/准（是否支持人次/量 量 worklist） 天 人） 20 1 25 20 60M 1M 25M 60M 24 Mbit 24 Mbit 8 Mbit 8 Mbit FUJIFILM DRY PIX 支持DICOM接口 1 4000 脑血流图 Elica EMS-9 1 仪器：Philips 彩超、B HD11 支持DICOM接口 1 电脑：DELL 超 OPTIPLEX 210L 心电图：GE MAC 其他设备 5000 1 计算方法：数据量(次/人)＝日数据量÷（检查人次÷天）×8，千兆上行链路，百兆下行已能满足目前业务要求。
分析：假设未来在中医院影像中心引入其它数据量较大影像设备，如血管造影系统等，将极大的增加数据量的传输，建议部署全千兆，可扩展万兆上行的交换机，并考虑接入交换机的认证、安全、管理等特性，以满足未来业务发展的需求。
2）传染病住院病房调用PACS图像时的分析
中医院住院楼房楼共计5层，按每层2个工作站同时调用PACS系统中数据量最大的CR FUJIFILM DRY PIX 4000，共传输的数据量为24×5×2=240 Mbit。目前一条千兆链路即可满足PACS系统要求，建议至少应部署两条链路实现负载均衡。若在未来数据量增加2倍或引入其它数据量较大影像设备，建议汇聚交换机到核心交换机采用两条千兆链路，汇聚交换机到接入交换机可部署千兆链路，以后可扩展为万兆链路。
第四章 项目建设方案
4.1建设目标
通过本项目的实施，应用虚拟化技术对现有服务器、存储、网络等设备的整合，实现万兆主干，千兆到楼层，百兆/千兆到桌面；通过内网核心设备、汇聚设备；实现全集团内网所有物理链路热备份，节点交换机采用双链路。建立虚拟化双活数据中心，实现业务系统的高可用性和可扩展性，提高数据安全水平。实现数据中心智能集中式管理，进行资源按需分配，降低设备购置和运维成本。实现系统容错、灾难恢复等，消除计划内和计划外停机，实现无停机机房迁移等。满足集团下属五个医院和八个社区的业务需求的同时，屏蔽底层的复杂性，把更多精力投入到IT资源的优化应用上去。
4.2 建设方案
网络升级改造主要通过数据中心交换机实现全面的网络虚拟化，计算、存储、
网络的融合；实现万兆主干，千兆到楼层，百兆/千兆到桌面；实现全集团内网所有物理链路热备份，节点交换机采用双链路。要求内网核心设备、汇聚设备支持FC模块功能。实现一个网络平台融合以太网和存储两个网络。
整个网络采用模块化的架构设计方法，清晰定义和区分不同的功能区域，使网架构具有可扩展性、灵活性、高可用性和高安全性。
在整个架构设计中，采用核心边缘设计，以核心区为中心，其它作为边缘处理。在网络中设计一个核心交换区，这个区域作为其它区域的交换中心。为了保证更好的网络性能，核心交换区只提供实现高速转发功能，安全控制在各边缘区域中实现。这样的架构设计有很好的伸缩性（扩展性），例如，根据将来业务发展的需要，可以非常容易的增加新的区域或者新的交换机，而不需要对整个架构进行大的修改。具备更好的可管理性，因为每个区域的安全功能和详细的路由可以根据每个区域的功能进行定义，可以在不影响其他应用或者整个区域的情况下进行网络的增强或强化。模块化分区设计的另一个好处是将整个网络的失效域进行隔离，单个边缘区域失效，不影响其他区域，有利于故障的快速定位和排除。
在核心层部署支持DCB（数据中心以太网协议）国际标准的数据中心交换机，在不改变传统设计的网络物理拓扑、保证现有布线方式的前提下，以弹性化扩展的技术实现网络各层的横向整合，即将交换网络每一层的两台、多台物理设备使用虚拟化技术形成一个统一的交换架构，两台数据中心核心交换机可以使用虚拟交换机技术，节省汇聚交换机的数量，为数据中心设备的统一管理、稳定性、毫秒级切换、虚拟机迁移等提供保证。
另外为了便于数据中心虚拟机之间无缝迁移，需数据中心内部通过采用VPC（虚拟端口捆绑技术）技术构建大型的二层透明交换网络，具有网络结构简单、保持高性能与高可靠、避免环路的好处。在数据中心内部，构建端到端的二层透明网络，实现内部虚拟化计算的透明交互。让整个网络就像是一台交换机一样运行，形成一个交换矩阵。适应云计算和大规模数据中心流量猛增、虚拟机动态迁移不中断的业务需求。VPC协议互联，实现整网二层环境下的互联互通，同时适
应云计算跨地域的服务器大规模虚拟化。
针对核心和汇聚的数据中心特性，保证虚拟机易管理和易维护的特点，为了实现虚拟主机全网范围内自由迁移时对应安全控制策略的同步迁移，消除服务器虚拟化环境中网络安全漏洞，减少网络维护工作量，需要数据中心支持虚拟机感知及安全策略自动迁移，有效实现大规模服务器虚拟化应用环境中虚拟机流量的安全控制策略统一部署。同时支持IEEE802.1qbg或者IEEE802.1qbh标准定义的虚拟以太网端口聚合，能够将服务器虚拟机产生的数据流牵引到物理网络设备上进行“硬交换”，让虚拟机交换功能重新回归到网络设备，既解决了虚拟机流量无法监管、访问控制策略无法统一部署等问题，又消除传统“软交换”对服务器资源的占用，使下一代数据中心网络解决方案更好适应虚拟化计算环境。
同时为了消除二层网络架构中的环路，增加网络的稳定性，提升用户业务部署的灵活性，并且扩大虚拟机的迁移范围，且不堵塞任何端口将带宽利用率提升至100%，网络的核心和汇聚数据中心交换机必须配置TRILL功能。
1、内网改造规划设计 1）网络结构
采用三层分层分区设计，共分为核心层、汇聚层、接入层。 核心层、汇聚层、接入层，其骨干采用万兆（10/40GE）链路连接，千兆接入。核心交换机和汇聚交换机之间通过vPC（虚拟端口捆绑技术）技术实现跨交换机链路捆绑，而
无需采用STP，彻底解决了二层环路的困扰。在接入层，采用全千兆医院级交换机，万兆、千兆上行,并支持三层功能，如端口安全、防ARP功能、可网管、线速转发等。 在服务器区,配置2台数据级交换机，配置虚拟化技术做为服务器区接入交换机，2台服务器接入交换机和核心交换机采用2*10GE互联。
在汇聚层，考虑到今后会有服务器存储设备会接入到网络中，因此要求汇聚交换机能够配置足够带宽,可以和服务器存储设备直接互联互通。实现计算、网络、存储三种资源的融合。 2）IP地址、VLAN规划
目前网络采用的是B类IP地址，所有终端均在一个子网内。各院之间的PC同处于一个广播域内。广播域内所有的设备都必须监听所有的广播包，广播域太大了，用户的带宽就小了，并且需要处理更多的广播，网络响应时间将会变得非常慢。我们可通过合理的VLAN规划与IP地址规划解决广播域较大问题，同时在IP地址的可扩展性、管理性、VLAN安全性方面有所提高。根据市立医疗集团的网络特性，划分VLAN采用如下原则：
区域分开，把医疗集团所管辖的医院和机构按照物理区域划分，把市人民医院（三级甲等）、市妇幼保健院（二级甲等）、市中医院（二级甲等）、开发区南部诊疗园区、市传染病医院分别划分成一个区域。
在区域内部按照楼宇弱电间划分VLAN，VLAN可有效隔离广播域，提高网络的安全。目前常见的VLAN技术有基于端口的VLAN、基于协议的VLAN、基于MAC的VLAN、基于用户的VLAN。此次建议选择基于端口的VLAN和基于用户的VLAN相结合。如没有通过安全认证的用户划分到一个临时的VLAN。对于医疗设备IP地址，作为保留独立vlan，只对子网掩码作修改。具体如下：
市立医疗集团IP地址及VLAN划分表
序号 区域 地址段 划分方式 地址段 VLAN 服务器群1 1 …… 2 3 …… 21 2 3 …… …… 101 2 3 …… …… 51 2 3 …… …… 51 2 3 4 …… …… 51 2 3 服务器 服务器群2 …… 服务器群20 弱电间1 2 3 4 5 6 市人民医院 弱电间2 …… 弱电间100 市妇幼保健院弱电间1 弱电间2 …… 弱电间50 弱电间1 市中医院 弱电间2 …… 弱电间50 开发区南部诊疗园区功辉大厦弱电间1 弱电间2 弱电间3 …… 弱电间50 弱电间1 弱电间2 …… 弱电间20 弱电间1 7 扩展 弱电间2 …… 8 网络 设备 …… …… 21 2 3 …… …… 3）网络管理平台规划设计
网络管理平台采用统一管理模式，可灵活扩展各种组件，并实现各组件间的联动功能，如可以在拓扑图中查看哪些用户接入到网络中来，并且提示哪些用户是安全用户。
2、外网改造规划设计
1） 网络规划拓扑图 2）网络基础平台规划设计
网络结构上，采用星型网络三层架构设计，分为核心层、汇聚层、接入层；核心层、汇聚层、接入层，采用千兆链路、设备冗余，百兆到桌面；核心层、汇聚层、接入层，所有设备均首先考虑集团内网设备利旧。 3）IP地址、VLAN规划
和内网规划方案一致，根据楼层进行VLAN、IP地址的规划。 4）网络管理平台规划设计
和集团内网采用相同的配置方案，替换医疗集团现有不支持SNMP协议的交换机，新增交换支持SNMP协议、端口安全、防ARP功能、可网管、线速转发等特性。
4.2.2 虚拟化双活数据中心总体架构设计
如下图所示，生产机房位于市立医疗集团信息中心机房，灾备机房位于市
立医疗集团南部医疗园区，设计成两个独立的数据中心，在每一个独立的虚拟化数据中心里，先实现服务器、网络和存储资源的虚拟化，主机房及备机房相聚10公里，之间利用裸光纤链接；通过高速的以太网将两个数据中心连接在一起，形成了分布在不同地域的统一的数据中心资源池，在这个资源池上，利用虚拟化存储和服务器虚拟化技术，并结合核心交换机的网络虚拟化技术使两个数据中心都处于活动状态，彼此之间可以对工作负载进行均衡，同时通过镜像等技术保持两个数据中心的数据一致性，使应用系统具有永远在线和容灾的保障。 对于这两个位于不同地理位置的虚拟化数据中心，从存储虚拟化、网络虚拟化和主机虚拟化的三个层次进行连接。
虚拟化双活数据中心总体架构图
1、在网络层，通过光纤将IP网和SAN网络打通，实现虚机迁移，保持网络连续性。
2、在主机层，使用现有服务器中12台两路服务器搭建虚拟化平台，对现有的物理服务器增加内存（每台物理服务器配置64GB内存）。8台部署在信息中心机房，4台部署在南园机房。采购服务器虚拟化软件1套，共24颗CPU或12台物理服务器的虚拟机使用授权，虚拟出90台逻辑服务器。通过服务器虚拟化技术为运行的虚机系统搭建了一座业务连续性的桥梁，可以从容的在两个数据中心之间进行虚机的迁移，在信息中心机房有任何异常时，业务系统可以很快的切换到南园灾备机房。
3、在存储层，在两个机房的SAN网络与存储之间各增加1台存储虚拟化设备，对在信息中心机房新购的1台高性能光纤存储设备和在南园机房部署的原有1台EMC VNX5100进行统一管理，实现双活数据中心，通过存储虚拟化技术将分布式卷进行联合、镜像，实现跨数据中心的数据一致性。并把现有的2台EMC CX4-240、2台HP低端存储也纳入存储虚拟化里统一管理。
4、安全方面，增加数据连续保护设备实现2TB容量的关键数据持续数据保
护、本地连续数据保护及远程容灾、实现基于秒级或IO级的数据保护、实现应用级别的数据恢复功能、能够实现远程双向数据复制和恢复。持续数据保护利用旁路设备实现，主数据IO不需要经过持续数据保护管理节点，不造成性能影响；不需要在主机端安装任何代理，不出现兼容性问题。
由于PACS图像数据量巨大，同时PACS本地工作站会保留一段时间内的影像数据资料，所以本方案没有考虑PACS的图像部分的数据连续保护。使用Application HA 软件20套,实现核心业务系统的高可用。
5、虚机安全防护，服务器虚拟化安全防护软件1套，共24颗CPU或12台物理服务器的授权，含病毒防护、防火墙、入侵检测/入侵防护、虚拟补丁、各种审计功能等；通过底层的虚机防护，与虚拟环境无缝集成，实现无代理的虚拟环境安全防护模式。
通过虚拟化双活数据中心项目的实施，可以很轻松地实现跨数据中心的应用在线移动，实现无宕机的数据中心维护、数据中心自然灾害避免、迁移关键应用至另一数据中心、数据中心迁移或数据中心整合、数据中心扩张、多站点负载均衡等。
4.3 项目建设预期目标与现状对比 1、虚拟化核心设备和冗余主干线路
方案中核心和汇聚均采用支持高密度万兆技术的核心设备，采用交换机虚拟化技术，实现双核心和双链路冗余，从而确保骨干网的稳定可靠，任何一台核心设备、任何一条主干线路出现问题都不会影响到整个医院网络的稳定运行。
2、 实现高带宽、大容量，低延迟，不丢包的网络
方案中核心交换机和汇聚交换机采用支持DCB技术的网络设备，实现现高带宽、大容量、端口到端口的低延迟能力、无丢包的网络平台。通过支持一体化交换技术：实现了数据以太网、高性能计算网络、存储局域网（SAN）三网整合。从而便于实现跨平台的资源调度和虚拟化服务，提高投资的有效性，同时还降低了管理成本。
3、部署汇聚区域减轻核心设备压力
采用骨干、汇聚分离的设计思想，严格将汇聚与骨干之间区分开，骨干层只作高速数据交换，原则上不在核心上启用复杂功能、不部署复杂策略，不会影响核心性能。骨干层也没有暴露在直接用户面前，不会受到恶意攻击。单个汇聚节点故障不影响整个集团网的正常运行。
4、数据中心的安全防护
服务器区域接入专用的数据中心交换机，满足数据中心、高性能计算等网络突发流量的要求，可为服务器提供FCoE接入和以太网接入服务，从而帮助医院轻松整合异构的LAN和SAN两张网络。
5、充分考虑设备利旧以节约成本
重点在设计集团内网架构，确保内网网络设备的稳定性、安全性、先进性、可扩展性；对于办公外网在满足功能需求前提下，充分考虑使用内网利旧设备组建，节约成本。
6、传统架构网络拓扑与虚拟化架构网络拓扑对比
两台数据中心核心交换机通过vPC技术（Virtual Port-Channel），即可以实现跨交换机的端口捆绑，这样在汇聚交换机上连属于不同机箱的核心交换机时，可以把分别连向不同机箱的万兆链路用与IEEE 802.3ad兼容的技术实现以太网链路捆绑，提高冗余能力和链路互连带宽的同时，大大简化网络维护。通过部署虚拟化技术，即将两台核心交换机在逻辑上虚拟成一台交换机，实现双机及链路负载均衡、分布式转发等特性，比传统的MSTP+VRRP技术相比，虚拟化技术具备快速部署、管理简单、易扩展等优势。 传统架构网络拓扑与虚拟化架构网络拓扑对比图
虚拟化项目成功实施之后，服务器数量、网络设备、机架、其它外设以及IT支撑设备会大量减少，机房环境会变得更加易于管理并井井有条。 设备利用率大幅度提升，发展空间进一步得到拓展，确保今后一段时间内不
需要购置新的服务器设备。信息中心可以按照不同应用所需资源的不同，动态地对物理服务器进行虚拟分区，提供最合适的虚拟环境，提高每台服务器的利用率，也使得资源分配更加合理。虚拟环境的大量使用，改变了以往在单台服务器上只能部署单个应用的弊病。
应用安全性明显提升，对各个应用系统实施动态冗余管理，系统可用性比以前提升了一倍左右。数据安全水平进一步提高。实现集中备份与还原。所有的应用全部运行在虚拟环境中，完全实现了软硬件的隔离。真正实现了零宕机迁移，可将迁移工作对业务的影响降低为零。
系统管理更为简化，减轻运维压力。服务器合并后降低了所需要管理的物理服务器数目，极大地降低了单点故障率，与之对应的是管理、维护工作量的极大下降。
虚拟化整合前后对比表
比较内容 虚拟化整合前 虚拟化整合后 3－10天硬件采购 新业务上线需要时间15-30 分钟 20-40小时安装操作系统模板部署虚拟机，启动即周期（软/硬件准备） 和应用程序。 可。 机器送修，恢复时间一周硬件故障，恢复周期 分钟级恢复周期。 左右。 数小时停机维护，且只能零时间宕机硬件维护，且可计划内的宕机维护 安排在非工作时间。 以在任何时间进行。 每个虚拟化的业务系统，都不具备高可用、数据容错具备高可用和数据容错等安全性 等保障性功能，业务系统安全措施保护，业务系统运运行中断风险性较大。 行中断风险性极小。 系统迁移升级风险 需要考虑软硬件的兼容不用考虑硬件兼容性问题，性，风险不可控，出现问当迁移升级失败后，可瞬间题恢复困难。 服务器数量 90台服务器。 恢复，把风险降到最低 。 12台两路服务器。 4.4 技术要求 4.4.1 网络设备
1、数据中心核心层交换机
产品分类：交换机 参考品牌： 参考型号： 数量：2台
修改分类 指标 指标项 招标方要求 意见 10插槽及以上，其中业务插总体要总体要系统构架 求 求 引擎数量 系统交换能≥ 8.5Tbps 性能要力 技术指求 标 能力全双工 端口 万兆光口数≥ 48个 万兆/千兆自适应 每插槽交换≥ 900 Mpps 槽数≥8个，支持多级多平 面交换架构 两个控制引擎模块 依据 理由量 千兆电口数光口 ≥ 48个 量 多模模块配万兆≥10个 光纤模置数量 块 单模模块配40KM万兆≥12个 置数量 40KM千兆≥12个 支持FCoE/DCE，支持IEEE 支持协支持协议类DCB 或CEE 议类型 型 所配置的万兆接口板支持二层多路径功能 冗余电源 可选项 冗余组件 冗余风扇 所有关键部件采用冗余设计，包括主控板、交换网接口、电源和风扇等；采用无源背板设计，避免机箱出现单点故障；所有单板支持热插拔功能，并且对其它单板上运行的业务无影响。
无阻塞矩阵，线速交换。分布式处理。
光接口、铜缆接口数量满足实际需求，至少保证各有20%余量。 支持动态路由协议、端口聚合、虚拟路由冗余协议等保护机制，有效保证全网高速可靠运行。部件冗余。
实现对网络业务的分析。为用户提供完整的网络流量分析解决方案；支持向服务器发送日志，防止统计信息丢失。帮助用户及时优化网络结构，调整资源部署。
与现有设备保证完全兼容，确保网络的稳定运行。
2、汇聚层交换机
产品分类：交换机 参考品牌： 参考型号： 数量：14台
修改分类 指标 指标项 招标方要求 意见 总体要总体要系统构架 求 求 ≥ 920Gbps(所有实配万兆性能要交换容量 端口为全线速) 求 包转发率 万兆光口数≥24 量 端口 千兆光口数技术指量 标 多模模块配万兆≥3个 光纤模置数量 块 单模模块配40KM万兆≥1个,15KM千兆 置数量 ≥1个,5KM千兆≥14个 ≥48 ≥ 720Mbps 配置双引擎模块 依据 理由支持协支持协议类BGP、OSPF等汇聚所需路由 议类型 型 协议； 所配置的万兆接口板支持二层多路径功能，且完全兼容IETF TRILL标准。 冗余电源 可选项 冗余组件 冗余风扇光接口、铜缆接口数量满足实际需求，人民医院至少保证各有30%余量，其他医院至少保证各有60%余量。
支持动态路由协议、端口聚合、虚拟路由冗余协议等保护机制，有效保证全网高速可靠运行。冗余电源。
3、数据中心服务器汇聚交换机
产品分类：交换机 参考品牌： 参考型号： 数量：2台
修改分类 指标 指标项 招标方要求 意见 总体要总体要系统构架 求 求 性能要交换容量 求 技术指40GE光口数标 量 端口 万兆光口数≥24 ≥2 包转发率 ≥ 920Gbps ≥ 720Mbps 配置双引擎模块 依据 理由量 千兆光口数≥48 量 万兆/千兆自适应电口数≥48 量 多模模块配万兆≥4个 置数量 单模模块配光纤模置数量 块 FC端口数量≥16个或可配 置不小于8端口激活光纤 交换机 支持FCoE/DCE，支持IEEE DCB 或CEE 支持协支持协议类所配置的万兆接口板支持 议类型 型 二层多路径功能，且完全兼容IETF TRILL标准 冗余电源 可选项 冗余组件 冗余风扇光接口、铜缆接口数量满足实际需求，光接口至少保证有30%余量，铜缆接口至少保证有100%余量。
支持动态路由协议、端口聚合、虚拟路由冗余协议等保护机制，有效
40KM万兆≥4个 保证全网高速可靠运行。冗余电源。
4、接入层48口全千兆接入交换机
产品分类： 交换机 参考品牌： 参考型号： 数量： 82
修改分类 指标 指标项 招标方要求 意见 性能要交换容量 求 包转发率 千兆光口数量 端口 千兆电口数量 光纤模模块类型 块 技术指 标 支持快速以太网、千兆以太网以太网支持协支持协议类型 议类型 端口捆绑标准，支持静态路由或RIP路由协议。 线速交换，支持全功能SNMP，标准vlan。
5、接入层24口全千兆接入交换机
理由依据 ≥ 80Gbps ≥ 65Mpps ≥4 ≥48 单模 模块配置数量 千兆≥2个 通道技术，802.3ad 产品分类： 交换机 参考品牌： 参考型号： 数量： 54
修改分类 指标 指标项 招标方要求 意见 性能要交换容量 求 包转发率 千兆光口数量 端口 千兆电口数量 光纤模模块类型 技术指块 标 模块配置数量 ≥24 单模 千兆≥2个 支持快速以太网、千兆以太网以太网支持协支持协议类型 议类型 端口捆绑标准，支持静态路由或RIP路由协议。 线速交换，支持全功能SNMP，标准vlan。
6、接入层24口全千兆接入2个万兆上联交换机
理由依据 ≥ 80Gbps ≥ 36Mpps ≥4 通道技术，802.3ad 产品分类： 交换机 参考品牌： 参考型号： 数量： 6
修改分类 指标 指标项 招标方要求 意见 性能要交换容量 求 包转发率 万兆光口数量 端口 千兆光口数量 千兆电口数量 光纤模模块类型 块 技术指标 支持快速以太网、千兆以太网和万兆以太网通道技术，支持协支持协议类 议类型 标准。支持静态路由或RIP路由协议。 虚拟化机箱之后，支持跨机箱端口聚合。 7、网络管理软件、端点准入系统
理由依据 ≥176Gbps ≥ 65Mpps ≥2 ≥2 ≥24 单模 5KM万兆≥2个 模块配置数量 802.3ad端口捆绑 功能支持可管理所有支持SNMP交换机和计算机终端接入有网络认证，网络故障有监控报警，支持短信、邮件通知；管理软件支持管理网络设备200个；终端准入认证数量2000个。
4.4.2 虚拟化数据中心
产序号 品技术参数要求 名称 1. 采用裸金属架构，无需绑定操作系统即可搭建虚拟化平台。 2. 虚拟机之间可以做到隔离保护，其中每一个虚拟机发生故障都不会影响同一个物理机上的其它虚拟机运行，每个虚服务器虚1 拟化软件 4. 适用于主流虚拟化架构（如vmware、citrix）以及GuestOS（操作系统）的运营管理 5. 支持现有市场上主要服务器厂商的主流X86服务器，包括IBM、HP、DELL、Sun、Intel、NEC, Unisys以及国内自主品牌服务器等等。 6. 兼容现有市场上主流的存储阵列产品，如SAN、NAS和iSCSI，品牌包括EMC、IBM、HP、HDS、Netapp、Sun、Dell等。 拟机上的用户权限只限于本虚拟机之内，以保障系统平台的安全性。 3. 虚拟化软件可以在线进行版本升级，不同版本之间可以相互兼容。 7. 兼容现有市场上X86服务器上能够运行的主流操作系统，必须包括以下操作系统： Win2003、Win2008、Reahat Linux、CentOS等，最好支持Windows NT、Suse linux、Ubuntu、Debian 。 8. 支持将多个物理机组成集群，同时支持动态资源分配功能，可以实现VM所拥有的资源(尤其是内存、存储等)可以自动地进行再分配，保障业务系统的服务水平。 9. 能够提供性能监控功能，对资源中CPU、网络、磁盘使用率等指标的实时数据统计，并能反映目前物理机、虚拟机的资源瓶颈。 10. 具有智能的电源管理功能，可以将集群内的物理机自行下电，支持节能减排的政策性要求。 11. 每个虚拟机可以支持虚拟多路CPU（vSMP）技术，以满足高负载应用环境的要求。 12. 虚拟化平台内建虚拟交换机(vSwitch)，实现VM之间或与物理机之间的网络调度，支持同一物理机上VM之间的网络隔离(支持VLAN)。 13. 提供防病毒接口平台，可以与第三方杀毒软件或安全软件融合，实现虚拟化环境下的安全防范。 14. 提供整合备份功能；同时提供备份接口，能够与第三方备份软件无缝兼容。 15. 可以实现基于成本的容量优化以及变更事件与性能和运行状况的关联 16. 以直观的图形方式（如仪表盘、面板等等）展示系统架构的运行状态和健康状况并能够积极主动地对事件进行提醒、通知 17. 支持在线存储迁移功能，无需中断或停机即可将正在运行的虚拟机从一个存储位置实时迁移到另一个存储位置。 18. 支持热添加CPU 和内存功能，在不对用户造成中断的情况下，根据需要为虚拟机部署更多 CPU 和内存。 19. 虚拟机支持3D图形加速功能，可以根据需要启用或停用。 20. 开放存储阵列接口规范，使主流的存储厂商可以将存储软件与虚拟化平台更好的整合。 21. 每台VM(虚拟机)的vCPU数量最好达到32个vCPU，最小不少于16个vCPU。 22. 每台VM(虚拟机)的内存大小至少达到128GB。 23. 多台物理机可以实现虚拟化集群，一个集群内的物理机数量至少达到16台。 24. 单台服务器的虚拟机在线迁移并发数量至少达到4个。 25. 虚拟化管理平台提供API、SDK等接口，可以与第三方管理软件结合或二次开发。 26. 非OEM产品，提供一年原厂技术支持服务，如免费的版本升级和专业的售后服务专线支持（800电话）等。至少15个原厂人/天服务 1. 要求软件支持对主流虚拟化（如vmware、citrix）环境中的应用程序进行状态监控情况并对它们进行控制，提供经过协调的应用程序恢复能力，可防范应用程序出现故障，保证虚拟化环境业务关键型应用程序的高可用性。 2. 支持主流虚拟化环境中Windows、Linux的应用程序的高可用。 3. 要求软件支持监控并检测虚拟机内的应用程序以及该应用程序所有依赖组件中的故障。如果某个应用程序在虚拟机内发生故障，该软件将检测到该故障，并协调该应用程序的自动恢复；在适当的情况下，它还可以与基础架构 HA 协调应用高可用 虚拟机重新引导，以便从应用程序故障中恢复 4. 要求软件支持在主流虚拟化访客机已损坏且该软件无法重新启动它时自动从备份进行恢复，从而提供了一种 3 层恢复模型 – 重新启动、重新引导、还原。虚拟机还原功能可通过与主流安全备份软件（如 Symantec 备份软件）集成实现。即当虚拟机中的一个应用程序出故障时，软件首先通过重新启动该应用程序及其依赖组件来尝试使其联机。如果该故障依然存在，软件将通过其与虚拟机HA的集成来触发虚拟机重新启动。如果上述两个补救步骤都无法纠正该故障，软件将通知备份软件还原最后知道的虚拟机完善副本 5. 要求软件支持与主流虚拟化软件平台的集成，以便通过确保在灾难恢复情况下完成应用程序恢复并持续对应用程序2 进行监控来实现端到端灾难恢复。即灾难发生时位于受保护站点上的虚拟机会故障转移到恢复站点并在该站点上启动，并确保完成应用程序恢复、持续对应用程序进行监控，以及使用应用程序恢复记录（提供了端到端灾难恢复审核跟踪）加强 SRM 审核跟踪 6. 要求软件提供向导驱动的简单流程协助配置和监视应用程序。对于 Microsoft® SQL™ 、 Microsoft® Exchange™ 、ORACLE、IIS、SAP、Weblogic等现成的应用程序，可通过该向导并利用这些应用程序共用的默认参数进行配置；同时也要求可以保护非现成的应用程序，即自定义应用程序。通过选择需要监视的不同服务、流程和资源来部署自定义应用程序，实现几乎不受限制的应用程序的高可用性 7. 要求软件支持为用户提供简化的、基于向导的安装和配置流程。利用安装向导可以安装和注册插件，也可以将访客组件安装到虚拟机中。 8. 要求软件与 vCenter 无缝集成，从 vCenter可以配置、监视、启动或停止虚拟机中运行的应用程序；实现集中式管理，并且无需再使用多个管理工具。 9. 要求提供原厂实施与1年技术支持服务； 10. 要求提供15套windows VM系统与5套linux VM系统的应用高可用性保护。 3 存储1. 知名品牌，主流虚拟化厂商（如wmware、citrix）全球系统 合作伙伴联盟成员品牌； 2. 要求存储设备为冗余控制器结构，配置≥2个控制器；要求控制器CPU采用Intel处理器；CPU不少于四核，拒绝赛扬处理器； 3. 统一数据存储系统，同时支持FC SAN、IP SAN、FCOE与NAS模式，全冗余模块化体系结构 4. 提供Cache缓存保护措施，支持停电数据保护； 5. SAN控制器缓存总配置≥20GB，不接受以扩展卡增加缓存方式； 6. 配置4个8Gb/s的前端FC光纤通道端口，可扩展10Gb/s iSCSI端口； 7. 要求存储系统可支持SSD和SAS磁盘； 8. 配置40×600GB 15K rpm 6Gb SAS接口磁盘及24×2TB NL-SAS磁盘； 9. 完全的硬件冗余：处理器、缓存、电源、风扇、适配卡、总线等都提供冗余，并保证在某硬件出问题时，能够进行自动切换，不出现单点故障； 10. 需提供图形化存储管理软件，并配置不低于32个分区许可，配置虚拟资源适配功能； 11. 支持二级缓存及数据块级自动分层功能；具有VAAI和VASA接口，主流虚拟化软件全球联盟合作伙伴成员； 12. 原厂商质保服务四年7x24小时，4小时用户现场响应服务。 1. 主数据中心和远程数据中心各部署1套，用于实现双活数据中心，可支持到30公里范围或链路延迟在5ms之内范围的两个数据中心做双活，2个数据中心可同时运行，在某一数据中心出现问题时，不需要切换时间，保证应用不停顿； 2. 每站点配置≥2个node/控制器，可扩展到≥8个node/控制器； 3. 每站点实际配置缓存≥64G； 4. 每站点配置≥16个8Gb FC端口用于前后端链接； 5. 如本地某一node/控制器故障，可以不停机自动切换到本存储虚拟化系统 地另一node/控制器提供服务； 6. 如某一站点故障，可以不停机自动切换到另一站点提供服务； 7. 如某一台存储设备出现故障时，不需要进行切换，另一台存储自动接管应用，不会造成停顿； 8. 任一存储扩容、升级、更换存储、迁移数据均可在线完成，不需要停止前端应用； 9. 要求系统不占用前端主机和后端存储资源； 10. 设备间可通过光纤、IP链路支持本地、远程数据镜像功能； 11. 支持EMC、IBM、HP、3PAR、HDS、Netapp等主流厂商主流存储系列；Brocade、Cisco、QLogic等交换厂商产品； 5 12. 具有跨存储的条带化能力，优化存储性能； 13. 提供≥64主机的路径冗余软件； 14. 配置图形化监控和管理软件； 15. 除服务器和IP链路外，配齐仲裁所需要的所有软硬件、链路条件； 16. 支持联机添加和更换缓存、控制器、风扇、电源、FC接口卡等部件； 17. 支持无中断硬件在线微码升级和在线软件升级； 18. 原厂商质保服务四年7x24小时，4小时用户现场响应服务。 1. 全球外部存储市场占有率前5名品牌，主流在售机型，拒绝停产或特配机型； 2. 提供持续数据保护功能，能够保存过去一段时间内应用数据的持续恢复点；可以捕获并记录每一个写I/O操作，当持续数据保护系统 数据需要恢复时，用户可从时间点中选择，使应用程序能够基于以前的事务快速地从任一时间点恢复； 3. 至少能够保存过去1周，颗粒度小于30秒的历史数据，并可调整策略保存更长周期； 4. 带外应用装置，主存储空间直接映射给主机，主数据IO不需要经过应用装置，不造成性能影响；不需要在主机端安装任何代理，不会出现兼容性问题； 5. 可以连接到 SAN 以用于本地存储访问，也可以连接到 6 IP WAN 用于远程复制和管理；也支持跨延长距离的光纤执行的远程复制； 6. 支持异构主机、异构存储； 7. 每组应用装置支持不低于32个一致性组； 8. 高可用性应用装置配置没有任何单点故障，每个应用装置都支持双连接结构；每个节点具有4个FC接口及2个IP接口； 9. 此次配置2个节点以及不低于2TB的CDP许可； 10. 原厂商质保服务四年7x24小时，4小时用户现场响应服务。 1、 虚拟化安全防护软件的配置以能满足本次项目采购的虚拟化平台的安全防护为准； 2、 虚拟化安全防护软件可以和选用的虚拟化软件无缝整合，提供管理整合功能，实现基于虚拟化平台底层的无代虚拟化安全防护 理安全防护功能，而非在每台虚拟机中部署安全软件实现防护功能； 3、 虚拟化安全防护软件需要实现以下几个功能： a. 无代理防病毒功能 b. 无代理深度包检测功能（包含主机IPS,主机防火墙，虚拟补丁和应用程序防护） c. 完整性监控功能 d. 日志审计功能 7 4、 虚拟化安全防护软件可安装在虚拟环境中并对虚拟环境中的所有Guest OS提供保护，支持的虚拟环境应该包括VMWare, Citrix, Hyper-V等主流虚拟化软件； 5、 虚拟化安全防护软件具有集中控管的功能，能够统一的管理和配置，并且日志能够统一的在集中控管平台上呈现； 6、 虚拟化安全防护软件需要和主流虚拟化软件的自动迁移和HA功能集成，能够自动感知和保护虚拟环境的变更和迁移； 7、 厂商（和该产品）必须是微软MAPP(Microsoft Active Protections Program)成员，并可在微软官网可查。 8、 厂商（和该产品）必须能是主流虚拟化软件厂商的合作伙伴，并在虚拟化软件厂商官网可查。 9、 所有产品必须是自主开发，拥有自主知识产权； 10、 产品具备公安部销售许可证； 11、 原厂商服务一年7x24小时，4小时用户现场响应服务。产品具有中文版本且提供原厂工程师部署，调优。 注释：以上技术参数要求，如某一参数为某产品所特有，不作为强制要求，但必须有不低于该效果的替代解决方案。
第五章 项目实施进度和组织安排
5.1项目建设周期
项目工期要求：须在2013年10月底完成开发、实施和验收。项目总体建设
周期1个月。
5.2实施进度计划
建设进度安排如下：
1) 10月1日至10月5日，完成项目调研、测试环境搭建、网络及硬件安装调
试；
2) 10月6日至10月10日，完成虚拟化数据中心虚拟服务器测试环境的部署，
并在测试环境中测试通过；完成移动医护应用的测试环境的搭建。 3) 10月11日至10月20日，虚拟化数据中心平台搭建完成，除HIS、PACS外
其他业务系统迁移到虚拟机上；
4) 10月16至10月20日，完成HIS、PACS服务器迁移；完成网络整体改造和
设备上线调试。
5) 10月17日至10月25日，完成新增存储的安装、调试、部署和存储虚拟化
部署；完成网络设备上线使用；完成移动医护应用的正式环境的搭建并能上线使用。
6) 10月26日至10月31日，完成连续数据保护的部署。
5.3责任人和组织保障
一、项目组织机构与人员
建立强有力的组织、管理与协调架构，统一领导、统筹协调、分工协作，以保障建设任务的及时、可靠、高质量地完成。项目建设将成立工作领导小组，负责项目建设的统一领导、重大问题决策和统筹协调工作。领导小组下设办公室及项目小组。项目组织机构及人员如下： 1、领导组织机构
组长：单位主要负责人承担； 副组长：信息中心负责人担任；
成员：信息中心业务副主任和相关业务信息员担任; 责任机构：市立医疗集团； 2、项目建设机构
本项目主体工程由政府投资，按照要求，将采用公开招标的方式来选定项目承建方，中标后再设定建设机构。 3、运行维护机构
由市立医疗集团负责协同合作单位制定长效的各业务系统日常维护合同，双方以稳定的技术队伍保障系统的长期正常运行。在系统投入运行以后，要通过定期或不定期地举办各种短训班，加强对业务人员的应用技术培训。 二、项目责任制
本项目由指定的责任人，负责总体项目按照规划的实施。职责如下： 从事项目的设计、开发、实施，应当执行有关的国家标准、行业标准和本市
地方标准。设计、施工单位对卫生信息建设项目质量终身负责。
严格按经批准的设计方案施工，未经设计单位和建设单位同意不得改变设计
方案。
建立健全建设项目质量保证体系，加强施工质量管理，并建立质量检查检测
制度和内部质量责任制。
项目竣工后，施工单位应当向建设单位提出完工报告，经试运行合格的，建
设单位组织设计、施工单位、监理单位进行初步验收；初验合格后，由建设单位向市主管部门提出验收申请。
协调项目建设施工单位根据《卫生信息建设项目承包合同》的规定履行工程
质量维护义务。工程质量维护期不得少于一年。确保未取得卫生信息建设项目使用许可证的信息工程，不得交付使用。
因设计、施工单位的过错导致信息工程质量不合格，给建设单位造成损失的，
设计、施工单位应赔偿建设单位损失。
第六章 项目风险及控制措施
6.1项目实施的外部风险及控制措施
1、项目符合国家的宏观政策，不存在政策法律风险。
2、近年来，国民经济发展良好，软件产业稳定发展，对于自然环境没有任何污染。
3、不可抗拒自然灾害风险对于项目的影响不会延缓本项目的实施进度。 4、开发商的技术实力、项目实施能力：包括项目队伍的需求分析能力、业务理解能力、开发技术能力、项目队伍的稳定性、项目实施的规范性、项目维护的可靠性等因素都将是影响虚拟化数据中心建设的风险。
因此需要加强对开发商的技术考察、背景考察，选择长期合作、稳定的企业参与本单位信息化建设。
6.2项目实施的内部风险及控制措施
1、目标范围定义的风险
用户对信息的期望值较高，很多人都希望能有一个完美的信息系统，能解决所有的问题。在有限的时间内必须对系统的范围作出合理的规定，这势必影响到很多人的期望值。
2、项目本身难度
业务涉及范围大、地域分布大、层次多。因而在实施中会遇到不可估计的各种因素，例如：人员素质较低，导致系统培训时间长，系统实施周期能的定义可变因素多，使软件功能的不稳定性大，变动因素使软件功能不能满足实际需求的变化。由于某些部门对办公信息化不太了解，初期调研时对信息需求定义不确切，致使开发的功能不能满足业务处理的要求，系统的信息需求一改再更改，致使开发周期推迟。
3、人力资源的风险
项目开发及工程实施人员的缺乏将造成项目进度的延误和质量的下降。
4、环境设备的风险
设备（服务器、网络环境、工作站等）经常会出现问题，花在设备维修和安装系统上的时间将严重影响项目组成员的工作效率，直接影响项目的进度。同时病毒感染也会造成死机或系统崩溃。
5、用户领导小组变更的风险
领导小组在项目中途退出或淡出，这将直接影响项目组的人心稳定和工作的协调。
6、对需求的风险
本信息系统建设在行业所处的特殊位置会有特殊的需求，卫生标准的不规范性，由于卫生标准的变动引起软件结构的变化等。
7、团队合作风险
人员之间会有一个磨合的过程，如果人员之间磨合地不好，不能形成团队的精神，将会严重影响工作的效率。
8、人员流动的风险
人员流动可能会直接影响项目的整体进度。
为了避免以上的项目风险，对开发周期应有必要的机动期，留有余地。功能的定义可变因素多，这是管理系统软件开发的常情，必须在开发初阶段，十分重视系统的需求分析阶段，要给予较充分的调研与分析的周期。不能草率，不能急于赶进度，而不顾需求分析的质量。同时，选用便捷的开发工具，使开发工作能适应多变的功能的定义。
6.3项目长期运行风险及控制措施
医疗卫生标准是一项繁重又是专业性特别强的工作，它需要医疗专家化费很大的时间才能完成的工作。而且还有长期的标准维护的工作，它必须授权一定的机构才能胜任。不进行维护的标准将成为无用的标准。因而系统开发时，项目开发的业主要有承担能力，标准的制定工作必须由卫生部门来承担。必须对开发商的能力有一定的判断能力，要选择有能力有信誉的开发商。
第七章 总体设备概算清单
一、网络整体改造
概算清单 序号 产品名称 数量 单位 备注 内网设备清单 一、核心交换机 2 台 台 核心交换机 二、服务器区交换机 2 数据交换机 三、汇聚和接入交换机 14 6 82 54 台 台 台 台 汇聚交换机1 接入交换机 （万兆上行） 接入交换机 （48口） 接入交换机3 （24口） 人民医院病理科；核磁CT；放射科1楼；门诊1楼、4、7楼； 标配2个千兆模块；其中7台为外网使用； 标配2个千兆模块；其中31台为外网使用； 四、管理平台+端点准入防御 1 套 包括在用内网和外网所有支持SNMP交换机和终端接入有网络认证 单位 数量 24颗CPU授权，1套管理软件授权 网络管理软件,端点准入系统 序货物名称 号 产品描述及其他要求 对现有服务器、存储、网络等设服务器虚拟备整合，提高设备利用率；建立1 化软件 虚拟化数据中心资源池，实现业务系统和数据的高可用性、系统套 容错、灾难恢复等； 2 应用高可用 应用程序监控。 3 服务器内存 扩展内存，每根内存8GB 高性能存储：配置40×600GB 套 根 20 50 15K rpm 6Gb SAS接口磁盘及24×2TB NL-SAS磁盘 4 存储系统 存储虚拟化：实现本地及远程数据中心存储虚拟化，实现统一存储池，可对群集中引擎之间的存储域进行自动共享、平衡和故障切换。实现机房无停机迁移。 核心数据持续保护 通过防火墙、病毒防护、访问控制、入侵检测/入侵防护、虚拟虚拟化安全5 补丁、主机完整性监控、日志审防护 计等功能实现虚拟主机和虚拟系统的全面防护； 台 1 台 2 套 1 套 24颗CPU授权，1套管理软件授权
因篇幅问题不能全部显示，请点此查看更多更全内容