本文件概述將應用程式部署至 CloudHub 2.0 的目前選項,以符合高可用性和災害復原需求。其使用美國地區作為範例,並可套用至其他區域。

CloudHub 2.0 是完全受管理的雲端原生整合平台,可透過在雲端中自動化 MuleSoft API 的部署、調整規模和管理,進而減少基礎結構負擔。這是 MuleSoft 的現代雲端部署平台,在 Amazon AWS 基礎結構上執行。

在大多數的情況下,CloudHub 2.0 提供的預設「高可用性」(HA) 和「災害復原」(DR) 便足夠。CloudHub 2.0 會在區域層級提供 HA 和 DR (如需詳細資料,請參閱 CloudHub 2.0 Outage Scenarios)。CloudHub 2.0 重要考量事項區段提供有關 CloudHub 2.0 支援 HA 和 DR 的詳細資料。

需要在 CloudHub 2.0 的預設可用性之外進行設計的條件包括:

• 應用程式必須確保在災害案例中沒有資料遺失 (例如,Amazon 區域中斷)。
• 應用程式取決於「物件存放區」,如果部署區域失敗,則必須確保連續性。

• 後端系統已針對相等的可用性進行設定。CloudHub 2.0 有時會透過列或類似機制提供可靠性,但無論整合是即時或非同步,後端系統都必須支援相似的 HA 和 DR 層級。
• 當 AWS 區域層級中斷影響後端系統時,系統會假設其復原會與 CloudHub 2.0 復原並行執行。
• 在多個區域中完成私人空間設定。

本指南中的設計選項著重於當整個 AWS 可用性區域或區域無法使用時,用於 CloudHub 2.0 中應用程式可用性的解決方案。

本指南並未說明這些復原情況,但會注意相關的後果:

• 還原在 Anypoint CloudHub 外部受管理和佈建的後端系統、應用程式、資料庫、網路元件和資料中心,無論是在內部部署或雲端中。
• 復原 CloudHub 2.0 與客戶私人資料中心之間的 VPN 連結 (例如,IPsec 隧道和 VPN Gateways)。本指南中的某些 DR 選項可能會部分處理這些情況。
• 當使用 IP 允許清單進行整合時,對 MuleSoft 的變更會在災害復原期間輸出 IP。本指南中的某些 DR 選項可能會部分處理這些情況。
• 客戶解決方案中使用的外部傳訊系統,無論由 MuleSoft (例如 Anypoint MQ) 或其他廠商 (例如 AWS MSK 或 Heroku Kafka) 提供。

針對 CloudHub 2.0 的 災害復原需求評估時,請考量下列重要考量事項。

CloudHub 2.0 對 AWS 區域可用性的相依性

• CloudHub 2.0 會在 AWS 上執行;其可用性與 AWS 區域相關聯。
• 部署和應用程式可用性會依區域進行組織。這些區域對應至 AWS 區域。

如果整個 AWS 區域失敗,則該區域中的應用程式將無法使用,且不會在其他位置自動複製。

應用程式高可用性 (HA) 和複本管理

• 硬體失敗時,CloudHub 2.0 會在相同區域內自動重新部署應用程式,但具有單一複本的應用程式可能會遇到停機。
• 具有多個複本的應用程式預設會跨個別的可用性區域部署,提供跨區域的 HA。
• 如果單一複本應用程式的可用性區域失敗,則應用程式會自動在相同區域內的其他可用性區域中出現。

美國東部地區的特定影響

• 在美國東部地區中斷的情況下:
  • CloudHub 2.0 管理 UI 與部署 REST 服務無法使用,且無法部署新的應用程式。
  • 在大多數失敗情況下,其他區域中的應用程式不會受到影響。這些應用程式會繼續正常運作,但在中斷期間無法使用透過控制平面的監視與管理功能。
  • 核心 CloudHub 2.0 模組 (例如應用程式設定) 會在美國東部維護,因此無法在中斷期間編輯設定。

監視與警示

• 透過 status.mulesoft.com 設定可用性區域或區域層級失敗的警示。
• 在 CloudHub 2.0 外部使用個別的健康檢查和警示機制,以便在複本失敗或應用程式停止回應時通知小組。

資料持續性 (物件存放區 V2)

• 「物件存放區 V2」會繫結至部署應用程式第一次的區域。
• 如果您將應用程式移至其他區域,則「物件存放區 V2」會保留在原始區域中,以避免資料遺失。
• 如果部署「物件存放區 V2」的區域失敗,則物件存放區無法使用。

