LSI3108 CacheCade PRO 2.0

[Fan]

Добрый вечер, уважаемые гуру. Столкнулся с непоняткой. Приехал сервер SuperMicro SSG-6048R-E1CR36N. 2 SSD Intel Original SATA III 800Gb SSDSC2BX800G401 DC S3610 Series 2.5" в зеркало под систему на встроенном SATA-контроллере, 15 винтов HGST Enterprise HE10 HDD 3.5" SAS 10000Gb, 7200rpm, 256MB (HUH721010AL5204) в рэйд 10 с одним таким же в глобал хот спайр. Под CacheCade PRO 2.0 2 диска SSD 2.5'' HGST HUSMR1619ASS234 1.9Tb SAS 12Gb/s SSD1600MR. Включаю кэш - жуткие тормоза. База в 1 терабайт ресторится почти 2 часа. Убираю кэш - 30 минут. Это реальная работа, когда каждая минута стоит денег. Иопсы тоже пропадают. Где засада? Диск P4600 почему-то умер спустя неделю эксплуатации. Как организовать систему, исходя из реалий?
PS. Что, на взгляд гуру, предпочтительнее - 1 Intel® SSD DC P4600 4 Tb, или 4 SSD 2.5'' HGST HUSMR1619ASS234 1.9Tb SAS 12Gb/s SSD1600MR в десятом рэйде? Спасибо, уважаемые. )

[Graf]

Думаю ваш Cachecade не умеет работать с SSD - фирмваре не та.

4 диска быстрее ))

А что Тринити молчат?

[Umlyaut]

Думаю ваш Cachecade не умеет работать с SSD - фирмваре не та.

Вот тут поподробнее можно? Что значит - "не та фирмварь"?

Насколько я себе представляю, рейд-контроллер НЕ взаимодействует с фирмварью ssd напрямую.

[Graf]

