企业官网建设流程全解析

搞达梦数据库的人，迟早会撞上一个叫DSC的词。DSC全称Data Sharing Cluster，也就是达梦的共享存储集群，双节点是最典型的部署形态：两台服务器各跑一个数据库实例，同时访问同一套存放在共享存储上的数据文件，对外像是一个数据库，业务连接任何一个节点都能读写。这方案的核心价值不是性能翻倍，而是高可用——一个节点挂了，业务不断，另一个节点继续扛。我这次在测试环境完整搭了一遍DSC双节点，存储用的不是昂贵的中端磁盘阵列，而是拿Openfiler搭出的IP SAN存储，整个过程从选型到落地踩了不少坑，这篇就把存储规划、集群配置、启动验证、故障演练逐个环节说清楚，给准备上手达梦DSC的人一份能照着做的参考。

1. 方案拆解：为什么共享存储集群要配Openfiler

1.1 DSC集群的核心组件

达梦DSC在概念上跟Oracle RAC走的是同一条技术路线：多个实例共享一份数据库文件，同时对外提供服务。但它不是简单地让两个dmserver进程指向同一目录就能跑起来的，中间夹着一套完整的集群控制软件，这套东西拆开看主要有三块：

DCR，全称Database Cluster Registry，相当于整个集群的“户口本”。哪个节点在线、哪个节点离线、集群里配了几块盘、盘是干什么用的、各个组件通过什么IP和端口互相找，全都记在DCR盘上。DCR还有一个类似仲裁的职责，节点间出现争议时，由DCR配合CSS来做最终判断。

CSS，Cluster Synchronization Service，集群同步服务，干的是“哨兵”的活。它负责监控各节点状态，维护集群的成员关系，发现某个节点没心跳了就触发隔离动作，防止两个节点同时操作共享数据造成数据损坏——说白了就是防脑裂。

DMASM，达梦的自动存储管理模块，作用跟Oracle ASM类似。有了它，我们不需要把裸盘直接分给数据库，而是先把多块共享盘组成一个磁盘组，数据文件在磁盘组里条带化分布，还可以配置冗余策略。DSC要求所有数据库文件必须放在共享存储上，用DMASM管理会比直接拿一堆裸分区更规范，也方便扩展。

除了这三块，节点间还有MAL通信机制，也就是达梦的消息层。实例之间要互传redo日志、锁信息和缓存块，这些流量全走MAL通道，所以心跳网络的延迟和稳定性对DSC来说极其关键。

1.2 为什么用Openfiler模拟IP SAN

生产环境里的DSC，共享存储一般是中高端磁盘阵列加光纤通道或者IP SAN，存储本身还需要支持SCSI-3持久预留这类特性，用来配合集群做IO fencing。但对于学习、测试、做POC验证来说，弄一台动辄几十万的存储根本不现实。Openfiler就是用来解决这个问题的。

Openfiler是一个开源的存储管理操作系统，基于Linux内核，自带Web管理界面，能提供iSCSI、NFS、SMB等多种存储服务。把一台普通PC装成Openfiler之后，它就变成一台标准的iSCSI Target服务器，数据库节点通过网卡发起iSCSI连接，就能拿到实实在在的共享块设备。双节点同时登录这个Target，看到的是同一批磁盘，DSC就能在这个基础上做集群。

用Openfiler搭IP SAN的另一个好处是便于故障模拟。我想验证存储链路断了之后DSC会有什么表现，直接在一端执行iSCSI登出操作就行，这在真存储上反而不容易操作。对搞测试环境的人来说，这就是低成本高可控的最佳选择。

1.3 本次部署的硬件与网络规划

先说我用的环境，三台机器加一张业务客户端机：

• 节点1（DSC01）：2核4G，CentOS 7.9，两块网卡
• 节点2（DSC02）：与节点1同配置同系统
• 存储节点：Openfiler 2.99，1核2G，两块盘，一张网卡
• 存储规划：一块1GB逻辑卷给DCR盘，一块20GB逻辑卷给DMASM数据盘

网络方面我给每台数据库节点规划了三张网卡，这是DSC部署里很容易被忽略但很重要的点。业务网走数据库客户端连接，心跳网走MAL通信和集群心跳，存储网走iSCSI流量。三张网必须从物理上分开，尤其是心跳和存储不能共用，否则一旦网络拥塞或广播风暴，轻则集群频繁重构，重则直接脑裂。

