Экономически эффективный способ построить сервер с большим количеством оперативной памяти

У меня есть Java-приложение, в котором масштабируемость в основном ограничена оперативной памятью, которую я хотел бы запустить на одном или нескольких серверах в центре обработки данных. Где мне искать серверное оборудование, которое может вместить 100 ГБ - 512 ГБ или более ОЗУ? Я не эксперт в таких вопросах, поэтому я действительно не знаю, с чего начать.

Это входит в территорию суперкомпьютера (6 цифр или более), или я мог бы получить такой сервер за 5 долларов?

Несколько заметок, основанных на некоторых вопросах ниже:

• Да, я изо всех сил пытался придумать, как убрать это требование к масштабируемости, и на самом деле это не вариант. Приложение, по сути, требует очень быстрого произвольного доступа к очень большим объемам данных, хранение которых на жестком диске (возможно, через базу данных) не приведет к его сокращению.
• Я почти уверен, что JVM может, по крайней мере, теоретически, расширяться настолько далеко. Я регулярно выполняю свой код с 10 ГБ, выделенными для Sun 1.6 JVM без заметных проблем.

Необычные требования иногда выигрывают от необычных решений. Конечно, вы можете дать 6 цифр Sun, Dell или HP и покончить с этим, но это не единственная игра в городе.

Для решений с одной коробкой получение до 128 ГБ очень дешево (32 x 4 ГБ ~ 3 000 долларов США), даже с материнскими платами домашнего изготовления, которые стоят менее 1 000 долларов США. (Не издевайтесь над создателями. Если это достаточно хорошо для Google ...)

256 ГБ серьезно дороже (32x8 ГБ ~ 18 000 долларов США), и сверх того ...

В качестве альтернативы вы рассматривали Infiniband (10 Гбит / с) подключенные дешевые коробки в качестве альтернативы?

Таким образом, вы могли бы построить 4-х узловую, 16-процессорную (64-ядерную) машину объемом 512 ГБ, и при этом все еще иметь изменение от 25 000 долларов США.

Кроме того, вы получите дополнительные преимущества постепенной деградации, если ваше приложение может работать на 3 компьютерах, если один из них выйдет из строя, и, возможно, получить линейное масштабирование до 8 узлов (просто добавьте еще 4 узла). В этот момент вы смотрите на крутое 128-ядерное устройство с объемом памяти 1 ТБ за <50 000 долларов США .

