บทนำ: ปัญหา Persistent Storage บน Kubernetes On-Premise
Kubernetes ได้กลายเป็นมาตรฐานสำหรับการ Deploy และจัดการ Container Workloads ไปแล้ว ไม่ว่าจะเป็นบน Cloud หรือ On-Premise แต่มีปัญหาหนึ่งที่ผู้ใช้ Kubernetes On-Premise ต้องเผชิญอย่างหลีกเลี่ยงไม่ได้ นั่นคือเรื่องของ Persistent Storage เมื่อคุณ Run Kubernetes บน Cloud เช่น AWS EKS, Azure AKS หรือ GCP GKE Cloud Provider จะจัดเตรียม Storage Solution ให้พร้อม เช่น AWS EBS, Azure Disk, GCP Persistent Disk ซึ่งสามารถ Provision ได้อัตโนมัติผ่าน StorageClass เพียงแค่สร้าง PersistentVolumeClaim (PVC) ก็ได้ Volume มาใช้ทันที
แต่เมื่อ Run Kubernetes On-Premise ไม่ว่าจะเป็นบน Bare Metal Servers หรือ Virtual Machines ใน Private Data Center คุณไม่มี Cloud Storage Backend ให้ใช้ คำถามคือจะเอา Storage มาจากไหนสำหรับ Stateful Applications เช่น Database (PostgreSQL, MySQL, MongoDB), Message Queue (Kafka, RabbitMQ), Search Engine (Elasticsearch), Monitoring Stack (Prometheus, Grafana) และ Application Data ที่ต้อง Persist ข้าม Pod Restarts
ทางเลือกดั้งเดิมคือใช้ NFS Server หรือ External Storage Array (เช่น NetApp, Pure Storage, Dell EMC) แต่ NFS มีข้อจำกัดด้าน Performance และ Reliability ส่วน External Storage Array มีราคาสูงมากและต้อง Expertise เฉพาะทาง ในยุค 2026 ทางเลือกที่ได้รับความนิยมมากขึ้นคือ Software-Defined Storage (SDS) ที่ทำงานบน Kubernetes เอง โดยใช้ Local Disks ของ Nodes ใน Cluster มาสร้างเป็น Distributed Storage Pool สอง Solutions ที่โดดเด่นที่สุดคือ Longhorn (จาก Rancher/SUSE) และ Rook-Ceph (Ceph ที่จัดการผ่าน Rook Operator บน Kubernetes)
ทำไม On-Premise Kubernetes ต้องการ Software-Defined Storage
ข้อจำกัดของ Local Storage และ HostPath
วิธีที่ง่ายที่สุดในการให้ Storage แก่ Pods บน Kubernetes คือใช้ hostPath Volume ที่ Mount Directory จาก Node โดยตรง หรือใช้ Local Persistent Volumes แต่ทั้งสองวิธีมีข้อจำกัดสำคัญ คือ Node Affinity ที่ Pod จะถูกผูกกับ Node ที่มี Data อยู่ ถ้า Node ล่ม Pod จะไม่สามารถ Schedule ไปยัง Node อื่นได้เพราะ Data อยู่ที่ Node เดิม ไม่มี Data Replication ถ้า Disk ของ Node เสีย Data จะสูญหาย ไม่มี Dynamic Provisioning ต้องสร้าง PV ด้วยมือทุกครั้ง และ Capacity Management ที่ต้องจัดการเองว่า Node ไหนมี Disk เหลือเท่าไร
ข้อจำกัดของ NFS
NFS (Network File System) เป็นอีกทางเลือกที่ใช้กันบ่อย เพราะติดตั้งง่ายและทำงานได้กับ Kubernetes ผ่าน NFS CSI Driver แต่มีข้อจำกัดหลายอย่าง Performance ที่ NFS มี Latency สูงกว่า Local Disk มากโดยเฉพาะ Random I/O ทำให้ไม่เหมาะกับ Database Workloads Single Point of Failure ถ้า NFS Server ล่ม ทุก Pod ที่ใช้ NFS จะมีปัญหา File Locking ที่ NFS มีปัญหากับ Application ที่ต้องการ File Locking เช่น SQLite ไม่รองรับ Block Storage ที่ NFS เป็น File Storage ไม่ใช่ Block Storage ทำให้ Database บางตัวที่ต้องการ Block Storage ใช้งานไม่ได้ดี และ Scalability ที่ NFS Server เดียวมีขีดจำกัดด้าน Throughput
Software-Defined Storage: ทางออกสำหรับ On-Premise Kubernetes
Software-Defined Storage (SDS) แก้ปัญหาเหล่านี้โดยการใช้ Local Disks ของ Nodes ใน Kubernetes Cluster มาสร้างเป็น Distributed Storage Pool ที่มี Data Replication, Automatic Failover, Dynamic Provisioning และ Self-healing ข้อดีหลักของ SDS คือ Data Replication ที่ข้อมูลถูก Replicate ไปยังหลาย Nodes ถ้า Node หนึ่งล่ม Data ยังอยู่ที่ Node อื่น Dynamic Provisioning ที่สร้าง PVC แล้วได้ Volume อัตโนมัติเหมือน Cloud No Single Point of Failure ที่ระบบทำงานแบบ Distributed ไม่มี Component ตัวเดียวที่ล่มแล้วทั้งระบบล่ม Cost Effective ที่ใช้ Commodity Hardware ไม่ต้องซื้อ Storage Array ราคาแพง และ Kubernetes Native ที่ทำงานบน Kubernetes เอง จัดการผ่าน Kubernetes APIs เช่น StorageClass, PVC, PV
Longhorn: Storage Solution จาก Rancher/SUSE
Longhorn คืออะไร
Longhorn เป็น Lightweight, Reliable และ Easy-to-use Distributed Block Storage System สำหรับ Kubernetes พัฒนาโดย Rancher Labs (ปัจจุบันเป็นส่วนหนึ่งของ SUSE) และเป็น CNCF Sandbox Project (ปัจจุบันเป็น Incubating Project แล้ว) Longhorn ออกแบบมาให้เรียบง่ายและใช้งานง่าย เหมาะสำหรับทีมที่ไม่มี Storage Expertise มากนัก
หลักการทำงานของ Longhorn คือ แต่ละ Persistent Volume ที่สร้างขึ้นจะเป็น “Longhorn Volume” ที่ประกอบด้วย Engine (Controller) ที่จัดการ I/O และ Replicas ที่เป็นสำเนาของ Data ที่กระจายอยู่บนหลาย Nodes ตัวอย่างเช่น ถ้ากำหนด Replica Count เป็น 3 Longhorn จะสร้างสำเนาของ Volume ไว้บน 3 Nodes ที่ต่างกัน เมื่อ Pod เขียนข้อมูล Engine จะเขียนไปยัง Replicas ทั้ง 3 พร้อมกัน (Synchronous Replication) ถ้า Node ที่มี Replica ตัวหนึ่งล่ม Longhorn จะสร้าง Replica ใหม่บน Node อื่นอัตโนมัติเพื่อรักษา Replica Count ที่กำหนด
สถาปัตยกรรมของ Longhorn
Longhorn ประกอบด้วย Components หลักดังนี้
Longhorn Manager เป็น DaemonSet ที่ Run บนทุก Node ทำหน้าที่จัดการ Volumes, Replicas, Snapshots และ Backups รวมถึงจัดการ Kubernetes API Interactions เช่น การสร้าง PV เมื่อมี PVC ใหม่
Longhorn Engine เป็น Controller ที่จัดการ I/O สำหรับแต่ละ Volume ทำหน้าที่รับ I/O จาก Pod แล้วกระจายไปยัง Replicas ทั้งหมด Engine เป็น User-space Process ที่ Run อยู่ในคนละ Container กับ Pod ที่ใช้ Volume ทำให้ไม่ต้อง Kernel Module พิเศษ
Longhorn Replicas เป็น Processes ที่เก็บข้อมูลจริงบน Disk ของ Node แต่ละ Replica เก็บ Full Copy ของ Volume Data โดยใช้ Sparse Files ที่ใช้ Disk Space เท่าที่เขียนจริง ไม่ได้จองพื้นที่ทั้งหมดตั้งแต่ต้น (Thin Provisioning)
Longhorn CSI Driver เป็น Interface ระหว่าง Kubernetes และ Longhorn ทำให้ Kubernetes สามารถ Provision, Attach, Mount Longhorn Volumes ได้ผ่าน Standard CSI Protocol
Longhorn UI เป็น Web UI สำหรับจัดการและ Monitor Longhorn ที่ให้ Visibility เกี่ยวกับ Volumes, Nodes, Replicas, Backups และ System Health
การติดตั้ง Longhorn บน Kubernetes
การติดตั้ง Longhorn ง่ายมาก มีหลายวิธีให้เลือก วิธีแรกคือใช้ Helm Chart ซึ่งเป็นวิธีที่แนะนำ ขั้นแรก ติดตั้ง Prerequisites บนทุก Node ที่จะเป็น Storage Node ได้แก่ open-iscsi และ NFSv4 client ใช้คำสั่ง apt install open-iscsi nfs-common บน Ubuntu/Debian หรือ yum install iscsi-initiator-utils nfs-utils บน RHEL/CentOS จากนั้น Enable และ Start iscsid service ด้วยคำสั่ง systemctl enable iscsid –now
ขั้นที่สอง เพิ่ม Longhorn Helm Repository ด้วยคำสั่ง helm repo add longhorn https://charts.longhorn.io แล้ว helm repo update จากนั้นติดตั้ง Longhorn ด้วยคำสั่ง helm install longhorn longhorn/longhorn –namespace longhorn-system –create-namespace –set defaultSettings.defaultReplicaCount=3 เท่านี้ Longhorn ก็พร้อมใช้งานแล้ว
วิธีที่สองคือใช้ kubectl apply ดาวน์โหลดไฟล์ YAML จากเว็บไซต์ Longhorn แล้ว Apply ด้วย kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.x/deploy/longhorn.yaml วิธีนี้ง่ายกว่าแต่ Customize ได้น้อยกว่า Helm
วิธีที่สามคือติดตั้งผ่าน Rancher UI ถ้าใช้ Rancher จัดการ Kubernetes Cluster สามารถติดตั้ง Longhorn ได้จาก Rancher Apps Catalog โดยตรง
การจัดการ Replicas และ Data Locality
Longhorn มี Feature ด้าน Replica Management ที่น่าสนใจ ได้แก่ Replica Count ที่สามารถกำหนดได้ว่าต้องการสำเนากี่ชุด Default คือ 3 (หมายความว่า Data จะถูกเก็บบน 3 Nodes) สามารถเปลี่ยนได้ตาม Workload เช่น ลดเหลือ 2 สำหรับ Development Environment หรือเพิ่มเป็น 4 สำหรับ Critical Data Replica Auto-Balance ที่ Longhorn จะกระจาย Replicas ให้สมดุลระหว่าง Nodes อัตโนมัติ ถ้าเพิ่ม Node ใหม่ Replicas บางส่วนจะถูกย้ายไปยัง Node ใหม่เพื่อกระจาย Load
Data Locality เป็น Feature ที่ช่วยลด Network Latency โดยพยายามให้ Replica อย่างน้อย 1 ชุดอยู่บน Node เดียวกับ Pod ที่ใช้ Volume ทำให้ Read I/O สามารถ Read จาก Local Replica ได้โดยไม่ต้องข้าม Network มี 3 Modes คือ disabled (ไม่สนใจ Data Locality), best-effort (พยายามแต่ไม่ Guarantee), strict-local (ต้องมี Local Replica เสมอ ถ้าไม่ได้ Pod จะไม่ Schedule)
Backup และ Restore ไปยัง S3
Longhorn รองรับ Backup ไปยัง External Storage ที่เป็น S3-compatible Object Storage เช่น AWS S3, MinIO, Wasabi, Backblaze B2 ทำให้สามารถเก็บ Backup ไว้ภายนอก Cluster ได้ ในกรณีที่ Cluster ทั้งหมดมีปัญหา ยังสามารถ Restore Data จาก Backup ได้
การตั้งค่า Backup Target ทำได้ผ่าน Longhorn UI หรือ Helm Values ระบุ S3 Endpoint, Bucket Name, Access Key และ Secret Key จากนั้นสามารถสร้าง Backup ได้ทั้งแบบ Manual และแบบ Recurring (ตั้งเวลา Backup อัตโนมัติ เช่น ทุก 6 ชั่วโมง หรือทุกวัน) Longhorn ใช้ Incremental Backup ที่ส่งเฉพาะ Data ที่เปลี่ยนแปลงไปตั้งแต่ Backup ครั้งล่าสุด ทำให้ Backup เร็วและประหยัด Storage
การ Restore ทำได้ง่ายเช่นกัน สามารถ Restore Backup เป็น Volume ใหม่ได้จาก Longhorn UI หรือสร้าง PVC ที่อ้างอิง Backup URL โดยตรง นอกจากนี้ Longhorn ยังรองรับ Volume Snapshots ที่สามารถสร้าง Point-in-time Snapshot ของ Volume ได้ทันที โดยไม่ต้อง Stop Pod ที่ใช้ Volume (Online Snapshot) ใช้สำหรับ Quick Recovery ภายใน Cluster โดยไม่ต้อง Restore จาก S3
Rook-Ceph: Enterprise-Grade Storage บน Kubernetes
Ceph คืออะไร
ก่อนจะเข้าใจ Rook-Ceph ต้องเข้าใจ Ceph ก่อน Ceph เป็น Open Source Distributed Storage System ที่พัฒนามาตั้งแต่ปี 2004 โดย Sage Weil เป็นส่วนหนึ่งของงานวิจัยระดับ PhD ที่ UC Santa Cruz ปัจจุบัน Ceph เป็น Project ภายใต้ Linux Foundation และได้รับการใช้งานอย่างกว้างขวางทั้งใน Enterprise และ Cloud Provider (Red Hat Ceph Storage, IBM Storage Ceph, SUSE Enterprise Storage ล้วนใช้ Ceph เป็น Backend)
Ceph มีจุดแข็งที่ความยืดหยุ่นสูง รองรับ Storage 3 ประเภทในระบบเดียว ได้แก่ Block Storage (RBD – RADOS Block Device) สำหรับ Workloads ที่ต้องการ Block Device เช่น Database, Virtual Machine Disks File Storage (CephFS) สำหรับ Workloads ที่ต้องการ Shared File System เช่น Application ที่ต้อง Share Files ระหว่างหลาย Pods และ Object Storage (RGW – RADOS Gateway) สำหรับ S3-compatible Object Storage เช่น Application ที่เก็บ Images, Videos, Documents
Components หลักของ Ceph
Ceph ประกอบด้วย Components หลักดังนี้
RADOS (Reliable Autonomic Distributed Object Store) เป็นชั้น Foundation ของ Ceph ที่จัดการ Data Storage, Replication และ Recovery ทุกอย่างใน Ceph ถูกเก็บเป็น Objects ใน RADOS
OSD (Object Storage Daemon) เป็น Process ที่จัดการ Disk แต่ละลูก โดยปกติ 1 OSD ต่อ 1 Disk (HDD หรือ SSD) OSD ทำหน้าที่เก็บ Data, Handle Replication, Recovery และ Rebalancing ถ้ามี 10 Disks ก็จะมี 10 OSDs ยิ่งมี OSD มาก Cluster ก็ยิ่งมี Capacity และ Performance สูง
MON (Monitor) เป็น Process ที่เก็บ Cluster Map ซึ่งเป็นแผนที่ของ Cluster ทั้งหมด รวมถึง OSD Map, MON Map, PG Map และ CRUSH Map MON ใช้ Paxos Consensus Protocol เพื่อให้ MON ทุกตัวเห็นข้อมูลเดียวกัน ต้องมี MON จำนวนคี่ (3 หรือ 5 ตัว) เพื่อ Quorum
MGR (Manager) เป็น Process ที่จัดการ Monitoring, Orchestration และ Plugin Modules ต่างๆ เช่น Dashboard, Prometheus Exporter, Balancer Module MGR ทำงานเป็น Active/Standby คู่
MDS (Metadata Server) เป็น Process ที่จัดการ Metadata สำหรับ CephFS (File Storage) เช่น Directory Structure, File Permissions, Timestamps ถ้าไม่ใช้ CephFS ก็ไม่จำเป็นต้องมี MDS
CRUSH Algorithm เป็น Algorithm ที่ Ceph ใช้ในการกำหนดว่า Data ควรอยู่ที่ OSD ไหน โดยไม่ต้องมี Central Lookup Table ทำให้ Scale ได้ดีมาก CRUSH สามารถกำหนด Failure Domains ได้ เช่น ระบุว่า Replicas ต้องอยู่คนละ Rack, คนละ Room หรือคนละ Data Center
Rook: Kubernetes Operator สำหรับ Ceph
Rook เป็น Kubernetes Operator ที่ทำให้การ Deploy และจัดการ Ceph บน Kubernetes ง่ายขึ้นอย่างมาก แทนที่จะต้องติดตั้งและ Configure Ceph เอง (ซึ่งค่อนข้างซับซ้อน) Rook จะจัดการให้ทั้งหมด Rook เป็น CNCF Graduated Project ซึ่งหมายความว่าผ่านการ Review ด้าน Maturity, Adoption และ Governance จาก CNCF แล้ว
Rook ใช้ Kubernetes Operator Pattern ที่ประกอบด้วย Custom Resource Definitions (CRDs) ที่กำหนด Resources ใหม่ เช่น CephCluster, CephBlockPool, CephFilesystem, CephObjectStore และ Operator Controller ที่ Watch CRDs เหล่านี้แล้วสร้างและจัดการ Ceph Components ให้อัตโนมัติ เมื่อคุณสร้าง CephCluster CRD Rook Operator จะ Deploy MONs, MGRs, OSDs ให้อัตโนมัติตาม Spec ที่กำหนด ถ้า OSD ล่ม Rook จะสร้างใหม่ให้อัตโนมัติ
การติดตั้ง Rook-Ceph บน Kubernetes
การติดตั้ง Rook-Ceph มีขั้นตอนหลักดังนี้
ขั้นตอนที่ 1 คือเตรียม Nodes ให้พร้อม แต่ละ Node ที่จะเป็น Storage Node ต้องมี Raw Disk (ไม่ได้ Format หรือ Mount) อย่างน้อย 1 ลูกสำหรับ OSD Rook จะใช้ Raw Disks เหล่านี้ในการสร้าง OSDs โดยไม่ต้อง Partition หรือ Format ด้วยมือ นอกจากนี้ต้องติดตั้ง LVM2 Package บนทุก Node
ขั้นตอนที่ 2 คือติดตั้ง Rook Operator ใช้ Helm Chart ด้วยคำสั่ง helm repo add rook-release https://charts.rook.io/release แล้ว helm install rook-ceph rook-release/rook-ceph –namespace rook-ceph –create-namespace Rook Operator จะถูก Deploy เป็น Deployment ใน Namespace rook-ceph
ขั้นตอนที่ 3 คือสร้าง CephCluster CRD สร้างไฟล์ YAML ที่กำหนด Spec ของ Ceph Cluster เช่น จำนวน MONs (แนะนำ 3), จำนวน MGRs (แนะนำ 2 สำหรับ HA), Storage Spec ที่ระบุว่าใช้ Disks ไหน (ใช้ All Devices, ใช้เฉพาะ Devices ที่ระบุ, หรือใช้เฉพาะ Nodes ที่มี Label บางตัว) และ Placement Spec ที่ระบุว่า Components ต้อง Run บน Nodes ไหน จากนั้น Apply ด้วย kubectl apply -f cluster.yaml Rook Operator จะเริ่ม Deploy Ceph Components ให้อัตโนมัติ ใช้เวลาประมาณ 5-10 นาทีจนกว่า Cluster จะพร้อม
ขั้นตอนที่ 4 คือสร้าง CephBlockPool และ StorageClass สร้าง CephBlockPool CRD ที่กำหนดว่า Data จะถูก Replicate กี่ชุด (เช่น replicated.size=3 หมายความว่า Data จะถูกเก็บ 3 ชุดบน 3 OSDs ที่ต่างกัน) จากนั้นสร้าง StorageClass ที่อ้างอิง CephBlockPool นี้ เพื่อให้ Kubernetes สามารถ Dynamic Provision Volumes ได้
CephBlockPool: Block Storage สำหรับ Kubernetes
CephBlockPool เป็น CRD ที่กำหนด Pool ของ Block Storage ใน Ceph แต่ละ Pool มี Replication Policy ของตัวเอง ตัวอย่างเช่น สามารถสร้าง Pool ที่มี Replication Factor 3 สำหรับ Production Data และ Pool ที่มี Replication Factor 2 สำหรับ Non-critical Data เพื่อประหยัด Disk Space
นอกจาก Replication แล้ว Ceph ยังรองรับ Erasure Coding ที่เป็นอีกวิธีในการ Protect Data โดยใช้ Disk Space น้อยกว่า Replication ตัวอย่างเช่น Erasure Coding 4+2 จะแบ่ง Data เป็น 4 ชิ้นและสร้าง 2 ชิ้นสำรอง (Parity) ใช้ Disk Space เท่ากับ 1.5x ของ Data จริง (เทียบกับ Replication 3x ที่ใช้ 3x) แต่สามารถทน Failure ได้ 2 OSDs เหมือนกัน ข้อแม้คือ Erasure Coding มี Latency สูงกว่า Replication สำหรับ Random Write ทำให้ไม่เหมาะกับ Database Workloads แต่เหมาะกับ Object Storage หรือ Archive Data ที่เน้น Sequential Read/Write
CephFilesystem: Shared File Storage
CephFilesystem (CephFS) เป็น CRD ที่สร้าง POSIX-compliant Shared File System บน Ceph ข้อดีของ CephFS คือรองรับ ReadWriteMany (RWX) Access Mode ที่หลาย Pods สามารถ Mount Volume เดียวกันและอ่านเขียนได้พร้อมกัน ซึ่ง Block Storage (RBD) รองรับเฉพาะ ReadWriteOnce (RWO) เท่านั้น (Pod เดียวเท่านั้นที่เขียนได้)
Use Cases ที่เหมาะกับ CephFS ได้แก่ Shared Application Data ที่หลาย Pods ต้อง Share Files เช่น CMS ที่เก็บ Uploaded Files, Machine Learning ที่ Share Training Data ระหว่างหลาย Workers, CI/CD ที่ Share Build Artifacts ระหว่าง Stages และ Legacy Applications ที่ต้องการ Shared File System
การสร้าง CephFilesystem ทำโดยสร้าง CRD ที่กำหนดจำนวน MDS (Metadata Server) Active/Standby และ Data Pools จากนั้น Rook จะ Deploy MDS Pods และสร้าง StorageClass ที่ใช้สำหรับ Provision CephFS Volumes
เปรียบเทียบ Performance: Longhorn vs Rook-Ceph vs OpenEBS
Benchmark Methodology
ในการเปรียบเทียบ Performance ของ Storage Solutions ควรใช้เครื่องมือ Benchmark ที่เป็นมาตรฐาน เช่น fio (Flexible I/O Tester) ที่สามารถจำลอง Workloads หลายรูปแบบ ได้แก่ Sequential Read/Write ที่จำลองการอ่านเขียนข้อมูลต่อเนื่อง เช่น Backup, Video Streaming Random Read/Write ที่จำลองการอ่านเขียนแบบสุ่ม เช่น Database Operations Mixed Read/Write (70/30) ที่จำลอง Workload ที่มีทั้งอ่านและเขียน Metrics ที่ควรวัด ได้แก่ IOPS (I/O Operations Per Second), Throughput (MB/s), Latency (Average, P99, P999) และ CPU Overhead บน Storage Nodes
ผลเปรียบเทียบทั่วไป
จากการ Benchmark ทั่วไป (ค่าจริงจะแตกต่างไปตาม Hardware, Network และ Configuration) Longhorn มี Performance ที่ดีสำหรับ Sequential I/O แต่ Random I/O อาจด้อยกว่า Rook-Ceph เล็กน้อย Longhorn ใช้ User-space Engine ที่มี Overhead มากกว่า Kernel-space อย่างไรก็ตาม Longhorn ใน Version ใหม่ (v2 Engine) มีการปรับปรุง Performance อย่างมากโดยใช้ SPDK (Storage Performance Development Kit) ที่ลด Overhead ลงมาก
Rook-Ceph (RBD) มี Performance ที่ดีมากโดยเฉพาะ Random I/O เพราะ Ceph RBD ใช้ Kernel Module (krbd) ที่ Efficient กว่า User-space สำหรับ SSD-backed Clusters Ceph สามารถให้ IOPS สูงมาก ส่วน CephFS มี Performance ที่ดีสำหรับ Shared File Access แต่มี Overhead จาก Metadata Operations
OpenEBS (อีกตัวเลือกหนึ่ง) มีหลาย Storage Engines ให้เลือก Jiva เป็น User-space Engine คล้าย Longhorn แต่ Performance ด้อยกว่า cStor มี Performance ดีกว่าแต่ซับซ้อนกว่า Mayastor (ปัจจุบันเรียก OpenEBS Replicated PV Mayastor) ใช้ NVMe-oF Protocol ที่ให้ Performance สูงมากใกล้เคียง Local Disk แต่ต้องการ Hardware ที่รองรับ (NVMe SSDs, High-speed Network)
การเลือกตาม Use Case
จากผลเปรียบเทียบ สามารถเลือก Storage Solution ตาม Use Case ได้ดังนี้ สำหรับ Small to Medium Clusters (3-10 Nodes) ที่ต้องการความง่ายและไม่มี Storage Expertise Longhorn เป็นตัวเลือกที่ดีที่สุด ติดตั้งง่าย จัดการง่าย UI ใช้งานง่าย สำหรับ Medium to Large Clusters (10-100+ Nodes) ที่ต้องการ Performance สูงและ Feature ครบ Rook-Ceph เป็นตัวเลือกที่ดีที่สุด Ceph เป็น Battle-tested Storage ที่ใช้ใน Production ขนาดใหญ่มานานหลายปี สำหรับ High-Performance Workloads ที่ต้องการ IOPS ใกล้เคียง Local Disk OpenEBS Mayastor หรือ Rook-Ceph กับ NVMe OSDs เป็นตัวเลือกที่เหมาะ
Longhorn vs Rook-Ceph: เปรียบเทียบเชิงลึก
ความซับซ้อนในการติดตั้งและจัดการ
Longhorn มีความซับซ้อนต่ำ ติดตั้งได้ภายไม่กี่นาทีด้วย Helm Chart เดียว ไม่ต้อง Configure Components หลายตัว มี Web UI ที่ใช้งานง่ายสำหรับจัดการ Volumes, Snapshots, Backups การ Troubleshoot ค่อนข้างตรงไปตรงมาเพราะ Architecture ไม่ซับซ้อน
Rook-Ceph มีความซับซ้อนปานกลางถึงสูง ต้องเข้าใจ Concepts ของ Ceph (OSD, MON, PG, CRUSH Map) เพื่อ Configure และ Troubleshoot ได้อย่างมีประสิทธิภาพ การติดตั้งเองไม่ยาก (Rook ทำให้ง่ายขึ้นมาก) แต่การ Tune Performance และ Troubleshoot ปัญหาต้องมีความรู้เกี่ยวกับ Ceph ค่อนข้างมาก มี Ceph Dashboard ที่ให้ Monitoring แต่ UI ไม่ง่ายเท่า Longhorn
Scalability
Longhorn ออกแบบสำหรับ Clusters ขนาดเล็กถึงกลาง การ Scale ไปมากกว่า 100 Nodes อาจเริ่มมีข้อจำกัดด้าน Control Plane Overhead เพราะแต่ละ Volume มี Engine และ Replica Processes แยกกัน ถ้ามี Volume จำนวนมากบน Cluster ขนาดใหญ่ จะมี Processes จำนวนมากที่ต้องจัดการ
Rook-Ceph สามารถ Scale ได้มากกว่ามาก Ceph ถูกออกแบบมาสำหรับ Scale ตั้งแต่แรก มี Production Deployments ที่มี Petabytes ของ Data และหลาย Thousand OSDs การ Scale เป็นเรื่องง่าย แค่เพิ่ม Nodes ที่มี Disks เข้า Cluster Rook Operator จะสร้าง OSDs ใหม่ให้อัตโนมัติ
Storage Types
Longhorn รองรับเฉพาะ Block Storage (ReadWriteOnce) เท่านั้น ไม่รองรับ Shared File Storage (ReadWriteMany) โดยตรง ถ้าต้องการ RWX ต้องใช้ NFS บน Longhorn Volume ซึ่งเพิ่ม Complexity และลด Performance
Rook-Ceph รองรับทั้ง Block Storage (RBD), File Storage (CephFS ที่รองรับ RWX), และ Object Storage (RGW ที่เป็น S3-compatible) ความหลากหลายนี้ทำให้ Rook-Ceph เหมาะกับ Workloads ที่หลากหลายกว่า
Resource Consumption
Longhorn มี Resource Footprint ที่เบากว่า Longhorn Manager เป็น DaemonSet ที่ใช้ Resources ไม่มาก แต่ต้องนับ Resources ของ Engine และ Replica Processes ด้วย โดยรวมแล้ว Longhorn ใช้ Resources น้อยกว่า Rook-Ceph สำหรับ Cluster ขนาดเดียวกัน
Rook-Ceph มี Resource Footprint ที่สูงกว่า ต้อง Run MON Pods (3 ตัว), MGR Pods (2 ตัว), OSD Pods (1 ตัวต่อ Disk), MDS Pods (ถ้าใช้ CephFS) และ Rook Operator Pod แต่ละ OSD Pod ใช้ RAM ประมาณ 2-4 GB ขึ้นอยู่กับ Configuration สำหรับ Small Clusters (3-5 Nodes) Overhead นี้อาจเป็นสัดส่วนที่สูงเมื่อเทียบกับ Total Resources
Production Considerations: สิ่งที่ต้องคำนึงถึงก่อน Deploy Production
Hardware Planning
การเลือก Hardware ที่เหมาะสมมีผลต่อ Performance และ Reliability อย่างมาก สำหรับ Disk ควรใช้ SSD (NVMe ถ้า Budget อนุญาต) สำหรับ Workloads ที่ต้องการ IOPS สูง เช่น Database ใช้ HDD สำหรับ Archive หรือ Backup ที่เน้น Capacity มากกว่า Performance อย่าใช้ USB Drives หรือ SD Cards เพราะไม่ Reliable สำหรับ Production สำหรับ Ceph ถ้ามี Budget แนะนำใช้ SSD แยกสำหรับ WAL/DB ของ OSD เพื่อเพิ่ม Performance เมื่อใช้ HDD สำหรับ Data
สำหรับ Network ควรใช้ Network 10 Gbps เป็นอย่างน้อย สำหรับ Storage Traffic โดยเฉพาะ Ceph ที่มี Data Replication ข้าม Nodes ถ้าเป็นไปได้ แยก Storage Network ออกจาก Application Network (Dedicated Storage VLAN) เพื่อไม่ให้ Storage Traffic กระทบ Application Traffic สำหรับ Longhorn ที่มี Replica Count 3 การเขียน Data 1 GB จะใช้ Network Bandwidth ประมาณ 3 GB (เพราะเขียนไป 3 Replicas) สำหรับ Ceph ที่มี Replication Factor 3 เช่นเดียวกัน
Node Planning
สำหรับ Longhorn ควรมี Node อย่างน้อย 3 ตัว เพื่อรองรับ Replica Count 3 (Default) ถ้ามีน้อยกว่า 3 Nodes ต้องลด Replica Count ลง ซึ่งลด Data Protection ด้วย สำหรับ Rook-Ceph ควรมี Node อย่างน้อย 3 ตัวเช่นกัน เพื่อ MON Quorum (3 MONs) และ OSD Replication ถ้าต้องการ HA สำหรับทุก Component ควรมี 5 Nodes ขึ้นไป เพื่อ Spread MONs, MGRs, OSDs ให้กระจาย
Network Policies
ถ้าใช้ Network Policies ใน Kubernetes ต้องเปิดให้ Storage Components สื่อสารกันได้ สำหรับ Longhorn ต้องเปิด Port 9500-9504 (Engine และ Replica Communication) และ Port 8500 (Longhorn Manager API) สำหรับ Rook-Ceph ต้องเปิด Port 6789 (MON), Port 3300 (MON v2), Port 6800-7300 (OSD), Port 8443 (Dashboard) และ Port 9283 (Prometheus Metrics)
Monitoring Storage Health: เฝ้าระวังสุขภาพของ Storage
Monitoring Longhorn
Longhorn มี Built-in Metrics ที่ Export ผ่าน Prometheus Endpoint สามารถเชื่อมต่อกับ Prometheus + Grafana เพื่อสร้าง Dashboard ที่แสดง Volume IOPS และ Throughput, Volume Latency (Read/Write), Disk Usage ของแต่ละ Node, Replica Status (Healthy/Degraded/Faulted), Backup Status (Success/Failure) และ Node Storage Capacity Longhorn มี Grafana Dashboard ที่พร้อมใช้งานบน Grafana Dashboard Repository สามารถ Import มาใช้ได้ทันที
นอกจากนี้ Longhorn UI ยังแสดง Health Status ของทุก Component รวมถึง Alerts เมื่อมีปัญหา เช่น Volume ที่มี Degraded Replicas, Node ที่ Disk Space ใกล้เต็ม, Backup ที่ Fail ทำให้สามารถเห็นปัญหาได้อย่างรวดเร็ว
Monitoring Rook-Ceph
Ceph มี Built-in Monitoring ที่ครอบคลุมมาก Ceph Dashboard (Enable ผ่าน MGR Module) แสดงภาพรวมของ Cluster Health, OSD Status, Pool Usage, PG Status และอีกมากมาย Ceph Prometheus Module Export Metrics มากกว่า 1,000 Metrics ที่ครอบคลุมทุก Component ของ Ceph
Metrics สำคัญที่ควร Monitor ได้แก่ ceph_health_status ที่แสดง Overall Cluster Health (HEALTH_OK, HEALTH_WARN, HEALTH_ERR), ceph_osd_up และ ceph_osd_in ที่แสดง OSD Status, ceph_pg_active ที่แสดง Placement Group Status, ceph_pool_bytes_used ที่แสดง Pool Usage, ceph_osd_op_r_latency และ ceph_osd_op_w_latency ที่แสดง OSD Latency และ ceph_cluster_total_used_raw_bytes ที่แสดง Total Cluster Usage
Rook มี PrometheusRule CRD ที่กำหนด Alerting Rules สำหรับ Ceph เช่น Alert เมื่อ OSD Down, Alert เมื่อ Cluster Space ใกล้เต็ม, Alert เมื่อ PG ไม่ Active+Clean สามารถ Deploy ด้วย kubectl apply ได้ทันที
Disaster Recovery: การกู้คืนข้อมูลเมื่อเกิดเหตุร้ายแรง
Disaster Recovery สำหรับ Longhorn
Longhorn มี DR Features ที่ใช้งานง่าย ดังนี้ Volume Snapshots สำหรับ Quick Recovery ภายใน Cluster สร้าง Snapshot ได้ทันทีโดยไม่ต้อง Stop Pod Revert กลับไปยัง Snapshot เก่าได้ง่าย S3 Backups สำหรับ Off-site Recovery ตั้ง Recurring Backup ไปยัง S3 ได้อัตโนมัติ Restore จาก S3 ไปยัง Cluster ใหม่ได้ (ในกรณีที่ Cluster เดิมเสียหายทั้งหมด) DR Volumes สำหรับ Cross-cluster Replication Longhorn รองรับ DR Volumes ที่เป็น Standby Volume ใน Cluster อื่นที่ Sync จาก Backup ใน S3 อย่างต่อเนื่อง เมื่อ Primary Cluster ล่ม สามารถ Activate DR Volume ใน Secondary Cluster ได้ทันที
Disaster Recovery สำหรับ Rook-Ceph
Ceph มี DR Features ที่ซับซ้อนและ Powerful กว่า RBD Mirroring สำหรับ Asynchronous Replication ระหว่าง 2 Ceph Clusters สามารถ Replicate Volumes จาก Primary Cluster ไปยัง Secondary Cluster แบบ Asynchronous ทำให้มี RPO (Recovery Point Objective) ที่ต่ำ (นาทีหรือวินาที ขึ้นอยู่กับ Sync Interval) เมื่อ Primary ล่ม สามารถ Failover ไปยัง Secondary ได้ CephFS Mirroring สำหรับ Replicate CephFS Snapshots ไปยัง Remote Cluster ทำงานคล้าย RBD Mirroring แต่สำหรับ File Storage RGW Multi-site สำหรับ Replicate Object Storage ข้าม Sites
การทำ DR สำหรับ Rook-Ceph ต้อง Setup Ceph Clusters 2 แห่ง (Primary และ Secondary) ตั้ง Peering ระหว่าง 2 Clusters Enable Mirroring สำหรับ Pools ที่ต้องการ DR ทดสอบ Failover และ Failback เป็นระยะ สิ่งที่ต้องระวังคือ Network Bandwidth ระหว่าง 2 Sites ต้องเพียงพอสำหรับ Replication Traffic และ Latency ระหว่าง Sites มีผลต่อ RPO
สรุป: เลือก Longhorn หรือ Rook-Ceph ดี
การเลือกระหว่าง Longhorn และ Rook-Ceph ขึ้นอยู่กับหลายปัจจัย ไม่มีคำตอบที่ถูกต้องเพียงคำตอบเดียว ถ้าคุณอยู่ในสถานการณ์ต่อไปนี้ ให้เลือก Longhorn เมื่อ Cluster มีขนาดเล็กถึงกลาง (3-20 Nodes), ทีมไม่มี Storage Expertise, ต้องการติดตั้งและจัดการง่าย, ต้องการ Block Storage อย่างเดียว (ไม่ต้องการ Shared File Storage หรือ Object Storage), ใช้ Rancher จัดการ Kubernetes (Longhorn Integrate กับ Rancher ได้ดีมาก) หรือต้องการ Backup ไปยัง S3 ที่ง่ายและตรงไปตรงมา
เลือก Rook-Ceph เมื่อ Cluster มีขนาดกลางถึงใหญ่ (10+ Nodes), ต้องการ Performance สูงสำหรับ Database Workloads, ต้องการ Shared File Storage (CephFS) สำหรับ RWX Access, ต้องการ Object Storage (S3-compatible) ในตัว, ต้องการ Scale ไปถึงระดับ Petabytes, ทีมมี Storage Expertise หรือพร้อมเรียนรู้ Ceph หรือต้องการ Cross-cluster DR ด้วย RBD/CephFS Mirroring
ทั้ง Longhorn และ Rook-Ceph เป็น CNCF Projects ที่มี Community ขนาดใหญ่ มีการพัฒนาอย่างต่อเนื่อง และมีผู้ใช้ใน Production จำนวนมาก ทั้งสอง Solutions ช่วยแก้ปัญหา Persistent Storage บน Kubernetes On-Premise ได้อย่างมีประสิทธิภาพ ทำให้องค์กรที่ต้องการ Run Stateful Applications บน Kubernetes โดยไม่ต้องพึ่ง Cloud Provider หรือ Hardware Storage Array ราคาแพง สามารถทำได้อย่างมั่นใจ การลงทุนเวลาในการเรียนรู้และ Deploy Storage Solution ที่เหมาะสม จะคุ้มค่าอย่างมากในระยะยาว เพราะ Storage เป็นรากฐานที่สำคัญที่สุดของ Stateful Applications ทั้งหมดบน Kubernetes ในปี 2026
