使用高可用性 (HA) 和 VRRP

IBM Cloud® Virtual Router Appliance (VRA) 支援 Virtual Router Redundancy Protocol (VRRP) 作為高可用性通訊協定。裝置的部署是以主動/被動方式來執行，其中一部機器是主要機器，另一部是備份機器。兩部機器上的所有介面都是相同 "sync-group" 的成員，因此如果其中一個介面發生錯誤，則相同群組中的其他介面也會發生錯誤，且裝置會停止成為主要裝置。現行備份會偵測主節點是否不再播送保留作用中/活動訊號訊息、假設控制 VRRP 虛擬 IP，並變成主節點。

佈建「閘道」時，VRRP 是配置中最重要的部分。高可用性功能取決於活動訊號訊息，因此確保它們未被封鎖是很重要的。

VRRP 虛擬 IP (VIP) 位址

dp0bond1 或 dp0bond0 的 VRRP 虛擬 IP 或 VIP 是指，發生失效接手時，從主要裝置變更為備份裝置的浮動 IP 位址。當 VRA 部署時，它會在每一個介面上指派公用及專用結合網路連線及實際 IP。不論裝置是獨立式或 HA 配對，也會在兩個介面上指派 VIP。在 VLAN 中與 VRA 相關聯的子網路中具有目的地 IP 的資料流量，會透過 FCR/BCR 上的靜態路徑直接傳送至這些 VRRP VIP。

您不應變更任何閘道群組的 VRRP 虛擬 IP 位址，也不應停用 VRRP 介面。這些 IP 位址是當 VLAN 已關聯時，資料流量用來遞送至閘道的方法。因此，如果它們已關閉，則 VLAN 資料流量也會關閉。如果 IP 位址不存在，則無法將資料流量從 BCR/FCR 轉遞至 VRA 本身。此時無法變更這個虛擬位址或 VIP。此限制在未來可能會變更，但目前不支援在 PODs/FCRs/BCR 之間移轉 VRA，也不支援變更 VIP。

下列是特定 VRA 的 dp0bond0 及 dp0bond1 VIP 的預設配置範例。請注意，您的 IP 位址及 vrrp-groups 可能與此範例不同。

set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'

如需相關資訊，請參閱與 VRRP 相關聯的 VLAN 子網路。

依預設，VRRP 會設為已停用。 這可確保新的佈建和重新載入不會導致「主要」裝置發生中斷。若要讓 VLAN 資料流量運作，必須在佈建或重新載入完成之後重新啟用 VRRP。下列範例詳述預設配置：

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

在佈建或重新載入 (獨立式及 HA 配對都需要) 之後，若要在這兩個介面上啟用 VRRP，請執行下列指令。然後，確定變更:

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

VRRP 群組

VRRP 群組由介面或虛擬介面的叢集組成，這些介面或虛擬介面為群組中的主要 (或主要) 介面提供備援。 VRRP 群組會在 Keepalive 配置中定義 virtual_router_id。在 VRRP 通訊協定本身中，它稱為 VRID。 VRRP 群組具有唯一的數值 ID，且可以獲得指派最多 20 個虛擬 IP 位址。

VRRP 群組 ID 由 IBM Cloud 指派，不應該變更。第一次在「前端客戶路由器 (FCR)/後端客戶路由器 (BCR)」之後佈建新的閘道群組時，它會收到 VRRP 群組 1。後續閘道群組供應會增加此值以防止衝突。例如，下一個群組具有群組 2，然後是群組 3，依此類推。然後由佈建處理程序計算並指派。變更此值可能會與其他作用中群組發生衝突，然後主要/主要競用，這可能會導致兩個閘道群組都中斷。

如果您是從前一個配置移轉，建議您再確認配置程式碼，以確定 VRRP 群組 ID 不是以靜態方式指派。

VRRP 群組 ID 會持續保存在資料庫中，因此在 OS 重新載入或升級期間會使用相同的群組 ID 值。在 OS 重新載入期間，任何使用者修改的 VRRP 群組 ID 都會改寫為系統指派的值。

