
数据存储项目从需求到方案v30.ppt
81页© 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Technology for better business outcomes 数据存储项目从需求到方案提纲•典型企业应用架构•数据存储层的需求分析•数据访问层的需求分析•应用层的需求分析•案例分享13 八月 20242典型企业应用架构•存储层− 存储企业数据− 通常是数据库•数据访问层− 对存储设备的访问− 对数据的操作•应用层− 业务逻辑•展现层− 数据的展现13 八月 20243数据存储层需要考虑的问题•存储环境的选择•数据容量•数据安全性•数据扩展性•数据访问效率(性能要求)•数据生命周期的考虑13 八月 20244Q1: 客户存储环境?客户现有环境和计划采用的技术SAN 环境环境 (光纤光纤)• 存储区域网络• 高速光纤网络• 高效• 适合提供块数据服务• 造价相对较高NAS• 通过网络提供数据• 通常适合文件服务• 容易共享 • 造价低• 受NAS服务器限制 iSCSI – IP SAN• SCSI over IP• 网络上提供数据块服务• 无需专用存储网络• 造价较低• 网络协议导致了性能相对FC SAN较低DAS• 直接连接服务设备• 连接方式多样 • 数据无法共享• 维护成本高 13 八月 20245Q2: 客户数据容量?现有数据容量和发展需求MSA系列出众的出众的TCO < 324 TB•存储整合 + 灾难恢复•通过虚拟化实现简易性•Windows、HP-UX、Linux以及其它实时可用实时可用 < 851 TB•数据中心整合 + 灾难恢复•大规模Oracle/SAP应用•HP-UX、Windows、以及其它20多种,包括mainframe 低成本整合低成本整合< 60 TB•WEB、Exchange、SQL •简单的DAS到SAN (ProLiant)•Windows、Linux、Netware可扩展性 总计吞吐量 EVA系列EVA4400EVA6400EVA8400XP 系列MSA30/50/60/70/20001 - 5T5 - 50T> 50T13 八月 20246Q3: Q3: 数据保护数据保护软件故障14%病毒7%自然故障3%硬件或系统故障44%人为错误32%•用户删除文件•格式化硬驱动器•PC 黑客•硬件、驱动器和 RAID 控制器故障.•操作系统死机.•火灾•地震•洪水•数据损坏来源:Understanding Data Loss. CBL Data Recovery Technologies Inc. Industry 资料来源 – Data Recovery Report5 – 4为什么需要数据保护?为什么需要数据保护?13 八月 20247Q3: 数据安全的保证一份数据还是两份?单存储?•即时数据拷贝保证数据安全−备份、对应用无影响−数据丢失可及时恢复•拷贝的数据可以用于−数据挖掘•改善业务流程•提高客户的业务能力−提供针对Oracle, Exchange和SAP系统特点的数据快照保护13 八月 20248Q3: 数据安全的保证一份数据还是两份?双存储?•持续数据保护•基于操作系统•简单易用•没有停机时间•费用较高•不能完成容灾mirroring13 八月 20249备份及其误区备份及其误区• •误区之一:用拷贝替代备份误区之一:用拷贝替代备份• •误区之二:用双机,磁盘阵列误区之二:用双机,磁盘阵列/ /镜像等系统冗余替代数据备份镜像等系统冗余替代数据备份l系统冗余保证了进程的连续性和系统的高可用性。
l系统冗余不能替代数据备份•人为错误,恶意破坏•病毒•断电•天灾人祸l数据的备份才能保证数据万无一失• •误区之三:只备份数据文件误区之三:只备份数据文件−恢复时要重新安装操作系统−恢复时要重新安装所有的应用程序−需要相当长的时间才能恢复所有的数据13 八月 202410LTO ULTRIUM•适用于寻求最佳性能、可靠性和投资保护的客户•网络备份和异构环境的理想之选•可选择高性能、全高磁带机或者经济的半高磁带机DAT/DDS•经济、可靠的解决方案•非常适用于工作站和小型服务器•提供热插拔型号•最低的介质价格可带来极低的拥有成本*上述所列容量为磁带机自身具备的容量Q4: 数据安全 – 备份磁带机 Tape Driver工作组级办公服务器部门/本地网络企业/网络备份DAT 4020 GB入门级入门级高端高端(高性能、全高磁带机)(高性能、全高磁带机)中档中档(半高磁带机)(半高磁带机)36 GBDAT 72Ultrium 460200 GBUltrium 960400 GBUltrium 448200 GBUltrium 920400 GBUltrium 1840800 GBDAT 16080GBUltrium 1760800 GB• 数据备份• 快速恢复 – 单键快速自动恢复 OBDR13 八月 202411MSL 系列•简单、低成本•适用于少量的服务器和小型网络环境•DAS 和 LAN 备份•易于管理, 灵活, 可靠•适用于中、大型业务环境•DAS, LAN, 入门级 SAN 备份•强大的扩展能力和高性能 •适用于企业级的数据中心 •大型的SAN环境性能容量中级入门级企业级ESL E- 系列AutoloadersEML E-系列•高扩展, 易于管理, 高度可靠•适用于中、大型的数据中心•中到大型的 SAN环境HP Restricted – For HP Partner & Internal Use OnlyQ5: 数据安全 – 备份磁带库 Tape Library• 集中备份• 自动备份与恢复13 八月 202412磁带的优势•大容量:1盘介质上可存储高达 800GB 的数据•小尺寸:所有这些容量都可存储在1盘小巧的数据磁带上•可移动性:介质可以与设备分离,提供额外的病毒保护•便携性:介质可以在现场之外存储,提供额外保护•长寿命:适合长期存储(至少10 – 15年)13 八月 202413磁带备份系统的问题问题当前的应对措施惠普虚拟磁带库系统解决问题的方法无法满足备份时间要求•听之任之,孤注一掷 •被迫在性能较低的情况下完成备份任务•硬着头皮向管理层提交备份故障报告•提升备份性能•提高备份流程可靠性恢复速度慢•专门投入存储管理资源 •迁就于低下的生产效率•减轻存储管理员和服务台工作人员的工作负担•提高相关人员的工作效率介质利用效率低下•购买更多的介质•支付更多的异地服务费用•减少磁带拷贝的数量•提高介质利用率解决方案无法满足需求(例如容量太低,不支持新应用)•淘汰和更换解决方案•针对主要问题部署专用解决方案•独立扩展容量和吞吐量•几乎支持所有的备份应用•采用重复数据删除技术和自动迁移技术14磁盘备份?磁带备份?•现在,市场上有两种备份方式可供您选择...13 八月 2024151613 八月 2024D2D100系列VLS6000系列D2D2500系列D2D4000系列VLS9000VLS12000EVA网关新新入门级中高端企业级•简单经济•小型企业•iSCSI•入门级机架•更小的IT环境或远程站点•iSCSI•更高容量的解决方案•具有小型数据中心的中型企业•iSCSI和FC•单节点系统•中型和企业级数据中心•大中型FC SAN•多节点系统•高性能和可扩展性•企业数据中心•大型FC SAN具备快速重复数据删除功能(Accelerated deduplication)具备重复数据删除功能数据安全 – 备份磁盘备份 – 虚拟磁带库VTL• 集中、自动备份与恢复• 快速自动备份与恢复• 提高介质利用率13 八月 202416•手动备份与恢复− 人员操作− 容易出错,恢复复杂− 成本高•集中自动备份与恢复− 自动运行− 无需或者很少人员的参与− 更容易的恢复数据安全 – 备份手段自动方式?手动备份?13 八月 202417Q6: 数据安全容灾需求?•多存储备份与恢复 −Storage Mirroring•磁盘阵列级多存储备份与恢复 - CA13 八月 202418容灾!容灾!容灾!如何选择合适的数据保护战略?•两个主要的衡量指标:−恢复时间目标(恢复时间目标(RTO))•业务流程能够承受多长的停机时间?•一天? 一个小时? 一刻都无法承受?−恢复点目标(恢复点目标(RPO))•企业可承受多少数据丢失?•一天的数据? 一个小时的数据? 不能丢失任何数据? 磁带和自动化处理虚拟磁带库基于磁盘复制连续保护数据 年 天 小时 分钟 秒 秒 分钟 小时 天恢复点(Recover Point Objective)恢复时间(Recovery Time Objective)保护方法磁带备份 写入时捕获 保险库综合备份 磁带备份 存档 快照 实时复制 镜像实时恢复 磁盘存储 磁带存储卷备份 时间点 搜索/检索恢复方法13 八月 20241920•2013 八月 2024多主机级多存储备份与恢复Storage Mirroring•持续的数据保护要求•快速数据备份,字节数据复制,秒级内•快速数据恢复,分钟级内•从SMB 到Enterprise•软件支持,价格较低•较低的网络配置也能满足13 八月 202420磁盘阵列级多存储备份与恢复CA容灾 - “抗地震”的应用系统高可用性方案•数据的连续拷贝•硬件级别的操作•对系统性能无影响•保证业务数据安全•在灾难发生时,保持业务运行•应用与数据容灾的配合13 八月 202421Q7:数据扩展性•如何扩展容量考虑的问题−是否考虑停机?−重构还是自动扩展?−一次采购还是逐渐升级•目标−应用不停机,容量自动增长−磁盘卷不用重构,容量自动扩展−减少初期投入,随业务稳步增长13 八月 202422Q8: 数据访问效率•阵列的选择− 并发用户数的考虑− 数据量的大小− 平均访问时间•磁盘的选择?−FC/FATA/SATA/SSD•如何利用所有磁盘的性能•不同类型的硬盘其性能差异很大,根据性能、容量、价格来进行衡量•同类型的硬盘选择指导:在满足相同存储容量要求下,尽量选择大容量低转速的硬盘,降低采购成本。
13 八月 202423固态硬盘SSD与光纤硬盘的对比 13 八月 202424近线FATA磁盘 不常访问的数据、快速恢复、备份到磁盘…FC磁盘 活动数据、本地和远程镜像、即时恢复…数据生命周期 – 分层存储固态硬盘 - SSD IO密集型应用…13 八月 202425数据访问层的需求•数据访问模式•数据访问安全•系统可靠性要求•系统性能需求•系统备份与恢复•资源共享13 八月 202426Q9: 数据访问模式•数据库−Oracle、SQL Server、DB2、Sybase、…•文件服务−NFS、CIFS−NAS13 八月 202427Q10: 数据安全访问•提供高可用,多节点的访问−如Oracle RAC,可以选择ServiceGuard+ServiceGuard extension for RAC•双机Standby−互备模式•应用容灾(涉及流程、切换、演练、人员等)13 八月 202428Q11:系统可靠性需求•非计划宕机时间•防病毒与安全•内部安全机制13 八月 202429小机?PC服务器?Æ安全性更高,PC Server上的OS安全性相对较低,而且病毒、bug等更严重Æ扩展性更高,如果业务增长较快必须移植到小型机Æ稳定性更高,小型机99.999%,而PC Server一般99.99%,停机时间分别为5分钟和52分钟Æ可靠性更高Æ硬件上更多的可靠性技术(如zx2的双芯片备件、IO故障隔离、CPU故障隔离)Æ集群技术更成熟13 八月 202430Q12: 系统性能需求•性能考虑指标− 并发用户数− 平均响应时间− 业务复杂程度•一般情况下,一个CPU Core支持20-50并发用户数•小型机下:CPU Core/Memory = 1:2 或者1:4•PC机下:CPU Core/Memory = 1:1 或者 1:213 八月 202431Q13: 烟囱式?融合式?•单一应用/多个应用•能利用应用峰值的错峰特性?•充分利用虚拟化技术实现资源的共享−硬件分区、软件分区、虚拟机、资源动态调度技术−虚拟连接VC、刀片技术13 八月 202432应用层的需求•中间件选择(应用架构)•应用访问安全•系统可靠性•系统性能需求•系统备份与恢复•资源共享13 八月 202433中间件选择•C/S 架构−无中间件平台•多层架构−J2EE架构,如WebLogic,WebSphere,JBoss−.NET架构−Transaction,如TUXEDO、CICS−需要有中间件服务器支撑13 八月 202434应用访问安全•应用服务器Cluster−应用服务器本身就有集群的能力,如WebLogic、WebSpere、JBoss等−有别于数据库中的HA和Standby13 八月 202435系统性能需求•根据系统的并发用户数来选择服务器•一般情况下,一个CPU Core支持50-100并发用户数•小型机下:CPU Core/Memory = 1:2 或者1:4•PC机下:CPU Core/Memory = 1:1 或者 1:213 八月 202436案例分享•某省社保案例•医疗信息系统案例13 八月 202437案例1 – 社保案例社保IT部门面临挑战•业务复杂、影响面广−养老、医疗、失业、工伤、生育•政策、流程变更频繁•参保机构/人员增加,系统不能满足业务需要−白天,参保机构办理停保、续保业务多,应用服务器很忙,客户等待时间很长。
晚上较闲)−晚上,批量处理参保机构信息,数据库服务器忙,有时在第二天上班前不能处理完毕白天较闲)•信息化建设正兴起,系统维护力量相对薄弱13 八月 202438案例1 – 社保案例了解客户需求•Q1: 客户存储环境?客户现有环境和计划采用的技术•结合用户现有技术环境,选择合适的存储环境− 客户对性能要求较高− 客户现有SAN 存储环境•A1: FC SAN39案例1 – 社保案例了解客户需求•Q2: 客户数据容量?现有数据容量和发展需求− 800万参保用户、48万参保单位为例− 保留五年的数据在一级存储− 存储需求30TB− 数据冗余, RAID 5− 阵列裸容量 50TB− 随着农村医疗和区域医疗的加入,数据还会增加•A2: 需要50TB存储容量,并提供容量增加的能力40案例1 – 社保案例了解客户需求•Q3: 数据安全的保证一份数据还是两份?单存储?−数据量大,难以保存两份数据−内置RAID技术可以满足数据的安全需求−需要存储阵列提供企业级的安全级别,99.999%−在第一期不考虑容灾的问题•A3: 企业级存储的内置RAID实现数据安全保护41案例1 – 社保案例了解客户需求•Q3: 数据安全的保证一份数据还是两份?双存储?− 利用企业存储阵列的RAID技术− 不使用两份或者双存储− 双存储的容灾解决方案将在后期考虑•A3: 企业级磁盘阵列42案例1 – 社保案例了解客户需求•Q4: 数据安全 – 备份磁带机 Tape Driver− 数据需要备份,以保证数据的安全− 需要利用磁带来保证具有数据的多个版本− 除了数据之外,主机的操作环境也需要备份− 全备份数据量 ~30TB− 日增加数据量 ~15GB•磁带机只能用于主机系统的数据备份,不能用于数据43案例1 – 社保案例了解客户需求•Q5: 数据安全 – 备份磁带库 Tape Library− 数据容量30TB− 每月完全备份一次 ~30TB− 每天增量备份 ~16GB− 多个备份任务要同时进行Q5: 磁带库容量一般按照数据容量的3倍进行选择,因此磁带库容量需要100TB,4-6个并发支持44案例1 – 社保案例了解客户需求•Q5:数据安全 – 备份磁盘备份 – 虚拟磁带库VTL− 备份时间窗口需求• 全备份不超过8小时• 增量备份1小时内完成• 系统数据恢复时间不能超过12小时•A5: 需要利用虚拟磁带库。
45案例1 – 社保案例了解客户需求•Q5:数据安全 – 备份手段自动方式?手动备份?− 自动完成备份− 无需人工干预− 出错报警技术,SMS, Email ……− 支持全备份与增量备份•自动的,全备份与增量备份软件46案例1 – 社保案例了解客户需求•Q6: 数据安全容灾需求?−本期不考虑容灾需求•A6: 暂不考虑,但存储和主机应该支持数据和应用的容灾47案例1 – 社保案例了解客户需求•Q7:数据扩展性− 现有容量20TB− 3年内增加到30TB− 如果政策改变,可能会涨到50TB•A7: 存储必须快速实现容量的增加,不能影响业务的连续运行48案例1 – 社保案例了解客户需求•Q8: 数据访问效率•75%的查询,25%对数据修改•平均操作响应时间不能超过5秒•~100个用户会对数据库访问•晚上数据的报表需要较多的计算资源•A8: 必须采用FC磁盘才能满足客户的高效能需求49案例1 – 社保案例了解客户需求•Q9: 数据访问模式−根据社保核心平台,J2EE环境−采用Oracle + Weblogic架构−采用Oracle RAC实现并行处理•本案例采用了Oracle数据库,利用Oracle RAC提供多节点访问和高性能50案例1 – 社保案例了解客户需求•Q10: 数据安全访问−Oracle RAC−WebLogic Cluster•HA方案51案例1 – 社保案例了解客户需求•Q11:系统可靠性需求− 系统需要连续不断运行− 必须对病毒免疫− 必须支持大规模高并发− 必须支持超过500个并发的用户数量•采用小型机,Unix52案例1 – 社保案例了解客户需求•Q12: 系统性能需求− 必须支持多达30TB的数据访问− 必须支持高达500的并发用户− 必须采用HA的方式− 系统平均响应时间小于5秒− 报表时间必须小于8小时A12: 高性能多CPU小型机53案例1 – 社保案例了解客户需求•Q13: 烟囱式?融合式?− 业务平台和报表平台共享数据库− 业务平台白天比较忙,而报表相反− 希望能利用峰值差在不同系统之间调度计算资源•Q13: 动态资源调度技术54客户需求Summary•从前面了解的需求,总结客户的需求如下:−性能要求较高、现有SAN环境−数据量大,现有数据20TB,3年内达到30TB,还会增加−数据不能丢失,系统可靠性99.999%−主机系统数据安全备份−用户数据备份,每月全备份一次30TB、每日增量备份15GB、全备份时间不能超过8小时、增量备份不超过1小时、数据恢复时间不超过12小时、要求自动、集中备份−数据库采用Oracle RAC、应用服务器采用WebLogic Cluster,要求支持500以上并发用户、平均响应时间不超过5秒、报表时间不超过8小时−白天应用系统忙、晚上数据库有大量的批量作业要进行处理,如报表、批量数据处理业务55HP建议硬件设备•根据用户的需求,建议的HP硬件配置方案:−存储阵列:EVA 8400−SAN交换机:8/16 SAN Switch−数据库服务器:SuperDome、HP-UX、ServiceGuard、ServiceGuard extension for RAC、1个nPar、2个vPar−应用服务器:SuperDome、HP-UX、1个nPar、2个vPar−虚拟带库:VLS9000−磁带库:245e−备份软件:DP−备份管理服务器:DL380−存储管理服务器:DL38056案例1 – 社保案例社保解决方案应用系统架构13 八月 202457集群集群案例1 – 社保案例社保总体架构社保数据库服务器RAC1SD 12*1.6GHz/32GB社保数据库服务器RAC2SD 12*1.6GHz/32GB存储管理服务器FC Switch 8/16MC/Service Guard Extension for RAC备份服务器磁带库245e数据离线备份EVA8400社保应用服务器SD 4*1.6GHz/8GB社保应用服务器SD 4*1.6GHz/8GBVLS900058案例1 – 社保案例产品配置需求清单•存储产品型号和配置需求清单−型号、台数、硬盘个数(按照转速)、软件LTU、服务级别•光纤交换机型号和配置需求清单−型号、台数、端口数LTU、SFP数量、光纤线长度与数量、高级软件LTU、服务级别•数据库服务器产品型号和配置需求清单−产品型号、台数、CPU个数、内存大小、内置硬盘个数与容量、网卡个数、FC卡个数、操作系统、磁带机、服务级别•应用服务器产品型号和配置需求清单−产品型号、台数、CPU个数、内存大小、内置硬盘个数与容量、网卡个数、操作系统、磁带机、服务级别•磁带库产品型号和配置需求清单−产品型号、台数、Driver数量、磁带容量和盘数、清洗带数量、磁带标签、服务级别•备份软件 DP和配置清单−SAN Backup、Online Backup、槽位数扩展、Driver数扩展•管理服务型号和配置清单(PC Server)596013 八月 2024案例2 – 医疗信息系统案例业务需求•业务集中−早上8~10点,下午13:30~15点,是医院看病的业务高峰期•安全性要求高−系统不能遭受病毒、安全漏洞攻击−数据不能丢失•系统要求稳定,不能宕机•系统扩展能力−业务发展快•系统易管理−要求降低运营成本60案例2 –医疗信息系统案例了解客户需求•Q1: 客户存储环境?客户现有环境和计划采用的技术•结合用户现有技术环境,选择合适的存储环境− 客户对性能要求较高− 客户现有SAN 存储环境•A1: FC SAN61案例2 –医疗信息系统案例了解客户需求•Q2: 客户数据容量?现有数据容量和发展需求− 每日门诊量5000人左右,住院床位数1000张左右− 保留五年的数据在一级存储− 存储需求3TB− 数据冗余, RAID 5− 阵列裸容量 5TB− 随着PACS、EMR的加入,数据还会增加•A2: 需要5TB存储容量,并提供容量增加的能力62案例2 –医疗信息系统案例了解客户需求•Q3: 数据安全的保证一份数据还是两份?单存储?−数据量大,难以保存两份数据−内置RAID技术可以满足数据的安全需求−需要存储阵列提供企业级的安全级别,99.999%−在第一期不考虑容灾的问题•A3: 企业级存储的内置RAID实现数据安全保护63案例2 –医疗信息系统案例了解客户需求•Q3: 数据安全的保证一份数据还是两份?双存储?− 利用企业存储阵列的RAID技术− 不使用两份或者双存储− 双存储的容灾解决方案将在后期考虑•A3: 企业级磁盘阵列64案例2 –医疗信息系统案例了解客户需求•Q4: 数据安全 – 备份磁带机 Tape Driver− 数据需要备份,以保证数据的安全− 需要利用磁带来保证具有数据的多个版本− 除了数据之外,主机的操作环境也需要备份− 全备份数据量 ~5TB− 日增加数据量 ~1GB•磁带机只能用于主机系统的数据备份,不能用于数据65案例2 –医疗信息系统案例了解客户需求•Q5: 数据安全 – 备份磁带库 Tape Library− 数据容量3TB− 每月完全备份一次 ~3TB− 每天增量备份 ~1GB− 并发性要求不是很高Q5: 磁带库容量一般按照数据容量的3倍进行选择,因此磁带库容量需要10TB,1-2个并发支持66案例2 –医疗信息系统案例了解客户需求•Q5:数据安全 – 备份磁盘备份 – 虚拟磁带库VTL− 备份时间窗口需求• 全备份不超过8小时• 增量备份1小时内完成• 系统数据恢复时间不能超过12小时•日增数据量1GB•A5: 不需要利用虚拟磁带库。
67案例2 –医疗信息系统案例了解客户需求•Q5:数据安全 – 备份手段自动方式?手动备份?− 自动完成备份− 无需人工干预− 出错报警技术,SMS, Email ……− 支持全备份与增量备份•自动的,全备份与增量备份软件68案例2 –医疗信息系统案例了解客户需求•Q6: 数据安全容灾需求?−本期不考虑容灾需求•A6: 暂不考虑,但存储和主机应该支持数据和应用的容灾69案例2 –医疗信息系统案例了解客户需求•Q7:数据扩展性− 现有容量2TB− 3年内增加到3TB− 如果有PACS系统的整合或者EMR系统的需求,可能会涨到10TB以上•A7: 存储必须快速实现容量的增加,不能影响业务的连续运行70案例2 –医疗信息系统案例了解客户需求•Q8: 数据访问效率•50%的查询,50%对数据修改•平均操作响应时间不能超过5秒•~100个用户会对数据库访问•存在业务高峰期的问题,早上8:00-10:00,下午13:30-15:00业务集中•A8: 必须采用FC磁盘才能满足客户的高效能需求71案例2 –医疗信息系统案例了解客户需求•Q9: 数据访问模式−根据HIS平台,C/S环境−采用SQL Server架构−采用SQL Server实现双机Standby•本案例采用了SQL Server数据库,利用SQL Server双机互备提供高可用性72案例2 –医疗信息系统案例了解客户需求•Q10: 数据安全访问−SQL Server•双机Standby方案73案例2 –医疗信息系统案例了解客户需求•Q11:系统可靠性需求− 系统需要连续不断运行− 必须对病毒免疫− 必须支持较大用户并发− 必须支持超过100个并发的用户数量− 管理简便•采用小型机,Windows74案例2 –医疗信息系统案例了解客户需求•Q12: 系统性能需求− 必须支持多达3TB的数据访问− 必须支持高达100的并发用户− 系统平均响应时间小于5秒− 存在业务高峰期的突发需求A12: 高性能多CPU小型机75案例2 –医疗信息系统案例了解客户需求•Q13: 烟囱式?融合式?− 目前业务平台单一− 业务未融合,资源要求简单− 仅数据库需求•Q13: 主机不采用资源共享模式,存储采用共享模式,进行存储集中76客户需求Summary•从前面了解的需求,总结客户的需求如下:−性能要求较高、现有SAN环境−数据量较大,现有数据2TB,3年内达到3TB,还会增加−数据不能丢失,系统可靠性99.999%−主机系统数据安全备份−用户数据备份,每月全备份一次3TB、每日增量备份1GB、全备份时间不能超过8小时、增量备份不超过1小时、数据恢复时间不超过12小时、要求自动、集中备份−数据库采用SQL Server,双机互备模式,要求支持100以上并发用户、平均响应时间不超过5秒、能够支持高峰突发性业务−现有IT管理力量薄弱,要求管理简便,防病毒,安全性高,系统可靠。
77HP建议硬件设备•根据用户的需求,建议的HP硬件配置方案:−存储阵列:EVA4400−SAN交换机:8/8 SAN Switch−数据库服务器:Rx6600、Windows−磁带库:MSL2024−备份软件:DP−备份管理服务器:DL38078Standby案例2 – 医疗信息系统案例系统架构SQL ServerDB1SQL ServerDB2HIS数据库服务器RX66004*1.6GHz/16GBHIS数据库服务器RX66002*1.6GHz/8GB备份服务器DL380EVA4400300GB*12FC Switch 8/8MSCSMSL202479总结•了解真正的用户需求•熟悉HP解决方案的特点•选择合适的HP解决方案•解决用户的问题80Q & A。












