Block Storage #

Dalam infrastruktur komputasi cloud, Block Storage adalah jenis penyimpanan terkelola (managed storage) yang paling menyerupai hard disk drive (HDD) atau solid state drive (SSD) fisik pada komputer lokal kita. Berbeda dengan object storage yang menyajikan file utuh melalui API HTTP, block storage memotong data menjadi blok-blok biner mentah (raw blocks) dengan ukuran tetap (misalnya 4 KB atau 8 KB). Blok-blok ini ditransfer menggunakan protokol jaringan khusus dengan kecepatan tinggi (seperti iSCSI atau NVMe-oF) dan dihubungkan (attach) ke Virtual Machine sebagai perangkat disk drive mentah (raw block device). Di dalam OS Virtual Machine, disk ini dapat kita format menggunakan sistem berkas pilihan kita (seperti ext4 di Linux atau NTFS di Windows), dibuat partisi, dan digunakan seperti media penyimpanan lokal dengan karakteristik latensi yang sangat rendah dan kinerja yang konsisten.

Cara Kerja Block Storage: Pemetaan Blok Jaringan #

Di dalam pusat data fisik cloud provider, instans Virtual Machine kita (Compute Node) dan media penyimpanan fisik (Storage Node) biasanya terpisah pada rak server yang berbeda. Keduanya dihubungkan oleh jaringan serat optik internal berkecepatan sangat tinggi (storage area network).

flowchart TD
    App["Aplikasi (Database / Filesystem)"] -->|"1. Read/Write Data (File)"| FS["System Berkas (ext4 / NTFS)"]
    FS -->|"2. Terjemahkan ke Sektor Blok (4 KB)"| OS["OS Block Device Driver (/dev/sdb)"]
    OS -->|"3. Protokol Transport (iSCSI / NVMe-oF)"| Network["Jaringan Storage SAN (Cloud Private Network)"]
    Network -->|"4. Distribusi Sektor Fisik"| StorageBackend["Storage Node (Managed Physical Disks)"]

Alur Operasi Baca/Tulis: #

  1. Application Layer: Aplikasi (misalnya database PostgreSQL) melakukan operasi penulisan file.
  2. Filesystem Layer: OS menerjemahkan file tersebut menjadi potongan blok biner berukuran tetap pada sektor tertentu.
  3. Device Driver: OS driver mengirimkan blok data tersebut ke luar melalui kartu jaringan menggunakan protokol transport data (seperti iSCSI atau NVMe-over-Fabrics).
  4. Storage Backend: Pengontrol penyimpanan (storage controller) milik cloud provider menerima blok tersebut dan mendistribusikannya ke beberapa disk fisik secara redundan untuk menjamin keamanan data.

Seluruh proses enkapsulasi jaringan ini terjadi di bawah tingkat sistem operasi Virtual Machine. Bagi OS, volume block storage eksternal ini terlihat dan berperilaku sama persis seperti hard disk fisik yang tercolok langsung di motherboard.

Persistent vs Ephemeral Block Storage #

Saat kita meluncurkan instans Virtual Machine di cloud, kita harus memahami perbedaan kritis antara dua tipe media penyimpanan ini. Kesalahan memilih tipe penyimpanan adalah penyebab utama terjadinya kehilangan data secara permanen di cloud.

1. Ephemeral Storage (Instance Store) #

Ephemeral storage is media penyimpanan SSD fisik yang terpasang secara langsung di dalam sasis server fisik (physical host) yang sama dengan tempat Virtual Machine kita berjalan.

  • Kelebihan: Kecepatan transfer data yang sangat luar biasa (bisa mencapai jutaan IOPS) dengan latensi sub-milidetik karena paket data tidak perlu menyeberangi jaringan fiber data center.
  • Bahaya Terbesar (Volatilitas): Data di dalam ephemeral storage bersifat sementara dan akan hilang selamanya apabila instans VM kita di-stop, di-terminate, atau dipindahkan ke server fisik lain secara otomatis oleh sistem auto-healing cloud provider.

