浮動 IP 位址最佳做法

本解決方案概述將應用程式從內部部署網路環境遷移至 Google Compute Engine 時,使用浮動 IP 位址的替代方案。浮動 IP 也稱為「共用」或「虛擬」IP 位址,通常用於讓內部部署網路環境具備高度可用性。在多個具有相同設定的實體或虛擬伺服器之間,您可以使用浮動 IP 來傳遞 IP 位址,以便對實際工作環境的軟體進行容錯移轉或升級。然而在 Compute Engine 環境中,您無法直接導入浮動 IP。

內部部署環境的浮動 IP

浮動 IP 常用於內部部署環境中。下列清單列出幾項浮動 IP 的應用實例:

  • 可用性高的實體設備 (像是一組防火牆或負載平衡器等) 通常會使用浮動 IP 進行容錯移轉。
  • 需要高可用性的伺服器通常會使用浮動 IP,例如採用 Always On 可用性群組的 Microsoft SQL Server 等主從關聯資料庫。
  • 採用負載平衡器或反向 Proxy 的 Linux 環境會使用 IPVSHAProxyNGINX 等浮動 IP。為了偵測節點故障情形以及在執行個體之間遷移浮動 IP,這類環境會使用 heartbeatpacemakerkeepalived 等 Daemon。
  • 浮動 IP 可讓使用 Windows Server 容錯移轉叢集的 Windows 服務擁有高可用性。

您可以透過數種方式在內部部署環境實作浮動 IP。但無論是何種情況,共用 IP 位址的伺服器也必須透過活動訊號機制分享彼此的狀態。這種機制能讓伺服器針對各自的健康狀態進行通訊,並可在連線伺服器故障時,讓次要伺服器接手管理浮動 IP 位址。此配置的實作方式通常是採用虛擬路由器備援通訊協定 (VRRP),但是您也可以使用其他類似的機制來進行。

啟動 IP 容錯移轉後,接管浮動 IP 位址的伺服器會將位址加入該伺服器的網路介面。伺服器會藉由傳送無償位址解析通訊協定 (ARP) 訊框,向使用第 2 層的其他裝置公告這項接管事宜。伺服器有時會採用另一種方法,即透過開放式最短路徑優先 (OSPF) 等轉送通訊協定,向上游第 3 層的路由器公告 IP 位址。

下圖說明內部部署環境的一般設定。

一般內部部署環境

您使用的設定會因不同的內部部署負載平衡解決方案而稍有調整,例如 Windows 網路負載平衡或 Linux 負載平衡會採用 IP 虛擬伺服器 (IPVS) 等伺服器直接回應。在這些情況下,服務也會送出無償 ARP 訊框,但是會使用另一個伺服器的 MAC 位址做為無償 ARP 來源,因此實質上是假冒 ARP 訊框並接管另一部伺服器的來源位址。這類設定情況已超出本解決方案的討論範圍。在絕大部分情況下,遷移至 Cloud Load Balancing 是最合適的遷移路徑。

將浮動 IP 遷移至 Compute Engine 所面臨的挑戰

Compute Engine 在虛擬私人雲端 (VPC) 網路中使用經虛擬化的網路堆疊,因此一般實作機制無法立即運作。舉例來說,VPC 網路會根據設定的轉送拓撲處理 ARP 要求,並忽略無償 ARP 訊框。此外,您無法透過 OSPF 或邊界閘道通訊協定 (BGP) 等標準轉送通訊協定,直接修改 VPC 網路路由表。

您可以使用覆蓋網路建立設定,以便透過 ARP 要求啟用完整的第 2 層通訊和 IP 接管功能。不過設定覆蓋網路是一項複雜的工作,而且會造成 Compute Engine 網路資源難以管理。該方法也超出了本解決方案的討論範圍,因此本解決方案會提供替代方法,讓您能在原生 Compute Engine 網路環境中導入容錯移轉機制。

本解決方案提供數種方法,能將本文描述的大部分應用實例遷移至 Compute Engine。

下列逐步指南適用於更具體的應用實例:

遷移的應用實例

本解決方案概述四種從內部部署浮動 IP 移至 Compute Engine 的遷移選項。

