У адным з чатаў мне задалі пытанне:
- А ёсць нешта пачытаць, як правільна пакаваць сервера ў стойкі?
Я зразумеў, што такога тэксту ня ведаю, таму напісаў свой.
Па-першае, гэты тэкст пра фізічныя сервера ў фізічных дата цэнтрах (ДЦ). Па-другое, лічым, што сервераў дастаткова шмат: сотні-тысячы, для меншай колькасці гэты тэкст не мае сэнсу. Па-трэцяе, лічым, што ў нас ёсць тры абмежавальнікі: фізічнае месца ў стойках, электрасілкаванне на стойку, і няхай стойкі стаяць у шэрагах, так што мы можам выкарыстоўваць адзін ToR світч для падлучэння сервераў у суседніх стойках.
Адказ на пытанне моцна залежыць ад таго, які параметр мы аптымізуем і што мы можам вар'іраваць, каб дабіцца найлепшага выніку. Напрыклад, нам толькі трэба заняць мінімум месца, каб больш пакінуць на далейшы рост. А можа, у нас ёсць свабода ў выбары вышыні стоек, магутнасці на стойку, разетак у PDU, колькасці стоек у групе скруткаў (адзін світч на 1, 2 ці 3 стойкі), даўжыні правадоў і работ па працяжцы (гэта крытычна на канцах шэрагаў: пры 10-ці стойках шэрагу і 3-х стойках на скрутак прыйдзецца цягнуць правады ў іншы шэраг або недавыкарыстоўваць парты ў світцы), etc., etc. Асобныя гісторыі: выбар сервераў і выбар ДЦ, будзем лічыць, што яны абраны.
Добра было б разумець некаторыя нюансы і падрабязнасці, у прыватнасці, сярэдняе/максімальнае спажыванне сервераў, і як нам падаецца электрычнасць. Так, калі ў нас расійскае харчаванне 230В і адна фаза на стойку, то 32А аўтамат можа трымаць ~7кВт. Дапусцім, мы намінальна плацім за 6кВт на стойку. Калі правайдэр мерае наша спажыванне толькі па шэрагу з 10 стоек, а не па кожнай стойцы, і калі аўтамат стаіць на адсечцы ўмоўна 7кВт, то тэхнічна мы можам у асобна ўзятай стойцы зжэрці 6.9кВт, у іншай 5.1кВт і ўсё будзе ок - непакарана.
Звычайна наша асноўная мэта - гэта мінімізацыя выдаткаў. Лепшы крытэр для вымярэння – зніжэнне TCO (total cost of ownership – сукупны кошт валодання). Яна складаецца з наступных кавалкаў:
- CAPEX: закупка інфраструктуры ДЦ, сервераў, сеткавых жалязяк і кабеляванне
- OPEX: арэнда ДЦ, спажыванае электрычнасць, абслугоўванне. OPEX залежыць ад тэрміна службы. Разумна выказаць здагадку яго роўным 3 гадам.
У залежнасці ад таго, наколькі вялікія асобныя кавалкі ў агульным пірагу, нам трэба аптымізаваць самае дарагое, а астатняе няхай выкарыстоўвае ўсе астатнія рэсурсы як мага больш эфектыўна.
Дапушчальны, у нас ёсць ужо існы ДЦ, ёсць вышыня стойкі H юнітаў (для прыкладу H=47), электрычнасць на стойку Prack (Prack=6кВт), і мы вырашылі выкарыстаць h=2U двухюнітавыя серверы. Прыбяром 2..4 юніта са стойкі на світчы, патч панэлі і арганайзеры. Г.зн. фізічна, у нас у стойцы змяшчаецца Sh=rounddown((H-2..4)/h) сервераў (г.зн. Sh = rounddown((47-4)/2)=21 сервер на стойку). Запомнім гэта Sh.
У простым выпадку ўсе серверы ў стойцы аднолькавыя. Разам, калі мы заб'ем стойку серверамі, то на кожны сервер мы зможам у сярэднім выдаткаваць магутнасць Pserv = Prack / Sh (Pserv = 6000Вт / 21 = 287Вт). Для прастаты мы тут ігнаруем спажыванне світача.
Зробім крок у бок і вызначымся, што такое максімальнае спажыванне сервера Pmax. Калі вельмі проста, вельмі неэфектыўна і зусім бяспечна, то чытэльны, што напісана на блоку сілкавання сервера - гэта яно.
Калі складаней, больш эфектыўна, то бярэм TDP (thermal design package) усіх кампанентаў і сумуем (гэта не вельмі праўда, але можна і так).
Звычайна мы TDP кампанентаў (акрамя CPU) не ведаем, таму бярэм самы правільны, але і самы складаны падыход (патрэбная лабараторыя) - бярэм эксперыментальны сервак патрэбнай канфігурацыі і нагружаем яго, напрыклад, Linpack'ом (CPU і памяць) і fio (дыскі) , мераем спажыванне. Калі падыходзіць сур'ёзна, то трэба яшчэ і стварыць найболей цёплае асяроддзе ў халодным калідоры падчас тэстаў, таму што гэта ўплывае і на спажыванне вентылятараў, і на спажыванне CPU. Атрымліваем максімальнае спажыванне канкрэтнага сервера з канкрэтнай канфігурацыяй у гэтых канкрэтных умовах пад гэтай канкрэтнай нагрузкай. Проста маем на ўвазе, што новая прашыўка сістэмы, іншая версія софту, іншыя ўмовы могуць паўплываць на вынік.
Разам вяртаемся да Pserv і як нам яго параўнаць з Pmax. Гэта пытанне разумення працы сэрвісаў і таго, наколькі моцныя нервы ў вашага тэхдзіра.
Калі зусім не рызыкаваць, то лічым, што ўсе серверы могуць аднамомантна пачаць спажываць свой максімум. У гэты ж момант можа скласціся адзін увод у ДЦ. Інфра і ў гэтых умовах павінна падаваць сэрвіс, таму Pserv ≡ Pmax. Гэта падыход, дзе абсалютна важная надзейнасць.
Калі ж тэхдзір думае не толькі аб ідэальнай бяспецы, але і аб грошах кампаніі і досыць смелы, то можна вырашыць, што
- мы пачынаем мяняваць нашых вендараў, у прыватнасці, забараняем праводзіць планавае абслугоўванне ў моманты планаванай пікавай нагрузкі для мінімізацыі падзення аднаго ўводу;
- і/ці наша архітэктура дазваляе страціць стойку/шэраг/ДЦ, а сэрвісы працягваюць працаваць;
- і/ці мы добра размазваем нагрузку гарызантальна па стойках, таму нашы сэрвісы ніколі не скокнуць да максімальнага спажывання ў адной стойцы ўсё разам.
Тут вельмі карысна не проста варажыць, а маніторыць спажыванне і ведаць, як рэальна ў звычайных і пікавых умовах сервера спажываюць электрычнасць. Таму пасля некаторага аналізу тэхдзір сціскае ўсё, што ў яго ёсць, і кажа: «мы валявым рашэннем прымаем, што максімальна дасягальнае сярэдняе ад максімумаў спажывання сервераў на стойку на **столькі вось ніжэй за максімальнае спажыванне», умоўна Pserv=0.8* Pmax.
І тады ў стойку на 6кВт залазіць ужо не 16 сервераў з Pmax = 375Вт, а 20 сервераў з Pserv = 375Вт * 0.8 = 300Вт. Г.зн. на 25% больш сервераў. Гэта вельмі вялікая эканомія - бо і стоек нам адразу трэба на 25% менш (а там яшчэ і на PDU, свитчах ды кабелях зэканомім). Сур'ёзны мінус такога рашэння - трэба стала маніторыць, што нашы здагадкі ўсё яшчэ дакладныя. Што новая версія прашыўкі не змяняе істотнай выявай працу вентылятараў і спажыванні, што распрацоўка раптам з новым рэлізам не пачала выкарыстаць сервера значна эфектыўней (чытай дамагліся большай загрузкі і большага спажывання на сервер). Бо тады і нашы першапачатковыя здагадкі, і высновы адразу становяцца няслушнымі. Гэта рызыка, якую трэба адказна прымаць (ці пазбягаць і тады плаціць за відавочна недагружаныя стойкі).
Важная заўвага - варта спрабаваць размяркоўваць сервера з розных сэрвісаў па стойках гарызантальна, калі гэта магчыма. Гэта трэба, каб не здараліся гісторыі, калі адна партыя сервераў для аднаго сэрвісу прыходзіць, стойкі вертыкальна забіваюцца ёю для падвышэння "шчыльнасці" (таму што так прасцей). У рэальнасці ж атрымліваецца, што адна стойка забітая аднолькавымі нізканагружанымі серверамі аднаго сэрвісу, а іншая - аднолькава высоканагружанымі. Верагоднасць падзення другой істотна вышэйшая, т.я. профіль нагрузкі аднолькавы, і ўсе серверы разам у гэтай стойцы пачынаюць спажываць аднолькава шмат у выніку падвышэння нагрузкі.
Вернемся да размеркавання сервераў у стойках. Мы разгледзелі фізічныя абмежаванні па месцы ў стойцы і абмежаванні па электрасілкаванні, зараз зірнем і на сетку. Можна выкарыстоўваць світчы на 24/32/48 партоў N (для прыкладу ў нас 48-партовыя ToR світчы). Варыянтаў, на шчасце, не так шмат, калі не задумвацца аб break-out кабелях. Разглядаем сцэнары, калі ў нас ёсць адзін світч на стойку, адзін світч на дзве ці тры стойкі ў групе Rnet. Мне здаецца, што больш за тры стоек у групе – ужо перабор, т.я. праблема кабелявання паміж стойкамі становіцца моцна больш.
Такім чынам, для кожнага сеткавага сцэнара (1, 2 ці 3 стойкі ў групе) размяркоўваем сервера па стойках:
Srack = min(Ш, раўндны(Prack/Pserv), раўндны(N/Rnet))
Такім чынам, для варыянту з 2 стойкамі ў групе:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 сервераў на стойку.
Аналагічна лічым астатнія варыянты:
Srack1 = 20
Srack3 = 16
І мы практычна ля мэты. Лічым колькасць стоек для размеркавання ўсіх нашых сервераў S (хай будзе 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 стоек
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 стоек
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 стойкі
Далей лічым TCO для кожнага варыянту на падставе колькасці стоек, неабходнай колькасці свіцей, кабелявання, etc. Выбіраемы той варыянт, дзе TCO менш. Profit!
Заўважым, што хоць неабходная колькасць стоек для варыянтаў 1 і 2 аднолькава, іх кошт будзе рознай, т.я. колькасць скруткаў для другога варыянту ўдвая менш, а даўжыня неабходных кабеляў больш.
PS Калі ёсць магчымасць пагуляць магутнасцю на стойку і вышынёй стойкі, варыятыўнасць павялічваецца. Але працэс можна звесці да вышэйапісанага, проста перабіраючы варыянты. Так, камбінацый будзе пабольш, але ўсёткі вельмі абмежаваную колькасць - харчаванне на стойку для разліку можна павялічваць з крокам па 1 квт, тыпавыя стойкі бываюць абмежаванай колькасці тыпаразмераў: 42U, 45U, 47U, 48U, 52U. І тут для разліку можа дапамагчы Excel'еўскі What-If analysis у рэжыме Data Table. Глядзім на атрыманыя таблічкі і выбіраемы мінімум.
Крыніца: habr.com