Ühes vestluses küsiti minult:
— Kas on midagi, mida lugeda, kuidas õigesti servereid rackides pakkida?
Mõistsin, et sellist teksti ei tea, seega kirjutasin oma.
Esiteks räägib see tekst füüsilistest serveritest füüsilistes andmekeskustes (DC). Teiseks eeldame, et servereid on piisavalt palju: sadu-tuhandeid, väiksema arvu korral ei ole see tekst mõttekas. Kolmandaks oletame, et meil on kolm piirangut: füüsiline ruum rackides, toiteallikas räkki kohta ja oletame, et rackid seisavad ridade kaupa, nii et saame kasutada ühte ToR lülitit serverite ühendamiseks naaberrakkides.
Küsimuse vastus sõltub suuresti sellest, millist parameetrit me optimeerime ja mida me saame varieerida, et saavutada parim tulemus. Näiteks peame võib-olla võtma minimumpinda, et jätta rohkem ruumi edasiseks kasvuks. Võib-olla on meil vabadus valida rackide kõrgus, võimsus racki kohta, PDU pesade arv, rackide arv lülitite grupis (üks lüliti 1, 2 või 3 racki kohta), kaablite pikkus ja tööde tegemine (see on kriitiline ridade lõpus: 10 rackiga rida ja 3 rackiga lüliti korral tuleb juhtmed tõmmata teise rida või kasutada lülitis porti mitte täielikult), jne., jne. Erinevad lood: serverite ja andmekeskuste valik, oletame, et need on juba valitud.
Hea oleks mõista teatud nüansse ja üksikasju, sealhulgas serverite keskmist/maksimaalset energiatarbimist ning kuidas meile elektrit tarnitakse. Kui meil on Venemaa 230V toide ja racki jaoks üks faas, siis 32A automaat võib taluda umbes 7 kW. Oletame, et maksame nominaalselt 6 kW racki kohta. Kui teenusepakkuja mõõdab meie tarbimist ainult 10 racki riba järgi, mitte iga racki kaupa, ja automaat on piiril 7 kW, siis tehniliselt võime ühes rackis tarbida 6.9 kW, teises 5.1 kW ning kõik on korras — mitte karistatav.
Tavaliselt on meie peamine eesmärk kulude vähendamine. Parim kriteerium mõõtmiseks on TCO (total cost of ownership — kogumaksumus omandamisel) alandamine. See koosneb järgmistest osadest:
- CAPEX: andmekeskuse infrastruktuuri, serverite, võrgusiinide ja kaablite soetamine
- OPEX: andmekeskuse rent, tarbitud elekter, hooldus. OPEX sõltub kasutuse kestusest. Mõistlik on eeldada, et see on võrdne 3 aastaga.
Sõltuvalt sellest, kui suured on eri osad üldises koogis, peame optimeerima kõige kallimat osa, ning ülejäänu las kasutab kõiki ülejäänud ressursse võimalikult tõhusalt.
Oletame, et meil on juba olemasolev andmekeskus, racki kõrgus H ja üksuste arv (näiteks H=47), racki elektrivõimsus Prack (Prack=6 kW) ning oleme otsustanud kasutada 2U kaheastmelisi servereid. Eemaldame rackist 2–4 üksust switchide, patšipaneelide ja organiseerijate jaoks. Füüsiliselt mahub meie racki Sh=rounddown((H-2..4)/h) servereid (st Sh = rounddown((47-4)/2)=21 serverit racki kohta). Salvestame selle Sh.
Lihtsas olukorras on kõik racki serverid ühesugused. Seega, kui täidame racki serveritega, saame keskmiselt iga serveri kohta anda võimsust Pserv=Prack/Sh (Pserv = 6000 W/21 = 287 W). Lihtsuse huvides ignoreerime siin switchi tarbimist.
Teeme sammu kõrvale ja määratleme, mis on serveri maksimaalne tarbimine Pmax. Kui öelda väga lihtsalt, väga ebaefektiivselt ja täiesti turvaliselt, siis vaatame, mis on kirjutatud serveri toiteploki küljes — see ongi see.
Kui keerulisem, siis võtame kõigi komponentide TDP (soojuse kujundamise pakett) ja summeerime (see ei ole väga tõsi, aga nii saab ka).
Tavaliselt me ei tea komponentide (välja arvatud CPU) TDP-d, seega kasutame kõige õiget, aga ka kõige keerulisemat lähenemist (vajatakse laborit) – võtame vajaliku konfiguratsiooniga katse serveri ja koormame seda näiteks Linpackiga (CPU ja mälu) ja fio’ga (kettad), mõõdame tarbimist. Kui läheneda tõsiselt, tuleb ka luua võimalikult soe keskkond külmas koridoris katsete ajal, kuna see mõjutab nii ventilaatorite tarbimist kui ka CPU tarbimist. Saame maksimaalse tarbimise konkreetse serveri konkreetse konfiguratsiooni korral nendes konkreetsetes tingimustes selle konkreetse koormuse all. Peame lihtsalt meeles pidama, et uus süsteemi püsivara, tarkvara teine versioon, teised tingimused võivad mõjutada tulemust.
Kokkuvõttes, pöördume tagasi Pservi juurde ja kuidas me saame seda võrrelda Pmaxiga. See on küsimus teenuste toimimise arusaamisest ja sellest, kui tugevad närvid on teie tehnilisel juhil.
Kui riski üldse vältida, siis arvestame, et kõik serverid võivad samal ajal hakata tarbima oma maksimumi. Sel hetkel võib tekkida üks sisend andmekeskusesse. Infrastruktuur peab ka nendes tingimustes pakkuma teenust, seega Pserv ≡ Pmax. See on lähenemine, kus usaldusväärsus on äärmiselt oluline.
Kuid kui tehniline direktor mõtleb mitte ainult ideaalsetele turvameetmetele, vaid ka ettevõtte rahale ning on piisavalt julge, siis on võimalik otsustada, et
- hakkame haldama oma tarnijaid, eelkõige keelame planeeritud hooldustööd plaanitud tipukoormuse ajal, et minimeerida ühe sisenemise kadumist;
- ja/või meie arhitektuur võimaldab kaotada kapi/read/andmekeskuse, samas kui teenused jätkuvad;
- ja/või hajutame koormuse hästi horisontaalselt kappide vahel, seega ei hüppa meie teenused kunagi ühe kapi maksimaalsele tarbimisele kõik koos.
Siin ei ole mõtet lihtsalt arvata, vaid on oluline jälgida tarbimist ja teada, kui palju serverid tegelikult tavalistes ja tipptundides elektrit kasutavad. Seetõttu, pärast teatud analüüsi, tõmbab tehniline direktor kokku kõik, mis tal on, ja ütleb: "me teeme tahteotsuse, et serverite maksimumtarbimise keskmine on **nii palju** madalam kui maksimumtarbimine", tinglikult Pserv=0.8*Pmax.
Ja siis seisukohas, kus 6 kW racks mahutab mitte 16 serverit Pmax = 375 W, vaid 20 serverit Pserv = 375 W * 0.8 = 300 W. See tähendab 25% rohkem servereid. See on suur kokkuhoid — kuna meil on vaja ka 25% vähem rack'e (sealjuures säästame ka PDU-de, switch-ide ja kaablite pealt). Kuid tõsine miinus selles lahenduses on see, et peame pidevalt jälgima, et meie eeldused oleksid endiselt õiged. Et uus firmware versioon ei muudaks oluliselt ventilaatorite ja energiatarbimise töövõimet, et arendajad ei hakkaks äkki uue väljalaskega servereid palju efektiivsemalt kasutama (loe: ei saavuta suuremat koormust ja suuremat energiatarbimist serveri kohta). Sest siis saavad kõik meie esialgsed eeldused ja järeldused kohe valeväärseks. See on risk, mille vastutustundlikult tuleb võtta (või vältida ja maksta siis ilmselgelt alakoormatud rack'ide eest).
Oluline märkus — serverite jaotamine erinevate teenuste vahel horisontaalselt, kui see on võimalik, on soovitatav. See on vajalik, et vältida olukordi, kus ühe teenuse serverid saabuvad samal ajal ja paigaldatakse vertikaalselt riiulitesse tiheduse suurendamiseks (sest see on lihtsam). Tegelikult tähendab see, et üks riiul on täis sama madala koormusega servereid ühest teenusest, samas kui teine on täis ühtlaselt kõrge koormusega servereid. Teise riiuli tõrke tõenäosus on palju suurem, kuna koormusprofiil on sama ja kõik need serverid samaaegselt hakkavad koormuse suurenemise tõttu tarbima sama palju.
Naasume tagasi serverite jaotamisele kappidest. Oleme uurinud füüsilisi piiranguid ruumi ja toite osas, nüüd vaatame ka võrku. Saame kasutada N (näiteks meil on 48-portilised ToR lülitid) jaoks 24/32/48 porti. Õnneks pole valikuid palju, kui mitte mõelda break-out kaablitele. Arutame stsenaariume, kus meil on üks lüliti kapi kohta, üks lüliti kahe või kolme kapi grupis Rnet. Minu arvates on rohkem kui kolm kappi grupis juba liialt, kuna kaablite haldamise probleem kappidest kappi muutub palju suuremaks.
Nii et igas võrgu stsenaariumis (1, 2 või 3 kappi grupis) jaotame serverid kappidesse:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Seega, kahe kapi variandi puhul grupis:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 serverit kapi kohta.
Samamoodi arvutame ülejäänud variandid:
Srack1 = 20
Srack3 = 16
Ja olemegi peaaegu sihtpunktis. Arvutame kõikide meie serverite jaotamiseks vajalike kappide arvu S (olgu see 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 kappi
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 kappi
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 kappi
Edasi arvutame TCO iga variandi jaoks, arvestades vajalikku riiulite arvu, lülitite vajalikku arvu, kaabeldust jms. Valime selle variandi, kus TCO on väiksem. Kasum!
Märkusena, kuigi vajalike riiulite arv variantide 1 ja 2 on sama, on nende hind erinev, kuna teise variandi lülitite arv on kaks korda väiksem ja vajalike kaablite pikkus suurem.
P.S. Kui on võimalik mängida riiuli võimsuse ja kõrgusega, suureneb variatiivsus. Kuid protsessi saab viia tagasi ülaltoodud kirjelduseni, lihtsalt valikute järjestamise teel. Jah, kombinatsioone saab olema rohkem, kuid siiski üsna piiratud arv — riiulile mõeldud toitearvutust võib suurendada 1 kW sammuga, tüüpilised riiulid on piiratud arvu tüpoloogia suurusi: 42U, 45U, 47U, 48U, 52U. Ja siin võib arvutust aidata Exceli What-If analyüs Data Table režiimis. Vaatame saadud tabeleid ja valime miinimumi.
Allikas: habr.com
