Memahami model penagihan Azure Files

Azure Files mendukung dua tingkat penyimpanan media yang berbeda, SSD dan HDD. Ini memungkinkan Anda untuk menyesuaikan berbagi file Anda dengan persyaratan performa dan harga skenario Anda:

• SSD (premium): berbagi file yang dihosting pada solid-state drive (SSD) memberikan performa tinggi yang konsisten dan latensi rendah, dalam milidetik satu digit untuk sebagian besar operasi IO.
• HDD (standar): berbagi file yang dihosting pada hard disk drive (HDD) menyediakan penyimpanan hemat biaya untuk penggunaan tujuan umum.

Azure Files memiliki beberapa model penetapan harga, termasuk opsi yang ditentukan sebelumnya dan bayar sesuai penggunaan.

• Model penagihan yang disediakan: Dalam model penagihan yang disediakan, biaya utama berbagi file didasarkan pada jumlah penyimpanan, IOPS (operasi input dan output per detik), dan throughput yang Anda provisikan saat membuat atau memperbarui berbagi file Anda. Anda membayar berdasarkan apa yang Anda provisikan, terlepas dari berapa banyak yang benar-benar Anda gunakan. Azure Files memiliki dua model yang disediakan berbeda: v2 yang disediakan dan v1 yang disediakan.

  • V2 yang disediakan: Dalam model v2 yang disediakan untuk Azure Files, Anda memiliki kemampuan untuk memprovisikan penyimpanan, IOPS, dan throughput secara terpisah, meskipun kami memberikan rekomendasi bagi Anda untuk membantu Anda dalam provisi pertama kali.
  • V1 yang disediakan: Dalam model v1 yang disediakan untuk Azure Files, Anda menyediakan jumlah penyimpanan yang Anda butuhkan untuk berbagi, sementara IOPS dan throughput ditentukan berdasarkan berapa banyak penyimpanan yang Anda provisikan. Model v1 yang disediakan untuk Azure Files hanya tersedia untuk berbagi file SSD.

• Model penagihan bayar sesuai pemakaian: Dalam model bayar sesuai pemakaian, biaya berbagi file didasarkan pada seberapa banyak Anda menggunakan file tersebut, dalam bentuk biaya penyimpanan, transaksi, dan transfer data. Model bayar sesuai pemakaian hanya tersedia untuk berbagi file HDD. Sebaiknya gunakan model v2 yang disediakan untuk penyebaran berbagi file HDD baru.

Artikel ini menjelaskan cara kerja model penagihan untuk Azure Files, sehingga Anda dapat lebih memahami tagihan Azure Files bulanan Anda. Untuk informasi harga Azure Files, lihat laman harga Azure Files.

Video ini memberikan ikhtisar menyeluruh tentang perbedaan antara berbagai model penagihan Azure Files, termasuk bayar sesuai penggunaan, v1 yang telah disediakan, dan v2 yang telah disediakan.

Video ini mendalami model penagihan v2 yang disediakan Azure Files, menawarkan instruksi penyiapan dan rekomendasi untuk mengurangi total biaya kepemilikan.

Berlaku untuk

Model manajemen	Model tagihan	Lapisan media	Redundansi	Bisnis Kecil dan Menengah (SMB)	Sistem Berkas Jaringan (NFS)
Microsoft.Storage	V2 yang telah disediakan	HDD (standar)	Lokal (LRS)
Microsoft.Storage	V2 yang telah disediakan	HDD (standar)	Zona (ZRS)
Microsoft.Storage	V2 yang telah disediakan	HDD (standar)	Geo (GRS)
Microsoft.Storage	V2 yang telah disediakan	HDD (standar)	GeoZone (GZRS)
Microsoft.Storage	V1 yang telah disiapkan	SSD (kelas atas)	Lokal (LRS)
Microsoft.Storage	V1 yang telah disiapkan	SSD (kelas atas)	Zona (ZRS)
Microsoft.Storage	Bayar sesuai penggunaan	HDD (standar)	Lokal (LRS)
Microsoft.Storage	Bayar sesuai penggunaan	HDD (standar)	Zona (ZRS)
Microsoft.Storage	Bayar sesuai penggunaan	HDD (standar)	Geo (GRS)
Microsoft.Storage	Bayar sesuai penggunaan	HDD (standar)	GeoZone (GZRS)

Unit penyimpanan

Azure Files menggunakan satuan pengukuran basis-2 untuk mewakili kapasitas penyimpanan: KiB, MiB, GiB, dan TiB.

Singkatan	Definisi	Satuan
KiB	1.024 byte	kibibyte
Mib	1.024 KiB (1.048.576 byte)	mebibyte
Gib	1.024 MiB (1.073.741.824 byte)	gibibyte
TiB	1.024 GiB (1.099.511.627.776 byte)	tebibyte

Satuan ukuran base-2 umumnya digunakan oleh sebagian besar sistem operasi dan alat untuk mengukur jumlah penyimpanan. Namun, unit tersebut sering dilabeli sebagai unit base-10, yang mungkin lebih Anda kenal: KB, MB, GB, dan TB. Alasan umum mengapa sistem operasi seperti Windows salah memberi label pada unit penyimpanan adalah karena banyak sistem operasi mulai menggunakan akronim ini sebelum distandarisasi oleh International Electrotechnical Commission (IEC), International Bureau of Weights and Measures (BIPM), dan US National Institute of Standards and Technology (NIST).

Tabel berikut ini memperlihatkan seberapa umum sistem operasi mengukur dan memberi label penyimpanan:

Sistem operasi	Sistem pengukuran	Pelabelan
Windows	Basis-2	Konsisten salah memberi label sebagai basis-10.
Distribusi Linux	Umumnya base-2, beberapa perangkat lunak menggunakan base-10	Pelabelan yang tidak konsisten, kesesuaian antara pengukuran dan pelabelan tergantung pada paket perangkat lunak.
macOS, iOS, dan iPad OS	Basis-10	Melabeli secara konsisten sebagai basis-10.

Tanyakan kepada vendor sistem operasi Anda apakah sistem operasi Anda tidak tercantum.

Daftar Periksa Biaya Kepemilikan Total untuk Berbagi Berkas

Jika Anda bermigrasi ke Azure Files dari lokal atau membandingkan Azure Files dengan solusi penyimpanan cloud lainnya, pertimbangkan faktor-faktor berikut untuk memastikan perbandingan apples-to-apples yang adil:

• Bagaimana Anda membayar penyimpanan, IOPS, dan lebar pita? Sebagian besar solusi cloud memiliki model yang selaras dengan prinsip penyimpanan yang disediakan, seperti determinisme harga dan kesederhanaan, atau penyimpanan bayar sesuai penggunaan, yang dapat mengoptimalkan biaya dengan hanya menagih Anda untuk apa yang sebenarnya Anda gunakan. Model penagihan yang disediakan dapat berbeda berdasarkan ukuran berbagi minimum yang disediakan, unit provisi, dan kemampuan untuk meningkatkan dan mengurangi provisi.

• Apakah ada metode untuk mengoptimalkan biaya penyimpanan? Anda dapat menggunakan Reservasi Azure Files untuk mencapai diskon hingga 36% pada penyimpanan. Solusi lain mungkin menggunakan strategi seperti deduplikasi atau kompresi untuk mengoptimalkan efisiensi penyimpanan secara opsional. Namun, strategi pengoptimalan penyimpanan ini sering memiliki biaya non-moneter, seperti mengurangi performa. Reservasi Azure Files tidak memiliki efek samping pada performa.

• Bagaimana Anda mencapai ketahanan penyimpanan dan redundansi? Dengan Azure Files, ketahanan penyimpanan dan redundansi disertakan dalam penawaran produk. Semua tingkatan dan tingkat redundansi memastikan bahwa data sangat tersedia dan setidaknya tiga salinan data Anda dapat diakses. Saat mempertimbangkan opsi penyimpanan file lainnya, pertimbangkan apakah ketahanan penyimpanan dan redundansi bawaan, atau sesuatu yang harus Anda kumpulkan sendiri.

• Apa yang perlu Anda lakukan untuk mengelola? Azure Files adalah solusi yang dikelola sepenuhnya. Solusi lain mungkin memerlukan pembaruan sistem operasi atau mengelola sumber daya virtual seperti VM, disk, dan alamat IP jaringan.

• Berapa biaya produk bernilai tambah? Azure Files mendukung integrasi dengan beberapa layanan bernilai tambah pihak pertama dan ketiga. Layanan bernilai tambah seperti Azure Backup, Azure File Sync, dan Microsoft Defender for Storage menyediakan pencadangan, replikasi, dan penembolokan, dan fungsionalitas keamanan untuk Azure Files. Solusi bernilai tambah, baik lokal atau di cloud, akan memiliki lisensi dan biaya produk mereka sendiri, dan sering dianggap sebagai bagian dari total biaya kepemilikan untuk penyimpanan file.

Model v2 yang disediakan

