邊緣的彈性 - AWS 方案指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

邊緣的彈性

可靠性支柱包含工作負載在預期情況下正確且一致地執行其預期功能的能力。這包括在整個工作負載生命週期中操作和測試工作負載的能力。在此意義上,當您在邊緣設計彈性架構時,您必須先考慮要使用哪些基礎設施來部署該架構。使用 AWS Local Zones 和 實作三種可能的組合 AWS Outposts:Outpost 到 OutpostOutpost 到 Local ZoneLocal Zone 到 Local Zone,如下圖所示。雖然彈性架構還有其他可能性,例如將 AWS 邊緣服務與傳統的現場部署基礎設施或 結合 AWS 區域,但本指南著重於這三種適用於混合式雲端服務設計的組合

使用 Local Zones 和 Outposts 在邊緣實作彈性。

基礎架構考量因素

在 AWS,服務設計的核心原則之一是避免基礎實體基礎設施中的單點故障。由於此原則, AWS 軟體和系統使用多個可用區域,並對單一區域的故障具有彈性。在邊緣, AWS 提供以 Local Zones 和 Outposts 為基礎的基礎設施。因此,確保基礎設施設計彈性的關鍵因素是定義應用程式資源的部署位置。

本機區域

Local Zones 的作用類似於其內的可用區域 AWS 區域,因為它們可以選取為區域 AWS 資源的置放位置,例如子網路和 EC2 執行個體。不過,它們不位於目前 AWS 區域 不存在的 AWS 區域,但接近大型人口、工業和 IT 中心。儘管如此,它們仍會保留本機區域中本機工作負載與 中執行工作負載之間的高頻寬、安全連線 AWS 區域。因此,您應該使用 Local Zones 來部署更接近使用者的工作負載,以滿足低延遲需求。

Outpost

AWS Outposts 是一種全受管服務,可將 AWS 基礎設施、 AWS 服務、APIs 和工具擴展到您的資料中心。用於 的相同硬體基礎設施 AWS 雲端 會安裝在您的資料中心。然後 Outpost 會連接到最近的 AWS 區域。您可以使用 Outposts 來支援低延遲或本機資料處理需求的工作負載。

父可用區域

每個 Local Zone 或 Outpost 都有一個父區域 (也稱為主區域)。父區域是 AWS 節點基礎設施 (Outpost 或 Local Zone) 的控制平面錨定位置。如果是 Local Zones,父區域是 Local Zone 的基本架構元件,客戶無法修改。 會將 AWS Outposts 延伸 AWS 雲端 到您的內部部署環境,因此您必須在訂購程序期間選取特定區域和可用區域。此選擇會將 Outposts 部署的控制平面錨定至所選的 AWS 基礎設施。

當您在邊緣開發高可用性架構時,這些基礎設施的父區域,例如 Outpost 或 Local Zones,必須相同,以便在它們之間延伸 VPC。此延伸 VPC 是建立這些高可用性架構的基礎。當您定義高彈性架構時,這就是為什麼您必須驗證服務將錨定 (或已錨定) 的父區域和可用區域。如下圖所示,如果您想要在兩個 Outpost 之間部署高可用性解決方案,您必須選擇兩個不同的可用區域來錨定 Outpost。這允許從控制平面角度進行異地同步備份架構。如果您想要部署包含一或多個 Local Zones 的高可用性解決方案,您必須先驗證基礎設施錨定所在的父可用區域。為此,請使用下列 AWS CLI 命令:

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

上一個命令的輸出:

{ "AvailabilityZones": [ { "State": "available", "OptInStatus": "opted-in", "Messages": [], "RegionName": "us-east-1", "ZoneName": "us-east-1-mia-1a", "ZoneId": "use1-mia1-az1", "GroupName": "us-east-1-mia-1", "NetworkBorderGroup": "us-east-1-mia-1", "ZoneType": "local-zone", "ParentZoneName": "us-east-1d", "ParentZoneId": "use1-az2" } ] }

