SSD बेहद तेज़ हो गई हैं, लेकिन क्लाउड को छोड़कर

 (databasearchitects.blogspot.com)
6 पॉइंट द्वारा GN⁺ 2024-02-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पिछले कुछ वर्षों में फ्लैश-आधारित SSD ने लगभग सभी स्टोरेज उपयोग मामलों में डिस्क को प्रतिस्थापित कर दिया है
  • SSD कई स्वतंत्र फ्लैश चिप्स से बने होते हैं, और इन्हें parallel तरीके से access किया जा सकता है
  • SSD का throughput मुख्यतः होस्ट के साथ interface speed पर निर्भर करता है
  • पिछले 6 वर्षों में SATA से तेज़ी से PCIe 3.0, PCIe 4.0 और PCIe 5.0 में स्थानांतरण होने से SSD throughput में विस्फोटक वृद्धि हुई
  • प्रदर्शन बढ़ने के साथ-साथ प्रति डॉलर क्षमता भी बढ़ी
  • यह बदलाव NVMe और PCIe जैसे ओपन स्टैंडर्ड, विशाल demand और प्रतिस्पर्धी vendors के कारण संभव हुआ
  • आज के PCIe 5.0 data center SSD अधिकतम 13 GB/s read throughput और 2.7 मिलियन से अधिक random read IOPS तक पहुंच रहे हैं
  • आधुनिक सर्वरों में लगभग 100 PCIe lanes होती हैं, इसलिए एक ही सर्वर में कई SSD को पूरी bandwidth के साथ चलाया जा सकता है

क्लाउड में SSD परफॉर्मेंस का ठहराव

  • AWS EC2 ने शुरुआती NVMe SSD वाले i3 instances 2017 की शुरुआत में लॉन्च किए थे
  • उस समय NVMe SSD महंगे थे, और प्रति सर्वर 8 इकाइयों का होना उल्लेखनीय था
  • लेकिन 7 साल बाद भी performance प्रति SSD 2 GB/s पर ही अटका हुआ है
  • i3 और i3en instances अब भी EC2 के सबसे अच्छे विकल्प हैं यदि आप IO/$ और SSD capacity/$ देखें
  • क्लाउड vendors द्वारा उपलब्ध SSD और नवीनतम SSD के बीच पढ़ने की throughput, लिखने की throughput और IOPS में लगभग 10x का अंतर करीब-करीब बन गया है
  • क्लाउड में यह ठहराव अन्य क्षेत्रों में तेज़ प्रगति की तुलना में उल्टा लग रहा है
  • उदाहरण के लिए, EC2 network bandwidth 2017 से 2023 तक 10 Gbit/s से बढ़कर 200 Gbit/s हो गई
  • क्लाउड vendors के storage हिस्से में आगे न बढ़ पाने के कई अनुमान हैं
    • EC2 शायद लिखने की गति को 1 GB/s तक intentionally limit करके device failure रोकने की कोशिश कर रहा हो, यह एक theory है
    • तेज़ storage के लिए demand की कमी होने के कारण सिस्टम को optimize करने का प्रोत्साहन कम होना भी संभव है
    • EC2 अगर तेज़ और सस्ता NVMe instance storage लाए तो अन्य storage सेवा (EBS) के cost structure पर असर पड़ सकता है, यह भी एक theory है
  • लेखक की इच्छा है कि बहुत जल्द हम 10 GB/s SSD वाले cloud instances देखें

GN⁺ की राय

  • SSD तकनीक की तेज़ प्रगति के बावजूद, cloud सेवा प्रदाता इन बदलावों को पकड़ने में विफल हैं, जो कि बाजार की विविध जरूरतों और तकनीकी सीमाओं को दर्शाते हैं
  • cloud storage में यह परफॉर्मेंस ठहराव cost efficiency और service quality के बारे में उपयोगकर्ताओं की अपेक्षाओं से टकरा सकता है, और क्लाउड उद्योग की competitiveness को प्रभावित कर सकता है
  • यह लेख cloud computing उपयोगकर्ताओं और providers दोनों के लिए महत्वपूर्ण insight देता है और faster storage solutions की मांग व तकनीकी उन्नति की जरूरत पर जोर देता है

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

