paano gumawa ng pinaka-inefficient na datacenter

Ang iyong bubuuin

Ang bawat guide sa site na ito ay nagtuturo ng tamang paraan: ang mga command sa tamang pagkakasunod-sunod, ang itsura ng tamang resulta, at ang pagtukoy sa mga failure modes. Iba ang guide na ito. Ngayon, sa paraang hypothetical, ididisenyo natin ang pinaka-inefficient na datacenter na kayang gawin ng pera, kuryente, at hubris.

Kailangan natin ng metric, kaya gagamitin natin ang standard ng industry: PUE, Power Usage Effectiveness — ang total facility power na hinati sa power na talagang umaabot sa computing equipment. Ang isang hyperscale datacenter ay tumatakbo sa paligid ng 1.1: halos bawat watt ay may kapaki-pakinabang na trabaho. Ang isang maayos na enterprise server room ay may 1.5. Ang target natin ay 4.0 o mas mataas, na nangangahulugang para sa bawat watt ng computing, may tatlong watt pang nasasayang. Madalas nating babanggitin ang numerong ito, gaya ng pagbanggit ng mga seryosong guide sa backups.

Site selection: heat ang punto

Ang cooling ang pinakamalaking overhead sa isang totoong datacenter, kaya ang atin ay lalaban sa thermodynamics sa mismong teritoryo nito. Ang ideal na lokasyon ay isang attic. South-facing. Mas mainam kung may skylight na nakatutok nang direkta sa server, para ang makina ay makatanggap ng sarili nitong waste heat at ang init mula sa araw—isang kolaborasyon sa pagitan ng iyong electricity bill at ng isang bituin.

Sa winter, ang cooling ay ginagawa sa pamamagitan ng pagbubukas ng bintana. Ang mga totoong datacenter ay gumagamit din ng outside air — ang technique na ito ay tinatawag na free cooling, at ito ay engineered, filtered, at may humidity control. Gagamitin natin ito nang hindi sinasadya, sa pamamagitan ng bintanang nagpapasok din ng ulan, pollen, at hindi bababa sa isang naliligaw na ibon bawat quarter.

Para sa tunay na artistry, mag-install ng air conditioner, pagkatapos ay maglagay ng space heater na dalawang talampakan ang layo mula sa thermostat nito, na naka-set nang mas mainit ng dalawang degree kaysa sa target ng air conditioner. Ang dalawang makina ay tatakbo na ngayon nang tuluy-tuloy, habambuhay, sa perpektong hindi pagkakaunawaan. Magpapadala sa iyo ang power company ng card tuwing Pasko.

Isang server, malaki, mahal

Ang redundancy ay nagpapahina sa commitment. Ang ating datacenter ay may eksaktong isang server, at ito ay napakalaki, dahil ang isang makina na may 512 GB ng RAM ay parang infrastructure, samantalang ang apat na maliliit na makina ay parang to-do list lang.

Ang server ay may pangalan. Hindi hostname — kundi isang pangalan. Gandalf, kadalasan, o Odin. Hindi mo maaaring i-decommission ang Odin. Ang Odin ay up na sa loob ng limang taon:

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

Ang numerong iyan ay isang point of pride, kaya naman ini-screenshot mo ito at pino-post, at kung bakit ang bawat attacker na makakakita ng screenshot ay hahanga rin dito: ang 1,847 days na uptime ay nangangahulugang 1,847 days ng kernel vulnerabilities na hindi pa na-papatched ng kahit sino. Hindi naman opsyon ang pag-reboot — sa reboot mo malalaman kung aling mga services ang manual na sinimulan noong 2021 at hindi naisulat sa isang systemd unit. Walang nakakaalala kung alin ang mga iyon. Ang server ay naging load-bearing na sa organizational chart.

Storage: bilis, at iba pang paraan para mawala ang data

Ang mga disk ay naka-configure sa RAID 0, para sa performance. Ang zero ay tumutukoy sa bilang ng mga disk na maaaring mag-fail. Para sa maximum effect, i-stripe ang array sa storage na may magkakaibang pinagmulan: dalawang maayos na SSD, isang lumang spinner, at isang USB stick mula sa isang conference. Ang array ay kasing-reliable lang ng conference stick, na siyang design.

Ang mga backup ay pinapatakbo ng isang directory sa parehong array na may pangalang backup_final_v2_REAL, na naglalaman ng tarball ng nakaraang naming scheme. Ang mga off-site backup ay kinakatawan ng isang sticky note na may nakasulat na "set up off-site backups," na, sa teknikal na aspeto, ay naka-store off-site kapag dinala mo ito sa bahay sa takip ng iyong laptop.

Ang tamang resulta ay: df na nagre-report ng 97% usage, at isang plano kung paano ito haharapin sa susunod na sprint.

Networking: isang strand ng lahat

Ang DNS server ay tumatakbo sa mismong makina, para kapag nag-down ang server, kasama nitong mawawala ang DNS record na gagamitin mo para malaman kung bakit. Ito ay tinatawag na consolidation.

Ang firewall ay na-disable noong 2021 — pansamantala, para mag-debug ng isang bagay. Natapos ang debugging; hindi na bumalik ang firewall. Ang bawat port sa router ay naka-forward sa server "para makatipid sa oras mamaya," at ang admin panel ng router ay ma-a-access mula sa WAN side gamit ang factory password nito, para sa convenient na remote management. Para sa iyo, at sa iba pa.

Ang server ay nagiging sobrang init na nitong mga nakaraang araw, kahit sa mga attic standards, at ipinapakita ng top na ang pinaka-busy na process ay isang bagay na tinatawag na xmrig. Ipinapalagay natin na ito ang monitoring tool na ginagamit natin. Hindi natin ito in-install — lumitaw ito nang kusa matapos i-forward ang mga port, na itinuturing nating senyales na ang ecosystem ay lumalago. Nagmo-monitor ito nang 24/7.

Ang power ay dumating sa pamamagitan ng isang chain ng mga consumer power strip na ang kabuuang haba ay mas mahaba pa kaysa sa layo patungo sa breaker panel — na efficient, sa isang banda, dahil madalas kang pupunta sa breaker panel.

Redundancy sa pamamagitan ng complexity

Dahil tinanggihan ang redundancy kung saan ito mahalaga, magdadagdag tayo nito kung saan hindi ito kailangan. Ang homepage ng kumpanya — isang static HTML file — ay pinapatakbo ng isang twelve-node Kubernetes cluster. Nagagawa nito ang tinatawag ng mga engineer na resume-driven architecture: ang page ay naglo-load sa parehong 40 milliseconds na ibibigay sana ng nginx, pero maaari na itong mag-fail sa mga paraang nangangailangan ng consultant.

Para sa isolation, ang cluster mismo ay tumatakbo sa loob ng isang virtual machine sa loob ng isang virtual machine sa loob ng isang virtual machine, kung saan ang bawat layer ay nagdadagdag ng security gaya ng bawat layer ng isang turducken na nagdadagdag ng ibon. Ang contact form ay binubuo ng siyam na microservices. Dalawa sa mga ito ay hindi pa kailanman nagamit. Ang isa sa mga ito ay load-bearing at walang nakakaalam kung alin.

Heating as a service

Ang isang modernong server ay nagko-convert ng kuryente tungo sa computation at init, at layunin nating i-maximize ang pangalawang output na ito. Ang isang media server na walang GPU ay ang classic na diskarte: ang CPU-transcoding ng isang 4K stream ay magpapagana sa labing-anim na cores at magpapainit sa isang maliit na bedroom, isang space heater na nagpe-play din ng mga movie. Ang mga ambisyosong operator ay lumilipat sa pagpapatakbo ng isang large language model sa CPU — isang 70-billion-parameter space heater na may API, na naglalabas ng mga token sa bilis na mas mainam sukatin nang seasonal.

Ang monitor ay nagbabantay sa sarili nito

Mahalaga ang observability, kaya mag-deploy tayo ng isang self-hosted uptime monitor — sa mismong server na binabantayan nito. Kapag namatay ang Odin, mamamatay din ang monitor kasama nito, at narito ang eleganteng bahagi: walang alerts na magti-trigger. Walang alerts ay nangangahulugang walang incidents. Walang incidents ay nangangahulugang perfect uptime, ayon sa sukat. Ang monthly report ay hindi pa naging ganito kaganda.

Ang mga alert email, para sa completeness, ay ipinapasa sa pamamagitan ng isang mail server na tumatakbo din sa Odin. Ang alerting pipeline ay ganap na self-contained, gaya ng isang ahas na kinakain ang sarili nitong buntot.

Ang hindi komportableng bahagi

Ito ang section na matagal ko nang ipinagpapaliban. Ang lahat ng ito ay hindi fiction. Ang mahal at hindi mapapalitang server, ang RAID 0 na may backups sa parehong volume, ang firewall na na-disable nang "pansamantala," ang Kubernetes cluster na nagpapatakbo ng isang page, ang monitor na nagbabantay sa sarili nito — nakita ko na ang lahat ng ito sa production. Ang ilan sa mga ito ay nakita ko ngayong taon. Ang isa o dalawa sa mga ito, noong nagsisimula pa lang ako, ay ako mismo ang bumuo.

Ang hitsura ng tunay na efficiency ay boring, kaya naman natatalo nito ang argumento sa sandaling iyon ngunit nananalo sa loob ng isang dekada: isang PUE na hindi mo na iniisip dahil may ibang engineer na gumawa nito. Mga makina na ang laki ay akma sa workload sa halip na sa self-image ng may-ari. Isang blast radius, na isinasaalang-alang bago ang pagsabog. Mga backup na sinusubukan sa pamamagitan ng pag-restore sa mga ito, sa isang schedule, na may calendar reminder at walang heroism. Redundancy na boring — ang dalawang murang bagay ay mas mabuti kaysa sa isang dakilang bagay, sa bawat pagkakataon, sa bawat failure na tinawagan ako.

At ang pinaka-efficient na datacenter na maaari mong patakbuhin ay ang hindi mo pinapatakbo. Ang isang VPS ang humahawak sa power, cooling, redundancy, at mga hardware failure sa madaling araw para sa mga taong gumagawa nito nang malawakan at boring, na siyang pinakamataas na papuri na maaaring makuha ng infrastructure — at iniiwan nito sa iyo ang tunay na masayang bahagi, ang pagpapatakbo ng sarili mong mga services sa ibabaw nito, sa isang makina na kaya mong mawala, na siyang tanging uri na dapat mong subukan.

FAQ

Dapat ko bang gawin ang alinman sa mga ito?

Hindi. Ang bawat section ng guide na ito ay isang documented anti-pattern na kumitil ng maraming weekend. Kung ang kasalukuyan mong setup ay katulad ng higit sa dalawang section, tumalon na sa huling tanong sa FAQ na ito — ayon sa pagkakasunod-sunod, dahil ang pagkakasunod-sunod na iyon ang triage.

Ano ang magandang PUE, sa katunayan?

Ang mga hyperscale datacenter ay tumatakbo sa paligid ng 1.1, ang isang maayos na enterprise room ay may 1.4 hanggang 1.6, at ang isang walang cooling na closet na may space heater feud ay maaaring lumampas sa 3. Hindi ka maaaring makipagsabayan sa 1.1 sa bahay, na siyang tahimik na economic argument para mag-renta ng compute mula sa mga taong kaya itong gawin.

Totoo bang nagpapainit ng gusali gamit ang mga server?

Oo — kung gagawin nang tama. Ang mga district-heating project sa ilang mga bansa ay kumukuha ng waste heat mula sa datacenter sa pamamagitan ng mga heat exchanger at ipinapasok ito sa mga tahanan, sa pamamagitan ng disenyo, engineering, at mga kontrata. Ang satire sa itaas ay hindi tungkol sa kakayahan ng init ng server na magpainit ng kwarto; ito ay tungkol sa paggawa nito nang hindi sinasadya at pagtawag sa aksidenteng iyon bilang isang estratehiya.

Mukha na ang server ko sa ganito. Ano ang una kong gagawin?

Backups, ngayong gabi, sa isang lugar na hindi ang server, at pagkatapos ay isang test restore — ang isang untested na backup ay isang sabi-sabi lang. Pangalawa, mga patch at ang reboot na iniiwasan mo, sa isang nakaplano na window, para matutunan mo kung ano ang masisira habang nagmamasid ka. Pangatlo, paghiwalayin ang single point of failure: ilipat ang DNS at monitoring palabas sa box. Ang lahat ng iba pa ay maaaring maghintay sa mas kalmadong linggo; ang tatlong iyan ay hindi maaaring maghintay.