Skalabilitas dan target performa Azure Files

Azure Files menawarkan berbagi file yang dikelola sepenuhnya di cloud yang dapat diakses melalui protokol sistem file SMB dan NFS. Artikel ini membahas skalabilitas dan target performa untuk Azure Files dan Azure File Sync.

Target yang tercantum di sini mungkin dipengaruhi oleh variabel lain dalam penyebaran Anda. Misalnya, performa I/O untuk file mungkin terpengaruh oleh perilaku klien SMB Anda dan oleh bandwidth jaringan yang tersedia. Anda harus menguji pola penggunaan untuk menentukan apakah skalabilitas dan performa Azure Files memenuhi persyaratan.

Berlaku untuk

Jenis berbagi File SMB NFS
Berbagi file standar (GPv2), LRS/ZRS Ya Tidak
Berbagi file standar (GPv2), GRS/GZRS Ya Tidak
Berbagi file premium (FileStorage), LRS/ZRS Ya Ya

Target skala Azure Files

berbagi file Azure disebarkan ke akun penyimpanan, yang merupakan objek tingkat atas yang mewakili gabungan penyimpanan bersama. Kumpulan penyimpanan ini dapat digunakan untuk menyebarkan beberapa berbagi file. Oleh karena itu, ada tiga kategori yang perlu dipertimbangkan: akun penyimpanan, Azure file share, dan file.

Target skala akun penyimpanan

Target skala akun penyimpanan berlaku di tingkat akun penyimpanan. Ada dua jenis akun penyimpanan utama Azure Files:

  • Akun penyimpanan tujuan umum versi 2 (GPv2): Akun penyimpanan GPv2 memungkinkan Anda menyebarkan berbagi file Azure pada perangkat keras standar/berbasis hard disk (berbasis HDD). Selain menyimpan berbagi file Azure, akun penyimpanan GPv2 dapat menyimpan sumber daya penyimpanan lain seperti kontainer blob, antrean, atau tabel. Berbagi dapat digunakan ke dalam tingkat transaksi yang dioptimalkan (default), panas, atau dingin.

  • Akun penyimpanan FileStorage:Akun penyimpanan FileStorage memungkinkan Anda menyebarkan berbagi file Azure pada perangkat keras premium/berbasis solid-state disk (berbasis SSD). Akun FileStorage hanya dapat digunakan untuk menyimpan berbagi file Azure; tidak ada sumber daya penyimpanan lain (kontainer blob, antrean, tabel, dll.) yang dapat digunakan di akun FileStorage.

Atribut Akun penyimpanan GPv2 (standar) Akun penyimpanan FileStorage (premium)
Jumlah akun penyimpanan per wilayah per langganan 2501 2501
Kapasitas akun penyimpanan maksimum 5 PiB2 100 TiB (tersedia)
Jumlah maksimum berbagi file Tidak Terbatas Tidak terbatas, ukuran total yang tersedia dari semua berbagi file harus kurang dari maksimal kapasitas akun penyimpanan maksimum
Tingkat permintaan bersamaan maksimum 20.000 IOPS2 102.400 IOPS
Throughput (masuk + keluar) untuk LRS/GRS
  • Australia Timur
  • US Tengah
  • Asia Timur
  • US Timur 2
  • Jepang Timur
  • Korea Tengah
  • Eropa Utara
  • US Tengah Selatan
  • Asia Tenggara
  • UK Selatan
  • Eropa Barat
  • US Barat
  • Masuk: 7.152 MiB/detik
  • Keluar: 14.305 MiB/detik
10.340 MiB/detik
Throughput (masuk + keluar) untuk ZRS
  • Australia Timur
  • US Tengah
  • US Timur
  • AS Timur 2
  • Jepang Timur
  • Eropa Utara
  • US Tengah Selatan
  • Asia Tenggara
  • UK Selatan
  • Eropa Barat
  • US Barat 2
  • Masuk: 7.152 MiB/detik
  • Keluar: 14.305 MiB/detik
10.340 MiB/detik
Throughput (masuk + keluar) untuk kombinasi redundansi/wilayah yang tidak tercantum dalam baris sebelumnya
  • Masuk: 2.980 MiB/detik
  • Keluar: 5.960 MiB/detik
