理解 OpenStack 高可用（HA）（2）：Neutron L3 Agent HA 之虛擬路由冗餘協議（VRRP）

本系列會分析OpenStack 的高可用性（HA）概念和解決方案：

1. 基礎知識

1.1 虛擬路由冗餘協議 - VRRP

1.1.1 概念

路由器是整個網路的核心。一個網路內的所有主機往往都設定一條預設路由，這樣，主機發出的目的地址不在本網段的報文將被通過預設路由發往路由器，從而實現了主機與外部網路的通訊。在通常只使用單路由器來承擔預設路由的情況下，當該路由器壞掉後，本網段內所有以它為預設路由下一跳的主機將斷掉與外部的通訊。可見，在使用單路由器的情況下，如果路由器發生致命性的故障，將導致本地網路的癱瘓，如果是骨幹路由器，影響的範圍將更大，所造成的損失也是難以估計的。因此，對路由器採用熱備份是提高網路可靠性的必然選擇。

VRRP（Virtual Router Redundancy Protocol，虛擬路由冗餘協議）是一種可以解決這種問題的容錯協議，其協議文字在這裡。它保證當主機的下一跳路由器出現故障時，由另一臺路由器來代替出現故障的路由器進行工作，從而保持網路通訊的連續性和可靠性。一組實現了該協議的路由器向區域網內的主句提供具有高可用性（HA）的虛擬路由器。

1.1.2 VRRP 怎麼解決問題

VRRP 將一組物理路由器組織成一個虛擬路由器，稱之為一個備份組。這個虛擬的路由器擁有自己的 IP 地址，區域網內的機器使用該 IP 地址作為其預設路由器的地址。

以上圖為例，

Device A 和 B 組成一個 VRRP 組，它的虛擬 IP（VIP）為 10.1.1.10/24。其中，通過選舉機制，A 是 Master Router，B 是 Backup Router。一個 VRRP 組內可以由多個裝置，但是隻有一個是 Master 裝置。

Device A 和 B 可以由自己的 IP 地址，VIP 可以和其中的某 IP 相同，也可以不同。
當前，Router A 作為 Master router 向區域網內的機器提供路由服務。
當前，Router B 作為 Backup router。它的任務是週期性地接受 A 發出的心跳。在規定的時間段內，如果都沒有收到 A 發出的心跳，則啟動一個選舉過程，重新選出 Master。
區域網內的機器將虛擬路由器當作預設閘道器，它們僅僅知道這個虛擬路由器的IP 地址 10.1.1.10，而並不知道具體的 Master 路由器的 IP 地址以及 Backup 路由器的IP 地址。它們將自己的預設路由下一跳地址設定為10.1.1.10。於是，網路內的主機就通過這個虛擬的路由器來與其它網路進行通訊。如果 Master 路由器壞掉，Backup 路由器將會通過選舉策略選出一個新的 Master 路由器，繼續向網路內的主機提供路由服務。從而實現網路內的主機不間斷地與外部網路進行通訊。

可以看出：

VRRP 是一種路由器選擇協議，它可以把一個虛擬路由器的責任動態分配到 VRRP 組內的多個路由器中的一臺。控制虛擬路由器 IP 地址的 VRRP 路由器稱為主路由器，它負責轉發資料包到這些虛擬 IP 地址。一旦主路由器不可用，這種選擇過程就提供了動態的故障轉移機制，這就虛擬允許路由器的 IP 地址可以作為終端主機的預設第一跳路由器。使用 VRRP 的好處是有更高的預設路徑的可用性而無需在每個終端主機上配置動態路由或路由發現協議。
VRRP 包封裝在 IP 包中傳送，用於 VRRP 組內裝置的互相通訊比如保持心跳等。它只定義了一種報文即 VRRP 報文，這是一種組播報文，由 Master 路由器定時發出來通告組內的路由器它的存在。
VRRP 中定義了三種狀態模型，初始狀態 Initialize，活動狀態 Master 和備份狀態 Backup，其中只有活動狀態的交換機可以為到虛擬IP地址的的轉發請求提供服務。

幾個概念：

VIP：VRRP 使用兩種型別的 VIP：一種 VIP 參與 VRRP 通告，使用配置項 virtual_ipaddress 指定；另一種 VIP 不參與 VRRP 通告，使用配置項 virtual_ipaddress_excluded 指定。
優先順序（Priority）：虛擬路由器中VRRP裝置的優先順序。虛擬路由器根據優先順序選舉出Master裝置和Backup裝置。
搶佔模式：在搶佔模式下，如果 Backup 裝置的優先順序比當前 Master 裝置的優先順序高，則主動將自己切換成 Master。
非搶佔模式：在非搶佔模式下，只要 Master 裝置沒有出現故障，Backup 裝置即使隨後被配置了更高的優先順序也不會成為Master裝置。
VRRP協議報文：封裝在IP報文中，傳送到分配給 VRRP 的 IP 組播地址。在IP報文頭中，源地址為傳送報文介面的主 IP 地址（不是虛擬IP地址），目的地址是224.0.0.18，TTL是255，協議號是112。目前，VRRP協議包括兩個版本：VRRPv2和VRRPv3，VRRPv2僅適用於IPv4網路，VRRPv3適用於IPv4和IPv6兩種網路。
VRRP 節點三種狀態：初始狀態（Initialize）、活動狀態（Master）、備份狀態（Backup）。其中，只有處於Master狀態的裝置才可以轉發那些傳送到虛擬IP地址的報文。

Master 路由器的選舉過程：

VRRP根據優先順序來確定虛擬路由器中每臺路由器的角色（Master 路由器或 Backup 路由器）。優先順序越高，則越有可能成為 Master 路由器。
初始建立的 VRRP 交換機工作在 Initialize 狀態，收到介面 Up 的訊息後，若此路由器的優先順序小於255，則會先切換至 Backup 狀態，待 Master_Down_Interval 定時器超時後再切換至 Master 狀態。首先切換至 Master 狀態的 VRRP 路由器通過 VRRP 通告報文的互動獲知虛擬交換機中其他成員的優先順序，進行Master的選舉：

