AWS 亚马逊云实现内网资源高可用（Keepalived broadcast失效的情况） 博客分类： keepalived高可用mysqlawsha awskeepalived高可用hamysql
我们在测试环境用KeepAliveD已经实现了内网中的Mysql、Redis和MongoDb的高可用。等我们把测试环境中的方案部署到亚马逊云中，因为亚马逊云环境的一些特性，很多问题就显现出来了。
方案描述：
两台资源服务器上都部署了Mysql、Redis和MongoDb，两台服务器上的所有服务都会实时同步数据。每台个服务的KeepAliveD都会用IP欺骗的方法使用广播APR包虚拟出这些有一个对外的IP：
Mysql：172.*.*.201:3306
Redis：172.*.*.202:6379
MongoDb：172.*.*.203:27017
KeepAliveD会定期检查这两台服务器的三个服务器的健康情况，并通过VRRP协议互通监控情况。一旦任何一个服务出现故障，KeepAliveD会广播ARP包告诉大家，这台故障的服务器不再拥有这个虚拟IP，而是另一台健康的资源服务器才是这个虚拟IP的真正归属。这样所有发送给故障服务的请求就发送给另外一台资源服务器了。
第一.亚马逊云不支持KeepAliveD中的组播模式。主备之间的VRRP包互相发不通。
解决办法：切换KeepAliveD到单播模式，在配置中增加单播机器的IP即可：
unicast_peer {
172.*.*.124 #Resource-02
#172.*.*.207 #Management
}
配置细节见：http://fredlong.iteye.com/blog/2226300
还有一点需要特别注意，VRRP协议既不属于TCP也不属于UDP，在做防火墙策略的时候，在协议类型选项需要选“All traffice”的选项来防止由于防火墙原因造成通信问题。
第二.在AWS环境中，所有的ARP广播都被禁止了。这样KeepAliveD的IP欺骗机制基本上也就不可行了。在资源服务器上配置的Virtual IP，应用服务器没有办法访问。
我们尝试了很多办法都失败了，最终凭着机制和勇敢找到了解决方案。下面是简单的步骤和思路：
1.在两台服务器的网卡上把这三个虚拟IP都配上：
ifconfig eth0:1 172.*.*.201 netmask 255.255.240.0
ifconfig eth0:2 172.*.*.202 netmask 255.255.240.0
ifconfig eth0:3 172.*.*.203 netmask 255.255.240.0
这个配置是基础配置。也就是说，如果一个IP指向这台服务器，可是这台服务器上的网卡不认为自己拥有这个IP是不行的。
2.在两台服务器上安装亚马逊云自己的客户端工具(awscli)
easy_install pip
pip install awscli
3.在两台服务器上注册awscli，具体过程不详细描述了，就是到aws console/service/IAM中去创建一个账号，然后创建一个系统管理员的组，把这个账号加入到组中，这个过程中会得到Access Key ID和Secret Access Key。在服务器上运行awscli configure，填入刚才两个参数，还有region就完成注册了。region是指你服务器所在的区域，比如我们买的新加坡机房的服务器，region就填写ap-southeast-1。
4.在KeepAliveD认为自己获取到Master权限的时候，调用awscli命令让Virtual IP实际指向本服务器。这个逻辑是本文章的核心逻辑。亚马逊云虽然不允许广播ARP，但可以用命令行指定网卡（ENI）的Secondary-private-ip-address。这个命令的具体形式如下：
上面公式中，$ENI指的是网卡的实例Id，$VIP是虚拟IP。这条命令执行完之后，在亚马逊云的网络环境中，这个虚拟IP就指向运行了这条命令的机器了，IP切换完成。
下面是KeepAliveD的相关配置
通过测试，通过以上方案在亚马逊云（AWS）中实现内网资源服务器（数据库，缓存服务器等）高可用是可行的。