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

 (ceph.io)
4 पॉइंट द्वारा GN⁺ 2024-01-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Clyso ने HDD-आधारित Ceph cluster को 10PB NVMe deployment में बदलने से पहले burn-in test किया, और 630 OSD वाले single cluster पर 1.0 TiB/s read हासिल किया
  • अंतिम hardware में 68 Dell PowerEdge R6615 और प्रति node 10 NVMe configuration था, लेकिन peak performance test उपलब्ध 63 machines और 630 OSD के साथ किया गया
  • शुरुआती bottleneck BIOS CPU c-state, kernel IOMMU mapping contention, और upstream Ceph Ubuntu Deb package के RocksDB compile flags की समस्या ठीक करके हटाए गए; compaction time लगभग 3 गुना घटा और 4KB random write 2 गुना बेहतर हुआ
  • 3X replication configuration में peak values थीं: 4MB read 1025GiB/s, 4MB write 270GiB/s, 4KB random read 25.5M IOPS, 4KB random write 4.9M IOPS; वहीं 6+2 erasure coding ने 4MB read 547GiB/s और write 387GiB/s दर्ज किया
  • बाकी जोखिम यह है कि बड़े पैमाने के writes में कुछ PG active+clean+laggy state में चले जाते हैं और throughput तेजी से गिर जाता है; प्रति node 10 से अधिक NVMe पर अधिक throughput के लिए 200GbE या उससे ऊपर का network चाहिए

10PB NVMe Ceph cluster का design

  • ग्राहक अपने मौजूदा HDD-आधारित Ceph cluster को 10PB NVMe deployment में बदलना चाहता था, और RBD, RGW, CephFS के लिए कोई specific requirement नहीं थी
  • design conditions में 17 racks में distribution, प्रति rack 4U space, power, cooling, density, और vendor preference शामिल थे
  • नए nodes को मौजूदा cluster में service interruption के बिना integrate करना था, और network पहले से बना हुआ fast Ethernet configuration था
  • शुरुआती proposal 17 racks में 34 dual-socket 2U nodes रखने का था, लेकिन अंत में Clyso द्वारा design किया गया Dell-based configuration चुना गया
    • final quote मूल configuration से लगभग 13% सस्ता था
    • प्रति OSD memory कम हुई, लेकिन फिर भी प्रति OSD करीब 12GiB थी, और memory throughput तेज था
    • single-socket configuration, कुल CPU resources अधिक, कुल network throughput बड़ा, latest AMD processor और DDR5 RAM का इस्तेमाल किया गया
    • छोटे nodes का उपयोग कर node failure का cluster recovery पर असर आधा कर दिया गया

Hardware और basic configuration

  • system specifications इस प्रकार हैं
    • Nodes: 68 × Dell PowerEdge R6615
    • CPU: 1 × AMD EPYC 9454P 48C/96T
    • Memory: 192GiB DDR5
    • Network: 2 × 100GbE Mellanox ConnectX-6
    • NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
    • OS: Ubuntu 20.04.6 Focal
    • Ceph: Quincy v17.2.7 upstream Deb packages
  • ग्राहक प्रति rack अतिरिक्त power consumption को लगभग 1000~1500W तक सीमित करना चाहता था
    • प्रति rack 4 nodes का total TDP कम से कम 1120W माना गया, जिसमें base power, CPU peak, और power supply inefficiency जुड़ती है
    • जरूरत पड़ने पर processor cTDP घटाकर प्रति rack लगभग 100W बचाया जा सकता है, ऐसा आंका गया
  • 1U Dell server upstream Ceph performance lab systems की latest generation के करीब का configuration था
    • पिछली generation के hardware में नहीं थीं, लेकिन इस hardware को प्रभावित करने वाली performance issues testing के दौरान मिलीं

Test method और benchmark selection

  • burn-in test CBT से temporary Ceph cluster deploy करके और FIO tests चलाकर किया गया
  • OSD के लिए 8GB osd_memory_target set किया गया
    • production में अधिक osd_memory_target भी संभव माना गया
  • ग्राहक को block या S3 workload testing की जरूरत नहीं थी, लेकिन RADOS bench के बजाय FIO के librbd engine का उपयोग किया गया
    • बड़े पैमाने पर RADOS bench में cluster saturate करने के लिए instances की संख्या तय करना कठिन है, और पहले कई concurrent pools की जरूरत पड़ी थी
    • मौजूदा upstream lab results से तुलना के लिए वही librbd-based FIO test इस्तेमाल किया गया
    • FIO एक well-known और trusted tool है, इस बात को भी ध्यान में रखा गया
  • kernel RBD test छोड़ दिया गया
    • librbd engine पुराने mount point के कारण system reboot की जरूरत वाली समस्या से बचा सकता है
    • इस cluster में IPMI access नहीं था, और test completion deadline भी tight थी
    • पिछले tests के आधार पर, पर्याप्त clients होने पर total performance broadly similar रहने की उम्मीद थी
  • test targets में 3X replication और 6+2 erasure coding शामिल थे
  • msgr V2 को unencrypted mode और secure mode दोनों में test किया गया
    • ms_client_mode = secure
    • ms_cluster_mode = secure
    • ms_service_mode = secure
    • ms_mon_client_mode = secure
    • ms_mon_cluster_mode = secure
    • ms_mon_service_mode = secure
  • FIO ने पहले RBD volumes को बड़े writes से भरा, फिर 4MB और 4KB IO tests को अलग-अलग 300 seconds तक चलाया
    • debugging runs में इसे 60 seconds तक घटाया गया
    • scrub, deep scrub, PG autoscaling, PG balancing जैसे background processes disable किए गए

