निरंतर नवाचार: AWS block storage का संक्षिप्त इतिहास

• AWS EBS की शुरुआत EC2 के लिए network-attached block storage के रूप में हुई थी, और यह shared HDD-आधारित सेवा से बढ़कर एक distributed SSD fleet बन गई जो प्रतिदिन 140 ट्रिलियन से अधिक operations संभालती है
• शुरुआती performance सीमाएँ सिर्फ HDD के 120~150 IOPS और औसत 6~8ms latency से नहीं, बल्कि एक ही disk को कई ग्राहकों के workloads द्वारा साझा किए जाने से पैदा हुई noisy neighbor समस्या से भी आईं
• SSD अपनाने के बाद 2012 में Provisioned IOPS volumes ने अधिकतम 1,000 IOPS और औसतन लगभग 2~3ms latency दी, लेकिन bottleneck network, hypervisor और software queue की ओर खिसक गया
• EBS टीम ने पूरे IO path को instrument किया और Xen queue, Nitro offloading, encryption hardware processing, TCP tuning, और SRD transport protocol तक हर layer पर सुधार किए
• performance सुधार बड़े पैमाने के rewrite की बजाय non-disruptive migration, छोटी टीमों के स्वतंत्र बदलाव, लगातार measurement, और rollback किए जा सकने वाले incremental improvements के जरिए आगे बढ़े

---

EC2 के लिए block storage से बड़े पैमाने की SSD fleet तक

• EBS की शुरुआत 20 अगस्त 2008 को हुई, EC2 beta लॉन्च के लगभग दो साल बाद, EC2 instances के लिए network-attached block storage उपलब्ध कराने के विचार से
• उस समय टीम में एक-दो storage विशेषज्ञ और कुछ distributed systems engineers थे, और उन्होंने computer systems तथा networking के ज्ञान के आधार पर सेवा बनानी शुरू की
• इसके बाद EBS एक shared HDD product से बदलकर ऐसी सेवा बन गई जो एक single EC2 instance को लाखों IOPS के कई हिस्सों तक दे सकती है
  • आज एक single instance को उपलब्ध कराए जा सकने वाले IOPS, शुरुआती HDD-आधारित दौर में पूरे Availability Zone को दिए जाने वाले स्तर से भी अधिक हैं
  • पूरा EBS distributed SSD fleet में प्रतिदिन 140 ट्रिलियन से अधिक operations प्रोसेस करता है
• मुख्य workload EC2 instances की system disks हैं, यानी यह रूप में उस network storage के अधिक करीब है जो physical server के अंदर hard disk की भूमिका निभाता है
• ग्राहक durability को महत्वपूर्ण मानते हैं, लेकिन EC2 अनुभव से सीधे जुड़े performance और availability को भी उतना ही महत्वपूर्ण समझते हैं
  • io2 Block Express volumes और volume snapshots, उच्च durability हासिल करने के लिए बुनियादी building blocks के रूप में दिए जाते हैं
  • EBS volumes की performance और availability लगभग सीधे EC2-आधारित application अनुभव में बदल जाती है

queueing और HDD से बनी शुरुआती सीमाएँ

• computer systems में storage requests, CPU, bus और device के बीच कई queues से होकर प्रोसेस होती हैं
• network storage में operating system kernel, storage adapter, storage fabric, target storage adapter और storage media के बीच कई queues बनती हैं
• 2008 में जब EBS पहली बार बनाया गया, तब storage market मुख्यतः HDD पर आधारित था और latency पर storage media का ही दबदबा था
  • hard disk एक mechanical device है, इसलिए इसकी physical limits हैं
  • कई दशकों तक HDD performance लगभग 120~150 operations per second और औसत IO latency 6~8ms के आसपास ही रही
  • queueing और drive के अंदर command reordering के कारण tail latency सैकड़ों ms तक बढ़ सकती थी
• उस समय EBS की end-to-end latency दर्जनों ms में थी, इसलिए network द्वारा जुड़ने वाले कुछ दर्जन microseconds, कुल latency का छोटा हिस्सा थे
• HDD performance, queue में जमा दूसरे कामों के असर से बहुत प्रभावित होती थी
  • media पर बिखरे छोटे random requests, पास-पास मौजूद कई बड़े requests की तुलना में खोजने और access करने में अधिक समय लेते हैं
  • ग्राहकों को कई disks में फैलाने से सबसे hot workloads की peak latency तो घटी, लेकिन अनियमित व्यवहार अधिक ग्राहकों तक फैल गया
• एक workload का दूसरे workload को प्रभावित करना, यानी noisy neighbor, एक महत्वपूर्ण business समस्या बन गया
  • AWS का मानना था कि ग्राहक अनुभव की गुणवत्ता बढ़ाने के लिए मजबूत performance isolation जरूरी है
  • disk scheduling algorithms में बदलाव और workloads को अधिक spindles में फैलाना केवल छोटे incremental improvements ही साबित हुए

SSD अपनाने के बाद instrumentation का महत्व स्पष्ट हुआ

• 2011 के आसपास SSD अधिक आम होने लगीं और AWS के मूल्यांकन लायक capacity में उपलब्ध होने लगीं
• SSD में data खोजने के लिए physical arm movement नहीं होता, random requests लगभग sequential requests जितनी तेज हो सकती हैं, और controller तथा NAND chips के बीच कई channels होते हैं
• EBS ने पहले SSD-आधारित नए storage server type और Provisioned IOPS नाम के नए volume type बनाए
  • नए volume type का launch छोटा काम नहीं था, और इसका लाभ उठा सकने वाले workloads भी सीमित थे
  • HDD को SSD से बदलने पर लगभग सारी समस्याएँ हल हो जाएँगी, इस उम्मीद के विपरीत noisy neighbor समस्या अपने-आप खत्म नहीं हुई
• अगस्त 2012 में लॉन्च हुए Provisioned IOPS ने अधिकतम 1,000 IOPS उपलब्ध कराए
  • यह मौजूदा EBS standard volume से 10 गुना अधिक था
  • औसत latency लगभग 2~3ms थी, यानी 5~10 गुना सुधार
  • outlier control भी काफी बेहतर हुआ
• उस समय EBS में केवल basic telemetry थी, और क्या ठीक करना है यह समझने के लिए अधिक घनी instrumentation की जरूरत थी
• टीम ने हर IO को कई बिंदुओं पर trace करने का तरीका बनाया
  • EBS client initiator
  • network stack
  • storage durability engine
  • operating system
• customer workload monitoring के अलावा, टीम ने canary tests भी बनाए जो ज्ञात workloads पर बदलावों के सकारात्मक और नकारात्मक प्रभावों को लगातार जाँचते थे

hardware और software को साथ बाँटकर किए गए सुधार

• नई telemetry ने शुरुआती निवेश के क्षेत्रों को स्पष्ट कर दिया
  • पूरे system में queues की संख्या कम करनी थी
  • EC2 में उपयोग हो रहे Xen hypervisor के IO path की complexity घटाने की गुंजाइश थी
  • network software optimization की जरूरत थी
  • core durability engine में on-disk data placement, cache line optimization और asynchronous programming model को अपनाने की आवश्यकता थी
• AWS में system performance समस्याएँ अक्सर hardware और software stack की कई layers को एक साथ पार करती हैं
• EBS ने storage server टीम और client टीम को parallel में चलाया, और EC2 hypervisor engineers तथा AWS की आंतरिक network performance group ने भी इसमें हिस्सा लिया
• development organization को भी software systems की तरह divide and conquer तरीके से बाँटा गया
  • monolithic storage server development team को data replication, durability, snapshot hydration जैसे क्षेत्रों के छोटे-छोटे teams में पुनर्गठित किया गया
  • प्रत्येक team सख्त testing के आधार पर स्वतंत्र रूप से iterate कर सकती थी और बदलाव लागू कर सकती थी
• 2013 में बना blueprint आज के EBS जैसा नहीं था, लेकिन उसने आगे बढ़ने की दिशा दी
  • उस समय यह अनुमान नहीं था कि Amazon कभी अपना SSD बनाएगा और EBS की जरूरतों के लिए अनुकूलित technology stack विकसित करेगा