Skenario Ideal Ephemeral: Hanya gunakan untuk data sementara (scratch data) seperti cache, memori buffer, temporary files, swap space, atau data log yang sudah langsung dikirimkan (forwarded) ke server log terpusat.

2. Persistent Block Storage (EBS, Managed Disk, Persistent Disk) #

Persistent block storage adalah volume terkelola yang siklus hidup (lifecycle) datanya terpisah penuh dari Virtual Machine.

  • Kelebihan: Data kita terjamin aman meskipun instans VM dimatikan, di-reboot, atau dihancurkan. Kita dapat melepas (detach) volume dari VM lama dan menempelkannya (attach) ke VM baru tanpa kehilangan data satu bit pun. Secara otomatis, cloud provider juga melakukan replikasi data internal di dalam satu Availability Zone untuk mencegah kerusakan data akibat kerusakan harddisk fisik.

Metrik Performa Utama: IOPS, Throughput, dan Latensi #

Untuk memilih tipe volume block storage yang tepat, kita harus memahami tiga metrik kinerja berikut:

  1. IOPS (Input/Output Operations Per Second): Jumlah operasi baca/tulis yang dapat ditangani oleh disk dalam satu detik. Semakin tinggi IOPS, semakin responsif disk dalam menangani transaksi kecil acak (random read/write), seperti pada database transaksional OLTP.
  2. Throughput (MB/s): Kecepatan volume dalam membaca atau menulis data bervolume besar secara kontinu (sekuensial), seperti saat melakukan backup database raksasa atau membaca file log panjang. Hubungan matematisnya adalah: $$\text{Throughput} = \text{IOPS} \times \text{Ukuran Blok (Block Size)}$$
  3. Latency: Waktu yang dibutuhkan oleh disk untuk menyelesaikan satu operasi I/O (biasanya diukur dalam milidetik).

Evolusi Protokol Host: SCSI vs NVMe #

Dalam infrastruktur modern, cloud provider beralih dari protokol SCSI (Small Computer System Interface) tradisional ke NVMe (Non-Volatile Memory Express) untuk menghubungkan volume block storage ke hypervisor.

  • SCSI Protocol: Protokol lawas yang dirancang untuk disk mekanis. Memiliki antrean tunggal (single queue) yang dapat menampung maksimal 32 perintah sekaligus, memicu antrean (bottleneck) ketika banyak core CPU mencoba menulis secara bersamaan.
  • NVMe Protocol: Dirancang khusus untuk SSD flash berkecepatan tinggi. Mendukung hingga 64.000 antrean paralel, dengan masing-masing antrean mampu menampung 64.000 perintah secara bersamaan. Ini meminimalkan hambatan kunci pemrosesan (lock contention) pada server database multi-core kita. Dengan menggunakan NVMe, latensi transfer data antara Hypervisor dan VM tereduksi sangat signifikan.

Hambatan Jaringan & EBS-Optimized Instances #

Satu aspek penting yang sering diabaikan adalah batasan throughput pada instans Virtual Machine itu sendiri. Jika kita menyewa volume SSD super cepat berkekuatan 10.000 IOPS, namun memasangnya pada instans VM berukuran sangat kecil (misalnya t3.micro), performa disk akan terhambat (throttled).

Hal ini terjadi karena link jaringan penghubung antara VM dan storage backend tidak memiliki kapasitas yang cukup.

  • Solusi: Pastikan kita menggunakan tipe instans VM yang berlabel EBS-Optimized (di AWS). Instans jenis ini memiliki jalur sirkuit jaringan terdedikasi khusus untuk lalu lintas I/O storage, terpisah dari lalu lintas jaringan internet biasa.

Enkripsi Transparan di Tingkat Hypervisor #

Persistent block storage modern mendukung enkripsi data secara penuh (Encryption at Rest) menggunakan kunci enkripsi KMS (AES-256). Proses enkripsi dan dekripsi ini ditangani langsung di tingkat hypervisor fisik (CPU host) sebelum data dikirimkan melewati jaringan SAN.

  • Dampak Kinerja: Karena ditangani oleh hardware khusus di tingkat hypervisor, fitur enkripsi ini tidak membebani CPU sistem operasi di dalam VM kita, menghasilkan latensi overhead yang hampir mendekati 0%.

