सबसे खराब datacenter kaise banaye

आप क्या बना रहे हैं

इस साइट पर हर गाइड आपको कुछ न कुछ सही तरीके से करना सिखाती है: क्रम में कमांड्स, सही परिणाम कैसा दिखता है, और विफलता के तरीकों (failure modes) का नाम। यह गाइड अलग है। आज, पूरी तरह से काल्पनिक रूप से, हम सबसे कम कुशल (least efficient) datacenter डिजाइन करेंगे जिसे पैसा, बिजली और अहंकार (hubris) मिलकर बना सकते हैं।

हमें एक metric की आवश्यकता है, इसलिए हम उद्योग के मानक का उपयोग करेंगे: PUE, Power Usage Effectiveness — कुल facility power को उस power से विभाजित करना जो वास्तव में computing equipment तक पहुँचती है। एक hyperscale datacenter लगभग 1.1 पर चलता है — लगभग हर watt उपयोगी कार्य करता है। एक अच्छा enterprise server room 1.5 मैनेज करता है। हमारा लक्ष्य 4.0 या उससे अधिक है, जिसका अर्थ है कि प्रत्येक watt computing के लिए, तीन और watts बिना किसी काम के नष्ट हो जाते हैं। हम इस नंबर का अक्सर संदर्भ देंगे, जैसे गंभीर गाइड backups का संदर्भ देते हैं।

Site selection: गर्मी ही मुख्य बिंदु है

Cooling एक वास्तविक datacenter में सबसे बड़ा overhead है, इसीलिए हमारा datacenter thermodynamics से उसके अपने ही क्षेत्र में मुकाबला करेगा। आदर्श स्थान एक attic है। South-facing। आदर्श रूप से एक skylight के साथ जो सीधे server पर रोशनी डाले, ताकि मशीन को अपना waste heat और सूरज की गर्मी दोनों मिलें, जो आपके electricity bill और एक तारे के बीच का सहयोग है।

सर्दियों में, cooling खिड़की खोलने से नियंत्रित की जाती है। वास्तविक datacenters बाहरी हवा का उपयोग करते हैं — इस तकनीक को free cooling कहा जाता है, और इसे engineered, filtered, और humidity-controlled किया जाता है। हम इसका उपयोग गलती से करेंगे, एक ऐसी खिड़की के माध्यम से जो बारिश, pollen, और हर तिमाही में कम से कम एक भ्रमित पक्षी को भी अंदर आने देती है।

सच्ची कलाकारी के लिए, एक air conditioner लगाएं, फिर उसके thermostat से दो फीट की दूरी पर एक space heater रखें, जिसे air conditioner के target से दो डिग्री अधिक पर सेट किया गया हो। अब दोनों machines लगातार, हमेशा, पूर्ण असहमति में चलेंगी। Power company क्रिसमस पर आपको एक कार्ड भेजेगी।

One server, large, beloved

Redundancy प्रतिबद्धता (commitment) को कम कर देता है। हमारे datacenter में ठीक एक server है, और वह विशाल है, क्योंकि 512 GB RAM वाली एक मशीन infrastructure जैसी लगती है, जबकि चार छोटी machines एक to-do list जैसी लगती हैं।

Server का एक नाम है। Hostname नहीं — एक नाम। आमतौर पर Gandalf, या Odin। आप Odin को decommission नहीं कर सकते। Odin पांच साल से uptime पर है:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

यह नंबर गर्व का विषय है, इसीलिए आप इसका screenshot लेते हैं और इसे post करते हैं, और इसीलिए हर attacker जो screenshot देखता है, उसे यह प्रभावशाली लगता है: 1,847 days of uptime का मतलब है 1,847 days के kernel vulnerabilities, जिन्हें किसी ने patch नहीं किया है। Reboot करना वैसे भी संभव नहीं है — reboot ही वह तरीका है जिससे आपको पता चलता है कि कौन सी services 2021 में हाथ से शुरू की गई थीं और कभी systemd unit में नहीं लिखी गईं। किसी को याद नहीं कि वे कौन सी थीं। Server अब organizational chart में load-bearing बन चुका है।

Storage: speed, और डेटा खोने के अन्य तरीके

Performance के लिए disks को RAID 0 में configure किया गया है। Zero उन disks की संख्या को दर्शाता है जो fail हो सकती हैं। अधिकतम प्रभाव के लिए, array को मिश्रित स्रोत (mixed provenance) वाले storage पर stripe करें: दो असली SSDs, एक पुराना spinner, और एक conference से लिया गया USB stick। Array उतना ही विश्वसनीय है जितना कि वह conference stick, जो कि हमारा design है।

