ప్రపంచంలో అత్యంత అసమర్థమైన డేటాసెంటర్‌ను ఎలా నిర్మించాలి

మీరు నిర్మించేది

ఈ సైట్‌లోని ప్రతి గైడ్ ఒక పనిని సరిగ్గా చేయడం నేర్పుతుంది: క్రమంలో ఉన్న commands, సరైన ఫలితం ఎలా కనిపించాలి, పేరుపెట్టిన failure modes. ఈ గైడ్ భిన్నమైనది. ఈ రోజు, పూర్తిగా ఊహాత్మకంగా, డబ్బు, విద్యుత్ మరియు అహంకారం కలిపి తయారు చేయగల అత్యంత అసమర్థమైన datacenter‌ను రూపొందించబోతున్నాం.

మనకు ఒక metric అవసరం. అందుకే పరిశ్రమలో ఉపయోగించే metric‌నే తీసుకుందాం: PUE, Power Usage Effectiveness. ఇది facility మొత్తం power‌ను computing equipment‌కు వాస్తవంగా చేరే power‌తో భాగించిన విలువ. ఒక hyperscale datacenter సాధారణంగా 1.1 చుట్టూ ఉంటుంది. అంటే దాదాపు ప్రతి watt ఉపయోగకరమైన పని చేస్తుంది. మంచి enterprise server room 1.5 సాధిస్తుంది. మన లక్ష్యం 4.0 లేదా అంతకంటే ఎక్కువ. అంటే computing కోసం ఉపయోగించే ప్రతి watt‌కు మరో మూడు watts ఏ ఉపయోగం లేకుండా వృథా అవుతాయి. గంభీరమైన గైడ్‌లు backups‌ను తరచుగా ప్రస్తావించినట్లే, మనం కూడా ఈ సంఖ్యను తరచుగా ప్రస్తావిస్తాం.

సైట్ ఎంపిక: వేడే ప్రధాన విషయం

నిజమైన డేటాసెంటర్‌లో శీతలీకరణే అత్యంత పెద్ద నిర్వహణ వ్యయం. అందుకే మన డేటాసెంటర్ ఉష్ణగతిశాస్త్రాన్ని దాని స్వంత పరిధిలోనే ఎదుర్కొంటుంది. అనువైన స్థలం అటిక్. దక్షిణాభిముఖంగా ఉండాలి. సర్వర్‌పై నేరుగా కాంతి పడేలా స్కైలైట్ ఉంటే మరింత మంచిది. అప్పుడు యంత్రానికి దాని స్వంత వ్యర్థ ఉష్ణంతో పాటు సూర్యుడి ఉష్ణం కూడా అందుతుంది. ఇది మీ విద్యుత్ బిల్లు మరియు ఒక నక్షత్రం కలిసి చేసే పని.

శీతాకాలంలో కిటికీ తెరవడం ద్వారా శీతలీకరణ జరుగుతుంది. నిజమైన డేటాసెంటర్లు కూడా బయట గాలిని ఉపయోగిస్తాయి. ఈ పద్ధతిని free cooling అంటారు. దీనికి ఇంజినీరింగ్ రూపకల్పన, వడపోత మరియు ఆర్ద్రత నియంత్రణ ఉంటాయి. మనం దీన్ని అనుకోకుండా ఉపయోగిస్తాం. వర్షం, పుప్పొడి మరియు ప్రతి త్రైమాసికంలో కనీసం ఒక దారి తప్పిన పక్షిని కూడా లోపలికి అనుమతించే కిటికీ ద్వారా ఇది జరుగుతుంది.

నిజమైన కళాత్మకత కోసం ఒక air conditioner‌ను ఏర్పాటు చేసి, దాని thermostat‌కు రెండు అడుగుల దూరంలో ఒక space heater‌ను ఉంచండి. దాన్ని air conditioner's target కంటే రెండు డిగ్రీలు ఎక్కువగా సెట్ చేయండి. ఇప్పుడు రెండు యంత్రాలు ఎప్పటికీ నిరంతరం నడుస్తాయి. అవి పరిపూర్ణంగా విభేదిస్తూనే ఉంటాయి. విద్యుత్ సంస్థ క్రిస్మస్ సమయంలో మీకు ఒక కార్డు పంపుతుంది.

ఒక server, పెద్దది, ప్రియమైనది

అదనపు వ్యవస్థలు బాధ్యతను పలుచన చేస్తాయి. మా datacenterలో ఖచ్చితంగా ఒక server మాత్రమే ఉంది. అది అపారమైనది. 512 GB RAM ఉన్న ఒకే machine మౌలిక వసతుల్లా అనిపిస్తుంది. నాలుగు చిన్న machineలు చేయాల్సిన పనుల జాబితాలా అనిపిస్తాయి.

ఆ serverకు ఒక పేరు ఉంది. అది hostname కాదు, పేరు. సాధారణంగా Gandalf లేదా Odin. Odinను decommission చేయలేరు. Odin ఐదు సంవత్సరాలుగా upలో ఉంది:

$ 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 అంటే 1,847 రోజుల kernel vulnerabilities. వాటికి ఎవరూ patchలు అమలు చేయలేదు. Reboot చేయడం కూడా సాధ్యం కాదు. Reboot చేస్తే 2021లో చేతితో ప్రారంభించిన, systemd unitలో ఎప్పుడూ నమోదు చేయని services ఏవో బయటపడతాయి. అవి ఏవో ఎవరికీ గుర్తులేదు. ఆ server ఇప్పుడు సంస్థాగత నిర్మాణంలో కీలక ఆధారంగా మారింది.

Storage: వేగం మరియు డేటాను కోల్పోయే ఇతర మార్గాలు

పనితీరు కోసం డిస్క్‌లు RAID 0లో కాన్ఫిగర్ చేయబడ్డాయి. ఇక్కడి zero విఫలమయ్యే డిస్క్‌ల సంఖ్యను సూచిస్తుంది. గరిష్ఠ ప్రభావం కోసం, వేర్వేరు మూలాలున్న storageపై arrayని stripe చేయండి: రెండు నాణ్యమైన SSDలు, ఒక పాత spinner, అలాగే ఒక సదస్సు నుంచి తెచ్చిన USB stick. ఈ array విశ్వసనీయత సదస్సు USB stickంతే ఉంటుంది. ఇదే ఈ రూపకల్పన ఉద్దేశం.

Backupsను అదే arrayలోని backup_final_v2_REAL అనే directory నిర్వహిస్తుంది. ఇందులో మునుపటి naming schemeకు చెందిన tarball ఉంటుంది. Off-site backupsకు బదులుగా "set up off-site backups" అని రాసిన sticky note ఉంది. దాన్ని laptop మూతపై పెట్టుకుని ఇంటికి తీసుకెళ్లినప్పుడు, సాంకేతికంగా అది off-siteలో నిల్వ ఉంటుంది.

సరైన ఫలితం ఇలా ఉంటుంది: df 97% usageని చూపిస్తుంది, దాన్ని తదుపరి sprintలో పరిష్కరించేందుకు ఒక ప్రణాళిక ఉంటుంది.

నెట్‌వర్కింగ్: ప్రతిదానికీ ఒకే ఆధారం

DNS server అదే machineలో నడుస్తుంది. అందువల్ల server down అయినప్పుడు, కారణం తెలుసుకోవడానికి ఉపయోగించే DNS record కూడా అందుబాటులో ఉండదు. దీనిని consolidation అంటారు.

2021లో ఏదో సమస్యను debug చేయడానికి firewallను తాత్కాలికంగా disabled చేశారు. Debugging పూర్తయింది. కానీ firewall మళ్లీ enable కాలేదు. “తర్వాత సమయం ఆదా చేయడానికి” routerలోని ప్రతి portను serverకు forward చేశారు. సౌకర్యవంతమైన remote management కోసం router admin panelను WAN వైపు నుంచి దాని factory passwordతో అందుబాటులో ఉంచారు. మీది మాత్రమే కాదు, ఇతరులది కూడా.

ఇటీవల server అసాధారణంగా వేడిగా నడుస్తోంది. Attic ప్రమాణాలతో చూసినా ఇదే పరిస్థితి. top ప్రకారం అత్యధిక వనరులను ఉపయోగిస్తున్న process పేరు xmrig. ఇది మనం ఉపయోగిస్తున్న monitoring tool అని భావిస్తున్నాం. దీన్ని మనం install చేయలేదు. Ports forward చేసిన కొద్దిసేపటికే ఇది స్వయంగా కనిపించింది. పర్యావరణ వ్యవస్థ చురుకుగా ఉందనడానికి దీనిని సంకేతంగా భావిస్తున్నాం. ఇది రోజుకు 24 గంటలు monitor చేస్తుంది.

విద్యుత్ consumer power strips వరుస ద్వారా వస్తుంది. వాటి మొత్తం పొడవు breaker panel వరకు నడిచే దూరాన్ని మించుతుంది. ఒక అర్థంలో ఇది సమర్థవంతమైనదే, ఎందుకంటే మీరు breaker panelను తరచుగా సందర్శించాల్సి ఉంటుంది.

సంక్లిష్టత ద్వారా పునరావృతం

అవసరమైన చోట పునరావృతాన్ని నిరాకరించిన తర్వాత, అవసరం లేని చోట దాన్ని జోడిస్తున్నాము. కంపెనీ హోమ్‌పేజీని ఒకే static HTML ఫైల్‌గా పన్నెండు-నోడ్ Kubernetes క్లస్టర్ అందిస్తోంది. ఇంజినీర్లు దీనిని resume-driven architecture అని పిలిచే విధానాన్ని ఇది సాధిస్తుంది: nginx అందించగలిగిన అదే నలభై మిల్లీసెకన్లలో పేజీ లోడ్ అవుతుంది, కానీ ఇప్పుడు కన్సల్టెంట్ అవసరమయ్యే విధంగా విఫలమవుతుంది.

వేరుచేయడం కోసం, క్లస్టర్ స్వయంగా ఒక virtual machine లోని virtual machine లోని virtual machine లో నడుస్తుంది. ప్రతి పొర భద్రతను జోడిస్తుంది. turducken లోని ప్రతి పొర పక్షిని జోడించినట్లే ఇది జరుగుతుంది. Contact form తొమ్మిది microservices గా విభజించబడింది. వాటిలో రెండింటిని ఇప్పటివరకు ఎప్పుడూ invoke చేయలేదు. వాటిలో ఒకటి సిస్టమ్‌కు కీలకం, కానీ అది ఏదో ఎవరికీ తెలియదు.

సేవగా వేడి

ఆధునిక server విద్యుత్‌ను computation మరియు వేడిగా మారుస్తుంది. రెండవ output‌ను గరిష్ఠం చేయాలని మేము ఉద్దేశిస్తున్నాము. GPU లేని media server అనేది దీనికి సాంప్రదాయిక ఉదాహరణ. ఒకే 4K stream‌ను CPU-transcoding చేయడం వల్ల పదహారు cores నిరంతరం పూర్తి సామర్థ్యంతో పనిచేస్తాయి. దీంతో చిన్న bedroom వేడెక్కుతుంది. ఇది movies కూడా play చేసే space heater వంటిది. మరింత లక్ష్యసాధన ఉన్న operator CPUపై large language model‌ను అమలు చేయడం వరకు వెళ్తాడు. ఇది API కలిగిన 70-billion-parameter space heater. ఇది tokens‌ను ఉత్పత్తి చేసే వేగాన్ని ఋతువారీగా మాత్రమే కొలవగలరు.

monitor తనను తాను పర్యవేక్షిస్తుంది

పర్యవేక్షణ ముఖ్యం. అందుకే అదే serverలో, ఆ serverనే monitor చేసేలా స్వయంగా హోస్ట్ చేసిన uptime monitorను deploy చేస్తాము. Odin ఆగిపోతే, monitor కూడా దానితోనే ఆగిపోతుంది. ఇందులోని ముఖ్యమైన విషయం ఏమిటంటే: ఎలాంటి alerts పంపబడవు. Alerts లేకపోతే incidents ఉండవు. Incidents లేకపోతే, కొలిచిన ప్రకారం uptime పరిపూర్ణంగా ఉంటుంది. Monthly report ఇంతకుముందెన్నడూ ఇంత మెరుగ్గా కనిపించలేదు.

పూర్తితనం కోసం, alert emailsను Odinపైనే నడుస్తున్న mail server ద్వారా relay చేస్తాము. అందువల్ల alerting pipeline పూర్తిగా అదే serverపై ఆధారపడి ఉంటుంది.

అసౌకర్యకరమైన భాగం

నేను ఇప్పటివరకు వాయిదా వేస్తూ వచ్చిన విభాగం ఇది. ఇందులో ఏదీ కల్పితం కాదు. ఎంతో ప్రియమైన, ప్రత్యామ్నాయం లేని server, అదే volumeలో backups ఉన్న RAID 0, తాత్కాలికంగా firewallని నిలిపివేయడం, ఒకే pageను అందిస్తున్న Kubernetes cluster, తనను తానే monitor చేస్తున్న monitor—ఇవన్నీ productionలో నేను చూశాను. వీటిలో కొన్నింటిని ఈ సంవత్సరమే చూశాను. వాటిలో ఒకటి లేదా రెండింటిని నా ప్రారంభ రోజుల్లో నేనే నిర్మించాను.

నిజమైన efficiency ఎలా ఉంటుందో చూస్తే అది విసుగుగా అనిపిస్తుంది. అందుకే ఆ క్షణంలో అది వాదనలో ఓడిపోతుంది, కానీ ఒక దశాబ్దం తర్వాత గెలుస్తుంది: మరొకరు engineering చేసినందువల్ల మీరు ఎప్పుడూ ఆలోచించనవసరం లేని PUE. యజమాని స్వీయభావనకు కాకుండా తమ workloadకు సరిపోయే పరిమాణంలో ఉన్న machines. పేలుడు సంభవించే ముందే పరిగణించిన blast radius. నిర్దిష్ట schedule ప్రకారం, calendar reminderతో, ఎలాంటి వీరత్వం లేకుండా restore చేసి పరీక్షించే backups. నిస్సారంగా అనిపించే redundancy—ప్రతి సారి, నేను paged అయిన ప్రతి failureలో, ఒక అద్భుతమైన వస్తువు కంటే చవకైన వస్తువులలో రెండు మెరుగైనవి.

మీరు నిర్వహించగల అత్యంత efficient datacenter అంటే మీరు నిర్వహించనిదే. VPS power, cooling, redundancy, అలాగే తెల్లవారుజామున 3 గంటలకు జరిగే hardware failuresను scaleలో, నిరంతరంగా నిర్వహించే వ్యక్తులకు అప్పగిస్తుంది. Infrastructure పొందగలిగే అత్యున్నత ప్రశంస ఇదే. దాంతో నిజంగా ఆసక్తికరమైన భాగం మీకు మిగులుతుంది—మీరు మీ స్వంత servicesను దాని పైన అమలు చేయడం. మీరు కోల్పోయినా భరించగలిగే machineపై మాత్రమే ఇలా చేయాలి. మీరు ప్రయోగాలు చేయాల్సింది ఎప్పుడూ అలాంటి machineపైనే.

FAQ

నేను నిజంగా ఇవన్నీ చేయాలా?

లేదు. ఈ మార్గదర్శకంలోని ప్రతి విభాగం, వారాంతాలను వృథా చేసినట్లు నమోదైన ఒక తప్పు విధానం. మీ ప్రస్తుత అమరిక రెండు విభాగాలకంటే ఎక్కువగా దీనిని పోలి ఉంటే, ఇచ్చిన క్రమంలో ఈ FAQలోని చివరి ప్రశ్నకు వెళ్లండి. ఆ క్రమమే ప్రాథమిక సమస్యా పరిష్కార క్రమం.

వాస్తవానికి మంచి PUE ఎంత?

హైపర్‌స్కేల్ డేటాసెంటర్లు సుమారు 1.1 వద్ద పనిచేస్తాయి. సమర్థంగా నిర్వహించే ఎంటర్‌ప్రైజ్ గది 1.4 నుంచి 1.6 వరకు సాధిస్తుంది. శీతలీకరణ లేని చిన్న గదిలో space heaterతో వేడి విషయంలో పోటీ పడితే, ఈ విలువ నిజంగా 3ని మించవచ్చు. ఇంటి వద్ద 1.1తో అర్థవంతంగా పోటీ చేయలేరు. అందుకే compute సామర్థ్యాన్ని అందించగల వ్యక్తి లేదా సంస్థ నుంచి అద్దెకు తీసుకోవడం ఆర్థికంగా సమంజసం.

సర్వర్లతో భవనాన్ని వేడి చేయడం నిజంగా సాధ్యమేనా?

అవును, సరిగ్గా చేస్తే. అనేక దేశాల్లోని district-heating ప్రాజెక్టులు heat exchangers ద్వారా datacenterలో ఉత్పత్తయ్యే అదనపు వేడిని సేకరించి, engineering రూపకల్పన మరియు ఒప్పందాల ఆధారంగా, పైపుల ద్వారా ఇళ్లకు పంపిస్తాయి. సర్వర్ వేడితో గదిని వేడి చేయడం అసాధ్యమని పై వ్యంగ్యం చెప్పడం లేదు. అది అనుకోకుండా జరిగి, ఆ అనుకోని పరిస్థితినే వ్యూహంగా ప్రకటించడమే సమస్య.

నా server ఇప్పటికే ఇలాగే ఉంది. నేను ముందుగా ఏమి చేయాలి?

ఈ రాత్రే backups తీసుకోండి. వాటిని serverలో కాకుండా వేరే ప్రదేశంలో నిల్వ చేయండి. తర్వాత test restore చేయండి. పరీక్షించని backup కేవలం ఒక వదంతి. రెండవది, మీరు వాయిదా వేస్తున్న patchesను అమలు చేసి, reboot చేయండి. ఇందుకోసం ప్రణాళికాబద్ధమైన maintenance windowను ఉపయోగించండి. మీరు గమనిస్తుండగానే ఏది విఫలమవుతుందో అప్పుడు తెలుస్తుంది. మూడవది, single point of failureను తొలగించండి: DNS మరియు monitoringను ఆ box నుంచి బయటకు మార్చండి. మిగతావన్నీ మరింత ప్రశాంతమైన వారానికి వాయిదా వేయవచ్చు. ఈ మూడు మాత్రం వాయిదా వేయకూడదు.