具体的网络划分如下：业务网段192.168.10.0/24，心跳网段192.168.100.0/24，存储网段192.168.20.0/24。DSC01和DSC02的心跳IP分别是192.168.100.11和192.168.100.12，这两个IP要保证互通且延迟极低，后面所有集群控制流量都走这里。

2. Openfiler存储准备：从安装到iSCSI Target

2.1 Openfiler安装

Openfiler的安装跟装普通Linux一样，镜像刻盘或者写U盘启动，分区、设置root密码、设好IP就能装完。有个要注意的地方，Openfiler的Web管理界面走HTTPS，默认端口是446，不是常见的443，浏览器访问的时候要输完整：https://存储IP:446。

装完之后用openfiler这个账号登录Web界面，默认密码也是openfiler。登录第一件事就是改密码、配置管理网IP，这些基础工作做完，接下来才是正经的存储配置。

2.2 创建卷组和逻辑卷

Openfiler的存储配置逻辑跟LVM是一样的：先建物理卷，再建卷组，最后在卷组上划逻辑卷。左侧菜单选Volumes，可以看到当前服务器上的全部磁盘设备。我这边两块盘，一块做系统盘，一块留给存储，所以只需要把第二块盘加到物理卷里。

把盘加为物理卷之后，创建一个卷组，名字我起的vg_dsc，然后把刚才那块物理盘全部空间划进这个卷组。卷组创建完，接着在卷组上创建逻辑卷。这里有个细节，Openfiler的Volume Type一定要选iSCSI，也就是块设备类型，如果选成File System，后面挂NFS或SMB能用，但iSCSI Target里就找不到了。

我创建了两个逻辑卷：lv_dcr，1GB；lv_data，20GB。不要觉得1GB太小，DCR盘上存的只是集群元数据，整个磁盘组的配置信息加起来不过几百MB，1GB完全够用。数据盘20GB对测试环境也绰绰有余，先连通跑起来再说。

2.3 配置iSCSI Target并验证共享盘

逻辑卷建好之后，要先把iSCSI Target服务打开。左侧菜单System下的Services页面，把iSCSI Target Server的状态设为启用并勾选开机自启。

然后进入Volumes下的iSCSI Targets页面，点Add Target新建一个Target，Openfiler会生成一个IQN，格式类似iqn.2006-01.com.openfiler:tsn.xxxxxxxx。这个IQN就是存储端的标识，后面数据库节点要用它来发现和登录。

Target建好后，要绑定LUN。在Target的LUN Mapping里把刚才的lv_dcr和lv_data分别映射为LUN 0和LUN 1。再往下是访问控制，Openfiler支持按IP或按Initiator IQN来限定哪些客户端能连这个Target。测试环境我图省事，直接按IP把192.168.20.11和192.168.20.12两个存储网IP放行了。生产环境建议用CHAP认证加IP白名单双重控制，不然任何人都能扫到你的存储。

到这里Openfiler侧就配完了。远程登录到数据库节点验证一下能不能发现Target：

iscsiadm -m discovery -t sendtargets -p 192.168.20.10

能看到一条IQN输出就说明网络通、Target存在。接下来在两台数据库节点上分别登录：

iscsiadm -m node -T iqn.2006-01.com.openfiler:tsn.xxxxxxxx -p 192.168.20.10 -l

登录后执行lsblk，能看到新的块设备，我这边是sdb和sdc，大小分别对应1GB和20GB。到这一步，共享存储的雏形就有了。

2.4 数据库节点挂载共享存储并绑定裸设备

这里有个DSC新手最容易犯的错：看到新盘就格式化、建文件系统、挂载目录。达梦DSC用的是裸设备，不能有文件系统，所以分区可以分，格式化和挂载绝对不能干。

我这边对sdb和sdc各建了一个主分区（sdb1、sdc1），保持无文件系统状态。然后通过udev规则把这两个分区绑定成raw设备，绑定有两个好处：一是路径固定，不会因为盘序变化导致路径错乱；二是可以统一设置属主和权限，让dmdba用户有读写权限。

在 /etc/udev/rules.d/60-raw.rules 里写：

