Memahami model biaya Azure NetApp Files

Untuk mengelola pengeluaran Anda untuk Azure NetApp Files, Anda perlu memahami model biayanya, termasuk kapasitas, harga, dan konsep penagihan yang efektif.

Overview

Azure NetApp Files menetapkan harga penyimpanan berdasarkan kapasitas yang diprovisikan dan performa yang diprovisikan. Anda mengalokasikan kapasitas melalui kumpulan kapasitas dan menggunakannya melalui volume. Anda menghadirkan kinerja baik sebagai throughput yang sebanding dengan kapasitas yang disediakan (tingkat layanan Standard, Premium, Ultra) maupun sebagai throughput yang disediakan secara terpisah dari kapasitas (tingkat layanan Flexible). Layanan mencatat seluruh penggunaan per jam dan menerbitkan tagihan setiap bulan, sehingga dapat dengan cepat merespons penyesuaian ukuran dinamis dan perubahan tingkat layanan secara dinamis.

Artikel ini menjelaskan model penagihan, hubungan antara kapasitas dan kinerja, kemampuan yang menurunkan harga efektif, serta fitur tambahan berbayar seperti pencadangan Azure NetApp Files dan replikasi lintas wilayah (CRR) yang menambahkan komponen penagihan tambahan. Ini juga mencakup contoh terperinci yang menunjukkan bagaimana kemampuan-kemampuan ini saling memperkuat untuk meningkatkan kapasitas efektif dan penetapan harga yang efektif.

Dasar-dasar penagihan

Pool kapasitas – penagihan kapasitas yang diprovisikan

Azure NetApp Files menagihkan biaya berdasarkan kombinasi throughput dan kapasitas penyimpanan yang diprovisikan, bukan berdasarkan jumlah data yang disimpan. Anda membeli kapasitas dan throughput melalui kumpulan kapasitas, yang merupakan unit utama penagihan. Anda mengalokasikan volume dari kumpulan tersebut. Anda dikenakan biaya berdasarkan tingkat layanan untuk ukuran pool yang diprovisikan, terlepas dari seberapa besar kapasitas tersebut yang Anda alokasikan ke volume.

Karena penagihan mengikuti provisi, keputusan ukuran awal, dan perubahan dinamis dari waktu ke waktu secara langsung menentukan biaya. Anda harus mengukur volume dan kumpulan kapasitas agar sesuai dengan kapasitas dan performa yang diperlukan beban kerja. Terus mempertimbangkan perubahan dinamis untuk menyesuaikan keseimbangan yang tepat antara kapasitas, performa, dan biaya.

Pengukuran per jam, penagihan bulanan

Layanan ini mengukur alokasi kumpulan kapasitas setiap jam. Setiap jam, layanan mencatat ukuran kumpulan, tingkat layanan, dan – untuk tingkat layanan Fleksibel – throughput yang disediakan berlaku pada jam tersebut. Tagihan Azure bulanan mengumpulkan pembacaan per jam.

Penagihan per jam adalah dasar optimalisasi biaya di Azure NetApp Files. Setiap perubahan yang diterapkan selama periode penagihan—mengubah ukuran pool atau volume, mengubah tingkat layanan, atau menyesuaikan throughput tingkat layanan Fleksibel—akan tercermin pada pengukuran per jam berikutnya. Anda dapat terus menyesuaikan ukuran volume, kumpulan kapasitas, dan beban kerja tanpa memaksa komitmen jangka panjang pada kumpulan kapasitas yang mendasarinya.

Important

Biaya sama dengan integral kapasitas yang disediakan – dan untuk tingkat layanan Fleksibel, throughput yang disediakan – dari waktu ke waktu. Menurunkan salah satu nilai kapan saja selama bulan mengurangi tagihan dari jam tersebut ke depan.

Kumpulan kapasitas dan volume

Seperti yang disebutkan sebelumnya, kumpulan kapasitas adalah unit utama untuk penyediaan dan penagihan. Volume adalah unit konsumsi.

Aturan penentuan ukuran

Kumpulan kapasitas: Kumpulan kapasitas memiliki ukuran minimum 1 TiB. Anda dapat mengubah ukurannya dalam kenaikan 1 TiB hingga ukuran kumpulan kapasitas maksimum 2.048 TiB. Anda juga dapat mengubah ukuran dalam pengurangan 1 TiB hingga mencapai kapasitas yang dialokasikan untuk volume-volume di kumpulan kapasitas.
Volume: Anda dapat mengukur volume reguler dari 50 GiB hingga 100 TiB. Volume besar mendukung hingga 2 PiB, atau 7,2 PiB untuk volume ekstra besar dengan akses dingin diaktifkan.
Volume memiliki baik kuota kapasitas maupun kuota throughput. QoS otomatis menetapkan kuota throughput secara otomatis berdasarkan kuota kapasitas. QoS manual menetapkan kuota throughput secara independen. Kuota kapasitas dikurangi dari ukuran kumpulan induk yang disediakan. Jumlah kuota kapasitas volume dalam kumpulan tidak boleh melebihi ukuran kumpulan. Aturan ini juga berlaku untuk throughput yang diprovisikan dalam kaitannya dengan kuota throughput.

Perhitungan kapasitas dan throughput

