Bagikan melalui

Memahami dan mengoptimalkan performa berbagi file Azure

Azure Files dapat memenuhi persyaratan performa untuk sebagian besar aplikasi dan kasus penggunaan. Artikel ini menjelaskan berbagai faktor yang dapat memengaruhi performa berbagi file dan cara mengoptimalkan performa berbagi file Azure untuk beban kerja Anda.

Berlaku untuk

Model manajemen Model tagihan Peringkat media Pemborosan SMB Network File System (NFS)
Microsoft.Storage Versi 2 yang telah disediakan SSD (kelas atas) Lokal (LRS) Tidak Ya
Microsoft.Storage Versi 2 yang telah disediakan SSD (kelas atas) Zona (ZRS) Tidak Ya
Microsoft.Storage Versi 2 yang telah disediakan HDD (standar) Lokal (LRS) Ya Tidak
Microsoft.Storage Versi 2 yang telah disediakan HDD (standar) Zona (ZRS) Ya Tidak
Microsoft.Storage Versi 2 yang telah disediakan HDD (standar) Geo (GRS) Ya Tidak
Microsoft.Storage Versi 2 yang telah disediakan HDD (standar) GeoZone (GZRS) Ya Tidak
Microsoft.Storage Versi 1 yang telah disediakan SSD (kelas atas) Lokal (LRS) Ya Ya
Microsoft.Storage Versi 1 yang telah disediakan SSD (kelas atas) Zona (ZRS) Ya Ya
Microsoft.Storage Bayar per penggunaan HDD (standar) Lokal (LRS) Ya Tidak
Microsoft.Storage Bayar per penggunaan HDD (standar) Zona (ZRS) Ya Tidak
Microsoft.Storage Bayar per penggunaan HDD (standar) Geo (GRS) Ya Tidak
Microsoft.Storage Bayar per penggunaan HDD (standar) GeoZone (GZRS) Ya Tidak

Glosarium

Sebelum membaca artikel ini, sangat berguna untuk memahami beberapa istilah utama yang berkaitan dengan performa penyimpanan:

  • Operasi IO per detik (IOPS)

    IOPS, atau operasi input/output per detik, mengukur jumlah operasi sistem file per detik. Istilah "IO" dapat dipertukarkan dengan istilah "operasi" dan "transaksi" dalam dokumentasi Azure Files.

  • Ukuran I/O

    Ukuran I/O, kadang-kadang disebut sebagai ukuran blok, adalah ukuran permintaan yang digunakan aplikasi untuk melakukan operasi input/output tunggal (I/O) pada penyimpanan. Tergantung pada aplikasi, ukuran I/O dapat berkisar dari ukuran kecil seperti 4 KiB hingga ukuran yang lebih besar. Ukuran I/O memainkan peran utama dalam throughput yang dapat dicapai.

  • Throughput

    Throughput mengukur jumlah bit yang dibaca dari atau ditulis ke penyimpanan per detik, dan diukur dalam mebibyte per detik (MiB/s). Untuk menghitung throughput, kalikan IOPS dengan ukuran I/O. Misalnya, ukuran I/O 10.000 IOPS _ 1 MiB = 10 GiB/dtk, sedangkan 10.000 IOPS _ 4 KiB ukuran I/O = 38 MiB/dtk.

  • Latensi

    Latensi adalah sinonim untuk penundaan dan diukur dalam milidetik (ms). Ada dua jenis latensi: latensi end-to-end dan latensi layanan. Untuk informasi selengkapnya, lihat Latensi.

  • Kedalaman antrean

    Kedalaman antrean adalah jumlah permintaan I/O yang tertunda yang dapat ditangani sumber daya penyimpanan kapan saja. Untuk informasi selengkapnya, lihat Kedalaman antrean.

Memilih tingkat media berdasarkan pola penggunaan

Azure Files menyediakan dua tingkat media penyimpanan memungkinkan Anda menyeimbangkan performa dan harga: SSD dan HDD. Anda memilih tingkat media berbagi file di tingkat akun penyimpanan, dan setelah Anda membuat akun penyimpanan di tingkat media tertentu, Anda tidak dapat berpindah ke yang lain tanpa bermigrasi secara manual ke berbagi file baru.

Saat memilih antara berbagi file SSD dan HDD, penting untuk memahami persyaratan pola penggunaan yang diharapkan yang anda rencanakan untuk dijalankan di Azure Files. Jika Anda memerlukan IOPS dalam jumlah besar, kecepatan transfer data cepat, atau latensi rendah, maka Anda harus memilih berbagi file SSD.

Tabel berikut ini meringkas target performa yang diharapkan antara berbagi file SSD dan HDD. Untuk detailnya, lihat Skalabilitas Azure Files dan target performa.

Persyaratan pola penggunaan SSD HDD
Latensi tulis (milidetik satu digit) Ya Ya
Latensi baca (milidetik satu digit) Ya Tidak

Saham file SSD menawarkan model penyediaan yang menjamin profil kinerja berikut berdasarkan ukuran saham. Untuk informasi selengkapnya, lihat model v1 yang disediakan.

Daftar Periksa Kinerja

Apakah Anda menilai persyaratan performa untuk beban kerja baru atau yang sudah ada, memahami pola penggunaan Anda membantu Anda mencapai performa yang dapat diprediksi.

  • Sensitivitas latensi: Beban kerja yang sensitif terhadap latensi baca dan memiliki visibilitas tinggi kepada pengguna akhir lebih cocok untuk berbagi file SSD, yang dapat memberikan latensi milidetik tunggal untuk operasi baca dan tulis (< 2 md untuk ukuran I/O kecil).

  • Persyaratan IOPS dan throughput: Berbagi file SSD mendukung batas IOPS dan throughput yang lebih besar daripada berbagi file HDD. Lihat target skala berbagi berkas untuk informasi lebih lanjut.

  • Durasi dan frekuensi beban kerja: Beban kerja pendek (menit) dan jarang (per jam) cenderung tidak mencapai batas performa atas berbagi file HDD dibandingkan dengan beban kerja yang berjalan lama dan sering terjadi. Pada berbagi file SSD, durasi beban kerja sangat membantu saat menentukan profil performa yang benar untuk digunakan berdasarkan penyimpanan, IOPS, dan throughput yang disediakan. Kesalahan umum adalah menjalankan pengujian performa hanya selama beberapa menit, yang sering menyesatkan. Untuk mendapatkan tampilan performa yang realistis, pastikan untuk menguji pada frekuensi dan durasi yang cukup tinggi.

  • Paralelisasi beban kerja: Untuk beban kerja yang melakukan operasi secara paralel, seperti melalui beberapa utas, proses, atau instans aplikasi pada klien yang sama, berbagi file SSD memberikan keuntungan yang jelas daripada berbagi file HDD: SMB Multichannel. Lihat Meningkatkan performa berbagi file SMB Azure untuk informasi selengkapnya.

  • Distribusi operasi API: Beban kerja berat metadata, seperti beban kerja yang melakukan operasi baca terhadap sejumlah besar file, lebih cocok untuk berbagi file SSD. Lihat Metadata atau beban kerja berat namespace.

Latensi

Saat memikirkan latensi, penting untuk terlebih dahulu memahami bagaimana latensi ditentukan dengan Azure Files. Pengukuran yang paling umum adalah latensi yang terkait dengan latensi end-to-end dan metrik latensi layanan. Menggunakan metrik transaksi ini dapat membantu mengidentifikasi latensi sisi klien dan/atau masalah jaringan dengan menentukan berapa banyak waktu yang dihabiskan lalu lintas aplikasi Anda saat transit ke dan dari klien.

  • Latensi end-to-end (SuccessE2ELatency) adalah total waktu yang diperlukan transaksi untuk melakukan perjalanan pulang-pergi dari klien, melalui jaringan, ke layanan Azure Files, dan kembali ke klien.

  • Latensi Layanan (SuccessServerLatency) adalah waktu yang diperlukan untuk transaksi bolak-balik dalam jaringan hanya dalam Azure Files. Ini tidak termasuk klien atau latensi jaringan apa pun.

    Diagram membandingkan latensi klien dan latensi layanan untuk Azure Files.

Perbedaan antara nilai SuccessE2ELatency dan SuccessServerLatency adalah latensi yang kemungkinan disebabkan oleh jaringan dan/atau klien.

Biasanya membingungkan latensi klien dengan latensi layanan (dalam hal ini, performa Azure Files). Misalnya, jika latensi layanan melaporkan latensi rendah dan end-to-end melaporkan latensi yang sangat tinggi untuk permintaan, ini menunjukkan bahwa semua waktu dihabiskan saat transit ke dan dari klien, bukan di dalam layanan Azure Files.

Selain itu, seperti yang diilustrasikan diagram, semakin jauh Anda jauh dari layanan, semakin lambat pengalaman latensi, dan semakin sulit untuk mencapai batas skala performa dengan layanan cloud apa pun. Ini terutama berlaku saat mengakses Azure Files dari lokal. Meskipun opsi seperti ExpressRoute ideal untuk lokal, opsi tersebut masih tidak cocok dengan performa aplikasi (komputasi + penyimpanan) yang berjalan secara eksklusif di wilayah Azure yang sama.

Petunjuk

Menggunakan VM di Azure untuk menguji performa antara lokal dan Azure adalah cara yang efektif dan praktis untuk menggarisbawaikan kemampuan jaringan koneksi ke Azure. Sirkuit ExpressRoute atau gateway VPN yang berukuran kurang atau salah dirutekan dapat memperlambat beban kerja yang berjalan di Azure Files secara signifikan.

Kedalaman antrean

Kedalaman antrean adalah jumlah permintaan I/O yang tertunda yang dapat dilayani oleh sumber daya penyimpanan. Karena disk yang digunakan oleh sistem penyimpanan telah berevolusi dari spindel HDD (IDE, SATA, SAS) ke perangkat solid state (SSD, NVMe), disk tersebut juga telah berevolusi untuk mendukung kedalaman antrean yang lebih tinggi. Beban kerja yang terdiri dari satu klien yang berinteraksi secara serial dengan satu file dalam himpunan data besar adalah contoh kedalaman antrean rendah. Sebaliknya, beban kerja yang mendukung paralelisme dengan beberapa utas dan beberapa file dapat dengan mudah mencapai kedalaman antrean tinggi. Karena Azure Files adalah layanan file terdistribusi yang mencakup ribuan simpul kluster Azure dan dirancang untuk menjalankan beban kerja dalam skala besar, sebaiknya bangun dan uji beban kerja dengan kedalaman antrean tinggi.

Kedalaman antrean tinggi dapat dicapai dengan beberapa cara berbeda dengan menggabungkan klien, file, dan utas. Untuk menentukan kedalaman antrean untuk beban kerja Anda, kalikan jumlah klien dengan jumlah file dengan jumlah utas (klien _ file _ utas = kedalaman antrean).

Tabel di bawah ini menggambarkan berbagai kombinasi yang dapat Anda gunakan untuk mencapai kedalaman antrean yang lebih tinggi. Meskipun Anda dapat melebihi kedalaman antrean optimal sebesar 64, kami tidak menyarankannya. Anda tidak akan melihat peningkatan performa lagi jika Anda melakukannya, dan Anda berisiko meningkatkan latensi karena saturasi TCP.

Klien File Benang Kedalaman antrean
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Petunjuk

Untuk mencapai batas performa maksimum, pastikan beban kerja atau pengujian tolok ukur Anda menggunakan banyak utas dengan beberapa file.

Aplikasi utas tunggal versus aplikasi multi-utas

Azure Files paling cocok untuk aplikasi multi-utas. Cara termudah untuk memahami dampak performa yang dimiliki multithreading pada beban kerja adalah dengan memperhatikan skenario berdasarkan I/O. Dalam contoh berikut, kami memiliki beban kerja yang perlu menyalin 10.000 file kecil secepat mungkin ke atau dari berbagi file Azure.

Tabel ini memecah waktu yang diperlukan (dalam milidetik) untuk membuat satu file 16 KiB pada berbagi file Azure, berdasarkan aplikasi utas tunggal yang menulis dalam ukuran blok 4 KiB.

Operasi I/O Buat Penulisan 4 KiB Penulisan 4 KiB Penulisan 4 KiB Penulisan 4 KiB Tutup Seluruh
Utas 1 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk

Dalam contoh ini, dibutuhkan sekitar 14 ms untuk membuat satu file 16 KiB dari enam operasi. Jika aplikasi berutas tunggal ingin memindahkan 10.000 file ke berbagi file Azure, yang diterjemahkan menjadi 140.000 md (14 ms * 10.000) atau 140 detik karena setiap file dipindahkan secara berurutan satu per satu. Perlu diingat bahwa waktu untuk melayani setiap permintaan terutama ditentukan oleh seberapa dekat komputasi dan penyimpanan yang terletak satu sama lain, seperti yang dibahas di bagian sebelumnya.

Dengan menggunakan delapan utas alih-alih satu, beban kerja di atas dapat dikurangi dari 140.000 ms (140 detik) menjadi 17.500 ms (17,5 detik). Seperti yang ditunjukkan tabel di bawah ini, saat Anda memindahkan delapan file secara paralel alih-alih satu file sekaligus, Anda dapat memindahkan jumlah data yang sama dalam waktu 87,5% lebih sedikit.

Operasi I/O Buat Penulisan 4 KiB Penulisan 4 KiB Penulisan 4 KiB Penulisan 4 KiB Tutup Seluruh
Utas 1 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Rangkaian 2 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Utas 3 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Alur 4 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Utas 5 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Utas 6 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Utas 7 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk
Utas 8 3 mdtk 2 mdtk 2 mdtk 2 mdtk 2 mdtk 3 mdtk 14 mdtk

Lihat juga

  • Last updated on