Оптимизирање на дистрибуцијата на сервери низ решетките

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

— Дали има нешто што можам да прочитам за тоа како правилно да ги спакувам серверите во решетки?

Сфатив дека не знам таков текст, па го напишав мојот.

Прво, овој текст е за физички сервери во физички центри за податоци (DC). Второ, веруваме дека има доста сервери: стотици илјади; за помал број овој текст нема смисла. Трето, сметаме дека имаме три ограничувања: физички простор во решетките, напојување по решетката и оставете ги решетките да стојат во редови за да можеме да користиме еден ToR прекинувач за поврзување на сервери во соседните решетки.

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

Би било добро да се разберат некои нијанси и детали, особено просечната/максималната потрошувачка на серверите и како ни се снабдува електрична енергија. Значи, ако имаме руско напојување од 230V и една фаза по багажник, тогаш машина од 32А може да издржи ~7kW. Да речеме дека номинално плаќаме за 6 kW по багажник. Ако давателот ни ја мери потрошувачката само за ред од 10 решетки, а не за секоја решетка, и ако машината е поставена на условно прекинување од 7 kW, тогаш технички можеме да потрошиме 6.9 kW во една решетка, 5.1 kW во друга и се ќе биде во ред - не е казниво.

Обично нашата главна цел е да ги минимизираме трошоците. Најдобар критериум за мерење е намалувањето на TCO (вкупните трошоци на сопственост). Се состои од следните делови:

• CAPEX: купување на DC инфраструктура, сервери, мрежен хардвер и кабли
• ОПЕКС: ДК изнајмување, потрошувачка на електрична енергија, одржување. OPEX зависи од работниот век. Разумно е да се претпостави дека е 3 години.

Во зависност од тоа колку големи се поединечните парчиња во целокупната пита, треба да го оптимизираме најскапиот, а останатите да ги искористиме сите преостанати ресурси што е можно поефикасно.

Да речеме дека имаме постоен DC, има висина на решетката од H единици (на пример, H=47), електрична енергија по решетката Prack (Prack=6kW) и решивме да користиме h=2U сервери со две единици. Ќе отстраниме 2..4 единици од решетката за прекинувачи, печ-панели и организатори. Оние. физички, имаме Sh=rounddown((H-2..4)/h) сервери во нашиот rack (т.е. Sh = rounddown((47-4)/2)=21 сервер по решетката). Да се ​​потсетиме на овој Ш.

Во едноставен случај, сите сервери во решетката се идентични. Севкупно, ако пополниме решетката со сервери, тогаш на секој сервер во просек можеме да ја трошиме моќноста Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). За едноставност, овде ја игнорираме потрошувачката на прекинувачот.

Ајде да тргнеме настрана и да одредиме која е максималната потрошувачка на серверот Pmax. Ако е многу едноставно, многу неефикасно и целосно безбедно, тогаш читаме што е напишано на напојувањето на серверот - ова е тоа.

Ако е покомплицирано, поефикасно, тогаш го земаме TDP (пакет за термички дизајн) од сите компоненти и го сумираме (ова не е многу точно, но е можно).

Обично не го знаеме TDP на компонентите (освен процесорот), па затоа го земаме најточниот, но и најкомплексниот пристап (ни треба лабораторија) - земаме експериментален сервер со потребната конфигурација и го вчитуваме, на пример, со Linpack (процесорот и меморија) и fio (дискови) ја мериме потрошувачката. Ако го сфатиме сериозно, треба да создадеме и најтопла средина во студениот коридор за време на тестовите, бидејќи тоа ќе влијае и на потрошувачката на вентилаторот и на потрошувачката на процесорот. Добиваме максимална потрошувачка на одреден сервер со специфична конфигурација во овие специфични услови под ова специфично оптоварување. Едноставно мислиме дека новиот системски фирмвер, различна верзија на софтверот и други услови може да влијаат на резултатот.

Значи, назад на Pserv и како го споредуваме со Pmax. Тоа е прашање на разбирање како функционираат услугите и колку се силни нервите на вашиот технички директор.

Ако воопшто не преземаме никакви ризици, веруваме дека сите сервери можат истовремено да почнат да го трошат својот максимум. Во истиот момент, може да се појави еден влез во DC. Дури и под овие услови, инфра мора да обезбеди услуга, така што Pserv ≡ Pmax. Ова е пристап каде сигурноста е апсолутно важна.

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