VRRP 優先順序

閘道群組中第一個機器的優先順序為 254，此值會針對下一個供應的裝置遞減。您絕不應該將優先順序設為 255，因為這會把 VIP 定義為「位址擁有者」，當使用與執行中的作用中主要伺服器不同的配置讓機器連線時，可能會產生非預期的行為。

VRRP 先占

應該一律在所有 VRRP 介面上停用先占，這樣新的裝置或正在重新載入 OS 的裝置才不會嘗試接管叢集。

VRRP 通告間隔

為了指出它仍在服務中，主要介面或 VIF 會將稱為「公告」「活動訊號」封包傳送至 LAN 區段，方法為針對 VRRP 使用 IANA 指派的多重播送位址（IPv4 為 224.0.0.18，IPv6 為 FF02:0:0:0:0:0:0:12）。

依預設，間隔設為 1。此值可以增加，但不建議設定超過 5 的值。在忙碌網路上，所有 VRRP 通知從主節點抵達備份裝置所需的時間可能比一秒長，因此值 2 應該用於高資料流量網路。

VRRP 同步化 (sync-group)

VRRP 同步化群組 ("sync group") 中的介面會同步化，以便如果群組中的其中一個介面失效接手至備份介面，則群組中的所有介面都會失效接手至備份介面。例如，如果主要路由器上的一個介面失敗，則整個路由器會失效接手至備份路由器。

此值不同於 VRRP 群組，因為當該群組中的介面登錄錯誤時，它會定義裝置失效接手上的哪些介面。建議所有介面都屬於相同的 sync-group; 否則，部分介面是主要介面，具有閘道 IP，而其他介面是備份介面，且資料流量不再適當地轉遞。不支援主動/主動配置。

VRRP rfc-compatibility

rfc-compatibility 會啟用或停用介面上 VRRP 的 RFC 3768 MAC 位址。在原生介面上應該啟用，但在任何已配置的 VIF 上則不應啟用。部分虛擬交換器 (大部分是 vmware) 在啟用此功能時發生問題，並導致捨棄資料流量，且不會從 Hypervisor 主機傳送至閘道 IP。請不要理會此設定，且不要配置任何 VIF 的設定。

VRRP 鑑別

如果為 VRRP 鑑別設定密碼，則也必須定義鑑別類型。如果已設定密碼且未定義鑑別類型，則系統會在您嘗試確定配置時產生錯誤。

同樣地，在不刪除 VRRP 鑑別類型的情況下，您無法刪除 VRRP 密碼。如果這樣做，當您嘗試確定配置時，系統會產生錯誤。如果您同時刪除 VRRP 鑑別密碼和鑑別類型，則會停用 VRRP 鑑別。

IETF 決定 VRRP 第 3 版不使用鑑別。如需相關資訊，請參閱 RFC 5798 VRRP。

版本 2/3 支援

VRA 支援 VRRP 第 2 版（預設值）和第 3 版通訊協定。在第 2 版中，您不能同時具有 IPv4 和 IPv6 ; 不過，在第 3 版中，您可以同時具有 IPv4 和 IPv6。

搭配 VRRP 的高可用性 VPN

VRA 能夠藉由使用一對 IBM Cloud® Virtual Router Appliance 搭配 VRRP，而維護通過一條 IPsec 通道的連線功能。當一個路由器失敗或關閉以進行維護時，新的 VRRP 主要路由器會還原本端與遠端網路之間的 IPsec 連線功能。

使用 VRRP 配置 HA VPN 時，每當 VRRP 虛擬位址新增至 VRA 介面時，您必須重新起始設定 IPsec 常駐程式，因為當起始設定「網際網路金鑰交換 (IKE)」服務常駐程式時，IPsec 服務只會接聽 VRA 上存在之位址的連線。

在主要及備份路由器上執行下列指令，以便在發生失效接手時，在 VIP 轉入之後，在新的主要裝置上重新啟動 IPsec 常駐程式，如下列範例所示:

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

