Optimalisering av distribusjonen av servere på tvers av rack

I en av chattene ble jeg stilt et spørsmål:

— Er det noe jeg kan lese om hvordan jeg pakker servere riktig inn i rack?

Jeg innså at jeg ikke kunne en slik tekst, så jeg skrev min egen.

For det første handler denne teksten om fysiske servere i fysiske datasentre (DC). For det andre tror vi at det er ganske mange servere: hundretusenvis; for et mindre antall gir ikke denne teksten mening. For det tredje vurderer vi at vi har tre begrensninger: fysisk plass i rackene, strømforsyning per rack, og la rackene stå i rader slik at vi kan bruke én ToR-svitsj til å koble til servere i tilstøtende rack.

Svaret på spørsmålet avhenger i stor grad av hvilken parameter vi optimaliserer og hva vi kan variere for å oppnå best resultat. For eksempel trenger vi bare å ta opp et minimum av plass for å legge igjen mer for videre vekst. Eller kanskje vi har frihet til å velge høyden på stativene, strøm per stativ, stikkontakter i PDU, antall stativer i en gruppe brytere (en bryter for 1, 2 eller 3 stativer), lengde på ledninger og trekkarbeid ( dette er kritisk i endene av radene: med 10 stativer på rad og 3 stativer per bryter, må du trekke ledningene til en annen rad eller underbruke portene i bryteren), osv. osv. Separate historier: utvalg av servere og utvalg av DC-er, vi vil anta at de er valgt.

Det ville være greit å forstå noen av nyansene og detaljene, spesielt gjennomsnittlig/maksimalt forbruk av servere, og hvordan elektrisitet leveres til oss. Så hvis vi har en russisk strømforsyning på 230V og en fase per stativ, så kan en 32A-maskin håndtere ~7kW. La oss si at vi nominelt betaler for 6kW per stativ. Hvis leverandøren måler forbruket vårt kun for en rad med 10 stativer, og ikke for hvert stativ, og hvis maskinen er satt til en betinget 7 kW cutoff, så kan vi teknisk sett forbruke 6.9 ​​kW i et enkelt stativ, 5.1 kW i et annet og alt vil være ok - ikke straffbart.

Vanligvis er hovedmålet vårt å minimere kostnadene. Det beste kriteriet å måle er en reduksjon i TCO (total cost of ownership). Den består av følgende deler:

  • CAPEX: kjøp av DC-infrastruktur, servere, nettverksmaskinvare og kabling
  • OPEX: DC-leie, strømforbruk, vedlikehold. OPEX avhenger av levetiden. Det er rimelig å anta at det er 3 år.

Optimalisering av distribusjonen av servere på tvers av rack

Avhengig av hvor store de enkelte bitene er i den samlede kaken, må vi optimalisere den dyreste, og la resten bruke alle de gjenværende ressursene så effektivt som mulig.

La oss si at vi har en eksisterende DC, det er en rackhøyde på H-enheter (for eksempel H=47), elektrisitet per rack Prack (Prack=6kW), og vi bestemte oss for å bruke h=2U to-enhetsservere. Vi vil fjerne 2..4 enheter fra stativet for brytere, patchpaneler og organisatorer. De. fysisk har vi Sh=rounddown((H-2..4)/h)-servere i racket vårt (dvs. Sh = rounddown((47-4)/2)=21 servere per rack). La oss huske denne Sh.

I det enkle tilfellet er alle servere i et rack identiske. Totalt, hvis vi fyller et rack med servere, kan vi på hver server bruke i gjennomsnitt kraften Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). For enkelhets skyld ser vi bort fra bryterforbruket her.

La oss ta et skritt til side og bestemme hva det maksimale serverforbruket Pmax er. Hvis det er veldig enkelt, veldig ineffektivt og helt trygt, så leser vi hva som er skrevet på serverens strømforsyning - dette er det.

Hvis det er mer komplekst og mer effektivt, tar vi TDP (termisk designpakke) for alle komponentene og summerer det opp (dette er ikke veldig sant, men det er mulig).

Vanligvis vet vi ikke TDP for komponenter (bortsett fra CPU), så vi tar den mest korrekte, men også den mest komplekse tilnærmingen (vi trenger et laboratorium) - vi tar en eksperimentell server med den nødvendige konfigurasjonen og laster den, for eksempel med Linpack (CPU og minne) og fio (disker) måler vi forbruk. Tar vi det på alvor må vi også skape det varmeste miljøet i den kalde korridoren under tester, for dette vil påvirke både vifteforbruk og CPU-forbruk. Vi får maksimalt forbruk av en spesifikk server med en spesifikk konfigurasjon under disse spesifikke forholdene under denne spesifikke belastningen. Vi mener ganske enkelt at ny systemfastvare, en annen programvareversjon og andre forhold kan påvirke resultatet.

Så tilbake til Pserv og hvordan vi sammenligner det med Pmax. Det er et spørsmål om å forstå hvordan tjenestene fungerer og hvor sterke nervene til den tekniske direktøren din er.

