DB2 pureScale 问题检查和分析
DB2 pureScale 提供了一个具有高可用性，高扩展性和应用透明性的数据库集群。对于应用来说，无论是连接到数据库的哪个成员，都可以看成为连接到一个单个的数据库，即使这个数据库其实是一个拥有多个成员服务的集群。虽然应用看到的是一个简单的数据库，但其实背后是一个复杂的数据库集群环境。相比较单独的数据库，DB2 pureScale 集群的管理人员需要关注更多的内容。首先来了解 DB2 pureScale 集群的架构。
图 1. DB2 pureScale 集群的架构
在 DB2 pureScale 集群里的服务器有两种角色：member 和 CF。应用是连接到 member 的，每个 member 可以看成是一个单独的数据库实例提供者。Member 进行数据库的处理，处理能力可以通过增加更多的 member 来扩展。CF 可以看作是整个集群的大脑，主管全局的缓冲池，锁和通信等。大脑只需要一个，但是为了保证集群的高可用性，可以配置一个后备的 CF。那样如果主 CF 出现异常，备用 CF 会接管工作，整个集群依旧正常运行。member 和 CF 都推荐放在 DB2 pureScale 集群里单独的服务器上。DB2 会根据角色在这些服务器启动不同的数据库进程来工作。
DB2 pureScale 集群 Member 和 CF 之间需要通信，彼此之间用高速的网络相连。DB2 pureScale 集群需要配置两种网络环境：以太网和无线带宽网（Infiniband network， 简称 IB 网）。所以 DB2 pureScale 集群里的每台服务器都需要配置这两种网络，任何网络出现问题，都会导致异常。
DB2 pureScale 集群是使用共享存储的工作方式。所有 member 和 CF 都需要连接到共享存储。DB2 pureScale 集群使用 GPFS 管理共享存储。GPFS 既是一种共享文件系统，也是一个文件系统集群管理者。如果 member 或者 CF 连接共享存储出问题，DB2 pureScale 集群就需要对此进行异常处理。DB2 pureScale 集成了管理 GPFS 集群环境的工具，当然用户也可以直接使用 GPFS 提供的工具。GPFS 需要在集群里所有的服务器上安装。
集群环境最核心的是图中红色的 CS。这就是管理整个 DB2 pureScale 的集群服务。这个产品就是集成到 DB2 pureScale 的 TSAMP 集群软件（IBM Tivoli System Automation for Multiplatforms 下面简称 TSA）和底层的 RSCT。TSA 会将前面所述的数据库进程，网络，GPFS 等创建为整个集群的 resource 并监控。一旦集群里面哪个资源出现问题，集群服务就会很快检测到，并控制数据库集群做出反应。所以 DB2 pureScale 集群环境问题检查和分析最好的方式就是从集群服务查看 resource 的状态开始。
DB2 pureScale 问题检查工具DB2 pureScale 集群环境包含了服务器的软硬件资源，GPFS，TSA，共享存储，网络环境等。所以除了 DB2 提供的各种检查工具之外，用户还需要使用系统工具，集群软件工具等等来检查和追踪问题。
DB2 pureScale 数据库工具首先介绍 DB2 提供的 db2instance 工具。这个工具能够查看 DB2 pureScale 集群的状态。使用实例用户执行“db2instance -list”：
图 2. db2instance 工具
如图所示，STATE 这列显示了所有 member，CF 和主机的状态。用户很容易在这里发现集群环境是否有问题。ALERT 这一列会提示用户集群环境是否存在警告。如果有警告，这个工具会提示如何查看。一般使用 DB2 提供另外一个工具 db2cluster 来查看。
清单 1. db2cluster 工具
db2cluster { -CM { -SET { -TIEBREAKER { -MAJORITY | -DISK { diskname | PVID=<pvid> } } | -OPTION { HOSTFAILUREDETECTIONTIME -VALUE value | PPRIMARY -VALUE value } } | -LIST [ -TIEBREAKER | -ALERT | -HOSTFAILUREDETECTIONTIME | -PPRIMARY ] | -VERIFY { -RESOURCES | -MAINTENANCE } | -ENTER -MAINTENANCE [ -ALL ] | -EXIT -MAINTENANCE [ -ALL ] | -COMMIT | -CLEAR -ALERT [ -MEMBER member-id | -CF -cf-id | -HOST hostname ] } -CFS { -CREATE -FILESYSTEM fs-name -DISK disk1...diskN [ -MOUNT directory-name ] | -ADD -FILESYSTEM fs-name -DISK disk1...diskN | -REMOVE -FILESYSTEM fs-name -DISK disk-name | -DELETE -FILESYSTEM fs-name | -SET { -TIEBREAKER { -MAJORITY | -DISK disk-name } | -OPTION option -VALUE value [ -FILESYSTEM fs-name ] } | -LIST [ -TIEBREAKER | -FILESYSTEM fs-name [ -CONFIGURATION | -DISK ] ] | -VERIFY { -CONFIGURATION [ -FILESYSTEM fs-name ] | -MAINTENANCE } | -MOUNT -FILESYSTEM fs-name | -REBALANCE -FILESYSTEM fs-name | -UNMOUNT -FILESYSTEM fs-name | -ENTER -MAINTENANCE [ -ALL ] | -EXIT -MAINTENANCE [ -ALL ] | }db2cluster 不仅是也个监控工具，它也是 DB2 用户操控整个数据库集群的工具。db2cluster 可以用来查看 RSCT/TSA (CM) 集群管理器，GPFS 集群管理器，验证所有资源等等。
DB2 pureScale 数据库日志数据库的日志文件 db2diag.log 会记录集群运行过程中出现的问题。这个文件的位置由 DIAGPATH 实例参数设置。DIAGLEVEL 实例参数控制收集诊断信息的级别。CF 的诊断信息 cfdiag*.log 会放在 CF_DIAGPATH 设置的路径里。默认 CF_DIAGPATH 和 DIAGPATH 一致。
TSA 查看集群资源工具因为集群软件以心跳的方式监测 DB2 pureScale 集群，所以获取所有资源状态最好的工具还是集群软件 TSA 提供的 lssam 工具。
图 3. lssam 工具
lssam 列举了所有集群的资源状态，甚至还可以展示各个资源之间的关系。例如共存还是互斥等。通过这个工具可以快速定位到问题存在的位置。
TSA 诊断日志TSA 关于 DB2 pureScale 的诊断日志放在 /var/ct/<domain_name>/log/mc/IBM.GblResRM/ 下面，可以用于进一步诊断异常状态的起因。
GPFS 工具和日志GPFS 是成熟的共享文件系统产品，提供了很多工具用以定位共享存储这块的问题。例如 mmlsnode, GPFS 的工具一般放在 /usr/lpp/mmfs/bin 下面，日志会在 /var/mmfs 里面找到。
uDAPL 工具 (Infiniband)IB 网络作为特殊的硬件环境，可以使用自己的 uDAPL 工具查看问题。例如使用 ibstat 查看 IB 网卡和网络的状态。
系统工具分析 DB2 pureScale 数据库的问题还需要结合操作系统提供的工具和日志。例如使用 ifconfig 可以查看网络，iostat 可以查看磁盘读取等。在 AIX 操作系统里可以使用 errpt 查看操作系统的异常信息。
因为 DB2 pureScale 集群环境使用到如此多的资源，所以需要 DB2 和其他的这些工具一起来分析和解决问题。下面我们通过一些案例来来讨论如何结合这些工具检查和分析 DB2 pureScale 集群环境可能遇到的问题。当这些问题出现的时候，数据库会做出什么样的反应。
进程故障DB2 pureScale 会在集群的所有服务器上启动一些进程来完成各种工作。在现实环境下，有可能出现某些进程会被用户不小心杀掉等情况，那这种行为会给 DB2 pureScale 带来什么样的影响？其实 DB2 pureScale 集群是一个比较强壮的集群，对此类情况会自我修复。数据库的参数 AUTORESTART 设置为 ON 的情况下，进程失灵的数据库服务器会重启 DB2。最终整个数据库集群会恢复正常。
如果是数据库 member 的进程失灵，那么这个 member 会被重启。如果查看当前数据库集群的状态，你会看到清单中显示的 member 1 的状态是 RESTARTING，最终会变成 STARTED.
清单 2. 查看 member 进程失灵时的状态
$ db2instance -list ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME -- ---- ----- --------- ------------ ----- ---------------- ------------ ------- 0 MEMBER STARTED SXYCDBM0 SXYCDBM0 NO 0 0 SXYCDBM0-ib0 1 MEMBER RESTARTING SXYCDBM1 SXYCDBM1 NO 0 0 SXYCDBM1-ib0 128 CF PRIMARY SXYCDBF0 SXYCDBF0 NO - 0 SXYCDBF0-ib0,SXYCDBF0-ib1 129 CF PEER SXYCDBF1 SXYCDBF1 NO - 0 SXYCDBF1-ib0,SXYCDBF1-ib1 HOSTNAME STATE INSTANCE_STOPPED ALERT -------- ----- ---------------- ----- SXYCDBF1 ACTIVE NO NO SXYCDBF0 ACTIVE NO NO SXYCDBM1 ACTIVE NO NO SXYCDBM0 ACTIVE NO NO因为 db2instance 查看的是当前状态，所以用户可能看到应用被回退后，去查看数据库状态却发现一个正常状态的集群。因为集群已经被重启了。这个时候就需要去查看数据库的诊断日志。
清单 3. 查看数据库诊断日志
... 2012-05-22-10.27.23.441781+480 E19658A384 LEVEL: Error PID : 18350146 TID : 2057 PROC : db2sysc 0 INSTANCE: db2sdin1 NODE : 000 EDUID : 2057 EDUNAME: db2fcmr 0 FUNCTION: DB2 UDB, fast comm manager, sqkfTcpServices::handleRecvBufferError, probe:20 DATA #1 : preformatted Recv err 0x8159006B for node 1; link state 5. 2012-05-22-10.27.23.444264+480 I20043A408 LEVEL: Event PID : 18350146 TID : 2057 PROC : db2sysc 0 INSTANCE: db2sdin1 NODE : 000 EDUID : 2057 EDUNAME: db2fcmr 0 FUNCTION: DB2 UDB, base sys utilities, sqleSendNodeFailure, probe:6136 DATA #1 : preformatted SD: Requested synchronous member failure recovery for member = [1] with seq. no = 175 ... 2012-05-22-10.27.23.497578+480 E37801A361 LEVEL: Info PID : 18350146 TID : 2571 PROC : db2sysc 0 INSTANCE: db2sdin1 NODE : 000 EDUID : 2571 EDUNAME: db2pdbc 0 FUNCTION: DB2 UDB, base sys utilities, sqleExecuteNodeRecovery, probe:200 DATA #1 : String, 34 bytes Node recovery completed for node 1数据库的诊断日志 db2diag.log 显示数据库察觉到 member 的 failure 并进行了重启，最终状态是节点重启成功。用户还可以在 DB2 的通知日志里面看到节点重启的原因。DB2 的通知日志和诊断日志在同一个目录下，名称为“实例名 .nfy”。本案例中是 db2sdin1.nfy。
清单 4. 查看数据库通知日志
... 2012-05-22-10.27.23.579591 Instance:db2sdin1 Node:001 PID:9503086(db2wdog 1 [db2sdin1]) TID:258 Appid:none base sys utilities sqleWatchDog Probe:20 ADM0503C An unexpected internal processing error has occurred. All DB2 processes associated with this instance have been shutdown. Diagnostic information has been recorded. Contact IBM Support for further assistance. 2012-05-22-10.27.38.557046 Instance:db2sdin1 Node:001 PID:40501534(db2star2) TID:1 Appid:none base sys utilities DB2StartMain Probe:911 ... ADM7513W Database manager has started. ^^ 2012-05-22-10.27.40.510641 Instance:db2sdin1 Node:001 PID:30146656(db2agnti (SXHRDB ) 1) TID:23646 Appid:*N1.DB2.120522022742 recovery manager sqlpresr Probe:205 Database:SXHRDB ADM1524I Member crash recovery has been initiated. ^^ 2012-05-22-10.27.40.703388 Instance:db2sdin1 Node:001 PID:30146656(db2agnti (SXHRDB ) 1) TID:23646 Appid:*N1.DB2.120522022742 recovery manager sqlpresr Probe:3105 Database:SXHRDB ADM1525I Member crash recovery has completed successfully. ...通知日志里面就能看到数据库集群检测到了一个异常内部进程失灵，于是做了重启恢复并成功完成。
这个案例里面使用了 DB2 的工具和参考 DB2 的日志等手段分析了进程失灵的情况。数据库集群能对此情况进行自我修复。上面的例子是关于 member 的进程失灵，如果是 CF，那就分两种情况。如果是备用 CF 失灵，那么备用 CF 节点会被仍然重启为备用 CF，做 catch up，日志里面也会查看到类似的信息，用户并不能明显察觉到。如果是主 CF 的进程失灵，那么备用 CF 会立刻转换角色成为新的主 CF，而原主 CF 节点会被重启为备用 CF 并做 catch up。这个状态会被用户使用 db2instance 工具查看到 CF 的角色出现了变化。从而用户可以去查看数据库日志确定发生了什么情况。
主机故障相对于进程失灵的不易察觉和 DB2 pureScale 强大的自我修复能力，主机失灵带来的影响会更大，也更易察觉。使用查看数据库集群状态的最佳工具 db2instance。
清单 5. 使用 db2instance 查看数据库集群状态
$ db2instance -list ID TYPE STATE HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME -- ---- ----- --------- ------------ ----- ---------------- ------------ ------- 0 MEMBER STARTED SXYCDBM0 SXYCDBM0 YES 0 0 SXYCDBM0-ib0 1 MEMBER WAITING_FOR_FAILBACK SXYCDBM1 SXYCDBM0 YES 0 1 SXYCDBM0-ib0 128 CF PRIMARY SXYCDBF0 SXYCDBF0 NO - 0 SXYCDBF0-ib0,SXYCDBF0-ib1 129 CF PEER SXYCDBF1 SXYCDBF1 NO - 0 SXYCDBF1-ib0,SXYCDBF1-ib1 HOSTNAME STATE INSTANCE_STOPPED ALERT -------- ----- ---------------- ----- SXYCDBF1 ACTIVE NO NO SXYCDBF0 ACTIVE NO NO SXYCDBM1 INACTIVE NO YES SXYCDBM0 ACTIVE NO NO There is currently an alert for a member, CF, or host in the data-sharing instance. For more information on the alert, its impact, and how to clear it, run the following command: 'db2cluster -cm -list -alert'.在清单中可以发现 member 1 处于 WAITING_FOR_FAILBACK 状态，他的 HOME_HOST 是 SXYCDBM1，但是现在运行在 SXYCDBM0 上。这个工具还提示集群环境里的节点 SXYCDBM1 是 INACTIVE 状态，集群还有报警，可以通过 db2cluster 工具来查看。
清单 6. 使用 db2cluster 查看警告信息
$ db2cluster -cm -list -alert 1. Alert: Host 'SXYCDBM1' is INACTIVE. Ensure the host is powered on and connected to the network. Action: This alert will clear itself when the host is ACTIVE. Impact: While the host is INACTIVE, the DB2 members on this host will be in restart light mode on other hosts and will be in the WAITING_FOR_FAILBACK state. Any CF defined on the host will not be able to start, and the host will not be available as a target for restart light.警告信息清晰说明 SXYCDBM1 节点当机了，还显示了 DB2 pureScale 集群会做出的反应。如果这个节点是 member 的节点，那么原先的 member 会在其他节点启动做恢复，然后处于 WAITING_FOR_FAILBACK 状态。如果是 CF 节点，那么 CF 是没有办法在其他节点启动的。
我们还可以通过 TSA 的命令查看他所监控的资源是什么情况。
图 4. 使用 lssam 工具查看主机资源
在 lssam 工具展示的信息里面，我们可以找到 SXYCDBM1 这个节点的主机资源 IBM.Application:instancehost_db2sdin1_SXYCDBM1 状态是 Offline。现在我们已经确认到主机失灵的问题，此次案例使用的是 IBM 的 POWER 主机。我们找到这个机器的硬件控制台，查看机器的状态和重启机器。
图 5. 硬件控制台
在硬件控制台中，这个主机的状态是非激活，也就是主机没有启动。在控制台里面启动机器，看看数据库会有什么反应。
如果通过 db2instance 工具持续查看集群的状态，用户会发现 member 1 的从 WAITING_FOR_FAILBACK 状态变为在 SXYCDBM1 这个节点上 RESTARTING，最后会变为 STARTED。原先的 ALERT 也不复存在。也就是说 DB2 pureScale 集群会自动检测到节点重新正常的状态并自动重启原先的 member，完成自我修复。
如果此次案例中失灵的不是 member 节点而是 CF 节点，那么失灵的 CF 节点首先会是变为 ERROR 状态，另外一个 CF 会是首选 CF 的角色。等到这个节点起来后，数据库集群会在这个节点重启 CF 为备用 CF，然后做 catch up 等，最终变为 PEAR 状态。
最后来看看系统当时究竟发生了什么。使用 AIX 的系统命令 errpt 查看系统日志。
清单 7. 使用 errpt 查看系统日志
#errpt -a ... LABEL: EPOW_SUS_CHRP IDENTIFIER: BE0A03E5 Date/Time: Thu Apr 12 18:59:50 2012 Sequence Number: 17 Machine Id: 00F6E0DB4C00 Node Id: localhost Class: H Type: PERM WPAR: Global Resource Name: sysplanar0 Resource Class: Resource Type: Location: Description ENVIRONMENTAL PROBLEM Probable Causes Power Turned Off Without a Shutdown POWER OR FAN COMPONENT Recommended Actions RUN SYSTEM DIAGNOSTICS. PERFORM PROBLEM DETERMINATION PROCEDURES Detail Data POWER STATUS REGISTER 0000 0003 ...AIX 系统日志显示，当时操作系统出现了没有关机就断电的情况。在这个案例里面展示了如何结合众多工具来分析主机失灵的问题，以及阐述了 DB2 pureScale 在主机失灵和恢复正常的情况下会保护数据库（member 在其他节点重启做恢复）和自动恢复（主机恢复后会自动加入数据库集群并正常工作）。
以太网故障网络是 DB2 pureScale 环境中不可或缺的一环。无论是以太网还是 IB 网络，都是数据库集群正常运行的保证。DB2 pureScale 集群各节点之间的通信是需要通过以太网的。如果节点的以太网络出现问题，这个节点就不能正常工作，解决以太网的问题是一个很普遍的学问，重要的是如何尽快定位到是以太网的问题。
这里参考一个简单的例子：当使用“db2instance -list”查看系统状态的时候发现有一个 CF 节点的状态是 ERROR，这台服务器有警告信息。
图 6. db2instance 查看集群状态
清单 8. 使用 db2cluster 工具查看警告信息
从警告信息里面可以看到这个 CF 节点上的网络适配器是有问题的。所以很快就定位到了这是一个网络问题。那么下面就同过系统工具 ifconfig 来分析。
清单 9. 使用 ifconfig 查看网络状态
# ifconfig -a en0: flags=1e080862,c0<BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> inet 10.20.0.183 netmask 0xffffff00 broadcast 10.20.0.255 tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0 ib0: flags=e3a0063<UP,BROADCAST,NOTRAILERS,RUNNING,ALLCAST,MULTICAST,LINK0, LINK1,GROUPRT,64BIT> inet 100.10.0.23 netmask 0xffffff00 broadcast 100.10.0.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 ib1: flags=e3a0063<UP,BROADCAST,NOTRAILERS,RUNNING,ALLCAST,MULTICAST,LINK0, LINK1,GROUPRT,64BIT> inet 100.10.1.23 netmask 0xffffff00 broadcast 100.10.1.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,LARGESEND,CHAIN> inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255 inet6 ::1%1/0 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1在 ifconfig 工具展示的网络状态信息中可以看到，以太网卡 en0 的状态不是 up，有可能是被人停用了。在使用命令“ifconfig en0 up”把这个网卡激活起来后，DB2 pureScale 环境自动检测到问题已经解决，这个节点又恢复了正常。
IB 网络故障IB 网络是 DB2 pureScale RDMA 技术的载体。一旦 IB 网络环境里面出现什么问题，出问题的 DB2 pureScale 节点就无法工作。配置 IB 网络环境是现在很多公司不太熟悉的工作，尤其是在 DB2 pureScale 已经定位到 IB 网络的时候，怎么去解决也是很大的难题。我们在给客户多次部署 DB2 pureScale 环境的时候多次遇到 IB 网络的问题，最后总结出一些容易出故障的地方和解决的办法。
首先大家需要的是正确的配置 IB 网络的环境，其中包括交换机的配置（参考 http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.sd.doc/doc/t0059423.html）和服务器的配置（参考 http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.sd.doc/doc/t0056052.html）。基本上如果是 IB 网络的问题，都会出现在这些配置里面涉及的方面。
我们从一个例子来了解如何定位和解决 IB 网络问题。例如在安装好了 DB2 pureScale 环境后，尝试启动数据库的时候出现了问题。
清单 10. db2start 失败报错
# $ db2start 06/04/2012 16:35:16 0 0 SQL2051N There was a communication failure between a DB2 member and a CF. Reason code = "1". CF identifier: "128". Host name: "sxyctestf0". SQL1032N No start database manager command was issued. SQLSTATE=57019db2 在启动的时候失败了，能看到返回的 SQL 代码是 SQL2051N，这个时候可以去看这个代码是什么原因。使用"db2 ? SQL2051N"能给出关于这个返回代码的帮助信息。
清单 11. 获取 SQL2051N 的帮助信息
$ db2 ? SQL2051N SQL2051N There was a communication failure between a DB2 member and a CF. Reason code = "reason-code". CF identifier: "CF-id". Host name: "host-name". Explanation: This message is returned when the database manager detects problems that interfere with communications between a DB2 member and cluster caching facility (CF). The nature of the communication problem is indicated by the reason code: 1 The error occurred or was detected in the User-Level Direct Access Programming Library (uDAPL.) 2 The error occurred or was detected in the sockets layer. 3 The nature of the error could not be determined. User response: Refer to the troubleshooting documentation.在这个帮助信息里面可以看到 db2 在启动时发现 member 连接不上 CF 而导致失败，原因代码 1 表示问题在 uDAPL 上。uDAPL 是 IB 网卡的驱动程序，是和操作系统紧密相关的。这个是后去查看 DB2 诊断日志，也会找到相关的错误。
清单 12. db2 诊断日志
--- 2012-06-04-16.34.03.083304+480 I1577A537 LEVEL: Severe PID : 4653376 TID : 772 PROC : db2sysc 0 INSTANCE: db2sdin1 NODE : 000 EDUID : 772 EDUNAME: db2castructevent 0 FUNCTION: DB2 UDB, RAS/PD component, pdLogCaPrintf, probe:876 DATA #1 : preformatted ca_svr_connect: dat_ep_create failed: 0x40000 DATA #1 : preformatted If a CF return code is displayed above and you wish to get more information then please run the following command: db2diag -cfrc CF_errcode 2012-06-04-16.34.03.161687+480 I2115A533 LEVEL: Severe PID : 4653376 TID : 772 PROC : db2sysc 0 INSTANCE: db2sdin1 NODE : 000 EDUID : 772 EDUNAME: db2castructevent 0 FUNCTION: DB2 UDB, RAS/PD component, pdLogCaPrintf, probe:876 DATA #1 : preformatted CAConnect: cmd_connect failed: 0x8009000c DATA #1 : preformatted If a CF return code is displayed above and you wish to get more information then please run the following command: db2diag -cfrc CF_errcode ---根据提示，使用 db2diag -cfrc CF_errcode 查看帮助信息。
清单 13. db2 获取 CF 返回代码的帮助信息
db2diag -cfrc 0x8009000c Input ZRC string '0x8009000c' parsed as 0x8009000C (-2146893812). Attempting to lookup value 0x8009000C (-2146893812) as a ZRC ZRC value to map: 0x97CA000C (-1748369396) ZRC class : Cluster caching facility transport common errors and warnings (Class Index: 23) Component: CF_XPORT_COMMON ; cluster caching facility xport common (Component Index: 202) Reason Code: 12 (0x000C) Identifer: CF_XPORT_RESOURCE_ERROR Identifer (without component): SQLZ_RC_CF_XPORT_RESOURCE_ERROR Description: Transport resource error Associated information: Sqlcode -2051 SQL2051N There was a communication failure between a DB2 member and a CF. Reason code = "3". CF identifier: "". Host name: "". Number of sqlca tokens : 3 Diaglog message number: 1最终发现 db2diag 里面的这些信息也是定位到 SQL2051N 这个错误号，提示 uDAPL 有问题而导致 Member 和 CF 之间通信有问题。那么现在分别查看 CF 和 Member 上的 IB 网络是否有问题。使用系统工具 ifconfig 查看 IB 网卡的状态。
清单 14. 使用 ifconfig 查看网络状态
# ifconfig -a ib0: flags=e3a0063<UP,BROADCAST,NOTRAILERS,RUNNING,ALLCAST,MULTICAST, LINK0,LINK1,GROUPRT,64BIT> inet 100.10.0.22 netmask 0xffffff00 broadcast 100.10.0.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 en0: flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> inet 10.20.0.182 netmask 0xffffff00 broadcast 10.20.0.255 tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0 lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT, 64BIT,LARGESEND,CHAIN> inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255 inet6 ::1%1/0 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1在 ifconfig 工具给出的信息里面能看到 IB 网卡 ib0 的状态是 UP，也就是在操作系统里面，这个网卡是启用了的。关于 IB 网卡的具体信息还可以通过 uDAPL 的工具 ibstat 查看。
图 7. 查看 IB 网卡信息
在 ibstat 给出的结果里面能看到物理网卡 iba0 的逻辑端口和物理端口的是“活动”的状态。如果网卡连接不正确或者有其他问题，这里的状态就会不一样。现在可以看出 IB 网卡和 IB 网络并没有故障。这个时候也可以 ping 彼此的 IB 网络的 IP 地址，确认能够 ping 通。
现在问题回到了原点，如果 IB 网络配置没有问题，那为什么 DB2 purescale 调用会有问题呢？是不是操作系统的级别和安装的 uDAPL 不兼容？这种不兼容不易被发现，因为你能看到使用 IB 网络的机器之间互相通过 IB 访问对方是没有问题的，没有什么办法可以测试到细微之处，唯一的办法是查看 DB2 或者是操作系统的一些文档，找到操作系统和 uDAPL 的对应关系。这个案例里面使用的是 AIX 操作系统。我们可以在 DB2 的 infocenter 里面找到 http://publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.sd.doc/doc/c0056281.html 这个网页，里面是在 AIX 系统安装 DB2 pureScale 的先决条件。这里主要查看里面的表三的内容：Specific software requirements for AIX operating system version and technology levels。
图 8. AIX 系统安装 DB2 pureScale 的软件需求
现在来看一看案例里面的服务器是否符合条件。分别查看操作系统的版本和 uDAPL 的版本。
清单 15. 使用 oslevel 查看系统版本
$ oslevel -s 6100-07-02-1150清单 16. 使用 lslpp 查看 uDAPL
$ lslpp -l bos.mp64 devices.chrp.IBM.lhca.rte devices.common.IBM.ib.rte udapl.rte Fileset Level State Description ---------------------------------------------------------------------------- Path: /usr/lib/objrepos bos.mp64 6.1.7.2 COMMITTED Base Operating System 64-bit Multiprocessor Runtime devices.chrp.IBM.lhca.rte 6.1.7.1 COMMITTED Infiniband Logical HCA Runtime Environment devices.common.IBM.ib.rte 6.1.7.2 COMMITTED Infiniband Common Runtime Environment udapl.rte 6.1.7.2 COMMITTED uDAPL Path: /etc/objrepos bos.mp64 6.1.7.2 COMMITTED Base Operating System 64-bit Multiprocessor Runtime devices.chrp.IBM.lhca.rte 6.1.7.1 COMMITTED Infiniband Logical HCA Runtime Environment devices.common.IBM.ib.rte 6.1.7.2 COMMITTED Infiniband Common Runtime Environment udapl.rte 6.1.7.2 COMMITTED uDAPL操作系统是 AIX6.1TL7SP2。uDAPL 版本是 6.1.7.2。因为这个案例比较特殊，AIX6.1TL7 的系统还没有更新到 db2 的 infocenter 里面，但是确实是支持的。这里给出最新的 AIX6.1TL7 与 uDAPL 的对应关系。
清单 17. 补充 AIX6.1TL7 与 uDAPL 的对应关系
AIX TL SP uDAPL level 6.1 7 1 6.1.7.0 6.1 7 3+ 6.1.7.1所以在这个案例里面，应该安装 6.1.7.0 的 uDAPL 版本，而不是现在的 6.1.7.2。最终这个问题也正是如此解决的。
综合本文作者在多个 DB2 pureScale 项目中曾遇到的 IB 网络相关的问题以及解决的方法，现总结一些经验，以供参考。
1， 安装的 uDAPL 驱动和操作系统版本不匹配会导致 DB2 pureScale 节点间通信有问题。
2， 配置 IB 网卡的时候使用的端口和配置文件 /etc/dat.conf 里面定义的端口不匹配。
3， /etc/dat.conf 里面配置的 uDAPL 驱动版本和 DB2 的版本不匹配，例如 DB2 9.8 只能使用 1.2 的 uDAPL 驱动。
4， IB 网络通过 IB 交换机相连，IB 交换机需要正确配置。尤其是使用到多个 IB 交换机时，不要忘记每台 IB 交换机都需要配置，要保证 IB 的“Subnet Manager”是激活状态。
GPFS 故障DB2 pureScale 集群使用到的共享文件系统 GPFS 是一个文件系统集群，它也有一般集群具有的“quorum-manager”和投票机制等概念。GPFS 是单独与 DB2 的一个成熟产品，提供了很多管理和监控工具。这一节里面主要讨论下如何从 DB2 发现 GPFS 故障，然后通过 GPFS 工具分析和解决问题。
来看一个案例，当使用 db2instance -list 查看集群状态的时候发现有一个数据库 member 处于 WAITING_FOR_FAILBACK 状态。这个 member 的 HOME_HOST 主机上还有 Alert。下面看看警告是什么。
清单 18. 使用 db2cluster 查看警告信息
$ db2cluster -cm -list -alert 1. Alert: Host 'sxyctestm1' is not able to mount file system '/db2fs/sxlog'. Ensure that the physical connection between the disks and the host is not broken and check the operating system for errors concerning the disks. Once the issue has been resolved, attempt to mount the file system again. Action: Check the cluster caching facility cfdiag log files for messages about CF failures on the host. If there are alerts about network adapters not responding, this alert cannot be cleared manually. It will be cleared when a network adapter becomes available. If it is not a problem with network adapters, this alert needs to be manually cleared after other alerts are handled. To clear this alert run the following command: 'db2cluster -cm -clear -alert'. For more information, see the 'Troubleshooting options for the db2cluster command' topic in the DB2 Information Center. Impact: While the file system is offline, the affected hosts' DB2 members will be in restart light mode on other systems and will be in the WAITING_FOR_FAILBACK state. ------------------------------------------------------------------------------- 2. Alert: Host 'sxyctestm1' is not able to mount file system '/db2fs/sxdata'. Ensure that the physical connection between the disks and the host is not broken and check the operating system for errors concerning the disks. Once the issue has been resolved, attempt to mount the file system again. Action: Check the cluster caching facility cfdiag log files for messages about CF failures on the host. If there are alerts about network adapters not responding, this alert cannot be cleared manually. It will be cleared when a network adapter becomes available. If it is not a problem with network adapters, this alert needs to be manually cleared after other alerts are handled. To clear this alert run the following command: 'db2cluster -cm -clear -alert'. For more information, see the 'Troubleshooting options for the db2cluster command' topic in the DB2 Information Center. Impact: While the file system is offline, the affected hosts' DB2 members will be in restart light mode on other systems and will be in the WAITING_FOR_FAILBACK state. ------------------------------------------------------------------------------- 3. Alert: Host 'sxyctestm1' is not able to mount file system '/db2sd_20120605103826'. Ensure that the physical connection between the disks and the host is not broken and check the operating system for errors concerning the disks. Once the issue has been resolved, attempt to mount the file system again. Action: Check the cluster caching facility cfdiag log files for messages about CF failures on the host. If there are alerts about network adapters not responding, this alert cannot be cleared manually. It will be cleared when a network adapter becomes available. If it is not a problem with network adapters, this alert needs to be manually cleared after other alerts are handled. To clear this alert run the following command: 'db2cluster -cm -clear -alert'. For more information, see the 'Troubleshooting options for the db2cluster command' topic in the DB2 Information Center. Impact: While the file system is offline, the affected hosts' DB2 members will be in restart light mode on other systems and will be in the WAITING_FOR_FAILBACK state. ------------------------------------------------------------------------------- 4. Alert: DB2 member '1' failed to start on its home host 'sxyctestm1'. The cluster manager will attempt to restart the DB2 member in restart light mode on another host. Check the db2diag.log for messages concerning failures on host 'sxyctestm1' for member '1'. Action: Check the cluster caching facility cfdiag log files for messages about CF failures on the host. If there are alerts about network adapters not responding, this alert cannot be cleared manually. It will be cleared when a network adapter becomes available. If it is not a problem with network adapters, this alert needs to be manually cleared after other alerts are handled. To clear this alert run the following command: 'db2cluster -cm -clear -alert'. For more information, see the 'Troubleshooting options for the db2cluster command' topic in the DB2 Information Center. Impact: DB2 member '1' will not be able to service requests until this alert has been cleared and the DB2 member returns to its home host. ------------------------------------------------------------------------------- 5. Alert: Could not restart light DB2 member '0' on host 'sxyctestm1'. Check the db2diag.log for messages concerning a restart light or database crash recovery failure on the indicated host for DB2 member '0'. Action: Check the cluster caching facility cfdiag log files for messages about CF failures on the host. If there are alerts about network adapters not responding, this alert cannot be cleared manually. It will be cleared when a network adapter becomes available. If it is not a problem with network adapters, this alert needs to be manually cleared after other alerts are handled. To clear this alert run the following command: 'db2cluster -cm -clear -alert'. For more information, see the 'Troubleshooting options for the db2cluster command' topic in the DB2 Information Center. Impact: DB2 member '0' will not be able to restart light on host 'sxyctestm1' until this alert has been cleared.从警告信息可以看出在这台主机上，很多个文件系统没有没加载成功。现在已经定位到 GPFS 可能出了问题。下面看如何使用 GPFS 的工具查看问题。使用 mmgetstate 查看 GPFS 集群的状态。GPFS 的工具可以在 /usr/lpp/mmfs/bin 目录下找到。
清单 19. 使用 mmgetstate 查看 GPFS 状态
# /usr/lpp/mmfs/bin/mmgetstate -a Node number Node name GPFS state ------------------------------------------ 1 sxyctestm0 active 2 sxyctestf0 active 3 sxyctestf1 active 4 sxyctestm1 down这里可以看到在 GPFS 集群里面，sxyctestm1 这台主机是 down 的状态，是有问题的。现在我们去看看 GPFS 的日志有什么信息。GPFS 的日志放在 /var/adm/ras 下面。
清单 20. 查看 GPFS 的日志文件
# cat mmfs.log.latest 。。。 Thu Jul 5 16:53:00.145 2012: Command: err 0: unmount sxlog Thu Jul 5 16:53:05.395 2012: GPFS: 6027-311 mmfsd64 is shutting down. Thu Jul 5 16:53:05.423 2012: Reason for shutdown: Normal shutdown Thu Jul 5 16:53:05 GMT+08:00 2012: mmcommon mmfsdown invoked. Subsystem: mmfs Status: down Thu Jul 5 16:53:05 GMT+08:00 2012: 6027-1674 mmcommon: Unmounting file systems ...在这个日志文件里面，我们能看到 GPFS 的服务被 shutting down 了。那么我们只要把这个环境的 GPFS 服务启动就好了。
清单 21. 使用 mmstartup 启动 GPFS 服务
# /usr/lpp/mmfs/bin/mmstartup Thu Jul 5 17:48:45 GMT+08:00 2012: 6027-1642 mmstartup: Starting GPFS ...等待一段时间，GPFS 集群会将 DB2 pureScale 集群用到的文件系统都 mount 上。最后 TSA 会发现这个状态，并将这个 member 重新启动，最终一切正常。查看 GPFS 自己的日志对于帮助分析 GPFS 问题非常重要和有效。
如果日志里面的内容也不够具体，GPFS 也可以通过设置 trace 的方式追踪问题。下面来了解一下如何设置 GPFS 的 trace。
1， 首先在每个节点上创建 /tmp/mmfs 目录。
2， 在每个节点激活 GPFS 关于 trace 的设置参数 traceRecycle，trace 和 traceFileSize 等。
清单 22. 修改 GPFS 的 trace 设置
# /usr/lpp/mmfs/bin/mmchconfig traceRecycle=globalOnShutdown mmchconfig: Command successfully completed mmchconfig: 6027-1371 Propagating the cluster configuration data to all affected nodes. This is an asynchronous process # /usr/lpp/mmfs/bin/mmchconfig trace="all 4 tm 2 thread 1 mutex 1 vnode 2 ksvfs 3 klockl 2 io 3 pgalloc 1 mb 1 lock 2 fsck 3" mmchconfig: Command successfully completed mmchconfig: 6027-1371 Propagating the cluster configuration data to all affected nodes. This is an asynchronous process. # /usr/lpp/mmfs/bin/mmchconfig traceFileSize=200000000 mmchconfig: Command successfully completed mmchconfig: 6027-1371 Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.3，运行 mmtrace 命令激活 trace。
清单 23. 使用 mmtrace 命令激活 trace
/usr/lpp/mmfs/bin/mmtrace start4， 重现出错的问题，或者等待一段时间，停止 trace。
清单 24. 使用 mmtrace 停止 trace
# /usr/lpp/mmfs/bin/mmtrace stop mmtrace: move /tmp/mmfs/trcfile.sxyctestm0 /tmp/mmfs/trcfile.120705.18.16.29.sxyctestm0 mmtrace: formatting /tmp/mmfs/trcfile.120705.18.16.29.sxyctestm0 to /tmp/mmfs/trcrpt.120705.18.16.29.sxyctestm05， 最后查看已经格式化的 trace 文件，得到丰富的信息。
总结关于 GPFS 的问题分析，主要是要收集 GPFS 的 trace 文件（在 /tmp/mmfs 下面），GPFS 的日志文件（在 /var/adm/ras 下面），还有 DB2 的日志文件和操作系统的日志文件。
RSCT 故障RSCT（Reliable Scalable Cluster Technology）是一系列软件组件的集合，为 IBM 许多集群软件提供可用性，可扩展性及易用性等方面的底层支持。DB2 pureScale 集群也是使用 RSCT 作为底层支持。RSCT 中最基础的概念就是资源。DB2 pureScale 所有相关的软硬件都被定义成了集群的资源。RSCT 会不停检测到集群的这些资源状态。这些状态信息和 RSCT 的日志等都会放在 /var/ct 这个目录下面。在分析资源问题的时候，我们也可以在这个目录下面找到相关资源的日志进行进一步的分析。
RSCT 有很多工具用来操作和管理整个集群。但是对于 DB2 pureScale 用户，DB2 提供了 db2cluster 等工具集成了 RSCT 的工具，更便于 DB2 用户使用。但是某些情况下，我们还是需要使用 RSCT 工具来分析和解决问题。下面还是举一个实际案例。
当用户在安装 DB2 pureScale 集群，或者是为集群增加一个新的节点的时候，可能会失败，用户就需要去查看 DB2 命令 db2icrt 或者是 db2iupdt 产生的日志。在这个案例里面，用户尝试使用 db2iupdt 增加一个新节点失败了，产生了 db2iupdt.log.6160814 日志。
清单 25. 检查 db2iupdt 日志
# cat db2iupdt.log.6160814 DB2 Setup log file started at: Tue Jun 5 13:26:26 2012 GMT+08:00 ...... ERROR: Adding node 'sxyctestm1' to the cluster ... Adding a node to the domain failed. Refer to the diagnostic logs (db2diag.log or /tmp/ibm.db2.cluster.*) and the DB2 Information Center for details. A diagnostic log has been saved to '/tmp/ibm.db2.cluster.p6a3aa'. ERROR: The RSCT peer domain, "db2domain_20120605104620", failed to extend to the host, "sxyctestm1". Failed command: "/opt/IBM/db2/V9.8/bin/db2cluster -cm -add -host sxyctestm1". The RSCT peer domain, "db2domain_20120605104620", failed to extend to the following hosts: "sxyctestm1". For more information, see the post-installation section of this log. ......这个信息说明集群在增加一个节点的时候失败了，失败的命令是 db2iupdt 调用到的 db2cluster 工具，让我们重新定向到去查看另外一个日志 /tmp/ibm.db2.cluster.p6a3aa。
清单 26. 检查 db2cluster 日志
# cat /tmp/ibm.db2.cluster.p6a3aa ............. 2012-06-05-13.29.44.224252+480 E2218A776 LEVEL: Error PID : 5964224 TID : 1 PROC : db2cluster INSTANCE: db2sdin1 NODE : 000 HOSTNAME: sxyctestm0 EDUID : 1 FUNCTION: <0>, <0>, <0>, probe:2695 RETCODE : ECF=0x90000546=-1879046842=ECF_SQLHA_ADD_NODE_FAILED Add node failed DATA #1 : String, 62 bytes libsqlha: sqlhaAddDomainNode() call error from wrapper library DATA #2 : String, 285 bytes Line # : 15193---2632-077 The following problems were detected while adding nodes to the domain. As a result, no nodes will be added to the domain. sxyctestm1: 2632-068 This node has the same internal identifier as sxyctestf1 and cannot be included in the domain definition. ; FFDC ID: DATA #3 : signed integer, 4 bytes 31 .............现在我们看到这其实是一个 RSCT 报出来的问题。RSCT 的错误编号是 2632-068，说明这个节点和集群里的某个节点具有相同的身份（identifier）。这个问题其实很常见。因为在集群环境里面有多个节点，这些节点基本都具有相同的硬件和操作系统。在安装这些节点的时候，管理员经常会使用复制系统的方式。所以很可能被复制的系统具有和原系统同样的 identifier。
解决这个问题就需要使用 RSCT 的工具。首先需要做的是怎么清除这个同一 identifier。作者的建议是重新构建 RSCT 环境，先删除所有 /var/ct 这个目录下面的内容，然后使用 RSCT 的 recfgct 工具重建 RSCT 环境。
清单 27. 使用 recfgct 重建 RSCT 环境
# /usr/sbin/rsct/install/bin/recfgct -s最后重试增加节点终于成功。
如何修复 DB2 pureScale 资源需要修复 DB2 pureScale 资源的情况很少见。但是某些特殊情况下也可能会出现。DB2 会将集群当前的 member 和 CF 配置信息记载在 db2nodes.cfg 文件里面。
清单 28. 查看 db2nodes.cfg 记载的节点信息
$ cat /home/db2sdin1/sqllib/db2nodes.cfg 0 SXYCDBM0 0 SXYCDBM0-ib0 - MEMBER 1 SXYCDBM1 0 SXYCDBM1-ib0 - MEMBER 128 SXYCDBF0 0 SXYCDBF0-ib0,SXYCDBF0-ib1 - CF 129 SXYCDBF1 0 SXYCDBF1-ib0,SXYCDBF1-ib1 - CF为 DB2 的集群服务的 TSAMP 软件会根据当前各资源的状况控制集群节点的分配。例如在某个 member 节点出故障的时候这个 member 会在其他健康的 member 主机上重启。那么这个节点信息就有了变化，这个时候如果出现全局的故障的话，很可能等故障解除后，TSAMP 和 DB2 节点文件记载的信息就可能不匹配，这个时候就需要修复 DB2 pureScale 资源。首先要使用 db2cluster 工具检查资源，如果有问题，还是使用 db2cluster 工具修复资源。
清单 29. 检查资源命令
$ db2cluster -CM -VERIFY -RESOURCES清单 30. 修复资源命令
$ db2cluster -CM -REPAIR -RESOURCES最终整个 DB2 pureScale 集群的资源又恢复到一致性。这是一个异常恢复需要知道的手段之一。
总结本文中总结了在 DB2 pureScale 环境中可能出现问题的方面，并针对这些问题举例说明如何发现和分析问题，最终解决问题。通常 DB2 pureScale 出现故障的时候，最佳实践就是尽可能多的收集各种相关的信息，综合起来分析问题。
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞1作者其他文章
评论 3 · 赞 4
评论 1 · 赞 10
评论 2 · 赞 5
评论 3 · 赞 7
评论 0 · 赞 7
添加新评论0 条评论