Konverter GiB ke TiB untuk Ukuran Datastore Hypervisor

Menjumlahkan Cakram Mesin Virtual Menjadi Satu Angka Datastore

Peninjauan kapasitas sebagian besar berisi kolom-kolom gibibyte. Setiap cakram virtual di vCenter, setiap volume di kumpulan Proxmox, setiap baris inventaris guest ditulis dalam GiB — tetapi datastore tempat semuanya akan dipasang ditulis dalam tebibyte, begitu pula permintaan pembelian yang akhirnya Anda ajukan. Menggulung daftar panjang gambar GiB menjadi satu angka TiB adalah cara Anda mengetahui apakah rombongan mesin virtual berikutnya punya tempat tinggal.

Faktor: TiB = GiB ÷ 1024. Satu rak guest dengan alokasi 3.072 GiB setara 3072 ÷ 1024 = 3 TiB datastore. Kalikan 1024 untuk mengembalikan target TiB menjadi anggaran GiB.

Dialokasikan Tidak Sama dengan Terpakai

Cakram 250 GiB dengan thin provisioning pada guest yang masih baru mungkin hanya menyentuh 20 GiB di penyimpanan, sedangkan thick provisioning mengklaim seluruh 250 GiB sejak dibuat. Kolom GiB yang sama karenanya bisa berarti dua total TiB yang sangat berbeda.

Snapshot Tumbuh Diam-Diam

Sebuah snapshot bermula mendekati nol dan membesar mengikuti tiap blok yang ditulis ulang guest. Biarkan satu snapshot hidup sepanjang siklus pemutakhiran pada basis data yang sibuk, dan deltanya bisa menyaingi cakram induknya, menambah ratusan GiB yang tak pernah dijumlahkan siapa pun.

Kelebihan Komitmen Ada Batasnya

Menjual kapasitas melebihi fisiknya itu wajar karena guest jarang memenuhi cakramnya serentak. Risikonya ditanggung bersama: ketika penyimpanan thin provisioning kehabisan ruang, semua mesin virtual di atasnya macet pada saat yang sama, bukan hanya yang rakus.

Mengonversi Total Alokasi Sebelum Anda Memutuskan

Jumlahkan Cakram Virtualnya dalam GiB

Tambahkan semua cakram virtual yang akan Anda tempatkan — termasuk cakram kedua dan ketiga pada guest basis data, yang gampang terlewat — lalu ketik totalnya ke kolom kiri. Koma maupun titik sama-sama bisa jadi pemisahnya.

Bandingkan dengan Datastore-nya

Sandingkan angka tebibyte itu dengan kapasitas yang disebutkan tim penyimpanan Anda. Bila total alokasinya sudah melampaui, berarti Anda bersandar pada thin provisioning — keputusan yang layak diambil secara sadar.

Salin ke Catatan Perubahan

Tombol Salin di tiap kolom memberi angka telanjang tanpa satuan, siap untuk tiket perubahan, lembar kerja kapasitas, atau tabel penentuan ukuran dalam dokumen desain.

Hitung Mundur dari Target

Tekan Tukar satuan untuk membalik pasangannya lalu masukkan kapasitas TiB yang dijatahkan kepada Anda. Hasil GiB-nya adalah anggaran cakram yang Anda serahkan kembali kepada pemilik aplikasi sebagai jatah per mesin virtual.

Tidak satu pun kolom bersifat baca-saja, jadi arah sebaliknya tak butuh langkah tambahan: ketik angka TiB di kanan dan padanan GiB-nya muncul seketika. Kedua sisi membawa daftar satuan yang bisa dicari, praktis ketika konsol larik melaporkan LUN yang sama dalam satuan yang tak pernah dipakai hypervisor Anda.

Contoh Perhitungan Datastore dari Cakram Mesin Virtual

Di bawah ini beban kerja campuran yang realistis, disusun seperti rencana kapasitas pada umumnya: kelompok guest, cakram yang dialokasikan untuk masing-masing, dan sumbangan tiap kelompok setelah dinyatakan dalam tebibyte.

Kelompok mesin virtual	Jumlah guest	Alokasi per guest	Total kelompok (GiB)	Total kelompok (TiB)
Front end web	12	40 GiB	480 GiB	0,46875 TiB
Server aplikasi	8	120 GiB	960 GiB	0,9375 TiB
Agen build	6	250 GiB	1.500 GiB	1,46484375 TiB
Guest basis data	4	500 GiB	2.000 GiB	1,953125 TiB
Server berkas	3	1.024 GiB	3.072 GiB	3 TiB
Total yang dialokasikan	33	—	8.012 GiB	7,82421875 TiB