Xen से Nitro और SRD तक: bottlenecks हटाना

• 2017 के अंत तक सभी EC2 instances Xen hypervisor पर चलते थे
• Xen device path में guest domain और privileged driver domain dom0 के बीच information साझा करने के लिए ring queue थी, और EBS client dom0 के kernel block device के रूप में चलता था
• instance से EC2 host के बाहर जाने तक IO requests कई queues से गुजरती थीं
  • instance block device queue
  • Xen ring
  • dom0 kernel block device queue
  • EBS client network queue
• EBS टीम ने हर queue के प्रभाव को अलग करने के लिए कई loopback devices लिखे
• यह पाया गया कि dom0 device driver latency लगभग न के बराबर होने पर भी, जब कई instances एक साथ IO generate करते थे, तो पूरे system का effective throughput धीमा हो जाता था
  • EC2, Xen के default block device queue count और queue entry count के साथ लॉन्च हुआ था
  • ये defaults, Xen के पुराने development environment में मौजूद सीमित storage hardware को ध्यान में रखकर तय किए गए थे
  • पूरे host के लिए outstanding IO requests की सीमा 64 थी, किसी एक device के लिए नहीं
• 2013 में networking के लिए पहला Nitro offload card विकसित किया जा रहा था
  • VPC software-defined networking processing को Xen dom0 kernel से dedicated hardware pipeline में शिफ्ट किया गया
  • packet processing data plane को hypervisor से अलग कर दिया गया, ताकि customer instance CPU cycles को network traffic handling में खर्च न करना पड़े
• यही approach EBS storage पर भी लागू की गई
  • अधिक processing को hardware में शिफ्ट करके hypervisor की operating system queues कम की गईं
  • interrupt-आधारित कामों को offload करके hypervisor का request processing समय घटाया गया
  • दूसरे Nitro card में EBS encrypted volumes को बिना performance impact संभालने की hardware capability भी थी
  • encryption key material को hypervisor से अलग करके customer data को अतिरिक्त सुरक्षा दी गई
• EBS को Nitro पर ले जाने के बाद bottleneck खुद network में चला गया
  • modern datacenter TCP tuning parameters और congestion control algorithms की समीक्षा की गई
  • storage server requests में थोड़ी random delay जोड़ने पर network smoothing effect से average latency और outliers कम होने के मामले भी मिले
  • ऐसे tuning उपाय system performance और scale बढ़ते रहने के कारण लंबे समय तक स्थिर नहीं रहे, और regressions रोकने के लिए लगातार measurement और monitoring की जरूरत बनी रही
• 2014 में TCP से बेहतर approach के लक्ष्य के साथ Scalable Reliable Datagram(SRD) आधारित काम शुरू हुआ
  • संबंधित paper है A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
  • requirements में failure recovery और rerouting क्षमता में सुधार, तथा hardware offloading को आसान बनाना शामिल था
• SRD design में दो observations महत्वपूर्ण थे
  • focus सामान्य internet पर नहीं, बल्कि AWS datacenter network design पर किया जा सकता था
  • storage में in-flight IO requests के execution order को reorder किया जा सकता था
• TCP की सख्त in-order delivery की लागत से बचते हुए, अलग-अलग requests को कई network paths पर भेजकर arrival के समय execute किया जा सकता था
• SRD का उपयोग सिर्फ storage में नहीं, networking में भी होता है
  • Elastic Network Adapter(ENA) Express में SRD guest के TCP stack की performance सुधारता है
  • यह कई network paths का उपयोग करता है और बीच के network devices में overflow तथा queueing को घटाकर उच्च network utilization संभव बनाता है

SSD cache और non-disruptive migration

• EBS इस बात से संतुष्ट नहीं था कि बेहतर performance केवल कुछ volumes और कुछ ग्राहकों को मिले; वह SSD के लाभ को अधिक व्यापक रूप से देना चाहता था
• उस समय हजारों storage servers पर लाखों non-provisioned IOPS customer volumes चल रहे थे
  • इनमें से कुछ volumes आज भी मौजूद हैं
  • पूरा hardware हटाकर बदल देना बहुत महँगा होता
