Belajar RAID - RAID-as-a-Service & Cloud

#Pendahuluan

Di cloud, disk virtual tidak lagi terlihat seperti fisik — tapi konsep RAID tetap hidup. Episode 20 ini membahas bagaimana prinsip striping, mirroring, dan parity diterapkan di EBS, NVMe cloud, Kubernetes, dan Ceph. Kalian akan melihat bahwa RAID berubah bentuk, bukan hilang.

Perbedaan terbesar di cloud: redundancy sudah disediakan provider di lapisan bawah. EBS mereplikasi data di beberapa storage node tanpa sepengetahuan kalian. Karena itu, strategi RAID di cloud harus dihitung ulang — menggandakan EBS untuk mirror kadang membuang biaya, kadang justru satu-satunya cara menambah IOPS.

#EBS RAID di EC2

#Membuat RAID 0 dari EBS

Kebutuhan paling umum di EC2 adalah RAID 0 untuk menggabungkan throughput dan IOPS beberapa volume EBS. EBS mereplikasi data, jadi striping di atasnya tidak perlu redundancy lagi:

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

Perintah mdadm --create --level=0 di atas menggabungkan dua EBS yang sudah terpasang. Volume EBS di instance modern muncul sebagai /dev/nvmeNn1. RAID 0 di sini murni untuk performa — redundancy sudah ada di lapisan EBS.

#RAID 10 untuk Workload Tulis Berat

Untuk database yang butuh IOPS tinggi sekaligus toleransi kegagalan volume individual, RAID 10 atas empat EBS adalah pola yang umum:

sudo mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1

Output mdadm --create --level=10 menampilkan array yang aktif. Sebelum memakai RAID 10 di EBS, periksa karakter IOPS per volume: satu volume provisioned IOPS sudah bisa melampaui kebutuhan banyak workload — RAID hanya menambah kompleksitas jika benar-benar perlu.

#Snapshot dan Backup EBS

EBS punya snapshot bawaan yang mengambil state volume ke S3:

aws ec2 create-snapshot --volume-id vol-0abc1234 --description "backup mingguan"

Perintah aws ec2 create-snapshot membuat snapshot EBS. Snapshot adalah lapisan backup kalian di cloud — setara dengan snapshot ZFS, dikelola oleh provider. Gunakan untuk recovery saat instance gagal.

#Managed RAID dan NVMe Cloud

#Layanan yang Menyembunyikan RAID

Cloud modern menawarkan managed storage yang menyembunyikan detail RAID: EBS provisioned IOPS, instance store NVMe, dan layanan SAN seperti AWS EFS atau volume block di provider lain. Kalian tidak perlu membuat array — provider yang memutuskan penempatan dan replikasi.

#Instance Store NVMe

Sebagian instance punya instance store NVMe — disk terpasang langsung ke instance, sangat cepat tapi ephemeral (hilang saat instance berhenti). Untuk workload yang butuh NVMe bersejajar, gabungkan dengan striping:

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1

Stripe instance store memberi throughput besar untuk cache dan data sementara — selama kalian sadar datanya tidak persisten.

#Object Storage sebagai Layer Redundancy

#Mengapa Object Storage Melampaui RAID

Object storage (S3, R2, GCS) menyimpan data sebagai objek dengan redundancy lintas zona di lapisan provider. Ini mewujudkan mimpi yang tidak bisa dicapai RAID: data yang selamat meski seluruh ruang data di satu lokasi hilang. Gunakan sebagai lapisan terluar pertahanan:

rclone sync /mnt/raid s3:backup-bucket/data

Perintah rclone sync menyinkronkan data array ke bucket S3. Kombinasikan dengan siklus backup otomatis untuk memenuhi aturan 3-2-1 yang kita bahas di episode 12.

#RAID di Kubernetes

#Local Persistent Volumes

Di Kubernetes, local persistent volumes mengekspos disk atau array lokal node ke pod. Local PV mengharuskan pod dijadwalkan ke node yang tepat memakai affinity. Array mdadm di node bisa diekspos sebagai local PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-md0
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/raid
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node-storage

Manifest PersistentVolume di atas mengekspos /mnt/raid pada node tertentu sebagai local PV. Data tetap disimpan di array mdadm; Kubernetes tinggal mengelola lifecycle volume.

#Abstraksi dengan Rook dan Ceph

Untuk storage terdistribusi yang tahan node gagal, banyak cluster memakai Rook, operator Kubernetes yang mengelola Ceph:

• Ceph mendistribusikan data dan parity ke banyak node — RAID dalam skala cluster.
• Rook otomatis membuat pools, mengelola OSD, dan menyediakan StorageClass.
• CrushMap menentukan penempatan replika secara independen per node.

Dengan Rook dan Ceph, redundancy tidak lagi terikat satu mesin — satu node mati tidak menghentikan data. Ini evolusi alami konsep RAID di era cloud-native.

#Penutup

Episode 20 membawa kalian ke dunia cloud dan Kubernetes: RAID 0 dan 10 di atas EBS, managed storage yang menyembunyikan detail RAID, object storage sebagai lapisan redundancy, serta local PV dan Rook dengan Ceph sebagai abstraksi storage terdistribusi.

Inti yang harus dibawa pulang:

• EBS sudah mereplikasi data; RAID 0 di atasnya untuk performa, bukan redundancy.
• RAID 10 atas empat EBS untuk workload tulis berat yang butuh toleransi.
• Snapshot EBS adalah lapisan backup standar di cloud.
• Instance store NVMe cepat tapi ephemeral — hanya untuk data sementara.
• Object storage memberi redundancy lintas lokasi yang tidak bisa RAID.
• Rook dan Ceph menghadirkan RAID dalam skala cluster Kubernetes.

Di episode 21 selanjutnya kita akan membahas fitur modern & roadmap — lockless bitmap dan perbaikan boot mdadm 4.6, OpenZFS 2.4 dengan RAIDZ expansion, AnyRaid, dan BRT, serta arah tren menuju software-defined storage berintegritas. Kalian akan melihat peta jalan teknologi RAID.