該應用實例包含遷移兩個內部 HAProxy 伺服器,這些伺服器會根據第 7 層的複雜標頭比對和替換,將流量轉送至不同的後端。由於牽涉到複雜的規則,因此您無法使用內部負載平衡或甚至是 HTTP 負載平衡取代這組伺服器。下圖顯示本應用實例的整體概念。

遷移應用實例

HAProxy 伺服器會透過內部部署的 Keepalived 軟體,使用獨立的交叉連結網路查看可用性,並在兩個伺服器之間傳遞浮動 IP。

在本應用實例中,以下各節說明的四種選項均為浮動 IP 的有效內部部署替換方案。如為其他更複雜的應用實例,則可用的選項可能會比較少。本解決方案會在說明選項後,根據特定的使用情況提供選取適用選項的指南。

下一節將會討論如何將本應用實例情境遷移至 Compute Engine。

使用 Compute Engine 進行實作

本節概述將內部部署情境遷移至 Compute Engine 的幾種方式。如要降低複雜度,則所有要求應轉送至所需後端設定最少的單一 NGINX 後端群組,而非採用先前提及的標頭比對方法。

在所有範例中,系統均會將流量從 HAProxy 轉送到在會自動資源調度的執行個體群組中的一組 Compute Engine 後端。您可以透過內部負載平衡器來存取這些後端。在設定範例中,這些後端會使用 NGINX 預設設定。

如要實作應用實例,請使用專屬專案進行測試。

設定後端

在本節中,您會將 NGINX 後端設定為由 HAProxy 節點存取。最佳做法是將後端建立在此部署專屬的 VPC 中

如要設定後端,請按照下列步驟進行:

  1. 設定預設區域,例如:

    gcloud config set compute/zone us-central1-f
    
  2. 設定用於測試的網路,以及允許內部流量的防火牆規則,並使用 ssh 指令與網路進行通訊:

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. 為 NGINX 後端建立執行個體範本:

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. 根據範本建立自動調度資源的區域性代管執行個體群組:

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. 將具有固定 IP 位址 (10.128.2.2) 的內部負載平衡器連結到這個執行個體群組:

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. 建立用於測試的執行個體,並使用 ssh 指令連線至該執行個體,接著檢查是否可連到內部負載平衡 IP:

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html> [...]
    username@testing:~$ exit

本範例設定使用 n1-standard-1 執行個體,每個執行個體的網路總處理量上限為每秒 2 GB。如為實際的部署作業,則能根據自己的需求調整執行個體的大小。

此外,執行個體是透過外部 IP 位址建立,因此可使用開機指令碼下載必要套件。在實際工作環境的設定中,您會建立自訂映像檔,並且在不使用外部 IP 位址的情況下建立執行個體。

選項 1:使用內部負載平衡

您可以將兩個 HAProxy 伺服器放在內部負載平衡後的代管執行個體群組中,並使用內部負載平衡 IP 做為虛擬 IP,藉此在 Compute Engine 中實作內部部署情境,如下圖所示。

選項 1:內部負載平衡

相較於內部部署設定的差異

內部負載平衡 IP 的作用與內部部署環境中的浮動 IP 類似,但仍有一些明顯差異:

  • 流量分佈

    最明顯的差異在於兩個節點之間會共用流量,但是在原始設定中,流量一次只會送達一個節點。假如在情境中,系統是根據要求本身的內容來轉送流量,則此方法並無不妥,但如果機器並非處於持續同步的狀態 (例如主從資料庫),則此方法並不適用。

  • 容錯移轉時間

    與無償 ARP 配對時,如果在內部部署環境中使用 Keepalived,就可能會在幾秒內完成 IP 容錯移轉。Compute Engine 環境的平均復原時間需視故障模式而定。如果虛擬機器 (VM) 執行個體或 VM 執行個體服務發生錯誤,則容錯移轉平均時間的流量會依據 Check IntervalUnhealthy Threshold 等健康狀態檢查參數而有不同。當這些參數設為預設值時,容錯移轉通常約需 15 至 20 秒,但您可以調整參數來減少時間。在 Compute Engine 中,區域內和區域之間的容錯移轉所花費的時間相同。

  • 健康狀態檢查

    在內部部署中使用 Keepalived 時,除了等候運作中的訊號外,Keepalived 也可透過各種方式檢查主機的健康狀態,像是監控 HAProxy 程序的可用性等。在 Compute Engine 中,則必須使用 HTTP/HTTPS/TCP 或 SSL 連接埠從主機外部存取健康狀態檢查。如果必須檢查主機的具體細節,您就需要在執行個體上安裝簡易的服務來公開這些詳細資料,否則請選擇其他替代選項。

  • 通訊埠

    在內部部署設定中,浮動 IP 可接受所有流量,然而內部負載平衡則限制最多轉送至五個連接埠。