Untuk volume, Anda mengukur konsumsi kapasitas terhadap kuota berdasarkan kapasitas logis, jumlah data sistem file aktif, dan data rekam jepret. Pool kapasitas itu sendiri ditagihkan berdasarkan kapasitas yang diprovisikan, terlepas dari seberapa besar kapasitas volume yang dialokasikan atau seberapa banyak data yang ditulis dalam volume di pool kapasitas host.

Anda memperhitungkan throughput pada tingkat volume terhadap kuota throughput kumpulan kapasitas. Dengan QoS otomatis, kuota diskalakan secara linier dengan alokasi kapasitas volume. Dengan QoS manual, Anda mengatur kuota secara independen. Dalam pool tingkat layanan Fleksibel, total kuota throughput volume tidak boleh melebihi throughput yang diprovisikan pada pool. Throughput yang disediakan untuk kumpulan menentukan komponen throughput pada tagihan.

Bagaimana throughput disediakan dan ditagihkan

Anda menyediakan throughput dalam Azure NetApp Files melalui tingkat layanan kumpulan kapasitas. Dua model tersedia.

Tingkat layanan linier: Standar, Premium, Ultra

Tingkat layanan Standar, Premium, dan Ultra menyediakan throughput dalam proporsi tetap dengan kapasitas yang disediakan. Setiap TiB kapasitas pool memiliki alokasi throughput tertentu, sehingga total throughput meningkat secara linear seiring dengan ukuran pool. Anda membayar satu tarif per GiB-jam yang bergantung pada tingkat layanan: Standard memiliki tarif terendah dan throughput terendah per TiB, sedangkan Ultra memiliki yang tertinggi.

Tingkat layanan ini sesuai dengan beban kerja di mana performa yang diperlukan diskalakan dengan ukuran himpunan data, dan di mana kesederhanaan operasional dimensi berbasis kapasitas tunggal lebih disukai.

Tingkat layanan	Throughput per TiB	Bagaimana throughput disediakan	Cara penagihan throughput
Standard	16 MiB/detik	Sebanding dengan kapasitas pool	Termasuk dalam tarif kapasitas (GiB-jam)
Premium	64 MiB/s	Sebanding dengan kapasitas pool	Termasuk dalam tarif kapasitas (GiB-jam)
Ultra	128 MiB/detik	Sebanding dengan kapasitas pool	Termasuk dalam tarif kapasitas (GiB-jam)
Flexibel	0-640 MiB/dtk (dapat dikonfigurasi secara independen)	Disediakan secara terpisah dari kapasitas	Add-on Throughput (MiB/s-jam)

Tingkat layanan yang fleksibel

Tingkat layanan Fleksibel memisahkan throughput dari kapasitas. Anda menyediakan kumpulan kapasitas tingkat layanan Fleksibel dengan kapasitas yang dipilih dan throughput yang dipilih secara terpisah. Pool ini mencakup alokasi throughput dasar sebesar 128 MiB/dtk, dan Anda dapat menambahkan throughput tambahan dalam penambahan 1 MiB/dtk tanpa mengubah kapasitas pool (dengan maksimum 640 MiB/dtk per TiB).

Penagihan untuk pool tingkat layanan Fleksibel terdiri dari dua komponen: biaya per GiB-jam untuk kapasitas yang disediakan, serta biaya per MiB/s-jam untuk throughput yang disediakan di atas nilai dasar. Anda dapat menyesuaikan kapasitas dan throughput secara independen kapan saja, dan pengukuran per jam berikutnya menangkap nilai yang diperbarui.

Tingkat layanan Fleksibel sesuai dengan beban kerja di mana rasio throughput terhadap kapasitas tidak selaras dengan rasio tetap tingkat layanan linier - misalnya, himpunan data kecil yang membutuhkan throughput tinggi, atau himpunan data besar yang hanya memerlukan throughput sederhana.

Memilih tingkat layanan

Standard, Premium, Ultra: Gunakan saat kebutuhan throughput meningkat secara terprediksi seiring volume data dan satu dimensi kapasitas menyederhanakan operasional.
Fleksibel: Gunakan saat kebutuhan kapasitas dan throughput berubah secara independen, saat menyediakan kapasitas berlebih pada satu dimensi demi memperoleh dimensi lainnya akan menjadi pemborosan, atau saat kapasitas dan kinerja harus disetel secara terpisah selama siklus hidup beban kerja.

Konsumsi kapasitas

Kapasitas logis dan fisik

Kapasitas logis adalah jumlah data yang disajikan dalam data sistem file aktif, ditambah data delta yang disimpan dalam rekam jepret. Kapasitas fisik adalah jumlah penyimpanan yang ditempati pada sistem.

Rekam jepret dan klon jangka pendek memungkinkan kapasitas logis melebihi kapasitas fisik, karena blok data umum dibagikan daripada diduplikasi.

Alokasi kapasitas dan konsumsi rekam jepret

Snapshot menggunakan kapasitas dari kuota volume induk dan oleh karena itu tidak dialokasikan maupun ditagih secara terpisah. Snapshot bersifat diferensial pada tingkat blok: penggunaan fisik volume hanya mencakup blok yang ada dalam satu atau beberapa snapshot ditambah blok yang berubah dalam filesystem aktif.

Contoh: volume 100 TiB memiliki konsumsi sistem file aktif 80 TiB dan dua rekam jepret yang menyimpan 10 TiB data diferensial. Konsumsi logis pada volume adalah 80 TiB data aktif dan dua snapshot yang masing-masing menghadirkan tampilan point-in-time penuh sebesar 80 TiB, sehingga total tampilan logisnya menjadi 240 TiB. Namun, konsumsi fisik yang dialokasikan ke kuota volume hanya 90 TiB, bukan 240 TiB.

