適合您工作負載的高可用性設計

IBM Cloud 支援單一區域內、跨多區域區域中的多個區域以及跨多個區域的高可用性應用程式部署。

故障域決定了每個部署選項對基礎架構故障的保護程度。 部署在單一區域中的應用程式實例不會受到該區域故障的保護。 部署在多個可用區域中的應用程式執行個體可以免受單一區域故障的影響。 多個可用區位於同一城域內，並透過低延遲網路鏈路連接，允許跨區域同步複製資料。 部署在多個區域的應用程式實例可以免受整個區域故障的影響。 不同的地區位於不同的國家或同一國家的不同地區。 區域之間的距離通常只允許非同步複製資料。

下表顯示了基於公有雲中可用的故障域的應用程式部署選項。

高可用性部署選項及其各自的可用性、故障域以及維護成本和複雜性。
部署 可用性 故障域 成本和複雜性
單區、
單區域 		低/中 虛擬伺服器/實體主機 低
多區域、
單區域 		高 區域 中
多區域、
多區域 		非常高 地區 高

單專區部署

在單一可用區部署中，多個應用程式執行個體部署在一個可用區中。 如果應用程式執行個體在單一虛擬伺服器中執行，則置放群組 允許在單獨的實體主機中設定這些虛擬伺服器。 VPC Autoscale 可用於根據工作負載變化實現動態容量調整。 單區域部署提供經濟高效的解決方案，基礎設施可用性高達 99.9 %。 此部署可能適合非生產環境或非業務關鍵型應用程式。 但是，單區域部署無法提供區域中斷保護。

在使用此部署模型時，最佳實務是避免區域性失衡。 所謂的「區域不平衡」，是指資源（例如 VPC 虛擬伺服器實例（VSIs））未在各區域之間均勻分配的情況。 假設有個工作負載，其 VSI 容量的 70% 部署在區域 1、20% 部署在區域 2，以及 10% 部署在區域 3。 倘若第 1 區發生故障，工作負載雖仍可維持可用狀態，但其容量將僅剩 30%。 其中一個解決方案是在第 1 區域發生中斷時配置更多資源，但此中斷可能會導致其餘區域的容量需求出現異常激增。 較佳的解決方案是消除這種不平衡，並確保所需容量均勻分配至各區域，同時在每個區域預留約 17% 的額外餘裕，以彌補任何單一區域可能造成的損失。 這可確保即使發生區域損失的情況，工作負載仍能維持可用狀態，並能以全容量運作。

多可用區、單區域部署

在多區域、單區域部署中，多個應用程式執行個體會跨區域內的兩個或多個可用區部署。 當應用程式部署於三個可用區域時，多區域、單區域的部署方式可提供高達 99.99 % 的基礎架構可用性。 此部署方式可保護應用程式免受區域故障的影響，並適用於具備 > 99.9 % 可用性要求的生產級企業工作負載。 實際的應用可用性取決於應用的高可用性設計。

使用此部署模式時，請避免區域間的不平衡。 當容量（例如 IBM Cloud® Virtual Servers for Virtual Private Cloud s（VSIs））未在各區域之間均勻分配時，便會發生區域不平衡的情況。 假設有個工作負載，其 VSI 容量的 70% 部署在區域 1、20% 部署在區域 2，以及 10% 部署在區域 3。 若第 1 區發生故障，工作負載可能仍可正常運作，但容量將僅剩 30%。 雖然在發生服務中斷時可以增配更多資源，但服務中斷可能會導致其餘區域的容量需求出現異常激增。 相反地，應將所需容量均勻分配至各區域，以消除這種不平衡，並在每個區域額外預留約 17% 的冗餘容量，以彌補任何單一區域可能造成的損失。 這可確保即使某個區域發生故障，工作負載仍能維持可用狀態，並能以全容量運作。

多地區、多區域部署

多專區、多區域部署可提供針對區域中斷的保護。 建議對具有連續或接近連續可用性要求的關鍵任務應用程式進行此部署。 此部署還支援具有跨地理或特定間隔距離要求的應用程式的區域外災難復原和業務連續性。

