Skalabilitas dan target performa untuk Azure Files dan Azure File Sync
Azure Files menawarkan berbagi file yang dikelola sepenuhnya di cloud yang dapat diakses melalui protokol sistem file Server Message Block (SMB) dan Network File System (NFS). Artikel ini membahas skalabilitas dan target performa untuk akun penyimpanan Azure, 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 |  |
 |
| Berbagi file standar (GPv2), GRS/GZRS | |
|
| Berbagi file premium (FileStorage), LRS/ZRS | |
|
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
|
|
10.340 MiB/detik |
Throughput (masuk + keluar) untuk ZRS
|
|
10.340 MiB/detik |
| Throughput (masuk + keluar) untuk kombinasi redundansi/wilayah yang tidak tercantum dalam baris sebelumnya |
|
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 | 100 TiB |
| Jumlah maksimum file dalam berbagi file | Tidak ada batasan | Tidak ada batasan |
| Tingkat permintaan maksimum (Max IOPS) | 20.000 |
|
| Throughput (masuk + keluar) untuk berbagi file tunggal (MiB/detik) | Hingga batas akun penyimpanan | 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 maksimum komponennama jalur individual 2 (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 Azure Files memberlakukan aturan penamaan tertentu untuk nama direktori dan 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:
- Provisi satu kali awal: Untuk mengoptimalkan performa pada provisi awal, lihat Onboarding dengan Azure File Sync untuk mengetahui detail penyebaran yang optimal.
- 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.