powerstat, sensors, dmidecode से Hetzner AX162 की खराबी ट्रैक करना

 (ubicloud.com)
1 पॉइंट द्वारा GN⁺ 2025-02-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ubicloud ने Hetzner के नए AX162 servers को AX161 की तुलना में performance और कीमत के लिहाज़ से बेहतर देखकर अपनाया, लेकिन संचालन के दौरान उन्हें reliability की समस्या झेलनी पड़ी, जहाँ failures 16 गुना ज़्यादा बार हो रहे थे
  • root cause tracking उन system logs से शुरू हुई जिनमें NULL bytes बचे थे, और फिर load, temperature, component information और power consumption को क्रमशः खारिज करने के तरीके से आगे बढ़ी; sensors, dmidecode, powerstat मुख्य tools बने
  • शुरुआती data में AX161 ने 3,784 दिनों की service अवधि में 11 failures के साथ AFR 1.06 दिखाया, जबकि AX162 ने 737 दिनों में 34 failures के साथ AFR 16.84 दर्ज किया
  • एक बार fail हुए servers में से 80% ने 24 घंटों के भीतर दूसरा failure देखा, और Hetzner ने power limiting की पुष्टि किए बिना motherboard batch defect की जानकारी दी
  • latest motherboard पर migrate किए गए AX162 -v3 का AFR कई महीनों की monitoring के बाद घटकर 0.39 तक आ गया, और नए hardware को non-critical workloads से शुरू करके चरणबद्ध रूप से verify करना चाहिए

AX162 अपनाने के बाद बार-बार crashes

  • Ubicloud ऐसा software बनाता है जो bare-metal providers को cloud platform में बदलता है, और Hetzner को कम लागत वाले व भरोसेमंद server provider के रूप में इस्तेमाल करता आया है
  • Hetzner की AX162 server line ने पिछले model AX161 की तुलना में बेहतर performance और कम कीमत दी, इसलिए इसे तेज़ी से अपनाया गया
  • पहला AX162 server खरीदने के 3 हफ्ते बाद एक server crash हुआ, और system logs में NULL bytes बचे मिले
    • इसे ऐसे अचानक failure का संकेत माना गया जिसमें power loss की तरह write operations सामान्य रूप से पूरा नहीं हो पाए
  • Hetzner की hardware जांच में शुरुआत में कोई समस्या नहीं मिली, लेकिन एक हफ्ते बाद एक और crash हुआ और कुछ दिनों के भीतर failures बार-बार होने लगे

failure किस तरह दिखे

  • सभी crashes केवल AX162 servers पर हुए
  • failures दो प्रकार के थे
    • manual restart के बाद server फिर से online लौट आता था
    • restart request या Hetzner engineer के diagnostic code पर भी response नहीं देता था, इसलिए server बदलना पड़ता था
  • server आमतौर पर लंबे समय तक सामान्य रूप से चलता था, लेकिन पहले crash के बाद अतिरिक्त crashes की संभावना बढ़ जाती थी
  • यह pattern देखा गया कि पहले type के crash कई बार दोहरने के बाद अंत में दूसरा type आता था और server को replace करना पड़ता था

पहले load और temperature को खारिज किया

  • AX162 96 vCPU देता था, और Ubicloud के पास ऐसे workloads थे जो सभी vCPU को एक साथ इस्तेमाल करते थे
  • यह hypothesis जांचा गया कि high load से temperature बढ़ सकता है या unexpected problems बन सकती हैं, लेकिन crash के समय low load या no load की स्थिति में भी failures हुए
  • temperature और failures के correlation को देखने के लिए sensors command से system components के temperatures collect किए गए
  • एक simple cron job से temperature data इकट्ठा किया गया, और फिर crash होने पर देखे गए temperatures average से बहुत ज़्यादा नहीं थे

