RAM 1TB DDR3 ECC

Ну как же, у них всему есть решение ;) Люди левитируют между стойками, силой мысли заменяют винты, которые перед этим месяц жестко тестировали, в конфигах не ошибаются за счет ECC в мозгу, роутеры сами перепрошиваются и у всех работников всех вендоров тоже ECC в мозгу ;)

zzzit, вы допустили ошибочку. "месяц жестко тестировали", но ведь может через месяц и час отказать. В "администрировании" как раз тема на этот счет.

Завелись как )))

Железо думаю найдет своего хозяина.

Например под кеширующий(мемкеш) сервер , поисковой сервер, отдача миллионов мелких картинок.

Распределить все эти примеры по разным дешевым серверам конечно можно, но время отклика даже на локальные соединения иногда нужно минимальное.

Напомнило: 300 миллионов долларов США, чтобы сэкономить 6 миллисекунд

Прогресс налицо.

Попробуем перенестись в прошлое, допустим в 1992 год.

Как бы Вы отреагировали бы если на рынке предложений появилась вот такая конфигурация:

CPU 33 MHz, а размер RAM можно увеличить до невероятных 128 Мегабайт!

Цена вот тоже правда заоблачная, почти 8к зелени за базовую комплектацию. Да дороговато...

Эти клиенты врядли будут брать сервер в online.net :)

Знай своих потребителей, как говорится.

Данный сервер отлично подходит для крупных баз данных.

Если у Вас около 1.4-1.5 ТБ БД то для обработки эта система как раз.

Для остального непригодна.

если не ошибаюсь, то яндекс(скорее всего и другие) подобное использует давно и много.

один из вариантов использования:

1, делается много одинаковых виртуалок (я бы сделал их бездисковыми)

2. виртуалки поднимаются по принципу bootp (или похожему, по максимуму - можно извратиться до клонирования hibernate... т.к. "железки" все одинаковые )

3. поднялись - получили нужные конфиги из "центра", смонтировали, что нужно. получили нужный прикладной софт, запустили - работаем.

4. "центр" сказал "даун" - закрываем текучку и идем на ребут. после ребута просыпаемся уже с другими конфигами и другим софтом на борту.

когда-то делал бездисковые рабочие места - красиво поднимаются. щелчок рубильника и через минуту 20 машинок в строю. выклють - рубильник вниз и все.

при таком подходе не нужно ни "восстановление" ни "бекап" - виртуалок. ребут - и снова в строю.

бекап и восстановление ноды? ну можно забекапить(клонировать) базовую файловую систему с установленной виртуализацией(по размеру этот бекап будет 2-5-10гиг, восстановить/клонировать - несколько минут).

конфиги виртуалок лучше не бекапить, а генерить их скриптом.

данные, прикладной софт - внешние NASы со своими бекапами.

как по мне, то эти "монстры" - это процессор+память под вычисление/обработку данных, диск на них ну разве что под локальный кеш/своп.

IMHO, 1-2-3 таких "монстров" ставить не имеет смысла, т.к получаем возможную потерю производительности кластера 100% - 50% - 33%. хотя 33% уже терпимо... думаю их ставят десятками.

---------- Добавлено 31.12.2013 в 10:36 ----------

странно, что они не уменьшили время для ботов до 30мс. подводный ДЦ в цетре океана, делов-то.. 😂

Под виртуалки это трата впустую.

Прощу Microcloud на 24 сервера в 3 юнита впихнуть и отдельный SAN.

И ядер больше и места и памяти и все децентрализовано, не говоря уже о цене.

30 мс до лондона + 30 мс до ньюйорка итого те же самые 60мс

только зачем тогда этот геморой с дц в атлантиде? вечно бояться за сервера, которые в любой момент уйдут под воду? :)

---------- Добавлено 01.01.2014 в 01:13 ----------

Лет через десять над нами потомки будут смеяться, как мы сейчас про 640КБ

"1Тб памяти? Да сейчас даже notepad, не говоря о Paint или сапёре на таком размере не запустишь..."

Как бы а что тут такого? Ну да, 1 ТБ памяти, 4 сокета, и что?

У меня все ноды 2 сокета и 384 оперативки. Можно и более толстые сервера юзать, но лично мне они менее экономически выгодны.

А так, такие ацие машинки имеют очень узкую специализацию применения.

Ну вот нарастите до гигабайта, то может быть сайт в вашей подписи сможет даже картинку отобразить. А то пока тяжко ему, html отработать :D