Мне нужно установить новый сервер с 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 может поглощать довольно большие рабочие наборы. Контроллеры SAN RAID обычно поддерживают больший объем кэш-памяти, чем контроллеры RAID на основе хоста, особенно в высокопроизводительном комплекте, где контроллер RAID может быть многопроцессорным устройством, столь же мощным, как и сервер.
Сети SAN с двумя контроллерами также имеют архитектуру без единой точки отказа и предлагают множество вариантов горячего резервирования. Это дает им преимущество с точки зрения управляемости и надежности. Однако они дороги и ограничены для потоковой передачи объемов данных, хотя последнее вряд ли станет проблемой для транзакционной системы.
Для операционных систем сети SAN почти всегда являются лучшим выбором, если таковые имеются. Они также могут использоваться несколькими серверами, на которых работают системы с низким и средним объемом. Однако они идут с ценой, которая значительно ограничивает минимальную систему, с которой может использоваться технология.
Прямое подключение
В некоторых случаях лучше всего использовать хранилище с прямым подключением. Одна из возможностей - приложения потоковой передачи с ограниченной полосой пропускания, в которых ограниченное количество соединений по оптоволоконному каналу ограничит доступную полосу пропускания до меньшего, чем это было бы возможно с помощью высокопроизводительного контроллера SAS. Однако, скорее всего, это будут довольно специализированные приложения, такие как очень большие хранилища данных, в которых ничего не поделено архитектура может обеспечить лучшую пропускную способность.
Фактически, хранилище с прямым подключением часто лучше, чем SAN для систем хранилищ данных по ряду причин:
Хранилища данных создают большие временные всплески нагрузки на дисковые подсистемы. Это делает их антиобщественными в сетях SAN, поскольку они могут влиять на производительность других систем в SAN.
Вышеупомянутое узкое место потоковой передачи.
Хранилище с прямым подключением намного дешевле хранилища SAN.
Другой рынок хранения с прямым подключением - это когда вы продаете на рынок, который не будет платить достаточно денег за SAN. Это часто относится к приложениям, продаваемым клиентам малого и среднего бизнеса. Для торговой точки или системы управления практикой, в которой будет шесть пользователей, SAN, вероятно, будет излишним. В такой ситуации гораздо более подходящим решением является небольшой автономный сервер в корпусе Tower с несколькими внутренними дисками.
Локальный или SAN - единственный способ сохранить производительность. В некоторых случаях SAN может быть быстрее, чем локальный диск, из-за большего размера кэша записи и конфигурации пропускной способности параллельного диска.
Избегайте высокопроизводительного ввода-вывода файлов через общие ресурсы Windows. Из-за большого количества накладных расходов на протокол пропускная способность значительно снижается. Например, несколько лет назад я измерил, что передача больших файлов по WAN была примерно на 50% быстрее при использовании FTP через общие ресурсы Windows.
При размере базы данных 2 ГБ нет причин даже рассматривать SAN. NAS не будет работать, вам следует подумать об использовании NAS только для резервного копирования, чтобы вы не хранили резервные копии на том же компьютере, что и ваши данные, и легко делать копии с NAS для хранения за пределами площадки.
С небольшой базой данных просто используйте локальные диски в RAID 1 или RAID 10. Если ваша база данных умещается в ОЗУ, вам не нужно так беспокоиться о производительности ввода-вывода. Используйте 64-битные окна и поместите туда 8 гигов. Это оставит много возможностей для ОС и даст вам возможность расти.
Не используйте NAS.
Либо используйте локальный (нормально в среднесрочной перспективе с хорошим контроллером RAID), но если позволяет бюджет, выберите приличную SAN. Если повезет, вы сможете начать «делить» SAN с другими системами и вернуть большую часть первоначальных затрат.
4 ГБ ОЗУ подходит для большинства систем, если это выделенный SQL-сервер (и так должно быть всегда). Если вы еще не рассматривали это, используйте 64-битную ОС и SQL-сервер, чтобы вы могли легко добавить больше оперативной памяти, не возясь с материалами PAE / AWE.
Также подумайте о виртуализации. Вам понадобится тестовый сервер? Сервер разработки? Протестируйте установку SP1? (Бесстыдный плюс за предыдущий пост: sql-сервер-в-VMware)
Я работаю с системами, которые используют как локальный 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 ГБ 15 000 об / мин, журналы RAID1 - 2x 73 ГБ 15 000 об / мин, резервные копии 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 Варуна Дхавана.
По крайней мере, технически возможен запуск SQL Server на NAS. Выбор зависит от многих факторов, и нетрудно представить себе ситуацию, когда хранилище для базы данных легко доступно на NAS.