Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 136
Это некая реализация блейд серверов, правильно я понял?
несказал бы
Аналог скорее :)
Нет нифига не блейды. Каждое такое лезвие несет свой блок питания. Кабинет содержит только вентиляторы и распределитель питания. Блоки питания обладают мощностью 450 ватт, системы 1+1 нет (в целом оно при подходе гугла и не надо). Ближайший родич вот это:
www.aicipc.ru/products/servernye_korpusa/rackmount_blade_server_rbs/88/
Дешево и сердито.
www.aicipc.ru/products/servernye_korpusa/rackmount_blade_server_rbs/88/
Дешево и сердито.
Не парьтесь! Все правильно написано! :)
В обычных компутерах 12 вольт подается далеко не во все места. Видимо такое решение мощнее.
Почему? Конкретней бы хотелось.
Тепла больше выделяет :))
проще -> дешевле, надёжней?
Почитайте любую приличную статью про современные блоки питания. Например вот эту. Там подробно описано почему выдача разных напряжений непосредственно блоком питания — не шибко выгодный подход если эти напряжения не напрямую «идут в ход» (как было 20 лет назад: схемы работали прямо от 5V и от 12V, никаких преобразователей не было), а поступают на вход очередного преобразователя (сейчас в компьютере схем, работающих от 5V и 3V — раз-два и обчёлся; разве что USB, которое на серверах не нужно)…
странно тогда что не 220 подали.
Через полгода откроется тайна, что на самом деле гуглосерверы работают от 13V :)
Это ключевой успех в унификации. Система питания проще чем у блейд систем. Хотя конечно идея не нова. У телефонистов стандартом такого рода являются 48 вольт.
хм. А как охлаждается эта железка интересно? Тепла должна немало выделять.
Тепла как раз мало выделяет, там двух- или четырехядерные LV Xeon'ы используются, и вся стойка продувается двумя большими вентиляторами от передней панели назад.
харды в таких количествах очень много тепла выделяют… так что охлаждение должно быть нормальное там.
На вид пространства там мало, чтобы было где продувать. Но я в этой области не ориентируюсь :)
А Вы думаете в обычном 1U сервере места больше? :)
Тянуть должно нормально, вентиляторы там стоят большие и о шуме врядли кто-то беспокоится будет.
Тянуть должно нормально, вентиляторы там стоят большие и о шуме врядли кто-то беспокоится будет.
Можно всё вместе в жидкий азот опустить ;)
Неплохо ориентируетесь судя по выводам. Показанная фотка не имеет никакого отношения к гугловым серверам. Там всё не так плотно упаковано. Ибо продувать подобную «плотную упаковку» == выдувать деньги на ветер. Имеет смысл только при аренде с платой за вершок, а не при строительстве своих датацентров…
Скажите мне что дешевле строить очередной датацентр или увеличить плотность серверов? Я вот как-то больше склоняюсь ко второму.
Если вы датацентр строите, а не арендуете, то вам, грубо говоря, пофигу — буден он как футбольное поле или как десять футбольных полей: основные затраты всё равно уйдут на оборудование, систему энергообеспечения и охлаждения, etc. Если вы увеличите после этого плотность серверов, то вы просто-напросто не сможете их все включить: мощности энергоподстанции не хватит.
Если вы арендуете место в датацентре и платите за юнит — ответ другой, потому когда Гугл только начинал и появилась эта знаменитая конструкция с двумя материнками на одном шасси в 1U. Но сейчас у Гугла деньги есть и датацентры он строит сам, потому вся эта история про две материнки в одном одном 1U отсеке наверняка осталась в прошлом.
Если вы арендуете место в датацентре и платите за юнит — ответ другой, потому когда Гугл только начинал и появилась эта знаменитая конструкция с двумя материнками на одном шасси в 1U. Но сейчас у Гугла деньги есть и датацентры он строит сам, потому вся эта история про две материнки в одном одном 1U отсеке наверняка осталась в прошлом.
Если вы датацентр строите, а не арендуете, то вам, грубо говоря, пофигу — буден он как футбольное поле или как десять футбольных полей: основные затраты всё равно уйдут на оборудование, систему энергообеспечения и охлаждения, etc.
Это деньги и существенно большие, чем собственно сами сервера.
Если вы увеличите после этого плотность серверов, то вы просто-напросто не сможете их все включить: мощности энергоподстанции не хватит.
Можно сразу расчитать датацентр на максимальную плотность и строить его отталкиваясь от этого значения (хотя обычно закладывается больше этого значения в два раза).
Но сейчас у Гугла деньги есть и датацентры он строит сам, потому вся эта история про две материнки в одном одном 1U отсеке наверняка осталась в прошлом.
Вообще нет. Потому что стоимость постройки датацентра несопоставима с стоимостью железа, чем больше плотность тем меньше требуется датацентров.
Это деньги и существенно большие, чем собственно сами сервера.С чего вдруг? У вас бетонные балки стоить как золотые стали или крышу из железа по стоимости бриллиантовой кто-то стоить собрался? Вот система энергоснабжения, кондиционирования и прочего — тут да, есть разница. При слишком большой плотности «железа» всё это становится более сложным.
Можно сразу расчитать датацентр на максимальную плотность и строить его отталкиваясь от этого значения (хотя обычно закладывается больше этого значения в два раза).А нафига? Если вы можете запитать 10'000 серверов — какой резон вам ставить 5000? А если решили запитать 10'000 серверов, то кто вам мешает построить датацентр в который они влезут «без напряга»? Или даже с запасом (вдруг следующие поколения процессоров окажутся более экономичными)… В стоимости датацентра цена стен и аренды земли — не самые важные компоненты. Гугл же не ставит их посреди Москвы...
Потому что стоимость постройки датацентра несопоставима с стоимостью железа, чем больше плотность тем меньше требуется датацентров.Это только в том случае если вы пытаетесь построить датацентр в уже существующем здании. В противном случае ограничением является не ёмкость коробки, а мощность энергоподстанции. И при увеличении плотности выше некоторого предела вы сможете запитать меньше серверов, а не больше!
С чего вдруг? У вас бетонные балки стоить как золотые стали или крышу из железа по стоимости бриллиантовой кто-то стоить собрался? Вот система энергоснабжения, кондиционирования и прочего — тут да, есть разница. При слишком большой плотности «железа» всё это становится более сложным
Датацентр это далеко не только бетонные балки.
А нафига? Если вы можете запитать 10'000 серверов — какой резон вам ставить 5000? А если решили запитать 10'000 серверов, то кто вам мешает построить датацентр в который они влезут «без напряга»? Или даже с запасом (вдруг следующие поколения процессоров окажутся более экономичными)… В стоимости датацентра цена стен и аренды земли — не самые важные компоненты. Гугл же не ставит их посреди Москвы…
В случае высокой плотности меньше необходимая площадь значит дешевле строительство. Чем больших вы размеров строите датацентр, тем больше вам прийдется прокладывать коммуникаций внутри тем более мощные системы охлаждения надо ставить. Церкуляция то должна весь датацентр охватывать.
Это только в том случае если вы пытаетесь построить датацентр в уже существующем здании. В противном случае ограничением является не ёмкость коробки, а мощность энергоподстанции. И при увеличении плотности выше некоторого предела вы сможете запитать меньше серверов, а не больше!
И в случае нового здания это так же. Вы забываете, что датацентр это не только бетонные балки это еще коммуникации, системы охлаждения и т.п. Стоимость строительства датацентра всегда выше чем стоимость установленного в нем железа.
В случае высокой плотности меньше необходимая площадь значит дешевле строительство.Да, но велика ли разница?
Чем больших вы размеров строите датацентр, тем больше вам прийдется прокладывать коммуникаций внутри тем более мощные системы охлаждения надо ставить.А вот это как раз не факт. Разница мизерна и не факт что в большем по размеру датацентре установка нужна более мощная (про разницу в длинах кабелей я и вообще молчу — они всё-таки не так дорого стоят). Всё подводимое в датацентр электричество так или иначе преобразуется в тепло и его нужно удалять — это и определяет мощность вентиляции. Есть, конечно, потери если ваш датацентр уж слишком велик, но для этого он должен быть как ангар — не на 10'000 серверов, а на 100'000. Таких мостров даже Гугл не строит.
Церкуляция то должна весь датацентр охватывать.Гораздо хуже — воздух должен проходить мимо каждого процессора и каждого винчестера. Ставить их слишком плотно — не слишком выгодно: придётся ставить специальные мощные вентиляторы, продувающие эту слишком плотную конструкцию — а это деньги и, что гораздо хуже, лишние затраты энергии.
Вы забываете, что датацентр это не только бетонные балки это еще коммуникации, системы охлаждения и т.п.Это вы забываете что датацентр — это всё-таки конструкция, призванная подвести энергию к процессорам и винчестерам и отвести от них тепло (всё остальное — вторично). Оптимальной это конструкция будет вовсе не тогда, когда вы напихаете много-много винчестеров в 1U корпус и поставите туда кучу ревущих вентиляторов. Есть разумный компромисс между плотностью «набивки» и сложностью охлаждения этой набивки. Игрушка показанная на фотке от этого компромисса так же далека как обычный MidiTower с одним винчестером и одним процессором…
Да, но велика ли разница?
Вообще велика. Если брать 44 юнита и корпуса в 4 юнита или 2 юнита, то вместо одной стойки надо будет поставить восемь стоек или четыре стойки соответственно. В масштабах 10000 серверов это уже существенно.
Для 10000 серверов в случае использования 88 мб на 44 юнита — 114 стоек, в случае 44 мб на 44 юнита — 228 стоек в случае 22 мб на 44 юнита — 455 стоек. Это из разряда почувствуйте разницу. Еще потребутется к каждой стойке подвести питание коммуникации и обеспечить охлаждение.
А вот это как раз не факт. Разница мизерна и не факт что в большем по размеру датацентре установка нужна более мощная (про разницу в длинах кабелей я и вообще молчу — они всё-таки не так дорого стоят).
Еще как факт. См выше приведенную калькуляцию.
Всё подводимое в датацентр электричество так или иначе преобразуется в тепло и его нужно удалять — это и определяет мощность вентиляции. Есть, конечно, потери если ваш датацентр уж слишком велик, но для этого он должен быть как ангар — не на 10'000 серверов, а на 100'000. Таких мостров даже Гугл не строит.
Если строить в расчете на высокую плотность, то площадь будет занимаься меньшая.
Гораздо хуже — воздух должен проходить мимо каждого процессора и каждого винчестера. Ставить их слишком плотно — не слишком выгодно: придётся ставить специальные мощные вентиляторы, продувающие эту слишком плотную конструкцию — а это деньги и, что гораздо хуже, лишние затраты энергии.
Это обеспечивается встроенной вентиляцией серверов. Далее образуются так называемые горячие и холодные коридоры. Вот их то и должна охватывать вентиляция.
Это вы забываете что датацентр — это всё-таки конструкция, призванная подвести энергию к процессорам и винчестерам и отвести от них тепло (всё остальное — вторично).
Я как раз не забываю. Я еще к примеру помню что кроме вентиляции и питания есть коммуникации. банальная витая пара и оптоволокно.
Оптимальной это конструкция будет вовсе не тогда, когда вы напихаете много-много винчестеров в 1U корпус и поставите туда кучу ревущих вентиляторов.
У приведенной конструкции ревущих вентиляторов ровно два и они обладают очень нефиговой производительностью.
Есть разумный компромисс между плотностью «набивки» и сложностью охлаждения этой набивки. Игрушка показанная на фотке от этого компромисса так же далека как обычный MidiTower с одним винчестером и одним процессором…
Вы когда в последний раз держали 1U сервер в руках? Я вот довольно недавно и потребляемая мощность его не могла быть больше 250Ватт. Реально еще меньше. Процессор там обладал TDP в 65Ватт. Его охлаждение обеспечивалось пассивными радиаторами и одной турбиной работающей на 4400 оборотов. При тестировании в полной загрузке корпус даже не нагревался.
Это обеспечивается встроенной вентиляцией серверов.А эта встроенная вентиляция — она святым духом питается? Вот тут-то собака и порылась: при более плотной конпоновке серверов вам потребуются большие затраты энергии на охлаждение каждого сервера — и не факт, что это перекроется экономией на общей системе охлаждения.
Я как раз не забываю. Я еще к примеру помню что кроме вентиляции и питания есть коммуникации. банальная витая пара и оптоволокно.Даже оптоволокно стоит не так много, а уж витая пара — стоит копейки. Конечно всё это нужно учитывать, но это — не определяющие факторы.
У приведенной конструкции ревущих вентиляторов ровно два и они обладают очень нефиговой производительностью.А энергию для этой производительности поступает прямо от господа бога?
Вы когда в последний раз держали 1U сервер в руках?Давненько, это правда. Обычно они выезжают на салазках и держать их в руках не нужно. Кстати, внешний вид корпуса на картинке тоже подозрителен: в нём нет крышки (что разумно), но вот передняя стенка в нём есть — а зачем она нужна? Какую функцию исполняет? В общем всё указывает на то, что это игрушка сделана «по мотивам» гуглового сервера, но всё-таки гугловым сервером не является: срезаны далеко не все возможные углы…
Вот тут-то собака и порылась: при более плотной конпоновке серверов вам потребуются большие затраты энергии на охлаждение каждого сервера — и не факт, что это перекроется экономией на общей системе охлаждения.
Это зависит от того сколько рассеивает один сервер. Мощная принудительная вентиляция требуется только для мощных серверов. К тому же энергопотери на ее создание внутри сервера не так уж велики как вы описываете, а общую систему охлаждения делать все равно надо.
Даже оптоволокно стоит не так много, а уж витая пара — стоит копейки. Конечно всё это нужно учитывать, но это — не определяющие факторы.
А стоимость работ в поддержании всего этого хозяйства в порядке и первоначальной прокладке где?
А энергию для этой производительности поступает прямо от господа бога?
Из электросети. И двигатели там даже до сотни ватт не дотянут.
Обычно они выезжают на салазках и держать их в руках не нужно.
Знаете на салазки их еще поставить надо, а еще иногда для обслуживания вынимиать из них.
Кстати, внешний вид корпуса на картинке тоже подозрителен: в нём нет крышки (что разумно), но вот передняя стенка в нём есть — а зачем она нужна? Какую функцию исполняет?
Ту же что и решетка радиатора на автомобиле, защищает компоненты внутри от попадания в них всяких не очень нужных внутри вещей.
В общем всё указывает на то, что это игрушка сделана «по мотивам» гуглового сервера, но всё-таки гугловым сервером не является: срезаны далеко не все возможные углы…
Ну а какие тогда с вашей точки зрения сервера использует гугл?
Мощная принудительная вентиляция требуется только для мощных серверов.Не только. Мощная вентиляция вам потребуется ещё и в другом случае: если вы сдуру расположите компоненты слишком плотно. Скажем поставите 4 винчестера в ряд, как на картинке без зазоров между ними.
А стоимость работ в поддержании всего этого хозяйства в порядке и первоначальной прокладке где?Единственная стационарно смонтированная система, которая нам требуется — это вентиляция. Провода можно просто уложить желоба из пловолоки — дёшево и сердито.
Ту же что и решетка радиатора на автомобиле, защищает компоненты внутри от попадания в них всяких не очень нужных внутри вещей.От этого защищает охрана на входе в датацентр.
Ну а какие тогда с вашей точки зрения сервера использует гугл?
А вот это интересный момент. Давайте подумаем.
Какие задачи перед нами стоят?
— Максимизировать производительность на ватт (всей системы, а не одного сервера).
— Минимизировать затраты на обслуживание.
Какие задачи перед нами не стоят?
— Увеличить надёжность одного сервера (надёжность — этого хорошо, но только если это не требует дополнительных затрат и не усложняет обслуживание).
— Обеспечить возможности постепенного расширения (каким датацетр родился — таким и умрёт, его место займёт другой).
Как выглядит идеальный сервер для такой задачи? Поддон на котором лежит материнка (возможно — две, а то и четыре — всё зависит от количества процессоров на
плату: 2 или 4, никак не 1) и винты (стопочкой, но с зазорами между ними — возможно на пластиковой подставке). Высота стопки — 2-3-4 винчестера, то есть 2U или 3U. Блок
питания — на несколько плат (определяется геометрией, но, видимо, тоже на 2-4 платы). Платы — максимально кастрированы (никаких видеокарт и USB), может быть
один диагностический разъём (надо считать что дешевле — иметь какую-никакую диагнстику и на время оно диагностики что-нибудь подключать или просто выкидывать
платы сразу… с учётом того, что PCI-E всё равно реализован в чипсете наверное один разъём оставить можно). Что ещё? Корпус, салазки для винтов, всевозможные
вентиляторы… Ну вентиляторы, конечно, нужны, но, опять-таки, нужны подешевше и послабее. Так как у нас поддоны идут через два-три вершка, то могут подойти
обычные корпусные на 8см или 12см. Может быть стоит поставить пару платиковых кожухов чтобы направлять воздух на винчестеры и процессоры.
Вот как-то примерно так. Заметим что в результате мы получаем плотность как у 1U серверов или где-то так, но такого ужаса как на картинке (где зазоры между винчестерами не дают организовать нормальное охлаждение) нету. И мы пытаемся рационально использовать объём стойки (а она довольно-таки глубока), но не в ущерб охлаждению, но запихивать что-либо в 1U нам не нужно.
Не только. Мощная вентиляция вам потребуется ещё и в другом случае: если вы сдуру расположите компоненты слишком плотно. Скажем поставите 4 винчестера в ряд, как на картинке без зазоров между ними.
Не поверите, но так винчестеры ставят довольно часто. И тут главное чтобы был поток воздуха сверху и снизу.
Единственная стационарно смонтированная система, которая нам требуется — это вентиляция. Провода можно просто уложить желоба из пловолоки — дёшево и сердито.
В датацентрах обычно используют фальшьполы. Это удобнее. И они как раз являются стационарно смонитроваными. Как собственно и место расположение стоек.
От этого защищает охрана на входе в датацентр.
При проведении работ в ДЦ она лишней не будет.
Как выглядит идеальный сервер для такой задачи? Поддон на котором лежит материнка (возможно — две, а то и четыре — всё зависит от количества процессоров на
плату: 2 или 4, никак не 1) и винты (стопочкой, но с зазорами между ними — возможно на пластиковой подставке). Высота стопки — 2-3-4 винчестера, то есть 2U или 3U. Блок
питания — на несколько плат (определяется геометрией, но, видимо, тоже на 2-4 платы). Платы — максимально кастрированы (никаких видеокарт и USB), может быть
один диагностический разъём (надо считать что дешевле — иметь какую-никакую диагнстику и на время оно диагностики что-нибудь подключать или просто выкидывать
платы сразу… с учётом того, что PCI-E всё равно реализован в чипсете наверное один разъём оставить можно).
Во первых никакой высоты в 2-3 юнита. Это очень неэкономно. В случае если у нас выбираются процессоры с высокой эффективностью ватт на произоводительность, то это процессоры с низким TDP в пределах 70 ватт, такие процессоры велколепно себя чувствуют в 1U корпусах или блейдсистемах типа той что я приводил. Винчестеры располагаются друг за другом в coldrack или крепятся на корпус. никаких пластиковых подставок, только сталь. это позволит отвести тепло от дисков.
вентиляторы… Ну вентиляторы, конечно, нужны, но, опять-таки, нужны подешевше и послабее. Так как у нас поддоны идут через два-три вершка, то могут подойти
обычные корпусные на 8см или 12см. Может быть стоит поставить пару платиковых кожухов чтобы направлять воздух на винчестеры и процессоры.
В 1U часто ставят вентиляторы той же призводительности.
А вообще рекомнедую посмотреть вот это:
www.aicipc.ru/products/servernye_korpusa/rackmount_appliance_chassis_rac/26/
Это типичный корпус для сервера с подходом максимизация производительнсти на ватт.
Не поверите, но так винчестеры ставят довольно часто.Почему не поверю? Поверю. И у меня ровно так винчестеры в серере расположены. Если мне главное — уменьшить количество денег, уходящих на оплату, а оплата идёт «за юнит» — это хорошее решение.
В датацентрах обычно используют фальшьполы. Это удобнее. Удобнее — кому и чем? И они как раз являются стационарно смонитроваными. Как собственно и место расположение стоек.Если вы хотите сделать солидный, правильный датацентр — то да, вы вбухаете кучу денег в это дело. А если ваша цель — экономия средств, то вы сделаете несколько по другому.
А вообще рекомнедую посмотреть вот это:Прикольно, да. Только вот беда: тут всё ещё рассчёт на аренду с оплатой за вершок. А вам я советую посмотреть на одну-единственную фотку гуглового датацентра:
www.aicipc.ru/products/servernye_korpusa/rackmount_appliance_chassis_rac/26/
Собственно статью можно уже и не читать — это как раз тут случай когда картинка стоит тысячи слов :-)
Ну и где тут 2U? Я вот вижу как раз таки 1U. А вот по тому что идет чувак это фальшпол.
Ну и где тут 2U? Я вот вижу как раз таки 1U.Всё. Посыпаю голову пеплом. Это таки 1U. В стойках высотой 20U, а рядом с ними идёт гном, рост которого меньше метра. Как же я на такую простую фальсификацию-то попался?
А вот по тому что идет чувак это фальшпол.Ну разумеется! Охлаждать-то всё это хозяйство как-то нужно. Но хорошо видно что стойки на колёсиках и от каждой стойки идёт ровно один провод в корзину, а вовсе на под фальш-пол (надо полагать там switch стоит, а может и роутер). Ну посмотрите на картику внимательнее, чёрт побери.
P.S. Это, кстати, довольно старая фотка — по слухам сейчас там всё немного по-другому. Но принципы — те же.
По этой фотографии нельзя точно сказать какого размера корпуса. Попробуйте увеличить и увидеть там что-то. Я вижу только рельсы и то что они висят через с промежутком в 2U и что там торчат провода. Провода распределены как при выткании в 1U.
По этой фотографии нельзя точно сказать какого размера корпуса.Наоборот! Там отлично видно всё! Нет там корпусов! Просто нет! Материнки просто лежат на лотках через 2U. Я бы скорее назвал эту конструкцию двуюнитовым сервером, чем одноюнитовым.
Провода распределены как при выткании в 1U.Ась? Что значитпровода распределены как при выткании в 1U? Провода воткнуты в материнки и всё… Какая принципиальная разница между распределением проводов при втыкании в 1U и в 2U???
Я этого как раз не вижу.
Ась? Что значитпровода распределены как при выткании в 1U?
Случае 2U питание втыкается выше.
Ась? Что значитпровода распределены как при выткании в 1U?
Случае 2U питание втыкается выше.
Случае 2U питание втыкается выше.Питание там вообще с другой стороны — на этой фотке его не видно и не может быть видно. Найти фотку со стороны питания мне сходу не удалось, но вряд ли у них там низкоформатные блоки питания, рассчитанные на 1U: смысл какой — использовать более дорогие и менее мощные блоки питания если вся конструкция располагается через 2U?
В случае если не покупать китай то собственно однофигственно. 2U хорошо в том случае если комплектуха берется рассыпухой. В него встают все штатные компоненты.
Там как раз таки низкоформатные блоки питания на 1U, посмотреть можно тут www.rackable.com/products/cr1000tray.aspx?nid=servers_60
И конструкция располагается не через 2U а через 1U, таким образом в 22U стойку влезает 20 шасси(http://www.rackable.com/products/cr1000cab.aspx?nid=servers_61)
И конструкция располагается не через 2U а через 1U, таким образом в 22U стойку влезает 20 шасси(http://www.rackable.com/products/cr1000cab.aspx?nid=servers_61)
С чего вы решили что эти фотки имеют какое-то отношение к серверам, стоящим в гугловых датацентрах? Да, какие-то идеи общие, может быть, там и есть, но рассмыстривать эти фотки как доказательство того, что Гугл использует низкоформатные блоки питания…
А я и не решал, просто в посте речь идет именно об этих стойках производства Rackable. А в них как сами видите стоят низкоформатные БП.
Вы оправдываете свой ник на 200%. Мы тут с norguhtar обсуждаем: является ли творение Rackable копией гугловых серверов или нет (один из доводов: как раз компоновка в 1U, которую, как мне кажется, Гугл использовать не должен) и тут появляетесь вы и говорите: «там как раз таки низкоформатные блоки питания на 1U». И чо? С этим никто и не спорил никогда. Вопрос шёл у гугловых серверах: если у них не 1U блоки питания, то то, что описано в статье прямого отношения к ним не имеет, если 1U — тогда ещё может быть.
Не надо встревать в дискуссию не прочитав самой дискуссии. Или вы считаете что с вашим ником — можно?
Не надо встревать в дискуссию не прочитав самой дискуссии. Или вы считаете что с вашим ником — можно?
Я боюсь что если вы имели опыт строительства, то только строительства в России. Я только когда увидел своими глазами осознал что на самом деле значит вот эта цитата:
В России, может быть, плотно набитые 1U сервера и будут кому-то выгодны, но Гугл-то строит датацентры не в России!
Согласно СНиП у нас необходим фундамент, подошва которого расположена глубже границы промерзания, а ведь чем глубже он залегает, тем такой фундамент дороже, и цена его растет более чем пропорционально глубине. Вдвое более глубокий фундамент стоит дороже минимум втрое-вчетверо. У нас на юго-западной границе России глубина промерзания 110 см, а ближе к Поволжью — уже 170. Стоимость даже простого фундамента под легкий садовый домик составляет у нас 30 % от общей стоимости строительства.Вот так и выглядит стоительство всех этих бесконечных гугловых датацентров: лёгкая карскасная конструкция без фундамента. Зато с дорогим электичеством (оно и сейчас в России безумно дёшево). Разумеется это сильно меняет соотношение сил.
Думаете, заводские корпуса всегда строятся массивными, и фундамент везде делается глубоким? Не скажите. Чтобы построить завод, например, в Ирландии или Малайзии, достаточно заасфальтировать площадку и поставить каркасную конструкцию типа выставочного павильона. Фундамента на непромерзающем грунте практически не нужно, достаточно срезать дерн.
Именно такими современные заводы и строятся, одноэтажными. Ведь если земля не дорога, то при одинаковой полезной площади многоэтажные здания дороже одноэтажных и существенно сложнее, одни перекрытия сколько стоят. По моей просьбе мои знакомые поинтересовались, как строятся двухэтажные здания в Баварии — оказалось, что на твердом грунте — вообще без фундамента. В английском руководстве по индивидуальному строительству приведены разрезы
типичных особняков — там без фундамента строятся и трехэтажные здания.
В России, может быть, плотно набитые 1U сервера и будут кому-то выгодны, но Гугл-то строит датацентры не в России!
Вы просто забываете одно замечательное правило СКС. Если вам сейчас требуется 50 портов, стройте как минимум 75, а лучше 100. В случае датацентров работает та же система. К тому же не забывайте, что датацентр должен обеспечивать температуру на одном уровне круглогодично.
А вы не забывайте причину, из которой это правило родилось. А родилось оно из потребности поддерживать работоспособность системы во время её роста. А вот как раз этого Гуглу и не нужно. Если у вас есть несколько десятков датацентров, то гораздо проще производить расширение путём полного выключения датацентра, вывоза оттуда оборудования и запуска в той же коробке нового оборудования — снова без запаса «на вырост». Гораздо более эффективное использование средств получается. Как мне расказывали знакомые гуглеры — ровно так Гугл и делает. При таком подходе вам нужен запас в несколько процентов (вдруг чего сгорит?), а не на 50% и уж тем более не в два раза.
А вот как раз этого Гуглу и не нужно. Если у вас есть несколько десятков датацентров, то гораздо проще производить расширение путём полного выключения датацентра, вывоза оттуда оборудования и запуска в той же коробке нового оборудования — снова без запаса «на вырост».
Для этого необходимо, чтобы у коробки были системы охлаждения и питания построены «на вырост». И опять же это указывает, на максимальную высокую плотность установки оборудования.
Для этого необходимо, чтобы у коробки были системы охлаждения и питания построены «на вырост».Вы опять не с той стороны смотрите. Система питания строится под мощности, которые удаётся купить, мощность системы охлаждения определяется мощностью системы питания, «на вырост» можно стоить разве что здание датацентра — что и делается.И опять же это указывает, на максимальную высокую плотность установки оборудования.Ну если мы ищем приключений на свою задницу — тогда да. А если мы разумные строители, то мы построим датацентр намного большей прощади чем нам нужно и если удастся получить ещё мощностей — поставим ещё компьютеров…
Если так смотреть то плотность будет выбираться в зависимости от мощности питания и того сколько при этом сожрет система охлаждения. В этом я согласен, но по расчетам как раз и выйдет 1U. Из моей практики, если требуется система средней мощности с небольшим количеством винчестеров 1U лучший выбор чем 2U. В случае если надо разместить большую мощь и больше винчестеров 2U более оптимален. В случае гугла я бы предпочел первый вариант. Он удобен, прост в монтаже.
В случае гугла я бы предпочел первый вариант.Почему вдруг? Нам нужно максимальное количество памяти, процессоров (чем больше процессоров и чем у них ниже частота там лучше — при той же архитектуре, конечно) и винчестеров (места много не бывает) — вы сами говорите что в этом случае 2U оптимальный размер! Мне почему-то казалось что и 3U может подойти, но, похоже, Гугл выбрал 2U… 1U однозначно плох из-за проблем с вентиляцией…
А кто вам сказал что у гугла топовое железо с большим количеством памяти и процессоров? :))) В свое время писали что у них типичное далеко не топовое железо. И у 2U с вентиляцией ничем не лучше чем у 1U. В случае смерти встроенных вениляторов и то и то печка.
У Гугла не топовое железо, как я уже заметил — наоборот, там много относительно маломощных процессоров и стандартных винчестеров (7200 RPM). А вот что их нужно напихать побольше это очевидно: задержки от общения процессов внутри одной машины на порядки меньше чем задержки от общения процессов между разными машинами (даже если использовать 10Gbit сеть). То же — с винчестерами (хотя можно часть машин останастить большой памятью и кучей процессоров, а часть — кучей винчестеров, а можно на одну повесить «всего побольше» — вот для последнего случая мне и казался подходящим 3U корпус).
В этом случае 2U не оправдано. Если два винчестера на машину, то оно не нужно. Если больше и нужен hotswap то 2U вполне подходит. 3U уже многовато хотя и может тащить 16 винтов.
Hotswap никому и даром не сдался (хотя, кстати, 4 винта в 1U корпусе вполне могут быть HotSwap — но это не случай Гугла), а вот сколько там винтов — интересный вопрос. Думаю что больше, чем два. По фотке это понять сложно… 3U может потребоваться если мы хотим на одну машину 4 процессора и кучу винтов навесить одновременно — но не 16, конечно, тут уже с охлаждением проблемы.
Ну вот я не думаю что у гугла есть 4 процессорные материнки. Я бы на их месте ставил обычные однопроцессорные материнские платы с максимальным количеством памяти и одним винтом. Это наиболее удобная и дешевая конфигурация. У 3U и 16 винтов проблем с охлаждением кстати нет :)
У Гугла точно есть 4 процессорные матери — правда не знаю наколько большой процент парка серверов они составляют. А «проблемы с охлаждением» != «всё сгорит нафиг». «Проблемы с озлаждением» == «вместо одного низкооборотистого вентилятора нужно 3-4 высокооборотистых». В этом смысле проблемы у 3U с 16 винтами есть :-)
Они и выделяют, судя по слухам.
Типа «1 датацентр гугла может отапливать средний российский городок» :)
Типа «1 датацентр гугла может отапливать средний российский городок» :)
Обычная протяжная вентиляция.
У SuperMicro, у тех серверов в которых по два блока питания (Redudant), как раз по вольт 12 и выходит с блока питания. По идее там должно быть не 12, а чуть больше. Очень эффективно UPS внутри такой стойки делать сразу.
12V в датацентрах и V8 в Хроме :) Ещё какие V (aka Victory) есть у Гуглы?
а в чем преимущество питания только +12В?
Есть подозрение, что КПД блока питания выше, т. к. не нужно разделять по напряжениям.
в любом случае на платах не используется логика только на 12 вольт. Значит, разделение происходит на самой плате. Получается, что часть логики БП перенесена на материнскую плату.
Преимущество в более простых блоках питания, UPS без двойного преобазования (220-12-220) сразу выдающих 12 вольт и, очевидно, отсутствии преобразования в другие напряжения (5, 3.3 и тд). Если им удалось сделать плату, которой нужно только 12 вольт и которых две штуки влезает в 1U вместе с винчестерами — то очевидно, что они экономят и энергию и место, которое в датацентрах очень дорого.
напряжение для чипов очень разнообразно, и всё равно везде стоит куча преобразователей.
унификация напряжений банально уменьшает число проводников и упрощает преобразователи.
унификация напряжений банально уменьшает число проводников и упрощает преобразователи.
А 12 вольт они наверное получают за счет преобразования на трансформаторном блоке питания. Ну чтобы КПД повысить.
Только на картинке видны харды, к которым тянутся провода питания +12 и +5. Значит, еще на материнке стоит понижающий ШИМ-контроллер. Да и напряжение на память и процессор нужно понижать все-таки.
Только на картинке видны харды, к которым тянутся провода питания +12 и +5. Значит, еще на материнке стоит понижающий ШИМ-контроллер. Да и напряжение на память и процессор нужно понижать все-таки.
Афтар, объяснитесь. Общественность хочет знать преимущеста такого подхода.
Я не очень понимаю в чём тут фишка. 12-вольтовые платы есть давно, например VIA их выпускает лет пять уже. Вопрос только в производительности процессора и всего остального — VIA делает маломощные платы (63 вата)).
Если перейти по ссылкам то можно прочитать что основное преимущество данной технологии заключается как раз в том что было сказано выше, а именно:
1) уменьшить размеры серверов (занимаемое пространство)
2) уменьшить кол-во потребляемого электричества
3) упрощение подключение материнских плат (видимо имеется ввиду упрощенные блоки питания)
так же сказано в статье, что за счет такого изменения БП можно увеличить их КПД до 93%
1) уменьшить размеры серверов (занимаемое пространство)
2) уменьшить кол-во потребляемого электричества
3) упрощение подключение материнских плат (видимо имеется ввиду упрощенные блоки питания)
так же сказано в статье, что за счет такого изменения БП можно увеличить их КПД до 93%
Интересно узнать силы тока в проводниках и потребляемую мощность. Даже при 120 ваттах по проводу потечет 10 ампер, а это потребует много меди :)
К стойке, соответственно, придется тянуть медный канат.
Хотя, может я и ошибаюсь…
К стойке, соответственно, придется тянуть медный канат.
Хотя, может я и ошибаюсь…
так лучше видно, что там внутри
Вообще несколько странно.
1) порты развернуты внутрь
2) плата ATX, 2 такие платы в один юнит невлезут.
3) решения у той же супермикро (twin), думаю, плотнее в размещении.
4) кроме питания от 12V тут нет ничего особенного.
5) основная оптимизация — это стоимость одного такого сервера.
1) порты развернуты внутрь
2) плата ATX, 2 такие платы в один юнит невлезут.
3) решения у той же супермикро (twin), думаю, плотнее в размещении.
4) кроме питания от 12V тут нет ничего особенного.
5) основная оптимизация — это стоимость одного такого сервера.
плата ATX, 2 такие платы в один юнит невлезут.
Влезут. Просто глубина будет большая и надо будет что-то решать с тем как вывести разъемы. У меня в хозяйстве есть сервера с ATX платами и их длина позволяет ставить их под две штуки в стойку.
решения у той же супермикро (twin), думаю, плотнее в размещении.
88 MB на 44 юнита. Если брать вышеприведенное мной решение то у него плотность на 42 юнита равно 50.
Да, странновато. Блок питания один и диски вроде как не hotswap (я правильно понимаю, что backplane нет и они подключены проводами)? Для замены диска сервер выключать что ли?
Где вентиляторы и почему спереди вход питания (если это перед)?
Обычные PCI-E разъемы в глубине справа. Что они туда собираются при 1U вставлять?
На первый взгляд дешевый 1U сервер только с большим для 1U количеством дисков, что тоже для Гугла странно. А как же SAN / NAS?
Где вентиляторы и почему спереди вход питания (если это перед)?
Обычные PCI-E разъемы в глубине справа. Что они туда собираются при 1U вставлять?
На первый взгляд дешевый 1U сервер только с большим для 1U количеством дисков, что тоже для Гугла странно. А как же SAN / NAS?
Во-первых это явно не гугловый сервер (PCI-E разъёмы ясно дают это понять, а уж PCI-X окончательно добивают), но во-вторых принципы показаны правильно. Блок питания один? А зачем их два? Это бессмысленное удорожание конструкции. Backplane нет? А что она даст? Нафига нужно выкидывать деньги на SAN/NAS если у вас есть GFS? Которая рассчитана на выключение/включение компьютеров в любой момент (копии данных автоматически восстанавливаются на живых серверах)?
khim & norguhtar
Судя по вашим мыслям enterprise решения должны быть именно на дешевых серверах без hotswap дисков и без redundancy (второй блок питания) вообще.
Пошел выключил поменял.
Судя по вашим мыслям enterprise решения должны быть именно на дешевых серверах без hotswap дисков и без redundancy (второй блок питания) вообще.
Пошел выключил поменял.
Давайте не путать «настоящие» enterprise решения с гугловым «облаком». Enterprise решения — это суровые машины стоимостью за много щтук баксов, которые должны работать, работать и работать. Гугл же понимает что когда у тебя сотни тысяч компьютеров, то независимо ни от чего какая-то часть из них будет выходить из строя — а значит система должна быть готова к тому, что не только один компьютер, но и целый датацентр может неожиданно выйти из строя (кажется этого идеала они не достигли, но стремятся к нему). А если вы можете что угодно отключить когда угодно, то зачем нам иметь redundancy на уровне одного компьютера? Чтобы лишние деньги потратить?
Приницип тот же, что и с простым RAID'ом: вспомните как эта технология расшифровывается и для чего придумана! Первоначальная статья называлась A Case for Redundant Arrays of Inexpensive Disks (RAID). Это потом «неблагородное» слово inexpensive из названия убрали — несолидно, типа. Гугл делает то же самое, но уже на уровне датацентра: максимально снизить затраты на каждый сервер, а резервирование перенести на уровень всего датацентра…
Приницип тот же, что и с простым RAID'ом: вспомните как эта технология расшифровывается и для чего придумана! Первоначальная статья называлась A Case for Redundant Arrays of Inexpensive Disks (RAID). Это потом «неблагородное» слово inexpensive из названия убрали — несолидно, типа. Гугл делает то же самое, но уже на уровне датацентра: максимально снизить затраты на каждый сервер, а резервирование перенести на уровень всего датацентра…
При архитектуре как у гугла как раз рулят унифицированные и простые решения. Нет смысла брать туда hotswap диски и hotswap блоки питания. Сдохло? Отключается, посылается уведомление. Приходят техники меняют.
а процессоры они тоже от 12 В питают? :)
на всех серийных материнских платах реализованы преобразователи для питания CPU и RAM именно с 12В.
не знал
en.wikipedia.org/wiki/ATX12V#ATX12V_1.x
The main changes and additions in ATX12V 1.0 (released in February 2000) were:
…
An extra 4-pin mini fit JR (Molex 39-01-2040), 12-volt connector to power the CPU.[13] Formally called the +12 V Power Connector, this is commonly referred to as the P4 connector because this was first needed to support the Pentium 4 processor.
Для расширения кругозора
The main changes and additions in ATX12V 1.0 (released in February 2000) were:
…
An extra 4-pin mini fit JR (Molex 39-01-2040), 12-volt connector to power the CPU.[13] Formally called the +12 V Power Connector, this is commonly referred to as the P4 connector because this was first needed to support the Pentium 4 processor.
Для расширения кругозора
Правильное электропитание это 220 В @ 400 Гц, ну или на худой конец 100 В постоянного. Всё остальное баловство.
Просьба поделиться ссылками на популярное описание технологии построения кластеров, подобных Google, но менее масштабных. Т.е. с чего они начинали? Как строили инфраструктуру?
Спасибо.
Спасибо.
Это в разных популярных книжках написано. Изначально они брали какой-то RedHat и навешивали систему, которая бы автоматом перекидывала задачи с машины на машину при крахе. Потом постепенно добавляли разных фишек. На сайте самого Google есть некоторое количество статей, у Apache Foundation есть аналог — правда он более ограничен, чем у Гугла (я не уверен что на основе Hadoop можно сделать что-либо подобное Google Apps Engine). Что конкретно вас интересует?
Меня интересует планирование развития веб-ресурса, подобного Одноклассникам. Т.е. сначала движок и БД, затем идея становиться востребованной и посещаемость начинает зашкаливать, объем информации растет геометрическими темпами… Как заранее спланировать вопросы развития и увеличения количества серверов (без верхней границы)? На железном и программном уровнях.
Спасибо.
Спасибо.
Заранее никак не спланировать — и не нужно. Эмпирически нужно планировать «от достигнутого»: система должна масштабироваться до 10-кратной нагрузки путём тупого добавления «железа». Дальше — вся система или её части (обычно конечно части системы, а не всё целиком) переписываются. Всё просто: без натурных испытаний зачастую сложно выяснить даже где у тебя проблемы и системы, которые масштабируются «до бесконечнести» сильно транжирят ресурсы если на них пускать одиночные простые задачи. Всё равно что перевозить мешок картошки на карьерном самосвале :-) Собственно Google так и строился… Если бы они сразу начали создавать то, что у них работает сейчас — то быстро бы обанкротились и никакого «феномена Гугла» и не было бы…
Уточняю свой вопрос — как планировать распределение нагрузки между несколькими серверами? Т.е. например сейчас бета-версия сервиса работает на одном сервере. Каким образом можно подключить дополнительный сервер?
Спасибо.
Спасибо.
Переход с одного сервера на несколько — это всегда не большое дело, а очень большое дело. Сложнее только переход от пары десятков к сотне. Нужно смотреть на архитектуру системы. Где-то до десятка-другого серверов можно дойти просто распределив между ними разные задачи: один — раздаёт статику, другой — обслуживает изменения, ещё парочка — раздают данные (но модификация идёт не через них). Где-то на уровне 10-20 серверов идёт полный отказ от реляционной модели (не от реляционных баз данных, а именно от реляционной модели: можно продолжать использовать и MySQL/PostgreSQL, но если они используются просто как B-tree и слиянием таблиц вы не пользуетесь, то можно ли сказать что вы используете реляционную модель?), что открывает путь к практически неограниченному масштабированию…
А как быть с случаями когда для модернизации (обновления) данных не хватает ресурсов одного сервера? Технология кластеров?
Спасибо.
Спасибо.
Некоторое время можно продержаться раскидав обновление разных видов данных по разным серверам, потом можно поставить железо помощнее, ну а в конце — да, BigTable или что-нибудь подобное. Но обычно если вы дошли до таких масштабов, то деньги на разработку у вас есть…
Меня волнует вопрос переноса работающей системы на одном сервере на систему, состоящую из множества серверов (хотя бы 2). Вопроса инвестиций не встает. Только вопрос эффективности.
Спасибо.
Спасибо.
Т.е. с чего можно начать? Требует ли это переработки системы (PHP) или необходимо лишь работа системных администраторов?
Есть такое понятия как масштабирование системы и клиент-серверная база данных. При умеренно больших проектах службы этих баз рекомендуют ставить отдельно от серверов приложений, навроде Apache, IIS и многих других.
Вот, к примеру, от клиента приходит запрос на некие данные, а у нас десятки или сотни миллиардов записей по которым надо провести поиск, т.е. таблица логически больше не делится, а искать надо. Плюс (или) количество запросов растёт день ото дня. Нужно срочно увеличивать доступность.
Исходя из этого чтобы потом не переделывать рекомендуют сразу строить кластерную базу данных. Вот сколько искал, приемлемыми оказались лишь MSSQL и PostgreSQL, но если использовать PHP, да ещё чтобы не платить при расширении, то выбор естественно за PostgreSQL, всё остальное будет гораздо хуже.
Таким образом для начала надо почитать книжки по этой базе. В них описано как создавать кластерные индексы, как распределять нагрузку, оптимизировать и кешировать запросы, делать запасные зеркала данных и так далее.
После создания кластерной базы данных в процессе развития сервиса понадобится её администрировать, подключать к ней новые компьютеры и т.п., при этом код веб-приложения по этой причине менять не нужно, разве что в голову придёт мысль по оптимизации запросов и прочем.
>Требует ли это переработки системы (PHP)
А он тут как бы ни причём так как висит не сервере-приложений, ему надо всего лишь дать запрос базе и все остальные операции с данными по идее должны выполнятся на её стороне, то есть на связанных вместе компьютерах, на каждом из которых стоит сервер базы данных. Далее придёт запрос, причём не нужно брать больше, чем хочешь отдать пользователю.
И в завершении, если это веб-приложение, данные преобразуются XSLT или ещё чем-нибудь в HTML (XHTML) или если это веб-служба, то уходят в формате XML пользователю-клиенту.
Вот, к примеру, от клиента приходит запрос на некие данные, а у нас десятки или сотни миллиардов записей по которым надо провести поиск, т.е. таблица логически больше не делится, а искать надо. Плюс (или) количество запросов растёт день ото дня. Нужно срочно увеличивать доступность.
Исходя из этого чтобы потом не переделывать рекомендуют сразу строить кластерную базу данных. Вот сколько искал, приемлемыми оказались лишь MSSQL и PostgreSQL, но если использовать PHP, да ещё чтобы не платить при расширении, то выбор естественно за PostgreSQL, всё остальное будет гораздо хуже.
Таким образом для начала надо почитать книжки по этой базе. В них описано как создавать кластерные индексы, как распределять нагрузку, оптимизировать и кешировать запросы, делать запасные зеркала данных и так далее.
После создания кластерной базы данных в процессе развития сервиса понадобится её администрировать, подключать к ней новые компьютеры и т.п., при этом код веб-приложения по этой причине менять не нужно, разве что в голову придёт мысль по оптимизации запросов и прочем.
>Требует ли это переработки системы (PHP)
А он тут как бы ни причём так как висит не сервере-приложений, ему надо всего лишь дать запрос базе и все остальные операции с данными по идее должны выполнятся на её стороне, то есть на связанных вместе компьютерах, на каждом из которых стоит сервер базы данных. Далее придёт запрос, причём не нужно брать больше, чем хочешь отдать пользователю.
И в завершении, если это веб-приложение, данные преобразуются XSLT или ещё чем-нибудь в HTML (XHTML) или если это веб-служба, то уходят в формате XML пользователю-клиенту.
Только переписывать ресурс для совместимости с масштабированием.
Т.е. распределяем базы, ресурсы и т.д.
У однокласников как-то было что пару серверов не работало и у некоторых пользователей не работали фотоальбомы (даже картинки в этих алюбомах)
Т.е. базы разнесены, контент тоже, масштабируемость после программной поддержки решается очень просто. Нагрузка повышается +1 сервер, уменьшилась -1 сервер. Но все равно есть узкое месо когда при отпаде главного сервера который ринимает запросы все остальное не работает (разве что NS менять на лету, но тут проблема в обновлении на стороне провайдеров)
Т.е. распределяем базы, ресурсы и т.д.
У однокласников как-то было что пару серверов не работало и у некоторых пользователей не работали фотоальбомы (даже картинки в этих алюбомах)
Т.е. базы разнесены, контент тоже, масштабируемость после программной поддержки решается очень просто. Нагрузка повышается +1 сервер, уменьшилась -1 сервер. Но все равно есть узкое месо когда при отпаде главного сервера который ринимает запросы все остальное не работает (разве что NS менять на лету, но тут проблема в обновлении на стороне провайдеров)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Серверы Google: по две штуки на 12V-плате