जगातील सर्वांत अकार्यक्षम datacenter: मार्गदर्शक

तुम्ही काय उभारत आहात

या साइटवरील प्रत्येक मार्गदर्शक तुम्हाला एखादी गोष्ट योग्य पद्धतीने करण्यास शिकवतो: commands योग्य क्रमाने चालवणे, योग्य परिणाम कसा दिसतो हे ओळखणे आणि failure modes समजून घेणे. हा मार्गदर्शक वेगळा आहे. आज आपण पूर्णपणे काल्पनिक उदाहरण म्हणून, पैसा, वीज आणि अहंकार यांच्या जोरावर उभारता येईल असे सर्वांत अकार्यक्षम datacenter डिझाइन करणार आहोत.

आपल्याला एक मापनपद्धती हवी आहे. म्हणून आपण उद्योगक्षेत्रातीलच PUE, म्हणजे Power Usage Effectiveness, वापरू. हे एकूण facility power आणि computing equipment पर्यंत प्रत्यक्ष पोहोचणाऱ्या power यांचे गुणोत्तर आहे. Hyperscale datacenter चे PUE साधारण 1.1 असते: जवळजवळ प्रत्येक watt उपयुक्त काम करतो. चांगल्या enterprise server room चे PUE 1.5 असते. आपले लक्ष्य 4.0 किंवा त्याहून अधिक आहे. म्हणजे computing साठी वापरल्या जाणाऱ्या प्रत्येक watt मागे आणखी तीन watts विनाकारण वाया जातील. गंभीर मार्गदर्शक ज्या प्रकारे backups चा वारंवार उल्लेख करतात, त्याच प्रकारे आपण या संख्येचा वारंवार उल्लेख करू.

स्थळ निवड: उष्णताच मुख्य मुद्दा आहे

वास्तविक data center मध्ये cooling हा सर्वांत मोठा खर्च असतो. म्हणून आमचा data center thermodynamics च्या मुळ ठिकाणीच त्याला आव्हान देईल. आदर्श ठिकाण म्हणजे माळा. दक्षिणाभिमुख. शक्य असल्यास server वर थेट प्रकाश पडेल अशा ठिकाणी skylight असावी. त्यामुळे machine ला तिची स्वतःची waste heat आणि सूर्याची उष्णता दोन्ही मिळतील. ही तुमच्या electricity bill आणि एका ताऱ्यामधील सहकार्याची रचना असेल.

हिवाळ्यात window उघडून cooling केली जाईल. वास्तविक data center मध्ये बाहेरील हवा वापरली जाते. या तंत्राला free cooling म्हणतात. त्यासाठी अभियांत्रिकीदृष्ट्या योग्य रचना, filtration आणि humidity control केले जाते. आपण ते चुकून वापरू. त्यासाठी अशी window वापरली जाईल जिच्यातून rain, pollen आणि दर तिमाहीला किमान एक गोंधळलेला bird देखील आत येईल.

खऱ्या कलात्मकतेसाठी air conditioner बसवा. त्यानंतर त्याच्या thermostat पासून दोन feet अंतरावर space heater ठेवा आणि तो air conditioner's target पेक्षा दोन degrees जास्त तापमानावर set करा. आता दोन्ही machines सतत आणि कायम चालू राहतील. त्यांचे नियंत्रण पूर्णपणे परस्परविरोधी असेल. वीज कंपनी Christmas ला तुम्हाला card पाठवेल.

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

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

त्या 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

हा uptime अभिमानाचा विषय आहे. म्हणून त्याचा screenshot घेऊन तो post केला जातो. तो screenshot पाहणाऱ्या प्रत्येक attacker ला तो uptime प्रभावी वाटतो. 1,847 दिवसांचा uptime म्हणजे 1,847 दिवसांच्या kernel vulnerabilities. त्या काळात कोणीही patches लागू केलेले नाहीत. Reboot करणे तरी शक्य नाही. Reboot केल्यावर 2021 मध्ये manually सुरू केलेल्या आणि systemd unit मध्ये कधीही नोंद न केलेल्या कोणत्या services आहेत, हे समजते. त्यापैकी कोणत्या services आहेत हे आता कोणालाही आठवत नाही. त्या server वर आता organizational chart मधील महत्त्वाच्या भूमिका अवलंबून आहेत.

साठवण: वेग आणि डेटा गमावण्याचे इतर मार्ग

कार्यक्षमतेसाठी डिस्क RAID 0 मध्ये कॉन्फिगर केल्या आहेत. शून्य हा आकडा निकामी होऊ शकणाऱ्या डिस्कची संख्या दर्शवतो. जास्तीत जास्त परिणामासाठी, वेगवेगळ्या स्रोतांच्या स्टोरेजवर array चे striping करा: दोन योग्य SSD, एक जुना फिरता डिस्क आणि एका परिषदेतून मिळालेली USB stick. या array ची विश्वसनीयता त्या conference stick इतकीच आहे. हीच रचना अपेक्षित आहे.

बॅकअपची जबाबदारी त्याच array वरील backup_final_v2_REAL नावाच्या directory कडे आहे. त्यात मागील naming scheme ची tarball आहे. Off-site backups चे प्रतिनिधित्व “set up off-site backups” असे लिहिलेल्या sticky note ने केले आहे. लॅपटॉपच्या झाकणावर तो note ठेवून तुम्ही तो घरी घेऊन गेल्यावर, तांत्रिकदृष्ट्या तो off-site साठवलेला असतो.

योग्य परिणाम असा दिसतो: df मध्ये usage 97% असल्याचे दाखवते आणि पुढील sprint मध्ये त्यावर उपाय करण्याची योजना असते.

नेटवर्किंग: सर्वकाही जोडणारा एकच धागा

DNS server स्वतः त्या machine वर चालतो. त्यामुळे server बंद पडल्यावर, समस्या का आली हे शोधण्यासाठी वापरायचा DNS record देखील उपलब्ध राहत नाही. याला consolidation म्हणतात.

काहीतरी debug करण्यासाठी 2021 मध्ये firewall तात्पुरता disabled करण्यात आला. Debugging पूर्ण झाले, पण firewall पुन्हा सुरू करण्यात आला नाही. “नंतर वेळ वाचेल” म्हणून router वरील प्रत्येक port server कडे forward केला आहे. सोयीस्कर remote management साठी router चे admin panel WAN side वरून factory password वापरून उघडता येते. तुमच्यासाठी आणि इतरांसाठीही.

अलीकडे server ने नेहमीपेक्षा जास्त उष्णता निर्माण केली आहे; attic मधील परिस्थितीचा विचार केला तरी. top दाखवते की सर्वाधिक व्यस्त process चे नाव xmrig आहे. आपण हे वापरत असलेले monitoring tool असावे असे गृहीत धरतो. ते आपण install केलेले नाही. ports forward केल्यानंतर थोड्याच वेळात ते स्वतःहून दिसू लागले. ecosystem चांगल्या प्रकारे कार्यरत असल्याचे हे चिन्ह आहे असे आपण मानतो. ते दिवसरात्र monitor करते.

वीज consumer power strips च्या साखळीतून येते. त्यांची एकत्रित लांबी breaker panel पर्यंत चालत जाण्याच्या अंतरापेक्षा जास्त आहे. एका अर्थाने ही कार्यक्षम रचना आहे, कारण तुम्हाला breaker panel कडे वारंवार जावे लागेल.

गुंतागुंतीद्वारे redundancy

जिथे redundancy आवश्यक आहे तिथे ती नाकारल्यानंतर, आता जिथे तिची आवश्यकता नाही तिथे ती जोडली आहे. कंपनीचे homepage, म्हणजे एकच static HTML file, बारा-node Kubernetes cluster द्वारे serve केले जाते. यामुळे अभियंते ज्याला resume-driven architecture म्हणतात ते साध्य होते: nginx ने page ज्या चाळीस milliseconds मध्ये serve केले असते, तेवढ्याच वेळात page load होते; पण आता ते अशा प्रकारे fail होऊ शकते की त्यासाठी consultant आवश्यक ठरतो.

Isolation साठी cluster स्वतः एका virtual machine मध्ये असलेल्या virtual machine मध्ये असलेल्या virtual machine मध्ये चालतो. प्रत्येक layer security वाढवते, जशी turducken मधील प्रत्येक layer आणखी एक पक्षी जोडते. Contact form मध्ये नऊ microservices आहेत. त्यांपैकी दोन कधीही invoke झालेले नाहीत. त्यांपैकी कोणती service load-bearing आहे, हे कोणालाही माहीत नाही.

सेवा म्हणून हीटिंग

आधुनिक सर्व्हर वीज वापरून computation आणि उष्णता निर्माण करतो. आम्ही दुसरे output कमाल करण्याचा प्रयत्न करतो. GPU नसलेला media server हा यासाठीचा पारंपरिक पर्याय आहे. CPU वर एका 4K stream चे transcoding केल्यास सोळा cores पूर्ण क्षमतेने वापरले जातात आणि लहान bedroom उबदार होते. चित्रपटही चालवणारा हा space heater असतो. अधिक महत्त्वाकांक्षी operator CPU वर large language model चालवण्याकडे वळतो. API असलेला हा 70-billion-parameter space heater tokens निर्माण करतो. त्याचा वेग ऋतूनुसार मोजावा लागतो.

मॉनिटर स्वतःचे निरीक्षण करते

निरीक्षण महत्त्वाचे आहे. म्हणून आपण स्वतः होस्ट केलेले uptime monitor त्याच सर्व्हरवर तैनात करतो, ज्याचे ते निरीक्षण करते. Odin बंद पडल्यावर मॉनिटरही बंद पडते. यातील महत्त्वाचा भाग असा की कोणतेही alerts सुरू होत नाहीत. Alerts नसतील तर incidents नसतात. Incidents नसतील तर मोजमापानुसार uptime परिपूर्ण असते. मासिक अहवाल यापेक्षा चांगला कधीच दिसलेला नाही.

पूर्णतेसाठी सांगायचे तर alert emails Odin वरच चालणाऱ्या mail server मार्फत relay केले जातात. त्यामुळे alerting pipeline पूर्णपणे self-contained आहे.

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

हा तो विभाग आहे, जो मी आतापर्यंत टाळत आलो आहे. यातील काहीही काल्पनिक नाही. जिव्हाळ्याचा आणि पर्याय नसलेला सर्व्हर, त्याच volume वर backups असलेला RAID 0, “तात्पुरते” disabled केलेले firewall, एकच page serve करणारा Kubernetes cluster आणि स्वतःचेच निरीक्षण करणारा monitor — production मध्ये मी यापैकी प्रत्येक गोष्ट पाहिली आहे. यापैकी काही गोष्टी मी याच वर्षी पाहिल्या आहेत. माझ्या सुरुवातीच्या काळात यापैकी एक-दोन गोष्टी मी स्वतः उभारल्या होत्या.

प्रत्यक्ष efficiency कशी दिसते हे कंटाळवाणे असते. त्यामुळे त्या क्षणी तिचा युक्तिवाद हरतो, पण दशकभरात तोच जिंकतो: एखाद्याने अभियांत्रिकी करून तयार केलेला PUE, ज्याचा तुम्ही कधी विचारही करत नाही. मालकाच्या आत्मप्रतिमेनुसार नव्हे, तर workload नुसार आकारमान ठरवलेली machines. स्फोट होण्यापूर्वी विचारात घेतलेला blast radius. ठरलेल्या वेळापत्रकानुसार restore करून तपासलेले backups; calendar reminder असते, पण heroics करण्याची गरज नसते. साधी आणि कंटाळवाणी redundancy; मी ज्या प्रत्येक failure साठी paged झालो आहे, त्यात प्रत्येक वेळी एक भव्य गोष्ट ठेवण्यापेक्षा दोन स्वस्त गोष्टी अधिक परिणामकारक ठरल्या आहेत.

आणि तुम्ही चालवू शकणारे सर्वात efficient datacenter म्हणजे तुम्ही न चालवलेले datacenter. VPS वीज, cooling, redundancy आणि पहाटे 3 वाजता होणारे hardware failures अशा लोकांकडे सोपवतो, जे हे सर्व मोठ्या प्रमाणावर आणि कंटाळवाण्या पद्धतीने करतात. Infrastructure कडून मिळू शकणारी हीच सर्वोच्च प्रशंसा आहे. त्यामुळे तुमच्याकडे खरोखर आनंद देणारा भाग उरतो: त्यावर स्वतःच्या services चालवणे, अशा machine वर जी गमावणे तुम्हाला परवडू शकते. प्रयोग करण्यासाठी तुम्ही नेहमी अशाच प्रकारची machine वापरली पाहिजे.

FAQ

मी हे प्रत्यक्षात करायलाच हवे का?

नाही. या मार्गदर्शकातील प्रत्येक विभाग हा अनेक सप्ताहांत वाया घालवणारा दस्तऐवजीकृत anti-pattern आहे. तुमची सध्याची रचना दोनपेक्षा अधिक विभागांसारखी दिसत असल्यास, या FAQ मधील शेवटच्या प्रश्नाकडे दिलेल्या क्रमाने जा, कारण हाच triage चा क्रम आहे.

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

Hyperscale datacenter साधारण 1.1 वर चालतात. व्यवस्थित व्यवस्थापित enterprise room मध्ये 1.4 ते 1.6 साध्य होते. योग्य cooling नसलेल्या closet मध्ये space heater मुळे होणारा संघर्ष असल्यास हा आकडा प्रत्यक्षात 3 पेक्षा जास्त जाऊ शकतो. घरच्या घरी 1.1 शी अर्थपूर्ण स्पर्धा करता येत नाही. ज्याच्याकडे ही कार्यक्षमता साध्य करण्याची क्षमता आहे, त्याच्याकडून compute भाड्याने घेण्यामागील हा एक स्पष्ट आर्थिक युक्तिवाद आहे.

सर्व्हरच्या साहाय्याने इमारत गरम करणे ही खरोखरची पद्धत आहे का?

होय, योग्य प्रकारे केल्यास. अनेक देशांतील district-heating प्रकल्प heat exchanger द्वारे datacenter मधील waste heat मिळवतात आणि अभियांत्रिकी नियोजन व करारांच्या आधारे ती पाइपद्वारे घरांपर्यंत पोहोचवतात. वरील उपरोधाचा मुद्दा server heat मुळे खोली गरम होऊ शकते हा नाही. अपघाताने ती गरम करणे आणि त्या अपघाताला strategy म्हणणे हा मुद्दा आहे.

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

आज रात्री backups घ्या. ते server वर नसलेल्या ठिकाणी ठेवा. त्यानंतर test restore करा; चाचणी न केलेला backup म्हणजे केवळ अफवा आहे. दुसरे, patches लागू करा आणि तुम्ही टाळत असलेला reboot नियोजित maintenance window मध्ये करा. त्यामुळे काय बिघडते हे तुम्ही निरीक्षण करत असताना समजेल. तिसरे, single point of failure वेगळा करा: DNS आणि monitoring त्या box बाहेर हलवा. बाकी सर्व गोष्टी शांत आठवड्यापर्यंत थांबू शकतात; या तीन गोष्टी थांबवता येणार नाहीत.