10.340 MiB/detik
Jumlah maksimum aturan jaringan virtual 200 200
Jumlah maksimum aturan alamat IP 200 200
Operasi baca manajemen 800 per 5 menit 800 per 5 menit
Operasi tulis manajemen 10 per detik/1200 per jam 10 per detik/1200 per jam
Operasi daftar manajemen 100 per 5 menit 100 per 5 menit

1 Dengan peningkatan kuota, Anda dapat membuat hingga 500 akun penyimpanan dengan titik akhir standar per wilayah. Untuk informasi selengkapnya, lihat Meningkatkan kuota akun Azure Storage. 2 Akun penyimpanan tujuan umum versi 2 mendukung batas kapasitas yang lebih tinggi dan batas yang lebih tinggi untuk masuk berdasarkan permintaan. Untuk meminta peningkatan batas akun, hubungi Dukungan Azure.

Target skala Azure file share

Target skala berbagi file Azure berlaku di tingkat berbagi file.

Atribut Berbagi file standar1 Berbagi premium
Ukuran minimum berbagi file Tidak ada minimum 100 GiB (tersedia)
Unit peningkatan/penurunan ukuran yang tersedia T/A 1 GiB
Ukuran maksimum berbagi file
  • 100 TiB, dengan fitur berbagi file besar diaktifkan2
  • 5 TiB, default
100 TiB
Jumlah maksimum file dalam berbagi file Tidak ada batasan Tidak ada batasan
Tingkat permintaan maksimum (Max IOPS)
  • 20.000, dengan fitur berbagi file besar diaktifkan2
  • 1.000 atau 100 permintaan per 100 md, default
  • IOPS Garis Besar: 3000 + 1 IOPS per GiB, hingga 102.400
  • Bursting IOPS: Maks (10.000, 3x IOPS per GiB), hingga 102.400
Throughput (masuk + keluar) untuk berbagi file tunggal (MiB/detik)
  • Hingga batas akun penyimpanan, dengan fitur berbagi file besar diaktifkan2
  • Hingga 60 MiB/dtk, default
100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)
Jumlah maksimum rekam jepret berbagi 200 rekam jepret 200 rekam jepret
Panjang nama objek maksimum3 (nama jalur lengkap termasuk semua direktori, nama file, dan karakter garis miring terbalik) 2.048 karakter 2.048 karakter
Panjang komponen nama jalur individual maksimum3 (di jalur \A\B\C\D, setiap huruf mewakili direktori atau file yang merupakan komponen individual) 255 karakter 255 karakter
Batas tautan keras (hanya NFS) T/A 178
Jumlah maksimum saluran Multisaluran SMB T/A 4
Jumlah maksimum kebijakan akses yang disimpan per berbagi file 5 5

1 Batasan untuk berbagi file standar berlaku untuk ketiga tingkatan yang tersedia untuk berbagi file standar: transaksi yang dioptimalkan, panas, dan dingin.

2 Default di berbagi file standard adalah 5 TiB, lihat Membuat berbagi file Azure untuk detail tentang cara membuat berbagi file dengan ukuran 100 TiB dan meningkatkan berbagi file standar yang ada hingga 100 TiB. Untuk memanfaatkan target skala yang lebih besar, Anda harus mengubah kuota sehingga lebih besar dari 5 TiB.

3 Azure Files menerapkan aturan penamaan tertentu untuk direktori dan nama file.

Target skala file

Target skala file berlaku untuk file individual yang disimpan di berbagi file Azure.

Atribut File dalam berbagi file standar File dalam berbagi file premium
Ukuran file maksimal 4 TiB 4 TiB
Tingkat permintaan bersamaan maksimum 1\.000 IOPS Hingga 8.0001
Ingress maksimum untuk sebuah file 60 MiB/dtk 200 MiB/dtk (Hingga 1 GiB/dtk dengan Multisaluran SMB)2
Egress maksimum untuk sebuah file 60 MiB/dtk 300 MiB/dtk (Hingga 1 GiB/dtk dengan Multisaluran SMB)2
Handel bersamaan maksimum untuk direktoriakar 3 10.000 handel 10.000 handel
Handel bersamaan maksimum per file dan direktori3 2\.000 handel 2\.000 handel

