Belajar Ceph - Ceph Client Integration
Episode 8 of 23

Belajar Ceph - Ceph Client Integration

Episode ini membahas cara menghubungkan client Linux ke CephFS dan RBD, mengonfigurasi RADOS Gateway clients, integrasi dengan Kubernetes CSI drivers dan platform cloud, serta best practice autentikasi client dan manajemen keyring.

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

Pendahuluan

Selamat datang di episode 8 series Belajar Ceph! Tiga interface utama — RBD, CephFS, dan RGW — sudah kalian kenal dari episode 5 sampai 7. Sekarang saatnya menjawab pertanyaan yang lebih praktis: bagaimana cara menghubungkan client ke cluster dari sisi pengguna? Episode ini membahas Ceph client integration secara menyeluruh.

Sebuah cluster Ceph tidak berguna tanpa client. Client bisa berupa server Linux yang membutuhkan disk RBD, workstation yang me-mount CephFS, atau aplikasi yang mengakses bucket S3 lewat RGW. Setiap jenis client memiliki jalur, kredensial, dan konfigurasi yang berbeda meskipun semuanya berjalan di atas RADOS.

Di akhir episode ini kalian akan mampu mengonfigurasi client Linux untuk CephFS dan RBD, mengatur client RGW dengan aman, memahami cara kerja Kubernetes CSI drivers, serta menerapkan best practice autentikasi client dan keyring. Mari kita mulai.

Menghubungkan Client Linux ke CephFS dan RBD

Menyiapkan Keyring dan Ceph Config di Client

Setiap client membutuhkan dua hal: file konfigurasi /etc/ceph/ceph.conf dan keyring yang sesuai. Cara paling mudah menyalin keduanya dari node cluster:

Salin config dan keyring ke client
scp node1:/etc/ceph/ceph.conf /etc/ceph/
scp node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/

File ceph.conf berisi daftar mon dan parameter network, sedangkan keyring berisi kredensial. Menggunakan keyring admin di client umum memang praktis, tetapi bukan praktik yang aman untuk produksi — kita akan membuat client key khusus di bagian autentikasi.

Mount CephFS dari Client

Setelah config dan keyring tersedia, mount CephFS dengan kernel driver:

Mount CephFS di client
sudo mkdir -p /mnt/myfs
sudo mount -t ceph ceph-mon1:6789:/ /mnt/myfs \
  -o name=admin,secretfile=/etc/ceph/admin.secret

Sintaks mount -t ceph membutuhkan daftar MON dan credential. Untuk persistensi lintas reboot, definisikan entry di /etc/fstab dengan opsi yang sama. Jika kernel driver tidak tersedia, gunakan ceph-fuse sebagai alternatif user-space.

Map Image RBD dari Client

Untuk RBD, client perlu paket ceph-common dan rbd, lalu memetakan image:

Install paket dan map RBD
dnf install -y ceph-common
rbd map rbd-pool/vol-data --id admin

Perintah rbd map memetakan image menjadi device /dev/rbdN. Device ini bisa dipartisi, diformat, dan di-mount seperti disk biasa. Jangan lupa menjalankan rbd unmap /dev/rbdN sebelum mematikan node agar tidak ada write yang tertinggal.

Mengonfigurasi RADOS Gateway Clients

Klien S3 dengan aws cli

Client RGW tidak memerlukan ceph.conf karena berkomunikasi lewat HTTP. Yang dibutuhkan hanyalah endpoint, access key, dan secret key dari user RGW yang sudah dibuat di episode 7:

Konfigurasi aws cli untuk RGW
aws configure --profile rgw
export AWS_PROFILE=rgw
aws --endpoint-url https://rgw.example.com s3 ls

Perintah aws configure menyimpan kredensial di ~/.aws/credentials. Seluruh operasi s3 kemudian diarahkan ke RGW dengan --endpoint-url. Untuk produksi, pertimbangkan memakai kredensial short-lived atau instance role jika platform cloud mendukungnya.

Client Library dalam Aplikasi

Aplikasi memakai SDK seperti boto3 di Python atau aws-sdk-go di Go. Kunci pentingnya: set endpoint ke RGW, bukan endpoint AWS default. Dengan begitu, aplikasi yang sudah ditulis untuk S3 langsung bekerja tanpa perubahan logika bisnis.

PythonClient boto3 ke RGW
import boto3
 
s3 = boto3.client(
    "s3",
    endpoint_url="https://rgw.example.com",
    aws_access_key_id="AKIAEXAMPLE",
    aws_secret_access_key="SECRETEXAMPLE",
)
 
for obj in s3.list_objects_v2(Bucket="bucket-pertama").get("Contents", []):
    print(obj["Key"])

Kode endpoint_url="https://rgw.example.com" adalah satu-satunya perbedaan dari client S3 biasa. Pastikan endpoint menggunakan TLS saat melewati jaringan publik.

Integrasi dengan Kubernetes CSI Drivers

Konsep CSI di Kubernetes

Container Storage Interface (CSI) memungkinkan Kubernetes mem-provision storage eksternal secara otomatis. Untuk Ceph, ada dua driver: RBD CSI untuk block volume dan CephFS CSI untuk shared filesystem. Keduanya berkomunikasi dengan cluster Ceph menggunakan keyring yang dikelola sebagai Kubernetes Secret.

Secret ceph-csi
apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret
stringData:
  userID: kubernetes
  userKey: <base64-keyring>
  adminID: admin
  adminKey: <base64-admin-key>

Secret di atas menyimpan kredensial yang dipakai driver. Deployment lengkap StorageClass dan PVC akan dibahas di episode 16, tetapi konsep dasarnya sudah terlihat: driver memakai credential dari Secret untuk berbicara ke MON.

Integrasi dengan Platform Cloud

Di platform cloud, Ceph sering menjadi backend storage native. Contoh paling terkenal adalah OpenStack: Cinder memakai RBD untuk block volume dan Manila dapat memakai CephFS untuk shared file service. Konfigurasi dilakukan di sisi cloud service, sementara cluster Ceph hanya perlu menyediakan pool dan keyring yang sesuai.

Verifikasi konektivitas dari sisi cloud
ceph auth get-or-create client.cinder mon 'allow r' \
  osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes'

Perintah di atas membuat client khusus untuk Cinder dengan capability yang dibatasi hanya ke pool volumes. Prinsip least privilege ini adalah best practice utama yang akan kita bahas berikutnya.

Best Practice Autentikasi Client dan Keyrings

Satu Keyring per Client

Hindari memakai keyring admin di client produksi. Buat satu entity CephX per client atau per kelompok workload, dengan capability yang hanya mencakup apa yang dibutuhkan:

Buat client khusus RBD
ceph auth get-or-create client.backup mon 'allow r' \
  osd 'allow rwx pool=backups'
ceph auth export client.backup -o /etc/ceph/ceph.client.backup.keyring

ceph auth get-or-create membuat key baru sekaligus mengekspornya ke file keyring. Rotasi key dilakukan dengan ceph auth rotate-key secara berkala, terutama saat ada anggota tim yang keluar.

Melindungi File Keyring

File keyring berisi rahasia dan harus dilindungi seperti file kredensial lainnya:

Set permission keyring
chown root:ceph /etc/ceph/ceph.client.*.keyring
chmod 640 /etc/ceph/ceph.client.*.keyring

Permission chmod 640 memastikan hanya owner dan grup yang bisa membaca keyring. Jangan pernah menaruh keyring di direktori yang bisa dibaca publik, dan hindari menyimpannya di image container tanpa enkripsi.

Penutup

Di episode ini kalian sudah memahami cara menghubungkan berbagai client ke cluster Ceph: mounting CephFS dan mapping RBD dari client Linux, mengonfigurasi client RGW dengan aws cli dan SDK, integrasi dengan Kubernetes CSI drivers dan platform cloud seperti OpenStack, serta best practice autentikasi client dan manajemen keyring.

Inti yang harus dibawa pulang:

  • Client Linux membutuhkan ceph.conf dan keyring sebelum bisa akses CephFS atau RBD.
  • Client RGW cukup memakai endpoint, access key, dan secret key tanpa ceph.conf.
  • Kubernetes CSI memakai Secret untuk menyimpan kredensial driver RBD dan CephFS.
  • Cinder dan Manila memakai keyring khusus yang dibatasi per pool.
  • Satu entity CephX per workload dengan capability minimal (least privilege).
  • Jaga permission keyring tetap privat dan rotasi key secara berkala.

Di episode 9 selanjutnya kita akan masuk ke performance tuning & data placement — mengoptimalkan OSD dengan Bluestore dan DB/WAL, tuning network dengan pemisahan public dan private network, penyesuaian placement groups dan device classes, serta memantau throughput, latency, dan perilaku backfill. Siapkan alat ukur performa kalian!

Belajar Ceph - Ceph Client Integration | Belajar Ceph