共用方式為

使用 Azure NetApp Files 進行電子設計自動化 (EDA) 的優點

  • 發行項

創新是半導體產業的識別標誌。 這種創新使戈登·摩爾1965年被譽為摩爾法律的理念在五十多年的時間里得以實現，即人們可以期望加工速度大約每年或兩年翻一番。 例如，半導體產業的創新通過將晶元堆疊成較小的尺寸，通過平行處理原則將效能調整為一度難以想像的水準，有助於發展摩爾的法律。

半導體（或電子設計自動化[EDA]） 公司對上市時間（TTM）最感興趣。 TTM 通常會根據工作負載所需的時間進行述詞，例如晶元設計驗證和預建工作，例如磁帶出完成。 TTM 考慮也有助於降低 EDA 授權成本：花在工作上的時間較少意味著授權有更多時間可供使用。 也就是說，伺服器陣列可用的頻寬和容量越多，越好。

Azure NetApp Files 可協助減少使用高效能、平行化文件系統解決方案的 EDA 作業時間： Azure NetApp Files 大型磁碟區。 最近的 EDA 基準檢驗顯示，單一大型磁碟區比先前透過單一 Azure NetApp Files 一般磁碟區達到的效能高出 20 倍。

Azure NetApp Files 大型磁碟區功能非常適合此最需求產業的記憶體需求，也就是：

  • 大型容量單一命名空間： 每個磁碟區在單一裝入點下提供最多 500TiB 的可用容量。

  • 高 I/O 速率、低延遲： 在使用 EDA 模擬基準進行測試時，單一大型磁碟區傳遞超過 650K 個記憶體 IOPS，且應用程式延遲少於 2 毫秒。 在典型的 EDA 工作負載中，IOPS 是由混合或檔案建立、讀取、寫入，以及大量的其他元數據作業所組成。 此結果會被視為許多客戶的企業級效能。 透過大型磁碟區能夠平行處理 Azure NetApp Files 中記憶體資源的連入寫入作業，即可改善此效能。 雖然許多公司需要 2 毫秒或更好的響應時間，但晶片設計工具可以容忍比這更高的延遲，而不會對業務造成影響。

  • 每秒 826,000 個作業： 單一大型磁碟區的效能邊緣 - 應用層在我們的測試中達到 7 毫秒的延遲尖峰，這顯示單一大型磁碟區中可能會有更多作業，但延遲成本微低。

使用 EDA 基準檢驗進行的測試發現，使用單一一標準 Azure NetApp Files 磁碟區，工作負載高達 40,000 IOPS 可以在 2 毫秒標記和邊緣達到 50,000。 如需一般和大型磁碟區並存概觀，請參閱下表和圖表。

案例 2 毫秒延遲的 I/O 速率 效能邊緣的 I/O 速率 （~7 毫秒） 2 毫秒延遲的MiB/秒 MiB/s 效能邊緣 （~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/s 效能邊緣 （~7 毫秒）
六個一般磁碟區 255,613 317,000 4,577 5,688
一個大型磁碟區 652,260 826,379 10,030 12,610

大規模簡化

由於大量，效能並不是整個故事。 簡單效能是最終目標。 客戶偏好使用單一命名空間/裝入點，而不是管理多個磁碟區，以方便使用和應用程式管理。

測試工具

此測試中的 EDA 工作負載是使用標準產業基準檢驗工具所產生。 它會模擬用於設計半導體晶元的 EDA 應用程式的混合。 EDA 工作負載散發如下：

描述前端 OP 類型的餅圖。

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
  • 附加
  • 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

# Misc 網路選項和旗標
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

# 各種檔案系統/ pagecache 選項
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 一起運作，以減輕 EDA 工作負載透過 NFSv3 通訊協定對某些元數據作業的影響。 這些掛接選項會減少進行元數據作業的數目，並在用戶端上快取一些元數據屬性，讓EDA工作負載比其他工作負載更進一步推送。 請務必考慮個別工作負載需求，因為這些掛接選項不適用。 如需詳細資訊，請參閱 Azure NetApp File 的 Linux NFS 掛接選項最佳做法。

摘要

EDA 工作負載需要可處理高檔案計數、大型容量，以及可能數千個用戶端工作站的大量平行作業的檔案記憶體。 EDA 工作負載也需要在一個層級執行，以減少測試和驗證完成所需的時間，以節省授權的金錢，並加快上市時間，以取得最新和最大的晶元組。 Azure NetApp Files 大型磁碟區可以處理 EDA 工作負載的需求，其效能與內部部署部署中所見的效能相當。

下一步