Belajar Ceph - Konsep Dasar & Arsitektur Ceph

#Pendahuluan

Selamat datang di episode 2 series Belajar Ceph! Di episode 1 kalian sudah memahami mengapa Ceph dipilih. Sekarang kita masuk ke bagian yang paling penting untuk dipahami secara utuh: arsitektur internal Ceph. Episode ini membedah komponen-komponen yang berjalan di dalam cluster dan bagaimana mereka bekerja sama.

Memahami arsitektur Ceph bukan sekadar formalitas. Ketika nanti terjadi masalah — OSD down, PG stuck, atau rebalance yang lambat — kalian harus tahu bagian mana yang bertanggung jawab. Tanpa peta mental ini, operasional Ceph akan terasa membingungkan.

Di episode ini kita akan membahas komponen inti MON, OSD, MDS, MGR, dan RGW, fondasi RADOS, cara kerja CRUSH map, serta konsep pool, placement groups, replikasi, dan erasure coding. Mari kita mulai.

#Komponen Inti Ceph

#MON (Monitor) — Sumber Kebenaran Cluster

MON menjaga peta-peta cluster: monitor map, OSD map, MGR map, CRUSH map, dan metadata. Setiap perubahan harus melalui consensus lewat quorum MON. Karena itulah minimal tiga MON direkomendasikan — jika dua dari tiga MON mati, quorum hilang dan cluster berhenti menerima perubahan.

MON tidak menyimpan data user. Tugasnya hanya menjaga state cluster agar semua daemon dan client melihat gambaran yang sama.

#OSD (Object Storage Daemon) — Tempat Data

OSD menyimpan data, menangani replikasi, recovery, rebalancing, dan menjawab request read/write dari client. Satu OSD biasanya terkait dengan satu disk. OSD juga bertanggung jawab untuk mengecek heartbeat daemon lain dan melaporkan statusnya ke MON.

#MGR (Manager) — Otak Operasional

MGR mengumpulkan metrik dan state dari seluruh cluster, menyediakan dashboard web, dan mengekspos endpoint Prometheus. MGR modern juga menangani balance, deep scrub scheduling, dan integrasi dengan tooling seperti cephadm. MGR berjalan dalam mode active-standby.

#MDS (Metadata Server) — Otak CephFS

MDS menyimpan metadata untuk CephFS: nama file, direktori, permission, dan struktur hierarki. MDS tidak menyimpan data file; data tetap disimpan di RADOS. MDS bisa berjalan multiple secara active-active untuk menskalakan throughput metadata.

#RGW (RADOS Gateway) — Pintu Object Storage

RGW menyediakan object storage yang kompatibel dengan S3 dan Swift. RGW menerjemahkan request HTTP menjadi operasi RADOS, termasuk manajemen bucket, user, dan kebijakan akses.

#RADOS: Fondasi Semua Layanan

#Apa Itu RADOS

RADOS (Reliable Autonomic Distributed Object Store) adalah lapisan tempat semua data Ceph disimpan. Setiap objek di Ceph — image RBD, file CephFS, objek S3 — pada akhirnya disimpan sebagai objek RADOS di pool.

Kelebihan RADOS adalah seluruh logika placement, replikasi, recovery, dan rebalancing berada di level ini. Interface-interface di atasnya (RBD, CephFS, RGW) hanya mengatur cara data dibaca dan ditulis.

RBD (block)  CephFS (file)  RGW (object)
        \        |         /
         v       v        v
              RADOS
         MON  MGR  MDS  OSD

#Keandalan Berasal dari Bawah

Keandalan Ceph tidak berasal dari hardware tunggal, melainkan dari replikasi di level objek. Saat client menulis objek, OSD akan menyimpan beberapa salinan di node berbeda sesuai rule CRUSH. Jika satu salinan rusak, salinan lain tetap melayani request sambil cluster memperbaiki diri.

#CRUSH Map dan Data Placement

#Algoritma CRUSH

CRUSH (Controlled Replication Under Scalable Hashing) adalah algoritma yang menentukan di mana objek disimpan, berdasarkan CRUSH map dan hash dari objek. Client menghitung sendiri lokasi data — tidak ada central lookup service, sehingga tidak ada bottleneck.

CRUSH map menggambarkan hierarki cluster: root, failure domain (host, rack), dan OSD di dalamnya. Dengan mengatur rule, kalian mengontrol bahwa replika tidak pernah ditempatkan di host atau rack yang sama.

#Failure Domain dan Rule

ceph osd tree
ceph osd crush rule ls
ceph osd crush rule dump replicated_rule

ceph osd tree menampilkan hierarki node dan OSD beserta statusnya, sementara ceph osd crush rule dump menunjukkan rule penempatan default. Failure domain default biasanya adalah host, artinya replika suatu objek akan diletakkan di host yang berbeda.

#Pool, Placement Group, dan Replikasi

#Pool dan Placement Group

Pool adalah partisi logis tempat objek disimpan. Setiap pool memiliki jumlah placement group (PG) yang ditentukan saat pembuatan. PG adalah shard logis dari pool: setiap objek dipetakan ke satu PG, dan setiap PG dipetakan ke beberapa OSD.

ceph pg stat
ceph osd pool ls detail

Jumlah PG menentukan granularity rebalancing. Terlalu sedikit PG menyebabkan distribusi tidak merata; terlalu banyak membebani MON dan OSD. Untuk pool berisi 100 GB dengan 100 OSD, aturan praktisnya total PG cluster sekitar 100 per OSD.

#Replication vs Erasure Coding

Ada dua cara menjaga keandalan data di pool:

• Replicated: setiap objek disalin utuh ke size salinan (biasanya 3). Sederhana, pemakaian disk 3x.
• Erasure coded: data dipecah menjadi chunk k+m, hanya k yang dibutuhkan untuk membaca. Hemat disk dengan overhead CPU lebih tinggi.

ceph osd pool create data 128
ceph osd pool set data size 3

ceph osd pool create data 128 membuat pool replicated dengan 128 PG dan ukuran replika default. Pengaturan size dan min_size akan kita bedah mendalam di episode 4.

#Penutup

Di episode ini kalian sudah memahami peta arsitektur Ceph: komponen MON, OSD, MDS, MGR, dan RGW beserta peran masing-masing, RADOS sebagai fondasi tunggal, CRUSH map untuk data placement tanpa central index, serta konsep pool, PG, replikasi, dan erasure coding.

Inti yang harus dibawa pulang:

• MON menjaga state cluster dan butuh quorum mayoritas agar berfungsi.
• OSD menyimpan dan mereplikasi data; MGR mengelola metrik dan dashboard.
• MDS melayani metadata CephFS, RGW menyediakan API S3/Swift.
• Semua data Ceph disimpan sebagai objek RADOS di dalam pool.
• CRUSH menempatkan replika dengan failure domain agar tidak sekarat bersama.
• Replicated mengandalkan salinan utuh; erasure coding menghemat disk dengan overhead CPU.

Di episode 3 selanjutnya kita akan praktik langsung: instalasi dan cluster setup dasar — menyiapkan cluster dengan cephadm, mengonfigurasi MON, OSD, dan MGR, memahami config file dan cluster keys, serta memverifikasi kesehatan dengan ceph status. Siapkan tiga node kalian, karena kita mulai membangun!