1 टिप्पणियां

 
GN⁺ 2024-02-21
Hacker News टिप्पणी

  • क्लाउड की तकनीकी समस्याओं पर चर्चा

    • Google ने क्लाउड की एक बुनियादी समस्या पर काम किया था। यह कई लोगों की टेक्नोलॉजी दिशा तय करने वाला बड़ा कारक है।
    • क्लाउड के SSD नेटवर्क से जुड़े होते हैं, जो कि ज़रूरी है। लेकिन नेटवर्क बहुत बड़ा और धीमा होने के कारण लोकल SSD जैसी परफॉर्मेंस नहीं दे पाते।
    • Hard Drive के साथ यह समस्या नहीं थी, लेकिन SSD के साथ यह मुद्दा बनती है क्योंकि SSD नेटवर्क से कहीं तेज़ हैं।

  • AWS Nitro SSD आर्किटेक्चर पर व्याख्या

    • AWS documentation और ब्लॉग में Nitro SSD आर्किटेक्चर समझाया गया है। ये सिस्टम की mainboard से PCIe के माध्यम से physically जुड़े होते हैं, लेकिन ग्राहक का workload चलाने वाली सिस्टम mainboard से logically अलग-थलग हैं।
    • SSD की life ज्यादा बढ़ाने के लिए firmware में 'wear leveling' संभालने वाला प्रोसेस होता है। इसमें एक तरह की garbage collection भी शामिल होती है। सामान्य SSD में ज्यादा write load के समय अचानक और अनपेक्षित slow-down आ सकता है। AWS ने database expertise का उपयोग करके SSD firmware में एक बहुत mature और power-failure-safe journal-based database डाल रखा है।

  • क्लाउड instances में IOPS का निजी अनुभव

    • cloud instances में 'provisioned IOPS' का नंबर बहुत कम देखकर मैं चौंका। यह संकेत देता है कि कई लोग, खासकर वे जो सिर्फ cloud instances ही use करते हैं, शायद ठीक से नहीं समझते कि एक-दो RU में वास्तव में कितना performance fit हो सकता है।
    • NVMe storage की तेज़ रफ़्तार आज के ज़माने की एक बड़ी टेक्नोलॉजी उपलब्धियों में से एक है।

  • एक OCI कर्मचारी की राय

    • OCI instances पर तेज़ NVMe drives देता है। E4 Dense मॉडल में Samsung MZWLJ7T6HALA-00AU3 लगा है, जो क्रमिक पढ़ने के लिए 7000 MB/s और क्रमिक लिखने के लिए 3800 MB/s सपोर्ट करता है।
    • AWS अभी और तेज़ NVMe क्यों नहीं दे रहा, शायद क्योंकि concrete demand अभी पर्याप्त नहीं है। यह एक अनुमान है, लेकिन सामान्यत: अगर किसी चीज़ की मांग कम हो तो अपग्रेड काफी पीछे खिसक जाते हैं।

  • क्लाउड छोड़ने के पक्ष में तर्क

    • आज के NVMe और अधिक core count के साथ cloud से बाहर निकलने के मजबूत कारण बनते हैं। यह स्पीड इतना करीब है कि लगता है data निश्चित रूप से disk में फिट हो जाएगा, जिससे जटिलता घटती है।
    • केवल एक strong server ही caching, compute और serving के लिए पर्याप्त हो सकता है, जिससे कई workload सरल हो जाते हैं।

  • क्लाउड ऑप्टिमाइज़ेशन पर आलोचना

    • समस्या bandwidth की नहीं, IOPS की है। जब random IO benchmark चलाते हैं, तो यह behavior SSD की बजाय बड़े spinning RAID array जैसी random IOPS देता है।
    • cloud optimization को seriously लेने में एक कारण यह भी है कि database आदि workloads ठीक से optimize नहीं हैं, जिससे खर्च बढ़ सकता है।

  • AWS के NVMe instance types पर चर्चा

    • कई NVMe instance types (जैसे i4i और im4gn) launch हो चुके हैं, लेकिन performance बढ़ी नहीं है। i3 के launch के 7 साल बाद भी हर SSD पर लगभग 2 GB/s ही है।
    • AWS मार्केटिंग का दावा है:
      • अधिकतम 800K random write IOPS
      • अधिकतम 1,000,000 random read IOPS
      • अधिकतम 5600 MB/s क्रमिक write
      • अधिकतम 8000 MB/s क्रमिक read

  • hybrid SSD कॉन्फ़िगरेशन पर व्यक्तिगत विकल्प

    • 2011 का X-25E 64GB और 2021 का PM897 3.7TB mix करके use करने से मुझे लगता है कि सबसे मजबूत solution और सबसे बड़ा database कम power में मिला।

  • cloud services की performance सीमा पर अनुमान

    • संभव है कि cloud service की low performance का कारण demand की कमी हो, जिससे virtualization layer में कुछ 'tricks' चलाने की जगह बनती है।

  • SSD खर्च पर विचार

    • सबसे तेज़ SSD आमतौर पर MLC tech use करते हैं, और उनकी write lifetime अन्य तकनीकों की तुलना में काफी कम होती है।
    • डेटा density बढ़ाना performance बढ़ाने को आसान बनाता है, लेकिन memory block/cell स्तर पर write होने की वजह से यदि एक cell खराब होता है तो बाकी सभी भी fail हो सकते हैं।
    • नए stack tech को adopt करना और fleet को cost-effective तरीके से upgrade करना मुश्किल हो सकता है।