In Ć©Ć©n van de gesprekken kreeg ik de vraag:
ā Is er iets om te lezen over hoe je servers correct in racks verpakt?
Ik begreep dat ik geen dergelijke tekst kende, dus schreef ik mijn eigen.
Ten eerste, deze tekst gaat over fysieke servers in fysieke datacenters (DC). Ten tweede, we gaan ervan uit dat er genoeg servers zijn: honderden tot duizenden, voor een kleiner aantal heeft deze tekst geen zin. Ten derde, we gaan ervan uit dat we drie beperkingen hebben: fysieke ruimte in de racks, stroomvoorziening per rack, en laten we zeggen dat de racks in rijen staan, zodat we Ć©Ć©n ToR-switch voor het aansluiten van servers in aangrenzende racks kunnen gebruiken.
Het antwoord op de vraag hangt sterk af van welke parameter we optimaliseren en wat we kunnen variƫren om het beste resultaat te bereiken. Bijvoorbeeld, we moeten alleen de minimale ruimte innemen, zodat er meer ruimte overblijft voor toekomstig groei. Of misschien hebben we vrijheid in de keuze van rackhoogte, vermogen per rack, sockets in de PDU, aantal racks in de switchgroep (ƩƩn switch voor 1, 2 of 3 racks), lengtes van kabels en kabelinstallaties (dit is cruciaal aan het einde van de rijen: bij 10 racks in een rij en 3 racks per switch moeten we kabels naar een andere rij trekken of ports in de switch onderbenutten), enzovoort. Specifieke verhalen: de keuze van servers en de keuze van DC's, laten we aannemen dat ze al geselecteerd zijn.
Het zou goed zijn om enkele nuances en details te begrijpen, in het bijzonder het gemiddelde/maximale energieverbruik van servers en hoe de elektriciteit aan ons wordt geleverd. Dus, als we Russische voeding van 230V en Ć©Ć©n fase per rack hebben, kan een automaat van 32A ongeveer 7kW aanhouden. Laten we aannemen dat we nominale kosten voor 6kW per rack betalen. Als de provider ons verbruik alleen meet op een rij van 10 racks, niet per rack, en als de automaat ingesteld is op een waarde van 7kW, dan kunnen we technisch gezien in een enkele rack 6.9kW verbruiken, in een andere 5.1kW, en alles zal in orde zijn ā ongestraft.
Gewoonlijk is ons belangrijkste doel het minimaliseren van kosten. De beste maatstaf voor meting is de vermindering van TCO (total cost of ownership ā totale eigendomskosten). Dit bestaat uit de volgende onderdelen:
- CAPEX: de aanschaf van DC-infrastructuur, servers, netwerkhardware en bekabeling.
- OPEX: huur van het DC, verbruikte elektriciteit, onderhoud. OPEX hangt af van de levensduur. Het is redelijk om dit gelijk te veronderstellen aan 3 jaar.
Afhankelijk van hoe groot de afzonderlijke stukken in de totale taart zijn, moeten we het duurste optimaliseren en de rest kan alle overgebleven middelen zo efficiƫnt mogelijk gebruiken.
Stel dat we al een bestaand datacenter hebben, er is hoogte van het rek H eenheden (bijvoorbeeld H=47), elektriciteit per rek Prack (Prack=6kW), en we besloten om h=2U twee-eenheid servers te gebruiken. We halen 2..4 eenheden uit het rek voor switches, patchpanelen en organisatoren. Dat wil zeggen, fysiek kunnen we in het rek Sh=rounddown((H-2..4)/h) servers plaatsen (dat wil zeggen Sh = rounddown((47-4)/2)=21 servers per rek). Laten we dit onthouden als Sh.
In de eenvoudigste situatie zijn alle servers in een rek gelijk. Dus, als we het rek vullen, servers, dan kunnen we gemiddeld per server vermogen Pserv=Prack/Sh besteden (Pserv = 6000W/21 = 287W). Voor de eenvoud negeren we hier het stroomverbruik van de switch.
Laten we een stap opzij zetten en vaststellen wat het maximale verbruik van een server Pmax is. In eenvoudige termen, heel inefficiĆ«nt en volledig veilig, staat op de voeding van de server ā dat is het.
Als het ingewikkelder en efficiƫnter is, dan nemen we de TDP (thermal design package) van alle componenten en tellen deze op (dit is niet helemaal juist, maar zo kan het ook).
Gewoonlijk kennen we de TDP van de componenten (behalve die van de CPU) niet, dus we nemen de meest correcte, maar ook de meest complexe aanpak (daar is een laboratorium voor nodig) ā we nemen een experimentele server van de juiste configuratie en belasten deze, bijvoorbeeld met Linpack (CPU en geheugen) en fio (disks), meten het verbruik. Als we serieus willen aanpakken, moeten we ook de warmste omgeving creĆ«ren in de koude gang tijdens de tests, omdat dit invloed heeft op zowel het verbruik van de ventilatoren als op dat van de CPU. We krijgen het maximale verbruik van een specifieke server met een specifieke configuratie onder deze specifieke omstandigheden met deze specifieke belasting. Onthoud gewoon dat een nieuwe firmware, een andere softwareversie of andere omstandigheden het resultaat kunnen beĆÆnvloeden.
Dus, we keren terug naar Pserv en hoe we dit kunnen vergelijken met Pmax. Dit is een kwestie van begrip van de werking van diensten en hoe sterk de zenuwen van je technische directeur zijn.
Als we helemaal geen risico willen lopen, beschouwen we dat alle servers gelijktijdig hun maximum kunnen gaan verbruiken. Op dat moment kan er Ć©Ć©n invoer in het datacenter zijn. De infrastructuur en onder deze voorwaarden moeten de dienst verlenen, dus Pserv ā” Pmax. Dit is de benadering waarbij betrouwbaarheid absoluut cruciaal is.
Als de technische directeur niet alleen denkt aan perfecte beveiliging, maar ook aan het geld van het bedrijf en voldoende moed heeft, kan worden besloten dat
- we beginnen met het beheren van onze leveranciers, met name door het plannen van onderhoud te verbieden tijdens verwachte piekmomenten om de impact van een enkele invoer te minimaliseren;
- en/of onze architectuur in staat is om een rack/rij/data-center te verliezen, terwijl de diensten doorgaan met functioneren;
- en/of we de belasting goed horizontaal over de racks verdelen, zodat onze diensten nooit naar de maximale consumptie in Ć©Ć©n rack allemaal tegelijk pieken.
Het is hier erg nuttig om niet alleen te gissen, maar om het verbruik te monitoren en te weten hoe servers daadwerkelijk elektriciteit verbruiken in normale en piekcondities. Daarom, na enige analyse, drukt de technische directeur alles samen wat hij heeft en zegt: 'we nemen de beslissing dat het maximaal haalbare gemiddelde van de maximale verbruikspiek van servers per rack op **zoveel** lager is dan het maximale verbruik', bij benadering Pserv=0.8*Pmax.
En dan passen er in een rack van 6kW al niet meer 16 servers met Pmax = 375W, maar 20 servers met Pserv = 375W * 0.8 = 300W. Dat is dus 25% meer servers. Dit is een enorme besparing - want ook hebben we 25% minder racks nodig (en dat bespaart ook op PDU's, switches en kabels). Een serieus nadeel van deze oplossing is dat we voortdurend moeten monitoren of onze aannames nog steeds kloppen. Of de nieuwe firmware geen significante invloed heeft op de werking van de ventilatoren en het verbruik, of de ontwikkeling met een nieuwe release ineens de servers veel efficiƫnter is gaan gebruiken (lees: dat we een hogere belasting en een hoger verbruik per server hebben bereikt). Want dan worden zowel onze initiƫle aannames als de conclusies direct onjuist. Dit is een risico dat we verantwoordelijk moeten nemen (of vermijden en dan betalen voor duidelijk onderbelaste racks).
Een belangrijke opmerking: probeer servers van verschillende diensten horizontaal over de rekken te verdelen, indien mogelijk. Dit is nodig om te voorkomen dat een partij servers voor Ć©Ć©n dienst arriveert en de rekken verticaal ermee worden gevuld om de 'dichtheid' te verhogen (omdat dit gemakkelijker is). In werkelijkheid resulteert dit in Ć©Ć©n rek dat vol zit met gelijksoortige servers met een lage belasting van dezelfde dienst, en een andere met gelijksoortige servers met een hoge belasting. De kans op uitval van de tweede is aanzienlijk groter, aangezien het belastingprofiel identiek is en alle servers samen in dit rek bij een verhoogde belasting evenveel gaan verbruiken.
Laten we terugkomen op de verdeling van servers in rekken. We hebben de fysieke ruimtebeperkingen in het rek en de beperkingen van de voeding bekeken, laten we nu ook naar het netwerk kijken. We kunnen switches gebruiken met 24/32/48 poorten N (ter illustratie hebben we 48-poorts ToR switches). Gelukkig zijn er niet veel opties, tenzij we nadenken over break-out kabels. We bekijken scenario's waarin we Ć©Ć©n switch per rek hebben, of Ć©Ć©n switch voor twee of drie rekken in een Rnet-groep. Ik denk niet dat meer dan drie rekken in een groep echt handig is, omdat de bekabelingsproblematiek tussen rekken aanzienlijk toeneemt.
Dus voor elk netwerkscenario (1, 2 of 3 rekken in een groep) verdelen we de servers over de rekken:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Dus voor het scenario met 2 rekken in de groep:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servers per rek.
Evenzo berekenen we de andere opties:
Srack1 = 20
Srack3 = 16
En we zijn bijna bij ons doel. We berekenen het aantal rekken dat nodig is om al onze servers S te verdelen (laten we zeggen 1000):
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 de TCO voor elke optie op basis van het aantal rekken, het benodigde aantal switches, bekabeling, enzovoort. We kiezen de optie met de laagste TCO. Profit!
Laten we opmerken dat, hoewel het benodigde aantal rekken voor opties 1 en 2 hetzelfde is, de kosten verschillend zullen zijn, aangezien het aantal switches voor de tweede optie de helft is, terwijl de lengte van de benodigde kabels groter is.
P.S. Als er de mogelijkheid is om te spelen met de kracht en de hoogte van de rack, neemt de variabiliteit toe. Maar het proces kan worden teruggebracht tot het hierboven beschreven, door simpelweg de opties te bekijken. Ja, er zullen meer combinaties zijn, maar het aantal blijft toch vrij beperkt ā de voeding voor het rack kan met stapjes van 1 kW worden verhoogd, en er zijn doorgaans een beperkt aantal standaard rackformaten: 42U, 45U, 47U, 48U, 52U. Voor de berekening kan de What-If-analyse in Excel in de modus Gegevens Tabel helpen. We kijken naar de verkregen tabellen en kiezen de minimumwaarde.
Bron: habr.com