Model v2 yang disediakan untuk Azure Files memasangkan kepastian total biaya kepemilikan dengan fleksibilitas, memungkinkan Anda membuat berbagi berkas yang memenuhi persyaratan penyimpanan dan performa yang tepat. Saat Anda membuat pembagian file v2 baru yang sudah ditentukan, Anda menentukan berapa banyak penyimpanan, IOPS, dan throughput yang dibutuhkan pembagian file Anda. Jumlah setiap kuantitas yang Anda provisikan menentukan total tagihan Anda.

Jumlah penyimpanan, IOPS, dan throughput yang Anda provisikan adalah batas jaminan penggunaan berbagi file Anda. Misalnya, jika Anda menyediakan partisi 2 TiB dan mengunggah 2 TiB data ke partisi tersebut, partisi Anda akan penuh. Anda tidak akan dapat menambahkan lebih banyak data kecuali Anda meningkatkan ukuran berbagi atau menghapus beberapa data. Bursting IOPS berbasis kredit memberikan fleksibilitas tambahan seputar penggunaan, berdasarkan usaha terbaik, selama kredit tersedia.

Jumlah penyimpanan, IOPS, dan throughput yang Anda provisikan dapat ditingkatkan atau diturunkan secara dinamis saat kebutuhan Anda berubah. Namun, Anda hanya dapat mengurangi jumlah yang disediakan setelah 24 jam berlalu sejak peningkatan kuantitas terakhir Anda. Perubahan penyimpanan, IOPS, dan throughput akan berlaku dalam beberapa menit setelah perubahan provisioning.

Secara default, saat Anda membuat berbagi file baru menggunakan model v2 yang disediakan, kami memberikan rekomendasi tentang berapa banyak IOPS dan berapa banyak throughput yang Anda butuhkan. Ini dihitung berdasarkan jumlah penyimpanan yang disediakan yang Anda tentukan. Rekomendasi ini didasarkan pada penggunaan pelanggan umum untuk jumlah penyimpanan yang disediakan untuk tingkat media yang Anda pilih. Namun, Anda mungkin menemukan bahwa beban kerja Anda memerlukan lebih banyak atau kurang IOPS dan throughput daripada "berbagi file biasa." Dalam hal ini, Anda dapat secara opsional menyediakan lebih atau kurang IOPS dan throughput, tergantung pada persyaratan berbagi file individual Anda.

Ketersediaan v2 yang disediakan

Model v2 yang disediakan disediakan untuk berbagi file di akun penyimpanan dengan jenis akun penyimpanan FileStorage . Saat ini, SKU akun penyimpanan berikut tersedia:

Jenis akun penyimpanan	SKU akun penyimpanan	Jenis berbagi file yang tersedia
FileStorage	Standardv2_LRS	File share v2 yang dipersiapkan oleh HDD dengan redundansi Lokal (LRS) yang ditentukan.
FileStorage	StandardV2_ZRS	Bagikan file v2 yang penyediaannya menggunakan HDD dengan redundansi Zona (ZRS) seperti yang ditentukan.
FileStorage	StandardV2_GRS	Berkas berbagi v2 yang disediakan oleh HDD dengan redundansi Geo (GRS) yang ditentukan.
FileStorage	StandardV2_GZRS	Berbagi file v2 dengan redundansi GeoZone (GZRS) yang sudah ditentukan, disediakan oleh HDD.

Saat ini, SKU ini umumnya tersedia di subset wilayah terbatas:

• Semua wilayah cloud publik Azure.
• Semua wilayah cloud Azure US Government.

Detail penyediaan v2 yang disediakan

Saat Anda membuat berbagi file v2 yang disediakan, Anda menentukan kapasitas yang disediakan untuk berbagi file dalam hal penyimpanan, IOPS, dan throughput. Berbagi file dibatasi berdasarkan atribut berikut:

Benda	Nilai HDD
Unit penyediaan penyimpanan	1 GiB
Unit penyiapan IOPS	1 IO per detik
Unit penyedia throughput	1 MiB / detik
Penyimpanan minimum yang disediakan per berkas bersama	32 GiB
IOPS minimum yang disediakan per berbagi berkas	500 IOPS
Laju aliran minimum yang dialokasikan per berkas	60 MiB / detik
Penyimpanan maksimum yang disediakan per setiap pembagian file	256 TiB (262.144 GiB)
IOPS maksimum yang disediakan per setiap berbagi file	50.000 IOPS
Throughput maksimum yang disediakan untuk setiap berbagi file	5.120 MiB/dtk
Penyimpanan maksimum yang disediakan per akun penyimpanan	4 PiB (4.194.304 GiB)
IOPS maksimum yang disediakan per akun penyimpanan	50.000 IOPS
Lalu lintas data maksimum yang disediakan per akun penyimpanan	5.120 MiB/dtk
Jumlah maksimum berbagi file per akun penyimpanan	50 pembagian file

Secara default, kami merekomendasikan penyediaan IOPS dan throughput berdasarkan penyimpanan yang Anda tentukan. Rumus rekomendasi ini didasarkan pada penggunaan pelanggan umum untuk jumlah penyimpanan yang disediakan untuk tingkat media tersebut di Azure Files:

Nama rumus	Rumus HDD
Rekomendasi IOPS	MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
Rekomendasi untuk Throughput	MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

Bergantung pada persyaratan berbagi file individual, Anda mungkin menemukan bahwa Anda memerlukan lebih atau kurang IOPS atau throughput daripada rekomendasi kami. Anda dapat secara opsional mengambil alih rekomendasi ini dengan nilai Anda sendiri sesuai keinginan.

Bursting versi 2 yang disediakan

Fitur bursting IOPS berbasis kredit memberikan fleksibilitas ekstra dalam penggunaan IOPS. Fleksibilitas ini paling baik digunakan sebagai buffer terhadap lonjakan IO yang tidak terduga. Untuk pola IO yang ditetapkan, sebaiknya melakukan persiapan untuk puncak IO.

Kredit IOPS burst terakumulasi setiap kali lalu lintas untuk file share Anda kurang dari IOPS yang disediakan (standar minimum). Setiap kali penggunaan IOPS pada penyimpanan berbagi file melebihi IOPS yang telah ditetapkan dan terdapat kredit burst IOPS yang tersedia, penyimpanan berbagi file dapat melakukan burst hingga batas IOPS burst maksimum yang diizinkan. File share dapat terus mengalami peningkatan selama ada kredit yang tersisa, berdasarkan jumlah kredit burst yang terakumulasi. Setiap IO di luar IOPS yang disediakan menggunakan satu kredit. Setelah semua kredit digunakan, kembali ke IOPS yang disediakan. IOPS terhadap layanan berbagi file tidak memerlukan tindakan khusus untuk menggunakan bursting. Bursting beroperasi berdasarkan upaya sebaik mungkin.

Kredit pembagian memiliki tiga status:

• Mengakumulasi, ketika berbagi file menggunakan IOPS lebih sedikit daripada yang disediakan.
• Penurunan terjadi ketika penggunaan berbagi file melebihi IOPS yang disediakan dan berada dalam mode bursting.
• Konstanta, ketika berbagi file menggunakan persis IOPS yang disediakan dan tidak ada kredit yang dikumpulkan atau digunakan.

Berbagi file baru dimulai dengan jumlah kredit penuh dalam wadah cadangannya. Kredit burst tidak terkumpul jika IOPS berbagi berada di bawah batas yang disediakan akibat pembatasan server. Rumus berikut digunakan untuk menentukan batas IOPS burst dan jumlah kredit yang mungkin untuk berbagi file:

Benda	Rumus HDD
Batas sewaktu untuk IOPS	MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
Kredit burst IOPS	(BurstLimit - ProvisionedIOPS) * 3600

Tabel berikut mengilustrasikan beberapa contoh rumus ini untuk berbagai jumlah IOPS yang disediakan:

IOPS yang disediakan	Batas IOPS ledakan HDD	Kredit lonjakan HDD
500	Hingga 5.000	16,200,000
1,000	Hingga 5.000	14.400.000
3.000	Hingga 9.000	21,600,000
5.000	Hingga 15.000	36.000.000
10.000	Hingga 30.000	72,000,000
25.000	Hingga 50.000	90.000.000
50.000	Hingga 50.000	0

Cuplikan v2 yang disediakan

Azure Files mendukung snapshot, yang mirip dengan salinan bayangan volume (VSS) di Windows File Server. Untuk informasi selengkapnya tentang berbagi snapshot, baca Garis besar snapshot untuk Azure Files.

