Вам нужно понять, что такое SAN.
SAN — это один или несколько массивов хранения, соединенных между собой сетью Fibre Channel. У вашего хоста есть специальные сетевые карты, называемые адаптерами главной шины (HBA), для связи с этой сетью. Сетевые протоколы предназначены для трафика хранилища и поэтому хорошо подходят для высокопроизводительного трафика с малой задержкой.
Массив, с которым вы разговариваете... ну, его возможности сильно различаются. Даже EMC SAN, как вы ее называете, может представлять собой множество продуктов EMC в качестве массива хранения. Их основная цель — консолидация производительности хранилища.
Вы получаете более высокую пиковую производительность при совместном использовании 100 шпинделей с 10 серверами, чем если бы каждый сервер имел по 10 шпинделей. То, что ваш массив хранения в основном делает, разделяет этот кусок из 100 шпинделей на логические единицы, а затем возвращает их вашему хосту, так что каждый хост имеет примерно одинаковое среднее значение производительность, но ее пик в 10 раз больше. (Или, возможно, более реалистично - они могут поставляться с 50 шпинделями, потому что тогда вы получаете 5-кратный пик, но половину стоимости в обмен на более низкое среднее значение).
Теперь - Файловые группы. Насколько я понимаю (будучи инженером по хранению, а не знающим SQL). Файловые группы позволяют управлять размещением данных, в частности, в базовом хранилище.
Это что-то вроде щекотливого момента - потому что это зависит. Как правило, ваш массив хранения будет делать некоторые довольно умные вещи, чтобы упростить размещение данных и пропускную способность. Такие вещи, как довольно агрессивное кэширование — гораздо больше, чем вы получите на обычном хосте — означает, что большая часть вашей рабочей нагрузки с произвольным доступом выполняется на «скорости ОЗУ», а не «скорости диска». Вполне возможно, что он будет чередовать гораздо больше шпинделей, чем вы обычно ожидаете.
Насколько я могу судить, это, по сути, то, к чему стремится файловая группа: вы вручную помещаете файл на диск и позволяете SQL обрабатывать параллельный ввод-вывод на эти диски. Ваш массив хранения уже делает это за вас, и в лучшем случае вы сделаете себе ненужную головную боль администратора, а в худшем вы фактически ухудшите оптимизацию на стороне массива.
Вы, вероятно, все еще хотите разделить различные типы контента, но я бы посоветовал вам сделать это с помощью разных LUN, выделенных из вашей SAN. Более того, вы не можете истощить пространство из одной базы данных, заполнив другую, но это также обеспечивает немного большую гибкость, когда дело доходит до создания моментальных снимков или клонов.
Что бы я предложил:
- поговорите с ребятами из вашего хранилища об ожидаемом профиле ввода-вывода вашей базы данных. (Ввод-вывод — это то, что дорого в SAN, и обычно базы данных используют его больше, чем «обычные» приложения)
- поместите каждый экземпляр в другой набор LUN - разделите БД, журналы и базу данных tempdb.
- В vmware вы можете получить «логические» диски в одном и том же хранилище данных. Если производительность критична, возможно, стоит передать данные через SAN LUN напрямую на хост.
И тогда не беспокойтесь об этом слишком сильно - если вы заметите конкретную проблему, должна быть возможность перенастроить/переместить отдельные LUN, чтобы улучшить ситуацию.
person
Sobrique
schedule
06.10.2014