- 如果 VRRP 報文中 Master 路由器的優先順序高於或等於自己的優先順序，則 Backup 路由器保持 Backup 狀態；
- 如果 VRRP 報文中 Master 路由器的優先順序低於自己的優先順序，採用搶佔方式的 Backup 交換機將切換至 Master 狀態，採用非搶佔方式的Backup 路由器仍保持Backup狀態。
- 如果多個 VRRP 路由器同時切換到 Master 狀態，通過 VRRP 通告報文的互動進行協商後，優先順序較低的 VRRP 路由器將切換成 Backup 狀態，優先順序最高的 VRRP 路由器成為最終的 Master裝置；優先順序相同時，VRRP 路由器上 VRRP 備份組所在介面主 IP 地址較大的成為 Master 裝置。
- 如果建立的VRRP 路由器為IP地址擁有者，收到介面 Up 的訊息後，將會直接切換至Master狀態。

Master交換機狀態的通告：

Master 路由器週期性地傳送 VRRP 通告報文，在 VRRP 備份組中公佈其配置資訊（優先順序等）和工作狀況。Backup 路由器通過接收到 VRRP 報文的情況來判斷Master 路由器是否工作正常。
- 當 Master 路由器主動放棄 Master 地位（如 Master 路由器退出備份組）時，會發送優先順序為0的通告報文，用來使 Backup 路由器快速切換成 Master 路由器，而不用等到 Master_Down_Interval 定時器超時。
- 當 Master 路由器發生網路故障而不能傳送通告報文的時候，Backup 路由器並不能立即知道其工作狀況。等到 Master_Down_Interval 定時器超時後，才會認為 Master 路由器無法正常工作，從而將狀態切換為 Master。

目前，主流的硬體路由器裝置都實現了該協議：這篇文章介紹了 Broadcom 路由器上 VRRP 的配置，這篇文章介紹了一個 Cisco 路由器 VRRP 的配置例子，這篇文章是華為的 VRRP 白皮書。

它的優勢：

操作簡單：它不需要改變組網情況，也不需要在主機上做任何配置，只需要在相關路由器上配置極少的幾條命令，就能實現下一跳閘道器的備份，並且不會給主機帶來任何負擔。和其他方法比較起來，VRRP更加能夠滿足使用者的需求。
簡化網路管理：在具有多播或廣播能力的區域網（如乙太網）中，藉助 VRRP 能在某臺裝置出現故障時仍然提供高可靠的預設鏈路，有效避免單一鏈路發生故障後網路中斷的問題，而無需修改動態路由協議、路由發現協議等配置資訊，也無需修改主機的預設閘道器配置。
適應性強：VRRP報文封裝在IP報文中，支援各種上層協議。
網路開銷小：VRRP只定義了一種報文——VRRP通告報文，並且只有處於Master狀態的路由器可以傳送VRRP報文。

其他參考文章：（1）（2）（3）。更多內容，參見協議文字，以及 VRRP 技術白皮書 - Huawei。

1.2 Keepalived

1.2.1 概念

Keepalived 是一個用 C 語言編寫的路由軟體，其主要目的是向 Linux 系統和基礎設施提供簡單可靠的工具來實現負載均衡（Load balancing）和高可用（HA）。其中，

負載均衡框架基於 Linux Virtual Server (IPVS) 核心模組來提供網路四層的負載均衡，它實現了一組檢查器（Checkers）來根據它們的健康狀態動態地和自適應地維護和管理被均衡的伺服器池。
高可用（HA）是使用 VRRP 來實現的，Keepalived 是 VRRP 的一個非常好的開源實現。它是一個基於 VRRP 協議來實現的 WEB 服務高可用方案，可以利用其來避免單點故障。一個 WEB 服務至少會由兩臺臺物理伺服器執行 Keepalived，一臺為主伺服器（MASTER），一臺為備份伺服器（BACKUP），但是對外表現為一個虛擬 IP，主伺服器會發送特定的訊息給備份伺服器，當備份伺服器收不到這個訊息的時候，即主伺服器宕機的時候，備份伺服器就會接管虛擬 IP，繼續提供服務，從而保證了高可用性。

1.2.2 軟體架構和功能

（本部分內容來自 Keepalived 官網）

Keepalived 使用三個程序，其中 Watchdog 是控制程序，VRRP Stack and Checkers 是它的兩個子程序。

Watchdog 通過心跳機制來確保子程序處於執行狀態。
Checkers：負責真實伺服器的健康檢測，用於負載均衡。
VRRP Stack：實現 VRRP 協議，提供 HA。

主要模組：

System call : 用於啟動使用者新增的指令碼。它可以被 Checkers 和 VRRP Stack 使用。它向 VRRP 框架提供了一種能力，即在 VRRP 協議狀態變化時可以執行使用者指定的指令碼。
SMTP : 使得 Keepalive 能夠使用郵件來通知管理員。
NETLINK Interface: 用於 VRRP。Keepalive 通過它來設定或者刪除 VIP。

VRRP Stack 模組：

VRRP Stack 是獨立於 LVS的，它可以被單獨使用。它主要提供以下功能：

Failover：實現 VRRP協議的核心功能，提供故障切換能力。
VRRP Instance synchronization：VRRP Group （組）之間的同步，比如保證兩個 VRRP 組直接保持同樣狀態。
VRRP 廣播：Master 例項通知 Backup 例項。
System call：在 VRRP 狀態變換時呼叫外部的指令碼或者程式。

它包括以下元件：

Netlink：提供 VIP 操作。
Multicast：用於傳送 VRRP 協議廣播。
SYSLOG：所有 daemon 的通知訊息都會通過該元件寫入日誌。

使用者可以使用配置檔案 /etc/keepalived/keepalived.conf 來配置 Keepalived。本部分主要講講 keepalived 的概念，使用會在下文談到。更多內容，參見官網。

1.2.3 keepalived 切換（failover）

在非搶佔模式下，只有噹噹前master出現故障了時，才會通過重新選舉才生新的 master。

在搶佔模式下，下面三個條件任何一個條件被滿足了的情況下會發生切換：

master 節點因為健康檢查失敗將其weight 降低至低於一個 slave 節點。
一個 slave 節點的weight 被配置為比當前 master 的weight 高。
當前master 節點不發出心跳資訊，比如當前節點宕機了，程序退出了，狀態進入 FAULT 了（一旦進入 FAULT 狀態，原 master 就會釋放 VIP，停止傳送心跳訊息）等等。

