dmitry stakanovвопрос: будет ли профит в скорости, если локальные RAID1/1+0 заменить на vRAID5 (для журналов транзакций)?Зависит от конкретной настройки и характеристик.

vRAID5 - сколько шпинделей, и сколько десятков серверов ещё туда подключено?

Если шпинделей много, и этот сервер единственный, кеш большой и кеширование записи разрешено, то будет быстрее. Но всё это маловероятно, скорее всего на это СХД будет навешано много чего.

Достаточно просто проверить разницу в быстродействии с помощью sqlio.

rahzerда с большим кэшем под это дело на сервкахБольшой или маленький кеш на серверах для кеширования лога MSSQL не используется. Сисадмины любят СХД, но не знают, как с дисками работает сиквел.

dmitry stakanovalexeyvg,

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

Несколько статей, чтоб не тестировать самому:

10 рекомендаций по настройке хранилищ данных
http://sqlcat.com/sqlcat_international/b/whitepapers_russian/archive/2008/10/30/492.aspx
!!! В некоторых случаях (в зависимости от характера использования TEMPDB) можно добиться повышения производительности, если поместить базу данных TEMPDB на дисковый массив RAID 1+0.
!!! Всегда размещайте файлы журналов на дисковых массивах RAID 1+0 (или RAID 1).

http://download.microsoft.com/download/B/E/1/BE1AABB3-6ED8-4C3C-AF91-448AB733B1AF/Analyzing%20Characterizing%20and%20IO%20Size%20Considerations.docx
!!! one RAID 1 pair for each LUN

Storage Top 10 Best Practices
http://technet.microsoft.com/en-us/library/cc966534.aspx
!!! Isolate log from data at the physical disk level
!!! Always place log files on RAID 1+0 (or RAID 1) disks.

dmitry stakanovда менять точно нечего не дадут на сдх, это самый главный гэп(Ага, это самое плохое :-(

Что бы там не говорили адепты волшебных виртуализированных хранилищ, размазывающих данные сразу на все диски, со сверхумными многоядерными контроллерами (кстати, по моему, за "числодробилки" эти процессоры не отвечают, только за управление, а числодробилки там специализированные), если это неправильно настроить, то работать будет плохо, а настраивать будут гарантированно непрофессионалы (по СУБД).

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

Конечно, альтернатива у вас слабенькая, пара дисков не смогут тягаться с большой СХД, но если есть возможность использовать несколько дисков, или тем более нормальную полку + нормальные контроллеры, то это для сиквела однозначно лучше.

dmitry stakanovлибо я неправильно конфигурировал sqlio, либо меня ввели в заблуждение где, какой рейд. странно все это...Посмотрите: SQL Server: Методика тестирования дисковой подсистемы

Вкратце: в настройках утилиты SQLIO для тестирования дисков под лог нужно сконфигурить последовательную запись небольшими блоками и отключить кеш.

Не забывайте, что при эксплуатации большой vRAID будет ещё параллельно загружен потоком случайной записи/чтения.

alexeyvgи отключить кешИмеется в виду кеш ОС и кеш без батарейки, то есть смоделировтаь реальную ситуацию.

dmitry stakanovвсе-таки можно про кэш подробнее?Да в общем ерунда... Я имел в виду, чтоб не использовался кеш записи в ОС (допустим, на настольных ОС такое озможно, или в виртуальных машинах).

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

dmitry stakanovзакончил тестыОооо, спасибо за проделанную работу, интересно будет ознакомиться!
dmitry stakanovадекватны ли были параметры тестирования?
ИМХО маловат файл, при тестировании на СХД, если нет другой нагрузки, будет большое попадание в кеш и результат будет некорректным (поскольку в реальной работе данных будет больше, и пользвателей у СХД будет ещё много, кроме одного этого сервера).

Ещё при тесте важно создавать адеватную нагрузку на подсистему хранения в целом.
Если райд на ХХХ дисков используется только для лога, то нужно создать нагрузку в виде последовательной записи небольших блоков, а если vRAID5 будет хранить и данные, и логи, то нужно создать нагрузку в виде последовательного потока записи 8 кб, случайного потока чтения 64 кб, случайного потока записи 64 кб. Такая мешанина будет лучше показывать реальную ситуацию.

Вообще, изначально не было сомнений, что vRAID5 на 96 дисков с 2 гб кеша будет быстрее RAID1, если он целиком предоставлен серверу :-)
dmitry stakanovпс оч сильный разброс между чтением и записью - это нормально?ИМХО, т.к. чтение и запись на RAID1 одинаковы, а на vRAID5 отличаются, это говорит о том, что на vRAID5 включён кеш записи, а на RAID1 выключен.

Вообще RAID1 должен быть с кешем на запись с батарейкой, иначе будет очень медленно.

Ещё вопрос - графики, которые с queue, там какой размер блока, какие параметры?
Вообще, непонятно на графиках и в таблицах, какие были выбраны параметры теста (кроме оси х на графиках, естественно).

dmitry stakanovчто можно улучшить в настройках операционной системы и рейд контроллеров дисков?Ещё хочу обратить ваше внимание на рад провалов при размере блока 64к

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

alexeyvgВообще, изначально не было сомнений, что vRAID5 на 96 дисков с 2 гб кеша будет быстрее RAID1, если он целиком предоставлен серверу :-)Хотя видно, что как раз для файла лога жалкие 2 диска победили :-)

Это тест sequential_write, b8 - характерная нагрузка для файла лога, 138,7 против 96,8