File Storage #

Dalam arsitektur komputasi cloud, File Storage (sering disebut sebagai penyimpanan berkas terbagi atau Shared File Systems) adalah layanan penyimpanan terkelola yang menyajikan data dalam bentuk hierarki direktori dan berkas standar. Berbeda dengan block storage yang dipasang sebagai perangkat disk mentah eksklusif untuk satu mesin virtual, atau object storage yang diakses secara flat menggunakan API HTTP, file storage dirancang khusus untuk mendukung akses konkuren dari banyak instans virtual secara bersamaan (multi-instance concurrent access). Layanan ini mematuhi semantik sistem berkas standar (seperti POSIX) sehingga aplikasi kita dapat membaca, menulis, membuat folder, dan mengunci file secara bersamaan menggunakan protokol jaringan standar seperti NFS (Network File System) untuk Linux atau SMB (Server Message Block) untuk Windows. Artikel ini akan membedah secara mendalam mekanisme kerja, protokol, perbandingan performa, serta panduan praktis dalam memilih dan mengoptimalkan file storage di cloud.

Cara Kerja dan Arsitektur File Storage #

Secara fisik, file storage di lingkungan cloud diimplementasikan sebagai kluster penyimpanan terdistribusi yang dikelola secara penuh oleh penyedia cloud (managed NAS/Network Attached Storage). Kluster ini mengekspos satu atau beberapa titik akses jaringan (mount targets) di dalam Virtual Private Cloud (VPC) kita. Instans Virtual Machine (VM) kita kemudian terhubung ke mount target tersebut menggunakan protokol sistem berkas jaringan.

flowchart TD
    subgraph VPC ["Virtual Private Cloud (VPC)"]
        VM1["Instans App Server 1<br>(Linux /mount/shared)"]
        VM2["Instans App Server 2<br>(Linux /mount/shared)"]
        VM3["Instans App Server 3<br>(Linux /mount/shared)"]
        
        MountTarget["Mount Target Jaringan<br>(IP Private: 10.0.1.50)"]
        
        VM1 -->|"NFS v4 (TCP Port 2049)"| MountTarget
        VM2 -->|"NFS v4 (TCP Port 2049)"| MountTarget
        VM3 -->|"NFS v4 (TCP Port 2049)"| MountTarget
    end
    
    subgraph StorageService ["Cloud Managed File Storage Service"]
        Controller["Storage Controller Layer<br>(Metadata & Lock Management)"]
        PhysicalDisks["Physical Storage Pool<br>(Redundant SSD/HDD Array)"]
        
        MountTarget --> Controller
        Controller --> PhysicalDisks
    end

Mekanisme Sinkronisasi dan Akses Konkuren #

Ketika Instans 1 menulis berkas baru ke direktori /mount/shared/data.txt, urutan operasi berikut terjadi:

1. Penerjemahan OS: Aplikasi pada Instans 1 memanggil API sistem berkas standar (seperti write() di Linux). Driver kernel sistem operasi mengubah operasi ini menjadi perintah protokol jaringan NFS/SMB.
2. Pengiriman via Jaringan: Perintah dikirimkan melalui koneksi TCP jaringan private menuju Mount Target.
3. Penyimpanan Redundan: Kontroler penyimpanan menerima data, memperbarui metadata sistem berkas (seperti inode, ukuran berkas, dan penanda waktu), menulis blok data ke disk fisik yang ter-replikasi, dan mengirimkan respons kembali.
4. Visibilitas Instan: Ketika Instans 2 melakukan panggilan read() pada lokasi berkas yang sama beberapa milidetik kemudian, perintah dikirimkan ke target akses yang sama dan langsung mendapatkan data terbaru yang ditulis oleh Instans 1.

Kemampuan ini disebut sebagai konsistensi baca-setelah-tulis (read-after-write consistency) di seluruh instans yang terhubung. Hal ini sangat krusial untuk arsitektur aplikasi web terdistribusi di mana satu pengguna mengunggah gambar melalui Server 1, dan pengguna lain harus segera dapat mengunduh gambar tersebut dari Server 2.

Protokol Utama: NFS dan SMB/CIFS #

Penyedia cloud biasanya memisahkan layanan file storage mereka berdasarkan sistem operasi target dan protokol jaringan yang digunakan. Memilih protokol yang salah dapat berdampak buruk pada kompatibilitas fitur dan performa aplikasi kita.

1. NFS (Network File System) #

