I en af chatterne blev jeg stillet et spørgsmål:
— Er der noget, jeg kan læse om, hvordan man korrekt pakker servere ind i racks?
Jeg indså, at jeg ikke kendte sådan en tekst, så jeg skrev min egen.
For det første handler denne tekst om fysiske servere i fysiske datacentre (DC'er). For det andet mener vi, at der er ret mange servere: hundredtusindvis; for et mindre antal giver denne tekst ikke mening. For det tredje mener vi, at vi har tre begrænsninger: fysisk plads i rackene, strømforsyning pr. rack, og lad rackene stå i rækker, så vi kan bruge én ToR-switch til at forbinde servere i tilstødende racks.
Svaret på spørgsmålet afhænger i høj grad af, hvilken parameter vi optimerer, og hvad vi kan variere for at opnå det bedste resultat. For eksempel skal vi blot optage et minimum af plads for at efterlade mere til yderligere vækst. Eller måske har vi frihed til at vælge højden på stativerne, strøm pr. stativ, stikkontakter i PDU'en, antallet af stativer i en gruppe af switches (en kontakt til 1, 2 eller 3 stativer), længde på ledninger og trækarbejde ( dette er kritisk i enderne af rækkerne: med 10 stativer i træk og 3 stativer pr. switch, bliver du nødt til at trække ledningerne til en anden række eller underbruge portene i switchen) osv. osv. Separate historier: udvælgelse af servere og udvælgelse af DC'er, vi antager, at de er udvalgt.
Det ville være godt at forstå nogle af nuancerne og detaljerne, især det gennemsnitlige/maksimale forbrug af servere, og hvordan elektricitet leveres til os. Så hvis vi har en russisk strømforsyning på 230V og en fase pr. stativ, så kan en 32A maskine klare ~7kW. Lad os sige, at vi nominelt betaler for 6kW pr. rack. Hvis udbyderen kun måler vores forbrug for en række med 10 stativer, og ikke for hvert stativ, og hvis maskinen er indstillet til en betinget 7 kW cutoff, så kan vi teknisk set forbruge 6.9 kW i et enkelt stativ, 5.1 kW i et andet og alt vil være ok - ikke strafbart.
Normalt er vores hovedmål at minimere omkostningerne. Det bedste kriterium at måle er en reduktion i TCO (total cost of ownership). Den består af følgende dele:
- CAPEX: køb af DC-infrastruktur, servere, netværkshardware og kabler
- OPEX: DC leje, elforbrug, vedligeholdelse. OPEX afhænger af levetiden. Det er rimeligt at antage, at det er 3 år.
Alt efter hvor store de enkelte stykker er i den samlede tærte, skal vi optimere den dyreste, og lade resten bruge alle de resterende ressourcer så effektivt som muligt.
Lad os sige, at vi har en eksisterende DC, der er en rackhøjde på H-enheder (for eksempel H=47), elektricitet pr. rack-Prack (Prack=6kW), og vi besluttede at bruge h=2U-servere med to enheder. Vi fjerner 2..4 enheder fra stativet til kontakter, patchpaneler og organizers. De der. fysisk har vi Sh=rounddown((H-2..4)/h) servere i vores rack (dvs. Sh = rounddown((47-4)/2)=21 servere pr. rack). Lad os huske denne Sh.
I det simple tilfælde er alle servere i et rack identiske. I alt, hvis vi fylder et rack med servere, så kan vi på hver server i gennemsnit bruge strømmen Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). For nemheds skyld ignorerer vi switchforbrug her.
Lad os tage et skridt til side og bestemme, hvad det maksimale serverforbrug Pmax er. Hvis det er meget enkelt, meget ineffektivt og helt sikkert, så læser vi, hvad der står på serverens strømforsyning - det er det.
Hvis det er mere kompliceret, mere effektivt, så tager vi TDP (termisk designpakke) af alle komponenter og opsummerer det (dette er ikke særlig sandt, men det er muligt).
Normalt kender vi ikke komponenternes TDP (undtagen CPU'en), så vi tager den mest korrekte, men også den mest komplekse tilgang (vi har brug for et laboratorium) - vi tager en eksperimentel server med den nødvendige konfiguration og indlæser den, for eksempel med Linpack (CPU og hukommelse) og fio (diske) måler vi forbrug. Hvis vi tager det seriøst, skal vi også skabe det varmeste miljø i den kolde korridor under test, for det vil påvirke både blæserforbrug og CPU-forbrug. Vi får det maksimale forbrug af en specifik server med en specifik konfiguration under disse specifikke forhold under denne specifikke belastning. Vi mener blot, at ny systemfirmware, en anden softwareversion og andre forhold kan påvirke resultatet.
Så tilbage til Pserv, og hvordan vi sammenligner det med Pmax. Det er et spørgsmål om at forstå, hvordan tjenesterne fungerer, og hvor stærke din tekniske direktørs nerver er.
Hvis vi overhovedet ikke tager nogen risiko, tror vi, at alle servere samtidigt kan begynde at forbruge deres maksimale. I samme øjeblik kan der forekomme én input til DC. Selv under disse forhold skal infra levere service, så Pserv ≡ Pmax. Dette er en tilgang, hvor pålidelighed er absolut vigtig.
Hvis den tekniske direktør ikke kun tænker på ideel sikkerhed, men også på virksomhedens penge og er modig nok, så kan du beslutte, at
- Vi begynder at administrere vores leverandører, især forbyder vi planlagt vedligeholdelse på tidspunkter med planlagt spidsbelastning for at minimere faldet i én input;
- og/eller vores arkitektur giver dig mulighed for at miste et rack/række/DC, men tjenesterne fortsætter med at fungere;
- og/eller vi fordeler belastningen godt vandret ud over stativerne, så vores tjenester aldrig springer til maksimalt forbrug i ét stativ tilsammen.
Her er det meget nyttigt ikke bare at gætte, men at overvåge forbruget og vide, hvordan serverne rent faktisk forbruger strøm under normale og spidsbelastningsforhold. Derfor, efter nogle analyser, klemmer den tekniske direktør alt, hvad han har, og siger: "vi træffer en frivillig beslutning om, at det maksimalt opnåelige gennemsnit af det maksimale serverforbrug pr. rack er **så meget** under det maksimale forbrug," betinget Pserv = 0.8* Pmax.
Og så kan et 6kW rack ikke længere rumme 16 servere med Pmax = 375W, men 20 servere med Pserv = 375W * 0.8 = 300W. De der. 25 % flere servere. Det er en meget stor besparelse - vi har trods alt umiddelbart brug for 25% færre racks (og vi sparer også på PDU'er, switches og kabler). En alvorlig ulempe ved en sådan løsning er, at vi hele tiden skal overvåge, at vores forudsætninger stadig er korrekte. At den nye firmwareversion ikke ændrer væsentligt på driften af ventilatorerne og forbrug, at udviklingen pludselig med den nye udgivelse ikke begyndte at bruge serverne meget mere effektivt (læs: de opnåede større belastning og større forbrug på serveren). Når alt kommer til alt, så bliver både vores indledende antagelser og konklusioner umiddelbart forkerte. Dette er en risiko, der skal tages ansvarligt (eller undgås og derefter betale for åbenlyst underudnyttede stativer).
En vigtig note - du bør prøve at distribuere servere fra forskellige tjenester horisontalt på tværs af racks, hvis det er muligt. Dette er nødvendigt, så der ikke opstår situationer, når en batch af servere ankommer til en tjeneste, rackene er lodret pakket med det for at øge "densiteten" (fordi det er nemmere på den måde). I virkeligheden viser det sig, at det ene rack er fyldt med identiske low-load-servere af samme tjeneste, og det andet er fyldt med lige høj-load-servere. Sandsynligheden for det andet fald er betydeligt højere, fordi belastningsprofilen er den samme, og alle servere sammen i dette rack begynder at forbruge den samme mængde som følge af øget belastning.
Lad os vende tilbage til distributionen af servere i racks. Vi har set på fysisk rackplads og strømbegrænsninger, lad os nu se på netværket. Du kan bruge switches med 24/32/48 N-porte (for eksempel har vi 48-ports ToR-switche). Heldigvis er der ikke mange muligheder, hvis du ikke tænker på break-out kabler. Vi overvejer scenarier, hvor vi har én switch pr. rack, en switch til to eller tre racks i Rnet-gruppen. Det forekommer mig, at mere end tre stativer i en gruppe allerede er for meget, fordi... problemet med kabelføring mellem stativer bliver meget større.
Så for hvert netværksscenarie (1, 2 eller 3 racks i en gruppe), fordeler vi serverne mellem rackene:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Således for muligheden med 2 stativer i en gruppe:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servere pr. rack.
Vi overvejer de resterende muligheder på samme måde:
Srack1 = 20
Srack3 = 16
Og vi er der næsten. Vi tæller antallet af racks til at distribuere alle vores servere S (lad 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
Dernæst beregner vi TCO for hver mulighed baseret på antallet af stativer, det nødvendige antal kontakter, kabler osv. Vi vælger den mulighed, hvor TCO er lavere. Profit!
Bemærk, at selvom det krævede antal stativer til valg 1 og 2 er det samme, vil deres pris være anderledes, fordi antallet af kontakter for den anden mulighed er halvt så meget, og længden af de nødvendige kabler er længere.
PS Hvis du har mulighed for at spille med kraften pr. stativ og højden af stativet, øges variabiliteten. Men processen kan reduceres til den ovenfor beskrevne ved blot at gå gennem mulighederne. Ja, der vil være flere kombinationer, men stadig et meget begrænset antal - strømforsyningen til stativet til beregning kan øges i trin på 1 kW, typiske stativer kommer i et begrænset antal størrelser: 42U, 45U, 47U, 48U, 52U. Og her kan Excels What-If-analyse i Data Table-tilstand hjælpe med beregninger. Vi ser på de modtagne plader og vælger minimum.
Kilde: www.habr.com