Одна вещь, которая меня всегда озадачивала, - это передовые методы хранения. Файловые системы хвастаются тем, что они могут быть петабайтами или экзабайтами. Тем не менее, я не знаю многих системных администраторов, которые хотели бы, чтобы один том увеличивался до нескольких террабайт. Я знаю, что основная причина этого заключается в том, сколько времени потребуется на восстановление массива в случае отказа диска. Чем больше дисков в одном LUN, тем больше времени это займет и тем выше риск потери другого диска во время восстановления.
Тогда есть причины использования. Администраторы выделяют LUN в зависимости от того, сколько места, по их мнению, необходимо выделить для проекта. Мне кажется более практичным, чтобы LUN был одним большим массивом и использовал квоты. Я понимаю, что это не удовлетворяет всем требованиям (iSCSI), но я вижу, что многие системы NAS (NFS) управляются таким образом. Я также понимаю, что базовые тома можно довольно легко увеличивать / уменьшать по мере необходимости, но не будет ли менее «рискованным» использовать квоты, а не манипулировать томами и вносить возможные потери данных в уравнение?
Могут быть и другие причины, по которым я упускаю, поэтому, пожалуйста, просветите меня. Разве мы не можем ожидать, что файловые системы когда-нибудь будут такими большими? Мы ждем, когда оборудование станет быстрее, чтобы сократить время восстановления?
Восстановление диска зависит не от файловой системы, а от самого диска. Если вы использовали диски емкостью 2 ТБ, вам потребуется много времени на восстановление.
Восстановление - это проблема рейда 5. Для этого теперь могут контроллеры поддерживать рейд 6 или лучше, вы можете сделать рейд 10 (если вы хотите наилучшую производительность). Экспорт lun - это работа для SAN, экспорт файловой системы - это работа NAS.
У обоих есть свои плюсы и минусы (ищите в гугле, там куча статей). Создание множества независимых LUN (или файловых систем) дает преимущество создания резервных копий моментальных снимков.
Разделение шпинделя - хороший повод не иметь одного большого объема. Если вы используете Exchange, SQL Server и другие случайные вещи (возможно, гостевые системы ESXi) на одном устройстве NFS, вам наверняка понадобится разделение шпинделя. Данные обмена и длинные позиции должны быть на отдельных шпинделях друг от друга, а также базы данных и журналы SQL.
Лично я бы вообще не запускал настоящий корпоративный трафик (Oracle, MSSQL, Production ESX) через iSCSI или NFS - я знаю и доверяю FC как в плане общей производительности, так и в случае сбоев. Конечно, это означает, что я не могу просто создавать массивные LUN и разделять их, и это действительно создает довольно много сложностей / работы, но показатели доступности нашей системы и опыта конечного пользователя оказались лучше и более последовательными, чем мы надеялись.
Что касается вашего фактического ответа - ну, ваши сообщения кажутся очень ориентированными на NetApp / filer, отсюда и мой последний абзац, - но вы сами изложили причины. Дисковые интерфейсы значительно отстают от емкости диска - это означает, что время восстановления может быть нелепым, особенно если вы хотите увидеть достойную производительность во время восстановления существующего трафика. Диски все время умирают, и идея повлиять на производительность нескольких платформ во время перестройки, чтобы просто облегчить жизнь администратору, была бы действительно недолговечной. Также чисто с точки зрения безопасности платформы вы можете захотеть разделить свои системы, и подход «большого LUN» может не сработать в этом сценарии (конечно, на основе оборудования).
В конечном итоге Enterprise SAN по своей сути критичны для бизнеса или миссии, требуя доступности и согласованности, а не стоимости, простоты администрирования или даже максимальной производительности.