應用程式的災難復原情境

本文是探討在 Google Cloud Platform (GCP) 中進行災難復原 (DR) 系列的最後一個單元。本單元旨在探索應用程式通用的災難復原情境。

本系列包含三個單元:

簡介

本文依據 DR 模式建構應用程式的 DR 情境。DR 模式表示應用程式從災難事件中復原的準備程度。我們藉由 DR 構成要素一文討論的概念,說明如何實作適合您的復原目標的端對端 DR 計畫。

首先,讓我們來看看一些典型的工作負載,藉此說明思考復原目標和架構如何對您的 DR 計劃造成直接影響。

批次處理工作負載

批次處理工作負載往往不是關鍵任務,所以您通常不需要花錢設計 HA 架構以最大化運作時間;一般來說,批次處理工作負載可以處理中斷作業。這類型的工作負載可利用符合成本效益的產品,例如先佔 VM 執行個體。建立和執行這類執行個體的費用比一般執行個體少很多。(然而,如果 Compute Engine 需要存取這些執行個體的資源以執行其他工作,則會終止 (先佔) 這些執行個體,執行個體最多會在啟動後終止 24 小時。)

若您在處理工作中實行定期查核點,則啟動新的 VM 時,會從失敗點開始繼續處理工作。如果您使用 Cloud Dataproc,則會由代管的執行個體群組管理啟動先佔工作站節點程序。這可視為暖模式,因為在等待替換的 VM 繼續處理時會短暫暫停。

電子商務網站

在電子商務網站中,應用程式的某些部分可能會有較大的復原時間目標 (RTO) 值。例如,實際採購管道需要高可用性,但傳送訂單通知給客戶的電子郵件程序可以容忍幾小時的延遲。客戶知道其採購項目,因此他們雖然預期會收到確認電子郵件,但通知並不是此程序的重要部分。這個程序混和了熱模式 (採購) 和暖/冷模式 (通知)。

應用程式的交易部分需要高運作時間,但 RTO 值要在最低,因此您會使用 HA 提高這部分應用程式的可用性。您可以將這個方法視為熱模式。

電子商務情境說明如何在同一個應用程式中使用不同的 RTO 值。

影片串流

影片串流解決方案的許多元件都需要高可用性,從搜尋體驗到串流內容給使用者的實際程序。此外,系統需要低延遲以提供令人滿意的使用者體驗。如果解決方案的任一部分無法提供出色的體驗,對供應商及客戶而言都不利。而且,現今的客戶可輕易地改用競爭對手的產品。

在此情境中,您必須要有 HA 架構和很小的 RTO 值。這個情境需要在整個應用程式結構中使用熱模式,才能保證在災難發生時,影響會是最小。

內部部署實際工作環境的 DR 和 HA 架構

本節說明在內部部署執行應用程式,而 DR 解決方案位於 GCP 上時,如何實行冷、暖、熱這三種模式。

冷模式:復原至 GCP

在冷模式中,您在 DR GCP 專案中的資源最少,只剛好夠用來啟用復原情境。當發生讓實際工作環境無法執行實際運作的工作負載問題時,容錯移轉策略需要在 GCP 中啟動實際工作環境鏡像。然後,用戶端會開始從 DR 環境使用服務。

我們將在本節檢視這個模式的範例。在範例中,Cloud Interconnect 設定了 Cloud VPN 以提供連至 GCP 的連線能力。資料會複製到 Cloud Storage,做為實際工作環境的一部分。

DR 構成要素:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

下圖說明此範例架構:

在內部部署執行實際工作時,冷模式的架構

