高可用性有广义和狭义之分。本文的研究对象是广义高可用环境,指整个系统的高可用,包括系统失败或崩溃,应用层或中间层错误,网络失败,存储介质失败,人为失误、分级与容灾,计划宕机与维护(陈吉平,2008)。数字地震网络项目竣工后两年内,通过数据整合,逐渐形成了由SUN Cluster的小型机服务器、Oracle10gR2数据库管理软件、Solaris Cluster HA操作系统,备份服务器(运行EMC legato备份软件)、TB级的IPSAN存储、以及三层双交换机组成的一套上海地震观测数据服务系统。

随着观测节点和实时数据量的增加,业务系统对数据库的访问频率增强,观测集成数据库的压力越来越大。业务高峰期,使用mpstat、echo::memstat|mdb-k等命令对系统负载进行监控,可以看到系统资源损耗严重。

高可用环境升级采取由分到总的策略,对服务器硬件、网络、存储和数据库体系架构分别进行分析测试,再综合择优,确定最合适的高可用环境升级方案。

(1)数据库服务器

数据库服务器硬件选择在传统机架式x86服务器、小型机和刀片服务器之间进行,比较了DELL、IBM、Oracle、Cisco等品牌。考虑到数据中心的统一资源管理,业务快速部署和低能耗需求,选择Cisco UCS(统一计算系统)为平台,将核心数据库服务器从Sun Fire V490更换为Cisco UCS Blade Server B200 M2刀片服务器。CPU由原来的4C 1.05 GHz提升到16C 2.67 GHz,内存由原来8 GB提升到32 GB。当多用户进行各种业务操作时,每一个用户的操作请求,CPU都会分配一个线程来处理。CPU核数的增加,使CPU总线程数也得到了增加,满足同一时间多用户进行业务操作。CPU主频的增大可以进一步提高CPU处理用户请求的速度。

(2)网络

Cisco UCS的统一矩阵Unified Fabric,将服务器的所有网络流量通过统一的fabric interconnects 传输,进行统一处理和管理,大大减少了网络适配器,刀片服务器交换设备和网络布线,最终提高整体性能。局域网由千兆网络变更为万兆网络,带宽的增加,使数据传输更快速,对业务应用响应也起到一定的提升作用。

(3)存储

存储的选择在IP SAN(以太网存储)和FC SAN(光纤存储)之间。高可用环境升级中,核心存储由原来的H3C IX1000 IP SAN更换为HDS VSP FC SAN,即将过去基于IP网络的存储系统变更为采用光纤通道的存储设备。HDS VSP FC SAN采用4 GB/s的光纤通道和512 GB数据缓存。FC由于协议设计的特点使得其具有先天的安全特性,与LAN业务网络相隔离,使存储与服务器之间进行数据传输时更快捷稳定,存储数据流也不会占用业务网络带宽。SAS盘比SATA盘在磁盘读写性能上也有一定提高。存储的升级对数据库服务器物理读取或写入存储中数据的性能有一定提升。

(4)数据库软件

集成后的观测业务数据库采用Oracle 10g R2作为数据库管理系统,软件版本由原来的10.2.0.3升级到10.2.0.4,更稳定可靠。

(5)数据库体系架构

业务集成数据库由HA方式的单实例变更为双节点RAC。比起单实例数据库,RAC数据库具有负载均衡的特性,Cache Fusion可以解决共享缓存(Cache)并发问题(刘增军,2006)。升级后的业务观测集成数据库将文件存储改为ASM存储方式,具有可扩展性,当磁盘满后,可以手动在线添加。ASM磁盘组中的磁盘做成镜像冗余方式,提高可靠性。ASM对从磁盘中进行数据读取的性能有一定提升作用。

升级后上海地震观测集成数据库高可用环境如图1所示。

对观测集成Oracle数据库采用调整内存参数、增加索引和对大数据表进行分区3种方式进行优化。

(1)内存参数调整

内存参数的调整主要是指Oracle数据库的系统全局区SGA(System Global Area)的调整。SGA 是 Oracle 数据库的心脏,是对数据库数据进行快速访问的一个系统区域,可以被服务器和用户共享(肖军,2004)。SGA 主要由3部分构成:共享池(Share Pool)、数据缓冲区(Data Buffers)和日志缓冲区(Redo Log Buffers)。程序全局区PGA(Program Global Area)也是一个内存区域,包含了

图1 升级后的地震观测集成数据库高可用环境
Fig.1 The high availability environment of seismic observation integrated database after the upgrade

与某个特定服务器进程相关的数据和控制信息。每个进程都具有自己私有的 PGA 区。

通过查询v$systat视图中的各种指标和在业务高峰期收集的AWR报告,发现系统运行速度过慢的主要原因是SGA内部的数据缓冲区命中率过低,数据库系统在查询时不能从共享池或者数据缓冲区内找到己经缓存的数据,从而频繁地到磁盘上读取数据,消耗系统资源,造成等待时间过长。

