浮動 IP 位址的最佳做法

在使用浮動 IP 位址的情況下,如果您要將應用程式從內部部署網路環境遷移至 Google Compute Engine 時,可以採用本文所概述的幾種替代方案。浮動 IP 位址也稱為「共用」或「虛擬」IP 位址,通常用於提升內部部署網路環境的可用性。只要使用浮動 IP 位址,您就可以在多個設定相同的實體或虛擬伺服器之間傳遞 IP 位址,以便對實際工作環境的軟體進行容錯移轉或升級。然而,您無法直接在 Compute Engine 環境中導入浮動 IP 位址。

內部部署環境中的浮動 IP 位址

浮動 IP 位址常用於內部部署環境中。下面列出了幾個浮動 IP 位址的應用實例:

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

要在內部部署環境中採用浮動 IP 位址的方法有好幾種,但無論是哪種方法,共用 IP 位址的伺服器也都必須透過活動訊號機制分享彼此的狀態。這種機制能讓這些伺服器互相回報本身的健康狀態,而且在連結的伺服器無法正常運作的情況下,也能讓次要伺服器接手管理浮動 IP 位址。這種配置通常是利用虛擬路由器備援通訊協定 (VRRP) 來實作的,但您也可以使用其他類似的機制來進行。

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

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

一般內部部署環境

您使用的設定會因不同的內部部署負載平衡解決方案而稍有調整,例如 Windows 網路負載平衡或 Linux 負載平衡會採用 IP 虛擬伺服器 (IPVS) 等伺服器直接回應。在這些情況下,服務也會送出無償 ARP 訊框,但是會使用另一個伺服器的 MAC 位址做為無償 ARP 來源,因此實質上是假冒 ARP 訊框並接管另一部伺服器的來源位址。這類設定情況已超出本解決方案的討論範圍。在絕大部分情況下,遷移至 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 層的複雜標頭比對和替換,將流量轉送至不同的後端。您無法將這組伺服器替換成內部 TCP/UDP 負載平衡,或是 HTTP 負載平衡,因為這牽涉到複雜的規則。下圖顯示本應用實例的整體概念。

遷移應用實例

HAProxy 伺服器會透過內部部署的 Keepalived 軟體,利用不同的交叉連結網路查看可用性,然後在兩個伺服器之間傳遞浮動 IP 位址。

對於這個應用實例來說,我們在下列各節所述的所有四個選項,均為有效的浮動 IP 位址的內部部署替代方案。而對於其他較複雜的應用實例來說,可用的選項可能會比較少。本解決方案會在說明這些選項後,根據特定的應用實例提供選取適用選項的指南。

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

使用 Compute Engine 進行實作

本節概述將內部部署情境遷移至 Compute Engine 的幾種方式。我們為了要降低複雜度,不會使用上述的標頭式比對方法,而是將所有要求轉送至擁有最低後端設定的單一 NGINX 後端群組。

在所有範例中,系統均會將流量從 HAProxy 轉送到在會自動資源調度的執行個體群組中的一組 Compute Engine 後端。您可以利用內部 TCP/UDP 負載平衡器來存取這些後端。而針對範例設定,這些後端會使用 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) 的內部 TCP/UDP 負載平衡器連結到這個執行個體群組:

    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 指令連線至該執行個體,然後查看您是否能連線到內部 TCP/UDP 負載平衡 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:使用內部 TCP/UDP 負載平衡

您可以在 Compute Engine 中實作內部部署情境,方法是兩個 HAProxy 伺服器放在內部 TCP/UDP 負載平衡後方的代管執行個體群組中,然後把內部 TCP/UDP 負載平衡 IP 位址做為虛擬 IP 位址,如下圖所示。

選項 1:內部 TCP/UDP 負載平衡

我們假設內部部署的已遷移服務只會對內部公開。如果您嘗試遷移的服務可供外部存取,則可使用 HTTP(S) 負載平衡TCP Proxy安全資料傳輸層 (SSL) Proxy,或是網路負載平衡,以類似的方式實作此情境。

您也可以使用下列僅限 Beta 版的選項:

與內部部署設定之間的差異

內部 TCP/UDP 負載平衡 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 位址會接受所有流量。而對於內部 TCP/UDP 負載平衡器來說,您必須在內部轉送規則中選擇下列某個通訊埠規格:

    • 用數字指定至少一個,最多五個通訊埠
    • 指定 ALL 即可將流量轉送至所有通訊埠

實作選項 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. 將內部 TCP/UDP 負載平衡器,連結到有健康狀態檢查的 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. 測試您是否能透過內部 TCP/UDP 負載平衡,連線至 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 的比較:內部 TCP/UDP 負載平衡

與選項 1 相較之下,選項 2 有幾個主要的優、缺點。

優點:

  • 流量分佈

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

  • 節省成本

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

  • 簡單易用

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

缺點:

  • 容錯移轉時間

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

  • 區域故障的應對情形

    大小為 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. 測試您是否能透過內部 TCP/UDP 負載平衡 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:使用優先順序不同的路徑進行容錯移轉

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

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

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

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

選項 3 與選項 1 的比較:內部 TCP/UDP 負載平衡

只要使用選項 3,您就可以在無法輕鬆使用內部 TCP/UDP 負載平衡時遷移應用實例。此選項具備以下優點:

  • 流量分佈

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

  • 通訊協定

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

  • 地區性

    內部 TCP/UDP 負載平衡只能在單一地區內使用,而路徑可在世界上任何地區內建立。

與使用內部 TCP/UDP 負載平衡的選項 1 相較之下,選項 3 是有缺點的。

  • 健康狀態檢查

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

  • 容錯移轉時間

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

  • 浮動 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 的差異:內部 TCP/UDP 負載平衡

與使用內部 TCP/UDP 負載平衡相較之下,選項 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 會自動建立及刪除這個位址的路徑。

首先,您要建立兩個已安裝 HAproxy 和 Keepalived 的 HAProxy 執行個體,且這兩個執行個體要使用不同的靜態內部 IP 位址。您也必須啟用 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:內部 TCP/UDP 負載平衡。這是因為 VM 執行個體為無狀態的,並且能在啟用/啟用情境下輕鬆運作。除此之外,您也可以使用 Compute Engine 健康狀態檢查。如為其他應用實例,選項 1 可能並非是最佳選擇。

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

決策樹狀圖

可用性高且穩定的應用程式的最佳實作方式,就是在 Compute Engine 中利用水平資源調度架構,以便將單一節點故障的影響降至最低。要遷移一般的內部部署情境 (例如使用浮動 IP 位址的兩個伺服器) 是有難度的,因為這種情境無法在 Compute Engine 中重現。如前所述,由於虛擬轉送基礎架構本質上的限制,您無法透過無償 ARP 在一秒內將某台機器上的 IP 位址移動到不同的機器上。

內部 TCP/UDP 負載平衡服務能讓您以簡單、可靠的方式,將許多應用實例轉移至 Compute Engine。而對於無法使用內部負載平衡器的實例,您可以採用其他幾種不需要使用複雜重疊轉送機制的選項。

後續步驟

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

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

這個網頁
Compute Engine 說明文件