通过对国内主流图书馆集成管理系统的调研^{[ 4]},只有Unicorn、Horizon和妙思不支持使用Oracle作为其底层数据库,因此本文以Oracle为例来介绍集群技术的应用,如表1所示:

表1

表1

表1 国内主流图书馆集成管理系统的比较 图书馆集成管理系统 数据库 体系架构 Aleph 500[ 5] Oracle C/S 汇文[ 6] Oracle C/S 图腾8.0[ 7] Oracle C/S 与B/S 两种应用模式 ILAS III[ 8] Oracle C/S 与B/S 两种应用模式 InterLib[ 9] Oracle B/S GDLISXP(NET)[ 10] Oracle,Sybase,MS SQL Server C/S SULCMIS[ 11] Oracle,Sybase,Informix,DB2,MS SQL Server C/S MELINETS[ 12] Oracle,Sybase C/S Millennium[ 13] Oracle,自行开发内嵌数据库内核 Host2based Horizon[ 14] Sybase C/S Unicorn[ 15] Informix C/S 妙思文献管理集成 系统V6.5[ 16] MS SQL Server,Sybase B/S 和C/S 混合架构

表1 国内主流图书馆集成管理系统的比较

大多数图书馆使用Oracle作为图书馆集成管理系统后台数据库的图书馆,一般会使用双机热备的机制。在这种情况下,若一台服务器出现问题,要将应用切换到另外一台服务器上,这时需要重新启动数据库核心进程,无法保证数据库系统连续不间断的运行;并且在系统切换过程中,客户端与服务器之间的数据连接也会中断,需要重新进行数据库的连接和登录工作;由于数据库系统只在一台服务器上运行,另一台服务器无法分担负载,造成了极大的资源浪费^{[ 1]}。

随着数字化资源的增加,图书馆集成管理系统的用户同时读写的数据量也随之迅猛增加,比如每天进入系统数据库的电子图书元数据以万条来计算。然而不管使用Oracle、Sybase、MS SQL Server等任一数据库系统,都必须采用双机热备的方式来预防灾难性事件的发生。

在Oracle的服务架构下^{[ 17]},上海交通大学图书馆集成管理系统也采用了双机热备的备份机制(如图1所示),采用三层架构的应用方案,建立了应用程序和数据库管理系统的备份机。为了让备份机和正式机之间的切换不对用户造成任何影响,对备份机和正式机分别赋予实际IP地址,并在其上层架设浮动IP。对于用户而言,他们访问的是浮动IP,这样就缩短了两台机器的切换时间^{[ 18]}。

图1

	Figure Option ViewDownloadNew Window
	图1 双机热备形式的应用框架

在这种数据库架构下,从服务器切换、购买配置和服务器利用率方面来看,存在一些问题^{[ 19]}:

(1)必须手工进行数据库管理系统的切换,在切换的过程中Oracle核心程序需要重启,因此数据很有可能丢失。由于图书馆集成管理系统在运行过程中会产生很多实时数据,若造成流通等关键信息的丢失将无法挽回。

(2)受到传统计算方式的限制,服务器配置只能针对高峰容量来构建计算容量需求,否则无法负载所有的应用,而备机也必须具有相同高的性能,否则无法完成备机的功能,这无疑增加了采购机器的成本。当需要用改善硬件设备配置的方法来提高系统性能时,双机热备形式的架构无法以低成本快速地扩充模块单元的容量,在极端的情况下,需要购买更高配置的新设备来实现系统性能的提升。对于大数据时代来讲,购置服务器的频率必然加快,花费必然增加,这将对图书馆的发展形成瓶颈。

(3)由于服务器备机和正式机的配置基本一样,图书馆希望充分利用备机,但是一般情况下备机并不实际工作,接近闲置状态,因此造成了极大的硬件资源浪费。

图书馆集成管理系统必须寻求一种新的数据库框架,来应对数据的随时变化,并且不产生太多的花费,即通过网络以按需、易扩展的方式来获得所需的服务。

集群是由一个或多个独立的服务器互相协作组成的一个系统。这种架构相对于对称多处理器系统更胜一筹,它可以随着系统的扩大而扩展,同时也提升了错误的恢复能力。Oracle实时应用集群 (Real Application Cluster,RAC)^{[ 8]}继承了集群的所有特性,是一项并行计算的技术。它使得多个服务器能同时共享对某个单一数据库的实时访问,从而获取更高的可用性、最灵活的可伸缩性以及经济型的系统架构,三节点Oracle RAC的体系框架如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 三节点的集群体系框架

