ssd cache

[heroin]

Добрый день.
Есть два сервера под 1С
На 1м стоит контроллер Adaptec 5805 под базу 10й рэйд из 6ти SAS дисков.
На 2м стоит контроллер LSI MegaRid SAS 9260cv-4i под базу 10й рэйд из 4х SAS дисков.
По остальным характеристикам сервера практически идентичные.
Есть основная рабочая база в которой одновременно работает порядка 80-90 человек. На данный момент база крутится на 1м сервере. Хотелось бы ускорить работу дисковой подсистемы.
Для ускорения дисковой подсистемы вижу переход на диски SSD.
Размер базы около 350 Гб.
Какой из вариантов более правильный и даст больший прирост производительности на чтение/запись, а так же сохранить отказоустойчивость ?
Купить в 1й сервер два ssd Intel SSDSC2BX400G401 по 400Гб собрать их в зеркало и перенести на них базу
или
на 2м сервере купить и активировать технологию от LSI CacheCade Pro 2.0, докупить два ssd Intel SSDSC2BX200G401 по 200Гб, собрать из них зеркало и использовать под ssd кэш и перенести базу на него на raid10 из 4х sas дисков ?

P.S. Каким образом ssd диски 2.5" вставлять в салазки 3.5" сервера ? Платформа Intel Server System SR2612URR

Заранее благодарю за ответы.

[Stranger03]

На 1м стоит контроллер Adaptec 5805 под базу 10й рэйд из 6ти SAS дисков.
На 2м стоит контроллер LSI MegaRid SAS 9260cv-4i под базу 10й рэйд из 4х SAS дисков.

Контроллеры старенькие, совместимых дисков SSD скорей всего не найдете. Посмотрите HLC. Я бы вместо 6-ти или 4-х дисков поставил пару - тройку SSD

P.S. Каким образом ssd диски 2.5" вставлять в салазки 3.5" сервера ? Платформа Intel Server System SR2612URR

Есть переходники, поищите 2.5" to 3.3" HDD convert

[heroin]

Посмотрел HLC для LSI MegaRid SAS 9260cv-4i

есть в доступности совместимые из списка по не заоблачным ценам
Intel SSDSC2BA100G301 - 100Гб
Intel SSDSC2BA200G401 - 200Гб

Я правильно понимаю, из ваших слов, что хранение полностью базы на зеркале из двух ssd более производительней и отказоустойчивей, чем 10й raid на sas + ssd кэш из зеркала ?
Как тогда правильно сделать 2 ssd в зеркало и 1 ssd в hot swap ?

[gs]

Чисто ССДшное зеркало будет быстрее. И, самое главное, производительность будет стабильна (кэширующие системы работают не особо предсказуемо).
С надежностью у интеловских ССДшек дела обстоят намного лучше, чем у ХДД.
Серия 37хх для Вашей задачи будет перебором - за глаза хватит и 3610. Но вот насчет совместимости - бес его знает, контроллеры больно старые. Впрочем, интел практически везде работает. Ну и в конце концов ССДшки можно повесить на бортовую интеграшку с софтовым зеркалом (если кузов позволяет).

[Umlyaut]

Чисто ССДшное зеркало будет быстрее. И, самое главное, производительность будет стабильна (кэширующие системы работают не особо предсказуемо).

А можно чуть больше подробностей насчёт "(не)предсказуемости"??? Ну не для красного же словца Вы упомянули эту "мантру" на техническом форуме?

Просто в рамках своей "области определения" именно кеширование силами CacheCade работает весьма и весьма, как по мне. Говорю, опираясь на несколько лет (порядка 5-ти) опыта использования CC в продакшене.

[gs]

Кэш работает шустро, если данные в него помещаются и часто запрашиваются. Если потребовалось что-то редко адресуемое, то будет привет. В контексте 1С это могут быть данные старых периодов, например.
Ну и в теоретическом плане, кэш напрягает невеликий интеллект контроллера - а он старый и дохлый. Он будет бегать гораздо шустрее и с меньшими задержками, если будет тупо гонять данные с/на ССД без раздумий. Правда в данном случае наверно мощи и так хватит.
Поскольку у автора данные легко влезают на ССД без всяких выкрутасов, то ему оно нафиг не нужно. А по деньгам вполне себе сравнимо.
И вообще, я предпочитаю не умножать сущностей без необходимости.

[Umlyaut]

И вообще, я предпочитаю не умножать сущностей без необходимости.

