Gabay sa Pinaka-Hindi Episyenteng Datacenter

Ang ginagawa mo

Itinuturo ng bawat guide sa site na ito kung paano gawin nang tama ang isang bagay: ang tamang pagkakasunod-sunod ng mga command, ang hitsura ng tamang resulta, at ang mga failure mode na tinukoy. Naiiba ang guide na ito. Ngayon, ganap na hypothetically, magdidisenyo tayo ng pinaka-hindi episyenteng datacenter na kayang likhain ng pera, kuryente, at labis na kumpiyansa sa sarili.

Kailangan natin ng metric, kaya hihiramin natin ang ginagamit mismo ng industriya: PUE, o Power Usage Effectiveness—ang kabuuang power ng facility na hinati sa power na aktuwal na nakararating sa computing equipment. Karaniwang nasa 1.1 ang PUE ng hyperscale datacenter: halos bawat watt ay gumagawa ng kapaki-pakinabang na trabaho. Nakakamit naman ng maayos na enterprise server room ang 1.5. Ang target natin ay 4.0 o mas mataas, na nangangahulugang sa bawat watt para sa computing, may tatlo pang watt na nasasayang. Madalas nating babanggitin ang numerong ito, gaya ng ginagawa ng mga seryosong guide kapag pinag-uusapan ang backups.

Pagpili ng lokasyon: init ang layunin

Ang cooling ang pinakamalaking overhead sa isang totoong datacenter, kaya lalaban ang atin sa thermodynamics sa mismong pinagmulan nito. Ang ideal na lokasyon ay attic. Nakaharap sa timog. Mas mainam kung may skylight na nakaposisyon para direktang tumama ang liwanag sa server, upang matanggap ng machine ang sarili nitong waste heat at ang init ng araw—isang pagtutulungan ng electricity bill mo at ng isang bituin.

Sa taglamig, ginagawa ang cooling sa pamamagitan ng pagbubukas ng bintana. Gumagamit nga ng outside air ang mga totoong datacenter; free cooling ang tawag sa technique na ito, at ito ay engineered, filtered, at kinokontrol ang humidity. Gagamitin natin ito nang hindi sinasadya, sa pamamagitan ng bintanang nagpapapasok din ng ulan, pollen, at kahit isang nalilitong ibon bawat quarter.

Para sa tunay na artistry, mag-install ng air conditioner, pagkatapos ay maglagay ng space heater dalawang talampakan mula sa thermostat nito, at itakda ito nang dalawang degree na mas mainit kaysa sa target ng air conditioner. Patuloy na tatakbo ang dalawang machine, magpakailanman, sa perpektong hindi pagkakasundo. Padadalhan ka ng power company ng card tuwing Pasko.

Isang server, malaki at minamahal

Pinapalabnaw ng redundancy ang commitment. Eksaktong isang server ang nasa datacenter namin, at napakalaki nito, dahil ang isang machine na may 512 GB ng RAM ay parang tunay na infrastructure, samantalang ang apat na maliit na machine ay parang listahan lang ng mga kailangang gawin.

May pangalan ang server. Hindi hostname, kundi pangalan. Karaniwan, Gandalf o Odin. Hindi mo maaaring i-decommission si Odin. Limang taon nang tumatakbo si Odin:

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

Ipinagmamalaki ang numerong iyon. Kaya kino-screenshot mo ito at ipinopost, at kaya napapansin din ito ng bawat attacker na nakakakita ng screenshot: ang 1,847 araw na uptime ay nangangahulugang 1,847 araw ng mga kernel vulnerability na walang nag-patch. Hindi rin puwedeng mag-reboot, dahil sa reboot mo matutuklasan kung aling mga service ang mano-manong sinimulan noong 2021 at hindi kailanman isinulat sa isang systemd unit. Walang nakakaalala kung alin ang mga iyon. Ngayon, bahagi na ang server ng organizational chart na hindi maaaring mawala.

Storage: bilis at iba pang paraan para mawalan ng data

Naka-configure ang mga disk sa RAID 0 para sa performance. Tinutukoy ng zero ang bilang ng mga disk na maaaring mag-fail. Para sa maximum na epekto, i-stripe ang array sa storage na magkakaiba ang pinagmulan: dalawang maayos na SSD, isang lumang hard disk, at isang USB stick mula sa isang conference. Ang reliability ng array ay eksaktong kapareho ng sa conference stick, at iyon ang disenyo.

