Memaksimalkan throughput Gateway File S3

Bagian berikut menjelaskan praktik terbaik untuk memaksimalkan throughput antara klien NFS dan SMB, Gateway File S3, dan Amazon S3. Panduan yang diberikan di setiap bagian berkontribusi secara bertahap untuk meningkatkan throughput secara keseluruhan. Meskipun tidak satu pun dari rekomendasi ini diperlukan, dan mereka tidak saling bergantung, mereka telah dipilih dan diurutkan dengan cara logis yang Dukungan digunakan untuk menguji dan menyetel implementasi S3 File Gateway. Saat Anda menerapkan dan menguji saran ini, ingatlah bahwa setiap penerapan S3 File Gateway adalah unik, sehingga hasil Anda dapat bervariasi.

S3 File Gateway menyediakan antarmuka file untuk menyimpan dan mengambil objek Amazon S3 menggunakan protokol file NFS atau SMB standar industri, dengan pemetaan asli 1:1 antara file dan objek. Anda menerapkan S3 File Gateway sebagai mesin virtual baik lokal di lingkungan VMware Microsoft Hyper-V, atau Linux KVM Anda, atau di cloud sebagai instans Amazon. AWS EC2 S3 File Gateway tidak dirancang untuk bertindak sebagai pengganti NAS perusahaan penuh. S3 File Gateway mengemulasi sistem file, tetapi ini bukan sistem file. Menggunakan Amazon S3 sebagai penyimpanan backend yang tahan lama menciptakan overhead tambahan pada setiap I/O operasi, jadi mengevaluasi kinerja Gateway File S3 terhadap NAS atau server file yang ada bukanlah perbandingan yang setara.

Terapkan gateway Anda di lokasi yang sama dengan klien Anda

Sebaiknya gunakan alat virtual S3 File Gateway Anda di lokasi fisik dengan latensi jaringan sesedikit mungkin antara itu dan klien NFS atau SMB Anda. Saat memilih lokasi untuk gateway Anda, pertimbangkan hal berikut:

• Latensi jaringan yang lebih rendah ke gateway dapat membantu meningkatkan kinerja klien NFS atau SMB.

• S3 File Gateway dirancang untuk mentolerir latensi jaringan yang lebih tinggi antara gateway dan Amazon S3 daripada antara gateway dan klien.

• Untuk instans Gateway File S3 yang diterapkan di Amazon EC2, sebaiknya simpan gateway dan klien NFS atau SMB dalam grup penempatan yang sama. Untuk informasi selengkapnya, lihat Grup penempatan untuk EC2 instans Amazon Anda di Panduan Pengguna Amazon Elastic Compute Cloud.

Mengurangi kemacetan yang disebabkan oleh disk yang lambat

Kami merekomendasikan pemantauan IoWaitPercent CloudWatch metrik untuk mengidentifikasi kemacetan kinerja yang dapat dihasilkan dari disk penyimpanan yang lambat pada Gateway File S3 Anda. Saat mencoba mengoptimalkan masalah kinerja terkait disk, pertimbangkan hal berikut:

• IoWaitPercentmelaporkan persentase waktu CPU menunggu respons dari disk root atau cache.

• Ketika IoWaitPercent lebih besar dari 5-10%, ini biasanya menunjukkan hambatan kinerja gateway yang disebabkan oleh disk yang berkinerja buruk. Metrik ini harus sedekat mungkin dengan 0% - artinya gateway tidak pernah menunggu di disk - yang membantu mengoptimalkan sumber daya CPU.

• Anda dapat memeriksa tab Monitoring IoWaitPercent pada konsol Storage Gateway, atau mengonfigurasi CloudWatch alarm yang disarankan untuk memberi tahu Anda secara otomatis jika metrik melonjak di atas ambang batas tertentu. Untuk informasi selengkapnya, lihat Membuat CloudWatch alarm yang direkomendasikan untuk gateway Anda.

• Sebaiknya gunakan salah satu NVMe atau SSD untuk disk root dan cache gateway Anda untuk meminimalkanIoWaitPercent.

