Udostępnij za pośrednictwem

Zalety korzystania z usługi Azure NetApp Files dla usługi Electronic Design Automation (EDA)

  • Artykuł

Innowacje to znak rozpoznawczy branży półprzewodników. Taka innowacja pozwoliła, aby tenet Gordona Moore'a z 1965 roku znany jako Prawo Moore'a było prawdziwe przez ponad pięćdziesiąt lat, a mianowicie, że można oczekiwać, że prędkość przetwarzania podwoi się mniej więcej co rok lub dwa. Na przykład innowacje w branży półprzewodników przyczyniły się do rozwoju prawa Moore'a poprzez układanie układów w mniejsze czynniki formowe w celu skalowania wydajności do nieobrażalnych poziomów poprzez równoległość.

Firmy półprzewodnikowe (lub Electronic Design Automation [EDA]) najbardziej interesują się czasem obrotu (TTM). Funkcja TTM jest często określana na czas potrzebny na obciążenia, takie jak walidacja projektu mikroukładu i praca wstępnie znaleziona, taka jak zakończenie pracy na taśmie. Problemy TTM pomagają również obniżyć koszty licencjonowania EDA: mniej czasu poświęcanego na pracę oznacza więcej czasu dostępnego dla licencji. Oznacza to, że tym większa przepustowość i pojemność dostępna dla farmy serwerów, tym lepiej.

Usługa Azure NetApp Files pomaga skrócić czas wykonywania zadań EDA przy użyciu wysoce wydajnego, równoległego rozwiązania systemu plików: duże woluminy usługi Azure NetApp Files. Ostatnie testy porównawcze EDA pokazują, że pojedyncza duża ilość jest 20 razy większa niż wcześniej osiągalna z pojedynczym woluminem regularnym usługi Azure NetApp Files.

Funkcja dużych woluminów usługi Azure NetApp Files jest idealna dla potrzeb magazynu tej najbardziej wymagającej branży, a mianowicie:

  • Pojedyncza przestrzeń nazw pojemności: każdy wolumin oferuje maksymalnie 500TiB pojemności do wykorzystania w ramach pojedynczego punktu instalacji.

  • Wysoka szybkość we/wy, małe opóźnienie: w testowaniu przy użyciu testu porównawczego symulacji EDA pojedyncza duża ilość dostarczana przez ponad 650 000 operacji we/wy magazynu z mniej niż 2 milisekundami opóźnienia aplikacji. W typowym obciążeniu EDA liczba operacji we/wy na sekundę składa się z kombinacji lub tworzenia plików, operacji odczytu, zapisu i znacznej ilości innych operacji metadanych. Ten wynik jest uważany za wydajność klasy korporacyjnej dla wielu klientów. Ta poprawa wydajności jest możliwa dzięki możliwości równoległego przetwarzania przychodzących operacji zapisu w zasobach magazynu w usłudze Azure NetApp Files. Chociaż wiele firm wymaga 2 ms lub lepszego czasu odpowiedzi, narzędzia projektowe chipów mogą tolerować większe opóźnienia niż to bez wpływu na działalność biznesową.

  • Przy 826 000 operacjach na sekundę: krawędź wydajności pojedynczego dużego woluminu — warstwa aplikacji osiągnęła 7 ms opóźnienia w naszych testach, co pokazuje, że więcej operacji jest możliwych w jednym dużym woluminie przy niewielkim koszcie opóźnienia.

Testy przeprowadzone przy użyciu testu porównawczego EDA wykazały, że w przypadku pojedynczego zwykłego woluminu usługi Azure NetApp Files obciążenie o wartości 40 000 operacji we/wy na sekundę można osiągnąć na 2 ms i 50 000 na brzegu. Zapoznaj się z poniższą tabelą i wykresem, aby zapoznać się z omówieniem regularnym i dużym woluminem obok siebie.

Scenariusz Szybkość we/wy z opóźnieniem 2 ms Szybkość we/wy na krawędzi wydajności (~7 ms) MiB/s z opóźnieniem 2 ms Krawędź wydajności programu MiB/s (~7 ms)
Jeden wolumin regularny 39,601 49,502 692 866
duży wolumin 652,260 826,379 10,030 12,610

