Block Storage #
Block storage adalah jenis penyimpanan yang paling mirip dengan hard disk fisik — ia menyimpan data dalam blok-blok berukuran tetap dan di-attach ke instance seperti disk drive. Di cloud, block storage hadir sebagai managed service: kamu tidak tahu atau perlu tahu di mana fisiknya, berapa disk yang menyimpan datanya, atau bagaimana replikasinya bekerja. Yang kamu tahu adalah: ada “disk” yang bisa kamu format, mount, dan gunakan seperti disk biasa — dengan performa yang bisa diprediksi dan lifetime yang terpisah dari instance yang memakainya.
Cara Kerja Block Storage #
Filesystem dan OS berinteraksi dengan block storage seperti disk fisik:
Application (database, filesystem)
│
▼
Filesystem Layer (ext4, xfs, ntfs)
│
▼
Block Device (/dev/sda, /dev/nvme0n1)
│
│ Network interface (iSCSI, NVMe-oF, atau proprietary)
│ (di cloud, "disk" ini sebenarnya jaringan storage)
▼
Storage Backend (dikelola provider)
Dari perspektif aplikasi:
→ Sama persis dengan disk fisik
→ Read/write di level blok (512 bytes atau 4KB per blok)
→ Mendukung semua filesystem: ext4, xfs, ntfs, btrfs
→ Bisa di-format, di-partition, di-mount
Persistent vs Ephemeral #
Ini adalah perbedaan kritis yang sering menyebabkan kehilangan data.
Ephemeral Storage (Instance Store):
→ Storage fisik yang menempel langsung di host server
→ SANGAT cepat (akses lokal, NVMe langsung)
PERINGATAN:
✗ Data HILANG ketika:
- Instance di-stop (berbeda dengan reboot)
- Instance di-terminate
- Instance gagal dan di-replace (auto-healing)
- Instance di-migrate ke host lain
Cocok HANYA untuk:
→ Temporary data: cache, buffer, working directory
→ Data yang bisa diregenerasi dengan mudah
→ BUKAN untuk data yang harus persisten
Persistent Block Storage (EBS, Persistent Disk, Managed Disk):
→ Volume terpisah dari siklus hidup instance
→ Data TETAP ADA ketika:
✓ Instance di-stop dan di-start ulang
✓ Instance di-reboot
✓ Volume di-detach dari instance lama dan attach ke instance baru
✗ Data BARU hilang jika:
- Volume itu sendiri yang dihapus (delete on termination jika diaktifkan)
- Volume tidak di-backup dan terjadi kerusakan (sangat jarang)
→ Selalu gunakan ini untuk data yang penting
Ephemeral storage adalah sumber kehilangan data yang sangat umum di cloud. Jangan pernah simpan data penting — database files, user uploads, log yang belum di-ship — di ephemeral storage. Selalu gunakan persistent block volume atau object storage untuk data yang harus survive instance lifecycle.
Tipe Volume dan Karakteristik Performa #
Block storage hadir dalam beberapa tipe dengan karakteristik performa yang berbeda. Pilihan tipe menentukan IOPS, throughput, dan latensi yang bisa kamu dapatkan.
SSD-based (General Purpose):
Karakteristik:
→ IOPS: hingga ribuan IOPS per volume
→ Latensi: single-digit milliseconds
→ Throughput: ratusan MB/s
Cocok untuk:
✓ OS volume (boot disk)
✓ Database umum (MySQL, PostgreSQL dengan beban sedang)
✓ Aplikasi umum yang butuh storage responsif
✓ Development dan testing
✓ Pilihan default yang baik untuk hampir semua kasus
SSD-based (Provisioned IOPS):
Karakteristik:
→ IOPS: bisa dipilih secara eksplisit (hingga puluhan ribu IOPS)
→ Latensi: konsisten dan sangat rendah
→ Throughput: tinggi dan konsisten
Cocok untuk:
✓ Database dengan beban I/O sangat tinggi (OLTP)
✓ Workload yang butuh latensi konsisten dan rendah
✓ Production database yang latency-sensitive
✗ Mahal — hanya gunakan jika benar-benar butuh IOPS tinggi
HDD-based (Throughput Optimized):
Karakteristik:
→ IOPS: rendah
→ Throughput: tinggi (sequential read/write)
→ Harga per GB: jauh lebih murah dari SSD
Cocok untuk:
✓ Big data workload (Hadoop, data warehouse)
✓ Log processing yang sequential
✓ Data yang sering dibaca berurutan, bukan random access
✗ Tidak cocok untuk database transaksional
Snapshot — Backup Block Storage #
Snapshot adalah cara utama untuk backup block storage. Ia membuat point-in-time copy dari volume yang bisa digunakan untuk restore atau membuat volume baru.
Cara Kerja Snapshot:
Volume: 100 GB data
│
│ Take snapshot
▼
Snapshot (incremental):
Snapshot pertama:
→ Copy seluruh data yang ada (100 GB)
→ Disimpan di object storage (lebih murah dari block storage)
Snapshot kedua (setelah ada perubahan 5 GB):
→ Hanya menyimpan PERUBAHAN (5 GB)
→ Tidak copy ulang 100 GB
→ Incremental — efisien dari segi storage dan waktu
Restore dari snapshot:
→ Buat volume baru dari snapshot tersebut
→ Attach ke instance
→ Data tersedia seperti saat snapshot diambil
Best Practice Snapshot:
✓ Automated snapshot schedule
→ Snapshot harian atau lebih sering untuk production database
→ Jangan hanya snapshot manual yang sering terlupa
✓ Retention policy
→ Simpan 7 hari snapshot harian
→ Simpan 4 minggu snapshot mingguan
→ Hapus otomatis snapshot yang sudah terlalu lama
✓ Cross-region copy untuk disaster recovery
→ Snapshot di region primer, copy ke region sekunder
→ Jika region primer down, bisa restore di region lain
✓ Test restore secara berkala
→ Snapshot yang tidak pernah di-test restore = tidak reliable
→ Lakukan restore test setidaknya sekali per kuartal
Volume Multi-Attach #
Beberapa provider mendukung attach satu volume ke beberapa instance secara bersamaan, dengan batasan tertentu.
Multi-Attach:
Volume ←── attach ──→ Instance A
←── attach ──→ Instance B
Kapan dibutuhkan:
→ Clustered applications yang butuh shared block storage
→ Oracle RAC, SQL Server Always On
Batasan penting:
✗ Hanya tersedia untuk tipe volume tertentu (Provisioned IOPS SSD)
✗ Hanya dalam satu AZ yang sama
✗ Filesystem harus cluster-aware (tidak bisa pakai ext4 biasa)
→ Filesystem biasa tidak dirancang untuk concurrent write dari
beberapa node — akan menyebabkan corruption
Untuk kebanyakan use case:
→ Shared storage lebih baik menggunakan file storage atau
managed database, bukan multi-attach block volume
Ringkasan #
- Block storage adalah “disk virtual” yang di-attach ke instance — dari perspektif OS, identik dengan hard disk fisik namun dikelola sepenuhnya oleh provider.
- Ephemeral storage HILANG saat instance stop atau gagal — jangan pernah simpan data penting di sana. Selalu gunakan persistent block volume.
- Pilih tipe volume berdasarkan kebutuhan performa — general purpose SSD untuk hampir semua kasus, provisioned IOPS hanya untuk database dengan beban I/O sangat tinggi.
- Snapshot adalah backup incremental yang efisien — hanya perubahan yang disimpan setelah snapshot pertama. Automasi dan uji restore secara berkala.
- Volume lifetime terpisah dari instance lifetime — detach dari satu instance, attach ke instance lain tanpa kehilangan data.
- Multi-attach sangat terbatas — untuk shared storage antar instance, pertimbangkan file storage atau managed database sebagai alternatif yang lebih aman.