Sesuaikan alokasi sumber daya mesin virtual untuk disk CPU, RAM, dan cache

Saat mencoba mengoptimalkan throughput untuk Gateway File S3 Anda, penting untuk mengalokasikan sumber daya yang cukup ke VM gateway, termasuk CPU, RAM, dan disk cache. Persyaratan sumber daya virtual minimum 4 CPUs, RAM 16GB, dan penyimpanan cache 150GB biasanya hanya cocok untuk beban kerja yang lebih kecil. Saat mengalokasikan sumber daya virtual untuk beban kerja yang lebih besar, kami merekomendasikan hal berikut:

• Tingkatkan jumlah yang dialokasikan CPUs menjadi antara 16 dan 48, tergantung pada penggunaan CPU khas yang dihasilkan oleh Gateway File S3 Anda. Anda dapat memantau penggunaan CPU menggunakan UserCpuPercent metrik. Untuk informasi selengkapnya, lihat Memahami metrik gateway.

• Tingkatkan RAM yang dialokasikan menjadi antara 32 dan 64 GB.

  catatan

  S3 File Gateway tidak dapat menggunakan lebih dari 64 GB RAM.

• Gunakan NVMe atau SSD untuk disk root dan disk cache, dan ukuran disk cache Anda agar sejajar dengan kumpulan data kerja puncak yang Anda rencanakan untuk ditulis ke gateway. Untuk informasi selengkapnya, lihat praktik terbaik ukuran cache S3 File Gateway di saluran Amazon Web Services YouTube resmi.

• Tambahkan setidaknya 4 disk cache virtual ke gateway, daripada menggunakan satu disk besar. Beberapa disk virtual dapat meningkatkan kinerja bahkan jika mereka berbagi disk fisik dasar yang sama, tetapi perbaikan biasanya lebih besar ketika disk virtual terletak pada disk fisik yang mendasarinya yang berbeda.

  Misalnya, jika Anda ingin menyebarkan cache 12TB, Anda dapat menggunakan salah satu konfigurasi berikut:

  • Disk cache 4 x 3 TB

  • Disk cache 8 x 1,5 TB

  • Disk cache 12 x 1 TB

  Selain kinerja, ini memungkinkan manajemen mesin virtual yang lebih efisien dari waktu ke waktu. Saat beban kerja Anda berubah, Anda dapat secara bertahap meningkatkan jumlah disk cache dan kapasitas cache Anda secara keseluruhan, sambil mempertahankan ukuran asli setiap disk virtual individu untuk menjaga integritas gateway.

  Untuk informasi selengkapnya, lihat Menentukan jumlah penyimpanan disk lokal.

Saat menerapkan S3 File Gateway sebagai EC2 instance Amazon, pertimbangkan hal berikut:

• Jenis instans yang Anda pilih dapat memengaruhi kinerja gateway secara signifikan. Amazon EC2 memberikan fleksibilitas luas untuk menyesuaikan alokasi sumber daya untuk instans Gateway File S3 Anda.

• Untuk jenis EC2 instans Amazon yang direkomendasikan untuk Gateway File S3, lihat Persyaratan untuk jenis EC2 instans Amazon.

• Anda dapat mengubah jenis EC2 instans Amazon yang menghosting Gateway File S3 aktif. Ini memungkinkan Anda untuk dengan mudah menyesuaikan pembuatan EC2 perangkat keras Amazon dan alokasi sumber daya untuk menemukan price-to-performance rasio yang ideal. Untuk mengubah jenis instans, gunakan prosedur berikut di EC2 konsol Amazon:

  1. Hentikan EC2 instans Amazon.

  2. Ubah jenis EC2 instans Amazon.

  3. Nyalakan EC2 instans Amazon.

  catatan

  Menghentikan instance yang meng-host S3 File Gateway untuk sementara akan mengganggu akses berbagi file. Pastikan untuk menjadwalkan jendela pemeliharaan jika perlu.

