Хранение научных данных: много маленьких файлов, один том или несколько?
У меня есть "выборочные" данные объемом около 8 ТБ со следующими характеристиками:
каждый образец: 5-15 ГБ в одной папке, содержащей ~20 КБ файлов и ~10 КБ подпапок (2000 верхнего уровня, 5 подуровней, содержащих файлы данных ~ 0,5-2 МБ и небольшие файлы настроек).
Я настраиваю сервер Dell T710 под управлением Windows server 2008 R2 с эффективным пространством 19 ТБ (RAID5) для консолидации данных. Ранее я наблюдал значительное замедление при открытии / просмотре / копировании на компьютере, на котором около 1,5 ТБ данных этого типа на выделенном внутреннем диске (NTFS).
Каждый образец будет скопирован на этот сервер для хранения, но анализ будет выполняться в другом месте (данные копируются с сервера). Таким образом, нет ежедневных изменений в существующих данных, просто новые данные.
Какова наилучшая конфигурация накопителя для обработки данных такого типа? Диск является GPT и в настоящее время имеет EFI, MSR, системный раздел 70 ГБ и пустой раздел данных 19 ТБ.
- один большой том 19 ТБ
- несколько меньших томов (меньше фрагментации?)
Было бы целесообразно создать zip-архив для каждого образца и сохранить его вместо этого? Я бы колебался из-за этого, потому что пользователи понимают папки интуитивно, а коррупция имеет худшие последствия для архивов - мы могли бы позволить себе несколько поврежденных подпапок (пример "пикселей", более или менее) в крайнем случае, но повреждая весь пример архива было бы плохо.
2 ответа
19 ТБ в одном томе RAID-5 ужасно велики. Вы не упоминаете, сколько дисков у вас в этом томе, но, будучи в Dell T710, я думаю, что, скорее всего, у вас есть более 1 ТБ на диск. Я начинаю нервничать с такими большими членами RAID-5. Если это один размах RAID-5, это еще страшнее для меня. (Мне не нравится промежуток больше 5 или 6 дисков, особенно с такими большими дисками.)
Помимо вашего выбора RAID-5, по моему опыту, это довольно большое количество файлов, которые нужно обрабатывать NTFS. Все, что вы можете сделать, чтобы уменьшить количество хранимых файлов, будет способствовать повышению производительности. Сжатие "образца", как вы описываете, радикально уменьшит количество файлов, которые вы просите NTFS обработать. В зависимости от того, насколько хорошо сжимаются ваши данные, вы также можете увидеть значительное увеличение производительности при передаче файлов по сети.
На мой взгляд, вам не стоит беспокоиться о "порче" данных. Если у вас недостаточно уверенности в том, что ваша система резервного копирования и основное хранилище будут работать без повреждения файлов, вам следует сконцентрироваться на усилении этих "базовых" компонентов. RAID-10 или RAID-50 был бы хорошим первым шагом к расширению основного хранилища. Поскольку вы не говорите о том, как вы делаете резервное копирование, я не могу говорить об этом.
Редактировать:
Я настороженно отношусь к RAID-5 для доступности. Основная статья об этом - Почему RAID 5 перестает работать в 2009 году. Суть в том, что частота появления битовых ошибок на больших дисках делает перестройку больших томов RAID-5 статистически маловероятной.
Если у вас есть другая копия данных вне сайта, то это, вероятно, меньше беспокоит. Вы должны подумать о том, что будет означать полную потерю тома RAID-5. Сможете ли вы раскрутить новый том и продолжить работу, пока вы заново копируете данные из сторонней копии? Вам нужно будет подождать, пока какое-то количество данных будет скопировано, прежде чем работа возобновится? Если будет простой, какая будет стоимость?
Вы потеряли место на диске, если у вас много маленьких файлов. Причина в размере блока вашей файловой системы. Мое первое предложение - использовать систему Linux для долгосрочной поддержки. И мое второе предложение - сохранить файлы без архивирования в файловой системе, потому что понимание системы гораздо важнее, если потерять несколько байтов. У меня была такая же проблема с геномными данными (анализатор дробовика). Мое третье предложение - использовать RAID10 или RAID50.