Elektronik Tasarım Otomasyonu (EDA) için Azure NetApp Files kullanmanın avantajları

  • Makale

Yenilik, yarı iletken sektörünün belirleyici bir özelliğidir. Bu tür yenilikler Gordon Moore'un Moore Yasası olarak bilinen 1965 tenet'inin elli yıldan uzun bir süre boyunca geçerli olmasını sağladı, yani işleme hızlarının yaklaşık olarak her yıl iki katına çıkmasını bekleyebilirsiniz. Örneğin, yarı iletken sektöründeki yenilikler, paralellik aracılığıyla performansı bir kez hayal edilemeyen düzeylere ölçeklendirmek için yongaları daha küçük form faktörlerine yığarak Moore Yasası'nın gelişmesine yardımcı olmuştur.

Yarı iletken (veya Elektronik Tasarım Otomasyonu [EDA]) firmaları en çok pazara çıkış zamanı (TTM) ile ilgileniyor. TTM genellikle yonga tasarımı doğrulaması gibi iş yükleri için gereken süreye göre belirlenir ve bant çıkışı gibi ön döküm işleri tamamlanır. TTM endişeleri, EDA lisans maliyetlerinin düşük kalmasını sağlamaya da yardımcı olur: çalışmaya daha az zaman harcanması, lisanslar için daha fazla zaman harcanması anlamına gelir. Bu, sunucu grubu için ne kadar fazla bant genişliği ve kapasite kullanılabilirse o kadar iyi olur.

Azure NetApp Files, yüksek performanslı, paralelleştirilmiş bir dosya sistemi çözümüyle EDA işlerinin süresini azaltmaya yardımcı olur: Azure NetApp Files büyük birimler. Son EDA karşılaştırma testleri, tek bir büyük birimin, tek bir Azure NetApp Files normal hacmiyle daha önce ulaşılabilenden 20 kat daha yüksek performanslı olduğunu gösteriyor.

Azure NetApp Files büyük hacimli özelliği, bu en zorlu sektörün depolama gereksinimleri için idealdir, yani:

  • Büyük kapasiteli tek ad alanı: Her birim, tek bir bağlama noktası altında 500 TB'a kadar kullanılabilir kapasite sunar.

  • Yüksek G/Ç hızı, düşük gecikme süresi: EDA benzetimi karşılaştırması kullanılarak yapılan testlerde tek bir büyük hacim, 2 milisaniyeden kısa uygulama gecikme süresiyle 650.000 depolama IOPS üzerinde teslim edilir. Tipik bir EDA iş yükünde IOPS bir karışımdan veya dosya oluşturma, okuma, yazma ve önemli miktarda diğer meta veri işleminden oluşur. Bu sonuç, birçok müşteri için kurumsal düzeyde performans olarak kabul edilir. Bu performans iyileştirmesi, büyük birimlerin Gelen yazma işlemlerini Azure NetApp Files'daki depolama kaynakları arasında paralel hale getirebilmesiyle mümkün hale getirilmiştir. Birçok firma 2ms veya daha iyi yanıt süresi gerektirse de, yonga tasarım araçları işletmeyi etkilemeden bundan daha yüksek gecikme süresini tolere edebilir.

  • Saniyede 826.000 işlem: tek bir büyük birimin performans kenarı - uygulama katmanı testlerimizde 7ms gecikme süresiyle zirveye çıktı ve bu da küçük bir gecikme süresi maliyetiyle tek bir büyük hacimde daha fazla işlemin mümkün olduğunu gösteriyor.

EDA karşılaştırması kullanılarak yapılan testler, tek bir normal Azure NetApp Files hacmi ile 40.000 IOPS'ye kadar olan iş yükünün 2ms işaretinde ve uçta 50.000'e ulaşabileceğini belirledi. Normal ve büyük hacimli yan yana genel bakış için aşağıdaki tabloya ve grafiğe bakın.

Senaryo 2ms gecikme süresinde G/Ç Hızı Performans kenarında G/Ç Oranı (yaklaşık 7 ms) 2ms gecikme süresinde MiB/sn MiB/sn performans kenarı (yaklaşık 7 ms)
Bir normal birim 39,601 49,502 692 866
büyük hacim 652,260 826,379 10,030 12,610

