Harga Layanan Pencadangan dan DR
Dokumen ini membahas detail harga DR dan Pencadangan Cloud.
Ringkasan
Layanan Pencadangan dan DR menawarkan model penagihan berbasis pemakaian dan penagihannya didasarkan pada komponen berikut:
Biaya penyimpanan cadangan. Jumlah penyimpanan yang digunakan oleh image cadangan.
Biaya penggunaan cadangan. Jumlah penggunaan untuk orkestrasi dan pengelolaan pencadangan.
Biaya penyimpanan cadangan
Dengan Layanan Pencadangan dan DR, pengguna dapat memanfaatkan kekayaan penuh penawaran Cloud Storage agar lebih selaras dengan penyimpanan cadangan dengan kepentingan bisnis dari beban kerja yang dilindungi.
Layanan Pencadangan dan DR mendukung persistent disk, penyimpanan standar, Nearline Storage, Coldline Storage, dan jenis penyimpanan arsip. Anda membayar jumlah penyimpanan yang digunakan oleh image cadangan di setiap jenis penyimpanan. Untuk mengetahui detail selengkapnya tentang harga Cloud Storage, lihat Harga Cloud Storage.
Biaya peralatan pencadangan/pemulihan
Alat pencadangan/pemulihan berjalan dalam VM instance komputasi yang berjalan di project yang dipilih pelanggan, dan biaya instance mesin komputasi standar berlaku. Layanan Pencadangan dan DR mendukung jenis mesin Compute Engine yang tercantum dalam artikel Menyiapkan dan merencanakan deployment Layanan Pencadangan dan DR.
Biaya penggunaan cadangan
Setiap project di Google Cloud memiliki akun penagihan yang digunakan untuk menentukan siapa yang membayar penggunaan resource dan API Google Cloud dalam project tersebut. Saat layanan pencadangan dan DR diaktifkan dalam sebuah project, penggunaan keempat SKU yang dijelaskan di bawah akan ditagihkan ke project tersebut. Ini terlepas dari zona atau project tempat peralatan cadangan/pemulihan berada.
Tabel berikut mencantumkan SKU dan titik harga saat Anda menggunakan Pencadangan dan DR.
| Produk/SKU - Pencadangan | Model penetapan harga | Pengukur | Harga jual |
|---|---|---|---|
| Data VM: VM Compute Engine, VM Lokal, Sistem File | Berdasarkan penggunaan | Per GiB-mo kapasitas sumber (front-end) yang dilindungi | $0,03/GiB-bulan |
| SAP HANA, Oracle, SAP ASE, SAP IQ, SAP MaxDB, IBM Db2 | Berdasarkan penggunaan | Per GiB-mo kapasitas sumber (front-end) yang dilindungi | $0,24/GiB-bulan |
| Microsoft SQL Server, MySQL, PostgreSQL, MongoDB, MariaDB | Berdasarkan penggunaan | Per GiB-mo kapasitas sumber (front-end) yang dilindungi | $0,09/GiB-bulan |
| Salinan virtual (Pengelolaan data pengujian) | Berdasarkan penggunaan | Per GiB-bln dari total kapasitas yang di-clone virtual | $0,03/GiB-bulan |
1 Termasuk skenario yang menggunakan penyangga virtual untuk pengujian pencadangan dan/atau pemulihan.
Harga untuk pencadangan Google Cloud VMware Engine didasarkan pada konsumsi dan persyaratan komitmen; opsi mencakup on demand atau diskon abonemen untuk jangka waktu satu dan tiga tahun.
Tabel berikut mencantumkan SKU dan titik harga untuk melindungi node ve1-standard-72 dan node khusus penyimpanan ve1-standard-72 Google Cloud VMware Engine.
| Produk/SKU - Pencadangan | Model penetapan harga | Pengukur | Region | Location | Harga jual (on demand) | Komitmen 1 tahun (Pembayaran bulanan USD) | Komitmen 1 tahun (Pembayaran di muka USD) | Komitmen 3 tahun (Pembayaran bulanan USD) | Komitmen 3 tahun (Pembayaran di muka USD) |
|---|---|---|---|---|---|---|---|---|---|
| Data VM: Google Cloud VMware Engine | Berbasis node | per jam per node | asia-northeast1 | Tokyo | $0,53 | $0,40 | $0,37 | $0,30 | $0,27 |
| Berbasis node | per jam per node | asia-south1 | Mumbai | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | asia-southeast1 | Singapura | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | australia-southeast1 | Sydney | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | europe-west2 | London | $0,53 | $0,40 | $0,37 | $0,31 | $0,27 | |
| Berbasis node | per jam per node | europe-west3 | Frankfurt | $0,53 | $0,40 | $0,37 | $0,31 | $0,27 | |
| Berbasis node | per jam per node | europe-west4 | Belanda | $0,53 | $0,40 | $0,37 | $0,31 | $0,27 | |
| Berbasis node | per jam per node | europe-west6 | Zurich | $0,58 | $0,44 | $0,40 | $0,33 | $0,29 | |
| Berbasis node | per jam per node | europe-west8 | Milan | $0,54 | $0,41 | $0,38 | $0,31 | $0,27 | |
| Berbasis node | per jam per node | northamerica-northeast1 | Montreal, Qubec, Amerika Utara | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | northamerica-northeast2 | Toronto, Ontario, Amerika Utara | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | southamerica-east1 | Sao Paulo | $0,66 | $0,50 | $0,46 | $0,38 | $0,33 | |
| Berbasis node | per jam per node | us-central1 | Council Buffs, Iowa, Amerika Utara | $0,46 | $0,35 | $0,33 | $0,27 | $0,23 | |
| Berbasis node | per jam per node | us-east4 | Ashburn | $0,46 | $0,35 | $0,33 | $0,27 | $0,23 | |
| Berbasis node | per jam per node | us-west2 | Los Angeles | $0,50 | $0,38 | $0,35 | $0,29 | $0,25 | |
| Berbasis node | per jam per node | Southamerica-west1 | Santiago | $0,64 | $0,48 | $0,45 | $0,37 | $0,32 | |
| Berbasis node | per jam per node | asia-south2 | Delhi | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | me-west-1 | Tel Aviv | $0,51 | $0,39 | $0,36 | $0,29 | $0,26 | |
| Berbasis node | per jam per node | europe-west-12 | Turin | $0,54 | $0,41 | $0,38 | $0,31 | $0,27 |
Bagaimana penggunaan Pencadangan dan DR diukur?
Pencadangan dan DR mengukur penggunaan berdasarkan ukuran workload sebenarnya di frontend atau ukuran workload yang dikelolanya. Satuan ukurnya adalah gibibyte (GiB). Satu gibibyte = 1024 * 1024 * 1024 byte.
Jika workload dalam pengelolaan melaporkan ukuran volume untuk data, Pencadangan dan DR akan memperhitungkan ukuran volume yang dilaporkan (misalnya, penghitungan penggunaan untuk VMware akan konsisten dengan ukuran VM yang dilaporkan di vCenter).
Jika Anda mengelola 10 TiB data Oracle yang tersebar di beberapa database, penggunaan Pencadangan dan DR akan melaporkan penggunaan data sebesar 10 * 1.024 GiB.
Pengukuran penggunaan untuk Compute Engine tanpa agen
Pencadangan dan DR mengukur penggunaan pencadangan VM Compute Engine berdasarkan jumlah penyimpanan PD yang terpasang pada VM Compute Engine pada saat pencadangan. Dengan Pencadangan dan DR, Anda dapat mengecualikan volume PD dari cadangan. Dalam kasus tersebut, hanya volume yang diidentifikasi akan dicadangkan yang digunakan untuk mengukur penggunaan.
Misalnya, jika dua volume PD dari satu TiB dan dua TiB terpasang ke VM Compute Engine dan Anda mengonfigurasi SLT cadangan untuk mengecualikan volume 2TiB, penggunaan untuk VM akan diukur menjadi satu TiB.
Selain itu, jika VM 1TiB bertambah atau menyusut, Pencadangan dan DR akan mengukur penggunaan berdasarkan ukuran volume saat pencadangan terbaru.
Pengukuran penggunaan untuk Google Cloud VMware Engine tanpa agen
Harga untuk Google Cloud VMware Engine dihitung berdasarkan node Google Cloud VMware Engine ve1 dan node khusus penyimpanan Google Cloud VMware Engine ve1.
Untuk node Google Cloud VMware Engine ve1
Harga dihitung berdasarkan jumlah node ESXi yang dilindungi. Node ESXi dianggap dilindungi jika satu atau beberapa VM yang terpasang padanya dilindungi oleh Layanan Pencadangan dan DR.
Berikut contoh yang menunjukkan proses penagihan untuk Google Cloud VMware Engine:
Harga untuk mencadangkan satu node Google Cloud VMware Engine (khusus cadangan VM) di region us-central1 selama sebulan =
(Harga jual untuk mencadangkan node/ jam) X (Jumlah jam dalam node hari aktif) X (Jumlah hari dalam sebulan).
Mengingat node Google Cloud VMware Engine aktif selama 24 jam, ada 30 hari dalam sebulan, dan harga untuk mencadangkan node adalah $0,46 X 24 X 30 = $331 USD.
Harga hanya untuk melindungi Google Cloud VMware Engine—seluruh pencadangan VM. Ini tidak termasuk biaya pengelolaan cadangan untuk pencadangan berbasis agen, seperti biaya pencadangan konsisten aplikasi untuk SAP HANA, SQL Server, MySQL, Postgres, agen Sistem File, dll. Untuk memperkirakan biaya pencadangan berbasis agen, lihat Pengukuran penggunaan untuk pencadangan berbasis agen.
Untuk node khusus penyimpanan Google Cloud VMware Engine ve1
Harga untuk melindungi node khusus penyimpanan Google Cloud VMware Engine ve1 ditentukan oleh jumlah node khusus penyimpanan Google Cloud VMware Engine ve1 yang ditambahkan ke cluster yang memiliki setidaknya satu atau beberapa node yang dilindungi Google Cloud VMware Engine ve1.
Jika Anda memiliki cluster dengan node yang dilindungi Google Cloud VMware Engine ve1 dan menambahkan node khusus penyimpanan Google Cloud VMware Engine ve1 ke cluster yang sama, semua node khusus penyimpanan di cluster akan dianggap terlindungi secara default dan Anda akan dikenai biaya karena melindungi semua node tersebut. Anda tidak dapat mengecualikan perlindungan untuk node khusus penyimpanan Google Cloud VMware Engine ve1 di cluster yang memiliki setidaknya satu atau beberapa node yang dilindungi Google Cloud VMware Engine ve1.
Misalnya, anggap Anda memiliki cluster yang terdiri dari 20 node dan Anda melindungi 10 cluster tersebut menggunakan layanan Pencadangan dan DR. Jika Anda menambahkan 3 node khusus penyimpanan ke cluster, ke-3 node khusus penyimpanan akan dianggap dilindungi, dan Anda akan dikenai biaya untuk melindungi 10 + 3 = 13 node Google Cloud VMware Engine ve1.
Jika Anda tidak melindungi node Google Cloud VMware Engine ve1 di cluster, node khusus penyimpanan Google Cloud VMware Engine v1 tidak dapat dilindungi dalam kasus tersebut.
Pengukuran penggunaan untuk pencadangan berbasis agen
Pencadangan dan DR mengukur penggunaan untuk pencadangan berbasis agen pada ukuran workload sebenarnya. Misalnya, jika pencadangan database SQL server menggunakan agen Pencadangan dan DR, dan jika jumlah file data dari SQL server adalah lima TiB pada tujuh volume TiB, penggunaan tersebut akan diukur sebagai lima TiB.
Pengukuran penggunaan untuk pencadangan database berbasis agen
Untuk workload Oracle dan SQL Server, hanya database yang dilindungi yang diperhitungkan dalam penggunaan. File log tidak akan dipertimbangkan:
- Oracle. Ukuran file database yang dialokasikan dalam perlindungan akan diperhitungkan dalam penggunaan. Ukuran yang dialokasikan mencakup file data dan file kontrol.
- Microsoft SQL Server. Ukuran total semua file database, termasuk file .MDF, .LDF, dan .NDF yang dilindungi, akan diperhitungkan dalam penggunaan.
Perlindungan database dengan Linux Change Block Tracking (CBT). Pencadangan dan DR mendukung pencadangan beberapa database secara efisien dengan pelacakan blok perubahan. Mode pencadangan ini bergantung pada log database dan file data agar berada di volume yang dikelola Linux Logical Volume Manager (LVM). Untuk class workload ini, penggunaan diukur sebagai ukuran database yang sebenarnya digunakan dalam perlindungan, menggunakan kueri berikut:
Db2: panggil get_dbsize_info(?,?,?,-1);
MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES dengan table_schema='
'; MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES dengan table_schema='
'; PostgreSQL: SELECT pg_database_size('$db');
SAP ASE: sp_spaceused;
SAP IQ: sp_iqdbsize * block_size;
SAP HANA: pilih sum(TOTAL_SIZE) dari sys_databases.M_VOLUME_FILES dengan file_type='DATA'
SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY info DATA
Perlindungan berbasis dump SQL tanpa Linux CBT. Pencadangan dan DR mendukung pencadangan berbasis dump SQL tradisional. Dalam mode ini, penggunaan diukur sebagai ukuran database seperti yang dilaporkan oleh database pada saat pencadangan.
Pengukuran penggunaan untuk salinan virtual
Pencadangan dan DR mengukur penggunaan salinan virtual yang dimulai saat salinan virtual beban kerja dibuat. Jumlah penggunaan didasarkan pada ukuran aplikasi pada saat pencadangan terakhir. Saat pencadangan baru dilakukan, jumlah penggunaan akan diperbarui untuk mencerminkan ukuran aplikasi saat ini. Cara paling umum untuk membuat salinan virtual adalah dengan tugas pemasangan. Ada jenis tugas lain seperti prep-mount dan penyediaan ulang yang juga dapat membuat salinan virtual. Biaya penggunaan dihitung secara prorata berdasarkan waktu penggunaan salinan virtual (dari saat pemasangan yang berhasil hingga saat pelepasannya, diukur dalam kelipatan 1 jam).
Pertimbangkan contoh database server SQL berukuran 500 GiB. Pencadangan database ini dikenai biaya penggunaan cadangan sebesar 500 GiB. Selain itu, pertimbangkan bahwa salinan virtual database ini disediakan ke server pengujian pada siang hari pertama setiap bulan dari cadangan terbaru. Pada tanggal 10 setiap bulan, {i>database<i} sumber menyusut menjadi 400 GiB. Pada tanggal 20 setiap bulan, salinan virtual dilepas dari server pengujian pada pukul 11.00. Dalam skenario ini, biaya penggunaan salinan virtual sebesar 500 GiB dikeluarkan selama 12 jam pada tanggal 1, dan 24 jam sehari setiap hari dari tanggal 2 hingga saat pencadangan pada tanggal 10. Biaya penggunaan salinan virtual akan berubah menjadi 400 GiB pada tanggal 10 (pada saat pencadangan) dan berlanjut hingga tanggal 20 setiap bulannya. Penggunaan salinan virtual untuk tanggal 20 hanya akan menghitung penggunaan selama 11 jam, bukan selama sehari penuh. Jumlah penggunaan tidak berubah dengan data tambahan yang ditulis ke salinan virtual.
Faktor yang memengaruhi pengukuran penggunaan
Faktor yang memengaruhi pengukuran penggunaan dalam skenario out-of-band:
- Volume terkompresi. Jika volume didukung kompresi, penggunaan akan menghitung nilai pasca-kompresi. Misalnya, jika dua volume TiB memiliki 2,5 TiB data yang dikompresi menjadi 1,8 TiB, jumlah penggunaannya adalah 1,8 TiB, bukan 2,5 TiB.
- Volume yang dioptimalkan Windows. Untuk volume yang dioptimalkan Windows, Pencadangan dan DR akan merehidrasi volume untuk pencadangan, dan jumlah penggunaannya akan menjadi nilai yang terhidrasi. Misalnya, jika volume satu TiB yang dioptimalkan Windows berisi data 800 GiB, saat direhidrasi untuk cadangan berakhir sebagai 1,1 TiB, maka penggunaannya adalah 1,1 TiB.
- Ukuran blok. Untuk disk staging, Pencadangan dan DR mengukur penggunaan berdasarkan ukuran blok disk staging. Jika ukuran blok volume sumber dan ukuran blok disk staging cocok, nilai penggunaan akan sama persis dengan volume sumber. Jika ukuran blok yang digunakan pada disk staging berbeda dengan volume sumber, akan ada perbedaan kecil karena penghitungan penggunaan dilakukan pada disk staging.
- Grup konsistensi. Jumlah penggunaan untuk grup konsistensi adalah jumlah dari semua ukuran workload dalam grup konsistensi. Workload diukur satu per satu dan dijumlahkan.
Langkah selanjutnya
Untuk pertanyaan terkait harga, lihat Pertanyaan umum (FAQ).