Ceph Storage Cluster — ระบบจัดเก็บข้อมูลแบบกระจายฉบับสมบูรณ์ 2026

ทำไมต้อง Ceph ในยุคที่ข้อมูลโตไม่หยุด

ผมดูแลระบบ Storage มาตั้งแต่ยุค RAID controller บน Hardware ผ่านมาถึง SAN, NAS แล้วก็ Software-Defined Storage ที่เปลี่ยนเกมทั้งหมดในบรรดา Distributed Storage ทั้งหลาย Ceph เป็นตัวที่ผมเลือกใช้และแนะนำมาตลอดหลายปีเพราะมันเป็น Open Source ที่มี Community ใหญ่มี Red Hat หนุนหลังและที่สำคัญคือมันรวม Block Storage, Object Storage และ File System ไว้ในระบบเดียว

ถ้าถามว่าทำไมต้อง Ceph ไม่ใช่ GlusterFS หรือ MinIO ผมตอบได้เลยว่า Ceph เป็นระบบเดียวที่ให้คุณทำได้ทั้ง 3 แบบพร้อมกัน GlusterFS ดีเรื่อง File Storage แต่ไม่มี Native Block Storage ส่วน MinIO ดีเรื่อง S3-compatible Object Storage แต่ไม่มี Block และ File ดังนั้นถ้าองค์กรต้องการ Unified Storage Platform Ceph คือคำตอบ

Use Case จริงที่ผมเจอ

โปรเจคล่าสุดที่ผมทำคือลูกค้าเป็นบริษัทสื่อที่มีข้อมูลวิดีโอ 4K ปริมาณ 200 TB และเพิ่มขึ้นเดือนละ 10-15 TB เดิมใช้ NAS ยี่ห้อดังตัวหนึ่งแต่พอข้อมูลเกิน 80% ของ capacity ระบบช้าลงมากและการ upgrade ก็แพงเพราะต้องซื้อ disk shelf ของยี่ห้อนั้นเท่านั้นเราเปลี่ยนมาใช้ Ceph cluster 5 nodes ใช้ SSD สำหรับ Metadata และ HDD สำหรับ Data ราคารวมถูกกว่า NAS ที่เทียบเท่าประมาณ 40% แถม scale out ได้ง่ายแค่เพิ่มเครื่องเข้า cluster

สถาปัตยกรรม Ceph แบบเจาะลึก

ก่อนจะลงมือติดตั้งผมอยากให้เข้าใจสถาปัตยกรรมของ Ceph ก่อนเพราะถ้าเข้าใจตรงนี้ดีการ troubleshoot และ tuning จะง่ายขึ้นมาก

RADOS — หัวใจของ Ceph

RADOS (Reliable Autonomic Distributed Object Store) คือ foundation layer ของ Ceph ทุกอย่างใน Ceph ไม่ว่าจะเป็น Block, Object หรือ File ล้วนถูกแปลงเป็น objects แล้วเก็บใน RADOS ทั้งหมด RADOS ประกอบด้วย 2 daemon หลักคือ OSD (Object Storage Daemon) ที่รับผิดชอบเก็บข้อมูลจริงบน disk และ MON (Monitor) ที่ดูแล cluster map และ quorum

CRUSH Algorithm — ไม่ต้องมี Metadata Server สำหรับ Object Placement

สิ่งที่ทำให้ Ceph ต่างจาก Distributed Storage อื่นๆคือ CRUSH Algorithm (Controlled Replication Under Scalable Hashing) แทนที่จะมี Central Metadata Server ที่บอกว่า data อยู่ที่ไหน CRUSH ใช้การคำนวณ (deterministic) เพื่อหาตำแหน่งของ data จาก object name ทำให้ไม่มี Single Point of Failure จาก metadata server และ scale ได้ดีมาก

CRUSH Map คือไฟล์ที่กำหนดว่า cluster มี topology อย่างไรเช่นมี rack กี่ตัวแต่ละ rack มี server กี่เครื่องแต่ละเครื่องมี OSD กี่ตัว CRUSH ใช้ข้อมูลนี้ในการกระจาย data โดยพยายามให้ replicas อยู่คนละ rack หรือคนละ server เพื่อ fault tolerance

Placement Groups (PGs) — หน่วยจัดการ Data

