В един от чатове ми зададоха въпрос:
— Има ли нещо, което да прочета, за това как правилно да опаковам сървъри в шкафове?
Разбрах, че не знам такъв текст, затова написах своя.
На първо място, този текст е за физически сървъри в физически дата центрове (ДЦ). На второ място, да приемем, че имаме много сървъри: стотици до хиляди, за по-малко количество този текст няма смисъл. На трето място, да предположим, че имаме три ограничения: физическо място в шкафовете, електрическа мощност на шкаф, и нека шкафовете бъдат подредени в редове, така че да можем да използваме един ToR превключвател за свързване на сървърите в съседни шкафове.
Отговорът на въпроса силно зависи от това, кой параметър оптимизираме и какво можем да променяме, за да постигнем най-добри резултати. Например, може би ни е важно да заемем минимум пространство, за да оставим повече за бъдещ растеж. Или пък имаме свобода при избора на височина на шкафовете, мощността на шкаф, контакти в PDU, броя на шкафовете в групата на превключвателите (един превключвател за 1, 2 или 3 шкафа), дължини на проводниците и работи по инсталация (това е критично в краищата на редовете: при 10 шкафа в един ред и 3 шкафа на превключвателя, ще трябва да протягаме проводници в друг ред или да недоизползваме портовете на превключвателя), и т.н. Отделни истории: избор на сървъри и избор на ДЦ, да приемем, че те са избрани.
Би било добре да разберем някои нюанси и подробности, в частност, средното/максимално потребление на сървърите и как получаваме електричеството. Така, ако имаме руско електрическо захранване с 230V и една фаза на шкаф, 32A автомат може да поддържа ~7kW. Да предположим, че номинално плащаме за 6kW на шкаф. Ако доставчикът измерва нашето потребление само по реда от 10 шкафа, а не по всеки шкаф, и ако автоматът стои на ограничение условно 7kW, то технически можем в един шкаф да консумираме 6.9kW, в друг 5.1kW и всичко ще бъде наред — безнаказано.
Обикновено нашата основна цел е минимизация на разходите. Най-добрият критерий за измерване — намаляване на TCO (общите разходи за собственост). Тя се състои от следните части:
- CAPEX: закупуване на инфраструктура за ДЦ, сървъри, мрежово оборудване и кабели
- OPEX: наем на ДЦ, консумирано електричество, обслужване. OPEX зависи от срока на експлоатация. Разумно е да предположим, че е равен на 3 години.
В зависимост от размера на отделните парчета от общата торта, трябва да оптимизираме най-скъпоценните, а останалото нека да използва всичките останали ресурси възможно най-ефективно.
Да приемем, че имаме съществуващ DC, имаме височина на шкафа H единици (например H=47), електричество на шкаф Prack (Prack=6kW) и решаваме да използваме 2U двуединични сървъри. Ще премахнем 2..4 единици от шкафа за суичове, патч панели и организатори. Тоест физически в шкафа ни побират Sh=rounddown((H-2..4)/h) сървъра (т.е. Sh = rounddown((47-4)/2)=21 сървър на шкаф). Нека запомним това Sh.
В простия случай всички сървъри в шкафа са еднакви. Следователно, ако запълним шкафа сървъри, ще можем в средно да изразходваме мощност Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). За опростяване тук игнорираме потреблението на суича.
Нека направим крачка назад и да определим какво е максималното потребление на сървъра Pmax. Ако много просто, много неефективно и напълно безопасно, прочитаме какво е написано на захранващия блок на сървъра — това е то.
Ако е по-сложно, по-ефективно, тогава взимаме TDP (топлинния дизайн пакет) на всички компоненти и ги сумираме (това не е съвсем вярно, но може и така).
Обикновено не знаем TDP на компонентите (с изключение на CPU), така че приемаме най-правилния, но и най-сложен подход (необходима е лаборатория) — взимаме експериментален сървър с необходимата конфигурация и го натоварваме, например, с Linpack (CPU и памет) и fio (дискове), измерваме потреблението. Ако подходим сериозно, трябва също така да създадем най-топлата среда в студения коридор по време на тестовете, защото това влияе както на потреблението на вентилаторите, така и на потреблението на CPU. Получаваме максималното потребление на конкретен сървър с конкретна конфигурация при тези конкретни условия под това конкретно натоварване. Просто имаме предвид, че новия софтуерен фърмуер, другата версия на софтуера, различни условия могат да повлияят на резултата.
Следователно, връщаме се към Pserv и как да го сравним с Pmax. Това е въпрос на разбиране на работата на услугите и колко здрави нерви има вашият техдир.
Ако не искаме да рискуваме, считаме, че всички сървъри могат едновременно да започнат да потребяват максимума си. В този момент може да се съобрази един вход в DC. Инфраструктурата и при тези условия трябва да предоставя услуга, така че 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(Sh, rounddown(Prack/Pserv), rounddown(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 за всеки вариант на база на броя стойки, необходимото количество суичове, кабели и т.н. Избираме варианта, при който TCO е по-малко. Печалба!
Забележете, че въпреки че необходимото количество стойки за варианти 1 и 2 е едно и също, цената им ще бъде различна, тъй като броят на суичовете за втория вариант е наполовина по-малък, а дължината на необходимите кабели е по-голяма.
P.S. Ако имате възможност да играете с мощността на стелажа и височината на стелажа, вариативността се увеличава. Но процесът може да бъде сведени до горепосоченото, просто разучавайки вариантите. Да, комбинациите ще бъдат повече, но все пак броят им е доста ограничен — захранването на стелажа за изчисление може да се увеличава с нарастваща стъпка от 1 кВт, стандартните стелажи обикновено имат ограничен брой формати: 42U, 45U, 47U, 48U, 52U. И тук за изчислението може да помогне Excel'овият What-If анализ в режим Data Table. Гледаме получените таблици и избираме минималното.
Източник: habr.com
