Memahami model penagihan Azure Files

Azure Files mendukung dua tingkat penyimpanan media yang berbeda, SSD dan HDD, yang memungkinkan Anda 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): host berbagi file pada hard disk drive (HDD) menyediakan penyimpanan hemat biaya untuk penggunaan tujuan umum.

Azure Files memiliki beberapa model harga termasuk opsi yang disediakan 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, terlepas dari berapa banyak yang Anda gunakan. Azure Files memiliki dua model yang disediakan berbeda v2 dan v1 yang disediakan.

  • V2 yang disediakan: Dalam model v2 yang disediakan, 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, 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 berapa banyak Anda menggunakan berbagi, dalam bentuk biaya penyimpanan, transaksi, dan transfer data yang digunakan. Model bayar sesuai penggunaan untuk Azure Files hanya tersedia untuk berbagi file HDD. Sebaiknya gunakan model v2 yang disediakan untuk penyebaran berbagi file HDD baru.

Artikel ini menjelaskan model penagihan untuk pekerjaan Azure Files untuk membantu Anda memahami tagihan Azure Files bulanan Anda. Untuk informasi harga Azure Files, lihat laman harga Azure Files.

Berlaku untuk

Model manajemen	Model tagihan	Tingkat media	Redundansi geografis	SMB	NFS
Microsoft.Storage	V2 yang disediakan	HDD (standar)	Lokal (LRS)
Microsoft.Storage	V2 yang disediakan	HDD (standar)	Zona (ZRS)
Microsoft.Storage	V2 yang disediakan	HDD (standar)	Geo (GRS)
Microsoft.Storage	V2 yang disediakan	HDD (standar)	GeoZone (GZRS)
Microsoft.Storage	V1 yang disediakan	SSD (premium)	Lokal (LRS)
Microsoft.Storage	V1 yang disediakan	SSD (premium)	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	Unit
KiB	1.024 byte	kibibyte
MiB	1.024 KiB (1.048.576 byte)	mebibyte
GiB	1024 MiB (1.073.741.824 byte)	gibibyte
TiB	1024 GiB (1.099.511.627.776 byte)	tebibyte

Meskipun unit ukuran base-2 umumnya digunakan oleh sebagian besar sistem operasi dan alat untuk mengukur jumlah penyimpanan, unit tersebut sering dilabeli sebagai unit base-10, yang mungkin lebih Anda kenal: KB, MB, GB, dan TB. Meskipun alasan kesalahan pelabelan bervariasi, alasan umum mengapa sistem operasi seperti Windows salah memberi label pada unit penyimpanan adalah karena banyak sistem operasi mulai menggunakan akronim ini sebelum distandarkan oleh IEC (Komisi Elektroteknik Internasional), BIPM (Biro Bobot dan Ukuran Internasional), dan NIST (Institut Standar dan Teknologi Nasional AS).

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

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

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

Daftar periksa total biaya kepemilikan berbagi file

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

• Bagaimana Anda membayar penyimpanan, IOPS, dan lebar pita? Sebagian besar solusi cloud memiliki model yang rata dengan prinsip penyimpanan yang diprovisikan, seperti determinisme harga dan kesederhanaan, atau penyimpanan prabayar, yang mana dapat mengoptimalkan harga hanya dengan pengisian sesuai yang benar-benar Anda gunakan. Yang menarik untuk model yang diprovisikan adalah ukuran berbagi minimum yang diprovisikan, unit penyediaan, 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 berkas lainnya, pertimbangkan apakah ketahanan penyimpanan dan redundansi bawaan atau sesuatu yang harus Anda kumpulkan sendiri.

• Apa yang perlu Anda lakukan untuk mengelola? Dengan Azure Files, unit pengelolaan dasar adalah akun penyimpanan. Solusi lain mungkin memerlukan manajemen tambahan, seperti pembaruan sistem operasi atau manajemen 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 prediksi total biaya kepemilikan dengan fleksibilitas, memungkinkan Anda membuat berbagi file yang memenuhi persyaratan penyimpanan dan performa yang tepat. Saat Anda membuat berbagi file v2 baru yang disediakan, Anda menentukan berapa banyak penyimpanan, IOPS, dan throughput yang dibutuhkan berbagi 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 berbagi 2 TiB dan mengunggah 2 TiB data ke berbagi Anda, berbagi Anda akan penuh dan 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, dengan upaya terbaik, sementara kredit tetap ada.

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 hanya setelah 24 jam berlalu sejak peningkatan kuantitas terakhir Anda. Perubahan penyimpanan, IOPS, dan throughput efektif dalam beberapa menit setelah perubahan provisi.

