Egyik csevegésben feltették a kérdést:
— Van valami olvasnivaló arról, hogyan kell helyesen becsomagolni a szervereket a rackekbe?
Rájöttem, hogy ilyen szöveget nem ismerek, ezért írtam egyet.
Először is, ez a szöveg a fizikai szerverekről fizikai adatközpontokban (DC). Másodszor, tegyük fel, hogy sok szerverünk van: százak ezrek, kisebb számú esetén ennek a szövegnek nincs értelme. Harmadszor, vegyük figyelembe, hogy három korlátozónk van: a rackek fizikai helye, az áramellátás a rackre, és tegyük fel, hogy a rackek sorokban állnak, így egy ToR kapcsolót használhatunk a szomszédos rackekhez való csatlakozáshoz.
A kérdésre adott válasz nagymértékben függ attól, hogy melyik paramétert optimalizáljuk, és mit tudunk módosítani a legjobb eredmény eléréséhez. Például lehet, hogy csak a lehető legkisebb helyet kell elfoglalnunk, hogy több hely maradjon a jövőbeli növekedéshez. Vagy talán van választási szabadságunk a rack magasságában, a rackre jutó teljesítményben, a PDU-ban lévő aljzatok számában, a switch csoportban lévő rackek számában (egy switch 1, 2 vagy 3 rackhez), a kábelek hosszában és a kihúzási munkákban (ez kritikus a sor végén: 10 rack esetén, ha a switchhez 3 rack van, akkor a kábeleket a másik sorba kell húzni, vagy nem használhatjuk ki a portokat a switchben), stb., stb. Külön történetek a szerverek kiválasztása és az adatközpontok kiválasztása, tegyük fel, hogy már kiválasztották őket.
Jó lenne megérteni néhány részletet és árnyalatot, különösen a szerverek átlagos / maximális fogyasztását, és hogy hogyan érkezik az áram. Tehát, ha orosz 230V-os áramellátásunk van, és egy fázisunk van a rackre, akkor a 32A-es automatikus biztosíték körülbelül 7kW-ot bír el. Tegyük fel, hogy névlegesen 6kW-ot fizetünk a rackért. Ha a szolgáltató a fogyasztásunkat csak a 10 rackből álló sor alapján méri, nem pedig minden rack alapján, és ha a biztosíték a feltételezett 7kW-os vágáson van, akkor technikailag egy adott rackben 6.9kW-ot, a másikban 5.1kW-ot fogyaszthatunk, és minden rendben lesz — nem büntethető.
Általában a fő célunk a költségek minimalizálása. A legjobb mérőszám a TCO (total cost of ownership — összes megvásárlási költség) csökkentése. Ez a következő elemekből áll:
- CAPEX: az DC infrastruktúra, szerverek, hálózati eszközök és kábelezés beszerzése
- OPEX: DC bérlése, az elfogyasztott áram, karbantartás. Az OPEX függ a szolgáltatás időtartamától. Ésszerű feltételezni, hogy 3 évnek felel meg.
Attól függően, hogy a különböző darabok mekkorák az összes tortában, optimalizálnunk kell a legdrágábbat, míg a többi a lehető leghatékonyabban használhatja a fennmaradó erőforrásokat.
Tegyük fel, hogy van egy meglévő adatközpontunk, van a rack magassága H egységekben (például H=47), áram a rackre Prack (Prack=6 kW), és úgy döntöttünk, hogy 2U-os két egységes szervereket használunk. Eltávolítunk 2-4 egységet a rackből a switchek, patch panelek és rendezők számára. Tehát fizikailag a rackben elfér Sh=rounddown((H-2..4)/h) szerver (azaz Sh = rounddown((47-4)/2)=21 szerver a rackben). Ezt az Sh-t jegyezzük meg.
Egyszerű esetben a rackben minden szerver azonos. Tehát ha megtöltjük a racket szerverek, akkor minden szerverre átlagosan Pserv=Prack/Sh (Pserv = 6000 W/21 = 287 W) teljesítményt tudunk fordítani. Az egyszerűség kedvéért itt figyelmen kívül hagyjuk a switch áramfogyasztását.
Tegyük egy lépést hátra, és határozzuk meg, mi az a maximális áramfogyasztás Pmax. Ha nagyon egyszerűen, nagyon hatékonyan és teljesen biztonságosan akarjuk megtenni, nézzük meg, mi van írva a szerver tápegységén — ez az.
Ha bonyolultabb, hatékonyabb, akkor a komponensek TDP (hőtervezési csomag) értékét összegyűjtjük (ez nem teljesen pontos, de így is lehet).
Általában nem ismerjük a komponensek TDP-jét (kivéve a CPU-t), ezért a leghelyesebb, de legbonyolultabb megközelítést alkalmazzuk (laboratórium szükséges) — veszünk egy kísérleti szervert a szükséges konfigurációval, és megterheljük, például Linpack-kel (CPU és memória) és fio-val (lemezek), és mérjük az áramfogyasztást. Ha komolyan vesszük, akkor a tesztelés alatt a legmelegebb környezetet is létre kell hozni a hideg folyosón, mert ez befolyásolja a ventilátorok és a CPU áramfogyasztását. Így megkapjuk egy konkrét szerver maximális áramfogyasztását adott konfiguráció mellett, ezekben a konkrét körülmények között, ezen konkrét terhelés alatt. Csak tartsuk észben, hogy egy új rendszer firmware, egy másik szoftververzió, más feltételek befolyásolhatják az eredményt.
Tehát visszatérünk a Pserv-hez, és össze kell hasonlítanunk Pmax-szal. Ez a szolgáltatások működésének megértéséről és arról szól, hogy mennyire erősek a technikus idegei.
Ha egyáltalán nem akarunk kockáztatni, akkor úgy számolunk, hogy minden szerver egyszerre elkezdheti elkérni a maksimumát. Ekkor egy bemenet is létrejöhet az adatközpontban. Az infrastruktúrának ezekben a körülmények között is biztosítania kell a szolgáltatást, ezért Pserv ≡ Pmax. Ez egy olyan megközelítés, ahol abszolút fontos a megbízhatóság.
Ha a műszaki igazgató nemcsak a tökéletes biztonságról, hanem a cég pénzügyi helyzetéről is gondoskodik, és elég bátor, akkor a következőt mondhatjuk:
- a beszállítóink kezelése elkezdődik, többek között megtiltjuk a tervezett karbantartás elvégzését a várható csúcsidőszakok során, hogy minimálisra csökkentsük egy bemenet leállásának lehetőségét;
- és/vagy az architektúránk lehetővé teszi, hogy elveszítsünk egy szekrényt/sort/adatközpontot, miközben a szolgáltatások folytatódnak;
- és/vagy jól elosztjuk a terheket vízszintesen a szekrények között, így a szolgáltatásaink soha nem ugornak a maximális fogyasztásra egyetlen szekrényben sem egyszerre.
Itt nagyon hasznos nem csupán találgatni, hanem figyelemmel kísérni a fogyasztást, és tudni, hogy a szerverek valójában hogyan fogyasztanak áramot normál és csúcsidőszakokban. Ezért egy kis elemzés után a műszaki igazgató mindent összegez, és azt mondja: „kényszerítő döntéssel elfogadjuk, hogy a szerverek maximális fogyasztásának átlaga egy szekrényre **ennyivel** alacsonyabb, mint a maximális fogyasztás”, feltételezve, hogy Pserv=0.8*Pmax.
Így egy 6 kW teljesítményű szekrénybe már nem 16 szerver fér bele Pmax = 375 W, hanem 20 szerver Pserv = 375 W * 0.8 = 300 W. Azaz 25%-kal több szerver. Ez hatalmas megtakarítás — hiszen a szekrényekből is 25%-kal kevesebb szükséges (és ott még a PDU-n, switch-eken és kábeleken is spórolhatunk). E megoldás komoly hátránya, hogy folyamatosan figyelni kell, hogy a feltételezéseink továbbra is helyesek. Hogy az új firmware-verzió nem változtatja meg lényegesen a ventilátorok működését és a fogyasztást, hogy a fejlesztés a legújabb kiadással hirtelen nem kezdte el a szervereket sokkal hatékonyabban használni (értsd: nagyobb terhelést és magasabb fogyasztást értek el a szervereken). Mert ha ez megtörténik, akkor az eredeti feltételezéseink és következtetéseink azonnal tévesek lesznek. Ez egy kockázat, amelyet felelősségteljesen el kell fogadni (vagy elkerülni, és akkor fizetni az nyilvánvalóan alulterhelt szekrényekért).
Fontos megjegyzés — érdemes megpróbálni a szervereket különböző szolgáltatásokból vízszintesen elosztani a rack-ek között, ha lehetséges. Erre azért van szükség, hogy elkerüljük azokat a helyzeteket, amikor egy szolgáltatás szerverei egy csoportban érkeznek, és a rack-ek függőlegesen telítődnek, hogy növeljük a „sűrűséget” (mert ez egyszerűbb). Valójában viszont az történik, hogy az egyik rack azonos alacsony terhelésű szerverekből áll, míg a másik azonosan magas terhelésű szerverekből. A második rack leállásának valószínűsége lényegesen magasabb, mivel a terhelési profil azonos, és minden szerver együtt kezdi el fogyasztani azonosan sokat a terhelés növekedése miatt.
Térjünk vissza a rack-ekben található szerverek elosztásához. Megvizsgáltuk a rack helyszíni korlátait és az energiaellátási korlátokat, most nézzük meg a hálózatot is. Használhatunk 24/32/48 portos N switcheket (például 48 portos ToR switchek ). Szerencsére nem sok lehetőség van, ha nem gondolunk az breakout kábelekre. Olyan forgatókönyveket vizsgálunk, amikor van egy switchünk egy rack-ben, egy switchünk két vagy három rackből álló Rnet csoportban. Szerintem három rack-nél több csoportban már túlságosan sok, mert a rack-ek közötti kábelezés problémája jelentősen megnő.
Tehát, minden hálózati forgatókönyv esetén (1, 2 vagy 3 rack csoportban) elosztjuk a szervereket a rack-ek között:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Így a 2 rack közötti lehetőség esetén:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 szerver rack-enként.
Hasonlóan számítjuk ki a többi lehetőséget:
Srack1 = 20
Srack3 = 16
Most már közel vagyunk a célhoz. Számoljuk ki a szükséges rack-ek számát az összes szerverünk elosztásához S (legyen 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 rack
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 rack
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 rack
Ezután kiszámítjuk az TCO-t minden lehetőség esetén a szükséges rack-ek, switchek száma, kábelezés stb. alapján. Az a lehetőség nyer, ahol a TCO alacsonyabb. Profit!
Megjegyzendő, hogy bár az 1 és 2 lehetőséghez szükséges rack-ek száma azonos, az áruk eltérő lesz, mivel a második lehetőséghez szükséges switchek száma fele annyi, míg a kábelek hossza nagyobb.
P.S. Ha van lehetőség a rack teljesítményének és magasságának variálására, a variabilitás növekszik. De a folyamat leegyszerűsíthető a fent leírtak szerint, egyszerűen az opciók kipróbálásával. Igen, több kombináció lesz, de végül is meglehetősen korlátozott számú — a rack táplálása a számításhoz 1 kW-os lépésenként növelhető, a tipikus rackek korlátozott méretválasztékban kaphatók: 42U, 45U, 47U, 48U, 52U. Itt az Excel-es What-If elemzés a Data Table módban segíthet a számításokhoz. Megnézzük a kapott táblázatokat, és kiválasztjuk a minimumot.
Forrás: habr.com