• server chassis में खाली जगह थी, लेकिन cooling airflow को बाधित किए बिना उपलब्ध स्थान motherboard और fan के बीच ही था
• SSD छोटे और हल्के थे, लेकिन उन्हें chassis के अंदर हिलना नहीं चाहिए था; materials scientists की मदद और trial and error के बाद heat-resistant industrial hook-and-loop fastening tape मिला
• 2013 में कुछ महीनों के दौरान EBS ने हजारों servers में मैन्युअली 1 SSD लगाई
• software में छोटा-सा बदलाव जोड़ा गया, जिसमें नए writes को पहले SSD पर stage किया जाता, application को completion लौटाई जाती, और फिर उन्हें धीमे HDD पर asynchronously flush किया जाता
• यह काम ग्राहकों के लिए बिना disruption के किया गया
  • EBS को शुरू से ही non-disruptive maintenance events को ध्यान में रखकर डिज़ाइन किया गया था
  • EBS volumes को नए storage server पर retarget किया जा सकता था, और खाली server को update या rebuild किया जा सकता था
• customer volumes को नए storage server पर ले जाने की क्षमता बाद में भी कई बार उपयोगी साबित हुई
  • on-disk format के लिए अधिक कुशल data structures लाने में इसका उपयोग हुआ
  • पुराने hardware को नए hardware से बदलने में भी यह काम आया
• 2008 में EBS launch के शुरुआती महीनों में बनाए गए कुछ volumes आज भी active हैं
  • संभव है कि ये volumes सैकड़ों अलग-अलग servers और कई generations के hardware से गुजर चुके हों
  • fleet update और rebuild इन workloads को प्रभावित किए बिना किए गए

performance scaling के अनुरूप leadership शैली

• EBS का scale केवल technology के लिहाज़ से नहीं, बल्कि organization के दृष्टिकोण से भी पारंपरिक छोटी कंपनी या startup माहौल से अलग था
• यदि system experts हर escalation, commit review और design change review में शामिल हों, तो वही organization का performance bottleneck बन सकते हैं
• इसे हल करने के लिए केवल code में नहीं, collaboration के तरीकों में भी प्रयोग किए गए
• एक प्रमुख tool के रूप में peer debugging का उपयोग हुआ
  • कई engineers एक साथ code और terminal देखते हुए समस्या का पीछा करते थे
  • इससे एक ऐसा मामला सामने आया जिसमें critical data structure updates के लिए locking की जगह और तरीका समस्या पैदा कर रहे थे
  • आम तौर पर समस्या दिखाई नहीं देती थी, लेकिन कभी-कभी request responses धीमे हो जाते थे; इसे ठीक करके jitter के एक कारण को हटाया गया
• engineers को सुरक्षित रूप से experiment करने की authority देना, बाधाएँ कम करना, और guardrails बनाए रखना बेहतर परिणाम दे सकता था

बड़े rewrite की बजाय निरंतर सुधार

• EBS में सुधार किसी एक विशाल बदलाव से नहीं, बल्कि समय के साथ हुए incremental improvements की श्रृंखला से आया
• इस approach ने ग्राहक मूल्य जल्दी पहुँचाने और customer workloads में बदलाव के साथ सीखी गई बातों के आधार पर दिशा बदलने की सुविधा दी
• EBS latency अनुभव, प्रति IO operation औसतन 10ms से अधिक के स्तर से सुधरकर, सर्वोच्च प्रदर्शन वाले io2 Block Express volumes में स्थिर sub-millisecond IO तक पहुँच गया
• यह बदलाव सेवा को offline किए बिना और नई architecture देने के लिए downtime लिए बिना हासिल किया गया
• ग्राहक लगातार अधिक performance चाहते हैं, और वही मांग EBS के innovation और iteration को आगे बढ़ाने वाली शक्ति है

[GN⁺]

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