Na poniższym wykresie przedstawiono wyniki testu.

Wykres porównujący opóźnienia i przepływność między dużymi i regularnymi woluminami.

Regularne testy zbiorcze badały również limity pojedynczego punktu końcowego, a limity zostały osiągnięte z sześcioma woluminami. Duży wolumin przewyższa scenariusz z sześcioma regularnymi woluminami o 260%. W poniższej tabeli przedstawiono te wyniki.

Scenariusz Szybkość we/wy z opóźnieniem 2 ms Szybkość we/wy na krawędzi wydajności (~7 ms) MiB/s z opóźnieniem 2 ms Krawędź wydajności miB/s (~7ms)
Sześć woluminów regularnych 255,613 317,000 4,577 5,688
Jeden duży wolumin 652,260 826,379 10,030 12,610

Prostota na dużą skalę

W przypadku dużego woluminu wydajność nie jest całą historią. Prosta wydajność jest celem końcowym. Klienci preferują jedną przestrzeń nazw/punkt instalacji, a nie zarządzanie wieloma woluminami w celu ułatwienia użycia i zarządzania aplikacjami.

Narzędzie do testowania

Obciążenie EDA w tym teście zostało wygenerowane przy użyciu standardowego narzędzia do testów porównawczych w branży. Symuluje mieszaninę aplikacji EDA używanych do projektowania układów półprzewodnikowych. Dystrybucja obciążeń EDA jest następująca:

Wykres kołowy przedstawiający typ operacji frontonu.

Typ operacji frontonu EDA Procent sumy
Stat 39%
Access 15%
Random_write 15%
Write_file 10%
Random_read 8%
Read_file 7%
Utworzenie 2%
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • Dołączanie
  • Niestandardowy 2
  • Zablokuj
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Pisać
0%

Wykres kołowy przedstawiający rozkład typów operacji zaplecza.

Typ operacji zaplecza EDA Procent sumy
Przeczytaj 50%
Write 50%
  • Niestandardowy 2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

konfiguracja testowa

Wyniki zostały wygenerowane przy użyciu poniższych szczegółów konfiguracji:

Składnik Konfigurowanie
System operacyjny RHEL 9.3 / RHEL 8.7
Typ wystąpienia D16s_v5
Liczba wystąpień 10
Opcje instalacji nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Możliwości dostrajania klienta # Parametry sieciowe. W jednostce bajtów
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

# Ustawienia w 4 fragmentach rozmiaru KiB, w bajtach są
net.ipv4.tcp_mem = 4096 89600 4194304

# Opcje i flagi sieci 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

# Różne opcje systemu plików/pagecache
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

noctoOpcje instalacji , noatimei actimeo=600 współpracują ze sobą, aby złagodzić efekt niektórych operacji metadanych dla obciążenia EDA za pośrednictwem protokołu NFSv3. Te opcje instalacji zmniejszają liczbę wykonywanych operacji metadanych i buforują niektóre atrybuty metadanych na kliencie, umożliwiając wypychanie obciążeń EDA dalej niż w przeciwnym razie. Ważne jest, aby wziąć pod uwagę poszczególne wymagania dotyczące obciążenia, ponieważ te opcje instalacji nie mają uniwersalnego zastosowania. Aby uzyskać więcej informacji, zobacz Linux NFS mount options best practices for Azure NetApp File (Najlepsze rozwiązania dotyczące instalacji systemu plików NFS w systemie Linux dla usługi Azure NetApp File).

Podsumowanie

Obciążenia EDA wymagają magazynu plików, który może obsługiwać duże liczby plików, dużą pojemność i dużą liczbę operacji równoległych w potencjalnie tysiącach stacji roboczych klienta. Obciążenia EDA muszą również działać na poziomie, który skraca czas potrzebny na przeprowadzenie testów i weryfikacji, aby zaoszczędzić pieniądze na licencjach i przyspieszyć wprowadzanie na rynek najnowszych i największych mikroukładów. Duże woluminy usługi Azure NetApp Files mogą obsługiwać wymagania obciążenia EDA o wydajności porównywalnej z tym, co można zobaczyć we wdrożeniach lokalnych.

Następne kroki