Linux файловая система для большого файлового сервера

Я хотел бы знать от более опытных людей, что было бы лучшим выбором файловой системы для файлового сервера, имеющего более 20 ТБ жестких дисков. Лично я всегда использовал EXT3 (в прежние времена) и EXT4 (с момента выхода) [и однажды ReiserFS 3, хотя это вызвало много повреждений данных] на моих персональных компьютерах и на дисках BOOT и ROOT «маленьких серверов».

Однако, поскольку инструменты EXT4 (хотя и не сам EXT4) ограничены разделами по 16 ТБ, это может быть не лучшим выбором. Дистрибутив будет Debian 6.0 (Squeeze) и / или Gentoo (последняя версия), поэтому ядро ​​должно быть довольно свежим (по крайней мере, в Debian с backports), что означает ядро ​​linux> = 2.6.32.

Файловый сервер будет использоваться для трех основных целей (а также для разделенных разделов, потому что цель состоит в том, чтобы сохранить данные «в безопасности» и не сильно заботиться о накладных расходах). Все диски должны быть зашифрованы с помощью LUKS :

1. Носители, файлы для загрузки и локальный репозиторий Debian [У меня есть как минимум 6 машин, на которых установлен Debian]> 20 ТБ (возможно, дальнейшее разделение между Media, Downloads и репозиторием Debian)
2. Данные (документы, фотографии, ...) ~ 4 ТБ БЕЗОПАСНО (имеется в виду raid1 или raid6 + резервный диск)
3. Резервные копии> = 20 ТБ для резервных копий других компьютеров в моей гигабитной локальной сети (можете ли вы предложить программное обеспечение, которое выполняет резервное копирование всей ОС, даже если это Windows, BackupPC говорит, что это делает, любые альтернативы?)

Быстрые скорости на самом деле не нужны (одновременный доступ: максимум 2 или 3 больших файла, скажем, видео), даже если это «просто» 200 МБ / с, считывающих с 10 HDD Raid6, с которым я могу жить.

Таким образом, я ищу надежную, масштабируемую (то есть легко расширяемую) файловую систему, которая поддерживает более 20 ТБ / раздел. Чем безопаснее и надежнее ФС, тем лучше. Используемое оборудование будет как минимум четырехъядерным (amd x4 630 или intel i5-2500k) и большим количеством оперативной памяти (> 8 ГБ, может быть> 16 ГБ), поэтому требования к оборудованию должны быть выполнены.

Мои ПК / Сервер будут подключены к ИБП (источник бесперебойного питания) в случае сбоя питания. Может выполнять резервное копирование и резервное копирование на отдельных компьютерах (то есть на двух серверах).

Многие люди предлагают ZFS. Но ZFS изначально недоступна в Linux, кроме как через fuse. Я не рекомендовал бы это для вашей ситуации, где производительность, вероятно, будет важна.

К сожалению, ZFS никогда не будет доступна в качестве собственного модуля ядра, если вопросы лицензирования не будут решены каким-либо образом.

XFS хорош, но некоторые люди сообщают о проблемах коррупции, и я не могу это прокомментировать. Я играл с маленькими разделами XFS и не имел этих проблем, но не в производстве.

ZFS имеет слишком много преимуществ и полезных функций, которые нельзя игнорировать. В итоге они (см. ZFS Wiki для полного описания того, что они означают):

• Целостность данных
• Бассейны для хранения
• L2ARC
• Высокая емкость
• Копирование при записи
• Снимки и клоны
• Динамическое чередование
• Переменные размеры блоков
• Создание облегченной файловой системы
• Управление кешем
• Адаптивный порядок байтов
• дедупликации
• Encrypion

Так как же нам обойти это? Моя предложенная альтернатива, которая может удовлетворить вашу ситуацию, - рассмотреть Nexenta . Это ядро ​​Open Solaris с инструментами GNU userland, работающими сверху. Наличие ядра Open Solaris означает наличие ZFS, доступной изначально.

Вы должны попробовать XFS, хорошо вписываясь в ваши требования:

XFS - это 64-битная файловая система. Он поддерживает максимальный размер файловой системы 8 exbibytes минус один байт, хотя это зависит от ограничений блоков, установленных операционной системой хоста. В 32-битных системах Linux это ограничивает размер файла и файловой системы до 16 ТБ.