PG count का performance पर प्रभाव

  • पिछले upstream lab tests में यह confirm हुआ कि PG count performance पर बड़ा असर डाल सकता है
  • कम PG count में random distribution की clumpiness performance को प्रभावित कर सकती है, और कुछ हिस्से को extra balancing से कम किया जा सकता है
  • fast cluster में OSD के अंदर PG lock contention भी overall performance में अहम भूमिका निभा सकता है
    • PG count बढ़ाने के अलावा इस समस्या को कम करना आसान नहीं है
  • सिर्फ 60 OSD इस्तेमाल करने वाले test में भी 3X replicated RBD pool की random read performance 16384 PG तक scale हुई
    • writes पहले peak पर पहुंच गए, लेकिन 2048 PG तक benefit था
  • high PG count को production में blindly apply नहीं करना चाहिए
    • PG log length और PG stat update जैसी Ceph defaults असर डाल सकती हैं
    • OSD प्रति 100 PG की पुरानी practice अब भी valid है या नहीं, इसे फिर से review करने की जरूरत है

शुरुआती performance issues और अजीब behavior

  • नए hardware में पहली बार US Thanksgiving के बाद वाले हफ्ते login किया जा सका, और original plan 1–2 weeks burn-in validation के बाद इसे existing cluster में integrate करने का था
  • low-level performance tests शुरुआत में अच्छे लग रहे थे
    • iperf network test प्रति node 200Gb/s के करीब था
    • कुछ nodes के NVMe drives की basic performance भी reasonable दिखी
  • सभी 68 nodes का operating system internal Dell BOSS m.2 boot drive के बजाय गलती से 2 OSD drives पर deploy हो गया था
    • planned 3-node 30 OSD test के बजाय प्रति node केवल 8 NVMe इस्तेमाल करके test करना पड़ा
  • पहला Ceph result कम OSD count को ध्यान में रखने पर भी expected से बहुत कम था
    • random read ही मुश्किल से acceptable level के करीब था, लेकिन पर्याप्त नहीं था
  • single node और single OSD test तक narrow करने पर abnormal pattern दिखाई दिया
    • single OSD test में ठीक चलने वाला system 8 OSD test के बाद slow हो गया
    • इसके बाद single OSD test भी कई घंटों तक खराब performance देता रहा, फिर recover हुआ
    • अगर multi OSD test न चलाया जाए तो performance लगातार high रहती थी
  • drives पर सीधे FIO चलाने पर वही समस्या reproduce नहीं हुई
  • 8 OSD test के दौरान एक specific OSD बाकी OSDs से बहुत ज्यादा CPU use कर रहा था
  • OSD wallclock profile ने io_submit में बहुत समय खर्च होते दिखाया, जो आमतौर पर drive queue भर जाने पर kernel के block होने वाला pattern होता है

तीन fixes

  • BIOS performance mode और c-state

    • पहली fix यह थी कि BIOS maximum performance mode में नहीं था, इसलिए CPU c-state enabled था
    • Ceph CPU c-state transitions से पैदा होने वाली latency के प्रति बहुत sensitive है
    • maximum performance mode से c-state disable करने पर performance 10~20% improved हुई, लेकिन target performance के लिए यह पर्याप्त नहीं था

  • IOMMU contention

    • दूसरी समस्या kernel-side perf profile में सामने आई
    • खराब run के दौरान native_queued_spin_lock_slowpath और IOMMU DMA mapping path में बहुत समय खर्च हुआ
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • kernel में IOMMU disable करने पर 8-node test की 4MB read/write performance काफी सुधरी
    • इस fix के बाद भी 4KB random write issue बाकी रहा

  • RocksDB compile flags

    • तीसरी समस्या यह थी कि 4KB random write और RocksDB compaction performance expected से कम थी
    • पहले Ceph में इसी तरह के symptoms दो causes से जुड़े थे
    • TCMalloc support के बिना compile किया जाना
    • proper cmake flags और compiler optimization के बिना compile किया जाना
    • upstream Ceph Ubuntu packages में TCMalloc शामिल था
    • 17.2.7 Ubuntu package build logs में confirm हुआ कि RocksDB सही compile flags के साथ build नहीं हुआ था
    • Canonical और Gentoo ने अपने builds में इस issue को fix कर दिया था
    • upstream container इस्तेमाल करने वाले Debian/Ubuntu cephadm users प्रभावित नहीं दिखे
    • fixed custom 17.2.7 packages build करने पर compaction time लगभग 3 गुना घटा, और 4KB random write performance 2 गुना बढ़ी

