EDA(전자 디자인 자동화)에 Azure NetApp Files를 사용할 경우의 이점
혁신은 반도체 산업의 특징입니다. 이러한 혁신을 통해 무어의 법칙으로 알려진 고든 무어의 1965년 신조는 50년 이상 사실로 유지될 수 있게 되었으며, 즉 처리 속도가 약 1~2배로 늘어날 것으로 예상할 수 있습니다. 예를 들어 반도체 산업의 혁신은 칩을 더 작은 폼 팩터로 쌓아 병렬 처리를 통해 한 번 상상할 수 없는 수준으로 성능을 확장함으로써 무어의 법칙을 발전시키는 데 도움이 되었습니다.
반도체(또는 전자 디자인 자동화 [EDA]) 기업은 TTM(Time to Market)에 가장 관심이 있습니다. TTM은 종종 칩 디자인 유효성 검사 및 테이프 아웃과 같은 사전 발견 작업과 같은 워크로드에 걸리는 시간에 따라 달라집니다. TTM 문제는 또한 EDA 라이선스 비용을 줄이는 데 도움이 됩니다. 작업에 소요되는 시간이 적다는 것은 라이선스에 사용할 수 있는 시간이 늘어나다는 것을 의미합니다. 즉, 서버 팜에서 사용할 수 있는 대역폭과 용량이 많을수록 좋습니다.
Azure NetApp Files를 사용하면 고성능의 병렬 처리된 파일 시스템 솔루션 인 Azure NetApp Files 대용량으로 EDA 작업이 수행하는 시간을 줄일 수 있습니다. 최근 EDA 벤치마크 테스트에 따르면 단일 대규모 볼륨이 단일 Azure NetApp Files 일반 볼륨으로 이전에 달성한 것보다 20배 더 성능이 더 높습니다.
Azure NetApp Files 대용량 기능은 가장 까다로운 이 산업의 스토리지 요구 사항 즉, 다음과 같은 경우에 적합합니다.
대용량 단일 네임스페이스: 각 볼륨은 단일 탑재 지점에서 최대 500TiB의 사용 가능한 용량을 제공합니다.
높은 I/O 속도, 짧은 대기 시간: EDA 시뮬레이션 벤치마크를 사용하여 테스트할 때 애플리케이션 대기 시간이 2밀리초 미만인 650K 스토리지 IOPS를 초과하는 단일 대용량 볼륨을 제공합니다. 일반적인 EDA 워크로드에서 IOPS는 혼합 또는 파일 생성, 읽기, 쓰기 및 상당한 양의 기타 메타데이터 작업으로 구성됩니다. 이 결과는 많은 고객에게 엔터프라이즈급 성능으로 간주됩니다. 이러한 성능 향상은 대규모 볼륨이 Azure NetApp Files의 스토리지 리소스에서 들어오는 쓰기 작업을 병렬화할 수 있는 방식으로 가능합니다. 많은 회사에서 2ms 이상의 응답 시간이 필요하지만 칩 디자인 도구는 비즈니스에 영향을 주지 않고 이보다 더 높은 대기 시간을 허용할 수 있습니다.
초당 826,000개의 작업: 단일 대용량의 성능 에지 - 애플리케이션 계층은 테스트에서 7ms의 대기 시간으로 정점을 찍었으며, 이는 약간의 대기 시간 비용으로 단일 대용량에서 더 많은 작업이 가능하다는 것을 보여줍니다.
2020년에 EDA 벤치마크를 사용하여 내부적으로 수행된 테스트에서는 단일 일반 Azure NetApp Files 볼륨을 사용하여 2ms 마크에서 40,000 IOPS의 높은 워크로드를 달성하고 에지에서 50,000개의 워크로드를 달성할 수 있음을 발견했습니다.
| 시나리오 | 2ms 대기 시간의 I/O 속도 | 성능 에지의 I/O 속도(~7ms) | 2ms 대기 시간의 MiB/s | MiB/s 성능 에지(~7ms) |
|---|---|---|---|---|
| 하나의 일반 볼륨 | 39,601 | 49,502 | 692 | 866 |
| 큰 볼륨 | 652,260 | 826,379 | 10,030 | 12,610 |
다음 차트에서는 테스트 결과를 보여 줍니다.
2020 년 내부 테스트는 단일 엔드포인트 제한을 탐구했으며, 제한은 6 개의 볼륨으로 도달했습니다. 대용량은 260%까지 6개의 일반 볼륨으로 시나리오를 능가합니다.
| 시나리오 | 2ms 대기 시간의 I/O 속도 | 성능 에지에서 I/O 속도(~7ms) | 2ms 대기 시간의 MiB/s | MiB/s 성능 에지(~7ms) |
|---|---|---|---|---|
| 6개의 일반 볼륨 | 255,613 | 317,000 | 4,577 | 5,688 |
| 큰 볼륨 1개 | 652,260 | 826,379 | 10,030 | 12,610 |
대규모 단순성
볼륨이 크면 성능이 전체 스토리가 아닙니다. 간단한 성능이 최종 목표입니다. 고객은 사용 편의성과 애플리케이션 관리를 위해 여러 볼륨을 관리하는 대신 단일 네임스페이스/탑재 지점을 선호합니다.
테스트 도구
이 테스트의 EDA 워크로드는 표준 업계 벤치마크 도구를 사용하여 생성되었습니다. 반도체 칩을 설계하는 데 사용되는 EDA 애플리케이션의 혼합물을 시뮬레이션합니다. EDA 워크로드 배포는 다음과 같습니다.
| EDA 프런트 엔드 OP 형식 | 총 백분율 |
|---|---|
| 통계 | 39% |
| Access | 15% |
| Random_write | 15% |
| Write_file | 10% |
| Random_read | 8% |
| Read_file | 7% |
| 만들기 | %2 |
| Chmod | %1 |
| Mkdir | %1 |
| Ulink | %1 |
| Ulink2 | %1 |
|
0% |
| EDA 백 엔드 OP 형식 | 총 백분율 |
|---|---|
| 읽기 | 50% |
| 쓰기 | 50% |
|
0% |
테스트 구성
결과는 아래 구성 세부 정보를 사용하여 생성되었습니다.
| 구성 요소 | 구성 |
|---|---|
| 운영 체제 | RHEL 9.3 / RHEL 8.7 |
| 인스턴스 유형 | D16s_v5 |
| 인스턴스 수 | 10 |
| 탑재 옵션 | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
| 클라이언트 튜닝 가능 | # 네트워크 매개 변수입니다. 바이트 단위 |
옵션을 noctonoatime탑재하고 actimeo=600 함께 작동하여 NFSv3 프로토콜을 통해 EDA 워크로드에 대한 일부 메타데이터 작업의 영향을 완화합니다. 이러한 탑재 옵션은 수행되는 메타데이터 작업의 수를 줄이고 클라이언트에서 일부 메타데이터 특성을 캐시하여 EDA 워크로드가 다른 작업보다 더 많이 푸시할 수 있도록 합니다. 이러한 탑재 옵션은 보편적으로 적용되지 않으므로 개별 워크로드 요구 사항을 고려해야 합니다. 자세한 내용은 Azure NetApp File에 대한 Linux NFS 탑재 옵션 모범 사례를 참조 하세요.
요약
EDA 워크로드에는 잠재적으로 수천 개의 클라이언트 워크스테이션에서 높은 파일 수, 대용량 및 많은 병렬 작업을 처리할 수 있는 파일 스토리지가 필요합니다. 또한 EDA 워크로드는 테스트 및 유효성 검사를 완료하는 데 걸리는 시간을 줄이는 수준에서 수행하여 라이선스 비용을 절감하고 최신의 가장 큰 칩셋 출시 시간을 단축해야 합니다. Azure NetApp Files 대용량은 온-프레미스 배포에서 볼 수 있는 것과 비슷한 성능으로 EDA 워크로드의 요구를 처리할 수 있습니다.