Sebagai panduan umum dalam perencanaan, cadangan kapasitas 20 persen cukup untuk menyimpan snapshot setidaknya selama seminggu untuk banyak beban kerja. Kapasitas rekam jepret aktual tergantung pada retensi rekam jepret dan tingkat perubahan tingkat blok harian.

Alokasi kapasitas dan konsumsi klon jangka pendek

Klon jangka pendek mirip dengan rekam jepret karena awalnya mereka berbagi blok yang tidak berubah dengan volume induk, tetapi berbeda dengan dua cara penting: kloning jangka pendek dapat ditulis, dan dibuat dengan kuota volume dan alokasi performanya sendiri. Blok bersama yang diwarisi dari rekam jepret sumber tidak memerlukan salinan lengkap himpunan data kedua. Sebaliknya, kuota klon berfungsi sebagai kapasitas penyangga penulisan untuk blok yang berubah setelah klon dibuat. Di kumpulan QoS otomatis, throughput kloning ditentukan oleh kuota yang ditetapkan ke kloning; dalam kumpulan QoS manual, throughput ditetapkan secara independen. Akibatnya, menentukan ukuran klon jangka pendek bukan berarti menduplikasi ukuran logis penuh volume induk, melainkan mengalokasikan kapasitas dan kinerja yang memadai untuk workload penulisan yang diperkirakan selama masa aktif klon.

Perhitungan kuota dalam kumpulan kapasitas

Pertimbangkan kumpulan kapasitas dengan 12 TiB yang disediakan, berisi tiga volume:

Volume A: Kuota 5 TiB, 4,5 TiB yang digunakan (4 TiB aktif, 500 GiB rekam jepret); 500 GiB gratis.
Volume B: Kuota 3 TiB, 2,5 TiB yang dikonsumsi (2,5 TiB aktif); 500 GiB gratis.
Volume C: Kuota 2 TiB, terpakai sepenuhnya (1,5 TiB aktif, 500 GiB buffer klon sementara).

Pool ditagih untuk 12 TiB yang diprovisikan. Dari itu, 10 TiB dialokasikan untuk kuota volume, 9 TiB dikonsumsi, dan 8 TiB dalam penggunaan aktif. 1 TiB tetap gratis dalam kuota, dan 2 TiB yang tersisa tidak dialokasikan.

Diagram ini menunjukkan bagaimana pool kapasitas 12 TiB dibagi ke dalam tiga volume ditambah cadangan kapasitas yang belum dialokasikan, yang dirinci berdasarkan ruang yang dialokasikan, terpakai, kosong, dan belum dialokasikan.

Lima lapisan kapasitas

Lapisan	Apa fungsinya	Jumlah
Dialokasikan	Kapasitas yang dialokasikan ke volume melalui kuota (Vol A: 5 + Vol B: 3 + Vol C: 2).	10 TiB
Digunakan	Ruang yang benar-benar digunakan di dalam setiap kuota - data aktif ditambah rekam jepret/kloning.	9 TiB
Active	Data sistem berkas aktif saat ini sedang digunakan.	8 TiB
Free	Ruang yang tidak digunakan dalam volume (500 GiB di Vol A + 500 GiB di Vol B; Vol C penuh).	1 TiB (Tebibyte)
Tidak dialokasikan	Kapasitas kumpulan tidak ditetapkan ke volume apa pun - tersedia untuk menumbuhkan atau membuat volume baru.	2 TiB

Memahami bayangan warna

Nuansa warna	Apa yang diwakilinya
Gelap	Data aktif yang sedang digunakan.
Medium	Rekam jepret, dicadangkan atau digunakan (Vol A), atau buffer klon jangka pendek (Vol C).
Light	Ruang kosong tersedia dalam volume.
Gray	Ruang pool tidak dialokasikan ke volume mana pun.

Rincian per volume

Volume	Kuota (Dialokasikan)	Digunakan	Active	Snapshot / Klon	Free
Volume A	5 TiB	4.5 TiB	4 TiB	snapshot 500 GiB	500 GiB
Volume B	3 TiB	2.5 TiB	2.5 TiB	—	500 GiB
Volume C	2 TiB	2 TiB	1,5 TiB	Buffer kloning 500 GiB	0 (penuh)
Tidak dialokasikan	—	—	—	—	2 TiB

Intinya: dari pool 12 TiB, 9 TiB sudah terpakai, 1 TiB masih tersedia dalam kuota, dan 2 TiB masih belum dialokasikan - sekitar 3 TiB total kapasitas cadangan sebelum pool penuh.

Penyesuaian ukuran yang tepat secara dinamis

Karena Azure NetApp Files diukur per jam, Azure NetApp Files mendukung kapasitas berkelanjutan, throughput, dan penyeimbangan biaya melalui tiga penyesuaian dinamis. Setiap penyesuaian berlaku pada batas penagihan per jam berikutnya.

Mengubah ukuran kapasitas dinamis