2. Neutron Juno 版本中 VRRP 的實現

在 OpenStack HA （1）概述一文中談到，Neutron L3 Agent 在 Juno 版本中添加了兩種 HA 機制的實現：VRRP 機制（blueprint， Spec，Wiki）和 DVR 機制。VRRP 機制就是藉助實現 VRRP 協議的軟體，來保證 Neutron L3 Agent 的高可用性。這需要多方面的實現：

建立 HA Router 時，建立多個 router 例項部署到不同物理伺服器上的 L3 Agent 中。這個實現需要修改 Neutron schedulers。
藉助實現 VRRP 的軟體，保證多個 L3 Agent 的 HA，即其中一個是 Master，其他是 Backup。由 Master 向虛機提供路由服務。在 Master 故障時，某個 Standby 被選舉為新的 Master，接替之前的 Master。目前的 Neutron VRRP 實現使用的是 Keepalived。
路由器故障切換時保持已建立的連線。Neutron 會使用 conntrack 來實現該功能。

2.1 建立 HA Router

neutron server 上：

（1）類似普通的 router，首先執行 DB 操作在 DB 中建立一個 router。

（2）檢查 router 所在的 tenant 中是否存在 HA Network，如果不存在的話，則建立名稱為 “HA network tenant”+ tenant_id 的 network，以及該 network 中的名字為 “HA subnet tenant” + tenant_id， cidr 為 cfg.CONF.l3_ha_net_cidr 的 subnet。其餘的引數皆為預設或者null。

[email protected]:~$ neutron net-show bc5501ed-56ee-4d32-974b-02279fb35c32
+---------------------------+----------------------------------------------------+
| Field                     | Value                                              |
+---------------------------+----------------------------------------------------+
| admin_state_up            | True                                               |
| id                        | bc5501ed-56ee-4d32-974b-02279fb35c32               |
| name                      | HA network tenant 74c8ada23a3449f888d9e19b76d13aab |
| provider:network_type     | gre                                                |
| provider:physical_network |                                                    |
| provider:segmentation_id  | 1                                                  |
| router:external           | False                                              |
| shared                    | False                                              |
| status                    | ACTIVE                                             |
| subnets                   | 2ce1ff9d-6889-41cb-8d6b-18e7ccd67a7b               |
| tenant_id                 |                                                    |
+---------------------------+----------------------------------------------------+

[email protected]:~$ neutron subnet-show 2ce1ff9d-6889-41cb-8d6b-18e7ccd67a7b
+-------------------+------------------------------------------------------+
| Field             | Value                                                |
+-------------------+------------------------------------------------------+
| allocation_pools  | {"start": "169.254.192.1", "end": "169.254.255.254"} |
| cidr              | 169.254.192.0/18                                     |
| dns_nameservers   |                                                      |
| enable_dhcp       | False                                                |
| gateway_ip        |                                                      |
| host_routes       |                                                      |
| id                | 2ce1ff9d-6889-41cb-8d6b-18e7ccd67a7b                 |
| ip_version        | 4                                                    |
| ipv6_address_mode |                                                      |
| ipv6_ra_mode      |                                                      |
| name              | HA subnet tenant 74c8ada23a3449f888d9e19b76d13aab    |
| network_id        | bc5501ed-56ee-4d32-974b-02279fb35c32                 |
| tenant_id         |                                                      |
+-------------------+------------------------------------------------------+

注意，當 tenant 最後一個 HA Router 被刪除的時候，該 HA network/subnet 不會被自動刪除，這裡有個 bug。看起來還沒有被 fixed，目前只能手動刪除。

（3）分配一個可用的 VRRP ID，該 ID 為 1 - 255 之間。

（4）建立與部署的 router 例項相同數量的 port 作為 HA Interfaces，每個 L3 Agent 上使用一個。

           {'tenant_id': '',
             'network_id': network_id,
             'fixed_ips': attributes.ATTR_NOT_SPECIFIED,
             'mac_address': attributes.ATTR_NOT_SPECIFIED,
             'admin_state_up': True,
             'device_id': router_id,
             'device_owner': constants.DEVICE_OWNER_ROUTER_HA_INTF,
             'name': constants.HA_PORT_NAME % tenant_id}})

比如需要部署的 router 的例項數目為2 的情況下，會分配 2 個port，分別用於各 router network namespace 中 keepalived 之間的通訊：

[email protected]:~$ neutron port-list | grep 169.254.192
| 20894a79-b668-44d9-bf42-ef6bc2981960 | HA port tenant 74c8ada23a3449f888d9e19b76d13aab | fa:16:3e:09:29:d4 | {"subnet_id": "2ce1ff9d-6889-41cb-8d6b-18e7ccd67a7b", "ip_address": "169.254.192.2"} |
| a8a3a49f-c175-4ea6-9342-240ef646e99c | HA port tenant 74c8ada23a3449f888d9e19b76d13aab | fa:16:3e:84:24:7f | {"subnet_id": "2ce1ff9d-6889-41cb-8d6b-18e7ccd67a7b", "ip_address": "169.254.192.1"} |

（5）schedule router。具體參見 2.1.2 章節.

（6）向待部署 router 例項的每個 L3 Agent 傳送 RPC Cast “routers_updated” 訊息

l3 ha router creation

每個 L3 Agent 上：

（1）迴圈執行的 routers_updated 方法將待處理的每個 router 加入到內部 queue 中，等待被 L3 Agent 啟動的迴圈執行緒處理

（2）處理過程可以參考我這篇文章的 3.1 部分

（3）在完成常規的 router 新增操作後，呼叫 process_ha_router_added 執行 HA 配置部分

（3.1）將 HA Port plug 到 OVS 的 br-int 上，並設定 interface 的三層屬性，比如 IP， gateway， route 等。

Bridge br-int
  Port "ha-20894a79-b6"
            tag: 7
            Interface "ha-20894a79-b6"
                type: internal

（3.2）準備 keepalived

（3.2.1）生成一個 keepalived 例項。該例項的初始狀態為 Backup，非搶佔式，VRRP 通告間隔2秒，優先順序為 50。

instance = keepalived.KeepalivedInstance('BACKUP', interface_name, ri.ha_vr_id, ha_port_cidr, nopreempt=True, advert_int=self.conf.ha_vrrp_advert_int, priority=ri.ha_priority)

