介绍

之前，我分享了我对 ESXi 主机上 NIC 负载平衡的某些问题的经验，以及如何使用 ESXCLI 解决这些问题。一直有同事问我几种负载均衡有什么区别，哪种更好用。因此，现在我将分享我对基础架构级别的网络环境负载平衡概念的看法。

对于初学者，让我们回顾一下负载平衡的全部内容。好吧，首先，您不想将负载平衡网络流量与平衡工作负载以获得最佳性能混淆（这就是 DRS（分布式资源调度程序）的作用）。VMware 的载波聚合技术可以将两个或多个 NIC 组合成一个数据通道，以增加 vSphere 虚拟交换机或一组端口的带宽，从而增强该通道的可靠性。通过配置故障转移程序，您可以选择在其中一个 NIC 出现故障时如何准确地重定向流量。通过配置负载均衡策略，您可以决定 vSwitch 如何准确地对 NIC 之间的流量进行负载均衡。

结论很简单。这是一种将物理接口组合成逻辑接口的技术。尽管聚合允许增加通道带宽，但您不应该真正指望聚合通道中所有接口之间的完美负载平衡。简而言之，负载平衡使您能够将流量从虚拟机分配到 vSwitch 再到 pNIC。无论是 vSwitch、pNIC 还是一组 vNIC，都有几种主要的负载均衡流量方式：

• 基于始发端口 ID 的路由
• 基于 IP 哈希的路由
• 基于源 MAC 哈希的路由
• 基于物理 NIC 负载的路由
• 使用明确的故障转移顺序

基于始发端口 ID 的路由

基于交换机上虚拟端口 ID 的负载平衡选项。此方法是标准和分布式 vSwitch 的默认选择。它根据 vSwitch 上的虚拟端口号选择一个上行链路端口。一个 vNIC 一次只能使用一个 pNIC。

此模式按照下一个算法工作。主机中的每个虚拟机在 vSwitch 上都有自己的标识符。为了给虚拟机分配一个上行链路端口，vSwitch 在一个网卡或一组网卡上使用类似的端口标识符。分配上行链路端口后，只要该虚拟机在该交换机上工作，vSwitch 就会通过同一上行链路端口为该虚拟机分配流量。

虚拟交换机只分配一次上行端口，虚拟机的端口标识是固定的，所以如果vSwitch分配不同的一组端口给虚拟机，它会生成一个新的上行端口。

现在，如果您要迁移、关闭或删除虚拟机，vSwitch 上的端口标识符将再次可用。此外，vSwitch 停止向此端口发送流量，这反过来又会降低分配给与其连接的上行链路端口的总体流量。但是，如果虚拟机打开或转移，它可能会出现在另一个端口上并开始使用另一个上行端口。

如果组中的所有 pNIC 都处于活动状态，它们会为虚拟机分配流量。

让我们看看，如果您关闭 VM 2 和 VM 5，然后按以下顺序打开 VM 8、VM 9、VM 2 和 VM 5，您会看到端口组 1 和端口组 2 上的端口标识符没有不会失去与 pNIC 上行链路端口的连接。反过来，VM 8 和 VM 9 连接到之前由 VM 2 和 VM 5 使用的上行链路端口。

优点：

• 简单的物理交换机配置。上行链路绑定 (EtherChannel) 不是必需的。只有交换机的独立端口需要配置；
• 如果vNIC数量超过pNIC数量，则支持平均分配；
• 物理 NIC 冗余。即使所有 pNIC 都处于活动状态，当一个 pNIC 出现故障时，团队中的其他 pNIC 会继续平衡流量；
• 可以在多个物理交换机之间平衡物理 NIC 组流量，以防止硬件故障；
• 这种负载平衡类型可以使用称为信标探测的网络故障转移检测机制；
• 在具有多个虚拟机的环境中，负载在所有活动网卡之间进行平衡以提高性能。

缺点：

• 一个 vNIC 不能使用来自多个 pNIC 的带宽。例如，如果一组中有四个 pNIC，每个 1 Gb/s，则具有一个 vNIC 的虚拟机不能通过一个 pNIC 使用超过 1Gb/s 的带宽；
• 当需要在多个 pNIC 之间负载平衡一个虚拟机（具有一个 vNIC）的流量时，对于处理来自不同客户端的大量请求的虚拟服务器来说，这不是一个合适的选择；
• 这种机制不会让您使用 802.3ad 信道聚合技术。此外，您可能还无法访问 IP 存储（iSCSI、NFS），因为 VMkernel 也可以仅使用一个 pNIC 来处理不同的 iSCSI 目标。

基于 IP 哈希的路由

