Файлы SQL Server Локальные или NAS или SAN?

Я должен установить новый сервер с SQL Server 2008, что вы рекомендуете, один сервер с Raid 10 или файлы в NAS?

Как насчет iSCSI, я должен его использовать?

Что насчет SAN?

Сервер имеет 4 ГБ ОЗУ, а размер файла базы данных составляет около 2 ГБ.

Чтобы понять, что сегодня на сервере нет RAID-массива, я должен реализовать какую-то стратегию, чтобы, если что-то случилось, я мог сохранить свои файлы в безопасности, так что мне выбрать Local Files, NAS, SAN? Какой вариант имеет наибольшую производительность, а какой более безопасный?

NAS

Определенно не NAS для SQL Server. SMB / CIFS не имеет адекватной поддержки блокировки файлов для поддержки СУБД (по крайней мере, несколько лет назад, около 2002-2003). Обратите внимание, что NFS делает, и вы можете сделать это с Oracle на сервере NFS. Однако SQL Server на общем ресурсе CIFS ненадежен из-за ограничений протокола. Это может даже не позволить вам поместить файлы на смонтированные общие ресурсы CIFS.

SAN

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

Сети SAN с двумя контроллерами также имеют архитектуру без единой точки отказа и предлагают множество вариантов оперативного резервного копирования. Это делает их победой с точки зрения управляемости и надежности. Однако они дороги и ограничены для потоковых объемов данных, хотя последние вряд ли будут проблемой в транзакционной системе.

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

Прямое присоединение

В некоторых случаях лучше использовать хранилище с прямым подключением. Одна из возможностей - потоковые приложения с ограниченной пропускной способностью, где ограниченное количество соединений по оптоволоконному каналу будет ограничивать доступную пропускную способность меньше, чем это возможно с высокопроизводительным контроллером SAS. Тем не менее, это, вероятно, будут довольно специализированные приложения, такие как очень большие хранилища данных, где архитектура без общего доступа может обеспечить наилучшую пропускную способность.

На самом деле хранилище с прямым подключением часто лучше, чем SAN для систем хранилищ данных по ряду причин:

• Хранилища данных создают большие скачки переходной нагрузки на дисковые подсистемы. Это делает их довольно антисоциальными в сетях SAN, поскольку они могут влиять на производительность других систем в сети SAN.

• Вышеупомянутое потоковое узкое место.

• Хранилище с прямым подключением намного дешевле, чем хранилище SAN.

Другой рынок для хранилищ с прямым подключением - это когда вы продаете на рынок, который не будет платить достаточно денег за SAN. Это часто относится к приложениям, продаваемым клиентам SMB. Для системы торговой точки или системы управления практикой, в которой будет шесть пользователей, SAN, вероятно, является излишним. В такой ситуации небольшой автономный сервер Tower с некоторыми внутренними дисками является гораздо более подходящим решением.

Локальный или SAN является единственным способом поддержания производительности. В некоторых случаях SAN может работать быстрее, чем локальный диск, из-за большего размера кэша записи и конфигурации пропускной способности параллельного диска.

Избегайте любых высокопроизводительных файловых операций ввода-вывода через общие папки Windows. Существует большое количество протоколов, которые значительно замедляют пропускную способность. Например, несколько лет назад я измерял передачу больших файлов по глобальной сети на ~ 50% быстрее при использовании FTP через общие папки Windows.

Не используйте NAS.

Либо используйте локальный (хорошо для среднесрочной перспективе с хорошим RAID-контроллером), но если бюджет позволяет, перейдите на приличную SAN. Если повезет, вы можете начать «делиться» SAN с другими системами и вернуть большую часть первоначальных затрат.

4 ГБ ОЗУ подходит для большинства систем, если это выделенный сервер SQL (и так должно быть всегда). Если вы еще не рассматривали это, используйте 64-битную ОС и сервер SQL, чтобы вы могли легко добавить больше оперативной памяти, не занимаясь при этом вещами PAE / AWE.