實作選項 1

如要實作此解決方案,請完成下列步驟:

  1. 為轉送要求的 HAProxy 伺服器建立執行個體範本:

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. 根據靜態大小為 2 的執行個體範本建立區域性執行個體群組。使用您先前建立的健康狀態檢查,將自動修復政策連結到執行個體:

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. 將內部負載平衡器連結至 HAProxy 伺服器並實作健康狀態檢查:

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. 測試是否能透過內部負載平衡與 HAProxy 連線:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

如果透過主控台刪除其中一個 HAProxy 執行個體,或是在其中一個執行個體上停止 HAProxy 程序,則經過短暫的容錯移轉時間後,curl 指令仍可成功執行。

選項 2:使用單一代管執行個體

即使內部部署使用多部伺服器,使用單一 VM 執行個體進行遷移仍可能為可行的 Compute Engine 選項,視復原時間需求而定。可行的理由在於您能夠在幾分鐘內啟用新的 Compute Engine 執行個體,而內部部署故障通常需要數小時或數日才能修復。

選項 2:單一代管執行個體

選項 2 和選項 1 的差異:內部負載平衡

相較於選項 1,選項 2 主要的優缺點如下。

優點:

  • 流量分佈

    只有一個執行個體,因此所有流量都會抵達單一執行個體,類似內部部署的主從情境。

  • 節省成本

    不使用兩個 VM 執行個體,而改用單一執行個體,可降低一半的實作成本。

  • 簡單易用

    本解決方案可輕鬆實作且負擔低。

缺點:

  • 容錯移轉時間

    健康狀態檢查偵測到機器故障後,刪除並重新建立故障的執行個體至少要花費一分鐘,但通常需要更久的時間。執行這項程序的速度比從內部負載平衡移除執行個體還慢得多。

  • 區域故障的應對情形

    大小為 1 的代管執行個體群組無法應對區域故障的情況。如要針對區域故障採取因應措施,請考慮加入服務失敗的 Stackdriver Monitoring 快訊,並於區域發生故障時在其他區域手動建立執行個體群組。

實作選項 2

請完成下列步驟來實作選項 2:

  1. 為 HAProxy VM 執行個體建立執行個體範本:

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. 為 HAProxy VM 建立大小為 1 的代管執行個體群組,並連結自動修復政策:

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. 測試是否能透過內部負載平衡 IP 連線至 HAProxy:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')
    
    username@testing:~$ curl $instance
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    當您透過主控台刪除 HAProxy 執行個體或停止 HAProxy 執行個體程序時,執行個體會因使用相同的 IP 位址和執行個體名稱而發生延遲,但之後應該會自動復原。

選項 3:使用優先順序不同的路徑進行容錯移轉

當您無法使用內部負載平衡時,也可以透過兩個具有不同優先順序的 Compute Engine 路徑,在兩個執行個體之間啟用流量容錯移轉。

在本節中,您會建立兩個 VM 執行個體,並將其放置到靜態大小為 1 的自動修復代管執行個體群組,讓系統能夠自動進行修復作業。

您必須在這兩個執行個體上啟用 IP 轉送功能。執行個體建立完成後,您可以設定兩個具有不同優先順序的路徑來處理流量,以便將所有浮動 IP 流量引導至這兩個執行個體。

選項 3:優先順序不同的路徑

選項 3 和選項 1 的差異:內部負載平衡