Secara default, saat Anda membuat berbagi file baru menggunakan model v2 yang disediakan, kami memberikan rekomendasi untuk berapa banyak IOPS dan berapa banyak throughput yang Anda butuhkan berdasarkan jumlah penyimpanan yang disediakan yang Anda tentukan. Meskipun rekomendasi ini didasarkan pada penggunaan pelanggan yang khas untuk jumlah penyimpanan yang disediakan untuk tingkat media tersebut di Azure Files, Anda mungkin menemukan bahwa beban kerja Anda memerlukan lebih atau kurang IOPS dan throughput daripada "berbagi file biasa", dan 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, subkumpulan SKU akun penyimpanan berikut tersedia:

Jenis akun penyimpanan	SKU akun penyimpanan	Jenis berbagi file yang tersedia
FileStorage	StandardV2_LRS	Berbagi file v2 yang disediakan HDD dengan redundansi Lokal (LRS) yang ditentukan.
FileStorage	StandardV2_ZRS	Berbagi file v2 yang disediakan HDD dengan redundansi Zona (ZRS) yang ditentukan.
FileStorage	StandardV2_GRS	Berbagi file v2 yang disediakan HDD dengan redundansi Geo (GRS) yang ditentukan.
FileStorage	StandardV2_GZRS	Berbagi file v2 yang disediakan HDD dengan redundansi GeoZone (GZRS) yang ditentukan.

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

• Prancis Tengah
• Prancis Selatan
• Australia Timur
• Australia Tenggara
• Asia Timur
• Asia Tenggara
• US Barat 2
• AS Tengah Bagian Barat
• Eropa Barat
• Eropa Utara

Detail provisi 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:

Item	Nilai HDD
Unit provisi penyimpanan	1 GiB
Unit provisi IOPS	1 IO /dtk
Unit provisi throughput	1 MiB / detik
Penyimpanan minimum yang disediakan per berbagi file	32 GiB
IOPS minimum yang disediakan per berbagi file	500 IOPS
Throughput minimum yang disediakan per berbagi file	60 MiB / dtk
Penyimpanan maksimum yang disediakan per berbagi file	256 TiB (262.144 GiB)
IOPS maksimum yang disediakan per berbagi file	50.000 IOPS
Throughput maksimum yang disediakan per 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
Throughput maksimum yang disediakan per akun penyimpanan	5.120 MiB /dtk
Jumlah maksimum berbagi file per akun penyimpanan	50 berbagi file

Secara default, kami merekomendasikan provisi IOPS dan throughput berdasarkan penyimpanan yang disediakan 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 throughput	MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

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

Bursting v2 yang disediakan

Bursting IOPS berbasis kredit memberikan fleksibilitas tambahan seputar penggunaan IOPS. Fleksibilitas ini paling baik digunakan sebagai buffer terhadap lonjakan IO yang tidak terduga. Untuk pola IO yang ditetapkan, sebaiknya provisi untuk puncak IO.

Kredit IOPS burst terakumulasi setiap kali lalu lintas untuk berbagi file Anda di bawah IOPS yang disediakan (garis besar). Setiap kali penggunaan IOPS berbagi file melebihi IOPS yang disediakan dan ada kredit IOPS burst yang tersedia, berbagi file dapat meledak hingga batas IOPS burst maksimum yang diizinkan. Berbagi file dapat terus meledak selama ada kredit yang tersisa, tetapi ini didasarkan pada jumlah kredit burst yang dikumpulkan. Setiap IO di luar IOPS yang disediakan menggunakan satu kredit. Setelah semua kredit digunakan, berbagi kembali ke IOPS yang disediakan. IOPS terhadap berbagi file tidak perlu melakukan sesuatu yang istimewa untuk menggunakan bursting. Bursting beroperasi berdasarkan upaya terbaik.

Kredit berbagi memiliki tiga negara bagian:

• Mengumpulkan, ketika berbagi file menggunakan kurang dari IOPS yang disediakan.
• Menolak, ketika berbagi file menggunakan lebih dari IOPS yang disediakan dan 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 penuh kredit dalam wadah burst-nya. Kredit burst tidak bertambah jika IOPS berbagi berada di bawah batas yang disediakan karena pembatasan oleh server. Rumus berikut digunakan untuk menentukan batas IOPS burst dan jumlah kredit yang mungkin untuk berbagi file:

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

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

IOPS yang diprovisikan	Batas IOPS ledakan HDD	Kredit ledakan 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

Rekam jepret 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.

