Nitro 系統效能調校的考量因素 - Amazon Elastic Compute Cloud
Nitro 卡上的網路封包流程透過網路設計達到最佳效能最大化 Nitro 系統的網路效能

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

Nitro 系統效能調校的考量因素

Nitro System 是由 建置的硬體和軟體元件集合 AWS ，可實現高效能、高可用性和高度安全性。Nitro 系統提供的類裸機功能可免除虛擬化開銷，並支援需完整存取主機硬體的工作負載。如需更多詳細資訊，請參閱 AWS Nitro 系統。

所有目前世代的 EC2 執行個體類型都會對 EC2 Nitro 卡進行網路封包處理。本主題涵蓋 Nitro 卡上的高階封包處理、影響封包處理效能的網路架構和組態的常見層面，以及達到 Nitro 型執行個體峰值效能所需採取的動作。

Nitro 卡會處理所有輸入和輸出 (I/O) 介面，例如虛擬私有雲端 (VPCs) 所需的介面。對於透過網路傳送或接收資訊的所有元件，Nitro 卡可做為 I/O 流量的獨立運算裝置，與客戶工作負載所執行的系統主機板在物理上是分開的。

Nitro 卡上的網路封包流程

在 Nitro 系統上建置的 EC2 執行個體具有硬體加速功能，可更快速地進行封包處理，其輸送量是以每秒封包數 (PPS) 的指標進行測量。當 Nitro 卡執行新流程的初始評估時，該卡會儲存流程中全部封包所具有的相同資訊，例如安全群組、存取控制清單和路由表項目。處理相同流程的其他封包時，可以使用儲存的資訊來減少這些封包的負荷。

您的連線速率是以每秒連線數 (CPS) 的指標進行測量。每個新連線都將產生額外的處理負荷，這些額外處理開銷必須納入工作負載能力預估。設計工作負載時，同時考慮 CPS 和 PPS 指標是至關重要的。

如何建立連線

當 Nitro 型執行個體與另一個端點之間建立連線時，Nitro 卡會評估兩個端點之間傳送或接收的第一個封包的完整流程。相同流程的後續封包通常不需要完整重新評估。不過，此規則也有例外狀況。如需例外狀況的詳細資訊，請參閱 不使用硬體加速的封包。

下列屬性將定義兩個端點和兩端之間的封包流程。這五個屬性合稱為 5 元組流程。

  • 來源 IP

  • 來源連接埠

  • 目標 IP

  • 目標連接埠

  • 通訊協定

封包流程的方向稱為「傳入」和「傳出」。以下是端對端網路封包流程的高階概述。

  • 「傳入」 – 當 Nitro 卡處理傳入網路封包時，會根據具狀態防火牆規則和存取控制清單來評估封包。該卡會追蹤連線、進行計量，並執行其他適用的動作。然後，該卡會將封包轉送到主機 CPU 上的目的地。

  • 「輸出」 – 當 Nitro 卡處理傳出網路封包時，會查詢遠端介面目的地、評估各種 VPC 函數、套用速率限制，以及執行其他適用的動作。然後，該卡會將封包轉送到網路中的下一個中轉目的地。

透過網路設計達到最佳效能

若要發揮 Nitro 系統的效能，您必須了解網路處理的需求，以及這些需求如何影響 Nitro 資源的工作負載。然後，您就可以透過設計，讓網路環境達到最佳效能。您的基礎架構設定、應用程式工作負載設計及其組態，都可能會影響封包處理和連線速率。例如，如果您的應用程式有較高的連線建立率，例如 DNS 服務、防火牆或虛擬路由器，其利用連線建立後才能加速硬體的機會就較低。

您透過應用程式和基礎架構設定，來簡化工作負載並改善網路效能。不過，並非所有封包都符合加速資格。Nitro 系統會針對新連線以及不符合加速資格的封包使用完整的網路流程。

本節的其餘部分將著重於應用程式和基礎設施設計考量因素，以協助確保封包盡可能在加速路徑內流動。

Nitro 系統的網路設計考量因素

為執行個體設定網路流量時，需要考量的層面非常廣，這些層面都可能對 PPS 效能造成影響。建立流程後，大多數定期傳入或傳出的封包都符合加速資格。不過，此規則也有例外狀況，這些例外的目的是確保基礎架構設計和封包流程持續符合通訊協定標準。

若要獲得 Nitro 卡的最佳效能，您應該仔細考量基礎架構和應用程式的下列組態，及其詳細資訊與優缺點。

基礎架構考量因素

