先说下背景最近有同行在群里问能不能用虚拟化平台搭一套国产数据库的共享存储集群也就是常说的DSC。我刚好在国产安全操作系统6.0上完整走过一遍从虚拟机创建、共享盘挂载、数据库安装到集群初始化、故障切换验证踩了不少坑也总结出一套能直接照着做的流程。这篇文章就把整个实操过程写透包含架构规划、参数配置、启动顺序和问题排查给正准备做同类验证环境的同学一个参考。1. 方案背景与适用场景1.1 这套组合解决什么问题DSC全称是共享存储集群核心思路是多个数据库节点共用同一份数据文件通过集群件协调访问对外提供高可用和负载均衡能力。跟常见的“主备复制”不同DSC不需要数据同步环节因为数据本来就在共享盘上所有节点读写的都是同一份数据。这样做的优势很明显主节点故障后另一个节点可以立刻接管服务RTO可以做到秒级多个节点同时承担业务流量把读能力横向扩展出去不存在主备复制常见的延迟问题数据实时性一致。我在虚拟化平台上搭这套环境的直接原因是为了验证数据库集群在不同部署场景下的表现。物理机成本高、排障麻烦虚拟化平台用共享虚拟磁盘模拟SAN存储跑两节点DSC非常合适既能验证功能又方便快照回滚。对想要学习国产数据库集群、或者需要给项目做POC验证的人来说这套虚拟化搭建路径是最快上手的方式。1.2 架构拆解整个架构由以下部分组成两台虚拟机节点分别部署数据库实例和集群服务一块共享虚拟磁盘所有节点通过SCSI总线同时访问三张网卡一张业务网、一张节点互联专用网、一张管理网集群件服务负责节点心跳检测、存储管理、资源编排数据库实例负责接收应用请求、执行SQL、维护事务一致性。关键在于“共享存储”。虚拟化平台给虚拟机添加磁盘时如果选择普通磁盘每个节点只能看到自己那块要模拟SAN必须创建“共享虚拟磁盘”让两个节点挂在同一个SCSI设备上。这个细节很多人第一次做会忽略导致明明两块盘内容一样节点却各写各的集群根本起不来。1.3 适合谁来参考这篇文章适合三类人对国产数据库感兴趣想在本地虚拟环境里体验DSC特性的开发者需要为项目提供高可用方案验证的DBA或架构师刚接触集群部署想理解共享存储、心跳机制、集群件协作原理的运维新人。如果你已经有一定Linux基础知道基本的命令操作那照着这篇文章做基本不会卡壳。如果完全没接触过也可以把每个步骤当成实验操作来执行我会把那些容易踩坑的地方单独标出来。2. 环境规划与前置准备2.1 硬件与虚拟化平台资源配置测试环境的资源规划直接影响集群稳定性不能随手乱给。数据库集群有两个特殊点共享盘I/O性能和节点间网络延迟。虚拟化平台上的资源分配建议如下项目建议配置说明虚拟化服务器内存不低于16GB两个节点各6GB剩下给虚拟化平台自身每节点CPU4核测试够用生产至少8核起业务网千兆应用连接数据库使用互联专用网千兆独立网段节点间心跳和数据传输重要性最高管理网任意SSH登录、维护用共享盘总容量60GB以上包含仲裁盘、数据盘、日志盘特别强调互联专用网。DSC节点之间需要频繁交换协调信息如果心跳网络不稳定集群会频繁误判节点故障导致成员关系反复调整业务中断不可避免。虚拟化平台创建网络时要保证互联网段的物理端口隔离虚拟交换机上不要让其他业务流量挤占带宽。2.2 虚拟机的创建与共享磁盘配置创建虚拟机时三个节点很多配置是相同的我直接给出可以“抄作业”的参数操作系统选择Linux 64位内核版本按国产操作系统的实际版本来选磁盘控制器选择LSI Logic SAS不要选NVMe后面共享盘配置会受限内存6GBCPU 4核网络先加三块分别对应业务网、互联网、管理网。重点来了共享虚拟磁盘的创建。虚拟化平台的图形界面里给虚拟机添加硬盘时有一个“磁盘模式”或“共享”选项。两块节点必须把共享盘挂在同一个SCSI控制器上而且SCSI设备编号要一致。实际操作步骤先创建节点A添加三块普通系统盘、一块共享盘。选择共享盘对应SCSI控制器改成“共享”模式。创建节点B时操作系统盘新建共享盘不再“新建”而是“使用现有磁盘”选中节点A那块共享盘。确认节点B里这块盘的SCSI控制器编号与节点A一致比如节点A是SCSI 1:0节点B必须也是SCSI 1:0。很多人在第4步翻车。虚拟化平台默认自动分配控制器编号如果节点B挂载后编号变成1:1节点A是1:0两个节点看到的是同一块物理盘、但SCSI地址不同数据库ASM层可能识别异常。排查时先看/sys/class/scsi_host/下的设备映射再确认盘符一致性。共享盘建议直接给“裸设备”不需要分区格式化。操作系统能识别到/dev/sdb这个块设备即可文件系统层的工作全部交给数据库的存储管理组件去处理。2.3 操作系统安装与初始化检查操作系统安装过程不多说需要注意几个点安装时创建普通用户比如dba_user后面数据库软件统一用这个用户管理别用root操作磁盘分区给/opt和/data留足空间软件和数据目录分开安装完成后立刻做快照方便后面配置出错来回滚。装完系统进入初始化检查阶段。先确认共享盘两个节点都能识别lsblk正常应该能看到同样名称和容量的共享盘。接着确认共享盘上没有被挂载过文件系统blkid /dev/sdb如果返回空说明是干净裸设备。如果显示了文件系统信息说明前面不小心格式化了需要重新处理。这块盘从创建到集群初始化完成之前都不要执行mkfs操作。网络这块按规划配置静态IP。节点间的互联网卡建议配置独立网段例如节点A互联IP10.10.1.1节点B互联IP10.10.1.2业务网和管理网各自使用自己的网段。配置完后用ping双向验证特别是互联网卡之间延迟要稳定。还有一个容易被忽略的防火墙和SELinux。测试环境为了省事可以直接关闭。生产环境则建议放行对应端口而不是全部关闭。在国产操作系统上我习惯的做法是systemctl stop firewalld systemctl disable firewalldSELinux设为permissive避免因为安全策略拦截数据库进程的共享内存访问。3. 数据库软件安装与系统参数调整3.1 安装用户与目录规划数据库软件不建议装在root目录下也不建议用root直接启动数据库进程。创建一个专门的系统用户比如dba_user用户组设为dba_group。这一步的目的是最小权限隔离数据库进程即使出现安全漏洞攻击者拿到的只是受限用户的权限无法直接控制整个操作系统。目录规划遵循“软件、数据、日志分离”的原则/opt/db8数据库软件安装目录/data/db8data数据库中数据文件存放目录/data/db8arch归档日志目录/home/dba_user用户家目录保存配置文件模板、脚本等。挂载共享盘时不需要在操作系统层做挂载共享盘目录直接映射为数据库存储管理的磁盘路径。3.2 内核参数与资源限制调整数据库集群正常运转需要依赖多项操作系统资源常见的内核参数包括共享内存、信号量、文件句柄等。DSC模式下还需要额外注意IPC资源因为集群件和数据库实例之间要通过共享内存通信。我把最关键的两类配置列出来。第一类资源限制在/etc/security/limits.conf中添加dba_user soft nofile 65536 dba_user hard nofile 65536 dba_user soft nproc 16384 dba_user hard nproc 16384 dba_user soft stack 10240 dba_user hard stack 10240nofile对应进程能打开的最大文件数。数据库连接池大的时候单进程文件描述符消耗非常快默认1024很容易撑满。nproc限制进程数量集群启动时会在各节点启动多个代理进程太小会启动失败。第二类内核参数在/etc/sysctl.conf中调整fs.file-max 65536 kernel.sem 250 32000 100 128 kernel.shmmax 68719476736 kernel.shmall 4294967296 net.ipv4.ip_forward 0 net.ipv4.conf.all.rp_filter 2 net.ipv4.conf.default.rp_filter 2shmmax是单个共享内存段的最大字节数建议设为物理内存的一半以上。如果系统内存只有8GB设成4GB也就是 4294967296 字节测试环境12GB内存我习惯直接设 6871947673664GB确保数据库实例启动时的共享内存段不会被拒绝。rp_filter是反向路径过滤设置为2松散模式避免因为多网卡路由问题导致集群节点间通信丢包。kernel.sem参数是信号量格式为SEMMSL SEMMNS SEMOPM SEMMNI。数据库使用System V信号量来协调进程访问默认值往往偏小。330行级别的并发连接压力下默认128 32000 100 128勉强够用但DSC集群每个节点还要叠加集群件进程建议放宽。修改完执行sysctl -p生效用ulimit -a验证nofile和nproc是否已经生效。重启系统后这些配置要保持建议做完所有修改后再重启一次确认各项参数自动加载。3.3 数据库软件安装与常见报错数据库8支持命令行静默安装和图形化安装两种方式。远程服务器没有图形界面的情况下我用的是命令行方式。安装前确认安装介质所在目录已经挂载到系统比如/mnt/db8_install。执行安装引导命令指定安装类型为“服务器版本”安装路径为/opt/db8。安装过程有几个需要留意的地方安装用户必须对目标目录有写权限如果/opt是root所有需要先chown安装过程中会检查操作系统依赖如果报缺少某某库用包管理器补齐后再重新执行不要在安装过程中同时操作共享盘那会让存储管理组件初始化读到错误数据。常见的报错是依赖包缺失比如缺少libaio、libnuma等。国产操作系统通常会预装大部分但最小化安装的系统容易漏。安装完成后执行环境变量初始化source /opt/db8/source_env.sh确保DM_HOME、PATH、LD_LIBRARY_PATH都指向正确。这个脚本类似Java的JDK环境配置少一步就会导致后面命令找不到。提示安装完成后先不要急着做集群初始化。先确认数据库单机模式能启动排除软件安装本身的问题再进入DSC配置阶段。否则集群起不来的时候很难判断是安装问题还是配置问题。4. DSC集群配置与初始化4.1 集群配置的核心原理DSC集群的家族关系可以理解为三部分协作集群同步服务CSS负责节点间的故障检测、成员管理、投票仲裁集群资源服务CRS负责管理各个资源进程比如ASM实例、数据库实例存储管理组件ASM负责管理共享磁盘把它划分成若干磁盘组供数据库使用。类比一下CSS相当于小区物业负责发现哪户人家还在、哪户失联了CRS相当于房屋管理员负责让每户的电器正常启动运行ASM相当于自来水管网让每家都能从公共管道的同一水池取水。搞清这个关系后配置顺序就很清晰了先在共享盘上规划出一块区域存放集群元数据类似于“物业档案”配置节点信息让每个节点的CSS、CRS都知道自己和其他节点的IP、端口初始化存储管理组件让它接管共享盘再把数据库实例建在这些磁盘组之上。4.2 配置文件与共享盘规划配置过程中每个节点需要一个配置文件记录节点编号、互联IP、业务IP、设备路径等信息。我把关键的参数结构整理如下节点编号区分0号节点和1号节点互联IP节点间心跳和数据传输的专用地址ASM磁盘路径共享盘对应的块设备路径CSS和CRS监听端口集群通信端口。共享盘规划也是需要提前计算的。以一个60GB共享盘为例我习惯分成三个磁盘组用途容量说明元数据库2GB存放DCR配置、集群状态信息ASM磁盘组8GB存放ASM元数据管理磁盘分配数据磁盘组50GB数据库的数据文件、控制文件、日志文件这个规划不是随便拍的。元数据和ASM元数据虽然占用不大但分配空间太小日志增长或磁盘组扩区时会直接卡住集群。数据磁盘组尽量留足余量DSC环境下数据文件自动扩展后如果磁盘组满了处理起来比单机麻烦得多要停下来扩容影响面是整集群。4.3 初始化集群环境配置完成后进入初始化环节。核心操作包括执行集群环境初始化工具向共享盘的元数据库区域写入配置初始化ASM磁盘组让存储管理组件识别并接管共享盘启动CSS和CRS服务验证节点成员关系正常。初始化过程中两个节点不能同时执行必须在一个节点上执行成功后再启动另一个节点。这个顺序错误是新手最容易踩的坑。DSC的元数据写入是排他性的双节点同时操作会导致配置数据互相覆盖结果可能是两边都拿到半套配置集群根本无法识别对方。初始化成功标志是两个节点都启动CSS、CRS后通过状态查看命令能看到对方节点已经在线成员关系稳定。4.4 建库与数据文件放置集群环境就绪后下一步是创建数据库实例。这里也要注意建库动作只需要在其中一个节点上执行一次。数据库创建工具会读取已经配置好的共享存储信息把控制文件、数据文件、日志文件都写到共享盘的对应位置。建库时几个关键参数数据库名集群内唯一实例名节点0和节点1各自不同数据文件路径指向共享盘的数据磁盘组路径不能指向本地盘字符集和时区所有节点保持一致否则汉字乱码、时间不一致会引发很隐蔽的数据问题。建库过程完成后到另一个节点上确认能正常识别到数据库实例。此时不应该直接启动还要把各节点的归档参数、日志参数配置好。4.5 注册服务与开机自启数据库集群正常运行时需要常驻多个进程。手动启动是可行的但是测试环境重启后还需要逐个拉起太容易漏掉。正确做法是把集群服务注册成系统服务。注册的核心流程编写服务管理脚本放到系统服务目录指定服务启动用户为dba_user设置启动顺序CSS、CRS必须先于数据库实例启动设置关机时的停止顺序防止未正常退出的实例破坏共享盘上的元数据。开机自启顺序特别重要。DSC依赖CSS稳定运行来维护成员关系如果数据库实例先于CSS启动实例会发现自己无法连接集群服务然后退出。我最初配置时偷懒所有服务一股脑全设为自启重启后集群总是起不来后来检查日志才发现是顺序问题。强行设定依赖关系之后问题才解决。5. 集群验证与故障切换测试5.1 正常启动与状态检查验证阶段先从正常启动开始。建议用一个状态检查命令把整个集群的成员关系、资源状态、实例状态一次性看清楚。至少需要覆盖节点之间是否有正常的双向通信磁盘组是否处于在线状态两个数据库实例是否都正常打开并能对外提供连接各节点的监听是否正常。还要用SQL做基础功能验证比如新建一张表、插入几条数据然后在两个节点分别执行查询都能看到一致的数据。因为底层共享的是同一份数据文件两个节点查到的结果天然就是一致的这里验证的是两个实例都能正常访问共享存储而不是本地缓存中的数据。5.2 故障切换与恢复验证故障切换测试是整个实操里最有价值的环节。最常见的测试方法是直接模拟节点故障。比如对节点A执行强制断电操作观察节点B的行为。正常情况下几秒到十几秒内集群会检测到节点A失联自动把节点A上的连接全部转移到节点B业务侧只感受到一次连接闪断。测试时注意观察几个时间点从故障发生到集群判定节点A故障的时间从判定故障到节点B完成资源接管的时间业务连接恢复的时间。这三个时间都要记录能直观了解集群性能和配置是否合理。如果第二个时间很长说明节点B的某些资源进程没有提前预配好或者磁盘繁忙导致目录读取慢。恢复节点A后不要急着把业务切回去。等节点A重新加入集群观察成员状态是不是恢复到双节点在线然后再通过手动切换或者负载策略把部分连接导回节点A。这样逐步切的方式可以验证节点的“加入后再接管”流程而不只是简单的“故障后接管”。5.3 日常维护命令速查日常维护中会反复用到几类操作整理成速查表操作说明查看成员状态确认所有节点都在线且角色正确查看资源状态确认CSS、CRS、ASM等进程状态正常查看数据库实例状态确认实例打开状态、会话连接数查看磁盘组使用率确认共享盘空间是否充足手动停止整个集群按顺序停止业务连接、实例、资源服务、集群服务正常关机的顺序是先断开应用连接再停止数据库实例接着停止ASM资源最后停止CSS各CRS。任何一步跳过都可能导致下次启动失败。特别是CSS直接退出时其他节点可能把该节点标记为“异常心跳超时”下次启动要额外做状态清理。6. 常见问题与排查实战6.1 共享盘识别异常现象两个节点看到的共享盘大小不一致或某个节点完全没有共享盘设备。排查思路先看虚拟化平台中两块虚拟机是否都指向同一块共享虚拟磁盘再确认SCSI控制器的共享模式是否已经开启最后检查两个节点的SCSI设备编号是否一致。这种情况九成以上是SCSI控制器编号不一致导致的。我在4.2节反复强调过虚机创建时的设备编号就是因为实操中遇到太多次了。两边编号不同虽然操作系统都能识别到设备但数据库集群认为它们访问的不是同一块盘导致DSC启动报错。6.2 集群启动阻塞、成员状态异常现象开CSS后进程一直在等待或者两个节点互相看不到对方有时状态命令显示只有一个节点。排查思路先ping互联IP确认通信正常再看防火墙是否放行了集群通信端口然后检查配置文件中的节点编号、IP是否写错最后看共享盘元数据区域是否只有某一个节点写入了配置。如果配置无误但节点始终无法同时在线多半是共享盘元数据冲突。真正有效的处理方式不是反复重启而是停掉所有节点的集群服务重新规划共享盘元数据区域同步配置文件后再启动。6.3 性能下降或频繁切换现象集群运行一段时间后频繁发生节点切换SQL执行变慢。排查思路优先检查互联网卡流量是否被打满心跳包丢包率是否升高重点观察共享盘I/O等待时间虚拟化平台上两块共享磁盘的实际吞吐量是否够用。DSC对网络和存储的敏感度比单机高很多。虚拟化平台共享虚拟磁盘本质是所有节点通过同一个SCSI总线并发访问并发量上升后I/O排队自然变严重。虚拟化平台层面要把共享盘所在的存储控制器设置好缓存策略不要把缓冲关闭。如果磁盘本身是机械盘两节点同时跑大量随机读写性能非常难看。6.4 断电恢复后集群无法自启现象虚拟化平台异常断电所有虚拟机强制关机重新启动后数据库集群卡在某个节点无法恢复。排查思路先手工启动集群服务观察日志中是否有磁盘元数据损坏的报错如果报错可能是断电瞬间共享盘有部分数据没写全遇到这种情况不要反复尝试应该从备份恢复元数据区域再逐节点拉起服务。这种场景全靠快照救场。所以我反复强调装完系统、配置完DSC后都要打快照。快照是虚拟化环境做集群实验最有效的一道保险。提示所有故障排查过程中除非明确知道问题原因否则不要在两台节点同时执行“暴力修复”操作。先停一台节点保留一个稳定节点再在另一个节点排查。两个节点同时重启或同时清理元数据只会让问题放大。7. 个人经验总结与扩展建议操作完这套DSC我最大的体会是集群能不能稳定跑起来关键不在数据库本身而在前置的存储和网络规划。共享盘访问一致性、心跳网络稳定性、节点退出顺序这三个环节任何一个掉链子都会暴露成集群层面的故障。对准备上手的人我给出几点经验虚拟化平台的共享盘创建时SCSI控制器编号务必保持一致集群配置文件的节点信息、IP信息先写好文档再填配置不要凭记忆录入不要跳过连通性测试直接做集群初始化多花五分钟验证能省下后面几小时的排障时间所有修改配置前保留快照DSC实验最大的成本是定位问题的时间而不是操作本身故障切换测试一定要做而且要多次做尤其要覆盖断电场景、存活节点同时故障场景不要只测优雅关机。最后再分享一个小技巧DSC环境的监视和日志收集务必提前配置好包括操作系统日志、集群日志、数据库实例日志、ASM日志并设置日志轮转。集群故障排障时最怕的是日志文件已经滚掉了关键信息全部丢失。我在一次模拟故障中发现节点进程异常退出但因为日志只保留了最近几分钟真正的根因信息早被覆盖只能靠猜测和反复复现来定位非常浪费时间。如果一开始就做好日志归档这类问题几分钟就能定位。后续如果条件允许这套环境还可以继续扩展比如增加第三个节点验证成员扩展流程把备份策略改成自动归档加异地存放再把监控告警接入运维平台。虚拟化平台下DSC的验证空间其实很大基础打好之后每一次扩展都是在往生产环境的复杂度靠拢。