（3.2.2）通過上面第三步分配的 VRRP ID，定位到 VRRP Group；然後將 3.2.1 中的 keepalived instance 加入到該 group 。

（3.2.3）將 group 和 instance 儲存到 keepalived config 中。

（4）呼叫 _add_keepalived_notifiers 方法來新增 neutron 需要的 keepalived notifiers。具體見 2.1.3 章節。

（5）呼叫 process_router 方法繼續處理該 route。對於HA Router，會首次啟動新的或者重啟已有的 keepalived 程序。

（5.1）生成 keepalived 配置。配置檔案的位置可以由配置項 vrrp_confs 指定，其預設值為 “$state_path/vrrp”。還可以使用配置項 ha_vrrp_auth_type （預設 'PASS'）和 ha_vrrp_auth_password （預設 none）指定 VRRP 組播的認證方法，以及使用配置項 ha_vrrp_advert_int （預設值 2）指定 VRRP 廣播發送的時間間隔。

vrrp_sync_group VG_1 { # VRRP ID 為 1
    group {
        VR_1
    }
    notify_master "/var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_master.sh"
    notify_backup "/var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_backup.sh"
    notify_fault "/var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_fault.sh"
}
vrrp_instance VR_1 {
    state BACKUP
    interface ha-20894a79-b6 # 例項繫結的網絡卡，因為在配置虛擬 IP 的時候必須是在已有的網絡卡上新增的
    virtual_router_id 1      # VRRP ID,每個 tenant HA Router 一個 ID
    priority 50              # 該 HA Router instance 的 優先順序，根據這個選舉 Master
    nopreempt                # 使用非搶佔模式
    advert_int 2             # VRRP 廣播發送間隔，單位秒
    track_interface {        # 跟蹤介面，設定額外的監控
        ha-20894a79-b6
    }
    virtual_ipaddress {      # 該 VRRP 的 VIP，格式為 HA Network CIDR 最後一位被 VID 替換，該例子中，CIDR 為 “169.254.0.1/24”， VID 為 1
        169.254.0.1/24 dev ha-20894a79-b6
    }
}

keepalived 各種配置說明：

配置	說明	neutron 用法
notify master/backup/fault	表示當該 VRRP 節點切換到 master/backup/fault 狀態時，要執行的指令碼	見本文 2.1.3 章節
state	state 指定 instance(Initial) 的初始狀態，就是說在配置好後，這臺伺服器的初始狀態就是這裡指定的，但這裡指定的不算，還是得要通過競選通過優先順序來確定，裡如果這裡設定為master，但如若他的優先順序不及另外一臺，那麼這臺在傳送通告時，會發送自己的優先順序，另外一臺發現優先順序不如自己的高，那麼他會就回搶佔為master	neutron 將所有 keeplived 例項的初始狀態都設定為 BACKUP，而且都使用預設優先順序 50。這樣實際上，一般來說，哪個 L3 Agent 先起來，它的 keepalived 例項就是 Master 了。
interface	VRRP 例項繫結的網絡卡，在此網絡卡上新增 VIP 作為 secondary IP	HA Interface
dont track primary	忽略 VRRP 的 interface 錯誤	不使用
track interface	跟蹤介面，設定額外的監控，裡面任意一塊網絡卡出現問題，都會進入故障(FAULT)狀態，例如，用nginx做均衡器的時候，內網必須正常工作，如果內網出問題了，這個均衡器也就無法運作了，所以必須對內外網同時做健康檢查	neutron 只跟蹤 HA Interface，其實它還是可以跟蹤 network namespace 的其他 interface，比如 qr，qg 等，是吧？
mcast src ip	傳送多播資料包時的源IP地址，這裡注意了，這裡實際上就是在那個地址上傳送VRRP通告，這個非常重要，一定要選擇穩定的網絡卡埠來發送，這裡相當於heartbeat的心跳埠，如果沒有設定那麼就用預設的繫結的網絡卡的IP，也就是interface指定的IP地址	不設定，預設使用 HA Interface IP
garp master delay	在切換到master狀態後，延遲進行免費的ARP(gratuitous ARP)請求	未指定
virtual router id	這裡設定VRID，這裡非常重要，相同的 VRID 為一個組，他將決定多播的MAC地址	建立 HA Router時從 neutron DB 分配，從 1 開始
priority 100	設定本節點的優先順序，優先順序高的為master	預設為 50
advert int	檢查間隔，預設為1秒	配置項 ha_vrrp_advert_int （預設值 2）
virtual ipaddress	這裡設定的就是VIP，也就是虛擬 IP 地址，他隨著 state 的變化而增加或者刪除，當 state 為master的時候就新增，當 state 為 backup 的時候刪除，這裡主要是有優先順序來決定的，和 state 設定的值沒有多大關係，這裡可以設定多個 IP 地址。這篇文章談到其數目限制為 20，超過該數目的 IP 可以放到 virtual_ipaddress_excluded。	VIP。格式為 HA Network CIDR 最後一位被 VID 替換，該例子中，CIDR 為 “169.254.0.1/24”， VID 為 1。因此，每個 HA Router 的 VIP 是固定的。
virtual routes	原理和 virtual ipaddress 一樣，只不過這裡是增加和刪除路由	不使用
authentication auth type auth pass	認證方式，型別，密碼	配置項 ha_vrrp_auth_type （預設 'PASS'）和 ha_vrrp_auth_password （預設 none）
nopreempt	設定不搶佔，這裡只能設定在state為backup的節點上，而且這個節點的優先順序必須別另外的高	設定，使用非搶佔模式。這樣，只要 Master 沒壞，即使 Backup 的優先順序更高，也不會觸發選舉
preempt delay	搶佔延遲	不使用
virtual_ipaddress_excluded	需要 keepalived 維護但是不會放在VRRP包中傳輸的IP。也就是說當某個router被選舉為master的時候其會的將qg口設定對應的IP。而在變為 backup 時，會將相應的 IP 刪除。	VIP。Neutron 將浮動 IP，internal/external port IP 等儲存在這裡。這樣，當一個 node 變為 master 的時候，這些 IP 地址會生效；當一個 node 變為 backup 的時候，這些 IP 地址會被刪除。
virtual_routes	在某個router設定為 master 的時候其會的設定對應的 route。相反的，如果一個router變成了backup，那麼上面這些操作會反過來做一遍。	每個 external port 對應一條路由，在 VRRP 狀態變化時增加或者刪除

