помогите выбрать сервер

[Anatoly Pashin]

Добрый день.

В ближайшем будущем планируется приобретение web-сервера (nginx + php-fpm, postgresql/mysql)

Бюджет ≈$15k

Приблизительная оценка посетителей: 500 запросов/секунда.

Сервер БД располагается тут же.

Пока прикидываю такое:

1. IBM x3650 M4 Rack (2U), 1x Xeon 8C E5-2680 (2.7GHz/1600MHz/20MB/130W), 1x8GB 1.5V RDIMM, noHDD 2.5''HS SAS/SATA(8/16up), SR M5110e (1GB flash, raid 0,1,10,5,50), noDVD, 4xGbE, 1x900W PS(up2) 
2. IBM Intel Xeon Processor E5-2680 8C (2.7GHz, 20MB, 1600MHz, 130W, W/Fan) (x3650 M4) 
3. 23 × IBM Express 8GB (1x8GB, 2Rx4, 1.5V) PC3-10600 CL9 ECC DDR3 1333MHz LP RDIMM (x3400 M3/x3500 M3/x3550 M3/x3620 M3/x3650 M3) (49Y1436) 

Вопросы:

1. Не могу определиться с дисковой системой. Пока пришёл к такому варианту: 
• 2 hdd под систему, raid 1
• 2 ssd под БД, raid 1. К сожалению, опыта с ssd нет. Их вообще стоит ставить в raid?
• 2 ssd под код, raid 1. То же по рейду…
• что-то под бекапы, скорее всего 2 hdd по 2ТБ в raid 1
2. С учётом вопроса 1, оцените, пожалуйста, теоретический rps такого сервера?

Спасибо. Извините, если где-то затупил или кажусь полным нубом в вопросе с ssd.

--
Пашин Анатолий,
эникейщик.

[Maxim Fedchishin]

По дискам:

2 HDD под OS в RAID 1

4 SSD/HDD под БД/код в RAID10. На текущий момент самое быстрое RAID решение.

Прикиньте, как быстро БД будет расти. Возможно имеет смысл взять SAS диски вместо SSD и поставить их в RAID10. Получится бОльший объем за ту же цену.

В коде используйте кеширование по максимуму, это снизит нагрузку на БД. Из моего опыта подвлючение memcached снизило нагрузку на БД в 10 раз.

Но по хорошему, рекомендовал бы иметь два сервера: один для БД, второй для кода.

Рано или поздно вырастите из масштабов одного сервера и надо будет расширяться.

Удачи!

14 ноября 2012 г., 7:34 пользователь Anatoly Pashin <anatoly...@gmail.com> написал:

[Илья Антипов]

Здесь делали тесты SSD vs RAID10 http://www.mysqlperformanceblog.com/2012/09/11/intel-ssd-910-vs-hdd-raid-in-tpcc-mysql-benchmark/ - почитайте, сделайте выводы. 

И прикиньте сколько Вам надо оперативной памяти. Memcahed + буферы mysql (желательно все в память загнать - тут надо на статистику базы смотреть) + некоторая память на каждый процесс php. 

И подумайте над хранением бэкапов в другом месте.

Вряд ли кто Вам скажет по оценке rps. Может получится и 1 rps на таком железе, если софт написан так, что блокирует всю базу и отпускает ее через 5 минут.

[Anatoly Pashin]

Спасибо за грамотные ответы.

Тестирование то несколько странное… сравнивают hi-end карточки ssd с hdd 7200? Ладно б ещё с 15к.

Некоторые уточнения, которые мне стоило дать сразу…

1. Приложения на php (symfony), онлайн-тесты. Есть набор вопросов, пользователь последовательно отвечает на каждый вопрос.
2. Запись в БД/чтение ≈ 1/30.
3. Среднее время генерации страницы, например, 150 мс.

15 ноября 2012 г., 6:19 пользователь Илья Антипов <ilan...@gmail.com> написал:

[Maxim Fedchishin]

