Belajar OpenStack - Cinder (Block Storage Service) & Persistent Volumes

#Pendahuluan

Sampai episode 7, semua data instance kalian tersimpan di disk ephemeral — disk yang ikut hilang ketika instance dihapus. Di dunia cloud, itu tidak cukup. Database, aplikasi, dan data pengguna butuh penyimpanan yang bertahan hidup dari siklus hidup instance. Inilah pekerjaan Cinder, Block Storage Service OpenStack.

Episode 8 membahas Cinder dari konsep hingga praktik: apa itu volume dan mengapa persisten, cara membuat dan melampirkan volume ke instance, melepas dan memindahkan volume antar instance, snapshot dan backup untuk recovery, serta strategi memilih backend driver sesuai kebutuhan lab atau produksi.

#Konsep Block Storage di Cloud

#Volume sebagai Virtual Hard Disk

Volume adalah penyimpanan berformat block yang disajikan ke instance seperti hard disk eksternal — di dalam instance ia muncul sebagai perangkat seperti /dev/vdb. Karakter utama volume:

• Persisten: data tetap ada meskipun instance dihapus.
• Portable: bisa dilepas dari satu instance dan dipasang ke instance lain.
• Skalabel: bisa diperbesar sesuai kebutuhan tanpa membuat ulang.

Cinder Volume (backend: LVM/Ceph)
        ↓  attach via virtio-scsi / iSCSI / RBD
Instance → /dev/vdb → mount /data

Bayangkan volume sebagai disk yang bisa dipindahkan dari satu komputer ke komputer lain — data di dalamnya ikut pindah. Inilah yang membuat volume menjadi fondasi database dan aplikasi stateful di cloud.

#Kapan Memakai Volume

Aturan praktisnya sederhana: jika datanya penting dan harus bertahan melewati siklus hidup instance, simpan di volume. Jika instance bersifat sementara dan bisa dibangun ulang dari image, biarkan di disk ephemeral. Kombinasi keduanya adalah pola yang paling umum di produksi.

#Operasi Cinder Volume

#Membuat Volume

openstack volume create --size 50 --name my-volume
openstack volume list

openstack volume create --size 50 meminta Cinder mengalokasikan 50 GB dari backend. Status volume berubah dari creating menjadi available saat siap. Perhatikan kolom Attached to — ketika kosong, volume belum terpasang ke instance mana pun.

#Menghubungkan Volume ke Instance

openstack server add volume my-server my-volume
openstack volume show my-volume -c attachments

Setelah openstack server add volume my-server my-volume, di dalam instance kalian bisa memformat dan mount:

sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data
sudo mount /dev/vdb /data

Pola di atas memakai volume sebagai penyimpanan data terpisah. Agar mount bertahan setelah reboot, tambahkan entri di /etc/fstab di dalam instance.

#Melepas dan Memindahkan Volume

Volume bisa dilepas dari instance yang berjalan:

openstack server remove volume my-server my-volume

Volume yang sudah available bisa dipasang ke instance lain — persis memindahkan hard disk fisik antar server:

openstack server add volume my-server-2 my-volume

openstack server remove volume melakukan detach yang aman. Pastikan data sudah di-unmount dari dalam instance sebelum melepas, agar tidak ada data yang korup.

#Volume Snapshots & Backups

#Snapshot untuk Point-in-Time Recovery

Snapshot adalah salinan point-in-time dari volume. Gunanya untuk dua hal: recovery ketika data rusak, dan cloning ketika butuh duplikat volume.

openstack volume snapshot create --volume my-volume my-volume-snap
openstack volume create --snapshot my-volume-snap --size 50 my-volume-restore

openstack volume snapshot create merekam kondisi volume pada saat itu. Untuk recovery, cukup buat volume baru dari snapshot tersebut — data kembali ke kondisi saat snapshot diambil. Di DevStack, backend LVM memakai thin provisioning sehingga snapshot cepat dan hemat ruang.

#Backup vs Snapshot

Penting membedakan keduanya:

Backup Cinder (openstack volume backup create) menyimpan data ke backend terpisah seperti Swift atau Object Storage — melindungi dari kegagalan backend utama, misalnya kerusakan physical disk LVM. Keduanya saling melengkapi, bukan pengganti.

#Cinder Backend Drivers

#Memilih Backend yang Tepat

Cinder tidak menyimpan data sendiri — dia mengorkestrasi backend penyimpanan di belakangnya. Pilihan backend menentukan performa, fitur, dan skala:

• LVM (iSCSI): default lab DevStack, ringan dan mudah, cocok untuk belajar.
• Ceph RBD: pilihan utama produksi — distribusi, tanpa SPOF, terintegrasi dengan Glance dan Nova.
• NFS: memanfaatkan fileserver yang sudah ada.
• SAN vendor (Dell, NetApp, HPE): untuk organisasi yang sudah punya storage array enterprise.

openstack volume service list

Output openstack volume service list menampilkan status backend Cinder. Kolom State harus up dan kolom Binary menunjukkan cinder-volume. Integrasi Ceph RBD akan kita bedah mendalam di episode 16.

#Penutup

Episode 8 memberi kalian kendali penuh atas penyimpanan persisten: memahami volume sebagai virtual hard disk yang persisten dan portable, membuat dan melampirkan volume, melepas dan memindahkannya antar instance, snapshot untuk recovery dan cloning, backup untuk perlindungan jangka panjang, serta memilih backend dari LVM hingga Ceph RBD.

Inti yang harus dibawa pulang:

• Volume persisten dan portable, tidak terikat siklus hidup instance.
• openstack volume create lalu openstack server add volume adalah alur dasar.
• Detach aman: unmount dulu di dalam instance sebelum melepas.
• Snapshot untuk recovery cepat dan cloning; backup untuk proteksi jangka panjang.
• LVM untuk lab, Ceph RBD untuk produksi.
• Data penting selalu ditempatkan di volume, bukan disk ephemeral.

Di episode 9 selanjutnya kita akan membahas Swift (Object Storage Service) — penyimpanan data tidak terstruktur yang skalabel, perbandingannya dengan block storage dan shared filesystem, arsitektur proxy dan storage server Swift, serta operasi membuat container, mengunggah object, dan mengaksesnya via REST API dan temporary URL.