In een van de chats werd mij een vraag gesteld:
— Kan ik iets lezen over hoe ik servers op de juiste manier in racks kan inpakken?
Ik besefte dat ik zo’n tekst niet kende, dus schreef ik mijn eigen tekst.
Ten eerste gaat deze tekst over fysieke servers in fysieke datacenters (DC’s). Ten tweede zijn we van mening dat er behoorlijk veel servers zijn: honderdduizenden; voor een kleiner aantal heeft deze tekst geen zin. Ten derde zijn we van mening dat we drie beperkingen hebben: fysieke ruimte in de racks, stroomvoorziening per rack, en de racks in rijen laten staan, zodat we één ToR-switch kunnen gebruiken om servers in aangrenzende racks aan te sluiten.
Het antwoord op de vraag hangt sterk af van welke parameter we optimaliseren en waarmee we kunnen variëren om het beste resultaat te bereiken. We hoeven bijvoorbeeld slechts een minimum aan ruimte in beslag te nemen, zodat er meer overblijft voor verdere groei. Of misschien hebben we wel vrijheid in de keuze van de hoogte van de racks, het vermogen per rack, stopcontacten in de PDU, het aantal racks in een groep schakelaars (één schakelaar voor 1, 2 of 3 racks), lengte van de draden en trekwerkzaamheden ( dit is van cruciaal belang aan de uiteinden van de rijen: met 10 racks op een rij en 3 racks per switch, zult u de draden naar een andere rij moeten trekken of de poorten in de switch te weinig gebruiken), enz., enz. Aparte verhalen: selectie van servers en selectie van DC's, we gaan ervan uit dat ze geselecteerd zijn.
Het zou goed zijn om enkele nuances en details te begrijpen, met name het gemiddelde/maximale verbruik van servers en hoe elektriciteit aan ons wordt geleverd. Dus als we een Russische stroomvoorziening van 230V en één fase per rack hebben, dan kan een 32A-machine ~7kW aan. Laten we zeggen dat we nominaal 6 kW per rack betalen. Als de aanbieder ons verbruik alleen meet voor een rij van 10 racks, en niet voor elk rack, en als de machine is ingesteld op een voorwaardelijke uitschakeling van 7 kW, dan kunnen we technisch gezien 6.9 kW verbruiken in een enkel rack, 5.1 kW in een ander rack en XNUMX kW in een ander rack. alles komt goed - niet strafbaar.
Meestal is ons hoofddoel het minimaliseren van de kosten. Het beste meetcriterium is een verlaging van de TCO (total cost of ownership). Het bestaat uit de volgende stukken:
- CAPEX: aankoop van DC-infrastructuur, servers, netwerkhardware en bekabeling
- OPEX: DC-huur, elektriciteitsverbruik, onderhoud. OPEX is afhankelijk van de levensduur. Het is redelijk om aan te nemen dat dit 3 jaar is.
Afhankelijk van hoe groot de individuele stukken in de totale taart zijn, moeten we de duurste optimaliseren en de rest alle resterende hulpbronnen zo efficiënt mogelijk laten gebruiken.
Laten we zeggen dat we een bestaande DC hebben, er is een rackhoogte van H-eenheden (bijvoorbeeld H=47), elektriciteit per rack Prack (Prack=6kW), en we hebben besloten om h=2U servers met twee eenheden te gebruiken. Voor schakelaars, patchpanelen en organizers halen wij 2..4 units uit het rack. Die. fysiek hebben we Sh=rounddown((H-2..4)/h) servers in ons rack (d.w.z. Sh = rounddown((47-4)/2)=21 servers per rack). Laten we dit onthouden Sh.
In het eenvoudige geval zijn alle servers in een rack identiek. Als we in totaal een rack vullen met servers, kunnen we op elke server gemiddeld het vermogen Pserv=Prack/Sh besteden (Pserv = 6000W/21 = 287W). Voor de eenvoud laten we hier het switchverbruik buiten beschouwing.
Laten we een stap opzij zetten en bepalen wat het maximale serververbruik Pmax is. Als het heel eenvoudig, heel ineffectief en volkomen veilig is, dan lezen we wat er op de voeding van de server staat - dit is het.
Als het ingewikkelder en efficiënter is, nemen we het TDP (thermisch ontwerppakket) van alle componenten en vatten dit samen (dit is niet helemaal waar, maar het is mogelijk).
Meestal kennen we de TDP van componenten (behalve de CPU) niet, dus nemen we de meest correcte, maar ook de meest complexe benadering (we hebben een laboratorium nodig) - we nemen een experimentele server met de vereiste configuratie en laden deze, Met Linpack (CPU en geheugen) en fio (schijven) meten we bijvoorbeeld het verbruik. Als we het serieus nemen, moeten we tijdens tests ook de warmste omgeving in de koude gang creëren, omdat dit zowel het ventilatorverbruik als het CPU-verbruik zal beïnvloeden. We krijgen het maximale verbruik van een specifieke server met een specifieke configuratie in deze specifieke omstandigheden onder deze specifieke belasting. We bedoelen eenvoudigweg dat nieuwe systeemfirmware, een andere softwareversie en andere omstandigheden het resultaat kunnen beïnvloeden.
Dus terug naar Pserv en hoe we het vergelijken met Pmax. Het is een kwestie van begrijpen hoe de dienstverlening werkt en hoe sterk de zenuwen van je technisch directeur zijn.
Als we helemaal geen risico nemen, denken we dat alle servers tegelijkertijd hun maximum kunnen gaan verbruiken. Op hetzelfde moment kan er één ingang in de DC plaatsvinden. Ook onder deze omstandigheden moet infra service verlenen, dus Pserv ≡ Pmax. Dit is een aanpak waarbij betrouwbaarheid absoluut belangrijk is.
Als de technisch directeur niet alleen aan de ideale veiligheid denkt, maar ook aan het geld van het bedrijf en dapper genoeg is, dan kun je dat beslissen
- We beginnen onze leveranciers te managen, in het bijzonder verbieden we gepland onderhoud op momenten van geplande piekbelasting om de daling van één input te minimaliseren;
- en/of dankzij onze architectuur kunt u een rack/rij/DC kwijtraken, maar blijven de services werken;
- en/of we spreiden de belasting goed horizontaal over de racks, zodat onze dienstverlening nooit in één rack naar het maximale verbruik springt.
Hier is het erg handig om niet alleen te raden, maar ook om het verbruik te volgen en te weten hoe de servers daadwerkelijk elektriciteit verbruiken onder normale en piekomstandigheden. Daarom perst de technisch directeur, na enige analyse, alles wat hij heeft uit en zegt: “we nemen een vrijwillige beslissing dat het maximaal haalbare gemiddelde van het maximale serververbruik per rack **zoveel** onder het maximale verbruik ligt”, voorwaardelijk Pserv = 0.8* Pmax.
En dan kan een 6kW-rack niet langer plaats bieden aan 16 servers met Pmax = 375W, maar aan 20 servers met Pserv = 375W * 0.8 = 300W. Die. 25% meer servers. Dit is een hele grote besparing; we hebben immers direct 25% minder racks nodig (en we besparen ook nog eens op PDU's, switches en kabels). Een ernstig nadeel van een dergelijke oplossing is dat we voortdurend moeten monitoren of onze aannames nog kloppen. Dat de nieuwe firmwareversie de werking van de ventilatoren en het verbruik niet noemenswaardig verandert, dat de ontwikkeling met de nieuwe release de servers plotseling niet veel efficiënter begon te gebruiken (lees: ze bereikten een grotere belasting en een groter verbruik op de server). Dan worden zowel onze aanvankelijke aannames als onze conclusies onmiddellijk onjuist. Dit is een risico dat op verantwoorde wijze moet worden genomen (of moet worden vermeden en vervolgens moet worden betaald voor duidelijk onderbenutte racks).
Een belangrijke opmerking: probeer, indien mogelijk, servers van verschillende services horizontaal over racks te verdelen. Dit is nodig zodat er geen situaties ontstaan waarin één partij servers arriveert voor één dienst; de racks worden er verticaal mee gevuld om de “dichtheid” te vergroten (omdat het op die manier gemakkelijker is). In werkelijkheid blijkt dat het ene rack gevuld is met identieke servers met een lage belasting van dezelfde dienst, en het andere met servers met een even hoge belasting. De kans op een tweede val is aanzienlijk groter, omdat het belastingsprofiel is hetzelfde en alle servers samen in dit rack beginnen dezelfde hoeveelheid te verbruiken als gevolg van de verhoogde belasting.
Laten we terugkeren naar de distributie van servers in racks. We hebben gekeken naar fysieke rackruimte en stroombeperkingen, laten we nu naar het netwerk kijken. U kunt switches gebruiken met 24/32/48 N-poorten (we hebben bijvoorbeeld ToR-switches met 48 poorten). Gelukkig zijn er niet veel opties als je niet aan breakout-kabels denkt. We overwegen scenario's waarin we één switch per rack hebben, één switch voor twee of drie racks in de Rnet-groep. Het lijkt mij dat meer dan drie racks in een groep al te veel is, want... het probleem van de bekabeling tussen racks wordt veel groter.
Voor elk netwerkscenario (1, 2 of 3 racks in een groep) verdelen we de servers dus over de racks:
Srack = min(Sh, naar beneden afgerond(Prack/Pserv), naar beneden afgerond(N/Rnet))
Dus voor de optie met 2 racks in een groep:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servers per rack.
We beschouwen de resterende opties op dezelfde manier:
Srack1 = 20
Srack3 = 16
En we zijn er bijna. We tellen het aantal racks om al onze servers S te verdelen (laat het 1000 zijn):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rekken
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rekken
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rekken
Vervolgens berekenen we per optie de TCO op basis van het aantal racks, het benodigde aantal switches, bekabeling etc. Wij kiezen voor de optie waarbij de TCO lager is. Winst!
Houd er rekening mee dat, hoewel het vereiste aantal racks voor opties 1 en 2 hetzelfde is, de prijs ervan zal verschillen het aantal schakelaars voor de tweede optie is de helft en de lengte van de benodigde kabels is langer.
PS Als je de mogelijkheid hebt om te spelen met het vermogen per rack en de hoogte van het rack, neemt de variabiliteit toe. Maar het proces kan worden teruggebracht tot het hierboven beschreven proces door simpelweg de opties te doorlopen. Ja, er zullen meer combinaties zijn, maar nog steeds een zeer beperkt aantal - de stroomtoevoer naar het rack voor berekening kan worden verhoogd in stappen van 1 kW, typische racks zijn verkrijgbaar in een beperkt aantal standaardformaten: 42U, 45U, 47U, 48U , 52U. En hier kan de What-If-analyse van Excel in de gegevenstabelmodus helpen bij berekeningen. We kijken naar de ontvangen borden en kiezen het minimum.
Bron: www.habr.com