ACTION=="add", KERNEL=="sdb1", RUN+="/bin/raw /dev/raw/raw1 %N" KERNEL=="raw1", OWNER="dmdba", GROUP="dinstall", MODE="660" ACTION=="add", KERNEL=="sdc1", RUN+="/bin/raw /dev/raw/raw2 %N" KERNEL=="raw2", OWNER="dmdba", GROUP="dinstall", MODE="660"

生效并验证：

udevadm control --reload-rules udevadm trigger raw -qa

两条raw设备都显示出来就算成功。需要注意raw设备断电重启后不会自动保留，所以这个udev规则必须让它在开机时执行，不然每次重启都要重新绑。

另外强调一点，两台节点挂载的必须是同一批盘。怎么确认？对比lsblk的输出，两台节点看到的sdb、sdc大小和序列号要一致。如果一台看到sdb是1GB另一台看到sdb是20GB，说明盘序乱了，一定要先用iscsiadm登出所有连接，再重新发现登录，确保两边的设备路径语义一致。

3. 双节点数据库环境准备与DM8安装

3.1 系统基础配置

DSC对操作系统层面的要求不少，但核心就三件事：主机名、时钟、防火墙。

主机名要固定，不能是默认的localhost，不然节点起来之后DCR里记录的节点信息会对不上。我这边节点1设置hostnamectl set-hostname dsc01，节点2设置hostnamectl set-hostname dsc02，同时把各自的IP和主机名写进/etc/hosts，确保互相ping主机名能通。

时钟同步这块容易被忽视。DSC节点之间的时间差一旦超过阈值，日志时间戳会错乱，严重的会触发实例异常退出。我用的chrony，两台节点都指向同一台NTP服务器，至少保证节点之间的时间偏差在毫秒级。查时间同步状态用chronyc tracking，确认系统时间一致后继续。

防火墙和SELinux也必须处理。DSC涉及大量端口，包括DCR的7236、CSS的7237、ASM的7238、MAL的7239/7240，以及数据库的5236等。测试环境我直接把防火墙关掉，SELinux设为permissive，省去一堆放行规则的麻烦。生产环境建议按端口粒度放行，别嫌麻烦。

3.2 创建dmdba用户与安装目录

达梦数据库不允许root直接运行数据库服务，所以要创建专用用户。我先建用户组：

groupadd dinstall useradd -g dinstall -m -d /home/dmdba dmdba

然后创建安装目录并改属主：

mkdir -p /dm8 chown -R dmdba:dinstall /dm8

两个节点的用户和目录结构要保持一致，安装路径也一致。这一点对DSC尤其重要，因为后面DCR拉起ASM和数据库时会用到绝对路径，如果节点1装到/dm8、节点2装到/opt，那DCR配置就没有统一的路径可写，启动必挂。

3.3 安装达梦DM8数据库软件

达梦的安装包是ISO文件，挂载后执行解压出来的DMInstall.bin。服务器没有图形界面的话，用命令行模式安装。安装过程中会问license文件路径，没有正式授权文件可以直接跳过，用试用key先顶着。后面拿到正式key，覆盖DM_HOME目录下的dm.key文件再重启数据库就完成替换，不需要重装软件。

安装内容选“服务器”组件就够了，测试环境不用装客户端工具。安装路径我填的是/dm8。安装完后，把环境变量写进dmdba用户的~/.bash_profile：

export DM_HOME=/dm8 export PATH=$DM_HOME/bin:$PATH export LD_LIBRARY_PATH=$DM_HOME/bin:$LD_LIBRARY_PATH

然后执行安装包自带的root脚本：

/dm8/script/root/root_installer.sh

这个脚本会注册一些系统级服务配置，不跑的话后面注册服务可能有问题。两台的达梦软件版本要一致，最好用同一个安装包，小版本不一致可能导致集群行为异常。

4. 读懂DSC配置：DCR、CSS、ASM三大件的配置文件

4.1 DCR/CSS/ASM分别承担什么角色

在动手写配置之前，先把角色理清楚。很多人卡在DSC配置看不懂，就是因为不知道每个配置文件是给谁看的。DCR负责记录集群所有组件的运行状态和元数据，它的持久化信息放在共享的DCR盘上。CSS是集群健康的守护者，它和DCR配合保证同一时刻只有一个节点能正常操作共享数据。DMASM则是存储管理，把多块共享盘组成磁盘组供数据库使用。