多區域部署依賴跨可用區域的應用程式感知資料複製，並支援主動-主動和主動-備用架構模式。 多區域、多區域部署支援具有持續可用性和始終在線要求的企業應用程式的架構模式。 下表顯示了不同部署選項和建議使用的比較。

高可用部署建議
部署 可用性 說明 建議用法
單一區域 99.9%
  • 一個區域內有多個計算實例
  • 防止基礎設施故障
  • 低/中等成本
  • 低到中優先順序的應用程序
  • 非關鍵生產工作負載
多區域、單區域 99.99%
  • 跨 2 個或更多可用區的多個計算實例
  • 跨區域同步資料複製
  • 防止區域斷電
  • 中/高成本
  • 核心業務應用
  • 具有嚴格彈性要求的生產級工作負載
  • 具有國家邊界或地理資料駐留限制的業務連續性政策
多區域、多區域

99.99%
  • 跨 2 個或更多區域的多個可用區的多個計算實例
  • 區域間非同步資料複製
  • 防止區域中斷
  • 成本高
  • 具有連續或接近連續可用性要求的任務關鍵型應用程式
  • 具有跨地域或特定間隔距離要求的業務連續性政策
  • 災難復原

以下架構框架提供了在 IBM Cloud Virtual Private Cloud (VPC) 基礎架構上部署彈性應用程式的設計注意事項和架構決策。 它涵蓋以下解決方案方面和領域：

  • 網路： 負載平衡、網域名稱系統
  • 安全性： 資料安全
  • 彈性： 高可用性、備份與復原、災難復原
  • 服務管理： 監控、日誌記錄、審核、警報

VPC彈性架構設計範圍
VPC彈性架構設計範圍

架構設計框架 透過解決一組面向和領域的需求，提供了一種一致的方法來設計雲端解決方案。 這些域是任何企業解決方案都需要考慮的架構領域，無論技術為何。

高可用應用程式的用戶端重試邏輯

您負責建立能夠有效處理臨時錯誤的客戶端應用程式。 臨時錯誤包括網路錯誤和由服務的高可用性實現引入的臨時故障，例如區域服務從區域性故障中恢復時。 有關特定 IBM Cloud 服務的更多信息，請參閱 高可用性和災難復原的服務文件。

許多 IBM Cloud SDK 均基於 IBM Cloud SDK Common 構建，支援自動重試，旨在處理特定 HTTP 錯誤（例如 429 和 503 錯誤）。 SDK 不會自動處理所有錯誤。 要利用重試邏輯，您必須正確配置 SDK。

一些 IBM Cloud 服務支援開源協議，使用開源 SDK 可能比較合適。 檢查這些 SDK 以確定它們是否對您的應用程式有用並提供合適的重試功能。

重試邏輯根據 IBM Cloud 服務的類型和操作類型而有所不同。 某些失敗的操作會產生適合重試的狀態代碼，而某些操作會產生不適合重試的狀態代碼。 失敗的讀取和 HTTP GET 操作通常可以透過使用固定時間段的指數退避來重試。 指數退避是一種重試策略，用於管理失敗操作（例如網路請求或 API 呼叫）後的重試。 它以指數模式逐漸增加重試之間的延遲，從而降低系統過載的風險。 應重試的故障取決於故障類型和特定的 IBM Cloud 服務。 有關更多信息，請參閱每個 IBM Cloud 服務 SDK 和文件。

失敗的寫入、HTTP PUT、POST、DELETE 和其他操作可能無法透過使用簡單的重試機制來恢復，除非明確操作未完成且記錄的客戶端邏輯表明重試是適當的。 當更改系統狀態的操作（例如建立資源）失敗時，通常不清楚導致失敗的原因。 由於這種不確定性，您不能依靠簡單的重試邏輯來解決問題。 相反，請使用專為 IBM Cloud 服務設計的更高級方法。

客戶端重試提高了單一客戶端的可用性，並且工作負載可以由多個客戶端組成。 將客戶端故障記錄到集中式日誌記錄服務（例如 IBM Cloud Logs 可以對整個工作負載進行故障和可用性分析。