Типичные рекомендации по планированию дисковой подсистемы
 

Последние 2 года я регулярно сталкиваюсь с такой ситуацией при внедрении какой-то новой системы. Каждый подрядчик рекомендует размещать систему на отдельной дисковой подсистеме, т.е. выделенных дисковых шпинделях и Raid под отдельную систему. При этом присылают ссылки на рекомендации MIcrosoft, Oracle и т.д.
Но в большинстве современных СХД диски собираются в такой виртуальный shared pool который делится между всеми подключенными системами. Даже в случае простых систем типа HP MSA P3 и виртуализированных серверах - иметь выделенные диски под каждую систему - это роскошь, имхо. Можно себе позволить только для критичных и высоконагруженных систем.
Ваше мнение коллеги, на этот счет? Классические рекомендации для дисковой подсистеме устарели для современных СХД и виртуализированных серверов или стоит к ним прислушиваться?
Конечно, я понимаю, что при таком подходе за загрузкой СХД в целом нужно внимательно следить и наращивать производительность, а не дожидаться пока все системы начнут тормозить.

в каком контексте вопрос?

Просто размышление из опыта. Сейчас подрядчик написал, что под SharePoint 2010, с котороым одновременно будут работать 20-30 максимум 50 пользователей надо обязательно [b]выделенные[/b] диски под SQL и Сервер приложений. Причем они не советовали какое-то определенное кол-во дисков в Raid, а напирали просто на выделенные. С виртуализацией серверов они согласились.

тут нужно просто отдавать себе отчет, что хранилише может быть механическим, а может и нет, дальше по вариантам

(3)[quote]надо обязательно выделенные диски под SQL[/quote]
Прально, ибо незачем SQL ставить в очередь на IO вместе со всяким своподрочерством системы.

джедай)

5-BigHarry > Даже, если у меня таких SQL 4 штуки для некритичных систем? Мне под каждый такой SQL ставить отдельные диски для базы, логов, и системы?
Для критичной системы, у нас SQL отдельный (физический и с выделенными дисками).

3-Friday13 > Т.е. у меня может быть Raid10 в общем сторадже из 30 дисков, где будут крутиться несколько систем. Но надо именно выделенные 2-4 диска под SQL DB в Raid1 или 10?

(7) [quote]Даже, если у меня таких SQL 4 штуки для некритичных систем?[/quote]
Ну если там пара запросов в сутки - можно куда угодно ставить, хоть на флоппик. Но системный диск все же лучше отдельно лучше вынести, хотя бы логически.

Friday13,очень сумбурно. В целом, в (5) BigHarry очень коротко, но правильно описал -- диски/шпиндели это хорошо, но данные обрабатываются контроллером(ами) и смешивание разнотипной нагрузки на контроллеры может привести к просадке производительности, так же как смешивание разнотипной нагрузки в вильтуализированном пространстве одной дисковой группе, т.к. диски офигеют если им одновременно будут подпихивать OLTP и стим.
По теме дать какие-то точные рекомендации нельзя. Если есть какие-то конкретные вопросы по конктетным задачам рад буду помочь, ась: 19шесть1018сорок6.

Кстати, поставило в тупик "HP MSA P3" -- это что за зверь?

Пардон, описался MSA P2000 G3.
Коллеги я не совсем это имел ввиду. Здесь у меня ИТ инфраструктура не большая, но принцип вопроса тот же. Вот была у нас северная с СХД NetApp 3170 на 15 полок по 14 дисков. На этой СХД были агрегаты Raid Group , допустим 4 штуки, каждый примерно по 50 дисков, на них были нарезаны Lun, которые подключались по FC к серверам. Если сервер имел внутренние диски, то на них в зеркале ставилась ОС. Имеется допустим 8 SQL серверов, что мне под каждый делать выделенные диски в отдельной Raid Group?

9-BigHarry > А что значит, хотя бы логически? Логически, конечно это будет отдельный раздел ОС, но физически все равно один рейд собранный на большом количестве дисков.

[em]Если сервер имел внутренние диски, то на них в зеркале ставилась ОС. Имеется допустим 8 SQL серверов, что мне под каждый делать выделенные диски в отдельной Raid Group?[/em]
Однозначно не надо для каждой, но могут быть вариенты. Ну и сравнивать P2000 и приведенный NetApp не очень корректно.

14-krotov > да, конечно системы очень разные.

Т.к. СХД (в смысле не системы хранения, а ля массивы, а сети хранения) моя оснавная специализация, рад буду помочь, ежели чего... но завтра, сегодня у тестя др был.

16-krotov > Спасибо, надо восстановить пароль в асе. Я не в смысле конкретной помощи, а просто обсудить этот вопрос.

Krotov, вот в случае Shared Storage на несколько десятков серверов у твоих заказчиков, ты что выделял под каждый сервер физически отдельные топа (на уровне дисков) ?

Friday13, не понял? Ты про SAN или про NAS?

В 18 физически отдельные ТОМА
19-krotov > Про SAN.

Под томами ты подразумеваешь некий LUN выделенный в отдельную RAID-группу дисков? Если да, то не всегда так надо делать, хотя обычно да, под каждый физический сервер создается отдельная RAID-группа. Но это, если речь идет о классических RAID-массивах, типа P2000, если же речь идет про твой NetApp или что-то вроде P6500 или 3Par, то там вообще нет понятия RAID из физических дисков, т.к. там пространство вильтуализировано и данные размазаны по всем дискам в DiskGroup (не путать с RAID, в одной DiskGroup могут быть созданы множества виртуальных RAID разных уровней).

Но опять же, надо рассматривать конкретную ситуацию. Т.е. не отдельную задачу, а всю инфраструктуру в целом, чтоб, простите за мой французский, потом не oбъeбaтbcя.
Можно почитать доку SAN Design and Best Practices от брокады.
[url]http://community.brocade.com/docs/DOC-2057[/url]

21-krotov > Вот я про это и хочу сказать. Но все внедренцы напирают на рекомендации по сайзингу и архитектуре для классических систем.
Конечно P2000 совсем не NetApp и не P6500.

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