Sa isa sa mga chat ay tinanong ako ng isang katanungan:
β Mayroon ba akong mababasa tungkol sa kung paano maayos na i-pack ang mga server sa mga rack?
Napagtanto ko na hindi ko alam ang ganoong text, kaya sinulat ko ang sarili ko.
Una, ang tekstong ito ay tungkol sa mga pisikal na server sa mga pisikal na data center (DC). Pangalawa, naniniwala kami na napakaraming server: daan-daang-libo; para sa isang mas maliit na bilang ay walang kahulugan ang tekstong ito. Pangatlo, isinasaalang-alang namin na mayroon kaming tatlong mga hadlang: pisikal na espasyo sa mga rack, power supply sa bawat rack, at hayaan ang mga rack na nakatayo sa mga hilera upang magamit namin ang isang switch ng ToR upang ikonekta ang mga server sa mga katabing rack.
Ang sagot sa tanong ay lubos na nakasalalay sa kung anong parameter ang aming ino-optimize at kung ano ang maaari naming pag-iba-iba upang makamit ang pinakamahusay na resulta. Halimbawa, kailangan lang nating kumuha ng isang minimum na espasyo upang mag-iwan ng higit pa para sa karagdagang paglago. O marahil ay mayroon tayong kalayaan sa pagpili ng taas ng mga rack, kapangyarihan sa bawat rack, mga socket sa PDU, ang bilang ng mga rack sa isang grupo ng mga switch (isang switch para sa 1, 2 o 3 rack), haba ng mga wire at trabaho sa paghila ( kritikal ito sa mga dulo ng mga hilera: na may 10 rack sa isang hilera at 3 rack bawat switch, kakailanganin mong hilahin ang mga wire sa isa pang hilera o hindi gaanong gamitin ang mga port sa switch), atbp., atbp. Paghiwalayin ang mga kwento: pagpili ng mga server at pagpili ng mga DC, ipagpalagay namin na napili ang mga ito.
Mainam na maunawaan ang ilan sa mga nuances at detalye, lalo na, ang average/maximum na pagkonsumo ng mga server, at kung paano ibinibigay sa amin ang kuryente. Kaya, kung mayroon tayong Russian power supply na 230V at isang phase sa bawat rack, kung gayon ang isang 32A machine ay maaaring humawak ng ~7kW. Sabihin nating nagbabayad tayo ng 6kW bawat rack. Kung sinusukat ng provider ang aming pagkonsumo para lamang sa isang hilera ng 10 rack, at hindi para sa bawat rack, at kung ang makina ay nakatakda sa isang kondisyon na 7 kW cutoff, kung gayon sa teknikal na paraan maaari kaming kumonsumo ng 6.9 kW sa isang rack, 5.1 kW sa isa pa at magiging ok ang lahat - hindi mapaparusahan.
Karaniwan ang aming pangunahing layunin ay upang mabawasan ang mga gastos. Ang pinakamahusay na criterion na susukatin ay ang pagbawas sa TCO (kabuuang halaga ng pagmamay-ari). Binubuo ito ng mga sumusunod na piraso:
- CAPEX: pagbili ng imprastraktura ng DC, mga server, hardware ng network at paglalagay ng kable
- OPEX: Pagrenta ng DC, pagkonsumo ng kuryente, pagpapanatili. Ang OPEX ay nakasalalay sa buhay ng serbisyo. Makatuwirang ipagpalagay na ito ay 3 taon.
Depende sa kung gaano kalaki ang mga indibidwal na piraso sa kabuuang pie, kailangan nating i-optimize ang pinakamahal, at hayaan ang iba na gamitin ang lahat ng natitirang mapagkukunan nang mahusay hangga't maaari.
Sabihin nating mayroon kaming kasalukuyang DC, mayroong taas ng rack ng H unit (halimbawa, H=47), kuryente sa bawat rack Prack (Prack=6kW), at nagpasya kaming gumamit ng h=2U na dalawang-unit na server. Aalisin namin ang 2..4 na unit mula sa rack para sa mga switch, patch panel at organizer. Yung. pisikal, mayroon kaming Sh=rounddown((H-2..4)/h) server sa aming rack (ibig sabihin, Sh = rounddown((47-4)/2)=21 server bawat rack). Tandaan natin itong Sh.
Sa simpleng kaso, ang lahat ng mga server sa isang rack ay magkapareho. Sa kabuuan, kung pupunuin natin ang isang rack ng mga server, kung gayon sa bawat server ay maaari nating gastusin sa average ang power Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Para sa pagiging simple, hindi namin binabalewala ang pagkonsumo ng switch dito.
Tumabi tayo at alamin kung ano ang pinakamataas na pagkonsumo ng server na Pmax. Kung ito ay napaka-simple, napaka-hindi epektibo at ganap na ligtas, pagkatapos ay basahin namin kung ano ang nakasulat sa power supply ng server - ito na.
Kung ito ay mas kumplikado at mas mahusay, pagkatapos ay kukunin namin ang TDP (thermal design package) ng lahat ng mga bahagi at ibuod ito (ito ay hindi masyadong totoo, ngunit ito ay posible).
Kadalasan hindi namin alam ang TDP ng mga bahagi (maliban sa CPU), kaya kinukuha namin ang pinaka tama, ngunit din ang pinaka kumplikadong diskarte (kailangan namin ng laboratoryo) - kumuha kami ng isang eksperimentong server ng kinakailangang pagsasaayos at i-load ito, halimbawa, sa Linpack (CPU at memory) at fio (disks) , sinusukat namin ang pagkonsumo. Kung seryosohin natin ito, kailangan din nating lumikha ng pinakamainit na kapaligiran sa malamig na koridor sa panahon ng mga pagsubok, dahil makakaapekto ito sa pagkonsumo ng fan at pagkonsumo ng CPU. Nakukuha namin ang maximum na pagkonsumo ng isang partikular na server na may partikular na configuration sa mga partikular na kundisyong ito sa ilalim ng partikular na pag-load na ito. Ang ibig lang naming sabihin ay maaaring makaapekto sa resulta ang bagong firmware ng system, ibang bersyon ng software, at iba pang kundisyon.
Kaya, bumalik sa Pserv at kung paano namin ito ihahambing sa Pmax. Ito ay isang bagay ng pag-unawa sa kung paano gumagana ang mga serbisyo at kung gaano kalakas ang nerbiyos ng iyong teknikal na direktor.
Kung wala kaming anumang mga panganib, naniniwala kami na ang lahat ng mga server ay maaaring sabay na magsimulang kumonsumo ng kanilang maximum. Kasabay nito, maaaring mangyari ang isang input sa DC. Kahit sa ilalim ng mga kundisyong ito, ang infra ay dapat magbigay ng serbisyo, kaya Pserv β‘ Pmax. Ito ay isang diskarte kung saan ang pagiging maaasahan ay talagang mahalaga.
Kung ang tech director ay nag-iisip hindi lamang tungkol sa perpektong seguridad, kundi pati na rin sa pera ng kumpanya at sapat na matapang, maaari kang magpasya na
- Nagsisimula kaming pamahalaan ang aming mga vendor, lalo na, ipinagbabawal namin ang naka-iskedyul na pagpapanatili sa mga oras ng nakaplanong peak load upang mabawasan ang pagbaba sa isang input;
- at/o pinapayagan ka ng aming arkitektura na mawalan ng rack/row/DC, ngunit patuloy na gumagana ang mga serbisyo;
- at/o ikinakalat namin nang maayos ang load nang pahalang sa mga rack, kaya hindi kailanman tataas ang aming mga serbisyo sa maximum na pagkonsumo sa isang rack nang sama-sama.
Narito ito ay lubhang kapaki-pakinabang hindi lamang upang hulaan, ngunit upang masubaybayan ang pagkonsumo at malaman kung paano aktwal na kumonsumo ng kuryente ang mga server sa ilalim ng normal at peak na mga kondisyon. Samakatuwid, pagkatapos ng ilang pagsusuri, pinipiga ng tech director ang lahat ng mayroon siya at sinabing: "gumagawa kami ng kusang-loob na desisyon na ang maximum na matamo na average ng maximum na pagkonsumo ng server sa bawat rack ay **napakarami** mas mababa sa maximum na pagkonsumo," may kondisyong Pserv = 0.8* Pmax.
At pagkatapos ay hindi na kayang tumanggap ng 6kW rack ng 16 server na may Pmax = 375W, ngunit 20 server na may Pserv = 375W * 0.8 = 300W. Yung. 25% higit pang mga server. Ito ay isang napakalaking pagtitipid - pagkatapos ng lahat, kailangan namin kaagad ng 25% na mas kaunting mga rack (at makakatipid din kami sa mga PDU, switch at cable). Ang isang seryosong disbentaha ng naturang solusyon ay dapat nating patuloy na subaybayan na ang ating mga pagpapalagay ay tama pa rin. Na ang bagong bersyon ng firmware ay hindi makabuluhang nagbabago sa pagpapatakbo ng mga tagahanga at pagkonsumo, na ang pag-unlad nang biglaan sa bagong release ay hindi nagsimulang gumamit ng mga server nang mas mahusay (basahin: nakamit nila ang mas malaking pag-load at mas malaking pagkonsumo sa server). Pagkatapos ng lahat, ang aming mga paunang pagpapalagay at konklusyon ay agad na nagiging mali. Ito ay isang panganib na dapat tanggapin nang may pananagutan (o iwasan at pagkatapos ay magbayad para sa malinaw na hindi gaanong ginagamit na mga rack).
Isang mahalagang tala - dapat mong subukang ipamahagi ang mga server mula sa iba't ibang serbisyo nang pahalang sa mga rack, kung maaari. Ito ay kinakailangan upang hindi mangyari ang mga sitwasyon kapag dumating ang isang batch ng mga server para sa isang serbisyo, ang mga rack ay naka-pack na patayo dito upang mapataas ang "density" (dahil mas madali sa ganoong paraan). Sa katotohanan, lumalabas na ang isang rack ay puno ng magkaparehong mababang-load na mga server ng parehong serbisyo, at ang isa ay puno ng pantay na mataas na pagkarga ng mga server. Ang posibilidad ng ikalawang pagkahulog ay makabuluhang mas mataas, dahil ang load profile ay pareho, at lahat ng mga server na magkasama sa rack na ito ay nagsisimulang kumonsumo ng parehong halaga bilang resulta ng tumaas na load.
Bumalik tayo sa pamamahagi ng mga server sa mga rack. Tiningnan namin ang pisikal na rack space at mga limitasyon ng kapangyarihan, ngayon tingnan natin ang network. Maaari kang gumamit ng mga switch na may 24/32/48 N port (halimbawa, mayroon kaming 48-port ToR switch). Sa kabutihang palad, walang maraming mga pagpipilian kung hindi mo iniisip ang tungkol sa mga break-out na cable. Isinasaalang-alang namin ang mga sitwasyon kapag mayroon kaming isang switch sa bawat rack, isang switch para sa dalawa o tatlong rack sa Rnet group. Para sa akin, sobra na sa tatlong racks sa isang grupo, dahil... ang problema ng paglalagay ng kable sa pagitan ng mga rack ay nagiging mas malaki.
Kaya, para sa bawat senaryo ng network (1, 2 o 3 rack sa isang grupo), ibinabahagi namin ang mga server sa mga rack:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Kaya, para sa opsyon na may 2 rack sa isang grupo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 server bawat rack.
Isinasaalang-alang namin ang natitirang mga pagpipilian sa parehong paraan:
Srack1 = 20
Srack3 = 16
At malapit na kami. Binibilang namin ang bilang ng mga rack upang ipamahagi ang lahat ng aming mga server S (hayaan itong maging 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
Susunod, kinakalkula namin ang TCO para sa bawat opsyon batay sa bilang ng mga rack, kinakailangang bilang ng mga switch, paglalagay ng kable, atbp. Pinipili namin ang opsyon kung saan mas mababa ang TCO. Kita!
Tandaan na kahit na ang kinakailangang bilang ng mga rack para sa mga pagpipilian 1 at 2 ay pareho, ang kanilang presyo ay magkakaiba, dahil ang bilang ng mga switch para sa pangalawang opsyon ay kalahati ng mas maraming, at ang haba ng mga kinakailangang cable ay mas mahaba.
PS Kung may pagkakataon kang maglaro gamit ang power per rack at ang taas ng rack, tumataas ang variability. Ngunit ang proseso ay maaaring mabawasan sa isa na inilarawan sa itaas sa pamamagitan lamang ng pagdaan sa mga opsyon. Oo, magkakaroon ng higit pang mga kumbinasyon, ngunit limitado pa rin ang bilang - ang supply ng kuryente sa rack para sa pagkalkula ay maaaring tumaas sa mga hakbang na 1 kW, ang mga tipikal na rack ay dumating sa isang limitadong bilang ng mga karaniwang sukat: 42U, 45U, 47U, 48U , 52U. At dito makakatulong ang pagsusuri ng What-If ng Excel sa Data Table mode sa mga kalkulasyon. Tinitingnan namin ang natanggap na mga plato at piliin ang pinakamababa.
Pinagmulan: www.habr.com