I ett av forumen fick jag en frÄga:
â Finns det nĂ„got att lĂ€sa om hur man korrekt packar servrar i skĂ„p?
Jag insÄg att jag inte kÀnde till nÄgon sÄdan text, sÄ jag skrev min egen.
För det första handlar den hÀr texten om fysiska servrar i fysiska datacenter (DC). För det andra förutsÀtter vi att det finns mÄnga servrar: hundratals till tusentals, för ett mindre antal har denna text ingen mening. För det tredje antar vi att vi har tre begrÀnsningar: fysisk plats i skÄpen, strömförsörjning per skÄp, och lÄt oss sÀga att skÄpen stÄr i rader, sÄ vi kan anvÀnda en ToR-switch för att koppla samman servrar i angrÀnsande skÄp.
Svaret pÄ frÄgan beror mycket pÄ vilken parameter vi optimerar och vad vi kan variera för att uppnÄ det bÀsta resultatet. Till exempel kanske vi behöver minimera utrymmet för att ha mer plats för framtida tillvÀxt. Eller sÄ har vi friheten att vÀlja höjd pÄ skÄpen, effekt per skÄp, uttag i PDU, antal skÄp i gruppen av switchar (en switch för 1, 2 eller 3 skÄp), kabellÀngd och arbete med dragning (detta Àr kritiskt i Àndarna av raderna: med 10 skÄp i en rad och 3 skÄp pÄ en switch mÄste kablar dras till en annan rad eller underutnyttja portar i switchen), och sÄ vidare. Separata frÄgor: val av servrar och val av DC, vi antar att de redan har valts.
Det skulle vara bra att förstĂ„ vissa nyanser och detaljer, sĂ€rskilt medel-/maxförbrukning av servrar, och hur elektricitet försörjs. SĂ„, om vi har rysk strömförsörjning pĂ„ 230V och en fas per skĂ„p, kan en 32A automatsĂ€kring hĂ„lla ~7kW. Anta att vi nominellt betalar för 6kW per skĂ„p. Om leverantören mĂ€ter vĂ„r konsumtion endast för raden med 10 skĂ„p, och inte per skĂ„p, och om automaten ligger pĂ„ bristen av ungefĂ€r 7kW, dĂ„ kan vi tekniskt konsumera 6.9kW i ett givet skĂ„p, 5.1kW i ett annat och allt blir okej â inget straff.
Vanligtvis Ă€r vĂ„rt huvudmĂ„l att minimera kostnader. Den bĂ€sta kriteriet för mĂ€tning Ă€r att minska TCO (total cost of ownership â total Ă€gandekostnad). Den bestĂ„r av följande delar:
- CAPEX: inköp av DC-infrastruktur, servrar, nÀtverksutrustning och kabeldragning
- OPEX: hyra av DC, förbrukad elektricitet, underhÄll. OPEX beror pÄ livslÀngden. Det Àr rimligt att anta att den Àr lika med 3 Är.
Beroende pÄ hur stora de enskilda bitarna Àr i den totala kakan, mÄste vi optimera det dyraste, medan resten fÄr anvÀnda de ÄterstÄende resurserna sÄ effektivt som möjligt.
LÄt oss anta att vi har ett befintligt datacenter, det finns en rackhöjd H i enheter (för exemplet H=47), elektricitet per rack Prack (Prack=6kW), och vi har beslutat att anvÀnda h=2U tvÄenhetsservrar. Vi tar bort 2..4 enheter frÄn racken för switchar, patchpaneler och organisatörer. Det vill sÀga, fysiskt fÄr vi i racken plats för Sh=rounddown((H-2..4)/h) servrar (d.v.s. Sh = rounddown((47-4)/2)=21 servrar per rack). Kom ihÄg detta Sh.
I det enklaste fallet Àr alla servrar i racken identiska. SÄ, om vi fyller racken servrar, sÄ kan vi i genomsnitt spendera kraft Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) per server. För enkelhetens skull ignorerar vi hÀr strömförbrukningen hos switchen.
LĂ„t oss stega tillbaka och definiera vad det maximala konsumtionsbehovet för en server Pmax Ă€r. Om vi gör det mycket enkelt, mycket ineffektivt och helt sĂ€kert, kan vi lĂ€sa vad som stĂ„r pĂ„ strömförsörjningen till servern â det Ă€r det.
Om det Àr mer komplicerat, mer effektivt, sÄ tar vi TDP (thermal design package) för alla komponenter och summerar (detta Àr inte riktigt korrekt, men det gÄr att göra sÄ).
Vanligtvis kĂ€nner vi inte TDP för komponenterna (förutom CPU), sĂ„ vi tar den mest korrekta, men ocksĂ„ mest komplexa metoden (laboratorium behövs) â vi tar en experimentell server i önskad konfiguration och belastar den, till exempel med Linpack (CPU och minne) och fio (diskar), och mĂ€ter strömförbrukningen. Om vi tar det seriöst, mĂ„ste vi ocksĂ„ skapa den mest varma miljön i kallkorridoren under testerna, eftersom det pĂ„verkar bĂ„de flĂ€ktens förbrukning och CPU:n. Vi fĂ„r maximalt konsumtionsbehov för en specifik server med en specifik konfiguration under dessa specifika omstĂ€ndigheter under denna specifika belastning. TĂ€nk pĂ„ att en ny firmwareversion, annan mjukvaruversion eller andra förhĂ„llanden kan pĂ„verka resultatet.
SÄ, vi ÄtervÀnder till Pserv och hur vi kan jÀmföra det med Pmax. Det handlar om att förstÄ hur tjÀnster fungerar och hur starka nerverna hos din teknikchef Àr.
Om vi vill undvika risk helt och hÄllet, kan vi rÀkna med att alla servrar kan börja konsumera sitt maximum pÄ en gÄng. Samtidigt kan en givning i datacentret ske. Infrastrukturen mÄste tillhandahÄlla tjÀnsten under dessa förhÄllanden, sÄ Pserv ⥠Pmax. Detta Àr en metod dÀr absolut pÄlitlighet Àr avgörande.
Om teknikchefen inte bara tÀnker pÄ perfekt sÀkerhet utan ocksÄ pÄ företagets ekonomi och Àr tillrÀckligt modig, kan man besluta att
- vi börjar hantera vÄra leverantörer, sÀrskilt genom att förbjuda planerat underhÄll under förvÀntade toppbelastningsperioder för att minimera nedgÄngar vid en enda ingÄng;
- och/eller vÄr arkitektur tillÄter oss att förlora en rack/rad/datacenter, medan tjÀnsterna fortsÀtter att fungera;
- och/eller vi fördelar lasten jÀmnt mellan racken, sÄ vÄra tjÀnster hoppar aldrig upp till maxförbrukning i ett rack samtidigt.
HĂ€r Ă€r det mycket nyttigt att inte bara gissa utan att övervaka konsumtionen och veta hur mycket servrar faktiskt anvĂ€nder elektricitet under normala och toppbelastningsförhĂ„llanden. DĂ€rför, efter en viss analys, kom teknikchefen fram till att âvi tar ett beslut och bestĂ€mmer att det maximalt uppnĂ„eliga genomsnittet av servrarnas maxima per rack Ă€r **sĂ„ mycket** lĂ€gre Ă€n den maximala förbrukningenâ, i princip Pserv=0.8*Pmax.
Och dĂ„ kan det rymmas 20 servrar med Pserv = 375W * 0.8 = 300W i ett rack pĂ„ 6kW istĂ€llet för 16 servrar med Pmax = 375W. D.v.s. 25% fler servrar. Det Ă€r en stor besparing â vi behöver 25% fĂ€rre rack (och dĂ€r sparar vi ocksĂ„ pĂ„ PDU, switchar och kablar). En allvarlig nackdel med en sĂ„dan lösning Ă€r att vi mĂ„ste övervaka kontinuerligt att vĂ„ra antaganden fortfarande Ă€r korrekta. Att den nya firmwareversionen inte vĂ€sentligt förĂ€ndrar flĂ€ktarnas drift och förbrukning, och att utvecklingen plötsligt inte började anvĂ€nda servrar mer effektivt med den nya releasen (lĂ€s: uppnĂ„tt större belastning och högre förbrukning pĂ„ servern). För dĂ„ blir bĂ„de vĂ„ra ursprungliga antaganden och slutsatser felaktiga. Det Ă€r en risk som man mĂ„ste ta ansvar för (eller undvika, och dĂ„ betala för uppenbart underutnyttjade rack).
Ett viktigt meddelande â försök att distribuera servrar frĂ„n olika tjĂ€nster horisontellt över rack om möjligt. Detta Ă€r nödvĂ€ndigt för att undvika situationer dĂ€r en partii av servrar för en tjĂ€nst levereras, och racken fylls vertikalt för att öka 'densiteten' (eftersom det Ă€r enklare). I verkligheten blir en rack fylld med identiska, lĂ„ga belastningsservrar för en tjĂ€nst, medan en annan har identiskt högbelastade servrar. Sannolikheten för att den andra racken faller Ă€r avsevĂ€rt högre, eftersom belastningsprofilen Ă€r densamma, och alla servrar tillsammans i denna rack börjar konsumera lika mycket som resultat av den ökade belastningen.
LÄt oss ÄtergÄ till distributionen av servrar i rack. Vi har sett pÄ fysiska begrÀnsningar av utrymme i rack och begrÀnsningar av strömförsörjning, nu ska vi titta pÄ nÀtverket. Man kan anvÀnda switchar med 24/32/48 portar N (som exempel har vi 48-portars ToR-switchar). Lyckligtvis finns det inte sÄ mÄnga alternativ om man inte tÀnker pÄ break-out-kablar. Vi övervÀger scenarier nÀr vi har en switch per rack, en switch för tvÄ eller tre racks i en Rnet-grupp. Jag tycker att fler Àn tre racks i gruppen Àr för mycket, eftersom kabelhanteringsproblemet mellan racks blir betydande.
SÄ, för varje nÀtverkscenario (1, 2 eller 3 racks i gruppen) distribuerar vi servrarna för racks:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
SÄledes, för alternativet med 2 racks i gruppen:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servrar per rack.
PÄ samma sÀtt berÀknar vi de andra alternativen:
Srack1 = 20
Srack3 = 16
Och vi Àr praktiskt taget vid vÄrt mÄl. BerÀkna antalet racks för att distribuera alla vÄra servrar S (lÄt oss sÀga 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
DÀrefter berÀknar vi TCO för varje alternativ baserat pÄ antalet racks, nödvÀndigt antal switchar, kabeldragning, etc. Vi vÀljer det alternativ dÀr TCO Àr lÀgre. Profit!
Observera att Àven om det nödvÀndiga antalet racks för alternativen 1 och 2 Àr likadant, kommer deras pris att vara olika, eftersom antalet switchar för det andra alternativet Àr hÀlften sÄ mÄnga, medan lÀngden pÄ de nödvÀndiga kablarna Àr större.
P.S. Om det finns möjlighet att justera kapaciteten per rack och höjd, ökar variationen. Men processen kan sammanfattas till det som beskrivits ovan, genom att helt enkelt gĂ„ igenom alternativen. Ja, det kommer att finnas fler kombinationer, men Ă€ndĂ„ ett ganska begrĂ€nsat antal â strömförsörjningen per rack kan ökas med steg om 1 kW, och det finns ett begrĂ€nsat antal standardstorlekar för rack: 42U, 45U, 47U, 48U, 52U. HĂ€r kan Excels What-If analys i Data Table-lĂ€ge vara till hjĂ€lp för berĂ€kningarna. Vi tittar pĂ„ de genererade tabellerna och vĂ€ljer minimum.
KĂ€lla: habr.com