入院控制項與私人空間

• CloudHub 2.0 的入院控制項在區域層級可供高度使用。
• 在共用空間中,如果某個區域失敗,則另一個區域中的入院控制項仍可供使用,但只能提供在該區域中部署的應用程式。
• 在私人空間中,如果某個區域失敗,除非預先設定其他區域的入院控制項,否則無法使用。
• 私人空間設定為區域設定;如果區域失敗,除非已設定其他區域,否則私人空間將無法使用。

概觀平台服務下拉式案例 – 物件商店

高可用性 (HA) 是系統在系統元件失敗時保持可存取能力的度量。一般而言,HA 會透過在系統中建立多個層級的錯誤容忍度和/或負載平衡功能來實作。這通常是「啟用中」組態,會對業務服務造成有限或無影響。

災害復原 (DR) 是將系統在災難案例後恢復至先前可接受狀態的程序,無論是自然狀態 (如洪水、捲風、地震或火災) 或人為 (例如電源故障、伺服器故障或錯誤設定)。DR 通常是「已啟用/被動」組態,會對業務服務造成一些影響。

如果需要「區域高可用性」或「區域災害復原」,以在發生 AWS 區域失敗時減少業務影響,請在 MuleSoft CloudHub 2.0 中設計您的解決方案時考量以下幾點:

• CloudHub 2.0 複本和相關功能 (私人空間、入院控制項和 Anypoint MQ 目的地) 是區域特有的。
• 如果整個 AWS 區域失敗,則該區域中的所有複本和相關服務將無法使用。
• 當區域復原時,系統會還原組態;您必須重新啟動應用程式。
• 如果美國東部區域失敗,則 Anypoint Platform 服務 (例如存取管理和執行階段管理員) 也無法使用。
• MuleSoft 為 Platform Services 提供 99.95% 的可用性 SLA,包括區域內啟用中組態中的 CloudHub 2.0 複本;請參閱最新的 MuleSoft Cloud 提供 SLA 以取得最新詳細資料。
• CloudHub 2.0 不支援立即可用的多區域 HA 或 DR;僅在單一區域內提供可用性。

無論您選擇的設定為何,都會套用這些設計指導方針。

多區域私人空間設定

下列區段中描述的所有選項都需要在個別區域中部署應用程式。這只有在災害發生前,事先完成私人空間設定時才可能。由於私人空間設定是區域性的,因此 DR 策略需要至少兩個私人空間 (每個區域一個),以及可將流量切換至適當 VPN 端點的機制。

區域內高可用性私人空間設定

當區域內的私人空間失敗時,CloudHub 2.0 不會提供自動故障切換。因應措施是跨多個環境的啟用中-被動設定,這需要:

• 在私人空間上設定多個 VPN Gateway。
• 在 CloudHub 2.0 區域中建立個別的環境,每個環境都有自己的私人空間。
• 將其中一個環境指定為被動 (當初未部署應用程式,但主要私人空間失敗時會出現應用程式)。

如果高可用性設定,但 VPN Gateway 不是單一失敗點,是硬需求,則部署至兩個區域是最佳選項。在此情況中,VPN Gateway 失敗可能會透過將受影響區域無法移至已設定私人空間的其他區域來解決。

零訊息損失

若要在整個區域失敗時達到零訊息遺失,應用程式必須防止資料遺失並解決以下問題:

• 使用外部傳訊達成訊息可靠性。
• 確保「物件存放區」未用於具有交易性質的飛行中交易資料。如果第一次部署 MuleSoft 應用程式的部署區域關閉,則「物件商店」將無法使用。
• 在「物件商店」讀取或寫入作業失敗時,將所有「物件商店」存取權封裝在單獨的流程或區段中,該流程或區段會繼續運作 (針對例外狀況處理與行為)。

備註。在大多數的情況下,DR 需求不需要確保在災難發生時會產生零訊息遺失,且需要確保資料遺失少於指定期間的資料損失 (例如 1 小時)。

保持整合無州

作為一般設計原則,務必確保整合的性質無州。這表示在各種用戶端叫用或執行之間不會共用任何交易資訊 (在已排程服務的情況下)。如果因系統限制而必須由中介軟體維護某些資料,則該資料應保留在外部存放區中,例如資料庫或傳訊排隊,而非 MuleSoft 基礎結構或記憶體中。請務必注意,當我們調整規模時 (特別是在雲端中),每個複本使用的狀態和資源應獨立於其他複本。此模型可確保更佳的效能、延展性和可靠性。