Прежде чем отклонить предложение Infiniband как экзотическое, оно не относится к типу машины, о которой вы просите. например, 141 из 500 лучших суперкомпьютеров построен таким образом, включая 4 из 10 лучших ( http://top500.org/connfam/8 )

Хорошо, смотри. Вы не найдете сервер с таким объемом ОЗУ, который вам нужен, по крайней мере, сервер, которому не нужна собственная электрическая сеть.

Почему бы не использовать масштабируемый подход и использовать memcached? Вы можете распределить память между различными машинами по сети. Данные никогда не должны касаться дисковода, и с такой сверхбыстрой сетью, которую можно купить за деньги, о которых вы говорите, задержка вряд ли будет проблемой вообще.

Вот клиент memcached для Java: http://www.whalin.com/memcached/

А вот введение в memcached на случай, если вы не знакомы: http://www.danga.com/memcached/

Посмотри на это. Это будет гораздо более экономически эффективным, чем создание одной монстровой машины с безумным объемом оперативной памяти. Кроме того, если вы делаете что-то, имеющее такого рода требования, это, вероятно, критически важно, и вам не нужна ни одна точка отказа.

Серверы Opteron с 4 или 8 разъемами, такие как HP DL585 или DL785 или Sun X4600, могут занимать большие объемы памяти в диапазоне 128-256 ГБ. Хотя они недешевы, они, конечно, не относятся к 6-значным ценникам; 8-полосная 32-ядерная Sun X4600 с 256ГБ списками оперативной памяти стоит около 35000 долларов на их веб-сайте, и это примерно столько же, сколько у этого типа систем. Вы, вероятно, обнаружите, что вы можете получить систему за несколько меньшую цену, чем указанная на веб-сайте.

Несмотря на то, что доступны 4-гигабитные модули DIMM, они, как правило, стоят с большой ценовой надбавкой, поэтому переход на максимизированную систему будет значительно дороже.

Если вы хотите использовать систему такого типа, вам потребуется 64-битная операционная система. Убедитесь, что вы также получили 64-разрядную JVM и убедитесь, что она хорошо работает с вашим приложением.

Я не буду повторять предложения по аппаратному обеспечению (которые являются правильными), но вы можете посмотреть на Terracotta, чтобы увидеть, подходит ли оно для вашего приложения.

http://www.terracotta.org/

Будьте абсолютно осторожны с такими размерами оперативной памяти. Мы увеличили размер машины HP до 64 ГБ (HP заявила, что она может занимать 128 ГБ), но только после добавления дополнительной переходной платы, охлаждающего вала и т. Д. (После большого разговора с HP).
Только потому, что машина указана для использования до n ГБ, это не значит, что она будет работать без дополнительных изменений. В нашем случае не все нормальные модули памяти работали, потому что они нагрелись, работали только очень специфические модули.

Стоимость оперативной памяти не масштабируется линейно до больших размеров. То, что я могу купить 1 ГБ DIMM за 15 долларов, не означает, что я могу получить сервер с 128 ГБ всего за 1920 долларов ... для начала вы не найдете материнскую плату со 128 слотами DIMM.

Выше определенного размера (~ 8–16 ГБ) вы начинаете видеть материнские платы, требующие полной буферизации модулей DIMM (FB-DIMM), что обойдется вам значительно дороже за ГБ, чем стандартная настольная память.

Мы регулярно используем машины с 128 ГБ памяти, и цена за последние годы значительно снизилась, но у меня нет текущих цифр ... и опыта того, насколько хорошо JVM будет масштабироваться до такого объема памяти. ,

На самом деле у вас есть много вариантов, только из списка HP у вас есть blade-сервер BL680c, который может занимать 128 ГБ, их DL580 / 585 могут занимать 256 ГБ, а их DL785 - 512 ГБ. Некоторые из IBM занимают 256 ГБ, как и один Dell.

Я думаю, вы начнете сталкиваться с проблемами в 64 ГБ на традиционном оборудовании. Если вы сможете масштабироваться оттуда, все будет в порядке, но я предполагаю, что гораздо более рентабельным решением было бы подвергнуть сомнению вашу архитектуру. Конечно, я говорю это, не зная, что вы делаете, но я просто выкидываю это туда.

Будет ли решение Amazon EC2 жизнеспособным для вас? Это, безусловно, будет наиболее экономически эффективным решением.

Допустим, вы могли бы разместить столько памяти на сервере (если я не ошибаюсь, Linux на стандартном оборудовании ограничен 64 ГБ, но я не уверен).

В большинстве операционных систем JVM ограничена пространством кучи около 1,4–1,6 ГБ, частично из-за того, что требуется непрерывная память, а частично из-за ограничений операционной системы.

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

Зачем вам столько оперативной памяти? Возможно, вам удастся найти базы данных, которые можно сохранить в памяти или использовать ОЗУ, но я не знаю о JVM, которая позволила бы вам хранить столько данных в памяти.

Типичный способ получить больше системной памяти - получить больше систем. Если память действительно является узким местом, то это не столько сколько у вас памяти, сколько то, насколько хорошо ваши данные связаны с вашими процессорами. Вам нужно будет масштабировать много вещей, чтобы это принесло вам много пользы.

Для пояснения: простое добавление пары нулей в системную память, вероятно, не приведет к тому, что вы думаете. Что вы обнаружите, так это то, что теперь, когда весь ваш набор данных помещается в память или даже чуть больший ее фрагмент, вы столкнетесь с некоторым другим узким местом, таким как аннулирование кэша.

Правильный способ масштабирования вашей системы - медленно. Если вы в данный момент работаете, скажем, на 4-х ядерной системе с 8 гигабайтами оперативной памяти, сначала чертите свое приложение, чтобы увидеть, на что он действительно тратит время, затем попробуйте увеличить до 12 или 16 гигабайт оперативной памяти и посмотреть, как результаты профилирования изменились.

На самом деле вопрос в том, зачем вам примерно в 100 раз больше системной памяти по сравнению с другими ресурсами, чем обычно доступно. Если ваша схема доступа к данным в некотором роде предсказуема, то, что вы должны сделать, это увеличить пропускную способность диска, этого добьются несколько контроллеров рейда с несколькими чередующимися дисками.

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

Вам, вероятно, нужен специализированный сервер для этого.

Попробуйте посмотреть на ES7000 от Unisys. Описание там, вероятно, немного устарело.

Он может поддерживать до 512 ГБ оперативной памяти. Он использует хорошо известные O / S, такие как Windows и Linux Enterprise.

Это будет стоить вам ~ 30 тыс. Долл. За стандартную конфигурацию, но с Itanium и всеми прибамбасами он может доходить до ~ 600 тыс. Долл.

С таким большим количеством оперативной памяти вы можете хранить много горячих данных, не затрагивая места на диске вообще.

Очевидно, вам нужны 64-битные операционные системы, но вы не находитесь на территории суперкомпьютера. В качестве примера, Dell PowerEdge R900 и R905 доступны с 256 ГБ ОЗУ и используют простые стандартные процессоры Intel Xeon / AMD Opteron и работают под управлением Linux, Solaris или Windows 2003 и 2008.

Конечно, покупка ОЗУ непосредственно в Dell не очень экономична (они хотят ~ 35 000 долларов США за 32 x 8 ГБ, а вы можете получить ее уже за 23 000 долларов США, возможно, дешевле), но с другой стороны, вы можете захотеть чтобы обеспечить надлежащую поддержку, если вы покупаете сервер за 40 000 долл. (вы не ожидали, что 256 ГБ ОЗУ будут дешевыми, не так ли? Если и 128 ГБ тоже в порядке, вы можете сэкономить ~ 12 000 долл.).

У меня нет опыта, какую операционную систему выбрать, хотя запуск 100+ ГБ Java обычно не то, чем я занимаюсь :)

