V enem od klepetov so mi zastavili vprašanje:
— Ali lahko preberem kaj o tem, kako pravilno zložiti strežnike v omare?
Spoznal sem, da takega besedila ne poznam, zato sem ga napisal sam.
Najprej, to besedilo govori o fizični strežniki v fizičnih podatkovnih centrih (DC). Drugič, predpostavljamo, da je strežnikov kar nekaj: na stotine ali tisoče; za manjše število je to besedilo brez pomena. Tretjič, predpostavljamo, da imamo tri omejitve: fizični prostor v omarah, napajanje omar in, če predpostavimo, da so omare razporejene v vrstah, lahko za povezavo strežnikov v sosednjih omarah uporabimo eno samo stikalo ToR.
Odgovor na to vprašanje je močno odvisen od parametra, ki ga optimiziramo, in od tega, kaj lahko spremenimo, da dosežemo najboljši rezultat. Na primer, morda moramo zavzeti le minimalno količino prostora, da pustimo več prostora za prihodnjo rast. Ali pa imamo morda večjo fleksibilnost pri izbiri višine omar, moči na omaro, vtičnic napajalnikov (PDU), števila omar v skupini stikal (eno stikalo na 1, 2 ali 3 omare), dolžin kablov in stroškov kabliranja (to je ključnega pomena na koncih vrst: z 10 omaricami na vrsto in 3 omaricami na stikalo bomo morali podaljšati kable v drugo vrsto ali premalo izkoristiti vrata v stikalu) itd. Ločena tema: izbira strežnika in izbira podatkovnega centra; predpostavimo, da sta bila izbrana.
Koristno bi bilo razumeti nekatere nianse in podrobnosti, zlasti povprečno/največjo porabo strežnikov in kako smo oskrbovani z električno energijo. Na primer, če imamo rusko napajanje 230 V in eno fazo na omaro, lahko 32A odklopnik prenese ~7 kW. Recimo, da nominalno plačamo za 6 kW na omaro. Če ponudnik meri našo porabo samo za vrsto 10 omar in ne za vsako omaro posebej, in če je odklopnik nastavljen tako, da se izklopi pri recimo 7 kW, potem lahko tehnično gledano porabimo 6.9 kW v eni omarici, 5.1 kW v drugi in vse bo v redu – brez kazni.
Naš primarni cilj je običajno zmanjšanje stroškov. Najboljša metrika za merjenje tega je zmanjšanje skupnih stroškov lastništva (TCO). Sestavljeni so iz naslednjih komponent:
- CAPEX: nakup infrastrukture podatkovnega centra, strežnikov, omrežne strojne opreme in kablov
- OPEX: najem podatkovnega centra, poraba električne energije, vzdrževanje. OPEX je odvisen od življenjske dobe. Razumna ocena je 3 leta.
Glede na to, kako veliki so posamezni deli celotnega kolača, moramo optimizirati najdražje, preostali pa pustiti, da čim bolj učinkovito uporabijo vse preostale vire.
Recimo, da imamo obstoječi podatkovni center, višino omare H enot (na primer H = 47) in porabo energije Prack (Prack = 6 kW). Odločili smo se za uporabo strežnikov z dvema enotama višine h = 2U. Iz omare bomo odstranili 2,4 enote za stikala, razdelilne plošče in organizatorje. To pomeni, da lahko naša omara fizično sprejme strežnike Sh = rounddown((H - 2,4) / h) (tj. Sh = rounddown((47 - 4) / 2) = 21 strežnikov na omaro). Zapomnimo si to Sh.
V preprostem primeru so vsi strežniki v omari enaki. Če torej napolnimo omaro strežniki, potem bo povprečna poraba energije za vsak strežnik Pserv = Prack/Sh (Pserv = 6000 W / 21 = 287 W). Zaradi poenostavitve tukaj zanemarimo porabo stikala.
Stopimo korak nazaj in definirajmo, kakšna je največja poraba energije strežnika (Pmax). Če je zelo preprosto, zelo neučinkovito in popolnoma varno, potem samo preberite, kaj piše na napajalniku strežnika – to je to.
Če je bolj zapleteno in učinkovitejše, potem vzamemo TDP (paket termične zasnove) vseh komponent in jih seštejemo (to ni povsem res, je pa mogoče).
Običajno ne poznamo TDP komponent (razen procesorja), zato uporabimo najbolj natančen, a tudi najbolj zapleten pristop (ki zahteva laboratorij): vzamemo eksperimentalni strežnik z želeno konfiguracijo in ga naložimo na primer z Linpackom (procesor in pomnilnik) in fio (pogoni), pri čemer merimo porabo. Če mislimo resno, bi morali med testiranjem ustvariti tudi najtoplejše možno okolje v hladnem hodniku, saj to vpliva tako na porabo ventilatorjev kot na porabo procesorja. To da največjo porabo določenega strežnika z določeno konfiguracijo v teh specifičnih pogojih in tej specifični obremenitvi. Upoštevajte, da lahko na rezultate vpliva nova sistemska programska oprema, drugačna različica programske opreme in drugi pogoji.
Torej, nazaj k Pserv in kako ga primerjamo s Pmax. Gre za razumevanje delovanja storitev in živce vašega tehničnega direktorja.
Če ne tvegamo, predpostavljamo, da bi vsi strežniki lahko nenadoma začeli porabljati svojo največjo zmogljivost. Hkrati bi lahko prišlo do odpovedi enega vhoda v podatkovni center. Tudi v teh pogojih mora infrastruktura zagotavljati storitev, zato je Pserv ≡ Pmax. Pri tem pristopu je zanesljivost ključnega pomena.
Če tehnični direktor ne razmišlja le o idealni varnosti, temveč tudi o denarju podjetja in je dovolj pogumen, se lahko odločite, da
- Začenjamo upravljati naše dobavitelje, zlasti prepovedujemo načrtovano vzdrževanje v obdobjih načrtovane konične obremenitve, da bi čim bolj zmanjšali padec enega vhoda;
- in/ali naša arhitektura vam omogoča, da izgubite omaro/vrsto/podatkovni center, vendar storitve še naprej delujejo;
- in/ali pa obremenitev dobro vodoravno porazdelimo po regalih, tako da naše storitve nikoli ne dosežejo maksimalne porabe v enem samem regalu hkrati.
Tukaj je zelo koristno ne le ugibati, temveč spremljati porabo in vedeti, koliko energije strežniki dejansko porabijo v normalnih in konicah. Zato tehnični direktor po nekaj analizah strne vse, kar ima, in reče: »Prostovoljno sprejemamo, da je največje dosegljivo povprečje največje porabe strežnika na omaro **toliko** nižje od največje porabe,« ob predpostavki, da je Pserv = 0.8 * Pmax.
Potem lahko 6 kW rack sprejme ne 16 strežnikov s Pmax = 375 W, temveč 20 strežnikov s Pserv = 375 W * 0.8 = 300 W. To je 25 % več strežnikov. To je znaten prihranek – navsezadnje takoj potrebujemo 25 % manj rack (in potem bomo prihranili pri PDU-jih, stikalih in kablih). Resna slabost te rešitve je, da moramo nenehno spremljati svoje predpostavke, da zagotovimo, da so še vedno veljavne. Da nova različica vdelane programske opreme bistveno ne spremeni delovanja ventilatorjev in porabe energije ter da razvojna ekipa z novo izdajo ni nenadoma začela veliko učinkoviteje uporabljati strežnikov (kar pomeni, da so dosegli večjo obremenitev in večjo porabo energije na strežnik). Navsezadnje potem tako naše začetne predpostavke kot sklepi takoj postanejo napačni. To je tveganje, ki ga je treba odgovorno sprejeti (ali se mu izogniti in nato plačati za očitno premalo izkoriščene rampe).
Pomembno obvestilo: če je mogoče, poskusite strežnike iz različnih storitev razporediti vodoravno po omarah. To je potrebno, da se izognete situacijam, ko prispe serija strežnikov za eno storitev in so omare zložene navpično, da se poveča gostota (ker je to lažje). V resnici pa je ena omara napolnjena z enakimi strežniki z nizko obremenitvijo iz ene storitve, druga pa z enakimi strežniki z visoko obremenitvijo. Verjetnost okvare druge omare je bistveno večja, saj je profil obremenitve enak in vsi strežniki v tej omari začnejo porabljati enako količino energije, ko se obremenitev povečuje.
Vrnimo se k razporeditvi strežnikov v omarice. Upoštevali smo že fizične prostorske in napajalne omejitve omare, zdaj pa si poglejmo omrežje. Uporabimo lahko stikala s 24/32/48 N vrati (na primer, mi uporabljamo 48-vratna stikala ToR). Na srečo možnosti ni tako veliko, razen če upoštevamo prelomne kable. Upoštevamo scenarije, kjer imamo eno stikalo na omaro, eno stikalo na dve ali tri omare v skupini Rnet. Mislim, da je več kot tri omare v skupini pretirano, saj postane vprašanje kablov med omari veliko bolj zahtevno.
Torej, za vsak omrežni scenarij (1, 2 ali 3 omare v skupini) razporedimo strežnike med omare:
Srack = min(Sh, zaokroževanje navzdol(Prack/Pserv), zaokroževanje navzdol(N/Rnet))
Torej, za možnost z dvema regaloma v skupini:
Srack2 = min(21, zaokroženo(6000/300), zaokroženo(48/2)) = min(21, 20, 24) = 20 strežnikov na omaro.
Preostale možnosti izračunamo na enak način:
Srack1 = 20
Srack3 = 16
In skoraj smo tam. Izračunajmo število regalov, potrebnih za razporeditev vseh naših S strežnikov (recimo 1000):
R = zaokroževanje(S / (Srack * Rnet)) * Rnet
R1 = zaokroževanje(1000 / (20 * 1)) * 1 = 50 * 1 = 50 stojal
R2 = zaokroževanje(1000 / (20 * 2)) * 2 = 25 * 2 = 50 stojal
R3 = zaokroževanje(1000 / (16 * 3)) * 3 = 25 * 2 = 63 stojal
Nato izračunamo skupne stroške lastništva (TCO) za vsako možnost na podlagi števila stojal, potrebnega števila stikal, kablov itd. Izberite možnost z najnižjimi skupnimi stroški lastništva. Dobiček!
Upoštevajte, da čeprav je potrebno število stojal za možnosti 1 in 2 enako, bo njihova cena drugačna, saj je število stikal za drugo možnost za polovico manjše, dolžina potrebnih kablov pa je večja.
P.S. Če se lahko poigrate z močjo in višino omare, se variabilnost poveča. Vendar pa je postopek mogoče zreducirati na zgoraj navedeno, preprosto s ponavljanjem možnosti. Da, kombinacij bo več, vendar jih bo še vedno zelo omejeno število – moč omare je mogoče za izračune povečevati v korakih po 1 kW, standardne omare pa so na voljo v omejenem številu velikosti: 42U, 45U, 47U, 48U, 52U. Tukaj je lahko v pomoč Excelova analiza »kaj-če« v načinu tabele podatkov. Oglejte si nastale tabele in izberite najmanjšo možno vrednost.
Vir: www.habr.com
