Txatetako batean galdera bat egin zidaten:
β Ba al dago zerbitzariak bastidoreetan behar bezala ontziratzeari buruz irakur dezakedan zerbait?
Konturatu nintzen ez nuela halako testurik ezagutzen, beraz, nirea idatzi nuen.
Lehenik eta behin, testu hau datu-zentro fisikoen (DC) zerbitzari fisikoei buruzkoa da. Bigarrenik, zerbitzari dezente daudela uste dugu: ehunka-mila; kopuru txikiago batentzat testu honek ez du zentzurik. Hirugarrenik, hiru muga ditugula uste dugu: espazio fisikoa racketan, rack bakoitzeko elikadura-hornidura eta rack-ak errenkadetan uztea, ToR etengailu bat erabili ahal izateko ondoko racketako zerbitzariak konektatzeko.
Galderaren erantzuna zer parametro optimizatzen ari garen eta emaitza onena lortzeko zer alda dezakegun araberakoa da. Esaterako, gutxieneko espazioa hartu besterik ez dugu behar gehiago hazteko gehiago uzteko. Edo agian askatasuna dugu bastidoreen altuera, bastidore bakoitzeko potentzia, PDUko entxufeak, etengailu talde bateko bastidore kopurua (etengailu bat 1, 2 edo 3 bastidorentzako), kableen luzera eta tiraka lanak ( hau funtsezkoa da errenkaden muturretan: 10 bastidor errenkadan eta etengailu bakoitzeko 3 bastidorekin, hariak beste ilara batera tiratu beharko dituzu edo switch-eko atakak gutxietsi), etab., etab. Istorio bereiziak: zerbitzarien hautaketa eta DCen hautaketa, hautatuak direla suposatuko dugu.
Ondo legoke Γ±abardura eta xehetasun batzuk ulertzea, bereziki zerbitzarien batez besteko/gehieneko kontsumoa, eta elektrizitatea nola hornitzen zaigun. Beraz, Errusiako 230V-ko elikadura-hornidura eta rack bakoitzeko fase bat baditugu, orduan 32A-ko makina batek ~ 7kW kudea dezake. Demagun nominalki rack bakoitzeko 6 kW ordaintzen ditugula. Hornitzaileak gure kontsumoa 10 bastidoreko ilara baterako bakarrik neurtzen badu, eta ez bastidore bakoitzeko, eta makina baldintzapeko 7 kW-ko eten batean ezartzen bada, teknikoki 6.9 kW kontsumi ditzakegu bastidore bakar batean, 5.1 kW beste batean eta dena ondo egongo da - ez da zigortua.
Normalean gure helburu nagusia kostuak gutxitzea da. Neurtzeko irizpiderik onena TCO (jabetzaren kostu osoa) murriztea da. Pieza hauek osatzen dute:
- CAPEX: DC azpiegitura, zerbitzariak, sareko hardwarea eta kableatzea erostea
- OPEX: DC alokairua, elektrizitate kontsumoa, mantenua. OPEX zerbitzu-bizitzaren araberakoa da. Arrazoizkoa da 3 urtekoa dela pentsatzea.
Pieza indibidualak tarta orokorrean zenbateraino diren kontuan hartuta, garestiena optimizatu behar dugu, eta gainerakoek gainerako baliabide guztiak ahalik eta modu eraginkorrenean erabiltzen utzi.
Demagun lehendik dagoen DC bat dugula, H unitateko rack altuera bat dagoela (adibidez, H=47), rack bakoitzeko elektrizitatea Prack (Prack=6kW), eta h=2U bi unitateko zerbitzariak erabiltzea erabaki dugu. Etengailuetarako, adabaki paneletarako eta antolatzaileetarako 2..4 unitate kenduko ditugu racktik. Horiek. fisikoki, Sh=rounddown((H-2..4)/h) zerbitzariak ditugu gure rack-ean (hau da, Sh = rounddown((47-4)/2)=21 zerbitzari rack bakoitzeko). Gogora dezagun Sh.
Kasu sinplean, rack bateko zerbitzari guztiak berdinak dira. Guztira, rack bat zerbitzariz betetzen badugu, zerbitzari bakoitzean batez beste Pserv=Prack/Sh potentzia gastatu dezakegu (Pserv = 6000W/21 = 287W). Sinpletasunerako, hemen etengailuen kontsumoa alde batera uzten dugu.
Eman dezagun pauso bat alde batera eta zehaztu zein den Pmax zerbitzariaren gehienezko kontsumoa. Oso erraza, oso eraginkorra eta guztiz segurua bada, zerbitzariaren elikadura-iturrian idatzitakoa irakurriko dugu - hau da.
Konplikatuagoa, eraginkorragoa bada, osagai guztien TDP (diseinu termikoko paketea) hartu eta laburbildu egiten dugu (hau ez da oso egia, baina posible da).
Normalean ez dugu osagaien TDP ezagutzen (PUZa izan ezik), eta, beraz, ikuspegi zuzenena hartzen dugu, baina baita konplexuena ere (laborategi bat behar dugu) - behar den konfigurazioko zerbitzari esperimental bat hartu eta kargatzen dugu, adibidez, Linpack-ekin (CPU eta memoria) eta fio (diskoak) , kontsumoa neurtzen dugu. Serio hartzen badugu, korridore hotzean ere girorik beroena sortu behar dugu probetan, horrek eragingo duelako bai haizagailuen kontsumoan, bai CPU kontsumoan. Konfigurazio zehatz bat duen zerbitzari zehatz baten gehieneko kontsumoa lortzen dugu baldintza zehatz hauetan karga zehatz honetan. Besterik gabe, esan nahi dugu sistemaren firmware berriak, software bertsio ezberdin batek eta beste baldintza batzuek emaitzan eragina izan dezaketela.
Beraz, itzuli Pserv-era eta nola alderatzen dugun Pmax-ekin. Zerbitzuek nola funtzionatzen duten eta zure zuzendari teknikoaren nerbioak zein indartsuak diren ulertzea da kontua.
Inongo arriskurik hartzen ez badugu, zerbitzari guztiak aldi berean gehienez kontsumitzen has daitezkeela uste dugu. Momentu berean, DCn sarrera bat gerta daiteke. Baldintza hauetan ere, infrak zerbitzua eman behar du, beraz Pserv β‘ Pmax. Fidagarritasuna guztiz garrantzitsua den ikuspegia da.
Zuzendari teknologikoak segurtasun ezin hobean ez ezik, konpainiaren diruan ere pentsatzen badu eta nahikoa ausarta bada, orduan erabaki dezakezu.
- Gure saltzaileak kudeatzen hasiak gara, bereziki, programatutako mantentze-lanak debekatzen ari gara aurreikusitako karga gailurren garaietan, sarrera batean jaitsiera minimizatzeko;
- eta/edo gure arkitekturak rack/ilara/DC bat galtzeko aukera ematen du, baina zerbitzuek funtzionatzen jarraitzen dute;
- eta/edo karga ondo zabaltzen dugu horizontalki bastidoreetan zehar, beraz, gure zerbitzuak ez dira inoiz gehienezko kontsumora igoko rack bakarrean.
Hemen oso erabilgarria da asmatzeko ez ezik, kontsumoa kontrolatzeko eta zerbitzariek benetan nola kontsumitzen duten elektrizitatea baldintza normaletan eta puntakoetan jakitea. Hori dela eta, azterketa batzuk egin ondoren, zuzendari teknologikoak daukan guztia estutu eta zera dio: "nahitaezko erabakia hartzen dugu rack bakoitzeko zerbitzariaren gehienezko kontsumoaren gehieneko batez bestekoa **hainbeste** kontsumo maximoaren azpitik dagoela", baldintzatuta Pserv = 0.8* Pmax.
Eta orduan 6kW-ko rack batek ezin du jada Pmax = 16W duten 375 zerbitzari hartu, baina Pserv = 20W * 375 = 0.8W duten 300 zerbitzari. Horiek. %25 zerbitzari gehiago. Hau oso aurrezpen handia da - azken finean, berehala %25 rack gutxiago behar dugu (eta PDU, etengailu eta kableetan ere aurreztuko dugu). Konponbide horren desabantaila larria da etengabe kontrolatu behar dugula gure hipotesiak zuzenak direla. Firmwarearen bertsio berriak ez duela nabarmen aldatzen haizagailuen eta kontsumoaren funtzionamendua, bertsio berriarekin bat-batean garapena ez zela zerbitzariak askoz eraginkorrago erabiltzen hasi (irakurri: karga handiagoa eta kontsumo handiagoa lortu zuten zerbitzarian). Azken finean, gure hasierako hipotesiak eta ondorioak berehala oker bihurtzen dira. Erantzukizunez hartu behar den arriskua da (edo saihestu eta gero, jakina, gutxi erabilitako rackak ordaindu).
Ohar garrantzitsu bat - ahal izanez gero zerbitzu ezberdinetako zerbitzariak horizontalean banatzen saiatu beharko zenuke bastidoretan. Hau beharrezkoa da egoerak gerta ez daitezen zerbitzari sorta bat zerbitzu baterako iristen denean, bastidoreak bertikalki josita daude "dentsitatea" handitzeko (errazagoa baita horrela). Egia esan, bastidore bat zerbitzu bereko karga baxuko zerbitzari berdinez beteta dagoela ematen du, eta bestea karga altuko zerbitzariez beteta dagoela. Bigarren erorketaren probabilitatea nabarmen handiagoa da, zeren karga-profila berdina da, eta rack honetan zerbitzari guztiak batera kopuru bera kontsumitzen hasten dira karga handitzearen ondorioz.
Itzuli gaitezen zerbitzarien banaketara racketan. Rack-en espazio fisikoa eta potentzia-mugak aztertu ditugu, orain ikus dezagun sarea. 24/32/48 N atakak dituzten etengailuak erabil ditzakezu (adibidez, 48 atakako ToR etengailuak ditugu). Zorionez, ez dago aukera asko apurtzeko kableetan pentsatzen ez baduzu. Rack bakoitzeko etengailu bat, Rnet taldean bizpahiru racktarako etengailu bat dugunean agertokiak aztertzen ari gara. Talde batean hiru bastidore baino gehiago jada gehiegi direla iruditzen zait, zeren... bastidoreen arteko kablearen arazoa askoz handiagoa da.
Beraz, sareko agertoki bakoitzeko (1, 2 edo 3 bastidore talde batean), zerbitzariak bastidoreen artean banatzen ditugu:
Srack = min (Sh, rounddown(Prack/Pserv), rounddown (N/Rnet))
Horrela, talde batean 2 bastidorekin aukeran:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 zerbitzari rack bakoitzeko.
Gainerako aukerak modu berean kontuan hartzen ditugu:
Srack1 = 20
Srack3 = 16
Eta ia hor gaude. Gure zerbitzari guztiak S banatzeko bastidore kopurua zenbatzen dugu (izan bedi 1000):
R = biribilketa (S / (Srack * Rnet)) * Rnet
R1 = biribilketa (1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = biribilketa (1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = biribilketa (1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
Ondoren, aukera bakoitzerako TCO kalkulatuko dugu bastidore kopuruaren, behar den etengailu kopuruaren, kablearen eta abarren arabera. TCO txikiagoa den aukera aukeratzen dugu. Irabazi!
Kontuan izan 1 eta 2 aukeretarako beharrezkoa den bastidore kopurua berdina den arren, haien prezioa ezberdina izango dela bigarren aukerarako etengailu kopurua erdia da, eta beharrezkoak diren kableen luzera handiagoa da.
PS Rack bakoitzeko potentziarekin eta rackaren altuerarekin jolasteko aukera baduzu, aldakortasuna handitzen da. Baina prozesua goian deskribatutakora murriztu daiteke, aukeren bidez besterik gabe. Bai, konbinazio gehiago egongo dira, baina oraindik kopuru oso mugatua - kalkulurako rack-aren elikadura hornidura 1 kW-ko urratsetan handitu daiteke, rack tipikoak tamaina estandar kopuru mugatu batean daude: 42U, 45U, 47U, 48U. , 52U. Eta hemen Excel-en What-If analisiak Datu Taula moduan kalkuluetan lagun dezake. Jasotako plakak begiratu eta gutxienekoa aukeratzen dugu.
Iturria: www.habr.com