Лучшая практика SQL Server рекомендует отдельные диски для файлов данных и журналов. Вы действительно получаете увеличение скорости, если оба логических диска расположены на одном EVA?
Ах, как раз моя специализация!
«Лучшие практики» SQL предполагают, что вы используете отдельный физический диск для данных и журнала, да, но это либо на сервере с физическими дисками, подключенными локально, либо с помощью традиционных методов SAN, где LUN был просто частью одного диска SAN. EVA сильно отличаются от этого.
В зависимости от того, какая модель у вас есть, любой LUN будет распределен по МИНИМАЛЬНОМУ восьми физическим дискам, если это P6xxx, это может быть 12 или больше для начала. Итак, если ваш журнал распределен по одной группе из восьми или более дисков, а данные распределены по другим восьми или более, вы, очевидно, получите намного лучшую производительность, чем если бы эти же данные были только на двух дисках. Учитывая, что это самая низкая производительная конфигурация, и вы действительно можете увидеть лучшую производительность из-за более широкого распространения, я думаю, вы согласитесь, что эта «лучшая практика» идет к черту с EVA.
По сути, просто выделите их из самой большой группы дисков, которую вы можете (вы действительно хотите, чтобы все диски одного типа и скорости были в одной DG), а EVA позаботится обо всем остальном. Я запускаю множество кластеров MSSQL в нескольких блоках EVA / P6xxx / 3Par, и в наши дни действительно нет необходимости слишком подробно описывать структуру LUN, как мы использовали в 2000-х годах со старыми массивами SAN.
Возможно, да ... организация очередей для каждого блочного устройства - это отдельная область, которая может выиграть от разделения, даже при переходе к одной и той же физической группе дисков.
Полностью согласен с Chopper3. Теоретического разделения файлов / журналов БД на диск для повышения производительности, которое вы делали для старых добрых JBOD, давно нет.
EVA с большой группой дисков (много шпинделей) - это все, что вам нужно.
Кроме того, если вы действительно посмотрите, что SQL Server или Oracle, если на то пошло, делают на аппаратном уровне, объем дискового ввода-вывода для файлов БД может быть в значительной степени сведен на нет за счет наличия большого количества ОЗУ. Логи, да, все равно пишут последовательно; просто убедитесь, что у вас установлены пороги прокрутки журнала, соответствующие вашей скорости транзакций.
Мы запускаем несколько экземпляров Oracle среднего размера (300 ГБ) на VMware, работающих на EVA. Это добавляет еще один уровень абстракции; то есть:
Тома O / S (NTFS) -> Файлы VMware VMDK -> Хранилище данных VMware (файловая система VMFS) -> EVA vDisk (LUN) с соответствующим уровнем vRAID -> Группа дисков EVA -> Физический диск FC / AL
Итак, если вы попросите компьютерного ученого найти блок на диске, содержащий ваш блок базы данных, чтобы применить некоторые рекомендации по оптимизации, он или она просто пожмет плечами.
Как правило, на старых хранилищах, в которых есть определенные рейды для определенных томов, они рекомендовали хранить журналы и данные в разных рейдах. В наши дни большая часть хранилищ устанавливается с пулами, которые охватывают все операции ввода-вывода на больших группах дисков. В большом пуле нет необходимости избегать хранения журналов и данных для любой базы данных на одних и тех же дисках, но я все же рекомендую хранить их на разных томах по причинам, упомянутым ewwhite в его ответе (конфликт очереди).