По поводу БД: логично использовать mysql master на записаь и mysql slave на чтение.

Снизит нагрузку на сервер и увеличит скорость работы.

Но это означает уже 3 сервера :)

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

14 ноября 2012 г., 11:54 пользователь Anatoly Pashin <b1rd...@gmail.com> написал:

[ColorPrint]

Как вариант - ZFS массив и SSD в качестве кэширующего диска в нем же...

Это если нагрузка и на базу, и на раздачу контента, и все это не поместится просто на SSD

2012/11/14 Anatoly Pashin <anatoly...@gmail.com>

--
Best Regards, 

Anton Anikin

[Artem Miolini]

Здравствуйте!

А что у вас сейчас в качестве сервера, какая посещаемость и нагрузка на сервер?

2012/11/14 Anatoly Pashin <anatoly...@gmail.com>

[Anatoly Pashin]

Оперативки в конфиге 192 гб.
По ссд тоже решил что не стоит рисковать.
Спасибо откликнувшимся :-)

15.11.2012 8:23 пользователь "Александр Сахарчук" <alex...@saharchuk.com> написал:

Я бы рассматривал в рамках бюджете разделение на 2а сервера. Отдельно MySQL сервер работает в связки куда лучше.

Это поможет и проще профилировать компоненты и прочее. Но это, отступление. Если клиент хочет, то конечно для старта обычно один сервер.

Вам давали очень толковые замечание по оперативке. По опыту долгой поддержки и работы с SSD, все часто забывают насколько они ненадежны и то, что в RAID они выходят из строя одновременно. SSD пока маркетинг. И оправдано, только для статики и введение в RAID вторых дисков не раньше, чем через месяц. А хороший RAID SAS в общем может и уделать SSD диски. Каждый случай уникальный, и возможно вам подойдут SSD, все будет казатся шустрым, но готовьтесь менять их и не забывайте вводить их в RAID по отдельности.

среда, 14 ноября 2012 г., 17:34:59 UTC+2 пользователь Anatoly Pashin написал:

[Anatoly Pashin]

У ssd нет механических частей, ресурс только на количество циклов записи. В raid 1 данные дублируются.
А значит помрут они сразу.

20.11.2012 22:24 пользователь "nikitosiusis" <nikito...@gmail.com> написал:

А что значит "что в RAID они выходят из строя одновременно" ? Расскажите подробнее.

On Thursday, November 15, 2012 1:23:43 AM UTC+4, Александр Сахарчук wrote:

Я бы рассматривал в рамках бюджете разделение на 2а сервера. Отдельно MySQL сервер работает в связки куда лучше.

Это поможет и проще профилировать компоненты и прочее. Но это, отступление. Если клиент хочет, то конечно для старта обычно один сервер.

Вам давали очень толковые замечание по оперативке. По опыту долгой поддержки и работы с SSD, все часто забывают насколько они ненадежны и то, что в RAID они выходят из строя одновременно. SSD пока маркетинг. И оправдано, только для статики и введение в RAID вторых дисков не раньше, чем через месяц. А хороший RAID SAS в общем может и уделать SSD диски. Каждый случай уникальный, и возможно вам подойдут SSD, все будет казатся шустрым, но готовьтесь менять их и не забывайте вводить их в RAID по отдельности.

среда, 14 ноября 2012 г., 17:34:59 UTC+2 пользователь Anatoly Pashin написал:

Добрый день.

[Alex Samorukov]

On 11/20/2012 03:00 PM, Anatoly Pashin wrote:
> У ssd нет механических частей, ресурс только на количество циклов
> записи. В raid 1 данные дублируются.
> А значит помрут они сразу.

Это не совсем так (точнее - совсем не так).

