it

Ceph Storage Cluster —

Ceph Storage Cluster —

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

Ceph Storage Cluster —

ผมดูแลระบบ 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)

เนื้อหาเกี่ยวข้อง — แนะนำให้อ่าน Redis Cluster Database Migration

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)

แนะนำเพิ่มเติม — บทวิเคราะห์จาก XM Signal

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

เนื้อหาเกี่ยวข้อง — อ่านต่อ: Go Fiber Event Driven Design — คู่มือฉบับสมบูรณ์ 2026

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

แนะนำเพิ่มเติม — เรียนเทรดกับ iCafeForex

ทดสอบ 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

เนื้อหาเกี่ยวข้อง — บทความที่เกี่ยวข้อง: Kubernetes Admission Webhook Performance Tuning

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

Ceph Storage Cluster —
# 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 จะอยู่ที่

เนื้อหาเกี่ยวข้อง — อ่านต่อ: Python Rich Identity Access Management

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 เดียวครับ

XM Legend · เทรดเดอร์ & ผู้สอน Forex 13 ปี

ผู้ก่อตั้ง SiamCafe ตั้งแต่ปี 1997 · เทรดเดอร์สาย Forex มากกว่า 13 ปี ได้รับการยกย่องเป็น XM Legend · แบ่งปันความรู้ Forex, ไอที, AI และการเทรด จากประสบการณ์จริงในตลาดจริง