OpenStack Neutron L3层高可靠

<span style="color:#333333;">[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: </span><span style="color:#ff0000;"><strong>ha-45249562-ec</strong></span><span style="color:#333333;">: <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</span>

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

* 我们是不是忘了Metadata Agent呢？

未来的工作和局限性

• TCP连接跟踪——在当前的实现中，TCP连接的session在失败恢复后中断。一种解决方案是使用conntrackd复制HA路由间的session状态，这样当故障恢复后，TCP的session会恢复到失败前的状态。
• Master节点在哪？当前，还没有办法让管理员知道哪个网络节点是HA路由的Master实例。计划由Agent提供这些信息，并可以通过API进行查询。
• Agent大逃亡——理想状态下，将一个节点变为维护模式后，应该触发所有HA路由所在节点回收他们的Master状态，加速恢复速度。
• 通知L2pop VIP的改变——考虑在一个tenant网络中路由IP/MAC，只有Master配置真正的有IP地址，但是同一个Neutron Port和同样的MAC会在相关的网络出现。这可能对配置了L2pop驱动产生不利，因为它只希望在一个网络中MAC地址只存在一处。解决的计划是一旦检测到VRRP状态改变，从Agent发送一个RPC消息，这样当路由变为Master，控制节点被通知到了，这样就能改变L2pop的状态了。
• 内置的防火墙、VPN和负载均衡即服务。在DVR和L3 HA与这些服务整合时还有问题，可能会在kilo中解决。
• 每一个Tenant一个HA网络。这就意味着每个Tenant只能有255个HA路由，因为每个路由需要一个VRID，根据VRRP协议每个广播域只允许255个不同的VRID值。

使用和配置

l3_ha = True
max_l3_agents_per_router = 2
min_l3_agents_per_router = 2

• l3_ha 表示所有的路由默认使用HA模式(与之前不同)。默认是关闭的。
• 你可以根据网络节点的数量设置最大最小值。如果你部署了4个网络节点，但是设置最大值为2，只有两个L3 Agent会被用于HA路由(一个是Master，一个是Slave)。
• min被用来稳健性(sanity)的检查：如果你有两个网络节点，其中一个坏掉了，任何新建的路由在这段时间都会失败，因为你至少需要min个L3 Agent启动来建立HA路由。

neutron router-create --ha=<True | False> router1

参考文档