Di Ceph ada beberapa “layanan/fitur” utama
- RBD (RADOS Block Device)
Storage berbasis block device, bentuknya kayak harddisk virtual (mirip iSCSI atau LVM). Biasanya dipakai untuk disk VM / container di Proxmox.
- CephFS (Ceph File System)
Storage berbasis file system terdistribusi, bisa di-mount seperti folder biasa (misalnya /mnt/cephfs). Cocok untuk backup, ISO, container templates, data share.
- RGW (RADOS Gateway / Ceph Object Storage)
Storage berbasis object storage, compatible dengan Amazon S3 / Swift API. Biasanya dipakai untuk aplikasi yang butuh object storage (Nextcloud, MinIO, backup S3, dll.).
Lalu Apa Itu RADOS?
RADOS (Reliable Autonomic Distributed Object Store) adalah lapisan dasar dari Ceph yang bertanggung jawab menyimpan data dalam bentuk object di cluster. Sistem ini reliable karena menjamin keamanan data melalui mekanisme replikasi atau erasure coding, autonomic karena mampu melakukan self-healing dan self-managing tanpa perlu campur tangan manual dari admin, serta distributed karena data tersebar secara merata di banyak OSD dan node. Sebagai object store, RADOS menyimpan data bukan dalam bentuk block atau file langsung, melainkan sebagai object yang kemudian dipetakan ke OSD. Seluruh layanan Ceph—seperti RBD untuk block storage, CephFS untuk filesystem, dan RGW untuk object/S3—berdiri di atas fondasi RADOS ini.
Komponen RADOS di CEPH
OSD (Object Storage Daemon)
Proses yang menyimpan data object di disk, biasanya 1 disk = 1 OSD. contoh:osd.0,osd.1,osd.2MON (Monitor)
Menyimpan metadata cluster (map cluster, siapa up/down), wajib ada minimal 3 untuk quorum.MGR (Manager)
Tambahan dari MON, mengatur statistik & balancing.CRUSH Map
Algoritma + peta yang menentukan object disimpan di OSD mana.PG (Placement Group)
Bucket logical yang jadi perantara antara object ke OSD dan Object ke PG lalu disebar ke beberapa OSD.
baca juga:
https://dev.to/seno21/osd-pool-pg-on-ceph-proxmox-44di
Cara Kerja RADOS di CEPH
Object Store
- Data tidak disimpan dalam bentuk file langsung, tapi dipecah menjadi object.
- Object disimpan di OSD (Object Storage Daemon) sesuai dengan aturan dari CRUSH Map.
Replication / Erasure Coding
- Saat kamu tulis data, RADOS akan otomatis mereplikasi ke beberapa OSD (default 3 copy) atau menggunakan erasure coding.
- Kalau ada OSD mati, data tetap aman karena copy ada di OSD lain.
Self-healing
- Jika 1 OSD rusak, RADOS akan melakukan rebalancing dan menyalin ulang object ke OSD lain agar tetap sesuai dengan policy.
Consistency
- RADOS memastikan data tetap konsisten dengan protokol strong consistency.
RADOS menyimpan data dalam bentuk object, bukan file secara langsung. Setiap object tidak langsung ditempatkan ke OSD, melainkan terlebih dahulu dimasukkan ke dalam Placement Group (PG). PG ini dapat diibaratkan sebagai “bucket logical” yang berfungsi untuk mendistribusikan object ke OSD. Penempatan object ke OSD ditentukan oleh CRUSH Map yang mengatur distribusi data di dalam cluster.
Sebagai contoh, dengan pengaturan replication size = 3, satu object akan disalin ke tiga OSD yang berbeda. Misalnya, Object A ditempatkan di OSD1, OSD3, dan OSD5, sementara Object B ditempatkan di OSD2, OSD4, dan OSD6. Dengan demikian, setiap object memiliki tiga salinan, namun penyebarannya berbeda-beda sesuai aturan CRUSH Map, sehingga tidak semua OSD menyimpan data yang sama.
Ketika salah satu OSD mati, misalnya OSD1, cluster melalui MON dan MGR akan segera mendeteksi kondisi ini. Status PG yang menyimpan object di OSD1 berubah menjadi degraded karena jumlah salinan berkurang. Ceph kemudian menjalankan proses rebalancing atau recovery dengan menghitung ulang CRUSH Map. Object-object yang kehilangan salinan akan dibuatkan replika baru di OSD lain, misalnya OSD7, sehingga distribusi tetap seimbang. Dalam contoh ini, sebelum OSD1 mati, Object A tersimpan di OSD1, OSD3, dan OSD5. Setelah OSD1 mati, salinan baru dibuat sehingga Object A tersimpan di OSD3, OSD5, dan OSD7.
Hal penting untuk dipahami adalah yang di-balancing bukan seluruh data cluster, melainkan hanya object-object yang kehilangan replika. Ceph juga memastikan distribusi replika baru tersebar merata ke OSD lain, agar tidak terjadi penumpukan data pada satu OSD.
Ketika OSD yang mati kembali hidup, Ceph akan mengecek apakah data di dalamnya masih valid. Jika valid, cluster dapat menghapus salinan tambahan yang sebelumnya dibuat atau melakukan sinkronisasi ulang. Setelah itu, status PG akan kembali menjadi active+clean, menandakan cluster dalam kondisi sehat.
Kesimpulannya, data dalam Ceph tidak di-mirror ke semua OSD, melainkan disebarkan sesuai CRUSH Map dengan jumlah salinan tertentu. Saat OSD mati, Ceph hanya mereplikasi ulang object yang kehilangan salinan, dan proses inilah yang disebut rebalancing atau recovery. Dengan demikian, yang di-balancing adalah penempatan object di cluster, bukan seluruh data secara keseluruhan.
Top comments (0)