• यहाँ यह लेख देखकर सचमुच अच्छा लगा। अगर आपको बड़े पैमाने के सिस्टम्स में ज़रा भी दिलचस्पी है, तो यह ज़रूर पढ़ने लायक है
  क्रमिक workload में आधुनिक magnetic disk पढ़ने/लिखने की 100MB/s से अधिक गति दे सकती है, लेकिन पूरी तरह random 4kB workload में यह 400kB/s तक गिर सकती है। Queueing और scheduling सबसे खराब स्थिति से बचा लें, तब भी वास्तविक performance workload के हिसाब से 100 गुना से ज़्यादा बदल सकती है, इसलिए multi-tenant systems के लिए इसे संभालना बहुत मुश्किल होता है। खासकर read के मामले में “बस कहीं और लिख दो” जैसा कोई workaround नहीं होता
  Marc से मैंने सबसे बड़ी बात यह सीखी कि क्या टूटा है, यह समझने के लिए पहले उसे सही तरह से देखना पड़ता है। उसने latency visualization बनाई, जैसे लेख में histogram time series, और उन visualizations के ज़रिए कहानी समझाकर टीम को यह बिल्कुल अलग नज़र से दिखाया कि उन्हें क्या करना चाहिए। Histogram के हर peak का अपना अलग कारण और optimization work था, और performance data को कई तरीकों से गहराई से देखने में निवेश किए बिना जो efficiencies और opportunities नहीं दिखतीं, वे खुलकर सामने आईं
  2013 में हज़ारों servers में एक-एक SSD जोड़ने वाला retrofit project AWS की कहानियों में मेरा सबसे पसंदीदा उदाहरण है। यह इसलिए संभव हुआ क्योंकि शुरू से ही non-disruptive maintenance events को ध्यान में रखते हुए EBS volumes को नए storage server पर reassign करना और खाली server को update या rebuild करना संभव बनाया गया था। यह अच्छा उदाहरण है कि distributed systems सिर्फ scale-out के लिए नहीं होते, बल्कि वे server failures को सहज रूप से झेलने, data loss के बिना migration करने, और बड़े पैमाने पर operations को संभव बनाने के लिए भी होते हैं

  • Marc ने latency visualization बनाई और उसी से कहानी समझाई—यह हिस्सा दिलचस्प लगा
    Google के Dick Lyon ने भी Google storage servers में यही approach अपनाई थी, और https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... की slide 62 से block storage के मुख्य bottlenecks के रूप में कई queues और resource contention की पहचान की गई है

• पुरानी यादें ताज़ा हो गईं। Reddit 2008 में EBS के शुरुआती users में से एक था, और हमें लगा कि 5 EBS volumes के साथ software RAID बनाकर IOPS बढ़ाया जा सकता है, तो हम बड़े होशियार हैं
  उस समय हर volume की performance बहुत अस्थिर होती थी, इसलिए हम 7–8 volumes चलाते, उन पर read/write load डालते, और सबसे अच्छा perform करने वाले 5 volumes चुनकर Linux software RAID में बाँध देते। जब यह काम करता था तो सचमुच मनचाहा असर मिलता था, और कभी-कभी single node के 5x से भी ज़्यादा IOPS मिल जाते थे, लेकिन जब चीज़ें बिगड़ती थीं तो हाल बहुत खराब हो जाता था
  हमें यह नहीं पता था कि software RAID में अगर एक node धीमा हो तो पूरा RAID सबसे धीमे volume की रफ़्तार से चलता है, और नतीजा यह दिखता था जैसे database ही टूट गया हो। यह समझने में समय लगा कि वजह RAID है, और खराब node को हटाना भी मुश्किल था। क्योंकि software RAID उस धीमे volume पर write पूरा होने से पहले उसे छोड़ना ही नहीं चाहता था
  हमें नया EBS volume जोड़कर array फिर से बनानी पड़ती थी, और यह भी नए volume के IOPS से सीमित होने के कारण अच्छा अनुभव नहीं था। बाद में हमने वह software RAID इस्तेमाल करना बंद कर दिया, और Netflix में तो लगभग EBS का इस्तेमाल ही नहीं होता था। Reddit में की गई अपनी गलती की कहानी मैं हर सुनने वाले को सुनाता था, और Netflix ने मेरे जुड़ने से पहले ही सिर्फ local disks इस्तेमाल करने को standard बना लिया था
  एक मज़ेदार बात यह है कि AWS के बड़े EBS outage के समय मैं Reddit में काम कर रहा था, और database ठीक करने के लिए EBS के वापस आने का इंतज़ार करते हुए Netflix देख रहा था। Netflix के interview में जब मैंने पूछा, “EBS outage के दौरान आप लोग कैसे बचे रहे?” तो जवाब मिला, “ओह, हम तो बस EBS इस्तेमाल ही नहीं करते”

  • हमने भी वही तरीका अपनाया था। आखिरकार network bandwidth limits आकर सामने आ गईं, और उस समय ज़्यादातर instance types पर performance लगभग 160MB प्रति सेकंड के आसपास रुक जाती थी