2024 के पहले हफ्ते की scaling test

  • 2 जनवरी को related दूसरे cluster की large-scale outage response के कारण performance testing delay हुई
  • शुक्रवार से CBT और tests को फिर से configure किया गया, और इस बार प्रति node सभी 10 drives उपयोग किए जा सके
  • FIO client count इस तरह बढ़ाया गया कि औसतन प्रति OSD io_depth 128 वाला लगभग 1 FIO client हो
  • 3-node test ने 4MB random read में 63GiB/s record किया
  • 10-node test ने 213.5GiB/s record किया
    • 3-node के मुकाबले लगभग linear scaling, 98.4% level
  • उस समय 68 nodes में से केवल 63 usable थे
    • 32 nodes, 320 OSD को एक तरफ रखा गया
    • 31 client nodes पर प्रति node 10 FIO processes चलाए गए
  • 320 OSD scale पर read 635GiB/s और 4KB random read 15 million IOPS से अधिक हासिल हुआ
  • average latency और tail latency scaling tests में consistent दिखीं
    • PG count और FIO client count को OSD के साथ बढ़ाने का असर माना गया
    • test बहुत IO-heavy state में था, और ऐसा माना गया कि यह उस point पर पहुंच गया था जहां और IO जोड़ने से performance नहीं बढ़ती, सिर्फ latency बढ़ती है

630 OSD पर 1 TiB/s हासिल करना

  • full capacity test के लिए अलग client nodes और नहीं थे, इसलिए FIO processes को OSD nodes पर co-locate किया गया
    • client के local OSD से communicate करने की संभावना 1/63 थी, जिससे हल्का network benefit मिलता है
    • दूसरी ओर OSD node पर FIO client साथ रखने से performance loss हो सकता है
  • 63 nodes पर 630 OSD खड़ा करने वाले CBT deployment में करीब 15 minutes लगे
  • पहला attempt लगभग 950GiB/s था, जो 1 TiB/s के बहुत करीब था
  • इसके बाद OSD shard और async messenger thread घटाए गए और Reef RocksDB tuning लागू की गई
    • read performance थोड़ी घटी और write performance improved हुई
    • random write performance लगभग 20% improved हुई
    • बड़ा असर shard/thread change से आया लगता है
  • PG count को double करने और client count को फिर बढ़ाने का experiment भी किया गया
    • 4MB random read client count increase के साथ थोड़ा improved हुआ
    • small random read IOPS खराब हुई
    • प्रति node FIO 8, कुल 504 processes पर sequential write performance में बड़ी गिरावट आई
  • 504 FIO processes द्वारा 4MB writes करने पर कुछ PG active+clean+laggy state में चले गए
    • throughput cluster की possible performance के केवल एक हिस्से जितना था, फिर भी समय के साथ laggy PG बढ़ते गए
    • workload खत्म होने तक cluster उस state से recover नहीं हुआ
    • Ceph docs के अनुसार laggy state में replica, primary से new lease को समय पर acknowledge नहीं कर पाता, जिससे IO temporarily suspend होता है
  • अंततः default Ceph settings — 8 shards, प्रति shard 2 threads, 3 msgr threads — 4MB read के लिए सबसे suitable रहीं
  • 256K PG, 630 OSD, 504 FIO client processes की condition में ceph -s ने 1.0 TiB/s read दिखाया
    • सभी 630 OSD up/in state में थे
    • सभी 262145 PG active+clean state में थे
    • displayed read operations 266.15k op/s थे

6+2 erasure coding results

  • ग्राहक का actual previous target cluster 6+2 erasure coding configuration था, इसलिए अलग test जरूरी था
  • पिछले tests में अच्छी तरह काम करने वाले PG, shard, client values चुनकर EC test किया गया
  • async messenger thread busy दिख रहा था, इसलिए default से ज्यादा बढ़ाने का experiment किया गया
  • 4~5 async msgr threads पर ये performance हासिल हुई
    • read: 500GiB/s से अधिक
    • write: लगभग 400GiB/s
  • 6+2 EC read, 3X replication से slow होने का कारण network overhead difference है
    • replication में primary OSD को local data पढ़कर client को भेजना होता है, इसलिए network overhead असल में 1X होता है
    • 6+2 EC में primary को object बनाने के लिए replicas से 6 chunks में से 5 पढ़कर client को भेजना होता है
    • request का total network overhead लगभग (1 + 5/6)X होता है
  • writes में उल्टा pattern दिखता है
    • 3X replication में client द्वारा primary को भेजे गए object को primary दो secondaries को फिर भेजता है, इसलिए total network overhead 3X होता है
    • EC में secondaries को 7/8 chunks भेजने होते हैं, इसलिए बड़े writes में better performance दिखती है
  • small IO की IOPS अलग issue है
    • बहुत छोटे read/write में Ceph उस object के PG में शामिल सभी OSDs को access करता है
    • भले data of interest सिर्फ एक chunk में हो, stripe में शामिल सभी OSDs से data लाया जाता है
    • Clyso ने 2023 की summer में erasure coding के partial stripe reads implement करने वाले PR को revive किया, और असर बड़ा था
    • Squid में merge हो पाएगा या नहीं, यह अभी clear नहीं है

