Какое хранилище лучше для SQL Server 2000?

Question

Я хочу получить доступ к файлам базы данных сервера sql в хранилище INTEL SS4000-E. Это хранилище NAS. Может ли быть возможно работать с ним как хранилище для SQL Server 2000? Если нет, то какое решение лучше?

Answer 1

Моя внутренняя реакция - я думаю, что вы безумно рискуете своими данными на NAS. SQL ожидает непрерывного непрерывного доступа с низкой задержкой к вашей подсистеме хранения. NAS почти наверняка не является ни тем, ни локальным хранилищем, ни хранилищем SAN (в порядке производительности, простоты и, следовательно, предпочтений), оставляя NAS для автономного хранения / резервного копирования файлов.

В следующем КБ перечислены некоторые ограничения и проблемы, с которыми вы можете столкнуться, пытаясь использовать NAS с SQL - хотя КБ охватывает SQL 7–2005, большая часть информации по-прежнему относится и к SQL 2008.

http://support.microsoft.com/kb/304261

Answer 2

Я настоятельно рекомендую против этого.

Поместите ваши файлы данных локально на сам сервер с помощью зеркальных дисков RAID. Причины двоякие:

• SQL Server будет работать намного быстрее для всех, кроме самых маленьких рабочих нагрузок
• SQL Server будет гораздо менее подвержен повреждению в случае разрыва связи с NAS.

Используйте NAS для хранения резервных копий вашего SQL Server, а не для размещения ваших файлов данных. Я не знаю, какой будет размер вашей базы данных или каков будет ваш шаблон использования, поэтому я не могу сказать вам, что вы ДОЛЖНЫ иметь. Как минимум, для базы данных, которая будет нести значительную нагрузку в производственной среде, я бы порекомендовал два логических диска (один для данных, один для журнала транзакций), каждый из которых состоит из массива RAID 1 из самых быстрых дисков, которые вы можете перенести покупать. Если это излишне, поместите вашу базу данных только на два физических диска (один для журнала транзакций, а другой для данных). Если даже это превышает бюджет, поместите данные на один диск, часто выполняйте резервное копирование. Но если вы выбираете решение для одного диска или NAS, IMO вы верите в силу молитвы (что может быть не плохо, но не очень эффективно при разработке баз данных).

Обратите внимание, что NAS - это не то же самое, что SAN (на котором люди обычно размещают файлы базы данных). NAS обычно намного медленнее и имеет гораздо меньшую пропускную способность, чем SAN-соединение, которое разработано для очень высокой надежности, высокой скорости, расширенного управления и низкой задержки. NAS больше ориентирован на снижение стоимости сетевого хранилища.

Answer 3

Как указывают другие ответы, здесь будет снижение производительности.

Стоит также упомянуть, что эти вещи иногда реализуют кэш ОЗУ для улучшения производительности ввода-вывода. Если это так, и вы пробуете эту конфигурацию, NAS должен быть на той же защите питания / ИБП, что и серверное оборудование. в противном случае в случае отключения питания NAS может «потерять» часть файла в кеше. ой!

Answer 4

Что ж, «лучший» означает разные вещи для разных людей, но я думаю, что «лучшая» производительность - это TMS RAMSAN или RAID-массив SSD ... и т.д.

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

Наилучшей надежности и безопасности данных можно достичь с помощью зеркалирования на многих дисках и регулярного резервного копирования (предпочтительно вне сайта) ...

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

Для обеспечения максимальной безопасности требуется шифрование, но в основном достаточно ограничить физический доступ к машине (и к ее резервным копиям), если она не подключена к Интернету.

Answer 5

Может работать, но SAN, подключенный к выделенному волокну, будет лучше.

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

Я не знаком с оборудованием, но мы изначально развернули склад на общем NAS. Вот что мы нашли.

Мы регулярно боролись за ресурсы на головном устройстве - пропускная способность была настолько большой, что он мог справиться. Массовые запросы к хранилищу данных и загрузка данных были сильно затронуты.

Нам потребовалось 1,5 ТБ для нашего хранилища (данных / индексов / журналов), мы поместили каждый из этих ресурсов в отдельный набор LUNS (как вы могли бы сделать с подключенным хранилищем). Данные охватывали всего 10 дисков. С этим мы столкнулись с множеством узких мест в IO. лучшим решением было создать один большой раздел на множестве маленьких дисков и хранить данные, индексы и журналы в одном месте. Это значительно ускорило процесс.

Если вы имеете дело с умеренно используемой системой OLTP, возможно, вы в порядке, но NAS может быть проблематичным.

Answer 6

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

Ваша производительность для sql будет зависеть от того, как определяются ваши объекты, файлы и файловые группы и как потребители используют данные.