Anda dapat mengubah ukuran kumpulan kapasitas dan volume di tempat tanpa waktu henti. Saat kebutuhan kapasitas berubah, sesuaikan pool sesuai kebutuhan. Penagihan mencerminkan ukuran baru yang disediakan pada pembacaan meteran per jam berikutnya. Fitur ini memungkinkan beban kerja dengan periode puncak singkat untuk diukur untuk periode tersebut alih-alih disediakan pada puncak selama sebulan penuh.

Perubahan tingkat layanan dinamis

Anda dapat mengubah volume antara kumpulan tingkat layanan Standar, Premium, dan Ultra untuk mengubah throughput yang tersedia untuknya. Penagihan didasarkan pada tingkat layanan yang berlaku pada setiap jam, sehingga beban kerja yang memerlukan kinerja Ultra hanya selama periode batch berkala dapat kembali ke Standar atau Premium di luar periode tersebut.

Penyesuaian throughput dinamis (tingkat layanan fleksibel)

Pool kapasitas tingkat layanan yang fleksibel mendukung penyesuaian throughput secara independen. Anda dapat menaikkan throughput sebelum fase performa tinggi dan menurunkannya setelah itu, tanpa mengubah ukuran kapasitas. Anda dapat meningkatkan kapasitas sebelum fase pertumbuhan data dan menurunkannya setelahnya, tanpa mengubah throughput.

Tip

Penagihan per jam menghilangkan dilema antara menyediakan kapasitas untuk beban puncak dan membayar kapasitas yang menganggur. Profil provisi beban kerja selama sebulan adalah fungsi langkah per jam. Jumlah tagihan merupakan integral dari fungsi tersebut, bukan nilai maksimumnya.

Kemampuan pengoptimalan biaya bawaan

Azure NetApp Files mencakup kemampuan yang menurunkan biaya penyimpanan dengan mengurangi tarif yang dibayarkan per GiB/jam, dengan mengurangi kapasitas yang harus Anda provisikan, atau dengan menyelaraskan sumber daya yang disediakan dengan permintaan aktual. Kapabilitas ini bersifat independen dan efeknya saling menguatkan saat digunakan bersama.

Penyimpanan dengan akses sejuk (pelapisan data transparan)

Penyimpanan Azure NetApp Files dengan kemampuan akses cool memindahkan blok data yang jarang diakses dari kumpulan kapasitas ke Azure Storage berbiaya lebih rendah. Masa tunggu (antara 2 hingga 183 hari) menentukan berapa lama sebuah blok harus tetap tidak diakses sebelum dipindahkan ke tier lain. Operasi baca pada data bertingkat berlangsung secara transparan, dan blok yang terdampak dikembalikan ke tier panas Azure NetApp Files, bergantung pada pola akses.

Setiap tingkat layanan mendukung penyimpanan dengan akses dingin. Profil performa untuk blok aktif tidak terpengaruh. Untuk penyimpanan dengan akses dingin, data di tingkat dingin ditagih secara terpisah, tidak dihitung terhadap penyediaan kumpulan kapasitas tingkat panas, dan tidak tercakup oleh kapasitas yang dipesan.

Kapasitas yang dicadangkan

Kapasitas terpesan adalah komitmen atas sejumlah kapasitas Azure NetApp Files yang telah ditentukan. Reservasi memberikan diskon pada tarif per GiB untuk kapasitas yang tercakup dalam reservasi. Anda membayar tarif sesuai pemakaian untuk penggunaan yang melebihi reservasi.

Anda dapat menggabungkan reservasi di berbagai tingkat layanan, tetapi reservasi tersebut tidak dapat digabungkan dengan skema diskon tingkat yang lebih tinggi seperti MACC.

Dalam Azure NetApp Files, penyimpanan dengan reservasi akses dingin mencakup kapasitas yang disediakan di kumpulan kapasitas. Hal tersebut tidak berlaku untuk data yang disimpan di tier akses cool, yang sudah ditagih dengan tarif tier cool yang lebih rendah.

Rekam jepret hemat ruang dan klon jangka pendek

Snapshot bersifat hanya-baca, dan klon jangka pendek merupakan salinan virtual volume pada titik waktu tertentu yang dapat dibaca dan ditulis. Karena hanya blok yang diubah yang disimpan, kapasitas fisik yang dikonsumsi oleh rekam jepret dan klon jangka pendek biasanya merupakan sebagian kecil dari ukuran volume yang dialokasikan.

Rekam jepret dan klon jangka pendek mengurangi biaya dengan dua cara. Pertama, mereka menghapus kebutuhan untuk menyediakan volume terpisah untuk menyimpan salinan historis untuk pemulihan jangka pendek atau membuat salinan volume penuh untuk skenario pengujian dan pengembangan siklus pendek. Kedua, mereka meningkatkan kapasitas logis yang diwakili oleh sejumlah kapasitas yang disediakan, yang pada gilirannya menurunkan biaya per GiB dari data fisik aktual yang disimpan.

Rekam jepret adalah mekanisme utama untuk pemulihan data cepat dalam Azure NetApp Files. Mereka tidak menggantikan cadangan. Untuk penyimpanan jangka panjang, perlindungan terhadap penghapusan volume yang tidak disengaja, dan ketahanan terhadap kegagalan, padukan snapshot dengan backup Azure NetApp Files.

Rekam jepret meningkatkan kapasitas efektif dengan berbagi blok data yang tidak berubah dengan volume aktif.