Самый простой вариант - использовать XFS. Много плохого опыта вокруг XFS основано на старых версиях и проблемах аппаратного обеспечения настольных компьютеров, которые, я не думаю, действительно актуальны для новых развертываний на стандартном качественном серверном оборудовании. Я написал сообщение в блоге на эту тему, которое может помочь вам разобраться в текущей ситуации. Есть несколько загруженных баз данных XFS с сотнями пользователей и терабайтами данных, которыми я управляю Они все в ядре Debian Lenny (2.6.26) или более поздней версии, и я не слышал о проблемах с ними годами. Я бы не использовал XFS с любым более ранним ядром, чем это. Я слышал некоторые прямые сообщения о людях, которые видели странное поведение XFS, когда в системе не хватает памяти или дискового пространства; Я сам еще этого не видел.

Единственный другой разумный вариант - это использовать ext4 с некоторым взломом для поддержки более крупных файловых систем. Я не ожидал бы, что это будет иметь совсем другой уровень надежности. Мне приходилось восстанавливать данные из нескольких сломанных систем ext4, которые сталкивались с ошибками ядра, пока все они были исправлены в восходящем, но не в ядре дистрибьютора в то время. У ext4 есть свой собственный набор проблем метаданных, таких как потеря данных о отложенном распределении , что менее вероятно случится в ext3. Я бы оценил вероятность того, что вы столкнетесь с ошибкой ext4, будет даже выше, чем обычно, если вы превысите нормальный размер, просто потому, что, скорее всего, в какой-то момент вы столкнетесь с менее хорошо протестированным новым путем кода ,

Альтернативная идея состоит в том, чтобы просто использовать более безопасный и скучный ext3, принять ограничение в 16 ТБ и лучше разбивать разделы, чтобы ни одна файловая система не была такой большой.

Один свободный конец, связанный с проблемами журнала. Вы не говорили о том, как все эти диски будут подключены. Убедитесь, что вы понимаете смысл любого кэширования записи, которое находится в вашей цепочке хранения здесь. Либо отключите его, либо убедитесь, что файловая система очищает кэш. Я спрятал некоторые ресурсы об этом в Reliable Writes, если вы еще не проверяли это.

Диски отстой. RAID массивы отстой. Файловые системы отстой. Многочисленные сбои случаются. Я рад видеть, что вы уже думаете о резервных копиях; Переход от хорошей к высокой надежности хранилища требует больше, чем просто RAID и некоторые запасные диски. Избыточность стоит чего-то на каждом уровне, и деньги на аппаратное обеспечение и сложность программного обеспечения сложно найти. И следите за вашими ожиданиями. В то время как RAID-массив, который вы рассматриваете, легко может работать с сотнями МБ / с, все, что требуется, - это два параллельных считывателя, постоянно ищущих диск, чтобы уменьшить его до нескольких МБ / с. Я легко могу разбить массив RAID10 на 24 диска, так что он обеспечивает производительность <5 МБ / с по сравнению с эталонной рабочей нагрузкой . Есть одна вещь, которая помогает в этом - убедиться, что вы настраиваете readahead вверх, если возможно несколько потоковых ридеров.

Развертывание на ZFS с использованием FreeBSD может происходить здесь с использованием gbde для шифрования. Сам ZFS будет поставщиком программного RAID, через RAIDZ . Сложность управления хранилищем при создании zpools существенно не отличается от того, что Linux собирается передать вам с помощью mdadm, а в некоторых случаях будет на самом деле проще. Моя первая установка ZFS (на Solaris 10 около 3 лет назад) имела файловую систему 17 ТБ и более 48 дисков. Там я без проблем пережил множество сбоев, изучая управление ZFS.

Главный плюс в том, что контрольная сумма ZFS обеспечивает лучшее обнаружение ошибок, чем Linux, что является защитой от плохого оборудования, которое стоит рассмотреть. Основным недостатком FreeBSD является то, что он менее популярен. Вы еще не знаете, как его администрировать, аппаратная поддержка немного слабее, чем в Linux, и, поскольку это менее популярная платформа, не так много людей обращаются за помощью, если вы столкнетесь с проблемами.

Массив хранения в несколько терабайт действительно показывает, в чем хорош ZFS. Стоит серьезно подумать, хотите ли вы окунуться в что-то новое. Если вы хотите исследовать настоящую паранойю резервного копирования, создайте серверы резервного копирования Linux и FreeBSD, чтобы уменьшить вероятность ошибок ОС в качестве единой точки отказа.

В соответствии с странице сравнения файловой системы Википедии , есть много известных файловых систем, которые удовлетворяют вашим потребностям, таких как JFS, XFS, UDF, ZFS, GPFS и Btrfs. Просто нажмите на максимальный размер файла, чтобы отсортировать и выбрать наиболее подходящий