1) SSD поддерживает SMART и там обычно есть параметр, что-то вроде
wearing, который в процентах говорит сколько диску жить осталось.
Мониторьте смарт smartd/smartctl и будет вам радость.
2) Ваше предположение основывается на том, что количество циклов записей
строго фиксировано. Это не так - в моей практике были случаи когда на
одинаковой нагрузке время жизни оказывалось очень разным. Производитель
говорит о гарантированном количестве циклов перезаписи, а не о какой-то
конечной цифре, всё равно "плохие" ячейки вылавливает сборщик мусора и
на основе количества "резервов" делает прогноз (в смарте) о состоянии диска.
3) Основная проблема ССД в рейдах - это то, что аппаратные рейды не
поддерживают TRIM, что не позволяет сообщать диску о том, что сектор
больше "не нужен" и устройство может использовать его для своих целей.
Это крайне негативно влияет на производительность.

Насколько я знаю пока трим поддерживают только софтовые рейды, а точнее
- mdraid на самых свежих ядрах, intel RST raid и ZFS с патчами для TRIM.
Все "hard". Естественно, что вся цепочка (filesystem -> volume manager
-> block_device_driver -> controller) должна также поддерживать. TRIM.

Такие дела.

[Александр Сахарчук]

Анатолий, верно передал суть. И я целиком согласен.

Поясню, что я имел ввиду когда писал одновременно.

Имел ввиду опыт того, как клиенты ставят себе RAID. Ваше замечание про SMART имеет право на жизнь, но реалии часто отличаются от того как должно быть. В реалиях даже бекапы не все делают...

Если рассматривать SSD как замена SAS, для ускорения работы, то скорость износа выше, в выход из строя конечно у них не ежесекундный, но часто когда приходит момент Х, восстановить с другого диска информацию нельзя в полном обьеме. А имея мониторинг, вы будете останавливать сервер и ждать замены дисков? В данном случае уместнее мониторить диски, зная что выход из строя у них не будет с разницей в день/два.

А все отсальное вы сами подвердили своим ответом, SSD еще сыроват как полноценная замена доброму RAID на SAS. Нужно пользоватся  с умом.

вторник, 20 ноября 2012 г., 17:17:52 UTC+2 пользователь Samm написал:

[nikitosiusis]

а можете рассказать про ваш личный опыт общения с ссд? какие модели вы ставили в зеркало и через сколько они умирали?
у какой модели вы видели скорость износа такой, что можно было бы сравнивать с сас-хардами(какими?) ?
сколько ссд у вас умерло из-за отсутствия TRIM, за какой срок, какие модели?
когда происходил "момент Х", что нельзя было восстановить информацию, с какого ссд и почему?

[Alex Samorukov]

On 11/20/2012 10:53 PM, nikitosiusis wrote:
> а можете рассказать про ваш личный опыт общения с ссд? какие модели вы
> ставили в зеркало и через сколько они умирали?

В основном - intel саташные, например тот же 330. Был OCZ, но вот он как
раз сдох как-то неприлично рано, может не повезло просто.

> у какой модели вы видели скорость износа такой, что можно было бы
> сравнивать с сас-хардами(какими?) ?

Для моих задачь (в основном - чтение из больших таблиц, часто без
индекса) - рейд10 из сравнительно дешевых десктопных SSD практически
всегда быстрее рейд10 из SAS. С записью не все столь очевидно, если raw
write - может проиграть, если random write - скорее всего выиграет за
счёт отсутсвия затрат на random seek.

> сколько ссд у вас умерло из-за отсутствия TRIM, за какой срок, какие
> модели?

Насколько я знаю - TRIM не влияет на продолжительность жизни, зато -
сильно влияет на скорость. Дело в том, что скорость SSD пустого и
полного очень сильно отличается (поэтому совтую планировать так, чтобы
~треть всегда было свободным). Без поддержки TRIM SSD просто не узнает,
что файловой системе этот "сектор" не нужен и его можно вернуть в пул
свободных ячеек.

> когда происходил "момент Х", что нельзя было восстановить информацию,
> с какого ссд и почему?

