Чи є користь мати NAS з ECC пам'яттю і файловою системою ZFS, коли я працюю на системах, в яких немає жодної?

Нещодавно я прочитав деякі тривожні статистичні дані про рівень корупції в системах з ОЗП не-ECC і типовими файловими системами. З того, що я можу Google, наявність системи з оперативною пам'яттю ECC, що працює з ZFS, ймовірно, є найкращим способом запобігти корупції. Більша частина цієї інформації була в контексті обговорень NAS.

Я бачу, як використання такої системи буде корисним для архівування файлів, припускаючи, що вони ще не пошкоджені на вихідній машині і чудово передаються по мережі.

Те, що я не зміг Google, полягає в наступному: який сенс мати максимально надійні файли NAS (або резервні), коли я працюю з файлами на менш надійних комп'ютерах? Я також не в змозі знайти хорошу інформацію про виправлення помилок в Samba (незалежно від останньої версії в ZFS-здатних ОС, як FreeNAS або OpenIndiana) - якщо це взагалі схильні до помилок, то майже все інше безглуздо (якщо я особисто хеш і перевірити всі перекази).

Чи потрібно (образно) викинути свої поточні системи і замінити їх на (міні) серверне обладнання, якщо я не хочу турбуватися про трохи гнилі і т.д.? І якщо я переходжу цей маршрут, чи можу я розумно розраховувати на наявність ресурсів для будь-яких можливостей, крім запуску ZFS? Не витрачаючи тисячі доларів?

Моє використання:

Мене цікавить більше, ніж просто відтворення (наприклад, фільмів та інших медіа). Я часто працюю над програмуванням на моїх домашніх комп'ютерах. Наприклад, у мене постійно зростає кількість файлів баз даних SQLite для різних проектів. Наявність однієї з них може стати проблемою. У мене також є багато гігабайт сімейних і відпусток фотографій, які я не тільки хочу архівувати, але й організувати, позначити тощо. їх «мовчки корумпують».

Те, що я не зміг Google, це: який сенс мати максимально   Надійні файли NAS (або резервні), коли я працюю з файлами на менше   надійних комп'ютерів?

Імовірність того, що щось піде не так, накопичується.

Іншими словами (і з фальшивими номерами):
Якщо є шанс на 10%, помилка на NAS і
Якщо 10% шансів на помилку в іншому пристрої,
Тоді у вас є 20% шанс невдачі при читанні чогось з NAS і відтворення його на іншому пристрої.

Я також не можу знайти хорошу інформацію про виправлення помилок у Samba

Яка версія samba. Протоколи трохи змінювалися між трьома версіями.

якщо це взагалі схильні до помилок, то практично все інше не має сенсу (хіба що   Я особисто хешу все і перевіряю всі перекази).

Існує ризик помилок. Це просто відбувається. Вони також виявляються та виправляються (наприклад, за допомогою контрольних сум). Це не завжди вірно, коли використовується оперативна пам'ять, що можна поліпшити за допомогою паритету та / або ECC. Проте ці проблеми є відносно малоймовірними, і ви повинні знайти баланс між золотим (і дорогим) дизайном і "досить хорошим".

Для деяких з нас цей баланс буде зовсім іншим (наприклад, банки потребують речей). Вони, ймовірно, не гарантують використання ECC на особистих системах, призначених для відтворення фільмів.

Підключення:

Я спробував прочитати документацію на веб-сайті Samba, але не зміг визначити, чи має Samba виправлення помилок. Я повинен був припустити найгірший випадок - що Samba покладається на базову мережу, щоб бути без помилок. Якщо ця базова мережа є TCP / IP, то, здається, єдиним захистом є слабка контрольна сума.

Я почав працювати з iSCSI, оскільки він підтримує додаткові дайджести заголовків і даних, які використовують алгоритм CRC32C. Це більше, ніж перевірка TCP / IP.

Чи є користь?

Для мене відповідь: "Так, принаймні в одному сценарії". Я можу створювати резервні копії файлів на серверному ZFS-машині за допомогою програми, якій я довіряю. Тоді я можу періодично перевіряти чи нібито незмінені файли на оригінальній машині насправді незмінений. Якщо є невідповідність, я можу відновити резервне копіювання з сервера.

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

Заміна комп'ютера на сервер, достатньо потужний для запуску ZFS, і ресурси, що залишилися для мого основного комп'ютера?

Можливо, але було б надзвичайно дорого. Я задоволений сценарієм, описаним вище, тому я не буду намагатися цього.

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

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

Значна частина того, що робить ZFS настільки чудовим для зберігання даних, про які вам цікаво, полягає в тому, що ви можете налаштувати його так, як можна виявити і правильно помилки при зберіганні. Це можуть бути тривіальні помилки, наприклад, один біт, або катастрофічні помилки, як декілька дисків, які збігаються відразу. До тих пір, поки ви перебуваєте вище порогового рівня резервування для вашого сховища (наприклад, не більше двох дисків, які одночасно відчувають проблеми в raidz2 vdev), ZFS може виправити будь-яку помилку за допомогою надлишкових даних. Подальші помилки, залежно від того, де і як вони відбуваються, можуть призвести до (напів-) витонченої системної паніки або простої помилки вводу-виводу.

Якщо ви зробите це правильно, ви також налаштуєте систему, щоб регулярно пробирати пул (и) ZFS. Це призведе до виникнення деградації, перш ніж вона стане проблемою, і сповістить вас про це, щоб розглянути можливість заміни пристроїв зберігання даних, які мають проблеми із збереженням даних, перш ніж це стане проблемою.