Cuplikan selalu berbeda dari bagikan langsung dan satu sama lain. Dalam model penagihan v2 yang disediakan, jika ukuran diferensial total dari semua snapshot sesuai dengan ruang penyimpanan berlebih yang disediakan untuk file share, tidak ada biaya tambahan untuk penyimpanan snapshot. Jika ukuran data berbagi langsung ditambah data snapshot diferensial lebih besar dari penyimpanan berbagi yang telah disediakan, kelebihan kapasitas yang digunakan dari snapshot ditagih terhadap meter Penggunaan Rekam Jepret Luapan. Rumus untuk menentukan jumlah luapan adalah: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Beberapa layanan bernilai tambah untuk Azure Files menggunakan rekam jepret sebagai bagian dari proposisi nilainya. Untuk informasi selengkapnya, lihat layanan bernilai tambah untuk Azure Files.

Penghapusan lunak v2 yang disediakan

Berbagi berkas yang dihapus di akun penyimpanan dengan penghapusan lembut diaktifkan ditagih sesuai kapasitas penyimpanan yang digunakan dari berkas yang dihapus untuk periode retensi yang ditentukan. Untuk memastikan bahwa berbagi file yang dihapus dapat selalu dipulihkan, penyimpanan yang disediakan, IOPS, dan throughput dari jumlah berbagi akan diperhitungkan dalam batas akun penyimpanan hingga berbagi file tersebut benar-benar dihapus. Namun, mereka tidak ditagih. Untuk informasi selengkapnya tentang penghapusan sementara, lihatlah Cara mengaktifkan penghapusan sementara pada file berbagi Azure.

Meter penagihan v2 yang disediakan

Berbagi file yang menggunakan model penagihan v2 ditagih berdasarkan meteran penagihan berikut:

• Penyimpanan yang Disediakan: Jumlah penyimpanan yang disediakan di GiB.
• IOPS yang disediakan: Jumlah IOPS (IO/dtk) yang disediakan.
• Throughput yang Disediakan dalam MiBPS: Jumlah throughput yang diatur dalam MiB/dtk.
• Penggunaan Rekam Jepret Luapan: Jumlah penggunaan rekam jepret diferensial apa pun di GiB yang tidak sesuai dengan kapasitas penyimpanan yang disediakan. Untuk informasi selengkapnya, lihat rekam jepret v2 yang disediakan.
• Penggunaan yang Dihapus Lunak: Kapasitas penyimpanan yang digunakan di GiB untuk berbagi file yang dihapus lunak. Untuk informasi selengkapnya, lihat penghapusan lunak v2 yang telah disediakan.

Unit konsumsi pada pengukur penagihan v2 yang disediakan dikeluarkan setiap jam. Misalnya, untuk berbagi dengan 1.024 GiB yang disediakan, Anda akan melihat:

• 1.024 unit terhadap meteran Penyimpanan yang disediakan selama satu jam.
• 24.576 unit terhadap Pengukur Penyimpanan yang Disediakan jika dikumpulkan selama satu hari.
• Jumlah variabel unit jika diagregasi selama sebulan tergantung pada jumlah hari dalam bulan:
  • Bulan 28 hari (Februari normal): 688.128 unit terhadap meter Penyimpanan yang Dialokasikan.
  • Bulan 29 hari (Februari di tahun kabisat): 712.704 unit terhadap meter Penyimpanan yang disediakan.
  • Bulan 30 hari: 737.280 unit terhadap meter Penyimpanan yang Ditetapkan.
  • Bulan 31 hari: 761.856 unit terhadap meter Penyimpanan yang Dialokasikan.

Migrasi v2 yang disediakan

Proses untuk memigrasikan berbagi file Azure SMB Anda dari model bayar sesuai pemakaian ke model penagihan v2 yang disediakan berbeda tergantung pada apakah Anda menggunakan Azure File Sync.

• Jika Anda menggunakan Azure Files tanpa Azure File Sync, lihat Memigrasikan file dari satu berbagi file Azure SMB ke file lainnya.
• Jika Anda menggunakan Azure File Sync, lihat Memigrasikan file dari satu berbagi file Azure ke berbagi file Azure lainnya saat menggunakan Azure File Sync.

Model v1 yang disediakan

Metode v1 yang sudah tersedia menawarkan penyimpanan, IOPS, dan throughput dalam rasio tetap satu sama lain, serupa dengan cara pembelian penyimpanan dalam solusi penyimpanan di lokasi sendiri. Saat Anda membuat layanan berbagi file v1 baru yang disediakan, Anda menentukan berapa banyak penyimpanan yang diperlukan, dan nilai IOPS serta throughput dihitung. Model v1 yang disediakan untuk Azure Files hanya tersedia untuk berbagi file SSD.

Jumlah penyimpanan yang Anda provisikan menentukan batas penyimpanan, IOPS, dan throughput yang dijamin dari penggunaan berbagi file Anda. Misalnya, jika Anda menyediakan partisi 2 TiB dan mengunggah 2 TiB data ke partisi tersebut, partisi Anda akan penuh. Anda tidak akan dapat menambahkan lebih banyak data kecuali Anda meningkatkan ukuran berbagi Anda, atau menghapus beberapa data. Bursting IOPS berbasis kredit memberikan fleksibilitas tambahan seputar penggunaan, berdasarkan usaha terbaik, selama kredit tersedia.

Tidak seperti membeli penyimpanan lokal, berbagi file v1 yang disediakan dapat ditingkatkan atau diturunkan skalanya secara dinamis saat kebutuhan Anda berubah. Namun, Anda hanya dapat mengurangi penyimpanan yang disediakan setelah 24 jam berlalu sejak peningkatan penyimpanan terakhir Anda. Perubahan penyimpanan, IOPS, dan throughput akan berlaku dalam beberapa menit setelah perubahan provisioning.

Dimungkinkan untuk mengurangi ukuran bagian yang telah Anda alokasikan ke bawah ukuran GiB yang telah terpakai. Jika Anda melakukannya, Anda tidak akan kehilangan data, tetapi Anda tetap akan ditagih berdasarkan ukuran yang digunakan. Anda akan menerima kinerja dari share yang telah dialokasikan, bukan kapasitas yang digunakan.

Ketersediaan v1 yang disediakan

Model v1 yang disediakan disediakan untuk berbagi file SSD di akun penyimpanan dengan jenis akun penyimpanan FileStorage :

Jenis akun penyimpanan	SKU akun penyimpanan	Jenis berbagi file yang tersedia
FileStorage	Premium_LRS	File share v1 yang dialokasikan pada SSD dengan redundansi Lokal (LRS) yang ditentukan.
FileStorage	Premium_ZRS	Berbagi file v1 yang disediakan oleh SSD dengan redundansi Zona (ZRS) yang telah ditentukan.

Berbagi file SSD menggunakan model v1 yang disediakan umumnya tersedia di sebagian besar wilayah Azure. Untuk informasi selengkapnya, lihat Produk Azure berdasarkan wilayah.

Detail provisi v1 yang disediakan

Saat Anda membuat share file v1 yang telah disediakan, Anda menentukan berapa banyak penyimpanan yang dibutuhkan untuk share tersebut. Setiap GiB yang Anda provisikan memberi Anda lebih banyak IOPS dan throughput dalam rasio tetap. Berbagi file dibatasi berdasarkan atribut berikut:

Benda	Nilai
Unit penyediaan penyimpanan	1 GiB
Penyimpanan minimum yang disediakan per berkas bersama	100 GiB
Penyimpanan maksimum yang disediakan per setiap pembagian file	100 TiB (102.400 GiB)
Penyimpanan maksimum yang disediakan per akun penyimpanan	100 TiB (102.400 GiB)

Formula di bawah ini menentukan jumlah IOPS dan throughput yang disediakan pada share:

Benda	Rumus
IOPS yang dihitung dan disediakan (tingkat dasar)	MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
Throughput yang dihitung dan dialokasikan (MiB/dtk)	100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

Bergantung pada persyaratan berbagi file individual, Anda mungkin menemukan bahwa Anda memerlukan lebih banyak IOPS atau throughput daripada yang disediakan rumus provisi kami. Dalam hal ini, Anda perlu menyediakan lebih banyak penyimpanan untuk mendapatkan IOPS atau throughput yang diperlukan.

Pemanfaatan kapasitas v1 yang disediakan

Model v1 yang disediakan mendukung dua jenis bursting: bursting berbasis kredit, yang disertakan secara gratis sebagai bagian dari provisi, dan bursting berbayar, yang merupakan fitur lanjutan yang dapat Anda aktifkan secara opsional untuk mendukung penagihan berbasis penggunaan setiap kali IOPS dan throughput melampaui jumlah yang disediakan.

Bursting berbasis kredit v1 yang telah disediakan

Fitur bursting IOPS berbasis kredit memberikan fleksibilitas ekstra dalam penggunaan IOPS. Fleksibilitas ini paling baik digunakan sebagai buffer terhadap lonjakan IO yang tidak terduga. Untuk pola IO yang ditetapkan, sebaiknya melakukan persiapan untuk puncak IO.