Rekam jepret selalu diferensial dari berbagi langsung dan satu sama lain. Dalam model penagihan v2 yang disediakan, jika ukuran diferensial total semua rekam jepret cocok dalam ruang penyimpanan kelebihan yang disediakan dari berbagi file, tidak ada biaya tambahan untuk penyimpanan rekam jepret. Jika ukuran data berbagi langsung ditambah data rekam jepret diferensial lebih besar dari penyimpanan berbagi yang disediakan, kelebihan kapasitas yang digunakan dari rekam jepret ditagih terhadap pengukur 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. Lihat layanan bernilai tambah untuk Azure Files untuk informasi selengkapnya.

Penghapusan sementara v2 yang disediakan

Berbagi file yang dihapus di akun penyimpanan dengan penghapusan sementara diaktifkan ditagih berdasarkan kapasitas penyimpanan yang digunakan dari berbagi yang dihapus selama periode penghapusan sementara. Untuk memastikan bahwa berbagi file yang dihapus selalu dapat dipulihkan, penyimpanan yang disediakan, IOPS, dan throughput jumlah berbagi terhadap batas akun penyimpanan hingga berbagi file dihapus menyeluruh, namun tidak ditagih. Untuk informasi selengkapnya tentang penghapusan sementara, lihat Cara mengaktifkan penghapusan sementara pada berbagi file Azure.

Meter penagihan v2 yang disediakan

Berbagi file yang disediakan menggunakan model penagihan v2 yang disediakan ditagih terhadap lima meter penagihan berikut:

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

Konsumsi terhadap pengukur penagihan v2 yang disediakan dipancarkan setiap jam dalam hal unit per jam. Misalnya, untuk berbagi dengan 1024 GiB yang disediakan, Anda akan melihat:

• 1.024 unit terhadap pengukur Storage yang Disediakan selama satu jam.
• 24.576 unit terhadap pengukur Penyimpanan yang Disediakan jika dikumpulkan selama sehari.
• 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 Disediakan.
  • Bulan 29 hari (tahun kampung Februari): 712.704 unit terhadap pengukur Penyimpanan yang Disediakan.
  • Bulan 30 hari: 737.280 unit terhadap meter Penyimpanan yang Disediakan.
  • Bulan 31 hari: 761.856 unit terhadap meter Penyimpanan yang Disediakan.

Model v1 yang disediakan

Metode v1 yang disediakan menyediakan penyimpanan, IOPS, dan throughput dalam rasio tetap satu sama lain, mirip dengan bagaimana penyimpanan dibeli dalam solusi penyimpanan lokal. Saat Anda membuat berbagi file v1 baru yang disediakan, Anda menentukan berapa banyak penyimpanan yang dibutuhkan berbagi Anda, dan IOPS dan throughput adalah nilai komputasi. 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 berbagi 2 TiB dan mengunggah 2 TiB data ke berbagi Anda, berbagi Anda akan penuh dan 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, dengan upaya terbaik, sementara kredit tetap ada.

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 hanya setelah 24 jam berlalu sejak peningkatan penyimpanan terakhir Anda. Perubahan penyimpanan, IOPS, dan throughput efektif dalam beberapa menit setelah perubahan provisi.

Dimungkinkan untuk mengurangi ukuran saham yang Anda cantumkan di bawah GiB bekas Anda. Jika Anda melakukannya, Anda tidak akan kehilangan data, namun Anda masih akan ditagih untuk ukuran yang digunakan dan menerima kinerja dari saham yang dicantumkan, bukan ukuran 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	Berbagi file v1 yang disediakan SSD dengan redundansi Lokal (LRS) yang ditentukan.
FileStorage	Premium_LRS	Berbagi file v1 yang disediakan SSD dengan redundansi Zona (ZRS) yang ditentukan.

Berbagi file SSD menggunakan model v1 yang disediakan umumnya tersedia di sebagian besar wilayah Azure. Lihat Produk Azure menurut wilayah untuk informasi selengkapnya.

Detail provisi v1 yang disediakan

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

Item	Nilai
Unit provisi penyimpanan	1 GiB
Penyimpanan minimum yang disediakan per berbagi file	100 GiB
Penyimpanan maksimum yang disediakan per berbagi file	100 TiB (102.400 GiB)
Penyimpanan maksimum yang disediakan per akun penyimpanan	100 TiB (102.400 GiB)

Jumlah IOPS dan throughput yang disediakan pada berbagi ditentukan oleh rumus berikut:

Item	Rumus
IOPS yang disediakan komputasi (garis besar)	MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
Throughput yang disediakan komputasi (MiB/dtk)	100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

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

Bursting v1 yang disediakan

Bursting IOPS berbasis kredit memberikan fleksibilitas tambahan seputar penggunaan IOPS. Fleksibilitas ini paling baik digunakan sebagai buffer terhadap lonjakan IO yang tidak terduga. Untuk pola IO yang ditetapkan, sebaiknya provisi untuk puncak IO.