Klon jangka pendek adalah volume yang dapat ditulis yang dibuat dari snapshot. Kloning berbagi blok umum dengan induknya dan mengonsumsi penyimpanan fisik hanya untuk blok baru atau yang dimodifikasi dalam volume kloning, dan independen dari volume induk.

Klon jangka pendek menghilangkan kebutuhan untuk menyediakan salinan penuh untuk pengembangan, pengujian, analitik, atau beban kerja forensik ketika himpunan data sumber besar, tetapi kumpulan kerja tulis yang diharapkan kecil. Di estimator, Anda dapat memperkirakan kebutuhan ini dengan menggunakan tingkat perubahan harian snapshot untuk ruang buffer tulis klon.

Misalnya, jika rekam jepret menggunakan tingkat perubahan harian 3 persen dan perkiraan ruang buffer tulis adalah 5 persen, estimator dapat menggunakan tingkat perubahan gabungan 8 persen. Pendekatan ini menyediakan cara praktis untuk memodelkan kapasitas terkait kloning tanpa mengukur kloning sebagai salinan kedua penuh.

Contoh estimasi klon jangka pendek ilustrasi. Gunakan laju perubahan snapshot dan buffer penulisan klon secara bersama untuk memperkirakan kapasitas klon jangka pendek pada estimator.

Klon jangka pendek hanya menggunakan penyimpanan fisik untuk blok yang menyimpang dari induknya.

Tingkat layanan fleksibel sebagai tuas efisiensi biaya

Ketika persyaratan throughput dan persyaratan kapasitas tidak cocok dengan rasio tetap tingkat layanan linier, tingkat layanan fleksibel menghapus dimensi yang terlalu provisi dari tagihan. Manfaat ini paling terasa pada beban kerja dengan throughput tinggi dan kapasitas rendah, serta pada beban kerja dengan kapasitas tinggi dan throughput rendah, seperti salinan pemulihan bencana dan arsip.

Pertimbangkan contoh beban kerja yang hanya memerlukan kapasitas 1 TiB dengan throughput 512 MiB/s, lalu lihat perbedaannya antara kumpulan kapasitas yang dikonfigurasi dengan tingkat layanan Ultra dan fleksibel. Perbedaan ini adalah contoh biaya dari beban kerja dengan throughput tinggi dan kapasitas rendah.

Option	Kapasitas	Throughput	Biaya bulanan
Tingkat layanan ultra	4 TiB	512 MiB/detik	$1.609
Tingkat layanan yang fleksibel	1 TiB (Tebibyte)	512 MiB/detik	$976

Penghematan ilustratif: 39%

Sebaliknya, pertimbangkan contoh beban kerja yang memerlukan kapasitas 550 TiB hanya dengan throughput 128 MiB/dtk dan lihat perbedaan antara kumpulan kapasitas yang disediakan dengan tingkat layanan Standar dan fleksibel. Perbedaan ini adalah contoh biaya dari beban kerja dengan throughput rendah dan kapasitas tinggi.

Option	Kapasitas	Throughput	Biaya bulanan
Tingkat layanan standar	550 TiB	128 MiB/detik	Lihat contoh harga
Tingkat layanan yang fleksibel	550 TiB	Nilai dasar 128 MiB/dtk	Biaya lebih rendah dari Standar

Penghematan ilustratif: 25%

Perbedaan ini adalah contoh biaya dari beban kerja dengan throughput rendah dan kapasitas tinggi.

Kumpulan kapasitas tingkat layanan fleksibel mendukung akses dingin, rekam jepret, klon jangka pendek, replikasi, dan pencadangan. Tak satu pun dari kemampuan ini terbatas hanya pada tingkat layanan fleksibel.

Fitur add-on berbayar

Di luar unit penagihan kumpulan kapasitas utama, Azure NetApp Files menawarkan fitur add-on berbayar. Setiap fitur ditagih secara terpisah dari penyediaan kumpulan kapasitas dan menambahkan item tagihan tersendiri pada tagihan bulanan.

pencadangan Azure NetApp Files

Cadangan Azure NetApp Files menyimpan cuplikan volume di penyimpanan Azure di luar volume, sehingga memberikan penyimpanan jangka panjang dan perlindungan terhadap penghapusan volume yang tidak disengaja. Penagihan backup memiliki dua komponen: tarif per GiB-bulan untuk penyimpanan backup vault yang terpakai (setelah baseline lengkap pertama, hanya blok yang berubah yang disimpan), dan tarif per GiB untuk operasi pemulihan. Karena hanya blok diferensial yang dipertahankan setelah garis besar awal, pertumbuhan penyimpanan cadangan yang sedang berlangsung melacak tingkat perubahan rekam jepret daripada ukuran logis penuhnya di tingkat file.

Replikasi lintas wilayah (CRR)

Replikasi lintas wilayah secara asinkron mereplikasi volume sumber ke volume tujuan di wilayah Azure lain untuk pemulihan bencana. Volume tujuan disediakan dalam kumpulan kapasitas di wilayah tujuan dan ditagih dengan tarif normal kumpulan tersebut. Selain itu, transfer data yang direplikasi antar wilayah diukur dan ditagih dengan tarif transfer per GiB. Jadwal replikasi (10 menit, per jam, harian) dan tingkat perubahan memengaruhi jumlah data yang diubah yang ditransfer tetapi tidak memengaruhi biaya kapasitas tujuan, yang mengikuti ukuran kumpulan tujuan yang disediakan. Untuk mengoptimalkan biaya untuk data pemulihan bencana yang tidak aktif, volume tujuan yang disediakan dengan tingkat layanan Flexible dapat dikonfigurasi pada laju throughput dasar 128 MiB/dtk, sehingga meminimalkan biaya saat replika tidak menangani lalu lintas produksi.

