Serverite paigutamise optimeerimine rack'idesse

Ühes vestluses küsiti minult:

— Kas on midagi lugeda, kuidas servereid õigesti rack'idesse pakkida?

Mõistsin, et sellist teksti ei tea, seega kirjutasin enda oma.

Esiteks, see tekst räägib füüsilistest serveritest füüsilistes andmekeskustes (DC). Teiseks, oletame, et servereid on piisavalt palju: sadu-tuhandeid, väiksema arvu korral pole sellel tekstil mõtet. Kolmandaks, oletame, et meil on kolm piirajat: füüsiline ruum rack'ides, toide rack'i kohta ja oletame, et rack'id on ridades, nii et saame kasutada ühte ToR lülitit, et ühendada servereid naaberrack'idega.

Küsimusele vastamine sõltub tugevalt sellest, millist parameetrit me optimeerime ja mida saame varieerida, et saavutada parim tulemus. Näiteks, kui meie ainus eesmärk on võtta võimalikult vähe ruumi, et rohkem kasvada tulevikus. Võib-olla on meil vabadus valida rack'i kõrgust, toimet, PDU'dse pistikupesa arvu, rack'ide arvu lüliti grupis (üks lüliti 1, 2 või 3 rack'i jaoks), kaablite pikkust ja paigaldustöid (see on kriitiline ridade otstes: 10 rack'iga reas ja 3 rack'i lülitis peab juhtmed venima teise ritta või portide vähest kasutamist lülitis), jne., jne. Erinevad lood: serverite valik ja DC valik, oletame, et need on juba valitud.

Oleks hea mõista mõningaid nüansse ja detaile, eriti serverite keskmist/maksimaalset tarbimist ja kuidas me saame elektrit. Näiteks, kui meil on Venemaa elektrivõrk 230V ja üks faas rack'i kohta, siis 32A automaat võib taluda ~7kW. Oletame, et maksame ametlikult 6kW rack'i kohta. Kui operaator mõõdab meie tarbimist ainult ühe rea 10 rack'i kaupa, mitte iga rack'i kohta, ja kui automaat on seatud 7kW lõikes, siis tehniliselt saame ühes rack'is tarbida 6.9kW, teises 5.1kW ja kõik on korras — ei mingit karistust.

Tavaliselt on meie peamine eesmärk kulude minimeerimine. Parim mõõdik on TCO (total cost of ownership — kogukulud). See koosneb järgmistest osadest:

• CAPEX: andmekeskuste, serverite, võrguseadmete ostmine ja kaablitööde teostamine
• OPEX: andmekeskuse rent, tarbitav elektrienergia, teenindus. OPEX sõltub eluajast. Mõistlik on eeldada, et see on 3 aastat.

Sõltuvalt sellest, kui suured on erinevad tükid kogu koogis, peame optimeerima kõige kallima, samas kui ülejäänud laskeme kasutada kõiki allesjäänud ressursse võimalikult tõhusalt.

Oletame, et meil on juba olemasolev andmekeskus, meil on H juunit (näiteks H=47), elektritarve rack'i kohta Prack (Prack=6kW) ja otsustasime kasutada 2U kaheteljelisi servereid. Eemaldame rack'ist 2..4 juunit lülititele, patch-paneelidele ja korraldajatele. T. e. füüsiliselt mahub meie rack'i Sh=rounddown((H-2..4)/h) serverit (s.t. Sh = rounddown((47-4)/2)=21 serverit rack'i kohta). Peame seda Sh meeles.

Lihtsas juhtumis on kõik rack'is olevad serverid ühesugused. Kokkuvõttes, kui me täidame rack'i serveritega, saame iga serveri kohta keskmiselt kulutada võimsust Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Lihtsuse huvides ignoreerime siin lüliti tarbimist.

Teeme sammu kõrvale ja määratleme, mis on serveri maksimaalne tarbimine Pmax. Kui väga lihtne, väga ebaefektiivne ja täiesti ohutu, siis loeme, mis on kirjutatud serveri toiteplokil — see on see.

Kui keerulisem, efektiivsem, siis võtame kõikide komponentide TDP (soojuse disainipakett) ja summeerime (see ei ole väga tõsi, aga nii saab ka teha).

Tavaliselt ei tea me komponentide TDP-d (välja arvatud CPU), seega võtame kõige õigem, kuid ka kõige keerulisema lähenemise (vajalik on labor) — võtame eksperimentaalse serveri vajaliku konfiguratsiooniga ja koormame selle näiteks Linpack'iga (CPU ja mälu) ja fio'ga (ketas), mõõdame tarbimist. Kui läheneda tõsiselt, siis tuleb luua ka kõige soojem keskkond külmas koridoris katsete käigus, sest see mõjutab nii ventilaatorite kui ka CPU tarbimist. Saame maksimaalse tarbimise konkreetse serveri konkreetses konfiguratsioonis nende konkreetsete tingimuste all selle konkreetse koormuse juures. Lihtsalt pidage meeles, et uus süsteemi püsivara, muu tarkvaraversioon, muud tingimused võivad tulemusele mõju avaldada.

Kokkuvõttes, naaseme Pserv'i juurde ja kuidas me seda Pmax'iga võrreldes. See on küsimus teenuste toimimise mõistmisest ja sellest, kui tugevad närvid on teie tehnikajuhil.

Kui ei soovi üldse riskida, siis eeldame, et kõik serverid võivad samal ajal hakata tarbima oma maksimaali. Sel hetkel võib andmekeskusesse tekkida üks sisend. Infra peab nende tingimuste all teenust pakkuma, seega Pserv ≡ Pmax. See on lähenemine, kus absoluutne usaldusväärsus on äärmiselt oluline.

