作者：Liping Mao  發表於：2014-08-20
版權宣告：可以任意轉載，轉載時請務必以超連結形式標明文章原始出處和作者資訊及本版權宣告

最近Assaf Muller寫了一篇關於Neutron L3 HA的文章很不錯。

建議看原文，地址如下：

http://assafmuller.wordpress.com/category/ml2/

大致翻譯如下：

L3 Agent Low Availability(L3 agent的低可用性) 目前，在Openstack中，你只能用多個網路節點達到負載分流，但是做不到HA。假設我們有3個網路節點，建立的一些虛擬路由會被分配到這三個節點上。然而，如果某一個節點down掉了，所有在這個節點上的虛擬路由器會中斷服務。在Icehouse的neutron中還沒有build-in的解決方案。 A Detour to the DHCP Agent(看看DHCP Agent是怎麼做的) DHCP是完全不同的情況。DHCP協議支援多個DHCP Server擁有相同的pool同時共存。 通過修改以下配置：

neutron.conf:
dhcp_agents_per_network = X

你就會將每個network的DHCP分配到X個DHCP agents。所以，如果你部署了3個網路節點，並且設定了dhcp_agents_per_network=2，那麼每個neutron的network會被這3個網路節點中的2個DHCP agents服務。那麼這是如何工作的呢？
首先我們看一下在實體機的情況下是怎麼做的。當server連入到10.0.0.0/24子網時，它會廣播出DHCP discover。兩個DHCP Servers dnsmasq1和dnsmasq2(或者其他的DHCP Server實現)會收到廣播包，之後回覆一個offer ip是10.0.0.2。假設第一臺dnsmasq1的response被server先收到，它就會廣播request 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的效果了。 在Neutron的情況下，MAC和IP的繫結關係是在建立port時設定好的。因此，所有的dnsmasq都會在收到請求前就知道MAC(AA:BB:CC:11:22:33)和IP(10.0.0.2)綁定了。可以看出DHCP HA是在協議層面就支援的。 Back to the Lowly Available L3 Agent(回到L3 Agent的低可用性) L3 agent目前和DHCP的情況不同，那麼如果需要做HA是怎麼做的呢？ 使用外部的Cluster技術(Pacemaker / Corosync)指定一個Standby網路節點，當active網路節點發生問題時，L3agent會起到standby節點上。兩個節點擁有相同的hostname。 另一個方案是寫一個指令碼作為cron job，它會呼叫api獲得哪些L3 agents死了，然後將屬於這些L3 agents的虛擬路由reschedule到其他L3 agents。 Rescheduling Routers Takes a Long, Long Time(rescheduling虛擬路由會花很長時間。。。) 所有的這些都需要很長的時間將虛擬路由reschedule到新的L3 agent。如果有上千個虛擬路由的話那failover可能需要以小時計的down time。 Distributed Virtual Router(分散式虛擬路由) 這裡有些文件說明它是如何工作的: 它主要是將路由移至計算節點： DVR只處理Floating IPs， 預設閘道器的SNAT還是在網路節點的L3 agent上做。 DVR目前不支援VLAN模式，只能同tunnels和L2pop啟用時工作。 在每一個計算節點上都需要連線到外部網路。 總的來說，如果你的部署是基於havana或者icehouse，那DVR會需要對你的部署有比較大的改動。而L3 HA會更貼近你當前的部署。 理想情況下，你應該使用DVR+L3 HA 。 Floating IP將被你計算節點直接路由，閘道器SNAT的traffic將會走網路節點帶HA的L3 agent。 Layer 3 High Availability(L3的高可用性) 在Juno裡，我們使用keepalived做L3的HA。 Keepalived內部使用的是VRRP，那麼首先我們看一下VRRP。

What is VRRP, how does it work in the physical world?(什麼是VRRP，它是如何工作的)

VRRP是為了解決網路預設閘道器的HA的問題。那麼是怎麼做的呢？當我們在有兩臺路由的網路拓撲中，你可以指定一半的server是第一個路由的IP地址，另外一半server指定到第二個路由的IP地址。

這樣可以提供負載分流，但是如果一個路由器down了就有問題了。自然的就會想到使用一個虛擬IP作為server的預設閘道器。當Master的路由down了之後，standby的路由器不會收到從Master發出的VRRP hello包，這樣就會導致standbys的路由器的一次選舉，獲勝者將作為新的Master。新的Master將使用VIP，並需要發出gratuitous ARP用於重新整理servers的ARP cache，交換機也會知道此虛擬MAC從舊的port移動至了新的port。

通過這樣做了之後，預設路由會改為新的Active的路由，但是沒有實現負載分流。那麼如何同時做到負載分流呢？可以通過VRRP groups，一半的servers使用第一個VIP，另一半的servers使用第二個VIP。這樣的話任意的路由 down掉之後就會移至另一臺路由。

