利用 MSCS 创建高可用性的 DB2 服务(二)

孙沁
IBM DM 解决方案技术支持工程师, 中化电子信息技术公司
2003 年 1 月

本文以实例的方式描述了 DB2 在 Windows 上使用 MSCS 服务来创建高可用性的服务。文中配有丰富的插图和比较详尽的代码，并且该实例基于的环境就是一个实际的生产环境。文中还讲述了在配置 MSCS 服务中会遇到的问题，以及解决的办法。例如：共享磁盘阵列的分区问题、DB2 高可用性实例服务创建的问题，管理服务器的配置等等。

接上集，话说 DB2 的 Cluster 配置成功后，笔者心情大好，不过前言中说过的该过程为一波三折，有了第一折，自然应该有第二折、第三折，且听笔者细细道来。

第二折(小困难)
配置好群集后的任务就是测试，一般的测试方法是使用一台独立的客户机远程连接群集实例，在远程客户机上安装 DB2 管理客户端，从控制中心上编目数据库，首先在群集实例下创建一个测试数据库 DBTEST，在目前拥有资源的服务器节点上的 DB2 CLP 中执行下面的命令：


            C:>db2 create db dbtest on f:

在远程客户端上使用客户机配置助手编目该数据库，打开配置助手或者使用控制中心中的功能进行系统、实例、数据库的搜索。这时我发现在搜索到的系统中没有我需要编目的实例和数据库，这是为什么呢？这么简单的问题，我想也难不倒大家，这是因为在群集实例上没有一个管理服务器来管理，所以我们只能搜索到在两个群集节点上运行的管理服务器，主机 A 和主机 B 上的管理服务器，但是这两个管理服务器所属的 IP 地址和前面设定的群集实例的 IP 地址都不一样所以该群集实例不能被我们搜索到。一个数据库要被搜索到必须遵循以下条件。

所以只有在群集实例相同的 IP 上创建管理服务器才可以是客户端自动搜索到该群集实例上的数据库。

为了在群集中使用 Administration Server，按如下步骤实施：

由于在 Windows 安装 DB2 的时候会缺省安装 Administration Server，所以需要对 DAS 进行处理；

在所有的节点上运行下面的命令停止 Administration Server；


            C:>db2admin stop

在群集的第一个节点上将 DB2DAS00 服务改为手动启动方式；

在群集的其他节点上将 Administration Server 删除；


            C:>db2admin drop

在 NODE1 节点上的 DB2MSCS.CFG


            DB2_INSTANCE=DB2DAS00			//指定需要转换的实例名称
            CLUSTER_NAME=MYCLUSTER		//指定群集的名称
            GROUP_NAME=DB2 Group A			//指定用于该实例的组名称
            DB2_LOGON_USERNAME=dbdomain/db2admin //指定登录管理服务器的用户名
            DB2_LOGON_PASSWORD=0000		//指定登录管理服务器的用户密码
            DISK_NAME=DISK F:					//指定该实例需要使用的磁盘资源
            INSTPROF_DISK=F:

在 NODE1 节点上运行下面的命令


            C:>DB2MSCS － f:DB2MSCS.CFG

注意该配置文件和上面的配置文件有一些不同，可以看到该配置文件中


            GROUP_NAME=DB2 Group A

这说明所有在该文件创建或需求的资源都将放在DB2 GroupA 中，在上面的有关 NODE1 中的配置中 IP 地址资源已经被创建了，所在 Administration Server 的 DB2MSCS.CFG 文件中不需要再创建该资源。同时还可以看到虽然 DISK F: 资源在前面的配置文件中已经有过，但是在这里必须要指定，因为这个磁盘将是与该管理服务器相关的所有实例信息存储的地方。

在 NODE1 上运行下面的命令：


            C:>SET DB2INSTANCE=DB2DAS00
            C:>DB2SET DB2_FALLBACK=ON

当管理服务器和实例以及数据库的 Discover 相关选项被打开的话，就可以使用 DB2 的 DISCOVERY 功能从客户端发现位于高可用性实例上的数据库了。

注：由于 DB2 的 Adminstration Server 的名字是固定的所以只能在 Hot Standby 方式下使用 Administration Server，而不能够在 Mutual Takeover Configuration（互备份配置）方式下为多个独立的应用使用 Administration Server，这是为什么呢？读者们可以考虑一下。

在编目好测试数据库之后，应该做如下测试以证明群集是成功的。

从远程客户端上连接到高可用性数据库上，并执行一个查询操作(例如：db2 list tables)；
在群集管理器中将被测试的实例组移动到群集中的其他节点上。如果 DB2_FALLBACK 参数未被设置则需要确认所有的数据库连接已经被断开；
从远程客户端再次执行相同的查询操作，这时该操作应该是失败的，因为此时数据库连接已经丢失；
从远程客户端重新连接高可用性数据库，并再次执行相同的查询操作，此时操作应该成功。
在群集管理器中将实例组移回到原先的机器上，如果 DB2_FALLBACK 参数未被设置则需要确认所有的数据库连接已经被断开；
从远程客户端再次执行相同的查询操作，这时该操作应该是失败的，因为此时数据库连接已经丢失；
从远程客户端重新连接高可用性数据库，并再次执行相同的查询操作，此时操作应该成功。
在硬件故障、软件故障、测试负荷情况以及工作负荷情况下运行 1-7 步。

经过测试又发现了一个问题，那就是当切换后发现数据仓库控制数据库不能打开。数据仓库数据库本身是一个普通的数据库，在其中存放了 ETL 过程的元数据信息。那么按理来说只要在群集实例上创建一个数据仓库控制数据库就可以了，但是数据仓库控制数据库还有两个相关的服务，一个是 DB2 仓库服务器，另一个是 DB2 仓库记录器服务。要在群集实例上实现数据仓库的数据库抽取功能，那么还要把这两个服务也加入到群集资源组中。只要使用群集管理器的标准资源类型 Generic Service 就可以了。

第三折(如果不多嘴就好了)
智者曰：言多必失。此话一点不假，如果再有一次机会的话我一定不会说那句话的，客户说：按你现在这种方式，我配置的硬件有一半是浪费的，能不能有更好的方式？出于一个技术人员的职业道德我说当然可以了，可做成双机互备方式，在一个群集中的两台服务器上分别运行各自的应用，在其中一个节点失效的时候由另外的一个节点同时负担两个应用的运行任务，问题是您这里有那么多应用吗？客户顿时两眼放光(当然有，老子有的就是应用)，给我介绍了他们的应用有什么数据仓库，数据中心，POS 系统...，总之是正在实施的和没影的全都搬出来了。怪谁呢？只能怪自己多嘴。

在 MSCS 上 DB2 支持两种方式的高可用性，一种是前面介绍的 HOT Standby 方式，还有一种就是下面我要做的，Mutual Takeover Configuration（互备份配置）方式，该方式的示意图如下：

互备份配置的操作过程与热备份配置大体相同，它们的不同点在于在互备份配置中的各个群集节点上都有自己的实例在运行，在上面已经在 NODE1 上配置了群集服务，那么在主机 NODE2 上创建一个新的实例叫做 DB2B，同样需要停止实例，并将其启动方式改为手动启动方式;

编写配置文件：
在 NODE2 节点上的 DB2MSCS.CFG


            DB2_INSTANCE=DB2B		//指定需要转换的实例名称
            CLUSTER_NAME=MYCLUSTER		//指定群集的名称
            GROUP_NAME=DB2 Group B		//指定用于该实例的组名称
            IP_NAME=MscsB                     //指定用于该实例的IP地址资源的名称
            IP_ADDRESS=192.168.192.33	//指定IP地址资源的IP地址属性
            IP_SUBNET=255.255.255.0		//指定IP地址资源的子网掩码
            IP_NETWORK＝Public Network      //指定IP地址资源绑定的网络连接
            NETNAME_NAME = MscsBName	//指定网络名资源的名称
            NETNAME_VALUE = POSSEVER       //指定网络名资源的机器名属性
            NETNAME_DEPENDENCY = MscsB   //指定该网络资源名对应的IP地址
            DISK_NAME=DISK G:	//指定该实例需要使用的磁盘资源
            INSTPROF_DISK=G:

在两个节点上分别运行属于自己的 DB2MSCS.CFG 文件。

在群集管理器中将两个组的 Failback 属性都激活；

在 NODE1 上运行：


            C:>DB2MSCS -f:db2mscs.cfg
            C:>SET DB2INSTANCE=DB2
            C:>DB2SET DB2_FALLBACK=ON

在 NODE2 上运行：


            C:>DB2MSCS -f:db2mscs.cfg
            C:>SET DB2INSTANCE=DB2B
            C:>DB2SET DB2_FALLBACK=ON

但是到此并没有结束，由于是双机热备方式一个必须考虑的问题是当群集中一个节点失效的时候，另一个节点需要同时负担两个应用的运行和资源分配问题，一般来说应用在主机上运行的时候，它应该获得充足的资源，在备用机资源不充足的情况，在应用被迁移至备用机之前应该对 DB2 实例和数据库的某些资源进行重新分配，很幸运，DB2 给了我们这种能力。

