杭州师范大学附属医院HIS系统虚拟化
杭州师范大学附属医院HIS系统虚拟化,背景介绍,医院概况,杭州师范大学附属医院（杭州市第二人民医院），创建于1949年，现已成为一所融医疗、教学、科研、预防保健为一体的浙江省三级甲等综合医院, 开放床位已达1500张。随着随着信息化应用水平不断提升，数字化医院建设的步伐加快，目前终端数量达到1000台以上，承载HIS、LIS、 PACS、电子病历、协同办公等应用系统的服务器数量达到数十台。,CONFIDENTIAL,3,原有架构,CONFIDENTIAL,4,杭州师范大学附属医院现有HIS系统承建于2008年 应用： 联众HIS，C/S架构 服务器： HP RX6600 操作系统： HP-UX 11 数据库： Oracle 10.2 双节点RAC,应对高峰时段负载时，核心HIS业务系统出现性能瓶颈,面临挑战,CONFIDENTIAL,5,原有硬件系统发生过系统宕机严重事故，可靠性难以满足业务需求,杭州师范大学附属医院希望能借助虚拟化平台的技术特点和优势，建设能实现随业务需求灵活扩展、提供高安全可靠性的关键业务系统支撑平台，承载HIS/EMR/PACS等基于ORACLE RAC的核心应用。,虚拟化测试,测试目标,对杭州师范大学附属医院HIS系统进行虚拟化测试，搭建虚拟化平台上的 Oracle RAC 测试HIS系统在虚拟化平台上的性能 测试HIS系统在虚拟化平台上的灵活性和可靠性,CONFIDENTIAL,7,测试方法,性能测试 TPM/TPS 每分钟/每秒钟交易数 Response Time 平均相应时间（秒） 高可用性测试 计划停机 故障模拟 稳定性测试 4小时高压力拷机,CONFIDENTIAL,8,测试内容,性能测试 使用LoadRunner录制HIS应用脚本模拟并发用户运行 调整Oracle RAC node vm的vCPU，考查TPS和响应时间变化 高可用性测试 采用vMotion将一个Oracle RAC node vm在线迁移至另外一台主机上 设置vSphere HA，将一台主机重启，验证HA机制自动启动Oracle RAC node vm 稳定性 4小时高并发压力测试,CONFIDENTIAL,9,测试应用模块构成,CONFIDENTIAL,10,测试环境,硬件,CONFIDENTIAL,11,软件,测试环境架构图,CONFIDENTIAL,12,测试安排,时间进度 测试场地 杭师附院机房 人员分工,CONFIDENTIAL,13,性能测试-方案,测试用途 验证虚拟化平台上的系统性能表现和系统扩展性 测试步骤 保持2000connection(正常一个用户产生2个connection，所以是1000左右的用户)的模拟背景压力负载 Oracle RAC node vm配置为16 vCPU(2*CPU)，进行25/50/75/100/150并发用户压力测试，观察TPS、响应时间和负载率 Oracle RAC node vm配置为32 vCPU(4*CPU)，进行50/75/100/150并发用户压力测试，观察TPS、响应时间和负载率,CONFIDENTIAL,14,性能测试-结果,CONFIDENTIAL,15,性能测试-结果,CONFIDENTIAL,16,性能测试-结果,CONFIDENTIAL,17,性能测试-结果,CONFIDENTIAL,18,性能测试-小结,CONFIDENTIAL,19,系统响应时间完全在符合业务要求的范围内 随着Oracle RAC node vm配置提升(处理能力增强)，系统TPS随之增大，具有纵向扩展性,高可用测试-Oracle RAC node vm vMotion,测试用途 检验Oracle RAC node vm主机间在线切换对业务的影响 测试步骤 压力生成器生成压力，并同时tnsping his1 在vCenter Server中将数据库节点his1从主机ESX01上迁移至ESX03上，考查业务影响 测试结果 32vPCU 的 vMotion 测试，75U并发用户压力下，数据库RAC节点1服务延时24秒 测试小结 虚拟机可以在主机间在线切换，无需停机，业务不停顿，延时5秒钟,CONFIDENTIAL,20,高可用测试-Oracle RAC node vm vMotion,CONFIDENTIAL,21,从ESX01上迁移至ESX03，期间切换导致tnsping延时24秒，TPS降低，但业务不停顿,高可用测试-Oracle RAC node主机故障HA,测试用途 检验主机发生故障后，虚拟机在其他主机上重启，快速恢复 测试步骤 在压力生成器上运行tnsping his1 在vCenter Server中，将数据库节点his1所在主机ESX01重新启动，考查数据库恢复耗时 测试结果 主机ESX01模拟故障后，his1在主机ESX03上重新启动，数据库自动修复后，恢复服务 测试小结 当主机故障时，虚拟机自动在其他主机上重启，数据库恢复，总计耗时214秒，高可用性得到保障,CONFIDENTIAL,22,高可用测试-Oracle RAC node主机故障HA,CONFIDENTIAL,23,主机ESX01模拟故障，整个系统理能力下降，但是业务不停顿,稳定性测试,测试用途 检验主机高负荷压力下的稳定性 测试结果 4小时高压力拷机，系统未出现故障及交易失败现象,CONFIDENTIAL,24,16vCPU（2路CPU）的情形下，系统可以支撑100U并发，已经高于现有系统高峰的处理能力（75U）,测试总结,CONFIDENTIAL,25,虚拟机可以在主机间在线切换，无需停机，业务影响极小 当主机故障时，虚拟机可以自动在其他主机上重启，自动修复数据库，高可用性得到保障 经过高压力拷机，系统未出现故障及交易失败现象,生产部署,系统上线,生产部署 测试完成后用户和联众都很满意结果，在进行相关数据准备工作后，按测试架构重新搭建环境并按32 vCPU配置3节点的Oracle RAC node vm，导入HIS系统生产数据，直接切割到生产环境，到目前已经稳定运行快1个月，同时系统各项性能指标令用户和联众都很满意，计划逐步把EMR/PACS等其它的核心业务系统都迁移到该虚拟化平台上来 虽然测试数据令用户和联众满意，但在生产环境部署时还是过于保守 以2 production + 1 standby的传统物理运维模式部署Oracle RAC集群，不能充分发挥虚拟化平台的高可用性特点 32 vCPU的过高配置使系统的纵向扩展性受到限制，同时存在很大的资源浪费 优化 通过部署vCOps，让客户直观看到在系统各项性能指标完全满足要求而整个虚拟化资源的利用率非常低，认识到16 vCPU的RAC配置在满足目前高峰需求之外还有充足预留资源，同意虚拟待系统再稳定运行足够时间后和联众配合降低配置,CONFIDENTIAL,27,生产环境vCOps截图,CONFIDENTIAL,28,