網路與流量管理

• 虛名網域對於區域可用性而言是必要的;它們會作為跨區域所有輸入控制項的全域 DNS。
• 全域負載平衡器會路由主要和 DR 區域私人空間之間的流量。客戶提供此元件;使用 AWS Route 53 或具有路由原則的全域 CDN 來跨區域路由流量。
• 使用自訂虛名網域在主要和 DR 區域中設定「入院」控制項。
• 規劃並維護防火牆規則和 VPN 管道,讓從主要和 DR 區域私人空間可存取內部部署應用程式。
• TLS 憑證維護必須涵蓋主要和 DR 區域的私人空間,以順暢復原。

應用程式部署和組態

• 應用程式名稱在整個區域中必須是唯一的。例如,CI/CD 銷售管道可以在部署前將區域名稱 (或區域代碼) 附加至應用程式名稱,以在主要和 DR 區域之間保持唯一性。
• 設定 CI/CD 管道將應用程式部署至主要與 DR 區域,讓所有應用程式皆可在這兩個區域中使用。

基礎結構與容量
當所有基礎結構層面具有相同的主要和 DR 區域容量時,效能最佳。這些基礎結構層面不同時,效能會降低。

資料持續性與儲存空間

• 兩個區域之間必須定期同步化 持續性儲存空間。客戶負責儲存空間複製;MuleSoft 不會提供。主要和 DR 區域中 VPC 之間的單一共用存放區是可能的,但共用儲存空間必須高可用性,否則這會成為兩個區域的單一失敗點。
• Object Store V2 為區域,僅適用於第一次部署 Mule 應用程式的區域。如果應用程式移至其他區域,則「物件存放區 V2」會保留在原始區域中,以避免資料遺失。針對多區域 DR 策略使用其他永久性儲存空間。

測試和作業程序

採用正式的 DR 測試策略並執行定期 DR 逐層細分。針對啟用中的 DR,請使用 canary 部署策略來驗證這兩個區域。

效能與服務等級協定 (SLA)

DR 區域可能與一般使用者或後端系統相較於主要區域,因此可能會發生部分效能降低。定義 DR SLA 並將其傳達給利害關係人。

復原模式行為 (內容備註)

在啟用中模式中,從主要區域到 DR 區域的私人空間的錯誤切換會快速:全域負載平衡器會偵測主要區域不健康,並將流量路由至健康 (DR) 區域。在啟用中被動模式中,您必須在發生災害時將應用程式部署至 DR 區域私人空間。

有 3 個選項可達成更高的 DR 層級可用性:

啟用中組態

啟用中的設定是根據跨區域散佈的啟用中工作人員,使用「外部負載平衡器」在兩個例項之間路由流量。

Warm Standby 組態
啟用中-被動設定會以一個區域的啟用中工作人員和另一個區域的被動工作人員為基礎。需要時會啟動「被動區域」。

被動區域的某些元���必須保持啟用,才能進行故障轉換或事先設定,包括私人空間、VPN 和傳輸門道附件。

冷候補組態

如上所述,複本和「入院」控制項會在失敗時透過完全自動 DevOps 程序在第二個區域中佈建。被動區域的某些元素必須保持為啟用,才能進行故障切換,包括私人空間、VPN 和「輸送管道附件」。

CloudHub 2.0 網路結構的基本元件有:

• HTTP 負載平衡程式
• 模擬複本 DNS 記錄
• 私人空間
• 區域服務

如需詳細資料,請參閱 CloudHub 2.0 網路結構。

虛名網域

建立「私人空間」時,會收到格式為 <space-id>.<region>.cloudhub.io 的 DNS 目標名稱。在該「私人空間」中部署名為 test-api 的應用程式時,其端點會遵循以下格式:

CloudHub 2.0 也支援使用 TLS 內容和 DNS 記錄在「私人空間」內設定自訂或虛名網域。若要在「私人空間」的「執行階段管理員」中建立 TLS 內容,請上載公用憑證和私人金鑰,然後在應用程式設定中新增自訂端點以使用該網域。建立 DNS 記錄 (例如 CNAME),將您的虛名網域指向您私人空間的預設主機名稱。