Проте, що велич залежить від того, що RAM можна довіряти. Все це перевірка, корекція, перезапис і так далі відбувається в основному в оперативній пам'яті. На серверах високого класу ви не знайдете нічого, крім оперативної пам'яті ECC.

ZFS захищає (і обробляє) метадані пулу, метадані файлової системи та дані користувача так само. Тут немає різниці.

Якщо ваша робоча станція перевертає біт RAM, тоді, коли ви пишете бітові дані до ZFS, дані, що перевертаються, будуть основою для того, що ZFS врешті-решт запише на диск. Це, очевидно, погано, тому що це означає, що ваш файл буде пошкоджено. Однак, дані, що перевертаються, будуть виправте, що стосується ZFS . Це насправді добре , тому що це означає, що всі нормальні методи відновлення ZFS працюватимуть. Так, остання копія цього файлу буде пошкоджена, але воно все одно було б пошкоджено, незалежно від того, яку файлову систему ви використовували. Ви можете використовувати знімки ZFS щоб принаймні мати можливість повернутися в часі до непошкодженої копії. Налаштуйте щось подібне zfs-auto-snap знімати ваші файлові системи регулярно, закриваючи проміжки часу, тримати грубу історію в зворотному напрямку і забути про неї, доки вони не будуть потрібні. (Наприклад, тримайте десять знімків на десять хвилин один від одного; 50 знімків на одну годину, 30 знімків через шість годин і так далі.) Знімки практично вільні в ZFS; якщо ви використовуєте ZFS, використовувати знімки так само.

Якщо ваш сервер зберігання даних, що працює з ZFS, відчуває погану оперативну пам'ять, будь то фліп-біт або застряглий (один або кілька) біт, і у вас є ECC RAM на сервері зберігання, це буде виявлено, і подія буде зареєстрована або система буде зупинити (якщо помилку не можна виправити). У будь-якому випадку, цілісність даних, що зберігаються на сервері, зберігається. Якщо ваш сервер зберігання даних ZFS має не-ECC RAM, тоді помилка може розповсюджуватися по всіх ваших даних і метаданих як ZFS намагається "виправити" помилки, які дійсно є лише складовими уяви комп'ютера. Як найгірший сценарій, що насправді відбувається з людьми весь ваш пул буде розбито через це, і всі ваші дані зникнуть. Рівень резервування на рівні зберігання / vdev також не допомагає. У більшості інших файлових систем (без поведінки з автоматичною корекцією) пошкоджено лише одне місце, на яке безпосередньо впливає біт, і якщо це відбудеться, метадані файлової системи можуть бути легко виправлені традиційними шашками файлової системи та відновлення інструменти. ZFS не має цього люка втечі; fsck.zfs немає. (Існує спуб спул , але це не працює, якщо басейн порушено.)

Те, що я не зміг Google, полягає в наступному: який сенс мати максимально надійні файли NAS (або резервні), коли я працюю з файлами на менш надійних комп'ютерах?

Це означає, що у вас є надійне сховище даних. Ви знаєте, що після того, як дані перейшли до вашого NAS, це безпечно від корупції. Будь-яка корупція буде або відремонтована автоматично, або ви будете поінформовані про проблему (у випадку ZFS, через помилку вводу-виводу). Дані можуть бути пошкоджені під час роботи над використанням менш надійних систем, але вам доведеться піти на відому не пошкоджену копію. Це є перевагою, навіть якщо тільки система NAS має ECC RAM, ZFS і якісний моніторинг зберігання та попередження.

Потім, за бажанням, можна додати (зокрема) оперативну пам'ять ECC до іншої системи (систем), яку дозволяє ваш бюджет, щоб підключити останню лунку.

Чи потрібно (образно) викинути свої поточні системи і замінити їх на (міні) серверне обладнання, якщо я не хочу турбуватися про трохи гнилі і т.д.? І якщо я переходжу цей маршрут, чи можу я розумно розраховувати на наявність ресурсів для будь-яких можливостей, крім запуску ZFS? Не витрачаючи тисячі доларів?

По-перше, вам не потрібні серверні апаратні засоби. Що вам потрібно, це в першу чергу ECC RAM (і процесор і контролер пам'яті / чіпсет, який підтримує ECC RAM), достатньо надійне постійне сховище, і в ідеалі це полегшує додавання та видалення дисків під час роботи системи. Це не повинно бути дуже дорогим, і, звичайно, не потрібно коштувати "тисячі доларів".

По-друге, ZFS любить оперативну пам'ять, але в основному для кешування. З більшістю робочих навантажень достатньо 8-16 Гб оперативної пам'яті, і 24-32 ГБ (легко досягається навіть з "споживчими" материнськими платами), але все ще є достатньо дорогою, навіть при покупці високоякісної торгової марки ECC. ZFS не дуже жадає від CPU; Ви можете зробити це потрібно багато процесора (як з ZoL , шляхом налаштування sha256, стиснення gzip-9 і, можливо, дедуплікації в комбінації), але вам не потрібно. Моя власна система запускає ZFS, не дуже потужна (FX-6100 процесор з розгортанням), я використовую sha256 скрізь, і навіть у суто послідовних входах / виводах диски є обмежуючим фактором: коли він пройде початковий малий випадково-читає частина скрабу, я отримую приблизно таку ж пропускну здатність на скраби, як я роблю на сировину dd з базового пристрою для зберігання даних, а CPU - для заощадження.