下列步驟大致說明如何設定環境:

  1. 建立虛擬私人雲端網路
  2. 設定連線以連結內部部署網路與 GCP 網路。
  3. 建立 Cloud Storage 值區做為資料備份的目標。
  4. 為專用服務帳戶產生服務帳戶金鑰。這個檔案是用來傳送憑證給自動化指令碼。
  5. 將服務帳戶金鑰複製到內部部署機器,然後在機器上執行指令碼以上傳資料庫備份 (此機器可以是您的資料庫伺服器,然而您的安全性政策可能不允許您在資料庫伺服器上安裝其他軟體)。

  6. 建立 IAM 政策以限制能夠存取值區與其物件的對象。請納入專為這項作業所建立的服務帳戶。此外,也請將使用者帳戶或群組加入作業員或系統管理員的政策中,向這些身分授予相關權限。如要進一步瞭解 Cloud Storage 的存取權限,請參閱 gsutil 指令所需的 IAM 權限相關頁面。

  7. 進行測試,確認您可以在目標值區中上傳與下載檔案。

  8. 建立資料移轉指令碼

  9. 建立排程工作以執行指令碼。

  10. 建立自訂映像檔,針對實際工作環境的各部伺服器進行設定。每個映像檔的設定應與內部部署的對應伺服器相同。

    在資料庫伺服器自訂映像檔設定中建立開機指令碼,從 Cloud Storage 值區將最新的備份自動複製到執行個體,然後叫用復原程序。

  11. 設定 Cloud DNS 為指向連結到網際網路的網路服務。

  12. 建立 Deployment Manager 範本,使用之前設定的自訂映像檔,在 GCP 網路中建立應用程式伺服器。這個範本也應視需要設定適當的防火牆規則。

您必須實作這些程序,以確保自訂映像檔的應用程式版本與內部部署相同。請務必在您的標準升級週期中納入升級到自訂映像檔的程序,並確保 Deployment Manager 範本使用最新的自訂映像檔。

容錯移轉程序和重新啟動後工作

如果發生災難,您可以復原到 GCP 上執行的系統。如要這麼做,請啟動復原程序,以使用您建立的 Deployment Manager 範本來建立復原環境。當復原環境中的執行個體準備好接受實際工作流量時,請調整 DNS 以指向 GCP 中的網路伺服器。

復原順序通常為:

  1. 使用 Deployment Manager 範本,在 GCP 中建立部署
  2. 遵循資料庫系統的復原備份檔案操作說明,將 Cloud Storage 中的最新資料庫備份套用到在 GCP 中執行的資料庫伺服器。
  3. 套用 Cloud Storage 中最新的交易記錄。
  4. 在已復原的環境中模擬使用者情境,測試應用程式是否如預期運作。
  5. 測試成功後,請設定 Cloud DNS 以指向 GCP 上的網路伺服器 (例如,您可以使用 GCP 負載平衡器後面的 Anycast IP 位址,在該負載平衡器後面使用數個網路伺服器)。

下圖顯示已復原的環境:

在內部部署執行實際工作時,冷復原模式的設定

當實際工作環境重新在內部部署中執行,且環境支援實際工作負載時,您可以反向執行容錯移轉至 GCP 復原環境時所採取的步驟,返回實際工作環境。順序通常為:

  1. 備份在 GCP 上執行的資料庫。
  2. 將備份檔案複製到實際工作環境。
  3. 將備份檔案套用到實際工作環境的資料庫系統。
  4. 不要連結到 GCP 中的應用程式。例如,不要連結全域負載平衡器。從這時開始到您完成還原實際工作環境前,應用程式將無法使用。
  5. 將所有交易記錄檔案複製到實際工作環境,並套用到資料庫伺服器。
  6. 設定 Cloud DNS 為指向內部部署網路服務。
  7. 確定您的程序會如預期運作,將資料複製到 Cloud Storage。
  8. 刪除部署

暖待命:復原到 GCP

通常實行暖模式是為了在不花錢設定完整的 HA 的情況下,最小化 RTO 和 RPO 值。RTO 和 RPO 的值愈小,費用愈高,因為此方法使用可處理來自兩個環境的流量的完全備援環境。因此,在 DR 情境實行暖模式可在預算和可用性之間取得良好平衡。

此方法的範例為使用設定了 Cloud VPN 的 Cloud Interconnect 建立連至 GCP 的連線能力。多層應用程式在內部部署執行的同時,也會在 GCP 上使用最小復原套件。復原套件含有 GCP 上的一個資料庫伺服器作業執行個體。此執行個體必須持續執行,以便透過非同步或半同步複製技術接收複製的交易。若要降低費用,您可以使用執行資料庫服務的最小機器類型來執行資料庫。因為您可以使用長時間執行的執行個體,因此適用續用折扣。

DR 構成要素:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Deployment Manager

Compute Engine 快照可讓您建立備份,並使用該備份復原到之前的狀態。本範例之所以使用快照,是因為更新的網頁和應用程式二進位檔會頻繁地寫入實際工作環境網路和應用程式伺服器。這些更新會定期複製到 GCP 上的參考網路伺服器和應用程式伺服器執行個體。(參考伺服器是用來建立快照的,因此不接受實際工作流量。)

下圖說明實行此方法的架構。圖中未顯示複製目標。

在內部部署執行實際工作時,暖模式的架構

下列步驟大致說明如何設定環境:

  1. 建立虛擬私人雲端網路
  2. 設定連線以連結內部部署網路與 GCP 網路。
  3. 將內部部署伺服器複製到 GCP VM 執行個體。您可以選擇使用夥伴解決方案;使用的方法須視您的情況而定。
  4. 在 GCP 上建立資料庫伺服器的自訂映像檔,此映像檔的設定要與內部部署資料庫伺服器相同。
  5. 為網路伺服器和應用程式伺服器執行個體建立快照
  6. 使用您稍早建立的自訂映像檔,在 GCP 中啟動資料庫執行個體。使用可從內部部署實際工作環境資料庫接受複製資料的最小機器類型。
  7. 連結永久磁碟與 GCP 資料庫執行個體,以儲存資料庫和交易記錄。
  8. 遵循資料庫軟體的操作說明,設定在內部部署資料庫伺服器和 GCP 中資料庫伺服器之間的複製作業。
  9. 將連結到資料庫執行個體的永久磁碟的自動刪除標記設為 no-auto-delete
  10. 設定排程工作,定期為 GCP 上資料庫執行個體的永久磁碟建立快照。
  11. 測試建立永久磁碟快照,以及從快照建立執行個體的程序。
  12. 使用稍早建立的快照,建立網路伺服器和應用程式伺服器的執行個體。
  13. 建立指令碼,只要對應的內部部署伺服器有更新,就會將更新複製到網路應用程式和應用程式伺服器。編寫指令碼,為更新的伺服器建立快照。
  14. 設定 Cloud DNS 以指向連結到網際網路的內部部署網路服務。

容錯移轉程序和重新啟動後工作

若要管理容錯移轉,通常需使用監控和快訊系統來叫用自動容錯移轉程序。內部部署應用程式需要容錯移轉時,您可以在 GCP 上設定資料庫系統,讓該系統接受實際工作流量。您也可以啟動網路和應用程式伺服器的執行個體。

下圖顯示容錯移轉至 GCP 後的設定,可讓 GCP 處理實際工作負載:

在內部部署執行實際工作時,暖復原模式的設定

復原順序通常為:

  1. 針對資料庫伺服器執行個體調整大小,使其能夠處理實際工作負載。
  2. 使用 GCP 上的網路伺服器和應用程式快照,以建立新的網路伺服器和應用程式執行個體。
  3. 在已復原的環境中模擬使用者情境,測試應用程式是否如預期運作。
  4. 測試成功後,請設定 Cloud DNS 以指向 GCP 上的網路服務。

