一次RAC VIP漂移的结果诊断及修复_数据库技术_Linux公社-Linux系统门户网站
你好，游客
一次RAC VIP漂移的结果诊断及修复
来源：Linux社区&
作者：应以峰
客户的10G数据库VIP出现宕，引起VIP负载到另一个节点
事件支持细节
04:29:56.378 一号机器VIP 出现 went OFFLINE unexpectedly，当天出现这个VIP漂移的故障后为检查VIP宕掉的原因，
对VIP资源启动DEBUG 5模式：./crsctl debug log res "orahostname1.vip:5"
04:38:36.047 一号节点VIP 出现 went OFFLINE unexpectedly。
根据ora.hostname.vip.log日志显示，出现VIP宕原因基本可以确定为公网IP与缺省网管通讯不畅引起。
根据管方建议，调整racgvip程序中的参数从& &
FAIL_WHEN_DEFAULTGW_NO_FOUND=1 修改成
FAIL_WHEN_DEFAULTGW_NO_FOUND=0
但是调整完后故障依旧
04:17:37.822: [& CRSRES][11025]32ora.hostname1.vip on hostname1 went OFFLINE unexpectedly
&为明确原因，再次收集ora.hostname1.vip.log及racgvip 信息进行分析
&分析结果如下：
在racgvip程序中，有如下代码
# Check the status of the interface thro' pinging gateway
if [ -n "$DEFAULTGW" ]
# get base IP address of the interface
tmpIP=`$LSATTR -El ${_IF} -a netaddr | $AWK '{print $2}'`
# get RX packets numbers (bug7855-&bug9743421)
_O1=`$NETSTAT -n -I $_IF | $AWK "{ if (/^$_IF/) {print \\$(NF-4); exit}}"`
x=$CHECK_TIMES
while [ $x -gt 0 ]
if [ -n "$tmpIP" ]
logx "About to execute command: $PING -S $tmpIP $PING_TIMEOUT $DEFAULTGW"
$PING -S $tmpIP $PING_TIMEOUT $DEFAULTGW & /dev/null 2&&1
logx "About to execute command: $PING $PING_TIMEOUT $DEFAULTGW"
$PING $PING_TIMEOUT $DEFAULTGW & /dev/null 2&&1
_O2=`$NETSTAT -n -I $_IF | $AWK "{ if (/^$_IF/) {print \\$(NF-4); exit}}"`
if [ "$_O1" != "$_O2" ]
# RX packets numbers changed
x=`$EXPR $x - 1`
if [ $_RET -ne 0 ]
logx "IsIfAlive: RX packets checked if=$_IF failed"
logx "IsIfAlive: RX packets checked if=$_IF OK"
logx "IsIfAlive: Default gateway is not defined (host=$HOSTNAME)"
if [ $FAIL_WHEN_DEFAULTGW_NO_FOUND -eq 1 ]
从源码我们可以看到检查缺省网关的处理逻辑
1、如果检测到缺省网关存在执行网管检查逻辑
2、_01收集网卡网络包量
3、$PING -S $tmpIP $PING_TIMEOUT $DEFAULTGW& ping网管
4、_02再次收集网卡网络包量
5、如果_01网卡网络包量 与 _02网卡网络包量不相同，表明网卡与缺省网卡之间通讯正常 _RET 返回编码为0
6、如果_01网卡网络包量 与 _02网卡网络包量相同，_RET 返回编码没指定，缺省返回1，同时打印日志logx "IsIfAlive: RX packets checked if=$_IF failed"，即判断网卡失败。
&FAIL_WHEN_DEFAULTGW_NO_FOUND参数从1修改成0，是为了跳过网关ping检测，而从源码中我们可以看到，FAIL_WHEN_DEFAULTGW_NO_FOUND参数只有在网卡参数$DEFAULTGW为空才生效，即主机上没有配置网关并且参数FAIL_WHEN_DEFAULTGW_NO_FOUND配置为非1时返回码RET为0。
&由于我们的环境中DEFAULTGW能获取成功及DEFAULTGW非空，导致程序没有进入FAIL_WHEN_DEFAULTGW_NO_FOUND判断是否为1的处理流程。
&故障期间DEBUG错误信息如下：
04:17:37.776: [& & RACG][1] [][ora.s9lp1.vip]: Wed Nov& 6 04:17:33 CST 2013 [ 6422696 ] checkIf: start for if=en5
Wed Nov& 6 04:17:33 CST 2013 [ 6422696 ] IsIfAlive: start for if=en5
Wed Nov& 6 04:17:33 CST 2013 [ 6422696 ] defaultgw:& started
04:17:37.776: [& & RACG][1] [][ora.s9lp1.vip]: Wed Nov& 6 04:17:33 CST 2013 [ 6422696 ] defaultgw:& completed with 10.0.241.254& （网关获取成功，网关为10.0.241.254）
Wed Nov& 6 04:17:33 CST 2013 [ 6422696 ] About to execute command: /usr/sbin/ping -S 10.0.241.150& -c 1 -w 1 10.0.241.254
04:17:37.777: [& & RACG][1] [][ora.s9lp1.vip]: Wed Nov& 6 04:17:35 CST 2013 [ 6422696 ] About to execute command: /usr/sbin/ping -S 10.0.241.150& -c 1 -w 1 10.0.241.254 （PING 网关）
Wed Nov& 6 04:17:37 CST 2013 [ 6422696 ] IsIfAlive: RX packets checked if=en5 failed（由于检查到网卡en5在2秒中内网卡流量包未方式变化，判断为en5失败） &
&1、故障每次发生都在凌晨04左右，时间如下：
04:17:372、从源码上分析，发生故障期间网卡en5连续1秒的网络包未变化
& & 可能的原因：
& & ping -S 10.0.241.150& -c 1 -w 1 10.0.241.254
& & Oracle检测网管时，由于当时网络质量不好导致ping不能在1秒钟内返回结果。
& & 引起网卡en5 ping前 ping后没有 网络包发生变化。
根据以上分析我们建议：
1、修改racgvip源码跳过网管检测
# Check the status of the interface thro' pinging gateway
if [ -n "$DEFAULTGW" ] &
& 修改后：
# Check the status of the interface thro' pinging gatewayif [ -n "$DEFAULTGW" -a $FAIL_WHEN_DEFAULTGW_NO_FOUND -eq 1 ]&
查阅oracle11.2.0.3版本的 RACGVIP代码，同样以次修改&
以下为Oracle11G的racgvip代码
if [ -n "$DEFAULTGW" -a $FAIL_WHEN_DEFAULTGW_NOT_FOUND -eq 1 ]
& & & _RET=1
& & & # get RX packets numbers
& & & _O1=`$IFCONFIG $_IF | $AWK '{ if (/RX packets:/) { sub("packets:", "", $2); print $2}}'`
& & & x=$CHECK_TIMES
& & & while [ $x -gt 0 ]
& & & & logx "About to execute $PING -r -I $_IF $DEFAULTGW $PING_TIMEOUT"
& & & & $PING -r -I $_IF $DEFAULTGW $PING_TIMEOUT & /dev/null 2&&1
& & & & rc=$?
& & & & if [ $rc -eq 0 ]
& & & & then
& & & & & _RET=0
& & & & & break
& & & & else
& & & & & echo "ping to $DEFAULTGW via $_IF failed, rc = $rc (host=$HOSTNAME)"
& & & & fi&
& & & & x=$(($x-1))
& & & done &
&结论及解决方案
修改racgvip代码
修改完成后，需要观察ora.s9lp1.vip.log里出现如下信息：
&IsIfAlive: Default gateway is not defined (host=$HOSTNAME)
表明修改失效
更多Oracle相关信息见 专题页面
本文永久更新链接地址：
相关资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款用户名：ylw6006
文章数：237
评论数：753
访问量：2028665
注册日期：
阅读量：1297
阅读量：3317
阅读量：584855
阅读量：470377
51CTO推荐博文
一直以来都是用nginx的upstream模块做网站最前端的负载均衡，为了防止nginx本身宕机导致网站不能访问，通常都会做两套nginx反向代理，然后用keepalive之类的软件提供VIP。常见的环境是nginx主节点和从节点各有一个公网IP，一个私有IP，VIP地址也使用公网IP来提供，正常情况下VIP只会在nginx主节点上工作，只有主节点宕机或者网络不可达等情况下，VIP才会漂移到nginx从节点上。如果keepalive配置了非抢占模式，则主节点恢复后，VIP也不会漂移会主节点，而是继续在从节工作。这种配置要求机房网络不做mac地址绑定。最近做的两套培训系统测试情况如下:系统一：主从节点做双网卡绑定，都只有一个私有IP，VIP也为私有IP，通过防火墙的NAT转发用户的访问请求。主节点宕机后，VIP可以漂移至从节点，但用户无法访问网站，telnet防火墙公网IP的80端口提示无法连接。系统二：主从节点各有两张网卡，分别配置一个公网IP和一个私有IP。VIP地址也使用公网IP来提供。主节点宕机后，VIP可以漂移至从节点，但用户无法ping通VIP，自然网站也就打不开。于是分别对这两种情况进行排查：系统二：属于比较常见的配置方案。VIP漂移后无法ping通，第一反应询问机房工作人员，是否相应的设备做了mac地址绑定。得知无绑定策略后继续排查。发现配置net.ipv4.ip_nonlocal_bind = 1 参数并使其生效后重新测试正常。系统一：情况有点特殊，按系统二的解决方法尝试无果后，怀疑端口路由器映射上出现问题。于是继续测试VIP漂移，发现VIP漂移到从节点后，防火墙上的arp表中vip对应的mac地址依旧是主节点网卡的mac地址，原来防火墙才是罪魁祸首，坑爹的货。机房使用的防火墙型号华为Quidway Eudemon1000E，据说默认配置下，这个arp地址表自动刷新需要20分钟！好吧！于是用下面的命名手工刷新后，万事大吉，网站访问也很顺畅，比较郁闷的是当主节点重新抢占VIP后，依然需要手工刷新下，否则防火墙还是把请求转给从节点响应。# arping -I 网卡地址 -c 3 -s VIP地址 网关地址后记：要彻底解决系统一的问题，可以从两方面去着手，首先是考虑去调整防火墙的arp表的自动刷新时间；其次是考虑在从节点上部署一个无限循环的脚本，时时去检测是否抢占到了VIP，若抢占成功，则运行前面的刷新命令，命令成功运行后退出脚本，同时可以用nagios监控该脚本，了解最新的主从切换情况。切记，循环运行一次接受后sleep 1秒，否则会死机的哦！如果在主节点上也部署类似的脚本，则会对网络带来负担，因而主节点恢复后的刷新手工运行下就好了，如果忘记运行了，从节点依然可以工作，无伤大雅！本文出自 “” 博客，谢绝转载！
了这篇文章
类别：┆阅读(0)┆评论(0)
09:52:29 14:35:35 10:58:34vip漂移问题
10.2.0.1不能自动漂回来。
10.2.0.3可以自动漂回来。
10.2.0.4不能自动漂回来。
11.1.XX不能自动漂回来
偶也遇到过LZ这种情况,10.2.0.1中instance和listener是依赖于vip的,oracle也意识到这样不合理,到了10.2.0.3,只有listener依赖与vip了.vip漂移,后果是很严重的.
根据我的测试，crs、host停止时会发生vip漂移，当停止的crs重启后，vip可以漂移会原来的节点！停止instance、nodeapps时不会发生vip漂移！
其实在节点一失效之后，vip1可以切换到node2上面去，但是node2上的listener不能使用新漂移过来的vip1进行连接服务，因为oracle10G还没有提供漂移过来的ip自动注册到listener的功能，因此，vip1切换到其他节点后，这个ip就不能提供连接服务，只是执行了切换过来这个动作。
这样是不行的,因为当vip漂移的时侯,这个结点的listener是会down的
因为vip是listener的依赖资源
个人认为vip漂移对client连接意义也不大,只是对telnet,ftp这样的服务还有些用处
可以配TAF,也可以解除vip与listener的依赖关系,用boot ip
看个人习惯,方式很多。
禁止漂移的话，HA还有什么用？
可以分不同的service，注册service的时候，每个service指定一个PREFERRED
instance，其他instance为AVAILABLE，这样，出问题的时候才会漂到其他节点
如何手工把vip漂回来
一直没看到你的小版本。
如果是10.2.0.3 vip可能能够漂回来，listener也会自动online，不需要手工干预。
如果没有飘回来，可以试一下：
手工将VIP飘回来：
注意：可以先crs_stop srs_start
单独起停你怀疑有问题的vip 根据提示信息 再做如下操作&
1, 先将vip漂回来
crs_relocate ora.node1.vip
再启动asm和实例
srvctl start asm
srvctl start instance
我又重新安装了RAC,顺利安装好了.不过启动的时候还可能会报"CRS-0223",我按照saintcruz2008
启动服务得时候一定要将所有节点服务关闭，然后先启动一个节点，接着观察crs_stat的状态。当这个节点的所有服务正常后，再启动另一个节点。
srvctl stop service -d devdb
srvctl stop database -d devdb
srvctl stop asm -n rac2
srvctl stop asm -n rac1
srvctl stop nodeapps -n rac2
srvctl stop nodeapps -n rac1
srvctl start nodeapps -n rac1
srvctl start nodeapps -n rac2
srvctl start asm&
srvctl start asm&
srvctl start database -d devdb
srvctl start service&&-d
这样就好了
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。拖动播放器想看猴子的私藏番剧30蕉即享所有私藏一整月该操作将消耗您30香蕉播放...弹幕...评论...收藏57手机观看更流畅扫描下载最新版客户端投蕉1喂sandman刘玉朴食&0&香蕉分享简介国外氪金玩家真会玩！展开详情关闭详情+&关注这个人很懒，什么都没有写!0投稿&/&0听众所属合辑：[title]订阅&[subscribeSize]取消订阅创建者:[username]稿件:[countSize]播放中[viewCount][danmuSize]相关主播展开全部主播[view]官方下载new友情链接反馈京ICP备号节目制作经营许可证（京）字第05158号0
还没有acfun账号，
请选择分组。您添加关注的用户将出现在对应的组中。添加关注把视频贴到博客或论坛视频地址复制flash地址复制html代码复制通用代码复制欢迎来到HugNew-拥抱变化，扫一扫右边二维码关注微信订阅号：Martin说 或 加QQ群：互相交流，Stay hungry, Stay foolish.
什么是keepalived呢？keepalived是实现高可用的一种轻量级的技术手段，主要用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。之所以说keepalived是轻量级的，是相对于corosync + ldirectord来说的。keepalived也可以实现高可用集群，而且配置起来比corosync + ldirectord简单方便很多，keepalived与corosync的工作机制相差很多。corosync + ldirectord实现的功能虽然强大，但配置起来比较麻烦，而keepalived功能虽然简单，但配置起来比较容易。也就是说keepalived可实现corosync + ldirectord实现的功能，只不过前者没有后者功能强大而已。
在介绍keepalived之前，不得不先介绍下一个协议——VRRP。之所以要介绍这个协议，是因为VRRP协议是keepalived实现的基础。下面先来一块看下这个这协议是干吗用的吧。
如上图所示，通常，同一网段内的所有主机都设置一条相同的、以网关为下一跳的缺省路由。主机发往其他网段的报文将通过缺省路由发往网关，再由网关进行转发，从而实现主机与外部网络的通信。当网关发生故障时，本网段内所有以网关为缺省路由的主机将无法与外部网络通信，仅能实现内部主机间通信。缺省路由为用户的配置操作提供了方便，但是对缺省网关设备提出了很高的稳定性要求。增加出口网关是提高系统可靠性的常见方法，此时如何在多个出口之间进行选路就成为需要解决的问题。而VRRP正好解决了此问题。
VRRP：Virtual Router Redundancy Protocol，虚拟路由冗余协议。VRRP说白了就是实现地址漂移的，是一种容错协议，在提高可靠性的同时，简化了主机的配置。该协议能够实现将可以承担网关功能的一组路由器加入到备份组中，形成一台虚拟路由器，由VRRP的选举机制决定哪台路由器承担转发任务，局域网内的主机只需将虚拟路由器配置为缺省网关。
在VRRP协议出现之前，为了不让单个路由器成为本地与外部通信的瓶颈，我们需要有多个路由，在此种模式下，我们内部的主机就需要将自己的网关指向不同的路由器，这样的配置对我们的网关管理员来说是很麻烦的，且不容易实现。在VRRP协议出现后，为了不让单个路由器成为本地与外部通信的瓶颈，我们仍需要有多个路由，但可以使用同一个缺省网关，我们只需将内部主机指定一个缺省网关即可。VRRP协议会根据优先级来选择一个正常的路由作为主路由器实现与外部的通信，而其他路由则作为备份路由不参与转发。在此模式下，多个路由器组成虚拟路由器组，物理上是多个路由器组成，但在逻辑上却是表现为只有一个路由。效果如下图所示：
在上图中，Router A、Router B和Router C组成一个虚拟路由器。各虚拟路由器都有自己的IP地址。局域网内的主机将虚拟路由器设置为缺省网关。Router A、Router B和Router C中优先级最高的路由器作为Master路由器，承担网关的功能。其余两台路由器作为Backup路由器。当master路由器出故障后，backup路由器会根据优先级重新选举新的master路由器承担网关功能。Master 路由器周期性地发送VRRP 报文，在虚拟路由器中公布其配置信息（优先级等）和工作状况。Backup路由器通过接收到VRRP 报文的情况来判断Master 路由器是否工作正常。
VRRP根据优先级来确定备份组中每台路由器的角色（Master 路由器或Backup 路由器）。优先级越高，则越有可能成为Master 路由器。VRRP优先级的可配置的取值范围为1 到254。
为了防止非法用户构造报文攻击备份组，VRRP通过在VRRP报文中增加认证字的方式，验证接收到的VRRP报文。VRRP提供了两种认证方式：
simple：简单字符认证。发送VRRP 报文的路由器将认证字填入到VRRP 报文中，而收到VRRP 报文的路由器会将收到的VRRP 报文中的认证字和本地配置的认证字进行比较。如果认证字相同，则认为接收到的报文是真实、合法的VRRP 报文；否则认为接收到的报文是一个非法报文。
md5：MD5 认证。发送VRRP 报文的路由器利用认证字和MD5 算法对VRRP 报文进行摘要运算，运算结果保存在Authentication Header（认证头）中。收到VRRP 报文的路由器会利用认证字和MD5 算法进行同样的运算，并将运算结果与认证头的内容进行比较。如果相同，则认为接收到的报文是真实、合法的VRRP 报文；否则认为接收到的报文是一个非法报文。
在有多个路由器组成的虚拟路由中，当我们的内部主机很多时，如果所有主机都使用同一个master路由，会使得其他路由器很清闲，很浪费资源，我们期望我们本地的内部主机平分到各个路由器上，即让我们的内部主机的缺省网关指向不同的路由，从而减轻因只有一个master路由而造成网络带宽拥堵的负担。这就是负载分担VRRP。但这个如何实现呢？先看下面的配置效果图：
在此情况下，同一台路由器同时加入多个VRRP备份组，在不同备份组中有不同的优先级，从而实现负载分担。
在上图中，有三个备份组存在：
备份组1：对应虚拟路由器1。Router A作为Master路由器，Router B和Router C作为Backup路由器。
备份组2：对应虚拟路由器2。Router B作为Master路由器，Router A和Router C作为Backup路由器。
备份组3：对应虚拟路由器3。Router C作为Master路由器，Router A和Router B作为Backup路由器。
为了实现业务流量在Router A、Router B和Router C之间进行负载分担，需要将局域网内的主机的缺省网关分别设置为虚拟路由器1、2和3。在配置优先级时，需要确保三个备份组中各路由器的VRRP优先级形成交叉对应。为了便于理解，我们假定有三个路由设备Router A、B、C和三台主机Host A、B、C，列举有在不同的虚拟路由组中。对路由器A来说，因在虚拟路由组1中Router A的优先级高于另外两个，因此，Router A 作为 Master 路由器，Router B 和Router C 作为 Backup路由器；同样，对路由器B来说，因在虚拟路由器组2中Router B的优先级高于另外两个，因此，Router B 作为 Master 路由器，Router A 和Router C 作为 Backup路由器；对路由器C来说，因在虚拟路由器组3中Router C的优先级高于另外两个，因此，Router C 作为 Master 路由器，Router A 和Router B 作为 Backup路由器。对不同的主机来说，一旦其master路由器出故障后，会在另外正常的路由器中根据优先级重新选定master路由。如这里假定Host A的默认网关指向Router A，即Host A指向虚拟路由器组1的默认网关，对主机A来说，如果其master路由出现故障，即Router A出现故障，则会从另外两个正常的备份虚拟路由中根据各自的优先级选取高优先级的作为新的master路由，这里就是选取Router B作为其master路由来完成网关功能。假如想了解更多关于VRRP协议相关的信息请查阅相关资料，这里不再过多介绍。
Keepalived
一、配置说明
keepalived的配置位于/etc/keepalived/keepalived.conf，配置文件格式包含多个必填/可选的配置段，部分重要配置含义如下：
global_defs: 全局定义块，定义主从切换时通知邮件的SMTP配置。
vrrp_instance: vrrp实例配置。
vrrp_script: 健康检查脚本配置。
细分下去，vrrp_instance配置段包括：
state: 实例角色。分为一个MASTER和一(多)个BACKUP。
virtual_router_id: 标识该虚拟路由器的ID，有效范围为0-255。
priority: 优先级初始值，竞选MASTER用到，有效范围为0-255。
advert_int: VRRP协议通告间隔。
interface: VIP所绑定的网卡，指定处理VRRP多播协议包的网卡。
mcast_src_ip: 指定发送VRRP协议通告的本机IP地址。
authentication: 认证方式。
virtual_ipaddress: VIP。
track_script: 健康检查脚本。
vrrp_script配置段包括：
script: 一句指令或者一个脚本文件，需返回0(成功)或非0(失败)，keepalived以此为依据判断其监控的服务状态。
interval: 健康检查周期。
weight: 优先级变化幅度。
fall: 判定服务异常的检查次数。
rise: 判定服务正常的检查次数。
二、选举算法
keepalived中优先级高的节点为MASTER。MASTER其中一个职责就是响应VIP的arp包，将VIP和mac地址映射关系告诉局域网内其他主机，同时，它还会以多播的形式（目的地址224.0.0.18）向局域网中发送VRRP通告，告知自己的优先级。网络中的所有BACKUP节点只负责处理MASTER发出的多播包，当发现MASTER的优先级没自己高，或者没收到MASTER的VRRP通告时，BACKUP将自己切换到MASTER状态，然后做MASTER该做的事：1.响应arp包，2.发送VRRP通告。
MASTER和BACKUP节点的优先级如何调整？
首先，每个节点有一个初始优先级，由配置文件中的priority配置项指定，MASTER节点的priority应比BAKCUP高。运行过程中keepalived根据vrrp_script的weight设定，增加或减小节点优先级。规则如下：
1. 当weight & 0时，vrrp_script script脚本执行返回0(成功)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时，进行主从切换。
2. 当weight & 0时，vrrp_script script脚本执行返回非0(失败)时优先级为priority + weight, 否则为priority。当BACKUP发现自己的优先级大于MASTER通告的优先级时，进行主从切换。
3. 当两个节点的优先级相同时，以节点发送VRRP通告的IP作为比较对象，IP较大者为MASTER。
主从的优先级初始值priority和变化量weight设置非常关键，配错的话会导致无法进行主从切换。比如，当MASTER初始值定得太高，即使script脚本执行失败，也比BACKUP的priority + weight大，就没法进行VIP漂移了。所以priority和weight值的设定应遵循: abs(MASTER priority – BAKCUP priority) & abs(weight)。
另外，当网络中不支持多播(例如某些云环境)，或者出现网络分区的情况，keepalived BACKUP节点收不到MASTER的VRRP通告，就会出现脑裂(split brain)现象，此时集群中会存在多个MASTER节点。
转载请注明： &
or分享 (0)}