性能考虑因素

本页面提供了有关配置 Google Cloud Managed Lustre 环境以获得最佳性能的指南。

如需查看每个性能层级的具体性能数据，请参阅 性能层级。

容量增加后的性能

增加现有实例的存储容量会提高其最大吞吐量和 IOPS，并可能提高其元数据性能。

随着新数据写入并重新分布到额外的存储空间，读取吞吐量性能会逐渐提高。写入吞吐量性能会立即提高。

高容量利用率

当实例的存储容量利用率达到 90% 时，实例的性能可能会降低。请考虑 增加 Managed Lustre 实例的容量。 您可能需要 在扩容之前申请额外的配额 。

如果您看到 No space left on device 错误，但实例显示 剩余容量，请参阅 No space left on device 错误。

VPC 网络最大传输单元 (MTU)

创建 VPC 网络时，将 mtu (最大传输单元，即可在此网络上传输的最大 IP 数据包的大小) 的值设置为允许的最大值 8896 后，性能可提高多达 10%（与默认值 1460 字节相比）。

您可以使用以下命令查看网络的当前 MTU 值：

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

网络的 MTU 值可以在创建网络后更新，但有一些重要的注意事项。如需了解详情，请参阅 更改网络的 MTU。

Compute Engine 机器类型

网络吞吐量可能会受到您选择的机器类型的影响。一般来说，如需获得最佳吞吐量，请执行以下操作：

  • 增加 vCPU 的数量。每个实例的最大出站流量带宽通常为 2 Gbps，最高可达机器类型的上限。
  • 选择支持更高入站和出站流量限制的机器系列。例如，使用 Tier_1 网络的 C2 实例支持高达 100 Gbps 的出站流量带宽。使用 Tier_1 网络的 C3 实例支持高达 200 Gbps 的出站流量带宽。
  • 使用更大的机器 类型来启用每个虚拟机的 Tier_1 网络性能。
  • 使用 Google 虚拟 NIC (gVNIC)。 gVNIC 是第 3 代及更新机器类型的唯一选择。使用 Tier_1 网络时，必须使用 gVNIC。

如需了解详情，请参阅网络带宽。

多 NIC 配置

借助 Lustre 的内置多轨功能，客户端可以跨多个网络接口卡（多 NIC）条带化网络流量。这样可以聚合带宽，以饱和高容量 Managed Lustre 实例。

如需配置多 NIC，您必须：

  • 选择具有多个物理 NIC 的机器类型。
  • 为每个 NIC 创建一个子网，并将每个 NIC 分配给其子网。
  • 从 Compute Engine或 GKE进行连接时，请按照多 NIC 步骤操作。

验证流量平衡

配置多 NIC 后，请验证数据是否正确平衡。

Compute Engine

通过在生成到 Managed Lustre 后端的流量时使用 nload 监控配置的网络接口（例如 eth0 和 eth1），直接在虚拟机上验证数据平衡：

nload -m eth0 eth1

在成功的多 NIC 配置中，所有已配置接口的出站比特率应大致相等。

GKE

通过将临时网络调试器 Pod 部署到工作负载计划到的节点，确认工作负载的网络流量在多个 NIC 之间平衡：

  1. 确定工作负载计划到的节点：

    kubectl get pod POD_NAME -o wide

    将 POD_NAME 替换为 Pod 的名称。在命令输出中，记下 NODE 列中的名称。

  2. 在该节点上启动网络调试器：

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    将 NODE_NAME 替换为上一步中的节点名称。

  3. 在输出中，分析 eth0 和 eth1 的出站 列比特率。如果配置成功，则比特率大致相等。输出类似于以下内容：

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. 按 Ctrl+C 退出调试器。

排查常见瓶颈问题

如果工作负载性能明显低于 Managed Lustre 性能层级的预期性能，请检查以下常见问题：

  • 客户端机器数量不足 ：单个客户端机器会受到其自身虚拟 CPU (vCPU) 和单链路网络处理限制的制约。如需饱和高吞吐量层级，您必须分配负载。例如，如需饱和 100,000 MBps 的 Managed Lustre 文件系统，您通常需要至少 60 台标准客户端机器（或 12 台配置为使用 Tier 1 高带宽网络的客户端机器）并行写入。对于任何性能层级的最大实例大小，您可能需要 2,500 多台配置为使用 Tier 1 高带宽网络的客户端机器。

  • 非理想的虚拟私有云 (VPC) MTU ：默认情况下，VPC 网络使用 MTU 1460（标准以太网帧）。对于 Managed Lustre 等高性能存储，您必须配置 MTU 为 8896 的巨型帧。使用标准 1460 MTU 运行会强制 CPU 处理的网络数据包数量超过两倍，从而增加 CPU 开销并限制最大带宽。

  • 缺少 Tier 1 网络带宽配置 ：许多高性能机器类型要求您明确选择使用 Tier 1 网络带宽。

    • 在 Compute Engine 和 GKE Standard 节点池上，在创建期间使用 --network-performance-configs=total-egress-bandwidth-tier=TIER_1 标志。如果没有此标志，虚拟机或节点可能会受到较低的默认出站流量限制。
    • 在 GKE Autopilot 上，您不会直接指定此标志。而是使用 Pod 规范中的节点选择器选择支持更高带宽（例如 c3）的机器系列。

    如需了解详情，请参阅 Compute Engine 机器类型。

  • Lustre 对象存储目标 (OST) 使用不平衡 ：Managed Lustre 会将文件数据拆分到多个对象存储目标 (OST) 中。如果您的测试或工作负载写入单个未条带化的文件，或者客户端任务写入的模式使单个 OST 过载，则该 OST 会成为瓶颈，而文件系统的其余部分则处于闲置状态。为避免这种情况，请确保在所有可用的 OST 之间均匀平衡写入载荷（例如，在基准测试中使用每个进程一个文件的模式）。

  • 共享网络带宽争用 ：客户端机器（Compute Engine 虚拟机或 GKE 节点）上的出站流量带宽在机器上的所有网络操作之间共享。如果您的客户端机器或 Pod 同时下载大型软件包、运行繁重的日志清理或与其他集群节点进行大量通信，则存储性能将受到剩余网络带宽的限制。