在此範例中,邁阿密本地區域 (us-east-1d-mia-1a1) 會錨定在us-east-1d-az2 可用區域中。因此,如果您需要在邊緣建立彈性架構,您必須確保次要基礎設施 (Outpost 或 Local Zones) 錨定至 以外的可用區域us-east-1d-az2例如, us-east-1d-az1是有效的。

下圖提供高可用性邊緣基礎設施的範例。

高度可用的邊緣架構。

網路考量事項

本節討論在邊緣聯網的初始考量,主要用於存取邊緣基礎設施的連線。它會檢閱為服務連結提供彈性網路的有效架構。

Local Zones 的彈性聯網

本機區域透過多個備援、安全、高速的連結連接到父區域,可讓您順暢地使用任何區域服務,例如 Amazon S3 和 Amazon RDS。您有責任提供從現場部署環境或使用者到 Local Zone 的連線。無論您選擇何種連線架構 (例如 VPN 或 AWS Direct Connect),都必須透過網路連結達到的延遲必須相等,以避免主要連結發生故障時對應用程式效能造成任何影響。如果您使用的是 AWS Direct Connect,則適用的彈性架構與存取 的架構相同 AWS 區域,如AWS Direct Connect 彈性建議中所述。不過,有些案例主要適用於國際本地區域。在啟用 Local Zone 的國家/地區中,只有一個 AWS Direct Connect PoP 就無法建立建議 AWS Direct Connect 用於恢復能力的架構。如果您只能存取單一 AWS Direct Connect 位置,或需要單一連線以外的彈性,您可以在 Amazon EC2 上建立 VPN 設備 AWS Direct Connect,如 AWS 部落格文章所述和討論啟用從現場部署到 的高可用性連線 AWS Local Zones

Outposts 的彈性聯網

與 Local Zones 不同,Outposts 具有備援連線,可從您的本機網路存取 Outposts 中部署的工作負載。此備援是透過兩個 Outposts 網路裝置 (ONDs) 達成。每個 OND 至少需要兩個與本機網路的 1 Gbps、10 Gbps、40 Gbps 或 100 Gbps 的光纖連線。這些連線必須設定為連結彙總群組 (LAG),以允許可擴展性新增更多連結。

上行鏈路速度

上行鏈路數目

1 Gbps

1、2、4、6 或 8

10 Gbps

1、2、4、8、12 或 16

40 或 100 Gbps

1、2 或 4

Outposts 的彈性聯網

如需此連線的詳細資訊,請參閱 AWS Outposts 文件中的 Outposts 機架的本機網路連線

為了獲得最佳體驗和彈性, AWS建議您使用至少 500 Mbps (1 Gbps 更好) 的備援連線來連接 的服務連結 AWS 區域。您可以使用 AWS Direct Connect 或 服務連結的網際網路連線。此最小值可讓您啟動 EC2 執行個體、連接 EBS 磁碟區和存取 AWS 服務,例如 Amazon EKS、Amazon EMR 和 CloudWatch 指標。

下圖說明高可用私有連線的此架構。

高可用私有連線的彈性架構。

下圖說明此架構的高可用性公有連線。

高可用公有連線的彈性架構。

使用 ACE 機架擴展 Outposts 機架部署

彙總、核心、邊緣 (ACE) 機架是 AWS Outposts 多機架部署的關鍵彙總點,主要建議用於超過三個機架的安裝或規劃未來擴展。每個 ACE 機架都有四個路由器,支援 10 Gbps、40 Gbps 和 100 Gbps 連線 (100 Gbps 為最佳)。每個機架最多可以連接到四個上游客戶裝置,以實現最大備援。ACE 機架會耗用高達 10 kVA 的功率,且重量高達 705 磅。主要優點包括降低實體聯網需求、減少光纖纜線上行連結,以及減少 VLAN 虛擬介面。 透過 VPN 通道的遙測資料 AWS 監控這些機架,並在安裝期間與客戶緊密合作,以確保適當的電源可用性、網路組態和最佳配置。隨著部署的擴展,ACE 機架架構提供更高的價值,並有效簡化連線,同時降低大型安裝的複雜性和實體連接埠需求。 如需詳細資訊,請參閱 AWS 部落格文章使用 ACE AWS Outposts 機架擴展機架部署