例如,在 us-west-2 中部署的名為 test-api 應用程式,其預設 DNS 42y52r.usa-w2.cloudhub.io 的 API 端點為:

https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io

此 URL 不使用虛名或自訂網域。若要使用 acme.com 讓 API URL 顯示為 https://test-api.acme.com,請遵循以下步驟。

1. 使用公用和私人金鑰在執行階段管理員中建立 TLS 內容。
2. 在應用程式的設定中新增虛名網域,以使用該網域。
3. 在 AWS Route 53 中建立 DNS 記錄,並設定簡單的路由原則 (例如 CNAME),讓虛名網域解析為私人空間的預設主機名稱。

針對自訂網域,您可以透過路由原則使用 AWS Route 53 或任何其他全域 CDN 服務。在下圖中,AWS Route 53 會與「簡單」路由原則搭配使用。當公用 (外部) 網路中的取用者要求 acme.com 時,AWS 路由 53 會將要求路由至 MuleSoft 私人空間進入控制項。

當應用程式需要故障切換時,請使用此選項:在主要區域 (例如,us-west-2) 中部署一個例項,並在次要區域 (例如,us-east-1) 中部署另一個例項。

盡可能在次要區域中使用現有環境;建立新環境需要額外的精力。

部署在一個區域 (美國西部 2) 且失敗移至另一個區域 (美國東部 1) 的應用程式範例

在此組態中,AWS 路線 53 會將流量路由至美國西部 2 與美國東部 1 的私人空間進入控制項。使用健康檢查設定故障轉換路由原則。

如需縮短延遲與高可用性,請使用圖表中所述的部署策略。透過此策略,可在兩個區域部署應用程式 (此範例中為 us-west-2 與 us-east-1)。

使用 AWS Route 53 中的延遲路由原則,將要求路由至提供最低延遲的區域,同時保留高可用性。 AWS Route 53 中的「延遲」路由原則,可將要求路由至較低延遲仍具有高可用性的區域。

在這兩個區域部署的應用程式 (美國西部 2 與美國東部 1) 以降低延遲和高可用性

MuleSoft CloudHub 2.0 為區域內彈性提供穩固的基礎,主要運用自動複本冗餘和智慧型負載平衡。在單一雲端區域內,使用多個複本部署應用程式可確保如果一個例項失敗,則其他例項可以立即接管工作量。整合型負載平衡程式可有效地將傳入流量分配至這些健康的複本,以儘量縮短停機時間並確保在正常營運條件下能夠持續提供服務。

不過,僅依賴此單一區域結構,即使是高冗餘的結構,也會造成廣泛的災難性區域中斷風險。歷程記錄已顯示,即使是最可靠且在技術上最先進的雲端提供者也容易受到影響整個地理區域的中斷事件。這些單一失敗點雖然罕見,但可能來自於各種事件,包括:

• 大規模的基礎結構事件
• 主要電源失敗
• 廣泛的網路中斷

因此,若要達成真正的高可用性 (HA) 和災害復原 (DR),則必須設計結構以超越單一區域模型的限制。建議的策略是跨多個地理不同區域部署。此區域間彈性可確保如果整個雲端區域因非預期的災害而無法使用,流量便可順暢地移轉至在個別且不受影響區域中執行的應用程式例項,以保證服務中斷最小並達到最大執行時間目標。

CloudHub 2.0 網路結構

設定跨區域錯誤轉換的標準列

物件存放區 V2 部署區域

您的物件商店部署區域

Gulal Kumar 是 Salesforce 的「軟體工程結構設計師」,專注於資料與整合結構。他在整合和 API、現代化計畫、安全性和 AIML 計畫方面擁有超過 20 年的經驗,提供豐富的專業知識。Gulal 一直致力於推進業務轉型計畫、增強安全性和彈性、促進傑出結構,並領導跨各種網域的 AIML 計畫。

Ajay Nagaraju 是 MuleSoft 的企業結構設計師和高級總監,在企業結構、系統整合和大規模數位轉型方面擁有超過 28 年的經驗。他負責跨財富 100 和財富 500 組織的複雜多百萬美元計畫架構和交付,並擁有 API 驅動連線、SOA、雲端技術和企業整合模式的深度專業知識。Ajay 已與執行領導階層密切合作,以現代化業務流程、資料平台和整合生態系統,並致力於建立可調整的結構、指導小組,並透過技術推動可測量的業務成果。