nkj827
作者nkj8272017-09-14 10:18
项目经理, 长春长信华天

证券业核心业务系统存储性能优化以及存储双活构建 活动总结

字数 4243阅读 1741评论 0赞 11

股票市场变化动荡,而一旦股票市场交易火爆,就会给证券公司核心后台交易带来不可预知的压力,高峰期间经常会出现交易堵塞等待等现象。给股民交易带了不少的烦恼。这种突发的情景使得证券公司核心后台亟待需要升级优化自己的基础架构平台来满足日常增长和不可预知的交易瓶颈。

某证券公司目前的核心业务系统运行在IBM POWER 780服务器上(两台服务器做的POWER HA实现了服务器的高可用),存储是采用的IBM DS8800和EMC VMAX高端存储。依据证券公司现在的交易状况和通过后端数据分析发现,高峰交易时段在每日上午10点至11点和下午13点至14点,证券公司在交易时段对系统的实时性和并发数要求很高,每天不定时存在大数据量分析负载,但产生分析负载的用户数量不多。月末统计数据量增大,需要产生大量数据报表。因此在高峰交易时段、大数据量分析和月末统计时段IO会出现繁忙,存储有热点等现象。

由于以上业务系统要求,该证券用户迫切需要进行以下改进:

  1. 迅速提高 IO 处理能力,解决迫在眉睫的 IO 压力需求,缓解当前的性能瓶颈;
  2. 整合现有的存储,使得在有额外突发需求时,不用中断业务就可以动态调整 IO 的负载能力;
  3. 新建立生产和同城数据中心双活。

一、核心议题:

1、是通过优化当前的系统架构来缓解问题?还是通过新构建系统架构来解决问题?
2、如果进行新建,有哪几种可选的方案?不同方案的优缺点?
3、不同方案中的产品应该如何选型?

二、活动问答

Q:做同城数据中心双活,有哪几种可选的方案?
目前SVC支持两种:
1,strechec cluster(spli io)
其实就是IO GROUP中两个node跨两个站点,实现双活;
这种方案,只需要两个SVC NODE,成本较为低廉。可以和MM/GM很好结合实现两地三中心。
2,svc 7.5开始支持hyperswap配合Metro Mirror实现双活:
两个站点各有一个IO GROUP(2 NODES),采用ACTIVE-ACTIVE MDOE提供双活。
这种方案需要4 节点、8节点实现双活,成本较为昂贵,但稳定性更高。

Q:V9000跨中心采用Metor Mirror同步复制与传统DS8000采用的PPRC技术有何异同点?
v9000 最大的优点就是读写性能很快,一般是结合SVC使用,我想该方案,是把V9000挂在SVC下,然后采用SVC metor Mirror 技术实现数据级容灾。 SVC metor mirror 技术和DS 8000 pprc 技术是两个不同的概念。DS8000 PPRC 技术是指DS8000 点对点复制,但是DS8000 PPRC 技术包含同步复制Metor Mirror,异步复制global mirror. SVC metor mirror 与DS8000 metor mirror 都是实现同步复制,唯一不同的是SVC 是介于主机与存储之间的中间层的存储虚拟化技术。

Q:V9000是否自身提供同步&异步复制容灾功能,依赖其它设备吗?对比其它产品,V9000的优势体现在哪?
首先是V9000中是集成F900产品,F900产品是ibm全新设计的一款纯硬件架构的闪存阵列,其核心是FlashCore
FlashCore是 FlashSystem的基础,IBM 已对 FlashCore 技术进行了重新设计,最大程度地提升闪存的 I/O 速度,同时提供最可靠的闪存存储解决方案。FlashCore 技术是 IBM FlashSystem存储产品下列三大基础组件的重要组成部分:
硬件加速的架构:FlashSystem 在控制器中采用 IBM 开发的硬件,可最大程度地减少甚至消除 I/O 活动中的软件交互量,从而为全闪存存储阵列提供具有最高 I/O 性能及最快响应时间的控制器。

IBM MicroLatency™ 模块:FlashSystem 采用 IBM 专有的闪存存储模块,可提供性能最快和最可靠的闪存存储。

高级闪存管理:FlashSystem 采用 IBM 硬件及专利软件算法,确保更好地管理原生 NAND 的可靠性,从而提供最可靠、最具可用性的闪存数据存储。

其他友商产品,EMC DSSD Xtremio HDS GX00/HFS 要么具备闪存性能,要么具备一些SVC软件特性,再或者就是需要搭配其他产品使用才能应用,而且仅仅是搭配没有做到的真正的融合集成到一起。两者兼而有之的产品是没有的。

Q:证券行业双活数据中心的建设关键点?
从整体建设思路来讲,不论是传统的主备模式,到两地三中心,再至目前都在尝试是双/多中心架构,在灾备建设路线上,都需要从以下六个维度进行考量:
策略:管理模式,IT发展路线,AA/AQ/AS
组织:双中心一体化运营的组织架构
流程:切换流程,日常运维
应用/数据:应用影响分析,数据整合
技术:技术选型
基础架构:机房风火水电,服务器、存储、网络等基础架构搭建

对于实施路线来说,
1.需求分析:业务影响分析、应用影响分析等
2.方案设计:策略与规划、技术架构设计、实施规划等
3.建设实施:生产改造、灾备建设、联调测试等
4.预案与演练:预案、流程开发、灾备演练、一体化管理平台等
5.日常运维:双/多中心的日常运维管理制度