您的基礎架構組態可能會影響封包流程和處理效率。要考慮的重要因素包含下列項目：

非對稱的網路介面組態

安全群組使用連線追蹤，以追蹤流入和流出執行個體流量的資訊。非對稱路由，也就是當流量透過一個網路介面進入執行個體，並透過不同的網路介面離開，可能導致執行個體在追蹤流程時，可達的峰值效能降低。如需安全群組連線追蹤、未追蹤的連線和自動追蹤連線的詳細資訊，請參閱 Amazon EC2 安全群組連線追蹤。

網路驅動程式

網路驅動程式會定期更新和釋出。過時的驅動程式可能會大幅降低效能。請將驅動程式保持於最新狀態，以確保您獲得最新的修補程式，並充分發揮效能改善功能，例如，加速路徑功能僅適用於最新一代的驅動程式。舊版驅動程式不支援加速路徑功能。

若要利用加速路徑功能，建議您在執行個體上安裝最新的 ENA 驅動程式。

Linux 執行個體 – ENA Linux 驅動程式 2.2.9 或更新版本。若要從 Amazon Drivers GitHub 儲存庫安裝或更新 ENA Linux 驅動程式，請參閱讀我檔案的驅動程式編譯一節。

Windows 執行個體 – ENA Windows 驅動程式 2.0.0 或更新版本。若要安裝或更新 ENA Windows 驅動程式，請參閱 在 EC2 Windows 執行個體上安裝 ENA 驅動程式。

端點之間的距離

由於應用程式層的 TCP 時段調整，相比於跨區域連線，在同一可用區域中的兩個執行個體之間連線，每秒可以處理更多的封包，這決定了在任意給定時間可傳輸的資料量。執行個體之間若距離較長，則延遲將增加，端點可處理的封包數量也將隨之減少。

位元組佇列限制 (BQL)

BQL 是一種功能，可限制傳遞至 Nitro 卡的位元組數，以減少佇列。在 ENA 驅動程式、Amazon Linux 作業系統和大多數 Linux 發行版本中，BQL 預設為停用。如果同時啟用 BQL 和片段代理覆寫，在處理所有片段之前限制傳遞給 Nitro 的位元組數，可能會導致效能限制。

應用程式設計考量因素

應用程式設計和組態有幾個層面，可能會對您的處理效率造成影響。要考慮的重要因素包含下列項目：

封包大小

若封包大小較大，則執行個體可在網路上傳送和接收的資料輸送量會增加。Amazon EC2 支援 9001 位元組的巨型訊框，但其他服務可能會強制執行不同的限制。若封包較小，則可提高封包處理速率，但當封包數量超過 PPS 額度時，可能造成可達到的最大頻寬降低。

如果封包的大小超過網絡跳轉的最大傳輸單位 (MTU)，路徑上的路由器可能會將其分段。產生的封包片段會被視為例外狀況，通常以標準速率處理 （非加速）。這可能會導致效能發生變化。不過，您可以使用片段代理模式設定覆寫傳出分段封包的標準行為。如需詳細資訊，請參閱最大化 Nitro 系統的網路效能。建議您在設定 MTU 時評估您的拓撲。

通訊協定權衡

TCP 等可靠的通訊協定比 UDP 等不可靠的通訊協定具有更高的額外負荷。UDP 傳輸通訊協定具有較低額外負荷，以及簡化的網路處理，可能會產生更高的 PPS 速率，但封包交付的可靠性將遭到犧牲。如果封包交付的可靠性對您的應用程式來說並非關鍵，則 UDP 可能是不錯的選擇。

微爆量

當流量短時間內超過限額，而不是平均分佈時，就會發生微爆量。這通常會以微秒為單位進行。

例如，假設您的執行個體最多可以傳送 10Gbps，而您的應用程式卻在半秒內傳送整整 10Gb。此微爆量在前半秒便已超過額度，導致剩餘的秒內沒有任何剩餘額度。即使您在 1 秒內傳送 10Gb，前半秒的額度可能會導致封包排入佇列或遭到捨棄。

您可以使用 Linux 流量控制等網路排程器來協助調整輸送量，並避免因微量爆量而造成佇列或捨棄封包。

流程數量

單一流程限制為 5Gbps，除非其位於支援高達 10Gbps 的叢集置放群組內，或者使用支援高達 25Gbps 的 ENA Express。

