Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Диски. HP EVA.  [new]
любитель EVA
Guest
Добрый день всем! Спасибо форуму, холиваров начитался, теперь тоже хочу :)
Поскольку основной опыт - разработка, то в теме специалист посредственный. Есть какой-то опыт настройки массивов на оборудовании HP, но только на MSA2000-й серии.

Итак, есть OLTP решение на SQL2005, у заказчика есть HP EVA 6400. На Еве, кроме этой задачи есть и другие потребители.
Есть 56 (или 64) дисков 15K по 300Gb на шпиндель (Диски только под эту задачу. Бэкапы отдельно)
Есть вопросы, как лучше ими распорядиться, хочется совета от администраторов, имеющих опыт эксплуатации EVA-систем.
Заставить админов заказчика перебрать все приходящие в голову конфигурации не получится, хотелось бы ограничиться хотя бы двумя конкретными вариантами конфигурации.

Пока видится три направления тестирования.
1.
1-я дисковая группа в составе 8(до 12ти) дисков в R10 под логи базы и логи tempdb.
2-я дисковая группа R10 под файлы данных базы и tempdb на все остальные диски.

2.
максимум дисковых групп по 8 дисков в R10 и распределение по ним файлов данных с целью равномерного распределения нагрузки
дисковая группа из остальных дисков под логи базы и tempdb

3.
Одна дисковая группа в R10 на все диски, на ней и файлы данных и логи как базы так и tempdb

Теперь вопросы (навеяны, в основном незнанием Евы и холиварами глубоко уважаемых товарищей Гладченко и Шаца):
1. Есть ли возможность создания Raid1 из пары дисков на EVA? Если есть, то в каком направлении смотреть.
2. HP-шные доки глаголють, что лучше иметь меньшее количество дисковых групп, но больше дисков в каждой. Соответственно вопрос к опытным пользователям EVA - насколько эта рекомендация согласуется с действительностью?
Если 2 верно, то будет ли более верным все диски массива организовать в одну большую группу, нарезать на луны и шарить между всеми серверами?
Я ведь правильно понимаю, что можно сделать так : одна дисковая группа -> несколько виртуальных дисков -> каждый виртуальный диск своему хосту, то есть на одной физической R-десятке будет сидеть несколько хостов каждый со своими задачами?

Пока склоняюсь к варианту 1.
8 ноя 11, 12:06    [11562685]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
SIMPLicity_
Member