Kredit IOPS burst terakumulasi setiap kali lalu lintas untuk file share Anda kurang dari IOPS yang disediakan (standar minimum). Setiap kali penggunaan IOPS pada penyimpanan berbagi file melebihi IOPS yang telah ditetapkan dan terdapat kredit burst IOPS yang tersedia, penyimpanan berbagi file dapat melakukan burst hingga batas IOPS burst maksimum yang diizinkan. File share dapat terus mengalami peningkatan selama ada kredit yang tersisa, berdasarkan jumlah kredit burst yang terakumulasi. Setiap IO di luar IOPS yang disediakan menggunakan satu kredit. Setelah semua kredit digunakan, kembali ke IOPS yang disediakan. IOPS terhadap layanan berbagi file tidak memerlukan tindakan khusus untuk menggunakan bursting. Bursting beroperasi berdasarkan upaya sebaik mungkin.

Kredit pembagian memiliki tiga status:

• Mengakumulasi, ketika berbagi file menggunakan IOPS lebih sedikit daripada yang disediakan.
• Penurunan terjadi ketika penggunaan berbagi file melebihi IOPS yang disediakan dan berada dalam mode bursting.
• Konstanta, ketika berbagi file menggunakan persis IOPS yang disediakan dan tidak ada kredit yang dikumpulkan atau digunakan.

Berbagi file baru dimulai dengan jumlah kredit penuh dalam wadah cadangannya. Kredit burst tidak terkumpul jika IOPS berbagi berada di bawah batas yang disediakan akibat pembatasan server. Rumus berikut digunakan untuk menentukan batas IOPS burst dan jumlah kredit yang mungkin untuk berbagi file:

Benda	Rumus
Batas ledakan	MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Kredit tambahan sementara	(BurstLimit - BaselineIOPS) * 3600

Tabel berikut ini menunjukkan beberapa contoh rumus dari ukuran berbagi yang telah ditentukan.

Kapasitas (GiB)	IOPS Garis Besar	Ledakan IOPS	Kredit burst	Throughput (ingress + egress) (MiB/detik)
100	3.100	Hingga 10.000	24.840.000	110
500	3.500	Hingga 10.000	23.400.000	150
1,024	4.024	Hingga 10.000	21.513.600	203
5,120	8.120	Hingga 15.360	26.064.000	613
10,240	13.240	Hingga 30.720	62.928.000	1.125
33.792	36.792	Hingga 102.400	227.548.800	3.480
51.200	54.200	Hingga 102.400	164.880.000	5.220
102,400	102,400	Hingga 102.400	0	10.340

Bursting berbayar versi 1 yang dipersiapkan

Fitur bursting berbayar adalah fitur lanjutan dari model v1 yang disiapkan yang dirancang untuk mendukung pelanggan yang tidak ingin mengalami pembatasan. Bursting berbayar menambahkan penagihan tambahan berdasarkan penggunaan untuk jumlah IOPS atau throughput berapa pun yang melebihi penyimpanan yang disediakan. Ini berbeda dari peningkatan kapasitas berbasis kredit, yang sudah termasuk tanpa biaya sebagai bagian dari penyimpanan yang telah dialokasikan. Meskipun bursting berbayar dapat memberikan fleksibilitas besar dalam cara Anda mengelola penyediaan file share, ini juga dapat menyebabkan penagihan yang tidak terduga jika digunakan dengan tidak benar.

Seperti bursting berbasis kredit, bursting berbayar bukanlah pengganti untuk menyediakan jumlah IOPS dan throughput yang sesuai. Sebaliknya, ini memberikan perlindungan lebih terhadap pembatasan pengaturan jika Anda menghadapi lonjakan permintaan yang tak terduga. Jika Anda memiliki tingkat penggunaan IOPS atau throughput yang konsisten, lebih murah untuk menyediakan IOPS dan throughput yang cukup (melalui penyediaan penyimpanan) untuk mencakup permintaan alih-alih mengandalkan bursting berbayar.

Bursting berbayar dinonaktifkan secara default, tetapi Anda dapat mengaktifkannya dengan mengikuti instruksi untuk mengubah karakteristik biaya dan kinerja dari v1 file share yang sudah disediakan (hanya untuk PowerShell dan CLI). Jika bursting berbayar diaktifkan, sebaiknya pantau penggunaan IOPS dan throughput dengan cermat menggunakan metrik berikut yang tersedia melalui Azure monitor:

• IOPS yang Dikonfigurasikan untuk Berbagi File
• Bandwidth Disediakan Berbagi Berkas MiB/s (performa)
• Transaksi oleh Max IOPS
• Bandwidth menurut Maksimum MiB/detik (throughput)
• Kredit Ledakan untuk IOPS (penggunaan kredit berbasis ledakan)
• IOS Bursting Berbayar (IO)
• Pembayaran Bandwidth Membludak

Snapshot v1 yang telah disediakan

Azure Files mendukung snapshot, yang mirip dengan salinan bayangan volume (VSS) di Windows File Server. Untuk informasi selengkapnya tentang berbagi snapshot, baca Garis besar snapshot untuk Azure Files.

Cuplikan selalu berbeda dari bagikan langsung dan satu sama lain. Dalam model penagihan v1 yang telah dialokasikan, ukuran diferensial total dibebankan pada meteran penggunaan, tanpa memperhatikan sisa penyimpanan yang tidak terpakai. Meter penyimpanan snapshot yang digunakan memiliki harga lebih rendah dibandingkan dengan harga penyimpanan yang disediakan.

Penghapusan sementara v1 yang disediakan

Berbagi berkas yang dihapus di akun penyimpanan dengan penghapusan lembut diaktifkan ditagih sesuai kapasitas penyimpanan yang digunakan dari berkas yang dihapus untuk periode retensi yang ditentukan. Kapasitas penyimpanan yang dihapus secara lunak dialokasikan terhadap meteran penyimpanan snapshot yang digunakan. Untuk informasi selengkapnya tentang penghapusan sementara, lihatlah Cara mengaktifkan penghapusan sementara pada file berbagi Azure.

Meter penagihan v1 yang disediakan

Berbagi file yang disediakan menggunakan model penagihan v1 yang disediakan ditagih berdasarkan meter berikut:

• Premium Disediakan: Jumlah penyimpanan yang dialokasikan dalam GiB.
• Snapshot Premium: Jumlah snapshots yang digunakan dan kapasitas yang dihapus secara sementara.

Konsumsi terhadap pengukur penagihan v1 yang disediakan diukur setiap jam dalam satuan bulanan. Misalnya, untuk berbagi dengan 1.024 GiB yang disediakan, Anda akan melihat:

• Jumlah variabel unit untuk satu jam individu tergantung pada jumlah hari dalam bulan:
  • Bulan 28 hari (Februari normal): 1,5238 unit terhadap meteran Premium yang Disediakan.
  • Bulan 29 hari (Februari tahun kabisat): 1,4713 unit terhadap Premium Provisioned meter.
  • Bulan 30 hari: 1.4222 unit terhadap Pengukur Premium Tersedia.
  • Bulan 31 hari: 1,3763 unit pada meter Premium Provisioned.
• Jumlah unit yang bervariasi jika diakumulasikan selama sehari tergantung pada jumlah hari dalam bulan.
  • Bulan 28 hari (Februari normal): 36,5714 unit terhadap pengukur Tersedia Premium.
  • Bulan 29 hari (tahun kabisat Februari): 35.3103 unit terhadap meter Premium Provisioned.
  • Bulan 30 hari: sebanyak 34.1333 unit pada meteran Premium yang Disediakan.
  • Bulan 31 hari: 33,0323 unit terhadap meteran Premium yang Dialokasikan.
• 1,024 unit pada meter Premium Provisioned jika dikumpulkan selama sebulan.

Model bayar sesuai penggunaan

Dalam model bayar sesuai pemakaian, Anda ditagih tentang berapa banyak penyimpanan yang Anda gunakan, bukan berapa banyak yang Anda provisikan. Pada tingkat tinggi, Anda membayar biaya untuk jumlah data logis yang disimpan, dan Anda juga dikenakan biaya untuk transaksi berdasarkan penggunaan data tersebut. Penagihan sesuai pemakaian mungkin sulit direncanakan sebagai bagian dari proses penganggaran, karena Anda membayar berdasarkan konsumsi pengguna akhir. Oleh karena itu, sebaiknya gunakan model v2 yang disediakan untuk penyebaran berbagi file baru. Model bayar sesuai pemakaian hanya tersedia untuk berbagi file HDD.

Ketersediaan bayar per penggunaan

Model bayar sesuai pemakaian disediakan untuk berbagi file HDD di akun penyimpanan dengan jenis akun penyimpanan StorageV2 atau Storage

Jenis akun penyimpanan	SKU akun penyimpanan	Jenis berbagi file yang tersedia
StorageV2 atau Storage	Standard_LRS	Berbagi file HDD dengan pembayaran sesuai penggunaan dan redundansi Lokal (LRS) yang ditentukan.
StorageV2 atau Storage	Standard_ZRS	Berbagi file berbasis HDD dengan sistem bayar sesuai pemakaian dan redundansi Zona (ZRS) yang ditentukan.
StorageV2 atau Storage	Standar_GRS	Berbagi file HDD dengan pembayaran sesuai pemakaian dan redundansi Geo (GRS) yang ditentukan.
StorageV2 atau Storage	Standar_GZRS	Berbagi file prabayar HDD dengan redundansi GeoZone (GZRS) yang ditentukan.