Penskalaan Volume Dinamis Tanpa Downtime (Elastic Volumes) #

Salah satu keunggulan luar biasa dari persistent block storage di cloud adalah fitur Elastic Volumes. Di data center tradisional, memperbesar kapasitas harddisk mengharuskan kita mematikan server, mencolokkan drive baru secara fisik, dan mengonfigurasi ulang RAID group.

Di cloud, kita dapat memperbesar kapasitas disk (misal dari 100 GB menjadi 200 GB) secara langsung pada volume aktif yang sedang digunakan oleh instans VM produksi tanpa perlu melakukan reboot atau mengalami downtime.

Langkah OS-Level untuk Memperbesar Kapasitas Disk (Linux ext4):

  1. Ubah kapasitas volume di Cloud Console/API (misal dari 100GB ke 200GB).
  
  2. Gunakan perintah growpart untuk memperbesar partisi disk lokal:
     $ sudo growpart /dev/nvme0n1 1
     
  3. Jalankan resize2fs untuk memperluas filesystem agar mengenali ruang baru:
     $ sudo resize2fs /dev/nvme0n1p1
     
  4. Ruang penyimpanan baru kini siap digunakan secara instan tanpa menghentikan aplikasi.

Aturan Batasan: Cloud provider biasanya menerapkan jeda waktu pendinginan (cooling-off period, misalnya 6 jam di AWS) sebelum kita diizinkan melakukan modifikasi ukuran atau performa pada volume yang sama kembali.

Volume Multi-Attach & Bahaya Split-Brain #

Beberapa provider cloud besar menyediakan fitur Multi-Attach, yang memungkinkan satu volume persistent block storage ditempelkan ke beberapa instans VM secara bersamaan di dalam Availability Zone yang sama.

flowchart LR
    VM1["Virtual Machine A"] <-->|"Concurrent Mount"| SharedVol["Shared Persistent Volume"]
    VM2["Virtual Machine B"] <-->|"Concurrent Mount"| SharedVol

Peringatan Kritis Keamanan Data: Kita dilarang keras menempelkan satu volume block storage biasa (seperti ext4 or XFS) ke beberapa VM secara bersamaan. Filesystem standar ditulis dengan asumsi hanya ada satu OS coordinator yang melakukan modifikasi data.

Jika VM A dan VM B menulis ke sektor disk yang sama tanpa koordinasi, akan terjadi fenomena Split-Brain yang menyebabkan kerusakan struktur metadata tabel filesystem instan (immediate filesystem corruption).

Untuk menggunakan Multi-Attach secara aman, kita wajib menggunakan Cluster-Aware Filesystem (seperti GFS2 atau OCFS2) yang memiliki mekanisme distributed lock manager, atau digunakan eksklusif untuk aplikasi terkluster khusus yang mengelola I/O disk di tingkat software aplikasi (seperti Oracle RAC). Bagi sebagian besar kebutuhan berbagi file, opsi File Storage jauh lebih aman dan direkomendasikan.

Snapshot: Mekanisme Backup Incremental yang Tangguh #

Snapshot adalah metode utama untuk melakukan backup volume block storage. Snapshot bekerja dengan cara mengambil salinan keadaan disk pada satu titik waktu tertentu (point-in-time copy).

Cara Kerja Incremental Snapshot: #

  • Snapshot Pertama: Sistem menyalin seluruh blok data yang digunakan (misalnya 100 GB) dan menyimpannya di platform object storage terenkripsi di belakang layar.
  • Snapshot Kedua: Sistem hanya melacak blok-blok data yang mengalami perubahan (delta change, misalnya 5 GB). Hanya blok 5 GB tersebut yang disalin. Ini membuat proses backup berjalan sangat cepat dan menghemat biaya penyimpanan.
  • Proses Restore: Meskipun snapshot bersifat inkremental, saat kita membuat volume baru dari Snapshot Kedua, sistem secara otomatis merakit kembali data utuh (100 GB) secara transparan.