Так жестко у меня сдохли только OCZ, за что и были возвращены
поставщику. Причём сдохли так, что их биос не видел. На каких-то интелах
через примерно год смарт стал ругаться и вскоре стала глючить запись -
но там отчасти была моя вина, на эти диски была слишком интенсивная
запись. Кстати, диск читался, т.е. информацию с него можно было спасти.
В целом мне почти наплевать на сохранность данных - это слейвы. На
мастере стоят кажется sas ssd по цене вертолета, но тот сервер
администрирую не я ) Часть дисков живет уже больше двух лет и пока не
дохнут. Да, ещё потребуется указать опцию discard при монтировании.

Кстати про TRIM. До того, как mdadm с горем пополам их научился на
raid1-raid10 (с лвм там до сих пор вроде не всё ок) я использовал скрипт
wiper.sh (гуглится в сети) который делал TRIM из крона, правда он
работал только с ext4. Для xfs был fstrim, но я его не тестировал. В
октябре в ядре добавили TRIM в mdraid RAID10 (уже вроде и в RAID5), я
правда не проверял работает ли оно с lvm, у меня он не используется для
этих дисков.

Короче, оно сыровато - но как по мне вполне работает и на некоторых
задачах легко уделает 15K SAS SSD, как по скорости, так и по цене
решения. Кстати, вы можете добавить потом в систему для RAID1 2 диска,
собрать mdraid и, например, положить на них базу. Ну а бекапы никто не
отменял, винты тоже дохнут ок, у меня недавно как раз в RAID5 два винта
сдохли с интервалом в час и сроком службы всего 2.5 года )

[nikitosiusis]

Что-то то, что вы рассказали отвечает разве что на 10% моих вопросов. Я не хочу теорию, хочу практику.
У вас правда интел 330 умерли в зеркале оба одновременно?
У вас правда был рейд10 из ссд(каких?) и с ним были какие-то проблемы?
Вы правда делали замеры скорости с TRIM и без и видели сильную разницу? Как TRIM может быть полезен на mostly-read базе данных?
"Без поддержки TRIM SSD просто не узнает, что файловой системе этот "сектор" не нужен и его можно вернуть в пул свободных ячеек. " - это вы думаете, что если нет TRIM, то на ссд можно записать только один раз?
Сколько терабайт было записано на тот интел, на котором стал за год ругаться смарт?

[Mykola Dzham]

2012/11/21 Alex Samorukov <sa...@os2.kiev.ua>

Насколько я знаю - TRIM не влияет на продолжительность жизни, зато - сильно влияет на скорость. Дело в том, что скорость SSD пустого и полного очень сильно отличается (поэтому совтую планировать так, чтобы ~треть всегда было свободным). Без поддержки TRIM SSD просто не узнает, что файловой системе этот "сектор" не нужен и его можно вернуть в пул свободных ячеек.

А вот если TRIM нету (не пролазит команда из-за наслоения вещей типа блочного шифрования через geli), то будет ли достаточно просто часть ssd изначально оставить неразмеченой?

LEFT-(UANIC|RIPE)

[Mykola Dzham]

2012/11/21 nikitosiusis <nikito...@gmail.com>

Что-то то, что вы рассказали отвечает разве что на 10% моих вопросов. Я не хочу теорию, хочу практику.
У вас правда интел 330 умерли в зеркале оба одновременно?

По моему Вы не отслеживаете кто именно и что именно писал.

 

...

"Без поддержки TRIM SSD просто не узнает, что файловой системе этот "сектор" не нужен и его можно вернуть в пул свободных ячеек. " - это вы думаете, что если нет TRIM, то на ссд можно записать только один раз?

Очень странные выводы из фразы

 

--
LEFT-(UANIC|RIPE)

[Alex Samorukov]

On 11/21/2012 11:10 AM, nikitosiusis wrote:
> Что-то то, что вы рассказали отвечает разве что на 10% моих вопросов.
> Я не хочу теорию, хочу практику.
> У вас правда интел 330 умерли в зеркале оба одновременно?

Нет, неправда. Я нигде этого не писал.

> У вас правда был рейд10 из ссд(каких?) и с ним были какие-то проблемы?