Ceph ไม่ได้จัดการ data ทีละ object โดยตรงแต่ใช้สิ่งที่เรียกว่า Placement Groups เป็นตัวกลาง Object จะถูก map ไปที่ PG (โดยใช้ hash ของ object name) แล้ว PG จะถูก map ไปที่ OSD (โดยใช้ CRUSH) จำนวน PG ส่งผลต่อ performance โดยตรงน้อยเกินจะ bottleneck มากเกินจะเปลือง memory ของ OSD โดยทั่วไปผมใช้สูตร PGs = (OSDs * 100) / replicas แล้วปัดขึ้นเป็นเลขยกกำลังสองที่ใกล้ที่สุด

เตรียมเครื่องและติดตั้ง Ceph Cluster

ผมจะแสดงการติดตั้ง Ceph Reef (version 18.x) ซึ่งเป็น LTS release ล่าสุดบน Ubuntu 22.04 LTS โดยใช้ cephadm ซึ่งเป็นวิธีที่แนะนำตั้งแต่ Ceph Octopus เป็นต้นมา

Hardware Requirements

สำหรับ Production cluster ผมแนะนำอย่างน้อย 3 nodes (สำหรับ MON quorum) แต่ละ node ควรมี RAM อย่างน้อย 16 GB (ผมแนะนำ 32 GB) CPU 4 cores ขึ้นไป NIC อย่างน้อย 10 GbE (ถ้าได้ 25 GbE จะดีมาก) OSD disk ขึ้นอยู่กับ workload ถ้าเป็น HDD ใช้ 7200 RPM Enterprise grade ถ้าเป็น SSD ใช้ Data Center grade เช่น Samsung PM893 หรือ Intel D3-S4520 อย่าใช้ Consumer SSD เด็ดขาดเพราะ endurance ไม่พอ

# Cluster layout ที่ผมใช้จริง
# Node 1 (ceph-mon1): MON + MGR + OSD x4 (HDD 4TB) + OSD x1 (SSD 480GB สำหรับ WAL/DB)
# Node 2 (ceph-mon2): MON + MGR + OSD x4 (HDD 4TB) + OSD x1 (SSD 480GB)
# Node 3 (ceph-mon3): MON + OSD x4 (HDD 4TB) + OSD x1 (SSD 480GB)
# Node 4 (ceph-osd1): OSD x8 (HDD 4TB) + OSD x2 (NVMe 1TB สำหรับ WAL/DB)
# Node 5 (ceph-osd2): OSD x8 (HDD 4TB) + OSD x2 (NVMe 1TB)
# Total raw capacity: 5 nodes x เฉลี่ย 4 HDD x 4TB = ~80 TB raw
# Usable (3x replication): ~26 TB

# Network layout
# Public network: 10.10.10.0/24 (สำหรับ client access)
# Cluster network: 10.10.20.0/24 (สำหรับ OSD replication)

ติดตั้งด้วย cephadm

# บน Node 1 (bootstrap node)
# ติดตั้ง cephadm
curl --silent --remote-name --location \
 https://download.ceph.com/rpm-reef/el9/noarch/cephadm
chmod +x cephadm
./cephadm add-repo --release reef
./cephadm install

# Bootstrap cluster
cephadm bootstrap \
 --mon-ip 10.10.10.11 \
 --cluster-network 10.10.20.0/24 \
 --initial-dashboard-user admin \
 --initial-dashboard-password MySecurePass123

# Output จะให้ URL ของ Ceph Dashboard
# https://10.10.10.11:8443/

# ติดตั้ง ceph CLI tools
cephadm install ceph-common

# เพิ่ม Node อื่นๆ เข้า cluster
# คัดลอก SSH key ไปยัง nodes อื่น
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon2
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon3
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd1
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd2

# เพิ่ม hosts
ceph orch host add ceph-mon2 10.10.10.12
ceph orch host add ceph-mon3 10.10.10.13
ceph orch host add ceph-osd1 10.10.10.14
ceph orch host add ceph-osd2 10.10.10.15

# เพิ่ม MON daemons
ceph orch apply mon --placement="ceph-mon1, ceph-mon2, ceph-mon3"

# เพิ่ม OSD จาก available disks
ceph orch apply osd --all-available-devices

# ตรวจสอบสถานะ
ceph status
ceph osd tree

ตรวจสอบ Cluster Health

# ดู cluster status
$ ceph status
 cluster:
 id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
 health: HEALTH_OK

 services:
 mon: 3 daemons, quorum ceph-mon1, ceph-mon2, ceph-mon3
 mgr: ceph-mon1(active), standbys: ceph-mon2
 osd: 20 osds: 20 up, 20 in

 data:
 pools: 1 pools, 1 pgs
 objects: 0 objects, 0 B
 usage: 20 GiB used, 72 TiB / 72 TiB avail
 pgs: 1 active+clean

# ดู OSD tree (topology)
$ ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS
-1 72.00000 root default
-3 14.40000 host ceph-mon1
 0 hdd 3.60000 osd.0 up
 1 hdd 3.60000 osd.1 up
 2 hdd 3.60000 osd.2 up
 3 hdd 3.60000 osd.3 up
...

Block Storage ด้วย RBD

RBD (RADOS Block Device) เป็น feature ที่ผมใช้บ่อยที่สุดเพราะมันให้ block device ที่ thin-provisioned, snapshotable และ cloneable ได้เหมาะสำหรับเป็น disk ของ Virtual Machine ใน Proxmox VE หรือ OpenStack

สร้าง RBD Pool และ Image

# สร้าง pool สำหรับ RBD
ceph osd pool create rbd-pool 128 128
ceph osd pool application enable rbd-pool rbd

# สร้าง RBD image (virtual disk) ขนาด 100 GB
rbd create --size 102400 rbd-pool/vm-disk-001

# ดูรายละเอียด image
rbd info rbd-pool/vm-disk-001
# rbd image 'vm-disk-001':
# size 100 GiB in 25600 objects
# order 22 (4 MiB objects)
# snapshot_count: 0

# Map image เป็น block device บน Linux
rbd map rbd-pool/vm-disk-001
# /dev/rbd0

# Format และ mount
mkfs.ext4 /dev/rbd0
mkdir -p /mnt/ceph-block
mount /dev/rbd0 /mnt/ceph-block

# ทดสอบ write performance
dd if=/dev/zero of=/mnt/ceph-block/testfile bs=1M count=1024 conv=fdatasync
# 1073741824 bytes (1.1 GB) copied, 3.2 s, 335 MB/s

Snapshot และ Clone

# สร้าง snapshot
rbd snap create rbd-pool/vm-disk-001@snap-20260228

# ดู snapshot list
rbd snap ls rbd-pool/vm-disk-001

# Clone จาก snapshot (instant, ใช้ COW)
rbd snap protect rbd-pool/vm-disk-001@snap-20260228
rbd clone rbd-pool/vm-disk-001@snap-20260228 rbd-pool/vm-disk-001-clone

# ข้อดีของ Clone คือมันเป็น Copy-on-Write
# สร้างได้ใน 1 วินาที ไม่ว่า image จะใหญ่แค่ไหน
# เหมาะสำหรับ provisioning VM ใหม่จาก template

Object Storage ด้วย RADOS Gateway

RADOS Gateway (RGW) เป็น component ที่ให้ S3-compatible และ Swift-compatible API สำหรับ Object Storage ผมใช้มันเก็บ backup files, static assets และ log archives

ติดตั้ง RGW

# Deploy RGW ด้วย cephadm
ceph orch apply rgw myrgw --placement="count:2 ceph-mon1 ceph-mon2" --port=8080

# สร้าง S3 user
radosgw-admin user create \
 --uid=s3admin \
 --display-name="S3 Admin" \
 --access-key=MYACCESSKEY123 \
 --secret=MYSECRETKEY456

# ทดสอบด้วย AWS CLI
aws --endpoint-url http://10.10.10.11:8080 s3 mb s3://my-backup-bucket
aws --endpoint-url http://10.10.10.11:8080 s3 cp /var/log/syslog s3://my-backup-bucket/logs/
aws --endpoint-url http://10.10.10.11:8080 s3 ls s3://my-backup-bucket/

ตั้งค่า Lifecycle Policy

# สร้าง lifecycle policy ลบ objects ที่อายุเกิน 90 วัน
cat > lifecycle.json << 'EOF'
{
 "Rules": [{
 "ID": "delete-old-logs",
 "Status": "Enabled",
 "Filter": {"Prefix": "logs/"},
 "Expiration": {"Days": 90}
 }]
}
EOF

aws --endpoint-url http://10.10.10.11:8080 \
 s3api put-bucket-lifecycle-configuration \
 --bucket my-backup-bucket \
 --lifecycle-configuration file://lifecycle.json

