虚拟机配置RAC，核心要点集中在存储共享、网络心跳、时间同步和资源分配四个维度，任何一个环节出错都可能导致集群无法正常启动或频繁节点驱逐。下面我把实操中容易踩坑的关键步骤和细节做一个系统梳理,希望能帮你少走弯路。
虚拟机配置RAC，存储规划如何避坑
共享磁盘是RAC的基石，不能放在本地磁盘上
很多初次在虚拟机上配置RAC的朋友，最容易犯的错误就是把共享磁盘文件放在ESXi或Hyper-V主机的本地存储上，物理机上RAC要求共享存储，虚拟机上同样如此，如果多个节点跑在同一台虚拟化宿主机上，可以把共享磁盘文件放在该宿主机的一个共享目录中,通过虚拟化平台提供的共享磁盘机制挂载给所有节点。
如果是跨物理机的虚拟机RAC集群，就需要借助存储层的高级功能，例如VMware环境对应的是共享虚拟磁盘（Shared VMDK），Hyper-V环境则需要配置虚拟光纤通道（Virtual FC）或iSCSI目标，这些年国内企业在做虚拟机RAC时，比较常见的是用NFS挂载共享存储，配配合ASM使用,效果稳定。
磁盘格式和策略直接影响ASM的稳定性
虚拟机的虚拟磁盘有两种常见格式：厚置备延迟置零（Thick Provisioned Lazy Zeroed）和厚置备快速置零（Thick Provisioned Eager Zeroed），RAC共享磁盘必须使用厚置备快速置零格式,或至少确保磁盘预分配并完全清零。
原因是ASM在初始化磁盘时需要对磁盘进行读写校验和头块格式化，如果磁盘是精简置备或延迟置零，ASM的某些操作会因为读到未清零的扇区而产生意外错误，行业共识认为，共享磁盘的格式错误是虚拟机RAC安装失败的头号原因。
另外还需注意，给共享磁盘打快照是RAC环境的大忌，打快照后，多个节点对磁盘的写入会在快照层上产生分叉，底层文件系统锁定和ASM的集群一致性会被严重破坏,直接导致节点被驱逐甚至OCR损坏。
ASM磁盘的udev绑定和权限配置
在Linux虚拟机上配置RAC，共享磁盘的设备名（如/dev/sdb）可能在重启后发生变化，如果使用ASMLib则问题不大，但如果使用udev规则绑定ASM磁盘,需要确保每个节点的配置一致。
具体操作是把磁盘的WWID（通过/usr/lib/udev/scsi_id -g -u /dev/sdb查看）写入udev规则，并为ASM设备用户（通常为grid用户）设置正确的属组和权限，这里有个极易遗漏的细节：udev规则文件需要配置SYMLINK指向如/dev/asm-disk1等固定链路，并在两个节点上粘贴相同的规则内容，很多DBA在虚拟机RAC修改磁盘大小后忘了刷新udev规则，导致新节点识别不到扩容后的磁盘，这是典型的”配置了但没生效”场景。
虚拟机RAC网络配置，心跳和SCAN最容易出问题
心跳网卡一定要直通或专用
虚拟机RAC网络配置中，私有心跳网络对延迟和稳定性要求极高，多数虚拟化平台默认的虚拟网卡会经过CPU虚拟化层进行转发，这通常会引入数毫秒的额外延迟，对于RAC的Cache Fusion进程影响很大，尤其在高并发场景下，容易触发gc cr block lost等内部等待事件。
建议在ESXi中给心跳网卡绑定专用物理网卡，使用VMXNET3类型驱动，并设置混杂模式为接受，如果是生产环境，可以考虑Intel的SR-IOV直通技术，将物理网卡的VF直接分配给虚拟机，延迟接近物理机，行业共识认为,心跳网络的稳定性直接决定了RAC集群的健壮性。
心跳网卡不要混跑业务流量
很多人在虚拟机上就配了两张网卡，一张public一张private，省事是省事了，但业务流量高峰时段，public网络的不稳定会直接干扰心跳通信，造成节点间误判对方”脑裂”，进而触发节点驱逐，权威数据表明，RAC集群中约一半的非计划宕机与心跳网络中断有关。
建议至少在虚拟机上配三张网卡：public、private1、private2（用于冗余心跳），如果条件不足以配置双心跳，也务必确保public和private不在同一物理网卡上，在进行虚拟机RAC网络配置时，另一个高频错误是私网掩码错误，两台节点的private IP不在同一子网，导致互ping不通,集群无法建立。
SCAN监听器的DNS解析策略
SCAN（Single Client Access Name）是RAC集群对外提供服务的关键组件，物理机上SCAN IP需要DNS解析，而虚拟机上很多RAC测试环境并没有建DNS服务器，这个时候需要修改所有客户端和节点的/etc/hosts文件来完成解析。
需要注意细节是：SCAN IP在/etc/hosts中必须解析为一个域名对应三个IP（三节点集群时），如果只配置一个IP，也能工作，但失去了SCAN的负载均衡和故障转移意义，更重要的一点是，尽量把SCAN IP和节点VIP放在同一网段的同一子网中,否则容易出现跨网段无法访问的尴尬问题。
时钟同步和CPU绑定策略
虚拟机的时钟漂移会导致节点被驱逐
RAC集群要求节点间时间差不能超过30秒（11g及之后版本为默认值，可通过参数调整），物理机有硬件时钟保证精度，虚拟机则不然虚拟机的时钟是由宿主机调度的，在宿主机繁忙或开启CPU节能模式时,虚拟机的时钟会明显变慢。
这会导致一个现象：节点1和节点2的心跳正常，但时间差超过阈值，其中一个节点会自动重启，日志中出现Cluster Synchronization Service相关的超时错误。
解决方案是给每台虚拟机配置NTP服务，并指向同一台时间源，在ESXi环境中，务必保证宿主机也开启NTP同步，否则虚拟机的时钟每隔几分钟就会向宿主机”校准”一次，反而干扰NTP的正常工作，多数情况下，
虚拟机时间同步优先采用NTP，不建议同时开启VMware Tools里的时间同步选项,两者会互相冲突。
CPU和内存的预留设置
虚拟机的CPU调度是争用式的，多个虚拟机争抢同一个物理核心时，RAC的latch和mutex竞争会显著增加，系统负载虚高，生产环境建议给每个RAC节点预留足够的CPU份额，或者在ESXi中设置CPU的Reservation参数确保算力。
内存方面，RAC的SGA和PGA通常占了内存的大部分，如果宿主机内存超配严重，虚拟机的内存页会被频繁换入换出（Ballooning），SQL查询性能会呈现严重的锯齿状波动，业内专家指出，虚拟机RAC的内存配置尽量不使用内存超配,以保证响应时间的稳定性。
虚拟机安装RAC注意事项，这些细节别忽略
磁盘写入缓存策略
无论是VMware还是Hyper-V，默认的硬盘控制器缓存策略可能包含写入缓存，对于RAC的ASM磁盘来讲，写入缓存可能导致数据在宿主机层的缓存中滞留，一旦宿主机掉电，这些未落盘的数据丢失,整个集群的一致性就毁了。
需要把虚拟磁盘的写入缓存策略设置为直写（Direct Write）或关闭缓存，VMware环境中可以在VMDK的高级参数中设置disk.EnableUUID = "TRUE"，确保每个磁盘的SCSI ID在节点间保持一致,这也是虚拟机RAC磁盘能否被ASM正确识别的前置条件。
大页内存和共享内存设置
RAC的SGA通常较大，Linux环境下会启用HugePages来减少页表开销，在虚拟机上开启HugePages需要注意：宿主机必须为虚拟机预留足额内存，防止内存气球驱动把大页拆分。/etc/sysctl.conf中的vm.nr_hugepages需要精确计算（SGA大小除以大页大小），设置过小会导致数据库SGA无法分配,设置过大又会浪费宿主机内存。
很多DBA在虚拟机上配置RAC时，忽略了/dev/shm的大小，Oracle 11g及以上版本的ASM和数据库实例都依赖共享内存，默认的/dev/shm只有物理内存的一半，如果SGA超过这个值，实例会启动失败，可以通过在/etc/fstab中修改tmpfs的挂载大小来解决这个问题。
节点时间的校准和防火墙设置
跨节点的防火墙配置是虚拟机安装RAC注意事项中容易被忽视的环节，Oracle RAC的集群通信需要开放1521（数据库监听）、1522（ASM监听）、1630（节点通信）等多个端口，如果用的是云主机或虚拟化平台的默认安全组规则,可能会默认屏蔽部分高端口。
建议直接关闭所有节点的iptables/防火墙
进行排查，确认集群正常后再针对性地开放端口，这里有个小技巧：在两台节点之间使用nc -vz <IP> <port>逐端口测试连通性,能快速定位防火墙拦截的位置。
RAC虚拟机遇到故障怎么办
节点驱逐后的重新加入流程
当节点因为心跳超时或存储IO异常被驱逐后，重新加入集群需要遵循正确流程，先在故障节点上执行crsctl stop crs，然后在正常节点上检查crsctl status resource -t确认故障节点的资源已完全清理。
之后回到故障节点执行crsctl start crs，观察alert.log和crsd.log，虚拟机上常见的故障点是ASM磁盘在节点重启后没有被正确识别（udev规则未生效），此时需要重新执行udevadm trigger并确认/dev/asm-disk链路存在。
虚拟机迁移时的绑定策略
虚拟机在宿主机之间进行在线迁移（vMotion）时，如果RAC节点的心跳网络中断时间过长，集群同样会出现节点驱逐，如果要在生产环境使用虚拟机RAC，建议为关键节点设置亲和性规则，使其绑定到固定的宿主机上,避免自动迁移带来的网络抖动。
存储层面的vMotion同样存在风险，将RAC的共享磁盘文件迁移到另一数据存储时，如果I/O路径有短暂中断，ASM会报告磁盘丢失错误，多数情况下,这种错误需要重启集群才能恢复。
Q&A：关于虚拟机RAC的常见疑惑
虚拟机RAC和物理机RAC性能差距有多大？
在I/O和网络延迟敏感的场景下，差距较为明显，尤其在高并发写操作时虚拟化层的CPU开销会使延迟增加，但对于常规的OLTP负载，通过合理配置直通网卡和预留内存，虚拟机RAC的性能可以接近物理机的80%到90%,且具备快速克隆和迁移的优势。
虚拟机RAC适合生产环境吗？
适合，但前提是底层虚拟化平台经过充分调优，存储使用企业级共享存储而非本地磁盘，网络配置了专用心跳且开启QoS保障，国内不少企业多年前就在生产环境中使用虚拟机运行Oracle RAC,稳定性记录良好。
单机虚拟机能同时跑多个RAC节点吗？
可以，多个节点虚拟机可同时运行于同一台物理宿主机，这也是常见测试架构，需注意内存分配和CPU核心数必须满足所有节点需求，即便宿主机超配资源，故障发生时多个RAC节点也会同时不可用,因而该架构不适合承担生产任务。
虚拟机配置RAC的难点不在于安装步骤本身，而在于底层的存储、网络和时间同步三项基础设施的精细调校，把共享磁盘的策略、心跳网络的隔离和时钟源的统一这三个基础落实到位，集群稳定运行就有了可靠保障，剩下的节点配置和ASM初始化只是按步操作的过程,稳定运行自然水到渠成。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/625395.html