Были и есть, сейчас 320 и 330 серия. Начинал с X25 и X18, сдохли вроде
25ки, уже точно не помню. Проблем особо не было, из рекомендаций -
шустрый контроллер SATA обязательно в AHCI mode (NCQ и все такое), ядро
посвежее. smartctl тоже желательно последний, там много SSD related
changes, атрибуты совсем другие чем в винтах + специфичные для ssd log
pages.

> Вы правда делали замеры скорости с TRIM и без и видели сильную
> разницу? Как TRIM может быть полезен на mostly-read базе данных?

Да, правда. Что вполне сходится с другими блогами. Mostly read != only
read, ага, несколько огромных таблиц ежемесячно дропаются и
пересоздаются. Разница хорошо была видна на синтетических тестах записи,
на read performance думаю это не особо повлияет.

> "Без поддержки TRIM SSD просто не узнает, что файловой системе этот
> "сектор" не нужен и его можно вернуть в пул свободных ячеек. " - это
> вы думаете, что если нет TRIM, то на ссд можно записать только один раз?

Нет, неправда. Это значит, что пул свободных ячеек будет намного меньше
чем в случае TRIM enabled, а write performance - ниже. Гугл прекрасно
дает ответы на этот вопрос, ага. При чем тут "только 1 раз" я вообще не
понимаю, команду WRITE винт прекрасно выполнит перезаписав "сектор".
Без TRIM перезапись "секторов" будет работать также как и ранее.

Почитайте http://www.ssdperformanceblog.com/, например. Там много тестов
в том числе и ent. level продуктов, которые мне недоступны.

> Сколько терабайт было записано на тот интел, на котором стал за год
> ругаться смарт?

Ежедневно писалось ~50-200Gb (реплицировались нафиг не нужные там daily
лог таблицы).

[nikitosiusis]

On Wednesday, November 21, 2012 2:39:37 PM UTC+4, Samm wrote:

On 11/21/2012 11:10 AM, nikitosiusis wrote:
> Что-то то, что вы рассказали отвечает разве что на 10% моих вопросов.
> Я не хочу теорию, хочу практику.
> У вас правда интел 330 умерли в зеркале оба одновременно?
Нет, неправда. Я нигде этого не писал.

Да, перепутал вас с топикстартером, это было его теория.

> У вас правда был рейд10 из ссд(каких?) и с ним были какие-то проблемы?
Были и есть, сейчас 320 и 330 серия. Начинал с X25 и X18, сдохли вроде
25ки, уже точно не помню. Проблем особо не было, из рекомендаций -
шустрый контроллер SATA обязательно в AHCI mode (NCQ и все такое), ядро
посвежее. smartctl тоже желательно последний, там много SSD related
changes, атрибуты совсем другие чем в винтах + специфичные для ssd log
pages.
> Вы правда делали замеры скорости с TRIM и без и видели сильную
> разницу? Как TRIM может быть полезен на mostly-read базе данных?
Да, правда. Что вполне сходится с другими блогами. Mostly read != only
read, ага, несколько огромных таблиц ежемесячно дропаются и
пересоздаются. Разница хорошо была видна на синтетических тестах записи,
на read performance думаю это не особо повлияет.

А что за бд использовали? К примеру mysql+иннодб по дефолту не вычистит за собой удаленную таблицу с диска и TRIM никак не пригодится.

> "Без поддержки TRIM SSD просто не узнает, что файловой системе этот
> "сектор" не нужен и его можно вернуть в пул свободных ячеек. " - это
> вы думаете, что если нет TRIM, то на ссд можно записать только один раз?
Нет, неправда. Это значит, что пул свободных ячеек будет намного меньше
чем в случае TRIM enabled, а write performance - ниже. Гугл прекрасно
дает ответы на этот вопрос, ага. При чем тут "только 1 раз" я вообще не
понимаю, команду WRITE винт прекрасно выполнит перезаписав "сектор".  
Без TRIM перезапись "секторов" будет работать также как и ранее.