如果無法輕鬆使用內部負載平衡,您可以採用選項 3 來遷移應用實例。此選項具備以下優點:

  • 流量分佈

    流量一律會流向優先順序最低的 VM 執行個體。如果無法使用此 VM 執行個體,流量就會採用下一個最佳路徑。此架構與特定時間內僅啟用一部伺服器的內部部署環境相似。

  • 通訊協定

    內部負載平衡僅適用於一組特定的通訊協定或連接埠,而路徑則適用於流向特定目的地的所有流量。

  • 地區性

    內部負載平衡僅可在某地區內使用,但路徑可在全域內建立。

相較於使用內部負載平衡的選項 1,選項 3 具有下列缺點。

  • 健康狀態檢查

    如果使用選項 3,則兩個路徑全都不會與健康狀態檢查連結。無論基礎 VM 服務的健康狀態為何,系統都會採用路徑。即使服務的健康狀態不良,系統仍會將流量導向執行個體。如果將自動修復政策與執行個體連結,則當執行個體處於不良的健康狀態一段特定期間後,系統即會予以終止。然而,一旦重新啟動這些執行個體,系統就會恢復流量傳送,即使服務尚未啟動也一樣;這樣一來,在健康狀態不良的執行個體仍繼續提供流量的期間,或重新啟動的過程中,服務可能會因此而發生錯誤。

  • 容錯移轉時間

    刪除或停止 VM 執行個體後,系統將會自動撤銷路徑。然而由於缺少健康狀態檢查,只要執行個體仍可供使用,系統就會繼續使用路徑。此外,停止執行個體需要一些時間,因此容錯移轉花費的時間會遠比內部負載平衡方法還長。

  • 浮動 IP 位址選擇

    您只能將路徑設定至不屬於任何子網路的 IP 位址,而且必須選擇所有現有子網路範圍以外的浮動 IP 位址。

  • VPC 網路對等互連

    VM 執行個體只能使用本身 VPC 網路的路徑,無法使用任何對等 VPC 網路的路徑。

實作選項 3

您在實作期間會使用 10.191.1.1 IP 位址,該位址位在 ip-failover 網路所有已啟用的子網路以外的範圍。請完成下列步驟:

  1. 為轉送要求的 HAProxy 伺服器建立執行個體範本:

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    apt-get update
    apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.191.1.1
        netmask 255.255.255.255
    EOF
    service haproxy restart
    service networking restart" --can-ip-forward
    
  2. 為 HAProxy VM 執行個體建立兩個大小均為 1 的代管執行個體群組,然後將自動修復政策連結到這些群組:

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud compute instance-groups managed update \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. 啟動這些 VM 執行個體後,建立連到這些 VM 執行個體的主要和備份路徑:

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. 測試是否能透過該路徑連線至 HAProxy:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.191.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    當您透過主控台刪除主要 HAProxy 執行個體時,只要主要執行個體完全停止,系統應會立即採用通往次要執行個體的路徑。

選項 4:使用路徑 API 呼叫進行容錯移轉

選項 4 和 選項 3 一樣也會使用路徑,但在某些地方仍有重大差異。Keepalived 或其他指令碼不會執行自動修復及重新建立執行個體,而是透過 API 呼叫,將路徑新增至健康狀態良好的新執行個體,或是從健康狀態不良的執行個體中移除路徑。如果您無法使用 Compute Engine 健康狀態檢查來追蹤應用程式的健康狀態,或判斷哪個主要虛擬機器為何,則適合採用這種方法。任何應用程式邏輯均可觸發作業,讓系統針對路徑重新進行動態設計。

如果您以手動方式調查應用程式並讓執行個體重新上線,那麼透過路徑 API 呼叫進行容錯移轉也是非常實用的方式。然而,由於 VM 必須可以記錄所有故障情形,以及在回復到良好健康狀態時能自動替換,因此請勿在 Compute Engine 上手動調查故障。

選項 4:使用路徑 API 呼叫進行容錯移轉

選項 4 的差異:內部負載平衡

