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