航空公司存储系统架构设计方案解答.docxVIP

存储系统架构设计 1．背景 - 2 - 2. 用户需求和存储系统架构方案设计 - 2 - 2.1 存储系统性能需求和方案设计 - 2 - 2.1.1 业务简介 - 2 - 2.1.2 需求分析和方案设计过程推演 - 4 - 2.1.3 具体方案设计 - 8 - 2.2 存储系统功能需求和方案设计 - 9 - 2.2.1存储系统架构现状 - 9 - 2.2.2 当前架构存在的问题（存储系统功能需求） - 11 - 2.2.3 存储系统架构优化方案 - 12 - 2.3 业务系统灾备需求和方案设计 - 14 - 2.3.1 业务系统灾备方案和架构现状 - 14 - 2.3.2 灾备方案优化 - 15 - 3. IBM存储系统解决方案的优势 - 16 - 4. 方案软硬件采购清单 - 17 - 附录 参考文献 - 18 -  1．背景 信息企业的业务规模和数据量呈现爆炸式的增长,这无疑给支撑业务的后端IT基础设施带来了巨大的挑战,于是各种硬件升级和资源扩容成了每个企业必须面对的课题,而这其中存储的优化却显得尤为重要。这也不难理解，因为CPU、内存和各种内部总线的速度和发展已经远远超越了磁盘存储。另外，虚拟化的大举推进使得I/O变得越来越密集。另一方面，生产系统的数据往往存在多个副本，再加上容灾系统中数据的两中心甚至多中心的复制，所有这些因素都给业务逻辑最末端的存储系统提出了严峻的性能考验。 随着企业信息系统的发展，在基础设施升级换代的过程中，数据中心往往存在多个厂牌的高中低端多档次的磁盘阵列。由于前端业务系统到后端的基础设施一般采用“竖井式”的架构设计，随之而来的是信息孤岛的存在。不同阵列间的数据缺乏流动性和资源共享，而且单个盘阵的资源利用率往往不高，同时单盘阵作为一个宏观的整体其本身也是个单点故障。另外不同厂牌的盘阵的数据复制技术各不相同，需要管理人员掌握多项复杂的技术，日常需要繁琐的存储配置，运维效率很低。因此为了提升存储系统的整体利用率和可靠性以及简化存储的管理、提高运维效率，亟需整合数据中心的存储系统。这种整合一方面是存储服务的整合，也就是将数据中心的存储资源进行池化，通过单一的接口对外提供存储服务，另一个维度也是运维管理的统一。 2. 用户需求和存储系统架构方案设计 2.1 存储系统性能需求和方案设计 2.1.1 业务简介 前段时间，公司某个核心结算系统在上线前开始出现性能问题。该系统采用典型的B/S架构设计，主要包含作业调度层、应用逻辑层和底层数据库平台。在线数据使用的是ORACLE数据库，近线的历史库使用的是MYSQL数据库，系统逻辑拓扑图如图一所示。 图一 业务逻辑拓扑图 该系统业务逻辑主要包含以下四类作业： ? 每天白天9点-17点的在线数据录入和一些简单查询 ? 白天逻辑单一的后端计算 ? 每天19点-次日7点的夜间维护批处理作业 ? 月末关户作业 目前该系统有500左右的用户数，日均销售数据量约12万（年销售量约4000万），日均运输承运数据量约26万（年运输量约9000万）。对于白天在线的OLTP交易类型和单一逻辑计算，尚未收到客户反应慢的问题。但是对于每天的夜维批处理作业和月度末的关户作业已经开始出现性能问题。对此，用户反馈的主要问题如下： ? 夜间Daily作业在处理月中后期无法按时（早上7点前）完成，出现推迟到白天工作时段运行，典型作业包括配比MCH_DAILY、运输日作业UPL_COM等业务模块 ? 运输月关户作业系统运行时间超过原计划的6小时 为了保证业务系统的顺利投产，需要尽快解决上述性能问题。 2.1.2 需求分析和方案设计过程推演 用户反馈的日常夜维作业共计71个作业，编排为8个队列进行作业调度，通过历时三个月对重点耗时作业的持续监控、反复测试、应用代码和后端基础架构调优，最终将业务窗口缩短到刚好满足系统SLA约束。这其中应用代码调优带来的系统性能提升很有限，最多在10%左右，距离投产的性能要求还相差很远。后续通过进一步的分析，发现存储系统IO是制约整个业务性能提升的瓶颈。 该业务系统部署在公司2007年采购的DMX4高端存储上，有限的前端CPU板卡和磁盘资源成了制约IO性能提升的短板，后续通过增加CPU板卡资源和扩充存储池中磁盘的数量，有效提升了系统IO性能。但是这种调整是有极限的，有限的硬件资源处理能力成了IO性能提升的硬件边界。当IO需求随着业务量的增长而进一步攀升时，后端的硬件很快会再次遇到IO瓶颈。因此为了解决长远的性能问题，需要寻求更高的硬件边界。 IO调优除了提升后端存储的IO处理能力外，另一个角度就是减少前端业务代码给后端基础架构带来的IO量。应用端通过将耗时作业由夜维窗口转移到白天进行，另外就是减少代码中COMMIT的次数。这些应用端的方案都可以减少IO量，但随之而来的问题