細心的讀者可能會想到一個問題，如果路由的external網路連線斷了會怎麼樣呢？他還會是active的路由嗎？其實VRRP是有能力監控external網路，這樣就可以把external網路斷掉的路由器標示為failure。

Note：對於IP地址，有下面兩種可行的方案： 1. 每個路由器都擁有自己的IP地址，VIP在master作為additional或者secondary IP。 2. 只有VIP一個地址，只有master有IP地址，slaves沒有IP地址。

VRRP – The Dry Facts(VRRP基本知識)

1. 直接通過IP協議封裝。 2. master使用組播地址224.0.0.18 MAC地址為01-00-5E-00-00-12傳送給standby節點Hello訊息。 3. 虛擬MAC的地址是00-00-5E-00-01-{VRID}， 因此在同一個廣播域中有256個VRIDs(0到255)。 4. 選舉的過程使用的是使用者設定的priority值，範圍是1-255， 數值越大優先順序越高。 5. 搶佔式(preemptive)選舉，這和其他的網路協議一樣，當優先順序高的路由器加入或者從錯誤狀態中恢復時，會搶佔成為master。 6. 非搶佔式(non-preemptive)選舉，當優先順序高的路由器加入或者從錯誤狀態中恢復時，不會搶佔成為master，還是維持slave的狀態。 7. hello訊息的週期是可配置的，如果standby在3倍週期內沒有收到hello訊息就會發起選舉。 Back to Neutron-land(回來看neutron的情況) L3 HA會在每一個router的namespace中啟動一個keepalived。不同的router通過專用的HA網路通訊。每一個tenant一個有一個專用的HA網路。HA網路和一般的網路沒什麼不同，只是它本身沒有屬於某個tenant，所以在CLI和GUI中是看不到的。HA routers在namespace中，有一個'HA' device：當一個HA router被建立時，它會被schedule到多個網路節點，每個namespace都會通過HA device連線到HA網路。Keepalived的控制流就是通過HA device轉發的。以下是router namespace的"ip addr"輸出：

[[email protected] ~]$ 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

這是master的輸出，在另一個網路節點上會有同樣的ha, qr 和qg，但是他們沒有IP。同時也沒有floating ip並且路由表為空。 他們是作為配置項寫在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
    }
}

這裡的notify指令碼是什麼呢？這些指令碼是keepalived在狀態轉換為master、backup或者fault時執行的。這裡是轉換為master的指令碼例子：

#!/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

這個指令碼僅僅是啟動了neutron-ns-metadata-proxy,再將狀態寫到了狀態檔案中(狀態檔案之後會被L3讀取)。backup和fault指令碼會kill neutron-ns-metadata-proxy程序，並記錄對應狀態。這意味著neutron-ns-metadata-proxy只會在master上存在。 * Aren’t We Forgetting the Metadata Agent?(我們忘了Metadata agent了嗎？) 你只需要將其(neutron-metadata-agent)在每個網路節點上跑著就可以了。 Future Work & Limitations(將來的工作和目前的限制) 1. TCP連線 -- 目前的實現中，TCP sessions會在failover的時候中斷。理想情況下，使用conntrackd應該可以做到sessions在failover時不中斷。 2. Master Router在哪裡？ 目前管理員不知道master在哪個網路節點中，計劃是agents上報這個資訊，然後通過API暴露出去。 3. 當需要維護一個網路節點時，我們所有Master能夠放棄Master狀態，這樣可以加快failover。 4. 通知l2pop VIP的移動。Master節點會擁有VIP，但是Standby會存在同樣的neutron port和MAC地址。這會對L2pop產生不利影響，因為它認為MAC地址是隻存在於網路的某一位置的。解決這個問題的計劃是：當agent檢測到VRRP狀態發生變化時，傳送RPC訊息，也就是說當一個路由變為Master時，Controller會收到訊息並通知L2pop更新。 5. FW, VPN和LB，與DVR和L3 HA整合時都有問題，在Kilo版本中會深入去看。 6. 每個tenant有1個HA網路，這就限制了每個tenant有255個HA Router，因為VRID在同一廣播域中有255個的限制。 Usage & Configuration(使用和配置)

neutron.conf:
l3_ha = True
max_l3_agents_per_router = 2
min_l3_agents_per_router = 2

l3_ha=Ture表示所有的虛擬路由都是HA模式的，預設為false 你可以設定HA Router被schedule到max和min數目的網路節點數。比如你有4個網路節點，你設定了max和min為2，那麼每個HA router會被schedule到兩個L3 agent上。當你的網路節點個數小於min時，HA路由會建立失敗。 CLI可以覆蓋l3_ha的配置(必須擁有admin許可權)：

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

References BP:  spec:  How to test:  Code:  Wiki: Section in Neutron L3 sub team wiki (Including overview of patch dependencies and future work):