Palvelinten jakelun optimointi telineiden välillä

Yhdessä chatissa minulta kysyttiin seuraava kysymys:

— Voinko lukea palvelimet oikein pakattavaksi telineisiin?

Tajusin, että en tiennyt tällaista tekstiä, joten kirjoitin oman.

Ensinnäkin tämä teksti koskee fyysisiä palvelimia fyysisissä datakeskuksissa (DC). Toiseksi uskomme, että palvelimia on melko paljon: satoja tuhansia; pienemmälle määrälle tämä teksti ei ole järkevä. Kolmanneksi katsomme, että meillä on kolme rajoitusta: fyysinen tila telineissä, virtalähde telinettä kohti ja telineiden seisominen riveissä, jotta voimme käyttää yhtä ToR-kytkintä vierekkäisten telineiden palvelimien yhdistämiseen.

Vastaus kysymykseen riippuu suuresti siitä, mitä parametria optimoimme ja mitä voimme muuttaa parhaan tuloksen saavuttamiseksi. Esimerkiksi meidän on vain vietävä vähän tilaa, jotta voimme jättää lisää kasvua varten. Tai ehkä meillä on vapaus valita telineiden korkeus, teho per teline, pistorasiat PDU:ssa, telineiden lukumäärä kytkinryhmässä (yksi kytkin 1, 2 tai 3 telineeseen), johtojen pituus ja vetotyö ( tämä on kriittistä rivien päissä: kun telineitä on 10 peräkkäin ja 3 telinettä kytkintä kohti, joudut vetämään johdot toiselle riville tai alikäyttöä kytkimen portteja) jne., jne. Erilliset tarinat: palvelimien valinta ja DC:iden valinta, oletamme, että ne on valittu.

Olisi hyvä ymmärtää joitain vivahteita ja yksityiskohtia, erityisesti palvelimien keskimääräinen/maksimikulutus ja sähkön toimitustapa meille. Eli jos meillä on venäläinen 230V virtalähde ja yksi vaihe telinettä kohti, niin 32A kone kestää ~7kW. Oletetaan, että maksamme nimellisesti 6 kW per teline. Jos toimittaja mittaa kulutustamme vain 10 telineen riville, ei jokaiselle telineelle, ja jos kone on asetettu ehdollisesti 7 kW:n rajalle, niin teknisesti voimme kuluttaa 6.9 kW yhdessä telineessä, 5.1 kW toisessa ja kaikki tulee olemaan ok - ei rangaistavaa.

Yleensä päätavoitteemme on minimoida kustannukset. Paras mittauskriteeri on TCO:n (kokonaisomistuskustannusten) aleneminen. Se koostuu seuraavista osista:

  • CAPEX: DC-infrastruktuurin, palvelimien, verkkolaitteiden ja kaapeloinnin hankinta
  • OPEX: DC-vuokraus, sähkönkulutus, huolto. OPEX riippuu käyttöiästä. On järkevää olettaa sen olevan 3 vuotta.

Palvelinten jakelun optimointi telineiden välillä

Riippuen siitä, kuinka suuria yksittäiset palat ovat kokonaisessa piiraassa, meidän on optimoitava kallein ja annettava loput käyttää kaikki jäljellä olevat resurssit mahdollisimman tehokkaasti.

Oletetaan, että meillä on olemassa DC, telinekorkeus on H yksikköä (esim. H=47), sähköä telinettä kohti Prack (Prack=6kW), ja päätimme käyttää h=2U kahden yksikön palvelimia. Poistamme telineestä 2..4 yksikköä kytkimiä, kytkentäpaneeleja ja järjestelyjä varten. Nuo. fyysisesti meillä on telineessämme Sh=rounddown((H-2..4)/h) palvelimia (eli Sh = rounddown((47-4)/2) = 21 palvelinta telinettä kohti). Muistakaamme tämä Sh.

Yksinkertaisessa tapauksessa kaikki telineen palvelimet ovat identtisiä. Yhteensä, jos täytämme telineen palvelimilla, voimme kuluttaa jokaiselle palvelimelle keskimäärin tehoa Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Yksinkertaisuuden vuoksi jätämme tässä huomioimatta kytkimien kulutuksen.