对应到软件上，达梦提供了三个后台进程：dmcss、dmdcr、dmasmsvr。启动顺序是CSS先起，DCR接着起，DCR会自动拉起ASM，最后数据库实例起来。这套依赖关系在后面的启动流程里会体现得很明显。

4.2 dmdcr_cfg.ini核心参数解读

dmdcr_cfg.ini是所有节点共用的集群配置文件，也是初始化DCR盘的依据。它定义集群的OGUID、节点列表、端口、DCR盘路径和ASM盘路径等多个关键信息。我把核心参数列一下：

# DCR段全局配置，OGUID是集群唯一标识，所有节点必须一致 DCR_OGUID = 63635 # DCR通信端口，节点之间通过该端口交换集群状态信息 DCR_INTF_PORT = 7236 # 集群第一个节点的序号 DCR_FIRST_EP = 0 # DCR共享盘路径，必须是共享裸设备 DCR_DISK_PATH = /dev/raw/raw1 DCR_DISK_SIZE = 1024 # CSS段配置 [CSS] CSS_OGUID = 63635 CSS_INTF_PORT = 7237 CSS_EP_HOST[0] = 192.168.100.11 CSS_EP_PORT[0] = 7237 CSS_EP_HOST[1] = 192.168.100.12 CSS_EP_PORT[1] = 7237 # ASM段配置 [ASM] ASM_OGUID = 63635 ASM_INTF_PORT = 7238 ASM_MAL_HOST[0] = 192.168.100.11 ASM_MAL_PORT[0] = 7239 ASM_MAL_HOST[1] = 192.168.100.12 ASM_MAL_PORT[1] = 7239 ASM_EP_HOST[0] = 192.168.100.11 ASM_EP_PORT[0] = 7240 ASM_EP_HOST[1] = 192.168.100.12 ASM_EP_PORT[1] = 7240

ASM共享盘路径这里没在cfg里写，因为ASM盘的注册是在DCR启动之后通过dmasmtool完成的，cfg里只需要把节点和通信信息定义好。每次改配置都要检查OGUID，这个数字相当于集群的暗号，任何一个节点的任何组件对不上，集群就起不来。

4.3 各节点的dmdcr.ini、dmmal.ini与dmasvrmal.ini

dmdcr_cfg.ini是公共配置，而dmdcr.ini是每个节点本地的启动配置，两个节点内容类似但DMDCR_SEQNO不同。节点1的dmdcr.ini核心内容：

DMDCR_CFG_PATH = /dm8/data/DSC/dmdcr_cfg.ini DMDCR_OGUID = 63635 DMDCR_SEQNO = 0 DMDCR_ASM_RESTART_INTERVAL = 10 DMDCR_ASM_STARTUP_CMD = /dm8/bin/dmasmsvr DMDCR_DB_RESTART_INTERVAL = 10 DMDCR_DB_STARTUP_CMD = /dm8/bin/dmserver /dm8/data/DSC/DSC01/dm.ini

节点2的DMDCR_SEQNO改成1，DMDCR_DB_STARTUP_CMD指向本地的/dm8/data/DSC/DSC02/dm.ini。这个文件是让dmcss和dmdcr启动时知道去哪儿找公共配置、自己在这个集群里排第几号、异常退出后要不要自动拉起ASM和数据库以及用什么命令拉起。

dmmal.ini是数据库实例之间的MAL通信配置，同样每个节点各持一份，内容一样。两个实例在这里定义实例名、心跳IP、MAL端口。实例名很重要，后面所有日志和视图都靠它区分节点，我这边一个叫DSC01一个叫DSC02。dmasvrmal.ini则是对ASM实例的MAL配置，格式类似，用来让两个节点的ASM实例之间建立通信。

4.4 配置分发注意事项

配置文件修改是DSC踩坑重灾区，我总结三个原则：第一，公共配置（如dmdcr_cfg.ini、dmmal.ini）两份节点必须完全一致，要养成改完就对比md5的习惯；第二，本地配置（如dmdcr.ini）里的序号和路径不能搞混，节点1的SEQNO写0、节点2写1，写反了DCR盘被初始化两次直接报废；第三，所有文件统一放在/dm8/data/DSC目录下，路径保持一致，至少排查问题的时候不用费脑子记谁在哪个目录。

