1. SCAN IP与VIP的本质区别第一次接触Oracle RAC时我也曾被SCAN IP和VIP这两个概念搞得晕头转向。直到有一次生产环境出现故障亲眼看到VIP自动漂移到健康节点才真正理解它们的价值。简单来说SCAN IP就像是公司的总机号码而VIP则是各部门的分机号。SCAN IPSingle Client Access Name是Oracle 11g引入的集群统一入口。它有三个关键特性通过DNS轮询解析实现负载均衡比如配置三个SCAN IP地址客户端连接时会随机选择一个与节点位置无关客户端无需知道集群具体有多少节点支持动态扩容缩容新增节点时无需修改客户端配置VIPVirtual IP则是与实例绑定的虚拟IP主要解决脑裂问题。我曾在测试环境模拟过这样的场景当节点1突然宕机其VIP会在30秒内自动迁移到节点2此时客户端连接虽然会短暂中断但重试后就能自动连到新节点。这比传统的主机IP方案可靠得多。2. 高可用性实现机制2.1 VIP的故障转移流程去年我们机房发生过一次电源故障正好让我完整观察到VIP的切换过程节点1突然断电CRSD进程终止集群健康检查发现节点1无响应默认每1秒检测一次节点2的OCR磁盘确认节点1失效节点2接管节点1的VIP资源包括更新ARP缓存监听程序在新节点重新注册服务整个过程通常能在30秒内完成。这里有个实用技巧通过crsctl status resource -t命令可以实时观察资源状态变化。2.2 SCAN IP的容错设计SCAN IP的高可用体现在三个层面DNS层面建议配置至少3个SCAN IP对应不同物理节点监听层面SCAN监听器会动态注册各节点服务状态客户端层面当连接某个SCAN IP失败时会自动尝试列表中的下一个实测中我发现个有趣现象即使所有SCAN IP解析到同一个物理节点负载均衡仍然有效因为监听器会根据负载情况将连接请求转发到其他节点。3. 负载均衡实战配置3.1 SCAN监听器配置要点在listener.ora中配置SCAN监听器时这几个参数最常被忽略LISTENER_SCAN1 (DESCRIPTION (LOAD_BALANCEON) (CONNECT_TIMEOUT10) (ADDRESS(PROTOCOLTCP)(HOSTscan1.cluster.com)(PORT1521)) )特别注意LOAD_BALANCEON要显式开启否则可能变成主备模式。有次性能调优时就发现这个参数被误设为OFF导致所有连接都压到第一个节点。3.2 服务端负载算法Oracle提供了四种负载算法通过SRVCTL设置SHORT最快响应优先LONG最少会话优先RATIO按处理能力比例分配NONE随机分配我们在电商大促时做过对比测试对于OLTP系统LONG算法能将节点负载差异控制在5%以内。而批处理场景更适合RATIO算法。4. 常见故障排查指南4.1 SCAN IP连接问题遇到SCAN IP连接失败时建议按这个顺序排查检查DNS解析是否正常nslookup scan_name验证SCAN监听器状态lsnrctl status LISTENER_SCAN1确认集群服务注册情况srvctl status scan_listener检查防火墙规则特别是1521端口有个容易忽略的坑如果修改了SCAN IP配置必须同时更新DNS和OCR中的记录否则会导致脑裂。4.2 VIP漂移异常VIP无法自动迁移时我通常会检查网络心跳线状态oifcfg getif验证VIP资源定义crsctl status resource ora.dbname.vip -f查看OCR健康状态ocrcheck测试ARP更新速度arping -c 3 vip曾经遇到过一个经典案例某台服务器的网卡驱动不兼容导致ARP更新延迟使得VIP切换需要2分钟。更新驱动后问题立即解决。5. 性能优化建议5.1 网络层优化在金融级低延迟环境中这些调整很有效将SCAN IP的DNS TTL设为60秒默认300秒调整TCP参数如tcp_keepalive_time设为300使用Jumbo Frame减少网络包数量为VIP配置独立的网络接口5.2 内存与线程调整对于高并发场景需要调整这些参数ALTER SYSTEM SET DISPATCHERS(PROTOCOLTCP)(DISPATCHERS8) SCOPEBOTH; ALTER SYSTEM SET SHARED_SERVERS32 SCOPEBOTH;同时监控V$SHARED_SERVER视图确保没有线程饥饿现象。我们某个核心系统就曾因为DISPATCHER配置不足导致连接池耗尽。6. 云环境下的特殊考量在云平台部署RAC时有几个关键差异点云厂商的负载均衡器可能和SCAN IP功能重叠虚拟网络对ARP广播的支持可能有限多可用区部署时需要调整网络延迟容忍度弹性扩容时需要自动更新SCAN配置最近帮客户在AWS上部署RAC时我们就用Route53实现了SCAN IP的自动注册配合Lambda脚本在节点增减时动态更新DNS记录。这种混合方案既保留了Oracle原生特性又符合云原生架构要求。
深入解析Oracle RAC中的SCAN IP与VIP：高可用与负载均衡的关键技术
1. SCAN IP与VIP的本质区别第一次接触Oracle RAC时我也曾被SCAN IP和VIP这两个概念搞得晕头转向。直到有一次生产环境出现故障亲眼看到VIP自动漂移到健康节点才真正理解它们的价值。简单来说SCAN IP就像是公司的总机号码而VIP则是各部门的分机号。SCAN IPSingle Client Access Name是Oracle 11g引入的集群统一入口。它有三个关键特性通过DNS轮询解析实现负载均衡比如配置三个SCAN IP地址客户端连接时会随机选择一个与节点位置无关客户端无需知道集群具体有多少节点支持动态扩容缩容新增节点时无需修改客户端配置VIPVirtual IP则是与实例绑定的虚拟IP主要解决脑裂问题。我曾在测试环境模拟过这样的场景当节点1突然宕机其VIP会在30秒内自动迁移到节点2此时客户端连接虽然会短暂中断但重试后就能自动连到新节点。这比传统的主机IP方案可靠得多。2. 高可用性实现机制2.1 VIP的故障转移流程去年我们机房发生过一次电源故障正好让我完整观察到VIP的切换过程节点1突然断电CRSD进程终止集群健康检查发现节点1无响应默认每1秒检测一次节点2的OCR磁盘确认节点1失效节点2接管节点1的VIP资源包括更新ARP缓存监听程序在新节点重新注册服务整个过程通常能在30秒内完成。这里有个实用技巧通过crsctl status resource -t命令可以实时观察资源状态变化。2.2 SCAN IP的容错设计SCAN IP的高可用体现在三个层面DNS层面建议配置至少3个SCAN IP对应不同物理节点监听层面SCAN监听器会动态注册各节点服务状态客户端层面当连接某个SCAN IP失败时会自动尝试列表中的下一个实测中我发现个有趣现象即使所有SCAN IP解析到同一个物理节点负载均衡仍然有效因为监听器会根据负载情况将连接请求转发到其他节点。3. 负载均衡实战配置3.1 SCAN监听器配置要点在listener.ora中配置SCAN监听器时这几个参数最常被忽略LISTENER_SCAN1 (DESCRIPTION (LOAD_BALANCEON) (CONNECT_TIMEOUT10) (ADDRESS(PROTOCOLTCP)(HOSTscan1.cluster.com)(PORT1521)) )特别注意LOAD_BALANCEON要显式开启否则可能变成主备模式。有次性能调优时就发现这个参数被误设为OFF导致所有连接都压到第一个节点。3.2 服务端负载算法Oracle提供了四种负载算法通过SRVCTL设置SHORT最快响应优先LONG最少会话优先RATIO按处理能力比例分配NONE随机分配我们在电商大促时做过对比测试对于OLTP系统LONG算法能将节点负载差异控制在5%以内。而批处理场景更适合RATIO算法。4. 常见故障排查指南4.1 SCAN IP连接问题遇到SCAN IP连接失败时建议按这个顺序排查检查DNS解析是否正常nslookup scan_name验证SCAN监听器状态lsnrctl status LISTENER_SCAN1确认集群服务注册情况srvctl status scan_listener检查防火墙规则特别是1521端口有个容易忽略的坑如果修改了SCAN IP配置必须同时更新DNS和OCR中的记录否则会导致脑裂。4.2 VIP漂移异常VIP无法自动迁移时我通常会检查网络心跳线状态oifcfg getif验证VIP资源定义crsctl status resource ora.dbname.vip -f查看OCR健康状态ocrcheck测试ARP更新速度arping -c 3 vip曾经遇到过一个经典案例某台服务器的网卡驱动不兼容导致ARP更新延迟使得VIP切换需要2分钟。更新驱动后问题立即解决。5. 性能优化建议5.1 网络层优化在金融级低延迟环境中这些调整很有效将SCAN IP的DNS TTL设为60秒默认300秒调整TCP参数如tcp_keepalive_time设为300使用Jumbo Frame减少网络包数量为VIP配置独立的网络接口5.2 内存与线程调整对于高并发场景需要调整这些参数ALTER SYSTEM SET DISPATCHERS(PROTOCOLTCP)(DISPATCHERS8) SCOPEBOTH; ALTER SYSTEM SET SHARED_SERVERS32 SCOPEBOTH;同时监控V$SHARED_SERVER视图确保没有线程饥饿现象。我们某个核心系统就曾因为DISPATCHER配置不足导致连接池耗尽。6. 云环境下的特殊考量在云平台部署RAC时有几个关键差异点云厂商的负载均衡器可能和SCAN IP功能重叠虚拟网络对ARP广播的支持可能有限多可用区部署时需要调整网络延迟容忍度弹性扩容时需要自动更新SCAN配置最近帮客户在AWS上部署RAC时我们就用Route53实现了SCAN IP的自动注册配合Lambda脚本在节点增减时动态更新DNS记录。这种混合方案既保留了Oracle原生特性又符合云原生架构要求。
