Ceph — Konsep & Arsitektur#

Dokumentasi konsep Ceph sebagai pembanding ZFS/LVM — konteks: evaluasi distributed storage untuk cluster Incus 4 node (alternatif QNAP iSCSI sebagai shared storage).

1. Big Picture#

ZFS/LVM itu scale-up: satu box, disk lokal, redundancy di level disk (RAID/vdev). Ceph itu scale-out: storage tersebar di banyak server, akses via network, redundancy di level objek yang direplikasi antar server.

flowchart TD
    subgraph clients["Client interfaces"]
        RBD["RBD<br/><small>block device — mirip zvol</small>"]
        CephFS["CephFS<br/><small>shared filesystem</small>"]
        RGW["RGW<br/><small>object storage, S3-compatible</small>"]
    end

    clients --> Pool["Pool<br/><small>namespace + aturan replika / erasure coding</small>"]
    Pool --> PG["PG — placement group<br/><small>unit sharding objek</small>"]
    PG --> CRUSH["CRUSH<br/><small>algoritma penempatan, tanpa lookup table</small>"]

    CRUSH --> O1["OSD<br/>node1"]
    CRUSH --> O2["OSD<br/>node2"]
    CRUSH --> O3["OSD<br/>node3"]
    CRUSH --> O4["OSD<br/>node4"]

Semua interface di atas (block, file, object) sebenarnya duduk di atas satu layer yang sama: RADOS — object store terdistribusi yang menyimpan segalanya sebagai objek ±4 MB.

2. Mapping Mental Model: LVM vs ZFS vs Ceph#

3. Komponen Inti#

3.1 OSD (Object Storage Daemon)#

• 1 disk fisik = 1 daemon OSD. Server dengan 6 disk = 6 OSD.
• OSD menyimpan objek, melayani read/write, dan saling replikasi peer-to-peer (bukan lewat server pusat).
• Backend penyimpanan modern: BlueStore (langsung ke raw disk, tanpa filesystem perantara).

3.2 MON (Monitor) & MGR (Manager)#

• MON: memegang cluster map (peta OSD, CRUSH map, state cluster). Butuh quorum ganjil, minimal 3 — kalau quorum hilang, cluster berhenti menerima I/O.
• MGR: metrics, dashboard, modul otomasi. 1 aktif + 1 standby.
• MON/MGR tidak berada di data path — data mengalir langsung client ↔ OSD.

3.3 Pool, PG, dan CRUSH#

• Pool = namespace logis dengan aturan proteksi: replicated size=3 (3 copy penuh) atau erasure coded k+m (mirip RAID5/6 versi terdistribusi, hemat space tapi CPU/latency lebih berat).
• PG (placement group) = bucket sharding. Objek → di-hash ke salah satu PG → PG dipetakan ke sekumpulan OSD. PG adalah unit yang dipindah-pindah saat rebalance.
• CRUSH = algoritma deterministik yang menghitung “PG X harus di OSD mana” berdasarkan CRUSH map + failure domain rules. Karena deterministik, client menghitung sendiri lokasi data — tidak ada metadata server yang jadi bottleneck.

4. Redundancy: Failure Domain, Bukan RAID#

Tidak ada RAID di Ceph. Aturan CRUSH menentukan replika harus tersebar di failure domain berbeda — default: beda host. Bisa dinaikkan ke beda rack / beda ruangan.

flowchart TD
    A["Objek A — 4 MB"]

    subgraph n1["node1"]
        O0["OSD.0 — A primary"]
        O1["OSD.1"]
    end
    subgraph n2["node2"]
        O2["OSD.2"]
        O3["OSD.3 — A replica"]
    end
    subgraph n3["node3"]
        O4["OSD.4 — A replica"]
        O5["OSD.5"]
    end

    A --> O0
    A --> O3
    A --> O4

Konsekuensi vs RAID/vdev:

Rule of thumb kapasitas: jangan isi cluster melebihi ~70% — sisanya adalah ruang untuk self-healing saat 1 node mati.

5. Write Path & Konsistensi#

sequenceDiagram
    participant C as Client
    participant P as Primary OSD
    participant R1 as Replica OSD
    participant R2 as Replica OSD

    Note over C: hitung lokasi objek via CRUSH map<br/>(tanpa tanya server)
    C->>P: 1. write objek
    P->>R1: 2. replicate
    P->>R2: 2. replicate
    R1-->>P: 3. ack
    R2-->>P: 3. ack
    P-->>C: 4. ack ke client

Poin penting:

• Write baru di-ack setelah semua replika tersimpan → konsistensi kuat.
• Konsekuensinya: latency write = network round-trip ke replika terjauh. Ini kenapa Ceph butuh network bagus (10GbE minimum, idealnya 25GbE + jaringan cluster terpisah untuk traffic replikasi).
• Read dilayani primary OSD saja → read latency lebih ringan dari write.

6. RBD untuk VM (relevansi ke Incus)#

RBD (RADOS Block Device) = block device virtual di atas RADOS — padanan zvol, tapi terdistribusi:

• Satu RBD image dipecah jadi ribuan objek 4 MB tersebar di semua OSD → I/O VM otomatis paralel ke banyak disk & server.
• Thin provisioned by default, support snapshot, clone (copy-on-write), dan live migration antar host tanpa storage migration.
• Incus punya driver ceph native:

# Di cluster Incus, setelah Ceph jalan:
incus storage create remote ceph ceph.cluster_name=ceph ceph.osd.pool_name=incus
incus launch images:ubuntu/24.04 vm-test --vm --storage remote

Keuntungan vs QNAP iSCSI saat ini: tidak ada single point of failure — NAS mati = semua VM mati; Ceph node mati = VM jalan terus (asal quorum MON aman).

7. Kebutuhan Minimum yang Realistis#

8. Trade-off Jujur: Ceph vs ZFS-on-NAS#

Kesimpulan praktis: untuk skala 4 node saat ini, QNAP + ZFS masih pilihan waras — simple dan cepat. Ceph layak diseriusin kalau: (1) SPOF di NAS mulai tidak bisa diterima secara bisnis, (2) network antar node minimal 10GbE tersedia, dan (3) ada disk lokal cukup di tiap node. Jalur migrasi natural: bangun pool Ceph kecil untuk VM non-kritikal dulu, validasi operasional, baru pindahkan beban utama.

9. Quick Reference CLI#

# Status cluster
ceph -s                          # ringkasan health, OSD, PG
ceph health detail               # detail warning/error
ceph osd tree                    # topologi OSD per host/rack
ceph df                          # kapasitas per pool

# OSD
ceph osd status                  # state semua OSD
ceph osd out osd.3               # tandai OSD keluar (sebelum maintenance)
ceph osd in osd.3                # masukkan kembali

# Pool & RBD
ceph osd pool create incus 128   # pool baru, 128 PG
ceph osd pool set incus size 3   # 3 replika
rbd ls incus                     # daftar RBD image di pool
rbd info incus/vm-disk-1         # detail image
rbd snap create incus/vm-disk-1@snap1

# Monitoring
ceph -w                          # live event stream
ceph osd perf                    # latency per OSD