Nitro 系统性能调整注意事项
Nitro 系统是由 Amazon 打造的硬件和软件组件集合，可实现高性能、高可用性和高安全性。Nitro System 提供类似裸机的功能，从而消除了所有虚拟化开销并支持需要完全访问主机硬件的工作负载。有关更多详细信息，请参阅 Amazon Nitro System
所有最新一代 EC2 实例类型都在 EC2 Nitro 卡上执行网络数据包处理。本主题涵盖 Nitro 卡上的高级数据包处理、影响数据包处理性能的网络架构和配置的常见方面，以及您可以采取哪些措施来实现基于 Nitro 的实例的峰值性能。
Nitro 卡可处理所有输入和输出（I/O）接口，例如虚拟私有云（VPC）所需的接口。对于通过网络发送或接收信息的所有组件，Nitro 卡可充当 I/O 流量的独立计算设备，在物理上与运行客户工作负载的系统主板分开。
Nitro 卡上的网络数据包流
基于 Nitro System 构建的 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 Traffic Control 之类的网络调度程序来帮助调整吞吐量，避免因微爆导致数据包排队或被丢弃。
- 流数
-
单个流限制在 5Gbps 以内，除非它位于支持高达 10Gbps 的集群置放群组内，或者它使用支持高达 25Gbps 的 ENA Express。
同样，Nitro 卡可以跨多个流处理更多数据包，而不是使用单个流。为了实现每个实例的峰值数据包处理速率，我们建议在聚合带宽为 100 Gbps 或更高的实例上至少有 100 个流。随着聚合带宽容量的增加，实现峰值处理速率所需的流数也随之增加。基准测试将帮助您确定在网络上实现峰值速率所需的配置。
- 弹性网络适配器（ENA）队列
-
ENA（弹性网络适配器）使用多个接收（Rx）和传输（Tx）队列（统称为 ENA 队列），来提高 EC2 实例上的网络性能和可扩展性。这些队列通过跨可用队列进行收发数据的负载均衡，从而有效地管理网络流量。
有关更多信息，请参阅 ENA 队列数。
- 功能处理开销
-
流量镜像和 ENA Express 等功能可能会增加更多的处理开销，从而降低绝对数据包处理性能。您可以限制功能使用或禁用功能以提高数据包处理速率。
- 连接跟踪以保持状态
-
您的安全组使用连接跟踪来存储有关进出实例的流量的信息。连接跟踪对网络流量每个单独的流应用规则，以确定是允许还是拒绝该流量。Nitro 卡使用流跟踪来维护流状态。随着安全组规则的应用越来越多，评估流程需要做更多工作。
注意
并非所有网络流量都会被跟踪。如果安全组规则配置了 未跟踪的连接，则除了在有多个有效回复路径时自动跟踪连接以确保对称路由之外，无需进行其他工作。
不使用硬件加速的数据包
并非所有数据包都能利用硬件加速。处理这些例外情况会涉及一些处理开销，这是确保网络流正常运行所必需的。网络流必须可靠地满足协议标准，符合 VPC 设计的变化，并且仅将数据包路由到允许的目标。但是，开销会降低您的性能。
- 数据包片段
-
如应用程序注意事项下所述，由超过网络 MTU 的数据包生成的数据包片段通常作为例外情况处理，无法利用硬件加速。但是，您可以使用片段代理模式绕过出口片段限制，具体取决于您的驱动程序版本。有关更多信息，请参阅 最大限度地提高 Nitro 系统的网络性能 部分中所列的具体操作。
- 空闲连接
-
当连接在一段时间内没有活动时，即使该连接尚未达到其超时限制，系统也可以取消其优先级。然后，如果数据是在取消连接优先级后进入的，则系统需要将其作为例外情况处理才能重新连接。
要管理连接，您可以使用连接跟踪超时来关闭空闲连接。您也可以使用 TCP keepalive 使空闲连接保持打开状态。有关更多信息，请参阅 空闲连接跟踪超时。
- VPC 突变
-
安全组、路由表和访问控制列表的更新都需要在处理路径中进行重新评估，以确保路由条目和安全组规则仍然按预期适用。
- ICMP 流
-
互联网控制信息协议 (ICMP) 是网络设备用来诊断网络通信问题的网络层协议。这些数据包始终使用完整流。
- 非对称 L2 流量
-
对于同一子网中的两个 ENI，如果其中一个 ENI 使用默认网关路由器，而另一个不使用默认网关路由器，则 Nitrov3 和更早版本的平台不会为两者之间的流量使用硬件加速，而 Nitrov4 及更高版本的平台会为此情况使用硬件加速。为确保在 Nitrov3 或更早版本的平台上获得更好的性能，请确保这两个 ENI 之间使用的默认网关路由器一致，或者确保这两个 ENI 位于不同的子网中。
最大限度地提高 Nitro 系统的网络性能
您可以通过调整网络设置来提高 Nitro 系统上的网络性能。
注意事项
在您做出任何设计决策或调整实例上的任何网络设置之前，建议您采取以下步骤来帮助确保获得最佳结果：
-
通过回顾 Nitro 系统的网络设计注意事项，了解为提高性能可以采取的措施的利弊。
有关 Linux 上实例配置的更多注意事项和最佳实践，请参阅 GitHub 上的 ENA Linux Driver Best Practices and Performance Optimization Guide
。 -
使用峰值活跃流计数对您的工作负载进行基准测试，以确定应用程序性能的基准。使用性能基准，您可以测试设置或应用程序设计中的变体，以了解哪些注意事项的影响最大，尤其是在您计划纵向扩展或横向扩展时。
调整 PPS 性能
以下列表包含您可以根据系统需求调整 PPS 性能的措施。
-
缩短两个实例之间的物理距离。当发送和接收实例位于同一个可用区或使用集群置放群组时，您可以减少数据包从一个端点传输到另一个端点所需的跃点数。
-
使用 未跟踪的连接。
-
对网络流量使用 UDP 协议。
-
对于聚合带宽为 100Gbps 或更高的 EC2 实例，请将工作负载分配到 100 个或更多的单个流中，以将工作均匀分布到 Nitro 卡上。
-
要消除 EC2 实例的出口片段 PPS 限制，您可以启用片段代理模式（取决于驱动程序版本）。此设置允许在处理路径中评估分段的数据包，从而消除 1024 的出口 PPS 限制。加载驱动程序时，请运行以下命令之一以启用或禁用片段代理模式：
启用片段代理模式
sudo insmod ena.ko enable_frag_bypass=1禁用片段代理模式
sudo insmod ena.ko enable_frag_bypass=0
监控 Linux 实例的性能
您可以在 Linux 实例上使用 Ethtool 指标，监控带宽、数据包速率和连接跟踪等实例网络性能指标。有关更多信息，请参阅 监控 EC2 实例上 ENA 设置的网络性能。
ENA 队列数
ENA 队列分配给网络接口，其默认静态限制取决于实例类型和大小。在受支持的实例类型上，您可以跨弹性网络接口（ENI）动态分配这些队列。虽然每个实例的队列总数取决于其类型和大小，但可以使用 ENA 队列配置多个 ENI，直到满足 ENI 和实例的最大队列数为止。
灵活分配 ENA 队列有助于优化资源分配，从而尽可能提高 vCPU 利用率。需要高网络性能的工作负载通常需要使用多个 ENA 队列。您可以根据特定的工作负载调整微调队列数，从而微调网络性能和每秒数据包数（PPS）。例如，网络密集型应用程序需要使用的队列数可能会多于 CPU 密集型应用程序。
支持的实例
以下实例支持动态分配多个 ENA 队列。
-
通用型：M6i、M6id、M6idn、M6in
-
计算优化型：C6i、C6id、C6in
-
内存优化型：R6i、R6in
您可以使用以下命令来验证实例是否支持动态分配 ENA 队列。
aws ec2 describe-instance-types --filters Name=network-info.flexible-ena-queues-support,Values=supported
Amazon EC2 裸机实例不支持灵活 ENA 队列功能。
ENA 队列可用性
可用 ENA 队列的数量取决于实例类型和大小。使用以下命令之一检查可用队列数。
aws ec2 describe-instance-types --filters "Name=network-info.flexible-ena-queues-support,Values=supported" --query "InstanceTypes[*].[InstanceType,NetworkInfo.NetworkCards[*].DefaultEnaQueueCountPerInterface,NetworkInfo.NetworkCards[*].MaximumEnaQueueCount,NetworkInfo.NetworkCards[*].MaximumEnaQueueCountPerInterface]" --output json
您可以查看 DefaultEnaQueueCountPerInterface、MaximumEnaQueueCountPerInterface 以及实例上所有 ENI 的可用 MaximumEnaQueueCount。
修改队列数
您可以使用 Amazon Web Services Management Console或 Amazon CLI 修改 ENA 队列数。在 Amazon Web Services Management Console中，ENA 队列配置位于每个网络接口的设置下。
要使用 Amazon CLI 修改 ENA 队列数，请使用以下任一命令。在修改队列数之前，请使用以下命令检查您当前的队列数。
aws ec2 describe-instances --instance-id i-1234567890abcdef0
注意
-
必须停止实例后才能修改 ENA 队列数。
-
ENA 队列的值必须是 2 的乘方，例如 1、2、4、8、16、32 等。
-
分配给任何单个 ENI 的队列数不能超过实例上可用的 vCPU 数。
以下示例在一个 ENI 上配置了 32 个 ENA 队列。
aws ec2 attach-network-interface \ --network-interface-id eni-001aa1bb223cdd4e4\ --instance-idi-1234567890abcdef0\ --device-index 1 \ --ena-queue-count 32
以下示例有 3 个 ENI，每个均配置了 2 个 ENA 队列。
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
以下示例将 ENA 数重置为默认值。
aws ec2 modify-network-interface-attribute \ --network-interface-id eni-1234567890abcdef0\ --attachment AttachmentId=eni-attach-12345678,DefaultEnaQueueCount=true