• 1. RSS-1 for GD CCB 测试成果汇报
  • 2. 2AgendaCCB RSS-1 后续工作建议4CCB RSS-1 测试结论3CCB RSS-1 测试过程2CCB RSS-1测试简介1
  • 3. 3CCB RSS-1 测试目的验证RSS-1存储优化解决方案中GD CCB客户关心的特定功能点。 通过对磁盘阵列的性能实时监控和容量实时监控,有效提高监控能力。 通过RSS-1 监控和分析,对数据库表空间如何重构提供依据,实现数据库表空间的物理部署能够得到有效合理的部署。 在持续性业务压力和间歇性业务压力的情况下,能够提供正确的存储正确分级依据,同时根据实际应用需求通过升级和降级实现存储正确分级,从而提高存储和业务性能。 通过RSS-1实现存储升级和降级数据迁移部署过程中,业务逻辑不受任何的影响。 通过RSS-1能够有效的改善存储设备整体利用率低下和使用欠均衡导致设备性能和贡献度差的情况,并对容量管理的分析工作提供一些依据。 通过RSS-1降低存储平台复杂带来的管理和支持难度。 通过本次RSS-1存储优化解决方案验证,为未来GD CCB部署RSS-1提供有效的测试案例及依据。
  • 4. 4RSS 测试结果测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性) 通 过通 过通 过通 过通 过通 过成 功
  • 5. 5CCB RSS-1 测试功能项 目现有环境缺陷RSS-1优势基于分级存储的性能改善预规划的存储性能可能无法不满足业务需求。可通过SVC+STAR将Lun Up-Tier到更高级存储上。缺少分级存储管理的方法和性能依据。STAR能通过负载性能数据提供分级存储管理建议。基于分级存储的空间利用率改善预规划的存储性能可能超过业务需求,造成高端存储浪费。可通过SVC+STAR将Lun Down-Tier到更中低端存储上。缺少分级存储管理的方法和性能依据。STAR能通过负载性能数据提供分级存储管理建议。精简配置大多数中低端存储不支持精简配置。通过SVC虚拟化管理将精简配置功能使用到所有的异构存储环境中。存储子系统实时监控 TPC和ECC分别监控自己厂商的存储阵列,无法对异构存储进行监控。所有后端存储由SVC统一管理进行虚拟化,TPC通过SVC直接对后端存储MDG进行性能监控无法结合磁盘状况分析存储后端负载。STAR结合磁盘数量,转数等因子通过模型演算有效分析负载。区分高峰压力是持续性还是间歇性存在困难。通过STAR可以快速判断高峰期压力是间歇性还是持续性,是否适合迁移。存储资源迁移无法在不同后端存储子系统间业务不中断地在线迁移。通过SVC可以实现Lun在后台不同存储子系统间业务不中断地在线迁移。异构存储平台的管理和支持复杂度不同存储子系统需要不同的多路径软件。通过SVC虚拟化管理,主机端采用单一多路径软件,不同Tier存储之间资源可以在主机上共存。对于不同存储子系统需要应用不同的管理软件。SVC统一规划,简化划盘流程。无法在不同存储子系统之间进行耦合,比如迁移,灾备,高可用,等通过SVC不同异构存储之间可以轻松进行耦合。
  • 6. 6AgendaCCB RSS-1 后续工作建议4CCB RSS-1 测试结论3CCB RSS-1 测试过程2CCB RSS-1测试简介1
  • 7. 7RSS-1 测试环境CCB 测试环境
  • 8. 测试环境介绍-参与设备 虚拟化产品:厂家产品Node数量版本IBMSAN Volume Controller4 5.1.0.3底层存储:厂家产品空间大小Disk/ RPMEMCSymmtrix 88301.2TB73G/ 10000rpmIBMDS48008.3TB146G/10000rpmIBMDS510010TB1024G/7200rpmSAN交换机:厂家产品数量备注EMC B16 (即Brocade 3800交换机)2台SAN环境采用星型连接方式,边缘交换机接入核心交换机,SVC接入核心交换机主机接入边缘交换机Brocade41002台Brocade38502台测试的服务器和 操作系统平台: 厂家产品OS平台CPUMemoryHBA卡IBMP670AIX5.3816G2IBMHS21Vmware-Windows12G 2IBMHS21Vmware-Linux12G数据库: 厂家版本RACOracle10g否
  • 9. 9SVC CCB IT环境中的RSS-1环境STAR虚拟磁盘(VDisks)P670性能实时监测 容量实时监控 热点和冷点实时监控 每日存储升级建议 每日存储降级建议 周期性的无影响的数据迁移T1T2T3RSS-1 测试环境架构TPCSymmetric 8830 1.2TB FC 10k RPMDS4800 8.3TB FC 10k RPMDS5100 10TB SATA 7.2k RPM搭建Oracle数据库环境,通过数据库脚本 实现加载存储负载
  • 10. 10详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 11. 11AgendaCCB RSS-1 后续工作建议4CCB RSS-1 测试结论3CCB RSS-1 测试过程2CCB RSS-1测试简介1
  • 12. 12RSS-1测试分类总结Up-Tierng 和 Down-Tiering : 数据迁移不影响业务逻辑。 迁移过后,得到up-tiering的Lun性能有显著提高,平均 IOPS处理能力最高上升30%,平均响应时间最高下降25%。 迁移过后,通过down-tiring,MDG的空间得到更有效的利用,Tier 1存储有了更多空余空间,Tier 3存储空间得到更多利用。 通过STAR的“Time XX exceeds 80% of Actual”属性能判断业务高峰期是持续性还是并发性,从而更有效的做出迁移决策。 迁移过程中对性能有一定影响,在主机方面检测,高峰期IOPS最多下降30%。一个半小时,迁移数据一共1200G。TPC对SVC probe期间对性能也有一定影响。
  • 13. 13RSS-1测试分类总结 (Cont.)LUN Activity Listing : 能够清晰的监控到Vdisk的读和写IOPS情况。 Fast Storage Provisioning : 通过准确快速的定位正确的MDG,实现快速配置存储。 能够快速分析MDG中的Vdisk的IOPS性能,为快速配置存储提供有效依据。 Thin Provisioning : 对于顺序写操作,例如VMWare的镜像克隆, 性能方面在SE VDisk和Regular VDisk是一样 的。(从测试上看,SE性能甚至更好)
  • 14. 测试1&2测试用例结果Tier 3 DS5100 SATATier 2 DS4800Tier 1 SymmetricP670 Oracle负载负载负载Tier 3 DS5100 SATATier 2 DS4800Tier 1 SymmetricP670 Oracle负载负载负载经过RSS-1优化
  • 15. 15存储需求评估和规划存储配置迁移和退役Traditional (no RSS-1)RSS-1t1t2减少所需要的时间– 在线操作 更快更好地对业务提供支持 - 大幅的 提高生产力t1’- 简单的工程计划STARSTARt4’t3’- 在线迁移 - 在线退役STAR- 快速发现可用空间 - 自动化的增加存储t3 = 迁移 (服务中断) t4 = 退役- 存储分配- 存储工程计划 -平台预订 - 压力测试工作量评估t3t4t2’’Thin prov.Test 4Test 5Test 1Test 2RSS-1 POC测试– 证明 RSS-1 能够有效减少运维管理时间Not Covered in PoC
  • 16. 16 Savings Cost of acquisition Tier 1 Enterprise 100% Mid-Range FC Disks 50% SATA 25% Space Energy & Cooling Tier 1 Enterprise 100% Mid-Range FC Disks 50% SATA 10% Expenses Initial tiering planning efforts Cost of detecting re-tiering needs QoS crisis effort or, Tiering Surveillance Extent, LUN, Application, MDG Cost of planning re-tiering Which source? Which target? Cost of re-tiering Lun or App migrate RSS-1 Almost eliminated Highly automated Strongly minimized Automated MDG Almost nil LUN identification Strongly assisted Almost nil Online migration – 33GB LUN move in 2 minPrevious state of the art: Application tiering is based on initial tiering planning and QoS crisis RSS-1: Application right-tiering based on actual application behavior and infrastructure loadTest 1Test 2RSS-1 POC测试– 证明采用RSS-1方案可 减少成本和运维管理时间Not Covered in PoC
  • 17. 17AgendaCCB RSS-1 后续工作建议4CCB RSS-1 测试结论3CCB RSS-1 测试过程2CCB RSS-1测试简介1
  • 18. 18下一步工作建议测试环境RSS-1部署: 建议在东风测试环境部署RSS-1,实现测试环境动态监控和动态迁移,确保测试环境存储正确分级。 建议将SOP运维管理平台迁移部署在RSS-1环境中,实现部分生产环境的动态架构。 通过脚本提取STAR和TPC的监控数据,与SOP运维管理平台有效的结合联动起来。 资源正确分配研究: 通过资源正确分配咨询与实施项目,满足通过业务需求合理进行资源分配的要求。 通过资源分配公式或者可度量的工具实现。 Thin Provisioning 空间自动分配性能研究: 通过对SE DISK的测试证明在SE空间自动分配过程中对磁盘读写性能无影响 证明SE 空间自动扩展后可以立即使用 证明不会发生空间溢出的问题
  • 19. 19RSS-1 – 1st Instance is 东风测试SVCSTARDong Feng Dev/TestTPC SE1 x STAR 1 x TPC SE 1 x SSPC & DB2 db 2 x old Cisco directorsKey RSS-1 Considerations Build up confidence Correct any errors in design and deployment
  • 20. 20&ANSWERSQUESTIONS
  • 21. 一路走来……
  • 22. 22Backup
  • 23. Q: RSS-1能否帮助识别数据库识别表空间物理结构是否分配合理? A: 完全可以。 一般如果表空间物理结构分配不合理,从而发生热点盘和冷点盘的情况,这可以通过STAR可以有效地予以发现。如果发现此种情况,最常用的解决方案有两种:一种是通过SVC做动态的Lun迁移,将表空间的盘根据STAR分析结果走down-tiering或者up-tiering;另一种则通过数据库的分析将表空间的表分拆,将热点表移到其他的表空间中去。 Q: RSS-1是否能有效区分OLTP和OLAP的负载类型?并对此提供分级存储优化建议? A: 可以,并可在RSS-2中改进。 目前RSS-1虽然主要针对的是随机读写,即OLTP,进行分级存储管理,但是对于OLAP型负载,RSS-1可以通过一些间接指标,如IO 尺寸,来加以识别,并通过QoS检测来确认是否真正地发生了性能瓶颈,由此提供分级存储的优化建议。在RSS-2中,我们还可以结合各个存储子系统的独特的性能指标,如随机和顺序读写检测,cache算法特点等,对OLTP和OLAP加以区分,从而更好地进行分级存储优化。
  • 24. 24POC验证测试团队单位人员角色职责广东省建行黄华经理,项目经理存储蒋景辉经理,架构师存储南天朱敏健系统工程师存储高波Oracle DBA数据库IBM胡鸣云存储经理 柏青PM,架构师存储杨奕信息系统专家存储任鹏信息系统专家存储项目实施周期 2周 (2010年6月23日至7月09日)项目测试团队
  • 25. 252010 H1RSS TimelineRI Optimizer (SERP)RI Optimizer (STAR)RI Manager (TPC)Responsive Infrastructure (SVC)RSS-1 PoC (SVC + TPC + STAR)RSS-1 HW/SW Joint Detail Design (SVC + TPC + STAR)RI Processes (ESP)RSS-1 Data Migration (SVC + TPC + STAR) for Tier-2 AppsSERP PoC2010 H22011 H1RSS-1 consists of (SVC+TPC+STAR)PoC in Beijing IBM Lab2011 H2RSS-1 Deployment (SVC + TPC + STAR)RSS-1 Production (SVC + TPC + STAR) for Tier-2 AppsSERP DeploymentRSS-2 Data Migration (SVC + TPC + STAR + SERP) for Tier-1 AppsRSS-2 Production (SVC + TPC + STAR +SERP) for Tier-1 AppsRSS-2 consists of (SVC+TPC+STAR+SERP)
  • 26. 26POC重要里程碑6月 22日 – 6月23日 前期远程测试环境数据收集 6月 24日 项目启动(6月29日)及测试环境修改 6月 25日 – 6月26日 TPC + STAR环境配置 6月 27日 – 6月28日 设计规划测试用例 6月 29日 – 7月02日 功能场景测试 7月 03日 – 7月05日 完成测试报告 7月 06日 成果汇报 7月 09日 最终报告提交
  • 27. 27RSS-1 详细测试计划RSS-1 测试启动会 (6月29日下午)
  • 28. 28
  • 29. 29SVC 初始存储分级和后来存储重新分级STAR虚拟磁盘(VDisks)Hosts性能实时监测 容量实时监控 热点和冷点实时监控 每日存储升级建议 每日存储降级建议 周期性的无影响的数据迁移T1T2T3RSS-1 产品架构TPC
  • 30. 30详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 31. 31测试0 测试内容测试目的: 证明RSS-1能够很容易的将一个应用部署到生产环境中 测试步骤: 模拟环境快速搭建。 RSS-1实测优点: 主机端的配置简单:单一多路径软件,多级存储共享。 SVC统一规划,简化划盘流程。 基于STAR报告,提供分级部署方案的基于容量和性能的科学依据。 在实际生产的应用部署过程中,可以实现环境的快速搭建。
  • 32. 32详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 33. 33测试1&2测试内容测试目的: 验证RSS-1能够很容易的识别并且解决性能瓶颈 问题。 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储。 测试步骤: 模拟OLTP真实场景,加载Oracle负载到不同的后台存储子系统的Lun上。其中,将部分Hotspot Lun放置在Tier 3存储上,将部分Cold Lun放置在Tier 1存储上。 查看STAR报告,检查重要指标,设计分级存储优化解决方案。 根据存储优化解决方案,通过SVC进行Lun的在线迁移。 查看STAR报告,检查分级存储优化结果。
  • 34. 测试1&2测试用例流程随机查找主表记录更新记录主表内容根据更新内容添加流水表找到记录?模拟业务逻辑处理更新主表记录业务处理失败更新流水表记录业务处理失败selectupdateinsertupdateupdateNoYes处理成功?更新流水表记录业务处理成功updateYesNo测试数据库每个表空间两张表,分别为数据主表和流水表。 整个数据库的访问过程,如右边流程图所示,尽可能的模拟真实业务环境。 整个测试流程通过使用随机参数保证负载的随机性。 通过控制测试程序的线程数来控制负载的大小。
  • 35. 测试1&2测试案例概述Tier 3 DS5100 SATATier 2 DS4800Tier 1 SymmetricP670 OracleabcdefghijklRegular Lun with WorkloadRegular Lun without WorkloadSE Lun with WorkloadSE Lun without Workload
  • 36. Test 1 & 2 – Right-tiering Management – MDG ViewDS5100_MDG_03 1.. “MDG Status” 为 “warning” 因为 SE VDisk物理尺寸超过阀指。 2.. “Warning MDG Size Avail < 5% Total” 为 “ok”,空间使用没有超过警戒.。但是其还有9T的剩余空间,剩余空间太多,需要提高利用率。 3.. “Warning MDG BE Read IO Rate Avail < 20%, although Capacity” 为 “ok”. 但是 “BE Read IO Rate Actual Max. [IOPS]” 接近 “BE Read IO Rate Capacity [IOPS]”, 需要注意。 根据分析,该 MDG存在热点Lun,需要进行Up-Tiering.DS4800_MDG_01 1.. “MDG Status” 为 “warning” 因为 SE VDisk物理尺寸超过阀指。 2.. “Warning MDG Size Avail < 5% Total” 为 “ok”,空间使用没有超过警戒.。 3.. “Warning MDG BE Read IO Rate Avail < 20%, although Capacity” 为 “ok”。 DS4800 MDG 因为有其他的生产系统应用在跑,因此我们在分析的时候该MDG不是重点。Sym8830_MDG_01 1.. “MDG Status” 为 “warning” 因为 SE VDisk物理尺寸超过阀指。 2.. “Warning MDG Size Avail < 5% Total” 为 “ok”,空间使用没有超过警戒.。但是其仅仅有743MB的剩余空间。与DS5100的MDG比较而言,该空间需要得到释放。 3.. “Warning MDG BE Read IO Rate Avail < 20%, although Capacity” 为 “ok”. 但是只有20%的IOPS Capacity得到利用,IOPS Capacity的利用率需要得到加强。 经过分析,该MDG存在一些不活跃的Lun,需要Down-Tiering到低级的MDG中去。
  • 37. Test 1 & 2 – Right-tiering Management – MDG QoS ViewDS5100_MDG_03 1.. “MDG Status” 为 “warning”. 2.. 右键点击灯泡控件即展示QoS数据。 3. “BE Read Resp. Time Actual Max” 和 “BE Read Resp. Time Actual Avg” 很接近,而且比较高. “BE Write Resp. Time Actual Max” 和 “BE Write Resp. Time Actual Avg” 很接近,而且都很高。 读和写时间超过“80% of Max Rate” 较多,业务瓶颈是持续性的。 这些指标都说明MDG中存在热点,他们需要得到Up-Tiering.DS4800_MDG_01 1.. “MDG Status” 为 “warning”. 2.. 右键点击灯泡控件即展示QoS数据. 3.. “BE Read Resp. Time Actual Max” 和 “BE Read Resp. Time Actual Avg” 很接近,并且对于FC磁盘来讲很正常。 4. “BE Write Resp. Time Actual Max” 和 “BE Write Resp. Time Actual Avg” 很接近,并且对于FC磁盘来说很正常。 Sym8830_MDG_01 1.. “MDG Status” 为 “warning”. 2.. 右键点击灯泡控件即展示QoS数据. 3.. “BE Read Resp. Time Actual Max” 和 “BE Read Resp. Time Actual Avg” 很接近,而且对于FC磁盘来说比较高。其实这不是因为FC磁盘高,而是SVC条带化的一些设置问题导致。该MDG实际还能容量更多IOPS,这在随后测试中可以证明。 4. “BE Write Resp. Time Actual Max” 和 “BE Write Resp. Time Actual Avg” 很接近,并且对于FC磁盘来说很正常。
  • 38. Test 1 & 2 – Right-tiering Management – VDisk View VDisks因为高IOPS需要升级。 VDisks因为IOPS不活跃而需要降级。
  • 39. 升级和降级迁移计划Tier 3 DS5100 SATATier 2 DS4800Tier 1 SymmetricP670 OracleabcdefghijklTier 3 DS5100 SATATier 2 DS4800Tier 1 SymmetricP670 OracleabcdefghijklRegular Lun with WorkloadRegular Lun without WorkloadSE Lun with WorkloadSE Lun without WorkloadBefore Migration:After Migration:
  • 40. 升级和降级过程中主机端IO和CPU总体分析 进行优化以后,主机端IOPS有大概15%的提升 数据迁移和TPC Probe过程中,对性能有一定所影响,IOPS最多降低30% 整个数据迁移持续将近一个半小时,迁移数据一共1200G,5个Lun。
  • 41. 升级和降级过程中主机端PV分析 HDisk 176从DS5100迁移到Symmtrix. HDisk 178从DS5100迁移到DS4800. 两个PV的Disk Busy都有不同程度降低.Hdisk176从60%左右降低到45%。
  • 42. 升级和降级过程STAR MDG数据分析迁移之前:迁移之后: 通过迁移,DS5100的IO Cpacity被充分解放,DS4800和Symmtric的IO能力得到充 分利用。 通过迁移,DS5100的空间被充分利用,Symmtric的空间得到解放。
  • 43. 降级过程中STAR VDisk 数据分析迁移之前:迁移之后: (DS51_STAR_V0001 to SYM, DS51_STAR_0003 to DS48)
  • 44. 从DS5100迁移到Symmetric和DS4800的Luns 性能都得到显著的提升。平均 IOPS处理能力最高上升30%,平均响应时间最高下降25%。 原先在 DS4800和Symmetric上的Lun性能从响应时间上看受到小幅度影响,这主要是因为所在MDG的负载加大造成。降级过程中STAR VDisk 数据分析 (Cont.)
  • 45. 45详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 46. 46测试3测试内容测试目的: 验证通过使用RSS-1,用户能够快速容易的分析存储活跃性 测试步骤: 模拟OLTP真实场景,加载Oracle负载到不同的后台存储子系统的Lun上。其中,将部分Hotspot Lun放置在Tier 3存储上,将部分Cold Lun放置在Tier 1存储上。 查看STAR报告,查看Vdisk 的IOPS值。
  • 47. 测试3 -分析VDisk的前端峰值读IOPS按最大前端读IOPS排序的VDisk
  • 48. 测试3–按最大前端写IOPS排序的VDisk按最大前端读IOPS排序的VDisk
  • 49. 49详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 50. 50测试4测试内容测试目的: 验证通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 测试步骤: 模拟OLTP真实场景,加载Oracle负载到不同的后台存储子系统的Lun上。其中,将部分Hotspot Lun放置在Tier 3存储上,将部分Cold Lun放置在Tier 1存储上。 查看STAR报告,检查MDG重要指标。
  • 51. 测试4 – 分析MDG的剩余空间剩余空间最大的两个MDG
  • 52. 测试4 – 在MDG中分析VDiskIOPS性能 读IOPS最靠前的两个VDisk几乎贡献了整个MDG的负载,然而其容量加起来仅在整个MDG的4%左右。
  • 53. 53详细测试内容测试0 – Initial App Placement 证明RSS-1能够很容易的将一个应用部署到生产环境中 (RSS-1的 灵活, 简单的显著特性) 测试 1 – Up-tiering 证明RSS-1能够很容易的识别并且解决性能瓶颈 问题 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 2 – Down-tiering 证明RSS-1能够识别并且迁移不活跃的数据到低级别存储 (RSS-1的 灵活, 简单, 有效 的显著特性) 测试 3 – LUN Activity Listing 证明通过使用RSS-1,用户能够快速容易的分析存储活跃性 (RSS-1的简单的显著特性) 测试 4 – Fast Storage Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中快速配置存储 (RSS-1的灵活的显著特性) 测试 5 – Thin Provisioning 证明通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 (RSS-1的有效 的显著特性)
  • 54. 54测试5测试内容测试目的: 验证通过使用RSS-1,用户能够在整个应用生命周期过程中有效的使用存储 测试步骤: 模拟OLTP真实场景,加载Oracle负载到不同的后台存储子系统的Lun上。其中,将部分Hotspot Lun放置在Tier 3存储上,将部分Cold Lun放置在Tier 1存储上。 查看STAR报告,检查重要指标,设计分级存储优化解决方案。 根据存储优化解决方案,通过SVC进行Lun的在线迁移。 查看STAR报告,检查分级存储优化结果。
  • 55. 测试 5 – 精简配置管理 – MDG 视角Virtual Capacity = Virtual Size of SE VDisks + Size of Regular VDisks Real Capacity = Physical Size of SE VDisks + Size of Regular
  • 56. 测试 5 –精简配置管理 – VDisk 视角Regular VDisks (full allocation mode): Regular VDisks: (over)-allocation = 100% SE VDisks (Thin Provisioning mode): SE VDisks require Real Capacity lower than Virtual Capacity seen by servers SE VDisks reached capacity warning thresholds: over 50% in the configuration
  • 57. 测试5 – 精简配置性能测试:测试场景: 克隆VMWare的镜像分别在SE VDisk和常规VDisk上。 镜像大小是20G。 比较克隆的时间。 克隆时间结果: SE VDisk: 143 秒 Regular VDisk: 145 秒 结论: 对于顺序写操作,例如VMWare的镜像克隆,性能方面在SE VDisk和 Regular VDisk是一样的。(从测试上看,SE性能甚至更好)