Berbagi file HDD menggunakan model bayar sesuai pemakaian umumnya tersedia di semua wilayah Azure.

Perbedaan tingkat akses

Saat membuat pembagian file HDD, Anda memilih antara tingkat akses berikut: dioptimalkan untuk transaksi, hot, dan cool. Ketiga tingkat akses disimpan pada perangkat keras penyimpanan yang sama persis. Perbedaan utama antara ketiga tingkat akses ini adalah harga penyimpanan data dalam keadaan diam, yang lebih rendah pada lapisan yang lebih dingin, dan harga transaksi, yang lebih tinggi pada lapisan yang lebih dingin. Ini berarti:

• Transaksi yang dioptimalkan, seperti namanya, mengoptimalkan harga untuk beban kerja IOPS (transaksi) tinggi. Transaksi yang dioptimalkan memiliki harga penyimpanan data saat tidak aktif tertinggi, tetapi harga transaksi terendah.
• Hot adalah untuk beban kerja aktif yang tidak melibatkan sejumlah besar transaksi. Ini memiliki harga penyimpanan data tidak aktif yang sedikit lebih rendah, tetapi harga transaksi yang sedikit lebih tinggi dibandingkan dengan transaksi yang dioptimalkan. Pikirkan sebagai jalan tengah antara tingkatan transaksi yang dioptimalkan dan tingkatan yang menarik.
• Cool mengoptimalkan harga untuk beban kerja yang tidak memiliki aktivitas tinggi, menawarkan harga penyimpanan data saat istirahat terendah, tetapi harga transaksi tertinggi.

Memilih tingkat akses yang sesuai untuk kasus penggunaan Anda memungkinkan Anda mengurangi biaya Anda secara besar-besaran. Jika Anda menempatkan beban kerja yang jarang digunakan di tingkat akses yang dioptimalkan untuk transaksi, Anda membayar hampir tidak ada untuk beberapa kali dalam sebulan ketika Anda melakukan transaksi pada bagian Anda. Namun, Anda membayar jumlah tinggi untuk biaya penyimpanan data. Jika Anda memindahkan saham yang sama ini ke tingkat akses yang lebih dingin, biaya transaksi Anda akan tetap hampir tidak ada, hanya karena Anda jarang melakukan transaksi untuk beban kerja ini. Namun, tingkat akses dingin memiliki harga penyimpanan data yang lebih murah.

Demikian pula, jika Anda menempatkan beban kerja yang sangat diakses di tingkat akses dingin, Anda membayar lebih banyak dalam biaya transaksi, tetapi lebih sedikit untuk biaya penyimpanan data. Ini dapat menyebabkan situasi di mana peningkatan biaya dari harga transaksi yang meningkat melebihi penghematan dari penurunan harga penyimpanan data, dan Anda mungkin membayar lebih untuk penyimpanan dingin daripada yang akan Anda bayarkan untuk penyimpanan yang dioptimalkan untuk transaksi. Untuk beberapa tingkat penggunaan, ada kemungkinan bahwa tingkat akses panas akan menjadi yang paling hemat biaya, dan tingkat akses dingin akan lebih mahal daripada transaksi yang dioptimalkan.

Beban kerja dan tingkat aktivitas Anda menentukan tingkat akses paling hemat biaya untuk berbagi file prabayar Anda. Dalam praktiknya, cara terbaik untuk memilih tingkat akses yang paling hemat biaya adalah dengan mempertimbangkan konsumsi sumber daya aktual dari bagian yang dibagikan (data yang disimpan, transaksi penulisan, dll.). Untuk berbagi file prabayar, sebaiknya mulai dari tingkat transaksi yang dioptimalkan selama migrasi awal ke Azure Files, lalu pilih tingkat akses yang benar berdasarkan penggunaan setelah migrasi selesai. Penggunaan transaksi selama migrasi biasanya tidak menunjukkan penggunaan transaksi normal.

Apa itu transaksi?

Saat Anda memasang berbagi file Azure di komputer menggunakan SMB, berbagi file Azure diekspos di komputer Anda seolah-olah itu adalah penyimpanan lokal. Ini berarti bahwa aplikasi, skrip, dan program lain di komputer Anda dapat mengakses file dan folder di berbagi file Azure tanpa perlu mengetahui bahwa mereka disimpan di Azure.

Saat Anda membaca atau menulis ke file, aplikasi yang Anda gunakan melakukan serangkaian panggilan API ke API sistem file yang disediakan oleh sistem operasi Anda. Sistem operasi Anda kemudian menginterpretasikan panggilan ini ke dalam transaksi protokol SMB, yang dikirim melalui kawat ke Azure Files untuk dipenuhi. Tugas sederhana yang dianggap pengguna akhir sebagai operasi tunggal, seperti membaca file dari awal hingga akhir, mungkin diterjemahkan ke dalam beberapa transaksi SMB yang dilayani oleh Azure Files.

Pada dasarnya, model penagihan pay-as-you-go yang digunakan dalam file share standar menagih berdasarkan pemakaian. Transaksi SMB dan FileREST yang dibuat oleh aplikasi dan skrip mewakili penggunaan berbagi file Anda, dan muncul sebagai bagian dari tagihan Anda. Konsep yang sama berlaku untuk layanan cloud bernilai tambah yang mungkin Anda tambahkan ke penyimpanan berbagi Anda, seperti Azure File Sync atau Azure Backup.

Transaksi dikelompokkan ke dalam lima kategori transaksi berbeda yang memiliki harga yang berbeda berdasarkan dampaknya pada berbagi file Azure. Kategori ini adalah: menulis, mencantumkan, membaca, lainnya, dan menghapus.

Tabel berikut menunjukkan kategorisasi setiap transaksi:

Keranjang transaksi	Operasi manajemen	Operasi Data
Melakukan transaksi	CreateShare SetFileServiceProperties SetShareMetadata SetShareProperties SetShareAcl SnapshotShare RestoreShare	CopyFile Create CreateDirectory CreateFile PutRange PutRangeFromURL SetDirectoryMetadata SetFileMetadata SetFileProperties SetInfo Write PutFilePermission Flush SetDirectoryProperties
Daftar transaksi	ListShares	ListFileRanges ListFiles ListHandles
Baca transaksi	GetFileServiceProperties GetShareAcl GetShareMetadata GetShareProperties GetShareStats	FilePreflightRequest GetDirectoryMetadata GetDirectoryProperties GetFile GetFileCopyInformation GetFileMetadata GetFileProperties QueryDirectory QueryInfo Read GetFilePermission
Transaksi lainnya/protokol	AcquireShareLease BreakShareLease ReleaseShareLease RenewShareLease ChangeShareLease	AbortCopyFile Cancel ChangeNotify Close Echo Ioctl Lock Logoff Negotiate OplockBreak SessionSetup TreeConnect TreeDisconnect CloseHandles AcquireFileLease BreakFileLease ChangeFileLease ReleaseFileLease
Hapus transaksi	DeleteShare	ClearRange DeleteDirectory DeleteFile

Catatan

NFSv4.1 hanya tersedia untuk berbagi file SSD, yang menggunakan model penagihan yang disediakan. Wadah transaksi tidak memengaruhi penagihan untuk berbagi file yang disediakan.

Beralih antar tingkat akses

Meskipun Anda dapat mengubah berbagi file prabayar antara tiga tingkat akses, praktik terbaik untuk mengoptimalkan biaya setelah migrasi awal adalah memilih tingkat akses optimal paling hemat biaya untuk masuk, dan tetap berada di sana kecuali pola akses Anda berubah. Ini karena mengubah tingkat akses berbagi file standar menghasilkan biaya tambahan sebagai berikut:

• Transaksi: Saat Anda memindahkan saham dari tingkat akses yang lebih panas ke tingkat akses yang lebih dingin, Anda dikenakan biaya transaksi tulis tingkat akses yang lebih dingin untuk setiap file dalam saham. Memindahkan berbagi berkas dari tingkat akses dingin ke tingkat akses panas akan menimbulkan biaya transaksi di tingkat akses baca dingin untuk setiap berkas dalam berbagi tersebut.

• Pengambilan data: Jika Anda berpindah dari tingkat akses dingin ke panas atau transaksi yang dioptimalkan, Anda dikenakan biaya pengambilan data berdasarkan ukuran data yang dipindahkan. Hanya lapis akses dingin yang memiliki biaya pengambilan data.

Tabel berikut mengilustrasikan perincian biaya pemindahan tingkat akses:

tingkat akses	Transaksi dioptimalkan (tujuan)	Populer (tujuan)	Dingin (tujuan)
Transaksi dioptimalkan (sumber)	--	Satu transaksi penulisan langsung per berkas.	Satu transaksi tulis khusus per file.
Panas (sumber)	Satu transaksi baca yang sering diakses per file.	--	Satu transaksi tulis khusus per file.
Dingin (sumber)	Satu transaksi baca yang efisien per file. Pengambilan data berdasarkan total GiB yang digunakan.	Satu transaksi baca yang efisien per file. Pengambilan data berdasarkan total GiB yang digunakan.	--

Anda dapat mengubah tingkat akses berbagi file hingga lima kali dalam jangka waktu 30 hari. Hari pertama jendela 30 hari dimulai ketika perubahan tingkat pertama terjadi. Perubahan antara tingkat akses terjadi secara instan, namun, setelah Anda mengubah tingkat akses berbagi, Anda tidak dapat mengubahnya lagi dalam waktu 24 jam, bahkan jika Anda telah mengubah properti tingkat akses kurang dari lima kali dalam 30 hari terakhir.

Memilih tingkat akses

Terlepas dari cara Anda memigrasikan data yang ada ke Azure Files, sebaiknya membuat berbagi berkas di tingkat akses yang dioptimalkan untuk transaksi. Hal ini disebabkan oleh banyaknya transaksi yang terjadi selama migrasi. Setelah migrasi selesai dan Anda beroperasi selama beberapa hari atau minggu dengan penggunaan reguler, Anda dapat menyambungkan jumlah transaksi Anda ke dalam kalkulator harga untuk menentukan tingkat akses mana yang paling cocok untuk beban kerja Anda.

Karena berbagi file prabayar hanya menampilkan informasi transaksi di tingkat akun penyimpanan, menggunakan metrik penyimpanan untuk memperkirakan tingkat akses mana yang lebih murah di tingkat berbagi file adalah ilmu yang tidak sempurna. Jika memungkinkan, sebaiknya sebarkan hanya satu berbagi file di setiap akun penyimpanan untuk memastikan visibilitas penuh ke dalam penagihan.

Untuk melihat transaksi sebelumnya:

1. Navigasikan ke akun penyimpanan Anda di portal Microsoft Azure.
2. Di menu layanan, di bawah Pemantauan, pilih Metrik.
3. Pilih Cakupan sebagai nama akun penyimpanan Anda, Metric Namespace sebagai "File", Metric sebagai "Transaksi", dan Agregasi sebagai "Jumlah ".
4. Pilih Terapkan Pemisahan.
5. Pilih Nilai sebagai "Nama API". Pilih Batas dan Urutkan yang Anda inginkan.
6. Pilih jangka waktu yang Anda inginkan.

Catatan

Pastikan Anda melihat transaksi dalam jangka waktu yang cukup lama untuk mendapatkan gagasan realistis tentang jumlah rata-rata transaksi. Pastikan bahwa periode waktu yang dipilih tidak tumpang tindih dengan provisi awal. Kalikan jumlah rata-rata transaksi selama periode waktu ini untuk mendapatkan perkiraan transaksi selama sebulan penuh.

Rekam jepret bayar sesuai pemakaian

Azure Files mendukung snapshot, yang mirip dengan salinan bayangan volume (VSS) di Windows File Server. Untuk informasi selengkapnya tentang berbagi snapshot, baca Garis besar snapshot untuk Azure Files.

Cuplikan selalu berbeda dari bagikan langsung dan satu sama lain. Dalam model penagihan bayar sesuai pemakaian, total ukuran perbedaan ditagihkan terhadap meteran penyimpanan normal yang digunakan. Ini berarti Anda tidak akan melihat item baris terpisah pada tagihan yang mewakili cuplikan untuk akun penyimpanan bayar-per-pemakaian Anda. Ini juga berarti bahwa penggunaan snapshot diferensial dihitung terhadap reservasi yang dibeli untuk berbagi file prabayar.

Penghapusan lunak bayar sesuai penggunaan

Berbagi file yang dihapus di akun penyimpanan dengan penghapusan sementara diaktifkan ditagih berdasarkan kapasitas penyimpanan yang digunakan dari berbagi file yang dihapus untuk periode retensi yang ditentukan. Kapasitas penyimpanan yang digunakan yang dihapus secara sementara dilaporkan dibandingkan dengan pengukur penyimpanan normal yang digunakan. Ini berarti Anda tidak akan melihat item terpisah pada tagihan Anda yang mewakili pembagian file yang terhapus sementara untuk akun penyimpanan dengan sistem pembayaran sesuai penggunaan Anda. Ini juga berarti bahwa penggunaan berbagi file yang dihapus lunak dihitung terhadap reservasi yang dibeli untuk berbagi file dengan skema bayar sesuai pemakaian.

Meter penagihan prabayar

Berbagi file yang dibuat menggunakan model penagihan bayar sesuai pemakaian dikenakan biaya berdasarkan meter pengukuran berikut:

• Data Disimpan: Penyimpanan yang digunakan termasuk berbagi langsung, rekam jepret diferensial, dan berbagi file yang dihapus sementara di GiB.
• Metadata: Ukuran metadata sistem file yang terkait dengan file dan direktori seperti daftar kontrol akses (ACL) dan properti lain di GiB. Meter penagihan ini hanya digunakan untuk berbagi file di tingkat akses panas atau dingin.
• Operasi Tulis: Jumlah wadah transaksi tulis (satu wadah = 10.000 transaksi).
• Operasi Daftar: Jumlah wadah transaksi daftar (satu wadah = 10.000 transaksi).
• Operasi Baca: Jumlah wadah transaksi baca (satu wadah = 10.000 transaksi).
• Operasi / LainOperasi Protokol: Jumlah wadah transaksi lainnya (satu wadah = 10.000 transaksi).
• Pengambilan Data: Jumlah data yang dibaca dari file share dalam GiB. Meter ini hanya digunakan untuk berbagi file pada tingkat akses dingin.
• Transfer Data Replikasi-Geo: Jika berbagi file memiliki redundansi Geo atau GeoZone, jumlah data yang dituliskan ke berbagi file direplikasi ke wilayah sekunder dalam GiB.

Unit konsumsi yang berhubungan dengan meter penagihan Data Tersimpan dan Metadata dikeluarkan per jam dalam unit bulanan. Misalnya, untuk simpanan dengan penggunaan 1.024 GiB, Anda akan melihat:

• Jumlah variabel unit untuk satu jam individu tergantung pada jumlah hari dalam bulan:
  • Bulan 28 hari (Februari normal): 1,5238 unit terhadap meter Data Tersimpan.
  • Bulan 29 hari (tahun kabisat Februari): 1,4713 unit terhadap meteran Data Tersimpan.
  • Bulan 30 hari: 1,4222 unit terhadap meter Data Tersimpan.
  • Bulan 31 hari: 1,3763 unit terhadap meteran Data Stored.
• Jumlah unit yang bervariasi jika diakumulasikan selama sehari tergantung pada jumlah hari dalam bulan.
  • Bulan 28 hari (Februari normal): 36.5714 unit terhadap meter Data yang Disimpan .
  • Bulan 29 hari (tahun kabisat Februari): 35.3103 unit terhadap meter Data yang Disimpan.
  • Bulan 30 hari: 34.1333 unit terhadap meter Data Tersimpan.
  • Bulan 31 hari: 33,0323 unit terhadap meter Data Tersimpan .
• 1,024 unit terhadap meter Data Tersimpan jika dikumpulkan selama sebulan.

Konsumsi untuk meteran lainnya (mis. Operasi Tulis atau Pengambilan Data) dikeluarkan setiap jam, tetapi karena tidak diukur berdasarkan jangka waktu, tidak memerlukan transformasi unit khusus.

Penyiapan/kuota, ukuran logis, dan ukuran fisik

Azure Files melacak tiga jumlah berbeda sehubungan dengan kapasitas berbagi:

• Ukuran atau kuota yang ditetapkan: Dengan berbagi file yang ditetapkan dan bayar sesuai penggunaan, Anda menentukan ukuran maksimum yang dapat dimiliki oleh berbagi file. Pada file share yang disediakan, nilai ini disebut ukuran yang dialokasikan. Berapa pun jumlah yang Anda sediakan adalah apa yang Anda bayar, tidak peduli seberapa banyak yang benar-benar Anda gunakan. Dalam berbagi file dengan sistem bayar sesuai penggunaan, nilai ini disebut kuota dan tidak langsung memengaruhi tagihan Anda. Ukuran yang ditentukan adalah bidang wajib untuk berbagi file yang telah diatur sebelumnya. Untuk berkas bersama dengan sistem pembayaran sesuai pemakaian, jika ukuran yang dialokasikan tidak ditentukan secara langsung, berkas tersebut akan secara default diatur ke nilai maksimum yang didukung oleh akun penyimpanan (100 TiB).