搭配 VRRP 的高可用性防火牆

當兩台裝置處於 HA 配對時，您的主要裝置必須小心，不要封鎖另一台裝置的存取權。必須在兩個裝置之間容許埠 443，配置同步才能運作，且必須容許傳送及接收 VRRP，包括 224.0.0.0/24 的多重播送範圍。

相關聯的 VLAN 子網路與 VRRP

對於具有 VRRP 的任何 VIF 配置，您需要一個虛擬 IP 位址 (子網路中第一個可用的 IP，該子網路中所有項目將遞送至的閘道 IP)，以及兩個裝置上 VIF 的實際介面 IP 位址。為了節省可用的 IP，建議實際介面 IP 使用頻外範圍，例如 192.168.0.0/30，其中一個裝置具有 .1，另一個裝置具有 .2 位址。您可以有多個 VRRP 虛擬 IP，但在每一個 VIF 上只需要一個實際位址。

以下是具有兩個專用 VLAN 及三個子網路的 VRRP 配置範例：

set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'

VRRP sync-group 與 VRRP 群組不同。屬於 sync-group 的介面變更狀態時，相同 sync-group 的所有其他成員都會轉移為相同的狀態。
VLAN 介面 (VIF) 的 vrrp-group 號碼應該幾乎一律與其相符的原生介面相同。例如，dp0bond1.789 應該一律具有與 dp0bond1 相同的 vrrp-group 號碼，除非這兩個介面共用相同的 sync-group。對 VIF 具有不同的群組號碼，且原生介面可能會在與不同的同步群組配對時造成「裂腦」狀況。當這兩個介面共用相同的 sync-group 時，即使它們是在不同的 vrrp-group 上，也會同時在主要介面與備份介面之間轉移，以防止裂腦。另一方面，如果原生介面設定了不同的 vrrp-group 號碼和不同的 sync-group 作為 VLAN 介面，因為 VLAN 介面上設定的子網路會靜態遞送至原生介面上的虛擬位址，但如果 VLAN 顯示為備份，而原生介面是主要的，則路由器仍會將 VLAN 介面資料流量傳送至原生介面是主要介面的 RVA，即使 VLAN 介面是次要介面，而且在 VRA 上不是作用中也一樣。此特定狀況會導致「腦分裂」及中斷。這就是為什麼重要的是要意識到 sync-groups 如何與 vrrp-groups 一起設定。在相同傳輸 VLAN 中的多個 HA VRA 配對之間，不要使用相同的 vrrp-group 號碼也很重要，因為使用相同群組的四個 Vyatta 會導致三個 VRA 可能假設「備份」狀態，而只有一個是「主要」，導致中斷。
原生 VLAN 上的實際介面位址（例如：dp0bond1: 169.110.20.28/29）不一定是在與其 VIP (169.110.21.26/29) 相同的子網路。

手動 VRRP 失效接手

如果您需要強制執行 VRRP 失效接手，則在目前為 VRRP 主節點的裝置上執行下列作業即可達成：

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

群組 ID 是原生介面的 VRRP 群組 ID，而且如上所述，在您的配對中可能會不同。

連線同步化

當兩個 VRA 裝置處於 HA 配對時，追蹤兩個裝置之間的有狀態連線可能會很有用，因此如果發生失效接手，則會將故障裝置上所有連線的現行狀態抄寫至備份裝置。不需要從頭開始重建任何現行作用中階段作業 (例如 SSL 連線)，這可能導致使用者體驗中斷。

這稱為連線追蹤同步化。

如果要配置它，您必須宣告失效接手方法、您用來傳送連線追蹤資訊的介面，以及遠端對等節點的 IP:

set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4

另一個 VRA 具有相同的配置，但具有不同的 remote-peer。

請注意，如果有大量連線進入其他介面，且在宣告的鏈結上與其他資料流量競爭，則這會使鏈結飽和。

VRRP 啟動延遲特性

Vyatta OS 版本 1801p 及更新版本包括新的 vrrp 指令。

