I en av chattarna fick jag en fråga:
— Finns det något jag kan läsa om hur man korrekt packar servrar i rack?
Jag insåg att jag inte kunde en 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 tror vi att det finns ganska många servrar: hundratusentals; för ett mindre antal är denna text inte vettig. För det tredje anser vi att vi har tre begränsningar: fysiskt utrymme i racken, strömförsörjning per rack, och låt racken stå i rader så att vi kan använda en ToR-switch för att ansluta servrar i intilliggande rack.
Svaret på frågan beror mycket på vilken parameter vi optimerar och vad vi kan variera för att uppnå bästa resultat. Till exempel behöver vi bara ta ett minimum av utrymme för att lämna mer för ytterligare tillväxt. Eller så kanske vi har frihet att välja höjd på rack, effekt per rack, uttag i PDU, antal rack i en grupp av switchar (en omkopplare för 1, 2 eller 3 rack), längd på ledningar och dragarbete ( detta är kritiskt i ändarna av raderna: med 10 rack i rad och 3 rack per switch, måste du dra ledningarna till en annan rad eller underutnyttja portarna i switchen), etc., etc. Separata berättelser: urval av servrar och urval av DC:er, vi antar att de är valda.
Det skulle vara bra att förstå några av nyanserna och detaljerna, i synnerhet den genomsnittliga/maximala förbrukningen av servrar och hur elen levereras till oss. Så om vi har en rysk strömförsörjning på 230V och en fas per rack, så kan en 32A-maskin klara ~7kW. Låt oss säga att vi nominellt betalar för 6kW per rack. Om leverantören mäter vår förbrukning endast för en rad med 10 rack, och inte för varje rack, och om maskinen är inställd på ett villkorligt 7 kW cutoff, så kan vi tekniskt sett förbruka 6.9 kW i ett enda rack, 5.1 kW i ett annat och allt kommer att ordna sig - inte straffbart.
Vanligtvis är vårt huvudmål att minimera kostnaderna. Det bästa kriteriet att mäta är en minskning av TCO (total cost of ownership). Den består av följande delar:
- CAPEX: köp av DC-infrastruktur, servrar, nätverkshårdvara och kablage
- OPEX: DC-hyra, elförbrukning, underhåll. OPEX beror på livslängden. Det är rimligt att anta att det är 3 år.
Beroende på hur stora de enskilda bitarna är i den totala pajen måste vi optimera den dyraste, och låta resten använda alla återstående resurser så effektivt som möjligt.
Låt oss säga att vi har en befintlig DC, det finns en rackhöjd på H-enheter (till exempel H=47), el per rack Prack (Prack=6kW), och vi bestämde oss för att använda h=2U tvåenhetsservrar. Vi kommer att ta bort 2..4 enheter från stället för strömbrytare, patchpaneler och organisatörer. De där. fysiskt har vi Sh=rounddown((H-2..4)/h)-servrar i vårt rack (dvs Sh = rounddown((47-4)/2)=21 servrar per rack). Låt oss komma ihåg denna Sh.
I det enkla fallet är alla servrar i ett rack identiska. Totalt, om vi fyller ett rack med servrar, så kan vi på varje server spendera i genomsnitt kraften Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). För enkelhetens skull ignorerar vi switchförbrukning här.
Låt oss ta ett steg åt sidan och bestämma vad den maximala serverförbrukningen Pmax är. Om det är väldigt enkelt, väldigt ineffektivt och helt säkert, läser vi vad som står på serverns strömförsörjning - det här är det.
Om det är mer komplext och mer effektivt tar vi TDP (termisk designpaket) för alla komponenter och summerar det (detta är inte riktigt sant, men det är möjligt).
Vanligtvis vet vi inte TDP för komponenter (förutom CPU), så vi tar det mest korrekta, men också det mest komplexa tillvägagångssättet (vi behöver ett laboratorium) - vi tar en experimentell server med den nödvändiga konfigurationen och laddar den, till exempel, med Linpack (CPU och minne) och fio (diskar) mäter vi förbrukningen. Om vi tar det på allvar behöver vi även skapa den varmaste miljön i den kalla korridoren under tester, eftersom detta kommer att påverka både fläktförbrukning och CPU-förbrukning. Vi får den maximala förbrukningen av en specifik server med en specifik konfiguration under dessa specifika förhållanden under denna specifika belastning. Vi menar helt enkelt att ny systemprogramvara, en annan mjukvaruversion och andra förhållanden kan påverka resultatet.
Så, tillbaka till Pserv och hur vi jämför det med Pmax. Det handlar om att förstå hur tjänsterna fungerar och hur starka din tekniska chefs nerver är.
Om vi inte tar några risker alls tror vi att alla servrar samtidigt kan börja konsumera sitt maximala. I samma ögonblick kan en ingång till DC inträffa. Även under dessa förhållanden måste infra tillhandahålla service, så Pserv ≡ Pmax. Detta är ett tillvägagångssätt där tillförlitlighet är absolut viktig.
Om den tekniska direktören inte bara tänker på idealisk säkerhet, utan också på företagets pengar och är modig nog, kan du bestämma det
- Vi börjar hantera våra leverantörer, i synnerhet förbjuder vi planerat underhåll vid tidpunkter med planerad toppbelastning för att minimera minskningen av en ingång;
- och/eller vår arkitektur gör att du kan förlora ett rack/rad/DC, men tjänsterna fortsätter att fungera;
- och/eller vi fördelar lasten väl horisontellt över ställen, så att våra tjänster aldrig kommer att hoppa till maximal förbrukning i ett ställ tillsammans.
Här är det mycket användbart inte bara att gissa, utan att övervaka förbrukningen och veta hur servrarna faktiskt förbrukar el under normala och höga förhållanden. Därför, efter lite analys, klämmer den tekniska direktören allt han har och säger: "vi fattar ett frivilligt beslut att det maximalt möjliga genomsnittet av den maximala serverförbrukningen per rack är **så mycket** under den maximala förbrukningen," villkorligt Pserv = 0.8* Pmax.
Och då kan ett 6kW-rack inte längre rymma 16 servrar med Pmax = 375W, utan 20 servrar med Pserv = 375W * 0.8 = 300W. De där. 25 % fler servrar. Detta är en mycket stor besparing - trots allt behöver vi omedelbart 25% färre rack (och vi kommer även att spara på PDU, switchar och kablar). En allvarlig nackdel med en sådan lösning är att vi hela tiden måste övervaka att våra antaganden fortfarande stämmer. Att den nya firmwareversionen inte nämnvärt förändrar driften av fläktarna och förbrukningen, att utvecklingen plötsligt med den nya releasen inte började använda servrarna mycket mer effektivt (läs: de uppnådde större belastning och större förbrukning på servern). När allt kommer omkring blir båda våra initiala antaganden och slutsatser omedelbart felaktiga. Detta är en risk som måste tas på ett ansvarsfullt sätt (eller undvikas och sedan betala för uppenbart underutnyttjade ställ).
En viktig anmärkning - du bör försöka distribuera servrar från olika tjänster horisontellt över rack, om möjligt. Detta är nödvändigt för att situationer inte ska uppstå när en grupp servrar anländer för en tjänst, racken är vertikalt packade med den för att öka "densiteten" (eftersom det är lättare så). I verkligheten visar det sig att det ena racket är fyllt med identiska lågbelastningsservrar av samma tjänst, och det andra är fyllt med lika högbelastningsservrar. Sannolikheten för det andra fallet är betydligt högre, eftersom belastningsprofilen är densamma, och alla servrar tillsammans i detta rack börjar förbruka samma mängd som ett resultat av ökad belastning.
Låt oss återgå till distributionen av servrar i rack. Vi har tittat på fysiskt rackutrymme och effektbegränsningar, låt oss nu titta på nätverket. Du kan använda switchar med 24/32/48 N-portar (vi har till exempel 48-portars ToR-switchar). Lyckligtvis finns det inte många alternativ om du inte tänker på brytkablar. Vi överväger scenarier när vi har en switch per rack, en switch för två eller tre rack i Rnet-gruppen. Det verkar för mig som att mer än tre ställ i en grupp redan är för mycket, eftersom... problemet med kablage mellan stativ blir mycket större.
Så för varje nätverksscenario (1, 2 eller 3 rack i en grupp) fördelar vi servrarna mellan racken:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Således, för alternativet med 2 ställ i en grupp:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servrar per rack.
Vi överväger de återstående alternativen på samma sätt:
Srack1 = 20
Srack3 = 16
Och vi är nästan framme. Vi räknar antalet rack för att distribuera alla våra servrar S (låt det vara 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
Därefter beräknar vi TCO för varje alternativ baserat på antalet rack, det erforderliga antalet omkopplare, kablar etc. Vi väljer alternativet där TCO är lägre. Vinst!
Observera att även om det erforderliga antalet ställ för alternativ 1 och 2 är detsamma, kommer deras pris att vara annorlunda, eftersom antalet omkopplare för det andra alternativet är hälften så mycket, och längden på de nödvändiga kablarna är längre.
PS Om du har möjlighet att spela med kraften per rack och höjden på racken ökar variationen. Men processen kan reduceras till den som beskrivs ovan genom att helt enkelt gå igenom alternativen. Ja, det kommer att finnas fler kombinationer, men fortfarande ett mycket begränsat antal - strömförsörjningen till racket för beräkning kan ökas i steg om 1 kW, typiska rack finns i ett begränsat antal standardstorlekar: 42U, 45U, 47U, 48U , 52U. Och här kan Excels What-If-analys i datatabellläge hjälpa till med beräkningar. Vi tittar på de mottagna plåtarna och väljer minimum.
Källa: will.com