Mwongozo wa datacenter isiyofaa kabisa duniani

Unachojenga

Kila mwongozo kwenye tovuti hii unakufundisha kufanya jambo kwa usahihi: amri kwa mpangilio, jinsi matokeo sahihi yanavyoonekana, na hali za kushindwa zilizopewa majina. Mwongozo huu ni tofauti. Leo, kwa dhana tu, tutabuni datacenter isiyofaa kabisa ambayo fedha, umeme na kiburi vinaweza kuzalisha.

Tunahitaji kipimo, kwa hiyo tutatumia kipimo cha sekta yenyewe: PUE, Power Usage Effectiveness, yaani jumla ya power ya facility ikigawanywa kwa power inayofikia vifaa vya computing. Hyperscale datacenter huwa karibu 1.1: karibu kila watt hufanya kazi yenye manufaa. Chumba kizuri cha servers cha enterprise hufikia 1.5. Lengo letu ni 4.0 au zaidi, kumaanisha kwamba kwa kila watt ya computing, watts nyingine tatu zinapotea bila sababu. Tutaitaja nambari hii mara nyingi, kama miongozo ya kitaalamu inavyotaja backups.

Uchaguzi wa eneo: joto ndilo lengo

Cooling ndiyo gharama kubwa zaidi ya uendeshaji katika datacenter halisi. Ndiyo sababu yetu itapambana na thermodynamics kwenye mazingira yake halisi. Eneo linalofaa ni attic. Lielekee kusini. Ikiwezekana, liwe na skylight iliyowekwa ili mwanga uangaze moja kwa moja kwenye server. Hivyo machine itapokea waste heat yake pamoja na joto la jua. Huu ni ushirikiano kati ya bili yako ya umeme na nyota.

Wakati wa winter, cooling inashughulikiwa kwa kufungua dirisha. Datacenter halisi hutumia hewa ya nje. Mbinu hiyo huitwa free cooling, na huundwa kwa engineering, huchujwa, na hudhibitiwa humidity yake. Sisi tutaitumia bila kukusudia kupitia dirisha ambalo pia huruhusu mvua, pollen, na angalau ndege mmoja aliyechanganyikiwa kila baada ya miezi mitatu.

Kwa ustadi wa hali ya juu, install air conditioner, kisha weka space heater umbali wa futi mbili kutoka thermostat yake, na uweke target yake iwe juu kwa nyuzi 2 kuliko target ya air conditioner. Machines zote mbili sasa zitaendelea kufanya kazi bila kukoma, milele, zikiwa hazikubaliani kikamilifu. Kampuni ya umeme itakutumia kadi wakati wa Christmas.

Seva moja, kubwa, inayopendwa sana

Redundancy hupunguza kujitolea. Kituo chetu cha data kina seva moja tu, nayo ni kubwa sana, kwa sababu mashine moja yenye 512 GB za RAM huhisi kama miundombinu, ilhali mashine nne ndogo huhisi kama orodha ya kazi za kufuatilia.

Seva ina jina. Si hostname, bali jina. Kwa kawaida ni Gandalf au Odin. Huwezi kuiondoa Odin kwenye matumizi. Odin imekuwa ikifanya kazi kwa miaka mitano:

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

Nambari hiyo ni sababu ya kujivunia. Ndiyo maana unapiga screenshot yake na kuichapisha. Pia kila mshambuliaji anayeiona screenshot hiyo huona nambari hiyo kuwa ya kuvutia: uptime ya siku 1,847 inamaanisha siku 1,847 za udhaifu wa kernel ambao hakuna aliyefanyia patch. Reboot haiwezi kufikiriwa hata hivyo. Reboot ndiyo njia ya kugundua ni huduma zipi zilianzishwa kwa mkono mwaka 2021 na hazikuwahi kuandikwa kwenye systemd unit. Hakuna anayezikumbuka. Sasa seva hiyo ni tegemeo muhimu katika muundo wa shirika.

Hifadhi: kasi na njia nyingine za kupoteza data

Diski zimeundwa katika RAID 0 kwa ajili ya utendaji. Nambari sifuri inarejelea idadi ya diski zinazoweza kushindwa. Kwa athari ya juu zaidi, sambaza array kwenye hifadhi zenye asili tofauti: SSD mbili zinazofanya kazi vizuri, diski moja ya zamani inayozunguka, na USB stick kutoka kwenye mkutano. Array ina utegemezi sawa kabisa na USB stick ya mkutano; huo ndio muundo uliokusudiwa.

Backup zinashughulikiwa na directory kwenye array hiyo hiyo inayoitwa backup_final_v2_REAL, ambayo ina tarball ya mfumo wa awali wa majina. Backup za off-site zinawakilishwa na sticky note iliyoandikwa "set up off-site backups." Kwa maana ya kiufundi, sticky note hiyo huhifadhiwa off-site unapoenda nayo nyumbani ikiwa imebandikwa kwenye kifuniko cha laptop yako.

Matokeo sahihi yanaonekana hivi: df inaripoti matumizi ya 97%, pamoja na mpango wa kushughulikia hali hiyo katika sprint inayofuata.

Mtandao: uzi mmoja unaounganisha kila kitu

Seva ya DNS inaendeshwa kwenye mashine yenyewe. Kwa hiyo, seva inapozimika, rekodi ya DNS unayotumia kutafuta sababu ya tatizo pia haipatikani. Hali hii huitwa consolidation.

Firewall ilizimwa mwaka wa 2021 kwa muda ili kuchunguza tatizo fulani. Uchunguzi uliisha, lakini firewall haikuwashwa tena. Kila port kwenye router imeelekezwa kwenye seva “ili kuokoa muda baadaye,” na paneli ya usimamizi ya router inapatikana kutoka upande wa WAN kwa kutumia nenosiri lake la kiwandani, kwa ajili ya usimamizi wa mbali. Yako, na ya wengine.

Hivi karibuni seva imekuwa na joto la juu isivyo kawaida, hata kwa viwango vya dari. top inaonyesha kuwa process inayotumia rasilimali nyingi zaidi ni kitu kinachoitwa xmrig. Tunadhani hiki ni kifaa cha monitoring tunachotumia. Hatukukisakinisha. Kilijitokeza chenyewe muda mfupi baada ya ports kuelekezwa, jambo tunalolichukulia kuwa ishara kwamba mfumo unaendelea vizuri. Kinafanya monitoring saa zote.

Umeme unafika kupitia mfululizo wa power strips za matumizi ya kawaida. Urefu wake wote unazidi umbali wa kutembea hadi kwenye paneli ya circuit breaker. Kwa maana fulani, hii ni yenye ufanisi, kwa sababu utatembelea paneli hiyo mara kwa mara.

Uratibu wa ziada kupitia ugumu

Baada ya kukataa redundancy pale inapohitajika, sasa tunaiongeza pale ambapo haihitajiki. Ukurasa wa mwanzo wa kampuni, faili moja ya HTML tuli, unatolewa na Kubernetes cluster yenye nodes kumi na mbili. Hii hutimiza kile ambacho wahandisi hukiita resume-driven architecture: ukurasa unapakia kwa milliseconds arobaini zilezile ambazo nginx ingetumia kuutuma, lakini sasa unaweza kushindwa kwa njia zinazohitaji consultant.

Kwa ajili ya isolation, cluster yenyewe inaendeshwa ndani ya virtual machine ndani ya virtual machine ndani ya virtual machine, huku kila layer ikiongeza security kama vile kila layer ya turducken inavyoongeza ndege. Contact form ina microservices tisa. Mbili kati yake hazijawahi kuitwa. Moja ndiyo inayobeba mfumo, na hakuna anayejua ni ipi.

Kupasha joto kama huduma

Seva ya kisasa hubadilisha umeme kuwa uchakataji na joto, na tunalenga kuongeza uzalishaji wa pili. Seva ya media isiyotumia GPU ndiyo njia ya kawaida: kufanya transcoding ya mkondo mmoja wa 4K kwa CPU kunaweza kushikilia cores kumi na sita katika matumizi ya juu na kupasha joto chumba kidogo cha kulala; ni heater ya nafasi inayocheza pia filamu. Mwendeshaji mwenye malengo makubwa zaidi huendelea hadi kuendesha large language model kwenye CPU, heater ya nafasi yenye parameters bilioni 70 na API, inayozalisha tokens kwa kasi inayofaa kupimwa kwa misimu.

Monitor hufuatilia yenyewe

Observability ni muhimu, kwa hiyo tunapeleka monitor ya uptime inayojihudumia, kwenye seva hiyo hiyo inayofuatiliwa. Odin inapokufa, monitor pia hufa pamoja nayo, na hapa ndipo sehemu ya kuvutia ilipo: hakuna alerts zinazotumwa. Hakuna alerts, hakuna incidents. Hakuna incidents, uptime huwa kamilifu, kulingana na vipimo. Ripoti ya kila mwezi haijawahi kuonekana bora zaidi.

Kwa ukamilifu, barua pepe za alerts hupitishwa kupitia mail server inayotumika pia kwenye Odin. Kwa hiyo, pipeline ya alerting inajitegemea kikamilifu, kwa njia ambayo mfumo unaojilisha wenyewe huonekana kuwa umeshiba kikamilifu.

Sehemu isiyofurahisha

Hii ndiyo sehemu ambayo nimekuwa nikiahirisha. Hakuna kitu hapa ni cha kubuniwa. Seva inayopendwa na isiyoweza kubadilishwa, RAID 0 yenye backups kwenye volume hiyo hiyo, firewall iliyozimwa “kwa muda,” Kubernetes cluster inayohudumia ukurasa mmoja, monitor inayojifuatilia yenyewe—nimeona kila moja ya hali hizi kwenye production. Baadhi nimeziona mwaka huu. Moja au mbili kati yake nilizijenga katika siku zangu za mwanzo.

Ufanisi halisi unaonekana wa kawaida, ndiyo maana hushindwa kwenye mjadala wa wakati huo lakini hushinda baada ya miaka 10: PUE ambayo huitafakari kamwe kwa sababu mtu mwingine aliisanifu. Mashine zilizopimwa kulingana na workload yake badala ya taswira ya mmiliki wake kujihusu. Blast radius iliyozingatiwa kabla ya mlipuko. Backups zinazojaribiwa kwa kuzirestore, kwa ratiba maalumu, kwa kutumia ukumbusho wa kalenda na bila kutegemea ushujaa. Redundancy isiyosisimua; vitu viwili vya bei nafuu ni bora kuliko kitu kimoja cha hali ya juu, kila mara, katika kila failure ambayo nimewahi kuitwa kushughulikia.

Na datacenter yenye ufanisi zaidi unayoweza kuendesha ni ile ambayo huiendeshi. VPS huwapa watu wanaofanya kazi hiyo kwa kiwango kikubwa, kwa utaratibu wa kawaida, majukumu ya umeme, cooling, redundancy na hardware failures za saa 3 asubuhi. Hiyo ndiyo pongezi kubwa zaidi ambayo infrastructure inaweza kupata. Pia hukuachia sehemu inayofurahisha kwa kweli, ambayo ni kuendesha huduma zako mwenyewe juu yake, kwenye mashine ambayo unaweza kumudu kuipoteza; kwa sababu hilo ndilo aina pekee ya mashine unayopaswa kuifanyia majaribio.

FAQ

Je, kwa kweli nifanye lolote kati ya haya?

Hapana. Kila sehemu ya mwongozo huu inaeleza anti-pattern iliyoandikwa, ambayo imetumia wikendi nyingi za watu. Ikiwa usanidi wako wa sasa unafanana na zaidi ya sehemu mbili, nenda moja kwa moja kwenye swali la mwisho la FAQ kwa mpangilio uliotolewa, kwa sababu mpangilio huo ndiyo triage.

PUE nzuri ni ipi hasa?

Datacenter za hyperscale huwa karibu na 1.1, chumba cha enterprise kinachosimamiwa vizuri hufikia 1.4 hadi 1.6, na kabati lisilopozwa lenye heater ya chumba inaweza kwa kweli kuzidi 3. Huwezi kushindana kwa maana na 1.1 ukiwa nyumbani. Hii ndiyo hoja ya kiuchumi isiyotamkwa ya kukodisha compute kutoka kwa mtu anayeweza kufikia ufanisi huo.

Je, kupasha jengo kwa kutumia server ni jambo halisi?

Ndiyo, likifanywa kwa njia sahihi. Miradi ya district heating katika nchi kadhaa hukusanya waste heat ya datacenter kupitia heat exchanger na kuipeleka kwenye nyumba kwa mabomba, kwa usanifu uliopangwa, uhandisi na mikataba. Satire iliyo hapo juu si kwamba joto la server haliwezi kupasha chumba. Tatizo ni kulifanya kwa bahati mbaya na kuita ajali hiyo mkakati.

Server yangu tayari inaonekana hivi. Nianze kufanya nini?

Fanya backups usiku wa leo, zihifadhi mahali pasipo kwenye server, kisha fanya test restore. Backup ambayo haijawahi kujaribiwa ni uvumi. Pili, sakinisha patches na ufanye reboot ambayo umekuwa ukiiahirisha, katika muda uliopangwa, ili ujue kitakachoharibika ukiwa unaangalia. Tatu, gawanya single point of failure: hamisha DNS na monitoring kutoka kwenye server hiyo. Kila kitu kingine kinaweza kusubiri wiki yenye utulivu zaidi; mambo hayo matatu hayawezi.