மிகக் குறைந்த திறன் கொண்ட Datacenter-ஐ உருவாக்குவது

நீங்கள் உருவாக்குவது என்ன

இந்தத் தளத்தில் உள்ள ஒவ்வொரு வழிகாட்டியும் ஒரு செயலைச் சரியாகச் செய்வதைக் கற்பிக்கிறது: கட்டளைகளின் வரிசை, சரியான முடிவு எப்படி இருக்கும், மற்றும் தோல்விக்கான காரணங்கள் ஆகியவை அதில் விளக்கப்படும். இந்த வழிகாட்டி மாறுபட்டது. இன்று, முற்றிலும் கற்பனையாக, பணம், மின்சாரம் மற்றும் ஆணவம் ஆகியவற்றால் உருவாக்கக்கூடிய மிகக் குறைந்த திறன் கொண்ட தரவு மையத்தை (datacenter) வடிவமைக்கப் போகிறோம்.

இதற்கு ஒரு அளவீடு தேவை, எனவே தொழில்துறையின் அளவீடான PUE-ஐ (Power Usage Effectiveness) எடுத்துக்கொள்வோம். இது மொத்த மின்சார வசதியின் பயன்பாட்டை, கணினி உபகரணங்களுக்குச் சென்றடையும் மின்சாரத்தால் வகுப்பதன் மூலம் கணக்கிடப்படுகிறது. ஒரு hyperscale தரவு மையம் சுமார் 1.1 PUE-ல் இயங்குகிறது: அதாவது ஒவ்வொரு வாட் மின்சாரமும் பயனுள்ள வேலைக்குச் செலவிடப்படுகிறது. ஒரு நல்ல enterprise server room 1.5 PUE-ஐ நிர்வகிக்கிறது. நமது இலக்கு 4.0 அல்லது அதற்கு மேல்; அதாவது, கணினி வேலைக்காகச் செலவிடப்படும் ஒவ்வொரு வாட் மின்சாரத்திற்கும், கூடுதலாக மூன்று வாட் மின்சாரம் வீணாகிறது. தீவிரமான வழிகாட்டிகள் எப்படி backups-ஐக் குறிப்பிடுவார்களோ, அதேபோல நாமும் இந்த எண்ணை அடிக்கடி குறிப்பிடுவோம்.

தளத்தைத் தேர்ந்தெடுத்தல்: வெப்பமே முதன்மை நோக்கம்

ஒரு உண்மையான datacenter-ல் cooling-க்குத்தான் அதிக செலவாகிறது. எனவே, நமது அமைப்பில் வெப்ப இயக்கவியலை (thermodynamics) அதன் சொந்த களத்திலேயே எதிர்கொள்வோம். இதற்கு attic (மாடி அறை) மிகச்சிறந்த இடம். அது தெற்கு நோக்கி இருக்க வேண்டும். skylight வழியாக சூரிய ஒளி நேரடியாக server-ன் மீது படுமாறு அமைப்பது சிறந்தது. இது உங்கள் மின்சாரக் கட்டணத்தையும் சூரியனின் வெப்பத்தையும் ஒன்றிணைத்து, server-க்கு கூடுதல் வெப்பத்தை வழங்கும்.

குளிர்காலத்தில், ஜன்னலைத் திறந்து வைப்பதன் மூலம் cooling-ஐக் கையாளலாம். உண்மையான datacenter-கள் வெளியிலிருந்து காற்றைப் பயன்படுத்துகின்றன; இந்த நுட்பம் free cooling என்று அழைக்கப்படுகிறது. இது முறையாக வடிவமைக்கப்பட்டு, வடிகட்டப்பட்டு, ஈரப்பதம் கட்டுப்படுத்தப்பட்டிருக்கும். நாம் இதைத் தற்செயலாகச் செய்வோம்; இதன் மூலம் மழை, மகரந்தம் மற்றும் ஒவ்வொரு காலாண்டிற்கும் ஒரு பறவை என அனைத்தும் உள்ளே வரும்.

உண்மையான கலைநயத்துடன் செயல்பட, ஒரு air conditioner-ஐ நிறுவுங்கள். அதன் thermostat-க்கு இரண்டு அடி தொலைவில் ஒரு space heater-ஐ வையுங்கள். heater-ன் வெப்பநிலையை air conditioner-ன் இலக்கை விட 2 டிகிரி அதிகமாக வையுங்கள். இப்போது இரண்டு இயந்திரங்களும் எப்போதும், இடைவிடாமல், ஒன்றுக்கொன்று முரணாக இயங்கும். மின்சார நிறுவனம் உங்களுக்குக் கிறிஸ்துமஸ் வாழ்த்து அட்டையை அனுப்பும்.

