Локальні файли SQL Server або NAS або SAN?

Мені потрібно встановити новий сервер із SQL Server 2008, що ти рекомендуєш, один сервер з Raid 10 або файли в NAS?

Що з iSCSI я повинен ним використовувати?

Що з SAN?

Сервер має 4 Гб оперативної пам’яті, і цей файл бази даних становить близько 2 ГБ.

Щоб сьогодні я зрозумів, що на сервері немає RAID, я повинен реалізувати якусь стратегію, тому якщо щось трапиться, я можу захистити свої файли, і що я повинен вибрати локальні файли, NAS, SAN? Який варіант має найбільшу продуктивність, який безпечніший?

НАН

Однозначно не 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. Це часто стосується програм, що продаються клієнтам SMB. Для системи продажу торгових точок або системи управління практикою, яка матиме шість користувачів, SAN, ймовірно, буде надмірним. У такому випадку невеликий автономний сервер вежі з деякими внутрішніми дисками є куди більш підходящим рішенням.

Місцевий або SAN - єдиний спосіб підтримати продуктивність. У деяких випадках SAN може бути швидшим, ніж локальний диск через більший кеш запису та конфігурацію пропускної здатності паралельного диска.

Уникайте робити якісь високопродуктивні файли вводу / виводу над спільними ресурсами Windows. Існує велика кількість накладних витрат на протокол, що різко сповільнить пропускну здатність. Наприклад, роки тому я вимірював велику передачу файлів через WAN на ~ 50% швидше, використовуючи FTP через спільний доступ до Windows.

Не використовуйте NAS.

Або використовуйте локальний (нормально середньостроковий з хорошим RAID-контролером), але якщо бюджет дозволяє, займіться гідним SAN. Якщо пощастити, ви можете почати "ділитися" SAN з іншими системами і відшкодувати більшу частину початкових витрат.

4 Гб оперативної пам’яті чудово підходить для більшості систем, якщо це виділений SQL Server (і він повинен бути завжди). Якщо ви ще не розглядали це питання, використовуйте 64-бітну ОС та SQL-сервер, щоб ви могли легко кинути більше оперативної пам’яті, не замислюючись з елементами PAE / AWE.

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

При розмірі бази даних 2Gb немає жодних підстав навіть вважати SAN. NAS не працюватиме, вам варто лише думати про використання NAS для резервного копіювання, щоб ви не зберігали резервні копії на тій же машині, що і ваші дані, і легко робити копії з NAS для зберігання поза межами сайту.

Маючи невелику базу даних, просто використовуйте локальні диски в RAID 1 або RAID 10. Якщо ваша база даних вміщається в оперативній пам’яті, вам не доведеться так сильно переживати про продуктивність IO. Використовуйте 64-бітні вікна та покладіть туди 8 гігів. Це залишить багато для ОС і дасть вам можливість рости.

Я працюю з системами, які використовують як локальний диск RAID, так і мережевий SAN. Здається, SAN працює краще, навіть коли колишня машина є більш новою та швидшою. Я думаю, що важливим фактором є те, що локальна дискова схема є єдиним накопичувачем, тому SQL обмінюється дисковим введенням-виведенням з ОС та файлом swap. Це, ймовірно, в значній мірі сприяє зносу.

Як згадував @spoulson, SAN може забезпечити набагато кращі показники диска. Мало того, що це окремий накопичувач, але, ймовірно, на набагато швидшому апаратному диску.

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

Єдине застереження, з яким ми боролися - це те, що призначення дискового простору SAN обробляється консервативно. Тому що це дорого, вони не збивають його з примхи. З використанням EMC SAN, який ми використовуємо, ви не можете повернути призначений простір без скидання цілого LUN. Отже, якщо ми знаходимо, що виділений простір більше, ніж нам потрібно, і ми хочемо використати частину цього простору для іншого LUN, ми не можемо просто зменшити великий розмір. Треба кинути його і перепризначити. У виробничих умовах це не так добре.

Як пропонують інші, уникайте NAS. Ви також можете поставити свої файли даних на зовнішній жорсткий диск USB.

Для невеликої бази даних 2 ГБ SAN буде надмірним.

Взагалі кажучи, ви не хочете, щоб ваші диски SQL ділилися з будь-яким іншим додатком. Крім того, чим більше шпинделів (дисків) ви можете розповсюджувати свої файли, тим краще. Знову ж таки, з невеликою базою даних, як ви описуєте, ви зможете вмістити все необхідне в оперативній пам’яті, тому продуктивність диска буде меншим фактором.

З цього приводу не створюйте єдиного тома RAID-10 і не ставте на нього ВСІ файли вашої бази даних. Ви можете почати з чогось простого, як-от: Дані - 2х 73 Гб 15 Кб RPM, Журнали RAID1 - 2х 73 ГБ 15 Кб / мін, Резервні копії RAID1 - один великий 7200 RPM або пара в 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.