component information और power consumption की जांच

  • lshw और dmidecode से hardware components के model और serial numbers check किए गए
  • crash वाले AX162 servers और बिना crash वाले servers के components की तुलना की गई, लेकिन कोई meaningful difference नहीं मिला
  • पुराने components के ज़्यादा fail होने की संभावना के कारण serial numbers की बढ़ती sequence भी जांची गई, लेकिन latest serial numbers वाले servers पर भी crashes हुए
  • datacenter expansion में अक्सर space से ज़्यादा power constraint बनती है, और operator प्रति machine power usage limit कर सकता है
    • Ubicloud को नहीं पता था कि Hetzner power consumption limit कर रहा है या नहीं, लेकिन लंबे समय तक stable चलने के बाद repeated crashes का symptom hardware wear से मेल खाता लगा
    • दूसरी hypotheses को एक-एक कर खारिज करने के बाद power limiting एक मजबूत hypothesis के रूप में बची
  • powerstat -R से लंबे समय तक maximum power consumption measure किया गया और advertised numbers से तुलना की गई
    • AX161: advertised maximum power 147W, measured maximum power 168W
    • AX162: advertised maximum power 408W, measured maximum power 266W
  • इस अंतर के कारण शक हुआ कि Hetzner actual power usage limit कर रहा हो सकता है

AFR से देखा गया failure rate

  • hardware reliability comparison के लिए Annualized Failure Rate(AFR) का इस्तेमाल किया गया
  • AFR की सीमाएँ हैं, लेकिन failure rate compare करने के शुरुआती point के रूप में यह काफी सरल metric था
  • शुरुआती measurement में AX162 का failure rate AX161 से काफी ज़्यादा था
    • AX161: 11 failures, total service 3,784 days, AFR 1.06
    • AX162: 34 failures, total service 737 days, AFR 16.84
  • यह data इस observation को support करता है कि AX162 में दूसरे models की तुलना में failure experience करने की संभावना 16 गुना ज़्यादा थी
  • एक बार crash हो चुके server के दोबारा crash होने की संभावना बहुत ज़्यादा थी, और एक crash झेल चुके servers में से 80% ने 24 घंटों के भीतर दूसरा crash देखा

motherboard replacement और v2 की सीमाएँ

  • Ubicloud ने power limiting के शक और AFR data सहित detailed support ticket Hetzner को submit किया
  • Hetzner ने power limiting की संभावना की पुष्टि या खंडन नहीं किया, लेकिन बताया कि उसने motherboard batch defect की पुष्टि की है
  • Hetzner को नए batch के motherboards मिले और उसने प्रभावित servers के motherboards बदलने की सलाह दी
  • बड़े पैमाने पर server replacement customer workloads को प्रभावित कर सकता था, लेकिन repeated crashes के कारण ज़्यादातर important jobs AX162 से पहले ही हटाई जा चुकी थीं, इसलिए replacement संभव था
  • नए motherboard से replacement के बाद भी important workloads को AX162 पर वापस नहीं रखा गया और long-term monitoring जारी रही
  • शुरुआत में कोई crash नहीं हुआ, लेकिन 2 हफ्ते बाद नए motherboard लगे server पर भी crash हुआ
    • AX162 -v2: 11 failures, total service 758 days, AFR 5.30
  • v2 पुराने AX162 की तुलना में कम बार crash हुआ, लेकिन failure rate फिर भी high था

v3 में stable हुए results

  • Hetzner से दोबारा संपर्क करने के बाद पता चला कि बेहतर reliability वाला latest motherboard version मौजूद है
  • servers को latest version पर migrate किया गया और reliability monitor की गई
  • कई महीनों तक नए servers observe करने के बाद माना गया कि AX162 का crash issue resolve हो गया है
  • final AFR comparison इस प्रकार है
    • AX161: 11 failures, total service 3,784 days, AFR 1.06
    • AX162: 34 failures, total service 737 days, AFR 16.84
    • AX162 -v2: 11 failures, total service 758 days, AFR 5.30
    • AX162 -v3: 4 failures, total service 3,738 days, AFR 0.39
  • AX162 -v3 का AFR AX161 से भी कम था

operational process में सुधार

  • नई server line को शुरुआत में अपनाने पर unexpected problems आ सकती हैं
  • AX162 के specs आकर्षक थे, और Hetzner द्वारा AX161 को बंद करना भी ऐसा signal लगा कि नई line production-ready है
  • अनुमान है कि अगर 6 महीने इंतज़ार किया गया होता, तो कई problems से बचा जा सकता था
  • आगे के changes इस प्रकार हैं
    • नए server models के लिए अधिक thorough verification की जाएगी
    • नए hardware को non-critical workloads से शुरू करके धीरे-धीरे introduce किया जाएगा
    • risk spread करने के लिए और bare-metal providers जोड़े जाएंगे
  • Ubicloud पहले से Leaseweb और Latitude नाम के दो अतिरिक्त bare-metal providers को support करता है, और चौथे provider को जोड़ने का काम भी चल रहा है

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

1 टिप्पणियां

 
GN⁺ 2025-02-21
Hacker News की राय

  • दूसरे AX मॉडल (AX42, AX52, AX102) में भी कुछ महीनों बाद खराब होने वाली गंभीर reliability समस्या है
    यह दोषपूर्ण mainboard पर आधारित है, इसलिए Hetzner को एक निश्चित तारीख से पहले बने सर्वरों के mainboard अगले 12 महीनों में अधिकांश, शायद सभी, बदलने पड़ेंगे [0]
    [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

    • मैं AX42 के दो सर्वर इस्तेमाल कर रहा हूँ; एक Eurocup discount अवधि में मिलने के बाद से स्थिर रहा है और दूसरा अब तक दो बार बदला जा चुका है
      सबसे नया replacement अभी तक टिकता हुआ लग रहा है, इसलिए छोटे sample के आधार पर failure rate 50% जैसा दिखता है। असली संख्या शायद सिर्फ Hetzner और ASRock को पता होगी

  • पिछली कंपनी में DevOps टीम Hetzner हार्डवेयर में CPU fan failure अक्सर पकड़ती थी
    यह सामान्य HDD/SSD failures से अलग बात थी, और इसे सीधे monitor करना पड़ता था। unmanaged server, cloud instance से सस्ते होने का यह भी एक कारण है

    • Azure में भी मैंने खराब cooling devices अक्सर देखे थे, और Google में काम करते समय भी यह कम स्तर पर लेकिन लगातार सिरदर्द था
      Dropbox में शामिल होने के पहले ही दिन मैंने टीम से कहा था कि “fleet में 400MHz पर चलने वाली मशीनें मिल सकती हैं” और यह सच निकला। गलत redundant PSU controller PROCHOT ट्रिगर कर रहा था। मशीनें बहुत हों तो ऐसा होता है
    • unmanaged होने का मतलब यह है कि आपको silicon-level access और remote KVM मिलता है, यह नहीं कि physical hardware की जिम्मेदारी ग्राहक पर चली जाती है
      physical hardware का सही ownership, maintenance और repair अब भी hosting company की जिम्मेदारी है, और इसमें monitoring भी शामिल है। पहले monitoring से जोड़ने के लिए scripts या packages install करने पड़ते थे, लेकिन अब IPMI जैसी चीज़ें standard हैं, इसलिए यह ग्राहक की मदद के बिना भी किया जा सकता है
      यदि मामला सिर्फ rack space, power और network देने का नहीं है, तो कहाँ तक जिम्मेदारी होगी यह contract का विषय है। अगर Hetzner अपने ही hardware में CPU fan failure नहीं पकड़ पाया और नए systems को पर्याप्त test किए बिना deploy कर दिया, तो यह लगातार फिसलने का संकेत लगता है
    • मैं free dependencies पर निर्भर रहने और हमेशा सबसे सस्ता विकल्प चुनने—दोनों का कड़ा विरोध करता हूँ
      अगर खरीद का मूल्यांकन करते समय आप सामने वाले की स्थिति पर एक पल भी विचार किए बिना सिर्फ लागत घटाने और revenue बढ़ाने की सोचते हैं, तो संदिग्ध sales industries को छोड़कर ऐसी चीज़ लंबे समय नहीं चलती
      server hardware वास्तव में सस्ता है, और ठीक-ठाक काबिल programmer के लिए ज़्यादातर programs एक single server या एक virtual machine पर भी चल सकते हैं। $25/माह की जगह $50/माह देकर थोड़ा margin देना चाहिए। फिर भी इससे यह गारंटी नहीं होती कि वह कंपनी बंद नहीं होगी या आपको महत्वपूर्ण ग्राहक मानेगी; अंत में आप उसी ढाँचे पर निर्भर रहते हैं जहाँ बड़े ग्राहकों की वजह से पूरा कारोबार लाभ में रहता है
      अगर आपका business अमेरिका में है, तो अमेरिकी hosting provider का इस्तेमाल करना ठीक है

  • “अगर 6 महीने इंतज़ार किया होता तो कई समस्याओं से बचा जा सकता था, और early adopters आम तौर पर पहले समस्याएँ ढूँढते हैं जिन्हें बाद में ठीक किया जाता है” — यह सलाह stability की ज़रूरत वाले हर system पर लागू होती है
    यदि security issue न हो तो कुछ महीने रुकें या एक-दो versions पीछे रहें

    • GitHub dependabot में यह feature जोड़ने की कोशिश कर रहा है: https://github.com/dependabot/dependabot-core/issues/3651
    • यह प्रकृति में भी लंबे समय से सफल pattern है। उम्रदराज़ जीव युवा और अनुभवहीन जीवों को उत्साही test units की तरह इस्तेमाल करते हैं
      उदाहरण के लिए, जंगल में बूढ़ा जंगली सूअर किसी संदिग्ध खुले स्थान पर पहले बच्चों को भेजने के लिए सुरक्षित होने का संकेत देता है। तकनीक की दुनिया में यह कुछ वैसा है जैसे ऐसी technology पर बढ़ा-चढ़ाकर blog post लिखना जो अभी production-ready नहीं है
    • मैं उस blog post का लेखक हूँ। कुल मिलाकर यह अच्छी practice है
      फिर भी यह थोड़ी राहत की बात है कि हमारी परेशानी ने root cause को जल्दी सामने लाने में मदद की
      मैंने लेख में नहीं लिखा, लेकिन आगे चलकर हम यह भी सोच रहे थे कि server मिलने के बाद उसे वास्तविक customer workload के बिना लगभग एक महीने idle छोड़ दिया जाए। इससे लागत बढ़ेगी, लेकिन users को प्रभावित किए बिना संभावित समस्याएँ पकड़ने में मदद मिल सकती है। हमारे मामले में पहले AX162 server को deploy करने के 3 हफ्ते बाद crashes शुरू हुए थे, इसलिए कम से कम एक महीने, शायद उससे भी लंबा buffer period चाहिए
    • यह हर system पर निर्भर करता है। Skunk Works के Kelly Johnson ने अपने मुख्य नियमों में से एक में कहा था कि मौजूदा inspection systems सैन्य आवश्यकताओं की भावना के अनुरूप हैं और नए projects में भी उनका उपयोग होना चाहिए, साथ ही मूल inspection responsibility का अधिक हिस्सा subcontractors और vendors को देना चाहिए और inspection की अनावश्यक duplication नहीं करनी चाहिए
      हालांकि Ubicloud के लिए नए model या खरीद tranche को burn-in के बिना इस्तेमाल करना पहली और आखिरी बार होगा। मैं भी वहाँ काम करता हूँ और co-founder हूँ

  • Dell में भी कभी-कभी ऐसी समस्याएँ आती हैं। जब हमें पुराने servers की पहली lot मिली थी, तो सर्वर कुछ समय के लिए rear I/O side के devices खो देते थे, इसलिए mainboard के I/O rear section को बदलना पड़ा
    उदाहरण के लिए ethernet controller, iDRAC, और कभी-कभी BIOS तक गायब हो जाता था। यह समस्या दूर होने के बाद वे लगभग 10 साल तक अच्छी तरह चले
    हाल में उन्हें RAID cards से लेकर power regulators तक सब घिस जाने के कारण retire किया गया। configuration बदलने की वजह से ठीक चल रहे server को reboot करना, और फिर electromigration के कारण RAID processor के अंदर traces घिस जाने से RAID card को हमेशा के लिए खो देना, सचमुच झकझोर देने वाला अनुभव है

    • Dell में वाकई बहुत समस्याएँ होती हैं। front LED की एक दोषपूर्ण mini board भी server को boot होने या चलने से रोक सकती है, और ऐसे में DRAC भी बंद हो जाता है

  • Hetzner ने पावर लिमिट की संभावना की न तो पुष्टि की और न ही खंडन किया, तो जिज्ञासा है कि पावर लिमिटिंग का नतीजा क्या होता है
    लेख में कहा गया है कि इससे हार्डवेयर जल्दी degrade हो सकता है, लेकिन क्यों, यह समझ नहीं आता
    Hetzner की चुप्पी और UbiCloud के measurements को देखते हुए लगता है कि वे सच में पावर लिमिट कर रहे हैं। अगर ऐसा नहीं होता, तो वे साफ़ मना कर देते

    • मैंने कई cloud products में पहले भी ऐसा देखा है, जहाँ CPU scaling governor को ऐसे eco-friendly value पर सेट किया जाता है जो सिर्फ cloud provider के काम आता है, user को कोई फायदा नहीं देता, और सिर्फ maximum CPU performance को काफी घटा देता है
      जांचने के लिए cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor चलाएँ। इसका मान performance होना चाहिए
      अगर ऐसा नहीं है, तो echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor से सेट किया जा सकता है। CPU-heavy workload हो तो इससे मदद मिल सकती है। reboot के बाद यह वापस बदल जाएगा, इसलिए cron/systemd आदि से इसे बनाए रखना होगा
      बेशक, अगर आप बिजली का बिल खुद भरते हैं या हार्डवेयर आपका अपना है, तो scaling governor का फैसला आप खुद करें। लेकिन rented bare-metal server में performance ही सही है

  • डेटा सेंटर ऑपरेटर पावर constraints के भीतर मशीनों की संख्या बढ़ाने के लिए per-server power usage limit करें, और इससे mainboard degradation तेज हो सकती है — यह बात सहज समझ के उलट लगती है
    मैंने सतही तौर पर जो देखा, उससे तो पावर लिमिटिंग कई components की effective lifespan बढ़ाने वाली चीज़ लगी
    इसके उलट जो results मिले, उनमें सिर्फ इतना था कि thermal throttling होने पर ऊँचा operating temperature capacitor जैसे parts को जल्दी degrade कर सकता है। लेकिन लेख में कई temperature sensors देखे गए थे, और वहाँ यह मामला स्पष्ट रूप से नहीं था

    • जांच के समय मुझे कुछ लेख मिले थे जिनमें कहा गया था कि power limiting से hardware degradation हो सकती है, लेकिन अभी सटीक source मेरे पास नहीं है
      नीचे की reply में एक उदाहरण साझा किया गया है, और खोजने पर कुछ और sources मिले [1], [2]
      हालांकि मैं electronics engineer नहीं हूँ, इसलिए संभव है मेरी समझ पूरी तरह सही न हो। degradation की वजह power limiting खुद न होकर power fluctuation रही हो, या कोई दूसरा factor रहा हो
      [1] https://electronics.stackexchange.com/questions/65837/can-el...
      [2] https://superuser.com/questions/1202062/what-happens-when-ha...
    • पावर = वोल्टेज × करंट
      वोल्टेज बिजली कंपनी देती है, और करंट rack के हिसाब से monitor किया जाता है। डेटा सेंटर में करंट limit पार होने पर सामान्य प्रतिक्रिया fuse उड़ना या ज्यादा पैसे माँगना होती है
      server की power usage घटाने का एकमात्र तरीका CPU को throttle करना है। आम तौर पर CPU throttling operating system के ज़रिए होती है, इसलिए सहयोग चाहिए
      मेरा अनुमान है कि यह OS की भागीदारी के बिना lights-out baseband controller से भी संभव हो सकता है, लेकिन अगर ऐसा है तो शायद /sys में दिखाई देगा
    • अजीब है। मैंने तो हमेशा पढ़ा है कि ज्यादा power और temperature electronics को कहीं तेज़ी से degrade करते हैं। क्या कोई electronics engineer इसे समझा सकता है?
    • डेटा सेंटर के हर rack का एक power budget होता है, और व्यवहार में सीमा अक्सर उपलब्ध बिजली से ज्यादा उस heat removal capacity से तय होती है जिसे cooling system डेटा सेंटर से बाहर निकाल सकता है
      फिर भी, कुछ high-power servers पूरे बड़े डेटा सेंटर को प्रभावित न कर दें, इसलिए rack-level limits लगाई जाती हैं
      यह कैसे लागू किया जाता है, पक्का नहीं, लेकिन घरों में लगे साधारण circuit breaker जैसा उपाय आसान समाधान हो सकता है। लेकिन अगर वह trip हो जाए, तो पूरे rack की power चली जाएगी और कई customers प्रभावित होंगे, इसलिए यह आदर्श नहीं है
      दूसरा विकल्प current/power limiter [0] है, लेकिन P = U * I होने के कारण यह और समस्याएँ पैदा कर सकता है। वोल्टेज (U) गिर सकता है, पूरा system undervoltage में जा सकता है, और अजीब glitches हो सकते हैं। यह chip की कई security protections को bypass करने का भी आम तरीका है। Raspberry Pi ने भी ऐसे bugs खोजने और यह परखने के लिए कि chip voltage attacks समेत हमलों को कितना झेल सकती है, एक challenge [1] चलाया था
      [0] - https://en.m.wikipedia.org/wiki/Current_limiting
      [1] - https://www.raspberrypi.com/news/security-through-transparen...
    • एक संभावना यह है कि low-power setting में CPU कम गर्म होता है, इसलिए fans कम चलते हैं, और नतीजतन दूसरे components को airflow कम मिलता है और वे उल्टा ज्यादा गर्म हो जाते हैं
      आम तौर पर इसका हल यह है कि उन दूसरे components के temperatures भी monitor किए जाएँ और fan speed algorithm के input में शामिल किए जाएँ। यहाँ वास्तव में ऐसा हुआ था या नहीं, पता नहीं

  • पक्का कहना मुश्किल है, लेकिन यह power, signal, या VRM issue भी हो सकता है
    CPU का गर्म न होना यह नहीं दिखाता कि board पर कोई और चीज़ spec के बाहर जाकर catastrophic failure में नहीं गई
    power/signal के आसपास के mainboard issues diagnose करना बहुत मुश्किल होता है। ये तरह-तरह के symptoms के रूप में दिखते हैं, जो ऊपर से किसी दूसरे component की समस्या जैसे लगते हैं; मेरे अनुभव में RAM initialization failure और random restarts बहुत आम हैं। अंत में असली mainboard बदलने से पहले आप लगभग सब कुछ बदलकर देख लेते हैं

  • मेरे मौजूदा AX102 में भी कुछ ऐसा ही हुआ था, और लगा कि crash network card से जुड़ी किसी समस्या की वजह से हुआ
    अच्छी बात यह रही कि Hetzner support ने replacement hardware अच्छी तरह संभाल लिया। यह काफी झंझट भरा था, लेकिन hardware issues सुलझाना सीखने का अच्छा मौका भी था, और मेरे हिसाब से यह उसके लायक था

    • मेरा भी यही अनुभव था। AX102 लगभग बिना load के भी crash हो जाता था, logs में कुछ नहीं होता था, और वह फिर से power on भी नहीं होता था
      Hetzner ने कई बार देखा, लेकिन कुछ नहीं मिला, या सिर्फ CPU thermal paste और PSU connectors बदले। मैं AX162 पर चला गया, और अब तक सब ठीक है

  • क्या data center का अनुभव रखने वाला कोई व्यक्ति अंदाज़ा लगा सकता है कि Hetzner ने यहाँ mainboard supplier के साथ किस तरह का commercial समाधान किया होगा?
    क्या मानना चाहिए कि उन्हें सभी mainboard मुफ़्त में बदलकर देने के साथ मुआवज़ा भी मिला होगा?

    • अगर आप किसी मशहूर brand का server खरीदते हैं, तो defective hardware निश्चित रूप से बदलवाया जा सकता है।
      मुआवज़ा आमतौर पर तभी संभव होता है जब उस पर पहले से negotiation हुई हो, और ऐसे मामले में अतिरिक्त लागत चुकानी पड़ती है। downtime की लागत vendor से वसूलने की कोशिश करने के बजाय business interruption insurance जैसी कोई चीज़ लेना शायद ज़्यादा बेहतर हो सकता है। vendor की गलती हो तब भी यही बात लागू होती है।
      Hetzner कोई सामान्य ग्राहक नहीं है। बहुत आक्रामक cost optimization के तहत उसके सबसे सस्ते parts खरीदने की संभावना ज़्यादा है, और यह भी हो सकता है कि उसने warranty के बिना और कम कीमत पर deal की हो। उस स्थिति में शायद उन्हें replacement mainboard खुद खरीदने पड़े होंगे।
    • लगता है कि शुरुआत में यह पूरा lot उन्हें बहुत सस्ते में मिला होगा। क्योंकि उन servers को शुरू में बिना installation fee के दिया गया था।
      उस समय Germany में Football World Cup चल रहा था।

  • यह पहली बार सुना, और काफ़ी हैरानी हुई, कि data center operator बिजली की सीमाओं की वजह से हर server की power usage limit कर सकते हैं, और इससे mainboard का degradation और तेज़ हो सकता है