（資料來源。Neutron 所使用的 keepalived config 模板在這裡）

（5.2）在 route network namespace 執行命令 'keepalived -P -f config_path -p pid_file -r pid_file-vrrp' 啟動 keepalived 程序。

root     31510     1  0 10:42 ?        00:00:00 keepalived -P -f /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/keepalived.conf -p /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid -r /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid-vrrp
root     31512 31510  0 10:42 ?        00:00:00 keepalived -P -f /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/keepalived.conf -p /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid -r /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid-vrrp

根據上面基礎知識部分的介紹，第一個程序（程序號 31510）是 Watchdog 程序，第二個程序（程序號 31512）是 VRRP Stack 程序。

（6） Neutron 中，keepalived 程序啟動後，初始狀態都是 BACKUP。在它指定時間沒收到 Master 的廣播後，它自己切換至 Master 狀態，然後通過 VRRP 通告報文的互動獲知虛擬路由器組中其他成員的優先順序，進行 Master 的選舉：

如果 VRRP 報文中 Master 路由器的優先順序高於或等於自己的優先順序，則 Backup 交換機保持 Backup 狀態。顯然，Neutron 中的 keepalived 都是同樣的優先順序，它們會各自保持自己的 BACKUP 狀態。
如果 VRRP 報文中 Master 路由器的優先順序低於自己的優先順序，因為 neutron 中 keepalived 採用非搶佔模式，Backup交換機仍保持 Backup 狀態。

可見，neutron 中，哪個 L3 Agent namespace 中的 keepalived 程序先啟動並先發出 VRRP 通告，則它會成為 Master，直到它 down 掉才會由別的節點接替。在狀態變化時，會呼叫指定的指令碼。詳細見 2.1.3 部分。狀態變化完成後，會達到下面這種效果（Juno 中還沒有實現 conntrack）：

（7）啟動後狀態轉換過程

Aug  1 18:42:32 network Keepalived[31509]: Starting Keepalived v1.2.7 (08/14,2013)    #程序啟動
Aug  1 18:42:32 network Keepalived[31510]: Starting VRRP child process, pid=31512     # VRRP Stack 程序啟動
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Interface queue is empty
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Registering Kernel netlink reflector
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Registering Kernel netlink command channel
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Registering gratuitous ARP shared channel
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Initializing ipvs 2.6
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Opening file '/var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/keepalived.conf'. #匯入配置檔案
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Configuration is using : 64796 Bytes
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Using LinkWatch kernel netlink reflector...
Aug  1 18:42:32 network Keepalived_vrrp[31512]: VRRP_Instance(VR_1) Entering BACKUP STATE #根據初始配置，首先進入 BACKUP 狀態
Aug  1 18:42:32 network Keepalived_vrrp[31512]: Opening script file /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_backup.sh #指令碼呼叫
Aug  1 18:42:39 network Keepalived_vrrp[31512]: VRRP_Instance(VR_1) Transition to MASTER STATE #第一次選舉後進入 Master 狀態
Aug  1 18:42:39 network Keepalived_vrrp[31512]: VRRP_Group(VG_1) Syncing instances to MASTER state
Aug  1 18:42:39 network Keepalived_vrrp[31512]: Opening script file /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_master.sh #指令碼呼叫
Aug  1 18:42:41 network Keepalived_vrrp[31512]: VRRP_Instance(VR_1) Entering MASTER STATE

（8）VRRP 心跳

下面的 log 能看出來，Master 每隔兩秒鐘，向組播地址 224.0.0.18/01:00:5e:00:00:12 發出長度為 54 bytes 的一個心跳：

ip netns exec qrouter-04f6e792-3b79-4b8f-a577-2ad38d33a2bb tcpdump -envi ha-20894a79-b6 -vvv

11:18:10.969378 fa:16:3e:09:29:d4 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 1066, offset 0, flags [none], proto VRRP (112), length 40)
    169.254.192.2 > 224.0.0.18: vrrp 169.254.192.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 50, authtype none, intvl 2s, length 20, addrs: 169.254.0.1
11:18:12.971101 fa:16:3e:09:29:d4 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 255, id 1067, offset 0, flags [none], proto VRRP (112), length 40)
    169.254.192.2 > 224.0.0.18: vrrp 169.254.192.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 50, authtype none, intvl 2s, length 20, addrs: 169.254.0.1

2.2 HA Router 排程（scheduling）

Neutron L3 Agent 的排程包括三個層面：

普通（Legacy）L3 Agent 排程：在存在多個 L3 Agent 的時候，通過隨機或者最小 router 數演算法找到一個 L3 Agent，將該 Router 部署在上面。
分散式（DVR）L3 Agent 排程：將 Router 分佈到所有計算節點和網路節點。
高可用（HA） L3 Agent 排程：見下文

關於 HA L3 Agent 的排程，這部分的實現程式碼在這裡。新的程式碼修改了已有的 scheduler 演算法，使得它們可以支援 HA Router，但是目前不能同時支援 DVR 和 HA Router。主要程式碼在 /n eutron/scheduler/l3_agent_scheduler.py。該實現在 Neutron server 配置檔案中添加了如下的配置項：

neutron.conf:
l3_ha = True #由管理做的全域性配置，建立的所有 router 均為 HA Router
max_l3_agents_per_router = 4 #每個 HA router 最多被部署到若干個 L3 Agent 上
min_l3_agents_per_router = 2 #每個 HA Router 最少被部署到若干個 L3 Agent 上

該檔案：

（1）檢查可用的 L3 Agent 數目（candidates）是否超過 conf.min_l3_agents_per_router 。

（2）確定部署的 router 數目，取 min（candidates，conf.max_l3_agents_per_router ）。

（3）實現兩個 scheduler 類：ChanceScheduler - 隨機地在可用的 L3 Agent 上部署 Router；LeastRoutersScheduler - 將 router 部署到所管理的 router 數目最少的 L3 Agent 上。它們根據不同的演算法選出待部署 router 例項的 L3 Agent。