Kredit IOPS burst terakumulasi setiap kali lalu lintas untuk berbagi file Anda di bawah IOPS yang disediakan (garis besar). Setiap kali penggunaan IOPS berbagi file melebihi IOPS yang disediakan dan ada kredit IOPS burst yang tersedia, berbagi file dapat meledak hingga batas IOPS burst maksimum yang diizinkan. Berbagi file dapat terus meledak selama ada kredit yang tersisa, tetapi ini didasarkan pada jumlah kredit burst yang dikumpulkan. Setiap IO di luar IOPS yang disediakan menggunakan satu kredit. Setelah semua kredit digunakan, berbagi kembali ke IOPS yang disediakan. IOPS terhadap berbagi file tidak perlu melakukan sesuatu yang istimewa untuk menggunakan bursting. Bursting beroperasi berdasarkan upaya terbaik.

Kredit berbagi memiliki tiga negara bagian:

• Mengumpulkan, ketika berbagi file menggunakan kurang dari IOPS yang disediakan.
• Menolak, ketika berbagi file menggunakan lebih dari IOPS yang disediakan dan 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 penuh kredit dalam wadah burst-nya. Kredit burst tidak bertambah jika IOPS berbagi berada di bawah batas yang disediakan karena pembatasan oleh server. Rumus berikut digunakan untuk menentukan batas IOPS burst dan jumlah kredit yang mungkin untuk berbagi file:

Item	Rumus
Batas peningkatan	MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Ledakan kredit	(BurstLimit - BaselineIOPS) * 3600

Tabel berikut ini mengilustrasikan beberapa contoh rumus ini untuk ukuran berbagi yang disediakan:

Kapasitas (GiB)	Garis Dasar IOPS	Burst IOPS	Ledakan kredit	Throughput (masuk + keluar) (MiB/dtk)
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

Performa berbagi file yang efektif tunduk pada batas jaringan mesin, bandwidth jaringan yang tersedia, ukuran IO, dan paralelisme, di antara banyak faktor lainnya. Untuk mencapai manfaat maksimum dari paralelisasi, sebaiknya aktifkan SMB Multichannel pada berbagi file SSD. Lihat panduan pemecahan masalah performa dan performa SMB untuk beberapa masalah dan solusi performa umum.

Rekam jepret v1 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.

Rekam jepret selalu diferensial dari berbagi langsung dan satu sama lain. Dalam model penagihan v1 yang disediakan, ukuran diferensial total ditagih terhadap pengukur penggunaan, terlepas dari berapa banyak penyimpanan yang disediakan tidak digunakan. Pengukur penyimpanan rekam jepret yang digunakan memiliki harga yang berkurang dibandingkan harga penyimpanan yang disediakan.

Penghapusan sementara v1 yang disediakan

Berbagi file yang dihapus di akun penyimpanan dengan penghapusan sementara diaktifkan ditagih berdasarkan kapasitas penyimpanan yang digunakan dari berbagi yang dihapus selama periode penghapusan sementara. Kapasitas penyimpanan penggunaan yang dihapus sementara dipancarkan terhadap pengukur penyimpanan rekam jepret yang digunakan. Untuk informasi selengkapnya tentang penghapusan sementara, lihat Cara mengaktifkan penghapusan sementara pada berbagi file Azure.

Meter penagihan v1 yang disediakan

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

• Premium Disediakan: Jumlah penyimpanan yang disediakan dalam GiB.
• Rekam Jepret Premium: Jumlah rekam jepret yang digunakan dan kapasitas yang dihapus sementara.

Konsumsi terhadap pengukur penagihan v1 yang disediakan dipancarkan setiap jam dalam hal unit bulanan. Misalnya, untuk berbagi dengan 1024 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 pengukur Yang Disediakan Premium.
  • Bulan 29 hari (tahun kampung Februari): 1,4713 unit terhadap pengukur Premium Yang Disediakan .
  • Bulan 30 hari: 1.4222 unit terhadap pengukur Yang Disediakan Premium.
  • Bulan 31 hari: 1,3763 unit terhadap pengukur Premium yang Disediakan .
• Jumlah variabel unit jika diagregasi selama sehari tergantung pada jumlah hari dalam bulan:
  • Bulan 28 hari (Februari normal): 36,5714 unit terhadap pengukur Yang Disediakan Premium.
  • Bulan 29 hari (tahun kampung Februari): 35.3103 unit terhadap pengukur Yang Disediakan Premium.
  • Bulan 30 hari: 34.1333 unit terhadap meteran Premium yang Disediakan .
  • Bulan 31 hari: 33,0323 unit terhadap meteran Premium yang Disediakan .
