Группы файлов базы данных SQL Server в сети хранения данных: актуальны или нет?
Я собираюсь создать новый SQL Server, и я планировал широко использовать файловые группы. Я ожидаю значительного роста и интенсивного чтения / записи в 5 различных базах данных на этом сервере. Я планировал создать 2 дополнительные группы файлов (одну для пользовательских данных и одну для индексов) для каждой базы данных, всего 3 группы файлов для каждой базы данных. Я планировал разделить файловые группы по разным дискам / шпинделям. Этот сервер является виртуальным сервером (VMWare) в сети EMC SAN. Я новичок в архитектуре SAN и не являюсь администратором SAN. В книге "Microsoft SQL Server 2012 Unleashed" я прочитал краткое описание групп файлов и сетей SAN, в которых группы файлов, скорее всего, не имеют значения при использовании сетей SAN. К сожалению, там было не так много подробностей, и я больше ничего не нашел по этой теме.
Есть ли смысл использовать файловые группы при использовании SAN для хранения?
Если нет, то почему? Если так, то почему?
Какие вопросы я могу задать моему администратору SAN по этой теме?
1 ответ
Вам нужно понять, что такое SAN.
SAN - это один или несколько массивов хранения, связанных через сеть Fibre Channel. Ваш хост имеет специальные сетевые карты - называемые адаптерами шины (HBA) - для связи с этой сетью. Сетевые протоколы предназначены для трафика хранилища и поэтому хорошо подходят для высокопроизводительного трафика с низкой задержкой.
Массив, с которым вы разговариваете... ну, он сильно зависит от его возможностей. Даже сеть EMC SAN, если вы на нее ссылаетесь, может представлять собой целый ряд продуктов EMC в качестве массива хранения. Их основная цель - консолидация производительности хранилища.
Вы получаете лучшую пиковую производительность из 100 общих шпинделей с 10 серверами, чем если бы на каждом сервере было по 10 шпинделей на каждом. Итак, в основном ваш массив хранения выполняет разделение 100 шпинделей на логические единицы, а затем возвращает их обратно вашему хосту, так что каждый хост имеет примерно одинаковую среднюю производительность, но его пик в 10 раз больше. (Или, может быть, более реалистично - они могут пойти с 50 шпинделями, потому что тогда вы получите 5-кратный пик, но половину стоимости, взамен более низкого среднего).
Теперь - Файловые группы. Насколько я понимаю (будучи инженером-хранителем, а не разбираясь в SQL). Файловые группы позволяют вам управлять размещением данных, особенно в базовом хранилище.
Это что-то вроде щекотливого момента - потому что это зависит. Как правило, ваш массив хранения будет делать некоторые довольно умные вещи для оптимизации размещения данных и пропускной способности. Такие вещи, как довольно агрессивное кеширование - гораздо больше, чем на обычном хосте, - это означает, что большая часть вашей работы с произвольным доступом идет с "скоростью ОЗУ", а не "скоростью диска". Вполне возможно, что он разбросан по гораздо большему количеству шпинделей, чем вы обычно ожидаете.
Что, насколько я могу судить, - это, по сути, цель файловой группы - достичь этого - вы вручную помещаете файл на диск и позволяете SQL обрабатывать параллельный ввод-вывод для этих дисков. Ваш массив хранения уже делает это для вас, и в лучшем случае вы избавите себя от ненужной головной боли администратора, а в худшем случае вы фактически ухудшите оптимизацию на стороне массива.
Вы, вероятно, все еще хотите разделить различные типы контента, но я бы посоветовал вам сделать это с помощью разных LUN, выделяемых из вашей SAN. Более того, вы не можете использовать пространство из одной базы данных, используя другую заливку, но это также обеспечивает немного большую гибкость, когда дело доходит до создания снимков или клонов.
Что бы я предложил:
- поговорите с ребятами из вашего хранилища об ожидаемом профиле ввода-вывода вашей базы данных. (IO - это то, что дорого для SAN, и обычно базы данных используют его больше, чем "обычные" приложения)
- поместите каждый экземпляр в другой набор LUN - выделите базу данных, журналы и базу данных tempdb.
- В vmware вы можете получить "логические" диски в одном хранилище данных. Если производительность критична, возможно, стоит пройти через SAN LUN напрямую к хосту.
И затем не беспокойтесь об этом слишком сильно - если вы заметили конкретную проблему, должна быть возможность перенастроить / переместить отдельные LUN вокруг, чтобы улучшить ситуацию.