Ventajas de usar Azure NetApp Files para la automatización de diseños electrónicos (EDA)

  • Artículo

La innovación es una seña de identidad de la industria de los semiconductores. Tal innovación permitió que el principio de Gordon Moore de 1965, conocido como la Ley de Moore, se mantuviera vigente durante más de cincuenta años, a esto es, que se puede esperar que las velocidades de procesamiento se dupliquen aproximadamente cada uno o dos años. Por ejemplo, la innovación en la industria de los semiconductores ha ayudado a evolucionar la Ley de Moore apilando chips en factores de forma más pequeños para escalar el rendimiento a niveles antes inimaginables a través del paralelismo.

Las empresas de semiconductores (o de automatización del diseño electrónico [EDA]) son las más interesadas en el tiempo de comercialización (TTM). El TTM se basa a menudo en el tiempo que tardan en completarse las cargas de trabajo, como la validación del diseño del chip y el trabajo previo a la fundición, como la salida de la cinta. Los problemas de TTM también ayudan a reducir los costos de licencias de EDA: menos tiempo invertido en el trabajo significa más tiempo disponible para las licencias. Eso sí, cuanto más ancho de banda y capacidad disponga la granja de servidores, mejor.

Azure NetApp Files ayuda a reducir el tiempo que tardan los trabajos de EDA con una solución de sistema de archivos altamente eficaz y en paralelo: Grandes volúmenes de Azure NetApp Files. Las recientes pruebas de referencia de EDA demuestran que un único volumen de gran tamaño ofrece un rendimiento 20 veces superior al que se conseguía anteriormente con un único volumen normal de Azure NetApp Files.

Las características de grandes volúmenes de Azure NetApp Files son ideales para las necesidades de almacenamiento de este sector tan exigente, por ejemplo:

  • Espacio de nombre único de gran capacidad: cada volumen ofrece desde hasta 500TiB de capacidad utilizable bajo un único punto de montaje.

  • Alta tasa de E/S, baja latencia: en las pruebas realizadas usando un punto de referencia de simulación EDA, un único gran volumen proporcionó más de 650K IOPS de almacenamiento con menos de 2 milisegundos de latencia de aplicación. En una carga de trabajo EDA típica, IOPS consiste en una mezcla o creación de archivos, lecturas, escrituras y una cantidad significativa de otras operaciones de metadatos. Este resultado se considera un rendimiento de nivel empresarial para muchos clientes. Esta mejora del rendimiento es posible gracias a la forma en que los grandes volúmenes pueden paralelizar las operaciones de escritura entrantes en todos los recursos de almacenamiento de Azure NetApp Files. Aunque muchas empresas exigen un tiempo de respuesta de 2 ms o superior, las herramientas de diseño de chips pueden tolerar una latencia mayor que ésta sin afectar al negocio.

  • A 826.000 operaciones por segundo: el límite de rendimiento de un único gran volumen : la capa de aplicación alcanzó un máximo de 7 ms de latencia en nuestras pruebas, lo que demuestra que es posible realizar más operaciones en un único gran volumen con un ligero costo de latencia.

Las pruebas realizadas internamente usando un punto de referencia EDA en 2020 descubrieron que con un único volumen regular de Azure NetApp Files se podían alcanzar cargas de trabajo de hasta 40.000 IOPS en la marca de los 2 ms, y de 50.000 en el borde.

Escenario Velocidad de E/S a 2 ms de latencia Velocidad de E/S en el borde de rendimiento (~7 ms) MiB/s a 2 ms de latencia Borde de rendimiento de MiB/s (~7 ms)
Un volumen normal 39 601 49 502 692 866
gran volumen 652,260 826,379 10,030 12,610

En el gráfico siguiente se muestran los resultados de la prueba.

Gráfico que compara la latencia y el rendimiento entre volúmenes grandes y normales.

Las pruebas internas de 2020 también exploraron los límites de punto de conexión único, los límites se alcanzaron con seis volúmenes. El volumen grande supera el escenario con seis volúmenes normales en un 260 %.

Escenario Velocidad de E/S a 2 ms de latencia Velocidad de E/S en el borde de rendimiento (~7 ms) MiB/s a 2 ms de latencia Borde de rendimiento de MiB/s (~7 ms)
Seis volúmenes normales 255 613 317 000 4,577 5,688
Un gran volumen 652,260 826,379 10,030 12,610

Simplicidad a escala

Con un gran volumen, el rendimiento no es toda la historia. El rendimiento simple es el objetivo final. Los clientes prefieren un único espacio de destino o punto de montaje en lugar de administrar varios volúmenes para facilitar su uso y la gestión de las aplicaciones.

Herramienta de prueba

La carga de trabajo de EDA en esta prueba se generó mediante una herramienta estándar de pruebas comparativas del sector. Simula una mezcla de aplicaciones EDA usadas para diseñar chips semiconductores. La distribución de la carga de trabajo de EDA es la siguiente:

Gráfico circular que representa el tipo de OP del frontend.

Tipo de OP de frontend de EDA Porcentaje del total
Estadística 39 %
Access 15 %
Random_write 15 %
Write_file 10%
Random_read 8 %
Read_file 7 %
Crear 2 %
Chmod %1
Mkdir %1
Ulink %1
Ulink2 %1
  • Anexar
  • Custom2
  • Bloquear
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Escritura
0 %

Gráfico circular que muestra la distribución del tipo op de backend.

Tipo de operación backend de EDA Porcentaje del total
Leer 50 %
Escribir 50 %
  • Custom2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0 %

Configuración de prueba

Los resultados se generaron con los siguientes detalles de configuración:

Componente Configuración
Sistema operativo RHEL 9.3 / RHEL 8.7
Tipo de instancia D16s_v5
Recuento de instancias 10
Opciones de montaje nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Ajustes del cliente # Parámetros de red. En unidad de bytes
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

# Configuración en fragmentos de 4 KiB de tamaño, que son en bytes
net.ipv4.tcp_mem = 4096 89600 4194304

# Opciones y marcas de red diversas
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

# Varias opciones de sistema de archivos/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

Las opciones de montaje nocto, noatimey actimeo=600 funcionan conjuntamente para aliviar el efecto de algunas operaciones de metadatos para una carga de trabajo de EDA a través del protocolo NFSv3. Estas opciones de montaje reducen a la vez el número de operaciones de metadatos que tienen lugar y almacenan en caché algunos atributos de metadatos en el cliente, lo que permite a las cargas de trabajo EDA avanzar más de lo que lo harían de otro modo. Es esencial tener en cuenta los requisitos individuales de carga de trabajo, ya que estas opciones de montaje no son de aplicación universal. Para más información, vea procedimientos recomendados de montaje NFS de Linux para Azure NetApp File.

Resumen

Las cargas de trabajo EDA requieren un almacenamiento de archivos que pueda gestionar un elevado número de archivos, una gran capacidad y un gran número de operaciones paralelas en miles de estaciones de trabajo cliente potenciales. Las cargas de trabajo EDA también tienen que rendir a un nivel que reduzca el tiempo que tardan en completarse las pruebas y la validación, de modo que se ahorre dinero en licencias y se acelere el tiempo de comercialización de los últimos y mejores conjuntos de chips. Los grandes volúmenes de Azure NetApp Files pueden hacer frente a las demandas de una carga de trabajo EDA con un rendimiento comparable al que se vería en implementaciones locales.

Pasos siguientes