Откуда: (((@)))
Сообщений: 8877
У мну нет ни сапа ни адинэса, поэтому такие девайсы не юзал... Тем не менее, склоняюсь к первому варианту. Там два контроллера. Поэтому, ИМБО, ничего суперфантастического с точки зрения чтения/записи хьюлетт не родил. Следовательно (ИМБО опять-таки), количество дисков имеет место быть. Посему - на один контроллер (!) логи, на другой базу. Темпдэбэ яп положил к логам - это криво в принципе но для ОЛТП оправдано (ибо, думаю, чтение и работа с временными таблицами у вас многократно превышает запись).
PS Эт чисто моё мнение. Если чо - я науральное блондинко.
8 ноя 11, 12:21    [11562807]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
Еву настраивают в расчёте на то, что она будет эффективно кешировать данные. Её админов трудно убедить, что в случае SQL Server этот кеш будет в большинстве случаев паразитным. Им проще нарезать луны как для файловых помоек и не вникать в особености иной нагрузки :(
По существу же всё сводится к тоому, какие требования к обслуживанию вашей нагрузки будут предъявлятся СХД. Если они не велики, то предложенные вами варианты вполне могут оказаться равнозначными. Если же нагрузка большая (по крайней мере сооразмерима с тем, что могут выдать в сумме все задействованные шпиндели, что можно определить по их паспортным данным), может понадобится разделить физически шпиндели на 4 задачи: файлы данных БД; файл журнала БД; файлы данных tempdb; файл журнала tempdb. Выбор типа массива не играет определяющей роли, это может быть RAID5, RAID10, RAID1 или даже RAID0 для файлов данных. Всегда есть возможность компенсировать потери на обслуживание задач массива увеличением числа шпинделей в массиве...
8 ноя 11, 13:54    [11563534]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
SIMPLicity_
У мну нет ни сапа ни адинэса, поэтому такие девайсы не юзал... Тем не менее, склоняюсь к первому варианту. Там два контроллера. Поэтому, ИМБО, ничего суперфантастического с точки зрения чтения/записи хьюлетт не родил. Следовательно (ИМБО опять-таки), количество дисков имеет место быть. Посему - на один контроллер (!) логи, на другой базу. Темпдэбэ яп положил к логам - это криво в принципе но для ОЛТП оправдано (ибо, думаю, чтение и работа с временными таблицами у вас многократно превышает запись).
PS Эт чисто моё мнение. Если чо - я науральное блондинко.


Начиная с SQL Server 2005 к tempdb предъявляются особые требования. Лучше руководствоваться соответствующими рекомендациями вендора.
8 ноя 11, 13:57    [11563558]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
SIMPLicity_
Member

Откуда: (((@)))
Сообщений: 8877
Александр Гладченко
SIMPLicity_
У мну нет ни сапа ни адинэса, поэтому такие девайсы не юзал... Тем не менее, склоняюсь к первому варианту. Там два контроллера. Поэтому, ИМБО, ничего суперфантастического с точки зрения чтения/записи хьюлетт не родил. Следовательно (ИМБО опять-таки), количество дисков имеет место быть. Посему - на один контроллер (!) логи, на другой базу. Темпдэбэ яп положил к логам - это криво в принципе но для ОЛТП оправдано (ибо, думаю, чтение и работа с временными таблицами у вас многократно превышает запись).
PS Эт чисто моё мнение. Если чо - я науральное блондинко.


Начиная с SQL Server 2005 к tempdb предъявляются особые требования. Лучше руководствоваться соответствующими рекомендациями вендора.

Так эта, Александр, я таки понимаю, что от хьюлеттов нет рекомендаций на этот счёт. Если у ТС в полках диски SSD, то имеет ли смысл использовать под tempdb чередующиеся диски без зеркалирования? Я совсем не против SSD, но стоит ли экономия в деньгах возможных убытков от падения tempdb под нагрузкой? Опять-таки учитывая, что у ТС будет крутиться база для OLTP...


PS И эта, прошу прощение, я тут фигню написал по поводу соотношения чтения/записи приминительно к системи OLTP. Tempdb всё-таки лучше от логов баз отдельно (кстати, а нагрузка на неё(темпдэбэ) хоть какая-то есть?).
8 ноя 11, 14:10    [11563671]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
Александр Гладченко
может понадобится разделить физически шпиндели на 4 задачи: файлы данных БД; файл журнала БД; файлы данных tempdb; файл журнала tempdb.

Я правильно понимаю, что Вы предлагаете 4 дисковых группы по одной на задачу? Это я к тому, что 16 шпинделей выделять под логи, судя по текущим показателям загруженности будет много (дисковая группа в EVA не менее 8 дисков). А если есть возможность создать группу менее чем из 8 дисков, то это повторение вопроса 1 - как?
Александр Гладченко
Всегда есть возможность компенсировать потери на обслуживание задач массива увеличением числа шпинделей в массиве...
Поясните пожалуйста, что-то я не понял Вашей мысли
8 ноя 11, 14:30    [11563830]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
SIMPLicity_
(кстати, а нагрузка на неё(темпдэбэ) хоть какая-то есть?).

Диски не SSD, см. первый пост.
А в каких ситуациях на Ваш вопрос можно ответить нет? :)
8 ноя 11, 14:34    [11563849]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
любитель EVA
Я правильно понимаю, что Вы предлагаете 4 дисковых группы по одной на задачу? Это я к тому, что 16 шпинделей выделять под логи, судя по текущим показателям загруженности будет много (дисковая группа в EVA не менее 8 дисков). А если есть возможность создать группу менее чем из 8 дисков, то это повторение вопроса 1 - как?


Вы правильно меня поняли. Выделяйте под журнал 8 дисков, пусть даже это много для задачи. Главное, что бы там жил только журнал. Любая другая нагрузка будет влиять на производительность запросов.
8 ноя 11, 14:38    [11563877]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
любитель EVA
Александр Гладченко
Всегда есть возможность компенсировать потери на обслуживание задач массива увеличением числа шпинделей в массиве...
Поясните пожалуйста, что-то я не понял Вашей мысли


