Поделиться через

Преимущества использования Azure NetApp Files для автоматизации электронной разработки (EDA)

  • Статья

Инновации являются отличительной чертой полупроводниковой промышленности. Такие инновации позволили Гордону Муру в 1965 году, известному как закон Мура, иметь правду более чем на пятьдесят лет, а именно, что можно ожидать скорости обработки в два раза в год или два. Например, инновации в полупроводниковой отрасли помогли эволюционировать закон Мура путем стека чипов в меньшие форм-факторы для масштабирования производительности до невообразимых уровней через параллелизм.

Полупроводниковые фирмы (или электронная автоматизация проектирования [EDA]) наиболее заинтересованы во времени на рынок (TTM). TTM часто предикатируется в течение времени, которое требуется для рабочих нагрузок, таких как проверка дизайна микросхемы и предварительная проверка, как завершение работы с лентой. Проблемы TTM также помогают снизить затраты на лицензирование EDA: меньше времени, потраченного на работу, означает больше времени, доступного для лицензий. Тем больше пропускной способности и емкости, доступной ферме серверов, тем лучше.

Azure NetApp Files помогает сократить время выполнения заданий EDA с высокопроизводительным решением параллельной файловой системы: большие тома Azure NetApp Files. Последние тесты тестов EDA показывают, что один большой том составляет 20 раз более производительности, чем ранее достижимо с одним обычным томом Azure NetApp Files.

Функция больших томов Azure NetApp Files идеально подходит для потребностей хранилища в этой самой сложной отрасли, а именно:

  • Большое пространство имен большой емкости: каждый том предлагает до 500TiB доступной емкости в одной точке подключения.

  • Высокая скорость ввода-вывода, низкая задержка: при тестировании с использованием тестового теста моделирования EDA один большой том доставлял более 650K операций ввода-вывода в секунду с менее чем 2 миллисекундами задержки приложения. В типичной рабочей нагрузке EDA операции ввода-вывода в секунду состоит из смеси или файла, создания, чтения, записи и значительного количества других операций метаданных. Этот результат считается производительностью корпоративного уровня для многих клиентов. Это улучшение производительности возможно благодаря тому, что большие тома могут параллелизировать входящие операции записи в ресурсах хранилища в Azure NetApp Files. Хотя многим фирмам требуется 2 мс или лучшее время отклика, средства разработки чипов могут терпеть более высокую задержку, чем это без влияния на бизнес.

  • При 826 000 операциях в секунду: край производительности одного большого тома — уровень приложения достиг 7 мс задержки в наших тестах, что показывает, что больше операций возможно в одном большом томе с небольшими затратами на задержку.

Тесты, проведенные с помощью теста EDA, обнаружили, что с одним регулярным томом Azure NetApp Files рабочая нагрузка свыше 40 000 операций ввода-вывода в секунду может быть достигнута на 2 мс и 50 000 на границе. См. таблицу и диаграмму ниже для регулярного и параллельного просмотра большого тома.

Сценарий Скорость ввода-вывода в 2 мс Скорость ввода-вывода при пограничном уровне производительности (~7 мс) Задержка МиБ/с в 2 мс Edge производительности MiB/s (~7 мс)
Один обычный том 39 601 49 502 692 866
большой объем 652,260 826,379 10,030 12,610

На следующей диаграмме показаны результаты теста.

Диаграмма сравнивает задержку и пропускную способность между большими и регулярными томами.

Регулярное тестирование томов также изучило ограничения одной конечной точки, ограничения были достигнуты с шестью томами. Большой объем превышает сценарий с шестью регулярными томами на 260 %. В следующей таблице показаны эти результаты.

Сценарий Скорость ввода-вывода в 2 мс Скорость ввода-вывода на пограничном уровне производительности (~7 мс) Задержка МиБ/с в 2 мс Граничная производительность MiB/s (~7 мс)
Шесть регулярных томов 255 613 317 000 4,577 5,688
Один большой том 652,260 826,379 10,030 12,610

Простота в масштабе

С большим объемом производительность не является всей историей. Простая производительность — это конечная цель. Клиенты предпочитают одно пространство имен или точку подключения, а не управление несколькими томами для упрощения использования и управления приложениями.

Средство тестирования

Рабочая нагрузка EDA в этом тесте была создана с помощью стандартного средства тестирования отрасли. Он имитирует смесь приложений EDA, используемых для разработки полупроводниковых чипов. Распределение рабочей нагрузки EDA такое:

Круговая диаграмма, изображающая тип передней части op.

Тип передней части операции EDA Процент общего числа
Стат 39 %
Открыть 15 %
Random_write 15 %
Write_file 10%
Random_read %8
Read_file 7%
Создание 2%
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • Добавление
  • Custom2
  • Заблокировать
  • Mmap_read
  • Mmap_write
  • Neg_stat
  • Read_modify_write
    • Rmdir
  • Писать
0%

Круговая диаграмма с распределением типов серверной части OP.

Тип серверной части операции EDA Процент общего числа
Читать 50%
Write 50%
  • Custom2
  • Mmap_read
  • Random_read
  • Read_file
  • Read_modify_file
 0%

Конфигурация теста

Результаты были получены с помощью следующих сведений о конфигурации:

Компонент Настройка
Операционная система RHEL 9.3 / RHEL 8.7
Тип экземпляра D16s_v5
Число экземпляров 10
Параметры подключения nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8
Ошеломимые клиенты # Сетевые параметры. Единица байтов
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 в байтах
net.ipv4.tcp_mem = 4096 89600 4194304

# Другие сетевые параметры и флаги
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

# Различные параметры файловой системы / pagecache
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

# Настройка exec сети ONTAP для клиента
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128

Параметры noctonoatimeподключения и actimeo=600 совместная работа, чтобы облегчить влияние некоторых операций метаданных для рабочей нагрузки EDA по протоколу NFSv3. Эти параметры подключения сокращают количество операций метаданных, выполняемых, и кэшируют некоторые атрибуты метаданных на клиенте, позволяя рабочим нагрузкам EDA отправлять дальше, чем в противном случае. Важно учитывать требования к отдельной рабочей нагрузке, так как эти параметры подключения не являются универсальными. Дополнительные сведения см. в рекомендациях по подключению Linux NFS для Azure NetApp File.

Итоги

Для рабочих нагрузок EDA требуется хранилище файлов, которое может обрабатывать большое количество файлов, большую емкость и большое количество параллельных операций в потенциально тысячах клиентских рабочих станций. Рабочие нагрузки EDA также должны выполняться на уровне, который сокращает время, необходимое для тестирования и проверки, чтобы сэкономить деньги на лицензиях и ускорить время на рынке последних и величайших наборов микросхем. Большие тома Azure NetApp Files могут обрабатывать требования рабочей нагрузки EDA с производительностью, сравнимой с производительностью, которую можно увидеть в локальных развертываниях.

Следующие шаги