msgr encryption का प्रभाव

  • अगर customer msgr-level encryption इस्तेमाल करे तो impact समझने के लिए msgr v2 encryption test भी किया गया
  • 3X replication और 6+2 erasure coding दोनों में encryption enabled results की previous results से तुलना की गई
  • सबसे बड़ा impact बड़े reads में दिखा
    • करीब 1 TiB/s से लगभग 750GiB/s तक गिरावट
  • अन्य items में अधिक moderate लेकिन consistent performance drop दिखा
  • PG scaling test और kernel RBD test भी करना चाहते थे, लेकिन system customer को वापस देकर re-imaging और integration work शुरू करना था

Final peak performance summary

  • tests में हासिल peak numbers इस प्रकार हैं
Item 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
Co-located FIO No No No Yes Yes
4MB Read 63 GiB/s 214 GiB/s 635 GiB/s 1025 GiB/s 547 GiB/s
4MB Write 15 GiB/s 46 GiB/s 133 GiB/s 270 GiB/s 387 GiB/s
4KB Rand Read 1.9M IOPS 5.8M IOPS 16.6M IOPS 25.5M IOPS 3.4M IOPS
4KB Rand Write 248K IOPS 745K IOPS 2.4M IOPS 4.9M IOPS 936K IOPS
  • test खत्म होने के बाद सभी hardware re-image किए गए, और नए OSD customer के existing HDD cluster में deploy किए गए
  • Dan के upmap-remapped script से migration control किया गया, और existing data का लगभग 80% NVMe-based OSD पर move किया गया
  • शुरुआत में test में लागू सभी tuning तुरंत इस्तेमाल करने के बजाय, पहले mostly default configuration में cluster behavior verify करने का फैसला किया गया
  • test data भविष्य में customer को performance issues आने पर system को आगे tune करने में इस्तेमाल किया जा सकता है

बाकी काम और scaling limits

  • बड़े scale के write load में आई laggy PG problem को solve करना जरूरी है
    • write workload बढ़ने पर Ceph का collapse होना acceptable नहीं है
  • इस test से confirm हुआ कि Ceph 2×100GbE NIC को saturate कर सकता है
  • प्रति node 10 NVMe drives से अधिक इस्तेमाल करते समय throughput और बढ़ाने के लिए 200GbE या उससे ऊपर चाहिए
  • IOPS ज्यादा complex है
    • PG count बड़ा असर डाल सकता है
    • OSD threading model भी अहम भूमिका निभाता है
    • कई deployments में प्रति node लगभग 400K~600K random read IOPS की wall से सामना हुआ
  • improvement points के रूप में async msgr और kernel के interface, तथा shard queue में नया काम आने पर OSD thread के wake-up तरीके की ओर संकेत किया गया
  • high load पर बेहतर result पाने के लिए OSD code modify किया गया था, लेकिन उसकी कीमत lower-load latency खराब होना थी
  • IOPS improvement के लिए कई दिशाओं से approach और कुछ OSD threading code को rewrite करने की संभावना जरूरी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-21
Hacker News टिप्पणियाँ

  • Ceph का एक दिलचस्प इतिहास है
    इसे DreamHost के संस्थापकों ने अपनी आंतरिक ज़रूरतों के लिए बनाया था, और DreamHost उस समय IaaS और PaaS जैसे शब्द उद्योग में प्रचलित होने से पहले ही VPS, managed OS/database/app server जैसी सेवाएँ वास्तव में दे रहा था
    बाद में Ceph को अलग कंपनी के रूप में निकाला गया और Red Hat ने उसे अधिग्रहित कर लिया
    https://en.wikipedia.org/wiki/DreamHost

    • मैं अभी भी DreamHost का ग्राहक हूँ, और मुझे उस समय के ऐसे blog posts या newsletters याद हैं जिनमें कहा जाता था, “हम Ceph नाम की कोई चीज़ बनाने की कोशिश कर रहे हैं, यह कुछ शानदार बन सकती है”
      तब हर वाक्य को बेचने के लिए चमकाया हुआ marketing copy नहीं होता था, बस लोग अपने छेड़छाड़ करके बनाए हुए काम को साझा करते थे
      मुझे याद है कि यह संस्थापकों में से एक का college project था, और बाकी संस्थापक उसका समर्थन करते हुए साथ जुड़े थे; मेरी समझ से Docker की शुरुआत भी कुछ ऐसी ही थी
    • थोड़ा और जोड़ूँ तो, DreamHost के संस्थापक Sage Weil ने इसे UC Santa Cruz में graduate studies के दौरान भी बनाया था
      UCSC वह जगह थी जहाँ से काफ़ी अच्छा storage research निकला था

  • बढ़िया लेख है। CERN ने भी हाल ही में 1TB/s हासिल किया, लेकिन Ceph से नहीं बल्कि EOS(https://cern.ch/eos) के साथ
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    हालाँकि, हमारे EOS cluster में nodes कहीं ज़्यादा हैं और उसमें ज़्यादातर HDDs इस्तेमाल होते हैं। CERN, Ceph का भी व्यापक रूप से उपयोग करता है

    • शानदार। Ceph को लेकर आपका नज़रिया क्या है, यह जानने की जिज्ञासा है। क्या लंबी अवधि में EOS पर migration की कोई योजना है?

  • मुझे इस तरह के experiments बहुत पसंद थे। Cisco में tech lead के रूप में काम करते हुए मुझे bare metal पर Kubernetes बनाना, और GlusterFS तथा Ceph को खुद सेट up करके यह सीखने और तुलना करने का मौका मिला कि कौन बेहतर है
    याद पड़ता है कि यह लगभग 2017/2018 की बात है, और वह अच्छा दौर था। यह लेख भी बहुत अच्छा था

    • Aerospike response time सुधारने के लिए मुझे AWS instance types ही नहीं, बल्कि एक ही type के अंदर individual instances की speed तक तुलना करने वाले ढेर सारे benchmarks चलाने पड़े थे
      कुछ NVMe SSDs दूसरों की तुलना में ज़्यादा इस्तेमाल हुए थे, इसलिए फ़र्क आता था, और यह सच में बेहद बेतुका काम था
    • अरे, आप Heketi इस्तेमाल करने वालों में से हैं। मेरा भी लगभग उसी समय वैसा ही अनुभव था, और वह सच में बहुत मज़ेदार था। सब कुछ इतना नया था, और उतना ही टूटा हुआ भी

  • किसी ने कहा कि node का आकार और छोटा किया जाए तो अच्छा होगा। यहाँ वर्णित system में प्रति node 10 disk हैं और लगभग 300W/node लगता है, यानी लगभग 30W प्रति disk।
    overhead काफ़ी बड़ा है, और थोड़ी-सी redundancy पाने के लिए भी काफ़ी storage space चाहिए।
    थोड़ी engineering की जाए तो लगता है कि पूरे setup को 10वें हिस्से तक घटाया जा सकता है। जैसे NVMe के लिए 4 PCIe lanes, 2x10GbE (2 SFP+ sockets), काफ़ी तेज़ ARM या RISC-V CPU, और boot के लिए eMMC या SD slot वाला छोटा single-board computer बनाया जाए।
    इससे इसे कुछ nodes के scale तक नीचे लाया जा सकेगा, और एक single failure में एक साथ 10 disks जाने का exposure भी कम होगा।
    ऐसे systems को 4U enclosure में बड़ी संख्या में रखा जा सकता है, और चाहें तो उसी enclosure के अंदर internal nodes को aggregate करने के लिए पूरी तरह independent 2 switches भी रखे जा सकते हैं।

    • मैंने पहले कई ODROID-HC2 के साथ 5-node Ceph cluster चलाया था।
      armhf processor होने की वजह से install करना बहुत दर्दनाक था, लेकिन एक बार चलने के बाद यह ठीक से काम करता था। बस single 1Gb NIC की वजह से धीमा था।
      उस समय यह सिर्फ़ सीखने के लिए था।
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • Nvidia के SODIMM compute module interface से इस concept को पहले से validate किया जा सकता है।
      मुझे जल्द ही 7W ARM Turing RK1 के दो units मिलने वाले हैं, जिनमें हर एक PCIe 3x4 पर 4GB/s देता है, और Turing Pi 2 cluster board ITX form factor में 4 modules तक लगा सकता है।
      कुल लागत 820 डॉलर में मैं प्रति watt 3Gbps से ज़्यादा की उम्मीद कर रहा हूँ।
      अभी तक bottleneck PCIe lanes ही हैं। 90 डॉलर वाला 2TB SSD भी PCIe 4x4 पर 7GB/s के रूप में listed है, इसलिए अभी single-board computer को best solution नहीं मानता।
      Ampere Altra line 40W पर PCIe 4x128 support करती दिखती है, इसलिए 100G networking के साथ 1U blade दिलचस्प हो सकता है।
      लेकिन homelab में भी ARM से जुड़े bugs और missing optimizations बहुत देखे हैं, इसलिए यह कहना मुश्किल है कि ऐसा समाधान अभी data center के लिए तैयार है।
    • सस्ते 100Gbps switches और 100Gbps interfaces बढ़ने के साथ 10Gbps धीरे-धीरे पुराना पड़ता जा रहा है।
      आज 10Gbps interface के साथ Ceph setup को justify करने के लिए उसे सच में बहुत छोटा और बहुत सस्ता होना पड़ेगा।
      और अगर scale इतना छोटा है, तो हर server में local NVMe storage रखना ज़्यादा बेहतर हो सकता है।
    • अगर थोड़ा अजीब-सा हिसाब लगाएँ, तो यह cluster लगभग 0.8Gbps प्रति watt संभालता है।
      मोटे तौर पर हिसाब है: 1TB/s × 8 bits/byte × 1024GB/TB ÷ 34 nodes ÷ 300W।
      नया Mac mini जैसा बहुत efficient ARM system interactive use में लगभग 10W लेता है और 10Gbps network संभाल सकता है, यानी data के हिसाब से लगभग 1Gbps प्रति watt।
      यानी मूल लेख का cluster मोटे तौर पर बहुत efficient ARM system के बराबर bits/sec/watt स्तर पर है।
      छोटे nodes इस्तेमाल करने से वास्तविक efficiency बेहतर होगी, ऐसा नहीं लगता; उल्टा लागत बढ़ सकती है। आजकल शक्तिशाली servers का performance per watt काफ़ी अच्छा है।
      फिर भी, यह general-purpose hardware पर चलने वाला open source software है, इसलिए कुछ सौ डॉलर में इसे ख़ुद आज़माया भी जा सकता है।
    • इस architecture में inefficiency का मुख्य स्रोत शायद NVMe controller है।
      जब operating system और NVMe device एक-दूसरे से दूर हों, तो controller को request के इरादे का अनुमान लगाकर placement और wear leveling को सबसे अच्छे तरीके से संभालना पड़ता है, इसलिए स्वाभाविक inefficiency आती है।
      नया FDP (flexible data placement) feature operating system को ज़्यादा control देकर इसी समस्या को हल करने की कोशिश है।
      सबसे अच्छा यह होगा कि इसे host operating system side पर ऊपर खींचा जाए, और flash को जहाँ तक संभव हो “PCIe device के रूप में जुड़ा हुआ एक बहुत बड़ा बेवकूफ़ transistor array” की तरह expose किया जाए।
      abstraction layers हटाने पर, लगता है कि मनचाहा system parallelism पाने के लिए integrated 100Gbps NIC और उसके अनुपात की flash वाले Atom-जैसे hardware units से इसे बनाया जा सकता है।

  • इतिहास में ऐसा एक समय ज़रूर रहा होगा जब दुनिया भर में store किए गए digital data की कुल मात्रा पहली बार 1TiB तक पहुँची होगी।
    वह दिन लगभग निश्चित रूप से पिछले 60 सालों के भीतर रहा होगा।
    लेकिन अब किसी काफ़ी हद तक arbitrary organization के server पर हर सेकंड उतना data move हो रहा है। कोई nation-state या supranational research project भी नहीं।

    • मुझे याद आया कि मैंने कभी हिसाब लगाया था कि मेरा desktop PC शायद 1978 के आसपास पृथ्वी के सभी computers को मिलाकर भी उनसे ज़्यादा शक्तिशाली होता।
    • कम से कम 20 साल से ज़्यादा हो चुके हैं। मुझे एक पुराने sysadmin याद हैं जो 2003 से पहले petabyte manage करने की बातें करते थे।

  • दिलचस्प लेख है। हम Docker layer cache बनाए रखने के लिए Ceph storage cluster चलाते हैं।
    EBS से Ceph पर आने के बाद throughput का फ़र्क़ बहुत बड़ा था। write throughput 146MB/s और 3,000 IOPS से बढ़कर 900MB/s और 30,000 IOPS हो गया।
    सबसे अच्छी बात यह है कि यह लगभग बस काम करता रहता है। कभी-कभार filesystem trim जैसी चीज़ों को छोड़ दें तो इसे लगभग संभालना नहीं पड़ता।
    cache system के लिए यह बहुत बड़ा सुधार था।
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • मैंने लगभग 10 साल पहले बहुत मिलता-जुलता काम किया था। उसी performance baseline पर EBS की लागत node disks पर चल रहे Ceph cluster से 10 गुना से भी ज़्यादा थी।
      बाद में हम अपने rack पर गए, तो लागत फिर लगभग 10वें हिस्से तक आ गई, और internal operational capability बन जाने के बाद हम काफ़ी स्वतंत्र हो गए।
    • यह जानने की जिज्ञासा है कि EBS को bare metal पर host किया गया था या नहीं। Ceph को कैसे host किया जा रहा है—अपने/leased bare metal पर, या EC2 virtual machines पर?
      सिर्फ़ ब्लॉग देखकर यह तुरंत साफ़ नहीं हुआ।

  • cluster के भीतर dynamic storage के साथ जो सबसे बुरी समस्याएँ मैंने देखीं, वे शुद्ध I/O problems नहीं थीं।
    समस्या ज़्यादा इस बात की थी कि Kubernetes का storage controller software real-world issues को ठीक से handle नहीं कर पाता, जैसे pod के मर जाने पर PVC बहुत लंबे timeout तक attach नहीं होता, और pod PVC lock छूटने तक ContainerCreating state में अटका रहता है।
    ऐसा rook/ceph और Longhorn इस्तेमाल करने वाले कई clusters में हुआ है।

  • यह जानने की जिज्ञासा है कि क्या किसी ने होमलैब में Ceph चलाया है। आख़िरी बार जब देखा था, तब इसकी हार्डवेयर आवश्यकताएँ काफ़ी बड़ी थीं

    • आवश्यकताएँ अभी भी बड़ी हैं। जिसने प्रोडक्शन और होमलैब, दोनों तरह की डिप्लॉयमेंट की हैं, उसके नज़रिए से कहूँ तो, अगर आपका उद्देश्य सिर्फ़ अनुभव लेना या डेमो सेट करना नहीं है, तो इसे करने की ज़्यादा ज़रूरत नहीं है
      जब यह ठीक चलता है, तो शानदार होता है, लेकिन समस्या आने पर यह बहुत बड़ा सिरदर्द बन जाता है
      अगर आपकी दिलचस्पी distributed storage में ही है, तो होमलैब सेटअप के लिए इससे बेहतर विकल्प मौजूद हैं
      seaweedfs छोटे और बहुत बड़े, दोनों स्केल पर कई सालों तक बहुत स्थिर रहा है, और वास्तव में एक प्रोडक्शन Ceph कॉन्फ़िगरेशन को उसी पर माइग्रेट किया गया
      Kubernetes की दुनिया में रहते समय Longhorn भी स्थिर था
      GlusterFS भी, अगर आप जानते हैं कि आप क्या trade-off स्वीकार कर रहे हैं, तो अब भी ठीक है
    • मैंने इसे इस्तेमाल किया है, और web UI, object storage, file storage सब बहुत शानदार थे
      लेकिन ठीक-ठाक performance निकालना बहुत मुश्किल था, और छोटे क्लस्टर में metadata daemon काफ़ी आसानी से रुक सकता था
      आख़िरकार, जब मज़ा खत्म हो गया, तो मैं फिर एक single machine पर ZFS चलाने की तरफ़ लौट गया
    • मुझे काम के माहौल और होमलैब-जैसे माहौल, दोनों में Ceph इस्तेमाल करने का अनुभव है
      सबसे पहले, यह ध्यान में रखना चाहिए कि Ceph एक distributed storage system है, इसलिए कई nodes होना इसकी बुनियादी शर्त है
      सीखने के लिए आप एक single machine पर सब कुछ virtualize कर सकते हैं, लेकिन अलग physical machines हों तो काफ़ी बेहतर रहता है
      Ceph, ZFS की तरह, disks तक physical access को प्राथमिकता देता है
      इसके अलावा, एक ठीक-ठाक network connection भी चाहिए। मुझे लगता है कि जब लोग Ceph की ऊँची hardware requirements के बारे में सोचते हैं, तो ज़्यादातर यही हिस्सा उनके दिमाग़ में होता है
      आदर्श रूप से कम-से-कम 10GbE अच्छा है, और अगर ज़्यादा performance चाहिए तो उससे ऊपर की ज़रूरत होगी। खासकर backfill जैसे कामों में network traffic बहुत ज़्यादा हो सकता है
      अगर होमलैब का हार्डवेयर सस्ते में मिल जाए तो 25Gbps भी अच्छा है, 50Gbps तकनीकी रूप से लगभग dead end है, और 100Gbps अच्छी तरह काम करता है
      फिर भी, होमलैब के लिए 10GbE वाले सस्ते mini PC या NUC पर भी यह ठीक से चल सकता है, और आपको उचित performance और अच्छा learning experience मिल सकता है
      आप Ceph को सीधे bare metal पर install कर सकते हैं, और अगर आप होमलैब Kubernetes वाले रास्ते पर जाना चाहते हैं, तो Rook(https://rook.io/) इस्तेमाल कर सकते हैं
      उम्मीद है यह मददगार होगा, और अगर कोई अतिरिक्त सवाल हो तो बताइए
    • Ceph की तरफ़ से एक ब्लॉग पोस्ट है जिसमें कुछ Raspberry Pi 4 पर Ceph install किया गया है
      उस स्तर को किसी भी तरह से भारी हार्डवेयर नहीं कहा जा सकता
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • मैं अपनी लैब में Ceph चला रहा हूँ। यह CPU काफ़ी इस्तेमाल करता है, लेकिन अगर आप तेज़ network का खर्च/समझौता स्वीकार कर सकते हैं, तो यह अच्छी तरह काम करता है
      कम-से-कम 10Gb, और संभव हो तो 40Gb या उससे ज़्यादा बेहतर है, और अगर आप spinning disks इस्तेमाल कर रहे हैं, तो कुछ nodes में हर एक पर कम-से-कम 6 disks होना बेहतर है
      अगर सब कुछ SSD है, तो प्रति node disks की संख्या काफ़ी कम होने की अच्छी संभावना है

  • मैंने यह देखने के लिए गणना की कि 1TiB/s वास्तविक हार्डवेयर की सैद्धांतिक सीमा से कैसे तुलना करता है
    यह क्लस्टर 68 नोड्स से बना है, और हर नोड Dell PowerEdge R6615(https://www.delltechnologies.com/asset/en-us/products/server...) है
    उपयोग किया गया कॉन्फ़िगरेशन 10 U.2 drive bays वाला R6615 है, और U.2 links डेटा को PCIe Gen 4 की 4 lanes पर ले जाती हैं. एक PCIe lane 16Gbit/s है, और 128b-132b encoding की वजह से overhead लगभग 3% है, इसलिए उसे नज़रअंदाज़ किया जा सकता है
    इसलिए एक U.2 link की अधिकतम link bandwidth 16×4=64Gbit/s, यानी 8Gbyte/s है. लेकिन इस्तेमाल हो रही U.2 NVMe drive, Dell 15.36TB Enterprise NVMe Read Intensive AG, की read throughput 7Gbyte/s दिखती है(https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), इसलिए U.2 link का 8Gbyte/s bottleneck नहीं है
    प्रति नोड 10 U.2 drives होने से, हर नोड local read I/O में अधिकतम 10×7=70Gbyte/s तक दे सकता है
    लेकिन हर नोड की network bandwidth सिर्फ 200Gbit/s (2×100GbE Mellanox ConnectX-6), यानी 25Gbyte/s है. इसका मतलब है कि remote reads में drives की 70Gbyte/s क्षमता का पूरा उपयोग नहीं हो सकता और network ही bottleneck है
    अगर मान लें कि कोई अतिरिक्त network bottleneck नहीं है, तो 68 नोड्स 68×25=1700Gbyte/s की network read throughput दे सकते हैं. लेखक ने वास्तव में 1TiB/s, यानी ठीक 1025GiB/s=1101Gbyte/s benchmark किया, जो सैद्धांतिक अधिकतम 1700Gbyte/s का 65% है
    यह काफ़ी अच्छा है, लेकिन अगर सभी नोड्स अपने 200Gbit/s network links को एक साथ पूरी तरह saturate कर सकें, तो सैद्धांतिक रूप से यह थोड़ा और बेहतर हो सकता है
    पूरा लेख पढ़ते हुए मुझे लगा कि Ceph की जटिलता CPU पर काफ़ी भारी पड़ती है. सिर्फ modules को -O2 से compile न करना (लेखक की linked “Fix Three”: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453) ही pure I/O workloads में “कुछ workloads को अधिकतम 5 गुना तक धीमा कर सकता है”(https://bugs.gentoo.org/733316) — यह काफ़ी अप्रत्याशित है
    OSD threads का IOMMU spinlock पकड़ने में CPU को ज़रूरत से ज़्यादा बर्बाद करना भी अजीब है. मैं इस निष्कर्ष से सहमत हूँ कि OSD threading model optimal नहीं है
    अपेक्षाकृत सरल synthetic 100% read benchmark में threading contention सामने नहीं आना चाहिए था — अगर Ceph software architecture का वह हिस्सा ठीक से design किया गया होता. यह ऐसी समस्या है जिसे ठीक किया जा सकता है, इसलिए उम्मीद है Ceph developers इसे ऊँची प्राथमिकता देंगे

    • मैं यह जोड़ना चाहूँगा कि Ceph में मैंने IOMMU समस्या पहले कभी नहीं देखी
      upstream Ceph lab में Dell की उसी 1U chassis की पिछली generation और AMD Rome processors वाला hardware है, जो लगभग इसी scale पर करीब 30 OSD के साथ समान performance देता है, और वहाँ यह समस्या नहीं आती
      ग्राहक ने कहा कि उसने अपने datacenter में पहले भी यह समस्या देखी है, और उम्मीद है कि AMD के साथ मिलकर root cause का पता लगाया जा सकेगा
      पिछले summer में मैंने OSD के मौजूदा threading model को अस्थायी रूप से मजबूत करने के लिए थोड़ा काम किया था. जैसे async msgr और worker threads के बीच handoff double buffering, adaptive thread wakeups वगैरह
      load के तहत इससे performance और efficiency काफ़ी बढ़ी, लेकिन low load पर latency बढ़ने की कीमत चुकानी पड़ी. Ceph मूल रूप से किसी खास shard पर नया I/O आते ही thread को जगाने में बहुत aggressive है
      मैंने एक और core developer के साथ इस पर चर्चा की, और हम दोनों इस निष्कर्ष पर पहुँचे कि threading code का पूरा overhaul ज़्यादा उचित होगा
    • यह benchmark random I/O है. डिस्क की 4K random read IOPS “सिर्फ” 10 लाख से थोड़ा ज़्यादा है, जो लगभग 5GiB/s के बराबर बनता है
      अगर 320 OSD हों, तो यह करीब 1.6TiB/s होता है
      कम से कम मुझे यही आँकड़े मिले. वैसे भी ऐसे enterprise NVMe disks की reviews बहुत ज़्यादा नहीं मिलतीं
      फिर भी यह NIC के साथ अच्छी तरह मेल खाता दिखता है. इस scale पर ज़्यादातर workloads storage layer पर random I/O जैसे ही दिखने की संभावना है
    • मेरा मानना है कि PCIe TLP overhead और NVMe commands 7GB/s और 8GB/s के अंतर को समझाते हैं

  • हैरानी की बात यह है कि अधिक cooling चुनौती वाले 1U nodes और 10 SSD/2×100Gb NIC वाले कॉन्फ़िगरेशन को क्यों चुना गया
    अगर 2U nodes में 24 SSDs और 2×200Gb या 400Gb NIC इस्तेमाल किए जाते, तो network bottleneck हट सकता था, और बड़े, धीमे fans तथा कम CPU packages की वजह से बिजली की खपत भी कम हो सकती थी. प्रति socket core count भी ज़्यादा हो सकती थी
    nodes कम होने से failure domain बड़ा हो जाता, लेकिन लगभग 34 nodes पर यह शायद इतना बड़ा मुद्दा नहीं होता
    nodes कम होने पर शायद 4 switches के साथ ज़्यादा flat network भी बनाया जा सकता था

    • जैसा आपने कहा, failure domain मुख्य कारण है, और आम तौर पर इससे patching और hardware replacement कम परेशान करने वाले बनते हैं
      racks और switches पहले से मौजूद हैं और दूसरे कामों में भी काफ़ी इस्तेमाल हो रहे हैं, इसलिए Ceph की वजह से बढ़ने वाली physical space बहुत कम है :)