Ceph: 1 TiB/s तक की यात्रा

मूल लेख ↗ Hacker News चर्चा ↗

इंजीनियर एक Ceph storage cluster का विश्लेषण करते हैं जो 68 NVMe-heavy servers का उपयोग करके 1 TiB/s से अधिक read throughput हासिल करता है, और इस बात पर ध्यान देते हैं कि वास्तविक bottlenecks कहाँ हैं (network बनाम PCIe बनाम CPU) तथा यह setup सैद्धांतिक limits के कितना करीब पहुँचता है। कई लोग Ceph की strengths—resilience, scale-out growth, और feature set—को उसकी complexity और latency के मुकाबले तौलते हैं, खासकर home labs और database workloads के लिए, और इसकी तुलना MinIO, SeaweedFS, Longhorn, GlusterFS, ZFS, btrfs, और EOS जैसे alternatives से करते हैं। बातचीत practical hardware choices को भी छूती है, 100 GbE+ switching और NICs से लेकर Raspberry Pi clusters तक, और OpenStack, Kubernetes, CERN, तथा custom AWS deployments जैसे environments में Ceph के इतिहास और वास्तविक उपयोग पर भी।

1 TiB/s के लिए हार्डवेयर और नेटवर्किंग

  • चर्चा में नोट किया गया कि 800 Gbps स्विच मौजूद हैं, लेकिन 800 G NIC अभी व्यावहारिक रूप से उपलब्ध नहीं हैं; PCIe lane की संख्या और generation एक बाधा हैं, लेकिन 32 lanes इस्तेमाल करने पर यह कोई कठोर रोक नहीं है।
  • अधिकांश योगदानकर्ता मानते हैं कि आधुनिक 100 GbE स्विच (pizza-box / leaf-spine / Clos fabrics) सभी पोर्ट्स पर full line rate संभाल सकते हैं; जो स्विच ऐसा नहीं कर पाता, उसे “toy” gear माना जाता है।
  • इस्तेमाल किए हुए 40/56/100 GbE स्विच अब अपेक्षाकृत सस्ते हैं; कुछ “bargain” MikroTik और used data-center स्विच homelab-friendly के रूप में बताए गए हैं।
  • benchmark cluster के विश्लेषण से निष्कर्ष निकलता है कि बाधा नेटवर्क है, NVMe drives नहीं; मापा गया 1 TiB/s, nodes के across सैद्धांतिक network capacity का लगभग 65% है।

Ceph की प्रदर्शन विशेषताएँ

  • Ceph मजबूत scalability और resilience देता है, लेकिन इसमें CPU overhead उल्लेखनीय है और latency अपेक्षाकृत कमजोर है, खासकर local NVMe की तुलना में।
  • benchmark विवरण compiler optimization flags और OSD threading/IOMMU contention को आश्चर्यजनक रूप से बड़े performance factors के रूप में उजागर करते हैं; developers स्वीकार करते हैं कि threading model को redesign करने की आवश्यकता है।
  • transactional databases के लिए, कई प्रतिभागी चेतावनी देते हैं कि Ceph की latency अक्सर बहुत अधिक होती है, हालांकि कुछ लोग अच्छे hardware के साथ स्वीकार्य block (RBD) latency की रिपोर्ट करते हैं।

Homelabs में Ceph

  • कई लोग घर पर Ceph से बचने की सलाह देते हैं, जब तक लक्ष्य सीखना न हो; hardware minimums (multiple nodes, fast networking, non-SMR disks) और complexity वास्तविक हैं।
  • अन्य लोग Proxmox clusters, mini‑PCs, NUCs, और यहाँ तक कि Raspberry Pis/ODROID boards पर भी Ceph सफलतापूर्वक चलाते हैं, कम performance और अधिक latency स्वीकार करते हुए।
  • एक दोहराता हुआ विषय: Ceph resilience और elasticity के लिए उत्कृष्ट है, raw speed या simplicity के लिए नहीं।

विकल्प और संबंधित प्रणालियाँ

  • सामान्य homelab alternatives: SeaweedFS, Longhorn, MinIO, Garage, GlusterFS (हालाँकि Red Hat support समाप्त हो रहा है), EOS, ZFS (विशेषकर mirror vdevs), Btrfs, LVM+mdadm, और SnapRAID।
  • चर्चा किए गए trade-offs:
    • MinIO: अच्छा S3 object store, लेकिन cluster size changes के प्रति संवेदनशील और fast disks की मांग करता है।
    • Garage: सरल, केवल duplication; homelabs के लिए ठीक, बड़े datasets के लिए नहीं।
    • ZFS mirrors: आसान incremental expansion और तेज resilvering, लेकिन 50% space efficiency।
    • CERN में EOS: physics workloads के लिए tuned, Ceph का विकल्प नहीं बल्कि उसका पूरक।

Operational complexity और rationale

  • Ceph को “जब तक सच में मतलब न हो, deploy न करें” के रूप में देखा जाता है: complex, लेकिन commodity hardware पर बड़े, सस्ते, linearly scalable, highly available storage के लिए uniquely अच्छा।
  • यह OpenStack/Kubernetes deployments, in-house EBS‑like systems, और high‑IOPS caches की नींव है, जहाँ उपयोगकर्ता cloud block storage की तुलना में बड़े cost और performance gains की रिपोर्ट करते हैं।