• Ukuran logis: Ukuran logis berbagi file atau file berkaitan dengan seberapa besar ukurannya tanpa mempertimbangkan bagaimana file tersebut benar-benar disimpan, tanpa pengoptimalan penyimpanan apa pun. Ukuran logis file adalah berapa banyak KiB/MiB/GiB yang akan ditransfer melalui kawat jika Anda menyalinnya ke lokasi yang berbeda. Dalam berbagi file yang menggunakan skema penyediaan maupun bayar sesuai penggunaan, ukuran logis total dari berbagi file digunakan untuk penerapan terhadap ukuran/kuota yang diprovisikan. Dalam berbagi file prabayar, ukuran logis adalah kuantitas yang digunakan untuk penagihan penggunaan data saat tidak aktif. Ukuran logis disebut sebagai "ukuran" dalam dialog properti Windows untuk file/folder dan sebagai "panjang konten" menurut metrik Azure Files.

• Ukuran fisik: Ukuran fisik file berkaitan dengan ukuran file seperti yang dikodekan pada disk. Ukuran fisik mungkin selaras dengan ukuran logis file, atau mungkin lebih kecil, tergantung pada bagaimana file telah ditulis oleh sistem operasi. Alasan umum ukuran logis dan ukuran fisik berbeda adalah penggunaan berkas jarang. Ukuran fisik file dalam berbagi digunakan untuk penagihan rekam jepret, meskipun rentang yang dialokasikan dibagikan antara rekam jepret jika tidak berubah (penyimpanan diferensial).

Layanan bernilai tambah

Seperti banyak solusi penyimpanan lokal, Azure Files menyediakan titik integrasi untuk produk pihak pertama dan ketiga untuk diintegrasikan dengan berbagi file milik pelanggan. Meskipun solusi ini dapat memberikan nilai ekstra yang cukup besar untuk Azure Files, Anda harus mempertimbangkan biaya tambahan yang ditambahkan layanan ini ke total biaya solusi Azure Files.

Biaya dipecah menjadi tiga wadah:

• Biaya lisensi untuk layanan bernilai tambah. Biaya lisensi mungkin datang dalam bentuk biaya tetap per pelanggan, pengguna akhir (kadang-kadang disebut "biaya kepala"), berbagi file Azure, atau akun penyimpanan. Mereka mungkin juga didasarkan pada unit pemanfaatan penyimpanan, seperti biaya tetap untuk setiap potongan data 500 GiB dalam berbagi file.

• Biaya transaksi untuk layanan bernilai tambah. Beberapa layanan bernilai tambah memiliki konsep transaksi mereka sendiri di atas model penagihan Azure Files yang dipilih. Transaksi ini muncul pada tagihan Anda di bawah biaya layanan bernilai tambah; namun, mereka berhubungan langsung dengan cara Anda menggunakan layanan bernilai tambah dengan berbagi file Anda.

• Biaya Azure Files untuk menggunakan layanan bernilai tambah. Azure Files tidak secara langsung membebankan biaya kepada pelanggan untuk menambahkan layanan bernilai tambah, tetapi sebagai bagian dari menambahkan nilai ke berbagi file Azure, layanan bernilai tambah mungkin meningkatkan biaya yang Anda lihat di berbagi file Azure Anda. Biaya ini mudah dilihat dengan berbagi file prabayar, karena biaya transaksi. Jika layanan bernilai tambah melakukan transaksi terhadap berbagi file atas nama Anda, layanan tersebut muncul di tagihan transaksi Azure Files Anda meskipun Anda tidak langsung melakukan transaksi tersebut sendiri. Ini berlaku untuk berbagi file yang disediakan juga, meskipun mungkin kurang terlihat. Transaksi terhadap file share yang disediakan oleh layanan bernilai tambah dihitung terhadap jumlah IOPS yang disediakan, yang berarti layanan bernilai tambah mungkin memerlukan penambahan penyediaan lebih banyak penyimpanan untuk memastikan IOPS atau throughput yang cukup tersedia bagi beban kerja Anda.

Saat menghitung total biaya kepemilikan untuk berbagi file Anda, Anda harus mempertimbangkan biaya Azure Files dan dari semua layanan bernilai tambah yang ingin Anda gunakan dengan Azure Files.

Ada beberapa layanan pihak pertama dan ketiga bernilai tambah. Dokumen ini mencakup subset dari layanan pihak pertama umum yang digunakan pelanggan dengan berbagi file Azure. Anda dapat mempelajari lebih lanjut layanan yang tidak tercantum di sini dengan membaca halaman harga untuk layanan tersebut.

Sinkronisasi File Azure

Azure File Sync adalah layanan bernilai tambah untuk Azure Files yang menyinkronkan satu atau beberapa berbagi file Windows lokal dengan berbagi file Azure. Karena Azure cloud file share memiliki salinan lengkap data dalam file share yang disinkronkan yang tersedia di lokasi, Anda dapat mengubah Windows File Server di lokasi Anda menjadi cache untuk Azure file share guna mengurangi jejak di lokasi Anda. Pelajari selengkapnya dengan membaca Pengantar Azure File Sync.

Saat mempertimbangkan total biaya kepemilikan untuk solusi yang disebarkan menggunakan Azure File Sync, Anda harus mempertimbangkan aspek biaya berikut:

• Biaya modal dan operasional Server File Windows dengan satu atau beberapa titik akhir server. Sinkronisasi File Azure sebagai solusi replikasi tidak tergantung pada lokasi Server File Windows yang disinkronkan dengan Azure Files; server tersebut bisa ditempatkan di lokal, dalam Azure VM, atau bahkan di cloud lainnya. Kecuali Anda menggunakan Sinkronisasi File Azure dengan Server File Windows yang dihosting di mesin virtual Azure, modal (yaitu biaya perangkat keras di muka dari solusi Anda) dan biaya pengoperasian (yaitu biaya tenaga kerja, listrik, dll.) tidak akan menjadi bagian dari tagihan Azure Anda, tetapi masih akan menjadi bagian besar dari total biaya kepemilikan Anda. Anda harus mempertimbangkan jumlah data yang Anda butuhkan untuk melakukan cache lokal, jumlah CPU dan jumlah memori yang diperlukan Server File Windows Anda untuk menghosting beban kerja Sinkronisasi File Azure (lihat sumber daya sistem yang direkomendasikan untuk informasi selengkapnya), dan biaya khusus organisasi lainnya yang mungkin Anda miliki.

• Biaya lisensi per server untuk server yang terdaftar di Sinkronisasi File Azure. Untuk menggunakan Sinkronisasi File Azure dengan Server File Windows tertentu, Anda harus terlebih dahulu mendaftarkannya dengan sumber daya Azure Sinkronisasi File Azure, Layanan Sinkronisasi Penyimpanan. Setiap server yang Anda daftarkan setelah server pertama memiliki biaya bulanan tetap. Meskipun biaya ini sangat kecil, ini adalah salah satu komponen dari tagihan Anda untuk dipertimbangkan. Untuk melihat harga biaya pendaftaran server saat ini untuk wilayah yang Anda inginkan, lihat bagian Sinkronisasi File di halaman harga Azure Files.

• Biaya untuk Azure Files. Karena Azure File Sync adalah solusi sinkronisasi untuk Azure Files, Anda akan mengonsumsi sumber daya Azure Files. Beberapa sumber daya ini, seperti konsumsi penyimpanan, relatif jelas, sementara yang lain seperti transaksi dan pemanfaatan snapshot mungkin tidak. Untuk sebagian besar pelanggan, kami sarankan menggunakan berbagi file standar dengan Sinkronisasi File Azure, meskipun jika diinginkan, Sinkronisasi File Azure sepenuhnya didukung dengan berbagi file premium.

  • Pemanfaatan penyimpanan. Sinkronisasi File Azure akan mereplikasi perubahan apa pun yang telah Anda buat pada path di Windows File Server yang ditentukan pada titik akhir server Anda ke file share Azure Anda, yang mengakibatkan penggunaan penyimpanan. Pada berbagi standar, menambahkan atau meningkatkan ukuran file yang ada di titik akhir server akan menyebabkan biaya penyimpanan bertambah, karena perubahan akan direplikasi. Pada berbagi file premium, perubahan akan menggunakan ruang provisioning - Anda bertanggung jawab untuk secara berkala meningkatkan pengaturan sumber daya sesuai kebutuhan guna memperhitungkan pertumbuhan berbagi file.

  • Pemanfaatan snapshot. Sinkronisasi File Azure mengambil cuplikan tingkat berbagi dan file sebagai bagian dari penggunaan reguler. Meskipun pemanfaatan snapshot selalu bersifat diferensial, hal ini dapat memberikan kontribusi yang signifikan terhadap total tagihan Azure Files.

  • Transaksi dari keseluruhan pelanggan. Saat file berubah di titik akhir server, perubahan diunggah ke cloud share, yang menghasilkan transaksi. Saat penjenjangan cloud diaktifkan, transaksi tambahan dibuat untuk mengelola file-file yang diberi jenjang, termasuk I/O yang terjadi pada file-file tersebut, selain biaya egress. Meskipun kuantitas dan jenis transaksi sulit diprediksi karena tingkat churn dan efisiensi cache, Anda dapat menggunakan pola transaksi sebelumnya untuk memperkirakan biaya di masa mendatang jika Anda yakin penggunaan Anda di masa mendatang akan mirip dengan penggunaan Anda saat ini.

  • Transaksi dari pendataan cloud. Sinkronisasi File Azure mengindeks Azure File Share di cloud sekali sehari untuk menemukan perubahan yang dibuat langsung pada file share tersebut sehingga dapat disinkronkan ke endpoint server. Pemindaian ini menghasilkan transaksi yang ditagihkan ke akun penyimpanan dengan biaya satu transaksi ListFiles per direktori per hari. Anda dapat memasukkan nomor ini ke dalam kalkulator harga untuk memperkirakan biaya pemindaian.

  Kiat

  Jika Anda tidak tahu berapa banyak folder yang Anda miliki, periksa alat TreeSize dari JAM Software GmbH.

