Сервер DELL, выбор дисковой подсистемы

[Andrey]

В общем, есть задачка - собрать сервер.
На сервере будет стоять Windows и MSSQL (это без вариантов).
Основная задача сервака - максимально быстрая работа SQL.
Предварительная конфигурация дисковой подсистемы:
- плата BOSS с 2х240Gb SSD под ОС
- контроллер PERC H740p (8Gb Cache) под основную корзинку

А вот дальше "мысли разбегаются" как лучше выстроить дисковую систему. SQL-хранилище представляет собой на данный момент "основную" базу около 150Gb (без логов) и пару десятков "прочих баз" общим объёмом около 500Gb (без логов). Плюс надо иметь запас места под файлопомойку, привязанную к базе (в силу особенностей работы софта - вынести эту помойку в сеть не получится, видимо). Плюс надо иметь запас места под оперативные бэкапы и прочую хрень (в данный момент база дифбэкапом снимается каждые 20 минут + intraday ротация + снятие ночных копий со всей помойки + иногда разрабам стреляет развернуть 2 или даже 3 копии основной базы "для опытов").

В первом приближении видятся возможные варианты:
2х480Gb SSD SAS 12Gbps в RAID1 + 4х1.8Tb 10k SAS 12Gbps в RAID10 - соотв 480Gb SSD под основную базу (вместе с логами?) + 3.6Tb SAS HDD под всё остальное (или логи сюда лучше унести?)
4х400Gb SSD SATA 6Gbps в RAID10 + 4х1.8Tb 10k SAS 12Gbps в RAID10 - аналогично предыдущему пункту
вообще плюнуть на SSD и
8х600Gb 15k SAS 12Gbps в 2хRAID10 + 4х1.8Tb 10k SAS 12Gbps в RAID10 - соотв первые 2 массива - под основную базу и её логи (разделить от логов - по цене получается сопоставимо с вариантов SSD) + второй массив-помойка.

Вопрос - в какой конфигурации дисковой подсистемы SQL будет шевелиться наиболее резво?
Или лучше смотреть вообще в сторону конфигурации RAID5/50 на SAS HDD? Или наоборот двигать в сторону NVMe и SoftRAID1?

База по профилю нагрузки считай как 1С-ная (не вникая в тонкости - тесты показывают, что почти как в 1С соотношение read/write).

У кого есть реальный опыт?

[Andrey]

Мда... Море ответов.

[axel]

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

[Andrey]

Мда... "Не читал, но осуждаю".

Есть ЧЁТКО означенная ОДНА функциональность сервера:
"На сервере будет стоять Windows и MSSQL (это без вариантов).
Основная задача сервака - максимально быстрая работа SQL."

То, что есть желание ещё иметь некоторые функционалы - это пусть как-нидь работает. Главное, чтоб основная задача была решена.

Память - видимо, в итоге будет 128Gb. Если совсем начнут бюджеты резать - 96Gb.

Логи в память - отказать. По массе причин. Несмотря на защиту по питанию в 2 уровня.

[Tos]

Не поставить ли на сервер VMWare и нарезать внутри неё виртуальные хосты под специфичные задачи?

[McLane]

именно.
под фалопомойку отдельный райд и обычных hdd серверных ( хошь зеркало, хошь 10-ку)
под систему нет смысла городить райд из ssd - практика показывает убыстрения нет, даже медленнее. лучше под систему ssd optran + одну тупо в резерв поставить. кэш скуля вынести на отдельный ssd.
строить лучше виртуалками с прамым пробросом дисков. но тестовый и файлопомойку в отдельных вируталках.
ЗЫ если есть деньги - пару серваков и хранилка от хуюлета :-) ( можно и трипар если бюджет тянет)

[Tos]

в общем да, макароны вилкой, а суп ложкой.
Можно будет еще поиграться переиспользованием ресурсов процессоров и памяти.

[Demige]

raid из ссд делают не для скорости а для зеркала.

[Tos]

ну почему же? для десктопных компов может и не имеет, но у серверов с большой глубиной очереди чтения/записи Raid 0 SSD имеет большой смысл.

[McLane]

это да, но % отказа серверных ssd настолько мал, что в большинстве случаев для "малых" серверов проще воткнуть новый ssd и накатить туда образ хостовой машины, т.к. помирает он не сразу и замену можно спрогнозировать и спланировать. а прирост скорости от raid ssd чаще всего отрицательный :-) ( это ессно не касается "хранилок" там другая история :-) )
ЗЫ ну и если он внезапно упадет - то развернуть образ хоста - несколько минут