• price-to-performanceRasio EC2 instans Amazon mengacu pada berapa banyak daya komputasi yang Anda dapatkan untuk harga yang Anda bayar. Biasanya, EC2 instans Amazon generasi yang lebih baru menawarkan price-to-performance rasio terbaik, dengan perangkat keras yang lebih baru dan peningkatan kinerja dengan biaya yang relatif lebih rendah dibandingkan dengan generasi yang lebih tua. Faktor-faktor seperti jenis instans, wilayah, dan pola penggunaan memengaruhi rasio ini, jadi penting untuk memilih instance yang tepat untuk beban kerja spesifik Anda guna mengoptimalkan efektivitas biaya.

Sesuaikan tingkat keamanan SMB

SMBv3 Protokol ini memungkinkan penandatanganan SMB dan enkripsi SMB, yang memiliki beberapa pertukaran dalam kinerja dan keamanan. Untuk mengoptimalkan throughput, Anda dapat menyesuaikan tingkat keamanan SMB gateway Anda untuk menentukan fitur keamanan mana yang diberlakukan untuk koneksi klien. Untuk informasi selengkapnya, lihat Menetapkan tingkat keamanan untuk gateway Anda.

Saat menyesuaikan tingkat keamanan SMB, pertimbangkan hal berikut:

• Tingkat keamanan default untuk S3 File Gateway adalah Enforce encryption. Pengaturan ini memberlakukan enkripsi dan penandatanganan untuk koneksi klien SMB ke berbagi file gateway, yang berarti bahwa semua lalu lintas dari klien ke gateway dienkripsi. Pengaturan ini tidak memengaruhi lalu lintas dari gateway ke AWS, yang selalu dienkripsi.

  Gateway membatasi setiap koneksi klien terenkripsi ke satu vCPU. Misalnya, jika Anda hanya memiliki 1 klien terenkripsi, maka klien itu akan dibatasi hanya 1 vCPU, bahkan jika 4 atau lebih v CPUs dialokasikan ke gateway. Karena itu, throughput untuk koneksi terenkripsi dari satu klien ke S3 File Gateway biasanya terhambat antara 40-60 MB/s.

• Jika persyaratan keamanan Anda memungkinkan postur yang lebih santai, Anda dapat mengubah tingkat keamanan ke Klien yang dinegosiasikan, yang akan menonaktifkan enkripsi SMB dan menegakkan penandatanganan SMB saja. Dengan pengaturan ini, koneksi klien ke gateway dapat memanfaatkan beberapa vCPUs, yang biasanya menghasilkan peningkatan kinerja throughput.

  catatan

  Setelah Anda mengubah tingkat keamanan SMB untuk Gateway File S3 Anda, Anda harus menunggu status berbagi file berubah dari Memperbarui ke Tersedia di konsol Storage Gateway, lalu putuskan dan sambungkan kembali klien SMB Anda agar pengaturan baru diterapkan.

Gunakan beberapa utas dan klien untuk memparalelkan operasi penulisan

Sulit untuk mencapai kinerja throughput maksimum dengan S3 File Gateway yang hanya menggunakan satu klien NFS atau SMB untuk menulis satu file pada satu waktu, karena penulisan berurutan dari satu klien adalah operasi single-threaded. Sebagai gantinya, sebaiknya gunakan beberapa utas dari setiap klien NFS atau SMB untuk menulis beberapa file secara paralel, dan menggunakan beberapa klien NFS atau SMB secara bersamaan ke Gateway File S3 Anda untuk memaksimalkan throughput gateway.

Menggunakan beberapa utas dapat meningkatkan kinerja secara signifikan. Namun, menggunakan lebih banyak thread membutuhkan lebih banyak sumber daya sistem, yang dapat berdampak negatif pada kinerja jika gateway tidak berukuran untuk memenuhi peningkatan beban. Dalam penerapan tipikal, Anda dapat mengharapkan untuk mencapai kinerja throughput yang lebih baik saat Anda menambahkan lebih banyak utas dan klien, hingga Anda mencapai batasan perangkat keras dan bandwidth maksimum untuk gateway Anda. Sebaiknya bereksperimen dengan jumlah thread yang berbeda untuk menemukan keseimbangan optimal antara kecepatan dan penggunaan sumber daya sistem untuk konfigurasi perangkat keras dan jaringan spesifik Anda.