Backups को उसी array पर एक directory द्वारा संभाला जाता है जिसका नाम backup_final_v2_REAL है, जिसमें पिछले naming scheme का एक tarball होता है। Off-site backups को "set up off-site backups" लिखे हुए एक sticky note द्वारा दर्शाया जाता है, जो तकनीकी रूप से तब off-site स्टोर होता है जब आप इसे अपने laptop के lid पर रखकर घर ले जाते हैं।

एक सही परिणाम ऐसा दिखता है: df जो 97% usage रिपोर्ट करता है, और अगले sprint में इससे निपटने की एक योजना।

Networking: हर चीज़ की एक एकल strand

DNS server उसी machine पर चलता है, ताकि जब server डाउन हो जाए, तो वह उस DNS record को भी अपने साथ ले जाए जिसका उपयोग आप यह पता लगाने के लिए करेंगे कि क्यों। इसे consolidation कहा जाता है।

Firewall को 2021 में disable कर दिया गया था — कुछ debug करने के लिए अस्थायी रूप से। Debugging समाप्त हो गई; firewall वापस नहीं आया। Router का हर port "बाद में समय बचाने के लिए" server पर forward किया गया है, और router का admin panel WAN side से अपने factory password के साथ सुलभ है, ताकि सुविधाजनक remote management हो सके। आपके लिए, और दूसरों के लिए भी।

Server हाल ही में असामान्य रूप से गर्म चल रहा है, attic के मानकों के अनुसार भी, और top दिखाता है कि सबसे व्यस्त process xmrig नामक कुछ है। हम मान लेते हैं कि यह वही monitoring tool है जिसका हम उपयोग कर रहे हैं। हमने इसे install नहीं किया है — यह ports forward होने के तुरंत बाद अपने आप प्रकट हो गया, जिसे हम इस संकेत के रूप में लेते हैं कि ecosystem फल-फूल रहा है। यह चौबीसों घंटे monitor करता है।

Power consumer power strips की एक श्रृंखला के माध्यम से आती है जिनकी कुल लंबाई breaker panel तक जाने वाली पैदल दूरी से अधिक है — जो एक अर्थ में efficient है, क्योंकि आपको breaker panel पर अक्सर जाना पड़ेगा।

Complexity के माध्यम से Redundancy

जहाँ आवश्यकता थी वहाँ redundancy को अस्वीकार करने के बाद, अब हम उसे वहाँ जोड़ रहे हैं जहाँ उसकी आवश्यकता नहीं है। Company homepage — एक static HTML file — एक twelve-node Kubernetes cluster द्वारा serve किया जाता है। यह वह हासिल करता है जिसे engineers resume-driven architecture कहते हैं: पेज उसी forty milliseconds में लोड होता है जो nginx deliver करता, लेकिन अब यह उन तरीकों से fail हो सकता है जिसके लिए consultant की आवश्यकता होती है।

Isolation के लिए, cluster स्वयं एक virtual machine के अंदर एक virtual machine के अंदर एक virtual machine के अंदर चलता है, जहाँ प्रत्येक layer सुरक्षा जोड़ती है, ठीक वैसे ही जैसे turducken की प्रत्येक layer मांस (bird) जोड़ती है। Contact form नौ microservices है। उनमें से दो को कभी invoke नहीं किया गया है। उनमें से एक load-bearing है और कोई नहीं जानता कि कौन सी।

Heating as a service

एक आधुनिक server बिजली को computation और गर्मी में बदलता है, और हमारा इरादा दूसरे output को maximize करने का है। एक media server जिसमें no GPU है एक क्लासिक तरीका है: CPU-transcoding एक single 4K stream sixteen cores को व्यस्त कर देगी और एक छोटे bedroom को गर्म कर देगी, एक space heater जो movies भी चलाता है। महत्वाकांक्षी operator CPU पर एक large language model चलाने की ओर बढ़ता है — एक 70-billion-parameter वाला space heater जिसमें API है, जो tokens को उस दर से produce करता है जिसे seasonal रूप में मापा जाना सबसे अच्छा है।

Monitor खुद को देखता है

Observability महत्वपूर्ण है, इसलिए हम एक self-hosted uptime monitor deploy करते हैं — उसी server पर जिसे वह monitor करता है। जब Odin मरता है, तो monitor भी उसके साथ मर जाता है, और यहाँ एक सुंदर बात है: कोई alert नहीं बजता। No alerts का मतलब है no incidents। No incidents का मतलब है perfect uptime, जैसा कि मापा गया है। Monthly report पहले कभी इतनी अच्छी नहीं दिखी।

पूर्णता के लिए, alert emails को एक mail server के माध्यम से relay किया जाता है जो Odin पर ही चलता है। इस प्रकार alerting pipeline पूरी तरह से self-contained है, जैसे एक सांप जो अपनी ही पूंछ खा रहा है, वह पूरी तरह से तृप्त है।

Uncomfortable हिस्सा

यहाँ वह section है जिसे मैं टालता आ रहा हूँ। इनमें से कुछ भी fiction नहीं है। वह प्यारा irreplaceable server, उसी volume पर backups के साथ RAID 0, "अस्थायी रूप से" disabled firewall, एक page serve करने वाला Kubernetes cluster, खुद को monitor करने वाला monitor — मैंने इनमें से हर एक को production में देखा है। इनमें से कुछ मैंने इस साल देखे हैं। इनमें से एक या दो, मेरे शुरुआती दिनों में, मैंने बनाए थे।

वास्तविक efficiency कैसी दिखती है, यह उबाऊ है, इसीलिए यह पल भर में बहस हार जाता है और एक दशक में जीत जाता है: एक ऐसा PUE जिसके बारे में आप कभी नहीं सोचते क्योंकि किसी और ने इसे engineer किया है। Machines जो अपने owner के self-image के बजाय अपने workload के हिसाब से sized हों। एक blast radius, जिसका विस्फोट से पहले विचार किया गया हो। Backups जिन्हें एक schedule पर, calendar reminder के साथ और बिना किसी heroism के, restore करके test किया जाता है। Redundancy जो उबाऊ है — दो सस्ती चीजें एक शानदार चीज से बेहतर होती हैं, हर बार, हर उस failure में जिसके लिए मुझे कभी page किया गया है।

और सबसे efficient datacenter जिसे आप चला सकते हैं, वह है जिसे आप नहीं चलाते। एक VPS power, cooling, redundancy, और 3 a.m. hardware failures को उन लोगों को सौंप देता है जो इन्हें scale पर, उबाऊ तरीके से करते हैं, जो infrastructure के लिए सबसे बड़ी प्रशंसा है — और यह आपको वास्तव में मजेदार हिस्सा छोड़ देता है, जो है उसके ऊपर अपनी services चलाना, एक ऐसी machine पर जिसे आप खोने का खर्च उठा सकते हैं, जो एकमात्र प्रकार है जिस पर आपको कभी experiment करना चाहिए।

FAQ

क्या मुझे वास्तव में इनमें से कुछ करना चाहिए?

नहीं। इस guide का हर section एक documented anti-pattern है जिसके कारण कई weekends बर्बाद हुए हैं। यदि आपका current setup दो से अधिक sections से मिलता-जुलता है, तो इस FAQ के अंतिम प्रश्न पर जाएँ — दिए गए क्रम में, क्योंकि क्रम ही triage है।

वास्तव में एक अच्छा PUE क्या है?

Hyperscale datacenters लगभग 1.1 पर चलते हैं, एक अच्छी तरह से संचालित enterprise room 1.4 से 1.6 मैनेज करता है, और एक space heater के विवाद वाला uncooled closet वास्तव में 3 से अधिक हो सकता है। आप घर पर 1.1 के साथ सार्थक रूप से प्रतिस्पर्धा नहीं कर सकते, जो कि compute को किसी ऐसे व्यक्ति से किराए पर लेने का शांत आर्थिक तर्क है जो ऐसा कर सकता है।

क्या servers के साथ एक building को गर्म करना एक वास्तविक चीज़ है?

हाँ — यदि सही ढंग से किया जाए। कई देशों में district-heating projects heat exchangers के माध्यम से datacenter waste heat को capture करते हैं और इसे design, engineering और contracts के माध्यम से घरों में pipe करते हैं। ऊपर दिया गया व्यंग्य यह नहीं है कि server heat एक कमरे को गर्म कर सकता है; यह यह है कि वह गलती से ऐसा कर रहा है और उस गलती को एक strategy कह रहा है।

मेरा server पहले से ही ऐसा दिखता है। मुझे सबसे पहले क्या करना चाहिए?

Backups, आज रात, ऐसी जगह जहाँ server न हो, और फिर एक test restore — एक untested backup केवल एक अफवाह है। दूसरा, patches और वह reboot जिसे आप टालते आ रहे हैं, एक planned window में, ताकि आप देख सकें कि क्या टूटता है। तीसरा, single point of failure को विभाजित करें: DNS और monitoring को box से हटा दें। बाकी सब कुछ एक शांत सप्ताह के लिए इंतज़ार कर सकता है; वे तीन नहीं कर सकते।