ProHoster > Blogs > interneta ziņas > Serveru sadales optimizÄ“Å”ana starp plauktiem

Serveru sadales optimizēŔana starp plauktiem

Vienā no tērzÄ“Å”anas sarunām man uzdeva jautājumu:

ā€” Vai es varu kaut ko izlasÄ«t par to, kā pareizi iepakot serverus plauktos?

Es sapratu, ka nezinu Ŕādu tekstu, tāpēc uzrakstÄ«ju savu.

Pirmkārt, Å”is teksts ir par fiziskiem serveriem fiziskajos datu centros (DC). Otrkārt, mēs uzskatām, ka serveru ir diezgan daudz: simtiem tÅ«kstoÅ”u, mazākam skaitam Å”im tekstam nav jēgas. TreÅ”kārt, mēs uzskatām, ka mums ir trÄ«s ierobežojumi: fiziskā vieta plauktos, strāvas padeve katram plauktam un ļaut plauktiem stāvēt rindās, lai mēs varētu izmantot vienu ToR slēdzi, lai savienotu serverus blakus esoÅ”ajos plauktos.

Atbilde uz jautājumu lielā mērā ir atkarÄ«ga no tā, kādu parametru mēs optimizējam un ko varam mainÄ«t, lai sasniegtu vislabāko rezultātu. Piemēram, mums vienkārÅ”i ir nepiecieÅ”ams aizņemt minimālu vietu, lai vairāk atstātu tālākai izaugsmei. Vai varbÅ«t mums ir brÄ«vÄ«ba izvēlēties statÄ«vu augstumu, jaudu uz statÄ«vu, ligzdas PDU, statÄ«vu skaitu slēdžu grupā (viens slēdzis 1, 2 vai 3 statÄ«viem), vadu garumu un vilkÅ”anas darbu ( tas ir ļoti svarÄ«gi rindu galos: ja ir 10 statÄ«vi pēc kārtas un 3 statÄ«vi uz vienu slēdzi, jums bÅ«s jāvelk vadi uz citu rindu vai nepietiekami jāizmanto slēdža pieslēgvietas) utt., utt. AtseviŔķi stāsti: serveru izvēle un DC izvēle, mēs pieņemsim, ka tie ir atlasÄ«ti.

BÅ«tu labi saprast dažas nianses un detaļas, jo Ä«paÅ”i serveru vidējo/maksimālo patēriņu un to, kā mums tiek piegādāta elektrÄ«ba. Tātad, ja mums ir krievu baroÅ”anas avots 230V un viena fāze uz statÄ«va, tad 32A maŔīna var tikt galā ar ~7kW. Pieņemsim, ka mēs nomināli maksājam par 6 kW uz vienu statÄ«vu. Ja pakalpojumu sniedzējs mēra mÅ«su patēriņu tikai 10 statÄ«vu rindai, nevis katram statÄ«vs, un ja iekārta ir iestatÄ«ta uz nosacÄ«ti 7 kW robežu, tad tehniski mēs varam patērēt 6.9 kW vienā statÄ«vā, 5.1 kW citā un viss bÅ«s ok - nav sodāms.

Parasti mÅ«su galvenais mērÄ·is ir samazināt izmaksas. Labākais mērÄ«Å”anas kritērijs ir TCO (kopējās Ä«paÅ”umtiesÄ«bu izmaksas) samazinājums. Tas sastāv no Ŕādām daļām:

  • CAPEX: lÄ«dzstrāvas infrastruktÅ«ras, serveru, tÄ«kla aparatÅ«ras un kabeļu iegāde
  • OPEX: LÄ«dzstrāvas noma, elektroenerÄ£ijas patēriņŔ, apkope. OPEX ir atkarÄ«gs no kalpoÅ”anas laika. Ir saprātÄ«gi pieņemt, ka tas ir 3 gadi.

Serveru sadales optimizēŔana starp plauktiem

AtkarÄ«bā no tā, cik lieli ir atseviŔķi gabali kopējā pÄ«rāgā, mums ir jāoptimizē dārgākais, bet pārējiem jāļauj izmantot visus atlikuÅ”os resursus pēc iespējas efektÄ«vāk.

Pieņemsim, ka mums ir lÄ«dzstrāva, ir H vienÄ«bu statÄ«va augstums (piemēram, H=47), elektrÄ«ba uz vienu statÄ«vu Prack (Prack=6kW), un mēs nolēmām izmantot h=2U divu vienÄ«bu serverus. No slēdžu, plāksteru paneļu un organizatoru plaukta noņemsim 2..4 vienÄ«bas. Tie. fiziski mÅ«su statÄ«vajā ir Sh=rounddown((H-2..4)/h) serveri (t.i., Sh = rounddown((47-4)/2)=21 serveri uz statÄ«va). Atcerēsimies Å”o Å .

