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 sa lahat, ang tekstong ito ay tungkol sa mga pisikal na server sa mga pisikal na data center (DC). Pangalawa, ipinapalagay natin na maraming server: daan-daan o libo-libo; para sa mas maliliit na numero, walang kahulugan ang tekstong ito. Pangatlo, ipinapalagay natin na mayroon tayong tatlong limitasyon: pisikal na espasyo ng rack, suplay ng kuryente ng rack, at, kung ang mga rack ay nakaayos sa mga hilera, maaari nating gamitin ang isang ToR switch upang ikonekta ang mga server sa magkakatabing mga rack.
Ang sagot sa tanong na ito ay lubos na nakadepende sa parameter na aming ino-optimize at kung ano ang maaari naming pag-iba-iba upang makamit ang pinakamahusay na resulta. Halimbawa, maaaring kailangan lang nating kumuha ng pinakamababang halaga ng espasyo upang mag-iwan ng mas maraming puwang para sa paglago sa hinaharap. O marahil ay mayroon tayong higit na kakayahang umangkop sa pagpili ng mga taas ng rack, power per rack, saksakan ng power-supply unit (PDU), ang bilang ng mga rack sa isang switch group (isang switch sa bawat 1, 2, o 3 rack), haba ng cable, at mga gastos sa paglalagay ng kable (ito ay kritikal sa mga dulo ng mga row: na may 10 rack bawat hilera at 3 rack ang gagamitin natin sa ilalim ng cable, o sa bawat row. ang switch), atbp. Isang hiwalay na paksa: pagpili ng server at pagpili ng data center; ipagpalagay natin na sila ay napili.
Makakatulong na maunawaan ang ilang mga nuances at detalye, lalo na, ang average/maximum na pagkonsumo ng mga server at kung paano tayo binibigyan ng kuryente. Halimbawa, kung mayroon tayong Russian 230V power supply at isang yugto sa bawat rack, ang isang 32A circuit breaker ay kayang humawak ng ~7 kW. Sabihin nating nagbabayad tayo ng 6 kW 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 circuit breaker ay nakatakdang putulin sa, sabihin nating, 7 kW, kung gayon sa teknikal na paraan maaari kaming kumonsumo ng 6.9 kW sa isang rack, 5.1 kW sa isa pa, at lahat ay magiging maayos—walang mga parusa.
Ang aming pangunahing layunin ay karaniwang mabawasan ang mga gastos. Ang pinakamahusay na sukatan para sa pagsukat nito ay ang pagbabawas ng TCO (kabuuang halaga ng pagmamay-ari). Binubuo ito ng mga sumusunod na sangkap:
- CAPEX: pagbili ng imprastraktura ng data center, mga server, hardware ng network, at paglalagay ng kable
- OPEX: pag-upa sa data center, pagkonsumo ng kuryente, pagpapanatili. Ang OPEX ay nakasalalay sa buhay ng serbisyo. Ang isang makatwirang pagtatantya ay 3 taon.
Depende sa kung gaano kalaki ang mga indibidwal na piraso ng pangkalahatang pie, kailangan nating i-optimize ang mga pinakamahal, at hayaan ang iba na gamitin ang lahat ng natitirang mapagkukunan nang mahusay hangga't maaari.
Sabihin nating mayroon tayong umiiral na data center, taas ng rack ng H unit (halimbawa, H = 47), at paggamit ng kuryente ng Prack (Prack = 6 kW). 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. Nangangahulugan ito na pisikal, ang aming rack ay maaaring magkasya sa Sh = rounddown((H - 2.4) / h) server (ibig sabihin, Sh = rounddown((47 - 4) / 2) = 21 server bawat rack). Tandaan natin itong Sh.
Sa isang simpleng kaso, lahat ng server sa rack ay magkakapareho. Kaya, kung pupunuin natin ang rack mga server, kung gayon ang karaniwang konsumo ng kuryente para sa bawat server ay magiging Pserv = Prack/Sh (Pserv = 6000W/21 = 287W). Para sa pagiging simple, hindi natin isinasaalang-alang ang konsumo ng switch dito.
Bumalik tayo ng isang hakbang at tukuyin kung ano ang maximum power consumption (Pmax) ng isang server. Kung ito ay napaka-simple, napaka-inefficient, at ganap na ligtas, pagkatapos ay basahin lamang kung ano ang nakasulat sa power supply ng server—iyon lang.
Kung ito ay mas kumplikado at mas mahusay, pagkatapos ay kukunin namin ang TDP (thermal design package) ng lahat ng mga bahagi at ibuod ang mga ito (ito ay hindi ganap na totoo, ngunit ito ay posible).
Karaniwang hindi namin alam ang TDP ng mga bahagi (maliban sa CPU), kaya kinukuha namin ang pinakatumpak, ngunit pinakakomplikadong diskarte (nangangailangan ng lab): kumukuha kami ng eksperimental na server na may gustong configuration at ni-load ito, halimbawa, Linpack (CPU at memory) at fio (mga drive), na sinusukat ang pagkonsumo. Kung seryoso tayo, dapat din tayong lumikha ng pinakamainit na posibleng kapaligiran sa isang malamig na pasilyo sa panahon ng pagsubok, dahil nakakaapekto ito sa pagkonsumo ng fan at pagkonsumo ng CPU. Nagbubunga ito ng maximum na pagkonsumo ng isang partikular na server na may partikular na pagsasaayos sa ilalim ng mga partikular na kundisyon sa ilalim ng partikular na pag-load na ito. Tandaan na ang bagong firmware ng system, ibang bersyon ng software, at iba pang kundisyon ay maaaring makaapekto sa mga resulta.
Kaya, bumalik sa Pserv at kung paano namin ito ihahambing sa Pmax. Ito ay isang bagay ng pag-unawa kung paano gumagana ang mga serbisyo at ang nerbiyos ng iyong teknikal na direktor.
Kung hindi kami nagsasagawa ng anumang mga panganib, ipinapalagay namin na ang lahat ng mga server ay maaaring biglang magsimulang kumonsumo ng kanilang pinakamataas na kapasidad. Kasabay nito, maaaring mabigo ang isang input sa data center. Kahit na sa ilalim ng mga kundisyong ito, ang imprastraktura ay dapat magbigay ng serbisyo, kaya Pserv ≡ Pmax. Ito ay isang diskarte kung saan ang pagiging maaasahan ay talagang mahalaga.
Kung ang teknikal na direktor 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 panahon ng nakaplanong peak load upang mabawasan ang pagbaba sa isang input;
- at/o pinapayagan ka ng aming arkitektura na mawalan ng rack/row/data center, ngunit patuloy na gumagana ang mga serbisyo;
- at/o ikinakalat namin ang load nang pahalang sa mga rack, kaya ang aming mga serbisyo ay hindi kailanman tumalon sa maximum na pagkonsumo sa isang rack nang sabay-sabay.
Dito, ito ay lubhang kapaki-pakinabang hindi lamang upang hulaan, ngunit upang subaybayan ang pagkonsumo at malaman kung gaano karaming mga power server ang aktwal na kumokonsumo sa ilalim ng normal at peak na mga kondisyon. Samakatuwid, pagkatapos ng ilang pagsusuri, ang CTO ay nag-condense ng lahat ng mayroon sila at nagsasabing, "Kusang-loob naming tinatanggap na ang maximum na maaabot na average ng maximum na pagkonsumo ng server bawat rack ay **napakababa** kaysa sa maximum na pagkonsumo," sa pag-aakalang Pserv = 0.8 * Pmax.
Kung gayon ang isang 6 kW rack ay hindi kayang tumanggap ng hindi 16 na server na may Pmax = 375 W, ngunit 20 server na may Pserv = 375 W * 0.8 = 300 W. Iyan ay 25% higit pang mga server. Malaking tipid ito—pagkatapos ng lahat, kailangan natin agad ng 25% na mas kaunting mga rack (at pagkatapos ay makakatipid tayo sa mga PDU, switch, at cable). Ang isang seryosong downside sa solusyon na ito ay kailangan nating patuloy na subaybayan ang ating mga pagpapalagay upang matiyak na wasto pa rin ang mga ito. Na ang bagong bersyon ng firmware ay hindi gaanong nagbabago sa pagpapatakbo ng fan at pagkonsumo ng kuryente, at na ang development team ay hindi pa biglang nagsimulang gumamit ng mga server nang mas mahusay sa bagong release (ibig sabihin, nakamit nila ang mas mataas na load at mas mataas na konsumo ng kuryente sa bawat server). Pagkatapos ng lahat, kung gayon ang aming mga paunang pagpapalagay at konklusyon ay agad na nagiging mali. Ito ay isang panganib na dapat na responsableng tanggapin (o iwasan at pagkatapos ay bayaran para sa malinaw na hindi gaanong ginagamit na mga rack).
Isang mahalagang tala: subukang ipamahagi ang mga server mula sa iba't ibang serbisyo nang pahalang sa mga rack, kung maaari. Ito ay kinakailangan upang maiwasan ang mga sitwasyon kung saan ang isang batch ng mga server para sa isang serbisyo ay dumating at ang mga rack ay nakasalansan nang patayo upang mapataas ang density (dahil mas madali ito). Sa katotohanan, gayunpaman, ang isang rack ay puno ng magkapareho, mababang-load na mga server mula sa isang serbisyo, habang ang isa ay puno ng magkapareho, mataas na-load na mga server. Ang posibilidad ng pagkabigo ng pangalawang rack ay makabuluhang mas mataas, dahil ang profile ng pagkarga ay magkapareho, at ang lahat ng mga server sa rack na iyon ay nagsisimulang kumonsumo ng parehong dami ng kapangyarihan habang tumataas ang pagkarga.
Bumalik tayo sa pamamahagi ng server sa mga rack. Isinaalang-alang namin ang pisikal na espasyo at mga limitasyon ng kapangyarihan ng isang rack, ngayon tingnan natin ang network. Maaaring gamitin ang mga switch na may 24/32/48 N port (halimbawa, gumagamit kami ng 48-port ToR switch). Sa kabutihang palad, ang mga opsyon ay hindi ganoon karami, maliban kung isasaalang-alang mo ang mga breakout cable. Isinasaalang-alang namin ang mga sitwasyon kung saan mayroon kaming isang switch bawat rack, isang switch bawat dalawa, o tatlong rack sa isang Rnet group. Sa palagay ko, higit sa tatlong rack sa isang grupo ang labis, dahil ang isyu sa paglalagay ng kable sa pagitan ng mga rack ay nagiging mas mahirap.
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.
Kinakalkula namin ang natitirang mga pagpipilian sa parehong paraan:
Srack1 = 20
Srack3 = 16
At malapit na kami. Kalkulahin natin ang bilang ng mga rack na kailangan upang ipamahagi ang lahat ng ating mga S server (sabihin nating 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. Piliin ang opsyon na may pinakamababang TCO. Kita!
Tandaan na kahit na ang kinakailangang bilang ng mga rack para sa mga opsyon 1 at 2 ay pareho, ang kanilang mga presyo ay magkakaiba, dahil ang bilang ng mga switch para sa pangalawang opsyon ay kalahati ng marami, at ang haba ng kinakailangang mga cable ay mas malaki.
P.S. Kung maaari mong laruin ang lakas ng rack at taas ng rack, tataas ang pagkakaiba-iba. Ngunit ang proseso ay maaaring bawasan sa itaas, sa pamamagitan lamang ng pag-ulit sa mga opsyon. Oo, magkakaroon ng higit pang mga kumbinasyon, ngunit napakalimitado pa rin ang bilang—maaaring tumaas ang lakas ng rack sa 1 kW na mga pagtaas para sa mga kalkulasyon, at ang mga karaniwang rack ay may limitadong bilang ng mga sukat: 42U, 45U, 47U, 48U, 52U. Ang pagsusuri ng What-If ng Excel sa Data Table mode ay maaaring makatulong dito. Tingnan ang mga resultang talahanayan at piliin ang minimum.
Pinagmulan: www.habr.com
