Az egyik chatben egy kérdést tettek fel nekem:
— Olvashatok valamit arról, hogyan lehet megfelelően rackbe csomagolni a szervereket?
Rájöttem, hogy nem ismerek ilyen szöveget, ezért megírtam a sajátomat.
Először is, ez a szöveg a fizikai adatközpontokban (DC-k) lévő fizikai szerverekről szól. Másodszor, úgy gondoljuk, hogy elég sok szerver létezik: több százezer, kisebb szám esetén ennek a szövegnek nincs értelme. Harmadszor, úgy gondoljuk, hogy három korlátunk van: fizikai hely a rackekben, rackenkénti tápellátás, és hagyjuk, hogy a rackek sorban álljanak, így egyetlen ToR kapcsolóval csatlakoztathatjuk a szomszédos rackekben lévő szervereket.
A kérdésre adott válasz nagymértékben függ attól, hogy milyen paramétert optimalizálunk, és mit változtathatunk a legjobb eredmény elérése érdekében. Például csak minimális helyet kell foglalnunk, hogy több maradjon a további növekedéshez. Vagy talán szabadon választhatjuk meg az állványok magasságát, a rackenkénti teljesítményt, a PDU-ban lévő aljzatokat, a kapcsolócsoportban lévő állványok számát (egy kapcsoló 1, 2 vagy 3 rackhez), a vezetékek hosszát és a húzási munkát ( ez kritikus a sorok végén: ha egy sorban 10 rack van és kapcsolónként 3 állvány van, akkor át kell húzni a vezetékeket egy másik sorba, vagy alul kell használni a kapcsolóban lévő portokat), stb., stb. Külön történetek: a szerverek kiválasztása és a DC-k kiválasztása, feltételezzük, hogy ki vannak választva.
Jó lenne megérteni néhány árnyalatot és részletet, különösen a szerverek átlagos/maximális fogyasztását, és azt, hogy miként kapjuk meg az áramellátást. Tehát ha 230V-os orosz tápunk van és rackenként egy fázis, akkor egy 32A-es gép ~7kW-ot bír. Tegyük fel, hogy névlegesen 6 kW-ot fizetünk rackenként. Ha a szolgáltató csak 10 rack sorára méri a fogyasztásunkat, nem pedig minden rackre, és ha a gépet feltételesen 7 kW-os levágásra állítják, akkor műszakilag egyetlen rackben 6.9 kW-ot, másikban 5.1 kW-ot fogyaszthatunk, ill. minden rendben lesz - nem büntethető.
Általában a fő célunk a költségek minimalizálása. A legjobb mérési kritérium a TCO (teljes birtoklási költség) csökkenése. A következő darabokból áll:
- CAPEX: DC infrastruktúra, szerverek, hálózati hardver és kábelezés vásárlása
- OPEX: DC bérlet, áramfogyasztás, karbantartás. Az OPEX az élettartamtól függ. Ésszerű feltételezni, hogy ez 3 év.
Attól függően, hogy mekkora az egyes darabok a teljes tortában, a legdrágábbat kell optimalizálnunk, és hagyni kell, hogy a többi a lehető leghatékonyabban használja fel az összes fennmaradó erőforrást.
Tegyük fel, hogy van egy meglévő egyenáramunk, H egység rackmagasság (például H=47), Prack rackenkénti áram (Prack=6kW), és úgy döntöttünk, h=2U kétegységes szervereket használunk. 2...4 egységet távolítunk el a kapcsolók, patch panelek és rendezők állványából. Azok. fizikailag Sh=rounddown((H-2..4)/h) szerverek vannak a rackünkben (azaz Sh = rounddown((47-4)/2)=21 szerver rackenként). Emlékezzünk erre a Sh.
Egyszerű esetben a rackben lévő összes szerver azonos. Összességében, ha egy rack-et megtöltünk szerverekkel, akkor minden szerveren átlagosan a Pserv=Prack/Sh teljesítményt költhetjük el (Pserv = 6000W/21 = 287W). Az egyszerűség kedvéért itt figyelmen kívül hagyjuk a kapcsolófogyasztást.
Tegyünk egy lépést félre, és határozzuk meg, mennyi a maximális szerverfogyasztás Pmax. Ha nagyon egyszerű, nagyon hatástalan és teljesen biztonságos, akkor elolvassuk, mi van a szerver tápegységére írva - ez az.
Ha bonyolultabb, hatékonyabb, akkor vesszük az összes komponens TDP-jét (termikus tervezési csomag), és összegezzük (ez nem nagyon igaz, de lehetséges).
Általában nem ismerjük az összetevők TDP-jét (kivéve a CPU-t), ezért a leghelyesebb, de egyben a legösszetettebb megközelítést alkalmazzuk (laboratórium kell) - veszünk egy kísérleti szervert a szükséges konfigurációval, és betöltjük, például Linpack (CPU és memória) és fio (lemezek) segítségével mérjük a fogyasztást. Ha komolyan vesszük, akkor a hideg folyosón is a legmelegebb környezetet kell kialakítanunk a tesztek során, mert ez kihat a ventilátor- és a CPU-fogyasztásra is. Egy adott szerver maximális fogyasztását kapjuk meg egy adott konfigurációval ilyen körülmények között, ezen a terhelés mellett. Egyszerűen azt értjük, hogy az új rendszer firmware, egy másik szoftververzió és egyéb feltételek befolyásolhatják az eredményt.
Szóval, térjünk vissza a Pservhez és hogyan hasonlítsuk össze a Pmax-szal. A szolgáltatások működésének megértése és a műszaki igazgató idegei erősek.
Ha egyáltalán nem kockáztatunk, úgy gondoljuk, hogy minden szerver egyszerre kezdheti el fogyasztani a maximumot. Ugyanebben a pillanatban előfordulhat egy bemenet a DC-be. Ilyen feltételek mellett is az infranak szolgáltatást kell nyújtania, így Pserv ≡ Pmax. Ez egy olyan megközelítés, ahol a megbízhatóság rendkívül fontos.
Ha a technológiai igazgató nem csak az ideális biztonságra gondol, hanem a cég pénzére is, és elég bátor, akkor dönthet úgy, hogy
- Elkezdjük kezelni szállítóinkat, különösen a tervezett csúcsterhelés idején megtiltjuk az ütemezett karbantartást, hogy minimalizáljuk az egy bemenet csökkenését;
- és/vagy architektúránk lehetővé teszi, hogy elveszítsen egy állványt/sort/DC-t, de a szolgáltatások továbbra is működnek;
- és/vagy vízszintesen jól elosztjuk a rakományt az állványokon, így szolgáltatásaink soha nem ugranak a maximális fogyasztásra egy állványban.
Itt nagyon hasznos nem csak találgatni, hanem figyelemmel kísérni a fogyasztást és tudni, hogy a szerverek mennyi áramot fogyasztanak ténylegesen normál és csúcskörülmények között. Ezért némi elemzés után a technológiai igazgató mindent összeprésel, amije van, és azt mondja: „akaratlagos döntést hozunk, hogy a rackenkénti maximális szerverfogyasztás maximális elérhető átlaga **annyival** a maximális fogyasztás alatt van”, feltételesen Pserv = 0.8* Pmax.
És akkor egy 6 kW-os rack már nem tud 16 Pmax = 375 W-os szervert, hanem 20 Pserv = 375 W * 0.8 = 300 W-os szervert. Azok. 25%-kal több szerver. Ez nagyon nagy megtakarítás – elvégre azonnal 25%-kal kevesebb rackre van szükségünk (és a PDU-kon, kapcsolókon és kábeleken is spórolunk). Egy ilyen megoldás komoly hátránya, hogy folyamatosan figyelnünk kell, hogy feltételezéseink továbbra is helyesek-e. Hogy az új firmware-verzió nem változtat jelentősen a ventilátorok működésén és a fogyasztáson, hogy a fejlesztés az új kiadással hirtelen nem kezdi el sokkal hatékonyabban használni a szervereket (olvasd: nagyobb terhelést és nagyobb fogyasztást értek el a szerveren). Hiszen ekkor mind a kezdeti feltevéseink, mind a következtetéseink azonnal tévessé válnak. Ez egy olyan kockázat, amelyet felelősségteljesen kell vállalni (vagy kerülni kell, és fizetni kell a nyilvánvalóan alulhasznált állványokért).
Fontos megjegyzés: lehetőség szerint próbálja meg vízszintesen elosztani a különböző szolgáltatások szervereit az állványok között. Erre azért van szükség, hogy ne forduljanak elő olyan helyzetek, amikor egy-egy szolgáltatásra egy köteg szerver érkezik, a rack-eket függőlegesen megpakolják vele a „sűrűség” növelése érdekében (mert így egyszerűbb). A valóságban kiderül, hogy az egyik rack ugyanazon szolgáltatás azonos alacsony terhelésű szervereivel, a másik pedig ugyanolyan nagy terhelésű szerverekkel van tele. A második esés valószínűsége lényegesen nagyobb, mert a terhelési profil ugyanaz, és a rackben lévő összes kiszolgáló ugyanannyit kezd fogyasztani a megnövekedett terhelés következtében.
Térjünk vissza a szerverek rack-ben való elosztásához. Megvizsgáltuk a fizikai állványterület és a teljesítmény korlátait, most pedig nézzük a hálózatot. Használhat 24/32/48 N porttal rendelkező kapcsolókat (például vannak 48 portos ToR kapcsolóink). Szerencsére nincs sok lehetőség, ha nem gondol a kiszakadó kábelekre. Olyan forgatókönyveket fontolgatunk, amikor az Rnet csoportban rackenként egy kapcsoló van, egy kapcsoló két vagy három rackhez. Számomra úgy tűnik, hogy háromnál több állvány egy csoportban már túl sok, mert... az állványok közötti kábelezés problémája sokkal nagyobb lesz.
Tehát minden hálózati forgatókönyv esetén (1, 2 vagy 3 rack egy csoportban) elosztjuk a szervereket a rackek között:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Így egy csoportban 2 állványos opció esetén:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 szerver állványonként.
A többi lehetőséget ugyanúgy mérlegeljük:
Srack1 = 20
Srack3 = 16
És már majdnem ott vagyunk. Megszámoljuk a rackek számát az összes S szerverünk elosztásához (legyen 1000):
R = körkép(S / (Srack * Rnet)) * Rnet
R1 = kerekítés (1000 / (20 * 1)) * 1 = 50 * 1 = 50 állvány
R2 = kerekítés (1000 / (20 * 2)) * 2 = 25 * 2 = 50 állvány
R3 = kerekítés (1000 / (16 * 3)) * 3 = 25 * 2 = 63 állvány
Ezután kiszámítjuk az egyes opciók TCO-ját a rackek száma, a szükséges kapcsolók, kábelezés stb. alapján. Azt az opciót választjuk, ahol alacsonyabb a TCO. Nyereség!
Vegye figyelembe, hogy bár az 1. és 2. opcióhoz ugyanaz a szükséges állványszám, ezek ára eltérő lesz, mert a második opció kapcsolóinak száma fele annyi, a szükséges kábelek hossza pedig hosszabb.
PS Ha lehetősége van a rackenkénti teljesítménnyel és a rack magasságával játszani, a változékonyság nő. De a folyamat lecsökkenthető a fent leírtra, ha egyszerűen végigmegyünk a lehetőségeken. Igen, több kombináció lesz, de még mindig nagyon korlátozott számban - a rack tápellátása a számításhoz 1 kW-os lépésekben növelhető, a tipikus állványok korlátozott számú szabványos méretben kaphatók: 42U, 45U, 47U, 48U , 52U. És itt az Excel Mi-ha elemzése adattábla módban segíthet a számításokban. Megnézzük a kapott lemezeket, és kiválasztjuk a minimumot.
Forrás: will.com