• 1024 unit terhadap meteran Premium yang Disediakan jika dikumpulkan selama sebulan.

Model bayar sesuai pemakaian

Dalam model bayar sesuai pemakaian, jumlah yang Anda bayar ditentukan oleh berapa banyak yang Anda gunakan, daripada berdasarkan jumlah yang disediakan. Pada tingkat tinggi, Anda membayar biaya untuk jumlah data logis yang disimpan, dan Anda juga dikenakan biaya untuk transaksi berdasarkan penggunaan data tersebut. Model penagihan bayar sesuai pemakaian mungkin sulit di rencanakan sebagai bagian dari proses penganggahan, karena model didorong oleh konsumsi pengguna akhir. Oleh karena itu, sebaiknya gunakan model v2 yang disediakan untuk penyebaran berbagi file baru. Model bayar sesuai penggunaan hanya tersedia untuk berbagi file HDD.

Ketersediaan bayar sesuai penggunaan

Model bayar sesuai penggunaan 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 bayar sesuai penggunaan HDD dengan redundansi Lokal (LRS) yang ditentukan.
StorageV2 atau Storage	Standard_LRS	Berbagi file bayar sesuai penggunaan HDD dengan redundansi Zona (ZRS) yang ditentukan.
StorageV2 atau Storage	Standard_GRS	Berbagi file bayar sesuai penggunaan HDD dengan redundansi Geo (GRS) yang ditentukan.
StorageV2 atau Storage	Standard_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 berbagi file HDD, Anda memilih antara tingkat akses berikut: transaksi dioptimalkan, panas, dan dingin. Ketiga tingkat akses disimpan pada perangkat keras penyimpanan yang sama persis. Perbedaan utama untuk ketiga tingkat akses ini adalah harga penyimpanan data saat istirahat, yang lebih rendah dalam tingkat yang lebih dingin, dan harga transaksi, yang lebih tinggi di tingkat yang lebih dingin. Ini berarti:

• Transaksi yang dioptimalkan, seperti namanya, mengoptimalkan harga untuk beban kerja IOPS (transaksi) tinggi. Transaksi yang dioptimalkan memiliki data harga penyimpanan saat istirahat 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. Anggaplah sebagai jalan tengah antara transaksi yang dioptimalkan dan tingkatan dingin.
• Cool mengoptimalkan harga untuk beban kerja yang tidak memiliki aktivitas tinggi, menawarkan harga penyimpanan data saat istirahat terendah, tetapi harga transaksi tertinggi.

Jika Anda menempatkan beban kerja yang jarang diakses di tingkat akses yang dioptimalkan transaksi, Anda akan membayar hampir tidak ada untuk beberapa kali dalam sebulan yang Anda lakukan transaksi terhadap berbagi Anda. Namun, Anda akan membayar biaya penyimpanan data dengan jumlah yang besar. Jika Anda memindahkan berbagi yang sama ini ke tingkat akses dingin, Anda masih akan membayar hampir tidak ada untuk biaya transaksi, hanya karena Anda jarang melakukan transaksi untuk beban kerja ini. Namun, tingkat akses dingin memiliki harga penyimpanan data yang jauh lebih murah. Memilih tingkat akses yang sesuai untuk kasus penggunaan Anda memungkinkan Anda mengurangi biaya Anda secara besar-besaran.