Kapasitas efektif dan konsep harga efektif

Kapasitas efektif

Kapasitas efektif adalah total data logis yang dapat diakses relatif terhadap kapasitas yang disediakan. Rekam jepret meningkatkan kapasitas efektif dengan mempertahankan tampilan titik waktu, dan klon jangka pendek memperluas manfaat tersebut dengan menyediakan salinan virtual yang dapat ditulis yang hanya mengonsumsi blok diferensial.

Contoh: volume 50 TiB yang terpakai sepenuhnya dengan empat snapshot yang menggunakan total 5 TiB ruang snapshot memiliki kapasitas logis 250 TiB (filesystem aktif ditambah empat tampilan pada titik waktu tertentu), sementara kapasitas yang diprovisikan dan terpakai hanyalah 55 TiB.

Harga efektif

Konsep harga efektif adalah biaya per GiB data logis setelah memperhitungkan penjenjangan, reservasi, peningkatan kapasitas efektif, dan diskon yang dinegosiasikan.

Tip

Harga efektif per GiB = (total biaya ÷ kapasitas efektif di GiB) − diskon yang berlaku

Kemampuan ini menurunkan harga efektif dengan dua cara: mereka mengurangi biaya keseluruhan yang Anda bayar, dan/atau meningkatkan jumlah data yang dapat digunakan yang Anda dapatkan dari kapasitas yang disediakan yang sama. Reservasi dan akses dingin membantu menurunkan biaya, sementara rekam jepret, klon jangka pendek, dan ukuran yang tepat tingkat layanan Fleksibel membantu Anda mendapatkan nilai lebih dari kapasitas yang Anda provisikan.

Harga efektif mencerminkan diskon dan peningkatan kapasitas yang didorong oleh kapabilitas yang diterapkan pada tarif daftar.

Contoh pemodelan biaya

Harga dalam contoh menggunakan tarif perwakilan dan bergantung pada wilayah. Lihat halaman harga Azure NetApp Files untuk tarif saat ini di wilayah Anda.

Contoh 1: Pengubahan ukuran kapasitas secara dinamis

Beban kerja menggunakan kumpulan kapasitas Premium dengan profil bulanan berikut: 24 jam pada 10 TiB, 96 jam pada 24 TiB, 24 jam pada 5 TiB, 480 jam pada 6 TiB, dan sisanya pada 0 TiB. Anda membayar $0,000403 per GiB-jam untuk kapasitas.

Scenario	Kalkulasi	Biaya bulanan
Provisi statis pada puncak	24 TiB × 720 jam × $0,000403 per GiB-jam	$7.130,97
Penyediaan sumber daya dinamis	10 TiB × 24 jam + 24 TiB × 96 jam + 6 TiB × 480 jam seharga $0,000403 per GiB-jam	$2.238,33

Penghematan: $4.892,64 per bulan (69%)

Contoh 2: Perubahan tingkat layanan dinamis

Kapasitas konstan pada 24 TiB. Persyaratan performa bervariasi: 384 jam pada Standar ($ 0,000202 per jam GiB), 120 jam pada Premium ($ 0,000403), 168 jam di Ultra ($ 0,000538), dan 48 jam kembali di Standar.

Scenario	Kalkulasi	Biaya bulanan
Penyediaan statis untuk beban puncak	24 TiB × 720 jam × $0,000538 per GiB-jam	$9.519,76
Perubahan tingkat layanan dinamis	Standar 432h + Premium 120h + Ultra 168h pada tarif per jam yang dinyatakan	$5.549,38

Penghematan: $3.970,38 per bulan (42%)

Contoh 3: Penyimpanan dengan akses dan reservasi dingin

Organisasi memiliki 550 TiB data berbagi file pada kumpulan kapasitas Standar. Harga daftar adalah $0,147 per GiB-bulan. Diperkirakan 80 persen data (440 TiB) dialokasikan ke tingkat cool dengan biaya $0,059 per GiB-bulan. 110 TiB tetap berada di tingkat panas. Reservasi tingkat layanan Standar 100 TiB dan 1 tahun (diskon 18%) mencakup sebagian dari tingkat panas.

Scenario	Kalkulasi	Biaya bulanan
Base	550 TiB × $0,147 per GiB-bulan	$83.049
Dengan penyimpanan dengan akses dingin	110 TiB panas × $ 0,147 + 440 TiB dingin × $ 0,059	$44.031
Dengan akses dingin + kapasitas yang dipesan	Tier hot setelah diskon 18% untuk kapasitas setara 100 TiB + tier cool tidak berubah	$41.041

Harga efektif turun dari $0,147 menjadi $0,073 per bulan GiB (sekitar 50% lebih rendah dari dasar).

Contoh 4: Snapshot

Volume Premium 110 TiB menyimpan tiga snapshot harian. Tingkat perubahan harian adalah 3%. Harga daftar premium adalah $0,294 per GiB-bulan.

Scenario	Kapasitas	Biaya bulanan
Kasus dasar	Volume Premium 110 TiB	$33.138

Kasus dasar: Volume Premium 110 TiB tanpa rekam jepret.

