Share via

Avantages de l’utilisation d’Azure NetApp Files pour l’automatisation de la conception électronique (EDA)

  • Article

L’innovation est une caractéristique propre à l’industrie des semi-conducteurs. Cette innovation a permis à au concept 1965 de Gordon Moore (connu sous le nom de Loi de Moore) d’être valable pendant plus de cinquante ans, à savoir que les vitesses de traitement devraient doubler environ tous les ans ou tous les deux ans. Par exemple, l’innovation dans l’industrie des semi-conducteurs a contribué à faire évoluer la loi de Moore en empilant des puces en facteurs de forme plus petits afin de mettre à l’échelle les performances à des niveaux une fois inimaginables par le parallélisme.

Les entreprises de semi-conducteurs (ou d’automatisation de la conception électronique [EDA]) sont les plus intéressées par le délai de commercialisation (TTM). Le TTM est souvent basé sur le temps nécessaire aux charges de travail, telles que la validation de conception de puce et le travail antérieur à la fonderie comme l’envoi en fabrication jusqu’à la sortie. Les préoccupations liées au TTM aident également à réduire les coûts de licence EDA : moins de temps consacré au travail signifie plus de temps disponible pour les licences. Cela dit, plus il y a de bande passante et de capacité disponibles pour la batterie de serveurs, mieux c’est.

Azure NetApp Files permet de réduire le temps nécessaire aux travaux EDA avec une solution de système de fichiers hautement performant et parallélisé : Grands volumes Azure NetApp Files. Les récents tests du point de référence EDA montrent qu’un seul grand volume est 20 fois plus performant que le résultat obtenu auparavant avec un seul volume standard Azure NetApp Files.

La fonctionnalité de grands volumes Azure NetApp Files est idéale pour les besoins de stockage de ce secteur très exigeant, à savoir :

  • Espace de noms unique de grande capacité : chaque volume offre jusqu’à 500 Tio de capacité utilisable sous un seul point de montage.

  • Taux d’E/S élevé, faible latence : lors du test à l’aide d’un point de référence de simulation EDA, un seul grand volume produit plus de 650 000 IOPS de stockage avec moins de 2 ms de latence pour l’application. Dans une charge de travail EDA classique, les IOPS se composent d’un mélange ou d’un fichier qui crée, lit et écrit, ainsi qu’une quantité importante d’autres opérations de métadonnées. Ce résultat est considéré comme des performances de niveau entreprise pour plusieurs clients. Cette amélioration des performances est rendue possible par la capacité des grands volumes à paralléliser les opérations d’écriture entrantes entre les ressources de stockage dans Azure NetApp Files. Bien que de nombreuses entreprises aient besoin d’un temps de réponse de 2 ms ou moins, les outils de conception de puce peuvent tolérer une latence plus élevée que celle-ci sans impact sur l’entreprise.

  • À 826 000 opérations par seconde : le bord des performances d’un seul grand volume – la couche application a atteint un pic de latence de 7 ms dans nos tests, ce qui montre que d’autres opérations sont possibles dans un seul grand volume à un faible coût de latence.

Les tests effectués en interne à l’aide d’un point de référence EDA en 2020 ont constaté qu’avec un seul volume standard Azure NetApp Files, la charge de travail pouvant atteindre 40 000 E/S par seconde à la marque de 2 ms et 50 000 à la périphérie.

Scénario Taux d’E/S à 2 ms de latence Taux d’E/S à la périphérie des performances (~7 ms) Mio/s à 2 ms de latence Périphérie de performances en Mio/s (~7 ms)
Un volume normal 39 601 49 502 692 866
grand volume 652 260 826 379 10 030 12 610

Le graphique suivant présente les résultats du test.

Graphique comparant la latence et le débit entre les grands volumes et les volumes standard.

Les tests internes 2020 ont également exploré des limites d’un unique point de terminaison. Ces limites ont été atteintes avec six volumes. Le grand volume dépasse le scénario avec six volumes standard de 260 %.

Scénario Taux d’E/S à 2 ms de latence Taux d’E/S à la périphérie des performances (~7 ms) Mio/s à 2 ms de latence Périphérie de performances en Mio/s (~7 ms)
Six volumes standard 255 613 317 000 4 577 5 688
Un grand volume 652 260 826 379 10 030 12 610

Simplicité à grande échelle

Avec un grand volume, il n’y a pas que les performances qui comptent. Des performances simples sont l’objectif final. Les clients préfèrent un unique espace de noms/point de montage, plutôt que gérer plusieurs volumes, pour la simplicité d’utilisation et la gestion des applications.

Outil de test

La charge de travail EDA de ce test a été générée à l’aide d’un outil Standard de point de référence du secteur. Il simule un mélange d’applications EDA utilisé pour concevoir des puces à semi-conducteurs. La distribution de la charge de travail EDA est telle que :

Graphique à secteurs montrant le type d’OP du serveur frontal.

Type d’OP du serveur frontal EDA Pourcentage total
Stat 39
Access 15 %
Random_write 15 %
Write_file 10 %
Random_read 8 %
Read_file 7 %
Create 2 %
Chmod %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Ajouter
  • Custom2
  • Verrouiller
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Write
0 %

Graphique à secteurs montrant la distribution du type d’OP du serveur principal.

Type d’OP du serveur principal EDA Pourcentage total
Lire 50 %
Écrire 50 %
  • Custom2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0 %

Configuration de test

Les résultats ont été obtenus à l’aide des détails de configuration ci-dessous :

Composant Configuration
Système d'exploitation RHEL 9.3 / RHEL 8.7
Type d'instance D16s_v5
Nombre d'instances 10
Options de montage nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Clients paramétrables # Paramètres réseau. En unité d’octets
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

# Paramètres des blocs de 4 Kio, en octets, ils sont
net.ipv4.tcp_mem = 4096 89600 4194304

# Options et indicateurs incorrects du réseau
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

# Diverses options du système de fichiers / cache de la page
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Réglage de l’exécution du réseau ONTAP pour le client
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Les options de montage nocto, noatime et actimeo=600 fonctionnent conjointement pour atténuer l’effet de certaines opérations sur les métadonnées pour une charge de travail EDA à travers le protocole NFSv3. Ces options de montage réduisent le nombre d’opérations sur les métadonnées effectuées et mettent en cache certains attributs de métadonnées sur le client, permettant aux charges de travail EDA de transmettre plus loin qu’elles ne le feraient autrement. Il est important de prendre en compte les exigences individuelles de la charge de travail, car ces options de montage ne sont pas universellement applicables. Pour plus d’informations, consultez Meilleures pratiques pour les options de montage NFS Linux pour Azure NetApp Files.

Résumé

Les charges de travail EDA nécessitent un stockage de fichiers pouvant gérer un nombre élevé de fichiers, une grande capacité et un grand nombre d’opérations parallèles potentiellement sur des milliers de stations de travail clientes. Les charges de travail EDA doivent également s’exécuter à un niveau qui réduit le temps nécessaire au test et à la validation, afin de réaliser des économies sur les licences et d’accélérer le temps de commercialisation pour les plus récents et les meilleurs circuits. Les grands volumes Azure NetApp Files peuvent gérer les demandes d’une charge de travail EDA avec des performances comparables à celles observables dans les déploiements locaux.

Étapes suivantes