Оптимизиране на разпределението на сървърите в стелажи

В един от чатовете ми беше зададен въпрос:

— Има ли нещо, което мога да прочета за правилното опаковане на сървъри в шкафове?

Разбрах, че не знам такъв текст, затова написах своя.

Първо, този текст е за физически сървъри във физически центрове за данни (DC). Второ, смятаме, че има доста много сървъри: стотици хиляди; за по-малък брой този текст няма смисъл. Трето, считаме, че имаме три ограничения: физическо пространство в стелажите, захранване на стелаж и оставяме стелажите да стоят в редове, така че да можем да използваме един ToR превключвател за свързване на сървъри в съседни стелажи.

Отговорът на въпроса до голяма степен зависи от това какъв параметър оптимизираме и какво можем да променяме, за да постигнем най-добър резултат. Например, просто трябва да заемем минимум място, за да оставим повече за по-нататъшен растеж. Или може би имаме свобода при избора на височината на стелажите, мощността на стелаж, гнездата в PDU, броя на стелажите в група превключватели (един превключвател за 1, 2 или 3 рака), дължината на проводниците и издърпващата работа ( това е критично в краищата на редовете: с 10 стелажа в един ред и 3 стелажа на суич, ще трябва да издърпате кабелите към друг ред или да използвате недостатъчно портовете в суича) и т.н., и т.н. Отделни истории: избор на сървъри и избор на DC, ще приемем, че са избрани.

Би било добре да разберем някои от нюансите и подробностите, по-специално средното/максималното потребление на сървърите и как ни се доставя електричество. Така че, ако имаме руско захранване от 230V и една фаза на стелаж, тогава машина от 32A може да поеме ~7kW. Да кажем, че номинално плащаме за 6kW на шкаф. Ако доставчикът измерва потреблението ни само за редица от 10 шкафа, а не за всеки шкаф, и ако машината е настроена на условно прекъсване от 7 kW, тогава технически можем да консумираме 6.9 kW в един шкаф, 5.1 kW в друг и всичко ще е наред - ненаказуемо.

Обикновено основната ни цел е да минимизираме разходите. Най-добрият критерий за измерване е намаляването на TCO (общата цена на притежание). Състои се от следните части:

• CAPEX: покупка на DC инфраструктура, сървъри, мрежов хардуер и окабеляване
• OPEX: DC наем, консумация на електроенергия, поддръжка. OPEX зависи от експлоатационния живот. Разумно е да се приеме, че е 3 години.

В зависимост от това колко големи са отделните парчета в общия пай, трябва да оптимизираме най-скъпите и да оставим останалите да използват всички останали ресурси възможно най-ефективно.

Да приемем, че имаме съществуващ DC, има височина на стелажа от H единици (например H=47), електричество на стелаж Prack (Prack=6kW) и решихме да използваме h=2U сървъри с две единици. Ще премахнем 2..4 броя от стелажа за суичове, пач панели и органайзери. Тези. физически имаме Sh=rounddown((H-2..4)/h) сървъри в нашия шкаф (т.е. Sh=rounddown((47-4)/2)=21 сървъра на шкаф). Да си припомним това Ш.

В простия случай всички сървъри в шкаф са идентични. Като цяло, ако напълним стелаж със сървъри, тогава на всеки сървър можем да изразходваме средно мощността Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). За простота ние игнорираме консумацията на превключвател тук.

Нека направим крачка встрани и да определим какво е максималното потребление на сървъра Pmax. Ако е много просто, много неефективно и напълно безопасно, тогава четем какво пише на захранването на сървъра - това е.

Ако е по-сложно, по-ефективно, тогава вземаме TDP (термичен дизайн пакет) на всички компоненти и го обобщаваме (това не е много вярно, но е възможно).

Обикновено не знаем TDP на компонентите (с изключение на процесора), така че предприемаме най-правилния, но и най-сложния подход (имаме нужда от лаборатория) - вземаме експериментален сървър с необходимата конфигурация и го зареждаме, например с Linpack (CPU и памет) и fio (дискове) измерваме консумацията. Ако го приемем на сериозно, трябва да създадем и най-топлата среда в студения коридор по време на тестовете, защото това ще се отрази както на консумацията на вентилатори, така и на консумацията на процесора. Получаваме максималната консумация на конкретен сървър със специфична конфигурация в тези специфични условия при това специфично натоварване. Ние просто имаме предвид, че нов системен фърмуер, различна версия на софтуера и други условия могат да повлияят на резултата.

И така, обратно към Pserv и как го сравняваме с Pmax. Въпрос на разбиране как работят услугите и колко здрави са нервите на вашия технически директор.

Ако изобщо не поемаме рискове, вярваме, че всички сървъри могат едновременно да започнат да консумират максимума си. В същия момент може да възникне един вход в DC. Дори при тези условия инфра трябва да предоставя услуга, така че Pserv ≡ Pmax. Това е подход, при който надеждността е абсолютно важна.

Ако техническият директор мисли не само за идеалната сигурност, но и за парите на компанията и е достатъчно смел, тогава можете да решите, че