Pertimbangkan informasi berikut tentang alat umum yang dapat membantu Anda menguji utas dan konfigurasi klien Anda:

• Anda dapat menguji kinerja penulisan multithreaded dengan menggunakan alat seperti robocopy untuk menyalin satu set file ke berbagi file di gateway Anda. Secara default, robocopy menggunakan 8 utas saat menyalin file, tetapi Anda dapat menentukan hingga 128 utas.

  Untuk menggunakan beberapa utas dengan robocopy, tambahkan /MT:n sakelar ke perintah Anda, di mana n jumlah utas yang ingin Anda gunakan. Misalnya:

  robocopy C:\source D:\destination /MT:64

  Perintah ini akan menggunakan 64 utas untuk operasi penyalinan.

  catatan

  Kami tidak menyarankan menggunakan Windows Explorer untuk menyeret dan melepaskan file saat menguji throughput maksimum, karena metode ini terbatas pada satu utas dan menyalin file secara berurutan.

  Untuk informasi selengkapnya, lihat robocopy di situs web Microsoft Learn.

• Anda juga dapat melakukan tes menggunakan alat benchmarking penyimpanan umum seperti DISKSPD, atau FIO. Alat-alat ini memiliki opsi untuk menyesuaikan jumlah utas, kedalaman I/O, dan parameter lainnya agar sesuai dengan persyaratan beban kerja spesifik Anda.

  DiskSpd memungkinkan Anda untuk mengontrol jumlah utas menggunakan -t parameter. Misalnya:

  diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

  Perintah contoh ini melakukan hal berikut:

  • Membuat file uji 10GB () -c1G

  • Berjalan selama 300 detik (-d300)

  • Melakukan I/O tes acak dengan 50% membaca 50% menulis (-r -w50)

  • Menggunakan 64 thread (-t64)

  • Menetapkan kedalaman antrian menjadi 32 per utas () -o32

  • Menggunakan ukuran blok 1MB () -b1M

  • Menonaktifkan cache perangkat keras dan perangkat lunak () -h -L

  Untuk informasi selengkapnya, lihat Menggunakan DISKSPD untuk menguji kinerja penyimpanan beban kerja di situs web Microsoft Learn.

• FIO menggunakan numjobs parameter untuk mengontrol jumlah thread paralel. Misalnya:

  fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

  Perintah contoh ini melakukan hal berikut:

  • Melakukan I/O tes acak (--rw=randrw)

  • Melakukan 70% membaca dan 30% menulis (--rwmixread=70)

  • Menggunakan ukuran blok 1MB () --bs=1M

  • Menetapkan I/O kedalaman ke 64 (--iodepth=64)

  • Tes pada file 10 GB (--size=10G)

  • Berjalan selama 5 menit (--runtime=300)

  • Menciptakan 64 pekerjaan paralel (thread) (--numjobs=64)

  • Menggunakan mesin asinkron I/O () --ioengine=libaio

  • Kelompokkan hasil untuk analisis yang lebih mudah (--group_reporting)

  Untuk informasi lebih lanjut, lihat halaman manual Fio Linux.

Matikan penyegaran cache otomatis

Fitur penyegaran cache otomatis memungkinkan Gateway File S3 Anda menyegarkan metadatanya secara otomatis, yang dapat membantu menangkap perubahan apa pun yang dilakukan pengguna atau aplikasi ke file Anda yang disetel dengan menulis ke bucket Amazon S3 secara langsung, bukan melalui gateway. Untuk informasi selengkapnya, lihat Menyegarkan cache objek bucket Amazon S3.

Untuk mengoptimalkan throughput gateway, kami sarankan untuk menonaktifkan fitur ini dalam penerapan di mana semua pembacaan dan penulisan ke bucket Amazon S3 akan dilakukan melalui Gateway File S3 Anda.