Почитайте http://www.ssdperformanceblog.com/, например. Там много тестов
в том числе и ent. level продуктов, которые мне недоступны.

> Сколько терабайт было записано на тот интел, на котором стал за год
> ругаться смарт?
Ежедневно писалось ~50-200Gb (реплицировались нафиг не нужные там daily
лог таблицы).

 ну это не больше 100тб за год. Это мизерное число для ссд, странно что оно от этого умерло.

[Alex Samorukov]

On 11/21/2012 12:03 PM, nikitosiusis wrote:

> Вы правда делали замеры скорости с TRIM и без и видели сильную
> разницу? Как TRIM может быть полезен на mostly-read базе данных?
Да, правда. Что вполне сходится с другими блогами. Mostly read != only
read, ага, несколько огромных таблиц ежемесячно дропаются и
пересоздаются. Разница хорошо была видна на синтетических тестах записи,
на read performance думаю это не особо повлияет.

А что за бд использовали? К примеру mysql+иннодб по дефолту не вычистит за собой удаленную таблицу с диска и TRIM никак не пригодится.

MySQL, причем с InnoDB и MyISAM т.к. использовался Spatial Extensions, а его только в 5.6 вроде в InnoDB запилили. По поводу innodb - google innodb_file_per_table, кстати в 6 оно дефолтово насколько я помню, и все прекрасно освобождается.

[Ruzin Alexey]

С уважением,

Алексей Рузин

14.11.2012, в 19:34, Anatoly Pashin <anatoly...@gmail.com> написал(а):

Добрый день.

В ближайшем будущем планируется приобретение web-сервера (nginx + php-fpm, postgresql/mysql)

Бюджет ≈$15k

Приблизительная оценка посетителей: 500 запросов/секунда.

Сервер БД располагается тут же.

Пока прикидываю такое:

1. IBM x3650 M4 Rack (2U), 1x Xeon 8C E5-2680 (2.7GHz/1600MHz/20MB/130W), 1x8GB 1.5V RDIMM, noHDD 2.5''HS SAS/SATA(8/16up), SR M5110e (1GB flash, raid 0,1,10,5,50), noDVD, 4xGbE, 1x900W PS(up2) 
2. IBM Intel Xeon Processor E5-2680 8C (2.7GHz, 20MB, 1600MHz, 130W, W/Fan) (x3650 M4) 
3. 23 × IBM Express 8GB (1x8GB, 2Rx4, 1.5V) PC3-10600 CL9 ECC DDR3 1333MHz LP RDIMM (x3400 M3/x3500 M3/x3550 M3/x3620 M3/x3650 M3) (49Y1436) 

Вопросы:

1. Не могу определиться с дисковой системой. Пока пришёл к такому варианту: 
• 2 hdd под систему, raid 1
• 2 ssd под БД, raid 1. К сожалению, опыта с ssd нет. Их вообще стоит ставить в raid?

По нашему опыту SSD лучше в RAID не ставить.

Мы правда делали 8xSSD128GB RAID5, и он два раза был сломан (один раз пришлось восстанавливать через специальную контору).

Мы выбирали с точки зрения производительность под большую БД (150GB)  и  до (1000/запросов секунду).

В итоге вернулись к двум SSD 500GB без RAID'а, один боевой, на другой делается бэкап, случись что,

в течение нескольких часов все можно поднять на другом. (Еще у нас делается непрерывно реплика на

другой почти такой же рядом стоящий сервер)

В целом за почти два года эксплуатации полет нормальный.

И вопрос в сторону, а точно ли нужны конфигурации 1xXeon 8GB? не лучше ли взять 2xXEON 16GB в том же корпусе?

Мы эксплуатируем свою систему взяв все в аренду тут: www.serverloft.com 

Для считалок XXL 2.5 на XEON'ах

Для БД один кастомный сервер на AMD 32 ядра и 64 GB RAM.

Когда запуститесь, было бы приятно узнать о финальном варианте, так сказать обмен оптом.

[Alex Samorukov]

