SQL Server - Разделение данных, журналов и файлов TempDB в сети SAN


8

У меня есть SQL Server, подключенный к SAN. Наш новый поставщик систем хранения данных рекомендует, чтобы все LUN ​​охватывали весь дисковый массив, то есть RAID5. Обычно я запрашиваю 3 отдельных LUN (data, log и TempDB) у администратора SAN, но, учитывая рекомендацию нового поставщика, есть ли смысл создавать отдельные LUN? Или я бы увидел ту же производительность, если бы все было в одном LUN, поскольку оно все равно охватывало бы все диски?

Отличная статья, но она не совсем подходит для моей конкретной ситуации: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

Ответы:


6

Следует учитывать, что файлы журналов являются последовательными записями, а файлы данных - непоследовательными. Это одна из причин для отдельных LUN. Файлы журнала пишутся быстрее, если они находятся на своем собственном LUN, потому что шпиндели не должны пропускать, просто пишите последовательно. Если вы добавите файл данных, то шпиндели придется пропустить, и вы потеряете некоторую производительность. Я надеюсь, что у меня есть правильная терминология, так как я не очень хорошо знаком с самими SAN. Идея этого должна быть, однако.

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


1
Я думаю, что OP говорит, что независимо от LUN, они все бьют по одному и тому же шпинделю. Другими словами, нет физического разделения для изолированных пулов дисков.
Томас Стрингер

1
Ах, я думаю, что я говорил, не устанавливайте это так :), чтобы каждый из LUN был на разных шпинделях, даже если поставщик предлагает иное. Если это невозможно, то нет причин производительности для разделения их на разные LUN. Хотя вы никогда не знаете, что произойдет в фоновом режиме, и в какой-то момент в будущем, если они находятся на разных LUN, они могут быть перемещены в разные шпиндели.
Кеннет Фишер

4

Многое зависит от SAN, обычно вы хотите настроить разные LUN ​​с разным кэшированием, сжатием, шифрованием, упреждающим чтением, политиками сквозной / обратной записи, приоритетами и т. Д. Файлы данных SQL часто ведут себя иначе, чем tempdb или log файлы. Метод доступа / сеть также вступают в игру, так как транкинг, многопутевые и другие технологии могут работать или не работать в зависимости от вашего метода доступа (FC, iSCSI, ...) и инфраструктуры. Вы захотите иметь возможность максимально использовать вашу сеть с SQL Server, так как задержка и пропускная способность имеют решающее значение. Я видел случаи с настройкой сетевого взаимодействия, но только 1 Гбит / с был применим из-за других ограничений, о которых клиент не знал. Я согласен с Кеннетом, принимаю рекомендации продавца с большой дозой соли, они довольно часто ошибаются. SQL Server - непостоянный зверь, абсолютов очень мало, обычно просто больше вопросов. Задавать правильные вопросы (путем тестирования) - это действительно ключ.


2

Не «принимайте рекомендации продавцов с большой дозой соли», если они не из отдела продаж или маркетинга. Наоборот, если вы можете получить доступ к своим техническим реализациям, ребята, подружитесь.

Вероятно, это одно из устройств нового поколения, которые виртуализируют пул хранения и включают возможности автоматического уровня. Одним из примеров будет Compellent . Они выполняют все виды вуду САН, такие как:

  • Запись активных блоков данных в хранилище уровня 1 с оптимизированными по производительности уровнями RAID, такими как RAID 10.
  • Автоматически переносите неактивные блоки данных в хранилище более низкого уровня с использованием RAID 5 или 6 с более высокими издержками и высокой степенью защиты.

Для Compellent хранилище разделено на 3 уровня, при этом Tier1 является самым быстрым (SSD или RAID 10) и медленным Tier3, который состоит из 7k дисков SAS. Я еще не использовал один из них в производственной среде, но у меня есть доступ к нему, и я надеюсь, что смогу выполнить некоторые тесты.

Я признаюсь, что был заинтригован и напуган функциями автоуровня, которые на бумаге звучат замечательно, но в производстве могут быть проблематичными. Первым примером, который имел место как потенциальный отказ механизма автоматического уровня, были резервные копии базы данных. Там у вас есть повторяющаяся цель высокой записи, которая может превратить механизм многоуровневого преобразования в перемещение блоков в высокопроизводительный пул, потенциально вытесняя данные, которые должны быть там.

На оригинальный вопрос:

... есть ли смысл создавать отдельные LUN?

Наверное, нет, нет. Чтобы убедиться в том, что поставщик использует ясный вариант использования, но если это устройство типа Compellent, я не верю, что вы выиграете от разделения LUN.


2

Есть ли смысл разделять LUN? Почти всегда. В противном случае вы перестанете перегружать очередь LUN на сервере Windows. И испытывать qfull условия болезненно, независимо от операционной системы, виртуализации или платформы хранения

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.