Saat mengonfigurasi penyegaran cache otomatis, pertimbangkan hal berikut:

• Jika Anda perlu menggunakan penyegaran cache otomatis karena pengguna atau aplikasi dalam penerapan Anda sesekali menulis ke Amazon S3 secara langsung, maka kami sarankan untuk mengonfigurasi interval waktu terpanjang antara penyegaran yang masih praktis untuk kebutuhan bisnis Anda. Interval penyegaran cache yang lebih lama membantu mengurangi jumlah operasi metadata yang perlu dilakukan gateway saat menjelajahi direktori atau memodifikasi file.

  Misalnya: atur penyegaran cache otomatis ke 24 jam, bukan 5 menit, jika itu dapat ditoleransi untuk beban kerja Anda.

• Interval waktu minimum adalah 5 menit. Interval maksimum adalah 30 hari.

• Jika Anda memilih untuk mengatur interval penyegaran cache yang sangat singkat, kami sarankan untuk menguji pengalaman penelusuran direktori untuk klien NFS dan SMB Anda. Waktu yang diperlukan untuk menyegarkan cache gateway dapat meningkat secara substansional tergantung pada jumlah file dan subdirektori di bucket Amazon S3 Anda.

Tingkatkan jumlah utas pengunggah Amazon S3

Secara default, S3 File Gateway membuka 8 utas untuk unggahan data Amazon S3, yang menyediakan kapasitas unggah yang cukup untuk sebagian besar penerapan umum. Namun, gateway dapat menerima data dari klien NFS dan SMB pada tingkat yang lebih tinggi daripada yang dapat diunggah ke Amazon S3 dengan kapasitas utas 8 standar, yang dapat menyebabkan cache lokal mencapai batas penyimpanannya.

Dalam keadaan tertentu, Dukungan dapat meningkatkan jumlah kumpulan thread upload Amazon S3 untuk gateway Anda dari 8 menjadi 40, yang memungkinkan lebih banyak data untuk diunggah secara paralel. Bergantung pada bandwidth dan faktor lain yang spesifik untuk penerapan Anda, ini dapat meningkatkan kinerja unggahan secara signifikan dan membantu mengurangi jumlah penyimpanan cache yang diperlukan untuk mendukung beban kerja Anda.

Sebaiknya gunakan CachePercentDirty CloudWatch metrik untuk memantau jumlah data yang disimpan di disk cache gateway lokal yang belum diunggah ke Amazon S3, dan Dukungan menghubungi untuk membantu menentukan apakah peningkatan jumlah kumpulan utas unggahan dapat meningkatkan throughput untuk Gateway File S3 Anda. Untuk informasi selengkapnya, lihat Memahami metrik gateway.

catatan

Pengaturan ini menggunakan sumber daya CPU gateway tambahan. Kami merekomendasikan pemantauan penggunaan CPU gateway dan meningkatkan sumber daya CPU yang dialokasikan jika perlu.

Tingkatkan pengaturan batas waktu SMB

Ketika S3 File Gateway menyalin file besar ke berbagi file SMB, koneksi klien SMB dapat batas waktu setelah jangka waktu yang lama.

Kami merekomendasikan untuk memperpanjang pengaturan batas waktu sesi SMB untuk klien SMB Anda hingga 20 menit atau lebih, tergantung pada ukuran file dan kecepatan tulis gateway Anda. Defaultnya adalah 300 detik, atau 5 menit. Untuk informasi selengkapnya, lihat Pekerjaan pencadangan gateway Anda gagal atau ada kesalahan saat menulis ke gateway Anda.

Aktifkan penguncian oportunistik untuk aplikasi yang kompatibel

Penguncian oportunistik, atau “oplocks”, diaktifkan secara default untuk setiap Gateway File S3 baru. Saat menggunakan oplock dengan aplikasi yang kompatibel, klien mengumpulkan beberapa operasi yang lebih kecil menjadi yang lebih besar, yang lebih efisien untuk klien, gateway, dan jaringan. Sebaiknya aktifkan penguncian oportunistik jika Anda menggunakan aplikasi yang memanfaatkan caching lokal sisi klien, seperti Microsoft Office, Adobe Suite, dan banyak lainnya, karena dapat meningkatkan kinerja secara signifikan.