[Andrey]

Эх... Ещё один теоретик...
Файлопомойка - вторичная задача. Да, там много файликов, но файлы все очень маленькие (до 1мб) и реально их читается около 1000-2000 раз в сутки почти равномерным распределением. В рамках производительности дисковой системы в любом варианте - вообще "ни о чём" влияние. Вот ваще никак.

Вынос ОС на BOSS-кард имеет только одну цель - "высадить системный обмен на отдельный канал(ы) PCI-E". Всё. Альтернатива - городить второй PERC - это сильно дороже и особо плюшек не даёт.

Виртуалки с пробросом дисков. Гениально, бро.
Расскажи как "распилить по виртуалкам" написанное выше. И на кой ляд вообще это делать. Никто даже не удосужился прочитать, что файлопомойка "привязана к базе" (должна лежать на той же машине, что и SQL ввиду особенностей работы софта).

Мой вопрос был - какой из предложенных вариантов "нашинковки дисков" даст наибольшую реальную производительность при работе именно с SQL-сервер? Или даже не так - какой оптимален по всему спектру параметров от цены до надёжности?
SSD/HDD прямо не влияют уже некоторое время. SSD (особенно NVMe) радикально отличается на базовой десктопной логике, ибо за относительно небольшие деньги вгоняет скорость дисковой системы на один порядок со скоростью PCI-E.

В случае серверных конфигураций всё становится очень не очевидно. Ибо 4-5 дисковый RAID5 SAS 12G уже близки к теоретическому пределу, а 6-дисковому SAS даже можно "не очень напрягать диски", ибо ломовая производительность дисковой системы упирается по ширине канала уже не в диски и их интерфейсы, а в "ширину" PCI-E.

Да, можно натыкать серверные NVMe, но, во-первых - это пинцет как дорого, во-вторых, ты убираешь всё кэширование между RAM и диском, в-третьих, только SoftRAID10 в пределе (с адово лютой ценой для достижения того же объёма). При этом на типичных для SQL операциях на накопительных базах (частые не совсем мелкие выборки условно-последних данных, не упихивающиеся в рамках RAM) из-за накладных расходов на CPU и main-RAM (ибо SoftRAID) "ломовая" скорость работы SQL легко может оказаться даже хуже, чем при работе с синтетически более медленным HardRAID с "тормозными" относительно NVMe дисками.

Различных синтетических тестов в инетах как говна за баней. Я хотел узнать - есть ли у кого опыт сборки сервачка именно под MSSQL и ставили ли опыты с разными вариантами массив в рамках предпродакшн опытов с железюкой...

[McLane]

опыт он разный )) ты ж написал

База по профилю нагрузки считай как 1С-ная

отсюда и советы. но и 1С бывает сильно разная ))

[Andrey]

Блин... Ещё раз: на сервере должен шустро летать SQL. Это ОДНА ОСНОВНАЯ задача. Остальные "как получится".
Расскажи мне - как вынесение бэкапов и файлопомойки хоть каким-то местом изменит скорость работы SQL, особенно в ситуациях интенсивных дисковых нагрузок. Только с объяснением - где что будет жраться - память, проц, шины и т.д.

[Tos]

Непонятно чего ты хочешь.
Загрузив сервер непонятными файлопомойками и бэкапами трудно говорить об производительности системы в целом на одном железе, где распределение ресурсов будет на уровне одной только ОС и прикладных ПО и сервисов.
У тебя шикарный raid контроллер, с ROC, зачем тогда заводить речь о softraid1?
Хочешь производительности MSSQL -
1 диск под ОС, в принципе любой.
1 ядро процессора под ОС, остальные под SQL
Раздели массивы на raid:
1. массив под DB
2. массив под журналы
3. массив под tempDB
4. массив под бэкап (сюда же можно фалопомойку)

Можно объединить 3+4
Разделив таким образом потоки я бы брал SAS диски, SSD не даст роста производительности, а серверные Optane дюже дорогие.

[rsx]

Дяденьки, а можно я просто молча восхищусь?

[hak]

SSD не очень и дороги уже. Всё собрать на SSD и пару hdd в райд 1, для помойки. Главное выполнить 1-2 пункт. Тогда всё будет летать.

[Tos]

У каждого конечно своё понятие недорого, но 1500$ за серверный Optane я считаю дороговато. Не оправдано.