云计算资源需求分析及规划.docx
《云计算资源需求分析及规划.docx》由会员分享，可在线阅读，更多相关《云计算资源需求分析及规划.docx（16页珍藏版）》请在冰点文库上搜索。
云计算资源需求分析及规划
1.1.1.1云计算资源需求分析与规划
1.1.1.1.1数据中心效劳器部署根本要求
本工程关键业务数据库、数据仓库采用物理效劳器独立部署〔集群+同城双活〕，应用和管理类效劳器采用虚拟机部署〔同城双活〕。
1.1.1.1.2应用效劳器采用虚拟化方案
采用虚拟化技术是实现云计算的根底。
通过为客户提供效劳器整合和数量控制、业务连续性、测试/开发自动化、企业台式机管理等解决方案，从而实现降低本钱、提高响应速度、实现零停机、灾难快速恢复等系列好处。
通过虚拟架构整合效劳器，可以控制x86效劳器的蔓延，在一台效劳器上运行多个操作系统和应用，并使新的硬件支持老的应用，数据中心撤退旧的硬件。
虚拟根底架构使企业能够通过提高效率、增加灵活性和加快响应速度而降低IT本钱。
管理一个虚拟根底架构使IT能够快速将资源和业务需要连结起来，并对其进展管理。
虚拟根底架构可以使x86效劳器的利用率从现在的5-15%提高到60-80%，并且在数十秒的时间内完成新应用程序的资源调配，而不需要几天时间。
请求响应时间也改为以分钟计算。
在维护上，可以实现零停机硬件维护，不需要等待维护窗口。
效劳器虚拟化是计算机资源逻辑组的过程，这种资源的新虚拟视图并不受实现，地理位置或底层资源的物理配置的限制。
这种逻辑视图对信息根底设施有深远的影响。
◆效劳器虚拟化带来的益处：
虚拟化技术可借助信息根底设施更好地提供效劳，从而帮助客户节省资金。
与传统的物理效劳器部署方式相比，虚拟化所带来的一些优势包括：
∙能够迅速保存、复制和供应虚拟机，从而实现零停机时间维护并支持全新的“golive〔实时化〕〞方案；
∙动态共享效劳器平台中的闲置资源，从而在消除烟囱式〔stovepipe〕部署的同时，进一步提高性能和利用率；与此同时也能为应用提供一个隔离性的操作环境；
∙可以实现更高的技术标准化水平和流通率，从而降低运营和维护本钱；
∙可在虚拟效劳器组件发生故障时进展无缝故障切换，从而提高系统可用性；
∙降低复杂性，从而改进逻辑和物理灾难恢复。
◆效劳器虚拟化的软件平台选型原那么
在效劳器虚拟化的软件平台方面，主流的软件提供商均提供了所有软件厂商具有管理CPU、内存、网络和硬盘资源的能力的效劳器虚拟化软件，这些软件都同时支持Windows与Linux操作环境。
目前，效劳器虚拟化软件分为商用软件和开源软件，这些软件都提供了对于效劳器虚拟化硬件平台的支持，然而之间存在细微的差异。
此外不同的虚拟化软件的软件架构之间的差异较大，不同平台上的虚拟机并不能很好实现相互之间的兼容或迁移。
在效劳器虚拟化的软件平台选择中，应重点考虑以下几点：
∙系统稳定性和可扩展性
∙迁移的便利性，包括从物理效劳器向虚拟机的迁移
∙对于虚拟化硬件平台的支持
∙良好的兼容性
◆效劳器虚拟化的硬件平台选型原那么
为效劳器虚拟化选择适当的硬件平台正如选择适当的虚拟化软件一样重要为了做出正确的选择，必须考虑到以下因素：
∙优越的性能：
效劳器虚拟化的主要目的是更加充分的利用资源。
在单台效劳器上增加的工作负载需要更高的系统性能，以保持所需的效劳等级和应用响应时间。
目前广泛采用的多核处理器架构，以及对多核处理器架构提供支持以充分利用其性能和能力的系统，可以进一步提高效劳器的性能和吞吐率。
在效劳器性能需求方面，除了要考虑在非虚拟化模式下运行工作负载所需的性能之外，还需要考虑运行虚拟机〔VM〕所需的额外资源。
硬件系统中的处理器与芯片组所包含的硬件辅助特性，可以在最大限度降低这一开销方面发挥作用。
∙能效与空间：
在本钱或物理限制影响最终用户正常工作的能力的情况下，例如，当本钱超出预算，或功耗要求超出可用资源时，功耗与散热问题最为明显。
当不断扩展的IT占用空间导致数据中心或IT空间扩建时，占地空间就会成为一个大问题。
虚拟化与整合有助于减少硬件占地空间和能源利用。
更高能效的系统能够进一步降低功耗要求，从而节省能源和降低运营本钱。
功耗要求较低和/或性能功耗比较高的系统可帮助IT人员有效控制能源和空间要求。
∙总拥有本钱〔TCO〕/投资回报〔ROI〕：
不断攀升的运营本钱使资源与资本从旨在推动创新和提高IT价值的方案中抽离了出来。
使用虚拟化环境将可以提高系统利用率，降低功耗与散热要求，减少空间要求，简化运营和降低系统管理要求。
∙优化的平台特性：
组件与系统厂商将不断推出多种专为虚拟化而优化的特性。
例如，主流的硬件厂商均为处理器增添了虚拟化能力，也有针对大量I/O、网络处理需求的平台虚拟化特性。
这些能力既能简化强大虚拟化软件的设计，又能降低在虚拟化环境中运行应用通常所需的性能开销。
对于EHRS上的大量文件处理，I/O虚拟化的优化可进一步提升信息交换平台的处理与扩展能力。
∙良好的厂商协作：
通过着眼于当前全行业X围内的协作，我们将能够更好地了解虚拟化的特征。
鉴于虚拟化涉及多个层次上的软硬件组件，系统厂商、操作系统与应用厂商以及虚拟化厂商需要携手合作，共同制定出可行的解决方案。
目前，多家行业合作伙伴正在全新平台上针对虚拟化进展优化。
∙良好的兼容性：
保持各代平台之间的兼容性是未来系统的一个重要特性。
将VM从一台效劳器迁移到另一台效劳器上需要考虑架构问题，这样IT部门无需创立虚拟资源岛〔islandsofvirtualresource〕，但却可以真正发挥出根底设施的最大灵活性。
◆对虚拟机平安的考虑
虚拟化使用户获得在效率、本钱方面的显著收益,以及在数据中心更具环保、灵活的扩展性和减少实施时间方面的附加价值。
数据中心的虚拟系统面临许多与物理效劳器一样的平安挑战，并且还有自身的一些特点，如果不解决这些问题，平安最终将抵消虚拟化的优势。
尤其在虚拟化体系构造将从根本上改变关键业务应用，包括设计、部署和管理的情况下，用户需要考虑哪种平安机制最适合保护这些虚拟效劳器。
传统环境下的网络平安拓扑图，在网络出口处部署有防火墙，防毒墙，上网行为管理等平安设备，用来隔离内外网，过滤来自外网的恶意程序，规X内网用户的上网行为，同时在DMZ区使用防火墙隔离，部署IDS监控对效劳器的非法访问行为，在效劳器上部署防病毒软件，保护核心效劳器的平安运行。
根据传统的平安设计模型，需要在每个操作系统中安装防毒软件，在网络层部署入防火墙、侵检测或入侵防御系统，但是在这种在传统方式下合理的设计，在虚拟环境下会面临一些新的问题：
未激活的虚拟机，物理机下关闭计算机后CPU停顿运行，网络关闭，理论上不会有数据的交互，操作系统也就不存在被感染的可能；但是在虚拟环境下，CPU，网络，底层的ESX都在工作中，关闭的操作系统类似于物理环境下的一个应用程序，尽管这个“应用程序〞没有运行，但仍然有被病毒感染的可能；
资源的冲突，防毒软件在启用预设扫描后，当到了指定时间，会同时进展文件扫描的动作，这个时候防毒软件对CPU和内存的占用急剧增加，当系统资源被耗尽的时候就会导致效劳器down机；
管理复杂度，由于虚拟化的便利性，系统管理员可以非常方便的根据模板生成新的系统，这些新系统要打补丁，进展病毒代码的更新，也会增加平安管理的复杂度；
虚拟化环境的动态特性面临入侵检测/防御系统〔IDS/IPS〕的新挑战。
基于网络的IDS/IPS，也无法监测到同一台ESX效劳器上的虚拟机之间的通讯；由于虚拟机能够迅速地恢复到之前的状态，利用VMwareVMotion™易于在物理效劳器之间移动，所以难以获得并维持整体一致的平安性。
所以虚拟化已经使“网络边界去除〞的挑战更加明显，虚拟化对于平安的需求也更加迫切。
平安虚拟机利用API来访问关于每一虚拟机的特权状态信息，包括其内存、状态和网络通信流量等。
因为在不更改虚拟网络配置的情况下，效劳器内部的全部网络通信流量是可见的。
包括防病毒、防火墙、IDS/IPS和系统完整性监控等在内的平安功能均可以应用于平安虚拟机中。
1.1.1.1.3数据库效劳器性能需求分析
区域卫生信息系统覆盖面广、业务极其复杂，各业务子系统之间穿插非常多，因此很难通过搭建业务模型通过压力测试来进展系统性能的分析，所以，业内一般采用“售前估算法〞，通常的做法是：
选择应用系统中业务重要性、业务频繁度、客户连接数最多、最具有代表性的一个业务进展估算，结合行业内其他工程的建立经历进展综合评价，得出最终的主要设备性能需求。
本工程中，我们选择“以EHR〔居民电子安康记录〕为根底的社区卫生信息系统〞作为我们评估数据中心核心数据库效劳器性能的参考业务系统，售前估算法主要涉及的要点见下表：
1XX市区域卫生信息系统网内注册用户估算为3000个，预计顶峰并发访问数在1500个左右；通过门户发起的业务申请用户估算为每天2000个，预计顶峰并发访问数在500个左右；因此，估算公式中的U值为2000；
2假设每个用户每秒提交业务处理请求个数为1个，公式中的Q值；
3平均处理每个业务处理请求所需要的时间应在1秒左右，公式中的J值；
4假设每年并发用户增长率暂时考虑为0，公式中的G值；
5主机系统的平均使用计算资源率建议不超过40%〔双机热备〕，公式中的B值；
6系统设计性能覆盖年限为5年左右，公式中的N值；
7根据经历及对应用程序的分析，每个业务请求相当于5-10个tpmC，本工程的主数据库效劳器主要为OLTP〔联机事务处理〕应用；公式中的S值；
81分钟为60秒，公式中的T值；
9由此得出:
U×Q×J×（100%+G）N×T×S÷B，根据以上数值，得出本系统所需的主机TPCC性能要求为最低1500000TPMC，最高3000000TPMC；
本方案以IBMPower740小型机为例，其3.6GHz的Power7CPU的单核TPmC值约为100000，因此满足信息系统5年应用的效劳器主机TPmC总值需要配32核Power73.6GHzCPU。
结合业务7×24小时不能停顿的系统高稳定可靠要求，以及节约本钱考虑，建议配置2台数据库效劳器做集群，两个节点可同时提供数据库处理，参照OracleRAC技术特性，双机集群后，整体性能为单机效劳器的1.5倍左右。
综上所述，数据库主机系统的单机参考配置为：
相当于IBMPower716Core3.6GHzCPU。
数据库效劳器内存需求分析如下：
（1）参照实际应用经历以及参考数据库的技术特性要求，信息系统数据库连接数约为2000个，每个连接占用20M内存，共计所需40G内存；
（2）以3-5年在线生成数据库数据将到达500GB左右的规模估算，一般医院信息系统的在线业务和查询业务都在同一数据库里执行，按照使用经历来看大概有接近5%的热点数据，因此数据缓存使用的内容为按照25G估算；
（3）在执行数据库备份时，为了加快备份速度，使用5GB左右的文件缓存；
（4）目前主流的、最新版本操作系统建议保存使用10G左右的内存用于系统调配；
综上，按照70%的系统内存使用阀值来计算，共计内存114GB；在主机硬件配置时，应配置128GB内存。
1.1.1.1.4存储需求分析
1.1.1.1.4.1存储性能根本要求
数据中心存储系统的磁盘阵列应采用支持多种转速的、热插拔硬盘的高性能存储设备，双控制器或多控制器模式保证磁盘阵列本身的高可用，阵列的控制器缓存建议少于32GB，采用8GB或以上FC通道连接SAN，并支持ISCSI接口便于文件类的存储。
针对数据库热点数据的存储，建议采用高性能的SSD盘；
针对一般数据库存储和虚拟机文件存储，建议采用不低于10000转速的SAS硬盘；
针对影像文件、视频文件等存储，可采用本钱较低的SATA硬盘；
磁盘阵列通过存储虚拟化网关进展存储资源的池化，从而支撑数据库和虚拟机同城双活方案的实现；
1.1.1.1.4.2数据量估算
〔1〕以EHR为核心的应用系统数据估算
业务类别
数据类型
说明
数据量估算
EHR业务
居XX索引数据
按500万人口计算
0.01M*500万=50G
居民安康卡数据
按500万人口计算
0.02M*500万=100G
出生证数据
按每年4万计算
1M*4万*1年=40G/年
妇幼保健数据
按每年80万计算
1M*80万*1年=80G/年
个人根本安康档案
按500万人口计算
0.1M*500万=500G
专项疾病保健数据
按每年6万计算
1M*6万*1年=60G/年
电子病历数据
按每年4万计算
10M*4万*1年=400G/年
检验/检查结果数据
按每年80万计算
0.02M*80万*1年=16G/年
处方/医嘱数据
按每年160万计算
0.01M*160万*1年=16G/年
安康体检数据
按每年14万计算
0.1M*14万*1年=14G/年
医学影像索引及图文报告系统数据
按每年4万计算
2M*4万*1年=80G/年
其他诊疗数据
按500万人口计算
0.2M*500万*1年=1000G/年
数据仓库
主题数据库
按每年100万条数据
0.02M*100万*1年=20G/年
资源数据库
按每年2万条数据
0.02M*2万*1年=0.4G/年
方法库，模型库
估算1G
其他数据
各种标准协议数据
估算1G
监控管理数据
按每年0.6G增量计算
0.6G/年
系统其他数据〔用户，日志等〕
按每年0.2G增量计算
0.2G/年
合计
约2829.2GB
每年增量
约600.2GB
系统设计5年总数据量
5230GB
以上数据存储应采用SSD和SAS混合形式
〔2〕区域医疗主要数据估算
应用系统
数据量估算
HIS/EMR/LIS/HSS等
300G，每年增量30G
疾控/卫监/急救等
500GB，每年增量50GB
合计
约800GB，每年增量80GB
系统设计5年总数据量
1200GB
以上数据存储应采用SSD和SAS混合形式
〔3〕其他应用系统数据估算
应用系统
数据量估算
基层卫生效劳信息系统/综合运营数据
100G，每年增量10G
外网应用数据
500GB，每年增量50GB
视频数据〔典型〕
1000GB，每年增量1000GB
合计
约1600GB，每年增量1060GB
系统设计5年总数据量
5840GB
以上数据存储应采用SAS和SATA混合形式
〔4〕数据中心系统平台存储资源占用估算
系统
数据量估算
虚拟机，预计50个虚拟机，每个虚拟机200GB
10000GB，每年增量200G
程序更新
10G，每年增量1G
配置管理
10G，每年增量1G
合计
约10020GB，每年增量202GB
系统设计5年总数据量
10828GB
以上数据存储应采用SAS和SATA混合形式
根据上述分析可得数据中心存储系统可用容量应不低于：
23098GB〔23TB〕，考虑设计不少于2个数据存储副本，那么建议容量不少于69TB，可分期逐步扩容。
1.1.1.1.5效劳器计算资源需求分析
根据本工程的应用系统建立需求，分解各个应用系统对计算资源的需求，如下表：
效劳器名称
用途说明
机器
数量
单个配置
〔core/G〕
合计资源
〔core/G〕
CPU
内存
CPU
内存
关键数据库〔物理机〕
电子安康档案资源库、电子病历资源库、全员人口信息库、卫生计生管理资源库、
2
40
128
80
256
数据仓库效劳器〔物理机〕
基于平台的ODS,DW等
2
40
128
80
256
分布式协调效劳器
zookeeper
5
2
8
10
40
数据交换效劳器
数据采集和交换平台、ETL、Adapter
1
4
32
4
32
对外交换前置机
XX省级平台、市属医院、镇区医院、社区效劳站、民营医院、人口与方案生育效劳中心、政务交换中心
72
2
8
144
576
平台应用效劳器
平台根底应用、主索引管理、安康一卡通系统、安康档案浏览器
4
4
32
16
128
公共卫生应用效劳器
疾病控制信息系统
1
4
16
4
16
疫苗冷链动态监测系统
1
4
16
4
16
区域120急救系统
1
4
16
4
16
突发公共卫生应急指挥系统
1
4
16
4
16
卫生从业人员管理系统
1
4
16
4
16
妇幼保健信息系统
1
4
16
4
16
医疗协作
双向转诊系统
1
4
16
4
16
检查检验结果互认系统
1
4
16
4
16
区域检验系统
1
4
16
4
16
远程影像会诊系统
1
4
16
4
16
在线培训考试系统
1
4
16
4
16
卫生综合管理
综合管理与决策支持系统
1
2
16
2
16
区域医疗效劳监管系统
1
2
16
2
16
区域公共卫生监管系统
1
2
16
2
16
区域卫生资源监管系统
1
2
16
2
16
区域用血监管系统
1
2
16
2
16
区域卫生绩效考核系统
1
2
16
2
16
区域卫生全面预算管理系统
1
2
16
2
16
区域卫生政府财政补偿管理系统
1
2
16
2
16
用药管理
区域药品监管信息系统
1
4
16
4
16
方案生育管理
方案生育管理信息系统
1
2
16
2
16
安康效劳
个人安康移动效劳平台数据库
2
8
16
16
32
个人安康移动效劳平台应用效劳器
2
4
8
8
16
居民安康效劳公共平台WEB应用效劳器
4
4
8
16
32
居民安康效劳公共平台数据库效劳器
2
8
32
16
64
安康网&APP数据交换效劳器
1
4
16
4
16
网管效劳器
网络平台管理
1
2
8
2
8
防病毒效劳器
防病毒系统
1
2
8
2
8
网络管理效劳器
网络节点管理
1
2
8
2
8
虚拟化管理效劳器
管理中心
1
2
16
2
16
备注：
如采用政务云租赁模式，那么需保证数据中心同城双活机制的实现，确保应用系统的业务连续性。
升级会员 