你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
创新是半导体行业的标志。 这种创新使得 Gordon Moore 1965 年提出的摩尔定律在五十多年中一直有效，即，人们可以预期处理速度大约每一两年就会翻一番。 例如，半导体行业的创新通过将芯片堆叠成更小的外形尺寸，利用并行性将性能扩展到过去难以想象的水平，促进了摩尔定律的发展。
半导体（或电子设计自动化 [EDA]）公司最感兴趣的是面市时间 (TTM)。 TTM 通常根据工作负荷（例如芯片设计验证以及要完成的流片之类的预铸造工作）所需的时间来预测。 TTM 问题还有助于降低 EDA 许可成本：工作花费的时间更少意味着许可证可用的时间更多。 尽管如此，可供服务器场使用的带宽和容量越多越好。
Azure NetApp 文件通过高性能并行化文件系统解决方案（Azure NetApp 文件大型卷）来减少 EDA 作业所花的时间。 最近的 EDA 基准测试显示，单个大型卷的性能比以前使用单个 Azure NetApp 文件常规卷可实现的性能高出 19 倍。 此外，当添加了多个大型卷且并置设置中有足够的计算和存储资源可以使用时，体系结构可以实现无缝缩放。
Azure NetApp 文件大型卷功能非常适合满足这个最苛刻行业的存储需求，即：
大型卷单一命名空间：每个卷在单个装入点下提供高达 1 PiB 的可用容量。 可以请求一个 2 PiB 的大型卷。
高 I/O 速率、低延迟： 在使用 EDA 模拟基准进行测试时，单个大型卷通过 740K 存储 IOPS 交付，且应用程序延迟不足 2 毫秒。 在典型的 EDA 工作负荷中，IOPS 由文件创建、读取、写入以及大量其他元数据操作组成。 对于许多客户来说，这个结果被认为是企业级性能。 这种性能改进是通过大型卷能够跨 Azure NetApp 文件中的存储资源并行化传入写入操作的方式实现的。 尽管许多公司需要 2 毫秒或更好的响应时间，但芯片设计工具可以容忍比这更高的延迟，而不会影响业务。
每秒 792,046 次操作： 单个大型卷的性能优势——在我们的测试中，应用程序层的延迟峰值为2.4毫秒，这表明在单个大型卷中可以进行更多的操作，尽管延迟稍微增加。
通过 EDA 基准进行的测试发现，使用单个常规 Azure NetApp 文件卷，可以在 2ms 的时候实现高达 40,000 IOPS 的工作负荷，边缘可以达到 50,000 IOPS。 请参阅以下表格和图表，获取常规卷和一个大型卷配置的并排概览。
| 场景 | 2 毫秒延迟时的 I/O 速率 | 性能边缘的 I/O 速率（约 3 毫秒） | 2 毫秒延迟时的 MiB/秒 | 性能边缘的 MiB/秒（~7 毫秒） |
|---|---|---|---|---|
| 一个常规卷 | 39,601 | 49,502 | 692 | 866 |
| 一个大型卷 | 742,541 | 742,541 | 11,699 | 12,480 |
下图说明了测试结果。
单个大型卷的性能比 6 个常规卷的方案高出 249%。 与单个大型卷相比，使用六个大型卷时，性能缩放是线性的。 下表和图表演示了六个常规卷、一个大卷和六个大型卷的结果：
| 场景 | 2 毫秒延迟时的 I/O 速率 | 性能边缘的 I/O 速率（~7 毫秒） | 2 毫秒延迟时的 MiB/秒 | 性能边缘的 MiB/秒（~7 毫秒） |
|---|---|---|---|---|
| 六个常规卷 | 255,613 | 317,000 | 4,577 | 5,688 |
| 一个大型卷 | 742,541 | 742,541 | 11,699 | 12,480 |
| 六个大卷 | 4,435,382 | 4,745,453 | 69,892 | 74,694 |
大规模简化
大型卷不单纯是性能。 最终目标是简单的性能。
无缝缩放
结果表明，Azure NetApp 文件服务为吞吐量和操作/秒提供了水平可伸缩性。 每个大型卷部署一个专用存储终结点，使性能能够线性缩放，而不会降低延迟。
| 指标 | 大容量 | 大体积规模 | 因子 |
|---|---|---|---|
| 吞吐量（MB/秒） | 12,780 | 76 487 | 5.98 |
| 操作/秒 | 792,046 | 4,745,453 | 5.99 |
测试工具
此测试中的 EDA 工作负荷是使用标准行业基准工具生成的。 它模拟用于设计半导体芯片的 EDA 应用程序的混合。 EDA 工作负荷分布如下：
| EDA 前端 OP 类型 | 总计百分比 |
|---|---|
| 统计 | 39% |
| 访问 | 15% |
| Random_write | 15% |
| Write_file | 10% |
| Random_read | 8% |
| Read_file | %7 |
| 创建 | 2% |
| Chmod | 1% |
| Mkdir | 1% |
| Ulink | 1% |
| Ulink2 | 1% |
|
0% |
| EDA 后端 OP 类型 | 总计百分比 |
|---|---|
| 读取 | 50% |
| 写入 | 50% |
|
0% |
测试配置
结果是使用以下配置详细信息生成的：
| 组件 | 配置 |
|---|---|
| 操作系统 | Red Hat Enterprise Linux |
| 实例类型 | D16s_v5/D32s_v5 |
| 实例计数 | 10 |
| 装载选项 | nocto，actimeo=600， hard， rsize=262144， wsize=262144， vers=3， tcp， noatime， nconnect=8 |
| 客户端可调参数 |
# 网络参数。以字节为单位 |
装载选项 nocto、noatime 和 actimeo=600 协同工作，可减轻某些元数据操作对基于 NFSv3 协议的 EDA 工作负荷的影响。 这些装载选项既减少了发生的元数据操作的数量，又在客户端上缓存了一些元数据属性，使 EDA 工作负荷推进得比其他方式更远。 必须考虑各项工作负荷要求，因为这些装载选项并不普遍适用。 有关详细信息，请参阅适用于 Azure NetApp 文件的 Linux NFS 装载选项最佳做法。
对于六个大型卷的测试，在跨四个 Azure 区域的六个 Azure 可用性区域中复制了同一配置。 每个区域都以相同方式配置了十台虚拟机和一个大型卷，每一个都并置于一个可用性区域内。 Azure 的虚拟网络对等互连连接了跨地区/区域的虚拟网络，因此我们可以执行同时跨所有客户端的单个基准运行。
摘要
EDA 工作负荷需要这样的文件存储：能够处理文件数大、容量大且在潜在数千个客户端工作站中存在大量并行操作的情况。 EDA 工作负载还需要高效执行，以减少测试和验证的完成时间，从而节省许可证费用，并加快最新和最强大芯片组的推向市场时间。 Azure NetApp 文件大型卷可以满足 EDA 工作负荷的需求，其性能与本地部署中的性能相当。