Otetaan askel sivuun ja määritetään, mikä on palvelimen enimmäiskulutus Pmax. Jos se on hyvin yksinkertaista, erittäin tehotonta ja täysin turvallista, luemme, mitä palvelimen virtalähteeseen on kirjoitettu - tässä se on.

Jos se on monimutkaisempi ja tehokkaampi, otamme kaikkien komponenttien TDP:n (lämpösuunnittelupaketti) ja laskemme sen yhteen (tämä ei ole kovin totta, mutta se on mahdollista).

Yleensä emme tiedä komponenttien TDP:tä (CPU:ta lukuun ottamatta), joten otamme oikeimman, mutta myös monimutkaisimman lähestymistavan (tarvitsemme laboratorion) - otamme tarvittavan kokoonpanon kokeellisen palvelimen ja lataamme sen, Esimerkiksi Linpackilla (CPU ja muisti) ja fiolla (levyt) mittaamme kulutusta. Jos otamme asian vakavasti, meidän on myös luotava lämpimin ympäristö kylmäkäytävään testien aikana, koska tämä vaikuttaa sekä tuulettimen kulutukseen että prosessorin kulutukseen. Saamme tietyn palvelimen enimmäiskulutuksen tietyllä kokoonpanolla näissä erityisolosuhteissa tällä tietyllä kuormalla. Tarkoitamme yksinkertaisesti sitä, että uusi järjestelmän laiteohjelmisto, eri ohjelmistoversio ja muut olosuhteet voivat vaikuttaa tulokseen.

Joten takaisin Pserviin ja siihen, kuinka vertaamme sitä Pmaxiin. Kysymys on ymmärtää, miten palvelut toimivat ja kuinka vahvat teknisen johtajasi hermot ovat.

Jos emme ota riskejä ollenkaan, uskomme, että kaikki palvelimet voivat samanaikaisesti alkaa kuluttaa maksimissaan. Samalla hetkellä voi tapahtua yksi tulo tasavirtaan. Näissäkin olosuhteissa infran on tarjottava palvelua, joten Pserv ≡ Pmax. Tämä on lähestymistapa, jossa luotettavuus on ehdottoman tärkeää.

Jos teknologiajohtaja ei ajattele vain ihanteellista turvallisuutta, vaan myös yrityksen rahoja ja on tarpeeksi rohkea, voit päättää, että

  • Olemme alkaneet hallita toimittajiamme, erityisesti kiellämme määräaikaishuollot suunnitellun huippukuormituksen aikoina minimoidaksemme yhden syötteen putoamisen;
  • ja/tai arkkitehtuurimme mahdollistaa telineen/rivin/DC:n katoamisen, mutta palvelut toimivat edelleen;
  • ja/tai levitämme kuorman hyvin vaakasuoraan telineisiin, joten palvelumme eivät koskaan hyppää maksimikulutukseen yhdessä telineessä yhdessä.

Täällä on erittäin hyödyllistä paitsi arvailla, myös seurata kulutusta ja tietää, kuinka palvelimet todella kuluttavat sähköä normaaleissa ja huippuolosuhteissa. Siksi tekninen johtaja puristaa analyysin jälkeen kaiken, mitä hänellä on, ja sanoo: "Teemme vapaaehtoisen päätöksen, että palvelimen maksimikulutuksen suurin saavutettava keskiarvo telinettä kohti on **niin paljon** enimmäiskulutuksen alapuolella", ehdollisesti Pserv = 0.8* Pmax.

Ja sitten 6 kW:n telineeseen ei voi enää mahtua 16 palvelinta, joiden Pmax = 375 W, vaan 20 palvelinta, joiden Pserv = 375 W * 0.8 = 300 W. Nuo. 25% enemmän palvelimia. Tämä on erittäin suuri säästö - loppujen lopuksi tarvitsemme heti 25 % vähemmän telineitä (ja säästämme myös PDU:issa, kytkimissä ja kaapeleissa). Tällaisen ratkaisun vakava haitta on, että meidän on jatkuvasti valvottava, että olettamuksemme ovat edelleen oikeita. Että uusi laiteohjelmistoversio ei muuta merkittävästi fanien toimintaa ja kulutusta, että kehitys yhtäkkiä uuden julkaisun myötä ei alkanut käyttää palvelimia paljon tehokkaammin (lue: ne saivat suuremman kuormituksen ja suuremman kulutuksen palvelimella). Loppujen lopuksi sekä alkuperäiset olettamuksemme että johtopäätöksemme muuttuvat välittömästi vääriksi. Tämä on riski, joka on otettava vastuullisesti (tai vältettävä ja sitten maksettava ilmeisen vajaakäyttöisistä telineistä).

Tärkeä huomautus - sinun tulee yrittää jakaa eri palveluiden palvelimia vaakasuunnassa telineiden kesken, jos mahdollista. Tämä on tarpeen, jotta ei tapahdu tilanteita, kun yksi palvelinerä saapuu yhteen palveluun, telineitä pakataan pystysuunnassa "tiheyden" lisäämiseksi (koska se on niin helpompaa). Todellisuudessa käy ilmi, että yksi teline on täynnä saman palvelun identtisiä matalakuormittaisia ​​palvelimia ja toinen yhtä kuormitettuja palvelimia. Toisen putoamisen todennäköisyys on huomattavasti suurempi, koska kuormitusprofiili on sama, ja kaikki palvelimet yhdessä tässä telineessä alkavat kuluttaa saman määrän lisääntyneen kuormituksen seurauksena.

Palataan telineiden palvelimien jakeluun. Olemme tarkastelleet fyysistä telinetilaa ja tehonrajoituksia, katsotaan nyt verkkoa. Voit käyttää kytkimiä, joissa on 24/32/48 N-portti (meillä on esimerkiksi 48-porttiset ToR-kytkimet). Onneksi vaihtoehtoja ei ole paljon, jos et ajattele katkeavia kaapeleita. Harkitsemme skenaarioita, joissa Rnet-ryhmässä on yksi kytkin per teline, yksi kytkin kahdelle tai kolmelle telineelle. Minusta tuntuu, että enemmän kuin kolme telinettä ryhmässä on jo liikaa, koska... telineiden välisen kaapeloinnin ongelma kasvaa paljon.

Joten jokaisessa verkkoskenaariossa (1, 2 tai 3 telinettä ryhmässä) jaamme palvelimet telineiden kesken:

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

Näin ollen vaihtoehto, jossa on 2 telinettä ryhmässä:

Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 palvelinta per teline.

Käsittelemme muita vaihtoehtoja samalla tavalla:

Srack1 = 20
Srack3 = 16

Ja olemme melkein perillä. Laskemme telineiden määrän kaikkien palvelimiemme jakelua varten (olkoon 1000):

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

R1 = kierto (1000 / (20 * 1)) * 1 = 50 * 1 = 50 telinettä

R2 = kierto (1000 / (20 * 2)) * 2 = 25 * 2 = 50 telinettä

R3 = kierros (1000 / (16 * 3)) * 3 = 25 * 2 = 63 telinettä

Seuraavaksi laskemme kullekin vaihtoehdolle TCO:n telineiden lukumäärän, tarvittavan kytkimien, kaapeloinnin jne. perusteella. Valitsemme vaihtoehdon, jossa TCO on pienempi. Voitto!

Huomaa, että vaikka tarvittava määrä telineitä vaihtoehdoille 1 ja 2 on sama, niiden hinta on erilainen, koska toisen vaihtoehdon kytkimien määrä on puolet pienempi ja tarvittavien johtojen pituus on pidempi.

PS Jos sinulla on mahdollisuus pelata telinekohtaisella teholla ja telineen korkeudella, vaihtelu lisääntyy. Mutta prosessi voidaan vähentää yllä kuvattuun yksinkertaisesti käymällä läpi vaihtoehtoja. Kyllä, yhdistelmiä tulee lisää, mutta silti hyvin rajallinen määrä - telineen virransyöttöä laskentaa varten voidaan lisätä 1 kW:n välein, tyypillisiä telineitä on rajoitettu määrä vakiokokoja: 42U, 45U, 47U, 48U , 52U. Ja tässä Excelin mitä jos -analyysi tietotaulukkotilassa voi auttaa laskelmissa. Katsomme vastaanotettuja levyjä ja valitsemme minimin.

Lähde: will.com

Lisää kommentti