作者：Liping Mao 发表于：2014-08-20
版权声明：能够随意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明
近期Assaf Muller写了一篇关于Neutron L3 HA的文章非常不错。
建议看原文。地址例如以下：
http://assafmuller.wordpress.com/category/ml2/
大致翻译例如以下：
如果我们有3个网络节点。创建的一些虚拟路由会被分配到这三个节点上。
然而，如果某一个节点down掉了。全部在这个节点上的虚拟路由器会中断服务。在Icehouse的neutron中还没有build-in的解决方式。
neutron.conf:
dhcp_agents_per_network = X
那么这是怎样工作的呢？
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbWF0dF9tYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
10.0.0.2，而且指定dnsmasq1的ip 10.0.0.253 。两台DHCP server都会收到广播包，可是仅仅有dnsmasq1会回复ACK。由于全部的DHCP通信都是通过广播。那么dnsmasq2也会收到ACK，能够标记10.0.0.2被AA：BB：CC：11:22:33使用了，就不会将此IP分配给其它Server了。总的来说，由于clients和servers全部的通信都是通过广播。这样就仅仅须要简单的部署多个DHCP server就能达到HA的效果了。
)
假设有上千个虚拟路由的话那failover可能须要以小时计的down time。
https://docs.google.com/document/d/1jCmraZGirmXq5V1MtRqhjdZCbUfiwBhRkUjDXGt5QUQ/
https://docs.google.com/document/d/1depasJSnGZPOnRLxEC_PYsVLcGVFXZLqP52RFTe21BE/
Floating IP将被你计算节点直接路由。网关SNAT的traffic将会走网络节点带HA的L3 agent。
What is VRRP, how does it work in the physical world?
(什么是VRRP，它是怎样工作的)
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbWF0dF9tYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
这样能够提供负载分流，可是假设一个路由器down了就有问题了。自然的就会想到使用一个虚拟IP作为server的默认网关。当Master的路由down了之后，standby的路由器不会收到从Master发出的VRRP hello包，这样就会导致standbys的路由器的一次选举。获胜者将作为新的Master。
新的Master将使用VIP。并须要发出gratuitous ARP用于刷新servers的ARP cache。交换机也会知道此虚拟MAC从旧的port移动至了新的port。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbWF0dF9tYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
通过这样做了之后，默认路由会改为新的Active的路由，可是没有实现负载分流。那么怎样同一时候做到负载分流呢？能够通过VRRP groups，一半的servers使用第一个VIP，还有一半的servers使用第二个VIP。
这种话随意的路由 down掉之后就会移至还有一台路由。
细心的读者可能会想到一个问题，假设路由的external网络连接断了会怎么样呢？他还会是active的路由吗？事实上VRRP是有能力监控external网络，这样就能够把external网络断掉的路由器标示为failure。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbWF0dF9tYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
VRRP – The Dry Facts(VRRP基本知识)
HA routers在namespace中，有一个'HA' device：当一个HA router被创建时，它会被schedule到多个网络节点。每个namespace都会通过HA
device连接到HA网络。
Keepalived的控制流就是通过HA device转发的。下面是router namespace的"ip addr"输出：
[stack@vpn-6-88 ~]$ sudo ip netns exec qrouter-b30064f9-414e-4c98-ab42-646197c74020 ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
...
2794: ha-45249562-ec: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 12:34:56:78:2b:5d brd ff:ff:ff:ff:ff:ff
inet 169.254.0.2/24 brd 169.254.0.255 scope global ha-54b92d86-4f
valid_lft forever preferred_lft forever
inet6 fe80::1034:56ff:fe78:2b5d/64 scope link
valid_lft forever preferred_lft forever
2795: qr-dc9d93c6-e2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether ca:fe:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 scope global qr-0d51eced-0f
valid_lft forever preferred_lft forever
inet6 fe80::c8fe:deff:fead:beef/64 scope link
valid_lft forever preferred_lft forever
2796: qg-843de7e6-8f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether ca:fe:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
inet 19.4.4.4/24 scope global qg-75688938-8d
valid_lft forever preferred_lft forever
inet6 fe80::c8fe:deff:fead:beef/64 scope link
valid_lft forever preferred_lft forever
他们是作为配置项写在keepalived的配置文件里的。当keepalived检測到master down掉时，这些地址将会被配置上去。这里是keepalived.conf的样例：
vrrp_sync_group VG_1 {
group {
VR_1
}
notify_backup "/path/to/notify_backup.sh"
notify_master "/path/to/notify_master.sh"
notify_fault "/path/to/notify_fault.sh"
}
vrrp_instance VR_1 {
state BACKUP
interface ha-45249562-ec
virtual_router_id 1
priority 50
nopreempt
advert_int 2
track_interface {
ha-45249562-ec
}
virtual_ipaddress {
19.4.4.4/24 dev qg-843de7e6-8f
}
virtual_ipaddress_excluded {
10.0.0.1/24 dev qr-dc9d93c6-e2
}
virtual_routes {
0.0.0.0/0 via 19.4.4.1 dev qg-843de7e6-8f
}
}
#!/usr/bin/env bash
neutron-ns-metadata-proxy --pid_file=/tmp/tmpp_6Lcx/tmpllLzNs/external/pids/b30064f9-414e-4c98-ab42-646197c74020/pid --metadata_proxy_socket=/tmp/tmpp_6Lcx/tmpllLzNs/metadata_proxy --router_id=b30064f9-414e-4c98-ab42-646197c74020 --state_path=/opt/openstack/neutron --metadata_port=9697 --debug --verbose
echo -n master > /tmp/tmpp_6Lcx/tmpllLzNs/ha_confs/b30064f9-414e-4c98-ab42-646197c74020/state
backup和fault脚本会kill neutron-ns-metadata-proxy进程，并记录相应状态。这意味着neutron-ns-metadata-proxy只会在master上存在。
解决问题的计划是：当agent检測到VRRP状态发生变化时，发送RPC消息。也就是说当一个路由变为Master时。Controller会收到消息并通知L2pop更新。
neutron.conf:
l3_ha = True
max_l3_agents_per_router = 2
min_l3_agents_per_router = 2
当你的网络节点个数小于min时，HA路由会创建失败。
neutron router-create --ha=<True | False> router1