電子設計自動化 (EDA) に Azure NetApp Files を使用するメリット
イノベーションは、半導体業界の顕著な特徴です。 このイノベーションにより、1965 年に Gordon Moore が示した、処理速度は 1 から 2 年ごとに約 2 倍になることが期待できるという、ムーアの法則として知られる見解は、50 年以上にわたって真実であると見なされてきました。 たとえば、半導体業界のイノベーションは、チップを小さなフォーム ファクターに積み重ね、並列処理を行って、かつては想像できなかったレベルまで性能を拡張することで、ムーアの法則を進化させてきました。
半導体 (または電子設計自動化 [EDA]) 企業は、市場投入までの時間 (TTM) に最も高い関心を持っています。 TTM は、多くの場合、チップ設計の検証やテープアウトなどのファウンドリ前の作業が完了するまでの、ワークロードにかかる時間を前提としています。 TTM の懸念は、EDA のライセンス コストを削減するのにも役立ちます。作業に費やす時間が短いほど、ライセンスに使用できる時間が長くなります。 つまり、サーバー ファームで使用できる帯域幅と容量が多いほど良いことになります。
Azure NetApp Files は、高パフォーマンスな並列化されたファイル システム ソリューションである Azure NetApp Files 大容量ボリュームを使用して、EDA ジョブにかかる時間を短縮するのに役立ちます。 最近の EDA ベンチマーク テストでは、単一の Azure NetApp Files 通常ボリュームで以前に達成できていたパフォーマンスの 20 倍を、単一の大容量ボリュームで達成できることが示されています。
次に示す特長を備えた Azure NetApp Files 大容量ボリューム機能は、この最も要求の厳しい業界のストレージ ニーズに最適です。
大容量の単一名前空間: 各ボリュームは、1 つのマウント ポイントで最大 500 TiB の使用可能な容量を提供します。
高い I/O レート、短い待機時間: EDA シミュレーション ベンチマークを使用したテストでは、単一の大容量ボリュームで、650,000 回を超えるストレージ IOPS と、2 ミリ秒未満のアプリケーション待機時間が達成されました。 一般的な EDA ワークロードでは、IOPS は、ファイルの作成、読み取り、書き込み、その他の大量のメタデータ操作、またはそれらの組み合わせで構成されます。 この結果は、多くのお客様からエンタープライズ レベルのパフォーマンスと見なされています。 このパフォーマンスの向上は、大容量ボリュームが、Azure NetApp Files 内のストレージ リソース間で受信する書き込み操作を並列化できることで実現されます。 多くの企業では 2 ミリ秒またはそれ以下の応答時間が求められますが、チップ設計ツールでは、ビジネスに影響を与えることなく、これより長い待機時間を許容できます。
1 秒あたり 826,000 回の操作: 単一の大容量ボリュームのパフォーマンス エッジであるアプリケーション層のテストでは、待機時間が 7 ミリ秒に達しました。これは、わずかな待機時間を犠牲にすることで、単一の大容量ボリュームでより多くの操作を実行できることを示しています。
EDA ベンチマークを使用して実施されたテストでは、単一の Azure NetApp Files 通常ボリュームでは、2 ミリ秒で最大 40,000 IOPS のワークロードを達成でき、エッジで 50,000 を達成できることがわかりました。 通常および大規模ボリュームを左右に並べて表示した概要については、次の表とグラフを参照してください。
| シナリオ | 2 ミリ秒の待機時間での I/O レート | パフォーマンス エッジでの I/O レート (最大 7 ミリ秒) | 2 ミリ秒の待機時間での MiB/秒 | MiB/秒のパフォーマンス エッジ (最大 7 ミリ秒) |
|---|---|---|---|---|
| 1 つの通常ボリューム | 39,601 | 49,502 | 692 | 866 |
| 大容量ボリューム | 652,260 | 826,379 | 10,030 | 12,610 |
次のグラフは、テスト結果を示しています。
通常ボリュームのテストでは、単一エンドポイントの制限も調べ、6 つのボリュームで制限に達しました。 大容量ボリュームは、6 つの通常ボリュームのシナリオの 260% のパフォーマンスを達成しました。 これらの結果を次の表に示します。
| シナリオ | 2 ミリ秒の待機時間での I/O レート | パフォーマンス エッジでの I/O レート (最大 7 ミリ秒) | 2 ミリ秒の待機時間での MiB/秒 | MiB/秒のパフォーマンス エッジ (最大 7 ミリ秒) |
|---|---|---|---|---|
| 6 つの通常ボリューム | 255,613 | 317,000 | 4,577 | 5,688 |
| 1 つの大容量ボリューム | 652,260 | 826,379 | 10,030 | 12,610 |
大規模でシンプル
大容量ボリュームで問題になるのはパフォーマンスだけではありません。 シンプルなパフォーマンスが最終目標です。 お客様は、使いやすさとアプリケーション管理のために、複数のボリュームを管理するのではなく、単一の名前空間/マウント ポイントを好みます。
テスト ツール
このテストの EDA ワークロードは、標準の業界ベンチマーク ツールを使用して生成されました。 半導体チップの設計に使用される EDA アプリケーションを組み合わせてシミュレートします。 EDA ワークロードの分散を次に示します。
| EDA フロントエンド操作の種類 | 対全体比率 |
|---|---|
| 統計 | 39% |
| アクセス | 15% |
| Random_write | 15% |
| Write_file | 10% |
| Random_read | 8% |
| Read_file | 7% |
| 作成 | 2% |
| Chmod | %1 |
| Mkdir | %1 |
| Ulink | %1 |
| Ulink2 | %1 |
|
0% |
| EDA バックエンド操作の種類 | 対全体比率 |
|---|---|
| 読み込み | 50% |
| 書き込み | 50% |
|
0% |
テスト構成
結果は、次の構成の詳細を使用して生成されました。
| コンポーネント | 構成 |
|---|---|
| オペレーティング システム | RHEL 9.3 / RHEL 8.7 |
| インスタンスの種類 | D16s_v5 |
| Instance Count | 10 |
| マウント オプション | nocto,actimeo=600,hard,rsize=262144,wsize=262144,vers=3,tcp,noatime,nconnect=8 |
| クライアントの調整可能な設定 | # Network parameters.In unit of bytes |
マウント オプション nocto、noatime、actimeo=600 を組み合わせて使用して、NFSv3 プロトコルを介した EDA ワークロードの一部のメタデータ操作の影響を軽減します。 これらのマウント オプションは、実行されるメタデータ操作の数を減らし、クライアントで一部のメタデータ属性をキャッシュすることで、そうしなかった場合よりも先に EDA ワークロードをプッシュできるようにします。 これらのマウント オプションは一般に適用可能ではないため、個々のワークロード要件を考慮することが不可欠です。 詳細については、「Azure NetApp Files 用の Linux NFS マウント オプションのベスト プラクティス」を参照してください。
まとめ
EDA ワークロードには、数千に上るクライアント ワークステーションにわたって、多数のファイル、大容量、多数の並列操作を処理できるファイル ストレージが必要です。 また、EDA ワークロードには、テストと検証の完了にかかる時間を短縮し、ライセンスのコストを削減し、最新かつ最も優れたチップセットの市場投入までの時間を短縮するレベルのパフォーマンスが求められます。 Azure NetApp Files 大容量ボリュームは、オンプレミスのデプロイで見られるのと同等のパフォーマンスで EDA ワークロードの要求を処理できます。