1.IP漂移修改需求
目前IP漂移的方案直接建立在业务网卡上,每个系统可以在启动时加入相应的多播组,通过多播数据后,每个系统独立计算分析出谁该是这一个组中的master,分析的原则就是组内存活的最小IP所在的主机,在组内有系统down机时,master负责接管down的系统,down多少,接多少。
上述方案在系统压力不大时,基本不存在问题,即心跳数据正常,接管了down机后的系统仍能轻松运行。但是在攻击发生的时候,就存在许多不稳定因素,包括心跳数据包丢失导致误接管、多机接管一起的情况下负荷过重,从而引起IP冲突或雪崩情形,即同一个IP在多个机器上工作,或是本来只有一台机器故障,接管后导致master也故障,然后产生下一个master,也会依次故障。
具体需求如下:
- 直接使用业务口用组播做心跳协商,端口号udp 5000,组播地址默认为224.0.1.8,可配置;
- 支持备用机类型,master选举包含三个逻辑:已经接管数相同的情况下,优先从备用机上选择,在同类型的情况下,优先从IP地址小的上面选择;
- 支持1~n台备用机,备用机没有的情况下工作机接管,如果系统负载过大的情况不去接管。
- 已经被接管的IP,除非自身重启申请恢复,否则master切换时不漂移
2.IP漂移关键点分析
鉴于抗D环境攻击随时存在,所以必须启用备用机来做接管动作,在本身有较大流量压力的情况下,不能再接管其他系统,避免雪崩效应。
由于环境部署无法启用专用的心跳卡,所以对部署环境下可能存在的问题分析一下。
2.1接管情形下的关键点分析
接管情形下,可能导致的误接管因素包括:
- 工作机工作时,因负载大,外发心跳时系统会丢包
- 交换机负载过大,转发心跳包时会丢包
这种情况下,备用机可能存在误接管,必须启用接管前的验证,目前也有实现,即接管前尝试连接被接管主机的WEB服务。
.2.2恢复情形下的关键点分析
恢复情形下,备用机进入工作状态,接收的流量较大,可能存在两种情形下收不到心跳包:
- 交换机负载过大,转发心跳包会丢失
- 备用机工作时,因负载大,收包存在丢失的情况
这种情况下,备用机不知道工作机即将恢复,而无法释放IP,导致冲突。解决这一问题应考虑工作机恢复前的确认,即得不到接管者的释放声明,就不要尝试去恢复。
3业务流程设计
整体方案中涉及的数据包类型包括:
- 心跳广播,主要广播自己的状态和类型,通过心跳广播,可以协商出master来,master优先在备用机中产生,同种类型下从活跃主机里挑选IP值最小的,在备用机不够的情况下协商出来的master只在流量不大的情况下具备接管故障机的能力。如果是在压力不大的情况下接管的主机,但压力突然变大后,也很难释放,这种情况需要人工及时介入处理。
- Master声明,当有系统自认是master时,可以发出此声明,如果在两个周期后,没有收到其它人的master声明,则表示有效
- 详细信息,详细信息包括本系统的需要同步过去的IP列表,发现收到的广播中节点数不一致时广播,1秒一次,为保证都更新此信息,一直广播直到节点一致后1秒。
- 退出通知,接收正常信号退出时发送此类通知,连续广播多个间隔,如果收到大家的广播数少1及以上,则可马上退出,否则要达5个周期。
- 恢复确认,初始启动时,以备用身份启动,并广播自身信息,如果没有其它人广播自己的信息,则可以立即启用自己的IP,否则等待master发送恢复确认消息后,再启用自己的身份
整个组内系统运行过程中,至少有一台备用机,当备用机被使用时,应尽快处理后,让备用机复位。
工作机启动时,如果之前IP被接管,会有短暂的冲突。备用机故障时,不会被接管。
4测试场景
以6台机器组成的环境为例,
1)第一种模式
2台备用机(A1,B1),4台工作机(C,D,E,F)。以下故障都是指关机或断开网络。
序号 | 故障 | 期望 |
1 | C故障 | A1,或B1接管(哪个IP小哪个接管) |
2 | C、D故障 | A1,B1各接管一台 |
3 | C、D、E故障 | A1,B1各接管一台,由于没有备用机,则F会接管一台 |
4 | 以第3种故障追加F故障 | 则F上接管的两台会被A1,B1各接管一台 |
2)第二种模式
6台工作机
与上述类似。
5程序设计
IP漂移程序以独立程序运行,只监控默认路由接口的IP,出现故障时,其它机器接管的也是默认路由上的IP。用于同一组服务下不同主机的互备。
程序主要有三个线程负责工作,如下图,包括超时管理线程、定时发摘要及通告线程和实时接收处理线程。事实上,便于运行维护,还有一个OP线程,可以通过本地telnet的方式打开命令行终端,有简单的命令支持,默认使用的端口号是6000。
接收到的各类型数据处理如下流程: