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
| Jenis berbagi File | SMB | NFS |
|---|---|---|
| Berbagi file standar (GPv2), LRS/ZRS |  |
 |
| Berbagi file standar (GPv2), GRS/GZRS | |
|
| Berbagi file premium (FileStorage), LRS/ZRS | |
|
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 yang sangat kecil seperti 4 KiB hingga ukuran yang jauh 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/dtk). Untuk menghitung throughput, kalikan IOPS dengan ukuran I/O. Misalnya, ukuran I/O 10.000 IOPS * 1 MiB I/O = 10 GiB/dtk, sedangkan 10.000 IOPS * ukuran I/O 4 KiB = 38 MiB/dtk.
Latensi
Latensi adalah sinonim untuk penundaan dan biasanya 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 performa berdasarkan pola penggunaan
Azure Files menyediakan berbagai tingkat penyimpanan yang membantu mengurangi biaya dengan memungkinkan Anda menyimpan data pada tingkat performa dan harga yang sesuai. Pada tingkat tertinggi, Azure Files menawarkan dua tingkat performa: standar dan premium. Berbagi file standar dihosting pada sistem penyimpanan yang didukung oleh hard disk drive (HDD), sementara berbagi file premium didukung oleh solid-state drive (SSD) untuk performa yang lebih baik. Berbagi file standar memiliki beberapa tingkat penyimpanan (transaksi dioptimalkan, panas, dan dingin) yang dapat Anda pindahkan dengan mulus antara untuk memaksimalkan penyimpanan data saat tidak aktif dan harga transaksi. Namun, Anda tidak dapat berpindah antara tingkat standar dan premium tanpa memigrasikan data Anda secara fisik di antara akun penyimpanan yang berbeda.
Saat memilih antara berbagi file standar dan premium, 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 yang sangat cepat, atau latensi yang sangat rendah, maka Anda harus memilih berbagi file Azure premium.
Tabel berikut ini meringkas target performa yang diharapkan antara standar dan premium. Untuk detailnya, lihat Skalabilitas Azure Files dan target performa.
| Persyaratan pola penggunaan | Standard | Premium |
|---|---|---|
| Latensi tulis (milidetik satu digit) | Ya | Ya |
| Latensi baca (milidetik satu digit) | Tidak | Ya |
Berbagi file premium menawarkan model provisi yang menjamin profil performa berikut berdasarkan ukuran berbagi. Untuk informasi selengkapnya, lihat Model yang disediakan. Kredit burst terakumulasi dalam wadah ledakan setiap kali lalu lintas untuk berbagi file Anda berada di bawah IOPS dasar. Kredit yang diperoleh digunakan nanti untuk mengaktifkan bursting ketika operasi akan melebihi IOPS dasar.
| Kapasitas (GiB) | IOPS Garis Besar | Burst IOPS | Kredit burst | Throughput (ingress + egress) |
|---|---|---|---|---|
| 100 | 3.100 | Hingga 10.000 | 24.840.000 | 110 MiB/dtk |
| 500 | 3.500 | Hingga 10.000 | 23.400.000 | 150 MiB/detik |
| 1,024 | 4.024 | Hingga 10.000 | 21.513.600 | 203 MiB/dtk |
| 5,120 | 8.120 | Hingga 15.360 | 26.064.000 | 613 MiB/dtk |
| 10,240 | 13.240 | Hingga 30.720 | 62.928.000 | 1.125 MiB/dtk |
| 33.792 | 36.792 | Hingga 100.000 | 227.548.800 | 3.480 MiB/dtk |
| 51,200 | 54.200 | Hingga 100.000 | 164.880.000 | 5.220 MiB/dtk |
| 102,400 | 100.000 | Hingga 100.000 | 0 | 10.340 MiB/dtk |
Daftar periksa performa
Baik Anda menilai persyaratan performa untuk beban kerja baru atau yang sudah ada, memahami pola penggunaan Anda akan membantu Anda mencapai performa yang dapat diprediksi. Konsultasikan dengan admin penyimpanan atau pengembang aplikasi Anda untuk menentukan pola penggunaan berikut.
Sensitivitas latensi: Apakah pengguna membuka file atau berinteraksi dengan desktop virtual yang berjalan di Azure Files? Ini adalah contoh beban kerja yang sensitif terhadap latensi baca dan juga memiliki visibilitas tinggi kepada pengguna akhir. Jenis beban kerja ini lebih cocok untuk berbagi file Azure premium, yang dapat memberikan latensi milidetik tunggal untuk operasi baca dan tulis (< 2 md untuk ukuran I/O kecil).
Persyaratan IOPS dan throughput: Berbagi file premium mendukung batas IOPS dan throughput yang lebih besar daripada berbagi file standar. Lihat target skala berbagi file untuk informasi selengkapnya.
Durasi dan frekuensi beban kerja: Beban kerja pendek (menit) dan jarang (per jam) akan lebih kecil kemungkinannya untuk mencapai batas performa atas berbagi file standar dibandingkan dengan beban kerja yang berjalan lama dan sering terjadi. Pada berbagi file premium, durasi beban kerja sangat membantu saat menentukan profil performa yang benar untuk digunakan berdasarkan ukuran provisi. Bergantung pada berapa lama beban kerja perlu meledak dan berapa lama waktu yang dihabiskan di bawah IOPS garis besar, Anda dapat menentukan apakah Anda mengumpulkan kredit yang cukup meledak untuk secara konsisten memenuhi beban kerja Anda pada waktu sibuk. Menemukan saldo yang tepat akan mengurangi biaya dibandingkan dengan provisi berbagi file secara berlebihan. 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 premium memberikan keuntungan yang jelas dibandingkan berbagi file standar: SMB Multichannel. Lihat Meningkatkan performa berbagi file SMB Azure untuk informasi selengkapnya.
Distribusi operasi API: Apakah metadata beban kerja berat dengan operasi buka/tutup file? Ini umum untuk beban kerja yang melakukan operasi baca terhadap sejumlah besar file. 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 lengkap dari klien, di seluruh jaringan, ke layanan Azure Files, dan kembali ke klien.
Latensi Layanan (SuccessServerLatency) adalah waktu yang diperlukan untuk transaksi untuk pulang pergi hanya dalam layanan Azure Files. Ini tidak termasuk klien atau latensi jaringan apa pun.
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, yang menunjukkan bahwa semua waktu dihabiskan saat transit ke dan dari klien, dan bukan di 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.
Tip
Menggunakan VM di Azure untuk menguji performa antara lokal dan Azure adalah cara yang efektif dan praktis untuk menggarisbawaikan kemampuan jaringan koneksi ke Azure. Seringkali beban kerja dapat diperlambat oleh sirkuit ExpressRoute atau gateway VPN yang berukuran kecil atau salah dirutekan.
Kedalaman antrean
Kedalaman antrean adalah jumlah permintaan I/O yang luar biasa yang dapat dilayankan 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 dalam kombinasi dengan 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 64, kami tidak merekomendasikannya. 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 |
Tip
Untuk mencapai batas performa atas, pastikan beban kerja atau pengujian tolok ukur Anda multi-utas dengan beberapa file.
Aplikasi tunggal versus multi-utas
Azure Files paling cocok untuk aplikasi multi-utas. Cara term mudah untuk memahami dampak performa yang dimiliki multi-utas pada beban kerja adalah dengan menelusuri skenario oleh 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 | Total |
|---|---|---|---|---|---|---|---|
| Rangkaian 1 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 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 | Total |
|---|---|---|---|---|---|---|---|
| Rangkaian 1 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Rangkaian 2 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Alur 3 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Alur 4 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Utas 5 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Utas 6 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Utas 7 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |
| Utas 8 | 3 md | 2 mdtk | 2 mdtk | 2 mdtk | 2 mdtk | 3 md | 14 mdtk |