Dengan rekam jepret harian:

Tiga rekam jepret harian pada tingkat perubahan 3% menambahkan sekitar 10 TiB data diferensial
Total kapasitas yang dikonsumsi adalah sekitar 120 TiB
Jejak penyimpanan logis adalah 440 TiB (set data aktif ditambah tiga salinan point-in-time yang dapat dipulihkan)
Harga efektif turun menjadi sekitar $0,080 per GiB data yang dapat diakses, atau sekitar 73% dari harga daftar untuk kapasitas yang dapat dipulihkan yang sama

Metrik	Dengan rekam jepret harian
Kapasitas diferensial ditambahkan	Sekitar 10 TiB
Total kapasitas yang dikonsumsi	Sekitar 120 TiB
Jejak logis	440 TiB
Harga efektif	Sekitar US$0,080/GiB untuk data yang dapat diakses

Dengan snapshot harian: kapasitas efektif meningkat empat kali lipat dengan tambahan biaya fisik yang minim.

Contoh 5: Klon jangka pendek

Volume sumber tingkat layanan Premium 50 TiB digunakan untuk membuat klon jangka pendek untuk pengujian dan analitik. Set kerja tulis yang diharapkan pada clone adalah 5 TiB. Harga daftar premium adalah $0,294 per GiB-bulan.

Scenario	Kapasitas yang disediakan	Biaya bulanan
salinan konvensional yang dapat ditulisi	50 TiB Premium	$15.063

Dengan kloning jangka pendek:

Kapasitas yang disediakan adalah 5 TiB alih-alih 50 TiB, hanya berukuran untuk set kerja tulis 5 TiB yang diharapkan
5 TiB × 1024 GiB/TiB × $0,294 = $1.506 per bulan, pengurangan sekitar 90%

Scenario	Kapasitas yang disediakan	Biaya bulanan
Klon jangka pendek	5 TiB Premium	$1.506

Perkiraan pengurangan: 90%

Dengan kloning jangka pendek, himpunan data sumber tetap dibagikan sementara kapasitas hanya disediakan untuk kumpulan kerja tulis yang diharapkan.

Contoh 6: Tingkat layanan fleksibel selaras dengan beban kerja

Empat beban kerja, masing-masing membandingkan tingkat layanan linier yang disediakan untuk memenuhi throughput puncak dengan konfigurasi tingkat layanan Flexible yang disesuaikan dengan kebutuhan throughput aktual dan kapasitas.

Beban Kerja	Penyediaan linier	Biaya / bulan	Konfigurasi fleksibel	Biaya / bulan	Menyimpan
Analitik (data kecil, I/O tinggi)	4 TiB Ultra (untuk 512 MiB/dtk)	$1.609	1 TiB fleksibel dengan 512 MiB/detik	$976	39%
Simulasi EDA (I/O yang sangat tinggi)	36 TiB Ultra (untuk ~4.500 MiB/dtk)	$14.478	7 TiB Fleksibel dengan 4.480 MiB/dtk	$10.582	27%
DB (besar, I/O cukup tinggi)	100 TiB Premium (untuk 6.400 MiB/dtk)	$30,125	Kapasitas fleksibel 75 TiB dengan 6.400 MiB/s	$22.577	25%
Pemulihan bencana (besar, I/O rendah)	Standar 175 TiB (performa yang tidak digunakan)	$26.425	175 TiB Fleksibel pada garis besar 128 MiB/dtk	$19.753	25%

Dalam setiap kasus, tingkat layanan Fleksibel menghilangkan dimensi yang diprovisikan secara berlebihan dari tagihan. Di mana beban kerja membutuhkan throughput tinggi pada himpunan data kecil, kapasitas berkurang. Jika beban kerja memerlukan kapasitas besar dengan laju pemrosesan rendah, laju pemrosesan dikurangi ke tingkat dasar.

Menggabungkan konsep kapasitas efektif dan harga efektif

Dataset 110 TiB menggunakan tiga snapshot harian dengan tingkat perubahan harian 3% serta klon jangka pendek yang berukuran dengan buffer tulis 5% untuk pengujian dan analisis. Dari himpunan data utama, 80% memenuhi syarat untuk penyimpanan dengan akses dingin. Tingkat hot tetap pada tingkat layanan Premium, dengan reservasi 100 TiB yang mencakup sebagian besar kapasitas yang diprovisikan tersebut. Salinan pemulihan bencana dihost pada tingkat layanan Flexible dengan baseline 128 MiB/dtk untuk menjaga biaya replikasi saat idle tetap rendah.

Dasar:

Beban kerja utama: penyimpanan Premium sebesar 110 TiB.
Salinan sementara yang dapat ditulisi: dialokasikan sebagai volume Premium kedua berkapasitas 110 TiB.
Tujuan pemulihan bencana: disediakan sebagai volume Premium 110 TiB di wilayah tujuan.
Total kapasitas Premium yang disediakan: 330 TiB sebelum rekam jepret dan biaya transfer replikasi.
Biaya penyimpanan bulanan: sekitar $99.414 seharga $0,294 per GiB-bulan.
Harga efektif: tetap pada harga daftar karena setiap salinan tambahan dialokasikan sebagai duplikat yang nyaris penuh.

