In een van die geselsies is ek 'n vraag gevra:
— Is daar iets wat ek kan lees oor hoe om bedieners behoorlik in rakke te pak?
Ek het besef dat ek nie so 'n teks ken nie, so ek het my eie geskryf.
Eerstens handel hierdie teks oor fisiese bedieners in fisiese datasentrums (DC's). Tweedens glo ons dat daar nogal baie bedieners is: honderde duisende vir 'n kleiner aantal maak hierdie teks nie sin nie. Derdens dink ons dat ons drie beperkings het: fisiese spasie in die rakke, kragtoevoer per rek, en laat die rakke in rye staan sodat ons een ToR-skakelaar kan gebruik om bedieners in aangrensende rakke te koppel.
Die antwoord op die vraag hang baie af van watter parameter ons optimaliseer en wat ons kan verander om die beste resultaat te bereik. Ons moet byvoorbeeld net 'n minimum spasie opneem om meer vir verdere groei oor te laat. Of miskien het ons vryheid in die keuse van die hoogte van die rakke, krag per rek, voetstukke in die PDU, die aantal rakke in 'n groep skakelaars (een skakelaar vir 1, 2 of 3 rakke), lengte van drade en trekwerk ( dit is krities aan die punte van die rye: met 10 rakke in 'n ry en 3 rakke per skakelaar, sal jy die drade na 'n ander ry moet trek of die poorte in die skakelaar onderbenut), ens., ens. Afsonderlike stories: seleksie van bedieners en seleksie van DC's, ons sal aanvaar dat hulle gekies is.
Dit sal goed wees om sommige van die nuanses en besonderhede te verstaan, veral die gemiddelde/maksimum verbruik van bedieners, en hoe elektrisiteit aan ons verskaf word. Dus, as ons 'n Russiese kragtoevoer van 230V en een fase per rek het, dan kan 'n 32A-masjien ~7kW hanteer. Kom ons sê ons betaal nominaal vir 6kW per rek. As die verskaffer ons verbruik net meet vir 'n ry van 10 rakke, en nie vir elke rak nie, en as die masjien op 'n voorwaardelike 7 kW afsnypunt gestel is, dan kan ons tegnies gesproke 6.9 kW in 'n enkele rak verbruik, 5.1 kW in 'n ander en alles sal reg wees - nie strafbaar nie.
Gewoonlik is ons hoofdoel om koste te minimaliseer. Die beste maatstaf om te meet is 'n vermindering in TCO (totale koste van eienaarskap). Dit bestaan uit die volgende stukke:
- CAPEX: aankoop van DC-infrastruktuur, bedieners, netwerk hardeware en bekabeling
- OPEX: GS-huur, elektrisiteitsverbruik, onderhoud. OPEX hang af van dienslewe. Dit is redelik om te aanvaar dat dit 3 jaar is.
Afhangende van hoe groot die individuele stukke in die algehele pastei is, moet ons die duurste optimeer, en laat die res al die oorblywende hulpbronne so doeltreffend moontlik gebruik.
Kom ons sê ons het 'n bestaande GS, daar is 'n rekhoogte van H eenhede (byvoorbeeld, H=47), elektrisiteit per rek Prack (Prack=6kW), en ons het besluit om h=2U twee-eenheid bedieners te gebruik. Ons sal 2..4 eenhede van die rak verwyder vir skakelaars, pleisterpanele en organiseerders. Dié. fisies het ons Sh=rounddown((H-2..4)/h)-bedieners in ons rek (dit wil sê Sh = rounddown((47-4)/2)=21 bedieners per rek). Kom ons onthou hierdie Sh.
In die eenvoudige geval is alle bedieners in 'n rek identies. In totaal, as ons 'n rek met bedieners vul, kan ons op elke bediener gemiddeld die krag Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) spandeer. Vir eenvoud ignoreer ons skakelaarverbruik hier.
Kom ons neem 'n stap opsy en bepaal wat die maksimum bedienerverbruik Pmax is. As dit baie eenvoudig, baie ondoeltreffend en heeltemal veilig is, lees ons wat op die bediener se kragtoevoer geskryf is - dit is dit.
As dit meer kompleks en doeltreffender is, neem ons die TDP (termiese ontwerppakket) van alle komponente en som dit op (dit is nie baie waar nie, maar dit is moontlik).
Gewoonlik ken ons nie die TDP van komponente nie (behalwe vir die SVE), so ons neem die mees korrekte, maar ook die mees komplekse benadering (ons benodig 'n laboratorium) - ons neem 'n eksperimentele bediener van die vereiste konfigurasie en laai dit, byvoorbeeld, met Linpack (CPU en geheue) en fio (skywe), meet ons verbruik. As ons dit ernstig opneem, moet ons ook tydens toetse die warmste omgewing in die koue gang skep, want dit sal beide waaierverbruik en SVE-verbruik beïnvloed. Ons kry die maksimum verbruik van 'n spesifieke bediener met 'n spesifieke konfigurasie in hierdie spesifieke toestande onder hierdie spesifieke las. Ons bedoel bloot dat nuwe stelselfirmware, 'n ander sagtewareweergawe en ander toestande die resultaat kan beïnvloed.
So, terug na Pserv en hoe ons dit met Pmax vergelyk. Dit is 'n kwessie van verstaan hoe die dienste werk en hoe sterk jou tegniese direkteur se senuwees is.
As ons glad nie enige risiko's neem nie, glo ons dat alle bedieners gelyktydig hul maksimum kan begin verbruik. Op dieselfde oomblik kan een inset in die GS plaasvind. Selfs onder hierdie toestande moet infra diens lewer, dus Pserv ≡ Pmax. Dit is 'n benadering waar betroubaarheid absoluut belangrik is.
As die tegniese direkteur nie net aan ideale sekuriteit dink nie, maar ook aan die maatskappy se geld en dapper genoeg is, dan kan jy besluit dat
- Ons begin om ons verskaffers te bestuur, in die besonder, ons verbied geskeduleerde instandhouding in tye van beplande pieklading om die daling in een inset te minimaliseer;
- en/of ons argitektuur laat jou toe om 'n rek/ry/DC te verloor, maar die dienste bly werk;
- en/of ons versprei die vrag goed horisontaal oor die rakke, sodat ons dienste nooit tot maksimum verbruik in een rak alles saam sal spring nie.
Hier is dit baie nuttig om nie net te raai nie, maar om verbruik te monitor en te weet hoe die bedieners eintlik elektrisiteit verbruik onder normale en spitstoestande. Daarom, na 'n paar ontleding, druk die tegniese direkteur alles wat hy het en sê: "ons neem 'n wilsbesluit dat die maksimum haalbare gemiddelde van die maksimum bedienerverbruik per rek ** soveel** onder die maksimum verbruik is," voorwaardelik Pserv = 0.8* Pmaks.
En dan kan 'n 6kW-rek nie meer 16 bedieners met Pmax = 375W akkommodeer nie, maar 20 bedieners met Pserv = 375W * 0.8 = 300W. Dié. 25% meer bedieners. Dit is 'n baie groot besparing - ons het immers dadelik 25% minder rakke nodig (en ons sal ook op PDU's, skakelaars en kabels bespaar). 'n Ernstige nadeel van so 'n oplossing is dat ons voortdurend moet monitor dat ons aannames steeds korrek is. Dat die nuwe firmware weergawe nie die werking van die waaiers en verbruik noemenswaardig verander nie, dat die ontwikkeling skielik met die nuwe vrystelling nie die bedieners veel meer doeltreffend begin gebruik het nie (lees: hulle het groter las en groter verbruik op die bediener behaal). Immers, dan word beide ons aanvanklike aannames en gevolgtrekkings dadelik verkeerd. Dit is 'n risiko wat verantwoordelik geneem moet word (of vermy moet word en dan betaal vir ooglopend onderbenutte rakke).
'n Belangrike nota - jy moet probeer om bedieners van verskillende dienste horisontaal oor rakke te versprei, indien moontlik. Dit is nodig sodat situasies nie gebeur wanneer een bondel bedieners vir een diens opdaag nie, die rakke is vertikaal daarmee gepak om die "digtheid" te verhoog (want dit is makliker so). In werklikheid blyk dit dat een rek gevul is met identiese lae-lading-bedieners van dieselfde diens, en die ander is gevul met ewe hoë-lading-bedieners. Die waarskynlikheid van die tweede val is aansienlik hoër, want die lasprofiel is dieselfde, en alle bedieners saam in hierdie rek begin dieselfde hoeveelheid verbruik as gevolg van verhoogde las.
Kom ons keer terug na die verspreiding van bedieners in rakke. Ons het gekyk na fisiese rakspasie en kragbeperkings, kom ons kyk nou na die netwerk. Jy kan skakelaars met 24/32/48 N-poorte gebruik (ons het byvoorbeeld 48-poort ToR-skakelaars). Gelukkig is daar nie baie opsies as jy nie aan uitbreekkabels dink nie. Ons oorweeg scenario's wanneer ons een skakelaar per rek, een skakelaar vir twee of drie rakke in die Rnet-groep het. Dit lyk vir my of meer as drie rakke in 'n groep reeds te veel is, want... die probleem van kabels tussen rakke word baie groter.
Dus, vir elke netwerkscenario (1, 2 of 3 rakke in 'n groep), versprei ons die bedieners onder die rakke:
Srack = min(Sh, afronding(Prack/Pserv), afronding(N/Rnet))
Dus, vir die opsie met 2 rakke in 'n groep:
Srack2 = min(21, afronding(6000/300), afronding(48/2)) = min(21, 20, 24) = 20 bedieners per rek.
Ons oorweeg die oorblywende opsies op dieselfde manier:
Srack1 = 20
Srack3 = 16
En ons is amper daar. Ons tel die aantal rakke om al ons bedieners S te versprei (laat dit 1000 wees):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = afronding(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rakke
R2 = afronding(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rakke
R3 = afronding(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rakke
Vervolgens bereken ons die TCO vir elke opsie gebaseer op die aantal rakke, die vereiste aantal skakelaars, bekabeling, ens. Ons kies die opsie waar TCO laer is. Wins!
Let daarop dat alhoewel die vereiste aantal rakke vir opsies 1 en 2 dieselfde is, hul prys anders sal wees, want die aantal skakelaars vir die tweede opsie is die helfte soveel, en die lengte van die vereiste kabels is langer.
NS As jy die geleentheid het om met die krag per rek en die hoogte van die rek te speel, neem die wisselvalligheid toe. Maar die proses kan verminder word tot die een hierbo beskryf deur eenvoudig deur die opsies te gaan. Ja, daar sal meer kombinasies wees, maar steeds 'n baie beperkte aantal - die kragtoevoer na die rek vir berekening kan verhoog word in stappe van 1 kW, tipiese rakke kom in 'n beperkte aantal groottes: 42U, 45U, 47U, 48U, 52U. En hier kan Excel se What-As-analise in Data Table-modus help met berekeninge. Ons kyk na die ontvangde plate en kies die minimum.
Bron: will.com