• Започваме да управляваме нашите доставчици, по-специално, забраняваме планираната поддръжка по време на планирано пиково натоварване, за да сведем до минимум спада на един вход;
• и/или нашата архитектура ви позволява да загубите шкаф/ред/DC, но услугите продължават да работят;
• и/или ние разпределяме натоварването добре хоризонтално през стелажите, така че нашите услуги никога няма да скочат до максимална консумация в един стелаж заедно.

Тук е много полезно не само да гадаете, но и да следите потреблението и да знаете колко електроенергия действително консумират сървърите при нормални и пикови условия. Ето защо, след известен анализ, техническият директор изстисква всичко, което има, и казва: „ние вземаме волево решение, че максималната постижима средна стойност на максималното потребление на сървър на стелаж е **толкова** под максималното потребление,“ условно Pserv = 0.8* Pmax.

И тогава 6kW шкаф вече не може да побере 16 сървъра с Pmax = 375W, но 20 сървъра с Pserv = 375W * 0.8 = 300W. Тези. 25% повече сървъри. Това е много голяма икономия - в края на краищата веднага се нуждаем от 25% по-малко стелажи (а също така ще спестим от PDU, превключватели и кабели). Сериозен недостатък на такова решение е, че трябва постоянно да следим дали нашите предположения все още са верни. Че новата версия на фърмуера не променя значително работата на вентилаторите и потреблението, че разработката внезапно с новата версия не е започнала да използва сървърите много по-ефективно (прочетете: постигнаха по-голямо натоварване и по-голяма консумация на сървъра). В края на краищата тогава както първоначалните ни предположения, така и изводите веднага стават неверни. Това е риск, който трябва да се поеме отговорно (или да се избегне и след това да се плати за очевидно недостатъчно използвани стелажи).

Важна забележка - трябва да се опитате да разпределите сървъри от различни услуги хоризонтално в стелажи, ако е възможно. Това е необходимо, за да не се случват ситуации, когато пристига една партида сървъри за една услуга, стелажите са вертикално опаковани с нея, за да се увеличи „плътността“ (защото така е по-лесно). В действителност се оказва, че единият шкаф е пълен с идентични нисконатоварени сървъри на една и съща услуга, а другият е пълен с еднакво високонатоварени сървъри. Вероятността от второ падане е значително по-висока, т.к профилът на натоварване е същият и всички сървъри заедно в този шкаф започват да консумират еднакво количество в резултат на увеличеното натоварване.

Да се ​​върнем към разпределението на сървърите в стелажи. Разгледахме физическото пространство в стелажа и ограниченията на мощността, сега нека да разгледаме мрежата. Можете да използвате суичове с 24/32/48 N портове (например имаме 48-портови ToR суичове). За щастие, няма много опции, ако не мислите за прекъсващи кабели. Обмисляме сценарии, когато имаме един комутатор на шкаф, един комутатор за два или три шкафа в Rnet групата. Струва ми се, че повече от три стелажа в група вече са твърде много, защото... проблемът с окабеляването между стелажите става много по-голям.

И така, за всеки мрежов сценарий (1, 2 или 3 стелажа в група), ние разпределяме сървърите между стелажите:

Srack = min(Sh, закръгляване(Prack/Pserv), закръгляване(N/Rnet))

Така за опцията с 2 стелажа в група:

Srack2 = min(21, закръгляване(6000/300), закръгляване(48/2)) = min(21, 20, 24) = 20 сървъра на шкаф.

Разглеждаме останалите опции по същия начин:

Srack1 = 20
Srack3 = 16

И почти стигнахме. Преброяваме броя на стелажите за разпространение на всички наши сървъри S (нека бъдат 1000):

R = заобикаляне (S / (Srack * Rnet)) * Rnet

R1 = заобикаляне (1000 / (20 * 1)) * 1 = 50 * 1 = 50 стелажа

R2 = заобикаляне (1000 / (20 * 2)) * 2 = 25 * 2 = 50 стелажа

R3 = заобикаляне (1000 / (16 * 3)) * 3 = 25 * 2 = 63 стелажа

След това изчисляваме TCO за всяка опция въз основа на броя стелажи, необходимия брой комутатори, окабеляване и т.н. Избираме опцията, при която TCO е по-ниска. печалба!

Обърнете внимание, че въпреки че необходимият брой стелажи за опции 1 и 2 е еднакъв, цената им ще бъде различна, т.к броят на превключвателите за втория вариант е наполовина по-малък, а дължината на необходимите кабели е по-голяма.

PS Ако имате възможност да играете с мощността на багажник и височината на багажника, променливостта се увеличава. Но процесът може да бъде намален до описания по-горе, като просто преминете през опциите. Да, ще има повече комбинации, но все пак много ограничен брой - захранването на шкафа за изчисление може да се увеличава на стъпки от 1 kW, типичните шкафове се предлагат в ограничен брой стандартни размери: 42U, 45U, 47U, 48U , 52U. И тук анализът Какво-Ако на Excel в режим Таблица с данни може да помогне с изчисленията. Разглеждаме получените табели и избираме минимума.

Източник: www.habr.com