В настоящее время у меня есть база данных SQL Server 2005 среднего размера (4 ГБ), работающая на сервере Windows 2003 Server 3-летней давности. [Xeon 2.8-2core, 2 ГБ, 2x 73 ГБ SCSI 10k - RAID 1]. Эта БД завершает работу приложения ASP.NET OLTP на том же сервере. Приложение также поддерживает отчеты из той же базы данных (без хранилища данных, только некоторая денормализация, где это критично).
Об загрузке ЦП на текущем сервере упоминать не стоит, использование памяти - «время подумать об обновлении». Производительность / использование диска ... Я не уверен ... но производительность приложений и запросов остается достаточно быстрой.
Мы планируем обновить оборудование в течение следующего года, чтобы учесть ожидаемый рост. Я хотел бы перейти на Windows 2008 R2 с Hyper-V для большей гибкости и т. Д.
Вопрос: Обеспечивает ли iSCSI SAN достаточную производительность для запуска SQL 2008 на виртуальной машине? Я не нахожу хорошего руководства в Google. Я знаю, что конфигурация поддерживается (а NAS - нет), но похоже, что консенсус таков: «Может быть, но Fiber / HBA или DAS лучше».
Какие показатели мне следует оценить в моей текущей системе, чтобы принять это решение? Есть ли какие-то пороговые значения, которые я должен искать, чтобы указать, что iSCSI не будет его сокращать?
Любое руководство или информация очень ценятся!
ОБНОВЛЕНИЕ: Кроме того, появился дополнительный поиск в Google Эта статья с полезной информацией и ссылками:
Вам следует провести несколько тестов по использованию вашего текущего диска с Perfmon. Если вы переходите на систему с большим объемом ОЗУ, вы, вероятно, увидите некоторое снижение использования диска (в результате увеличения объема памяти для кеширования SQL Server), но конкретный шаблон доступа ваших клиентов будет диктовать это. , в конечном итоге.
Очень быстрая и действительно грязная проверка - это захват «Физический диск - Диск байт / сек» с текущего сервера. Это даст вам «нижнюю границу» того, что вы хотите от новой дисковой технологии. Вы должны быть в состоянии получить от различных поставщиков iSCSI некоторые цифры пропускной способности своих решений и использовать их в качестве общей меры. Я видел, как SQL Server 2005 обеспечивает очень приемлемую производительность в двух разных средах VMware, где используются цели iSCSI. Опять же, решающим фактором будет производительность, необходимая вашему конкретному приложению.
Я видел пропускную способность iSCSI повсюду, в зависимости от того, насколько сложна сантехника. Однажды я увидел установку VMware ESX с файлами VMDK, размещенными на целевых объектах iSCSI, которые на самом деле являются файлами VHD, экспортируемыми машиной Windows Server 2003 Storage Server Edition через гигабитный Ethernet, причем эти файлы VHD хранятся на томах NTFS, поддерживаемых шкафом DASD, прикрепленным к серверный компьютер с встроенным в шкаф RAID-контроллером, управляющим четырнадцатью дисками SAS 146 ГБ. Как вы могли догадаться, он не показал выдающихся результатов. С другой стороны, я доволен пропускной способностью (хотя у меня нет под рукой числа, которое я могу вам назвать) массивов Dell EqualLogic, используемых на нескольких сайтах клиентов (до моего участия в в обоих случаях, поэтому я не указал и не выбрал их - я просто их использую).
Найдите лучшее решение, которое обеспечит вам необходимую производительность по той цене, которую вы хотите потратить. Обязательно используйте в своей оценке факторы, помимо производительности. (соображения гарантии и обслуживания, что происходит при выходе из строя диска, возможность динамического изменения размера тома, возможность расширения для дополнительных дисков / шкафов в будущем, возможность добавления сетевых адаптеров / пропускной способности и т. д.).
Я бы подумал, что ключевой метрикой Perfmon была длина дисковой очереди, а не дисковые байты / сек. iSCSI обладает высокой пропускной способностью, но имеет большую задержку по сравнению с напрямую подключенным хранилищем. Я никогда не использовал iSCSI для базы данных SQL, но, по моему опыту, в производительности SQL Server, как правило, преобладает произвольный доступ, а не последовательный доступ, и чем меньше задержка, тем лучше. В таком случае iSCSI - не очевидный выбор.
JR