跨 Outpost 和本機區域分發執行個體

Outpost 和 Local Zones 的運算伺服器數量有限。如果您的應用程式部署多個相關執行個體,這些執行個體可能會在相同伺服器或相同機架的伺服器上部署,除非設定不同。除了預設選項之外,您還可以跨伺服器分配執行個體,以降低在相同基礎設施上執行相關執行個體的風險。您也可以使用分割區置放群組,將執行個體分散到多個機架。這稱為分散機架分佈模型。使用自動分佈將執行個體分散到群組中的分割區,或將執行個體部署到選取的目標分割區。透過將執行個體部署到目標分割區,您可以將選取的資源部署到相同的機架,同時將其他資源分散到機架。Outposts 也提供另一個稱為分散主機的選項,可讓您在主機層級分配工作負載。下圖顯示分散機架和分散主機分佈選項。

Outposts 和 Local Zones 的分散機架和分散主機分佈選項。

中的 Amazon RDS 多可用區 AWS Outposts

當您在 Outposts 上使用異地同步備份執行個體部署時,Amazon RDS 會跨兩個 Outposts 建立兩個資料庫執行個體。每個 Outpost 都會在自己的實體基礎設施上執行,並連線到區域中的不同可用區域,以獲得高可用性。當兩個 Outpost 透過客戶管理的本機連線連線時,Amazon RDS 會管理主要和待命資料庫執行個體之間的同步複寫。如果發生軟體或基礎設施故障,Amazon RDS 會自動將待命執行個體提升為主要角色,並更新 DNS 記錄以指向新的主要執行個體。若為異地同步備份部署,Amazon RDS 會在一個 Outpost上建立主要資料庫執行個體,並將資料同步複製至不同 Outpost 上的備用資料庫執行個體。Outposts 上的異地同步備份部署的運作方式與 中的異地同步備份部署類似 AWS 區域,但有以下差異:

異地同步備份部署適用於所有支援的 MySQL 和 PostgreSQL on Amazon RDS on Outposts 版本。異地同步備份部署不支援本機備份。

下圖顯示 Amazon RDS on Outposts 異地同步備份組態的架構。

Amazon RDS on Outposts 的異地同步備份組態。

容錯移轉機制

負載平衡和自動擴展

Elastic Load Balancing (ELB) 會自動將傳入的應用程式流量分配到您正在執行的所有 EC2 執行個體。ELB 透過最佳路由流量來協助管理傳入請求,讓單一執行個體不會不堪負荷。若要搭配 Amazon EC2 Auto Scaling 群組使用 ELB,請將負載平衡器連接至 Auto Scaling 群組。這樣會將群組註冊到負載平衡器,該負載平衡器會作為 群組所有 Web 流量的單一聯絡點。當您搭配 Auto Scaling 群組使用 ELB 時,不需要向負載平衡器註冊個別 EC2 執行個體。由 Auto Scaling 群組啟動的執行個體會自動註冊到負載平衡器。同樣地,由 Auto Scaling 群組終止的執行個體會自動從負載平衡器取消註冊。將負載平衡器連接到 Auto Scaling 群組之後,您可以將群組設定為使用 ELB 指標 (例如每個目標的 Application Load Balancer 請求計數),以隨著需求波動擴展群組中的執行個體數量。或者,您可以將 ELB 運作狀態檢查新增至 Auto Scaling 群組,以便 Amazon EC2 Auto Scaling 可以根據這些運作狀態檢查來識別和取代運作狀態不佳的執行個體。您也可以建立 Amazon CloudWatch 警示,在目標群組的運作狀態良好的主機計數低於允許的主機計數時通知您。

下圖說明 Application Load Balancer 如何在 中管理 Amazon EC2 上的工作負載 AWS Outposts。

Outposts 中 Amazon EC2 工作負載的負載平衡。

