通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure NetApp 文件实现电子设计自动化 (EDA) 的好处

  • 项目

创新是半导体行业的标志。 这种创新使得 Gordon Moore 1965 年提出的摩尔定律在五十多年中一直有效，即，人们可以预期处理速度大约每一两年就会翻一番。 例如，半导体行业的创新通过将芯片堆叠成更小的外形尺寸，利用并行性将性能扩展到过去难以想象的水平，促进了摩尔定律的发展。

半导体（或电子设计自动化 [EDA]）公司最感兴趣的是面市时间 (TTM)。 TTM 通常根据工作负荷（例如芯片设计验证以及要完成的流片之类的预铸造工作）所需的时间来预测。 TTM 问题还有助于降低 EDA 许可成本：花在工作上的时间更少意味着可用于许可的时间更多。 尽管如此，可供服务器场使用的带宽和容量越多越好。

Azure NetApp 文件通过高性能并行化文件系统解决方案（Azure NetApp 文件大型卷）来减少 EDA 作业所花的时间。 最近的 EDA 基准测试表明，单个大型卷的性能是以前使用单个 Azure NetApp 文件常规卷实现的性能的 20 倍。

Azure NetApp 文件大型卷功能非常适合满足这个最苛刻行业的存储需求，即：

  • 大型卷单一命名空间：每个卷在单个装入点下提供高达 500TiB 的可用容量。

  • 高 I/O 速率、低延迟：在使用 EDA 模拟基准进行的测试中，单个大型卷提供超过 650K 的存储 IOPS，且应用程序延迟低于 2 毫秒。 在典型的 EDA 工作负荷中，IOPS 由文件创建、读取、写入操作和大量其他的元数据操作混合组成。 对于许多客户来说，这个结果被认为是企业级性能。 这种性能改进是通过大型卷能够跨 Azure NetApp 文件中的存储资源并行化传入写入操作的方式实现的。 尽管许多公司要求 2 毫秒或更好的响应时间，但芯片设计工具可以容忍比这更高的延迟，而不会对业务产生影响。

  • 每秒 826,000 次操作：单个大型卷的性能优势 - 在我们的测试中，应用程序层延迟时间的峰值为 7 毫秒，这表明在单个大型卷中，只需很小的延迟成本就可以执行更多操作。

通过 EDA 基准进行的测试发现，使用单个常规 Azure NetApp 文件卷，可以在 2ms 的时候实现高达 40,000 IOPS 的工作负荷，边缘可以达到 50,000 IOPS。 请参阅下面的表格和图表，获取常规和大容量的并排概览。

场景 2 毫秒延迟时的 I/O 速率 性能边缘的 I/O 速率（~7 毫秒） 2 毫秒延迟时的 MiB/秒 性能边缘的 MiB/秒（~7 毫秒）
一个常规卷 39,601 49,502 692 866
大型卷 652,260 826,379 10,030 12,610

下图说明了测试结果。

此图表比较了大型卷和常规卷的延迟和吞吐量。

常规卷测试还探索了单一终结点限制，六卷就达到了限制。 大型卷的性能比六个常规卷的方案高出 260%。 下标说明了这些结果。

场景 2 毫秒延迟时的 I/O 速率 性能边缘的 I/O 速率（~7 毫秒） 2 毫秒延迟时的 MiB/秒 性能边缘的 MiB/秒（~7 毫秒）
六个常规卷 255,613 317,000 4,577 5,688
一个大型卷 652,260 826,379 10,030 12,610

大规模简化

大型卷不单纯是性能。 最终目标是简单的性能。 为了便于使用和便于进行应用程序管理，客户更喜欢单个命名空间/装入点，而不喜欢管理多个卷。

测试工具

此测试中的 EDA 工作负荷是使用标准行业基准工具生成的。 它模拟用于设计半导体芯片的 EDA 应用程序的混合。 EDA 工作负荷分布如下：

描绘前端 OP 类型的饼图。

EDA 前端 OP 类型 总计百分比
统计 39%
Access 15%
Random_write 15%
Write_file 10%
Random_read 8%
Read_file %7
创建 %2
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • 追加
  • Custom2
  • 锁定
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • 写入
0%

描绘后端 OP 类型分布的饼图。

EDA 后端 OP 类型 总计百分比
读取 50%
写入 50%
  • Custom2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

测试配置

结果是使用以下配置详细信息生成的：

组件 配置
操作系统 RHEL 9.3/RHEL 8.7
实例类型 D16s_v5
实例计数 10
装载选项 nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
客户端可调参数 # 网络参数。以字节为单位
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535

# 设置为 4 KiB 大小的块，以字节为单位
net.ipv4.tcp_mem = 4096 89600 4194304

# 其他网络选项和标志
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.
tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

# 各种文件系统/页面缓存选项
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# 客户端的 ONTAP 网络执行优化
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

装载选项 nocto、noatime 和 actimeo=600 协同工作，可减轻某些元数据操作对基于 NFSv3 协议的 EDA 工作负荷的影响。 这些装载选项既减少了发生的元数据操作的数量，又在客户端上缓存了一些元数据属性，使 EDA 工作负荷推进得比其他方式更远。 必须考虑各项工作负荷要求，因为这些装载选项并不普遍适用。 有关详细信息，请参阅适用于 Azure NetApp 文件的 Linux NFS 装载选项最佳做法。

总结

EDA 工作负荷需要这样的文件存储：能够处理文件数大、容量大且在潜在数千个客户端工作站中存在大量并行操作的情况。 EDA 工作负荷的性能水平还需要达到能够缩短完成测试和验证所需的时间的地步，以便节省许可证费用并缩短最新且最好的芯片组的面市时间。 Azure NetApp 文件大型卷可以满足 EDA 工作负荷的需求，其性能与本地部署中的性能相当。

后续步骤