Ühes vestluses esitati mulle küsimus:
— Kas ma saan midagi lugeda selle kohta, kuidas servereid korralikult riiulitesse pakkida?
Sain aru, et ma ei tea sellist teksti, nii et kirjutasin oma.
Esiteks käsitleb see tekst füüsilistes andmekeskustes (DC-des) asuvaid füüsilisi servereid. Teiseks usume, et servereid on üsna palju: sadu-tuhandeid, väiksema arvu puhul pole sellel tekstil mõtet. Kolmandaks arvestame, et meil on kolm piirangut: füüsiline ruum riiulites, toiteallikas riiuli kohta ja riiulite seismine ridades, et saaksime kasutada ühte ToR-lülitit külgnevates riiulites asuvate serverite ühendamiseks.
Vastus küsimusele sõltub suuresti sellest, millist parameetrit me optimeerime ja mida saame parima tulemuse saavutamiseks muuta. Näiteks peame lihtsalt võtma minimaalselt ruumi, et jätta rohkem edasiseks kasvuks. Või võib-olla on meil vabadus valida riiulite kõrgust, võimsust riiuli kohta, PDU pistikupesasid, riiulite arvu lülitite rühmas (üks lüliti 1, 2 või 3 riiuli jaoks), juhtmete pikkust ja tõmbamistööd ( see on kriitiline ridade otstes: kui reas on 10 riiulit ja 3 riiulit lüliti kohta, peate juhtmed teise ritta tõmbama või lüliti porte kasutamata) jne jne. Eraldi lood: serverite valik ja DC-de valik, eeldame, et need on valitud.
Hea oleks mõista mõningaid nüansse ja detaile, eelkõige serverite keskmist/maksimaalset tarbimist ja seda, kuidas meile elektrit tarnitakse. Seega, kui meil on vene toiteallikas 230V ja üks faas racki kohta, siis 32A masin saab ~7kW hakkama. Oletame, et me maksame nominaalselt 6 kW eest püstiku kohta. Kui pakkuja mõõdab meie tarbimist ainult 10 püstiku rea, mitte iga riiuli kohta ja kui masin on seatud tinglikult 7 kW piirväärtusele, siis tehniliselt saame ühes riiulis tarbida 6.9 kW, teises 5.1 kW ja kõik saab korda - ei ole karistatav.
Tavaliselt on meie peamine eesmärk kulude minimeerimine. Parim kriteerium mõõtmiseks on TCO (omamise kogukulu) vähenemine. See koosneb järgmistest osadest:
- CAPEX: alalisvoolu infrastruktuuri, serverite, võrguriistvara ja kaablite ostmine
- OPEX: DC rent, elektritarbimine, hooldus. OPEX sõltub kasutuseast. Mõistlik on eeldada, et see on 3 aastat.
Sõltuvalt sellest, kui suured on üksikud tükid üldises pirukas, peame optimeerima kõige kallima ja laskma ülejäänutel kasutada kõiki ülejäänud ressursse võimalikult tõhusalt.
Oletame, et meil on olemasolev alalisvooluseade, püstiku kõrgus on H ühikut (näiteks H=47), elekter iga racki kohta (Prack=6kW) ja otsustasime kasutada h=2U kaheühikulisi servereid. Lülitite, patch-paneelide ja korraldajate riiulist eemaldame 2...4 ühikut. Need. füüsiliselt on meil riiulis Sh=rounddown((H-2..4)/h) serverid (st Sh = rounddown((47-4)/2)=21 serverit riiuli kohta). Meenutagem seda Sh.
Lihtsamal juhul on kõik riiulis olevad serverid identsed. Kokkuvõttes, kui täidame serveritega riiuli, siis iga serveri peale saame kulutada keskmiselt võimsust Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Lihtsuse huvides ignoreerime siin lüliti tarbimist.
Astume sammu kõrvale ja määrame kindlaks, milline on serveri maksimaalne tarbimine Pmax. Kui see on väga lihtne, väga ebaefektiivne ja täiesti ohutu, siis loeme, mis on kirjutatud serveri toiteallikale - see on see.
Kui see on keerulisem ja tõhusam, siis võtame kõigi komponentide TDP (termilise disaini paketi) ja võtame selle kokku (see pole tõsi, kuid see on võimalik).
Tavaliselt me ei tea komponentide TDP-d (v.a CPU), seega võtame kõige õigema, aga ka kõige keerukama lähenemise (vajame laborit) - võtame vajaliku konfiguratsiooniga eksperimentaalserveri ja laadime selle, näiteks Linpacki (CPU ja mälu) ja fio (kettad) abil mõõdame tarbimist. Kui asja tõsiselt võtta, siis tuleb katsete ajal luua ka kõige soojem keskkond külmas koridoris, sest see mõjutab nii ventilaatori tarbimist kui ka protsessori tarbimist. Me saame konkreetse konfiguratsiooniga konkreetse serveri maksimaalse tarbimise nendes konkreetsetes tingimustes selle konkreetse koormuse all. Me mõtleme lihtsalt seda, et uus süsteemi püsivara, erinev tarkvaraversioon ja muud tingimused võivad tulemust mõjutada.
Niisiis, tagasi Pservi juurde ja selle juurde, kuidas me seda Pmaxiga võrdleme. Iseasi on mõista, kuidas teenused töötavad ja kui tugevad on teie tehnilise direktori närvid.
Kui me üldse riske ei võta, usume, et kõik serverid saavad korraga hakata oma maksimumi tarbima. Samal hetkel võib tekkida üks sisend alalisvoolu. Isegi nendel tingimustel peab infra teenust pakkuma, seega Pserv ≡ Pmax. See on lähenemine, kus usaldusväärsus on absoluutselt oluline.
Kui tehnoloogiadirektor ei mõtle ainult ideaalsele turvalisusele, vaid ka ettevõtte rahale ja on piisavalt julge, siis võite otsustada, et
- Hakkame oma tarnijaid haldama, eelkõige keelame plaanipärase hoolduse kavandatud tippkoormuse ajal, et minimeerida ühe sisendi vähenemist;
- ja/või meie arhitektuur võimaldab teil riiuli/rea/DC kaotada, kuid teenused töötavad edasi;
- ja/või jaotame koorma hästi horisontaalselt üle riiulite, nii et meie teenused ei hüppa kunagi ühes riiulis maksimaalse tarbimiseni.
Siin on väga kasulik mitte lihtsalt oletada, vaid jälgida tarbimist ja teada, kuidas serverid tava- ja tippoludes tegelikult elektrit tarbivad. Seetõttu pigistab tehnikadirektor pärast mõningast analüüsi kõike, mis tal on, ja ütleb: "Teeme vabatahtliku otsuse, et maksimaalne saavutatav keskmine serveri maksimaalse tarbimise keskmine riiuli kohta on **nii palju** alla maksimaalse tarbimise," tinglikult Pserv = 0.8* Pmax.
Ja siis ei mahu 6 kW rack enam 16 serverit, mille Pmax = 375 W, vaid 20 serverit Pserv = 375 W * 0.8 = 300 W. Need. 25% rohkem servereid. See on väga suur kokkuhoid – vajame ju kohe 25% vähem nagid (ja hoiame kokku ka PDU-de, lülitite ja kaablite pealt). Sellise lahenduse tõsine miinus on see, et peame pidevalt jälgima, et meie eeldused ikka õiged oleksid. Et uus püsivara versioon ei muuda oluliselt ventilaatorite tööd ja tarbimist, et arendus ootamatult uue väljalaskega ei hakanud servereid palju efektiivsemalt kasutama (loe: saavutasid suurema koormuse ja suurema tarbimise serveris). Ju siis muutuvad nii meie esialgsed oletused kui ka järeldused kohe valeks. See on risk, mida tuleb võtta vastutustundlikult (või vältida ja seejärel maksta ilmselgelt alakasutatud riiulite eest).
Oluline märkus – võimalusel proovige erinevate teenuste servereid riiulite vahel horisontaalselt jaotada. See on vajalik selleks, et ei juhtuks olukordi, kui ühe teenuse jaoks saabub üks ports servereid, riiulid pakitakse sellega vertikaalselt, et suurendada “tihedust” (sest nii on lihtsam). Tegelikkuses selgub, et üks rack on täidetud sama teenuse identsete madala koormusega serveritega ja teine sama suure koormusega serveritega. Teise kukkumise tõenäosus on oluliselt suurem, sest koormusprofiil on sama ja kõik serverid koos selles riiulis hakkavad tarbima sama palju koormuse suurenemise tulemusena.
Tuleme tagasi serverite jaotamise juurde riiulites. Vaatasime füüsilise riiuli ruumi ja võimsuse piiranguid, nüüd vaatame võrku. Saate kasutada 24/32/48 N pordiga lüliteid (meil on näiteks 48-pordilised ToR-lülitid). Õnneks pole palju võimalusi, kui te ei mõtle katkestuskaablitele. Kaalume stsenaariume, kus Rnet rühmas on üks lüliti iga riiuli kohta, üks lüliti kahe või kolme riiuli kohta. Mulle tundub, et üle kolme nagi grupis on juba liig, sest... riiulitevahelise kaabelduse probleem muutub palju suuremaks.
Seega jaotame iga võrgustsenaariumi jaoks (1, 2 või 3 riiulit rühmas) serverid riiulite vahel:
Srack = min (Sh, ümardamine (Prack/Pserv), ümardamine (N/Rnet))
Seega 2 riiuliga variandi puhul rühmas:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serverit riiuli kohta.
Ülejäänud võimalusi kaalume samal viisil:
Srack1 = 20
Srack3 = 16
Ja me oleme peaaegu kohal. Loendame riiulite arvu kõigi meie serverite levitamiseks S (olgu see 1000):
R = ümardamine (S / (Srack * Rnet)) * Rnet
R1 = kokkuvõte (1000 / (20 * 1)) * 1 = 50 * 1 = 50 riiulit
R2 = kokkuvõte (1000 / (20 * 2)) * 2 = 25 * 2 = 50 riiulit
R3 = kokkuvõte (1000 / (16 * 3)) * 3 = 25 * 2 = 63 riiulit
Järgmiseks arvutame iga variandi TCO-d riiulite arvu, vajaliku lülitite arvu, kaablite jms alusel. Valime variandi, kus TCO on madalam. Kasum!
Pange tähele, et kuigi vajalike riiulite arv variantide 1 ja 2 jaoks on sama, on nende hind erinev, kuna teise variandi lülitite arv on poole väiksem ja vajalike kaablite pikkus on pikem.
PS Kui teil on võimalus mängida racki võimsuse ja riiuli kõrgusega, suureneb varieeruvus. Kuid protsessi saab taandada ülalkirjeldatud protsessile, lihtsalt läbides valikud. Jah, kombinatsioone tuleb veel, kuid siiski väga piiratud arv - racki toiteallikat saab arvutamiseks suurendada 1 kW sammuga, tüüpilisi rakke on piiratud arvul standardsuurustel: 42U, 45U, 47U, 48U , 52U. Ja siin võib arvutuste tegemisel abiks olla Exceli Mis-Kui-analüüs andmetabeli režiimis. Vaatame vastuvõetud plaate ja valime miinimumi.
Allikas: www.habr.com