下圖說明 Amazon EC2 在 Local Zones 中的類似架構。

Local Zones 中 Amazon EC2 工作負載的負載平衡。
注意

Application Load Balancer 可在 AWS Outposts 和 Local Zones 中使用。不過,若要在 中使用 Application Load Balancer AWS Outposts,您需要調整 Amazon EC2 容量的大小,以提供負載平衡器所需的可擴展性。如需在 中調整負載平衡器大小的詳細資訊 AWS Outposts,請參閱 AWS 部落格文章在 上設定 Application Load Balancer AWS Outposts

DNS 容錯移轉的 Amazon Route 53

當您有一個以上的資源執行相同的函數時,例如多個 HTTP 或郵件伺服器,您可以設定 Amazon Route 53 來檢查資源的運作狀態,並僅使用運作狀態良好的資源來回應 DNS 查詢。例如,假設您的網站 example.com託管在兩個伺服器上。一個伺服器位於 Local Zone,另一個伺服器位於 Outpost。您可以設定 Route 53 來檢查這些伺服器的運作狀態,並example.com僅使用目前運作狀態良好的伺服器來回應 的 DNS 查詢。如果您使用別名記錄將流量路由到選取的 AWS 資源,例如 ELB 負載平衡器,您可以設定 Route 53 來評估資源的運作狀態,並僅將流量路由到運作狀態良好的資源。當您設定別名記錄來評估資源的運作狀態時,您不需要為該資源建立運作狀態檢查。

下圖說明 Route 53 容錯移轉機制。

Outposts 和 Local Zones 的 Route 53 容錯移轉機制。
備註
  • 如果您要在私有託管區域中建立容錯移轉記錄,您可以建立 CloudWatch 指標、將警示與指標建立關聯,然後建立以警示資料串流為基礎的運作狀態檢查。

  • 若要 AWS Outposts 使用 Application Load Balancer 在 中公開存取應用程式,請設定聯網組態,讓目的地網路位址轉譯 (DNAT) 從公有 IPs 到負載平衡器的完整網域名稱 (FQDN),並建立 Route 53 容錯移轉規則,其中包含指向公開公有 IP 的運作狀態檢查。此組合可確保對 Outposts 託管應用程式的可靠公開存取。

Amazon Route 53 Resolver 上的 AWS Outposts

Amazon Route 53 Resolver Outposts 機架上提供 。它直接從 Outposts 為您的內部部署服務和應用程式提供本機 DNS 解析。Local Route 53 Resolver 端點也啟用 Outposts 與內部部署 DNS 伺服器之間的 DNS 解析。Route 53 Resolver on Outposts 有助於改善現場部署應用程式的可用性和效能。

Outposts 的典型使用案例之一是部署需要低延遲存取內部部署系統的應用程式,例如工廠設備、高頻率交易應用程式和醫療診斷系統。

當您選擇在 Outpost 上使用本機 Route 53 解析程式時,應用程式和服務將繼續受益於本機 DNS 解析,以探索其他服務,即使與父系的連線 AWS 區域 中斷。本機解析程式也有助於降低 DNS 解析的延遲,因為查詢結果會從 Outposts 快取並在本機提供,這樣可消除對父系不必要的往返 AWS 區域。Outposts VPCs 中使用私有 DNS 的應用程式的所有 DNS 解析都會在本機提供。

除了啟用本機解析程式之外,此啟動也會啟用本機解析程式端點。Route 53 Resolver 傳出端點可讓 Route 53 Resolvers 將 DNS 查詢轉送至您管理的 DNS 解析程式,例如,在內部部署網路上。相反地,Route 53 Resolver 傳入端點會將從 VPC 外部收到的 DNS 查詢轉送至在 Outposts 上執行的 Resolver。它可讓您從該 VPC 外部,針對部署在私有 Outposts VPC 上的服務傳送 DNS 查詢。如需傳入和傳出端點的詳細資訊,請參閱 Route 53 文件中的解決 VPCs 與網路之間的 DNS 查詢