从经验谈一下对两点比较难的地方:

一、两中心的组织架构
两中心的组织架构建议可设置为流程平台,组织架构相似
对于基础架构如系统、网络、安全、环境团队可以采用同等的设置,但是根据灾备的规模,人员可以有少部分消减
对于应用团队,若为双活系统,则在灾备中心可以进行设置,否则仅有少量基本维护人员即可
对于质控、开发工具团队可以在主中心存在即可

二、两中心的技术架构
技术架构以及灾备架构统一设计,两中心同时参与建设
有比较统一的灾备模式,例如双活、冷备、数据备份等,
对于数据同步有统一的方式,例如应用级、数据库级、存储级等
这样有了较为标准的技术方式,则在建设、维护、操作、切换应急、监控、数据追补、人员技能、平台均可以进行长期的稳定标准的运维

Q:在存储层面做复制(不是存储双活),对Oracle RAC带来的影响有哪些?
Oracle RAC ASM架构中,ASM+OCR和voting盘,在存储层面做的复制(类似EMC的SRDF,IBM metro mirror等,不是存储双活,只是底层做lun镜像),如果主存储宕了,在OS上面删除所有盘的信息,将备存储的lun映射到主机,调整好盘序,保持原样,修改好权限。能拉起oracle RAC数据库吗?

1、你这需求相当于Oracle RAC异机挂载磁盘,在使用RAW/ACFS时候是可以简单操作就可以完成的,如果使用ASM的话,操作会比较复杂和一定的风险性。原因在于如果使用ASM,ASM会记录你物理磁盘的信息,而使用卷镜像时,理想情况下,2个盘的数据结构是一毛一样的,但是由于卷信息不一致,导致ASM认为你是2个不同的卷,导致无法快速加载这些磁盘使用,(特别是VOTEDISK),如果不镜像VOTE DISK的话,那比较简单的方式是使用另外的机器来维护VOTE DISK,但是这样的话就违背了当前的需求。

2、建议配置一些操作比较简单,成熟案例较多的方法,可以的做做POC和切换演练。
2.1 如果你现在处于规划阶段,而且对连续性要求确实很高,建议一步到位使用存储双活来做这个事情。
2.2 如果对连续性要求不那么高,对RTO有一定的容忍而且业务允许的情况下,可以使用DG做。
2.3 如果你现在是有2台存储还没购买卷镜像许可、可以考虑通过ASM配置Failure Group来保证数据的双份保存,同时配置VOTE DISK和ORC的自动保存,在出现问题的时候手动恢复VOTE/ORC到另外一台存储保证业务快速启动。

3、如果你现在确定要使用卷复制来做这个事情,建议与存储厂商沟通技术细节,并做模拟真实环境的POC,确定操作步骤,并在允许的情况下,做真实环境的切换演练。这个方法需要谨慎,因为不同的存储厂商、不同的Oracle版本和不同的卷管理方式都有不尽相同的地方,你说的方案本人有过失败的项目经历。

Q:存储性能和可用性监控的常用指标和注意事项?
重点关注双中心间光纤交换机级联端口的状态、流量变化,避免发生链路抖动甚至断开;关注cluster中仲裁盘状态是否online可用;关注vdisk的mirror状态是否实时一致。svc节点ups有自动充放电机制,关注集群事件告警信息。

性能指标主要包含双活SVC节点上的总的IOPS,IO响应时间,IO吞吐量,FC卡的流量,FC端口状态,光功率等,还可以针对某个卷进行专门的指标监控,如果是VDM的话,还可以监控VDM间的写延迟时间等。

两个数据中心间的链路是重点监控对象,看光功率,状态,流量,带宽等等。

目前SVC主要还是通过TPC进行针对性的监控,链路主要是波分设备厂商提供的监控软件。如果没有走波分设备,而是两个数据中心间的SAN直连,可以直接监控SAN交换机即可。

Q:提升证券业核心业务系统最有效的办法是什么?
硬件方面计算机系统的CPU、内存、网络都有了飞速的发展,传统硬盘发展到15000转后速度就没有质的提升了,而软件方面应用系统的代码优化和数据库调优既增加人力支出又增加成本,然而调优的效果确不明显,存储系统采用闪存加速,使存储系统IO有几倍的提升,SVC 对现有的存储设备进行整合,同时使用SVC的EasyTier功能自动把热点数据从传统硬盘迁移到闪存,加速了应用系统的访问。

Q:V9000的Real-time Compression挺不错,请问是否所以的应用都适合使用实时压缩?
1、通用场景,数据为系统目录文件,文本资料,压缩率为50-60%
2、数据库场景,压缩率大概在50-80%
3、虚拟桌面场景,压缩率大概在45-75%
4、日志服务器场景,压缩率最大可以到90%
其他需要注意的是,视频音频类文件和已经启用表压缩等功能的数据库所属的卷不建议开实时压缩功能,本来压缩率就不高,还会浪费存储性能在这些压缩上。

Q:v9000开启实时压缩对性能的影响?
存储负载压力较低时,10%左右,负载越高,影响越大,每种业务场景下也会不一样。
音频视频类数据,已采用表压缩的数据库不要去开实时压缩,浪费存储资源还没什么效果
具体需要根据时间环境来测试,可以通过命令行模式lsnodestats和lssystemstats查看或者GUI模式下查看

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

11

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广