Chaparral FFS224 Dual Redundant version

[SVV]

Здравствуйте,
есть некий зверь Chaparral FFS224 Dual Redundant version:
http://www.chaparralnet.com/prod/produc ... n=benefits
с вот такой коробкой http://www.jmr.com/solutions/collateral ... index.html

Интерисует что в нём плохого
Какие грабли могут вылезти, может кто пользовал, а может что-то по спецификации видно.

Может есть у кого-то результаты тестирования или сравнения с конкурентами.

[a_shats]

Это всего лишь контроллер Ну, 15К IOps, 2 хоста FC...Старенький. Ну что еще о нем сказать можно ? Сказать можно что-либо о сторадже, куда Вы его вставлять будете.
Вы лучше скажите, чего Вы собственно сделать хотите в итоге.

[gs]

Этот контроллер стоит в Чапараловских же системах RR1422-LVD-FS (SRF114/214) и, по всей видимости в Адаптек 7320.

Про корпус ничего не скажу - не знаю. А вот контроллер сам по себе очень неплох (для своего класса). Надежен как танк и в меру шустрый (15кИОпс - это два-три раза больше обычных PCI контроллеров, хотя и слабже самых новых LSI320-2X).

[SVV]

Ну делать то заказчик хочет двохузловой кластер под MS SQL. На текущем Infortrend 2500 и 7-ми дисках ST318406LC он имеет своих 2500 IOps, которые его не устраивают. Ему показали систему JFS224 с двумя контроллерами и с 11-тью дисками 10K IBM. Где он спог поднять 4000 IOps. Логично сообразив что дисков то у него мало я получил
- на старой системе 7 x 350 ~ 2500 IOps
- на старой системе 11 x 370 (они новее и чуть быстрее) ~ 4000 IOps
Ну и пояснил, что как бы дисками проблема решается, но все таки после этого выплыло, что ему таки нужна новая система, так как деньги то выделяют, и он этому естественно рад

[SVV]

Еще есть вот такой вопросик к практикам, так как с точки зрения теории я вроде его перевариваю .

Для 2-node MS Enterprise SQL кластера как лучше разбивать дисковую подсистему на сторедже. Лучше ли делать отдельные дисковые групы на все подряд: кворум, хзостовые зоны (а их тоже как бы можно отдель делать по частям - под логи, базу). Или делать одну группу - 1+0 масив. И его уже розбавать на логические диски, которые хосты будут видеть как диски. Несмотря на то, что с софтом мы вроде как не занимаемся (почти), но рекомендации пользователи просят.

Раньше в рекомендациях, например Оракл (у него к совместных ресурсам другой подход, но на даном уровне абстракции это может и не важно) говорилось - делайте ребята, столько-то (21-22 штуки ) шпинделей (дисков или их груп). А теперь ребята говорят, нет уж - не нужно, давайте нам 1+0 массив с максимальным кооличеством дисков для максимум IOps а там мы его уже оприходуем.

[gs]

Диски (при достаточном количестве!) имеет смысл разбить на две группы - зеркало под логи базы, рэйд10 под саму базу. Это чтобы при развале тома с базой можно было поднять ее из бэкапа и последние изменения по логам накатить. Кворум можно держать где угодно - он ничего не требует.
А группы уже резать как удобнее, правда рэйд10 не порежешь.

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

[SVV]

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

Угу, согласен насчет кеширования и самого Чапарала, он то пошустрей, хотя и старая зараза. Но думаю Инфортренд 2500-й больше выдаст на большем колличестве или более быстрых дисках. Хотя, что интерестно соотношение 2500 и 4000 IOps как-раз соответствует соотношения по возможностям контроллеров. У меня возникла мысль, что, так как эти IO которые меряет заказчик это быстрее всего не чистые IO (которые выдаёт контроллер та чтение/или на запись), ведь он меряет не промышленным тестом (например IO metter). То есть это может быть "попугаи" - комплексные операции, которые они эмулируют своей прогой, а соответственно может случиться что тест диски вообще не трогает, и это работа с кеш памятью - а результат соответственно характеризует производительность контроллера. Хотя IOps дисков, тоже прекрастно ложится на рассчёты производительности

[SVV]

Ребята, а что у вас есть из контролеров/сторедж систем для price sensitive клиента. Можно даже SCSI to SCSI, или если быстрых паралельных SCSI нет то FC.

[gs]

http://www.chaparralnet.com/prod/product.php?category=1

[gs]

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

Только ценники спросите - на сайте старые могут быть.

[SVV]

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

Вот только если посчитать максимальные возможности по IOps с каждого диска, получается что реальным тормозом являются именно диски, так как брать больше одной забитой полки (10 - 15 шт.) клиент вроде не собирается.
Хотя RIVA интерестная железка а RIO еще интерестней

[gs]

RIVA - очень интересная и очень мощная (100тыс. ИОпс или 600МБ/с на чтение, 250 на запись).
RIO по мощности практически не отличается, но у нее больше хостовых портов и на нее можно повесить ящики не только с FC дисками, но и SATA (причем микс). Она весьма дорогая (хотя смотря с чем сравнивать), но при объеме в десятки терабайт (сата) становится до смешного дешевой. К тому же к ней в данный момент находятся в разработке дополнительные внутренние модули, на которых будет крутиться полноценный софт виртуализации (FalconStor IPStor - он же Chaparral RAIDar PS).
Причем обе системы принципиально дублированные (имейте в виду при рассмотрении цены ).

[gs]

Кстати, не стоит недооценивать эффективность кэша. У одного клиента время отклика биллинговой базы уменьшилось чуть ли не в 1000 раз за счет того, что основные таблицы туда влезли (хотя сама база достаточно большая). Правда этот случай образцово-показательный, обычно такого конечно не бывает, но базе данных быстрый кэш еще никогда не мешал.

[SVV]

Кстати, не стоит недооценивать эффективность кэша. У одного клиента время отклика биллинговой базы уменьшилось чуть ли не в 1000 раз за счет того, что основные таблицы туда влезли (хотя сама база достаточно большая). Правда этот случай образцово-показательный, обычно такого конечно не бывает, но базе данных быстрый кэш еще никогда не мешал.

Хммм, я почему-то сомневаюсь, что можно управлять загрузкой данных в кеш у таких систем. Всё-таки системы начального уровня. А если так, то ожидать регулярности такого поведения сложно.

[gs]

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