У меня очень мало опыта работы с сетями SAN, так что прошу прощения за этого новичка.
На одном из наших производственных участков есть HP EVA8000 SAN с кучей дисков (не забудьте, сколько именно). он был сконфигурирован в группу raid5, и сервер SQL использует один том RAID для данных, а другой - для журнала.
Все идет нормально. Или так я думал
Сегодня я провел несколько тестов на скорость. Используя rdfc, я создал файл размером 100 МБ на основном диске с данными, когда система интенсивно использовалась. Это показало пропускную способность от 5 до 20 МБ / с для записи, что, как мне показалось, было немного невысоко. Затем я удалил приложение для обслуживания и снова запустил тест. На этот раз в тихой системе я получил скорость записи 50 МБ / с.
Разве это не на низком уровне? То есть я получаю то же самое от диска SATA на моем рабочем столе.
Затем я попытался записать 500 МБ на один диск (диск с данными), а 500 МБ на другой диск (диск с журналами). Эти две записи мешали друг другу. Это признак того, что что-то неправильно настроено?
Не знаю, чего я ожидал, но в настоящее время проверяю систему, чтобы попытаться найти узкие места.
Итак, я думаю, у меня будет вопрос. Какой производительности вы ожидаете (чтение / запись) от (возможно) дорогостоящей сети хранения данных с оптоволоконными соединителями?
(Нет, это не маленькая штуковина netgear, это это) http://h10010.www1.hp.com/wwpc/ca/en/sm/WF05a/12135568-12135820-12135820-12208992-12208992-12236532.html
У нас есть EVA6100, поэтому я проводил тесты на аналогичном оборудовании. 8000, IIRC, более старая система, чем 6100.
Во-первых, ваши записи в том БД и том журнала, скорее всего, конкурируют за записи, поскольку похоже, что они находятся в одной группе дисков внутри EVA. Группа дисков - это группа дисков, на которых вы создаете LUN, и каждый LUN - это диск, представленный одному (или нескольким) серверам. Совсем не редко размещать много-много LUN в одной дисковой группе. Если у вас есть только одна дисковая группа, то преимущества отделения ввода-вывода журнала от ввода-вывода базы данных несколько уменьшаются.
Во-вторых, если этот DG действительно вступает в конфликт ввода-вывода, это ухудшит производительность. Это то, что очень сложно проверить с точки зрения потребителя, это то, о чем должны знать специалисты по обслуживанию SAN. Спросите их, знают ли они, какова средняя загрузка ЦП контроллера, поскольку это существенно повлияет на вашу производительность записи.
В-третьих, знайте, какой ваш набор операций ввода-вывода действительно является эталоном для этого, а не только скорость копирования файлов. Если объем ввода-вывода вашего тома БД составляет 80/20 чтения / записи, вы действительно хотите проверить пропускную способность пути чтения. Если наоборот, то производительность записи - это показатель, который вам действительно нужно проверить.
Просто написав большой файл, вы не измеряете производительность хранилища. Вы просто измеряете производительность записи большого файла. Вы, к сожалению, ошибаетесь, если думаете, что получите что-то подобное, когда: записываете случайным образом по всему диску, записываете много блоков одновременно, записываете действительно большие или очень маленькие блоки. Я гарантирую вам, что вы можете получить из вашего массива максимум 1 МБ / с для одного типа рабочей нагрузки, а затем с другой рабочей нагрузкой / настройкой вы легко получите 800 МБ / с (... при условии, что ваш сервер может справиться с этим).
Если вы хотите узнать об этом, используйте подходящий инструмент. В то время я использовал Intel IOMeter и многому научился с его помощью. Наверное, теперь есть инструменты получше. Основным параметром, на который следует обратить внимание, является размер очереди и случайная или последовательная операция. Прочтите о механике диска, о том, почему время поиска так невероятно велико и как работает RAID5.
Если вы хотите узнать, как ваше хранилище работает в реальной жизни, взгляните на счетчики PhysicalDisk в perfmon.exe в течение рабочего дня. Затем создайте некоторую нагрузку на ваше настоящее приложение и наблюдайте, что происходит.
Еще одна важная вещь, которую необходимо проверить, - это правильность выравнивания диска. Я не раз видел, как невыровненные LUN-ы были источником больших проблем с производительностью. Если смещение раздела не задано перед форматированием, вы можете увидеть 25% -ное снижение производительности ввода-вывода.
RAID 10 также является лучшим вариантом, по крайней мере, для LUN журналов.
Наконец, вы можете настроить соотношение кэширования чтения / записи на LUN до 100% записи, поскольку SQL Server отлично справляется с кэшированием операций чтения.
SQLIO - хороший инструмент для тестов, но определенно не для производства. Он прост в использовании, запускает последовательные и случайные тесты чтения / записи переменного размера и обеспечивает хорошую основу для сравнения с другими системами.
Загляните в RAID10. Один умный коллега однажды убедил меня, что это лучше, чем RAID5 для баз данных с интенсивной записью, и был прав. Это.
Это кажется очень низким, коробки EVA8xxx довольно быстрые, если учесть, что они созданы для простоты использования. У нас их много для разных вещей, и у меня есть запасной 8100 со 112 * 1 ТБ 7.2k дисками, и я могу легко заполнить соединение FC 4 Гбит / с даже на виртуальном диске RAID5 - это примерно 385 Мбит / с.
Я думаю, что что-то не так, я с радостью предлагаю свою помощь, но это может занять некоторое время. Возможно, вам будет лучше привлечь HP, если у вас с ними достаточно хорошие отношения.
Дай мне знать, как у тебя дела, ладно.
Какие диски находятся в сети SAN (оптоволоконный канал, sata и т. Д.), Это может существенно повлиять на скорость вашего доступа. Я так понимаю, когда вы проводите тесты, вы копируете с серверов, напрямую подключенных к SAN?