Более чем соглашусь. Но иногда просто нужно "делать шаг".

Кэш работает шустро, если данные в него помещаются и часто запрашиваются. Если потребовалось что-то редко адресуемое, то будет привет. В контексте 1С это могут быть данные старых периодов, например.

Соглашусь с оговорками.

Во-первых, надо смотреть организацию данных. Если БД (не обязательно 1С) бывает регулярно "обращаема", то может получиться так, что её файл(ы) перечитываются системой "оптом", а выборка конкретных агрегатов осуществляется "выше", на уровне приложения. Т.е. с т.з. контроллера надо прокешить все страницы БД.

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

Я уж не говорю о том, что "данные старых периодов" не грех и "подождать" (пока они прочитаются с HHD) - априори актуальность и срочность этой операции не такая, как ежедневное OLTP-ворочание данными текущими: так что даже если и закрыть глаза на резоны двух предыдущих абзацев, то всё равно насущность (не)кеширования "старых данных" не бог весть какая.

Ну и в теоретическом плане, кэш напрягает невеликий интеллект контроллера - а он старый и дохлый. Он будет бегать гораздо шустрее и с меньшими задержками, если будет тупо гонять данные с/на ССД без раздумий. Правда в данном случае наверно мощи и так хватит.

Ну да, почти так.
Лично я думаю, что дури 92xx/93xx контроллеров (LSI), на которых я гоняю CC, более чем достаточно.
Там же голимая "табличная статистика" - для проверки "hit or miss" по "плоской" таблице, лежащей в RAM контроллера, космические мощности не нужны.

Поскольку у автора данные легко влезают на ССД без всяких выкрутасов, то ему оно нафиг не нужно. А по деньгам вполне себе сравнимо.

У меня тоже есть "ssd-only" LUN`ы на рейд-контроллерах и софт-рейдах - когда, как Вы справедливо заметили, "всё влезает".

А CC у мну используется на хомякохранилище (Home directories store) и LUN`ах аналогичной направленности - там, где надо быстро читать выборку по большим объёмам данных.
Закешировать-то запись проще - приложением, ОС, рейд-контроллером - а вот для чтения СС будет, пожалуй. самым доступным и безгеморройным способом закешировать его. Ну и плюс разрыв между стоимостью гига хранения между HDD И SSD.

Как-то так...

[sivanov]

Как я не эксперементировал с аппаратными или программными реализациями кэширования на SSD, у меня они все вызвали разочарование.
Для хостинга БД или виртуалок нет ничего лучше SSD, за этим следуют гибридные массивы из SSD+HDD, в тех случаях, когда можно указать с какой половины зеркала осуществлять чтение.
RAID0 на дешевых SATA SSD имеют проблемы с масштабируемостью из-за непредсказуемых задержек на запись, когда один, из, например 20 SSD тупит и тормозит запись всего страйпа.
Лушие переходники с 2.5 на 3.5 это WD Icepack, те самые алюминиевые башмаки, которыми комплектовались WD Velociraptor, они абсолютно точно копируют габариты и резьбовые отверстия 3.5 HDD.

[Umlyaut]

Как я не эксперементировал с аппаратными или программными реализациями кэширования на SSD, у меня они все вызвали разочарование.

Как я обычно говорю - "или вы делаете что-то не так, или вы это делаете первый раз".
Без обид, это шутка - на самом же деле у Вас может бытьпросто другой, как это принято говорить, кейс.

Например. Вы могли использовать СС v2 - на чтение и на запись, а это совсем не то же самое, что СС в режиме R/O. Там несколько другое поведение контроллера (кэш пополамится между R и W), плюс извечная засада со скоростью записи на 100%-заполненный ssd кеша (там нельзя отдать под это дело часть, искусственно увеличив тем самым WLA сверх заводского "запаса").

Повторял, повторю и буду повторять - закешировать запись не проблема, вот кеширование чтения - проблема. И СС с ней справляется отменно, как по мне.
Ещё на стенде. когда я решал вопрос о необходимости применения СС, я лично убедился в том, что СС на LUN`е с 2k IOPS рэндомного чтения (по IOmeter) даёт не менее 20k IOPS - т.е. на порядок.
Последующая эксплуатация БД на этом LUN`e показала справедливость подобной оценки.

Для хостинга БД или виртуалок нет ничего лучше SSD, за этим следуют гибридные массивы из SSD+HDD, в тех случаях, когда можно указать с какой половины зеркала осуществлять чтение.

Это Вы про адаптековские "гибриды" (LSI этим не балуется)? Так тут ещё вопрос с (а)синхронностью записи на такой "бутерброд". Если ssd вынужден ждать, пока hdd запишет свою копию - это не гуд.
И вообще, вот это Ваше "указать, с какой половины зеркала читать" подразумевает, что Вы хотите читать с ssd. Но тогда это ничем не отличается от СС или MaxIO, только без наворотов с "зеркалированием" друг на друга быстрого и медленного носителей.

RAID0 на дешевых SATA SSD имеют проблемы с масштабируемостью из-за непредсказуемых задержек на запись, когда один, из, например 20 SSD тупит и тормозит запись всего страйпа.

За RAID0 на боевых базах нужно показательно пороть (конечно, если это не R/O справочная база какая - да и тогда выгоднее бухнуть её на рамдрайв, чтоб совсем быстро было).
А "тупящий" SSD отлавливается по логам контроллера и заменяется.
Ну и оттопыривать до 20% (больше, по заслуживающим доверия данным, не нужно - эффект уже не соразмерный) объёма принудительно в пользу увеличения WLA - крепко снижает "фризы" на запись.

Этого:

Лушие переходники с 2.5 на 3.5 это WD Icepack, те самые алюминиевые башмаки, которыми комплектовались WD Velociraptor, они абсолютно точно копируют габариты и резьбовые отверстия 3.5 HDD.

вообще не понял. При чём тут ssd-кеширование?

[Stranger03]

За RAID0 на боевых базах нужно показательно пороть

Для временных файлов, TEMP, вполне можно использовать. Если только не нужна работа 24х7 с временем восстановления в несколько минут.

Лушие переходники с 2.5 на 3.5 это WD Icepack, те самые алюминиевые башмаки, которыми комплектовались WD Velociraptor, они абсолютно точно копируют габариты и резьбовые отверстия 3.5 HDD.

вообще не понял. При чём тут ssd-кеширование?

Был вопрос про переходники, коллега sivanov ответил. Кеш тут не при чем.

[Umlyaut]

За RAID0 на боевых базах нужно показательно пороть

Для временных файлов, TEMP, вполне можно использовать. Если только не нужна работа 24х7 с временем восстановления в несколько минут.

В принципе согласен: просто изначально контекст кружился вокруг ssd-кеширования LUN`ов из HDD, а тут бац! - и прыжок в сторону.
Собственно, для TEMP/TMP, других всякообразных временных файлов (например, у меня на Firebird`e сортировки в памяти, вылезающие за пороговое значение и вынужденные осуществляться в виде temp-файлов), как раз весьма выгодно складывать на рамдрайв - любой R0 на ssd курит в сторонке.
Да, нужен некий запас по RAM, но при отработке "тяжёлых" сервисов воленс-ноленс приходится при сайзинге системы закладывать "ефрейторский зазор", в котором несколько гигов "лишней" RAM для рамдрайва вообще ни о чём.

Лушие переходники с 2.5 на 3.5 это WD Icepack, те самые алюминиевые башмаки, которыми комплектовались WD Velociraptor, они абсолютно точно копируют габариты и резьбовые отверстия 3.5 HDD.

вообще не понял. При чём тут ssd-кеширование?

Был вопрос про переходники, коллега sivanov ответил. Кеш тут не при чем.

А-ааа! Так он ответил мне на чужой вопрос? Понятно. с цитированием промахнулся, бывает.

[sivanov]

За RAID0 на боевых базах нужно показательно пороть (конечно, если это не R/O справочная база какая - да и тогда выгоднее бухнуть её на рамдрайв, чтоб совсем быстро было).
А "тупящий" SSD отлавливается по логам контроллера и заменяется.
Ну и оттопыривать до 20% (больше, по заслуживающим доверия данным, не нужно - эффект уже не соразмерный) объёма принудительно в пользу увеличения WLA - крепко снижает "фризы" на запись.

RAID0 на SSD меня интересовал в качестве одной из половин **софтового** гибридного массива для хранения образов виртуалок и физических серверов для простого и VDI хостинга, для увеличения IOPS на чтение, а "медленная" половина на RAID6/7 или raidz2/3, вероятно, с кэшированием записи. Уж очень привлекательна идея использования только половины из потребных для RAID10 SSD (тем более БУ SSD за $.25/gb) для дешевого коммерческого хостинга <happy-merchant.jpg> .