दुनिया का सबसे कम दक्ष datacenter: पूरी guide

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

इस साइट की हर गाइड आपको कोई काम सही तरीके से करना सिखाती है: क्रम से दिए गए commands, सही परिणाम कैसा दिखता है, और नामित failure modes। यह गाइड अलग है। आज, पूरी तरह काल्पनिक रूप से, हम ऐसा सबसे कम दक्ष datacenter design करेंगे, जिसे पैसा, बिजली और अहंकार मिलकर बना सकते हैं।

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

साइट चयन: ऊष्मा ही उद्देश्य है

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

सर्दियों में cooling का प्रबंध window खोलकर किया जाएगा। वास्तविक datacenter बाहर की air का उपयोग करते हैं। इस तकनीक को free cooling कहा जाता है। इसमें engineering, filtering और humidity control किया जाता है। हम इसका उपयोग अनजाने में करेंगे। इसके लिए ऐसी window होगी, जिससे rain, pollen और हर quarter में कम से कम एक confused bird भी अंदर आ सके।

वास्तविक कलात्मकता के लिए एक air conditioner install करें। फिर उसके thermostat से two feet दूर एक space heater रखें। उसे air conditioner's target से two degrees अधिक पर set करें। अब दोनों machines लगातार और हमेशा चलेंगी। वे पूरी तरह असहमत रहेंगी। बिजली कंपनी आपको Christmas पर एक card भेजेगी।

एक सर्वर, बड़ा और प्रिय

अतिरेक प्रतिबद्धता को कम करता है। हमारे data center में ठीक एक server है, और वह बहुत बड़ा है, क्योंकि 512 GB RAM वाली एक machine infrastructure जैसी लगती है, जबकि चार छोटी machines कामों की सूची जैसी लगती हैं।

Server का एक नाम है। Hostname नहीं, नाम। आमतौर पर Gandalf या Odin। Odin को decommission नहीं किया जा सकता। Odin पांच वर्षों से चालू है:

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

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

स्टोरेज: गति और डेटा खोने के अन्य तरीके

प्रदर्शन के लिए डिस्क को RAID 0 में कॉन्फ़िगर किया गया है। शून्य उन डिस्क की संख्या को दर्शाता है जो विफल हो सकती हैं। अधिकतम प्रभाव के लिए, अलग-अलग स्रोतों वाले स्टोरेज पर array को stripe करें: दो उचित SSD, एक पुराना spinning disk और किसी सम्मेलन से मिली USB stick। array की विश्वसनीयता सम्मेलन वाली stick जितनी ही है। यही इसका डिज़ाइन है।

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

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

नेटवर्किंग: हर चीज़ की एक ही कड़ी

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

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

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

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

जटिलता के माध्यम से अतिरेक

जहाँ अतिरेक महत्वपूर्ण था, उसे अस्वीकार करने के बाद अब हम उसे वहाँ जोड़ते हैं जहाँ उसकी आवश्यकता नहीं है। कंपनी का होमपेज, जो एक स्थिर HTML फ़ाइल है, बारह-नोड वाले Kubernetes क्लस्टर से सर्व किया जाता है। इससे वह हासिल होता है जिसे इंजीनियर resume-driven architecture कहते हैं: पेज उतने ही चालीस मिलीसेकंड में लोड होता है, जितने में nginx उसे सर्व कर देता, लेकिन अब यह उन तरीकों से विफल हो सकता है जिनके लिए सलाहकार की आवश्यकता पड़ती है।

अलगाव के लिए, क्लस्टर स्वयं एक वर्चुअल मशीन के अंदर एक वर्चुअल मशीन के अंदर एक वर्चुअल मशीन में चलता है। हर परत सुरक्षा जोड़ती है, जैसे turducken की हर परत एक पक्षी जोड़ती है। संपर्क फ़ॉर्म नौ microservices से बना है। उनमें से दो को कभी invoke नहीं किया गया। उनमें से एक load-bearing है, और किसी को पता नहीं कि वह कौन-सा है।

सेवा के रूप में ताप

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

मॉनिटर स्वयं की निगरानी करता है

ऑब्ज़र्वेबिलिटी महत्वपूर्ण है, इसलिए हम स्वयं होस्ट किया गया अपटाइम मॉनिटर उसी server पर deploy करते हैं, जिसकी यह निगरानी करता है। जब Odin बंद हो जाता है, तो मॉनिटर भी उसके साथ बंद हो जाता है। इसका परिणाम यह होता है कि कोई alert जारी नहीं होता। कोई alert नहीं होने का अर्थ है कि कोई incident नहीं है। कोई incident नहीं होने का अर्थ है कि मापे गए uptime के अनुसार सब कुछ सही है। मासिक report पहले से बेहतर दिखती है।

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

असुविधाजनक हिस्सा

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

वास्तविक efficiency उबाऊ दिखती है। इसी कारण वह तत्काल बहस हार जाती है और एक दशक में जीतती है: ऐसा PUE, जिसके बारे में आपको कभी सोचना नहीं पड़ता क्योंकि किसी और ने उसे engineer किया है। Machines को उनके workload के अनुसार आकार दिया जाता है, उनके owner की आत्म-छवि के अनुसार नहीं। Explosion से पहले blast radius पर विचार किया जाता है। Backups को schedule के अनुसार restore करके test किया जाता है, calendar reminder के साथ और किसी heroics के बिना। Redundancy उबाऊ होती है। हर बार, और मेरे द्वारा paged किए गए हर failure में, एक शानदार चीज़ की तुलना में सस्ती चीज़ की दो इकाइयां बेहतर होती हैं।

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

FAQ

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

नहीं। इस गाइड का प्रत्येक खंड एक दस्तावेजीकृत गलत तरीका है, जिससे कई सप्ताहांत बर्बाद हुए हैं। यदि आपका वर्तमान सेटअप दो से अधिक खंडों जैसा है, तो दिए गए क्रम में इस FAQ के अंतिम प्रश्न पर जाएँ, क्योंकि यही ट्रायेज का क्रम है।

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

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

क्या servers से किसी building को गर्म करना वास्तव में संभव है?

हाँ, यदि इसे सही तरीके से किया जाए। कई देशों में district-heating projects heat exchangers के माध्यम से datacenter की waste heat एकत्र करते हैं और engineering तथा contracts के आधार पर उसे pipes से घरों तक पहुँचाते हैं। ऊपर का व्यंग्य इस बात पर नहीं है कि server heat किसी कमरे को गर्म कर सकती है। समस्या यह है कि इसे दुर्घटनावश किया जाता है और उस दुर्घटना को रणनीति कहा जाता है।

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

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