Angka 7,82 TiB itu adalah skenario terburuk dengan thick provisioning. Pada datastore 8 TiB nyaris tak ada sisa — tak ada ruang untuk delta snapshot maupun berkas swap, dan alarm yang disetel di 80% sudah akan berbunyi saat pemakaian mencapai 6.553,6 GiB. Thin provisioning menebus sebagian besar selisihnya, tetapi hanya selama guest-nya tetap jauh di bawah ukuran yang dideklarasikan.

Menjaga Pecahannya Tetap Jujur

Hasil membawa sampai delapan angka di belakang koma, jadi 1.500 GiB tampil sebagai 1,46484375 TiB, bukan 1,5 yang dibulatkan dan menyembunyikan 36 GiB cakram sungguhan.

Pas untuk Peninjauan Kapasitas

Konversikan tiap kelompok mesin virtual satu per satu lalu salin angka telanjangnya ke tabel penentuan ukuran yang sedang Anda isi, tanpa akhiran satuan yang harus dibuang dari tiap sel.

Menganggarkan ke Bawah Maupun ke Atas

Balik arahnya dan jatah TiB berubah menjadi kumpulan GiB yang bisa Anda bagi ke tim-tim peminta — bentuk yang paling sering dipakai permintaan cakram saat datang.

Tidak Ada Detail Infrastruktur yang Dikirim

Ukuran datastore dan jumlah guest menggambarkan aset Anda. Semuanya dihitung di peramban setelah halaman dimuat, jadi tidak ada apa pun tentang lingkungan Anda yang dikirimkan.

Pertanyaan Seputar Kapasitas Datastore

Mengapa cakram virtual 500 GiB tidak persis menjadi 0,5 TiB?

Karena jarak antar-awalan biner adalah 1.024, bukan 1.000. Membagi 500 dengan 1.024 menghasilkan 0,48828125 TiB. Hanya kelipatan dua yang mendarat pada angka rapi: 512 GiB persis 0,5 TiB dan 2.048 GiB persis 2 TiB. Ukuran cakram yang dipilih demi kenyamanan manusia — 250, 500, 750 — tidak akan pernah begitu.

Alokasi guest saya melebihi daya tampung datastore. Apakah itu masalah?

Hanya kalau mereka benar-benar menagih apa yang dijanjikan. Kelebihan langganan itu disengaja dan berhasil karena kebanyakan cakram virtual separuh kosong sepanjang hidupnya. Yang penting adalah rasionya dan seketat apa Anda mengawasi konsumsi nyata: penyimpanan pada 1,5:1 dengan pertumbuhan stabil masih terkendali, sedangkan yang 3:1 dengan basis data tanpa pemantauan adalah antrean mesin virtual macet yang tinggal menunggu waktu.

Apakah snapshot perlu ikut dihitung dalam total GiB yang saya konversikan?

Perlu, dan justru itulah penyebab lazim datastore yang direncanakan matang tetap penuh juga. Sebuah snapshot menyimpan blok yang berubah sejak ia diambil, jadi ukurannya mengikuti laju tulis guest, bukan ukuran cakramnya. Snapshot yang diambil sebelum pemutakhiran hanya makan sedikit; yang terlupakan sebulan pada guest bertulis padat bisa menambah sebesar cakram aslinya. Sediakan jatah kerja di atas gambar dasarnya.

Menentukan ukuran sebaiknya pakai GiB yang dialokasikan atau GiB yang terpakai?

Konversikan keduanya; keduanya menjawab pertanyaan yang berbeda. Angka alokasi adalah skenario terburuk bila setiap cakram thin mengembang sampai ukuran yang dideklarasikannya, sedangkan angka terpakai adalah posisi Anda hari ini. Pembelian biasanya berada di antara keduanya — pemakaian sekarang ditambah kurva pertumbuhan, dengan angka alokasi sebagai angka yang tak boleh sampai membuat penyimpanan mentok tanpa peringatan.

Ambang ruang kosong berapa yang sebaiknya memicu alarm datastore?

Peringatan sekitar 75–80% terpakai dengan tingkat kritis mendekati 90% adalah pasangan yang lazim, dan jaraknya harus cukup lebar untuk memindahkan satu guest sebelum penyimpanannya penuh. Konversikan ambangnya sekali supaya Anda tahu artinya dalam GiB nyata: 10% dari penyimpanan 8 TiB adalah 819,2 GiB, yang masih longgar, sedangkan 10% dari penyimpanan 1 TiB hanya 102,4 GiB — cukup dilahap satu snapshot liar dalam semalam.