ஒரே server, பிரம்மாண்டமானது, விருப்பத்திற்குரியது

Redundancy என்பது அர்ப்பணிப்பைக் குறைக்கும். எங்கள் datacenter-ல் ஒரே ஒரு server மட்டுமே உள்ளது, அது பிரம்மாண்டமானது. ஏனெனில் 512 GB RAM கொண்ட ஒரு இயந்திரம் உள்கட்டமைப்பாகத் தெரிகிறது, ஆனால் நான்கு சிறிய இயந்திரங்கள் ஒரு செய்ய வேண்டிய வேலைகளின் பட்டியலாகவே (to-do list) தெரிகிறது.

இந்த 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 எடுத்துப் பகிர்கிறீர்கள். அதைப் பார்க்கும் ஒவ்வொரு தாக்குதல் நடத்துபவருக்கும் அது வியப்பாகவே இருக்கும்: 1,847 நாட்கள் uptime என்பது 1,847 நாட்களாக kernel vulnerabilities எவராலும் சரிசெய்யப்படவில்லை என்று அர்த்தம். எப்படியும் reboot செய்வது சாத்தியமில்லை. 2021-ல் கையால் தொடங்கப்பட்டு, systemd unit-ல் எழுதப்படாத services எவை என்பதை reboot செய்த பிறகுதான் கண்டறிய முடியும். அவை எவை என்பது யாருக்கும் நினைவில்லை. இப்போது இந்த server நிறுவனத்தின் கட்டமைப்பு வரைபடத்தில் ஒரு முக்கிய ஆதாரமாக உள்ளது.

சேமிப்பகம்: வேகம் மற்றும் தரவுகளை இழப்பதற்கான பிற வழிகள்

செயல்திறனுக்காக வட்டுகள் RAID 0 முறையில் கட்டமைக்கப்பட்டுள்ளன. இதில் உள்ள '0' என்பது தோல்வியடையக்கூடிய வட்டுகளின் எண்ணிக்கையைக் குறிக்கிறது. அதிகபட்ச விளைவைப் பெற, வெவ்வேறு மூலங்களைக் கொண்ட சேமிப்பகங்களில் இந்த array-ஐ stripe செய்யவும்: இரண்டு தரமான SSD-கள், ஒரு பழைய HDD, மற்றும் ஒரு மாநாட்டில் வழங்கப்பட்ட USB stick ஆகியவற்றை இணைக்கவும். இந்த array-ன் நம்பகத்தன்மை அந்த USB stick-ன் நம்பகத்தன்மைக்கு சமமானது; இதுவே இதன் வடிவமைப்பு.

காப்புப்பிரதிகள் (backups) அதே array-ல் உள்ள backup_final_v2_REAL என்ற கோப்பகத்தால் கையாளப்படுகின்றன; இதில் முந்தைய பெயரிடும் முறையின்படி உருவாக்கப்பட்ட tarball உள்ளது. வெளியூர் காப்புப்பிரதிகள் (off-site backups) "set up off-site backups" என்று எழுதப்பட்ட ஒரு sticky note மூலம் குறிக்கப்படுகின்றன. நீங்கள் அதை உங்கள் laptop மூடியில் ஒட்டி வீட்டிற்கு எடுத்துச் செல்லும்போது, தொழில்நுட்ப ரீதியாக அது வெளியூர் சேமிப்பகமாக மாறுகிறது.

சரியான முடிவு என்பது இதுதான்: df 97% பயன்பாட்டைக் காட்டுகிறது, மேலும் அதை அடுத்த sprint-ல் கையாள்வதற்கான ஒரு திட்டம் உங்களிடம் உள்ளது.

Networking: அனைத்தையும் உள்ளடக்கிய ஒற்றை அமைப்பு

DNS server அந்த machine-லேயே இயங்குகிறது. எனவே server செயலிழக்கும்போது, அது ஏன் செயலிழந்தது என்பதைக் கண்டறிய உதவும் DNS record-ம் அதனுடன் சேர்ந்து செயலிழந்துவிடும். இதற்கு consolidation என்று பெயர்.

Firewall 2021-ல் தற்காலிகமாக debug செய்வதற்காக முடக்கப்பட்டது. Debugging முடிந்த பிறகும், firewall மீண்டும் இயக்கப்படவில்லை. "பிற்காலத்தில் நேரத்தை மிச்சப்படுத்த" router-ல் உள்ள அனைத்து port-களும் server-க்கு forward செய்யப்பட்டுள்ளன. மேலும், வசதியான remote management-க்காக router-ன் admin panel, அதன் factory password-உடன் WAN பக்கத்திலிருந்து அணுகக்கூடிய வகையில் உள்ளது. இது உங்களுக்கும், மற்றவர்களுக்கும் பொருந்தும்.

Server சமீபகாலமாக வழக்கத்திற்கு மாறாக அதிக வெப்பத்துடன் இயங்குகிறது, attic-ன் வெப்பநிலையை கணக்கில் கொண்டாலும் இது அதிகம். top-ல் பார்க்கும்போது, அதிகப்படியான சுமையைக் கொடுக்கும் process xmrig என்று காட்டுகிறது. இது நாம் பயன்படுத்தும் monitoring tool என்று கருதுகிறோம். இதை நாம் நிறுவவில்லை; port-கள் forward செய்யப்பட்ட சிறிது நேரத்திலேயே இது தானாகவே தோன்றியது. இது அந்த ecosystem செழிப்பாக இருப்பதற்கான அறிகுறியாகக் கருதுகிறோம். இது 24 மணி நேரமும் கண்காணிப்பில் ஈடுபடுகிறது.

மின்சாரம் பல consumer power strips வழியாக வருகிறது. அவற்றின் மொத்த நீளம், breaker panel-க்குச் செல்லும் தூரத்தை விட அதிகம். ஒரு வகையில் இது திறமையானது, ஏனெனில் நீங்கள் அடிக்கடி breaker panel-க்குச் செல்ல வேண்டியிருக்கும்.

சிக்கலான தன்மையின் மூலம் தேவையற்ற redundancy

முக்கியமான இடங்களில் redundancy-ஐத் தவிர்த்துவிட்டு, இப்போது தேவையற்ற இடங்களில் அதைச் சேர்க்கிறோம். நிறுவனத்தின் முகப்புப் பக்கம், ஒரு static HTML கோப்பு, பன்னிரண்டு-node கொண்ட Kubernetes cluster மூலம் வழங்கப்படுகிறது. இது பொறியாளர்கள் 'resume-driven architecture' என்று அழைக்கும் நிலையை அடைகிறது: nginx வழங்கிய அதே 40 மில்லி விநாடிகளில் பக்கம் லோட் ஆகிறது, ஆனால் இப்போது ஒரு ஆலோசகரின் உதவி தேவைப்படும் வகையில் இது செயலிழக்கக்கூடும்.

தனிமைப்படுத்தலுக்காக (isolation), இந்த cluster-ஆனது ஒரு virtual machine-க்குள் மற்றொரு virtual machine, அதற்குள் இன்னொன்று என இயங்குகிறது. ஒவ்வொரு அடுக்கிலும் பாதுகாப்பு சேர்க்கப்படுவது, ஒரு turducken-ல் ஒவ்வொரு அடுக்கிலும் பறவை சேர்க்கப்படுவது போன்றது. தொடர்பு படிவம் (contact form) ஒன்பது microservices-களைக் கொண்டது. அவற்றில் இரண்டு இதுவரை ஒருமுறை கூட அழைக்கப்பட்டதில்லை. அவற்றில் ஒன்று சுமையைத் தாங்குகிறது (load-bearing), ஆனால் அது எது என்று யாருக்கும் தெரியாது.

Heating as a service

நவீன server ஒன்று மின்சாரத்தை கணக்கீடுகளாகவும் வெப்பமாகவும் மாற்றுகிறது. நாம் இந்த இரண்டாவது வெளியீட்டை அதிகப்படுத்த விரும்புகிறோம். GPU இல்லாத media server என்பது இதற்கான ஒரு சிறந்த எடுத்துக்காட்டு: ஒரு 4K stream-ஐ CPU மூலம் transcoding செய்யும்போது, அது பதினாறு cores-ஐயும் முழுமையாகப் பயன்படுத்தி ஒரு சிறிய அறையை வெப்பமாக்கும்; இது திரைப்படங்களை இயக்கும் ஒரு space heater போலச் செயல்படும். ஆர்வமுள்ள நிர்வாகிகள் CPU-வில் பெரிய language model-ஐ இயக்குவதை அடுத்த கட்டமாக மேற்கொள்வார்கள்; இது 70-billion-parameter கொண்ட ஒரு space heater போலச் செயல்பட்டு, API மூலம் tokens-ஐ வெளியிடும். இதன் வேகத்தை பருவ கால அடிப்படையில் அளவிடுவதே பொருத்தமானது.

கண்காணிப்பு கருவி தன்னைத்தானே கண்காணித்தல்

Observability மிக முக்கியமானது, எனவே self-hosted uptime monitor ஒன்றை அது கண்காணிக்கும் அதே server-ல் நிறுவுகிறோம். Odin செயலிழக்கும்போது, கண்காணிப்பு கருவியும் அதனுடன் சேர்ந்து செயலிழந்துவிடும். இதில் உள்ள நுணுக்கம் என்னவென்றால்: எந்த எச்சரிக்கையும் (alerts) அனுப்பப்படாது. எச்சரிக்கைகள் இல்லை என்றால், சம்பவங்களும் (incidents) இல்லை. சம்பவங்கள் இல்லை என்றால், அளவீட்டின்படி uptime மிகச்சிறப்பாக இருக்கும். மாதாந்திர அறிக்கை எப்போதும் இல்லாத அளவுக்கு சிறப்பாக இருக்கும்.

முழுமைக்காக, எச்சரிக்கை மின்னஞ்சல்கள் Odin-ல் இயங்கும் ஒரு mail server வழியாக அனுப்பப்படுகின்றன. எனவே, எச்சரிக்கை அனுப்பும் pipeline முழுமையாக அந்த server-க்குள்ளேயே இயங்குகிறது; இது தனது வாலையே தானே உண்ணும் பாம்பைப் போல, தனக்குத்தானே உணவளித்துக் கொள்கிறது.

சங்கடமான உண்மை

இப்பகுதியை எழுதுவதைத் தான் நான் தள்ளிப்போட்டுக் கொண்டிருந்தேன். இதில் எதுவும் கற்பனையல்ல. மாற்றீடு செய்ய முடியாத அன்பிற்குரிய server, ஒரே volume-ல் backup எடுக்கப்பட்ட RAID 0, "தற்காலிகமாக" முடக்கப்பட்ட firewall, ஒரே ஒரு பக்கத்தை மட்டும் காட்டும் Kubernetes cluster, தன்னைத்தானே கண்காணிக்கும் monitor என இவை அனைத்தையும் production சூழலில் நான் பார்த்திருக்கிறேன். இதில் சிலவற்றை இந்த ஆண்டிலேயே பார்த்தேன். ஒன்று அல்லது இரண்டை, எனது ஆரம்ப காலங்களில் நானே உருவாக்கியிருக்கிறேன்.

உண்மையான செயல்திறன் என்பது சலிப்பூட்டும் விஷயம். அதனால்தான் அந்தந்த தருணத்தில் அது தோற்று, ஒரு தசாப்த கால அளவில் வெற்றி பெறுகிறது. மற்றவர் வடிவமைத்ததால் நீங்கள் ஒருபோதும் கவலைப்படத் தேவையில்லாத PUE, உரிமையாளரின் அகங்காரத்திற்கு ஏற்ப அல்லாமல், பணிச்சுமைக்கு ஏற்ப அளவிடப்பட்ட இயந்திரங்கள், வெடிப்பு நிகழும் முன்பே கணிக்கப்பட்ட பாதிப்பு எல்லை (blast radius), வீரதீரச் செயல்கள் இன்றி, காலண்டர் நினைவூட்டலுடன் திட்டமிட்டு, restore செய்து சோதிக்கப்படும் backup-கள், சலிப்பூட்டும் வகையிலான redundancy என இவைதான் அவை. நான் இதுவரை கையாண்ட அனைத்து தோல்விகளிலும், ஒரு விலையுயர்ந்த பொருளை விட, இரண்டு மலிவான பொருட்கள் எப்போதும் சிறந்ததாகவே இருந்திருக்கின்றன.

நீங்கள் நிர்வகிக்கும் மிகச்சிறந்த datacenter என்பது, நீங்கள் நிர்வகிக்காத ஒன்றுதான். ஒரு VPS, மின்சாரம், குளிர்விப்பு, redundancy மற்றும் அதிகாலை 3 மணிக்கு ஏற்படும் வன்பொருள் கோளாறுகளை, அதைச் சிறப்பாகச் செய்யும் நபர்களிடம் ஒப்படைக்கிறது. இது உள்கட்டமைப்பிற்கு அளிக்கக்கூடிய மிக உயர்ந்த பாராட்டு. இது உங்களுக்கு உண்மையான சுவாரஸ்யமான பகுதியை விட்டுச் செல்கிறது, அதுதான் அதன் மேல் உங்கள் சொந்த சேவைகளை இயக்குவது. இழக்கத் துணியக்கூடிய ஒரு இயந்திரத்தில் மட்டுமே நீங்கள் பரிசோதனைகளைச் செய்ய வேண்டும்.

FAQ

நான் உண்மையில் இதையெல்லாம் செய்ய வேண்டுமா?

வேண்டாம். இந்த வழிகாட்டியின் ஒவ்வொரு பகுதியும் ஆவணப்படுத்தப்பட்ட ஒரு anti-pattern ஆகும், இது பல வார இறுதி நாட்களை வீணடிக்கும் தன்மை கொண்டது. உங்கள் தற்போதைய அமைப்பு இரண்டுக்கும் மேற்பட்ட பகுதிகளைப் போல இருந்தால், இந்த FAQ-வின் கடைசி கேள்விக்குச் செல்லுங்கள். கொடுக்கப்பட்ட வரிசையிலேயே செல்லுங்கள், ஏனெனில் அந்த வரிசைதான் முன்னுரிமை அடிப்படையில் அமைக்கப்பட்ட triage ஆகும்.

உண்மையில் ஒரு நல்ல PUE என்றால் என்ன?

Hyperscale datacenters சுமார் 1.1 PUE-ல் இயங்குகின்றன, நன்கு நிர்வகிக்கப்படும் நிறுவன அறைகள் 1.4 முதல் 1.6 வரை பராமரிக்கின்றன, மேலும் குளிரூட்டப்படாத ஒரு சிறிய அறையில் space heater-ஐப் பயன்படுத்தினால் அது 3-ஐத் தாண்டக்கூடும். வீட்டில் உங்களால் 1.1-ஐ எட்டுவது சாத்தியமற்றது, இதனால்தான் compute வசதியை மற்றவர்களிடமிருந்து வாடகைக்கு எடுப்பது பொருளாதார ரீதியாகச் சிறந்தது.

server-களைக் கொண்டு ஒரு கட்டிடத்தை வெப்பப்படுத்துவது உண்மையான விஷயமா?

ஆம், சரியாகச் செய்தால் இது சாத்தியம். பல நாடுகளில் உள்ள district-heating திட்டங்கள், datacenter-ல் இருந்து வெளியேறும் வெப்பத்தை heat exchangers மூலம் சேகரித்து, பொறியியல் மற்றும் ஒப்பந்தங்களின் அடிப்படையில் வீடுகளுக்குக் குழாய் மூலம் அனுப்புகின்றன. மேலே உள்ள கிண்டல், server வெப்பம் ஒரு அறையை வெப்பப்படுத்தும் என்பது பற்றியது அல்ல; மாறாக, தற்செயலாக நடக்கும் ஒரு விஷயத்தை ஒரு திட்டமிட்ட உத்தியாகக் கருதுவதுதான் தவறு.

எனது server ஏற்கனவே இப்படித்தான் உள்ளது. நான் முதலில் என்ன செய்ய வேண்டும்?

இன்றிரவே, server அல்லாத வேறொரு இடத்திற்குத் தரவுகளை backup செய்யுங்கள். பிறகு, ஒரு test restore செய்யுங்கள்; சோதிக்கப்படாத backup என்பது வெறும் வதந்தி மட்டுமே. இரண்டாவதாக, நீங்கள் தவிர்த்து வரும் patches மற்றும் reboot-ஐ ஒரு திட்டமிட்ட நேரத்தில் செய்யுங்கள், அப்போதுதான் எதனால் பாதிப்பு ஏற்படுகிறது என்பதை உங்களால் கண்காணிக்க முடியும். மூன்றாவதாக, single point of failure-ஐப் பிரியுங்கள்: DNS மற்றும் monitoring-ஐ அந்த server-லிருந்து வெளியேற்றுங்கள். மற்ற அனைத்தும் அமைதியான வாரம் வரும் வரை காத்திருக்கலாம்; ஆனால் இந்த மூன்றையும் தவிர்க்க முடியாது.