（4）bind_router 函式會執行 db 操作，將 router 和 scheduler 選出的 L3 Agent 繫結在一起。比如：

2015-08-01 10:42:21.488 19430 DEBUG neutron.scheduler.l3_agent_scheduler [req-827c863f-cb01-4650-a26d-0f176ef84026 None] HA Router 04f6e792-3b79-4b8f-a577-2ad38d33a2bb is scheduled to L3 agent 04c360d0-3066-4f04-9af2-d4ef8586ad2b) bind_ha_router_to_agents /usr/lib/python2.7/dist-packages/neutron/scheduler/l3_agent_scheduler.py:330
2015-08-01 10:42:21.547 19430 DEBUG neutron.scheduler.l3_agent_scheduler [req-827c863f-cb01-4650-a26d-0f176ef84026 None] Router 04f6e792-3b79-4b8f-a577-2ad38d33a2bb is scheduled to L3 agent 4705d27c-5008-4828-b619-bbb2114188ba bind_router /usr/lib/python2.7/dist-packages/neutron/scheduler/l3_agent_scheduler.py:226

當確定的部署數量為2 時，會是下面的情形：

2.3 Keepalived notifier script （ VRRP 狀態變化時的通知指令碼）

Neutron 的 KeepalivedNotifierMixin 類實現了 keepalived 在 VRRP 狀態變化時的通知方法。Neturon 添加了 VRRP 狀態變為 master，backup 和 fault 狀態時的 notifier。

變更為 master 狀態時的 notifier script：

#!/usr/bin/env bash
neutron-ns-metadata-proxy --pid_file=/var/lib/neutron/external/pids/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid --metadata_proxy_socket=/var/lib/neutron/metadata_proxy --router_id=04f6e792-3b79-4b8f-a577-2ad38d33a2bb --state_path=/var/lib/neutron --metadata_port=9697 --debug --verbose --log-file=neutron-ns-metadata-proxy-04f6e792-3b79-4b8f-a577-2ad38d33a2bb.log --log-dir=/var/log/neutron
echo -n master > /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/state

第一個命令，在 router network namespace 中啟動 neutron-ns-metadata-proxy，這樣使用該 router 的虛機就可以通過該 proxy 訪問 metadata service 了。關於 metadata service， proxy 和 agent，可以參考文章（1）（2）（3）。

第二個命令，設定 state 檔案內容為 “master”。 Keepalived 不支援直接查詢 VRRP 狀態，因此，只能通過 state 變化時被呼叫的指令碼檔案來儲存其狀態。

變更為 backup 狀態的 notifier script：

#!/usr/bin/env bash
kill -9 $(cat /var/lib/neutron/external/pids/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid)
echo -n backup > /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/state

第一個命令，在 router network namespace 中殺掉 neutron-ns-metadata-proxy 程序，這樣使用該 router 的虛機就無法通過該 proxy 訪問 metadata service 了。

第二個命令，在 state 檔案中記錄 VRRP state 為 “backup”。

#!/usr/bin/env bash
kill -9 $(cat /var/lib/neutron/external/pids/04f6e792-3b79-4b8f-a577-2ad38d33a2bb.pid)
echo -n fault > /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/state

因此，第一次 VRRP 選舉完成後，即有一個 Master router 被選舉出來。這時候，各節點上不同的 script 會執行不同的動作：

Master router 的節點上：啟動 route namespace 對應的 neutron-ns-metadata-proxy 程序，儲存 “master” 至 state 檔案，設定 VIP（包括配置檔案中 virtual ipaddress 指定的 IP 地址和 virtual_ipaddress_excluded 部分的 IP 地址）和 virtual_routes 部分的 route。
Slave router 的節點上：殺掉 route namespace 對應的 neutron-ns-metadata-proxy 程序，儲存 “backup” 至 state 檔案，清除 VIP 和 virtual_routes 部分的 route。

2.4 依次新增 gateway，subnet，虛機和浮動 IP

這些操作都是對已有 HA router 的更新。當 HA Router 的資訊發生改變的時候，執行 DB 操作後，Neutron Server 會通知部署有 router 例項的 L3 Agent，然後它會去獲取到更新後的資訊，重新生成新的 keepalived 配置檔案，然後通知 keepalived 去使用新的配置檔案。

2.4.1 新增 gateway

keepalived 的配置檔案的 virtual_ipaddress_excluded 部分會增加 gateway 的 interface IP：192.168.1.113/24 dev qg-f19f97bc-e5 作為一個 VIP。這個 VIP 地址會在 Master node 被設定，在 Backup node 上不會被設定。

master：

36: qg-f19f97bc-e5: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:14:be:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.113/24 scope global qg-f19f97bc-e5
       valid_lft forever preferred_lft forever

slave：

61: qg-f19f97bc-e5: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:14:be:06 brd ff:ff:ff:ff:ff:ff

2.4.2 新增 subnet interface

同樣地，keepalived 的配置檔案的 virtual_ipaddress_excluded 部分會增加 subnet的 gateway IP：10.0.10.1/24 dev qr-73641a84-72 做為一個新的 VIP。這個 VIP 會在 Master node 被設定，在 Backup node 上不會被設定。

master：

37: qr-73641a84-72: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:86:dd:53 brd ff:ff:ff:ff:ff:ff
    inet 10.0.10.1/24 scope global qr-73641a84-72
       valid_lft forever preferred_lft forever

bakckup：

62: qr-73641a84-72: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:86:dd:53 brd ff:ff:ff:ff:ff:ff

2.4.3 新增一個虛機到 10.0.10.1/24 網路

虛機的預設閘道器為 10.0.10.1，這正是 Master node 上的 qr-73641a84-72 interface 上設定的 VIP 。因此，虛機發送到不是本機所在網路的網路包都會經過本 interface 進入 Master 路由器。

2.4.4 向該 IP 新增一個浮動 IP 192.168.1.112

同樣地，keepalived 的配置檔案的 virtual_ipaddress_excluded 部分會增加該浮動 IP 和它所在的 external port：192.168.1.112/32 dev qg-f19f97bc-e5 作為一個新的 VIP。這個 VIP 會在 Master node 被設定，在 Backup node 上不會被設定。

該 VIP 被加到了 Master router 的 external port 上：

