<p>选择主机系统的几个基本点<br />根据医院信息管理系统建设的需要和医院的实际情况,可以通过对业务系统的分析,推算出主机系统性能。<br />1. TPC-C及TPMC<br />TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数十家会员公司创建的非盈利组织,它的功能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量,并管理测试结果的发布。<br />TPC已经推出了四套基准程序,被称为TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已经过时,不再使用了。TPC-C是在线事务处理(OLTP)的基准程序,TPC-D是决策支持(DecisionSupport)的基准程序。TPC即将推出TPC-E,作为大型企业(Enterprise)信息服务的基准程序。<br />TPC-C使用三种性能和价格度量,其中性能由TPC-C吞吐率衡量,单位是tpmC。tpm是transactions per minute的简称;C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。价格是指系统的总价格,单位是美元,而价格性能比则定义为总价格÷性能,单位是$/tpmC。<br />关于"每笔实际交易对应多少个TPC-C值"这个问题,其数值是随着业务性质的不同而不同的。对此数值最科学的解释,应该来自应用系统本身,当应用系统跑起来以后,可以通过对系统运行效率的科学评测和分析,来获取。也可以根据类似应用的经验值来参考。不同厂家的机器,对应值也不完全一样。<br />一般来说我们需要保证40%(M1)的主机CPU处理余量,用于系统、数据库、中间件软件、工具软件、监控软件或其它应用系统的使用。</p><p>1. HIS/LIS系统交易量分析<br />医院具体的情况分析,同时考虑到系统未来的扩展需求,考虑所有系统信息点约x个,在峰值情况下的一分钟之内全部对数据库服务器发起连接请求,即可得到系统的联机事务处理请求的峰值约为每分钟x个连接(当然,这是以最大峰值进行估计)。考虑到系统3~5年后的业务扩展,按照50%的比例增长,这样得出联机事务处理请求为x×(1+50%)个连接。每一次请求对应数据库的操作3-5笔,则可得到联机事务处理峰值为x×(1+50%)×5=2280笔/分。<br />根据计算公式:TpmC = TPS峰值 × M2 / (1-M1)<br />一般来说每一笔M2(联机事务处理所对应的TPC值)的值都根据具体的业务处理情况不同,一般好的系统的M2的值应该在5~15范围内。在此不可能将每一笔值进行精确的估算, 只能够对这些所有的联机事务处理做一个平均值估算。因此总体来看,按照M2=15来进行估算是一个比较合理的数值。<br />这样我们就可以将这些值计算出来。<br />TPM =2280×15/( 1-40%) =57000TpmC。<br />由此可以得出医院HIS/LIS系统数据库服务器的TPCC值最少应该达到57000TpmC。<br />2. 内存容量分析<br />关于内存的配置,我们是这样进行估算的。内存的消耗主要包括有如下几个部分:<br />1) 主机系统正常运行所需消耗(主要指操作系统消耗);<br />2) 数据库运行所需开销;<br />3) 数据库SGA运行所需正常开销;<br />4) 联机事务处理消耗;<br />因此从上边我们可以看到主机系统所需内存大小由五大部分组成。通常情况下我们建议CPU和内存比例为 1:2。<br />因此,医院HIS/LIS管理信息系统所需的比较合理的内存容量为8GB。<br />3. 内置硬盘<br />实际上系统对内置硬盘的大小要求不是很高,根据经验,可以得出这个结论即:内置硬盘大小为:操作系统+数据库+应用软件;整个容量不超过18GB左右,但是考虑到数据库软件随着运行时间的不断增长,其所要求的存储容量也会相应增加,并且考虑采用镜像的方式保证系统文件的安全。<br />因此我们配置的内置硬盘大小为72.8GB(36.4GB×2)。<br />2存储系统设计<br />磁盘阵列存储的内容根据医院的要求,主要是全院信息系统3~5年时间产生的所有数据及其原始数据。<br />对于磁盘阵列的大小,我们根据医院的实际情况进行估算:<br />预计全院满负荷运转时,日门诊量达a人次,病床b张,根据以往对医院管理信息系统建设和实施的经验,我们认为医院管理信息系统数据量的组成主要包括以下几个方面:<br />? 基础信息数据(包括医院的人员信息、科室信息、物资信息、药品信息等等),数据容量不超过2GB。<br />? 住院系统信息数据(包括住院登记信息、住院收费信息、住院药房管理信息等等),每天产生的数据容量约为60MB。<br />? 门诊系统信息数据(包括门诊挂号信息、门诊综合收费信息、门诊药房管理信息等等),每天产生的数据容量约为20MB。<br />? 其他系统信息数据(包括医院其他管理系统信息等等),每天产生的数据容量约为10MB。<br />? 同时要考虑到电子病历系统产生的大量信息数据,按照年出院22000人计算,每天产生的数据量约为72GB。<br />通过以上对系统产生数据量的估算可见,系统的初始基础数据约为2GB,满负荷运转时,每年产生的数据容量约为几个主要数据信息增长量之和,即为:<br />(20MB+60MB+10MB)×365+72000MB=104850MB,约等于105GB;医院系统5年运行产生的数据量约为:105GB×5=525GB。<br />同时,为了保证数据的安全性和可靠性,我们考虑使用目前最通用的RAID5技术,磁盘空间利用率为(磁盘数量-1)×单块磁盘容量=实际存储容量,还要预留一块硬盘作HOTSPARE。这里以单块硬盘容量73GB计算,可得所需硬盘数量为:(N-1)×73GB=525GB,N=9。这样系统所需配置磁盘存储容量为73G×10=730GB。<br />根据以上估算,可以得出医院管理信息系统的磁盘阵列容量为730GB。</p><p>3灾难备份策略</p><p>冷备份设计思想<br />用户可以考虑额外配置一套磁带库或是光盘塔之类的大容量存储设备,定期对核心服务器内的内容进行数据复制,然后将备份出来的数据放入磁带库或是光盘塔中,这是一种及其简单且实用的方式,而且它的技术含量较低,容易实现,不过采用此种方式效率很低,因为它不但在备份数据时需要大量时间,且数据进行恢复的时候也需要大量时间。<br />暖备份设计思想<br />采用此种方式,相对投资要大一些,我们可以再另外配置一台低档次的小型机或PC服务器,配置大容量的内置硬盘或磁盘阵列,也可以是磁带库,通过网络系统保持与核心服务器之间的实时连接,可以以一天或是更短的时间为单位,对数据实现近似于实时备份。这台机器可以在物理上与主服务器分布在不同的大楼里,可以通过局域网或是广域网线路保持与中心服务器系统的连接。以实现对数据进行备份。<br />这种方式不论在技术上和存储速度上都比冷备份方式成熟且相当可靠,由于目前技术十分成熟,实现起来也相对没有什么困难,但是投入相对较大,用户可以根据自己目前的财政状况选择这两种方式去实现整个系统真正的可靠性!<br />具体备份方式(磁带库)<br />由于信息系统事关全院医疗业务的开展,所以我们对可靠性的要求不仅仅要求停留在传统意义上对硬件设备的进行冗余设计、对线路进行冗余设计的基础上,而且还要在整体上实现对系统所有的数据进行实时备份,以保证系统全方位的实现真正意义上的可靠性设计。<br />但是如果真正采用灾难备份设计,这也意味着用户需要付出更多的财力去实现它,根据医院项目建设的实际情况,具体的实现方式如下:<br />另外配置一PC服务器作为系统备份服务器,连接磁带库,并配置专业备份软件系统,通过网络系统保持与核心服务器之间的实时连接,可以以一天或是更短的时间为单位,对数据实现近似于实时备份。这台机器可以在物理上与主服务器分布在不同的大楼里,可以通过局域网线路保持与中心服务器系统的连接。以实现对数据进行备份。<br />具体备份策略如下:<br />a.主机数据均采用:<br />日备份--每天作一次归档备份(小数据量)<br />周备份--每周作一次全备份(保留5个周备份拷贝)<br />月备份--每月作一次全备份(保留6个月备份拷贝)<br />b.备份操作可以在关闭数据库情况下进行,这样备份工作就应在夜间无业务或很少业务量时完成。<br />可以在不关闭数据库情况下随时进行,但由于备份操作需要占用系统资源,造成系统额外开销,所以备份工作应尽量安排在生产业务不繁忙时进行。<br />c.做一次全备份的时间应不超过3-5小时。<br />4不同投入的医院数据备份解决方案</p><p>10万元投入解决方案</p><p>当系统数据的重要性很高时,数据备份的投资力度相应的也会增大。尤其是当系统要求7x24小时可用,没有给备份工作提供停机备份的时间窗口时,备份系统必须具有能够对打开文件进行备份的能力,即所谓在线备份技术。这就要求备份软件的功能足够强大。同时,随着系统自动化要求的提高,手工管理磁带介质的方式难以满足系统的需求,在数据量不是很大的情况下,可以考虑采购自动加载机(AutoLoader)进行准自动化的磁带管理。</p><p>在这样的要求下,投入在软件和硬件方面的资金都需求有所增加。一般Windows平台上能够进行在线备份的软件,投资应该在6~8万元,而自动加载机的价格也在3万元左右,这样整体的系统投资基本在10万元左右。</p><p>以此投资力度建立的备份系统可以支撑一个相当规模的Windows网络环境,对其中的文件、数据库应用、邮件系统、用户信息等数据都可以进行集中统一的备份保护。备份过程完全是自动化的,无需人工干预。而且,当系统中某节点出现故障时,数据恢复工作也完全是自动化和智能化的,只要提供备份介质和可引导的系统启动盘,备份软件就可以恢复出系统故障前的状态。</p><p> </p><p>总结:中型网络备份;Windows*作系统平台;数据量较大;需要长期保存数据;典型数据库应用;邮件系统等其他专业数据;基本无停机备份;智能化恢复数据。</p><p>30万元以上的投入</p><p>当数据量达到TB级时,单台磁带机和自动加载机已经无法满足自动化管理的需求,而需求配置自动化程度更高的磁带库设备。一般这种环境下*作系统平台也会以Unix为主,或者是更为复杂的多种*作系统平台混和系统。这种环境下,数据保护工作的复杂程度进一步增加。一个典型的混和平台环境,数据备份系统投资额基本都在30万元以上。</p><p>如果以30万元投入计算,其中软件部分所占的投入约为30~40%,用来采购支持Unix平台的高端备份软件服务器端和客户端代理,以及一些数据库接口程序和磁带库支持程序等部分。其他60~70%的资金是用来采购磁带库设备以及一定数量的磁带。如果需要实现SAN架构下的LAN Free的数据备份,则还需要增加10万元左右的资金投入,用以搭建SAN的光纤交换部分。</p><p>这种解决方案不仅可以全面的实现混和系统平台的全自动化数据备份工作,支持各种大型数据库应用,实现7x24小时的不停机数据在线备份,而且可以实现不需要占用网络资源的LAN Free的数据备份。同时,在这样的解决方案中,数据的傻瓜化恢复功能已经不再重要,由于系统结构的复杂和数据关系的复杂,完全无需人工干预的傻瓜化智能灾难恢复往往会造成系统状态的不一致,从而丧失了数据恢复的意义。在这种级别的应用环境中,系统需要对数据恢复的方式和内容更加灵活的控制。系统应该可以提供选择性的恢复数据,以及指定时间的状态恢复。</p><p>这种级别的数据备份系统一般应用在大型的海量存储系统中。例如大型医院信息系统。这些系统基本上完全排除了系统故障,极高的要求业务系统的连续性、稳定性和可用性,完全不允许任何情况下的计划内和计划外停机。对备份任务对系统资源的占用一般也有严格而明确的限制,一般不允许备份数据流大量占用网络带宽资源。总之,在这一应用层次上,备份系统已经被作为一个独立的系统来看待,备份工作已经是整个系统正常运行不可缺少的一个组成部分。所谓的高端备份市场就是指这一领域的市场需求。</p><p>总结:大型网络备份;Unix或多种*作系统平台;数据量达到TB级;需要长期保存数据;大型数据库应用;邮件系统等其他专业数据;完全无停机备份;灵活的恢复数据;不占用网络带宽资源。</p><p>100万元以上的投入</p><p>对于数据中心级的存储系统,数据备份系统的建设也大大增加。这主要源于两方面的原因:数据量的庞大和安全性要求的提高。事实上,在数据中心级的超大型存储系统中,对备份系统的功能要求,并不比前一个层次更多。但是其动辄数十甚至上百TB的数据量,却使磁带库设备的硬件成本翻倍的增加。另外,由于这些数据一旦丢失或损坏,后果将十分严重,所以其在线存储系统也大多采用了远程容灾等手段,这进一步增加了与之配合的备份系统的软硬件成本投入。一般一个配合远程容灾系统的数据备份系统,其投资额度都不会小于100万元。</p><p>在这种超大型的系统中,备份系统的软件投入比例一般为20~30%,而硬件投入占绝大部分,有70~80%之多。采购内容基本没有什么变化,软件部分基本还是备份服务器端、备份客户端、数据库接口模块、磁带库支持模块等部分,对容灾系统而言,有时候也会有特殊的在线存储设备接口模块。而对硬件设备部分,基本还是磁带库及其连接设备。当然,在如此大容量的环境中,采购磁带也是一笔不可忽视的资金投入。</p><p>有趣的是,在如此大资金的投入下,建成的数据备份系统,其真正面临系统故障的机会是少之又少。因为这种数据中心级的存储系统,其数据可用性要求已经达到了顶峰,所以在线存储系统大多采用目前最为稳定的产品,并配合最为先进的技术来保证数据不丢失。那么是不是说这样的备份系统就没有意义了呢?当然不是!事实上,在这种大型的数据中心里,备份系统的另一个意义凸现了出来,那就是文件的归档保存。我们知道在线存储系统的技术再先进,也只能保证当前的数据不丢失不损坏,而无法帮系统记录下从前的历史数据,而备份系统的功能正在于此。那些需要保留下来,以便进行统一分析的数据和状态,都完整的保留在备份系统中。<br /> </p><p><br /></p> |