• Почнуваме да управуваме со нашите продавачи, особено, забрануваме планирано одржување во моменти на планирано максимално оптоварување за да го минимизираме падот на еден влез;
• и/или нашата архитектура ви дозволува да изгубите багажник/ред/DC, но услугите продолжуваат да работат;
• и/или го шириме товарот добро хоризонтално низ решетките, така што нашите услуги никогаш нема да скокнат до максимална потрошувачка во една решетка сите заедно.

Овде е многу корисно не само да се погоди, туку да се следи потрошувачката и да се знае како серверите всушност трошат електрична енергија во нормални и шпиц услови. Затоа, по некоја анализа, технолошкиот директор стиска сè што има и вели: „донесуваме доброволна одлука дека максималниот достижен просек од максималната потрошувачка на сервер по решетката е **толку** под максималната потрошувачка“, условно Pserv = 0.8* Pmax.

И тогаш решетката од 6 kW повеќе не може да прими 16 сервери со Pmax = 375W, туку 20 сервери со Pserv = 375W * 0.8 = 300W. Оние. 25% повеќе сервери. Ова е многу голема заштеда - на крајот на краиштата, веднаш ни требаат 25% помалку решетки (а ќе заштедиме и на PDU, прекинувачи и кабли). Сериозен недостаток на таквото решение е тоа што мора постојано да следиме дека нашите претпоставки се уште се точни. Дека новата верзија на фирмверот не ја менува значително работата на вентилаторите и потрошувачката, дека развојот наеднаш со новото издание не почна да ги користи серверите многу поефикасно (читај: постигнаа поголемо оптоварување и поголема потрошувачка на серверот). На крајот на краиштата, тогаш и нашите првични претпоставки и заклучоци веднаш стануваат неточни. Ова е ризик што мора да се преземе одговорно (или да се избегне и потоа да се плати за очигледно недоволно искористените лавици).

Важна забелешка - треба да се обидете да дистрибуирате сервери од различни услуги хоризонтално низ лавиците, ако е можно. Ова е неопходно за да не се случуваат ситуации кога пристигнува една серија сервери за една услуга, решетките се вертикално набиени со неа за да се зголеми „густината“ (бидејќи така е полесно). Во реалноста, излегува дека едната решетка е исполнета со идентични сервери со мала оптовареност на истата услуга, а другата е исполнета со сервери со подеднакво високо оптоварување. Веројатноста за втор пад е значително поголема, бидејќи профилот на оптоварување е ист, и сите сервери заедно во оваа решетка почнуваат да трошат иста количина како резултат на зголеменото оптоварување.

Да се ​​вратиме на дистрибуцијата на сервери во лавици. Го разгледавме физичкиот простор на решетката и ограничувањата на моќноста, сега ајде да ја погледнеме мрежата. Можете да користите прекинувачи со порти 24/32/48 N (на пример, имаме ToR прекинувачи со 48 порти). За среќа, нема многу опции ако не размислувате за пробивни кабли. Размислуваме за сценарија кога имаме еден прекинувач по решетка, еден прекинувач за две или три решетки во групата Rnet. Ми се чини дека повеќе од три лавици во група се веќе премногу, бидејќи ... проблемот со кабли меѓу решетките станува многу поголем.

Значи, за секое мрежно сценарио (1, 2 или 3 решетки во група), ги дистрибуираме серверите меѓу решетките:

Srack = min (Sh, заокружување (Prack/Pserv), заокружување (N/Rnet))

Така, за опцијата со 2 лавици во група:

Srack2 = мин (21, заокружување (6000/300), заокружување (48/2)) = мин (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 е ист, нивната цена ќе биде различна, бидејќи бројот на прекинувачи за втората опција е половина повеќе, а должината на потребните кабли е поголема.

П.С. Ако можете да си играте со моќноста по решетка и висината на решетката, варијабилноста се зголемува. Но, процесот може да се сведе на оној опишан погоре со едноставно поминување низ опциите. Да, ќе има повеќе комбинации, но сепак многу ограничен број - напојувањето на решетката за пресметка може да се зголеми во чекори од 1 kW, типичните лавици доаѓаат во ограничен број на стандардни големини: 42U, 45U, 47U, 48U , 52 U. И тука анализата What-If на Excel во режим на Табела со податоци може да помогне во пресметките. Ги гледаме примените таблички и го избираме минимумот.

Извор: www.habr.com