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

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

• यह लेख Ceph क्लस्टर के performance improvement की यात्रा को दर्ज करता है, जिसमें लंबे debugging और performance optimization की प्रक्रिया के बाद 1TiB/s की data processing speed हासिल करने की कहानी है.
• इसमें साझा किया गया है कि Clyso नाम की कंपनी ने NVMe-आधारित 10 petabyte Ceph क्लस्टर बनाने में मदद करते हुए सामने आई विभिन्न technical समस्याओं और उनके समाधानों से कैसे निपटा.
• ग्राहक कंपनी का network बहुत तेज़ था, और Ethernet configuration उपलब्ध सबसे तेज़ सेटअप्स में से एक था.

आभार

• Clyso ने अपने ग्राहक को धन्यवाद दिया, जिनके सहयोग की बदौलत Ceph community के साथ यह अनुभव साझा किया जा सका.
• IBM/Red Hat और Samsung को भी धन्यवाद, जिन्होंने तुलना परीक्षणों में इस्तेमाल किए गए hardware उपलब्ध कराए.
• Ceph contributors को भी धन्यवाद दिया गया, जो Ceph को शानदार software बनाने के लिए लगातार प्रयास कर रहे हैं.

क्लस्टर configuration

• ग्राहक ने 17 racks में फैले 34 dual-socket 2U nodes का प्रस्ताव रखा था, लेकिन Clyso ने छोटे nodes का उपयोग करने वाली कई configurations सुझाईं.
• आखिरकार Dell architecture चुना गया, जिससे लागत घटी और तेज़ memory throughput, अधिक CPU resources, और ऊँचा network throughput मिला.
• node failure की स्थिति में cluster recovery पर पड़ने वाला असर आधा हो गया.

test configuration

• CBT का उपयोग करके एक अस्थायी Ceph cluster deploy किया गया और FIO tests चलाए गए.
• library-आधारित FIO tests का उपयोग करके cluster को छोटे units में बाँटा गया और पिछले results से तुलना की गई.
• 3X replication और 6+2 erasure coding का परीक्षण किया गया, और message version 2 को encrypted mode तथा secure mode में test किया गया.

PG count पर ध्यान

• PG count का performance पर क्या असर पड़ता है, इसे प्रयोगात्मक रूप से test किया गया.
• ऊँचा PG count performance पर सकारात्मक प्रभाव डाल सकता है, लेकिन वास्तविक production environment में इसे अन्य settings के साथ मिलाकर देखना चाहिए.

कठिन शुरुआत

• hardware पर पहली बार login करने के बाद, उम्मीद से कम performance के कारण troubleshooting में कठिनाई हुई.
• शुरुआती performance tests अच्छे थे, लेकिन कई OSDs के साथ किए गए tests में performance गिर गई.

अजीब व्यवहार

• विभिन्न OSD test combinations चलाते समय performance में अजीब patterns दिखाई दिए.
• यह देखा गया कि multi-OSD tests के बाद system performance गिर जाती थी और फिर कुछ घंटों बाद वापस recover हो जाती थी.

तीन समाधान

• CPU c-state switching से होने वाली latency समस्या को हल कर performance में थोड़ा सुधार किया गया.
• IOMMU को disable करने से performance में बड़ा सुधार हुआ.
• RocksDB compile flags की समस्या को ठीक कर 4K random write performance को दोगुना किया गया.

2024 का पहला सप्ताह

• नए साल के पहले दिन दूसरे cluster में आई बड़ी outage की वजह से performance testing पर ध्यान केंद्रित नहीं किया जा सका.
• शुक्रवार को performance testing दोबारा शुरू की गई और यह पुष्टि हुई कि cluster ऊँचे load पर भी अच्छी तरह काम कर रहा था.

किस्मत की मुस्कान

• performance test results बेहतर होने लगे और यह पुष्टि हुई कि cluster linear रूप से scale कर रहा था.
• 63 nodes वाले cluster में 635GiB/s की data processing speed हासिल की गई.

आंशिक रूप से काम करता Death Star

• client nodes की कमी के कारण OSD nodes और FIO processes को share करना पड़ा.
• इस setup में भी लगभग 950GiB/s का performance हासिल किया गया.

1TiB/s तक पहुँचना

• OSD shard count और messenger thread count को समायोजित करके 1TiB/s की data processing speed हासिल की गई.

नींद; erasure coding

• 3X replication के साथ testing के बाद, cluster को ग्राहक द्वारा उपयोग किए जाने वाले 6+2 erasure coding के लिए फिर से configure कर test किया गया.
• read performance 500GiB/s से अधिक और write performance लगभग 400GiB/s तक पहुँची.

GN⁺ की राय:

