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各接管一台