DB2 赋予了用户在 DB2 资源在被激活前和激活后执行脚本的能力，通过这些脚本我们可以实现某些参数设置的工作；DB2 在 DB2 资源被激活前会去执行名为 db2cpre.bat 脚本，在 DB2 资源激活后会去执行名为 db2cpost.bat 脚本。这些脚本都不是必须的，只有在存在的时候 DB2 才会去执行它们。这些脚本位于每个实例的目录下，该目录的位置由概要注册表（Registry Profile）中的 DB2INSTPROF 参数值与实例名称决定。

该脚本为上面场景中实例 DB2 所用；

使用如下命令确定用户脚本需要存放的位置


                C:>set db2instance=DB2
                C:>db2set db2instprof
                F:\\DB2PROFS

则 DB2 实例的目录为 F:\\DB2PROFS\\DB2，即用户脚本应放在此目录下；

为需要使用的数据库创建别名，这一步是为了便于管理，不是必须要做的；


                C:>set db2instance=DB2
                C:>db2 catalog db dbtest as testdb

对于外部客户端，其访问和编目的数据库名为 testdb。

创建脚本文件


                [F:\\DB2PROFS\\DB2A\\db2cpre.bat]
                @echo off
                if "%COMPUTERNAME%"="NODE1" goto NODE1
                if "%COMPUTERNAME%"="NODE2" goto NODE2
                echo Error ! No script for this computer >> f:\\db2profs\\db2a\\pre.out
                goto end
                :NODE1
                db2cmd -c db2 -z p:\\db2profs\\db2\\pre.out -vf f:\\db2profs\\db2a\\preNODE1.clp
                goto end
                :NODE2
                db2cmd -c db2 -z p:\\db2profs\\db2\\pre.out -vf f:\\db2profs\\db2a\\preNODE2.clp
                :end
                [F:\\DB2PROFS\\DB2A\\preNODE1.clp]
                uncatalog db testdb
                update dbm cfg using INTRA_PARALLEL YES
                [F:\\DB2PROFS\\DB2A\\preNODE2.clp]
                uncatalog db testdb
                update dbm cfg using INTRA_PARALLEL NO

在上述脚本中 NODE1 为主机，NODE2 为备份机，以上脚本的意思是指在备份机上工作的时候将分区内的并行关闭，使用较少的资源。因为往往热备份配置中，备份机的硬件配置要比主机低。并且在 DB2 资源被激活前删除数据库编目，使用户不能在资源启动期间访问数据库。还有需要注意一点,在这些批处理文件中凡是有输出的命令必须将输出重定向到输出文件。


            [F:\\DB2PROFS\\DB2A\\db2cpost.bat]
            @echo off
            if "%COMPUTERNAME%"="NODE1" goto NODE1
            if "%COMPUTERNAME%"="NODE2" goto NODE2
            echo Error ! No script for this computer >> f:\\db2profs\\db2a\\post.out
            goto end
            :NODE1
            db2cmd -c db2 -z p:\\db2profs\\db2a\\post.out -vf f:\\db2profs\\db2a\\postNODE1.clp
            goto end
            :NODE2
            db2cmd -c db2 -z p:\\db2profs\\db2a\\post.out -vf f:\\db2profs\\db2a\\postNODE2.clp
            :end
            [f:\\db2profs\\db2A\\postNODE1.clp]
            restart db samplea
            update db cfg for samplea using dbheap 12000
            alter bufferpool IBMDEFAULTBP size 100000
            connect reset
            activate db samplea
            catalog db samplea as testdb
            [f:\\db2profs\\db2A\\postNODE1.clp]
            restart db samplea
            update db cfg for samplea using dbheap 6000
            alter bufferpool IBMDEFAULTBP size 60000
            connect reset
            activate db samplea
            catalog db samplea as testdb

同样在激活后脚本的任务为根据机器的配置调整相应的数据性能参数并重新编目数据库的别名使客户端可以通过该别名连接数据库。

结束语
终于完成了，应该说这算一次比较完整的对 Windows 上群集的实践。如果您耐着性子看完了，那么你应该对 DB2 群集的实施有了一定的了解，当然关于 DB2 在 Windows 上的群集的内容远远不只于此，如果读者有兴趣的话可以参考 IBM 的红皮书资料：
Implementing IBM® DB2® Universal DatabaseTM V8.1 Enterprise Server Edition with Microsoft® Cluster Server

关于作者
孙沁是中化电子信息技术公司的 IBM DM 解决方案的技术支持工程师，在 DB2 上已经有两年左右的经验，主要负责 DB2 数据库的技术支持工作。

返回顶部

下一篇：DB2 通用数据库中的事务性日志记录概述 >>