1. यह लेख Ceph क्लस्टर के performance optimization की प्रक्रिया को विस्तार से समझाता है और जटिल troubleshooting के ज़रिए ऊँचा performance हासिल करने का उदाहरण देकर तकनीकी insight प्रदान करता है.
2. यह दिखाता है कि ग्राहक के साथ सहयोग, community contributors के प्रयास, और hardware व software optimization की विभिन्न रणनीतियाँ वास्तविक दुनिया में कैसे बड़े परिणाम दे सकती हैं.
3. यह लेख बड़े data storage systems पर काम करने वाले experts के साथ-साथ performance optimization में रुचि रखने वाले engineers के लिए भी उपयोगी जानकारी देता है.

[GN⁺]

Hacker News टिप्पणियाँ

• CERN के 1TB/s तक पहुँचने की खबर और Ceph का इतिहास
  • एक उपयोगकर्ता ने उल्लेख किया कि CERN ने EOS क्लस्टर के ज़रिए 1TB/s की गति हासिल की, और बताया कि यह क्लस्टर मुख्य रूप से HDD का उपयोग करता है और इसमें अधिक नोड्स हैं। साथ ही, उन्होंने Ceph का एक दिलचस्प इतिहास साझा किया कि इसे Dreamhost में आंतरिक ज़रूरतों के कारण बनाया गया था, और बाद में इसे Redhat ने अधिग्रहित कर लिया।
• पूर्व तकनीकी लीडर का अनुभव और Ceph के प्रति लगाव
  • एक उपयोगकर्ता ने Cisco में तकनीकी लीडर के रूप में काम करते हुए Kubernetes को bare metal पर सेटअप करने और GlusterFS तथा Ceph के साथ प्रयोग करने के अपने अनुभव को याद किया, और कहा कि उन्हें ऐसे प्रयोग करना पसंद था। उन्होंने यह भी कहा कि यह लेख बहुत अच्छी तरह लिखा गया है।
• नोड का आकार घटाने का सुझाव
  • एक उपयोगकर्ता ने इशारा किया कि मौजूदा सिस्टम में प्रति नोड ऊर्जा खपत अधिक है, और सुझाव दिया कि नोड का आकार घटाने के लिए इंजीनियरिंग प्रयास होने चाहिए। उनका तर्क था कि इससे कम नोड्स में भी काम चल सकता है, और किसी एक विफलता से 10 डिस्क प्रभावित होने का जोखिम भी घटेगा।
• डिजिटल डेटा स्टोरेज पर ऐतिहासिक दृष्टिकोण
  • एक उपयोगकर्ता ने कहा कि पिछले 60 वर्षों के भीतर कभी न कभी ऐसा पहला दिन रहा होगा जब पूरी दुनिया में कुल 1TiB डिजिटल डेटा स्टोर हुआ होगा, और अब हम हर सेकंड उतनी मात्रा का डेटा स्थानांतरित कर रहे हैं—यह बात उन्हें आश्चर्यजनक लगी।
• Ceph क्लस्टर से Docker cache प्रदर्शन बेहतर होने का अनुभव
  • एक उपयोगकर्ता ने साझा किया कि वे Docker layer cache बनाए रखने के लिए Ceph storage cluster चला रहे हैं, और EBS से Ceph पर स्विच करने के बाद throughput में बड़ा सुधार देखा। उन्होंने यह भी कहा कि Ceph को लगभग किसी maintenance की ज़रूरत नहीं पड़ती।
• Kubernetes में storage controller software की समस्याएँ
  • एक उपयोगकर्ता ने कहा कि Kubernetes में dynamic storage से जुड़ी सबसे बड़ी समस्या I/O नहीं है, बल्कि तब आती है जब storage controller software वास्तविक समस्याओं का सामना करता है। खासकर, rook/ceph और Longhorn का उपयोग करते समय उन्होंने अनुभव किया कि PVC बहुत लंबे समय बाद attach होते हैं।
• हार्डवेयर की सैद्धांतिक सीमा की तुलना में 1 TiB/s प्रदर्शन का विश्लेषण
  • एक उपयोगकर्ता ने विश्लेषण किया कि 1 TiB/s का प्रदर्शन हार्डवेयर की सैद्धांतिक सीमा की तुलना में कैसा है, और बताया कि network bottleneck बन रहा है। उन्होंने निष्कर्ष निकाला कि Ceph की जटिलता CPU पर काफी भार डालती है और OSD threading model अभी optimized नहीं है; साथ ही उन्होंने सुधार की उम्मीद जताई।
• Ceph और अन्य object storage engine की तुलना का अनुरोध
  • एक उपयोगकर्ता ने कहा कि वे Ceph की तुलना MinIO, Garage जैसे अन्य object storage engine के साथ, benchmark सहित, देखना चाहते हैं।
• ट्रांज़ैक्शन database storage के लिए Ceph की उपयुक्तता और IO latency पर सवाल
  • एक उपयोगकर्ता ने पूछा कि क्या Ceph ट्रांज़ैक्शन database storage के लिए उपयुक्त है और इसकी IO latency कैसी है। उन्होंने यह भी कहा कि वे Oracle के cluster file system या Veritas जैसे सिस्टम से मुकाबला कर सकने वाले किसी सस्ते file system की ओर जाना चाहते हैं।