银行系统异构数据库整合运维研究.docVIP

银行系统异构数据库整合运维研究 　　摘 要： 银行系统中使用的数据库类型和数量逐渐增多，这对银行系统的数据库运维提出了更高的要求。通过研究建立统一的数据库集中运维管理平台，实现了异构数据库的整合运维，节约了数据库运维管理的人力投入和厂商资源成本，达到了主动和预防性的数据库运维模式，提高了数据库运维管理的效率及事件处理的时效性，提升了银行系统的稳定性。 　　关键词： 异构数据库； 整合运维； 预防性； 效率 　　中图分类号：TP391 文献标志码：A 文章编号：1006-8228（2013）10-06-04 　　0 引言 　　在现代银行系统中，由于业务模式的类型不断扩张，使用的数据库产品种类也越来越多，已有的主流数据库产品有Informix、Sybase、Sqlserver、Oracle。随着数据库类型和数量越来越多，对数据库的运维质量要求[1]也越来越高。由于缺乏有效的运行监控、自动化巡检、趋势预测、隐患排查的方法和工具，导致运维成本不断增加，数据库管理工作面临严峻的考验。因此，对于不同类型的异构数据库的整合运维[2-4]是现代金融企业IT科技必须研究的一个重要课题。 　　目前，异构数据库的整合运维存在两大问题： 　　⑴ 数据库的产品种类不同，导致运维标准缺乏统一性； 　　⑵ 当前主流的数据库运维工具侧重于“事中”和“事后”监控[5-7]等被动模式，缺乏主动性运维模式。 　　为解决上述问题，本文通过研究建立异构数据库的集中运维管理平台，改变数据库运维中存在的效率低、管理方式被动等不足，同时通过实现主动和预防性的数据库运维模式，提高数据库运维效率。 　　1 平台体系架构 　　经调研发现，目前业界尚没有一款产品可以完全覆盖四种异构数据库的指标监控，往往仅支持一种或两种数据库。在经过对几款主流数据库监控平台POC测试的基础上，我们最终选用ORACLE公司的GRID CONTROL，作为我行异构数据库整合运维度量分析平台的基础框架，其物理架构如图1所示。 　　如图1所示，数据库运维度量平台共包括四台服务器，分别为一台应用服务器、一台数据库服务器和两台中转服务器。其中，应用服务器和数据库服务器互为热备，通过SAN网络连接到共享存储，两台中转服务器互为冷备。因此，总体来说，本平台可满足高可用性。 　　四台服务器上都安装了SUSE LINUX操作系统。其中，应用服务器安装了Weblogic中间件，数据库服务器和两台中转服务器都安装了Oracle数据库。此外，数据库服务器上安装了GRID CONTROL产品，作为异构数据库监控分析的平台；而中转服务器则作为接收和存放报表数据的平台。 　　本平台的系统逻辑架构图如图2所示。其逻辑结构从下往上依次为：数据源层、数据收集层、数据中转层、数据存储层、数据处理层、数据展示层、数据分析层和事件通知层。 　　通过分层架构模式，本平台细化并明确了各层次的专有功能，极大地降低了各层次间的耦合程度。各层次的组成和作用说明如下。 　　数据源层 处于整个逻辑架构的最底层，是数据库运维指标的原始数据来源，由生产系统的各类数据库和其中的数据组成，包括Informix、Sybase、Oracle、Sqlserver数据库。 　　数据收集层 用于从数据源层实时收集数据库的各类运维指标数据。 　　数据中转层 对收集到的原始指标数据进行过滤和格式转换，将原始指标数据转换成符合运维度量平台库表所定义的存储格式，并将指标数据导入到平台的存储数据库中。 　　数据存储层 定义了存储和分析异构数据库运维指标所需的库表结构，存放经过数据中转层过滤和转换后的各类数据库运维指标值，以及运维度量分析平台自身正常运行所需要的元数据，用于提供给更高层进行展示、分析、监控。 　　数据处理层 通过数据处理引擎，计算出各项数据库运维指标的基线，以满足更高层对数据库进行自动化巡检、趋势预测、运维指标监控的需要。 　　数据展示层 生成数据库自动巡检结果和日常检查报表。 　　数据分析层 通过趋势分析，提前预警数据库未来可能发生的问题，并帮助数据库管理员做好隐患排查和解决的准备工作。 　　事件通知层 通过和邮件系统、HP Openview事件监控平台结合，进行告警。 　　其中，Oracle Grid Control产品的实现功能为：Oracle数据库所有运行指标、Sybase、Sqlserver数据库部分运行指标的数据采集功能和数据展示、事件通知功能。 　　我们的创新点为：通过自定义数据收集层、数据中转层、数据存储层、数据处理层，实现了所有非Oracle数据库（Informix、Sybase、Sqlserver等）运行指标的数据采集功能，并通过特定的策略算法，对数据库指标进行了趋势分析和自动化等主动性运维。