5. 集群初始化与启动全流程

5.1 初始化DCR磁盘

配置写完，先在节点1上初始化DCR盘。这个操作会在共享盘上写入集群元数据，只做一次，整个集群只有这一份DCR盘。

执行：

/dm8/bin/dmdcr -i

交互式命令会读dmdcr_cfg.ini，然后提示确认OGUID、DCR盘路径、节点IP等信息，一步一步确认完，日志里出现初始化成功字样就完成了。初始化之后再执行同样的命令就会提示磁盘已存在，这时候停下来，千万别想着再初始化一次，DCR盘内容被覆盖，整个集群就得从头搭。

5.2 启动CSS与DCR

DCR盘初始化后，在节点1的执行：

/dm8/bin/dmcss /dm8/data/DSC/dmdcr.ini

启动后窗口会挂着日志输出，看到CSS服务正常启动、等待DCR连接的信息，就说明CSS活着了。接着开另一个窗口启动DCR：

/dm8/bin/dmdcr /dm8/data/DSC/dmdcr.ini

DCR启动后会自动执行dmdcr.ini里配置的ASM启动命令，拉起本节点的dmasmsvr。这时候等一小会，查看进程：

ps -ef | grep -E "dmcss|dmdcr|dmasmsvr"

三个进程都在，节点1的集群底座就算立起来了。然后到节点2上以同样方式启动CSS和DCR。节点2的DCR起来后会通过DCR盘发现节点1已经在线，两边握手完成，集群成员关系建立。

5.3 通过dmasmtool创建ASM磁盘组

CSS和DCR跑通后，节点1的ASM实例已经在运行，但还没有磁盘组。用dmasmtool连上去创建：

/dm8/bin/dmasmtool dcr_ini=/dm8/data/DSC/dmdcr.ini

进入交互界面后执行：

create diskgroup 'DSCDATA' type external disk '/dev/raw/raw2'

这条命令把整块/dev/raw/raw2作为external冗余的磁盘组DSCDATA。external意味着不做镜像，靠存储自身保障数据安全。测试环境用external足够，生产环境如果要达梦ASM做镜像，需要至少两块盘组normal类型。

创建成功后在dmasmtool里查询磁盘组：

lsdg

看到DSCDATA状态正常，这一步就过了。ASM磁盘组创建好，数据库文件才有地方放。

5.4 用dminit初始化共享数据库

在节点1用dminit初始化数据库，数据文件路径指向ASM磁盘组：

/dm8/bin/dminit path=+DSCDATA db_name=DSC instance_name=DSC01 sysdba_pwd=Dmdba123 sysdba_priv=3

这里的db_name是数据库名字，集群内所有实例共享同一个db_name；instance_name是当前实例的名字，跟dmmal.ini里定义的DSC01保持一致。初始化完成后，数据文件、控制文件都在ASM磁盘组里，同时会在本地生成一份dm.ini，默认位于/dm8/data/DSC/下的DSC01目录（具体路径取决于安装和dminit输出）。

节点2不需要再跑一次dminit，数据文件已经在共享盘上了，只需要准备自己的本地dm.ini。最可靠的做法是把节点1生成的那份dm.ini复制到节点2，把里面的instance_name改成DSC02，同时检查MAL相关配置是否与本节点相符。

5.5 启动双实例并验证集群状态

所有配置就绪后，DCR会自动拉起数据库实例。回到DCR所在窗口，或者手动执行：

/dm8/bin/dmserver /dm8/data/DSC/DSC01/dm.ini

节点1实例启动，再在节点2执行类似命令启动DSC02实例。两个实例都起来后，用disql连接验证：

disql SYSDBA/Dmdba123@192.168.10.11:5236

查询实例状态：

select INST_NAME, STATUS$ from v$instance;

正常的话会返回两行，DSC01和DSC02都处于OPEN状态。看到这个结果，达梦DSC双节点集群就算正式跑起来了。还可以在任意节点创建一张测试表插入数据，再到另一个节点查询，能查到就说明确实是共享一份数据，不是各自为政。

6. 故障模拟：DSC到底能不能扛住节点宕机

6.1 模拟方案设计