ข้อดีของการใช้ Ceph RGW แทน MinIO คือคุณใช้ storage pool เดียวกับ RBD และ CephFS ได้ทำให้จัดการ capacity ง่ายกว่าไม่ต้องแบ่ง disk ให้คนละระบบถ้าสนใจเรื่อง backup ไปยัง cloud สามารถอ่านเพิ่มได้ที่ Rclone Cloud Sync Backup

CephFS — Shared Filesystem

CephFS เป็น POSIX-compliant filesystem ที่ mount ได้จากหลายเครื่องพร้อมกันเหมาะสำหรับ workload ที่ต้องการ shared storage เช่น web server cluster, render farm หรือ home directory ของ users

ตั้งค่า CephFS

# สร้าง CephFS
ceph fs volume create myfs

# ตรวจสอบ
ceph fs status myfs
# myfs - 0 clients
# POOL TYPE USED AVAIL
# cephfs.myfs.meta metadata 96.0k 23.4T
# cephfs.myfs.data data 0 23.4T

# Mount CephFS บน client
# ต้อง install ceph-common บน client ก่อน
apt install ceph-common

# สร้าง keyring สำหรับ client
ceph auth get-or-create client.cephfs \
 mon 'allow r' \
 osd 'allow rw pool=cephfs.myfs.data' \
 mds 'allow rw' > /etc/ceph/ceph.client.cephfs.keyring

# Mount ด้วย kernel driver (เร็วกว่า FUSE)
mount -t ceph ceph-mon1:6789:/ /mnt/cephfs \
 -o name=cephfs, secretfile=/etc/ceph/cephfs.secret

# หรือ mount ผ่าน fstab
echo "ceph-mon1:6789:/ /mnt/cephfs ceph name=cephfs, secretfile=/etc/ceph/cephfs.secret, noatime,_netdev 0 0" >> /etc/fstab

Quotas และ Subvolumes

# สร้าง Subvolume Group สำหรับแต่ละ department
ceph fs subvolumegroup create myfs engineering
ceph fs subvolumegroup create myfs marketing

# สร้าง Subvolume พร้อม quota
ceph fs subvolume create myfs project-alpha engineering --size=1073741824 # 1 TB
ceph fs subvolume create myfs campaign-q1 marketing --size=536870912 # 500 GB

# ดู path ของ subvolume
ceph fs subvolume getpath myfs project-alpha engineering
# /volumes/engineering/project-alpha/...

Performance Tuning และ Monitoring

Ceph ออกจะจุกจิกเรื่อง Performance tuning พอสมควรแต่ถ้าตั้งค่าถูกผลลัพธ์จะดีมากผมจะแชร์ค่าที่ผมปรับจริงบน production cluster

OSD Tuning

# ค่าที่ผมปรับสำหรับ HDD-based cluster
ceph config set osd osd_memory_target 4294967296 # 4 GB per OSD
ceph config set osd bluestore_cache_size_hdd 1073741824 # 1 GB cache per HDD OSD
ceph config set osd osd_max_backfills 2 # ลดจาก default 1 เป็น 2
ceph config set osd osd_recovery_max_active 3 # recovery ทำพร้อมกัน 3

# สำหรับ SSD/NVMe cluster
ceph config set osd bluestore_cache_size_ssd 3221225472 # 3 GB cache per SSD OSD

# BlueStore WAL/DB บน SSD แยกจาก HDD data
# ทำให้ metadata operations เร็วขึ้นมาก
# ตั้งค่าตอนสร้าง OSD
ceph orch daemon add osd ceph-osd1:/dev/sdb --db-devices /dev/nvme0n1

Network Tuning

# เพิ่ม TCP buffer size บนทุก node
cat >> /etc/sysctl.conf << 'EOF'
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl -p

# ตั้งค่า Jumbo Frames (MTU 9000)
ip link set ens192 mtu 9000
# อย่าลืมตั้งค่าที่ switch ด้วย

Monitoring ด้วย Prometheus + Grafana

Ceph มี Prometheus exporter ในตัวผ่าน ceph-mgr module สามารถดึง metrics ไปแสดงบน Grafana Dashboard ได้เลย

# เปิด Prometheus module
ceph mgr module enable prometheus

# Prometheus endpoint จะอยู่ที่
# http://ceph-mon1:9283/metrics

