Добрый день.

Вопрос по дисковой подсистеме.

задача: Конфигурирование репликации транзакций.

софт: win2008, ms sql2008r2;

3 сервера: публикация, распространение, подписка;

диски: vRAID5 (EVA4400), локально RAID1, RAID1+0, RAID0;


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

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

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

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

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

спасибо!
админы говорят, что пока висит 5 серверов и один кластер vmware (без нагрузки) + я навешу еще 3 сервера с репликацией.
также сказано, что стойка максимально забита шпинделями. судя по спеку - 56 штук.
каковы могут быть прогнозы относительно 1 vs v5, 0 vs v5 и 1+0 vs v5?

пс кэширование где? на стойке?
ппс и какой должен быть размер страйпа?
пппс сорри, я по части железа полный профан(

alexeyvg,

я бы, конечно, методом тыка (тестирования) все бы сделал. но, к сожалению, время очень ограничено и хотелось бы иметь представление о том, чего делать не стоит.

alexeyvgdmitry 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.

доп инфа, 96 дисков - 15K RPM, 5 LUN, 2 контроллера кэш по 2гб.

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

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

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

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

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


Протестировал RAID0+1, RAID5 и vRAID5.
в общем-то разницы никакой нет. и это странно.
либо я неправильно конфигурировал sqlio, либо меня ввели в заблуждение где, какой рейд. странно все это...

dmitry stakanovalexeyvgпропущено...
Ага, это самое плохое :-(

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

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

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


Протестировал RAID0+1, RAID5 и vRAID5.
в общем-то разницы никакой нет. и это странно.
либо я неправильно конфигурировал sqlio, либо меня ввели в заблуждение где, какой рейд. странно все это...

да наврали мне. оказывается я тестировал raid1 vs raidv5

alexeyvg,

спасибо! А. Гладченко уже прочитал.

все-таки можно про кэш подробнее?
в статье идет речь об отключении кеша контроллеров.

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

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

закончил тесты, но результаты довольно странные (см вложение).

Тестировались: RAID1, RAIDv5 (EVA4400)
параметры тестирования:

-k(W, R)
-s180
-(fsequential, frandom)
-t8
-o(1,2,4,8,16,32,64)
-b(8,16,32,64,128,512)
-LS
-Fparam.txt (файл 8гб, маска - все процессоры, потоки - 8);

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

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

да согласен, с размером файла нагрузки промахнулся.

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


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

Кэш включен. ниже конфигурация контроллера и дисков:
конфигурация RAID1: controller: Smart Array P410i, logical drive 600gb (2 шпинделя) ntfs, drive type=SAS, 10k, stripe=128k, sectors=32, queue depth=automatic, cache=512mb, array accelerator= 25% read / 75% write, cache status = ok, array accelerator=yes;
alexeyvgЕщё вопрос - графики, которые с queue, там какой размер блока, какие параметры?
Вообще, непонятно на графиках и в таблицах, какие были выбраны параметры теста (кроме оси х на графиках, естественно).

Это средние значения: для каждого варианта очереди прогонялся каждый вариант размера блока и наоборот;
те для
q1 -> b1...b512
....
q64 ->b1...b512

и для
b8 -> q1...q64
...
b512 -> q1...q64

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

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

вроде бы выравнено все, но вот только размер сектора 32.
диск парт показывает ровно 32 и на вьюер рейда показывает тоже самое.
мб дело в этом?

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

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

я думал характерный ворклоад для лога на отдельном томе будет 54-512? а для данные рандомные операции 8?

alexeyvgdmitry stakanovпропущено...


вроде бы выравнено все, но вот только размер сектора 32.
диск парт показывает ровно 32 и на вьюер рейда показывает тоже самое.
мб дело в этом?Вы про размер кластера в NTFS? ИМХО тоже надо 64 ставить.

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

Вот щас АГ придёт, поставит диагноз :-)


Status OK
Drive Number 4
Drive Unique ID 600508B1001C8144D0416EF8F13F3715
Size 572293 MB
Fault Tolerance RAID 1
Heads 255
Sectors 32
Cylinders 65535
Stripe Size 128 KB
Array Accelerator Enabled

диск парт тоже показывает размер сектора 32

alexeyvgdmitry stakanovЭто средние значения: для каждого варианта очереди прогонялся каждый вариант размера блока и наоборотПонятно, спасибо.
dmitry stakanovпропущено...


Кэш включен. ниже конфигурация контроллера и дисков:Тут важно, верит ли этому сиквел :-)

Даже при включённом аппаратном кеше записи он может не использоваться для некоторых операций, если контроллер об этом попросит ОС.

Я не такой уж бльшой спец по железу, вам нужно ещё поискать что нибуть про это. По крайней мере, результаты теста подозрительные.
dmitry stakanovбудут разные тома под журнал и под данные, вне зависимости от того на каком рейде остановлюсь.Разделение по томам вообще ни на что не влияет, если вы про тома NTFS на рейде/луне. Это же просто логическое разделение, влияет разве что на фрагментирование, да и то, если вы не задали файлы изначально нужного размера.


прошу прощения, имел виду разные тома на разных lun/raid.

alexeyvg,

да, и стоит ли устанавливать фиксированный замер очереди на контроллере?