图2显示了三台服务器作为Oracle RAC的三个节点,每台节点服务器都是相对独立的。集群服务器间又可以通过各自的通讯层在无人工干预的情况下实现互联互通,从而实现故障保护、缓存融合和负载均衡。所有的集群服务器共享一个数据库,在数据库中除了数据文件,还有控制文件、日志文件等内容。可以看出,Oracle RAC是所有的服务器共享磁盘的共享所有(Shared Everything)体系架构。在RAC环境下,所有节点可以同时在同一个数据库上并发处理事务,由RAC来协调各个节点,把大的事务分解为多个小事务,配发给不同的节点执行,并保证每个节点访问共享数据的完整性和一致性。

在RAC环境中,当服务器的处理能力需要提高时,可以通过直接增加服务器节点数来完成服务器性能的提升,并且不需要对应用程序进行任何修改,原有的服务器也可继续使用。新增服务器节点的配置只要对应需要提升的服务器处理能力即可,即按照增量来设定新增服务器节点的配置。若有个别服务器节点出现故障,也不会影响整个RAC架构的运行,但会增加其他服务器节点的负荷。这些特性也说明RAC具有很高的有效性、可靠性和可伸缩性,而且为用户节省了大量的硬件购置费用。

为了应对大数据时代的来临,图书馆集成管理系统必须可以管理大量的全媒体信息资源,并支持云计算,这就要求其数据库具备高可用性、灵活的可伸缩性以及经济合理的价格。Oracle RAC具备了这些性能,它是所有服务器共享磁盘的Shared Everything体系,集群中的所有服务器共享RAC数据库的所有存储设备^{[ 8]}。集群是由一个或多个服务器构成,每个服务器都有局域网(LAN)连接来互联互通,并且都要被连接到共享存储上,Oracle集群件和真正应用集群(RAC)支持可达100个服务器节点。集群中的每台服务器在硬件配置上不必完全相同,但必须采用相同的操作系统和同样的Oracle数据库版本。所有服务器必须支持同样的架构,如所有32位和64位^{[ 20]}。在应用集群技术的架构时,准备工作中需要注意:

(1)每台节点服务器的硬件配置不需要相同,也不需要性能很高,但必须同时支持32位的操作系统或同时支持64位的操作系统。

(2)只要所有节点服务器的性能总和达到应用系统对服务器的峰值要求即可。

(3)每台节点服务器所安装操作系统的版本号必须完全一致。

这些准备工作就绪后,可以在每台节点服务器上建立Oracle用户,然后安装Oracle Cluster Ware。此时,Oracle RAC的应用环境全部准备完成,接下来就可以安装应用系统,投入正式使用。

依据Oracle RAC的架构,上海交通大学图书馆利用原有的正式机和备份机来搭建双节点的Oracle RAC应用框架,如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 集群应用框架

在数据层部分采用Oracle RAC来管理数据库管理系统,在中间层的应用程序服务器上建立了高可用性(High Available, HA)集群机制,以此来支持表示层中的C/S和B/S架构的应用。

在这种应用框架体系下,真正应用集群使单个数据库能够跨网格中的多个集群化的节点运行,从而可以利用多台计算机服务器处理资源。具有以下优点:

(1)它是不需要随着工作负载变化对数据进行再分区或分配的数据库技术,因此Oracle在跨计算机供应工作负荷的能力方面具备独特的灵活性。

(2)明显提高了硬件设备和资源的利用率,使用多台服务器并行为用户提供服务,大大提高了服务器对数据的处理能力,很好地满足了业务负载的需求,并行执行请求以提高性能,从而做到负载均衡。

(3)在RAC的运行机制下,不仅故障应用可以自动切换,而且可以随时增加服务器节点的数量,最重要的是RAC系统对服务器硬件配置的要求并不高。

上海交通大学图书馆以原有的图书馆集成管理系统的正式机和备份机实现了双节点的Oracle RAC。原有的图书馆集成管理系统是配置在M5000(简称为M5001)中,备份机也是一台M5000(简称为M5002)。配置Oracle RAC要求两台机器的操作系统完全一致,包含操作系统的升级包。由于两台机器的操作系统在小版本上有些差异,因此必须将一台重新安装操作系统。Oracle RAC和Oracle不能并存在一台机器上,这次Oracle RAC的实施是在摒弃原有系统的基础上重新建立一个新的系统,因此在实施过程中数据的备份和可恢复性至关重要,否则任何一个环节出现问题均会带来灾难性的后果。

具体实施步骤如下:

(1)从M5001的Oracle中将数据导出,并对应用程序、重要参数等必要内容进行备份。该步骤是对程序和数据的备份,在此需要特别说明的是如果原应用程序的服务器将成为实施Oracle RAC的服务器之一,意味着RAC启动,原有的Oracle必须停止对外服务。因此建议在实施Oracle RAC方案之前进行一次备份恢复的实验,以保证在RAC实施不成功的情况下可以返回原有状态,保证应用程序的正常运行。

(2)为M5001和M5002安装操作系统Solaris 10,并安装其相应的补丁。需要再次保障两台服务器的操作系统必须完全一致,这样才能保证之后Oracle RAC顺利的安装和运行。

(3)对M5001和M5002进行组卷的划分,并创建用户,配置相关参数(如节点间的对等性)。

(4)在M5001和M5002上建立Oracle用户后,安装Oracle Cluster Ware。

(5)Oracle RAC数据库在M5001和M5002上安装及设置,创建ASM实例并建库。

(6)图书馆集成管理系统的安装。

(7)数据导入,建立索引。此处的数据导入是将Oracle数据导入Oracle RAC中,采用Oracle Dump方式导入,并且数据是带结构和带权限的,因此在创建数据库账户时需要注意,一定要和以前的账户保持一致。

(8)系统测试。测试应用系统是否有影响、数据是否完全、系统的破坏性实验,并且需要进行备份和恢复的测试。

由于之前的非RAC系统架构稳定性一般,在出现一些由硬件、网络、应用系统等故障造成的应用系统服务中断时,工作人员需要至少一个小时的时间来查出并解决问题,因此为了保证流通的正常开放,系统管理员必须配合流通工作人员的上班时间来值班,否则问题出现时会影响图书馆流通业务的正常运行。在实施应用Oracle RAC之后,对于系统管理员来说,最大的变化就是在工作以外的时间不需要专人值班,如果出现一般的系统问题,比如一台服务器的硬件故障,一般在2-10分钟之内集群系统会自动切换到可正常运行的机器上来支持现有服务,系统管理员再来解决出现的问题即可。

在非RAC系统架构中,如果正在运行的服务器出现硬件故障,或所连接的网络中交换机故障,或应用系统出现异常停止服务等故障,无论是自动切换还是手工切换,都需要中断数据库的运行,将其切换到另外一台服务器。由于数据库系统的恢复比较复杂,在切换后数据库要花费时间进行数据的恢复,而且在切换过程中可能造成数据的丢失。然而在RAC系统架构中遇到这些情况,无论是自动切换还是手工切换,都不需要中断数据库,RAC会管理每个服务器节点的数据库系统的运行,只需要切换应用系统到另外的服务器上即可。集群技术可以解决除数据库系统自身故障以外的其他故障发生时数据库系统的不中断运行,在实现高可用性上也减少了数据库的切换时间,从而增加了数据库的安全性和稳定性。比如2011年11月,本馆一台与图书馆集成管理系统的主服务器连接的交换机出现了问题,将应用系统直接切换为从服务器即可正常对外服务。

在非RAC系统架构中,为了保证主从机相关配置的一致性,一般从机不提供包括数据库在内的各种对外服务。这样主机同时负担了数据库服务和应用服务,如果数据库和应用服务访问量很大,则会出现主机负载量过大,而从机却一直空闲的情况。比如在2006年秋季开学时,由于瞬时新增数据量过大,导致系统完全死锁。系统不得不进行重新启动,但是由于是非正常重启,数据库中数据发生丢失,包括当天的借还书、新增读者办证事物、编目数据、采访数据、典藏数据等。但在RAC系统架构中,多节点服务器上的数据库系统可以同时对外服务,分担负载,因此在每学期开学时就可以应对剧增的瞬时新增数据量。而且RAC系统架构还可以通过扩展服务器节点的数量来提高数据库对外服务的性能。

但是系统管理员必须花费更多的时间来掌握集群系统管理,因为集群系统的设置要比一般的数据库管理复杂很多。也正是由于它的设置及其内部结构更加复杂,使得数据库的稳定性更强。RAC系统架构无法解决数据库本身出现的问题,因此本馆又采用Data Guide技术,用来保障正式运行的数据库出现问题时,数据库还能够在较短时间内重新提供服务。