Всё просто, массивы выше уровнем RAID1 сильно проигрывают в производительности обслуживания нагрузки SQL Server по сравнению с зеркалом или простым чередованием, когда тестируется одинаковое количество обслуживающих нагрузку шпинделей. Если итоговой производительности массива недостаточно для достижения заданных норм, в старшие массивы можно просто добавить шпинделей, они хорошо масштабируются.
8 ноя 11, 14:43    [11563912]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
Александр Гладченко
любитель EVA
Я правильно понимаю, что Вы предлагаете 4 дисковых группы по одной на задачу? Это я к тому, что 16 шпинделей выделять под логи, судя по текущим показателям загруженности будет много (дисковая группа в EVA не менее 8 дисков). А если есть возможность создать группу менее чем из 8 дисков, то это повторение вопроса 1 - как?
Вы правильно меня поняли. Выделяйте под журнал 8 дисков, пусть даже это много для задачи. Главное, что бы там жил только журнал. Любая другая нагрузка будет влиять на производительность запросов.
Ок.
По поводу двух различных групп для журнала tempdb и журнала базы. Вы эти два журнала также предлагаете изолировать друг от друга, правильно? Если да, то не затруднит пояснить причину. Вроде и там лог и там лог.
?
8 ноя 11, 14:43    [11563913]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
Александр Гладченко
...в старшие массивы можно просто добавить шпинделей, они хорошо масштабируются.
Ясно.
Я почему то подумал, что два предложения
Александр Гладченко
Выбор типа массива не играет определяющей роли, это может быть RAID5, RAID10, RAID1 или даже RAID0 для файлов данных. Всегда есть возможность компенсировать потери на обслуживание задач массива увеличением числа шпинделей в массиве.
связаны друг с другом. И удивился, причем тут Raid0 и потери на обслуживание.
Но в EVA, как я понимаю, нет Raid1 и Raid10 в привычном смысле. Там vRaid1 из 8 дисков минимум. Потому и первый вопрос в стартовом посте.
8 ноя 11, 14:47    [11563956]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
любитель EVA
Александр Гладченко
Вы правильно меня поняли. Выделяйте под журнал 8 дисков, пусть даже это много для задачи. Главное, что бы там жил только журнал. Любая другая нагрузка будет влиять на производительность запросов.
Ок.
По поводу двух различных групп для журнала tempdb и журнала базы. Вы эти два журнала также предлагаете изолировать друг от друга, правильно? Если да, то не затруднит пояснить причину. Вроде и там лог и там лог.
?
Если журнал один, то головы на всех лисков стоят неподвижно и пишут, пишут... со скоростью линейная скорость диска * количество дисков, то есть больше гигабайта в секунду, даже несмотря на маленкий блок записи.

А если журналов больше одного, то головы скачут от одного журнала к другому, скорость уменьшается в разы.

Разумеется, решение нужно принимать исходя из нагрузки на логи - может, там лог tempdb даст нагрузку в 1 IOPS...
8 ноя 11, 14:49    [11563971]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
любитель EVA
По поводу двух различных групп для журнала tempdb и журнала базы. Вы эти два журнала также предлагаете изолировать друг от друга, правильно? Если да, то не затруднит пояснить причину. Вроде и там лог и там лог.
?


Характер нагрузки для журнала транзакций: последовательный доступ блоками от размера сектора и до 64К. Часто, преобладают блоки 8К. Чемь меньше очередей к LUN журнала, тем лучше время отклика. Поскольку SQL Server ярый блокировочник, от производительности журнала, во многом, зависит производительность приложений, т.о. нужно для журнала создавать самые "тепличные" условия.
Журнал tempdb сильно зависит от манеры написания кода разработчиком. Принимать решение о его размещении лучше основываясь на метриках его реальной работы в ваших условиях. Очень может быть, что его нагрузка будет мизерной, тогда его размещение не критично. Однако, нерегламентированные запросы могут существенно поднимать требования к журналу tempdb, хотя и могут исполняться очень редко. Это тоже нужно учитывать и, по возможности, подстраховываться дополнительными ресурсами.
Если нагрузка на данные и журнал tempdb мала, можно их положить на диски одной группы (8 шпинделей), главное, воизбежание файловой фрагментации, нарезать под каждый файл свой LUN...
8 ноя 11, 14:54    [11564001]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
alexeyvg
Если журнал один, то головы на всех дисков стоят неподвижно и пишут, пишут... со скоростью линейная скорость диска * количество дисков, то есть больше гигабайта в секунду, даже несмотря на маленкий блок записи.
А если журналов больше одного, то головы скачут от одного журнала к другому, скорость уменьшается в разы.
Алексей, я тут чем больше читаю про EVA, тем меньше уверен что в отношении неё Ваша фраза справедлива. Точнее я практически уверен, что Вы неправы в случае, если на дисковой группе созданы разные типы Raid'ов и не знаю, правы Вы или нет в случае одной дисковой группы с одним уровнем Raid'а и с единственным файлов - файлом журнала.
8 ноя 11, 14:55    [11564006]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
Александр Гладченко
любитель EVA
...