1 Berlaku untuk membaca dan menulis I/Os (biasanya ukuran I/O yang lebih kecil kurang dari atau sama dengan 64 KiB). Operasi metadata, selain baca dan tulis, mungkin lebih rendah. Ini adalah batas lunak, dan pembatasan dapat terjadi di luar batas ini.

2 Tunduk pada batas jaringan mesin, bandwidth yang tersedia, ukuran I/O, kedalaman antrean, dan faktor lainnya. Untuk detailnya lihat Performa SMB Multichannel.

3 Azure Files mendukung 10.000 handel terbuka pada direktori akar dan 2.000 handel terbuka per file dan direktori dalam berbagi. Jumlah pengguna aktif yang didukung per berbagi tergantung pada aplikasi yang mengakses berbagi. Jika aplikasi Anda tidak membuka handel di direktori akar, Azure Files dapat mendukung lebih dari 10.000 pengguna aktif per berbagi. Namun, jika Anda menggunakan Azure Files untuk menyimpan gambar disk untuk beban kerja desktop virtual skala besar, Anda mungkin kehabisan handel untuk direktori akar atau per file/direktori. Dalam hal ini, Anda mungkin perlu menggunakan beberapa berbagi file Azure. Untuk informasi selengkapnya, lihat Panduan ukuran Azure Files untuk Azure Virtual Desktop.

Panduan ukuran Azure Files untuk Azure Virtual Desktop

Kasus penggunaan populer untuk Azure Files adalah menyimpan kontainer profil pengguna dan gambar disk untuk Azure Virtual Desktop, menggunakan FSLogix atau App attach. Dalam penyebaran Azure Virtual Desktop skala besar, Anda mungkin kehabisan handel untuk direktori akar atau per file/direktori jika Anda menggunakan satu berbagi file Azure. Bagian ini menjelaskan bagaimana handel dikonsumsi oleh berbagai jenis gambar disk, dan memberikan panduan ukuran tergantung pada teknologi yang Anda gunakan.

FSLogix

Jika Anda menggunakan FSLogix dengan Azure Virtual Desktop, kontainer profil pengguna Anda adalah file Virtual Hard Disk (VHD) atau Hyper-V Virtual Hard Disk (VHDX), dan dipasang dalam konteks pengguna, bukan konteks sistem. Setiap pengguna akan membuka satu handel direktori akar, yang harus ke berbagi file. Azure Files dapat mendukung maksimum 10.000 pengguna dengan asumsi Anda memiliki berbagi file (\\storageaccount.file.core.windows.net\sharename) + direktori profil (%sid%_%username%) + kontainer profil (profile_%username.vhd(x)).

Jika Anda mencapai batas 10.000 handel bersamaan untuk direktori akar atau pengguna melihat performa yang buruk, coba gunakan berbagi file Azure tambahan dan distribusikan kontainer di antara berbagi.

Peringatan

Meskipun Azure Files dapat mendukung hingga 10.000 pengguna bersamaan dari satu berbagi file, sangat penting untuk menguji beban kerja Anda dengan benar terhadap ukuran dan jenis berbagi file yang telah Anda buat. Persyaratan Anda mungkin bervariasi berdasarkan pengguna, ukuran profil, dan beban kerja.

Misalnya, jika Anda memiliki 2.400 pengguna bersamaan, Anda memerlukan 2.400 handel pada direktori akar (satu untuk setiap pengguna), yang berada di bawah batas 10.000 handel terbuka. Untuk pengguna FSLogix, mencapai batas 2.000 file terbuka dan handel direktori sangat tidak mungkin. Jika Anda memiliki satu kontainer profil FSLogix per pengguna, Anda hanya akan menggunakan dua handel file/direktori: satu untuk direktori profil dan satu untuk file kontainer profil. Jika pengguna memiliki masing-masing dua kontainer (profil dan ODFC), Anda memerlukan satu handel tambahan untuk file ODFC.

Lampiran aplikasi dengan CimFS

