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

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

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

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

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

  • Одно пространство имен большой емкости: Каждый том предлагает до 1 piB доступной емкости под одной точкой подключения. Можно запросить большой объем 2 PiB.

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

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

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

Сценарий Скорость ввода-вывода при задержке 2 мс Скорость ввода-вывода при пограничном уровне производительности (~3 мс) Задержка 2 мс при скорости МиБ/с Преимущество производительности в MiB/s (~7 мс)
Один обычный том 39 601 49,502 692 866
Один большой том 742,541 742,541 11,699 12,480

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

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

Одиночный Большой Объем превосходит сценарий с шестью обычными томами на 249%. При использовании шести больших томов масштабирование производительности было линейным по сравнению с одним большим томом. В следующей таблице и диаграмме показаны результаты для шести регулярных томов, одного большого тома и шести больших томов:

Сценарий Скорость ввода-вывода при задержке 2 мс Скорость ввода-вывода на пограничном уровне производительности (~7 мс) Задержка 2 мс при скорости МиБ/с Преимущество производительности MiB/s (~7 мс)
Шесть регулярных томов 255,613 317 000 4,577 5,688
Один большой том 742,541 742,541 11,699 12,480
Шесть больших томов 4,435,382 4,745,453 69,892 74,694

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

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

При большом объеме производительность — это лишь часть картины. Простая производительность — это конечная цель.

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

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

Единица измерения Большой том Масштаб большого объема Фактор
Пропускная способность (МБ/с) 12,780 76 487 5.98
Операции/секунда 792,046 4,745,453 5,99

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

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

Круговая диаграмма, показывающая тип OP для фронтенда.

Тип интерфейса EDA для операции Процент от общего числа
статистика 39%
Доступ 15 %
Случайная_запись 15 %
Записать_файл 10%
Случайное чтение 8%
Чтение_файла 7%
Создайте 2%
Chmod 1%
Mkdir 1%
Ulink 1%
Ulink2 1%
  • Добавить
  • Custom2
  • Замок
  • Mmap_read
  • Mmap_write (функция для записи в отображаемую область памяти)
  • Негативный статус
  • Чтение_модификация_запись
    • Rmdir
  • Писать
0%

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

Тип серверной части операции EDA Процент от общего числа
Читайте 50%
Напишите 50%
  • Custom2
  • Mmap_read
  • Случайное чтение
  • Чтение_файла
  • Чтение_модификация_файла
 0%

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

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

Схема архитектуры для одного большого тома.

Компонент Конфигурация
Операционная система Red Hat Enterprise Linux
Тип экземпляра D16s_v5/D32s_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 = 4194304
net.core.somaxconn = 65535

# Параметры в блоках размером 4 KiB, в байтах они
net.ipv4.tcp_mem = 4096 89600 8388608

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

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

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

Сводка

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

Дальнейшие шаги

  • Last updated on