Pencadangan Azure

Azure Backup menyediakan solusi pencadangan tanpa server untuk Azure Files yang terintegrasi dengan berbagi file Anda dengan lancar, serta layanan bernilai tambah lainnya seperti Azure File Sync. Azure Backup untuk Azure Files adalah solusi pencadangan berbasis snapshot yang menyediakan mekanisme penjadwalan untuk mengambil snapshot secara otomatis pada jadwal yang ditentukan administrator. Ini juga menyediakan antarmuka yang mudah digunakan untuk memulihkan file/folder yang dihapus atau seluruh berbagi ke titik waktu tertentu. Untuk mempelajari selengkapnya, lihat Tentang pencadangan berbagi file Azure.

Saat mempertimbangkan biaya penggunaan Azure Backup, pertimbangkan faktor-faktor berikut:

• Biaya lisensi instans yang terlindungi untuk data berbagi file Azure. Azure Backup mengenakan biaya lisensi instans yang diproteksi untuk setiap akun penyimpanan yang berisi berbagi file Azure yang telah dicadangkan. Instans yang dilindungi didefinisikan sebagai 250 GiB penyimpanan berbagi file Azure. Akun penyimpanan yang berisi kurang dari 250 GiB akan dibebankan biaya instans terlindungi secara proporsional. Untuk informasi selengkapnya, lihat Harga Azure Backup. Anda harus memilih Azure Files dari daftar layanan yang dapat dilindungi Azure Backup.

• Biaya untuk Azure Files. Azure Backup meningkatkan biaya Azure Files dengan cara berikut:

  • Biaya diferensial dari snapshot pada layanan berbagi file Azure. Azure Backup mengotomatiskan pengambilan snapshot berbagi file Azure pada jadwal yang ditentukan administrator. Rekaman snapshot selalu bersifat diferensial; namun, biaya tambahan tergantung pada lama waktu snapshot disimpan dan jumlah perubahan pada berbagi file selama waktu tersebut. Faktor-faktor ini menentukan seberapa berbeda rekam jepret dari berbagi file langsung dan oleh karena itu berapa banyak data tambahan yang disimpan oleh Azure Files.

  • Biaya transaksi dari operasi pemulihan. Memulihkan operasi dari rekam jepret ke berbagi langsung dikenakan biaya transaksi. Untuk berbagi file standar, bacaan dari cuplikan/tulisan dari pemulihan ditagih sebagai transaksi berbagi file normal. Untuk file share yang sudah disediakan, operasi ini dihitung terhadap IOPS yang sudah dipersiapkan untuk file share tersebut.

Microsoft Defender untuk Penyimpanan

Microsoft Defender mendukung Azure Files sebagai bagian dari produk Microsoft Defender for Storage-nya. Microsoft Defender for Storage mendeteksi upaya yang tidak biasa dan berpotensi berbahaya untuk mengakses atau mengeksploitasi berbagi file Azure Anda melalui SMB atau FileREST. Microsoft Defender for Storage diaktifkan pada tingkat langganan untuk semua berbagi file di akun penyimpanan dalam langganan tersebut.

Pertahanan Microsoft untuk Penyimpanan tidak mendukung kemampuan antivirus untuk berbagi file Azure.

Biaya utama dari Microsoft Defender untuk Penyimpanan adalah serangkaian biaya transaksi tambahan yang dipungut produk di atas transaksi yang dilakukan terhadap Azure file share. Meskipun biaya ini didasarkan pada transaksi yang dikeluarkan dalam Azure Files, biaya tersebut bukan bagian dari penagihan untuk Azure Files, melainkan merupakan bagian dari harga Microsoft Defender. Microsoft Defender for Storage mengenakan biaya transaksi bahkan pada berbagi file yang diprovisikan, sementara Azure Files menyertakan transaksi sebagai bagian dari provisi IOPS. Tingkat transaksi saat ini dapat ditemukan di halaman harga Microsoft Defender untuk Cloud di baris tabel Microsoft Defender untuk Penyimpanan.

Berbagi file dengan transaksi tinggi dikenakan biaya yang signifikan menggunakan Microsoft Defender untuk Penyimpanan Data. Berdasarkan biaya ini, Anda mungkin ingin menolak Microsoft Defender for Storage untuk akun penyimpanan tertentu. Untuk informasi lebih banyak, lihat Mengecualikan akun penyimpanan dari perlindungan Microsoft Defender for Storage.

Reservasi

Azure Files mendukung reservasi (juga disebut sebagai instans terpesan) untuk model v1 yang telah ditentukan dan model bayar sesuai penggunaan. Reservasi memungkinkan Anda mendapatkan diskon penyimpanan dengan berkomitmen di awal terhadap penggunaan penyimpanan. Anda sebaiknya mempertimbangkan pembelian instans cadangan untuk beban kerja produksi apa pun, atau untuk beban kerja pengembangan/ujian dengan jejak yang konsisten. Saat membeli Reservasi, Anda harus menentukan dimensi berikut:

• Ukuran kapasitas: Reservasi dapat untuk 10 TiB atau 100 TiB, dengan diskon lebih besar untuk membeli reservasi kapasitas yang lebih tinggi. Anda dapat membeli beberapa Reservasi, termasuk Reservasi dengan ukuran kapasitas yang berbeda untuk memenuhi persyaratan beban kerja Anda. Misalnya, jika penerapan produksi Anda memiliki 120 TiB file share, Anda dapat membeli satu komitmen 100 TiB dan dua komitmen 10 TiB untuk memenuhi total persyaratan kapasitas penyimpanan.
• Jangka Waktu: Anda dapat membeli reservasi untuk jangka waktu satu tahun atau tiga tahun, dengan diskon yang lebih signifikan untuk membeli jangka waktu Reservasi yang lebih lama.
• Lapisan: Lapisan Azure Files untuk Reservasi. Reservasi saat ini tersedia untuk model penagihan yang disediakan oleh SSD v1 (dikenal sebagai "premium") dan HDD dengan sistem bayar sesuai pemakaian, yang hanya mencakup tingkatan akses panas dan dingin.
• Lokasi: Wilayah Azure untuk Reservasi. Reservasi tersedia di sebagian wilayah Azure.
• Redundansi: Redundansi penyimpanan untuk Reservasi. Reservasi didukung untuk semua opsi redundansi yang didukung Azure Files, termasuk LRS, ZRS, GRS, dan GZRS.
• Frekuensi penagihan: Menunjukkan seberapa sering akun ditagih untuk Reservasi. Opsi ini termasuk Bulanan atau Uang Muka.

Setelah Anda membeli Reservasi, reservasi tersebut secara otomatis digunakan untuk pemanfaatan penyimpanan yang sudah ada. Jika Anda menggunakan lebih banyak penyimpanan daripada yang telah dipesan, Anda membayar harga pasaran untuk kelebihan penggunaan yang tidak dicakup oleh reservasi. Biaya transaksi, bandwidth, transfer data, dan penyimpanan metadata tidak termasuk dalam Reservasi.

Ada perbedaan dalam cara kerja Reservasi dengan cuplikan layanan berbagi file Azure untuk layanan berbagi file v1 dengan model pay-as-you-go dan model yang ditentukan. Jika Anda mengambil rekam jepret pembagian file sesuai penggunaan, maka perubahan rekam jepret terhitung terhadap Reservasi dan dihitung sebagai bagian dari penggunaan penyimpanan normal. Namun, jika Anda mengambil snapshot dari berbagi file v1 yang telah disediakan, maka snapshot tersebut ditagih menggunakan meter terpisah dan tidak dihitung terhadap Reservasi.

Untuk informasi selengkapnya tentang cara membeli Reservasi, lihat Mengoptimalkan biaya untuk Azure Files dengan Reservasi.

Lihat juga

• Penetapan Harga Azure Files.
• Merencanakan untuk penyebaran Azure Files dan Merencanakan penyebaran Azure File Sync.
• Membuat berbagi berkas dan Menyebarkan Azure File Sync.