VienkārŔā gadÄ«jumā visi plauktā esoÅ”ie serveri ir identiski. Kopumā, ja uzpildām plauktu ar serveriem, tad uz katra servera varam vidēji iztērēt jaudu Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). VienkārŔības labad mēs ignorējam slēdža patēriņu.

Paņemsim soli malā un noteiksim, kāds ir maksimālais servera patēriņŔ Pmax. Ja tas ir ļoti vienkārÅ”i, ļoti neefektÄ«vi un pilnÄ«gi droÅ”i, tad mēs lasām, kas rakstÄ«ts uz servera baroÅ”anas avota - tas ir tas.

Ja tas ir sarežģītāks un efektīvāks, tad mēs ņemam visu komponentu TDP (termiskā dizaina paketi) un summējam (tas nav īsti patiesi, bet tas ir iespējams).

Parasti mēs nezinām komponentu TDP (izņemot CPU), tāpēc mēs izmantojam vispareizāko, bet arÄ« sarežģītāko pieeju (mums ir nepiecieÅ”ama laboratorija) - ņemam vajadzÄ«gās konfigurācijas eksperimentālo serveri un ielādējam to, piemēram, ar Linpack (CPU un atmiņa) un fio (diski) mēs izmērām patēriņu. Ja mēs to uztveram nopietni, tad arÄ« testu laikā aukstajā koridorā ir jārada siltākā vide, jo tas ietekmēs gan ventilatora patēriņu, gan CPU patēriņu. Mēs iegÅ«stam maksimālo konkrēta servera patēriņu ar noteiktu konfigurāciju Å”ajos konkrētajos apstākļos pie Ŕīs konkrētās slodzes. Mēs vienkārÅ”i domājam, ka rezultātu var ietekmēt jauna sistēmas programmaparatÅ«ra, cita programmatÅ«ras versija un citi apstākļi.

Tātad, atpakaļ pie Pserv un kā mēs to salīdzinām ar Pmax. Tas ir jāsaprot, kā darbojas pakalpojumi un cik stipri ir jūsu tehniskā direktora nervi.

Ja mēs vispār neuzņemamies nekādu risku, mēs uzskatām, ka visi serveri vienlaikus var sākt patērēt maksimālo. Tajā paŔā brÄ«dÄ« var notikt viena ievade lÄ«dzstrāvā. Pat Ŕādos apstākļos infra ir jānodroÅ”ina pakalpojums, tāpēc Pserv ā‰” Pmax. Å Ä« ir pieeja, kurā uzticamÄ«ba ir absolÅ«ti svarÄ«ga.

Ja tehnoloÄ£iju direktors domā ne tikai par ideālu droŔību, bet arÄ« par uzņēmuma naudu un ir pietiekami drosmÄ«gs, tad varat izlemt, ka

  • Mēs sākam pārvaldÄ«t savus pārdevējus, jo Ä«paÅ”i mēs aizliedzam plānoto apkopi plānotās maksimālās slodzes laikā, lai samazinātu vienas ievades samazināŔanos;
  • un/vai mÅ«su arhitektÅ«ra ļauj pazaudēt plauktu/rindu/DC, taču pakalpojumi turpina darboties;
  • un/vai mēs labi sadalām kravu horizontāli pa plauktiem, lai mÅ«su pakalpojumi nekad nesasniegs maksimālo patēriņu vienā plauktā kopā.

Å eit ir ļoti noderÄ«gi ne tikai uzminēt, bet arÄ« uzraudzÄ«t patēriņu un zināt, kā serveri faktiski patērē elektroenerÄ£iju normālos un maksimālās slodzes apstākļos. Tāpēc pēc nelielas analÄ«zes tehnoloÄ£iju direktors izspiež visu, kas viņam ir, un saka: "Mēs pieņemam lēmumu, ka maksimālais vidējais maksimālais servera patēriņŔ uz vienu plauktu ir **tik daudz** mazāks par maksimālo patēriņu," nosacÄ«ti Pserv = 0.8* Pmaks.