Jika Anda menggunakan MSIX App attach atau App attach untuk melampirkan aplikasi secara dinamis, Anda dapat menggunakan file Composite Image File System (CimFS) atau VHD/VHDX untuk gambar disk. Bagaimanapun, batas skala adalah per VM yang memasang gambar, bukan per pengguna. Jumlah pengguna tidak relevan saat menghitung batas skala. Ketika VM di-boot, VM memasang gambar disk, bahkan jika tidak ada pengguna.

Jika Anda menggunakan App attach dengan CimFS, gambar disk hanya menggunakan handel pada file gambar disk. Mereka tidak menggunakan handel pada direktori akar atau direktori yang berisi gambar disk. Namun, karena citra CimFS adalah kombinasi dari file .cim dan setidaknya dua file lainnya, untuk setiap VM yang memasang gambar disk, Anda memerlukan satu handel masing-masing untuk tiga file di direktori. Jadi, jika Anda memiliki 100 VM, Anda memerlukan 300 handel file.

Anda mungkin kehabisan handel file jika jumlah VM per aplikasi melebihi 2.000. Dalam hal ini, gunakan berbagi file Azure tambahan.

Lampiran aplikasi dengan VHD/VHDX

Jika Anda menggunakan Lampiran aplikasi dengan file VHD/VHDX, file dipasang dalam konteks sistem, bukan konteks pengguna, dan file tersebut dibagikan dan baca-saja. Lebih dari satu handel pada file VHDX dapat dikonsumsi oleh sistem penghubung. Untuk tetap berada dalam batas skala Azure Files, jumlah VM yang dikalikan dengan jumlah aplikasi harus kurang dari 10.000, dan jumlah VM per aplikasi tidak boleh melebihi 2.000. Jadi kendalanya adalah mana pun yang Anda tekan terlebih dahulu.

Dalam skenario ini, Anda dapat mencapai batas per file/direktori dengan 2.000 pemasangan satu VHD/VHDX. Atau, jika berbagi berisi beberapa file VHD/VHDX, Anda dapat mencapai batas direktori akar terlebih dahulu. Misalnya, 100 VM yang memasang 100 file VHDX bersama akan mencapai batas direktori akar penanganan 10.000.

Dalam contoh lain, 100 VM yang mengakses 20 aplikasi akan memerlukan 2.000 handel direktori akar (100 x 20 = 2.000), yang berada dalam batas 10.000 untuk handel direktori akar. Anda juga memerlukan handel file dan handel direktori/folder untuk setiap VM yang memasang gambar VHD(X), sehingga 200 handel dalam hal ini (100 handel file + 100 handel direktori), yang nyaman di bawah batas 2.000 handel per file/direktori.

Jika Anda mencapai batasan handel bersamaan maksimum untuk direktori akar atau per file/direktori, gunakan berbagi file Azure tambahan.

Target skala Sinkronisasi File Azure

Tabel berikut menunjukkan target mana yang lunak, mewakili batas yang diuji Microsoft, dan keras, menunjukkan maksimum yang diberlakukan:

Sumber daya Target Batas keras
Layanan Sinkronisasi Penyimpanan per wilayah 100 Layanan Sinkronisasi Penyimpanan Ya
Storage Sync Services per langganan 15 Storage Sync Services Ya
Grup sinkronisasi per Layanan Sinkronisasi Penyimpanan 200 grup sinkronisasi Ya
Server terdaftar per Layanan Sinkronisasi Penyimpanan 99 server Ya
Titik akhir privat per Storage Sync Service 100 titik akhir privat Ya
Titik akhir cloud per grup sinkronisasi 1 titik akhir cloud Ya
Titik akhir server per grup sinkronisasi 100 titik akhir server Ya
Titik akhir server per server 30 titik akhir server Ya
Objek sistem file (direktori dan file) per grup sinkronisasi 100 juta objek Tidak
Jumlah maksimum objek sistem file (direktori dan file) dalam sebuah direktori (tidak rekursif) 5 juta objek Ya
Ukuran pendeskripsi keamanan objek (direktori dan berkas) maksimum 64 KiB Ya
Ukuran file 100 GiB Tidak
Ukuran file minimum untuk file yang akan bertingkat Berdasarkan ukuran kluster sistem file (ukuran kluster sistem file ganda). Misalnya, jika ukuran klaster sistem file adalah 4 KiB, ukuran file minimum adalah 8 KiB. Ya

Catatan

Titik akhir Azure File Sync dapat ditingkatkan ke ukuran Azure file share. Jika batas ukuran berbagi file Azure tercapai, sinkronisasi tidak akan dapat beroperasi.

Metrik kinerja Sinkronisasi File Azure

Karena agen Azure File Sync berjalan pada komputer Windows Server yang terhubung ke berbagi file Azure, performa sinkronisasi yang efektif tergantung pada sejumlah faktor dalam infrastruktur Anda: Windows Server dan konfigurasi disk yang mendasarinya, bandwidth jaringan antara server dan penyimpanan Azure, ukuran file, ukuran total himpunan data, dan aktivitas pada himpunan data. Karena Azure File Sync berfungsi pada tingkat file, karakteristik performa solusi berbasis Azure File Sync harus diukur berdasarkan jumlah objek (file dan direktori) yang diproses per detik.

Untuk Azure File Sync, performa sangat penting dalam dua tahap:

  1. Provisi satu kali awal: Untuk mengoptimalkan performa pada provisi awal, lihat Onboarding dengan Azure File Sync untuk mengetahui detail penyebaran yang optimal.
  2. Sinkronisasi yang sedang berlangsung: Setelah data awalnya diunggulkan dalam Azure file share, Azure File Sync membuat beberapa titik akhir tetap sinkron.

Catatan

Ketika banyak titik akhir server dalam grup sinkronisasi yang sama disinkronkan pada saat yang sama, mereka bersaing untuk sumber daya layanan cloud. Akibatnya, performa unggahan terpengaruh. Dalam kasus ekstrem, beberapa sesi sinkronisasi akan gagal mengakses sumber daya, dan akan gagal. Namun, sesi sinkronisasi tersebut akan segera dilanjutkan dan akhirnya berhasil setelah hambatan berkurang.

Hasil pengujian internal

Untuk membantu Anda merencanakan penyebaran untuk setiap tahapan (provisi satu kali awal dan sinkronisasi yang sedang berlangsung), berikut adalah hasil yang kami amati selama pengujian internal pada sistem dengan konfigurasi berikut:

Konfigurasi sistem Detail
CPU 64 Virtual Cores dengan cache 64 MiB L3
Memori 128 GiB
Disk Disk SAS dengan RAID 10 dengan cache yang didukung baterai
Jaringan Jaringan 1 Gbps
Beban kerja Server File Tujuan Umum

Provisi satu kali awal

Provisi satu kali awal Detail
Jumlah objek 25 juta objek
Ukuran Himpunan Data ~ 4.7 Tib
Ukuran File Rata-rata ~ 200 KiB (File Terbesar: 100 GiB)
Enumerasi perubahan cloud awal 80 objek per detik
Unggah Throughput 20 objek per detik per grup sinkronisasi
Throughput Pengunduhan Namespace Layanan 400 objek per detik

Enumerasi perubahan cloud awal: Saat grup sinkronisasi baru dibuat, enumerasi perubahan cloud awal adalah langkah pertama yang dijalankan. Dalam proses ini, sistem akan menghitung semua item dalam berbagi file Azure. Selama proses ini, tidak akan ada aktivitas sinkronisasi. Tidak ada item yang akan diunduh dari titik akhir cloud ke titik akhir server, dan tidak ada item yang akan diunggah dari titik akhir server ke titik akhir cloud. Aktivitas sinkronisasi akan dilanjutkan setelah enumerasi perubahan cloud awal selesai.

Tingkat performanya adalah 80 objek per detik. Anda dapat memperkirakan waktu yang diperlukan untuk menyelesaikan enumerasi perubahan cloud awal dengan menentukan jumlah item di berbagi cloud dan menggunakan rumus berikut untuk mendapatkan waktu dalam hari.

Waktu (dalam hari) untuk enumerasi cloud awal = (Jumlah objek di titik akhir cloud)/(80 * 60 * 60 * 24)