36: qg-f19f97bc-e5: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:14:be:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.113/24 scope global qg-f19f97bc-e5
       valid_lft forever preferred_lft forever
    inet 192.168.1.112/32 scope global qg-f19f97bc-e5
       valid_lft forever preferred_lft forever

同樣，在 Slave router 的 exernal port 上沒有新增。

但是，每一次 router 例項都更新的時候，Master router 和 Backup router 的 iptables 規則保持了一致的更新。從以上過程可以看出，在某一時刻，只有 Master router 的 interface 在接受虛機發來的網路包，其它 VRRP router 只是在 standby。

至此，Master 和 Backup L3 Agent namespace 的效果為：

2.5 HA Router 故障切換

非搶佔模式下，因為在master 把某個 slave 低時也不會發生切換，因此要觸發 keepalived VRRP failover，需要考慮：

當 slave 節點在規定的時間內沒有收到 master 的心跳：比如一個 L3 Agent 上的 keepalived 程序死了，或者 HA Device down 了，或者 HA network down 了等。除此以外的其它情況，都需要使用 workaround 來觸發故障切換：比如使用 peacemaker 監視 L3 Agent，一旦發現它 down 了，立刻將 HA Device down 掉。
當 master 節點上的 external gateway 在規定的時間內無法訪問時：這裡有個 bug 報出來了，到目前為止還沒有被解決。

而在搶佔模式下，可以通過修改 master 的 weight 來主動觸發切換，這可以使用 keepalived 自帶的 tracing script 來實現。該指令碼可以自行執行檢查操作，然後 keepalived 會根據返回值做預訂的各項操作，包括設定 weight 甚至直接將狀態設定為 FAULT 來觸發切換。其格式為：

vrrp_script script_name {
  script       "program_path arg ..."
  interval i  # Run script every i seconds
  fall f      # If script returns non-zero f times in succession, enter FAULT state
  rise r      # If script returns zero r times in succession, exit FAULT state
  timeout t   # Wait up to t seconds for script before assuming non-zero exit code
  weight w    # Reduce priority by w on fall
}

配置示例：

vrrp_instance instance_name {
  state MASTER
  interface eth0
  virtual_router_id 21
  priority 200
  advert_int 1
  virtual_ipaddress {
    10.0.0.10/24
  }
  track_script {
    script_name
    ...
  }
}

簡單起見，為了驗證 failover，把 master node 上的 HA Device down 掉。

 ip netns exec qrouter-04f6e792-3b79-4b8f-a577-2ad38d33a2bb ifconfig ha-20894a79-b6 down

這時候，該節點的 VRRP 狀態變為 fault。

Aug  1 15:26:58 network Keepalived_vrrp[4415]: Kernel is reporting: interface ha-20894a79-b6 DOWN
Aug  1 15:26:58 network Keepalived_vrrp[4415]: Kernel is reporting: interface ha-20894a79-b6 DOWN
Aug  1 15:26:58 network Keepalived_vrrp[4415]: VRRP_Instance(VR_1) Entering FAULT STATE
Aug  1 15:26:58 network Keepalived_vrrp[4415]: VRRP_Instance(VR_1) Now in FAULT state
Aug  1 15:26:58 network Keepalived_vrrp[4415]: VRRP_Group(VG_1) Syncing instances to FAULT state
Aug  1 15:26:58 network Keepalived_vrrp[4415]: Opening script file /var/lib/neutron/ha_confs/04f6e792-3b79-4b8f-a577-2ad38d33a2bb/notify_fault.sh

該master 被設定為 FAULT 狀態後，它會釋放 VIP，而且停止傳送 VRRP 心跳。原 backup node 上的 keepalived 因為在規定時間內收不到 VRRP 通告，主動發起選舉過程，將自己變為 Master 狀態，觸發 notify_master.sh 被呼叫。這時候，該節點上的 router namespace 的 qr，gg 和 ha interface 的 VIP 全部被配置了，而且 route 規則也增加了。它已經接替原 master 節點向虛機提供路由服務。

60: ha-a8a3a49f-c1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:84:24:7f brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.1/18 brd 169.254.255.255 scope global ha-a8a3a49f-c1
       valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-a8a3a49f-c1
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe84:247f/64 scope link
       valid_lft forever preferred_lft forever
61: qg-f19f97bc-e5: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:14:be:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.112/32 scope global qg-f19f97bc-e5
       valid_lft forever preferred_lft forever
    inet 192.168.1.113/24 scope global qg-f19f97bc-e5
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe14:be06/64 scope link
       valid_lft forever preferred_lft forever
62: qr-73641a84-72: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fa:16:3e:86:dd:53 brd ff:ff:ff:ff:ff:ff
    inet 10.0.10.1/24 scope global qr-73641a84-72
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe86:dd53/64 scope link
       valid_lft forever preferred_lft forever


              
           
              
              
            
            相關推薦
			   
            
            
            
 

    

    
    理解 OpenStack 高可用（HA）（2）：Neutron L3 Agent HA 之 虛擬路由冗餘協議（VRRP）
      本系列會分析OpenStack 的高可用性（HA）概念和解決方案：







1. 基礎知識
1.1 虛擬路由冗餘協議 - VRRP
1.1.1 概念
    路由器是整個網路的核心。一個網路內的所有主機往往都設定一條預設路由，這樣，主機發出的目的地址不在本網段的報文將被通過預設路由 

  
 

    

    
    CCNA 之第一跳冗餘協議（FHSRP）HSRP、VRRP、GLBP
      
							
							
							




一、第一跳冗餘協議（FHSRP）簡介



1.起因

如果路由器或路由器介面（作為預設閘道器）發生故障，配置該預設閘道器的主機將與外部網路隔離，大部分功能不能使用。交換網路需要一種閘道器冗餘的機制。因此出現了第一跳冗餘協議。



2.原理

把多個 

  
 

    

    
    理解 OpenStack 高可用（HA）（5）：RabbitMQ HA
      
                

本系列會分析OpenStack 的高可用性（HA）概念和解決方案：