通过多方测试,观测集成数据库中将sga_target参数从原来的1.5 GB扩大到14 GB,pga_aggregate_target从809 MB扩大到4 805 MB。调整内存参数后,在业务高峰期收集Oracle RAC两个节点的49minsAWR报告,从中可以看到测试时间段一节点数据库内存分配为:buffer cache 8 176 MB,shared pool 5 248 MB,PGA 4 805 MB。测试时间段二节点数据库内存分配为:buffer cache 6 784 MB,shared pool size 6 656 MB,PGA 4 805 MB。根据各自节点的AWR报告中的Buffer Pool Advisory和PGA Memory Advisory,可以看出两节点buffer cache值所在的因子下,比原来buffer cache值所在的因子下产生更低的额外物理读; 两节点PGA的值对应各自因子下,比原来PGA的值对应的因子下产生更低的额外物理写。同时从各自节点上AWR报告中可以看出两个节点的Buffer Hit%都在100%,数据块在数据缓冲区中命中率正常。从TOP 5等待时间中没有发现明显耗资源的等待事件。在测试过程中各节点的AWR报告中DB Time都远小于内核数*Elapsed,说明在测试过程中数据库压力不大。扩大SGA和PGA对数据库性能有一定提升。

另外,从AWR报告上还发现,数据库的软解析值很高,但Execute to Parse%比例却很低。查看session_cached_cursors的使用情况(表1),发现其使用率为100%,这个参数限制了在PGA内session cursor cache list的长度,提供快速软分析的功能,比软解析性能更高(谭磊,2010)。因此,需要根据应用情况适当增大这个参数值,session_cached_cursors数量要小于open_cursors,采用下面的命令将session_cached_cursors值增加到100:alter system set session_cached_cursors=100 scope=spfile。

表1 session_cached_cursors使用情况
Tab.1 Service condition of session_cached_cursors

对JOPENS系统的MySQL数据库进行异构整合,迁移到地震观测集成Oracle数据库中,并为其创建MATE用户。为了提高测震业务用户读取波形数据的速度,分别对MATE用户下的WAVEFORM_CON表中CHANNEL_ID和START_TIME字段添加索引,索引名为WFC_CHANNEL_IDX和WFE_STARTTIME_IDX。添加索引后,当JOPENS测震应用进行读取某一频道的波形数据,或者读取某一时间点(时间段)的波形数据时,数据库通过索引扫描查询数据,避免顺序扫描整个表,从而提高应用查询效率。

(3)使用分区表存储波形数据

Oraclel的分区(Partitfon)技术,是为解决数据库中大表或者索引读写速度过慢而提出的解决方案。通过把大表和大索引拆分成更小的块(称为分区),与原来相比,因为分区变小,所以系统访问分区的速度更快、效率也更高,但分区的存在对用户而言是透明的。系统可单独访问这些小尺寸的表或索引,也可以以组或整体方式访问(姜维智,2005)。

泰德测震、强震的表空间seism,每个月的数据增长有300～400 GB。当前泰德应用的测震、强震表都在seism表空间中。该业务应用数据量大,实时波形数据不断增长,并且应用经常会做查询某一时间点的测震或者强震少量的数据。采用在线重定义的方法对后续收集的数据使用分区技术,对测震、强震分别按时间范围(按月)建立分区表,同时对站点、频道和起始时间字段建立分区索引。分区表的使用可以增强维护性,当表某个分区出现故障,只需修复该分区,不需要对整表进行修复; 可以均衡I/O,把不同的分区映射到磁盘以平衡I/O; 可以改善查询性能,对分区对象的查询可以仅搜索自己关心的分区,排除其它不相干的数据,从而提高检索速度,改善数据库的性能。

(1)系统资源状况

经过整体优化后,观测集成数据库系统资源充足,可查看CPU和内存使用,如下所示:

[root@DZJ1 ～]# mpstat

Linux 2.6.18-274.el5(DZJ1)03/25/2013

03:33:59 PM CPU%user%nice%sys%iowait%irq%soft%steal%idle intr/s

03:33:59 PM all 5.05 0.00 0.43 0.20 0.02 0.26 0.00 94.03 765.19

[root@DZJ1 ～]# free-m

total used free shared buffers cached

Mem:32112 18103 14009 0 301 15872

-/+buffers/cache:1929 30183

Swap:34111 0 34111

(2)数据库负载状况

在测震、强震、前兆等业务高峰期,观测集成数据库两个节点负载明显降低,整体性能如图2所示:

图2 优化后的集成数据库节点1(a)、节点2(b)性能图
Fig.2 Performance of Nade 1(a)、Nade 2(b)of integrated database after optimization

在业务正常运行情况下,抽选对用户影响较大的几个业务场景,执行相关SQL语句,测试数据库耗时,对比如表1所示。

根据测试对比结果,地震观测集成数据库高可用环境升级后,使系统整体(包括数据库服务器、存储、网络)性能得到了一定提升,系统硬件资源已不存在明显性能瓶颈,同时Oracle数据库软件版本和系统架构也进行了升级和调整,降低数据库负载,更加符合业务应用的需求。对Oracle数据库的优化(包括内存参数、索引和分区优化)后,集成数据库的性能有了一定的提升,业务高峰时期数据库压力不大,原来响应缓慢应用操作在整体优化后执行效率显著的提升。独立的核心数据存储区将业务观测数据与一般数据隔离,保障了安全性。另外,整体优化后,集成数据库再没有出现坏块。

表2 数据库优化前后运行时间对比
Tab.2 Run time contrast before and after Database optimization