• यह लेख पढ़ना अच्छा लगा
  दिलचस्प बात यह है कि लेख जिस दौर की बात करता है, उसी समय AWS को EBS की वजह से लगभग 4 दिन का outage झेलना पड़ा था, और मेरी याद में EC2, EBS, और RDS सब प्रभावित हुए थे। इस outage ने AWS पर भरोसे को काफ़ी हिला दिया था
  नतीजतन organizational restructuring हुई, और EBS में एक स्वतंत्र service के रूप में कहीं अधिक गहराई से निवेश किया गया। यही वह समय भी था जब Apple customer बन रहा था, और Netflix, Zynga, Dropbox जैसे startups के adoption की वजह से AWS तेज़ी से बढ़ रहा था
  ऐसी technical और operational कहानियाँ दिलचस्प तो हैं ही, लेकिन production में होने वाला technical innovation अक्सर अव्यवस्थित होता है और वास्तविक business requirements की पृष्ठभूमि में होता है। काश ऐसी कहानियाँ और ज़्यादा सुनने को मिलें

  • उस घटना के बाद वाला 1 साल अच्छा रहा। Reliability पर फ़ोकस किया गया, issues कम किए गए, और कई development ideas की दिशा भी बदली गई
    लेकिन चक्र फिर घूम गया और चीज़ें वापस feature development पर आ गईं। वहाँ बिताए समय में वह साल मुझे हमेशा सबसे कम escalations वाला साल याद रहेगा

• “Storage server requests में थोड़ी-सी random latency जोड़ने से network smooth हो गया, और इस वजह से average latency और outliers दोनों कम हो गए” — यह हिस्सा जिज्ञासापूर्ण लगा। कोई समझा सकता है कि ऐसा क्यों हुआ?

  • Synchronized network traffic incast या दूसरे buffer overflows पैदा कर सकता है

• अगर दिलचस्पी हो, तो 2009 में Amazon S3 की internal architecture पर दिया गया एक talk [0] है। यह S3 team की internal material पर आधारित था, और यहाँ की बहुत-सी बातें EBS के development approach को भी प्रभावित करती थीं
  [0]: https://vimeo.com/7330740

• 2013 में सभी EBS उपकरणों में SSD को मैन्युअली जोड़ने वाला हिस्सा अच्छा लगा। तस्वीर देखें तो वह Samsung SATA SSD से काफ़ी मिलता-जुलता लगता है
  https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
  मेरी याददाश्त ग़लत भी हो सकती है, लेकिन ऐसा लगता है कि उससे काफ़ी पहले ही Dell blade में SSD लगाकर इस्तेमाल किया जा रहा था। 2010~2012 के आसपास I/O performance वाकई बहुत बड़ा मुद्दा था, और वही समय था जब rotational hard disk से flash memory की ओर बदलाव हो रहा था
  मुझे raw flash-आधारित devices के साथ प्रयोग करने की याद है, जिनमें न error handling था न wear leveling। वह पागलपन था, लेकिन सब लोग rotational disk से silicon पर जाने से मिलने वाले भारी I/O performance gains के लिए बेताब थे

  • वह बस कुछ ही Frankenracks थे। उन्हें संभालना मुश्किल था और performance भी बहुत अच्छी नहीं थी, लेकिन उन्होंने सबको research जल्दी शुरू करने का मौका दिया
    disk की speed इतनी तेज़ी से बढ़ी कि सिर्फ़ 6 महीनों में पहला SKU पुराना पड़ गया। अच्छा हुआ कि योजना से कई साल पहले उन racks को हटाते समय मुझे asset team को खुद समझाना नहीं पड़ा। नए, ज़्यादा dense और तेज़ models लगाना rack space value के हिसाब से कहीं बेहतर था