Характер нагрузки для журнала транзакций: последовательный доступ блоками от размера сектора и до 64К. Часто, преобладают блоки 8К. Чемь меньше очередей к LUN журнала, тем лучше время отклика. Поскольку SQL Server ярый блокировочник, от производительности журнала, во многом, зависит производительность приложений, т.о. нужно для журнала создавать самые "тепличные" условия.
Журнал tempdb сильно зависит от манеры написания кода разработчиком. Принимать решение о его размещении лучше основываясь на метриках его реальной работы в ваших условиях. Очень может быть, что его нагрузка будет мизерной, тогда его размещение не критично. Однако, нерегламентированные запросы могут существенно поднимать требования к журналу tempdb, хотя и могут исполняться очень редко. Это тоже нужно учитывать и, по возможности, подстраховываться дополнительными ресурсами.
Если нагрузка на данные и журнал tempdb мала, можно их положить на диски одной группы (8 шпинделей), главное, воизбежание файловой фрагментации, нарезать под каждый файл свой LUN...
Ясно. В моём случае нагрузка на запись на журнал tempdb примерно в два раза меньше, чем на журнал базы. То есть будет составлять около трети нагрузки на массив. Я подумаю, объединить их или нет.
Забыл написать в начале, каюсь. Будет поднята транзакционная репликация. С учетом этого есть смысл как то изменить конфигурацию?
8 ноя 11, 15:00    [11564050]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
любитель EVA
В моём случае нагрузка на запись на журнал tempdb примерно в два раза меньше, чем на журнал базы. То есть будет составлять около трети нагрузки на массив. Я подумаю, объединить их или нет.

Если есть возможность нарезать LUN на других шпинделях, луше не объединяйте...

любитель EVA
Забыл написать в начале, каюсь. Будет поднята транзакционная репликация. С учетом этого есть смысл как то изменить конфигурацию?


У вас появится база распространителя, которая при большом числе тиражируемых транзакций, может создавать существенную нагрузку. Думаю, под неё нужны дополнительные шпиндели...
8 ноя 11, 15:10    [11564127]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
...для EVA нагрузка СУБД это одна из множества нагрузок. Перед такими СХД не ставится задачи обеспечить максимальную производительность ввода-вывода, у неё задача скорее сбалансировать нагрузку так, что бы всем хватило и никто не умер. Разумеется, любой СУБД это не нравится... но, если взять дисков кроме как на виртуализаторе больше негде, можно и нужно адаптировать и СУБД и СХД. Главное, точно знать, на какие метрики нужно вывести производительность...
8 ноя 11, 15:21    [11564245]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
любитель EVA
alexeyvg
Если журнал один, то головы на всех дисков стоят неподвижно и пишут, пишут... со скоростью линейная скорость диска * количество дисков, то есть больше гигабайта в секунду, даже несмотря на маленкий блок записи.
А если журналов больше одного, то головы скачут от одного журнала к другому, скорость уменьшается в разы.
Алексей, я тут чем больше читаю про EVA, тем меньше уверен что в отношении неё Ваша фраза справедлива. Точнее я практически уверен, что Вы неправы в случае, если на дисковой группе созданы разные типы Raid'ов и не знаю, правы Вы или нет в случае одной дисковой группы с одним уровнем Raid'а и с единственным файлов - файлом журнала.
Ну, я вот читал всякие статьи больших специалистов по SAN, и в частности по EVA - везде пишут, что главная (и практически единственная) рекомендация при настройке хранилищ - всегда разделать файлы логов от файлов данных на физическом уровне, не используя деление на LUN-ы (или используя, но при мапировании луна на физические диски - тут есть некоторая терминологическая путанница)

Например: http://technet.microsoft.com/en-us/library/ee410782(SQL.100).aspx
"one RAID 1 pair for each LUN"

Про EVA нельзя читать рассказы производителя (ну это понятно) и сисадминов - только рассказы DBA. Это черезвычайно важно - характер нагрузки совсем другой.
8 ноя 11, 15:34    [11564364]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
Александр Гладченко
любитель EVA
Забыл написать в начале, каюсь. Будет поднята транзакционная репликация. С учетом этого есть смысл как то изменить конфигурацию?


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

Так что может и имеет смысл.

Но вы ограничены тем, что в группе не может быть меньше 8-ми дисков, так что небольшими блоками может не получится нарезать...

Вот в той статье писали, что лучьше нарезать группы по зеркалу из 2-х дисков, и отдавать их винде, а там уже объединять страйпом в тома.
И я ещё во многих местах про такое читал - это типа стандартный подход для SAN, позволяющий максимизировать нагрузку на хранилище (это как бы обходит узкие места драйверов).
8 ноя 11, 15:45    [11564466]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
alexeyvg
Ну, я вот читал всякие статьи больших специалистов по SAN, и в частности по EVA - везде пишут, что главная (и практически единственная) рекомендация при настройке хранилищ - всегда разделать файлы логов от файлов данных на физическом уровне, не используя деление на LUN-ы (или используя, но при мапировании луна на физические диски - тут есть некоторая терминологическая путанница)