Jika Anda mematikan penguncian oportunistik, aplikasi yang mendukung oplock biasanya akan membuka file besar (50 MB atau lebih besar) jauh lebih lambat. Penundaan ini terjadi karena gateway mengirimkan data dalam 4 bagian KB, yang menghasilkan throughput tinggi I/O dan rendah.

Sesuaikan kapasitas gateway sesuai dengan ukuran set file kerja

Parameter kapasitas gateway menentukan jumlah maksimum file yang gateway Anda akan menyimpan metadata dalam cache lokalnya. Secara default, kapasitas gateway diatur ke Kecil, yang berarti gateway menyimpan metadata hingga 5 juta file. Pengaturan default berfungsi dengan baik untuk sebagian besar beban kerja, bahkan jika ada ratusan juta, atau bahkan miliaran objek di Amazon S3, karena hanya sebagian kecil file yang diakses secara aktif pada waktu tertentu dalam penerapan tipikal. Kelompok file ini disebut sebagai “set kerja”.

Jika beban kerja Anda secara teratur mengakses satu set file kerja yang lebih besar dari 5 juta, maka gateway Anda perlu melakukan penggusuran cache yang sering, yang merupakan operasi I/O kecil yang disimpan dalam RAM dan bertahan pada disk root. Ini dapat berdampak negatif pada kinerja gateway saat gateway mengambil data baru dari Amazon S3.

Anda dapat memantau IndexEvictions metrik untuk menentukan jumlah file yang metadatanya dikeluarkan dari cache untuk memberi ruang bagi entri baru. Untuk informasi selengkapnya, lihat Memahami metrik gateway.

Sebaiknya gunakan tindakan UpdateGatewayInformation API untuk meningkatkan kapasitas gateway agar sesuai dengan jumlah file dalam set kerja tipikal Anda. Untuk informasi selengkapnya, lihat UpdateGatewayInformation.

catatan

Meningkatkan kapasitas gateway membutuhkan RAM tambahan dan kapasitas root disk.

• Kecil (5 juta file) membutuhkan setidaknya 16 GB RAM dan 80 GB root disk.

• Medium (10 juta file) membutuhkan setidaknya 32 GB RAM dan 160 GB root disk.

• Besar (20 juta file) membutuhkan 64 GB RAM dan 240 GB root disk.

penting

Kapasitas gateway tidak dapat dikurangi.

Terapkan beberapa gateway untuk beban kerja yang lebih besar

Sebaiknya pisahkan beban kerja Anda di beberapa gateway bila memungkinkan, daripada mengkonsolidasikan banyak pembagian file pada satu gateway besar. Misalnya, Anda dapat mengisolasi satu berbagi file yang banyak digunakan pada satu gateway, sambil mengelompokkan berbagi file yang jarang digunakan bersama-sama di gateway lain.

Saat merencanakan penerapan dengan beberapa gateway dan berbagi file, pertimbangkan hal berikut:

• Jumlah maksimum berbagi file pada satu gateway adalah 50, tetapi jumlah berbagi file yang dikelola oleh gateway dapat memengaruhi kinerja gateway. Untuk informasi selengkapnya, lihat Panduan kinerja untuk gateway dengan beberapa berbagi file.

• Sumber daya pada setiap Gateway File S3 dibagikan di semua pembagian file, tanpa partisi.

• Berbagi file tunggal dengan penggunaan berat dapat memengaruhi kinerja berbagi file lain di gateway.

catatan

Kami tidak menyarankan membuat beberapa berbagi file yang dipetakan ke lokasi Amazon S3 yang sama dari beberapa gateway, kecuali setidaknya satu di antaranya hanya-baca.

Menulis simultan ke file yang sama dari beberapa gateway dianggap sebagai skenario multi-penulis, yang dapat menyebabkan masalah integritas data.