Belajar Kubernetes Block Storage RWO - Mengapa Database Butuh Block Storage

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — cluster 5 node, open-iscsi, dan nfs-common — pada episode ini kita menjawab pertanyaan paling mendasar: kenapa sih database harus pakai block storage? Studi kasus kita adalah aplikasi Laravel dengan database PostgreSQL.

Mengapa ini penting dipahami sebelum menyentuh Longhorn? Karena seluruh keputusan arsitektur di series ini — memilih RWO, memakai StatefulSet, mereplikasi volume — berakar dari satu fakta: database menulis data secara eksklusif dan membutuhkan jaminan durability pada setiap transaksi. Begitu kalian paham "mengapa", semua konfigurasi teknis berikutnya jadi masuk akal sendiri.

#Kasus: Laravel + PostgreSQL

#Di Mana Data Aplikasi Laravel Disimpan

Aplikasi Laravel seperti toko online menyimpan data inti di database:

• Tabel users (akun pelanggan).
• Tabel posts atau products (konten/produk).
• Tabel orders (transaksi bisnis).

Semua tabel ini hidup di PostgreSQL. Ceritanya: aplikasi Laravel adalah stateless — bisa di-scale berapa pun replikanya. Tapi PostgreSQL adalah stateful — datanya harus bertahan meski Pod dihapus, restart, atau dipindah node.

#Database Menyimpan Data di Block Device

PostgreSQL tidak menyimpan data sebagai file di dalam shared folder. Secara internal, ia memakai:

• WAL (Write-Ahead Log): setiap perubahan ditulis ke WAL dulu sebelum data page diubah.
• Data files: page berukuran 8 KB yang di-flush ke disk.
• fsync: memaksa kernel menulis data dari page cache ke media penyimpanan.

Dengan kata lain, PostgreSQL butuh block device mentah yang bisa di-fsync, diakses O_DIRECT, dan dimiliki eksklusif oleh satu writer pada satu waktu.

#Mengapa Database Sulit Dipakai di Shared Filesystem

#Masalah NFS dan Network Filesystem

Bayangkan dua skenario:

1. NFS — model jaringan klien-server. Setiap fsync lewat jaringan menambah latency dan rawan hilang kalau koneksi terputus di tengah penulisan.
2. Panic di database: kalau dua proses menulis file WAL yang sama lewat NFS tanpa locking yang benar, data page bisa korup.

Kesimpulan yang didukung banyak vendor database (PostgreSQL, MySQL): jangan letakkan data utama database di shared filesystem. Alasannya konkret:

• fsync tidak dijamin benar-benar durable di semua implementasi NFS.
• O_DIRECT sering tidak didukung atau tidak masuk akal lewat mount jaringan kuno.
• Latency setiap I/O naik drastis karena harus round-trip ke server file.

#Yang Lebih Aman: Block Storage

Block storage memberikan apa yang database butuhkan:

Block storage diakses satu node pada satu waktu → access mode RWO (ReadWriteOnce).

#Access Mode RWO (ReadWriteOnce)

#Arti RWO

RWO artinya volume hanya bisa di-mount read-write oleh satu node pada satu waktu. Cocok untuk pola database: satu primary, satu node yang menulis.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-postgres
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-ha
  resources:
    requests:
      storage: 10Gi

Bersamaan dengan PVC ini, kita akan memakai StorageClass longhorn-ha dari Longhorn (detail di episode 5).

#Hati-Hati: RWO Bukan RWX

Error paling umum di production:

Ingat: menyediakan 2 replica Pod database dengan volume RWO yang sama akan membuat salah satu gagal attach, atau — jika dipaksa — dua proses menulis ke satu filesystem. Keduanya berbahaya.

#StatefulSet vs Deployment untuk Database

#Deployment Itu untuk Aplikasi Stateless

Deployment memberi Pod ID acak (laravel-5f4d9-xyz). Kalau replica di-scale, Pod baru tidak peduli Pod lama. Cocok untuk Laravel, API, worker.

Tapi untuk database? Deployment memaksa semua replica pada PVC yang sama. Dua PostgreSQL menulis ke satu volume = bencana.

#StatefulSet Memberi Identitas Stabil

StatefulSet memberi nomor ordinal: pg-0, pg-1, dst. Setiap Pod terikat PVC sendiri lewat volumeClaimTemplates:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: longhorn-ha
        resources:
          requests:
            storage: 10Gi

Ini menghasilkan PVC bernama data-postgres-0 yang tidak akan dihapus saat Pod di-delete. Database tetap persisten meski Pod restart atau pindah node.

#Ringkasan Praktis

Berikut peta keputusan untuk workload database:

• Butuh menulis data secara eksklusif → block storage, RWO.
• Ingin replika baca untuk beban besar → replika terpisah dengan PVC sendiri.
• Pod harus punya identitas stabil + PVC permanen → StatefulSet.
• Aplikasi bisa dibagi ke banyak Pod tanpa state → Deployment (tetap boleh RWO untuk media sharing semacam NFS).

#Penutup

Inti yang harus dibawa pulang:

• Database butuh fsync, O_DIRECT, dan volume eksklusif → block storage, bukan NFS.
• RWO = satu node menulis pada satu waktu; cocok untuk pola database.
• RWO ≠ RWX — jangan bagikan volume database ke multi-writer.
• StatefulSet + volumeClaimTemplates menjamin PVC dan data tetap hidup saat Pod dihapus.

Di episode 2 selanjutnya kita akan membahas arsitektur Longhorn & konsep replikasi block — apa itu Longhorn, komponen utama (Engine, Replica, Share Manager), perbedaan V1 vs V2 Data Engine, dan cara kerja replikasi sinkron yang membuat data aman. Sampai jumpa di episode 2!