1. RabbitMQ 叢集

    你可以使用若干個RabbitMQ 節點組成一個 RabbitMQ 叢集。叢集解決的是擴充套件性問題。所有的資料和狀態都會在叢集內所有的節點上被複制，只 

  
 

    

    
    理解 OpenStack 高可用（HA）（3）：Neutron 分散式虛擬路由（Neutron Distributed Virtual Routing）
      本系列會分析OpenStack 的高可用性（HA）概念和解決方案：







    Neutron 作為 OpenStack 一個基礎性關鍵服務，高可用性（HA）和擴充套件性是它的基本需求之一。對 neutron server 來說，因為它是無狀態的，我們可以使用負載均衡器（Load B 

  
 

    

    
    理解 OpenStack 高可用（HA）（1）：OpenStack 高可用和災備方案 [OpenStack HA and DR]
      本系列會分析OpenStack 的高可用性（HA）概念和解決方案：







1. 基礎知識
1.1 高可用 （High Availability，簡稱 HA）
    高可用性是指提供在本地系統單個元件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬體的 

  
 

    

    
    理解 OpenStack 高可用(HA) （4）: Pacemaker 和 OpenStack Resource Agent （RA）
      本系列會分析OpenStack 的高可用性（HA）概念和解決方案：







1. Pacemaker
1.1 概述
    Pacemaker 承擔叢集資源管理者（CRM - Cluster Resource Manager）的角色，它是一款開源的高可用資源管理軟體，適合各種大小叢集 

  
 

    

    
    ?VRRP 虛擬路由冗余協議(Virtual Router Redundancy Protocol）
      save   9.png   運行   net   -i   mar   ado   area   就是   VRRP:      虛擬路由冗余協議(Virtual Router Redundancy Protocol）實驗目的:         在多個路由器之間運行，         可以虛擬出一個或者多個 

  
 

    

    
    私有云落地解決方案之openstack高可用（pike版本）-cinder
      
								
								            
							
							
							作者：【吳業亮】



建立使用者

# openstack user create --domain default --project service --password Changeme_123 

  
 

    

    
    私有云落地解決方案之openstack高可用（pike版本）-架構
      
							
							
							作者：【吳業亮】



本架構借鑑redhat架構

1、API 服務：包括 *-api, neutron-server，glance-registry, nova-novncproxy，keystone，httpd 等。由 HAProxy 提供負載均衡，將請求 

  
 

    

    
    私有云落地解決方案之openstack高可用（pike版本）-horizon
      
								
								            
							
							
							作者：【吳業亮】



安裝rpm包

# yum  -y install openstack-dashboard

修改配置檔案 /etc/openstack-dashboard/local_sett 

  
 

    

    
    私有云落地解決方案之openstack高可用（pike版本）-訊息佇列
      
								
								            
							
							
							作者：【吳業亮】



1、安裝軟體包

yum install erlang rabbitmq-server –y

2、啟動服務並設定開機啟動



systemctl enable rabbitm 

  
 

    

    
    私有云落地解決方案之openstack高可用（pike版本）-叢集引數
      
							
							
							作者：【吳業亮】



一、新增服務

將訊息佇列加入叢集監控中



crm configure primitive rabbitmq-server systemd:rabbitmq-server \
params environment_file="/etc 

  
 

    

    
    OpenStack 高可用和災備方案（下）
      
                
3. 部分 OpenStack 方案提供者的 HA 方案
3.1 RDO HA
這裡 有完整的 RDO HA 部署方案：

該配置最少需要五臺機器：
一臺（物理或者虛擬）伺服器部署 nfs server，dhcp，dns一臺物理伺服器來作為計算節點三臺物理伺服器組成 pac 

  
 

    

    
    理解 neutron（15）：Neutron Linux Bridge + VLAN/VXLAN 虛擬網路
      
學習 Neutron 系列文章：
















雖然大部分的OpenStack 部署環境中，都會使用 Open vSwitch 來作為虛擬交換機來實現二層網路功能，但是Neutron 仍然支援使用 Linux bridge 作為虛擬交換機來實現二層網路。 

  
 

    

    
    一起talk C栗子吧（第一百二十三回：C語言實例--顯示變量和函數的地址）
      調試   ora   部分   example   多線程   ear   red   語言   help   
        

各位看官們，大家好，上一回中咱們說的是多線程的樣例。這一回咱們說的樣例是：顯示變量和函數的地址。閑話休提，言歸正轉。讓我們一起talk C栗子吧！ 

在編敲代碼時，有時候須 

  
 

    

    
    理解HDFS高可用性架構
      共享存儲   src   mage   namenode   存儲系統   tro   ima   會同   同時   在Hadoop1.x版本的時候，Namenode存在著單點失效的問題。如果namenode失效了，那麽所有的基於HDFS的客戶端——包括MapReduce作業均無法讀，寫或列文件，因為nam 

  
 

    

    
    配置VRRP（虛擬路由器冗余協議）
      standby   驗證   名稱   mes   image   ces   oss   ado   term   1，實驗名稱：配置VRRP（虛擬路由器冗余協議）2，實驗目的：3，實驗拓撲：4.配置步驟：(1)配置交換機SW1SW1(config)#vlan 10   創建vlan 10SW1(confi 

  
 

    

    
    華為拓撲---vrrp（虛擬路由器冗余協議）的使用
      moni   pla   ext   交互   進入   報文   設置ip   導致   enter   一、拓撲圖展示—華為的vrrp（虛擬路由器冗余協議）的使用


二、你要知道的知識點
1.什麽是vrrp？
VRRP是共有協議，在多個路由器之間運行，可以虛擬出一個或者多個網關IP地址(虛擬路由器)，從 

  
 

    

    
    六LWIP學習筆記之用戶數據報協議（UDP）
      端口   數據結構   筆記   udp協議   pos   body   校驗   傳輸   連接   一、背景知識
1、傳輸層協議
2、UDP協議
3、端口
4、UDP報文的交付
5、UDP報文格式
6、UDP偽首部與校驗和
二、UDP數據結構
1、報文首部結構
2、控制塊
三、控制塊操作函數
1、使用U 

  
 

    

    
    Ajax（form表單文件上傳、請求頭之contentType、Ajax傳遞json數據）
      ati   沒有   服務端   內容   click   寫入   ESS   mit   上傳   form表單文件上傳
上菜
file_put.html

<form action="" method="post" enctype="multipart/form-data">
{#

理解 OpenStack 高可用（HA）（2）：Neutron L3 Agent HA 之 虛擬路由冗餘協議（VRRP）