Например: http://technet.microsoft.com/en-us/library/ee410782(SQL.100).aspx
"one RAID 1 pair for each LUN"

Про EVA нельзя читать рассказы производителя (ну это понятно) и сисадминов - только рассказы DBA. Это черезвычайно важно - характер нагрузки совсем другой.
Нет, Вы не так меня поняли. Я не пытаюсь опровергнуть целесообразность разделения логов и данных. Я предполагаю, что применительно к виртуальному массиву ваши слова "Если журнал один, то головы на всех лисков стоят неподвижно и пишут, пишут... со скоростью линейная скорость диска * количество дисков, то есть больше гигабайта в секунду, даже несмотря на маленкий блок записи.
А если журналов больше одного, то головы скачут от одного журнала к другому, скорость уменьшается в разы"
скорее всего неверны. Поскольку использование дисков EV'ой среднего уровня уж очень отличается от СХД более низких категорий. А по поводу "нельзя читать рассказы производителя (ну это понятно) и сисадминов - только рассказы DBA" - я сюда для того и пришел :)
8 ноя 11, 15:46    [11564476]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
alexeyvg
Александр Гладченко
У вас появится база распространителя, которая при большом числе тиражируемых транзакций, может создавать существенную нагрузку. Думаю, под неё нужны дополнительные шпиндели...
Да, у меня вот были репликации, в которых буд полностью загружен отдельный неслабый сервер для распространителя...
Репликацией занимаюсь не я, но, насколько я понимаю, база распространителя будет на другом сервере и его диски к упомянутым 56ти не относятся. Под влиянием реплики я понимал "читающую" нагрузку на лог.
8 ноя 11, 15:59    [11564617]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
любитель EVA
Guest
alexeyvg
Вот в той статье писали, что лучьше нарезать группы по зеркалу из 2-х дисков, и отдавать их винде, а там уже объединять страйпом в тома.
Я в стартовом посте как раз задал вопрос. Есть в Еве возможность создать классический Raid1. Если есть, то как. Там ещё второй пункт, на него кто бы ответил, хотя бы да/нет.
8 ноя 11, 16:02    [11564628]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
любитель EVA,

Нагрузка на журнал выростет пропорционально числу публикаций и числу пописок по каждой из них. Записи в журнале будут задерживаться до тех пор, потка распространитель не растиражирует их всем подписчикам.
Кроме ядра с журналом будет работать ещё и логридер агент, что тоже немаловажно...
8 ноя 11, 16:02    [11564632]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
любитель EVA
Я предполагаю, что применительно к виртуальному массиву ваши слова "Если журнал один, то головы на всех лисков стоят неподвижно и пишут, пишут... со скоростью линейная скорость диска * количество дисков, то есть больше гигабайта в секунду, даже несмотря на маленкий блок записи.
А если журналов больше одного, то головы скачут от одного журнала к другому, скорость уменьшается в разы"
скорее всего неверны. Поскольку использование дисков EV'ой среднего уровня уж очень отличается от СХД более низких категорий.
Я такие мнения слышал, но не понимаю, что они значат :-)

Если у нас есть 2 файла, расположенных на одном или на 2-х массивах (рассматриваю 2 случая), в файлы идёт последовательная запись сектор за сектором.

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

Не понимаю, как именно некий "виртуальный массив" может это изменить...

Или имеется в виду, что просто делается на всех дисках один рейд, на нём виртуальные массивы (LUN-ы), и вот там в современных системах хранения просто нельзя ничего разделить?
Да, такое есть, админам это проще, так и производительность будет процентов 10 от максимальной. Я такое много раз видел.

Админам главное не производительность, а чтоб тикеты закрыть.

Сам стараючсь откреститься от SAN-ов, не потому что они плохие, а потому, что их не только неправильно настроят, а даже не скажут, как настроили. Единственно понятная цифра для менеджеров, на которую можно хоть как то влять - это размер. И всё.
8 ноя 11, 16:04    [11564639]     Ответить | Цитировать Сообщить модератору
 Re: Диски. HP EVA.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
любитель EVA
Под влиянием реплики я понимал "читающую" нагрузку на лог.
А, понял. Она есть, но не такая большая - чтение только один раз, ну и обновление, что прочитано.
Это всё таки не мелкие записи от транзакций, не думаю, что окажут сильное влияние.
8 ноя 11, 16:06    [11564664]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить