Файлова система Linux для великого файлового сервера

Мені хотілося б дізнатися від більш досвідчених людей, який найкращий вибір файлової системи використовувати для файлового сервера, який має більше 20 ТБ жорстких дисків. Особисто я завжди використовував EXT3 (ще в ті часи) і EXT4 (з моменту появи) [і колись ReiserFS 3, хоча це спричинило багато корупції даних] на моїх персональних комп’ютерах та на дисках BOOT і ROOT на "маленьких серверах".

Однак, оскільки інструменти EXT4 (хоча не сам EXT4) обмежений розділами 16 ТБ, це може бути не найкращим моїм ставкою. Розподіл буде Debian 6.0 (Squeeze) та / або Gentoo (остання версія), тому ядро ​​повинно бути досить недавнім (на Debian принаймні із задніми списками), тобто ядро ​​Linux> = 2.6.32.

Файловий сервер використовуватиметься для трьох цілей (і розділених розділів, оскільки ціль - зберегти дані "безпечно" і не дуже турбуватись про накладні витрати). Хоча всі диски повинні бути зашифровані за допомогою LUKS :

1. Медіа, завантаження та локальне сховище debian [У мене принаймні 6 машин працює Debian]> 20 ТБ (можливо подальше розділення між медіа, завантаженнями та сховищем Debian)
2. Дані (Документи, Фото, ...) ~ 4 ТБ БЕЗПЕЧНО (означає raid1 або raid6 + резервний диск)
3. Резервне копіювання> = 20 ТБ для резервного копіювання інших комп’ютерів у моєму гігабітному LAN (чи можете ви запропонувати програмне забезпечення, яке створює резервну копію всієї ОС, навіть якщо це Windows, BackupPC каже, що це робить, будь-які альтернативи?)

Швидка швидкість насправді не потрібна (паралельний доступ: максимум до 2 або 3 великих файлів, скажімо, відео), навіть якщо це "просто" 200 Мб / с читається з 10-ти жорсткого диска Raid6, я можу з цим жити.

Підсумовуючи, я шукаю надійну, масштабовану (тобто легко розширювану) файлову систему, яка підтримує більше 20 ТБ / розділ. Чим безпечніше і надійніше FS, тим краще. Апаратне забезпечення буде щонайменше чотирьохядерним (amd x4 630 або intel i5-2500k) і великою кількістю оперативної пам’яті (> 8 ГБ, можливо,> 16 ГБ), тому слід дотримуватися вимог до обладнання.

Мої ПК / сервер будуть підключені до ДБЖ (безперебійного живлення) у разі відключення електроенергії. Можливо, роблять медіа та резервні копії на окремих машинах (тобто на двох серверах).

Багато людей пропонують ZFS. Але ZFS доступний не так, як Linux, окрім запобіжника. Я б не рекомендував це для вашої ситуації, коли ефективність може бути важливою.

На жаль, ZFS ніколи не буде доступний як власний модуль ядра, якщо проблеми ліцензування якимось чином не розібрані.

XFS - це добре, але деякі люди повідомили про проблеми корупції, і я не можу це коментувати. Я грав з невеликими розділами XFS і не мав цих проблем, але не був у виробництві.

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

• Цілісність даних
• Басейни для зберігання
• L2ARC
• Висока ємність
• Копіювати при написанні
• Знімки та клони
• Динамічна смужка
• Змінні розміри блоків
• Створення легкої файлової системи
• Кеш керування
• Адаптивна витривалість
• Дедуплікація
• Шифрування

То як нам це обійти? Моя запропонована альтернатива, яка може відповідати вашій ситуації, - це розглянути нексента . Це ядро ​​Open Solaris з інструментами GNU, що працюють на вершині. Мати ядро ​​Open Solaris - означає мати доступний ZFS на всьому світі.

Спробуйте спробувати XFS, що добре відповідає вашим вимогам:

XFS - це 64-розрядна файлова система. Він підтримує максимальний розмір файлової системи 8 екбібайт мінус один байт, хоча це обмежується обмеженнями блоку, накладеними хост-операційною системою. У 32-бітних системах Linux це обмежує розмір файлу та файлової системи до 16 тебібайт.

Ваш найпростіший варіант - використовувати XFS. Багато поганого досвіду навколо XFS базується на старих версіях та технічних проблемах на робочому столі, які, на мою думку, не є актуальними для нових розгортань на сервері стандартної якості обладнання. Я написав повідомлення в блозі на цю тему, яке може допомогти вам розібратися в ситуації, що склалася. Є кілька зайнятих установок баз даних XFS із сотнями користувачів і терабайт даних, якими я допомагаю керувати. Вони всі на ядрі Debian Lenny (2.6.26) або пізнішої версії, і я не чув жодних натяків на проблеми з ними протягом багатьох років. Я б не використовував XFS з будь-яким раніше ядром, ніж це. Я чув деякі прямі повідомлення про те, що люди бачать дивну поведінку XFS ще, коли в системі не вистачає пам'яті чи дискового простору; Я цього ще не бачив.

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

Альтернативна ідея - просто використовувати більш безпечний і нудний ext3, прийняти обмеження 16TB і краще розділити речі, так що жодна файлова система не повинна бути такою великою.

Один нескінченний кінець, пов'язаний з виданнями журналів. Ви не говорили про те, як усі ці накопичувачі будуть підключені. Переконайтеся, що ви розумієте значення будь-якого кешування записів, яке знаходиться у вашому ланцюзі зберігання даних тут. Або відключіть його, або переконайтеся, що файлова система вимиває кеш-пам'ять. Я приховав деякі ресурси щодо цього в Надійному письмі, якщо це ще не те, що ви перевіряєте.

Приводи смоктати. RAID-масиви висмоктуються. Файлові системи смоктають. Трапляються численні збої. Я радий бачити, що ти вже думаєш про резервні копії; Перехід від хорошої до великої надійності на зберіганні вимагає більше, ніж просто RAID та кілька запасних накопичувачів. Надлишок коштує щось на кожному рівні, а гроші на обладнання та складність програмного забезпечення важко орієнтуватися. І слідкуйте за своїми очікуваними результатами. У той час як RAID-масив, як ви розглядаєте, легко зробить сотні МБ / с, все, що потрібно, - це два одночасних зчитувачі, які постійно шукають диск, щоб замість цього знизити лише кілька МБ / с. Я можу легко розчавити 24-дисковий масив RAID10 таким чином, що він забезпечує лише <5 Мб / с проти робочого навантаження з орієнтиром . Єдине, що там допомагає, - це переконатися, що ви переробите читання вгору, якщо можливо декілька потокових читачів.

Розгортання на 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. Просто клацніть максимальний розмір файлу для сортування та виберіть найбільш відповідний