У меня есть приложение Java, масштабируемость которого в первую очередь ограничивается оперативной памятью, и я хотел бы запустить его на одном или нескольких серверах в центре обработки данных. Где мне искать серверное оборудование, вмещающее от 100 до 512 ГБ ОЗУ? Я не специалист в таких вопросах, поэтому не знаю, с чего начать.
Выходит ли это на территорию суперкомпьютеров (6 и более цифр), или я могу получить такой сервер за небольшие 5-значные доллары?
Несколько примечаний на основе некоторых вопросов ниже:
Необычные требования иногда выигрывают от необычных решений. Конечно, вы можете отдать 6 фигурок Sun, Dell или HP и покончить с этим, но это не единственная игра в городе.
Для решений с одной коробкой получение до 128 ГБ очень дешево (32 x 4 ГБ ~ 3 000 долларов США), даже с домашними материнскими платами, которые стоят менее 1 000 долларов США. (не глумитесь над создателями. Если этого достаточно для Google ...)
256 ГБ намного дороже (32x8 ГБ ~ 18000 долларов США), и помимо этого ...
В качестве альтернативы рассматривали ли вы как альтернативу соединенные между собой дешевые боксы Infiniband (10 Гбит / с)?
Таким образом вы можете построить машину с 4 узлами, 16 процессорами (64 ядра) и объемом 512 ГБ, и при этом все равно получить сдачу от 25 000 долларов США.
Кроме того, у вас будут дополнительные преимущества постепенной деградации, если ваше приложение может работать на 3 машинах, если одна из них выйдет из строя, и, возможно, получить линейное масштабирование стоимости до 8 узлов (просто добавьте еще 4 узла). В таком случае вы смотрите на крутой 128-ядерный зверь с 1 ТБ RAM за <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/
Загляни в это. Это будет намного более рентабельно, чем создание единственной машины-монстра с безумным объемом оперативной памяти. Кроме того, если вы делаете что-то, что требует такого рода, это, вероятно, критически важно, и вам не нужна единая точка отказа.
БУДЬТЕ абсолютно осторожны при выборе таких размеров ОЗУ. Мы увеличили размер машины HP до 64 ГБ (HP заявила, что машина может занимать 128 ГБ), но только после добавления дополнительной переходной платы, охлаждающего вала и так далее (после долгого разговора с HP).
Только то, что для машины указано, что она занимает до n ГБ, это не означает, что она будет работать без дополнительных изменений. В нашем случае работали не все нормальные модули памяти, потому что они перегорели, работали только очень специфические модули.
Я не буду повторять предложения по оборудованию (которые звучат), но вы можете взглянуть на Terracotta, чтобы узнать, подходит ли он для вашего приложения.
Серверы Opteron с 4 или 8 сокетами, такие как HP DL585 или DL785 или Sun X4600, могут занимать большие объемы памяти в диапазоне 128–256 ГБ. Несмотря на то, что они недешевы, они определенно не соответствуют шестизначным ценникам; Восьмипроцессорный 32-ядерный Sun X4600 с 256 ГБ оперативной памяти на своем веб-сайте оценивает примерно 35 000 долларов, и это примерно столько же, сколько бывает у систем этого типа. Вы, вероятно, обнаружите, что можете приобрести систему по несколько меньшей цене, чем указанная на веб-сайте цена по прейскуранту.
Хотя доступны модули DIMM на 4 Гб, они, как правило, имеют большую надбавку к цене, поэтому переход на систему с максимальным их количеством будет значительно дороже.
Если вы хотите использовать систему этого типа, вам понадобится 64-битная операционная система. Убедитесь, что у вас также установлена 64-битная JVM, и убедитесь, что она хорошо работает с вашим приложением.
На самом деле у вас есть много вариантов: только из списка HP у вас есть их blade-сервер BL680c, который может занимать 128 ГБ, их DL580 / 585 - 256 ГБ, а их DL785 - 512 ГБ. Некоторые из IBM увеличивают объем до 256 ГБ, как и один Dell.
Стоимость оперативной памяти не масштабируется линейно до больших размеров. То, что я могу купить 1 ГБ DIMM за 15 долларов, не означает, что я могу получить сервер на 128 ГБ всего за 1920 долларов ... для начала вы не найдете материнскую плату со 128 слотами DIMM в ней.
Выше определенного размера (от ~ 8 до 16 ГБ) вы начинаете видеть материнские платы требующий модули DIMM с полной буферизацией (FB-DIMM), которые будут стоить вам значительно дороже за 1 ГБ, чем стандартная настольная память.
Мы регулярно используем машины со 128 ГБ памяти в них, и цена за последние годы сильно снизилась, но у меня нет текущих цифр ... ни опыта того, насколько хорошо JVM будет масштабироваться до такого размера памяти .
Я прочитал ваш комментарий о характере вашего приложения, но вы все же можете рассмотреть альтернативные решения.
FusionIO - реальная альтернатива. Просто посмотри. При цене в 10 тыс. Долларов он по-прежнему намного дешевле, чем сервер высокого класса. Пропускная способность записи 1,0 ГБ / с - звучит безумно.
Другой вариант - конечно же SSD. На всякий случай вы видели спецификации для твердотельного накопителя Intel® X25-E Extreme:
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 ГБ, это намного дешевле, чем альтернативные высокопроизводительные серверы.
Я большой поклонник подхода «много дешевых серверов». Вы изучали, возможно, запустить такой процесс на платформе Eucalyptus, доступной в Ubuntu 9.04? Возможно, вы сможете запустить такую программу на нескольких компьютерах в их собственной выделенной гигабитной сети с несколькими серверами с 8, 16 или 32 ГБ оперативной памяти и линейно масштабировать, добавляя больше дешевых серверов, когда они вам нужны.
Как насчет полностью готового решения: базы данных. Я знаю, вы сказали, что это будет слишком медленно, но это зависит от того, на каком хостинге он находится. Как насчет того, чтобы разместить его на массиве RAID0.
400 долларов за гаджет, Pricewatch перечисляет чипы по цене 55 долларов (совместимость не проверял) на 4 ГБ, так что это еще 440 долларов за память. Это дает вам 32 ГБ за 840 долларов. (Теоретически устройство может использовать чипы 8 ГБ, что в сумме составляет 64 ГБ, но чипы пока не поддерживаются.)
RAID0 4 из них, и вы находитесь в нижней части своего диапазона за чуть более 3000 долларов + обычная коробка. 16 из них получат верхнюю часть вашего диапазона за 14 тысяч долларов.
Независимо от того, можно ли это использовать или нет, также зависит от характера ваших данных - эти устройства энергозависимы и разряжают свою резервную батарею за несколько часов, хотя они могут выполнять резервное копирование на CF-карту.
Очевидно, вам нужны 64-битные операционные системы, но вы не находитесь на территории суперкомпьютеров. Например, Dell PowerEdge R900 и R905 доступны с 256 ГБ оперативной памяти и используют простые стандартные процессоры Intel Xeon / AMD Opteron и работают под управлением Linux, Solaris или Windows 2003 и 2008.
Конечно, покупка оперативной памяти непосредственно в Dell не очень рентабельна (они хотят ~ 35000 долларов США за 32 x 8 ГБ, в то время как вы можете получить ее уже примерно за 23000 долларов США, возможно, меньше), но, с другой стороны, вы можете захотеть для обеспечения надлежащей поддержки, если вы покупаете сервер за 40 000 долларов США (вы не ожидали, что 256 ГБ ОЗУ будет дешевым, не так ли? Если 128 ГБ также в порядке, вы можете сэкономить ~ 12 000 долларов США).
У меня нет опыта, какую операционную систему выбрать, я обычно не использую 100+ ГБ Java :)
Для этого вам, вероятно, понадобится специализированный сервер.
Попробуйте посмотреть ES7000 от Unisys. Описание там, вероятно, немного устарело.
Он может поддерживать до 512 ГБ оперативной памяти. Он использует хорошо известные операционные системы, такие как Windows и Linux Enterprise.
Это будет стоить вам ~ 30 тысяч долларов за стандартную конфигурацию, но с Itanium и всеми прибамбасами он может вырасти до ~ 600 тысяч долларов.
С таким большим объемом оперативной памяти вы можете хранить много горячих данных, вообще не занимая места на диске.
Типичный способ увеличить объем системной памяти - увеличить количество систем. Если память действительно является узким местом, то дело не столько в том, сколько памяти у вас есть, а в том, насколько хорошо ваши данные связаны с вашими процессорами. Вам нужно будет масштабировать множество вещей, чтобы это принесло вам много пользы.
Чтобы уточнить, просто добавление пары нулей в системную память, вероятно, не собираюсь делать то, что вы думаете. Что вы обнаружите, так это то, что теперь, когда весь ваш набор данных умещается в памяти или даже немного больше, вы столкнетесь с другим узким местом, таким как недействительность кеша.
Правильный способ масштабирования вашей системы - медленно. Если вы в настоящее время работаете, скажем, на 4-ядерной системе с 8 гигабайтами оперативной памяти, сначала чертовски профилируйте свое приложение, чтобы увидеть, на что оно действительно тратит время, затем попробуйте увеличить до 12 или 16 гигабайт оперативной памяти и посмотрите, как результаты профилирования изменились.
Настоящий вопрос заключается в том, зачем вам нужно примерно в 100 раз больше системной памяти по сравнению с другими ресурсами, чем обычно доступно. Если ваш шаблон доступа к данным в некотором роде предсказуем, вам следует увеличить пропускную способность диска, несколько контроллеров рейда с несколькими дисками с чередованием смогут этого добиться.
Если ваш шаблон доступа к данным действительно случайный, то, вероятно, есть место для более оптимизированного алгоритма.
Допустим, вы можете разместить такой объем памяти в сервере (если я не ошибаюсь, Linux на стандартном оборудовании ограничен 64 ГБ, но я не уверен).
В большинстве операционных систем JVM ограничена пространством кучи около 1,4–1,6 ГБ, отчасти потому, что требуется непрерывная память, а отчасти из-за ограничений операционной системы.
Следовательно, дополнительная оперативная память не поможет вам масштабировать одно приложение, она позволит вам запускать только несколько экземпляров приложения. Однако тогда вам понадобится несколько ядер и возникнут другие проблемы.
Зачем вам столько оперативной памяти? Возможно, вам удастся найти базы данных, которые можно хранить в памяти или использовать RAM-диск, но я не знаю JVM, которая позволила бы вам хранить такой объем информации в памяти.
Подойдет ли вам решение Amazon EC2? Это, безусловно, было бы наиболее экономичным решением.
Я думаю, вы начнете сталкиваться с проблемами с запасом на 64 ГБ на традиционном оборудовании. Если вы можете масштабировать оттуда, все будет в порядке, но я предполагаю, что гораздо более экономичным решением было бы подвергнуть сомнению вашу архитектуру. Конечно, я говорю это, не зная, что вы делаете, но я просто бросаю это там.
Подобно предложению FusionIO, вы можете получить устройства, которые позволяют подключать динамическую RAM к интерфейсу SATA. Что-то вроде этот (У меня нет опыта работы с продуктом или компанией, это всего лишь первый вариант, появившийся при поиске в Google Покупках).
Вы можете использовать пару из них в качестве смонтированных файловых систем для кэширования данных с использованием логики вашего приложения (оно имеет резервное питание, поэтому оно должно выдерживать загрузку и другие сбои), или вы можете использовать их как пространство подкачки и позволить ядру решать, как их использовать ( хотя, поскольку ядра ОС обычно оптимизированы, предполагая, что все места подкачки на несколько порядков медленнее и более латентны, чем реальная оперативная память, тогда это будет, вам, вероятно, придется значительно настроить его, чтобы наилучшим образом использовать такое расположение).
Вариант FusionIO будет более выгодным, если вам действительно нужно что-то такое большое, такой тип RAM-накопителя может быть лучше в качестве компромисса. Я оставлю читателю в качестве упражнения для определения того, насколько хорошо сервер, способный иметь 128 ГБ ОЗУ на материнской плате и пару таких с заполненными 64 ГБ, по сравнению с ценой и производительностью со специализированным сервером, поддерживающим напрямую 256 ГБ или более!
Через 3 года после квеста все намного проще.
Я искал некоторые Кремниймеханика конфиги.
Самый дешевый способ - использовать платформы AMD с 32 димма - 512 ГБ - 11.940 $.
Альтернативой, но гораздо более дорогой за гигабайт, является Платформа Intel на 64 димма - 1 ТБ - 48.769 $.