Viename iš pokalbių man buvo užduotas klausimas:
– Ar galiu ką nors perskaityti apie tai, kaip tinkamai supakuoti serverius į stelažus?
Supratau, kad tokio teksto nežinau, todėl parašiau savo.
Pirma, šis tekstas yra apie fizinius serverius fiziniuose duomenų centruose (DC). Antra, manome, kad serverių yra gana daug: šimtai tūkstančių; mažesniam skaičiui šis tekstas neturi prasmės. Trečia, manome, kad turime tris apribojimus: fizinę vietą stelažuose, maitinimo šaltinį ir leisti stovams stovėti eilėmis, kad galėtume naudoti vieną ToR jungiklį serveriams prijungti gretimuose stovuose.
Atsakymas į klausimą labai priklauso nuo to, kokį parametrą optimizuojame ir ką galime keisti, kad pasiektume geriausią rezultatą. Pavyzdžiui, mums tereikia užimti mažiausiai vietos, kad liktų daugiau tolimesniam augimui. O gal turime laisvę pasirinkti stelažų aukštį, stelažo galią, lizdus PDU, stelažų skaičių jungiklių grupėje (vienas jungiklis 1, 2 arba 3 stovams), laidų ilgį ir tempimo darbus ( tai labai svarbu eilučių galuose: 10 stelažų iš eilės ir 3 stelažus vienam jungikliui, turėsite traukti laidus į kitą eilutę arba nepakankamai išnaudoti jungiklio prievadus) ir pan. Atskiros istorijos: serverių parinkimas ir DC pasirinkimas, manysime, kad jie pasirinkti.
Būtų gerai, kad suprastumėte kai kuriuos niuansus ir smulkmenas, ypač vidutinę/maksimalią serverių suvartojimą ir kaip mums tiekiama elektra. Taigi, jei turime rusišką maitinimą 230V ir viena fazė vienai stelažai, tai 32A mašina gali atlaikyti ~7kW. Tarkime, mes nominaliai mokame už 6 kW už stovą. Jei tiekėjas mūsų suvartojimą matuoja tik 10 stelažų eilutei, o ne kiekvienam stovui, o mašinai nustatyta sąlyginė 7 kW galia, tai techniškai galime sunaudoti 6.9 kW viename stove, 5.1 kW kitoje ir viskas bus gerai - nebaudžiama.
Paprastai pagrindinis mūsų tikslas yra sumažinti išlaidas. Geriausias vertinimo kriterijus yra TCO (bendros nuosavybės kainos) sumažinimas. Jis susideda iš šių dalių:
- CAPEX: nuolatinės srovės infrastruktūros, serverių, tinklo techninės įrangos ir kabelių pirkimas
- OPEX: DC nuoma, elektros suvartojimas, priežiūra. OPEX priklauso nuo tarnavimo laiko. Pagrįsta manyti, kad tai yra 3 metai.
Priklausomai nuo to, kokio dydžio atskiri gabaliukai yra bendrame pyrage, turime optimizuoti brangiausią, o likusiems leisti kuo efektyviau panaudoti visus likusius išteklius.
Tarkime, kad turime esamą DC, yra H vienetų stovo aukštis (pavyzdžiui, H=47), elektra vienam stovui Prack (Prack=6kW), ir nusprendėme naudoti h=2U dviejų blokų serverius. Išimsime iš 2..4 vnt. jungiklių, pataisų skydelių ir organizatorių stovo. Tie. fiziškai, mes turime Sh=rounddown((H-2..4)/h) serverius savo stove (t. y. Sh = rounddown((47-4)/2) = 21 serveris viename stove). Prisiminkime šį Sh.
Paprastu atveju visi stovo serveriai yra identiški. Iš viso, jei užpildysime stelažą serveriais, tai kiekviename serveryje galime vidutiniškai išleisti galią Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Paprastumo dėlei čia nepaisome jungiklio suvartojimo.
Ženkime į šoną ir nustatykime, koks yra maksimalus serverio suvartojimas Pmax. Jei tai labai paprasta, labai neveiksminga ir visiškai saugu, tada perskaitome, kas parašyta ant serverio maitinimo šaltinio - štai kas.
Jei jis sudėtingesnis ir efektyvesnis, paimame visų komponentų TDP (šiluminio dizaino paketą) ir susumuojame (tai nelabai tiesa, bet įmanoma).
Paprastai mes nežinome komponentų TDP (išskyrus CPU), todėl imamės teisingiausio, bet kartu ir sudėtingiausio požiūrio (reikia laboratorijos) – paimame reikiamos konfigūracijos eksperimentinį serverį ir jį įkeliame, pavyzdžiui, su Linpack (CPU ir atmintis) ir fio (diskais) matuojame suvartojimą. Jei žiūrime rimtai, bandymų metu taip pat turime sukurti šilčiausią aplinką šaltame koridoriuje, nes tai turės įtakos tiek ventiliatorių, tiek procesoriaus suvartojimui. Mes gauname maksimalų konkretaus serverio su konkrečia konfigūracija suvartojimą šiomis konkrečiomis sąlygomis, esant šiai specifinei apkrovai. Turime omenyje tiesiog tai, kad nauja sistemos programinė įranga, kita programinės įrangos versija ir kitos sąlygos gali turėti įtakos rezultatui.
Taigi, grįžkime prie Pserv ir kaip mes jį palyginame su Pmax. Svarbu suprasti, kaip veikia paslaugos ir kokie stiprūs jūsų techninio direktoriaus nervai.
Jei visiškai nerizikuojame, manome, kad visi serveriai vienu metu gali pradėti vartoti maksimaliai. Tuo pačiu metu gali įvykti vienas įėjimas į DC. Net ir tokiomis sąlygomis infra turi teikti paslaugą, todėl Pserv ≡ Pmax. Tai metodas, kai patikimumas yra labai svarbus.
Jei technologijų direktorius galvoja ne tik apie idealų saugumą, bet ir apie įmonės pinigus ir yra pakankamai drąsus, tuomet galite nuspręsti, kad
- Pradedame valdyti savo pardavėjus, ypač uždraudžiame planinę techninę priežiūrą planuojamos didžiausios apkrovos metu, kad sumažintume vienos įvesties sumažėjimą;
- ir (arba) mūsų architektūra leidžia prarasti stovą / eilutę / DC, tačiau paslaugos veikia ir toliau;
- ir (arba) gerai paskirstome krovinį horizontaliai per lentynas, todėl mūsų paslaugos niekada nepasieks maksimalaus suvartojimo vienoje lentynoje.
Čia labai naudinga ne tik spėlioti, bet ir stebėti suvartojimą bei žinoti, kaip serveriai realiai vartoja elektros energiją įprastomis ir piko sąlygomis. Todėl, atlikęs tam tikrą analizę, technologijų direktorius išspaudžia viską, ką turi, ir sako: „Mes priimame savo norą sprendimą, kad maksimalus pasiekiamas maksimalaus serverio suvartojimo vienam stovui vidurkis yra **tiek** mažesnis už maksimalų suvartojimą“, sąlyginai Pserv = 0.8* Pmax.
Ir tada 6kW stovas nebetelpa 16 serverių, kurių Pmax = 375W, bet 20 serverių su Pserv = 375W * 0.8 = 300W. Tie. 25% daugiau serverių. Tai labai didelis sutaupymas – juk iš karto reikia 25% mažiau stelažų (taip pat sutaupysime PDU, jungiklius ir kabelius). Rimtas tokio sprendimo trūkumas yra tai, kad turime nuolat stebėti, ar mūsų prielaidos vis dar teisingos. Kad naujoji programinės aparatinės įrangos versija ženkliai nepakeistų ventiliatorių veikimo ir vartojimo, kad kūrimas staiga su nauja versija nepradėjo daug efektyviau naudoti serverių (skaitykite: jie pasiekė didesnę apkrovą ir didesnį suvartojimą serveryje). Juk tada ir mūsų pradinės prielaidos, ir išvados iškart tampa neteisingos. Tai rizika, kurios reikia imtis atsakingai (arba vengti, o tada mokėti už akivaizdžiai nepakankamai išnaudojamas lentynas).
Svarbi pastaba – jei įmanoma, turėtumėte pabandyti paskirstyti skirtingų tarnybų serverius horizontaliai per stelažus. Tai būtina, kad neatsitiktų situacijų, kai vienai paslaugai atkeliauja viena serverių partija, stelažai vertikaliai supakuoti su ja, kad padidėtų "tankis" (nes taip lengviau). Realiai pasirodo, kad vienas stovas užpildytas identiškais tos pačios paslaugos mažos apkrovos serveriais, o kitas – tokios pat didelės apkrovos serveriais. Antro kritimo tikimybė žymiai didesnė, nes apkrovos profilis yra tas pats, ir visi serveriai, esantys šioje stelaže, pradeda vartoti tą patį kiekį dėl padidėjusios apkrovos.
Grįžkime prie serverių platinimo stelažuose. Išnagrinėjome fizinės stovo vietos ir galios apribojimus, o dabar pažvelkime į tinklą. Galite naudoti jungiklius su 24/32/48 N prievadais (pavyzdžiui, turime 48 prievadų ToR jungiklius). Laimei, nėra daug galimybių, jei negalvojate apie nutrūkusius kabelius. Svarstome scenarijus, kai „Rnet“ grupėje turime vieną jungiklį vienai stelažai, vieną jungiklį dviem ar trims stovams. Man atrodo, kad daugiau nei trys stelažai grupėje jau yra per daug, nes... kabelių tarp stelažų problema tampa daug didesnė.
Taigi kiekvienam tinklo scenarijui (1, 2 arba 3 stelažai grupėje) paskirstome serverius tarp stovų:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Taigi, pasirinkus 2 stelažus grupėje:
Srack2 = min (21, apvalinti (6000/300), apvalinti (48/2)) = min (21, 20, 24) = 20 serverių viename stove.
Likusias parinktis svarstome taip pat:
Srack1 = 20
Srack3 = 16
Ir mes jau beveik ten. Skaičiuojame stelažų skaičių, kad paskirstytume visus savo serverius S (tebūnie 1000):
R = apvalinimas (S / (Srack * Rnet)) * Rnet
R1 = apvalinimas (1000 / (20 * 1)) * 1 = 50 * 1 = 50 stelažų
R2 = apvalinimas (1000 / (20 * 2)) * 2 = 25 * 2 = 50 stelažų
R3 = apvalinimas (1000 / (16 * 3)) * 3 = 25 * 2 = 63 stovai
Toliau apskaičiuojame kiekvienos parinkties TCO pagal stelažų skaičių, reikiamą jungiklių skaičių, kabelius ir kt. Renkamės variantą, kur TCO mažesnė. Pelnas!
Atkreipkite dėmesį, kad nors reikalingas stelažų skaičius 1 ir 2 variantams yra vienodas, jų kaina skirsis, nes antrojo varianto jungiklių skaičius perpus mažesnis, o reikiamų laidų ilgis ilgesnis.
P.S. Jei galite žaisti su stelažo galia ir stovo aukščiu, kintamumas padidėja. Tačiau procesas gali būti sumažintas iki aprašyto aukščiau, tiesiog peržiūrint parinktis. Taip, derinių bus ir daugiau, bet vis tiek labai ribotas skaičius - stelažo maitinimas skaičiavimui gali būti didinamas 1 kW žingsniais, tipiniai stovai būna riboto standartinių dydžių: 42U, 45U, 47U, 48U , 52U. Ir čia „Excel“ „What-If“ analizė duomenų lentelės režimu gali padėti atlikti skaičiavimus. Mes žiūrime į gautas plokštes ir pasirenkame minimumą.
Šaltinis: www.habr.com