Hvis vi ikke tar noen risiko i det hele tatt, tror vi at alle servere samtidig kan begynne å konsumere maksimalt. I samme øyeblikk kan det forekomme én inngang til DC. Selv under disse forholdene må infra yte service, så Pserv ≡ Pmax. Dette er en tilnærming hvor pålitelighet er absolutt viktig.

Hvis den tekniske direktøren ikke bare tenker på ideell sikkerhet, men også på selskapets penger og er modig nok, kan du bestemme det

  • Vi begynner å administrere leverandørene våre, spesielt forbyr vi planlagt vedlikehold til tider med planlagt toppbelastning for å minimere fallet i én inngang;
  • og/eller arkitekturen vår lar deg miste et stativ/rad/DC, men tjenestene fortsetter å fungere;
  • og/eller vi fordeler lasten godt horisontalt over stativene, slik at tjenestene våre aldri hopper til maksimalt forbruk i ett stativ til sammen.

Her er det veldig nyttig ikke bare å gjette, men å overvåke forbruket og vite hvordan serverne faktisk forbruker strøm under normale og toppforhold. Derfor, etter litt analyse, klemmer den tekniske direktøren alt han har og sier: "vi tar en frivillig beslutning om at det maksimalt oppnåelige gjennomsnittet av det maksimale serverforbruket per rack er **så mye** under det maksimale forbruket," betinget Pserv = 0.8* Pmaks.

Og så kan et 6kW-rack ikke lenger romme 16 servere med Pmax = 375W, men 20 servere med Pserv = 375W * 0.8 = 300W. De. 25 % flere servere. Dette er en veldig stor besparelse - vi trenger tross alt umiddelbart 25 % mindre stativer (og vi vil også spare på PDUer, brytere og kabler). En alvorlig ulempe med en slik løsning er at vi hele tiden må følge med på at våre forutsetninger fortsatt stemmer. At den nye fastvareversjonen ikke endrer driften av viftene og forbruk nevneverdig, at utviklingen plutselig med den nye utgivelsen ikke begynte å bruke serverne mye mer effektivt (les: de oppnådde større belastning og større forbruk på serveren). Tross alt, da blir både våre første antakelser og konklusjoner umiddelbart feil. Dette er en risiko som må tas ansvarlig (eller unngås og deretter betale for åpenbart underutnyttede stativer).

En viktig merknad - du bør prøve å distribuere servere fra forskjellige tjenester horisontalt på tvers av rack, hvis mulig. Dette er nødvendig for at situasjoner ikke skal skje når en gruppe med servere ankommer for én tjeneste, rackene er vertikalt pakket med den for å øke "tettheten" (fordi det er enklere på den måten). I virkeligheten viser det seg at det ene racket er fylt med identiske lavbelastningsservere av samme tjeneste, og det andre er fylt med like høybelastningsservere. Sannsynligheten for det andre fallet er betydelig høyere, fordi belastningsprofilen er den samme, og alle servere sammen i dette racket begynner å forbruke like mye som følge av økt belastning.

La oss gå tilbake til distribusjonen av servere i rack. Vi har sett på fysisk rackplass og strømbegrensninger, la oss nå se på nettverket. Du kan bruke svitsjer med 24/32/48 N-porter (for eksempel har vi 48-porters ToR-svitsjer). Heldigvis er det ikke mange alternativer hvis du ikke tenker på bruddkabler. Vi vurderer scenarier når vi har en bryter per rack, en bryter for to eller tre rack i Rnet-gruppen. Det virker for meg som om mer enn tre stativer i en gruppe allerede er for mye, fordi... problemet med kabling mellom stativer blir mye større.

Så for hvert nettverksscenario (1, 2 eller 3 rack i en gruppe), fordeler vi serverne mellom rackene:

Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))

For alternativet med 2 stativer i en gruppe:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servere per rack.

Vi vurderer de resterende alternativene på samme måte:

Srack1 = 20
Srack3 = 16

Og vi er nesten der. Vi teller antall rack for å distribuere alle våre servere S (la det være 1000):

R = roundup(S / (Srack * Rnet)) * Rnet

R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 stativer

R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 stativer

R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 stativer

Deretter beregner vi TCO for hvert alternativ basert på antall stativer, nødvendig antall brytere, kabling osv. Vi velger alternativet der TCO er lavere. Profitt!

Merk at selv om det nødvendige antallet stativer for alternativene 1 og 2 er det samme, vil prisen være forskjellig, fordi antall brytere for det andre alternativet er halvparten så mye, og lengden på de nødvendige kablene er lengre.

PS Hvis du har mulighet til å spille med kraften per stativ og høyden på stativet, øker variasjonen. Men prosessen kan reduseres til den som er beskrevet ovenfor ved ganske enkelt å gå gjennom alternativene. Ja, det vil være flere kombinasjoner, men fortsatt et svært begrenset antall - strømforsyningen til stativet for beregning kan økes i trinn på 1 kW, typiske stativer kommer i et begrenset antall standardstørrelser: 42U, 45U, 47U, 48U , 52U. Og her kan Excels What-If-analyse i datatabellmodus hjelpe med beregninger. Vi ser på de mottatte platene og velger minimum.

Kilde: www.habr.com

Legg til en kommentar