Я разрабатываю решение для хранилища данных, и я новичок в вопросах конфигурации дисков, позвольте мне объяснить вам.
Наше хранилище распределено по 6 блокам хранения, каждый из которых имеет 5 дисковых массивов raid-1 и имеет 2 LUNS, определенных для каждого дискового массива, что в общей сложности составляет 48 LUNS (это соответствует рекомендациям Microsoft Fast Track для архитектур хранилищ данных).
Я хотел бы разделить свои данные, в других проектах, с которыми я работал раньше, мы всегда следовали правилу 1 раздел - 1 файловая группа. В рекомендациях Microsoft Fast Track рекомендуется создать файловую группу, а затем для этой файловой группы файл данных для каждого lun ... но я делаю вид, что у меня есть разделение на уровне недели ... если я применяю это правило, я думаю, что я получить слишком много файлов и сложный макет.
Я подумываю создать только одну файловую группу (с 48 файлами данных lun), но все же создать разделы, так как я хочу сохранить все преимущества разделов, таких как переключение разделов ... Этот сценарий не рекомендуется? Что ты предлагаешь?
Чтобы ответить на этот вопрос, нужно углубиться в Storage Geek. Заранее прошу прощения.
Причина, по которой Microsoft, кажется, предлагает 48 отдельных разделов, заключается по одной причине: максимальное распараллеливание в ОС для операций ввода-вывода. Имея 48 LUN, ОС должна поддерживать 48 отдельных очередей ввода-вывода, и эти очереди теоретически могут обслуживаться параллельно. Если один LUN работает особенно медленно (он выполняет тяжелую произвольную запись), он не задерживает доступ к другим LUN.
На современном оборудовании это небольшой процент при БОЛЬШОЙ головной боли с хранилищем. Если вы не знаете, что будете доводить хранилище данных до абсолютного верхнего предела, оно того не стоит. Современные карты RAID достаточно быстры, чтобы справиться с этим за вас. Наличие 4 LUN может принести пользу. 48 действительно может повредить.
В наши дни хранилище обычно характеризуется метрикой производительности операций ввода-вывода в секунду (I / O Ops). Каждый диск имеет свой собственный верхний предел для случайного ввода-вывода (колеблется от 90 до 180 на диск, в зависимости от числа оборотов в минуту и некоторых других параметров). Когда вы группируете диски вместе, например, в наборе RAID10, это количество операций ввода-вывода равно добавка. Набор RAID10 с 12 дисками будет иметь такую же емкость операций ввода-вывода, что и 6 пар Raid1, и не заставит вас создавать шесть отдельных файлов БД. Создав один большой набор RAID10, вы можете создать один большой файл БД, способный обрабатывать огромные объемы нагрузки.
Возвращаясь к тому, что я сказал во втором абзаце о медленном LUN, не удерживающем доступ к другим LUN, вот почему максимизация операций ввода-вывода для LUN имеет смысл. У него гораздо меньше шансов на блокировку, если у него достаточно накладных расходов на операции ввода-вывода. При создании большого массива RAID10 распараллеливание переносится на карту RAID, а не на операционную систему, что оставляет ОС свободной для других дел. Вы по-прежнему получаете преимущество распараллеливания и используете для этого выделенное оборудование.
Для серверов баз данных целесообразно хранить ввод-вывод файла данных и файла журнала на разных шпинделях. Точный процент из которых Отдам экспертам по SQL Server (Я не один), и, вероятно, это основано на вашей точной конфигурации и шаблонах использования. Поскольку это хранилище данных, вам понадобится много места для журнала для обработки массовых загрузок. Ввод-вывод журнала в значительной степени последовательный, при этом ввод-вывод данных в значительной степени случайен, поэтому максимальную производительность записи лучше всего найти, поместив журналы на разные шпиндели, чем файлы данных.
В вашем случае вы можете обойтись двумя LUNами. Большой набор RAID10 для ваших файлов данных и меньший набор RAID10 для ваших файлов журналов.