相較於使用內部負載平衡,選項 4 可提供下列優點:

  • 流量分佈

    與選項 2 和 3 相同,流量一次只會送向一個 VM 執行個體。

  • 無須使用 Compute Engine 健康狀態檢查

    任何自訂的應用程式邏輯均可觸發容錯移轉機制。在選項 4 的環境中,您可以使用指令碼來管理 Keepalived 如何應對主要與次要 HAProxy 之間的通訊失敗情形。當您無法或不想使用 Compute Engine 健康狀態檢查時,這是唯一可行的選項。

但是選項 4 也有以下主要缺點:

  • 複雜度

    此選項必須透過 Compute Engine API 或 gcloud 呼叫進行自訂,以便使用 Compute Engine API 撤銷或設定一個新路徑。因次,以安全可靠的方式建構此邏輯通常需要進行複雜的作業。

  • 容錯移轉時間

    由於這個選項需要使用自訂程式碼執行至少兩個 Compute Engine API 呼叫,才能在 Compute Engine 上撤銷及建立新路徑,因此容錯移轉作業的速度會比使用內部負載平衡器還稍慢一些。

  • 浮動 IP 位址選擇

    您只能將路徑設定至不屬於任何子網路的 IP 位址,而且必須選擇所有現有子網路範圍以外的浮動 IP 位址。

  • VPC 網路對等互連

    VM 執行個體只能使用本身 VPC 網路的路徑,無法使用任何對等 VPC 網路的路徑。

實作選項 4

此實作會使用 10.190.1.1 IP 位址,該位址位在 ip-failover 網路所有已啟用的子網路以外的範圍。此位址的路徑會透過 Keepalived 自動建立及刪除。

首先,您要使用靜態內部 IP 建立兩個已安裝 HAproxy 和 Keepalived 的 HAProxy 執行個體。您也必須啟用 IP 轉送功能以便能夠終止路徑,並取得 Compute Engine API 的存取權。為求說明簡潔,您在本例中不會使用執行個體範本和群組。

請完成下列步驟來建立選項 4:

  1. 使用 10.128.4.100 的靜態 IP 位址建立主要執行個體:

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state MASTER
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.100
        unicast_peer {
            10.128.4.200
        }
        virtual_router_id 50
        priority 100
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance haproxy-a --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  2. 使用 10.128.4.200 的靜態 IP 位址建立次要執行個體:

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state BACKUP
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.200
        unicast_peer {
            10.128.4.100
        }
        virtual_router_id 50
        priority 50
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-c \
        --next-hop-instance haproxy-b --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  3. 測試是否能透過該路徑連線至 HAProxy:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.190.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    如果終止 haproxy-a 執行個體的 HAProxy 或鎖定該執行個體,VRRP 活動訊號就會遺漏,而 haproxy-b 執行個體將叫用 takeover.sh 指令碼。這項指令碼會將 10.190.1.1 的路徑從 haproxy-a 移至 haproxy-b,而且測試仍可順利運作。

針對您的應用實例選擇最佳選項

如果應用實例涉及需要一組制定複雜轉送決策的 HAProxy 節點,則建議的 Compute Engine 實作為選項 1:內部負載平衡。這是因為 VM 執行個體為無狀態的,並且能在啟用/啟用情境下輕鬆運作。除此之外,您也可以使用 Compute Engine 健康狀態檢查。如為其他應用實例,選項 1 可能並非是最佳選擇。

除了先前針對各選項所列出的優缺點可供參考外,以下的決策樹狀圖也能協助您決定實作配置。

決策樹狀圖

可用性高且穩定的應用程式在 Compute Engine 中最適合採用水平資源調度架構,如此可將單一節點故障的影響降至最低。一般的內部部署情境無法在 Compute Engine 中完整重現,因此遷移這類情境 (如使用兩部具有浮動 IP 的伺服器) 頗具挑戰性。如前所述,由於受到虛擬轉送基礎架構本質上的限制,您無法透過無償 ARP 在毫秒內移動不同機器間的 IP 位址。

內部負載平衡服務能以簡單可靠的方式,將許多應用實例轉移至 Compute Engine。如果無法使用內部負載平衡器,您可以導入其他幾個不需要使用複雜重疊轉送機制的選項。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Compute Engine 說明文件