Yn ien fan 'e petearen waard my in fraach steld:
- Is d'r wat ik kin lêze oer hoe't jo servers goed yn racks kinne pakke?
Ik realisearre dat ik sa'n tekst net koe, dat ik skreau myn eigen.
As earste giet dizze tekst oer fysike servers yn fysike datasintra (DC's). Twads leauwe wy dat d'r nochal in soad servers binne: hûnderttûzenen foar in lytser oantal hat dizze tekst gjin sin. Tredde, wy beskôgje dat wy hawwe trije beheinings: fysike romte yn 'e rekken, macht oanbod per rek, en lit de rekken stean yn rigen, sadat wy kinne brûke ien ToR switch te ferbinen tsjinners yn neistlizzende rekken.
It antwurd op 'e fraach hinget tige ôf fan hokker parameter wy optimalisearje en wat wy kinne fariearje om it bêste resultaat te berikken. Bygelyks, wy moatte gewoan in minimum fan romte nimme om mear oer te litten foar fierdere groei. Of miskien hawwe wy frijheid yn it kiezen fan 'e hichte fan' e rekken, macht per rek, sockets yn 'e PDU, it oantal rekken yn in groep skeakels (ien switch foar 1, 2 of 3 rekken), lingte fan triedden en lûkwurk ( dit is kritysk oan 'e ein fan' e rigen: mei 10 racks yn in rige en 3 racks per switch, do silst moatte lûke de triedden nei in oare rige of underuse de havens yn 'e switch), etc., etc. Aparte ferhalen: seleksje fan servers en seleksje fan DC's, wy sille oannimme dat se binne selektearre.
It soe goed wêze om guon fan 'e nuânses en details te begripen, benammen it gemiddelde / maksimale konsumpsje fan servers, en hoe't elektrisiteit oan ús wurdt levere. Dus, as wy in Russyske stroomfoarsjenning hawwe fan 230V en ien faze per rack, dan kin in 32A-masine ~7kW behannelje. Litte wy sizze dat wy nominaal betelje foar 6kW per rek. As de provider ús konsumpsje allinich mjit foar in rige fan 10 racks, en net foar elke rack, en as de masine is ynsteld op in betingst 7 kW cutoff, dan technysk kinne wy konsumearje 6.9 kW yn ien rack, 5.1 kW yn in oar en alles sil goed wêze - net strafber.
Normaal is ús haaddoel om kosten te minimalisearjen. It bêste kritearium om te mjitten is in fermindering fan TCO (totale eigendomskosten). It bestiet út de folgjende stikken:
- CAPEX: oankeap fan DC-ynfrastruktuer, servers, netwurkhardware en bekabeling
- OPEX: DC-ferhier, elektrisiteitsferbrûk, ûnderhâld. OPEX hinget ôf fan libbensdoer. It is ridlik om oan te nimmen dat it 3 jier is.
Ofhinklik fan hoe grut de yndividuele stikken binne yn 'e totale pie, wy moatte optimalisearje de djoerste, en lit de rest brûke alle oerbleaune middels sa effisjint mooglik.
Litte we sizze dat wy hawwe in besteande DC, der is in rack hichte fan H units (Bygelyks, H = 47), elektrisiteit per rack Prack (Prack = 6kW), en wy besletten in gebrûk h = 2U twa-ienheid tsjinners. Wy sille fuortsmite 2..4 ienheden út it rek foar skakelaars, patch panielen en organisators. Dy. fysyk, wy hawwe Sh = rounddown ((H-2..4) / h) tsjinners yn ús rack (d.w.s. Sh = rounddown ((47-4) / 2) = 21 tsjinners per rack). Lit ús ûnthâlde dizze Sh.
Yn it ienfâldige gefal binne alle tsjinners yn in rek identyk. Yn totaal, as wy folje in rack mei tsjinners, dan op elke tsjinner kinne wy besteegje gemiddeld de macht Pserv = Prack / Sh (Pserv = 6000W / 21 = 287W). Foar ienfâld negearje wy switch konsumpsje hjir.
Litte wy in stap oan 'e kant nimme en bepale wat de maksimale serverkonsumpsje Pmax is. As it heul ienfâldich, heul net effektyf en folslein feilich is, dan lêze wy wat skreaun is op 'e stroomfoarsjenning fan' e server - dit is it.
As it yngewikkelder, effisjinter is, dan nimme wy it TDP (thermysk ûntwerppakket) fan alle komponinten en summe it op (dit is net heul wier, mar it is mooglik).
Normaal kenne wy de TDP fan komponinten net (útsein de CPU), dus wy nimme de meast korrekte, mar ek de meast komplekse oanpak (wy hawwe in laboratoarium nedich) - wy nimme in eksperimintele tsjinner fan 'e fereaske konfiguraasje en laden it, bygelyks,, mei Linpack (CPU en ûnthâld) en fio (skiven), wy mjitte konsumpsje. As wy it serieus nimme, moatte wy ek de waarmste omjouwing yn 'e kâlde korridor meitsje tidens testen, om't dit sawol fanferbrûk as CPU-konsumpsje sil beynfloedzje. Wy krije it maksimale konsumpsje fan in spesifike tsjinner mei in spesifike konfiguraasje yn dizze spesifike betingsten ûnder dizze spesifike lading. Wy betsjutte gewoan dat nije systeemfirmware, in oare softwareferzje en oare betingsten it resultaat kinne beynfloedzje.
Dat, werom nei Pserv en hoe't wy it fergelykje mei Pmax. It is in kwestje fan begripen hoe't de tsjinsten wurkje en hoe sterk de nerven fan jo technyske direkteur binne.
As wy hielendal gjin risiko's nimme, leauwe wy dat alle servers tagelyk kinne begjinne om har maksimum te konsumearjen. Op itselde momint kin ien ynfier yn 'e DC foarkomme. Sels ûnder dizze betingsten moat infra tsjinst leverje, dus Pserv ≡ Pmax. Dit is in oanpak dêr't betrouberens perfoarst wichtich is.
As de techdirekteur net allinich tinkt oer ideale feiligens, mar ek oer it jild fan it bedriuw en dapper genôch is, dan kinne jo beslute dat
- Wy begjinne ús leveransiers te behearjen, yn it bysûnder, wy ferbiede pland ûnderhâld yn tiden fan plande pyklast om de daling yn ien ynfier te minimalisearjen;
- en / of ús arsjitektuer kinne jo ferlieze in rack / rige / DC, mar de tsjinsten fierder te wurkjen;
- en / of wy fersprieden de lading goed horizontaal oer de rekken, sadat ús tsjinsten sille nea springe nei maksimale konsumpsje yn ien rek allegear tegearre.
Hjir is it heul nuttich net allinich om te rieden, mar om konsumpsje te kontrolearjen en te witten hoefolle elektrisiteit de tsjinners eins konsumearje ûnder normale en pykomstannichheden. Dêrom, nei wat analyze, squeeze de tech-direkteur alles wat hy hat en seit: "wy meitsje in frijwillige beslút dat it maksimum te berikken gemiddelde fan it maksimale serverferbrûk per rack **safolle ** ûnder it maksimale konsumpsje is," betingst Pserv = 0.8* Pmax.
En dan kin in 6kW-rack net mear 16 tsjinners mei Pmax = 375W, mar 20 tsjinners mei Pserv = 375W * 0.8 = 300W. Dy. 25% mear tsjinners. Dit is in heul grutte besparring - wy hawwe ommers fuortendaliks 25% minder rekken nedich (en wy sille ek besparje op PDU's, skeakels en kabels). In serieus neidiel fan sa'n oplossing is dat wy konstant kontrolearje moatte dat ús oannames noch krekt binne. Dat de nije firmware ferzje net signifikant feroaret de wurking fan 'e fans en konsumpsje, dat de ûntwikkeling ynienen mei de nije release net begûn te brûken de tsjinners folle effisjinter (lês: se berikten gruttere lading en grutter konsumpsje op de tsjinner). Ommers, dan wurde sawol ús earste oannames as konklúzjes fuortendaliks ferkeard. Dit is in risiko dat moat wurde nommen ferantwurdlik (of mijd en dan betelje foar fansels underutilized rekkens).
In wichtige notysje - jo moatte besykje servers fan ferskate tsjinsten horizontaal oer rekken te fersprieden, as it mooglik is. Dit is nedich sadat situaasjes net bart as ien batch fan tsjinners oankomt foar ien tsjinst, de racks wurde fertikaal ynpakt mei it te fergrutsjen de "tichtens" (om't it is makliker op dy manier). Yn werklikheid docht bliken dat ien rack is fol mei identike low-load tsjinners fan deselde tsjinst, en de oare is fol mei like hege-load tsjinners. De kâns dat de twadde falt is signifikant heger, om't de load profyl is itselde, en alle tsjinners tegearre yn dit rack begjint te konsumearjen itselde bedrach as gefolch fan ferhege load.
Litte wy weromgean nei de ferdieling fan servers yn rekken. Wy hawwe sjoen nei fysike rackromte en krêftbeheiningen, litte wy no nei it netwurk sjen. Jo kinne skeakels brûke mei 24/32/48 N-poarten (wy hawwe bygelyks 48-poarte ToR-skeakels). Gelokkich binne d'r net in protte opsjes as jo net tinke oan break-out kabels. Wy beskôgje senario as wy hawwe ien switch per rack, ien switch foar twa of trije racks yn de Rnet groep. It liket my dat mear as trije rekken yn in groep al tefolle is, want... it probleem fan bekabeling tusken rekken wurdt folle grutter.
Dat, foar elk netwurkscenario (1, 2 of 3 racks yn in groep), fersprieden wy de servers ûnder de racks:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Dus, foar de opsje mei 2 rekken yn in groep:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 tsjinners per rack.
Wy beskôgje de oerbleaune opsjes op deselde manier:
Srack1 = 20
Srack3 = 16
En wy binne der hast. Wy telle it oantal rekken om al ús servers S te fersprieden (lit it 1000 wêze):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rekken
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rekken
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rekken
Dêrnei berekkenje wy de TCO foar elke opsje basearre op it oantal racks, it fereaske oantal skeakels, bekabeling, ensfh. Wy kieze de opsje wêr't TCO leger is. Winst!
Tink derom dat hoewol it fereaske oantal rekken foar opsjes 1 en 2 itselde is, sil har priis oars wêze, om't it oantal skeakels foar de twadde opsje is de helte safolle, en de lingte fan de fereaske kabels is langer.
PS As jo de mooglikheid hawwe om te spyljen mei de krêft per rek en de hichte fan it rek, nimt de fariabiliteit ta. Mar it proses kin wurde fermindere nei de hjirboppe beskreaune troch gewoan troch de opsjes te gean. Ja, d'r sille mear kombinaasjes wêze, mar noch in heul beheind oantal - de stroomfoarsjenning nei it rek foar berekkening kin wurde ferhege yn stappen fan 1 kW, typyske rekken komme yn in beheind oantal standertgrutte: 42U, 45U, 47U, 48U , 52u. En hjir kin Excel's What-If-analyse yn Data Table-modus helpe by berekkeningen. Wy sjogge nei de ûntfongen platen en selektearje it minimum.
Boarne: www.habr.com