Hinahawakan ang mga backup ng isang directory sa parehong array na may pangalang backup_final_v2_REAL. Naglalaman ito ng tarball ng dating naming scheme. Ang mga off-site backup ay kinakatawan ng isang sticky note na may nakasulat na "set up off-site backups." Sa teknikal na paraan, naka-store ito off-site kapag inuuwi mo ito sa takip ng laptop.

Ganito ang hitsura ng tamang resulta: df na nag-uulat ng 97% usage, at isang planong haharap dito sa susunod na sprint.

Networking: isang hibla ng lahat

Tumatakbo ang DNS server sa mismong machine, kaya kapag bumagsak ang server, kasama nitong mawawala ang DNS record na gagamitin mo sana para alamin kung bakit ito bumagsak. Ang tawag dito ay consolidation.

Na-disable ang firewall noong 2021, pansamantala, para mag-debug ng isang problema. Natapos ang pag-debug, pero hindi naibalik ang firewall. Ipinapasa ang bawat port sa router papunta sa server “para makatipid ng oras sa hinaharap,” at naaabot ang admin panel ng router mula sa WAN side gamit ang factory password, para maginhawa ang remote management. Sa iyo at sa iba.

Kamakailan ay hindi karaniwang umiinit ang server, kahit ayon sa pamantayan ng attic, at ipinapakita ng top na ang pinakabusy na process ay ang tinatawag na xmrig. Ipinapalagay nating ito ang monitoring tool na ginagamit natin. Hindi natin ito na-install; kusang lumitaw ito di-nagtagal matapos ipasa ang mga port, na itinuturing nating palatandaang umuunlad ang ecosystem. Patuloy itong nagmo-monitor buong maghapon at buong magdamag.

Dumadaan ang kuryente sa magkakasunod na consumer power strip na ang pinagsamang haba ay higit pa sa distansiyang lalakarin papunta sa breaker panel. Sa isang paraan, mahusay ito dahil madalas kang pupunta sa breaker panel.

Redundancy sa pamamagitan ng complexity

Matapos iwasan ang redundancy kung saan ito mahalaga, idinadagdag naman natin ito kung saan hindi ito kailangan. Ang homepage ng kumpanya, na isang static HTML file lamang, ay sine-serve ng isang twelve-node Kubernetes cluster. Nakakamit nito ang tinatawag ng mga engineer na resume-driven architecture: naglo-load ang page sa parehong forty milliseconds na kakailanganin ng nginx, ngunit maaari na itong mag-fail sa mga paraang nangangailangan ng consultant.

Para sa isolation, tumatakbo ang cluster mismo sa loob ng isang virtual machine na nasa loob ng isa pang virtual machine na nasa loob ng isa pang virtual machine, kung saan bawat layer ay nagdaragdag ng security. Ang contact form ay binubuo ng siyam na microservice. Dalawa sa mga ito ay hindi pa kailanman nagamit. May isang load-bearing, ngunit walang nakaaalam kung alin.

Pag-init bilang serbisyo

Kino-convert ng modern server ang kuryente bilang computation at init, at layunin nating i-maximize ang pangalawang output. Ang media server na walang GPU ang klasikong setup: ang CPU transcoding ng isang 4K stream ay maaaring gumamit ng lahat ng labing-anim na core at magpainit ng maliit na kuwarto—isang space heater na nakakapag-play din ng mga pelikula. Ang mas ambisyosong operator ay lumilipat sa pagpapatakbo ng malaking language model sa CPU, isang space heater na may 70-billion parameter at API, na gumagawa ng mga token sa bilis na mas praktikal sukatin ayon sa panahon.

Ang monitor ay nagmo-monitor sa sarili nito

Mahalaga ang observability, kaya nag-deploy kami ng self-hosted uptime monitor sa parehong server na mino-monitor nito. Kapag bumagsak ang Odin, bumabagsak din ang monitor kasama nito, at narito ang eleganteng bahagi: walang alert na naipapadala. Kapag walang alert, walang incident. Kapag walang incident, perpekto ang uptime ayon sa naitala. Hindi pa naging ganito kaganda ang monthly report.

Para kumpleto, ipinapasa ang alert email sa isang mail server na tumatakbo rin sa Odin. Kaya ganap na self-contained ang alerting pipeline, na para bang kumpleto ang pagpapakain ng isang ahas na kinakain ang sarili nitong buntot.

Ang hindi komportableng bahagi

Narito ang seksyong matagal kong ipinagpapaliban. Wala sa mga ito ang kathang-isip. Ang minamahal at hindi mapapalitang server, ang RAID 0 na may backups sa parehong volume, ang firewall na “pansamantalang” naka-disable, ang Kubernetes cluster na isang page lang ang sini-serve, at ang monitor na sarili nito ang mino-monitor—nakita ko ang bawat isa sa mga ito sa production. May ilan sa mga ito akong nakita ngayong taon. Isa o dalawa sa mga ito ang ako mismo ang nag-build noong bago pa ako sa larangan.

Nakababagot ang aktuwal na hitsura ng efficiency. Kaya natatalo ito sa argumento sa mismong sandali, pero nananalo paglipas ng isang dekada: isang PUE na hindi mo na kailangang isipin dahil may ibang nag-engineer nito. Mga machine na sinukat ayon sa workload ng mga ito, hindi ayon sa imaheng nais ng owner ng mga ito tungkol sa sarili niya. Isang blast radius na pinag-isipan bago mangyari ang pagsabog. Mga backup na sinusubukan sa pamamagitan ng pag-restore sa mga ito, ayon sa iskedyul, may calendar reminder, at walang kailangang magpakabayani. Redundancy na nakababagot—mas mabuti ang dalawang murang bagay kaysa sa isang pambihirang bagay, sa bawat pagkakataon at sa bawat failure na tinawagan ako para ayusin.

At ang pinaka-efficient na datacenter na maaari mong patakbuhin ay ang hindi mo pinapatakbo. Ipinauubaya ng isang VPS ang power, cooling, redundancy, at mga hardware failure sa ganap na alas-3 ng umaga sa mga taong gumagawa nito sa malaking scale at sa nakababagot na paraan. Ito ang pinakamataas na papuri na maaaring matanggap ng infrastructure. Naiiiwan sa iyo ang talagang nakakatuwang bahagi: pagpapatakbo ng sarili mong mga serbisyo sa ibabaw nito, sa isang machine na kaya mong mawala, na siya lamang ang uri ng machine na dapat mong pag-eksperimentuhan.

FAQ

Dapat ko ba talagang gawin ang alinman dito?

Hindi. Ang bawat seksyon ng gabay na ito ay isang dokumentadong anti-pattern na kumitil na ng maraming weekend. Kung kahawig ng kasalukuyan mong setup ang higit sa dalawang seksyon, dumiretso sa huling tanong sa FAQ na ito at sundin ang ibinigay na pagkakasunod-sunod, dahil iyon ang triage.

Ano ba talaga ang magandang PUE?

Karaniwang nasa 1.1 ang PUE ng hyperscale datacenter, nasa 1.4 hanggang 1.6 naman sa maayos na enterprise server room, at maaaring lumampas talaga sa 3 sa isang hindi naka-air-condition na closet na may space heater. Hindi mo makabuluhang matutumbasan sa bahay ang 1.1, kaya makatuwirang mag-rent ng compute mula sa provider na kayang makamit iyon.

Totoo bang ginagamit ang mga server para magpainit ng gusali?

Oo, kung maayos ang pagpapatupad. Sa mga district-heating project sa ilang bansa, kinokolekta ang waste heat ng datacenter gamit ang heat exchanger at ipinapadala ito sa mga tahanan sa pamamagitan ng mga tubo, ayon sa maayos na disenyo, engineering, at mga kontrata. Ang satire sa itaas ay hindi tungkol sa kakayahan ng server heat na magpainit ng isang silid; ang punto ay ginagawa ito nang hindi sinasadya at tinatawag na strategy ang aksidenteng iyon.

Ganito na ang hitsura ng server ko. Ano ang una kong gagawin?

Backup, ngayong gabi, sa lokasyong hindi ang server, at pagkatapos ay magsagawa ng test restore. Ang backup na hindi pa nasusubukan ay sabi-sabi lamang. Ikalawa, mag-install ng patches at isagawa ang reboot na matagal mo nang iniiwasan, sa isang planadong maintenance window, para makita mo kung ano ang masisira habang mino-monitor mo ito. Ikatlo, hatiin ang single point of failure: ilipat ang DNS at monitoring sa ibang system. Maaaring ipagpaliban ang lahat ng iba pa hanggang sa mas kalmadong linggo; hindi maaaring ipagpaliban ang tatlong ito.