Как насчет полностью готового решения: базы данных. Я знаю, что вы сказали, что это будет слишком медленно, но это зависит от того, что на нем размещено. Как насчет размещения его на массиве RAID0 достаточно этих.

В Pricewatch 400 долларов за гаджет, чипы стоят по 55 долларов (я не проверял совместимость) за 4 Гб, так что это еще 440 долларов за память. Это дает вам 32 ГБ за 840 долларов. (Теоретически устройство может принимать 8-гигабитные чипы на общую сумму 64 ГБ, но пока чипы не поддерживаются.)

RAID0 4 из них, и вы находитесь в нижней части диапазона за чуть более 3000 долларов США + обычная коробка. 16 из них получают верхний предел вашего диапазона за $ 14k.

Является ли это полезным или нет, также зависит от характера ваших данных - эти устройства нестабильны и разряжают свою резервную батарею в течение нескольких часов, хотя могут выполнять резервное копирование на CF-карту.

Я большой поклонник подхода "много дешевых серверов". Вы рассматривали, может быть, запуск такого рода процесса на платформе Eucalyptus, доступной в Ubuntu 9.04? Вполне возможно, что вы можете запускать такого рода программы на нескольких компьютерах в их собственной выделенной гигабитной сети с несколькими серверами, работающими на 8, 16 или 32 ГБ ОЗУ, и выполнять линейное масштабирование, добавляя более дешевые серверы, когда они вам нужны.

Я прочитал ваш комментарий о характере вашего приложения, но, тем не менее, вы могли бы рассмотреть альтернативные решения.

FusionIO - это одна из реальных альтернатив. Просто взгляни . На 10 000 $ это все еще намного дешевле чем сервер высокого уровня. Запись пропускной способности 1,0 ГБ / с - это звучит по-настоящему безумно.

Другой вариант - SSD, конечно. На всякий случай вы уже видели спецификации для Intel® X25-E Extreme SSD:

Read Latency 75 microseconds
I/O Per Second (IOPS) Random 4 KB reads: >35,000 IOPS
Random 4 KB writes: >3,300 IOPS
Sustained sequential read: up to 250 MB/s
Sustained sequential write: up to 170 MB/s

Помещение их в массив raid 10 может дать вам достаточно производительности. И с 400 долларов США за 32 ГБ, это намного дешевле, чем альтернативные высокопроизводительные серверы.

Аналогично предложению FusionIO, вы можете получить устройства, которые позволяют подключать динамическую оперативную память к интерфейсу SATA. Что - то вроде этого (я не имею никакого опыта продукта или компании, это только первый вариант , который вышел из «Google Shopping» поиск).

Вы можете использовать пару из них в качестве смонтированных файловых систем для кэширования данных с использованием логики вашего приложения (оно питается от батареи, поэтому должно выдержать загрузку и другие сбои), или вы можете использовать их в качестве пространства подкачки и позволить ядру решать, как их использовать ( хотя ядра ОС обычно оптимизируются, если предположить, что все области подкачки на несколько порядков медленнее и более латентны, чем реальная оперативная память, тогда это, вероятно, придется значительно изменить, чтобы наилучшим образом использовать такую ​​схему).

Опция FusionIO будет более выгодной, если вам действительно нужно что-то такое большое, такой тип ОЗУ может быть лучше в качестве компромисса. Оценивая, насколько хорошо сервер, способный иметь 128 ГБ ОЗУ на материнской плате, и пару из них с полными заполненными 64 ГБ, сравнивает по цене и производительности со специализированным сервером, поддерживающим 256 ГБ или более, я оставляю это упражнение для читателя!

Через 3 года после вопроса все намного проще.

Я искал некоторые конфиги Siliconmechanics .

Самый дешевый способ - использовать платформы AMD с 32 диммами - 512 ГБ - 11,940 $ .

Альтернативой, но гораздо более дорогой на ГБ, является платформа Intel с 64 диммерами - 1 ТБ - 48,769 $ .