Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Amazon FSx untuk kinerja Lustre Bab ini menyediakan Amazon FSx untuk topik kinerja Lustre, termasuk beberapa tips dan rekomendasi penting untuk memaksimalkan kinerja sistem file Anda. **Topics** + [Ikhtisar](#performance-overview) + [Cara FSx kerja sistem file Lustre](#how-lustre-fs-work) + [Kinerja metadata sistem file](#dne-metadata-performance) + [Throughput ke instance klien individu](#throughput-clients) + [Layout penyimpanan sistem file](#storage-layout) + [Sedang melakukan stripe data di sistem file Anda](#striping-data) + [Memantau performa dan penggunaan](#performance-monitoring) + [Karakteristik kinerja kelas penyimpanan SSD dan HDD](ssd-storage.md) + [Karakteristik kinerja kelas penyimpanan Intelligent-Tiering](intelligent-tiering-file-systems.md) + [Tips performa](performance-tips.md) ## Ikhtisar Amazon FSx for Lustre, dibangun di atasLustre, sistem file berkinerja tinggi yang populer, memberikan kinerja scale-out yang meningkat secara linier dengan ukuran sistem file. Lustreskala sistem file secara horizontal di beberapa server file dan disk. Penskalaan ini memberikan setiap klien akses langsung ke data yang disimpan pada setiap disk untuk menghapus banyaknya kemacetan yang ada dalam sistem file tradisional. Amazon FSx for Lustre dibangun di atas arsitektur yang Lustre dapat diskalakan untuk mendukung kinerja tingkat tinggi di sejumlah besar klien. ## Cara FSx kerja sistem file Lustre Masing-masing FSx untuk sistem file Lustre terdiri dari server file yang klien berkomunikasi dengan, dan satu set disk yang dilampirkan ke setiap file server yang menyimpan data Anda. Setiap server file menggunakan cache dalam memori untuk meningkatkan performa untuk data yang diakses paling sering. Tergantung pada kelas penyimpanan, server file Anda dapat disediakan dengan cache baca SSD opsional. Ketika klien mengakses data yang disimpan di cache dalam memori atau cache SSD, server file tidak perlu membacanya dari disk, yang mana akan mengurangi latensi dan meningkatkan jumlah total throughput yang dapat Anda drive. Diagram berikut menggambarkan jalur operasi tulis, operasi baca yang disajikan dari disk, dan operasi baca yang disajikan dari cache dalam memori atau SSD. ![\[FSx untuk arsitektur kinerja Lustre.\]](http://docs.aws.amazon.com/id_id/fsx/latest/LustreGuide/images/LustrePerfDiagram.png) Ketika Anda membaca data yang disimpan di cache dalam-memori atau cache SSD pada server file, performa sistem file ditentukan oleh throughput jaringan. Ketika Anda menulis data ke sistem file Anda, atau ketika Anda membaca data yang tidak disimpan pada cache dalam memori, kinerja sistem file ditentukan oleh yang lebih rendah dari throughput jaringan dan throughput disk. Untuk mempelajari lebih lanjut tentang throughput jaringan, throughput disk, dan karakteristik IOPS dari kelas penyimpanan SSD dan HDD, lihat dan. [Karakteristik kinerja kelas penyimpanan SSD dan HDD](ssd-storage.md) [Karakteristik kinerja kelas penyimpanan Intelligent-Tiering](intelligent-tiering-file-systems.md) ## Kinerja metadata sistem file Sistem file metadata operasi IO per detik (IOPS) menentukan jumlah file dan direktori yang dapat Anda buat, daftar, baca, dan hapus per detik. Sistem file 2 persisten memungkinkan Anda untuk menyediakan Metadata IOPS independen dari kapasitas penyimpanan dan memberikan peningkatan visibilitas ke dalam jumlah dan jenis metadata yang ditargetkan oleh instans klien IOPS di sistem file Anda. Dengan sistem file SSD, Metadata IOPS secara otomatis disediakan berdasarkan kapasitas penyimpanan yang Anda berikan. Mode otomatis tidak didukung pada sistem file Intelligent-Tiering. Dengan FSx sistem file Lustre Persistent 2, jumlah IOPS Metadata yang Anda sediakan dan jenis operasi metadata menentukan tingkat operasi metadata yang dapat didukung oleh sistem file Anda. Tingkat IOPS metadata yang Anda berikan menentukan jumlah IOPS yang disediakan untuk disk metadata sistem file Anda. | Jenis operasi | Operasi yang dapat Anda kendarai per detik untuk setiap metadata yang disediakan IOPS | | --- | --- | | Membuat File, Buka dan Tutup | 2 | | Hapus File | 1 | | Direktori Buat, Ganti Nama | 0.1 | | Direktori Hapus | 0.2 | Untuk sistem file SSD, Anda dapat memilih untuk menyediakan metadata IOPS menggunakan mode Otomatis. Dalam mode Otomatis, Amazon FSx secara otomatis menyediakan IOPS metadata berdasarkan kapasitas penyimpanan sistem file Anda sesuai dengan tabel di bawah ini: | Kapasitas penyimpanan sistem file | Termasuk metadata IOPS dalam mode Otomatis | | --- | --- | | 1200 GiB | 1500 | | 2400 GiB | 3000 | | 4800—9600 GiB | 6000 | | 12000—45600 GiB | 12000 | | ≥48000 GiB | 12000 IOPS per 24000 GiB | Dalam mode yang disediakan pengguna, Anda dapat memilih untuk menentukan jumlah IOPS metadata yang akan disediakan. Nilai yang valid adalah sebagai berikut: + Untuk sistem file SSD, nilai yang valid adalah `1500` `3000``6000`,`12000`,,,, dan kelipatan `12000` hingga maksimum. `192000` + Untuk sistem file Intelligent-Tiering, nilai yang valid adalah dan. `6000` `12000` Untuk informasi tentang cara mengonfigurasi IOPS Metadata, lihat. [Mengelola kinerja metadata](managing-metadata-performance.md) Perhatikan bahwa Anda membayar Metadata IOPS yang disediakan di atas nomor default Metadata IOPS untuk sistem file Anda. ## Throughput ke instance klien individu Jika Anda membuat sistem file dengan kapasitas throughput lebih GBps dari 10, sebaiknya aktifkan Elastic Fabric Adapter (EFA) untuk mengoptimalkan throughput per instance klien. Untuk lebih mengoptimalkan throughput per instance klien, sistem file berkemampuan EFA juga mendukung GPUDirect Penyimpanan untuk instans klien berbasis GPU NVIDIA yang mendukung EFA dan ENA Express untuk instans klien yang mendukung ENA Express. Throughput yang dapat Anda arahkan ke satu instance klien tergantung pada pilihan jenis sistem file dan antarmuka jaringan pada instance klien Anda. | Tipe Sistem File | Antarmuka jaringan instance klien | Throughput maksimum per klien, Gbps | | --- | --- | --- | | Tidak mendukung EFA | Setiap | 100 Gbps\$1 | | Diaktifkan EFA | ENA | 100 Gbps\$1 | | Diaktifkan EFA | ENA Ekspres | 100 Gbps | | Diaktifkan EFA | EFA | 700 Gbps | | Diaktifkan EFA | EFA dengan GDS | 1200 Gbps | **catatan** \$1 Lalu lintas antara instance klien individu dan individu FSx untuk server penyimpanan objek Lustre dibatasi hingga 5 Gbps. Lihat [Alamat IP untuk sistem file](using-fsx-lustre.md#ip-addesses-for-fs) untuk jumlah server penyimpanan objek yang mendukung sistem file FSx Lustre Anda. ## Layout penyimpanan sistem file Semua data file Lustre disimpan pada volume penyimpanan yang disebut *target penyimpanan objek* (OSTs). *Semua metadata file (termasuk nama file, cap waktu, izin, dan lainnya) disimpan pada volume penyimpanan yang disebut target metadata ().* MDTs Amazon FSx untuk sistem file Lustre terdiri dari satu atau lebih MDTs dan beberapa. OSTs Amazon FSx for Lustre menyebarkan data file Anda ke seluruh OSTs yang membentuk sistem file Anda untuk menyeimbangkan kapasitas penyimpanan dengan throughput dan beban IOPS. Untuk melihat penggunaan penyimpanan MDT dan OSTs yang membentuk sistem file Anda, jalankan perintah berikut dari klien yang memiliki sistem file terpasang. ``` lfs df -h mount/path ``` Hasil akhir dari perintah ini adalah sebagai berikut. **Example** ``` UUID bytes Used Available Use% Mounted on mountname-MDT0000_UUID 68.7G 5.4M 68.7G 0% /fsx[MDT:0] mountname-OST0000_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:0] mountname-OST0001_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:1] filesystem_summary: 2.2T 9.0M 2.2T 0% /fsx ``` ## Sedang melakukan stripe data di sistem file Anda Anda dapat mengoptimalkan performa throughput sistem file Anda dengan melakukan file striping. Amazon FSx for Lustre secara otomatis menyebarkan OSTs file untuk memastikan bahwa data disajikan dari semua server penyimpanan. Anda dapat menerapkan konsep yang sama di tingkat file dengan mengonfigurasi bagaimana file digaris-garis di beberapa. OSTs Striping berarti bahwa file dapat dibagi menjadi beberapa potongan yang kemudian disimpan di berbagai bagian. OSTs Ketika file digaris-garis di beberapa OSTs, permintaan baca atau tulis ke file tersebar di seluruh file tersebut OSTs, meningkatkan throughput agregat atau IOPS yang dapat digerakkan oleh aplikasi Anda. Berikut ini adalah layout default untuk Amazon FSx untuk sistem file Lustre. + Untuk sistem file yang dibuat sebelum 18 Desember 2020, tata letak default menentukan jumlah garis 1. Ini berarti bahwa kecuali tata letak yang berbeda ditentukan, setiap file yang dibuat di Amazon FSx untuk Lustre menggunakan alat Linux standar disimpan pada satu disk. + Untuk sistem file yang dibuat setelah 18 Desember 2020, tata letak default adalah tata letak file progresif di mana file di bawah ukuran 1GiB disimpan dalam satu garis, dan file yang lebih besar diberi jumlah garis 5. + Untuk sistem file yang dibuat setelah 25 Agustus 2023, tata letak default adalah tata letak file progresif 4 komponen yang dijelaskan di. [Layout file progresif](#striping-pfl) + Untuk semua sistem file terlepas dari tanggal pembuatannya, file yang diimpor dari Amazon S3 tidak menggunakan tata letak default, melainkan menggunakan tata letak dalam parameter sistem file. `ImportedFileChunkSize` File yang diimpor S3 yang lebih besar dari file `ImportedFileChunkSize` akan disimpan di beberapa OSTs dengan jumlah garis. `(FileSize / ImportedFileChunksize) + 1` Nilai default dari `ImportedFileChunkSize` adalah 1GiB. Anda dapat melihat konfigurasi layout dari sebuah file atau direktori menggunakan perintah `lfs getstripe`. ``` lfs getstripe path/to/filename ``` Perintah ini melaporkan jumlah stripe dari file, ukuran stripe, dan offset stripe. *Jumlah garis* adalah berapa banyak file OSTs yang digaris-garis. *Ukuran stripe *adalah seberapa banyak data berkelanjutan yang disimpan dalam sebuah OST. *Offset stripe *adalah indeks OST pertama tempat file di-stripe. ### Memodifikasi konfigurasi striping Anda Parameter layout dari sebuah file diatur ketika file pertama kali dibuat. Gunakan perintah `lfs setstripe` untuk membuat sebuah file yang baru, kosong dengan layout yang telah ditentukan. ``` lfs setstripe filename --stripe-count number_of_OSTs ``` Perintah `lfs setstripe` mempengaruhi hanya layout dari sebuah file baru. Gunakan perintah tersebut untuk menentukan layout sebuah file sebelum Anda membuatnya. Anda juga dapat menentukan layout untuk sebuah direktori. Setelah ditetapkan pada sebuah direktori, layout diterapkan ke setiap file baru yang ditambahkan ke direktori tersebut, tetapi tidak ke file yang sudah ada. Setiap subdirektori baru yang Anda buat juga mewarisi layout baru, yang kemudian diterapkan ke setiap file atau direktori baru yang Anda buat dalam subdirektori tersebut. Untuk memodifikasi layout dari file yang ada, gunakan perintah `lfs migrate`. Perintah ini menyalin file sebagaimana diperlukan untuk mendistribusikan isinya berdasarkan layout yang Anda tentukan di perintah. Misalnya, file-file yang ditambahkan atau ditingkatkan ukurannya tidak akan mengubah jumlah stripe, jadi Anda harus me-migrasi file-file untuk mengubah layout file. Atau, Anda dapat membuat file baru menggunakan perintah `lfs setstripe` untuk menentukan layout-nya, menyalin konten semula ke file yang baru, dan kemudian mengubah nama file yang baru untuk mengganti file semula. Mungkin ada kasus-kasus di mana konfigurasi layout default tidak optimal untuk beban kerja Anda. Misalnya, sistem file dengan puluhan OSTs dan sejumlah besar file multi-gigabyte dapat melihat kinerja yang lebih tinggi dengan menghapus file di lebih dari nilai hitungan garis default lima. OSTs Membuat file besar dengan jumlah strip rendah dapat menyebabkan kemacetan I/O kinerja dan juga dapat menyebabkan pengisian. OSTs Dalam hal ini, Anda dapat membuat sebuah direktori dengan jumlah stripe yang lebih besar untuk file-file ini. Mengatur layout yang ditetapkan stripe-nya untuk file-file besar (terutama file-file yang lebih besar dari ukuran gigabyte) adalah penting karena alasan-alasan berikut ini: + Meningkatkan throughput dengan memungkinkan beberapa OSTs dan server terkait untuk berkontribusi IOPS, bandwidth jaringan, dan sumber daya CPU saat membaca dan menulis file besar. + Mengurangi kemungkinan bahwa sebagian kecil OSTs menjadi hot spot yang membatasi kinerja beban kerja secara keseluruhan. + Mencegah satu file tunggal besar mengisi OST, yang berpotensi menyebabkan error disk penuh. Tidak ada konfigurasi layout optimal tunggal untuk semua kasus penggunaan. Untuk panduan men-detail tentang layout file, lihat [Mengelola Layout File (Melakukan Stripe) dan Ruang Bebas](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace) dalam dokumentasi Lustre.org. Berikut ini adalah pedoman umum: + Layout yang sudah ditentukan stripe-nya adalah masalah bagi file-file besar, terutama dalam kasus penggunaan di mana file-file secara rutin memiliki ukuran ratusan megabyte atau lebih. Untuk alasan ini, layout default untuk sistem file baru menetapkan jumlah stripe sebanyak lima untuk file-file di atas ukuran 1GiB. + Jumlah Stripe adalah parameter layout yang harus Anda sesuaikan untuk sistem yang men-support file-file besar. Jumlah stripe menentukan jumlah volume OST yang akan menyimpan potongan file yang memiliki stripe. Misalnya, dengan jumlah garis 2 dan ukuran garis 1MiB, Lustre tulis potongan 1MiB alternatif dari file ke masing-masing dua. OSTs + Jumlah stripe yang efektif adalah lebih sedikit dari jumlah volume OST yang sebenarnya dan nilai jumlah stripe yang Anda tentukan. Anda dapat menggunakan nilai jumlah stripe sebanyak `-1` untuk menunjukkan bahwa stripe harus ditempatkan di semua volume OST. + Mengatur jumlah strip besar untuk file kecil adalah sub-optimal karena untuk operasi tertentu Lustre memerlukan jaringan pulang pergi ke setiap OST dalam tata letak, bahkan jika file terlalu kecil untuk mengkonsumsi ruang pada semua volume OST. + Anda dapat mengatur layout file progresif (PFL) yang mengizinkan layout sebuah file berubah-ubah sesuai ukuran. Konfigurasi PFL dapat menyederhanakan pengelolaan sebuah sistem file yang memiliki kombinasi file besar dan kecil tanpa Anda harus secara eksplisit mengatur konfigurasi untuk setiap file. Untuk informasi selengkapnya, lihat [Layout file progresif](#striping-pfl). + Ukuran Stripe secara default adalah 1MiB. Menyetel garis offset mungkin berguna dalam keadaan khusus, tetapi secara umum yang terbaik adalah membiarkannya tidak ditentukan dan menggunakan default. ### Layout file progresif Anda dapat menentukan konfigurasi layout file progresif (PFL) untuk sebuah direktori untuk menentukan konfigurasi stripe yang berbeda-beda untuk file kecil dan besar sebelum mengisinya. Misalnya, Anda dapat mengatur PFL di direktori tingkat atas sebelum ada data yang dituliskan ke sistem file yang baru. Untuk menentukan konfigurasi PFL, gunakan perintah `lfs setstripe` dengan opsi `-E` untuk menentukan komponen layout untuk file dengan ukuran yang berbeda-beda, seperti perintah berikut: ``` lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname/directory ``` Perintah ini menetapkan empat komponen tata letak: + Komponen pertama (`-E 100M -c 1`) menunjukkan nilai jumlah stripe sebanyak 1 untuk file-file dengan ukuran 100MiB. + Komponen kedua (`-E 10G -c 8`) menunjukkan nilai jumlah stripe sebanyak 8 untuk file-file dengan ukuran 10GiB. + Komponen ketiga (`-E 100G -c 16`) menunjukkan jumlah garis 16 untuk file berukuran hingga 100GiB. + Komponen keempat (`-E -1 -c 32`) menunjukkan jumlah garis 32 untuk file yang lebih besar dari 100GiB. **penting** Menambahkan data ke file yang dibuat dengan sebuah layout PFL, data akan mengisi semua komponen layout-nya. Misalnya, dengan perintah 4-komponen yang ditunjukkan di atas, jika Anda membuat file 1MiB dan kemudian menambahkan data ke ujungnya, tata letak file akan diperluas untuk memiliki jumlah garis -1, yang berarti semua yang ada di OSTs sistem. Hal ini tidak berarti data akan ditulis ke setiap OST, tetapi sebuah operasi seperti membaca panjang file akan mengirimkan permintaan secara paralel ke setiap OST, menambah beban jaringan yang signifikan ke sistem file. Oleh karena itu, berhati-hatilah untuk membatasi jumlah stripe untuk panjang file berukuran kecil dan medium yang selanjutnya dapat diisi oleh data ke dalamnya. Karena file log biasanya tumbuh dengan menambahkan catatan baru, Amazon FSx untuk Lustre menetapkan jumlah garis default 1 ke file apa pun yang dibuat dalam mode tambahan, terlepas dari konfigurasi garis default yang ditentukan oleh direktori induknya. Konfigurasi PFL default di Amazon FSx untuk sistem file Lustre yang dibuat setelah 25 Agustus 2023 diatur dengan perintah ini: ``` lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname ``` Pelanggan dengan beban kerja yang memiliki akses sangat bersamaan pada file sedang dan besar cenderung mendapat manfaat dari tata letak dengan lebih banyak garis pada ukuran yang lebih kecil dan striping di semua file terbesar, seperti yang ditunjukkan dalam OSTs contoh tata letak empat komponen. ## Memantau performa dan penggunaan Setiap menit, Amazon FSx untuk Lustre memancarkan metrik penggunaan untuk setiap disk (MDT dan OST) ke Amazon. CloudWatch Untuk melihat detail penggunaan sistem file agregat, Anda dapat melihat statistik Jumlah dari setiap metrik. Misalnya, Jumlah `DataReadBytes` statistik melaporkan total throughput baca yang dilihat oleh semua OSTs dalam sistem file. Sama halnya, Jumlah dari statistik `FreeDataStorageCapacity` melaporkan jumlah kapasitas penyimpanan yang tersedia untuk data file di dalam sistem file. Untuk informasi selengkapnya tentang pemantauan performa dari sistem file Anda, lihat [Memantau Amazon FSx untuk sistem file Lustre](monitoring_overview.md). # Karakteristik kinerja kelas penyimpanan SSD dan HDD Throughput yang didukung oleh sistem file FSx for Lustre dengan SSD atau HDD kelas penyimpanan sebanding dengan kapasitas penyimpanannya. Amazon FSx untuk sistem file Lustre menskalakan ke beberapa TBps throughput dan jutaan IOPS. Amazon FSx for Lustre juga mendukung akses bersamaan ke file atau direktori yang sama dari ribuan instance komputasi. Akses ini mengaktifkan checkpointing data cepat dari memori aplikasi ke penyimpanan, yang merupakan teknik umum dalam komputasi performa tinggi (HPC). Anda dapat meningkatkan jumlah penyimpanan dan kapasitas throughput yang diperlukan setiap saat setelah Anda membuat sistem file. Untuk informasi selengkapnya, lihat [Mengelola kapasitas penyimpanan](managing-storage-capacity.md). FSx untuk sistem file Lustre menyediakan throughput burst read menggunakan mekanisme I/O kredit jaringan untuk mengalokasikan bandwidth jaringan berdasarkan pemanfaatan bandwidth rata-rata. Sistem-sistem file memperoleh kredit ketika penggunaan bandwidth jaringan mereka di bawah batas baseline, dan dapat menggunaan kredit ini ketika sistem-sistem file melaksanakan transfer data jaringan. Tabel berikut menunjukkan kinerja yang dirancang FSx untuk opsi penyebaran untuk Lustre menggunakan kelas penyimpanan SSD dan HDD. **Performa sistem file untuk pilihan penyimpanan SSD** | Jenis Deployment | **Throughput jaringan (MBps/TiB penyimpanan disediakan)** | **IOPS Jaringan (IOPS/TIB penyimpanan disediakan)** | **Penyimpanan cache (GiB penyimpanan RAM/TiB yang disediakan)** | **Latensi disk per operasi file (milidetik, P50)** | **Throughput disk (MBps/Tib penyimpanan atau cache SSD disediakan)** | | --- |--- |--- |--- |--- |--- | | **** | **Baseline** | **Meledak** | **** | **** | **** | **Baseline** | **Meledak** | | --- |--- |--- |--- |--- |--- |--- |--- | | SCRATCH\$12 | 200 | 1300 | Puluhan ribu baselineRatusan ribu burst | 6.7 | Metadata: sub-ms Data: sub-ms | 200 (baca) 100 (tulis) | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTEN-125 | 320 | 1300 | 3.4 | 125 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTEN-250 | 640 | 1300 | 6.8 | 250 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTEN-500 | 1300 | ‐ | 13.7 | 500 | ‐ | | --- |--- |--- |--- |--- |--- | | PERSISTEN-1000 | 2600 | ‐ | 27.3 | 1000 | ‐ | | --- |--- |--- |--- |--- |--- | **Performa sistem file untuk opsi penyimpanan HDD** | Jenis Deployment | **Throughput jaringan (MBps/Tib penyimpanan atau cache SSD disediakan)** | **IOPS Jaringan (IOPS/TIB penyimpanan disediakan)** | **Penyimpanan cache (GiB penyimpanan RAM/TiB yang disediakan)** | **Latensi disk per operasi file (milidetik, P50)** | **Throughput disk (MBps/Tib penyimpanan atau cache SSD disediakan)** | | --- |--- |--- |--- |--- |--- | | **** | **Baseline** | **Meledak** | | **Baseline** | **Meledak** | | --- |--- |--- |--- |--- |--- | | PERSISTENT-12 | | --- | | Penyimpanan HDD | 40 | 375\$1 | Puluhan ribu baseline Ratusan ribu burst | Memori 0,4 | Metadata: sub-ms Data: ms ber-digit tunggal | 12 | 80 (baca) 50 (tulis) | | --- |--- |--- |--- |--- |--- |--- |--- | | Cache baca SSD | 200 | 1.900 | 200 cache SSD | Data: sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | | PERSISTENT-40 | | --- | | Penyimpanan HDD | 150 | 1.300\$1 | Puluhan ribu baseline Ratusan ribu burst | 1.5 | Metadata: sub-ms Data: ms ber-digit tunggal | 40 | 250 (baca) 150 (tulis) | | --- |--- |--- |--- |--- |--- |--- |--- | | Cache baca SSD | 750 | 6500 | 200 cache SSD | Data: sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | **Kinerja sistem file untuk opsi penyimpanan SSD generasi sebelumnya** | Jenis Deployment | **Throughput jaringan (MBps per TiB penyimpanan yang disediakan)** | **IOPS Jaringan (IOPS per TiB penyimpanan yang disediakan)** | **Penyimpanan cache (GiB per TiB penyimpanan disediakan)** | **Latensi disk per operasi file (milidetik, P50)** | **Throughput disk (MBps per TiB penyimpanan atau cache SSD yang disediakan)** | | --- |--- |--- |--- |--- |--- | | **** | **Baseline** | **Meledak** | **** | **** | **** | **Baseline** | **Meledak** | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-50 | 250 | 1.300\$1 | Puluhan ribu baselineRatusan ribu burst | 2.2 RAM | Metadata: sub-ms Data: sub-ms | 50 | 240 | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-100 | 500 | 1.300\$1 | 4.4 RAM | 100 | 240 | | --- |--- |--- |--- |--- |--- | | PERSISTENT-200 | 750 | 1.300\$1 | 8,8 RAM | 200 | 240 | | --- |--- |--- |--- |--- |--- | **catatan** \$1 Sistem file persisten berikut ini Wilayah AWS menyediakan ledakan jaringan hingga 530 MBps per TiB penyimpanan: Afrika (Cape Town), Asia Pasifik (Hong Kong), Asia Pasifik (Osaka), Asia Pasifik (Singapura), Kanada (Tengah), Eropa (Frankfurt), Eropa (London), Eropa (Milan), Eropa (Stockholm), Timur Tengah (Bahrain), Amerika Selatan (Sao Paulo), Tiongkok, dan AS Barat (Los Angeles). ## Contoh: Agregat baseline dan burst throughput Contoh berikut menggambarkan bagaimana kapasitas penyimpanan dan throughput disk mempengaruhi performa sistem file. Sistem file persisten dengan kapasitas penyimpanan 4,8 TiB dan 50 MBps per TiB throughput per unit penyimpanan menyediakan throughput disk dasar agregat 240 dan throughput disk burst 1,152. MBps GBps Terlepas dari ukuran sistem file, Amazon FSx untuk Lustre menyediakan latensi sub-milidetik yang konsisten untuk operasi file. # Karakteristik kinerja kelas penyimpanan Intelligent-Tiering Kelas penyimpanan FSx for Lustre Intelligent-Tiering menawarkan penyimpanan yang elastis dan dioptimalkan biaya untuk beban kerja yang secara tradisional berjalan pada sistem file penyimpanan file berkinerja tinggi berbasis HDD atau campuran HDD/SDD. Sistem file yang menggunakan kelas penyimpanan Intelligent-Tiering menggunakan penyimpanan regional yang sepenuhnya elastis, berjenjang cerdas, yang secara otomatis tumbuh dan menyusut agar sesuai dengan beban kerja Anda saat berubah. Untuk informasi tentang cara tingkatan data, lihat[Bagaimana kelas penyimpanan Intelligent-Tiering meningkatkan data](using-fsx-lustre.md#how-INT-tiering-works). Throughput yang didukung oleh sistem file FSx for Lustre dengan kelas penyimpanan Intelligent-Tiering independen untuk penyimpanannya. Sistem file Intelligent-Tiering menskalakan ke beberapa throughput TBps dan jutaan IOPS. Sistem file yang menggunakan kelas penyimpanan Intelligent-Tiering juga menyediakan cache baca SSD yang disediakan opsional untuk akses latensi rendah ke data yang sering diakses. Secara default, Amazon FSx untuk Lustre menyediakan cache baca SSD untuk metadata yang sering diakses. Karena sebagian besar beban kerja cenderung berat baca dan aktif bekerja hanya dengan sebagian kecil dari keseluruhan kumpulan data pada waktu tertentu, model hybrid penyimpanan Intelligent-Tiering dan cache baca SSD memungkinkan sistem file menggunakan kelas penyimpanan Intelligent-Tiering untuk menyediakan penyimpanan yang berkinerja pada tingkat yang sebanding dengan sistem file SSD untuk sebagian besar beban kerja, sambil memberikan penghematan biaya penyimpanan relatif terhadap kelas penyimpanan SSD dan HDD. Saat membaca dan menulis data ke sistem file Intelligent-Tiering, terutama data yang belum diakses baru-baru ini atau cukup sering berada di cache dalam memori server file, kinerja tergantung pada ukuran cache baca SSD. Akses data dari penyimpanan Intelligent-Tiering memiliki time-to-first-byte latensi kira-kira puluhan milidetik serta biaya per permintaan, sementara akses dari cache baca SSD kembali dengan latensi sub-milidetik dan tidak ada biaya per permintaan. Saat mengonfigurasi ukuran cache baca SSD untuk sistem file Anda, Anda harus mempertimbangkan ukuran kumpulan data yang sering diakses dalam beban kerja dan sensitivitas beban kerja terhadap latensi yang lebih tinggi untuk pembacaan data yang jarang diakses. Anda dapat beralih di antara mode ukuran cache baca SSD setelah sistem file Anda dibuat dan skala cache naik atau turun. Untuk informasi selengkapnya tentang cara memodifikasi cache baca SSD Anda, lihat[Mengelola cache baca SSD yang disediakan](managing-ssd-read-cache.md). Permintaan tulis terjadi ketika FSx Lustre menulis blok data ke penyimpanan Intelligent-Tiering. Saat Anda menulis data ke sistem file, permintaan tulis dikumpulkan dan ditulis ke penyimpanan Intelligent-Tiering, meningkatkan throughput dan menurunkan biaya permintaan. Pembacaan dapat disajikan dari cache dalam memori server file, cache baca SSD, atau langsung dari penyimpanan Intelligent-Tiering. Ketika pembacaan disajikan dari penyimpanan Intelligent-Tiering, permintaan baca terjadi untuk setiap blok data yang diambil. Ketika Anda membaca data secara berurutan, FSx untuk Lustre akan mengambil data sebelumnya untuk meningkatkan kinerja. *Data dari cache dalam memori pada sistem file yang menggunakan kelas penyimpanan Intelligent-Tiering disajikan langsung ke klien yang meminta sebagai I/O jaringan.* Ketika klien mengakses data yang tidak ada dalam cache dalam memori, itu dibaca dari cache baca SSD atau penyimpanan Intelligent-Tiering sebagai *disk I/O dan kemudian disajikan ke klien sebagai I/O* jaringan. ## Kinerja sistem file untuk Intelligent-Tiering Tabel berikut menunjukkan kinerja yang dirancang FSx untuk sistem file Lustre Intelligent-Tiering. | Kapasitas throughput yang disediakan () MBps | **Throughput jaringan () MBps** | **Jaringan IOPS** | **Penyimpanan cache dalam memori (GB)** | **Throughput disk cache SSD maksimum () MBps** | **Disk cache SSD maksimum IOPS** | | --- |--- |--- |--- |--- |--- | | **** | **Baseline** | **Meledak** | **** | **** | **** | **Baseline** | **Meledak** | | --- |--- |--- |--- |--- |--- |--- |--- | | Setiap 4000 | 12500 | ‐ | Ratusan ribu | 76.8 | 4000 | 160000 | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | # Tips performa Saat menggunakan Amazon FSx untuk Lustre, ingatlah kiat kinerja berikut. Untuk batas-batas layanan, lihat [Kuota layanan untuk Amazon FSx untuk Lustre](limits.md). + ** I/O Ukuran rata-rata** - Karena Amazon FSx untuk Lustre adalah sistem file jaringan, setiap operasi file melewati perjalanan pulang pergi antara klien dan Amazon FSx untuk Lustre, menimbulkan overhead latensi kecil. Karena latensi per operasi ini, throughput keseluruhan umumnya meningkat seiring dengan meningkatnya I/O ukuran rata-rata, karena overhead diamortisasi pada jumlah data yang lebih besar. + **Model permintaan** — Dengan mengaktifkan penulisan asinkron ke sistem file Anda, operasi penulisan yang tertunda di-buffer pada instans Amazon EC2 sebelum ditulis ke Amazon untuk Lustre secara asinkron. FSx Penulisan asinkron biasanya memiliki latensi yang lebih rendah. Saat melakukan penulisan asinkron, kernel menggunakan memori tambahan untuk melakukan cache. Sistem file yang telah mengaktifkan penulisan sinkron mengeluarkan permintaan sinkron ke Amazon FSx untuk Lustre. Setiap operasi melewati perjalanan pulang pergi antara klien dan Amazon FSx untuk Lustre. **catatan** Model permintaan pilihan Anda telah mengorbankan konsistensi (jika Anda menggunakan beberapa instans Amazon EC2) dan kecepatan. + **Batasi ukuran direktori** — Untuk mencapai kinerja metadata optimal pada Persistent 2 FSx untuk sistem file Lustre, batasi setiap direktori hingga kurang dari 100K file. Membatasi jumlah file dalam direktori mengurangi waktu yang diperlukan untuk sistem file untuk memperoleh kunci pada direktori induk. + **Instans Amazon EC2** — Aplikasi-aplikasi yang melakukan sejumlah besar operasi baca dan tulis cenderung memerlukan lebih banyak memori atau kapasitas komputasi daripada aplikasi-aplikasi yang tidak melakukannya. Ketika meluncurkan instans-instans Amazon EC2 Anda untuk beban kerja komputasi intensif Anda, pilihlah jenis-jenis instans yang memiliki jumlah sumber daya yang dibutuhkan aplikasi Anda. Karakteristik kinerja sistem file Amazon FSx untuk Lustre tidak bergantung pada penggunaan instans Amazon EBS yang dioptimalkan. + **Penyetelan instans klien yang direkomendasikan untuk kinerja optimal** 1. Untuk tipe instance klien dengan memori lebih dari 64 GiB, kami sarankan untuk menerapkan penyetelan berikut: ``` sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs> ``` 1. Untuk tipe instans klien dengan lebih dari 64 core vCPU, kami sarankan untuk menerapkan penyetelan berikut: ``` echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf # reload all kernel modules to apply the above two settings sudo reboot ``` Setelah klien dipasang, penyetelan berikut perlu diterapkan: ``` sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50 ``` 1. Untuk mengoptimalkan kinerja daftar direktori (ls), penyetelan berikut perlu diterapkan: ``` sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi ``` Perhatikan bahwa `lctl set_param` diketahui tidak bertahan selama reboot. Karena parameter ini tidak dapat diatur secara permanen dari sisi klien, disarankan untuk menerapkan pekerjaan boot cron untuk mengatur konfigurasi dengan penyetelan yang disarankan. + **Keseimbangan beban kerja OSTs** - Dalam beberapa kasus, beban kerja Anda tidak mendorong throughput agregat yang dapat disediakan sistem file Anda (200 per MBps TiB penyimpanan). Jika demikian, Anda dapat menggunakan CloudWatch metrik untuk memecahkan masalah jika kinerja dipengaruhi oleh ketidakseimbangan dalam pola beban kerja Anda. I/O Untuk mengidentifikasi apakah ini penyebabnya, lihat CloudWatch metrik Maksimum untuk Amazon FSx untuk Lustre. Dalam beberapa kasus, statistik ini menunjukkan beban pada atau di atas 240 MBps throughput (kapasitas throughput FSx Amazon 1,2-Tib tunggal untuk disk Lustre). Dalam kasus tersebut, beban kerja Anda tidak tersebar secara merata di seluruh disk Anda. Jika demikian kasusnya, Anda dapat menggunakan perintah `lfs setstripe` untuk memodifikasi striping file yang paling sering diakses oleh beban kerja Anda. Untuk kinerja optimal, stripe file dengan persyaratan throughput tinggi di semua yang OSTs terdiri dari sistem file Anda. Jika file Anda diimpor dari repositori data, Anda dapat mengambil pendekatan lain untuk menghapus file throughput tinggi Anda secara merata di seluruh file Anda. OSTs Untuk melakukan ini, Anda dapat memodifikasi `ImportedFileChunkSize` parameter saat membuat Amazon berikutnya FSx untuk sistem file Lustre. Misalnya, beban kerja Anda menggunakan sistem file 7.0-Tib (yang terdiri dari 6x 1.17-Tib OSTs) dan perlu mendorong throughput tinggi di seluruh file 2.4-GiB. Dalam hal ini, Anda dapat mengatur `ImportedFileChunkSize` nilainya `(2.4 GiB / 6 OSTs) = 400 MiB` sehingga file Anda tersebar merata di seluruh sistem file Anda OSTs. + **Lustreklien untuk Metadata IOPS** - Jika sistem file Anda memiliki konfigurasi metadata yang ditentukan, kami sarankan Anda menginstal klien Lustre 2.15 atau klien Lustre 2.12 dengan salah satu versi OS ini: Amazon Linux 2023; Amazon Linux 2; Red Hat/Rocky Linux 8.9, 8.10, atau 9.x; CentOS 8.9 atau 8.10; Ubuntu 22\$1 dengan 6.2, 6.5, atau 6.8 kernel; atau Ubuntu 20. ## Pertimbangan kinerja Tingkat Cerdas Berikut adalah beberapa pertimbangan kinerja penting saat bekerja dengan sistem file menggunakan kelas penyimpanan Intelligent-Tiering: + Beban kerja membaca data dengan I/O ukuran yang lebih kecil akan membutuhkan konkurensi yang lebih tinggi dan menimbulkan lebih banyak biaya permintaan untuk mencapai throughput yang sama dengan beban kerja menggunakan I/O ukuran besar karena latensi yang lebih tinggi dari tingkatan penyimpanan Intelligent-Tiering. Sebaiknya konfigurasi cache baca SSD Anda cukup besar untuk mendukung konkurensi dan throughput yang lebih tinggi saat bekerja dengan ukuran IO yang lebih kecil. + IOPS disk maksimum yang dapat dikendarai klien Anda dengan sistem file Intelligent-Tiering tergantung pada pola akses spesifik dari beban kerja Anda dan apakah Anda telah menyediakan cache baca SSD. Untuk beban kerja dengan akses acak, klien biasanya dapat mendorong IOPS jauh lebih tinggi jika data di-cache di cache baca SSD daripada jika data tidak ada dalam cache. + Kelas penyimpanan Intelligent-Tiering mendukung pembacaan untuk mengoptimalkan kinerja permintaan baca berurutan. Kami menyarankan untuk mengonfigurasi pola akses data Anda secara berurutan bila memungkinkan pengambilan data sebelumnya dan kinerja yang lebih tinggi.