Component	Kapasitas yang disediakan	Biaya bulanan
Beban kerja utama	110 TiB Premium	Disertakan di bawah ini
Salinan bisa-tulis sementara	110 TiB Premium	Disertakan di bawah ini
Tujuan pemulihan bencana	110 TiB Premium	Disertakan di bawah ini

Total kapasitas Premium yang disediakan: 330 TiB | Biaya penyimpanan bulanan: sekitar $99.414

Dengan optimasi gabungan:

Tingkat Hot: 22 TiB Premium setelah tiering; biaya bulanan sekitar $8.870.
Tingkat cool: 88 TiB dengan akses cool; biaya bulanan sekitar $5.304.
Kapasitas terpesan: Reservasi 100 TiB mencakup sebagian besar kapasitas Premium tingkat panas
Rekam jepret: Tiga rekam jepret harian pada tingkat perubahan 3 persen menambahkan sekitar 10 TiB kapasitas diferensial.
Tapak logis: meningkat dari 110 TiB menjadi sekitar 440 TiB.
Kapasitas yang dikonsumsi: naik menjadi hanya sekitar 120 TiB.
Klon jangka pendek: buffer tulis 5 persen, bukan volume penuh kedua sebesar 110 TiB; biaya bulanan sekitar US$1.506.
Salinan untuk pemulihan bencana: Tingkat layanan yang fleksibel dengan garis dasar 128 MiB/dtk menjaga biaya saat tidak digunakan tetap rendah.

Komponen pengoptimalan	Result	Biaya/dampak bulanan
Kategori panas	22 TiB Premium setelah pelapisan tingkat	Sekitar $ 8.870
Lapisan dingin	88 TiB dalam akses dingin	Sekitar $5.304
Kapasitas yang dicadangkan	Reservasi 100 TiB mencakup sebagian besar kapasitas Premium tingkat panas	Mengurangi laju tingkat panas
Snapshots	Tiga snapshot harian menambah sekitar 10 TiB kapasitas diferensial	Meningkatkan jejak logis menjadi sekitar 440 TiB
Kapasitas yang dikonsumsi	Sekitar 120 TiB	Jauh lebih rendah daripada alternatif salinan lengkap
Klon jangka pendek	5% buffer tulis alih-alih volume 110 TiB penuh kedua	Sekitar $1.506
Salinan pemulihan bencana	Tingkat layanan fleksibel pada tingkat dasar 128 MiB/s	Menjaga biaya DR saat tidak digunakan tetap rendah

Intinya: harga efektif lebih rendah karena biaya turun sementara kapasitas yang dapat digunakan naik.

Contoh ini menunjukkan bagaimana faktor-faktor pengungkit biaya saling memperkuat alih-alih saling bersaing: penyimpanan dengan akses cool dan cakupan reservasi mengurangi tarif yang dibayarkan untuk salinan utama, snapshot dan klon jangka pendek meningkatkan jumlah data logis yang direpresentasikan oleh sejumlah kapasitas terprovisi tertentu, dan tingkat layanan Fleksibel mencegah throughput pemulihan bencana yang diprovisikan secara berlebihan menaikkan tagihan bulanan. Hasilnya adalah harga efektif yang secara signifikan lebih rendah untuk aset data yang sama yang terlindungi dan dapat diuji.

Ringkasan

Model biaya Azure NetApp Files didasarkan pada tiga properti utama:

Provisioning menentukan penagihan. Biaya mencerminkan kapasitas yang disediakan (dan, untuk tingkat layanan Fleksibel, throughput yang disediakan) - bukan data yang disimpan.
Pengukuran dilakukan per jam. Pengubahan ukuran dinamis, perubahan tingkat layanan dinamis, dan penyesuaian throughput fleksibel dinamis berlaku dalam waktu satu jam dan tercermin pada faktur bulanan.
Kapabilitas berkembang secara berlipat. Akses dingin, kapasitas cadangan, rekam jepret, klon jangka pendek, dan tingkat layanan Fleksibel membahas berbagai bagian dari persamaan biaya dan dapat digabungkan.

Menentukan ukuran pool dan volume sesuai dengan permintaan aktual, memilih tingkat layanan yang sesuai dengan rasio kapasitas terhadap throughput dari beban kerja, serta menggabungkan kapabilitas pengoptimalan bawaan secara berlapis akan menghasilkan harga efektif terendah untuk kebutuhan fungsional tertentu.

Kapasitas efektif dan harga efektif memberikan lensa untuk memahami nilai ekonomi penuh Azure NetApp Files. Kapasitas efektif menjelaskan berapa banyak data logis yang dapat diwakili atau dilindungi oleh sejumlah kapasitas yang disediakan ketika kemampuan seperti rekam jepret dan klon jangka pendek menggunakan kembali blok yang tidak berubah alih-alih membuat salinan penuh. Harga efektif mengekspresikan biaya yang dihasilkan per GiB data yang berguna setelah menggabungkan keuntungan efisiensi tersebut dengan tingkatan biaya yang lebih rendah, reservasi, dan provisi yang selaras dengan beban kerja seperti tingkat layanan Fleksibel.

Bersama-sama, konsep-konsep ini menunjukkan bahwa model biaya Azure NetApp Files bukan hanya tentang harga daftar kapasitas yang disediakan. Ini tentang seberapa efisien layanan mengonversi kapasitas dan throughput yang disediakan menjadi data yang dapat digunakan, dilindungi, dan dapat dipulihkan dengan biaya serendah mungkin.

Langkah berikutnya

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-06-23