同樣地，Nitro 卡可以處理多個流程的更多封包，而非使用單一流程。為了達到每個執行個體的尖峰封包處理速率，我們建議在總頻寬為 100Gbps 或更高的執行個體上至少 100 個流程。隨著彙總頻寬的增加，達到峰值處理速率所需的流程數量也會增加。基準測試將協助您判斷在網路上達到尖峰速率所需的組態。

彈性網路轉接器 (ENA) 佇列

ENA （彈性網路轉接器） 使用多個接收 (Rx) 和傳輸 (Tx) 佇列 (ENA 佇列） 來改善 EC2 執行個體的網路效能和可擴展性。這些佇列透過負載平衡跨可用佇列傳送和接收的資料，有效率地管理網路流量。

如需詳細資訊，請參閱ENA 佇列。

特徵處理負荷

流量鏡射和 ENA Express 等功能可能導致處理負荷增加，進而降低絕對封包處理效能。您可以限制功能使用，或停用功能，以提高封包處理速率。

保持狀態的連線追蹤

您的安全群組使用連線追蹤來儲存流入和流出執行個體流量的資訊。連線追蹤會將規則套用至每個個別的網路流量流程，以判斷流量被允許還是被拒絕。Nitro 卡會使用流程追蹤來維持流程的狀態。套用的安全群組規則更多，評估流程便需要更多工作。

注意

並非所有的網路流量流程都會追蹤。如果使用 未追蹤的連線 設定安全群組規則，則在有多個有效的回覆路徑時，除了自動追蹤連線以確保對稱路由之外，不需要額外的工作。

不使用硬體加速的封包

並非所有封包都可以利用硬體加速。處理這些例外狀況時，通常需要一些處理負荷，以確保網路流程的運作狀態。網路流程必須可靠地符合通訊協定標準、符合 VPC 設計中的變更，以及僅將封包路由至允許的目的地。不過，額外負荷將導致您的效能降低。

「封包片段」

如應用程式考量所述，超過網路 MTU 之封包所產生的封包片段通常視為例外處理，無法利用硬體加速。不過，視您的驅動程式版本而定，您可以使用片段代理模式略過輸出片段限制。如需詳細資訊，請參閱 最大化 Nitro 系統的網路效能區段中您可以採取的動作。

「閒置連線」

當連線有一段時間沒有活動時，即使連線尚未達到逾時限制，系統也可以取消其優先順序。然後，如果資料在取消優先順序之後傳入，系統需要將其視為例外處理才能重新連線。

若要管理您的連線，您可以使用連線追蹤逾時來關閉閒置連線。您也可以使用 TCP 保持連線，讓閒置連線保持開啟。如需詳細資訊，請參閱閒置連線追蹤逾時。

VPC 變動

安全群組、路由表和存取控制清單的更新，皆需要在處理路徑中重新評估，以確保路由項目和安全群組規則的套用仍符合預期。

ICMP 流程

網路控制訊息通訊協定 (ICMP) 是一個網路層通訊協定，可供網路裝置診斷網路通訊問題。這些封包一律使用完整流程。

非對稱 L2 流程

NitroV3 和較舊的平台不會針對相同子網路中兩個 ENIs 之間的流量使用硬體加速，其中一個 ENI 使用預設閘道路由器，另一個則不使用。在此案例中，NitroV4 和更新版本平台會使用硬體加速。為了在 NitroV3 或更早的平台上獲得更好的效能，請確保兩個 ENIs 之間使用的預設閘道路由器相符，或這些 ENIs 位於不同的子網路中。

最大化 Nitro 系統的網路效能

您可以透過調整網路設定，在 Nitro 系統上最大化網路效能。

考量事項

在您做出任何設計決策，或調整執行個體上的任何網路設定之前，建議您採取下列步驟，以協助確保您獲得最佳結果：

  1. 了解您可以藉由檢閱 Nitro 系統的網路設計考量因素 來改善效能之動作的優缺點。

    如需 Linux 執行個體組態的更多考量和最佳實務，請參閱 GitHub 上的 ENA Linux 驅動程式最佳實務和效能最佳化指南。

  2. 以峰值活動流量計數作為工作負載的基準，以確定應用程式效能的基準。透過效能基準，您可以在設定或應用程式設計中測試變化，以了解哪些考量因素將產生最大影響，特別是如果您計劃向上擴展或橫向擴充。

調校 PPS 效能

下列清單包含您可以根據系統需求調整 PPS 效能的動作。

  • 減少兩個執行個體之間的實體距離。若傳送和接收執行個體位於相同的可用區域，或使用叢集置放群組時，您可以減少封包從一個端點移動到另一個端點所需的跳轉次數。

  • 請使用 未追蹤的連線。

  • 針對網路流量使用 UDP 通訊協定。

  • 對於彙總頻寬為 100Gbps 或更高的 EC2 執行個體，請將工作負載分散到 100 個以上的個別流程，以將工作平均分散到 Nitro 卡。

  • 若要克服 EC2 執行個體上的輸出片段 PPS 限制，您可以啟用片段代理模式 （取決於您的驅動程式版本）。此設定允許在處理路徑中評估分段封包，藉此克服輸出 PPS 限制 1024。載入驅動程式時，請執行下列其中一個命令來啟用或停用片段代理模式：

    啟用片段代理模式

    sudo insmod ena.ko enable_frag_bypass=1

    停用片段代理模式

    sudo insmod ena.ko enable_frag_bypass=0

監控 Linux 執行個體的效能

您可以在 Linux 執行個體上使用 Ethtool 指標，以監控執行個體聯網效能指標，例如頻寬、封包速率和連線追蹤。如需詳細資訊，請參閱監控 EC2 執行個體的 ENA 設定網路效能。

ENA 佇列

ENA 佇列會根據執行個體類型和大小，配置到具有預設靜態限制的網路介面。在支援的執行個體類型上，您可以在彈性網路界面 (ENIs) 之間動態配置這些佇列。雖然每個執行個體的總佇列計數取決於其類型和大小，但您可以使用 ENA ENIs 佇列設定多個 ENI，直到您符合 ENI 和執行個體的最大佇列計數為止。

彈性 ENA 佇列配置可最佳化資源分佈，實現最大 vCPU 使用率。高效能網路工作負載通常需要多個 ENA 佇列。您可以根據您的特定工作負載需求調整佇列計數，以微調網路效能和每秒封包數 (PPS)。例如，相較於 CPU 密集型應用程式，網路密集型應用程式可能需要更多佇列。

支援的執行個體

下列執行個體支援動態配置多個 ENA 佇列。

一般用途
執行個體類型 每個界面的預設 ENA 佇列 每個界面的 ENA 佇列上限 每個執行個體的 ENA 佇列上限
M6i
m6i.large 2 2 6
m6i.xlarge 4 4 16
m6i.2xlarge 8 8 32
m6i.4xlarge 8 16 64
m6i.8xlarge 8 32 64
m6i.12xlarge 8 32 64
m6i.16xlarge 8 32 120
m6i.24xlarge 8 32 120
m6i.32xlarge 8 32 120
M6id
m6id.large 2 2 6
m6id.xlarge 4 4 16
m6id.2xlarge 8 8 32
m6id.4xlarge 8 16 64
m6id.8xlarge 8 32 64
m6id.12xlarge 8 32 64
m6id.16xlarge 8 32 120
m6id.24xlarge 8 32 120
m6id.32xlarge 8 32 120
M6idn
m6idn.large 2 2 6
m6idn.xlarge 4 4 16
m6idn.2xlarge 8 8 32
m6idn.4xlarge 8 16 64
m6idn.8xlarge 16 32 128
m6idn.12xlarge 16 32 128
m6idn.16xlarge 16 32 240
m6idn.24xlarge 32 32 480
m6idn.32xlarge 32 32 256
M6in
m6in.large 2 2 6
m6in.xlarge 4 4 16
m6in.2xlarge 8 8 32
m6in.4xlarge 8 16 64
m6in.8xlarge 16 32 128
m6in.12xlarge 16 32 128
m6in.16xlarge 16 32 240
m6in.24xlarge 32 32 480
m6in.32xlarge 32 32 256
運算最佳化
執行個體類型 每個界面的預設 ENA 佇列 每個界面的 ENA 佇列上限 每個執行個體的 ENA 佇列上限
C6i
c6i.large 2 2 6
c6i.xlarge 4 4 16
c6i.2xlarge 8 8 32
c6i.4xlarge 8 16 64
c6i.8xlarge 8 32 64
c6i.12xlarge 8 32 64
c6i.16xlarge 8 32 120
c6i.24xlarge 8 32 120
c6i.32xlarge 8 32 120
C6id
c6id.large 2 2 6
c6id.xlarge 4 4 16
c6id.2xlarge 8 8 32
c6id.4xlarge 8 16 64
c6id.8xlarge 8 32 64
c6id.12xlarge 8 32 64
c6id.16xlarge 8 32 120
c6id.24xlarge 8 32 120
c6id.32xlarge 8 32 120
C6in
c6in.large 2 2 6
c6in.xlarge 4 4 16
c6in.2xlarge 8 8 32
c6in.4xlarge 8 16 64
c6in.8xlarge 16 32 128
c6in.12xlarge 16 32 128
c6in.16xlarge 16 32 240
c6in.24xlarge 32 32 480
c6in.32xlarge 32 32 256
C8gn
c8gn.medium 1 1 2
c8gn.large 2 2 6
c8gn.xlarge 4 4 16
c8gn.2xlarge 8 8 32
c8gn.4xlarge 8 16 64
c8gn.8xlarge 8 32 128
c8gn.12xlarge 16 64 192
c8gn.16xlarge 16 64 256
c8gn.24xlarge 16 128 384
c8gn.48xlarge 32 128 384
記憶體最佳化
執行個體類型 每個界面的預設 ENA 佇列 每個界面的 ENA 佇列上限 每個執行個體的 ENA 佇列上限
R6i
r6i.large 2 2 6
r6i.xlarge 4 4 16
r6i.2xlarge 8 8 32
r6i.4xlarge 8 16 64
r6i.8xlarge 8 32 64
r6i.12xlarge 8 32 64
r6i.16xlarge 8 32 120
r6i.24xlarge 8 32 120
r6i.32xlarge 8 32 120
R6idn
r6idn.large 2 2 6
r6idn.xlarge 4 4 16
r6idn.2xlarge 8 8 32
r6idn.4xlarge 8 16 64
r6idn.8xlarge 16 32 128
r6idn.12xlarge 16 32 128
r6idn.16xlarge 16 32 240
r6idn.24xlarge 32 32 480
r6idn.32xlarge 32 32 256
R6in
r6in.large 2 2 6
r6in.xlarge 4 4 16
r6in.2xlarge 8 8 32
r6in.4xlarge 8 16 64
r6in.8xlarge 16 32 128
r6in.12xlarge 16 32 128
r6in.16xlarge 16 32 240
r6in.24xlarge 32 32 480
r6in.32xlarge 32 32 256
R6id
r6id.large 2 2 6
r6id.xlarge 4 4 16
r6id.2xlarge 8 8 32
r6id.4xlarge 8 16 64
r6id.8xlarge 8 32 64
r6id.12xlarge 8 32 64
r6id.16xlarge 8 32 120
r6id.24xlarge 8 32 120
r6id.32xlarge 8 32 120

修改佇列數量

您可以使用 AWS Management Console 或 修改 ENA 佇列的數量 AWS CLI。在 中 AWS Management Console，每個網路介面設定下都可使用 ENA 佇列組態。

若要使用 修改 ENA 佇列數量 AWS CLI，請使用下列其中一個命令。在修改佇列計數之前，請使用下列命令來檢查您目前的佇列計數。

aws ec2 describe-instances --instance-id i-1234567890abcdef0
注意

  • 您必須先停止執行個體，才能修改 ENA 佇列的數量。

  • ENA 佇列的值必須為 2 的功率，例如 1、2、4、8、16、32 等。

  • 配置給任何單一 ENI 的佇列數目不能超過執行個體上可用的 vCPUs 數目。

attach-network-interface

在下列範例中，在 ENI 上設定了 32 個 ENA 佇列。

aws ec2 attach-network-interface \
  --network-interface-id eni-001aa1bb223cdd4e4 \
  --instance-id i-1234567890abcdef0 \
  --device-index 1 \
  --ena-queue-count 32

run-instances

在下列範例中，分別在 3 個 ENIs 佇列。

aws ec2 run-instances \
  --image-id ami-12ab3c30 \
  --instance-type c6i.large \
  --min-count 1 \
  --max-count 1 \
  --network-interfaces \
    "[{\"DeviceIndex\":0,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2},
      {\"DeviceIndex\":1,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2},
      {\"DeviceIndex\":2,\"SubnetId\":\"subnet-123456789012a345a\",\"EnaQueueCount\":2}]"

modify-network-interface-attribute

在下列範例中，在 ENI 上設定了 32 個 ENA 佇列。

aws ec2 modify-network-interface-attribute \
--network-interface-id eni-1234567890abcdef0 \
--attachment AttachmentId=eni-attach-12345678,EnaQueueCount=32

在下列範例中，EMA 計數會重設為預設值。

aws ec2 modify-network-interface-attribute \
--network-interface-id eni-1234567890abcdef0 \
--attachment AttachmentId=eni-attach-12345678,DefaultEnaQueueCount=true