• इस्तेमाल लायक open source आने से पहले storage-as-a-service infrastructure बनाने के दिनों की याद आ गई। Sun SAN, Fibre Channel, Solaris से हटकर हम Linux और NFS चलाने वाले Supermicro storage servers पर GlusterFS तक पहुँचे, और 2007 में वहाँ से जाने से पहले यह लगभग 2PB तक पहुँच गया था
  यह भी याद आया कि एक समय running server में rotational disk की जगह SSD लगाकर चुपचाप mdraid को तोड़ना और फिर बनाना बस एक practical काम माना जाता था। SATA कुछ हद तक drive hot-swap support देता था। rotational disk से SSD पर बदलने के बाद platform के सबसे अहम system की IOPS 14 गुना बढ़ गई

• करियर की शुरुआत में मैंने ऐसी internet company में काम किया था जहाँ scale लोगों की संख्या में नहीं, बल्कि technology और operations में बहुत बड़ा था, और वहाँ पूरे system stack पर काम करना पड़ता था। बहुत कम समय में मैंने अविश्वसनीय संख्या में सबक सीखे। उस कंपनी को छोड़ने के बाद समझ आया कि ज़्यादातर लोग अपने पूरे करियर में ऐसे problems का लगभग कभी सामना ही नहीं करते, इसलिए वे वे सबक सीख भी नहीं पाते
  इसलिए मुझे लगता है कि professional qualification system होना चाहिए। अगर किसी skilled engineer के अधीन apprenticeship अनिवार्य हो, तो कम समय में वह बेहद मूल्यवान ज्ञान और कौशल सीखे जा सकते हैं जो सिर्फ़ अनुभव से आते हैं, और उसके बाद लोग कहीं ज़्यादा प्रभावी ढंग से काम कर सकते हैं। उम्मीदवारों का interview लेते समय भी अनुभव का प्रमाण और mentor की recommendation बहुत मूल्यवान होगी

  • qualification लेने के बाद भी, अगर ग्राहक को बस साधारण UI वाला CRUD service चाहिए, तो अंत में वही बनाना पड़ेगा—ऐसी स्थिति की कल्पना की जा सकती है। अगर ग्राहक unqualified developers को रख ही न सके, तो यह और भी ज़्यादा होगा

• यह वाक्य अच्छा लगा
  “बहुत सराहा जाने वाला full-stack engineer का आदर्श भी मूल्यवान है, लेकिन गहरे और जटिल systems में अक्सर उससे भी ज़्यादा मूल्यवान यह होता है कि ऐसे specialists का समूह बनाया जाए जो पूरे stack और अपनी-अपनी गहरी विशेषज्ञता के पार सहयोग और रचनात्मक तरीके से काम कर सकें”

• लेख का पहला diagram या तो inaccurate है या काफ़ी पुराना। आधुनिक computers में ज़्यादातर PCIe lanes पहले की तरह अलग PCH से होकर नहीं, बल्कि सीधे CPU के I/O hub या Uncore area से जुड़ते हैं
  यह I/O throughput और latency—दोनों के लिए एक महत्वपूर्ण प्रगति है। इसके अलावा लेख शानदार है, और यह अच्छी तरह दिखाता है कि आख़िरकार हर जगह queues ही हैं

  • सही है, आधुनिक computers की architecture काफ़ी बेहतर है। कहानी को गढ़ते समय मैं उस दौर को याद कर रहा था जब हमने शुरुआत की थी
    मैं image caption में यह स्पष्ट कर दूँगा कि वह उस समय की architecture है