DB2 pureScale是IBM在DB2 for LUW平台上推出的一种数据库集群架构，它允许多个成员节点同时访问同一份数据，从而在提供高可用性的同时获得近乎线性的性能扩展能力。对于刚接触这一架构的运维人员和DBA来说，理解它的核心组件和部署流程是上手的第一步。本文将从架构原理、环境准备和实际部署三个方面，系统地介绍pureScale的入门知识。
一、pureScale架构的核心组件与工作原理
pureScale架构由三个关键部分组成：成员、集群缓存设施和集群服务。成员是实际处理数据库事务的数据库服务器，每个成员是一个独立的DB2实例成员，客户端的连接请求会被分配到不同的成员上处理。集群缓存设施简称CF，是整个架构的协调者，它负责维护全局锁、全局缓冲池以及成员之间的数据一致性。集群服务则由TSAMP和GPFS组成，负责监控各节点的健康状态并在故障发生时自动进行接管。
理解CF的角色非常关键。在pureScale中，所有成员共享同一份物理数据，每个成员本地都有自己的缓冲池，但CF中维护了一份页面锁定状态的全局视图。当成员A修改了某个数据页，其他成员中该页的旧副本会被标记为失效，从而保证任何成员读到的都是一致的数据。这种机制使得pureScale可以在不拆分数据的前提下实现多节点并行写入，这与HADR的主备模式、DPF的分区模式都有本质区别。
CF本身也是高可用的，一个pureScale集群中通常配置主CF和备CF两台。主CF故障时，备CF会在几秒内接管，期间成员会被短暂挂起，事务不会丢失。这种设计让pureScale能够在单节点故障甚至CF故障的情况下保持数据库服务连续，RPO接近于零。
二、pureScale与DPF的区别以及适用场景
很多人容易把pureScale和DPF混淆。两者都是多节点架构，但思路完全不同。DPF即数据库分区特性，采用无共享架构，数据按照哈希分布到各个分区上，每个分区只处理落在自己范围内的数据，适合超大规模的数据仓库和分析型负载。而pureScale采用共享磁盘架构，所有成员看到的是同一份数据，应用不需要感知数据的分布位置，天然适合OLTP这类高并发的交易型业务。
从应用改造角度来看，pureScale的优势更加明显。应用程序连接pureScale集群时，只需要配置成员列表，无需关心数据在哪个节点上，分库分表的应用逻辑基本不需要调整。DPF则需要根据分布键来设计表结构，分布键选择不当会导致数据倾斜。因此，如果你的业务场景是银行核心交易、订单系统这类需要强一致性和高并发的场景，pureScale是更合适的选择；如果是海量数据分析，DPF则更有优势。
此外，pureScale支持在线添加成员节点。当业务量增长时，可以直接向集群中加入新成员，过程对应用基本透明，只需要简单调整负载均衡配置即可。这种横向扩展能力是其最大的卖点之一。
三、部署前的环境准备
pureScale对环境的要求比单机DB2严格不少。操作系统方面，Linux平台上推荐使用RHEL或SUSE的特定版本，需要提前安装好对应的补丁包。所有参与集群的主机必须配置域名解析，建议在/etc/hosts中写明所有节点的主机名和IP，并且主机名要符合DB2的命名规范，不能包含下划线等特殊字符。
网络方面，pureScale要求至少两条物理上隔离的网络：一条用于客户端连接和日常管理，另一条专用于集群内部通信，包括CF与成员之间的锁和页面失效消息传递。内部通信网络建议使用万兆网络并配置冗余网卡绑定，否则网络延迟会成为整个集群的性能瓶颈。
存储方面，所有成员和CF必须能访问同一份共享存储，GPFS会在此基础上构建集群文件系统。常见的方案是使用SAN存储或者支持共享访问的NVMe设备。共享磁盘需要划分出用于GPFS文件系统的卷，建议为DB2数据、日志和GPFS管理信息分别规划空间。以AIX环境为例，典型部署前需要确认的几点如下：
# 检查所有节点的主机名解析 cat /etc/hosts # 确认共享磁盘在各节点上都可见 lsdev -Cc disk # 验证节点之间的root SSH互信已建立 ssh node2 hostname # 确认时间同步服务正常，pureScale要求节点间时间偏差极小 ntpdate -q ntpserver
用户和组规划也是重要环节。pureScale安装前需要创建实例用户、隔离用户和GSKit用户等，这些用户的UID和GID在所有节点上必须一致，否则安装过程中会出现权限校验失败的问题。建议提前使用脚本批量创建并核对。
四、安装与配置实例的完整流程
环境检查通过后，就可以开始正式安装。安装DB2 pureScale版本的软件包与普通版基本相同，运行root用户下的db2_install，选择带pureScale特性的版本安装即可。安装完成后，创建pureScale实例使用的是db2icrt命令，但参数与单机实例有明显区别，需要指定成员数量、CF数量以及各主机角色。
下面是一个典型的两成员加两CF的实例创建命令示例：
# 以root身份执行，创建pureScale实例 ./db2icrt -d -a SERVER_ENCRYPT -u db2fenc1 \ -cf casshared1 -cfnet nodecf1-ib0:nodecf1-ib1 \ -cf casshared2 -cfnet nodecf2-ib0:nodecf2-ib1 \ -member casshared1 -membernet node1-ib0:node1-ib1 \ -member casshared2 -membernet node2-ib0:node2-ib1 \ -instance db2inst1 -dev /dev/hdisk10,/dev/hdisk11
参数中-cf指定CF所在主机，-cfnet指定CF的内部通信网络接口，-member和-membernet同理指定成员主机及其内部网络，-dev则指定用于GPFS的共享磁盘设备。命令执行过程中，安装程序会自动完成GPFS集群构建、文件系统创建、RSCT资源配置等一系列动作，整个过程可能持续二十分钟到一个小时，期间不要中断。
实例创建完成后，需要验证集群状态。使用db2instance -list可以查看所有成员和CF的当前状态，正常情况下所有成员应处于STARTED状态，CF应处于PRIMARY和CATCHUP状态：
# 切换到实例用户 su - db2inst1 # 查看pureScale集群整体状态 db2instance -list # 输出示例中应包含类似信息： # ID TYPE HOME_HOST CURRENT_HOST STATE # 0 MEMBER node1 node1 STARTED # 1 MEMBER node2 node2 STARTED # 128 CF nodecf1 nodecf1 PRIMARY # 129 CF nodecf2 nodecf2 CATCHUP
接下来可以创建数据库并开启自动客户端重新路由功能，这样当某个成员故障时，连接会被自动路由到健康成员上：
-- 创建测试数据库 CREATE DATABASE TESTDB AUTOMATIC STORAGE YES; -- 更新数据库配置，启用自动客户端重新路由 UPDATE DB CFG FOR TESTDB USING BLK_LOG_DSK_FUL YES; -- 查看当前连接分布在哪些成员上 SELECT MEMBER_ID, APPLICATION_HANDLE, CLIENT_IPADDRESSES FROM SYSIBMADM.APPLICATIONS;
五、常见问题与排查思路
部署过程中最常见的故障集中在共享存储和网络两块。如果GPFS构建失败，首先检查-dev指定的磁盘是否在所有节点上都可见且未被占用，GPFS的日志位于/tmp下，可以找到具体的报错原因。如果实例创建卡在网络配置阶段，多半是内部通信网络不通或者SSH互信没有配好，可以用ping和ssh逐项验证。
实例运行阶段，如果发现性能不如预期，要重点排查CF的负载情况。通过监控工具查看CF的锁请求和页面失效消息的吞吐量，如果内部网络延迟过高，锁的获取时间会明显变长，事务响应时间随之恶化。此时应考虑升级网络带宽或者将内部通信网络独立出来，避免与业务流量争抢。
成员故障接管也是需要验证的重点。测试时可以手动停止某个成员，观察事务是否被透明地转移到其他成员，客户端应用是否通过自动重新路由机制保持连接。建议在上线前做完整的故障演练，包括成员宕机、主CF宕机、网络闪断等场景，确认各种情况下业务的表现符合预期。
总结来说，pureScale的部署门槛主要在于环境准备的细致程度，网络、存储和用户规划任何一处疏漏都会导致安装失败。建议初次部署先在测试环境完整走一遍流程，记录每一步的输出，形成自己的部署手册后再到生产环境操作，这样可以大大降低出错的概率。
DB2 pureScale数据库集群部署CF组件修改时间：2026-09-11 17:48:44