Каждый тип LSI контроллера имеет свою прошивку. Так вот есть модели контроллеров умеющие работать с SSD и к сожелению есть модели, которые с SSD не работают - например или диски отваливаются или тормоза жуткие. Производитель он оптимизирует прошивку под такие диски. Кстати еще и не все диски SSD могут быть совместимы. Одни могут при наличии правильной фирмаре работать, а другие нет. В общем умет ли контроллер работать с SSD - это написано в доках, на сайте, в листе совместимости (если не найдете всегда можно в саппорте производителя запросить, ну или у поставщика.

[Umlyaut]

Под CacheCade PRO 2.0 2 диска SSD 2.5'' HGST HUSMR1619ASS234 1.9Tb SAS 12Gb/s SSD1600MR. Включаю кэш - жуткие тормоза. База в 1 терабайт ресторится почти 2 часа. Убираю кэш - 30 минут. Это реальная работа, когда каждая минута стоит денег. Иопсы тоже пропадают. Где засада?

У меня есть подозрение, что тут мы имеем дело с классическим "фризом" у ssd при массированных долговременных операциях записи.

Поскольку CacheCade2 в режиме записи объединяет два Ваших ssd кеша в зеркало, то скорость на запись у него как у одиночного ssd. И если отталкиваться от Ваших данных "объём / время" рестора, то данные льются на ssd CC с постоянной скоростью ~555MB/s - для непрерывной записи такого объёма это очень много, ssd в норме не может держать такой уровень i/o долго.

Ёмкости заводской WLA просто не хватает для того, чтобы BGC успевала превентивно очищать ячейки флеша перед записью, что приводит к тормозам из-за принудительной очистки непосредственно в момент записи.

При этом у нас нет возможности искусственно "растянуть" WLA, оставив неразмеченной часть объёма ssd - СacheСade использует весь объём автоматом.

Именно по этим причинам лично я стараюсь использовать СС исключительно в режиме кеширования чтения с HDD-Шных LUN`ов.
Бо запись на эти LUN`ы можно закешировать и без использования CC - на уровне приложения (например, in-memory DB), ОС (дисковый кеш), рейд-контроллера (бортовой RAM-кеш контроллера) и, в особых случаях, собственно носителя (встроенный кеш hdd/ssd, хоть это и не комильфо... кроме случаев наличия у последних конденсаторной поддержки).

Если же до зарезу хочется/нужно писАть данные именно на ssd, то делаю ssd-LUN с "недоразмеченным хвостом", чтобы иметь резерв чистого флеша при массированной записи до момента вступления в игру BGC - так сказать, размениваю объём на скорость.

В Вашем случае может показаться, что организовав СС на бОльшем к-ве ssd - от 4-х и выше - Вы получите бОльшую скорость записи, т.к. СС организует из них R10 и при постоянном WP=2 увеличение числа ssd даст прирост скорости записи.

Это не вполне так - да, ssd-кеш целиком будет способен принимать данные от контроллера с бОльшей скоростью, чем сейчас у Вас... но до тех пор, пока снова не упрётся в "наедание" флеша в полном объёме. Просто на бОльшей скорости "по интерфейсу" это произойдёт раньше по времени, но на том же объёме данных на запись (рестор БД) Вы получите в целом ту же задержку.

Да, можно сделать ssd-кеш СС не "под расчёт" - R10 из 4-х 1ТБ-ssd - а "с припуском", из 4-х 2ТБ-ssd - с расчётом на то, что примерно половина объёма ssd останется неиспользованной СС и естественным образом дополнит заводскую WLA.
Беда в том, что по моим воспоминаниям контроллеры LSI не давали сделать CC-группу ssd большего объёма, чем допускается спекой (максимальным объёмом кеша СС) - то есть в приведённом примере СС скорее должен разрешить СС-группу из пары 2ТБ-ssd на запись, объединив их в R1, а вот 4 таких ssd в R10 он дать не должен.

Можно, конечно, проверить, но вот прямо сейчас меня нет под руками ssd большой ёмкости в нужных кол-вах (хотя контроллеры с СС есть ).

Вот вкратце так...

[Umlyaut]

Каждый тип LSI контроллера имеет свою прошивку. Так вот есть модели контроллеров умеющие работать с SSD и к сожелению есть модели, которые с SSD не работают - например или диски отваливаются или тормоза жуткие.

Ну я скорее поверю в какие-то косяки матчасти (включая баги в проектировании). Особенно у ssd - их не пёк только ленивый, каждая собака нынче норовит выпустить ssd под своей маркой (а платить ОЕМерам за нормальную базовую модель хотят не все).
Это если не принимать в расчёт случаи, когда отвал или тормоза на совести корзин/бекплейнов и/или некошерных кабелей (такое сплошь и рядом).

В общем умет ли контроллер работать с SSD - это написано в доках, на сайте, в листе совместимости (если не найдете всегда можно в саппорте производителя запросить, ну или у поставщика.

Хех!

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

Отсутствие девайса в HCL отнюдь НЕ является признаком того, что рекомый непременно запорет работу при его использовании.

И, реагируя на Вашу фразу:

Думаю ваш Cachecade не умеет работать с SSD - фирмваре не та.

(полагаю, фирварь Вы имели в виду ssd-шную, а не контроллера)

повторюсь - фирмварь ssd недоступна для взаимодействия с нею со стороны рейд-контроллера.

То есть можно лишь говорить о том, что у некоторых ssd фирмварь настолько похабна, что со стороны рейд-контроллера сей ssd виден как, скажем, подыхающий hdd или что-то типа того... короче, сообразно поведению этого самого ssd.

[setar]

А что Тринити молчат?

когда есть что сказать по делу - говорим.

А вообще вы все некропостеры - посмотрите дату сообщения

[Graf]

Дата - датой. Человеку то - не ответили (
Да и эти контроллеры есть в продаже, вот прямо сейчас и проверил )

[Fan]

Спасибо за пояснения. Спец в этих вопросах неглубокий, теперь чуть продвинулся. От кэша отказался, развернул базы на Р4600, доволен. А SSD в резерв, машина боевая, и пусть они не потребуются. )

[noute]

Интересная засада с СУБД.
Была такая проблема 10 лет назад, отключали кэш всё летает (кэш причем был на Сасе ), включаем висит. Причём траблы были в работе СУБД было 2 инстанса которые начали работать с разной скоростью.
Точнее один инстанс очень сильно прогружали не оптимизированные селекты.
В другой пошли инсёрты.
Решили проблему радикально разделением инстансов, и миграцией СУБД на более быстрые диски.
Думаю объяснять не стоит про OLTP запись СУБД на диск и скорость вращения шпинделя который просто не успевает.
По проблеме 2 варианта.
1. Миграцию СУБД на более быстрые шпиндёли (может не помочь если там 2 инстанса и они на одном Lun-е на sas-е и тем более если сам кэш на sas-е. Скорость работы будет = самому медленному инстансу).
2. Смотреть в работу самой СУБД (точнее характер загрузки - что это инсерт или неоптимизированый селект).

[Umlyaut]

развернул базы на Р4600, доволен

Не страшно, на одиночном-то носителе без редундантности?

[Fan]

Страшновато, не скрою. Зеркало на постаревшем сервере поднято, прикрывает задницу.

[Dmitry]

Коллеги,
объявляем о снятии с выпуска софтовых ключей CacheCade и SafeStore (последний, по правде говоря, в России не востребован). Срок окончания поставок - 20.11.2018.
Альтернатива - такие же ключи, только "hardware".
Официальный документ - ниже.
Надеюсь, сильных потрясений не будет, функционал и цена "хардверных" ключей полностью аналогичны "софтовым".


EOL of Electronic MegaRAID Premium Feature Keys
Broadcom is announcing the EOL of the MegaRAID Advanced Software Licensing
Options. Broadcom will continue offering the HW based keys for supported HW. Since
the software portal allows instant activation of purchased keys the LTB and LTS will be
the same. The LTB/LTS for these keys will be in 90 days, or November 20 2018. The
table below shows the replacement product.

EOL MPN Replacement MPN
MR CACHECADE2 OCS L5-25199-04 MegaRAID CacheCade Pro 2.0 Software Pack w/ FastPath –
physical key for
9265/9266/9270/9271/9285/9286/9361/9380 SeriesMR SAFESTORE OCS L5-25188-01 MegaRAID SafeStore Software – physical key for
9265/9266/9270/9271/9285/9286/9361/9380 Series

MR FASTPATH OCS No Replacement This feature is included in all current MR products

[Umlyaut]

Dmitry, похоже, Бродкому надоело поддерживать инфраструктурку софтовых ключей.

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

В приципе, физ.ключи были неудобны только тем, что позволяли "подключить" к контроллеру лишь одну фичу - бо разъём для этих ключей там один-одинёшенек.
Тогда приходилось выбирать между, скажем, FastPath и CacheCad (первый одно время был платной опцией, как Вы помните).

[WalterWanny]

Я конечно, прошу прощения, но это мне не совсем подходит. Может, есть ещё варианты?