# เพิ่มใน prometheus.yml
scrape_configs:
 - job_name: 'ceph'
 static_configs:
 - targets: ['ceph-mon1:9283']

# Grafana Dashboard ที่แนะนำ
# Import Dashboard ID: 2842 (Ceph Cluster)
# Import Dashboard ID: 5336 (Ceph OSD)
# Import Dashboard ID: 5342 (Ceph Pools)

Ceph ต้องใช้เครื่องอย่างน้อยกี่ตัว?

สำหรับ production ผมแนะนำอย่างน้อย 3 ตัวสำหรับ MON quorum แต่ถ้ารวม OSD ด้วยก็ใช้ 3 ตัวเดียวกันได้สำหรับ lab ทดสอบสามารถรันทุกอย่างบนเครื่องเดียวได้เลยแต่ไม่แนะนำสำหรับ production เพราะไม่มี fault tolerance จริงๆแล้วถ้าจะให้ดี cluster ควรมี 5 nodes ขึ้นไปเพราะเมื่อ node ตายไป 1 ตัว OSD จะ rebalance data ไปยัง node ที่เหลือถ้ามี node น้อยเกินจะทำให้ disk เต็มเร็ว

Ceph vs ZFS — ควรใช้ตัวไหน?

เป็นคำถามที่ต่างกันมาก ZFS เป็น local filesystem ที่ทำ RAID, compression, snapshot ได้ในตัวเหมาะสำหรับ single server Ceph เป็น distributed storage ที่กระจาย data ข้าม server ได้เหมาะสำหรับ cluster ถ้ามีเครื่องเดียวใช้ ZFS ถ้ามีหลายเครื่องและต้องการ scale out ใช้ Ceph จริงๆแล้วสามารถใช้ ZFS เป็น local filesystem ของ OSD ได้ด้วยแต่ผมไม่แนะนำเพราะ Ceph BlueStore จัดการ disk โดยตรงได้ดีกว่า

Ceph เหมาะกับ Database workload ไหม?

สำหรับ Database ที่ต้องการ low latency เช่น OLTP (MySQL, PostgreSQL) ผมแนะนำให้ใช้ RBD บน All-Flash cluster (SSD/NVMe ทั้งหมด) ไม่ควรใช้ HDD-based cluster เพราะ latency สูงเกินไป IOPS ที่ได้จาก All-Flash Ceph cluster สามารถแตะ 100K IOPS ต่อ RBD image ได้สบายๆซึ่งเพียงพอสำหรับ database ส่วนใหญ่สำหรับ workload แบบ OLAP หรือ Data warehouse ที่เน้น throughput มากกว่า latency ใช้ HDD-based ได้เลย

การ Recovery เมื่อ OSD ตายใช้เวลานานไหม?

ขึ้นอยู่กับปริมาณ data ที่ต้อง re-replicate และ network bandwidth สำหรับ OSD ขนาด 4 TB ที่เต็ม 70% ใช้เวลา recovery ประมาณ 2-4 ชั่วโมงบน 10 GbE network ช่วง recovery cluster จะทำงานช้าลงเล็กน้อยแต่ยังให้บริการได้ตามปกติผมแนะนำให้ตั้ง osd_recovery_max_active ให้เหมาะสมไม่มากเกินจน impact client I/O

สรุป

Ceph เป็น Distributed Storage ที่ทรงพลังที่สุดตัวหนึ่งในโลก Open Source มันให้คุณรวม Block, Object และ File Storage ไว้ใน Platform เดียว scale out ได้แทบไม่มีขีดจำกัดและมี self-healing ที่จัดการ disk failure ได้อัตโนมัติแต่ก็ต้องยอมรับว่า learning curve สูงการ tuning ต้องเข้าใจ internals ดีและ hardware requirements ก็ไม่น้อย

สำหรับองค์กรที่มีข้อมูลตั้งแต่ 10 TB ขึ้นไปและคาดว่าจะโตอย่างต่อเนื่องผมแนะนำให้ลงทุนเรียนรู้ Ceph อย่างจริงจังเพราะมันจะประหยัดค่าใช้จ่ายในระยะยาวได้มหาศาลเมื่อเทียบกับ Proprietary SAN/NAS ที่ต้องจ่ายทั้งค่า license และค่า hardware ที่ lock-in กับ vendor เดียวครับ