Aşağıdaki grafikte test sonuçları gösterilmektedir.

Büyük ve normal birimler arasındaki gecikme süresini ve aktarım hızını karşılaştıran grafik.

Normal birim testi aynı zamanda tek uç nokta sınırlarını da inceledi, altı birimle sınırlara ulaşıldı. Büyük Birim, %260 oranında altı normal birimle senaryodan daha iyi performans gösterir. Aşağıdaki tabloda bu sonuçlar gösterilmektedir.

Senaryo 2ms gecikme süresinde G/Ç Hızı Performans uçlarında G/Ç Hızı (yaklaşık 7ms) 2ms gecikme süresinde MiB/sn MiB/sn performans kenarı (~7ms)
Altı normal birim 255,613 317,000 4,577 5,688
Bir büyük hacim 652,260 826,379 10,030 12,610

Büyük ölçekte basitlik

Büyük bir hacimle, performans hikayenin tamamı değildir. Basit performans son hedeftir. Müşteriler, kullanım kolaylığı ve uygulama yönetimi için birden çok birimi yönetmenin aksine tek bir ad alanı/bağlama noktası tercih eder.

Test aracı

Bu testteki EDA iş yükü, standart bir endüstri karşılaştırma aracı kullanılarak oluşturulmuştur. Yarı iletken yongaları tasarlamak için kullanılan EDA uygulamalarının bir karışımını simüle eder. EDA iş yükü dağıtımı şöyledir:

Ön uç OP türünü gösteren pasta grafik.

EDA Ön Uç OP Türü Toplam Yüzdesi
Eyalet 39%
Access %15
Random_write %15
Write_file %10
Random_read %8
Read_file %7
Oluşturma %2
Chmod %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Arkasına Ekle
  • Özel2
  • Kilitle
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Yazmak
%0

Arka uç OP türü dağılımını gösteren pasta grafik.

EDA Arka Uç OP Türü Toplam Yüzdesi
Okundu %50
Write %50
  • Özel2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 %0

Test yapılandırması

Sonuçlar aşağıdaki yapılandırma ayrıntıları kullanılarak üretildi:

Bileşen Yapılandırma
İşletim Sistemi RHEL 9.3 / RHEL 8.7
Örnek Türü D16s_v5
Örnek Sayısı 10
Bağlama Seçenekleri nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
İstemci tonlamaları # Ağ parametreleri. Bayt birimi cinsinden
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 boyutlu öbeklerdeki ayarlar, bayt cinsinden
net.ipv4.tcp_mem = 4096 89600 4194304

# Çeşitli ağ seçenekleri ve bayrakları
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

# Çeşitli dosya sistemi / pagecache seçenekleri
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# ontap network exec tuning for client
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Bağlama seçenekleri nocto, noatimeve actimeo=600 birlikte çalışarak bir EDA iş yükü için bazı meta veri işlemlerinin NFSv3 protokolü üzerindeki etkisini hafifletin. Bu bağlama seçenekleri hem gerçekleşen meta veri işlemlerinin sayısını azaltır hem de istemcideki bazı meta veri özniteliklerini önbelleğe alarak EDA iş yüklerinin aksi durumdan daha fazla göndermesine olanak tanır. Bu bağlama seçenekleri evrensel olarak geçerli olmadığından tek tek iş yükü gereksinimlerini göz önünde bulundurmanız önemlidir. Daha fazla bilgi için bkz . Azure NetApp File için Linux NFS bağlama seçenekleri en iyi yöntemleri.

Özet

EDA iş yükleri, binlerce istemci iş istasyonunda yüksek dosya sayılarını, büyük kapasiteyi ve çok sayıda paralel işlemi işleyebilen dosya depolama alanı gerektirir. EDA iş yüklerinin ayrıca lisanslardan tasarruf etmek ve en son ve en büyük yonga kümeleri için pazarlama süresini kısaltmak için test ve doğrulamanın tamamlanması için gereken süreyi azaltan bir düzeyde performans göstermeleri gerekir. Azure NetApp Files büyük hacimleri, şirket içi dağıtımlarda görülebilecek performansla karşılaştırılabilir bir EDA iş yükünün taleplerini işleyebilir.

Sonraki adımlar