这种负载平衡方法是通过在源 IP 地址和目标 IP 数据包之间创建哈希（固定大小的值）来平衡流量。这样，一个虚拟机和多个客户端之间的流量（包括通过路由器的流量）可以使用不同的 vmNIC 进行平衡。为此，您需要在连接到 ESX Server 的物理交换机上打开 802.3ad 支持。因此，此负载平衡选项是最有效和最复杂的算法。尽管如此，它也可能对服务器造成最大的负载，因为它在那里计算每个 IP 数据包的 IP 地址哈希值。IP地址哈希是基于异或算法计算的，公式如下：
((LSB (SrcIP) xor LSB (DestIP)) mod (# pNICs)
负载平衡的公平性取决于主机和不同客户端之间的 TCP/IP 会话数量，也取决于 pNIC。对于大量连接，此选项允许更平等地平衡流量，并且没有基于 ID 端口的选项固有的缺点。

如果主机连接到多个交换机，此方法要求您将物理交换机的所有端口聚合到一个堆栈 (EtherChannel) 中。如果物理交换机不支持这种工作模式，就无法使用这种负载均衡算法。这通常意味着您必须将 vSwitch 中的所有 pNIC 连接到一个物理交换机。

请记住：如果您真的必须将所有 pNIC 连接到一个物理交换机，当它发生故障时，它背后的所有系统也会发生故障。

在应用 IP 哈希作为负载平衡算法时，您需要在 vSwitch 上执行配置，而不必在端口组级别覆盖它。换句话说，所有连接到具有 IP 哈希负载平衡的 vSwitch 的设备都应该使用 IP 哈希负载平衡。

要最大限度地利用 IP 哈希负载平衡，您将需要一个具有很多目的地的源，或者您冒着遇到两个或更多请求而不是平衡的请求将尝试加载同一个 pNIC 的情况。

假设有一个 VM 使用来自 2 个 SAN 的 iSCSI 连接磁盘。如果这 2 个 SAN 具有可以使用相同模块值计算的 IP 地址（查看选项卡），则所有流量将加载一个 pNIC，这反过来又将使用 IP 哈希负载平衡的效率降至最低。

优点：

在 VM 与多个 VM 通信的情况下提高性能。理论上，虚拟机可以使用比 pNIC 支持的带宽更大的带宽；
物理 NIC 冗余：在 pNIC 或上行链路故障的情况下，组中剩余的 NIC 将继续平衡流量。ESXi 主机和物理交换机必须将通道识别为非活动状态，以便上行链路能够正常工作。如果存在任何不一致，流量将无法切换到组中的其他 pNIC。

缺点：

物理交换机配置不太灵活，需要为 EtherChannel 静态连接配置交换机的端口。您只能为 pNIC 组使用一个交换机，因为大多数交换机不支持多个物理交换机之间的 EtherChannel。

请注意。当然，也有例外。特定堆栈或模块交换机实际上可以在多个交换机或模块上执行此操作。Cisco vPC（Virtual Port Channel）也可以解决这个问题，前提是交换机支持这项技术。与供应商交谈以获取更多信息。

此负载平衡选项不支持 Beacon 探测。作为检测错误的工具，您只能使用上行链路端口故障通知。

基于源 MAC 哈希的路由

现在，此场景建议 vSwitch 根据 VM 的 MAC 地址为 VM 选择上行链路端口。为了计算 VM 的上行链路端口，vSwitch 根据 vSwitch 中活动 pNIC 数量的模块应用源 MAC 地址（vNIC MAC 地址）的 LSB（最低有效位）以接收 pNIC 阵列中的地址。

例如，让我们以以下具有 2 个 pNIC 的场景为例。假设 vNIC 的 MAC 地址为 00:15:5D:99:96:0B，则 LSB 等于 0x0B 或十进制的 11。在模运算中，您将（使用整数除法）LSB MAC 拆分为 pNIC 的数量 (11 / 3)，然后选择余数（在本例中为 2）作为运算的模数。物理网卡阵列是从0开始的，也就是说0=pNIC 1, 1=pNIC 2, 2=pNIC 3。

如果我们看一下具有 6 个具有一致 MAC 地址的虚拟机的场景（至少，LSB 是一致的），我们将在以下情况下结束：

优点：

与基于原始端口 ID 的路由相比，或多或少等于负载平衡，因为 vSwitch 为每个数据包计算一个上行链路端口；
所有 VM 使用相同的上行链路端口，因为 MAC 地址是静态的。打开和关闭虚拟机不会影响其上行链路端口分配；
无需更改物理交换机。

缺点：

连接到相应端口标识符的上行链路端口的速度定义了虚拟机可用的带宽，除非 VM 使用多个具有不同 MAC 地址的 vNIC；
比路由消耗资源更高，这可以通过 vSwitch 为每个数据包计算上行链路端口这一事实来解释；
虚拟交换机不监控上行链路端口的当前负载，这就是它们可能变得过载的原因。

基于物理 NIC 负载的路由

此负载均衡方法仅适用于分布式交换机。大多数情况下，它提醒我们的第一个选项，即基于源端口 ID 的路由。但是，也有差异，它们足够重要。首先，在选择哪个 pNIC 来平衡流量时，选择不是随机的，而是根据此 pNIC 上的负载来定义的。此外，选择频率为 30 秒（在其他 vSwitch 选项中，一旦您为 pNIC 选择了端口标识符，它将保持这种状态直到 VM 启动）。如果负载超过 75%，则 I/O 操作值最高的 VM 端口标识符切换到另一个 pNIC 的另一个上行端口。

简单来说，这个算法基本上根本不使用负载均衡，不管听起来多么讽刺。它看起来像一个故障转移场景，并为所有流量使用活动 pNIC 列表中最可用的上行链路端口。

优点：

资源消耗低，因为分布式交换机只为虚拟机计算一次上行链路端口，检查上行链路对它的影响最小；
分布式交换机正在监控上行链路端口负载并尽可能降低负载；
无需更改物理交换机。

缺点：

连接到相应 Distributed Switch 的上行链路端口定义了虚拟机可用的带宽。

使用明确的故障转移顺序

现在，这可能令人惊讶。该策略使实际的负载平衡几乎不可能。问题是，vSwitch 始终使用可用活动 NIC 列表中最高的上行链路端口。如果您无法使用列表中的第一个上行链路端口，则可以使用列表中的第二个，依此类推。故障转移顺序参数定义上行链路端口。此参数定义 vSwitch 的活动/备用 pNIC 模式。

结论

通常，每个负载平衡策略都有其优点和缺点。选择什么选项取决于您需要做什么。如果您在这些方面没有经验，我强烈建议您从基于原始端口 ID 的方法开始，这是默认选项。此外，随着对流程的更多了解，您可以切换到最适合您的方式。