當實際工作環境重新在內部部署中執行並能支援實際工作負載時,您可以反向執行容錯移轉至 GCP 復原環境時所採取的步驟,返回實際工作環境。順序通常為:

  1. 備份在 GCP 上執行的資料庫。
  2. 將備份檔案複製到實際工作環境。
  3. 將備份檔案套用到實際工作環境的資料庫系統。
  4. 不要連結到 GCP 中的應用程式。其中一個方式是透過修改防火牆規則,避免連結到網路伺服器。從這時開始到您完成還原實際工作環境之前,應用程式將無法使用。
  5. 將所有交易記錄檔案複製到實際工作環境,並套用到資料庫伺服器。
  6. 在實際工作環境中模擬使用者情境,以測試應用程式是否按照預期運作。
  7. 設定 Cloud DNS 為指向內部部署網路服務。
  8. 刪除在 GCP 中執行的網路伺服器和應用程式伺服器執行個體。讓參考伺服器保持執行。
  9. 將 GCP 上的資料庫伺服器大小調整回可接受內部部署實際運作資料庫中複製的資料的最小執行個體大小。
  10. 遵循資料庫軟體的操作說明,設定在內部部署資料庫伺服器和 GCP 中資料庫伺服器之間的複製作業。

跨內部部署和 GCP 的熱 HA

如果您的 RTO 和 RPO 值較小,只要在實際工作環境和 GCP 並行執行 HA,就能獲得這些值。這個方法是熱模式,因為內部部署和 GCP 都在處理實際工作流量。

而與暖模式間的主要差異為兩種環境的資源都是在實際運作模式中執行,並處理實際工作流量。

DR 構成要素:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • 代管執行個體群組
  • Stackdriver
  • Cloud Load Balancing

下圖說明此範例架構。實作這個架構後,發生災難時您的 DR 計劃只需要最少的人為操作。

在內部部署執行實際工作時,熱模式的架構

下列步驟大致說明如何設定環境:

  1. 建立虛擬私人雲端網路
  2. 設定連線以連結內部部署網路與 GCP 網路。
  3. 在 GCP 中建立自訂映像檔,針對內部部署實際工作環境的各部伺服器進行設定。每個 GCP 映像檔的設定都應與內部部署的對應伺服器相同。
  4. 遵循資料庫軟體的操作說明,設定在內部部署資料庫伺服器和 GCP 中資料庫伺服器之間的複製作業。

    設定複製作業時,由於許多資料庫系統只允許一個可寫入的資料庫執行個體,因此您可能需要確定其中一個資料庫備用資源將做為唯讀伺服器。

  5. 建立個別的執行個體範本,在應用程式伺服器和網路伺服器使用映像檔。

  6. 設定應用程式和網路伺服器的地區代管執行個體群組

  7. 使用 Stackdriver Monitoring 設定健康狀態檢查。

  8. 使用稍早設定的地區代管執行個體群組,設定負載平衡

  9. 設定排程工作,定期建立永久磁碟快照。

  10. 設定 DNS 服務,分配內部部署環境和 GCP 環境之間的流量。

如要使用這種混合式方法,就必須使用可加權轉送到這兩個實際工作環境的 DNS 服務,才能從這兩個環境提供相同的應用程式。

您必須針對只在環境中的一小部分發生失敗 (部分失敗) 的情況來設計系統。在此情況下,流量應轉送到另一個備份環境中的相等服務。例如,如果内部部署網路伺服器變成無法使用,您可以停用以該環境為目的地的 DNS 轉送。如果 DNS 服務支援健康狀態檢查,則在健康狀態檢查判定無法連結其中一個環境的網路伺服器時,即會自動停用該轉送功能。

如果您使用的資料庫系統只允許一個可寫入的執行個體,在許多情況下,資料庫系統會在原始可寫入資料庫和讀取備用資源之間的活動訊號中斷時,自動將唯讀備用資源升級成可寫入的主要執行個體。請確定您瞭解這方面的資料庫複製作業,以防您在災難發生後需要介入操作。

您必須實行這些程序,以確保 GCP 中的自訂 VM 映像檔的應用程式版本與內部部署版本相同。請在標準升級週期中納入升級到自訂映像檔的程序,並確保 Deployment Manager 範本使用最新的自訂映像檔。

