Aracılığıyla paylaş

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

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ı ve bant çıkışı gibi işlerle birlikte döküm öncesi çalışmalar gibi iş yüklerinin tamamlanması için geçen süreye dayanı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 nedenle, sunucu çiftliği için ne kadar fazla bant genişliği ve kapasite mevcutsa o kadar iyi.

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 en fazla 1 PiB kullanılabilir kapasite sunar. 2 PiB büyük hacim isteyebilirsiniz.

  • Yüksek G/Ç hızı, düşük gecikme süresi: EDA simülasyon benchmark testi kullanılarak yapılan testlerde, tek bir büyük hacim, 2 milisaniyeden kısa uygulama gecikme süresiyle 650.000 üzerinde depolama IOPS sağlandı. 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üklerinin 2ms hedefinde ve uç noktada 50.000'e ulaşabileceğini belirledi. Normal ve büyük hacimlerin yan yana genel görünümü için aşağıdaki tabloya ve grafiğe bakın.

Senaryo 2ms gecikme süresinde G/Ç Hızı Performans sınırında Girdi/Çıktı Oranı (yaklaşık 7 ms) 2ms gecikme süresinde MiB/sn MiB/sn performans kenarı (yaklaşık 7 ms)
Bir normal hacim 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 sınırında G/Ç Hızı (ortalama 7ms) 2ms gecikme süresinde MiB/sn MiB/sn performans kenarı (~7ms)
Altı normal birim 255,613 317.000 4,577 5,688
Büyük bir hacim 652,260 826,379 10,030 12,610

Büyük ölçekte basitlik

Büyük bir hacim olduğunda, performans yalnızca hikayenin bir kısmıdır. 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:

Önyüz OP türünü gösteren pasta grafik.

EDA Ön Uç OP Türü Toplam Yüzdesi
İstatistik 39%
Erişim %15
Rastgele_yaz %15
Dosya_yaz %10
Rastgele oku %8
Read_file %7
Oluştur %2
Chmod (Unix ve Linux sistemlerinde dosya izinlerini değiştirmek için kullanılan bir komut) %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Sonuna Ekle
  • Özel2
  • Kilitle
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Oku_değiştir_yaz
    • Rmdir
  • Yazmak
%0

Arka plan OP türü dağılımını gösteren pasta grafiği.

EDA Arka Uç OP Türü Toplam Yüzdesi
Okundu %50
Yaz %50
  • Özel2
  • Mmap_read
  • Rastgele oku
  • Read_file
  • Okuma_değiştirme_dosyası
 %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 ayarlanabilir parametreleri # 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 (Kirli arka plan oranı) = 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, noatime ve actimeo=600 birlikte çalışarak bir EDA iş yükü için bazı meta veri işlemlerinin NFSv3 protokolü üzerindeki etkisini hafifletir. 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 Azure NetApp File için Linux NFS bağlama seçenekleri en iyi yöntemleri başlıklı makaleye bakın.

Ö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