Amazon FSx File Gateway tidak lagi tersedia untuk pelanggan baru. Pelanggan FSx File Gateway yang ada dapat terus menggunakan layanan ini secara normal. Untuk kemampuan yang mirip dengan FSx File Gateway, kunjungi [posting blog ini](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kinerja dan optimasi
Bagian ini menjelaskan panduan dan praktik terbaik untuk mengoptimalkan kinerja File Gateway.
**Topics**
+ [Panduan kinerja dasar untuk](#performance-fgw)
+ [Mengoptimalkan kinerja gateway](#Optimizing-common)
+ [Memaksimalkan throughput Gateway File S3](Performance-Throughput.md)
+ [Mengoptimalkan Gateway File S3 untuk backup database SQL Server](SQL-Backup-Best-Practices.md)
## Panduan kinerja dasar untuk
Di bagian ini, Anda dapat menemukan panduan untuk penyediaan perangkat keras untuk FSx File Gateway VM Anda. Konfigurasi instance yang tercantum dalam tabel adalah contoh, dan disediakan untuk referensi.
Untuk kinerja terbaik, ukuran disk cache harus disetel ke ukuran set kerja aktif. Menggunakan beberapa disk lokal untuk cache meningkatkan kinerja penulisan dengan memparalelkan akses ke data dan mengarah ke IOPS yang lebih tinggi.
**catatan**
Kami tidak menyarankan menggunakan penyimpanan sementara. Untuk informasi tentang penggunaan penyimpanan sementara, lihat. [Menggunakan penyimpanan singkat dengan gateway EC2](ephemeral-disk-cache.md)
Batas ukuran yang disarankan untuk direktori individual dalam sistem file yang Anda sambungkan ke File Gateway adalah 10.000 file per direktori. Anda dapat menggunakan File Gateway dengan direktori yang memiliki lebih dari 10.000 file, tetapi kinerja mungkin terpengaruh.
Dalam tabel berikut, operasi baca *tekan cache* dibaca dari data file yang disajikan dari cache. Operasi *gagal baca cache* dibaca dari data file yang disajikan dari Amazon FSx untuk Windows File Server.
Tabel berikut menunjukkan contoh konfigurasi FSx File Gateway.
### FSx Kinerja File Gateway pada klien Windows
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/filegateway/latest/filefsxw/Performance.html)
**catatan**
Kinerja Anda mungkin bervariasi berdasarkan konfigurasi platform host dan bandwidth jaringan Anda. Kinerja throughput tulis menurun dengan ukuran file, dengan throughput tertinggi yang dapat dicapai untuk file kecil (kurang dari 32MiB) menjadi 16 file per detik.
## Mengoptimalkan kinerja gateway
Anda dapat menemukan informasi berikut tentang cara mengoptimalkan kinerja gateway Anda. Panduan ini didasarkan pada penambahan sumber daya ke gateway Anda dan menambahkan sumber daya ke server aplikasi Anda.
### Tambahkan Sumber Daya ke Gateway Anda
Anda dapat mengoptimalkan kinerja gateway dengan menambahkan sumber daya ke gateway Anda dengan satu atau beberapa cara berikut.
**Gunakan disk berkinerja lebih tinggi**
Untuk mengoptimalkan kinerja gateway, Anda dapat menambahkan disk berkinerja tinggi seperti solid-state drive (SSDs) dan pengontrol. NVMe Anda juga dapat melampirkan disk virtual ke VM Anda langsung dari jaringan area penyimpanan (SAN) alih-alih Microsoft Hyper-V NTFS. Peningkatan kinerja disk umumnya menghasilkan throughput yang lebih baik dan lebih banyak input/output operasi per detik (IOPS). Untuk informasi tentang menambahkan disk, lihat[Mengkonfigurasi penyimpanan cache tambahan](ConfiguringLocalDiskStorage.md).
Untuk mengukur throughput, gunakan `ReadBytes` dan `WriteBytes` metrik dengan statistik `Samples` Amazon CloudWatch . Misalnya, `Samples` statistik `ReadBytes` metrik selama periode sampel 5 menit dibagi 300 detik memberi Anda IOPS. Sebagai aturan umum, saat Anda meninjau metrik ini untuk gateway, cari throughput rendah dan tren IOPS rendah untuk menunjukkan kemacetan terkait disk.
CloudWatch metrik tidak tersedia untuk semua gateway. Untuk informasi tentang metrik gateway, lihat[Memantau Anda](monitoring-file-gateway.md).
**Tambahkan sumber daya CPU ke host gateway Anda**
Persyaratan minimum untuk server host gateway adalah empat prosesor virtual. Untuk mengoptimalkan kinerja gateway, konfirmasikan bahwa empat prosesor virtual yang ditugaskan ke VM gateway didukung oleh empat inti. Selain itu, konfirmasikan bahwa Anda tidak kelebihan langganan CPUs server host.
Ketika Anda menambahkan tambahan CPUs ke server host gateway Anda, Anda meningkatkan kemampuan pemrosesan gateway. Melakukan hal ini memungkinkan gateway Anda untuk menangani, secara paralel, baik menyimpan data dari aplikasi Anda ke penyimpanan lokal Anda dan mengunggah data ini ke S3 untuk Windows File Server. Tambahan CPUs juga membantu memastikan bahwa gateway Anda mendapatkan sumber daya CPU yang cukup saat host dibagikan dengan yang lain VMs. Menyediakan sumber daya CPU yang cukup memiliki efek umum meningkatkan throughput.
Storage Gateway mendukung penggunaan 24 CPUs di server host gateway Anda. Anda dapat menggunakan 24 CPUs untuk meningkatkan kinerja gateway Anda secara signifikan. Kami merekomendasikan konfigurasi gateway berikut untuk server host gateway Anda:
+ 24 CPUs.
+ 16 GiB RAM yang dicadangkan untuk File Gateways
+ 16 GiB RAM cadangan untuk gateway dengan ukuran cache hingga 16 TiB
+ 32 GiB RAM cadangan untuk gateway dengan ukuran cache 16 TiB hingga 32 TiB
+ 48 GiB RAM cadangan untuk gateway dengan ukuran cache 32 TiB hingga 64 TiB
+ Disk 1 melekat pada controller paravirtual 1, untuk digunakan sebagai cache gateway sebagai berikut:
+ SSD menggunakan NVMe pengontrol.
+ Adaptor jaringan 1 dikonfigurasi pada jaringan VM 1:
+ Gunakan jaringan VM 1 dan tambahkan VMXnet3 (10 Gbps) yang akan digunakan untuk konsumsi.
+ Adaptor jaringan 2 dikonfigurasi pada jaringan VM 2:
+ Gunakan jaringan VM 2 dan tambahkan VMXnet3 (10 Gbps) yang akan digunakan untuk terhubung. AWS
**Back gateway virtual disk dengan disk fisik terpisah**
Saat Anda menyediakan disk gateway, kami sangat menyarankan agar Anda tidak menyediakan disk lokal untuk penyimpanan lokal yang menggunakan disk penyimpanan fisik dasar yang sama. Misalnya, untuk VMware ESXi, sumber daya penyimpanan fisik yang mendasarinya direpresentasikan sebagai penyimpanan data. Saat Anda menyebarkan VM gateway, Anda memilih penyimpanan data untuk menyimpan file VM. Saat Anda menyediakan disk virtual (misalnya, sebagai buffer unggahan), Anda dapat menyimpan disk virtual di penyimpanan data yang sama dengan VM atau penyimpanan data yang berbeda.
Jika Anda memiliki lebih dari satu penyimpanan data, maka kami sangat menyarankan Anda memilih satu penyimpanan data untuk setiap jenis penyimpanan lokal yang Anda buat. Penyimpanan data yang didukung oleh hanya satu disk fisik yang mendasarinya dapat menyebabkan kinerja yang buruk. Contohnya adalah ketika Anda menggunakan disk seperti itu untuk mendukung penyimpanan cache dan mengunggah buffer dalam pengaturan gateway. Demikian pula, penyimpanan data yang didukung oleh konfigurasi RAID yang kurang berkinerja tinggi seperti RAID 1 dapat menyebabkan kinerja yang buruk.
### Tambahkan Sumber Daya ke Lingkungan Aplikasi Anda
**Tingkatkan bandwidth antara server aplikasi dan gateway Anda**
Untuk mengoptimalkan kinerja gateway, pastikan bandwidth jaringan antara aplikasi Anda dan gateway dapat mempertahankan kebutuhan aplikasi Anda. Anda dapat menggunakan `ReadBytes` dan `WriteBytes` metrik gateway untuk mengukur total throughput data.
Untuk aplikasi Anda, bandingkan throughput yang diukur dengan throughput yang diinginkan. Jika throughput yang diukur kurang dari throughput yang diinginkan, maka meningkatkan bandwidth antara aplikasi dan gateway Anda dapat meningkatkan kinerja jika jaringan adalah hambatan. Demikian pula, Anda dapat meningkatkan bandwidth antara VM dan disk lokal Anda, jika tidak terpasang langsung.
**Tambahkan sumber daya CPU ke lingkungan aplikasi Anda**
Jika aplikasi Anda dapat menggunakan sumber daya CPU tambahan, menambahkan lebih banyak CPUs dapat membantu aplikasi Anda untuk menskalakan I/O bebannya.
Beberapa operasi file pada FSx File Gateway, seperti penggantian nama folder tingkat atas atau perubahan izin, dapat menghasilkan beberapa operasi file yang mengarah ke I/O beban tinggi pada sistem file Windows File Server Anda FSx . Jika sistem file Anda tidak memiliki sumber daya kinerja yang cukup untuk beban kerja Anda, sistem file mungkin menghapus [salinan bayangan](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html) karena memprioritaskan ketersediaan untuk berkelanjutan I/O daripada retensi salinan bayangan historis.
Di FSx konsol Amazon, periksa halaman **Pemantauan dan kinerja** untuk melihat apakah sistem file Anda kurang disediakan. Jika ya, Anda dapat beralih ke penyimpanan SSD, meningkatkan kapasitas throughput, atau meningkatkan IOPS SSD untuk menangani beban kerja Anda.
# 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 AWS instans Amazon 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 instans Amazon EC2 Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 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:
+ `IoWaitPercent`melaporkan 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html).
+ Sebaiknya gunakan salah satu NVMe atau SSD untuk disk root dan cache gateway Anda untuk meminimalkan`IoWaitPercent`.
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) 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 dasar 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).
Saat menerapkan S3 File Gateway sebagai instans Amazon EC2, 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 instans Amazon EC2 yang direkomendasikan untuk Gateway File S3, lihat [Persyaratan untuk jenis instans Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Anda dapat mengubah jenis instans Amazon EC2 yang menghosting Gateway File S3 aktif. Ini memungkinkan Anda untuk dengan mudah menyesuaikan pembuatan perangkat keras Amazon EC2 dan alokasi sumber daya untuk menemukan rasio yang ideal. price-to-performance Untuk mengubah jenis instans, gunakan prosedur berikut di konsol Amazon EC2:
1. Hentikan instans Amazon EC2.
1. Ubah jenis instans Amazon EC2.
1. Nyalakan instans Amazon EC2.
**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 instans Amazon EC2 mengacu pada berapa banyak daya komputasi yang Anda dapatkan untuk harga yang Anda bayar. Biasanya, instans Amazon EC2 generasi yang lebih baru menawarkan rasio price-to-performance 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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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. Contoh:
`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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/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. Contoh:
`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](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113) di situs web Microsoft Learn.
+ FIO menggunakan `numjobs` parameter untuk mengontrol jumlah thread paralel. Contoh:
`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](https://linux.die.net/man/1/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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).
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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
**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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
Sebaiknya gunakan tindakan `UpdateGatewayInformation` API untuk meningkatkan kapasitas gateway agar sesuai dengan jumlah file dalam set kerja tipikal Anda. Untuk informasi selengkapnya, lihat [UpdateGatewayInformation](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html).
**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](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares).
+ Sumber daya pada setiap Gateway File S3 dibagikan di semua berbagi 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.
# Mengoptimalkan Gateway File S3 untuk backup database SQL Server
Pencadangan basis data adalah kasus penggunaan yang umum dan direkomendasikan untuk S3 File Gateway, yang menyediakan retensi jangka pendek dan jangka panjang yang hemat biaya dengan menyimpan cadangan basis data di Amazon S3, dengan kemampuan siklus hidup untuk menurunkan tingkat penyimpanan biaya sesuai kebutuhan. Dengan solusi ini, Anda dapat mengurangi kebutuhan akan aplikasi cadangan perusahaan menggunakan alat bawaan seperti SQL Server Management Studio dan Oracle RMAN.
Bagian berikut menjelaskan praktik terbaik untuk menyetel penerapan Gateway File S3 Anda untuk kinerja yang dioptimalkan dan dukungan hemat biaya untuk ratusan terabyte cadangan database SQL. 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 AWS instans Amazon 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.
## Menerapkan gateway Anda di lokasi yang sama dengan SQL Server
Sebaiknya gunakan alat virtual S3 File Gateway Anda di lokasi fisik dengan latensi jaringan sesedikit mungkin antara itu dan server SQL Anda. Saat memilih lokasi untuk gateway Anda, pertimbangkan hal berikut:
+ Latensi jaringan yang lebih rendah ke gateway dapat membantu meningkatkan kinerja klien SMB, seperti server SQL.
+ 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 server SQL dalam grup penempatan yang sama. Untuk informasi selengkapnya, lihat [Grup penempatan untuk instans Amazon EC2 Anda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) 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:
+ `IoWaitPercent`melaporkan 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html).
+ Sebaiknya gunakan salah satu NVMe atau SSD untuk disk root dan cache gateway Anda untuk meminimalkan`IoWaitPercent`.
## Sesuaikan alokasi sumber daya mesin virtual S3 File Gateway 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) 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 dasar 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).
Saat menerapkan S3 File Gateway sebagai instans Amazon EC2, 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 instans Amazon EC2 yang direkomendasikan untuk Gateway File S3, lihat [Persyaratan untuk jenis instans Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Anda dapat mengubah jenis instans Amazon EC2 yang menghosting Gateway File S3 aktif. Ini memungkinkan Anda untuk dengan mudah menyesuaikan pembuatan perangkat keras Amazon EC2 dan alokasi sumber daya untuk menemukan rasio yang ideal. price-to-performance Untuk mengubah jenis instans, gunakan prosedur berikut di konsol Amazon EC2:
1. Hentikan instans Amazon EC2.
1. Ubah jenis instans Amazon EC2.
1. Nyalakan instans Amazon EC2.
**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 instans Amazon EC2 mengacu pada berapa banyak daya komputasi yang Anda dapatkan untuk harga yang Anda bayar. Biasanya, instans Amazon EC2 generasi yang lebih baru menawarkan rasio price-to-performance 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.
## Tingkatkan throughput klien SMB dengan menyesuaikan tingkat keamanan Gateway File S3 Anda
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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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.
## Tingkatkan throughput klien SMB dengan membagi cadangan SQL menjadi beberapa file
+ Sulit untuk mencapai kinerja throughput maksimum dengan S3 File Gateway yang hanya satu server SQL menulis satu file pada satu waktu, karena penulisan berurutan dari server SQL tunggal adalah operasi single-threaded. Sebagai gantinya, sebaiknya gunakan beberapa thread dari setiap server SQL untuk menulis beberapa file secara paralel, dan menggunakan beberapa server SQL secara bersamaan ke S3 File Gateway Anda untuk memaksimalkan throughput gateway. Dengan cadangan SQL, membagi cadangan menjadi beberapa file memungkinkan setiap file menggunakan utas terpisah, yang akan menulis beberapa file secara bersamaan ke berbagi file S3 File Gateway. Semakin banyak thread yang Anda miliki, semakin banyak throughput yang dapat Anda capai, hingga batas gateway.
+ SQL Server mendukung penulisan ke beberapa file pada saat yang sama selama operasi pencadangan tunggal. Misalnya, Anda dapat menentukan beberapa tujuan file menggunakan perintah T-SQL atau SQL Server Management Studio (SSMS). Setiap file menggunakan thread terpisah untuk mengirim data dari server SQL ke berbagi file gateway. Pendekatan ini memungkinkan I/O throughput yang lebih baik, yang secara signifikan dapat meningkatkan kecepatan dan efisiensi cadangan.
Saat mengonfigurasi cadangan server SQL Anda, pertimbangkan hal berikut:
+ Dengan membagi backup menjadi beberapa file, admin SQL Server dapat mengoptimalkan waktu backup dan mengelola backup database besar dengan lebih efektif.
+ Jumlah file yang digunakan tergantung pada konfigurasi penyimpanan server dan persyaratan kinerja. Untuk database besar, kami sarankan untuk memecah cadangan menjadi beberapa file yang lebih kecil antara 10 GB dan 20 GB masing-masing.
+ Tidak ada batasan ketat pada berapa banyak file SQL Server dapat menulis ke selama backup, tetapi pertimbangan praktis seperti arsitektur penyimpanan dan bandwidth jaringan harus memandu pilihan ini.
Untuk informasi lebih lanjut, lihat:
+ [Cadangkan SQL Server 43-67% lebih cepat dengan menulis ke beberapa file](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [Simpan backup SQL Server Anda dengan mudah di Amazon S3 menggunakan File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## Mencegah kegagalan salinan file besar dengan meningkatkan pengaturan batas waktu SMB
Ketika S3 File Gateway menyalin file cadangan SQL besar ke berbagi file SMB, koneksi klien SMB dapat batas waktu setelah jangka waktu yang lama. Sebaiknya perpanjang pengaturan batas waktu sesi SMB untuk klien SMB SQL server 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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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 server SQL dengan kecepatan 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
**catatan**
Pengaturan ini menggunakan sumber daya CPU gateway tambahan. Kami merekomendasikan pemantauan penggunaan CPU gateway dan meningkatkan sumber daya CPU yang dialokasikan jika perlu.
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).
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 server SQL Anda. Waktu yang diperlukan untuk menyegarkan cache gateway dapat meningkat secara substansional tergantung pada jumlah file dan subdirektori di bucket Amazon S3 Anda.
## Terapkan beberapa gateway untuk mendukung beban kerja
Storage Gateway dapat mendukung backup SQL untuk lingkungan besar dengan ratusan database SQL, beberapa SQL Server, dan ratusan terabyte data cadangan dengan membagi beban kerja di beberapa gateway.
Saat merencanakan penyebaran dengan beberapa gateway dan server SQL, pertimbangkan hal berikut:
+ Sebuah gateway tunggal biasanya dapat mengunggah hingga 20 TB per hari, dengan sumber daya perangkat keras dan bandwidth yang memadai. Anda dapat meningkatkan batas ini hingga 40 TB per hari dengan [meningkatkan jumlah utas pengunggah Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads).
+ Sebaiknya lakukan proof-of-concept pengujian untuk mengukur kinerja dan memperhitungkan semua variabel dalam penerapan Anda. Setelah Anda menentukan throughput puncak beban kerja cadangan SQL Anda, Anda dapat menskalakan jumlah gateway untuk memenuhi kebutuhan Anda.
+ Kami merekomendasikan merancang solusi Anda dengan mempertimbangkan pertumbuhan, karena jumlah database dan ukuran database dapat meningkat seiring waktu. Untuk terus meningkatkan skala dan mendukung peningkatan beban kerja, Anda dapat menerapkan gateway tambahan sesuai kebutuhan.
## Sumber daya tambahan untuk beban kerja pencadangan basis data
+ [Simpan cadangan SQL Server di Amazon S3 menggunakan AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [Simpan backup SQL Server Anda dengan mudah di Amazon S3 menggunakan File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [Menggunakan AWS Storage Gateway untuk menyimpan cadangan database Oracle di Amazon S3](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Mencadangkan database Oracle ke Amazon S3 dalam skala besar](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [Integrasikan database SAP ASE ke Amazon S3 menggunakan AWS Storage Gateway](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [Bagaimana satu AWS Pahlawan menggunakan AWS Storage Gateway untuk pencadangan di cloud](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [Praktik terbaik ukuran cache S3 File Gateway](https://www.youtube.com/watch?v=-ibL1eEcROI)