Belajar Linux Filesystem - Cloud & Managed Storage
Episode 19 of 23

Belajar Linux Filesystem - Cloud & Managed Storage

Di cloud, filesystem lokal hidup berdampingan dengan layanan storage terkelola. Episode ini membahas instance store vs EBS/gp3, filesystem untuk cloud images, object storage S3-compatible, lalu EFS, Azure Files, dan GCP Filestore serta kapan harus memakai masing-masing.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Konsep filesystem yang kalian pelajari sejauh ini tetap berlaku di cloud — hanya saja ada lapisan baru yang harus dipahami: instance store yang menghilang, EBS yang bertahan tapi mahal, dan object storage yang menawarkan skala hampir tak terbatas. Episode 19 memetakan lanskap storage cloud.

Kita bandingkan instance store vs EBS/gp3, bahas filesystem yang tepat untuk cloud images, lalu kenali object storage S3-compatible sebagai layer yang terpisah. Terakhir, kita bandingkan managed file system — EFS, Azure Files, dan GCP Filestore — dan kapan memakai storage lokal versus terdistribusi.

Tujuannya: kalian tidak lagi melihat storage cloud sebagai satu hal, melainkan spektrum pilihan dengan karakteristik sangat berbeda.

Instance Store vs EBS

Instance Store: Cepat tapi Sementara

Instance store adalah disk yang menempel langsung pada physical host VM — NVMe yang sangat cepat, tapi data hilang saat instance dihentikan atau dimigrasi.

Cocok untuk:

  • Cache, scratch space, dan data yang bisa dibangun ulang.
  • Workload yang butuh latency terendah.

Tidak cocok untuk:

  • Data yang harus bertahan dari instance restart atau termination.

Periksa instance store di EC2 Linux:

Lihat instance store
lsblk

Perangkat seperti /dev/nvme1n1 yang tidak ada di volume attachment biasanya instance store — periksa dengan df -hT untuk melihat mana yang sudah diformat.

EBS/gp3: Persistent tapi Terjaring

EBS adalah block storage yang melewati jaringan storage — lebih lambat dari instance store, tapi data bertahan melewati restart instance. Volume gp3 adalah tipe default modern:

Mount EBS volume
sudo mkfs.ext4 /dev/nvme0n1
sudo mount /dev/nvme0n1 /mnt/data

gp3 memungkinkan provision IOPS dan throughput secara terpisah dari ukuran — sesuatu yang tidak dimiliki gp2. Karena EBS bersifat block device, semua pengetahuan filesystem episode sebelumnya berlaku langsung: ext4, XFS, bahkan ZFS di atasnya.

Filesystem untuk Cloud Images

Standar: ext4 dan XFS

Sebagian besar cloud images Linux memakai ext4 untuk root — alasan yang sama dengan on-premise: kesederhanaan dan dukungan bootloader yang matang. RHEL-based images memakai XFS.

Gunakan blkid untuk melihat filesystem yang dipakai image:

Cek filesystem image
sudo blkid

Snapshot Volume sebagai Backup

EBS snapshot adalah mekanisme backup utama di cloud. Karena beroperasi di level block, EBS snapshot bisa menangkap ext4, XFS, btrfs, atau ZFS tanpa peduli isinya:

Buat EBS snapshot
aws ec2 create-snapshot --volume-id vol-0abcd1234efgh5678 --description "Backup harian"

Untuk konsistensi, freeze filesystem dulu (seperti episode 9):

Freeze sebelum snapshot EBS
sudo fsfreeze --freeze /mnt/data
aws ec2 create-snapshot --volume-id vol-0abcd1234efgh5678
sudo fsfreeze --unfreeze /mnt/data

Pola fsfreeze + snapshot cloud memberi backup yang konsisten bahkan untuk filesystem yang tidak mendukung snapshot native.

Object Storage: Layer Terpisah

S3-Compatible Object Storage

Object storage (S3, MinIO, Ceph RGW) bukan filesystem — ia menyimpan objek dengan key, tanpa hierarki direktori dan tanpa update in-place. Sifatnya berbeda total:

  • Skala praktis tak terbatas (petabyte+).
  • Konsistensi eventual pada beberapa provider.
  • Operasi berbasis HTTP API, bukan mount.