Kui tehnilised juhid mõtlevad mitte ainult ideaalsetele turvalisusele, vaid ka ettevõtte rahale ja on piisavalt julged, siis võib otsustada, et

• me hakkame haldama oma teenusepakkujaid, sealhulgas keelame planeeritud hoolduse tegemise meie oodatud tiploadude ajal, et minimeerida ühe sisendi langemist.
• ja/või meie arhitektuur võimaldab kaotada rikka/rida/andmekeskuse, samas jätkavad teenused töötamist;
• ja/või hajutame koormust tõhusalt rakkude vahel, mistõttu meie teenused ei pruugi kunagi kogu koormust samal ajal ühes rackis maksimaalselt tarbida.

Siinkohal on väga kasulik mitte ainult oletada, vaid jälgida tarbimist ja teada, kuidas serverid tegelikult tavalistes ja tipukoormuse tingimustes elektrit tarbivad. Seetõttu, pärast teatavat analüüsi, koondab tehniline juht kõik, mis tal on, ja ütleb: „me võime otsustada, et maksimaalselt saavutatav keskmine serveri tarbimine rackis on **nii palju** madalam kui maksimaalne tarbimine,” eeldades, et Pserv=0.8*Pmax.

Ja siis rack, mille võimsus on 6kW, mahutab juba mitte 16 serverit, mille Pmax = 375W, vaid 20 serverit Pserv = 375W * 0.8 = 300W. See tähendab 25% rohkem servereid. See on väga suur kokkuhoid – sest racks on meile kohe 25% vähem vajalikud (ja seal saame säästa ka PDU, lülititel ja kaablitel). Sellise lahenduse tõsine miinus on see, et tuleb pidevalt jälgida, et meie eeldused on ikka tõesed. Et uus tarkvaraversioon ei muuda oluliselt ventilaatorite tööd ja tarbimist, et arendus ei oleks äkki uue versiooniga hakanud servereid palju efektiivsemalt kasutama (loe: saavutati suurem koormus ja suurem tarbimine serveri kohta). Siis muutuvad ka meie esialgsed eeldused ja järeldused kohe valeks. See on risk, mida tuleb vastutustundlikult võtta (või vältida, makstes selgelt alakoormatud rackide eest).

Oluline märkus — servereid tuleks, kui võimalik, horisontaalselt jaotada erinevate teenuste vahel kioskites. See on vajalik, et vältida olukordi, kus ühe teenuse serverid saabuvad ja kioskid täidetakse vertikaalselt sama teenusega „tiheduse“ suurendamiseks (sest see on lihtsam). Tegelikkuses on aga nii, et üks kiosk on sama madala koormusega sama teenusega serveritest täidetud, samas kui teine on sama kõrge koormusega serveritest täidetud. Teise kioskide tõrke tõenäosus on oluliselt suurem, kuna koormusprofiil on sama ja kõik serverid selle kioski sees hakkavad ühiselt suureneva koormuse tõttu sama palju energiatarve suurenema.

Naaseme serverite jaotamise juurde kioskites. Oleme käsitlenud füüsilisi ruumi- ja elektritoite piiranguid, nüüd vaatame ka võrku. Võib kasutada 24/32/48 pordiga lüliteid N (näiteks meil on 48-pordilised ToR lülitid). Õnneks ei ole variantide arv suur, kui mitte mõelda break-out kaablitele. Käsitleme stsenaariume, kus meil on üks lüliti igas kioskis, üks lüliti kahes või kolmes kioskis Rnet grupis. Mulle tundub, et rohkem kui kolm kioskis grupis on juba liialdus, kuna probleem kaabeldamise vahel kioskite vahel muutub oluliselt suuremaks.

Nii et igasuguste võrgu stsenaariumide jaoks (1, 2 või 3 kioskit grupis) jaotame serverid kioskite vahel:

Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))

Nii et 2 kioskiga grupi puhul:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serverit kioski kohta.

Samasuguseid arvutusi teeme ka teiste variantide jaoks:

Srack1 = 20
Srack3 = 16

Ja me oleme peaaegu eesmärgini jõudnud. Arvutame välja vajaolevate kioskite arvu S (olgu see 1000):

R = roundup(S / (Srack * Rnet)) * Rnet

R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 kioskite

R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 kioskite

R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 kioskite

Edasi arvutame TCO iga variandi puhul, tuginedes vajalike kioskite arvule, vajalike lülitite arvule, kaabeldamisele jne. Valime variandi, kus TCO on väiksem. Kasum!

Käime tähele, et kuigi vajalike kioskite arv variantide 1 ja 2 puhul on sama, on nende hind erinev, kuna teise variandi puhul on lülitite arv kaks korda vähem ja vajalike kaablite pikkus suurem.

P.S. Kui on võimalik racki võimsust ja kõrgust mängida, suureneb muutlikkus. Kuid protsessi võib vähendada eelpoolkirjeldatud, lihtsalt variatsioone läbi vaadates. Jah, kombinatsioone saab olema rohkem, kuid siiski väga piiratud hulk — racki toitearvutamiseks saab suurendama 1 kW sammuga, tavapäraselt on rackide arv piiratud tüübi suurustega: 42U, 45U, 47U, 48U, 52U. Ja siin võib Exceli What-If analüüs Data Table režiimis aidata arvutustes. Vaatame saadud tabelite peale ja valime minimaalse.

Allikas: habr.com