集群搭完不验证等于白搭。我设计了两轮故障模拟：第一轮杀掉一个数据库实例进程，看集群能不能自动恢复；第二轮直接断掉一个节点的心跳网络，看会不会脑裂、会不会出现双主。

在模拟之前，先在业务客户端跑一个持续插入脚本，让数据库一直有写入流量，这样才能真实验证故障切换时业务是否中断。

6.2 节点进程异常退出后的自动拉起

在节点1找到dmserver进程并直接kill：

ps -ef | grep dmserver | grep -v grep kill -9 <pid>

正常情况下，节点2的CSS会通过心跳发现节点1实例消失，DCR根据dmdcr.ini里的DMDCR_DB_RESTART_INTERVAL设置，在10秒左右重新拉起节点1的dmserver。观察节点1的窗口或日志，能看到进程被自动拉起、重新申请资源、重新加入集群的完整过程。

业务侧的表现是连接有短暂抖动，但不需要人工干预，数据库服务整体没有停摆。连续插入的脚本会偶发重连，但应用层配了连接池的话基本无感知。这个场景模拟的就是最常规的实例崩溃，DSC对此有比较成熟的自动恢复机制。

6.3 断网场景下的脑裂防护

第二个模拟更狠一点，我直接停掉节点1的心跳网卡：

ifdown eth1

心跳断了之后，节点2无法感知节点1的状态，但节点1可能还活着、还在操作共享数据，这就具备脑裂条件。这时候就要靠CSS的隔离机制。过一段时间查看节点2的CSS日志，能看到它把节点1标记为故障，并尝试通过存储侧操作隔离对方，保证只有节点2能继续访问共享数据。

恢复心跳网卡，节点1重新连上集群后，观察两个节点的v$instance，最终状态会重新回到双节点OPEN。这个测试非常直观地说明了为什么DSC不能省心跳网——没有独立的低延迟心跳，脑裂时根本来不及做隔离决策。

7. 常见问题与避坑指南速查

7.1 高频故障与排查思路

这七个问题是我这次搭建中真实遇到或排查过的高频项，其中裸设备权限和OGUID不一致占了八成的问题。遇到集群起不来，别急着怀疑达梦，先按顺序检查：存储盘两边是否一致、裸设备权限是否到位、配置文件有没有差异、心跳网络是否畅通。

7.2 我自己踩过最深的三个坑

第一个坑是共享盘被当成普通盘用。最开始我在节点1上把/dev/sdb1格式化成了ext4并挂载到目录，想在挂载点里建数据文件，结果另一台节点根本看不到文件，反而dminit初始化时直接报错。后来才彻底理解了共享存储集群的逻辑：数据文件必须放在没有文件系统的裸设备或ASM磁盘组里，文件系统本身就会破坏共享语义。

第二个坑是Openfiler的LUN映射完成后忘了设置写权限。iSCSI连上了、lsblk也能看到盘，但所有写操作都报权限错误。进Openfiler的iSCSI Target页面检查LUN Mapping，才发现映射的访问模式是只读，改成读写后问题消失。这类看似高深的问题往往就是配置界面里一个选项没选对。

第三个坑是节点2复制dm.ini时漏改了实例名。两个实例都用DSC01启动，导致集群里出现两个同名实例，DCR判定异常，节点2的实例一直起不来。排查了半天，最后一条grep INSTANCE_NAME dm.ini就发现了问题。配置文件这种事，靠肉眼检查就是会漏，最好用diff对比，改完立即看日志。

8. 写在最后的一点实操体会

这套DSC环境从存储到集群全部跑通之后，我自己最大的感受是：共享存储集群的搭建门槛并不在数据库本身，而在对“共享”二字的理解是否到位。磁盘是共享的，路径要一致，配置要一致，连权限都要一致——它不是一个独立实例的加倍，而是一整套分布式协调逻辑。用Openfiler做存储有一个额外好处，就是排查问题更透明，iSCSI层、裸设备层、DCR层、数据库层逐层都能看到日志和状态，出了问题容易定位。对想学达梦DSC的人来说，这套环境从成本到效果都合适，照着我这个流程走一遍，再回头去看官方手册里的原理章节，会顺畅很多。后续如果想继续深入，还可以试试在这个基础上把归档配置打开做DSC两节点联机备份，或者用达梦的DMSQL工具做更多集群运维验证，方向很多，但底子就是今天这套双节点共享存储。