网关高可用协议：HSRP、VRRP、GLBP、CASP

网络中网关设备负责完成大部分的高级处理，因此网关设备的高可用十分重要。常见的高可用协议包括 HSRP、VRRP、GLBP、CASP。基本原理都是在一个组里面选出一个主节点，拿到虚的网关 IP 和 虚 MAC。这些协议也可以提供 IP 节点的高可用保护。

HSRP

全称是 Hot Standby Routing Protocol，Cisco 家 98 年公开的专利协议，在 RFC 2281 中给出。

一主一从，其它为监听状态。组内多播到 224.0.0.2（v1）或 224.0.0.102（v2），虚地址不能跟物理地址重复，虚 MAC 地址为00-00-0c-07-AC-XX。

基本只有 Cisco 家设备支持。

VRRP

全称是 Virtual Route Rendundancy Protocol，IETF 的标准协议，在 RFC 3768 和 RFC 5798 中给出。设计思路是基于 HSRP，所以两者之间在概念上有很多相似之处，但并不兼容。

一主多从。组内 IP 多播到 224.0.0.18，IP 协议号为 112。虚地址可以复用物理地址，虚 MAC 为 00-00-5E-00-01-XX。

除了 Cisco，别家硬件支持的较多，另外有开源软件实现，Linux 上的 VRRPd。

用 VRRPd 配置的话很简单，指定网卡，本机的优先级，所属的组号和虚 IP 即可，例如

$ vrrp –i eth0 –p 24 –v 1 192.168.1.1

GLBP

GLBP 也是 Cisco 家的私有协议，基于 HSRP，最大的改进是考虑了负载均衡。特别之处的设计在于通过激活的虚网关（Active Virtual Gateway）来负责响应网络中的 ARP 请求，虚网关会根据权重来答复不同的成员的虚 MAC 地址。

组内多播到 224.0.0.2（v1）或 224.0.0.102（v2），协议基于 UDP，目标和源端口都是 3222。

最多同时可有 4 个转发网关。

CASP

全称是 Common Address Redundancy Protocol，非标准协议，最初是为了避免 HSRP 的专利风险，由 OpenBSD 在 2003 年完成的全新的设计，加强了安全性，带有负载均衡功能。

OpenStack 部署分布式应用的一个坑

之前基于 OpenStack 部署了一个云，运营下来一段时间下来还算正常，出现了各种问题也是意料之内，基本都很快搞定。

搞云计算的人嘛，就得懂得多一些、深一些不是：）

但有一天有个客户找上来反映了一个小问题，虽然最终解决掉，却引发了我的深思。

问题

客户的应用很简单，也是在我们的平台上申请了虚机，然后自己用 keepalived 为后面的某 db 业务提供 HA 保障。一切运行的都很正常，突然有一天，死活访问不通 db 了。

通过查看日志，发现故障发生前 keepalived 发生了切换，灾备节点被切换了。一开始怀疑是 keepalived 配置问题，检查后发现都正常，而且灾备节点确实也拿到地址了。我们搞运维的同学怀疑是网络问题，但底下排查了半天，也没找到原因，而且别的业务都跑的好好的。

分析和解决

出现问题肯定不会是莫名其妙的，我仔细回想了 VRRP 的原理和 Neutron 的实现。keepalived 基于 VRRP 来切换主从节点，被激活的节点会抢到配置的虚地址。然而，neutron 里面为了防止虚机作恶，会记录每个虚机启动时候分配的 IP 和 Mac，并用这个地址来过滤，避免出现篡改源地址的恶意流量。好了，那问题来了，neutron 并不知道某个虚地址其实是在两个 port 上都可能出现的，就会阻碍切换后的灾备节点流量通信。

问题定位到，就好解决了，直接改 iptables 规则，或者开启 Allowed-Address-Pairs (https://review.openstack.org/#/c/38230/) 即可。

进一步思考

从应用的角度看，VRRP 这种切换地址机制毫无问题；从 OpenStack 角度看，你申请一个虚机配置好了地址后，我只允许已知地址的流量出来，也是正常的。但偏偏两个结合到一起就有了问题。这根子上还是在于上层应用和底层平台之间的整合出现了偏差。其实系统就是这样，俩都正常的组件，放一起不出问题的概率很小，这也是为啥接口设计很关键。

我们一直说，要懂业务，要理解业务，其实也是避免设计出的产品跟真实的需求出现偏差。

首先，客户往往并不懂技术（甚至自己都不懂业务），这意味着他们很难用准确的语言描述清楚自己的真正需求（甚至自己都不知道真正需求是啥）。这就需要提供服务的团队要做到比客户更懂自己的业务，这是赢得客户信任的一个极大的优势。懂得从客户需求到业务流程到底下各种技术栈的灵活运用，这才是优秀的技术人员。

另外，就是产品的形态很重要，为什么现在云有 IaaS、PaaS、SaaS 等多种分类，其实这不同的产品形态都是针对不同的客户群体，满足不同的业务需求。呈现细节越少，意味着灵活性越差，但客户使用难度会降低。但无论是那种形态，都应该有严格的范围限制和操作保障，要让完全不懂技术的人能成功操作，甚至各种误操作也能纠正过来。在这点上，OpenStack 是做得很差的，这也是为什么基于 OpenStack 做云服务，首要任务是替换掉 Horizon。极简设计和极繁设计，无所谓高低，合适最好。

最后就是要选择合适的工具。现在开源特别发达，甚至同一个应用场景会出现数个优秀的开源产品，光看特性都是很吸引人。这个时候，选择就很重要了，最看重啥特性？二次开发的难度有多大？针对需求选这个是否合适？选择对了，事半功倍，反之往往陷入各种坑难以自拔。