Interaksi normal adalah melalui CLI, bukan mount:

Upload objek ke S3
aws s3 cp /mnt/data/arsip.tar.gz s3://bucket-saya/backup/

Kapan Memakai Object Storage

Object storage paling cocok untuk:

  • Backup dan arsip yang jarang diakses.
  • Aset statis (media, distribusi aplikasi).
  • Data lake dan log terpusat.

Bukan untuk:

  • Database dengan operasi in-place.
  • Beban yang butuh semantik file (locking, rename atomik).

Ingat pemisahan peran: filesystem untuk komputasi, object storage untuk arsip. Keduanya hidup berdampingan, bukan bersaing.

Managed Filesystem: EFS, Azure Files, Filestore

EFS dan Azure Files

EFS (AWS) dan Azure Files adalah NFS/SMB terkelola yang bisa di-mount ke banyak instance sekaligus:

Mount EFS ke instance
sudo mount -t nfs4 fs-0a1b2c3d4e.efs.us-east-1.amazonaws.com:/ /mnt/efs

Kelebihan: skala otomatis, multi-AZ, dan shared access antar instance. Kekurangan: latency lebih tinggi dan harga lebih mahal daripada EBS per gigabyte.

GCP Filestore

GCP Filestore menawarkan NFS terkelola dengan tiga tier performa (basic, high, enterprise):

Mount Filestore
sudo mount -o nolock filestore-ip:/vol1 /mnt/filestore

Enterprise tier menyediakan high availability dan backup bawaan — cocok untuk data yang butuh shared storage tanpa mengelola NFS sendiri.

Kapan Lokal, Kapan Terdistribusi

Pertanyaan Penentu

Gunakan tiga pertanyaan ini:

  1. Apakah data harus dibagi antar instance? Ya → managed FS atau object storage.
  2. Apakah workload butuh latency rendah? Ya → EBS/instance store lokal.
  3. Apakah data bisa dibangun ulang? Ya → instance store yang murah.

Pola Arsitektur yang Umum

Kombinasi yang sering muncul di produksi:

  • Database: EBS gp3 dengan filesystem di atasnya (ext4/XFS) — butuh konsistensi dan latency.
  • Cache dan scratch: instance store NVMe — cepat dan boleh hilang.
  • Media dan arsip: object storage — skala besar dan murah.
  • Shared file kecil: EFS/Filestore — akses bersama antar banyak pod.

Sebuah arsitektur sehat biasanya memakai ketiganya sekaligus — bukan satu jawaban tunggal.

Penutup

Cloud tidak menghapus filesystem — ia menambah lapisan pilihan di sekitarnya. Instance store memberi kecepatan mentah, EBS memberi persistensi dengan semua pengetahuan filesystem yang sudah kalian miliki, dan object storage serta managed FS membuka dimensi skala yang baru. Kuncinya adalah memahami peran masing-masing.

Inti yang harus dibawa pulang:

  • Instance store cepat tapi sementara; EBS/gp3 persisten tapi lebih lambat.
  • Cloud images standar memakai ext4 atau XFS — blkid untuk memastikan.
  • EBS snapshot membackup semua filesystem di level block; freeze dulu untuk konsistensi.
  • Object storage S3 bukan filesystem — gunakan untuk arsip, bukan database.
  • EFS, Azure Files, dan Filestore untuk shared storage terkelola multi-instance.
  • Arsitektur sehat memakai kombinasi: lokal untuk latency, managed untuk sharing, objek untuk skala.

Di episode 20 selanjutnya kita membahas fitur modern dan roadmap — block-group-tree btrfs, BRT dedup dan AnyRaid ZFS, feature flags ref, skala exabyte ZFS 256-bit, NFS/CIFS sebagai lapisan network filesystem, serta roadmap btrfs-progs 8.x dan OpenZFS 2.5/2.6. Kalian akan melihat ke mana arah filesystem Linux.

Belajar Linux Filesystem - Cloud & Managed Storage | Belajar Linux Filesystem