Demikian pula, jika Anda menempatkan beban kerja yang sangat diakses di tingkat akses dingin, Anda akan membayar lebih banyak dalam biaya transaksi, tetapi lebih sedikit untuk biaya penyimpanan data. Hal ini dapat menyebabkan situasi di mana peningkatan biaya dari harga transaksi meningkat melebihi penghematan dari penurunan harga penyimpanan data, membuat Anda membayar lebih banyak uang dengan dingin daripada yang Anda miliki pada transaksi yang dioptimalkan. 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 akan menentukan tingkat akses paling hemat biaya untuk berbagi file prabayar Anda. Dalam praktiknya, cara terbaik untuk memilih tingkat akses yang paling hemat biaya melibatkan melihat konsumsi sumber daya aktual berbagi (data yang disimpan, transaksi tulis, 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 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.

Sebagai prinsip, model penagihan bayar sesuai pemakaian yang digunakan oleh berbagi file standar ditagih berdasarkan penggunaan. Transaksi SMB dan FileREST yang dilakukan 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 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:

Wadah transaksi	Operasi pengelolaan	Operasi Data
Transaksi tulis	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

NFS 4.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 berbagi dari tingkat akses yang lebih panas ke tingkat akses yang lebih dingin, Anda akan dikenakan biaya transaksi tulis tingkat akses yang lebih dingin untuk setiap file dalam berbagi. Memindahkan berbagi file dari tingkat akses yang lebih dingin ke tingkat akses yang lebih panas akan dikenakan biaya transaksi baca tingkat akses yang lebih dingin untuk setiap file dalam berbagi.

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

Tabel berikut mengilustrasikan perincian biaya pemindahan tingkat akses:

Tingkat penyimpanan	Transaksi dioptimalkan (tujuan)	Panas (tujuan)	Dingin (tujuan)
Transaksi dioptimalkan (sumber)	--	1 transaksi penulisan panas per file.	1 transaksi penulisan dingin per file.
Panas (sumber)	1 transaksi baca panas per file.	--	1 transaksi penulisan dingin per file.
Dingin (sumber)	1 transaksi baca dingin per file. Pengambilan data per total GiB yang digunakan.	1 transaksi baca dingin per file. Pengambilan data per total GiB yang digunakan.	--

Meskipun tidak ada batas formal tentang seberapa sering Anda dapat mengubah tingkat akses berbagi file Anda, berbagi Anda akan memakan waktu untuk transisi berdasarkan jumlah data dalam berbagi Anda. Anda tidak dapat mengubah tingkat akses berbagi saat berbagi file bertransisi di antara tingkat akses. Mengubah tingkat akses berbagi file tidak memengaruhi akses berbagi file reguler.

Memilih tingkat akses

Terlepas dari cara Anda memigrasikan data yang ada ke Azure Files, sebaiknya buat berbagi file di tingkat akses yang dioptimalkan transaksi karena banyaknya transaksi yang terjadi selama migrasi. Setelah migrasi selesai dan Anda telah beroperasi selama beberapa hari atau minggu dengan penggunaan reguler, Anda dapat menyambungkan jumlah transaksi Anda ke dalam kalkulator harga untuk mengetahui 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 selama periode waktu tertentu untuk mendapatkan gambaran yang lebih baik 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.

Rekam jepret selalu diferensial dari berbagi langsung dan satu sama lain. Dalam model penagihan bayar sesuai pemakaian, ukuran diferensial total ditagih terhadap pengukur penyimpanan normal yang digunakan. Ini berarti Anda tidak akan melihat item baris terpisah pada tagihan yang mewakili rekam jepret untuk akun penyimpanan bayar sesuai pemakaian Anda. Ini juga berarti bahwa penggunaan snapshot diferensial dihitung terhadap reservasi yang dibeli untuk berbagi file prabayar.

Penghapusan sementara 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 selama periode penghapusan sementara. Kapasitas penyimpanan yang digunakan yang dihapus sementara dipancarkan terhadap pengukur penyimpanan normal yang digunakan. Ini berarti Anda tidak akan melihat item baris terpisah pada tagihan Anda yang mewakili berbagi file yang dihapus sementara untuk akun penyimpanan bayar sesuai penggunaan Anda. Ini juga berarti bahwa penggunaan berbagi file yang dihapus sementara dihitung terhadap reservasi yang dibeli untuk berbagi file prabayar.

Meter penagihan prabayar

Berbagi file yang dibuat menggunakan model penagihan bayar sesuai pemakaian ditagih berdasarkan meter 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 (1 wadah = 10.000 transaksi).
• Operasi Daftar: Jumlah wadah transaksi daftar (1 wadah = 10.000 transaksi).
• Baca Operasi: Jumlah wadah transaksi baca (1 wadah = 10.000 transaksi).
• Operasi Protokol Operasi / Lainnya: Jumlah wadah transaksi lainnya (1 wadah = 10.000 transaksi).
• Pengambilan Data: Jumlah data yang dibaca dari berbagi file di GiB. Meteran ini hanya digunakan untuk berbagi file di tingkat akses dingin.
• Transfer Data Geo-Replikasi: Jika berbagi file memiliki redundansi Geo atau GeoZone, jumlah data yang ditulis ke berbagi file direplikasi ke wilayah sekunder di GiB.

Konsumsi terhadap meter penagihan Data Tersimpan dan Metadata dipancarkan setiap jam dalam hal unit bulanan. Misalnya, untuk berbagi dengan GiB yang digunakan 1024, 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 pengukur Tersimpan Data .
  • Bulan 29 hari (tahun kampung Februari): 1,4713 unit terhadap pengukur Tersimpan Data .
  • Bulan 30 hari: 1.4222 unit terhadap pengukur Tersimpan Data .
  • Bulan 31 hari: 1,3763 unit terhadap pengukur Tersimpan Data .
• Jumlah variabel unit jika diagregasi selama sehari tergantung pada jumlah hari dalam bulan:
  • Bulan 28 hari (Februari normal): 36.5714 unit terhadap meteran Tersimpan Data.
  • Bulan 29 hari (tahun kampung Februari): 35.3103 unit terhadap pengukur Tersimpan Data.
  • Bulan 30 hari: 34.1333 unit terhadap pengukur Tersimpan Data.
  • Bulan 31 hari: 33,0323 unit terhadap pengukur Tersimpan Data.
• 1024 unit terhadap meteran Tersimpan Data jika dikumpulkan selama sebulan.

Konsumsi terhadap meteran lainnya (mis. Operasi Tulis atau Pengambilan Data) dipancarkan setiap jam, tetapi karena tidak dipancarkan dalam hal jangka waktu, tidak memiliki transformasi unit khusus yang harus diperhatikan.

Diprovisikan/kuota, ukuran logis, dan ukuran fisik

Azure Files melacak tiga jumlah berbeda sehubungan dengan kapasitas berbagi:

• Ukuran atau kuota yang disediakan: Dengan berbagi file yang disediakan dan bayar sesuai penggunaan, Anda menentukan ukuran maksimum yang diizinkan untuk ditumbuhkan oleh berbagi file. Dalam berbagi file yang disediakan, nilai ini disebut ukuran yang disediakan. Berapa pun jumlah yang Anda provisikan adalah apa yang Anda bayar, terlepas dari berapa banyak yang benar-benar Anda gunakan. Dalam berbagi file bayar sesuai penggunaan, nilai ini disebut kuota dan tidak secara langsung memengaruhi tagihan Anda. Ukuran yang disediakan adalah bidang yang diperlukan untuk berbagi file yang disediakan. Untuk berbagi file bayar sesuai penggunaan, jika ukuran yang disediakan tidak ditentukan secara langsung, berbagi akan default 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, di mana pengoptimalan penyimpanan mungkin diterapkan. 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 disediakan dan bayar sesuai penggunaan, ukuran logis total berbagi file digunakan untuk penegakan terhadap ukuran/kuota yang disediakan. 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. Ini mungkin selaras dengan ukuran logis file, atau mungkin lebih kecil, tergantung pada bagaimana file telah ditulis oleh sistem operasi. Alasan umum untuk ukuran logis dan ukuran fisik menjadi berbeda dengan menggunakan file sparse. Ukuran fisik file dalam berbagi digunakan untuk penagihan snapshot, meskipun rentang yang dialokasikan dibagikan di antara snapshot 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. Ini 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 akan muncul pada tagihan Anda berdasarkan 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. Ini mudah dilihat dengan berbagi file prabayar, karena biaya transaksi. Jika layanan bernilai tambah melakukan transaksi terhadap berbagi file atas nama Anda, mereka akan 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 berbagi file yang disediakan dari jumlah layanan bernilai tambah terhadap nomor IOPS yang disediakan, yang berarti bahwa layanan bernilai tambah mungkin memerlukan provisi lebih banyak penyimpanan agar memiliki cukup IOPS atau throughput yang tersedia untuk 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.

Azure File Sync

Azure File Sync adalah layanan bernilai tambah untuk Azure Files yang menyinkronkan satu atau beberapa berbagi file Windows lokal dengan berbagi file Azure. Karena berbagi file Azure cloud memiliki salinan lengkap data dalam berbagi file yang disinkronkan yang tersedia secara lokal, Anda dapat mengubah Windows File Server lokal Anda menjadi cache berbagi file Azure untuk mengurangi jejak lokal 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 adalah agnostik di mana Server File Windows yang disinkronkan dengan Azure Files; mereka dapat dihosting secara lokal, di mesin virtual Azure, 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 Azure Files. Karena Sinkronisasi File Azure adalah solusi sinkronisasi untuk Azure Files, hal ini akan menyebabkan Anda menggunakan 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 standar dengan Sinkronisasi File Azure, meskipun Sinkronisasi File Azure sepenuhnya didukung dengan berbagi premium jika diinginkan.

  • Pemanfaatan penyimpanan. Sinkronisasi File Azure akan mereplikasi perubahan apa pun yang telah Anda buat pada jalur di Server File Windows yang ditentukan di titik akhir server ke berbagi file Azure Anda, sehingga menyebabkan penyimpanan dikonsumsi. 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 premium, perubahan akan menggunakan ruang yang disediakan - Anda bertanggung jawab untuk secara berkala meningkatkan provisi sesuai kebutuhan guna memperhitungkan pertumbuhan berbagi.

  • Pemanfaatan snapshot. Sinkronisasi File Azure mengambil rekam jepret tingkat file dan berbagi sebagai bagian dari penggunaan reguler. Meskipun pemanfaatan snapshot selalu diferensial, hal ini dapat berkontribusi dengan cara yang nyata terhadap total tagihan Azure Files.

  • Transaksi dari churn. Saat file berubah di titik akhir server, perubahan diunggah ke cloud share, yang menghasilkan transaksi. Saat penetapan tingkat cloud diaktifkan, transaksi tambahan dibuat untuk mengelola file berjenjang, termasuk I/O yang terjadi pada file berjenjang, selain biaya keluar. 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 enumerasi cloud. Sinkronisasi File Azure menghitung File Bersama Azure di cloud sehari sekali untuk menemukan perubahan yang dibuat langsung ke file bersama sehingga dapat disinkronkan ke titik akhir 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.

  Tip

  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 hal berikut:

• Biaya lisensi instans yang dilindungi untuk data berbagi file Azure. Azure Backup membebankan biaya lisensi instans yang dilindungi per akun penyimpanan yang berisi berbagi file Azure yang dicadangkan. Instans yang dilindungi didefinisikan sebagai 250 GiB penyimpanan berbagi file Azure. Akun penyimpanan yang berisi kurang dari 250 GiB tunduk pada biaya instans yang dilindungi pecahan. Untuk informasi selengkapnya, lihat Harga Azure Backup. Anda harus memilih Azure Files dari daftar layanan yang dapat dilindungi Azure Backup.

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

  • Biaya diferensial dari snapshot berbagi file Azure. Azure Backup mengotomatiskan pengambilan snapshot berbagi file Azure pada jadwal yang ditentukan administrator. Rekam jepret selalu diferensial; namun, biaya tambahan yang ditambahkan tergantung pada lamanya rekam jepret waktu disimpan dan jumlah churn pada berbagi file selama waktu tersebut. 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. Operasi pemulihan dari snapshot ke berbagi langsung akan menyebabkan transaksi. Untuk berbagi file standar, ini berarti bahwa membaca dari rekam jepret/tulis dari pemulihan ditagih sebagai transaksi berbagi file normal. Untuk berbagi file yang disediakan, operasi ini dihitung terhadap IOPS yang disediakan untuk berbagi file.

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 Pertahanan Microsoft untuk Penyimpanan adalah serangkaian biaya transaksi tambahan yang dipungut produk di atas transaksi yang dilakukan terhadap berbagi file Azure. 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. Pertahanan Microsoft untuk Penyimpanan mengenakan tarif transaksi bahkan pada berbagi file yang disediakan, di mana 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 yang sering bertransaksi akan dikenakan biaya signifikan menggunakan Microsoft Defender for Storage. 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 cadangan) untuk model v1 dan bayar sesuai penggunaan yang disediakan. Reservasi memungkinkan Anda untuk mencapai diskon penyimpanan dengan melakukan pra-penerapan terhadap pemanfaatan penyimpanan. Anda harus mempertimbangkan pembelian instans yang dipesan untuk beban kerja produksi apa pun, atau beban kerja dev/test dengan jejak yang konsisten. Saat membeli Reservasi, Anda harus menentukan dimensi berikut:

• Ukuran kapasitas: Reservasi dapat untuk 10 TiB atau 100 TiB, dengan diskon yang lebih signifikan 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 penyebaran produksi Anda memiliki 120 TiB berbagi file, Anda dapat membeli satu Reservasi 100 TiB dan dua Reservasi 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.
• Tingkat: Tingkat Azure Files untuk Reservasi. Reservasi saat ini tersedia untuk tingkat premium (SSD), panas (HDD), dan dingin (HDD).
• Lokasi: Wilayah Azure untuk Reservasi. Reservasi tersedia di subset wilayah Azure.
• Redundansi: Redundansi penyimpanan untuk Reservasi. Reservasi didukung untuk semua dukungan Redundansi 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 akan secara otomatis digunakan oleh pemanfaatan penyimpanan yang ada. Jika Anda menggunakan lebih banyak penyimpanan daripada yang telah Dipesan, Anda akan membayar harga daftar untuk saldo yang tidak dicakup oleh Reservasi. Biaya transaksi, bandwidth, transfer data, dan penyimpanan metadata tidak termasuk dalam Reservasi.

Ada perbedaan dalam cara kerja Reservasi dengan rekam jepret berbagi file Azure untuk berbagi file v1 prabayar dan yang disediakan. Jika Anda mengambil rekam jepret berbagi file prabayar, maka diferensial rekam jepret dihitung terhadap Reservasi dan ditagih sebagai bagian dari pengukur penyimpanan normal yang digunakan. Namun, jika Anda mengambil rekam jepret berbagi file v1 yang disediakan, rekam jepret 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

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