容錯移轉程序和重新啟動後工作

本文說明的熱情境設定中,災難單純是指兩個環境中有一個無法使用。暖情境或冷情境所使用的容錯移轉程序都不相同,您在此程序中必須移動資料,或將資料處理到第二個環境。但您可能需要處理下列設定變更:

  • 如果 DNS 服務無法在健康狀態檢查失敗時自動重新轉送流量,您必須手動將 DNS 轉送重新設定為將流量傳送到仍在作用中的系統。
  • 如果資料庫系統無法在失敗時將唯讀備用資源自動升級成可寫入的主要執行個體,您必須介入操作,以確保備用資源能夠升級。

當第二個環境再次執行且可以處理實際工作流量時,您必須重新同步處理資料庫。因為這兩個環境都支援實際工作負載,所以您不需要採取任何變更主要資料庫的動作。資料庫同步後,您可以調整 DNS 設定,就能再次在這兩個環境之間分配實際工作流量。

GCP 上實際工作環境的 DR 和 HA 架構

針對 GCP 上的實際工作負載設計應用程式架構時,平台的 HA 功能會直接影響 DR 架構。

冷:可復原的應用程式伺服器

在只需要一個伺服器執行個體的冷情境中,您只需要一個寫入磁碟的執行個體。而在內部部署中,這通常是透過主動/被動叢集來進行。相反地,當您在 GCP 上執行實際工作環境時,伺服器執行個體是代管執行個體群組的一部分,且該群組將做為內部負載平衡服務的後端服務

DR 構成要素:

  • Compute Engine
  • GCP 內部負載平衡

下圖說明此範例架構。此圖不包含用戶端連線,因為您通常不會讓外部用戶端直接連結到應用程式伺服器,而會透過應用程式伺服器前面的 Proxy 或網路應用程式進行連結。

在 GCP 執行實際工作時,冷情境的架構

以下步驟概述如何設定這個情境:

  1. 建立虛擬私人雲端網路
  2. 建立設定了應用程式服務的自訂映像檔。在映像檔中,執行下列設定:

    1. 設定伺服器,將應用程式服務處理的資料寫入連結的永久磁碟。
    2. 從連結的永久磁碟建立快照
    3. 設定開機指令碼,從最新的快照建立永久磁碟及掛接磁碟。這個指令碼必須取得磁碟的最新快照。
  3. 建立使用映像檔的執行個體範本

  4. 使用您稍早建立的執行個體範本,設定目標大小為 1 的地區代管執行個體群組

  5. 使用 Monitoring 設定健康狀態檢查。

  6. 使用您稍早設定的地區代管執行個體群組,設定內部負載平衡

  7. 設定排程工作,定期建立永久磁碟快照。

這個情境利用了 GCP 提供的某些 HA 功能。您不需要發動任何容錯移轉步驟,因為這些步驟會在發生災難時自動執行。內部負載平衡器可確保即使需要替換執行個體,應用程式伺服器前面還是會使用相同的 IP 位址。執行個體範本和自訂映像檔可確保替換執行個體的設定與被替換的執行個體完全相同。

您的 RPO 將由最近一次取得的快照決定。取得快照的頻率愈密集,RPO 值就愈小。

地區代管執行個體群組提供深度的 HA,可因應應用程式、執行個體或區域層級的錯誤。如果發生上述任一情境,您不需要手動介入。將目標大小設為 1,可確保您永遠都只會有 1 個執行個體在執行。

永久磁碟屬於區域層級,因此在發生區域失敗時,必須建立快照才能重建磁碟。您也可以跨地區使用快照,將磁碟還原到其他地區,就像在同一地區還原一樣輕鬆。

容錯移轉程序

在這個情境中,發生區域失敗時,地區執行個體群組會啟動同個地區不同區域中的替換執行個體。系統會依據最新的快照建立新的永久磁碟,然後將該永久磁碟連結至新的執行個體。下圖說明此狀態:

在 GCP 執行實際工作時,冷復原模式的設定

此設定的部分變更包括:

  • 使用地區永久磁碟而非區域永久磁碟。如果使用這個方法,在執行復原步驟的過程中,您不需要使用快照來還原永久磁碟。但這個變化版本會使用兩倍儲存空間,您要有這樣的預算才能執行。
  • 使用代管執行個體群組而非地區代管執行個體群組,並將永久磁碟連結到在失敗的執行個體的區域中啟動的替代執行個體。在這個情境中,您必須將永久磁碟的自動刪除設定設為 no-auto-delete

您選擇的方法取決於您的預算以及 RTO 和 RPO 值。

暖:靜態網站容錯移轉

如果 Compute Engine 執行個體失敗,您可以讓以 Cloud Storage 為基礎的靜態網站處於待命狀態,以減輕服務中斷問題。 如果您的網路應用程式大多時間是靜態時,可以選擇使用靜態網站。在此情境下,主要應用程式會在 Compute Engine 執行個體上執行。這些執行個體分成代管執行個體群組,以及做為 HTTP 負載平衡器後端服務的執行個體群組。HTTP 負載平衡器會依據負載平衡器設定、每個執行個體群組的設定及每個執行個體的健康狀態,將連入流量引導到執行個體。

DR 構成要素:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

下圖說明此範例架構:

在 GCP 執行實際工作時,暖容錯移轉到靜態網站的架構

以下步驟概述如何設定這個情境:

  1. 建立虛擬私人雲端網路
  2. 建立設定應用程式網路服務的自訂映像檔
  3. 建立使用網路伺服器映像檔的執行個體範本
  4. 為網路伺服器設定代管執行個體群組
  5. 使用 Monitoring 設定健康狀態檢查。
  6. 使用您稍早設定的代管執行個體群組,設定負載平衡
  7. 建立以 Cloud Storage 為基礎的靜態網站

在實際工作環境設定中,Cloud DNS 設定為指向這個主要應用程式,且待命靜態網站處於休眠狀態。如果 Compute Engine 應用程式故障,您可以將 Cloud DNS 設定為指向這個靜態網站。

容錯移轉程序

如果一或多個應用程式伺服器故障,復原順序會是設定 Cloud DNS 以指向您的靜態網站。下圖顯示復原模式中的架構:

在 GCP 執行實際工作時,容錯移轉到靜態網站後的設定

當應用程式 Compute Engine 執行個體再次執行並能支援實際工作負載時,請反向執行復原步驟:設定 Cloud DNS 以指向在執行個體前面的負載平衡器。

熱:HA 網路應用程式

當實際工作環境在 GCP 上執行時,使用熱模式的目的是要建立架構良好的 HA 部署。

DR 構成要素:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

下圖說明此範例架構:

在 GCP 執行實際工作時,熱模式的架構

這個情境利用了 GCP 提供的 HA 功能。您不需要啟動任何容錯移轉步驟,因為它們會在發生災難時自動執行。

如圖所示,此架構會使用地區代管執行個體群組,搭配全域負載平衡和 Cloud SQL 一起使用。這裡提供的範例使用地區代管執行個體群組,因此執行個體會分佈在三個區域。

使用這個方法,您就能獲得深度 HA。地區代管執行個體群組提供的機制可因應應用程式、執行個體或區域層級的錯誤,其中任何情境發生時,您都不需要手動介入。

若要在設定代管執行個體群組的過程中處理應用程式層級復原,請設定 HTTP 健康狀態檢查,確認服務在該群組的執行個體上正常運作。如果健康狀態檢查確定執行個體上的服務失敗,則群組會自動重建該執行個體。

如需其中一個在 GCP 上設定 HA 網路應用程式的方法和其詳細步驟,請參閱在 GCP 上建置可擴充且有彈性的網路應用程式

後續步驟

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

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

這個網頁
Architectures