vrrp 指定選取通訊協定，動態將虛擬路由器的責任指派給 LAN 上的其中一個 VRRP 路由器。 VRRP 路由器 (控制與虛擬路由器相關聯的 IPv4 或 IPv6 位址) 稱為「主要」，它會轉遞傳送至這些 IPv4 或 IPv6 位址的封包。選取處理程序會在轉遞責任中提供動態失效接手，因此「主節點」會變成無法使用。所有通訊協定傳訊都是使用 IPv4 或 IPv6 多點播送資料包來執行；因此，通訊協定可以透過支援 IPv4/IPv6 多重播送的各種多重存取 LAN 技術來運作。

若要最小化網路資料流量，只有每個虛擬路由器的「主節點」才會傳送定期「VRRP 公告」訊息。除非「主要」具有較高的優先順序，否則備份路由器不會嘗試先占「主要」。除非有更偏好的路徑可用，否則這會消除服務中斷。也可以由管理方式禁止所有先佔嘗試。如果「主要」變成無法使用，則最高優先順序備份會在短暫延遲之後轉移至「主要」，以提供虛擬路由器責任的受控制轉移，且服務岔斷最小。

在 IBM Cloud 佈建的部署中，啟動延遲值設為預設值。當您測試失效接手及高可用性方法時，您可能想要自行決定變更此項。

先占與無先占

vrrp 通訊協定會定義邏輯，以決定網路上具有較高優先順序的 VRRP 對等節點，以及作為「主要」執行角色的最佳對等節點。使用預設配置時，VRRP 會啟用以執行先占，這表示網路上新的較高優先順序對等節點會強制失效接手「主要」角色。

停用先占時，如果網路上不再有現有較低優先順序對等節點，則較高優先順序對等節點只會失效接手「主節點」角色。停用先占有時在實際情境中很有用，因為它更能應付高優先順序對等節點可能由於對等節點本身或其中一個網路連線的可靠性問題而開始定期啟動的狀況。它也適用於防止過早失效接手至尚未完成網路聚合的新較高優先順序對等節點。

先占的假設及限制

如果 VRRP 對等節點配置為停用先占，則在某些情況下，先占可能「似乎」發生，但實際上實務範例只是標準 VRRP 失效接手。如上所述，VRRP 會使用 IP 多重播送資料包作為確認目前已選取「主節點」路由器之可用性的方法。因為它是偵測到 VRRP 對等節點失敗的第 3 層通訊協定，所以 VRRP 中的失效接手偵測會延遲至 VRRP，而且已備妥並聚合網路堆疊的第 1 層到第 2 層。在某些情況下，執行 VRRP 的網路介面可能會向通訊協定確認介面已啟動，但其他基礎服務 (例如 Spanning Tree 或 Bonding) 可能尚未完成。因此，無法建立對等節點之間的 IP 連線功能。如果發生此情況，則新的較高對等節點上的 VRRP 會變成「主要」，因為它無法從網路上的現行「主要」對等節點偵測到 VRRP 訊息。收斂之後，有兩個「主要 VRRP」對等節點的短暫時段會導致執行 VRRP 的雙重「主要」邏輯。較高優先順序的同層級仍然是「主要」，而較低優先順序會變成備份。此實務範例可能顯示「不先占」功能中的失敗。

啟動延遲特性

為了容納在介面啟動事件期間與網路堆疊較低層次延遲聚合相關聯的問題，以及其他促成因素，在 1801p 修補程式中引進了稱為「啟動延遲」的新特性。此特性會導致「重新載入」機器上的 VRRP 狀態保持 INIT 狀態，直到網路操作員可以配置預先定義的延遲為止。此延遲值的彈性可讓網路操作員在實際情況下自訂其網路及裝置的特徵。

指令詳細資料

vrrp {
start-delay <0-600>
}

start-delay 的值可以介於 0（預設值）與 600 秒之間。

範例配置

interfaces {
  bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
      start-delay 120
      vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}