Dokumen ini memberikan panduan arsitektur untuk membantu Anda mendesain dan mengukur sistem file Lustre untuk workload komputasi berperforma tinggi (HPC). Panduan ini juga memberikan ringkasan tentang proses men-deploy sistem file Lustre di Google Cloud menggunakan DDN EXAScaler.
Lustre adalah sistem file open source paralel yang menyediakan penyimpanan throughput tinggi dan latensi rendah untuk workload HPC yang terkait erat. Anda dapat menskalakan sistem file Lustre untuk mendukung puluhan ribu klien HPC dan penyimpanan berukuran petabyte. EXAScaler Cloud adalah Lustre versi perusahaan yang ditawarkan oleh DDN, partner Google. Anda dapat men-deploy EXAScaler Cloud dalam arsitektur cloud hybrid untuk meningkatkan kapasitas HPC lokal. EXAScaler Cloud juga dapat berfungsi sebagai repositori untuk menyimpan aset jangka panjang dari deployment EXAScaler lokal.
Panduan dalam dokumen ini ditujukan bagi arsitek perusahaan dan praktisi teknis yang mendesain, menyediakan, dan mengelola penyimpanan untuk workload HPC di cloud. Dokumen ini mengasumsikan bahwa Anda memiliki pemahaman konseptual tentang sistem file paralel. Anda juga harus memiliki pemahaman bahwa sistem file paralel seperti Lustre ideal untuk kasus penggunaan HPC. Untuk informasi selengkapnya, lihat Sistem file paralel untuk workload HPC.
Ringkasan sistem file Lustre
Diagram berikut menunjukkan arsitektur sistem file Lustre:
Seperti yang ditunjukkan pada diagram, arsitektur berisi komponen berikut:
Server pengelolaan (MGS) dan target pengelolaan (MGT): MGS menyimpan dan mengelola informasi konfigurasi tentang satu atau beberapa sistem file Lustre. Diagram ini menunjukkan MGS yang mengelola satu sistem file Lustre. MGS memberikan informasi konfigurasi ke komponen Lustre lain di semua sistem file yang dikelolanya. MGS mencatat log konfigurasi sistem file di perangkat penyimpanan yang disebut MGT.
Server metadata (MDS) dan target metadata (MDT): Node MDS mengelola akses klien ke namespace sistem file Lustre. Namespace ini mencakup semua metadata sistem file, seperti hierarki direktori, waktu pembuatan file, dan izin akses. Metadata disimpan di perangkat penyimpanan yang disebut MDT. Sistem file Lustre memiliki setidaknya satu MDS dan satu MDT terkait. Guna meningkatkan performa untuk workload intensif metadata, seperti ketika ribuan klien membuat dan mengakses jutaan file kecil, Anda dapat menambahkan lebih banyak node MDS ke sistem file.
Server penyimpanan objek (OSS) dan target penyimpanan objek (OST): Node OSS mengelola akses klien ke data file yang disimpan dalam sistem file Lustre. Setiap file disimpan sebagai satu atau beberapa objek Lustre. Objek tersebut disimpan di satu perangkat penyimpanan (yang disebut OST) atau dipisahkan ke beberapa node OSS dan OST. Sistem file Lustre memiliki setidaknya satu OSS dan satu OST terkait. Anda dapat menskalakan kapasitas penyimpanan dan performa sistem file dengan menambahkan lebih banyak node OSS dan OST. Total kapasitas penyimpanan sistem file merupakan jumlah kapasitas penyimpanan OST yang terpasang ke semua node OSS dalam sistem file.
Klien: Klien Lustre adalah node komputasi, seperti virtual machine (VM), yang mengakses sistem file Lustre melalui direktori pemasangan. Direktori pemasangan menyediakan namespace terpadu untuk seluruh sistem file. Anda dapat menskalakan sistem file Lustre untuk mendukung akses serentak oleh lebih dari 10,000 klien. Klien Lustre mengakses semua node MDS dan OSS dalam sistem file Lustre secara paralel. Akses paralel ini membantu memaksimalkan performa sistem file. Akses paralel juga membantu mengurangi hotspot penyimpanan, yang merupakan lokasi penyimpanan yang jauh lebih sering diakses daripada lokasi lain. Hotspot biasa digunakan dalam sistem file non-paralel, dan dapat menyebabkan ketidakseimbangan performa di antara klien.
Untuk mengakses sistem file Lustre, klien mendapatkan direktori dan metadata file yang diperlukan dari MDS, lalu membaca atau menulis data lewat berkomunikasi dengan satu atau beberapa node OSS. Lustre memberikan kepatuhan yang erat terhadap semantik POSIX, dan mengizinkan semua klien akses penuh dan paralel ke sistem file.
Untuk informasi selengkapnya tentang sistem file Lustre dan cara kerjanya, lihat dokumentasi Lustre.
Arsitektur Lustre di Google Cloud
Diagram berikut menunjukkan arsitektur untuk men-deploy sistem file Lustre di Google Cloud:
Arsitektur yang ditampilkan dalam diagram ini berisi referensi berikut. Semua resource di-deploy dalam satu project Google Cloud. Resource komputasi dan penyimpanan disediakan dalam satu zona.
VM Compute Engine menghosting node MGS, MDS, dan OSS serta klien Lustre. Anda juga dapat memilih untuk men-deploy klien Lustre di cluster Google Kubernetes Engine, dan men-deploy sistem file di VM Compute Engine.
Arsitektur ini mencakup resource jaringan berikut:
- Satu subnet Virtual Private Cloud (VPC) yang digunakan untuk semua VM.
- Gateway Cloud NAT opsional dan Cloud Router opsional untuk traffic keluar dari VM pribadi ke internet.
- Aturan firewall opsional untuk mengizinkan koneksi masuk SSH ke semua VM dalam topologi.
- Aturan firewall opsional untuk mengizinkan akses HTTP dari internet ke konsol web DDN EXAScaler di MGS.
- Firewall untuk mengizinkan koneksi TCP antara semua VM.
Persistent Disk menyediakan kapasitas penyimpanan untuk node MGS, MDS, dan OSS. Jika tidak memerlukan penyimpanan persisten, Anda dapat membangun sistem file gosok menggunakan disk solid state drive (SSD) lokal yang terpasang pada VM.
Google telah mengirimkan entri IO500 yang menunjukkan performa sistem file Lustre persisten dan gosok. Baca tentang pengiriman Google Cloud yang menunjukkan sistem file gosok berbasis Lustre berbasis 10+ Tbps tentang peringkat sistem penyimpanan HPC IO500.
Pedoman desain
Gunakan panduan berikut untuk mendesain sistem file Lustre yang memenuhi persyaratan workload HPC Anda. Panduan di bagian ini tidak lengkap. Mereka menyediakan framework untuk membantu Anda menilai persyaratan penyimpanan workload HPC Anda, mengevaluasi opsi penyimpanan yang tersedia, dan menyesuaikan ukuran sistem file Lustre Anda.
Persyaratan workload
Identifikasi persyaratan penyimpanan workload HPC Anda. Tentukan persyaratan sedetail mungkin dan pertimbangkan persyaratan Anda di masa mendatang. Gunakan pertanyaan berikut sebagai titik awal untuk mengidentifikasi persyaratan workload Anda:
- Apa saja persyaratan Anda untuk throughput dan operasi I/O per detik (IOPS)?
- Berapa kapasitas penyimpanan yang Anda butuhkan?
- Apa sasaran desain Anda yang paling penting: throughput, IOPS, atau kapasitas penyimpanan?
- Apakah Anda memerlukan penyimpanan persisten, penyimpanan gosok, atau keduanya?
Opsi penyimpanan
Untuk opsi penyimpanan yang paling hemat biaya, Anda dapat memilih dari jenis Persistent Disk berikut:
- Persistent Disk Standar (
pd-standard) adalah opsi yang paling hemat biaya jika kapasitas penyimpanan menjadi tujuan desain utamanya. Jenis ini menyediakan block storage yang efisien dan andal menggunakan hard-disk drive (HDD). - Persistent Disk SSD (
pd-ssd) adalah opsi yang paling hemat biaya jika tujuannya adalah memaksimalkan IOPS. Jenis ini menyediakan block storage yang cepat dan andal menggunakan SSD. - Persistent Disk Seimbang (
pd-balanced) adalah opsi yang paling hemat biaya untuk memaksimalkan throughput. Jenis ini menyediakan block storage yang hemat biaya dan andal dengan menggunakan SSD.
Persistent Disk Ekstrem (pd-extreme) dapat memberikan performa yang lebih tinggi daripada jenis disk lainnya, dan Anda dapat memilih IOPS yang diperlukan. Namun, biaya pd-extreme lebih mahal
daripada jenis disk lainnya.
Untuk mengetahui informasi selengkapnya tentang kemampuan performa Persistent Disk, lihat Performa blok penyimpanan.
Untuk penyimpanan gosok, Anda dapat menggunakan SSD lokal sementara. SSD lokal terpasang secara fisik ke server yang menghosting VM. Jadi, SSD lokal memberikan throughput yang lebih tinggi dan latensi lebih rendah daripada Persistent Disk. Namun, data yang tersimpan di SSD lokal hanya akan dipertahankan sampai VM dihentikan atau dihapus.
Server penyimpanan objek
Saat Anda mendesain infrastruktur untuk node OSS, sebaiknya lakukan hal-hal berikut:
Untuk penyimpanan, pilih jenis Persistent Disk yang sesuai berdasarkan persyaratan Anda untuk kapasitas penyimpanan, throughput, dan IOPS.
- Gunakan
pd-standarduntuk workload yang memiliki persyaratan berikut:- Workload memerlukan kapasitas penyimpanan yang tinggi (misalnya, lebih dari 10 TB), atau memerlukan throughput baca dan kapasitas penyimpanan yang tinggi.
- Latensi I/O tidak penting.
- Throughput tulis yang rendah dapat diterima.
- Gunakan
pd-balanceduntuk workload yang memiliki salah satu dari persyaratan berikut:- Throughput tinggi dengan kapasitas rendah.
- Latensi rendah yang disediakan oleh disk berbasis SSD.
- Gunakan
pd-ssduntuk workload yang memerlukan IOPS tinggi (baik permintaan I/O atau file yang kecil).
- Gunakan
Sediakan kapasitas penyimpanan yang cukup untuk mencapai IOPS yang diperlukan. Pertimbangkan IOPS baca dan tulis yang disediakan oleh setiap jenis disk.
Untuk VM, gunakan jenis mesin dari kelompok mesin N2 atau N2D. Jenis mesin ini memberikan performa yang dapat diprediksi dan hemat biaya.
Alokasikan vCPUs dalam jumlah yang cukup untuk mencapai throughput Persistent Disk yang diperlukan. Throughput Persistent Disk maksimum per VM adalah 1,2 GBps, dan throughput ini dapat dicapai dengan 16 vCPU. Jadi, mulailah dengan jenis mesin yang memiliki 16 vCPU. Pantau performa dan alokasikan lebih banyak vCPU saat Anda perlu menskalakan IOPS.
Server metadata
Node MDS tidak memerlukan kapasitas penyimpanan tinggi untuk menyalurkan metadata, tetapi memerlukan penyimpanan yang mendukung IOPS tinggi. Saat mendesain infrastruktur untuk node MS, sebaiknya lakukan hal berikut:
- Untuk penyimpanan, gunakan
pd-ssdkarena jenis Persistent Disk ini memberikan IOPS tinggi (30 IOPS per GB) meskipun dengan kapasitas penyimpanan rendah. - Sediakan kapasitas penyimpanan yang cukup untuk mencapai IOPS yang diperlukan.
- Untuk VM, gunakan jenis mesin dari kelompok mesin N2 atau N2D. Jenis mesin ini memberikan performa yang dapat diprediksi dan hemat biaya.
- Alokasikan vCPU yang cukup untuk mencapai IOPS yang diperlukan:
- Untuk workload metadata rendah, gunakan 16 vCPU.
- Untuk workload metadata sedang, gunakan 32 vCPU.
- Untuk workload intensif metadata, gunakan 64 vCPU. Pantau performa dan alokasikan lebih banyak vCPU jika diperlukan.
Server pengelolaan
MGS memerlukan resource komputasi minimal. Layanan ini tidak membutuhkan penyimpanan yang besar.
Mulailah dengan jenis mesin kecil untuk VM (misalnya, n2-standard-2) dan
disk pd-ssd 128 GB untuk penyimpanan, lalu
pantau performanya.
Jika respons lambat, alokasikan lebih banyak vCPU dan tingkatkan ukuran disk.
Ketersediaan dan ketahanan
Jika Anda memerlukan penyimpanan persisten, jenis Persistent Disk pd-standard dan pd-balanced menyediakan penyimpanan dengan ketersediaan tinggi dan tahan lama dalam suatu zona. Untuk persistensi lintas zona atau lintas region, Anda dapat menyalin data ke Cloud Storage berbiaya rendah menggunakan Google Cloud CLI atau Storage Transfer Service.
Untuk mengurangi biaya penyimpanan data di Cloud Storage, Anda dapat menyimpan
data yang jarang diakses di bucket
kelas
Nearline storage
atau
Coldline storage.
Jika Anda hanya memerlukan penyimpanan sementara untuk deployment awal, gunakan SSD lokal sebagai disk data untuk node OSS dan MDS. Desain ini memberikan performa tinggi dengan jumlah VM OSS yang paling sedikit. Desain ini juga membantu Anda mencapai rasio biaya terhadap performa yang optimal jika dibandingkan dengan opsi lainnya.
Contoh ukuran untuk VM OSS
Strategi yang direkomendasikan untuk mengukur dan menyediakan sistem file Lustre Anda adalah dengan menyediakan VM OSS yang cukup untuk memenuhi persyaratan throughput secara keseluruhan. Kemudian, tingkatkan kapasitas penyimpanan disk OST hingga Anda mencapai kapasitas penyimpanan yang diperlukan. Contoh workload yang digunakan di bagian ini menunjukkan cara menerapkan strategi ini dengan mengikuti langkah-langkah berikut:
- Menentukan persyaratan workload.
- Pilih jenis Persistent Disk.
- Menghitung jumlah VM OSS.
- Menghitung ukuran disk per VM.
- Menentukan jumlah vCPU per VM.
Menentukan persyaratan workload
Dalam contoh ini, workload memerlukan penyimpanan persisten berkapasitas 80 TB dengan throughput baca 30 GBps.
Pilih jenis Persistent Disk
Seperti dibahas di bagian
Opsi penyimpanan,
pd-standard adalah opsi paling hemat biaya jika kapasitas penyimpanan
merupakan sasaran utama desain, dan pd-balanced adalah opsi paling hemat biaya untuk
memaksimalkan throughput. Throughput maksimum berbeda untuk setiap jenis disk
dan dapat diskalakan sesuai dengan ukuran disk.
Untuk setiap jenis Persistent Disk yang dapat digunakan untuk beban kerja ini, hitung kapasitas penyimpanan yang diperlukan untuk menskalakan throughput baca ke target 30 GBps.
| Jenis disk | Throughput baca per TB | Kapasitas penyimpanan yang diperlukan untuk mencapai throughput target |
|---|---|---|
pd-standard |
0.12 GBps | 30 dibagi 0.12 = 250 TB |
pd-balanced |
0.28 GBps | 30 dibagi 0.28 = 107 TB |
Untuk mencapai target throughput baca sebesar 30 Gbps dengan menggunakan pd-standard, Anda
harus menyediakan kapasitas penyimpanan sebesar 250 TB. Jumlah ini melebihi tiga kali
kapasitas yang diperlukan, yaitu 80 TB. Jadi untuk workload dalam contoh ini,
pd-balanced menyediakan penyimpanan hemat biaya yang memenuhi persyaratan
performa.
Menghitung jumlah VM OSS
Throughput baca maksimum per VM Compute Engine adalah 1.2 GBps. Untuk mencapai target throughput baca sebesar 30 GBps, bagi target throughput baca dengan throughput maksimum per VM seperti berikut:
30 GBps / 1.2 GBps = 25
Anda memerlukan 25 VM OSS untuk mencapai target throughput baca.
Menghitung ukuran disk per VM
Untuk menghitung ukuran disk per VM, bagi kapasitas (107 TB) yang diperlukan untuk mencapai throughput target (30 GBps) dengan jumlah VM seperti berikut:
107 TB / 25 VMs = 4.3
Anda memerlukan kapasitas pd-balanced sebesar 4.3 TB per VM.
Menentukan jumlah vCPU per VM
Throughput baca VM diskalakan sesuai dengan jumlah vCPU yang dialokasikan ke
VM. Throughput baca mencapai puncak pada 1.2 Gbps untuk 16 vCPU atau lebih. Anda memerlukan
jenis mesin
yang menyediakan setidaknya 16 vCPU. Jadi, pilih jenis mesin dari kelompok mesin
N2 atau N2D, seperti n2-standard-32.
Ringkasan konfigurasi
Contoh workload memiliki persyaratan berikut:
- Penyimpanan persisten berkapasitas 80 TB
- Throughput baca 30 Gbps
Untuk memenuhi persyaratan workload ini, Anda memerlukan resource komputasi dan penyimpanan berikut:
- Jumlah VM OSS: 25
- Kelompok mesin VM: N2 atau N2D
- Jumlah vCPU per VM: 16 atau lebih
- Jenis Persistent Disk:
pd-balanced - Ukuran disk per VM: 4.3 TB
Contoh konfigurasi untuk sistem file gosok
Konfigurasi berikut didasarkan pada pengiriman Google Cloud ke IO500 yang menunjukkan performa sistem file gosok berskala besar yang menggunakan Lustre dan di-deploy di Google Cloud:
| Parameter konfigurasi | MDS | OSS | Klien |
|---|---|---|---|
| Jumlah VM | 50 | 200 | 1.000 |
| Machine type | n2-standard-80 |
n2-standard-64 |
c2-standard-16 |
| Jumlah vCPU per VM | 80 vCPU | 64 vCPU | 16 vCPU |
| RAM per VM | 320 GB | 256 GB | 64 GB |
| OS | CentOS 8 | CentOS 8 | CentOS 8 |
| Bandwidth jaringan | 100 Gbps | 75 Gbps | 32 Gbps |
| Penyimpanan SSD lokal | NVMe 9 TB (24 disk) |
NVMe 9 TB (24 disk) |
Tidak ada |
Konfigurasi sebelumnya memberikan performa berikut:
| Metrik performa | Hasil |
|---|---|
| Throughput tulis | 700 GBps (5.6 Tbps) |
| Throughput baca | 1,270 GBps (10,16 Tbps) |
Operasi file stat() |
1.9 juta per detik |
| Pembacaan file kecil (3,901 byte) | 1.5 juta per detik |
Opsi penerapan
Bagian ini memberikan ringkasan metode yang dapat Anda gunakan untuk men-deploy sistem file EXAScaler Cloud di Google Cloud. Bagian ini juga menguraikan langkah-langkah yang harus diikuti saat Anda men-deploy VM klien.
Deployment sistem file EXAScaler Cloud
Anda dapat memilih dari metode berikut untuk men-deploy sistem file EXAScaler Cloud di Google Cloud:
Deploy dengan menggunakan solusi Google Cloud Marketplace yang disediakan oleh DDN.
Deploy dengan menggunakan Cloud HPC Toolkit. Toolkit ini menyertakan blueprint yang menggunakan modul Terraform yang disediakan oleh DDN untuk men-deploy sistem file I/O tinggi.
Anda dapat menyesuaikan sistem file saat men-deploy menggunakan salah satu dari kedua metode tersebut. Misalnya, Anda dapat menentukan jumlah VM OSS, jenis mesin untuk VM, jenis Persistent Disk, dan kapasitas penyimpanan.
Saat memilih metode, pertimbangkan perbedaan berikut:
Modifikasi pasca-deployment: Jika menggunakan Cloud HPC Toolkit, Anda dapat mengubah sistem file secara efisien setelah deployment. Misalnya, Anda dapat meningkatkan jumlah node OSS dengan mengupdate blueprint Cloud HPC Toolkit dan kembali menerapkan konfigurasi Terraform yang telah dibuat untuk menambahkan kapasitas penyimpanan. Untuk daftar parameter yang dapat Anda tentukan dalam blueprint, lihat bagian Input di README untuk modul Terraform. Untuk mengubah sistem file yang di-deploy menggunakan solusi Cloud Marketplace, Anda harus mengubah resource komputasi dan penyimpanan satu per satu dengan menggunakan konsol Google Cloud, gcloud CLI, atau API.
Dukungan: Solusi Cloud Marketplace menggunakan Deployment Manager, yang tidak didukung oleh Kontrol Layanan VPC. Untuk informasi selengkapnya tentang batasan ini, lihat produk yang didukung dan batasan Kontrol Layanan VPC.
Deployment klien
Anda dapat menggunakan salah satu metode yang dijelaskan di bagian deployment sistem file EXAScaler Cloud untuk men-deploy VM klien. Namun, Google merekomendasikan agar Anda menyediakan dan mengelola VM klien secara terpisah dari sistem file. Cara yang direkomendasikan untuk men-deploy klien Anda adalah dengan menggunakan image VM HPC yang disediakan Google dan dioptimalkan untuk workload HPC.
Berikut adalah ringkasan proses penggunaan image VM HPC untuk men-deploy klien Lustre:
- Buat VM menggunakan image VM HPC.
- Instal paket klien Lustre di VM.
- Sesuaikan VM sesuai kebutuhan.
- Buat image kustom dari VM.
- Sediakan VM klien Lustre menggunakan image kustom yang Anda buat. Untuk mengotomatiskan penyediaan dan pengelolaan VM klien, Anda dapat menggunakan grup instance terkelola Compute Engine atau alat pihak ketiga seperti Slurm Workload Manager.
- Instal sistem file Lustre di VM klien.
Opsi transfer data
Setelah men-deploy sistem file Lustre di Google Cloud, Anda harus memindahkan data ke sistem file. Tabel berikut menunjukkan metode yang dapat Anda gunakan untuk memindahkan data ke sistem file Lustre. Pilih metode yang sesuai dengan volume data yang perlu dipindahkan dan lokasi data sumber Anda (lokal atau di Cloud Storage).
| Sumber data | Ukuran data | Metode transfer data yang direkomendasikan |
|---|---|---|
| Lokal | Kecil (misalnya, kurang dari 1 TB) | Lakukan tahapan data di Cloud Storage menggunakan alat gsutil. Kemudian, download data ke sistem file Lustre menggunakan Storage Transfer Service atau gcloud CLI. |
| Lokal | Besar | Pindahkan data ke sistem file Lustre menggunakan
Storage Transfer Service. Ikuti petunjuk di Mentransfer data antar-sistem file
POSIX.
Metode ini melibatkan penggunaan bucket Cloud Storage perantara. Setelah menyelesaikan tugas transfer, Storage Transfer Service akan menghapus data di bucket perantara. |
| Cloud Storage | Besar atau kecil | Download data dari Cloud Storage ke sistem file Lustre menggunakan Storage Transfer Service atau gcloud CLI. |
Langkah selanjutnya
- Pelajari lebih lanjut tentang Lustre.
- Pelajari lebih lanjut tentang DDN EXAScaler Cloud dan kemitraan DDN dengan Google.
- Baca tentang pengiriman Google Cloud yang menunjukkan sistem file gosok berbasis Lustre berbasis 10+ Tbps tentang peringkat sistem penyimpanan HPC IO500.
- Deploy DDN EXAScaler di Google Cloud seperti yang dijelaskan di bagian Deployment sistem file EXAScaler Cloud dalam dokumen ini.
Kontributor
Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk
Kontributor lainnya:
- Carlos Boneti | Staf Software Engineer Senior
- Dean Hildebrand | Direktur Teknis
- Sean Derrington | Group Outbound Product Manager