Также подумайте о виртуализации. Вам нужен тестовый сервер? Сервер разработки? Протестировать установку SP1? (Бесстыдный плюс для предыдущего поста: sql-server-in-vmware )

При размере базы данных 2 Гб нет причин даже рассматривать SAN. NAS не будет работать, вам следует подумать только об использовании NAS для резервного копирования, чтобы не хранить резервные копии на том же компьютере, на котором хранятся ваши данные, а также легко создавать копии из NAS для хранения вне сайта.

При небольшой базе данных просто используйте локальные диски в RAID 1 или RAID 10. Если ваша база данных помещается в ОЗУ, вам не нужно беспокоиться о производительности ввода-вывода. Используйте 64-битные окна и поместите туда 8 гигов. Это оставит много для ОС и даст вам возможность расти.

Я работаю с системами, которые используют как локальный RAID-диск, так и SAN с оптоволоконным подключением. SAN, кажется, работает лучше, даже если первый - более новая и быстрая машина. Я думаю, что существенным фактором является то, что локальное расположение дисков - это один диск, поэтому SQL совместно использует дисковый ввод-вывод с ОС и файлом подкачки. Это, вероятно, вносит большой вклад в сопротивление.

Как отметил @spoulson, SAN может обеспечить гораздо лучшую производительность диска. Это не только отдельный диск, но, скорее всего, на гораздо более быстром оборудовании диска.

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

Единственное предостережение, с которым мы столкнулись, заключается в том, что назначение дискового пространства SAN обрабатывается консервативно. Потому что это дорого, они не делают это по прихоти. С помощью EMC SAN, которую мы используем, вы не можете освободить назначенное пространство без сброса всего LUN. Поэтому, если мы обнаружим, что выделенное пространство больше, чем нам нужно, и мы хотим использовать часть этого пространства для другого LUN, мы не сможем просто уменьшить слишком большое. Мы должны отбросить его и переназначить. Это не так хорошо работает в производственной среде.

Как и предполагали другие, избегайте NAS. Вы также можете поместить свои файлы данных на внешний жесткий диск USB.

Для небольшой базы данных объемом 2 ГБ SAN будет излишним.

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

Тем не менее, не идите и создайте один том RAID-10 и поместите ВСЕ файлы базы данных на него. Вы можете начать с чего-то простого, такого как: данные - 2x 73 ГБ 15K RPM, журналы RAID1 - 2x 73 ГБ 15K RPM, резервные копии RAID1 - один большой 7200 об / мин или пара в RAID1

Если у вас есть бюджет для обновления, добавьте еще один отдельный том для TempDB (если вы выполняете какие-либо сложные отчеты / аналитические запросы) или предоставьте журналу больше дисков и настройте его как RAID10, если в вашей системе больше транзакций с большим объемом обновлений.

SAN, вероятно, будет стоить в 3-4 раза больше, чем хранилище с прямым подключением для эквивалентного количества дисков. Сети SAN предоставляют множество расширенных возможностей для резервного копирования / создания снимков, поддержки кластеризации, а также миграции и расширения LUN. Если они важны для вас, это может стоить дополнительных расходов.

Отказ от ответственности: существует много серьезных проблем с хранением файлов базы данных SQL Server на NAS. При прочих равных условиях правильно выбрать опцию SAN. Подробное обсуждение соответствующих вопросов находится в MS KB304261 . Тем не менее, этот поток стал уловкой для других вопросов, касающихся SQL Server на сетевом ресурсе, я бы лучше опубликовал ссылки на состояние поддержки NAS в версиях SQL Server.

Немногие люди сейчас экспериментируют с использованием NAS с MS SQL.

Раньше это было запрещено по умолчанию, однако можно было снять ограничение в MS SQL 2008 и MS SQL 2005. Начиная с MS SQL 2008 R2 такого ограничения нет.

В MS SQL 2005 и 2008 ключом является флаг трассировки, запрещающий использование общих сетевых ресурсов. Можно выпускать

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Больше подробностей в сентябрьском посте 2010 года в блоге MSDN Varun Dhawan.

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