Форум Трініті - перегляд теми - зробити кеш з ssd дисків

Добрий день, прошу знову допомогти.
Завдання як я писав раніше: зробити кеш з ssd дисків. + Дзеркальний RAID
Є сервер Intel® Server System SR2625URLXR з RAID контролером LSI 1078-based SAS RAID Controllers
4 диска SAS 2діска sata і 2 ssd диска


1. Гідна звірятко (і вже всяко краще, ніж древній 1 078)
3. Однозначно "так" - LSI поки не настільки альтруїст, щоб дарувати цю фічу by default (як він це недавно зробив з FastPath), так що готуйте приблизно плюс пару сотень зелених.
2. "об'ємні" в якому сенсі - на багато гігазов потоком (а-ля бикапніца / файлопомойка) або на багато IOPS (а-ля OLTP / mailserver).

Ну і непогано було б позначити необхідну ємність "зараз / потім" - щоб хоча б начорно прикинути к-ть шпинделів і конфігурації (хоча з урахуванням витрачання портів на ssd і хоч один HSD без експандера особливо не розженешся - або R10, або R6).

Про аварійне живлення кеша (то, що називають BBU або CV) вже і не заїкаюся - без нього як без штанів на балу: можна, але непристойно.

Добрий день, прошу знову допомогти.
Завдання як я писав раніше: зробити кеш з ssd дисків. + Дзеркальний RAID
Є сервер Intel® Server System SR2625URLXR з RAID контролером LSI 1078-based SAS RAID Controllers
4 диска SAS 2діска sata і 2 ssd диска


1. Гідна звірятко (і вже всяко краще, ніж древній 1 078)
3. Однозначно "так" - LSI поки не настільки альтруїст, щоб дарувати цю фічу by default (як він це недавно зробив з FastPath), так що готуйте приблизно плюс пару сотень зелених.
2. "об'ємні" в якому сенсі - на багато гігазов потоком (а-ля бикапніца / файлопомойка) або на багато IOPS (а-ля OLTP / mailserver).

Ну і непогано було б позначити необхідну ємність "зараз / потім" - щоб хоча б начорно прикинути к-ть шпинделів і конфігурації (хоча з урахуванням витрачання портів на ssd і хоч один HSD без експандера особливо не розженешся - або R10, або R6).

Про аварійне живлення кеша (то, що називають BBU або CV) вже і не заїкаюся - без нього як без штанів на балу: можна, але непристойно.

Дякую за відповідь, як я зрозумів з вашої відповіді вона підійде, сервер робиться для якоїсь СУБД яка в свою чергу, при конвертації вантажить RAID на 100% і хочеться хоч якось прискорити процес, диски вже є: 4 диска SAS 2діска sata і 2 ssd диска, ці 2 SSD і хотілося б використовувати під КЕШ

Дякую за відповідь, як я зрозумів з вашої відповіді вона підійде, сервер робиться для якоїсь СУБД яка в свою чергу, при конвертації вантажить RAID на 100% і хочеться хоч якось прискорити процес, диски вже є: 4 диска SAS 2діска sata і 2 ssd диска, ці 2 SSD і хотілося б використовувати під КЕШ


Товариш, я не хочу "вчити Вас життя", але все ж порекомендую з більшим старанням ставитися до визначень ( "розуміння - функція термінології" (с) моє). "Вантажить RAID на 100%" - це як? Bottleneck по шині / пам'яті контролера? Або вперлися в межі трансферу носіїв?

Взагалі мені не дуже подобається Ваша затія кроїти дискову підсистему під наявні залізяки, а не під задачу. А вже брати новий сучасний високопродуктивний контролер і обважувати його буквально "зоопарком" різнопланових носіїв (SAS / SATA HDD + SSD) взагалі в розум не вміщається.

