имеем:
- два одинаковых SSD диска по 400 Гб каждый
- два одинаковых HDD SATA по терабайту.
- РЭЙД контроллер на 4 канала со скоростью до 6 Гб (или 6 ГБит..)

хотим два виртуальных сервера для разработки приложений: один для программистов, другой под сервер баз данных

как лучше организовать РЭЙД? критерий - быстродействие.
конфигурации серверов и оборудования обсуждаются.

зачем ссд рейд ускорение ?

хост на зеркало ХДД, обе машины на ссд, бекапы всего этого куда-нить на сторону, один ссд в запасе

даже если все сдохнет, машины из бекапа на любой подручный хост и поехали

(0)Если критерий быстродействие то нужен просто SSD.
Если очень критична бесперебойная работа, то можно задуматься о зеркальном рейде.

В общем смотрите (2).

(1) если ССД сам по себе медленнее, чем 6Гбит/с, то объединив 2 ССД в РЭЙД-0, получим ускорение. или нет?

(5)В некоторых случаях да, в некоторых случаях нет.

Причем реально получить и замедление вместо ускорения.

(5) от контроллера зависит. Судя по всему, контроллер здесь никакой

И довольно странные у вас представления о скорости.
6Гбит/с это скорость интерфейса, это примерно 750мегабайт в секунду скорость.
Где вы видели диск, неважно HDD или SSD работающий на таких скоростях с описанными вами задачами?


Разработка приложений, и работа с БД это в основном операции случайного чтения и записи, блоками в районе 4к.
При такой работе средняя скорость HDD в районе 0,5-5Мб/c, а для SSD 30-60МБ/с.
Какие там 750мегабайт/с ?

(8) все железо древнее. выкинь на мусорку - никто не позарится ((

(10) Ну и забудьте про рейды для скорости.
Зеркало для отказоустойчивости из HDD сделать можно, причем и без контроллера, софт рейд ничуть не хуже для этих целей.

А вот SSD в рейд пихать, это сто раз подумать надо.
Большинство контроллеров банально не поддерживают TRIM  в рейде.
А без трима вы получите нехилую деградацию скорости записи.
С этим можно бороться и без трима, но тут нужен либо дорогой серверный SSD c мощным процессором, и 100% запасом резервных ячеек. Или делать подобие такового из обычного SSD оставляя неразмеченным часть диска.

Тогда только вариант (2). И упретесь вы в память и проц, явно не в ССД

(2) почему обе машины на ссд?

(1) материнка поддерживает SAS интерфейс. значит, ССД точно не надо в РЭЙД, да?

(13) Потому что на них будут работать пользователи и будет критично быстродействие.
А хосту в принципе пофиг, один раз загрузился в память и все.

(14)Какое отношение имеет наличие SAS интерфейса к необходимости рейда?

железо:
cpu Xeon E31240 3.30 GHz
4*8 Гб оперативы
материнка с поддержкой САС
РЭЙД 4*6 Гбит/с

хренасе древнее, ксеон на иви с 32 озу. Это уровень G8
Другое дело, что все это десктопное. Мать какая?

на иопсы всем тут пофиг по ходу

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

То навскидку:
На SSD - поставить СУБД в RAID 1 (получим _возможно_ быстрое чтение + сохранность данных при падении одного диска).
На обычные харды - один хард под систему, второй - под бэкапы.

Основная нагрузка ляжет на диски под СУБД. Аппликейшн особо дергать винты не будет.

(17) не знаю, я разработчик. в VMWare client это можно посмотреть?

(18) это тестовые сервера. из пользователей я одна. 2 базы под MSSQL по 60 Га.

(21) см (19) - ИМХО лучший вариант.

(21) А если вы одна и база всего лишь под 60Гб, то такой вариант:
1 виртуалка: 1 sata под систему + 1 ssd под СУБД
2 виртуалка: 1 sata под систему + 1 ssd под СУБД

И все. Саташные диски 15к или 10к rpm?

(23) фигню сморозил ))), у нас же всего лишь app + db.

1 виртуалка: 1 ssd под систему
2 виртуалка: 2 sata (raid 1) под СУБД

А один ssd - можно выключить.

Вы все равно одна, а этой конфигурации вам хватит.

(21)  база в сингл мод 60гб? Памяти мало хорошо бы 128 озы и два камня.

(18) Про йопсы тебе уже рассказали выше: текущее железо не сможет реализовать потенциал и одного ссд, а уж нулевой рейд может поломать вообще.
ты херню какую-то советуешь, ни к железу, ни к задачам

(20) Тогда зачем ты эту ветку завела, если делать будет другой человек?

(24)А хост на чем?

У меня как-то SSD 40Гб на ESXi 5.0 был только в качестве загрузочного и кэша. Для домашнего "сервера". SSD умер через 2 месяца.

(26) то, что сделано, меня не устраивает.

(27) а сделано следующее:
SSD + SSD -> RAID0 virtual drive1
HDD + HDD -> RAID0 virtual drive2

виртуалки на virtual drive1
пользовательские данные на virtual drive2

думаю все согласятся с фразой "жесть какая"

(30) не устраивает чем?

(31) Это называется - хуже не придумаешь.

(33) неутешительные нагрузочные тесты
(34) я к этому причастна.
на данный момент я за выведение SSD из РЭЙД. но если система имеет право на существование, то пусть будет как есть.

(35) один ssd можно и убрать из рейда.

(29) И что ты хочешь этим сказать?

(31) Это ужасно.
Отказоустойчивость ниже плинтуса, скорость меньше чем у одного SSD.

(37) SSD на персональном компе живут давно, проблем нет.
На ESXi 6.0 пока не рискую, т.к. не нашел информации, что, например, умеет ли гость сообщать хосту, что у него есть незанятое пространство на диске. Т.е. непонятно как там работает TRIM.

На век ТС этих ссд хватит

(39) SSD по надежности мало отличаются от HDD.
Так же ломаются, как правило из за брака, или ошибок в прошивке.

Особой разницы между использованием в пк и на сервере нет.
Разница только в нагрузке.

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

Насчет ESXi 6.0 зачем гость должен что-то сообщать хосту?
ТRIM делает тот кто пишет на диск, в данном случае хост, если конечно умеет.
И ему для этого никакая информация от гостя не нужна.

тут выше вроде проскочила инфа, что кто-то подружил ESXi с ССД, ну типа даже хост воткнул.

я хочу пообщаться с этими спецами, есть для них работа )

(40) при умелом исппользовании можно убить и эти ссд

(43) убить можно все, не спорю.

(43) Только в случае целенаправленного убивания.
Случайно, или по незнанию, просто эксплуатируя это на грани фантастики.