— А есть что-то почитать, как правильно упаковывать сервера в стойки?
Я понял, что такого текста не знаю, поэтому написал свой.
Во-первых, этот текст про физические сервера в физических дата центрах (ДЦ). Во-вторых, считаем, что серверов достаточно много: сотни-тысячи, для меньшего количества этот текст не имеет смысла. В-третьих, считаем, что у нас есть три ограничителя: физическое место в стойках, электропитание на стойку, и пусть стойки стоят в рядах, так что мы можем использовать один 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(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 для каждого варианта на основании количества стоек, необходимого количества свитчей, кабелирования, etc. Выбираем тот вариант, где TCO меньше. Profit!
Заметим, что хотя необходимое количество стоек для вариантов 1 и 2 одинаково, их цена будет разной, т.к. количество свитчей для второго варианта вдвое меньше, а длина необходимых кабелей больше.
P.S. Если есть возможность поиграть мощностью на стойку и высотой стойки, вариативность увеличивается. Но процесс можно свести к вышеописанному, просто перебирая варианты. Да, комбинаций будет побольше, но все-таки весьма ограниченное количество — питание на стойку для расчета можно увеличивать с шагом по 1 кВт, типовые стойки бывают ограниченного количества типоразмеров: 42U, 45U, 47U, 48U, 52U. И тут для расчета может помочь Excel'евский What-If analysis в режиме Data Table. Смотрим на полученные таблички и выбираем минимум.
Комментарии (17)
safari2012
01.11.2019 10:34В-третьих, считаем, что у нас есть три ограничителя: физическое место в стойках, электропитание на стойку, и пусть стойки стоят в рядах, так что мы можем использовать один ToR свитч для подключения серверов в соседних стойках.
Вы как-то забыли взять в расчет отведение тепла…emirochnik Автор
01.11.2019 10:50Я считал, что это очевидно и подразумевается без обсуждений: ДЦ должен по умолчанию уметь отвести всё то электричество и соответственно то генерируемое тепло, что он подает в машинный зал.
Поэтому если мы не превышаем выделенное питание на стойку какое-то значимое время, тепло тут влиять не должно.
Если мы говорим о том, что вендор при проектировании «соптимизировал» и с машинного зала IT-мощностью 1МВт может отвести не более 700кВт тепла в расчете, что нагрузка выше 70% никогда не поднимется, то это мне кажется обманом клиента. Это надо тщательно проверять при выборе ДЦ.safari2012
01.11.2019 11:20есть нормативы тепла на одну стойку. на нормативы влияет множество факторов, например наличие холодных и горячих коридоров, изоляция коридоров, каким образом отводится тепло, и.т.д.
вы можете напихать в одну стойку столько горячих серверов, что тепло отвести оттуда будет физически невозможно. ДЦ вам даст данные, сколько он гарантирует отвести от одной стойки, а дальше ваш головняк, взять это в расчет или нет.emirochnik Автор
01.11.2019 11:26А как именно нормативы тепла на одну стойку отличаются от предлагаемого электричества для этой стойки?
safari2012
01.11.2019 11:46+1Электричество подается в расчёте не на одну стойку, а на ряд (один автомат на несколько стоек, в каждый шкаф, минимум по две фазы от разных ИБП). Соответственно, где-то будет перекос. Где-то будет практически не продуваемый горячий Hi End дисковый массив, а где-то едва теплое телеком оборудование или ленточная библиотека. И вам придется думать, как это распределить более равномерно по разным стойкам.
emirochnik Автор
01.11.2019 12:42Электричество подают в стойки по-разному. У Вас — по две фазы на ряд с автоматом на каждую фазу. Ок. У других — трехфазные автоматы на каждую стойку на каждый из двух вводов в стойку от разных ИБП, у третьих — это два трехфазных ввода с отводными коробками и автоматами на шинопроводах без резервирования на каждую стойку, у четвертых — по 4 однофазных ввода с автоматами в стойку от 4-х разных ИБП. На всё есть свои резоны.
Мне, например, в первом подходе не нравится мысль, что чужая закоротившая железяка или несколько чужих жрущих электричество как не в себя биткойн-майнеров из соседней стойки могут отрубить автомат и для моей стойки тоже. Но, видимо, такой сервис должен стоить дешевле для клиента.
Во-вторых, считаем, что серверов достаточно много: сотни-тысячи, для меньшего количества этот текст не имеет смысла.
Где сотни-тысячи серверов, разговор должен быть о десятках-сотнях стоек. В этом случае куда правильнее регламентировать питание на стойку, и это питание на стойку должно быть меньше либо равно отводимому от этой стойки теплу в масштабах машзала. Понятно, что мы отводим тепло не от одной единственной конкретной стойки.
Поэтому телеком оборудование и ленточная библиотека нас в этом контексте не интересуют. Мы распределяем существенно много подобных друг другу серверов по соседним стойкам в рядах. И я упомянул, что их надо распределять горизонтально — такое распределение эффективным образом улучшает теплоотвод.
Наверное, стоило написать, что перед началом распределения стойки пустые.
Longenen
01.11.2019 13:25+1В чём смысл 47-вершковых стоек?
Есть куда более практичные 42U, они в лифт грузовой без проблем лезут, и обслуживание верхних юнитов упрощают.
Эзернетные и SAN свитчи занимают 4U сверху, итого 38 юнитов. Всё равно больше 16 двухюнитовых серверов нам питание не позволит. Остаётся пара PDU cнизу и 4 юнита под ящик с барахлом. Сервера туда ставить рисково, сервисники ходят и грязь тащат.
Что касается разных блейд-корзин, всё равно из-за веса больше двух в шкаф вешать плохо, да и питания с охлаждением по одной фазе — впритык.
А что до стораджей их вообще имеет смысл поставить в обособленную зону. А поскольку потребление любых массивов это в основном диски, то даже разнотипные массивы можно развесить по фазам, так что перекоса фаз не будет. Ленточку можно приткнуть где-нибуть с краю, в менее продуваемой части (обычно начало ряда), особенно если ленточка больше стандартной плитки. Туда же выкинуть коммутацию зоны, оптику и менеджмент.
maxsl78
01.11.2019 19:38Что значит питание не позволит? Ладно еще отвод тепла. Если владелец ДЦ сэкономил на кабеле, автоматах и PDU и 5-7 кВА лимит на секцию — то в случае коллокейшена будет терять место в никуда.
Ну и в целоv есть еще вские инхаус серверные, контенеры и прочие мини цоды где +6-8 юнитов вверх решают…
emirochnik Автор
01.11.2019 20:33Смысл 47U, 48U и даже 52U в том, что они с одной стороны выше, а с другой имеют какую-то другую стоимость. Пусть какой-то производитель предлагает 45U или 47U по цене 42U. Что брать будете?
Не в каждом дата центре лифты двухметровые. Совсем даже наоборот, в отличие от браунфилдов (как-то переделанных заводских/офисных/складских зданий), гринфилды — специально спроектированные и построенные датацентры — делаются с просторными грузовыми лифтами и с большой высотой проемов и дверей по пути следования стоек, например, 2400мм.
Дальше подумаем про место в стойках не для свитчей: разве везде и всегда только Ethernet и FC свитчи? А второй ethernet свитч для устранения единой точки отказа, а менеджмент свитч, а хотя бы 1U для кабелей у каждого свитча, а патч панель в стойке (хорошо, если она модульная и только одна, а если отдельно оптика и отдельно медь). И я еще очень надеюсь, что про все устройства подумали заранее, и нам не надо втыкать в стойку ATS. При этом для расстановок сотен-тысяч серверов мы точно используем вертикальные zero-unit PDUs, которые не занимают наших юнитов. «Ящики с барахлом», «сервисников с грязью» и «ленточку» я комментировать не буду.
Питание в стойках бывает разное не только по способу подключения, как я написал выше, но и по подведенной мощности: смешные 3кВт, или почти предельные для одной фазы в России 7кВт, или трехфазные 12кВт — это не предел (на 32А и 380В предел получается в 21кВт, но и его можно обойти, если надо). Сервера бывают и высотой не только 2U, но и 1U, и это отличный выбор для серверов приложений, особенно, когда есть отдельные хранилища. И при очень условной потребляемой мощности 1U сервера в 300Вт и предоставленной 12кВт на стойку наши сервера отлично займут 40 юнитов, а оставшихся двух юнитов для свитчей, скорее всего, не хватит. Тут нам захочется иметь более высокие стойки.
Чтобы более подробно отвечать на вопрос, какие стойки более правильные, надо понимать как ограничения, так и экономику датацентра, соотношение затрат на землю, строительство, электропитание, охлаждение, etc. И эта экономика уникальна для каждого отдельного проекта. Обычно электрика — это самая дорогая часть в России (но не обязательно в других странах), поэтому ее надо утилизировать полностью даже за счет того, что часть стоек не будет заполнена. Этот воздух в стойках обычно дешевле недоиспользованного электричества.
Что касается стораджей, а в более общем случае вопрос распределения разнородных типов оборудования, то это заслуживает отдельной статьи. Как и вопрос балансировки по фазам.
r3l0c
02.11.2019 16:06Если автомат выбивает на 7квт то мы не сможем нагрузить его на 6.9, даже на 6 не сможем. Максимум пять. Иначе через час работы он отстрельнет тк разогреется. Для тех кто хочет сказать мол юзайте нормальные автоматы, а не китайское говно- отвечу что "нормальные" автоматы ведут себя так же как и китайские в случае продолжительной нагрузки)
emirochnik Автор
03.11.2019 02:17Если внимательно посмотреть на время-токовые характеристики ваших автоматов, сравнить их с реальной температурой окружающей среды места их установки и точно замерить, что ваша нагрузка и вправду не превышает номинала/уставки автомата, то проблема может быть в их качестве. Тогда надо предъявлять их обратно производителю.
Но я сильно сомневаюсь, потому что для автоматов типов B, C, D ток минимум в 1.13 от номинала автомат должен держать 10000 минут при +30°С. И такие автоматы — это очень надежно отработанная техника.
См. тут.
remzalp
тут мне кажется Вы сказали меньше, чем могло бы быть.
Как минимум имеет смысл не хранить все реплики БД в одной стойке
emirochnik Автор
Да, конечно.
И больше того, надо распределять реплики БД не просто по разным стойкам, но по разным свитчам в случае, если у нас сервера подключены только к одному ToR свитчу. Это нужно помнить в случае, когда у нас не один свитч на стойку, а один на две, три. Так, оба инстанса БД в соседних стойках умрут одновременно с падением одного свитча, к которому они подключены.
gecube
А еще упомянуть необходимость резервирования коммутаторов, ввода питания и пр… Все-таки экономия должна быть разумной, а не оголтелой.
emirochnik Автор
Это был простой вопрос и относительно простой ответ.
Вопросы о принятии решений и компромиссе между надежностью/экономией очень важны, но немного выходят за рамки статьи.
oller
Стот делать отказоустой региональной. Т.е все в одном датацентре держать глупо, когда выросли из 1й стойки
emirochnik Автор
Не так важно — одна стойка, или сто.
Региональная отказоустойчивость — это дорого: само оборудование, ДЦ, связность, более сложная архитектура для синхронизации данных между локациями. В целом ее надо делать осознанно, когда потери от отказов могут превысить расходы на обеспечение отказоустойчивости.
Тут могут сильно помочь облачные провайдеры, если уметь готовить инфрастуктуру как сервис и раскатывать ее в облаке в момент поломки основного ДЦ, не держа при этом постоянный запас.