Ось тільки що ув. gs справедливо зазначив, що якщо БД влазить на SSD (у Вашому випадку це буде R1 на них), то туди їй і дорога (до слова, питання щодо необхідних обсягів Ви так і не висвітлили, а адже це важливо). Але навіть якщо й ні, то є варіант добити ще парою таких же SSD і замутити R10 / R6 (автоматом збільшивши обсяг томи).

І Ваш "зоопарк" з хард в цьому кейсі теж кілька напружує - я так і бачу ДВІ роздільних рейд-групи, як це люблять робити по інерції дуже багато: R1 на SATA "під систему" і Rx на SAS під дані. Але ж уже давно окреме дзеркало "під систему" - моветон (крадуться IOPSи і обсяг у LUN для даних): зробіть єдину рейд-групу з 6 HDD SAS, відріжте контролером або OS спочатку її окремий LUN під систему - так буде правильніше.

Взагалі ж ще непогано було б розуміти профіль навантаження (рейт між W і R, плюс обсяг даних по ним же) - якщо вийде так, що кеша в 1GB вистачить для згладжування бурстов на запис, а рейд-групи з 6 SAS буде досить по IOPS , то можна не класти БД на SSD, а дійсно замутити CacheCade в r / o, бо читання закеширувати набагато складніше, ніж запис.

От якось так. Без образ, ОК?

Дякую за відповідь, як я зрозумів з вашої відповіді вона підійде, сервер робиться для якоїсь СУБД яка в свою чергу, при конвертації вантажить RAID на 100% і хочеться хоч якось прискорити процес, диски вже є: 4 диска SAS 2діска sata і 2 ssd диска, ці 2 SSD і хотілося б використовувати під КЕШ


Товариш, я не хочу "вчити Вас життя", але все ж порекомендую з більшим старанням ставитися до визначень ( "розуміння - функція термінології" (с) моє). "Вантажить RAID на 100%" - це як? Bottleneck по шині / пам'яті контролера? Або вперлися в межі трансферу носіїв?

Взагалі мені не дуже подобається Ваша затія кроїти дискову підсистему під наявні залізяки, а не під задачу. А вже брати новий сучасний високопродуктивний контролер і обважувати його буквально "зоопарком" різнопланових носіїв (SAS / SATA HDD + SSD) взагалі в розум не вміщається.

Ось тільки що ув. gs справедливо зазначив, що якщо БД влазить на SSD (у Вашому випадку це буде R1 на них), то туди їй і дорога (до слова, питання щодо необхідних обсягів Ви так і не висвітлили, а адже це важливо). Але навіть якщо й ні, то є варіант добити ще парою таких же SSD і замутити R10 / R6 (автоматом збільшивши обсяг томи).

І Ваш "зоопарк" з хард в цьому кейсі теж кілька напружує - я так і бачу ДВІ роздільних рейд-групи, як це люблять робити по інерції дуже багато: R1 на SATA "під систему" і Rx на SAS під дані. Але ж уже давно окреме дзеркало "під систему" - моветон (крадуться IOPSи і обсяг у LUN для даних): зробіть єдину рейд-групу з 6 HDD SAS, відріжте контролером або OS спочатку її окремий LUN під систему - так буде правильніше.

Взагалі ж ще непогано було б розуміти профіль навантаження (рейт між W і R, плюс обсяг даних по ним же) - якщо вийде так, що кеша в 1GB вистачить для згладжування бурстов на запис, а рейд-групи з 6 SAS буде досить по IOPS , то можна не класти БД на SSD, а дійсно замутити CacheCade в r / o, бо читання закеширувати набагато складніше, ніж запис.

От якось так. Без образ, ОК?

Дивіться ситуація зараз така, база важить 1,15Tb, Windows стоїть на RAID масиві з 2-ух ssd дисків, а сама база висить на окремому RAID масиві зліпленому з 4 дисків SAS

При конвертації бази, диск використовується на 100%, не вистачає швидкості для Read / Write тому завдання тільки якимось чином прискорити роботу дисків, я не спец в цьому, тому запитав ради, як краще поступити

Схожі статті