Sinkronisasi awal data dari Windows Server ke Azure File share: Banyak penyebaran Azure File Sync dimulai dengan Azure file share kosong karena semua data ada di Windows Server. Dalam kasus ini, enumerasi perubahan cloud awal cepat, dan sebagian besar waktu dihabiskan untuk menyinkronkan perubahan dari Windows Server ke berbagi file Azure.

Saat sinkronisasi mengunggah data ke berbagi file Azure, tidak ada waktu henti di server file lokal, dan administrator dapat mengatur batas jaringan untuk membatasi jumlah bandwidth yang digunakan untuk pengunggahan data latar belakang.

Sinkronisasi awal biasanya dibatasi oleh kecepatan unggah awal 20 file per detik per grup sinkronisasi. Pelanggan dapat memperkirakan waktu untuk mengunggah semua data ke Azure menggunakan rumus berikut untuk mendapatkan waktu dalam hitungan hari:

Waktu (dalam hari) untuk mengunggah file ke grup sinkronisasi = (Jumlah objek di titik akhir server)/(20 * 60 * 60 * 24)

Memisahkan data Anda menjadi beberapa titik akhir server dan grup sinkronisasi dapat mempercepat pengunggahan data awal ini, karena pengunggahan dapat dilakukan secara paralel untuk beberapa grup sinkronisasi dengan kecepatan masing-masing 20 item per detik. Jadi, dua grup sinkronisasi akan berjalan dengan kecepatan gabungan 40 item per detik. Total waktu penyelesaian akan menjadi perkiraan waktu untuk grup sinkronisasi dengan file terbanyak untuk disinkronkan.

Throughput unduhan namespace: Saat titik akhir server baru ditambahkan ke grup sinkronisasi yang sudah ada, agen Azure File Sync tidak mengunduh konten file apa pun dari titik akhir cloud. Pertama-tama, ia menyinkronkan namespace layanan lengkap dan kemudian memicu pengenalan ulang latar belakang untuk mengunduh file, baik secara keseluruhan atau, jika tingkatan cloud diaktifkan, ke kebijakan tingkatan cloud yang ditetapkan pada titik akhir server.

Sinkronisasi yang sedang berlangsung

Sinkronisasi yang sedang berlangsung Detail
Jumlah objek yang disinkronkan 125.000 objek (~1% churn)
Ukuran Himpunan Data 50 GiB
Ukuran File Rata-rata ~500 KiB
Unggah Throughput 20 objek per detik per grup sinkronisasi
Throughput Pengunduhan Lengkap* 60 objek per detik

*Jika penjenjangan cloud diaktifkan, Anda mungkin mengamati performa yang lebih baik karena hanya beberapa data file yang diunduh. Azure File Sync hanya mengunduh data file yang di-cache saat diubah di salah satu titik akhir. Untuk file berjenjang atau yang baru dibuat, agen tidak mengunduh data file, dan sebaliknya hanya menyinkronkan namespace layanan ke semua titik akhir server. Agen juga mendukung pengunduhan parsial file berjenjang saat diakses oleh pengguna.

Catatan

Angka-angka ini bukan indikasi performa yang akan Anda alami. Performa aktual tergantung pada beberapa faktor seperti yang diuraikan di awal bagian ini.

Sebagai panduan umum untuk penyebaran Anda, ingatlah beberapa hal:

  • Throughput objek kira-kira berskala sebanding dengan jumlah grup sinkronisasi di server. Memisahkan data menjadi beberapa grup sinkronisasi pada server menghasilkan throughput yang lebih baik, yang juga dibatasi oleh server dan jaringan.
  • Throughput objek berbanding terbalik dengan throughput MiB per detik. Untuk file yang lebih kecil, Anda akan mengalami throughput yang lebih tinggi dalam hal jumlah objek yang diproses per detik, tetapi throughput MiB per detik yang lebih rendah. Sebaliknya, untuk file yang lebih besar, Anda akan mendapatkan lebih sedikit objek yang diproses per detik, tetapi throughput MiB per detik yang lebih tinggi. Throughput MiB per detik dibatasi oleh target skala Azure Files.

Lihat juga