NFS adalah protokol standar de facto untuk berbagi berkas di lingkungan Unix dan Linux. Versi terbaru yang umum digunakan di cloud adalah NFS v4 (NFSv4.1 atau NFSv4.2).

• Kelebihan: Mendukung fitur POSIX secara penuh termasuk izin akses berkas terperinci (user/group permissions), tautan simbolik (symbolic links), penguncian berkas (file locking), dan deteksi stateful untuk koneksi klien.
• Keamanan: Akses dikendalikan di tingkat jaringan menggunakan aturan firewall VPC (security groups) dan kebijakan otorisasi internal cloud (seperti IAM policy).
• Opsi Mount di Linux: Untuk mendapatkan performa optimal dan stabilitas saat terjadi gangguan jaringan, kita harus menyetel parameter pemasangan (mount options) dengan sangat hati-hati pada file /etc/fstab.

# Contoh konfigurasi mount NFSv4 yang dioptimalkan di Linux (/etc/fstab)
# BENAR: Menggunakan opsi optimasi untuk performa dan toleransi kegagalan jaringan
fs-xxxxxx.efs.ap-southeast-1.amazonaws.com:/ /mnt/shared nfs4 defaults,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0

# Penjelasan opsi di atas:
# - rsize & wsize: Menetapkan ukuran maksimum blok data (1 MB) untuk operasi baca/tulis guna mengurangi overhead jaringan.
# - hard: Memastikan sistem operasi akan terus mencoba kembali (retry) jika koneksi ke storage terputus, mencegah aplikasi crash karena kehilangan write disk.
# - timeo=600: Menunggu 60 detik sebelum mencoba kembali jika terjadi timeout.
# - retrans=2: Melakukan maksimum 2 kali percobaan kembali sebelum menganggap timeout terjadi.
# - _netdev: Memberi tahu OS untuk menunda mount disk ini saat booting sampai kartu jaringan aktif.

2. SMB (Server Message Block) / CIFS #

SMB adalah protokol asli yang dikembangkan oleh Microsoft untuk Windows. Di cloud, layanan seperti Azure Files atau AWS FSx for Windows File Server menyediakan implementasi SMB yang dikelola secara penuh.

• Integrasi Active Directory: SMB mendukung integrasi penuh dengan Microsoft Active Directory (AD). Ini berarti kita dapat menerapkan izin akses folder yang sangat spesifik berdasarkan pengguna dan grup yang ada di domain perusahaan kita menggunakan Access Control Lists (ACLs) NTFS bawaan Windows.
• Fitur Lanjutan: Mendukung enkripsi data dalam perjalanan (in-transit encryption) secara bawaan mulai dari protokol SMB 3.0, serta teknik optimasi SMB Multichannel untuk menggabungkan beberapa koneksi jaringan guna melipatgandakan throughput.

# Contoh perintah PowerShell untuk melakukan mount SMB share di Windows Server
# ✓ BENAR: Menggunakan enkripsi SMB 3.0 dan menyimpan kredensial dengan aman
New-SmbMapping -LocalPath "Z:" -RemotePath "\\fs-xxxx.file.core.windows.net\sharedfolder" -UserName "AD\admin_user" -Password "SecurePassword123"

Perbandingan Komprehensif: Object vs Block vs File Storage #

Untuk membantu kita menentukan pilihan teknologi penyimpanan yang tepat, mari kita bandingkan karakteristik mendasar ketiga jenis storage ini dalam tabel berikut:

(Catatan: Beberapa penyedia cloud menyediakan fitur Multi-Attach Block Storage, namun memerlukan sistem berkas terdistribusi khusus seperti GFS2 atau OCFS2 di tingkat aplikasi untuk menghindari korupsi data).

Kapan Memilih File Storage (Skenario Ideal) #

File storage sangat ideal digunakan ketika aplikasi kita membutuhkan karakteristik berikut:

1. Migrasi Aplikasi Warisan (Lift-and-Shift) #

Banyak aplikasi perusahaan tua (legacy apps) yang dirancang untuk berjalan di server lokal berasumsi bahwa mereka memiliki akses ke sistem berkas lokal. Aplikasi ini sering kali menggunakan operasi kode seperti membuka file di /var/app/uploads/data.csv, menulis ke tengah berkas, atau menggunakan penguncian file tingkat OS (POSIX file lock).

• Solusinya: Mengubah kode aplikasi tersebut untuk menggunakan API Object Storage (seperti AWS S3 SDK) akan memakan biaya dan waktu pengembangan yang sangat besar. Dengan memasang (mounting) file storage terbagi di cloud ke direktori yang sama pada semua instans VM baru, aplikasi tersebut dapat langsung berjalan tanpa perubahan kode satu baris pun.

2. Berbagi Data untuk Kluster Server Web (Shared Content) #

Skenario klasik di mana kita menjalankan sekelompok server web di belakang Load Balancer (misalnya kluster WordPress atau Drupal).

• Kebutuhan: Ketika admin mengunggah tema baru atau pengguna mengunggah berkas gambar, berkas tersebut harus dapat dibaca secara instan oleh semua instans server web lainnya.
• Implementasi: Dengan memasang direktori wp-content/uploads ke file storage jaringan, seluruh server web akan selalu melihat daftar gambar yang konsisten dan sinkron secara real-time.

flowchart TD
    LB["Load Balancer"] --> Web1["Web Server 1"]
    LB --> Web2["Web Server 2"]
    
    subgraph Storage ["Penyimpanan Bersama"]
        SharedFS["Shared File Storage<br>(NFS /mnt/uploads)"]
    end
    
    Web1 -->|"Tulis Gambar Baru"| SharedFS
    Web2 -->|"Baca Gambar Baru"| SharedFS

3. Pipeline Pemrosesan Data & Machine Learning #

Dalam beberapa pipeline data ilmiah atau pelatihan machine learning (ML), kita memiliki kluster instans komputasi GPU yang besar yang perlu membaca dataset yang sama untuk memproses analisis paralel.

• Keunggulan: Dataset raksasa diletakkan di satu file storage pusat. Setiap node worker membaca bagian dataset-nya masing-masing secara acak, dan menuliskan hasil analisisnya ke folder output yang terbagi.

Kapan Harus Menghindari File Storage (Anti-Pattern) #

Meskipun fleksibel, file storage memiliki keterbatasan arsitektur yang signifikan. Menggunakan file storage untuk workload yang tidak sesuai akan berujung pada performa buruk dan pembengkakan biaya.

1. Jangan Gunakan untuk Database OLTP (Transactional Database) #

Sangat menggoda untuk meletakkan file data database MySQL, PostgreSQL, atau Oracle kita di atas file storage dengan alasan agar data mudah di-backup atau agar database bisa dialihkan ke server cadangan dengan mudah.

• ANTI-PATTERN: Database transaksional OLTP melakukan operasi tulis acak berukuran kecil (misalnya halaman data 8 KB atau 16 KB) dengan frekuensi sangat tinggi secara terus-menerus. Karena file storage berada di jaringan, setiap penulisan database akan mengalami latensi round-trip jaringan tambahan. Ini akan memicu antrean I/O yang panjang (write queue stagnation), performa transaksi drop drastis, dan risiko korupsi berkas akibat kegagalan sinkronisasi kunci (lock contention).
• BENAR: Untuk database, selalu gunakan Block Storage (seperti AWS EBS gp3/io2 atau Azure Premium SSD) yang ditempelkan langsung ke satu instans database server. Jika membutuhkan replikasi data, lakukan di tingkat database (seperti replikasi master-slave atau arsitektur active-passive database clustering), bukan di tingkat storage.

// ANTI-PATTERN: Konfigurasi direktori data database MySQL pada mount NFS
[mysqld]
datadir=/mnt/shared-nfs/mysql/data  // JANGAN: Memicu latensi jaringan tinggi & korupsi data!

// BENAR: Konfigurasi direktori data pada local block storage
[mysqld]
datadir=/var/lib/mysql              // ✓ BENAR: Latensi sub-milidetik dengan SSD block device

2. Jangan Gunakan untuk Data Inaktif (Cold Data & Backup) #

Menyimpan cadangan sistem (backup image), berkas arsip laporan keuangan 5 tahun lalu, atau log sistem di file storage adalah pemborosan anggaran yang besar.

• Masalah Biaya: Harga per GB file storage berkisar 3 hingga 5 kali lipat lebih mahal daripada object storage standard, dan bisa mencapai 10 hingga 20 kali lipat jika dibandingkan dengan object storage tier archive (seperti Glacier Deep Archive).
• Solusi: Tulis skrip cadangan untuk langsung mengunggah file hasil backup ke object storage menggunakan CLI penyedia cloud, bukan menyimpannya di folder NFS yang terpasang.

3. Workload dengan Jutaan Berkas Kecil (Small File I/O Workload) #

Workload seperti proses instalasi dependensi Node.js (npm install yang membuat folder node_modules dengan jutaan file javascript kecil) atau kompilasi kode sumber C++ berskala besar.

• Mengapa Lambat?: Setiap operasi berkas (seperti mengecek keberadaan berkas, membuka berkas, membaca metadata) memerlukan perjalanan bolak-balik jaringan (network round-trip). Jika sebuah proses harus membaca 10.000 file berukuran 1 KB secara berurutan, latensi jaringan 5ms per file akan terakumulasi menjadi: $$10.000 \times 5\text{ ms} = 50\text{ detik}$$ Padahal jika dijalankan di SSD block storage lokal, operasi yang sama hanya memakan waktu kurang dari 1 detik.
• Solusi: Lakukan proses build dan kompilasi di direktori lokal VM (misalnya di /tmp yang menggunakan ephemeral block storage lokal), kemudian kompres hasilnya menjadi satu file tarball (.tar.gz), baru kirimkan file kompresi tersebut ke shared file storage.

Manajemen Performa: Throughput Mode dan Kunci File #

Performa file storage di cloud diatur oleh aturan penentuan throughput dan mekanisme penguncian berkas terdistribusi.

1. Karakteristik Mode Throughput #

Penyedia cloud biasanya menawarkan beberapa model penentuan performa untuk file storage:

• Bursting Mode: Throughput bawaan scale-up secara dinamis berbanding lurus dengan kapasitas data yang kita simpan. Semakin banyak data yang kita simpan, semakin tinggi throughput dasar yang kita dapatkan. Jika kita membutuhkan throughput tinggi untuk data berukuran kecil, kita diberikan “credit burst” yang dapat habis jika digunakan secara terus-menerus.
• Provisioned Mode: Kita membayar biaya tambahan untuk mengunci throughput spesifik (misalnya 100 MB/s) terlepas dari seberapa kecil data yang kita simpan di dalamnya. Mode ini sangat disarankan untuk aplikasi web produksi dengan pola traffic yang stabil.
• Elastic Mode (Auto-scaling): Layanan mengukur performa secara real-time dan secara otomatis menyesuaikan alokasi throughput berdasarkan beban kerja aplikasi kita, dengan tagihan dinamis berdasarkan jumlah transaksi.

2. Mekanisme Penguncian Berkas (Distributed File Locking) #

Ketika ratusan instans VM menulis ke sistem berkas yang sama, penguncian berkas sangat penting untuk mencegah tumpang tindih data yang berujung pada kerusakan file. NFS v4 mengelola hal ini menggunakan mekanisme kunci berbasis status lease (lease-based stateful locks).

• Advisory Locking: Secara bawaan, penguncian bersifat opsional. Aplikasi harus secara aktif meminta kunci sebelum menulis berkas (misalnya menggunakan fungsi flock() di Python atau Linux system call).
• Bottleneck Kunci: Jika banyak instans mencoba menulis berkas yang sama secara bersamaan, mereka akan mengalami hambatan antrean kunci (lock contention). Kontroler metadata akan sibuk mengelola daftar antrean kunci, menurunkan throughput keseluruhan sistem berkas kita.
• Rekomendasi Arsitektur: Rancang sistem agar instans yang berbeda menulis ke berkas dengan nama unik (misalnya menyertakan ID instans dan timestamp: data_worker01_1718910000.json), kemudian gunakan proses penggabungan berkas (consolidation worker) terpisah di latar belakang jika data perlu disatukan.

Ringkasan #

• File storage menyediakan sistem berkas terbagi (shared file systems) yang dapat di-mount oleh ribuan instans virtual secara bersamaan menggunakan protokol standar NFSv4 atau SMB3.
• Niche utama layanan ini adalah pemenuhan kompatibilitas POSIX dan visibilitas data instan di seluruh server aplikasi web terdistribusi secara konsisten.
• Sangat cocok untuk migrasi Lift-and-Shift aplikasi perusahaan yang bergantung pada struktur folder dan operasi file OS tradisional tanpa harus menulis ulang kode.
• Merupakan anti-pattern untuk database OLTP karena latensi round-trip jaringan yang tinggi akan merusak performa penulisan acak database dan berisiko korupsi data.
• Hindari menjalankan operasi I/O jutaan berkas kecil secara berurutan (seperti dependensi kode atau kompilasi) karena overhead protokol jaringan per-operasi akan memperlambat proses secara drastis.
• Gunakan opsi mount yang dioptimalkan di Linux (seperti penyetelan rsize/wsize besar dan opsi hard retry) untuk memastikan sistem tahan terhadap gangguan jaringan minor.

← Sebelumnya: Block Storage   Berikutnya: Durability vs Availability →