Un tad 6kW plaukts vairs nevar uzņemt 16 serverus ar Pmax = 375W, bet 20 serverus ar Pserv = 375W * 0.8 = 300W. Tie. Par 25% vairāk serveru. Tas ir ļoti liels ietaupÄ«jums ā€“ galu galā mums uzreiz vajag par 25% mazāk statÄ«vu (un arÄ« ietaupÄ«sim uz PDU, slēdžiem un kabeļiem). Nopietns Ŕāda risinājuma trÅ«kums ir tas, ka mums pastāvÄ«gi jāuzrauga, vai mÅ«su pieņēmumi joprojām ir pareizi. Ka jaunā programmaparatÅ«ras versija bÅ«tiski nemaina ventilatoru darbÄ«bu un patēriņu, ka attÄ«stÄ«ba pēkŔņi ar jauno laidienu nesāka daudz efektÄ«vāk izmantot serverus (lasi: tie panāca lielāku slodzi un lielāku patēriņu serverÄ«). Galu galā gan mÅ«su sākotnējie pieņēmumi, gan secinājumi uzreiz kļūst nepareizi. Tas ir risks, kas jāuzņemas atbildÄ«gi (vai jāizvairās un pēc tam jāmaksā par acÄ«mredzami nepietiekami izmantotiem plauktiem).

SvarÄ«ga piezÄ«me - ja iespējams, mēģiniet sadalÄ«t dažādu pakalpojumu serverus horizontāli pa plauktiem. Tas ir nepiecieÅ”ams, lai nerastos situācijas, kad vienam servisam pienāk viena serveru partija, ar to vertikāli tiek sapakoti statÄ«vi, lai palielinātu ā€œblÄ«vumuā€ (jo tā ir vieglāk). Realitātē izrādās, ka viens statÄ«vs ir piepildÄ«ts ar identiskiem viena un tā paÅ”a servisa zemas slodzes serveriem, bet otrs ar tikpat augstas slodzes serveriem. Otrā kritiena iespējamÄ«ba ir ievērojami lielāka, jo slodzes profils ir vienāds, un visi serveri kopā Å”ajā plauktā sāk patērēt vienādu daudzumu palielinātas slodzes rezultātā.

AtgriezÄ«simies pie serveru sadales plauktos. Mēs esam apskatÄ«juÅ”i fizisko plauktu vietu un jaudas ierobežojumus, tagad apskatÄ«sim tÄ«klu. Varat izmantot slēdžus ar 24/32/48 N portiem (piemēram, mums ir 48 portu ToR slēdži). Par laimi, nav daudz iespēju, ja nedomājat par kabeļiem. Mēs apsveram scenārijus, kad mums ir viens slēdzis katram plauktam, viens slēdzis diviem vai trim plauktiem Rnet grupā. Man Ŕķiet, ka vairāk nekā trÄ«s plaukti grupā jau ir par daudz, jo... kabeļu problēma starp statÄ«viem kļūst daudz lielāka.

Tātad katram tīkla scenārijam (1, 2 vai 3 plaukti grupā) mēs sadalām serverus starp statīviem:

Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))

Tādējādi opcijai ar 2 plauktiem grupā:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serveri vienā plauktā.

Pārējās iespējas mēs apsveram tādā paŔā veidā:

Srack1 = 20
Srack3 = 16

Un mēs esam gandrīz klāt. Mēs saskaitām statīvu skaitu, lai izplatītu visus mūsu serverus S (lai tas būtu 1000):

R = roundup (S / (Srack * Rnet)) * Rnet

R1 = noapaļoŔana (1000 / (20 * 1)) * 1 = 50 * 1 = 50 plaukti

R2 = noapaļoŔana (1000 / (20 * 2)) * 2 = 25 * 2 = 50 plaukti

R3 = noapaļoŔana (1000 / (16 * 3)) * 3 = 25 * 2 = 63 plaukti

Tālāk mēs aprēķinām TCO katrai opcijai, pamatojoties uz statÄ«vu skaitu, nepiecieÅ”amo slēdžu skaitu, kabeļiem utt. Mēs izvēlamies opciju, kur TCO ir zemāka. Peļņa!

Ņemiet vērā, ka, lai gan nepiecieÅ”amais statÄ«vu skaits 1. un 2. opcijai ir vienāds, to cena bÅ«s atŔķirÄ«ga, jo slēdžu skaits otrajai opcijai ir uz pusi mazāks, un nepiecieÅ”amo kabeļu garums ir lielāks.

PS Ja jums ir iespēja spēlēt ar jaudu uz statÄ«vu un plaukta augstumu, mainÄ«ba palielinās. Bet procesu var samazināt lÄ«dz iepriekÅ” aprakstÄ«tajam, vienkārÅ”i izpētot iespējas. Jā, bÅ«s vairāk kombināciju, bet tomēr ļoti ierobežots skaits - baroÅ”anas padevi statnei aprēķinam var palielināt ar 1 kW soli, tipiski statÄ«vi ir ierobežotā skaitā standarta izmēru: 42U, 45U, 47U, 48U , 52U. Un Å”eit Excel What-If analÄ«ze datu tabulas režīmā var palÄ«dzēt aprēķinos. Apskatām saņemtās plāksnes un izvēlamies minimumu.

Avots: www.habr.com

Pievieno komentāru