Вопрос по использованию CasheCade 2Pro на LSI 9266

[icetest]

Купили сервер на шасси supermicro SC-846 с экспандером, контроллер LSI 9266-8i с купленной опцией CasheCade 2.
Есть 4 SSD Intel 3700 по 200 Гб, при создании группы дисков для CacheCade задаю Raid 0 (кэш нужен только на чтение), и выбираю эти 4 SSD.
Софт выдаёт предупреждение о том что максимум кэш 512 Гб и превышаемая ёмкость не будет использоваться (это я знал и готов был использовать 512 из 800 Гб) и создаёт группу дисков (4 диска) для CacheCade. При тестировании видно, что один из SSD просто не производит никаких операций, то есть получается, что используются 3 первых диска (ёмкость ~600Гб) и ввиду превышения над 512 Гб, 4 диск вообще не используется.
Вопрос такой - можно ли заставить его использовать все 4 диска но по 128 Гб на каждом (в целях продления ресурса и повышения скорости)?

[gs]

Честно говоря не задумывался над таким вариантом.
Теоретически, может дискам просто объем зарезать предварительно (HPA)?

Но вообще-то я сомневаюсь в целесообразности затеи. Рид перфоманс 4к блоками у этих ССД - 75к иопс. Три диска - больше 200к иопс - контроллер поперхнется...

[icetest]

Тут даже не производительность интересна, а объём - 512 против 375 Гб (У виртуалки под ESXi iometer уже 85к IOPS не может превысить).
Я если честно сам удивился, думал он просто будет 128 Гб с каждого диска брать и всё, в мануалах этот вопрос вообще не освещён никак.
Поскольку там создаётся не логический диск, а виртуальный диск, то размер ограничить нельзя, как при создании обычных томов?
А ёмкость урезать - вроде особо смысла действительно нет.

[gs]

Разве нельзя использовать три ССД?

[Umlyaut]

При тестировании видно, что один из SSD просто не производит никаких операций, то есть получается, что используются 3 первых диска (ёмкость ~600Гб)

А каким образом Вы увидели отсутствие операций на этом диске? И что будет, если убрать один из "тех трёх" и поставить взамен него тот, на котором "нет операций". Дурацкая идея - может, он изначально "того", не жилец?

Я Вас понимаю - сам использую CacheCade (v1 - ReadOnly), пока на 3-х 64-ках, но хочу расшириться на весь допустимый объём кеша... кстати надысь общался с русским LSI на тему "когда LSI догонит адаптека по размеру SSD-кеша?" - в общем, камингсун, но когда - хз...

Насчёт мнения ув.gs что контроллер захлебнётся IOPSами... так-то оно так, однако LSI врёт в Q&A, что применение FastPath якобы увеличивает IO до 465 kIOPS (http://www.lsi.com/downloads/Public/Meg ... _Final.pdf).

Поскольку они кричат, что FP суть есть оптимизация работы с носителями (типа контроллер не будет пытаться учитывать геометрию HDD, поскольку в SSD таковой геометрии не просматривается ), то, по логике вещей получается, что запас по IO у контроллера должен быть - FP же не "растягивает" bandwidth контроллера...

В принципе я, наверно, смогу себе позволить при расширении SSD-кеша на своём 9265-8i потестировать несколько вариантов (с SSDшками объёмом 60GB можно устроить перебор от 1 до 8 носителей) - тогда смогу сказать определённее...

[icetest]

В общем, в корзине есть индикация активности на каждый диск и всё видно (3 из 4х активность показывают, 4-й только присутствие питания показывает).
Разве нельзя использовать три ССД? - но ведь есть четыре (их же уже купили).
Потестил - при использовании CacheCade в сервере (в моей конфигурации) виртуальная машина не может преодолеть порог в 81к IOPS что с 2-мя, что с 3-мя дисками, что с 4-мя в 10 рэйде.

[Umlyaut]

Потестил - при использовании CacheCade в сервере (в моей конфигурации) виртуальная машина не может преодолеть порог в 81к IOPS что с 2-мя, что с 3-мя дисками, что с 4-мя в 10 рэйде.

Ну я буду тестить не из виртуалки, а на "физике" - хочу отловить плато...
А "порог 81 kIOPS" - на чтение? Seq или Rand? И как мерили?
И эт-то... 10-й то рейд зачем на ReadOnly - Вы, вроде, в стартовом посте говорили про R-0 ???

[icetest]

Физически - LUN на R10 из 18 сас 7200об, к которому разрешается кэширование на чтение.

Мерил при помощи iometer в windows 2008r2, запущенном в среде ESXi 5.1, контроллер диска у ВМ - паравиртуальный , 8 vCPU, паттерн - чтение 100%, блоки 4кБ, 100% произвольное, имитируются 8 работников, каждый создаёт 8 потоков дисковых операций (надо, чтобы не упёрлось в один поток на процессоре - иначе 60к и 100% загрузка одного ядра процессора). У ВМ диск дополнительный на 40Гб, на котором тест и проводится, при этом параметр IOPS растёт, за счёт попадания данных в кэш в течении нескольких минут с 4к до 81к, на корзине сервера при этом видно, что активность HDD постепенно падает до нуля (к моменту когда всё берётся из кэша).

10 рэйд создавал, дабы проверить функционирование всех SSD (объём при этом 375 Гб).

81к операций - не ограничено паравиртуальным контроллером, LUN на рэйд 1 из 2х ссд (просто LUN, не кэш) даёт на нём около 120к на таком же типе доступа.

По поводу FastPatch - параметры у LSI приведены наверно не для кэша, а для LUN на SSD, при работе как кэш возможны некоторые дополнительные задержки на определение каких-либо параметров, например лежат ли данные в кэше, что может вызвать существенное падение скорости от теоретического максимума.

[Umlyaut]

По поводу FastPatch - параметры у LSI приведены наверно не для кэша, а для LUN на SSD, при работе как кэш возможны некоторые дополнительные задержки на определение каких-либо параметров, например лежат ли данные в кэше, что может вызвать существенное падение скорости от теоретического максимума.

А без разницы. Просто ув.gs ссылался на пар-р 200 kIOPS как на предельную производительность контроллера - вот я и рассудил, что если применение опции FastPath (ага, для LUN на SSD) даёт 465 kIOPS, то говорить о том, что 200 kIOPS есть предел производительности контроллера, в общем-то странно...

Эх, блин, не проверил я другой массив (9260CV + 8 SSD w/FastPath) на производительность с FP И без него - нужно было срочно запускать сервак...

По поводу пресловутых "доп.задержек" на проверку попадания в SSD-кэш я дискутировать не готов, бо не в курсе тамошних алгоритмов. Мне, видимо, будет проще проверить (как я писАл выше)...