Halaman ini menjelaskan pola arsitektur untuk beban kerja otomatisasi desain elektronik (EDA) di Google Cloud NetApp Volumes.
NetApp Volumes menyediakan penyimpanan bersama NFS yang sangat skalabel untuk mendukung workload EDA. Beban kerja ini memproses set data skala petabyte yang terdiri dari jutaan file kecil, menjalankan operasi direktori yang berat metadata, dan mendorong I/O paralel yang bergejolak di ribuan core komputasi. NetApp Volumes menjaga agar library desain, toolchain, dan data sementara dapat diakses dengan menskalakan dari volume berukuran project hingga volume berkapasitas besar, dengan FlexCache opsional untuk desain hibrida dan fan-out. Pola berikut memetakan model deployment EDA umum ke kemampuan ini.
Untuk implementasi referensi GitHub, seperti eda-all-on-cloud dan
eda-hybrid-cloud, lihat contoh EDA Cluster Toolkit.
Pola arsitektur
Tabel berikut merangkum pola umum untuk workload EDA. Pola terbaik untuk kasus penggunaan Anda bergantung pada lokasi data utama Anda dan cara Anda ingin menskalakan performa baca dan komputasi.
| Pola | Kasus penggunaan | Kemampuan utama NetApp Volumes |
|---|---|---|
| Volume berkapasitas besar untuk cluster komputasi | Data desain dan toolchain berada di Google Cloud dan memerlukan satu namespace bersama dalam skala besar | Volume dan gabungan berkapasitas besar, tata letak multi-volume, dan siklus proses grup deployment |
| Burst ke cloud | Set data utama berada di infrastruktur lokal atau di region lain, dan Anda memerlukan komputasi cloud untuk permintaan puncak | FlexCache dari asal ONTAP lokal, pengisian awal, dan volume yang sudah ada |
| Penskalaan performa melalui cache fan-out | Fase yang banyak membaca memerlukan throughput atau lokalitas gabungan yang lebih besar daripada yang dapat disediakan oleh satu ekspor | Beberapa volume FlexCache atau beberapa endpoint penyimpanan per volume besar |
Menggunakan volume berkapasitas besar sebagai penyimpanan file untuk cluster komputasi
Gunakan pola ini saat komputasi dan data persisten berjalan di Google Cloud, misalnya, farm EDA greenfield, pusat desain yang dimigrasikan, atau partisi cloud burst khusus yang memiliki set datanya.
Tantangan yang diselesaikan oleh volume berkapasitas besar
Volume berkapasitas besar memenuhi persyaratan kapasitas, performa, dan konkurensi tinggi untuk workload EDA skala besar. Konfigurasi ini mengatasi tantangan berikut:
Batasan kapasitas: Menampung set kerja besar, seperti pustaka, blok IP, dan data sementara regresi.
Beban I/O dan metadata tinggi: Menangani jalur metadata intensif (termasuk operasi
readdirdanstat), I/O acak kecil, dan bandwidth berurutan tinggi.
Tata letak yang direkomendasikan
Daripada menempatkan semua data Anda ke dalam satu volume besar, partisi data Anda di beberapa volume berdasarkan siklus proses dan pola aksesnya.
Tabel berikut menjelaskan tata letak yang direkomendasikan untuk mempartisi data Anda:
| Peran volume | Jenis data umum | Pola akses dan siklus proses |
|---|---|---|
| Alat | Biner vendor dan penginstalan EDA berlisensi | Ekspor yang sebagian besar dibaca, retensi panjang, dan stabil |
| Library | PDK, sel standar, dan desain referensi | Sebagian besar baca, jumlah file besar, dan manfaat dari penyesuaian cache atribut pada klien |
| Beranda | Dotfile pengguna dan status project kecil | Kecepatan baca/tulis dan metadata sedang |
| Menggaruk | Direktori yang dijalankan dan hasil sementara | Churn tinggi, kapasitas terbesar, dan permintaan IOPS tertinggi |
Blueprint Cluster Toolkit eda-all-on-cloud menyediakan tata letak ini dengan partisi Compute Engine yang dikelola Slurm yang memasang NetApp Volumes melalui NFS.
Kapan harus menggunakan volume berkapasitas besar
Untuk volume yang lebih besar dari 4,8 TiB (Flex Unified) atau 15 TiB (Premium dan Extreme), buat volume berkapasitas besar. Volume ini dapat diskalakan ke kapasitas yang sangat besar dan memberikan throughput dan batas IOPS yang lebih tinggi. Volume sementara dan library yang melebihi batas endpoint tunggal cocok untuk konfigurasi ini.
Distribusi klien pada volume besar
Volume berkapasitas besar mengekspos beberapa endpoint penyimpanan (alamat IP) ke ekspor yang sama. Mendistribusikan klien NFS di beberapa endpoint untuk menskalakan throughput gabungan dan mencegah satu alamat IP menjadi penyebab bottleneck. Anda dapat menggunakan salah satu opsi berikut:
DNS round-robin (direkomendasikan dalam skala besar): Buat data A Cloud DNS yang mencantumkan beberapa alamat IP. Lakukan pemasangan menggunakan FQDN sehingga setiap klien di-resolve ke satu alamat pada waktu pemasangan. Pasang kembali jika Anda mengubah data DNS.
Sharding statis: Membagi klien ke dalam beberapa grup dan memasang setiap grup ke endpoint yang dipilih untuk penempatan beban deterministik.
Dalam arsitektur semua di cloud, Anda menyediakan ekspor NetApp Volumes terpisah di satu region Google Cloud untuk alat, library, dan scratch. Alat dan library menyimpan data referensi yang sebagian besar hanya dibaca;
scratch menyimpan direktori dan checkpoint yang dijalankan dan sering kali merupakan volume
berkapasitas besar. Node Compute Engine yang dikelola Slurm di VPC yang sama memasang setiap ekspor menggunakan NFS. Penyimpanan di-deploy dalam grup deployment base dan komputasi dalam grup cluster untuk memungkinkan Anda menskalakan atau menghapus cluster tanpa menghapus volume.
Burst ke cloud
Gunakan pola ini saat data desain otoritatif tetap berada di lokal atau di sistem ONTAP jarak jauh dan Anda ingin menjalankan tugas regresi, karakterisasi, atau kapasitas puncak pada Google Cloud compute tanpa menyalin seluruh library terlebih dahulu.
Mengatasi tantangan penyimpanan hybrid cloud dengan FlexCache
Volume FlexCache menyelesaikan tantangan penyimpanan hybrid cloud umum untuk lingkungan EDA dengan memberikan manfaat berikut:
Performa akses seperti LAN: Latensi dan bandwidth WAN membatasi seberapa cepat core komputasi cloud dapat membaca set data lokal. FlexCache melayani fase yang banyak membaca dan operasi metadata secara lokal setelah set kerja di-cache untuk mengatasi masalah ini.
Caching tingkat blok sesuai permintaan: Menyalin seluruh library ke cloud sebelum setiap pekerjaan akan menyebabkan penundaan saat memulai dan duplikasi penyimpanan. FlexCache hanya meng-cache blok data yang diakses, sehingga meminimalkan waktu mulai dan mengurangi penggunaan penyimpanan cloud secara keseluruhan.
Sumber asal yang kohesif: Alih-alih mengelola salinan data yang terputus, Anda dapat menggunakan ekspor NFS lokal di cloud dan tetap mempertahankan satu salinan yang koheren di volume asal lokal.
Perilaku dan karakteristik FlexCache
Anda membuat volume FlexCache di NetApp Volumes yang mengarah ke volume asal ONTAP yang ada. Pembacaan data yang di-cache ditayangkan oleh Google Cloud. Bacaan dingin mengambil blok dari volume asal ONTAP sekali, lalu menyajikannya secara lokal. Secara default, operasi tulis menggunakan tulis-putar: cache meneruskan operasi tulis ke origin dan membatalkan validasi data yang di-cache yang terpengaruh, yang mempertahankan koherensi di seluruh cache.
Berikut adalah karakteristik utama FlexCache untuk lingkungan EDA:
Caching tingkat blok hanya tarik: Hanya data yang diakses yang menggunakan kapasitas cache. Volume jarang efisien untuk library besar yang diakses sebagian per proses.
Pembacaan yang koheren dan terkini: Data yang dibaca dari cache atau asal konsisten. Pendekatan ini cocok untuk library referensi bersama jika pola penulisan sesuai dengan panduan FlexCache.
Latensi baca seperti LAN setelah pemanasan: Fase baca yang berat metadata dan berat throughput, seperti penelusuran pustaka dan file referensi berulang, akan diuntungkan setelah set kerja di-cache.
Pengisian otomatis: Untuk menghindari penalti baca dingin pada akses pertama, isi otomatis direktori untuk daftar proses yang diketahui sebelum memulai tugas.
Cetak biru referensi hybrid
eda-hybrid-cloud
memasang volume yang sudah ada sebelumnya, seperti tools, library, home, dan scratch, menggunakan
pre-existing-network-storage. Volume dapat berupa ekspor NetApp Volumes standar, volume berkapasitas besar, atau volume FlexCache. Penyediaan penyimpanan di luar blueprint cluster menghindari penghapusan yang tidak disengaja saat Anda menghentikan komputasi dan mendukung asal FlexCache yang Anda kelola di ONTAP.
Perhatikan panduan operasional berikut:
Ukur volume cache untuk set kerja, bukan kapasitas volume asal penuh.
Nonaktifkan atau batasi update waktu akses pada volume asal (
-atime-updatedi ONTAP) untuk menghindari invalidasi cache yang tidak perlu. Untuk mengetahui informasi selengkapnya, lihat ringkasan FlexCache.Aktifkan penguncian file global hanya jika alur Anda memerlukan semantik tolak-baca lintas-cache yang ketat. Pendekatan ini menambahkan latensi dan menggabungkan ketersediaan ke link asal.
Rencanakan konektivitas dan bandwidth jaringan antara asal dan Google Cloud. Fase yang banyak menulis tetap terikat oleh link asal atau jaringan saat Anda menggunakan write-around.
Dalam arsitektur baca-burst hybrid, alat dan data library yang otoritatif berada di sistem ONTAP lokal. NetApp Volumes menghosting volume FlexCache di Google Cloud yang mereferensikan origin tersebut menggunakan WAN atau link pribadi. Node Slurm di Google Cloud memasang ekspor FlexCache. Pembacaan ditayangkan dari cache saat data sudah siap; pembacaan dingin mengambil blok dari origin lokal. Untuk scratch dan titik pemeriksaan yang menerima traffic tulis berat dari komputasi cloud, buat volume scratch berbasis cloud terpisah di region yang sama dengan cluster untuk mempertahankan penulisan secara lokal, bukan merutekan traffic tulis berkelanjutan melalui FlexCache dengan asal lokal.
Penskalaan performa melalui cache fan-out
Gunakan pola ini saat satu ekspor, bahkan volume berkapasitas besar, tidak memberikan throughput baca gabungan atau fan-out klien yang memadai untuk satu fase alur.
Anda dapat menerapkan fan-out dengan dua cara:
Volume FlexCache fan-out
Buat beberapa volume FlexCache yang didukung oleh volume asal yang sama, dan pasang kumpulan komputasi (atau jenis tugas) yang berbeda pada cache yang berbeda. Setiap cache di-warm-up secara independen, menskalakan I/O baca di seluruh endpoint NetApp Volumes yang terpisah, dan mengisolasi thrash antar-workload, misalnya, pra-pemrosesan library versus regresi panjang.
Tabel berikut membandingkan pendekatan deployment FlexCache tunggal dan ganda.
| Pendekatan | Timbangan | Kompromi |
|---|---|---|
| FlexCache Tunggal | Kesederhanaan, satu jalur pemasangan | Satu kapasitas cache dan batas throughput |
| Beberapa FlexCache (fan-out) | Throughput baca yang di-cache gabungan; isolasi per kumpulan | Lebih banyak volume untuk dikelola; set kerja dibagi di seluruh cache |
| Hanya origin (tanpa cache) | Koherensi penulisan terkuat ke satu situs | Latensi WAN untuk komputasi cloud |
Jika Anda mengetahui input tugas sebelumnya, gunakan pengisian otomatis di setiap cache fan-out.
Fan-out pada volume berkapasitas besar dengan beberapa endpoint
Volume berkapasitas besar dan volume FlexCache dalam skala besar mengekspos beberapa alamat IP per volume. Perlakukan setiap IP sebagai endpoint penyimpanan dengan anggaran slot koneksi sendiri.
Jika Anda memiliki ratusan atau ribuan klien NFS, pertimbangkan hal berikut:
Entri tabel slot RPC per klien yang lebih rendah: Misalnya, 8 slot per klien di NFSv3, sehingga total operasi yang belum selesai per endpoint tetap berada dalam batas yang direkomendasikan (sekitar 10.000 slot per endpoint di seluruh farm). Untuk mengetahui informasi selengkapnya, lihat Konkurensi NFS Linux.
Sebarkan pemasangan di seluruh endpoint: Gunakan round robin Cloud DNS atau sharding statis.
Untuk menerapkan fan-out FlexCache, gunakan satu volume asal (ONTAP lokal atau volume mode ONTAP cloud) untuk mendukung beberapa volume FlexCache di NetApp Volumes. Pasang setiap cache menggunakan konsumen yang berbeda, seperti partisi Slurm atau class tugas, untuk mengisolasi set kerja dan beban baca di seluruh ekspor.
Untuk menerapkan fan-out multi-endpoint, gunakan satu volume berkapasitas besar yang mengekspos ekspor NFS yang sama di beberapa alamat IP. Sebarkan klien di seluruh endpoint tersebut dengan menetapkan grup klien tetap ke setiap alamat IP, atau dengan memasang nama DNS yang di-resolve ke satu alamat per pemasangan. Setiap endpoint memiliki anggaran koneksinya sendiri; mendistribusikan klien membantu menghindari konsentrasi I/O di seluruh farm pada satu alamat IP.
Menggabungkan pola
Untuk lingkungan EDA produksi, Anda dapat menggabungkan pola arsitektur ini untuk mengoptimalkan performa:
Semua di cloud: Gunakan volume sementara berkapasitas besar serta volume standar yang lebih kecil untuk alat dan rumah.
Hybrid: Menggunakan FlexCache untuk library dan alat, dengan volume sementara yang disediakan cloud untuk output tugas.
Fan-out: Gunakan FlexCache per situs atau per antrean scheduler, ditambah DNS multi-endpoint untuk volume sementara besar yang berbasis cloud.
Sesuaikan tingkat layanan volume dan jenis pool (Flex Unified reguler versus kapasitas besar) dengan kebutuhan kapasitas dan performa setiap tingkat. Untuk mengetahui informasi selengkapnya, lihat tingkat layanan.