जगातील सर्वात वाईट डेटासेंटर कसे बांधावे

तुम्ही काय बांधत आहात

या साइटवरील प्रत्येक मार्गदर्शक तुम्हाला काहीतरी योग्यरित्या करायला शिकवतो: क्रमाने कमांड, योग्य परिणाम कसा दिसतो, आणि अपयशाच्या प्रकारांची नावे. हा मार्गदर्शक वेगळा आहे. आज, पूर्णपणे गृहीतक म्हणून, आपण पैसा, वीज आणि गर्व यांनी तयार करू शकतील असा सर्वात कमी कार्यक्षम डेटासेंटर डिझाइन करणार आहोत.

आपल्याला एक मेट्रिक हवे आहे, म्हणून आपण उद्योगाचाच मेट्रिक वापरू: PUE, Power Usage Effectiveness — एकूण सुविधेची शक्ती, विभाजित केलेली संगणकीय उपकरणांपर्यंत पोहोचणाऱ्या शक्तीने. एक हायपरस्केल डेटासेंटर 1.1 भोवती चालतो: जवळजवळ प्रत्येक वॅट उपयुक्त काम करतो. एक चांगली एंटरप्राइझ सर्व्हर रूम 1.5 व्यवस्थापित करते. आमचे लक्ष्य 4.0 किंवा त्याहून जास्त आहे, म्हणजे संगणनाच्या प्रत्येक वॅटसाठी, तीन अतिरिक्त वॅट व्यर्थ मरतात. आपण या संख्येचा वारंवार संदर्भ घेऊ, जसे संकटनिवारण मार्गदर्शक बॅकअपचा संदर्भ घेतात.

साइट निवड: उष्णता हेच मुद्दा आहे

एका वास्तविक डेटासेंटरमध्ये कूलिंग हा सर्वात मोठा खर्च असतो, म्हणून आपले डेटासेंटर थर्मोडायनामिक्सशी त्याच्याच घरात लढेल. आदर्श जागा एक अटारी आहे. दक्षिण-दिशेला तोंड केलेली. आदर्शपणे एका स्कायलाइटसह जी थेट सर्व्हरवर चमकेल, जेणेकरून मशीनला त्याची स्वतःची कचरा उष्णता आणि सूर्याची उष्णता दोन्ही मिळतील, तुमच्या वीज बिलाची आणि एका ताऱ्याची भागीदारी.

हिवाळ्यात, कूलिंग खिडकी उघडून हाताळले जाते. वास्तविक डेटासेंटर बाहेरची हवा वापरतात — या तंत्राला free cooling म्हणतात, आणि ते अभियांत्रिकी केलेले, फिल्टर केलेले आणि आर्द्रता-नियंत्रित असते. आपण ते नियोजनाशिवाय वापरू, एका खिडकीद्वारे जी पाऊस, परागकण, आणि दर तिमाहीत किमान एक गोंधळलेला पक्षी आत घेते.

खऱ्या कलाकौशल्यासाठी, एक एअर कंडिशनर इन्स्टॉल करा, मग त्याच्या थर्मोस्टॅटपासून दोन फूट दूर एक स्पेस हीटर ठेवा, एअर कंडिशनरच्या लक्ष्यापेक्षा दोन अंश जास्त गरम सेट केलेला. आता दोन्ही मशीन सतत, कायमचे, पूर्ण भांडणात चालतील. वीज कंपनी तुम्हाला ख्रिसमसला एक कार्ड पाठवेल.

एक सर्व्हर, मोठा, लाडका

रिडंडन्सी वचनबद्धता कमी करते. आमच्या डेटासेंटरमध्ये नेमका एकच सर्व्हर आहे, आणि तो प्रचंड मोठा आहे, कारण 512 GB RAM सह एक मशीन इन्फ्रास्ट्रक्चरसारखे वाटते, तर चार लहान मशीन्स एक to-do list सारखे वाटतात.

सर्व्हरचे एक नाव आहे. hostname नाही — एक नाव. सहसा Gandalf, किंवा Odin. तुम्ही Odin डिकमिशन करू शकत नाही. Odin पाच वर्षांपासून चालू आहे:

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

ती संख्या अभिमानाचा मुद्दा आहे, म्हणून तुम्ही त्याचा स्क्रीनशॉट घेऊन पोस्ट करता, आणि म्हणूनच तो स्क्रीनशॉट पाहणारा प्रत्येक हल्लाखोर तो देखील प्रभावी वाटतो: 1,847 दिवसांचे uptime म्हणजे 1,847 दिवस कर्नल भेदांचे, कोणीही पॅच केलेले नाही. रीबूट करणे तर प्रश्नच नाही — रीबूट म्हणजे तुम्हाला कळते की 2021 मध्ये हाताने सुरू केलेली आणि कधीच systemd unit मध्ये लिहिली नाहीत अशी कोणती सेव्हिसेस होत्या. कोणालाही आठवत नाही कोणती. सर्व्हर आता संस्थेच्या संरचनेत भार वाहणारा आहे.

स्टोरेज: वेग, आणि डेटा गमावण्याच्या इतर पद्धती

डिस्क RAID 0 मध्ये कॉन्फिगर केल्या आहेत, कामगिरीसाठी. ते झिरो म्हणजे न बिघडता चालू शकणाऱ्या डिस्कची संख्या. जास्तीत जास्त परिणामासाठी, अॅरे वेगवेगळ्या स्रोतांच्या स्टोरेजवर स्ट्राइप करा: दोन योग्य SSDs, एक जुनी स्पिनर, आणि एका कॉन्फरन्समधील USB stick. अॅरे नेमके त्या कॉन्फरन्स stick एवढाच विश्वासार्ह आहे, हेच डिझाइन आहे.

बॅकअप्स त्याच अॅरेवरील एका डिरेक्टरीद्वारे हाताळले जातात ज्याचे नाव backup_final_v2_REAL आहे, ज्यात मागील नामकरण योजनेचा एक tarball आहे. ऑफ-साइट बॅकअप्स एका स्टिकी नोटद्वारे दर्शविले जातात ज्यावर "set up off-site backups" लिहिले आहे, जी तांत्रिकदृष्ट्या, तुम्ही ती तुमच्या लॅपटॉपच्या झाकणीवर घेऊन घरी नेल्यावर ऑफ-साइट साठवलेली असते.

एक योग्य परिणाम असा दिसतो: df 97% वापर दर्शवित आहे, आणि पुढील स्प्रिंटमध्ये त्यावर उपाय करण्याची योजना आहे.

नेटवर्किंग: सर्व गोष्टींचा एकच धागा

DNS सर्व्हर मशीनवरच चालतो, जेणेकरून सर्व्हर बंद पडल्यास, ते का बंद पडले हे शोधण्यासाठी तुम्ही वापरणार DNS रेकॉर्ड देखील त्यासोबत बंद पडतो. याला कन्सॉलिडेशन म्हणतात.

फायरवॉल 2021 मध्ये बंद करण्यात आला होता — तात्पुरता, काहीतरी डीबग करण्यासाठी. डीबगिंग संपले; फायरवॉल परत आला नाही. राउटरवरील प्रत्येक पोर्ट सर्व्हरवर फॉरवर्ड केला आहे "नंतर वेळ वाचवण्यासाठी," आणि राउटरचा admin panel WAN बाजूनून त्याच्या फॅक्टरी पासवर्डसह पोहोचण्यायोग्य आहे, सोयीस्कर रिमोट व्यवस्थापनासाठी. तुमच्यासाठी, आणि इतरांसाठी.

सर्व्हर अलीकडे अनपेक्षितरित्या गरम चालू आहे, अटारीच्या मानकांनुसारही, आणि top सर्वात व्यस्त प्रक्रिया xmrig नावाची काहीतरी आहे हे दर्शविते. आपण गृहीत धरतो की हे आपण वापरत असलेले मॉनिटरिंग साधन आहे. आपण ते इन्स्टॉल केले नाही — पोर्ट्स फॉरवर्ड केल्यानंतर ते आपोआप दिसू लागले, जे आपण इकोसिस्टम भरभराटीत आहे याचे लक्षण म्हणून घेतो. ते आठवड्याचे सात दिवस, चोवीस तास मॉनिटर करते.

वीज ग्राहक पावर स्ट्रिप्सच्या साखळीद्वारे येते ज्यांची एकत्रित लांबी ब्रेकर पॅनेलपर्यंत चालण्याच्या अंतरापेक्षा जास्त आहे — जे एका अर्थाने कार्यक्षम आहे, कारण तुम्ही ब्रेकर पॅनेलवर वारंवार भेट देत राहाल.

जटिलतेद्वारे रिडंडन्सी

जिथे महत्त्वाचे आहे तिथे रिडंडन्सी नाकारल्यानंतर, आपण आता तिथे जोडतो जिथे ते नाही. कंपनीचे होमपेज — एक static HTML फाइल — बारा-नोड्सच्या Kubernetes क्लस्टरद्वारे सर्व्ह केले जाते. हे अभियंते ज्याला resume-driven architecture म्हणतात ते साध्य करते: पेज त्याच चाळीस मिलिसेकंदांत लोड होतो जे nginx दिले असते, पण ते आता अशा प्रकारे अपयशी होऊ शकते ज्यासाठी एका सल्लागारची गरज असते.

विलगीकरणासाठी, क्लस्टर एका व्हर्च्युअल मशीनमधील एका व्हर्च्युअल मशीनमधील एका व्हर्च्युअल मशीनमध्ये चालतो, प्रत्येक स्तर सुरक्षा वाढवतो जसे turducken चा प्रत्येक स्तर पक्षी वाढवतो. संपर्क फॉर्म नऊ मायक्रोसेव्हिसेस आहेत. त्यापैकी दोन कधीच कॉल केल्या गेल्या नाहीत. एक भार वाहणारी आहे आणि कोणालाही माहित नाही कोणती.

सेवा म्हणून तापणे

एक आधुनिक सर्व्हर वीजीला संगणन आणि उष्णतेत रूपांतरित करतो, आणि आपण दुसरे आउटपुट जास्तीत जास्त करण्याचे इरादा करत आहोत. एक GPU नसलेला मीडिया सर्व्हर हा क्लासिक मार्ग आहे: एकच 4K स्ट्रीम CPU-ट्रान्सकोडिंग करणे सोळा कोर्सला पिन करेल आणि एक लहान बेडरूम गरम करेल, एक स्पेस हीटर जे चित्रपट देखील चालवते. महत्त्वाकांक्षी ऑपरेटर CPU वर एक मोठे भाषा मॉडेल चालवण्यापर्यंत पोहोचतो — एक 70-बिलियन-पॅरामीटरचा स्पेस हीटर API सह, टोकन्स अशा वेगाने तयार करतो जो मोजणे हंगामानुसार सोयीचे आहे.

मॉनिटर स्वतःलाच पाहतो

ऑब्झर्व्हबिलिटी महत्त्वाची आहे, म्हणून आपण एक सेल्फ-होस्टेड uptime मॉनिटर डिप्लॉय करतो — त्याच सर्व्हरवर जे ते मॉनिटर करते. Odin मरताच, मॉनिटर त्यासोबत मरतो, आणि इथे एक सुंदर भाग आहे: कोणतीही अलर्ट्स फायर होत नाहीत. अलर्ट्स नसणे म्हणजे अपघात नाहीत. अपघात नसणे म्हणजे उत्तम uptime, मोजल्याप्रमाणे. मासिक अहवाल कधीच इतका चांगला दिसला नाही आहे.

अलर्ट ईमेल्स, पूर्णतेसाठी, एका मेल सर्व्हरद्वारे रिले केले जातात जो देखील Odin वर चालतो. अलर्टिंग पाइपलाइन अशा प्रकारे पूर्णपणे स्वयंपूर्ण आहे, जसे स्वतःची शेपूट खाणारा साप पूर्णपणे भरलेला असतो.

अस्वस्थ करणारा भाग

हा तो भाग आहे जो मी पुढे ढकलत होतो. यापैकी काहीही कल्पना नाही. लाडका अप्रतिम सर्व्हर, समान व्हॉल्यूमवर बॅकअप्ससह RAID 0, "तात्पुरता" बंद केलेला फायरवॉल, एकच पेज सर्व्ह करणारा Kubernetes क्लस्टर, स्वतःलाच पाहणारा मॉनिटर — यापैकी प्रत्येक मी प्रोडक्शनमध्ये पाहिले आहे. त्यापैकी काही मी या वर्षी पाहिले आहेत. एक किंवा दोन, माझ्या सुरुवातीच्या दिवसांत, मी स्वतः बांधले आहेत.

वास्तविक कार्यक्षमता कशी दिसते ते कंटाळवाणे आहे, म्हणून ते क्षणात वादात हरते आणि दशकात जिंकते: एक PUE ज्याबद्दल तुम्ही कधीच विचार करत नाही कारण दुसऱ्या कोणीत्याचे अभियांत्रिकी केले आहे. मशीन्स त्यांच्या मालकाच्या स्वतःच्या प्रतिमेपेक्षा त्यांच्या कामाच्या आकारानुसार आकारात आहेत. एक ब्लास्ट रेडियस, स्फोटापूर्वी विचारलेला. बॅकअप्स जे त्यांना रिस्टोअर करून तपासले जातात, एका वेळापत्रकानुसार, एका कॅलेंडर रिमाइंडरसह आणि शूरवीरपणाशिवाय. रिडंडन्सी जी कंटाळवाणी आहे — स्वस्त वस्तूचे दोन, एका भव्य वस्तूचे एकावर हरवतात, प्रत्येक वेळी, प्रत्येक अपयशात ज्यासाठी मला पेज केले गेले आहे.

आणि तुम्ही चालवू शकत असे सर्वात कार्यक्षम डेटासेंटर ते आहे जे तुम्ही चालवत नाही. एक VPS वीज, कूलिंग, रिडंडन्सी, आणि 3 a.m.चे हार्डवेअर अपयश अशा लोकांकडे सोपवते जे ते मोठ्या प्रमाणावर, कंटाळवाण्या पद्धतीने करतात, जे इन्फ्रास्ट्रक्चरला मिळू शकणारा सर्वोच्च स्तुती आहे — आणि ते तुम्हाला खरोखर मजेदार भाग सोडते, जो त्यावर तुमच्या स्वतःच्या सेव्हिसेस चालवणे आहे, अशा मशीनवर ज्याला तुम्ही गमावू शकता, जो एकमेव प्रकार आहे ज्यावर तुम्ही कधीही प्रयोग करायला हवे.

FAQ

मी खरंच यापैकी काही करावे?

नाही. या मार्गदर्शकाचा प्रत्येक भाग एक दस्तऐवजजोग अँटी-पॅटर्न आहे ज्यामध्ये सुट्ट्यांचा बळी गेला आहे. जर तुमची सध्याची सेटअप दोनपेक्षा जास्त भागांसारखी दिसत असेल, तर या FAQ मधील शेवटच्या प्रश्नावर जा — दिलेल्या क्रमानुसार, कारण हा क्रम त्रियेज आहे.

चांगले PUE प्रत्यक्षात काय असते?

हायपरस्केल डेटासेंटर 1.1 भोवती चालतात, एक चांगल्या प्रकारे चालवलेली एंटरप्राइझ रूम 1.4 ते 1.6 व्यवस्थापित करते, आणि एक कूलिंग नसलेला कपाळ स्पेस हीटरच्या भांडणासह खरोखर 3 पेक्षा जास्त होऊ शकतो. तुम्ही घरी 1.1 शी अर्थपूर्णरित्या स्पर्धा करू शकत नाही, जो करू शकणाऱ्याकडून कंप्युट भाड्याने घेण्याचा शांत आर्थिक युक्तिवाद आहे.

सर्व्हर्ससह इमारत तापवणे हे खरं गोष्ट आहे का?

होय — योग्यरित्या केल्यास. अनेक देशांमधील डिस्ट्रिक्ट-हीटिंग प्रकल्प हीट एक्सचेंजर्सद्वारे डेटासेंटरची कचरा उष्णता कॅप्चर करतात आणि ती नियोजनाने, अभियांत्रिकी आणि करारांसह घरांमध्ये पाईप करून पाठवतात. वरील व्यंगचित्र हे नाही की सर्व्हर उष्णता एखादी खोली गरम करू शकते; ते आपघाताने तसे करणे आणि त्या आपघाताला धोरण म्हणणे आहे.

माझा सर्व्हर आधीच असा दिसत आहे. मी आधी काय करावे?

बॅकअप्स, आज रात्री, सर्व्हर नसलेल्या ठिकाणी, आणि मग एक टेस्ट रिस्टोअर — न तपासलेला बॅकअप ही एक अफवा आहे. दुसरे, पॅचेस आणि तुम्ही टाळत असलेले रीबूट, एका नियोजित विंडोमध्ये, जेणेकरून तुम्ही पाहत असताना काय तुटते हे तुम्हाला कळेल. तिसरे, एकमेव अपयशाचा मुद्दा विभाजित करा: DNS आणि मॉनिटरिंग बॉक्सवरून हलवा. बाकी सर्व एका शांत आठवड्यासाठी थांबू शकते; हे तीन थांबू शकत नाहीत.