On 12/03/2012 05:49 AM, Ruzin Alexey wrote:
>
> По нашему опыту SSD лучше в RAID не ставить.
> Мы правда делали 8xSSD128GB RAID5, и он два раза был сломан (один раз
> пришлось восстанавливать через специальную контору).
>

Конечно же, вы засунули их в аппаратный рейд и не мониторили смарт ))

Кстати, рейд5 для ссд - глупость как по мне. Обычно RAID SSD
используется для обеспечения максимального TPS. А это 10ка, тем более
что запись у ССД и так значительно хуже чтения. Да и чинить 10ку проще,
если что, без всяких "специальных" контор.

[Vitaliy Okulov]

3 декабря 2012 г., 14:27 пользователь Alex Samorukov <sa...@os2.kiev.ua> написал:

Лучше конечно мониторить и иметь как один минимум hotspare диск.

RAID 10 тоже ломается, особенно если диски ставятся из одной партии, особенно если ломаются 2-а диска из RAID 1 сразу, такое бывало.

[Anatoly Pashin]

Там 2 ксеона восьмиядерных и озу 192 гб.

Нет возможности поставить несколько серверов, поэтому остановились на таком варианте.

По дисковой подсистеме остановились на SAS 146GB 15K. Заказали 11 штук, пока не определился в какие массивы их поделить.

Почему hdd: дело в том, что IBM планирует начать поставки ssd только в 2013. А это грустно.

Постараюсь рассказать про финальный вариант.

3 декабря 2012 г., 15:49 пользователь Ruzin Alexey <00a...@gmail.com> написал:

[Alexey V. Karagodov]

чем вам RAID6 +2 hotspare не вариант? 

RAID6 - может упасть сразу 2 диска 

2 hotspare не будут дёргаться пока кто-нить из массива не сдохнет, соответственно у них ресурс будет больше и того ресурса хватит чтобы в магаз гонца послать 

да, дорого, но дешевле чем hotspare на каждую 1-ничку 

по скорости тоже самое будет с нормальным контроллером, даже лучше 

[Anatoly Pashin]

Raid 1 хочу чтобы разделить нагрузку от бд отдельно от всего. А 6, насколько я понимаю, даст мне 1 контейнер?

03.12.2012 21:35 пользователь "Alexey V. Karagodov" <kav.karag...@gmail.com> написал:

[Alexey V. Karagodov]

On 03.12.2012, at 15:35, Anatoly Pashin <anatoly...@gmail.com> wrote:

Raid 1 хочу чтобы разделить нагрузку от бд отдельно от всего.

не понимаю как и зачем и что это разделит 

А 6, насколько я понимаю, даст мне 1 контейнер?

да 

потом уже можно будет нарезать средствами ОС или виртуализации 

[Vitaliy Okulov]

RAID 10 процентов на 30% побыстрее RAID 6, судя по тестам:

http://www.tomshardware.com/reviews/sas-6gb-raid-controller,3028-12.html

http://docs.oracle.com/cd/E19269-01/820-1847-20/appendixf.html#50515995_80148

3 декабря 2012 г., 14:35 пользователь Alexey V. Karagodov <kav.karag...@gmail.com> написал:

[Vitaliy Okulov]

В итоге скорость работы СУБД ограничится скоростью работы 2-х HDD, на том же RAID 10 СУБД будет работать побыстрее.

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

3 декабря 2012 г., 15:35 пользователь Anatoly Pashin <anatoly...@gmail.com> написал:

[Alexey V. Karagodov]

тут есть о чём похоливарить 

http://lonesysadmin.net/2010/09/28/disk-performance-of-a-16-drive-dell-poweredge-r910/

[Vitaliy Okulov]

Согласен, тут главное лоб не разбить +).

Вот еще в топку: http://www.bestor.spb.ru/Bestor_02/Marks/MarkByRAID.aspx?act=1

3 декабря 2012 г., 16:13 пользователь Alexey V. Karagodov <kav.karag...@gmail.com> написал: