级别: 初级 孙沁, 中化电子信息技术公司,IBM DM 解决方案技术支持工程师
2002 年 11 月 01 日 本文以实例的方式描述了DB2 在 Windows 上使用 MSCS 服务来创建高可用性的服务。文中配有丰富的插图和比较详尽的代码,并且该实例基于的环境就是一个实际的生产环境。文中还讲述了在配置 MSCS 服务中会遇到的问题,以及解决的办法。例如:共享磁盘阵列的分区问题、DB2 高可用性实例服务创建的问题,管理服务器的配置等等。
前言
该故事发生在不久以前,话说某天笔者接紧急任务,要去某省某市安装基于 Windows® 上的 DB2,开始觉得 Windows 上的东西,不就是 Next>Next>…..>Finish, 这次赚到了,可以免费旅游一番(该市也风景秀丽之所),不料其后发生的事情一波三折(放心啦,不会写游记。当然是安装过程中的一波三折),导致不仅旅游计划泡汤,人也瘦了一圈,为免各位同道不再身受其苦,特将本人之经验教训拿出来分享一下,各位大侠见笑了。
顺利的开始
一到场地,见到 N 台服务器正在呼呼地吹风呢,感到压力骤增,再看看操作系统,Windows® Advance Server,心下暗自欢喜( Windows® Advance Server 只允许一个集群中包含两台服务器,而 Windows® Datacenter Server 允许四台服务器在一个集群中),任务难度较低。
要在 Windows® 上实现 DB2 的群集服务,首先必须实现操作系统级别上的 HA(High Available),先给出一张现场配置示意图:
应该来说群集环境比单服务器环境中就多了一个磁盘阵列和心跳线,磁盘阵列的功能我想就不用讲了吧,不过在群集中磁盘阵列不仅仅是一个高可靠的磁盘组,同时它为存在其上的数据提供被接管的可能性,即磁盘阵列是独立存在的,不以服务器的资源存在为前提。心跳线的功能和它的名字非常相配,在群集服务中的心跳线是用于检测各个群集节点是否在工作的媒介,在群集中的各个节点通过心跳线网络按照一定的频率发包检测是否对方是否有响应。因此服务器上需要有两张网卡,一张连接到交换机提供外部访问,另一张用于心跳线,在服务器上把两个本地连接一个名称改为 Public,一个改为 Private,Public 连接用于和公用网络交互数据,Private 连接为心跳线所用,图中 Private 连接是采用网卡到网卡直接互联的方式。当然也可以使用从服务器到交换机再到服务器的做法。
Windows 上实现群集需要域的支持,现场的思路是为了便于管理将所有的服务器放在一个域中,便于进行管理和安全方面的设置,如果已经有域存在,那就只要将服务器加入域就可以了。
首先配置主机 A 为域控制器,配置其 Active Directory,将主机 B 配置为冗余控制器。(一般来说最好能够提供与数据库服务器独立的机器来做域控)。然后安装Windows群集服务,在控制面板中->安装和删除程序->安装和删除Windows组件->选择群集服务,后面的任务就是选择仲裁资源的磁盘,以及选择集群使用网络的选择,下图是群集配置的一些图形界面:
-
选择仲裁资源使用的磁盘
-
选择供外部客户机使用的网络,这里使用了 Public
-
选择供心跳线使用的网络,这里选择了 Private
-
设置访问群集的 IP 地址
在另一台服务器上也配置好群集服务将其加入到刚才建立好的群集之中。
配置完群集服务就可以使用 Windows 自带的群集管理器来对群集进行管理了。
添加域用户中添加 db2admin 用户,并将其加入到主机 B 的本地管理员组中。安装 DB2 V8 在两台服务器上,在选择域的时候要记得填上域的名称。总算可以开始配置群集了,心情非常愉快。
可怕的沉默
要配置 DB2 的群集服务,必须要了解一个工具那就是 DB2MSCS,这个工具为用户屏蔽了复杂的 DB2 群集资源配置。下面为大家介绍一下该工具的用法。
DB2MSCS 是用来将非高可用性 DB2 实例转变成高可用性 DB2 实例的工具,该工具可以为需要被转换的实例创建所有的 MSCS 组、资源以及资源的依赖关系。它还会将 Windows 注册表中的 DB2 实例信息拷贝到 MSCS 环境中,包括实例目录等。DB2MSCS 使用一个输入配置文件(DB2MSCS.CFG)来定义所有的资源及信息。
在 DB2 ESE 或者 EEE 版本中需要的条目如下:
- DB2_INSTANCE:DB2 实例名称,如果未指定该项,DB2MSCS 会使用由环境变量 DB2INSTANCE 内容指定的缺省实例。
- GROUP_NAME:MSCS 的组名,如果指定的组名不存在的话,会创建以该参数命名的组。除非又定义了其他组,所有在该条目后定义的资源将从属于该组。
- IP_NAME:IP 地址资源的名称,这个参数的值可以是任意的,但是在整个 MSCS 资源中必须是唯一的。指定了该名称后,MSCS 会创建一个类型为 IP 地址的资源,并以该名称命名。
- IP_ADDRESS:定义上面所述的 IP 地址资源的 IP 地址值,需要注意的是该 IP 地址是一个虚拟的漂移 IP 地址,该地址不能与现存的 IP 地址冲突,该地址也就是访问 DB2 实例时需要使用的地址,如果定义了 IP_NAME 参数,则必须设定该参数。
- IP_SUBNET:定义上面所述的 IP 地址资源的子网掩码,如果定义了 IP_NAME 参数,则必须设定该参数。
- IP_NETWORK:定义相对于上述 IP 地址的绑定的网络连接。
- DISK_NAME:指定 DB2 实例需要使用的共享磁盘资源名称,该磁盘资源应该在群集资源中已经存在,当 DB2MSCS 实用程序对实例进行配置的时候会将指定的共享物理磁盘资源从原来的组中移动到 DB2 实例指定的组中。
- INSTPROF_DISK:该参数为可选参数,指定 DB2 实例存放在那个磁盘上,如果不指定该参数,DB2 实例将存放在指定的第一个磁盘资源上。
- INSTPROF_PATH:该参数为可选参数,指定 DB2 实例存放的目录。
- DB2_LOGON_USERNAME:管理实例所用的域用户帐号。
- DB2_LOGON_PASSWORD:管理实例所用的域用户账号的密码。
- NETNAME_NAME :网络名称资源的名字,网络名称资源允许客户端使用机器名的方式来访问群集实例。
- NETNAME_VALUE :定义上述网络名称资源的机器名。
- NETNAME_DEPENDENCY :如果需要使用网络名称资源,必须已经存在 IP 地址资源,该选项就是用来指定和该网络名称资源对应的 IP 地址资源名称。
- TARGET_DRVMAP_DISK:创建一个磁盘映射,因为在创建分区数据库的时候,要求创建数据库所在的磁盘资源必须对该实例的所有节点都可用。
- DB2NODE:指定在分区实例中节点的名字。
下面是一个 DB2MSCS.CFG 文件的例子,该实例文件中使用的实例是一个含有两个 NODE 的实例。
#
# Global section
#
DB2_INSTANCE = DB2MPP
DB2_LOGON_USERNAME = db2nt
DB2_LOGON_PASSWORD = db2nt
CLUSTER_NAME = MSCS
#
# MSCS Group for Node 0
#
GROUP_NAME = DB2 Node 0
DB2_NODE = 0
IP_NAME = IP Address for Node 0
IP_ADDRESS=9.26.118.251
IP_SUBNET=255.255.255.0
IP_NETWORK=Ethernet(2)
NETNAME_NAME = Network Name for Node 0
NETNAME_VALUE = DB2SRV0
NETNAME_DEPENDENCY = IP Address for Node 0
DISK_NAME = Disk M:
INSTPROF_DISK = Disk M:
TARGET_DRVMAP_DISK = Disk M:
#
# MSCS Group for Node 1
#
GROUP_NAME = DB2 Node 1
DB2_NODE = 1
IP_NAME = IP Address for Node 1
IP_ADDRESS=9.26.118.252
IP_SUBNET=255.255.255.0
IP_NETWORK=Ethernet(2)
NETNAME_NAME = Network Name for Node 1
NETNAME_VALUE = DB2SRV1
NETNAME_DEPENDENCY = IP Address for Node 1
DISK_NAME = Disk O:
TARGET_DRVMAP_DISK = Disk O:
|
客户要求在这两台机器上运行一个数据仓库的应用,于是我开始编辑我的 DB2MSCS.CFG 文件,在两台机器上使用一个应用,也就是说平时应用在主机上运行,而备份机处于等待状态,当主机失败后应用转移到备份机上工作,原来主机拥有的 DB2 资源由备份机接管(如下图)。现在我想转换的群集实例是由系统缺省创建的 DB2 实例,虽然用的是 DB2 V8 版本,虽然缺省的 DB2 实例也是一个 ESE 类型的实例,但是客户的数据量不是非常的大,所以只使用拥有一个分区数据库来支持(这小子是不是偷懒啊)。所以下面的配置文件会比上面的范例配置文件要简单。
配置文件如下:
DB2_INSTANCE=DB2 //指定需要转换的实例名称
DB2_LOGON_USERNAME=dbdomain/db2admin //指定登录实例的域用户账号
DB2_LOGON_PASSWORD=0000 //指定登录实例域用户账号的密码
CLUSTER_NAME=MYCLUSTER //指定群集的名称
GROUP_NAME=DB2 Group A //指定用于该实例的组名称
DB2NODE=0 //指定该组资源对应的 DB2 节点号
IP_NAME= MscsA //指定用于该实例的 IP 地址资源的名称
IP_ADDRESS=192.168.192.31 //指定 IP 地址资源的IP地址属性
IP_SUBNET=255.255.255.0 //指定 IP 地址资源的子网掩码
IP_NETWORK=Public Network //指定 IP 地址资源绑定的网络连接
NETNAME_NAME = MscsAName //指定网络名资源的名称
NETNAME_VALUE = DataCenter //指定网络名资源的机器名属性
NETNAME_DEPENDENCY = MscsA //指定该网络资源名对应的 IP 地址
|
资源的名称
DISK_NAME=DISK E: //指定该节点需要使用的磁盘资源
INSTPROF_DISK=E: //指定该节点目录所在的磁盘资源
|
在运行 DB2MSCS 命令之前需要把被配置的实例停止,并且在服务面板上将该服务的启动方式该为手动启动方式。然后在 DB2 CLP 中运行下面的命令就可以了:
C:>db2mscs -f:db2mscs.cfg
C:>此处光标在朝我眨眼
|
好了吗?怎么没有感觉,没有任何变化,难道 DB2 真的到了波澜不惊的地步了吗。看看群集管理器中没有任何变化,于是按 UP 键继续回车,每次都是一样的结果,可怕的沉默,DB2 不理我...
第一折
经过本人翻阅资料,终于得出结果了,DB2 实例获得不了它所需要的磁盘资源,为什么呢,因为用户在做硬件安装的时候将磁盘阵列做成了一块 RAID5 磁盘,而我在创建群集时使用的仲裁资源就是指定了 E:,而 DB2 实例需要使用独立的磁盘资源,所以在运行 DB2MSCS 工具的时候不能获得磁盘资源,非常可恶的是它居然一点提示也没有。接下来的工作是非常乏味的,删除群集服务,将磁盘阵列重新做 RAID5,分成三块物理分区(E:,F:,G:),而非逻辑分区,一般来说现在的磁盘阵列都支持这个功能,(注意:假如你使用了逻辑分区的话,你会发现结果是一样的,因为在群集服务中的磁盘资源指的是物理分区而不是逻辑分区。)再重新安装群集服务,指定 E: 为仲裁资源所使用的磁盘,仲裁资源所使用的磁盘空间要求容量较小,一般分配 500M 就足够了,然后将 DB2MSCS.CFG 文件中指定磁盘资源的两行改成:
DISK_NAME=DISK F: //指定该节点需要使用的磁盘资源
INSTPROF_DISK=F: //指定该节点目录所在的磁盘资源
|
再执行:
C:>DB2MSCS /f:DB2MSCS.CFG
.............
.............
|
创建 Windows 服务失败,可能是您的权限不够,或者是服务虽然已经被标记为删除但是仍然存在。
新运行一遍,并在运行期间看着群集管理器,发现确实在运行该程序,所指定的资源在一个个被创建出来,当创建到 DB2 服务的时候,就开始报该错误,并回滚所有操作。睁大眼睛仔细看错误报告,是权限权限问题吗?我登录的账户是域中的管理员,在域中所有节点都将它自动加入本地管理员组,在脚本中指定的账户是域中的 db2admin 用户,我也已经将其加入到各节点的本地管理员组了,在安装 DB2 的时候确实提醒过我,需要为用户分配一些权限,那么我加加加,在本地安全策略中将如下权限赋给 db2admin 和 administrator:
- 充当操作系统的一部分(Act as part of operation system)
- 创建记号对象(Create a token object)
- 作为服务登录(Log on as service)
- 增加配额(Increase quotas)
- 替换进程级记号(Replace a process level token)
这回可以了吧,运行前面的命令发现结果照旧,当时就感觉客户在身旁嘿嘿冷笑,不热的天怎么竟流汗呢?考虑多时觉得自己在这台服务器上手气不好,决定换一台服务器试试,(客户依然微笑着,换服务器?没问题,老子有的就是服务器!)。坐到备份机上之后,我想是平时的习惯救了我,打开 DB2 CLP,就敲了一个 db2ilist,显示当前服务器上的实例列表,命令打完后,屏幕上空空如也,(不会吧,它又沉默啦,老大,我错了还不行吗!),在 Windows 上安装 DB2 之后,系统会自动创建一个名字为 DB2 的实例,可是这里的实例到哪里去了呢?
没有人来删除过它,自己就不见了,等等,"删除"这个词我好象在什么地方看到过,会不会是 DB2MSCS 将备份机上的实例删除了呢,因为要创建的群集实例和备份机上的实例是同名的,而在 DB2 上是不允许的,于是它也不请示我就把它删除了,并且由于 DB2 实例在 Windows 上是以服务的形式存在的,而 Windows 在删除实例的时候只是在注册表中将其标志为删除,只有到下次启动的时候才真正删除了,于是乎重新启动(告诉你了吧,确定不了什么问题的时候,重新启动没错)。启动后再执行 DB2MSCS 命令,成功了!生成群集服务后的群集管理器截图如下:
注:教训是最好新建一个实例来做群集,而不要使用缺省创建的 DB2 实例。
下面你可以决定是否需要在主机故障恢复后应用会切换回主机,在 MSCS 群集中缺省的设置是不恢复。你可以在群集管理器中配置该选项。选定 DB2 GROUP 查看它的属性如下图,在 Failback 属性页中将 Allow failback 选中,你还可以选择何时恢复应用至主机。并且需要配置 DB2 实例的概要注册表参数 DB2_FALLBACK。
C:>SET DB2INSTANCE=DB2
C:>DB2SET DB2_FALLBACK=ON
|
欲知后事如何,请听
下回分解... ...
关于作者  | |  |
孙沁是中化电子信息技术公司的IBM DM 解决方案的技术支持工程师,在 DB2 上已经有两年左右的经验,主要负责 DB2 数据库的技术支持工作。
|
对本文的评价
|