Catatan Crash Consistency: Sebelum melakukan snapshot pada volume database produksi yang aktif, kita disarankan untuk menangguhkan (freeze) proses penulisan I/O database atau menggunakan utilitas sistem operasi seperti fsfreeze agar data di dalam memori cache OS ter-flush ke disk secara sempurna. Hal ini menjamin snapshot kita bersifat crash-consistent.

Contoh Kode: Membuat dan Mengotomatisasi Backup Volume via Terraform #

Berikut adalah contoh konfigurasi Terraform untuk mendeploy Virtual Machine EC2, membuat volume Persistent EBS tambahan bertipe GP3 dengan spesifikasi khusus, melakukan proses attachment, serta mengonfigurasi kebijakan backup otomatis (Data Lifecycle Manager) harian:

# ✓ BENAR: Gunakan Terraform untuk mendeploy Persistent Block Storage dengan kebijakan otomatisasi backup

# 1. Instans VM Utama
resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.private_az1.id

  tags = {
    Name = "production-app-vm"
  }
}

# 2. Membuat Volume Persistent EBS Tambahan (GP3)
resource "aws_ebs_volume" "app_data_vol" {
  availability_zone = "ap-southeast-1a"
  size              = 100 # Ukuran 100 GB
  type              = "gp3"
  iops              = 3000 # Provisioned IOPS dasar gp3
  throughput        = 125  # Throughput dasar gp3 (MB/s)

  tags = {
    Name = "production-app-data"
  }
}

# 3. Menempelkan (Attach) Volume ke Instans VM
resource "aws_volume_attachment" "ebs_att" {
  device_name = "/dev/sdh"
  volume_id   = aws_ebs_volume.app_data_vol.id
  instance_id = aws_instance.app_server.id
}

# 4. Kebijakan Otomatisasi Backup Harian (Lifecycle Policy)
resource "aws_dlm_lifecycle_policy" "daily_backup" {
  description        = "Kebijakan backup harian otomatis untuk volume produksi"
  execution_role_arn = aws_iam_role.dlm_lifecycle_role.arn
  state              = "ENABLED"

  policy_details {
    resource_types = ["VOLUME"]

    target_tags = {
      Name = "production-app-data"
    }

    schedule {
      name = "Daily Snapshots"

      create_rule {
        interval      = 24
        interval_unit = "HOURS"
        times         = ["20:00"] # Eksekusi jam 8 malam
      }

      retain_rule {
        count = 7 # Simpan snapshot selama 7 hari terakhir
      }

      copy_tags = true
    }
  }
}

Ringkasan #

  • Block storage menyajikan raw block device yang di-attach ke VM melalui jaringan khusus SAN (Storage Area Network) berlatensi rendah.
  • Ephemeral storage bersifat volatil dan datanya akan musnah seketika saat VM di-stop; gunakan hanya untuk data sementara seperti cache.
  • Persistent block storage memiliki siklus hidup indeks independen dari VM, menjamin keamanan data saat terjadi kegagalan VM induk.
  • Pilih protokol NVMe dibanding SCSI untuk meminimalkan antrean lock CPU saat melakukan operasi I/O paralel pada database multi-core.
  • Gunakan VM bertipe EBS-Optimized untuk memastikan bandwidth I/O antara instans dan storage backend tidak mengalami kemacetan network.
  • Aktifkan enkripsi bawaan transparan di tingkat hypervisor untuk mengamankan data disk tanpa membebani performa CPU VM.
  • Gunakan fitur Elastic Volumes untuk mengubah ukuran kapasitas dan performa disk secara langsung di produksi tanpa memicu downtime reboot.
  • Gunakan Multi-Attach secara bijak hanya dengan cluster filesystem (seperti GFS2) guna mengantisipasi bahaya split-brain yang merusak data.
  • Lakukan backup periodik via Snapshot Incremental yang efisien, dan pastikan crash-consistency sebelum snapshot dieksekusi pada database aktif.

← Sebelumnya: Object Storage   Berikutnya: File Storage →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact