Сценарії втрати даних ZFS


27

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

Наприклад: скажімо, vdev втрачається через такий збій, як втрата живлення зовнішнього корпусу накопичувача або збій карти контролера. З того, що я прочитав, пул повинен перейти в несправний режим, але якщо повернути vdev, пул повинен відновитися? чи ні? або якщо vdev частково пошкоджений, чи втрачається цілий пул, деякі файли тощо?

Що станеться, якщо пристрій ZIL виходить з ладу? Або просто один із декількох ЗІЛів?

Дійсно оцінюються будь-які анекдоти чи гіпотетичні сценарії, підкріплені глибокими технічними знаннями!

Спасибі!

Оновлення:

Ми робимо це дешево, оскільки ми малий бізнес (9 людей або близько того), але ми генеруємо неабияку кількість даних для зображень.

Дані - це в основному невеликі файли, на мою кількість приблизно 500 тис. Файлів на туберкульоз.

Дані важливі, але не є критичними. Ми плануємо використовувати пул ZFS для відображення "живого" масиву даних 48TB (використовується 3 роки або більше), а решту місця зберігання використовувати для "архівованих" даних.

Пул буде надано за допомогою NFS.

Стійка нібито знаходиться на лінії резервного генератора будівлі, і у нас є два ДБЖ APC, здатні живити стійки при повному навантаженні протягом 5 хвилин або близько того.


2
Якщо ви ще не знаєте, чим займаєтесь, знайдіть консультанта та / або пройдіть деякі курси. Сумніваюсь, що всі необхідні вами конкрети можуть бути висвітлені в одній простій відповіді.
Лукас Кауффман

3
Тож ви все ще плануєте використовувати споживач cheapo 7.2 SATA? зітхання
Chopper3

@ Chopper3 Насправді я навмисно не сказав, що ... я серйозно розглядаю питання про придбання накопичувачів SAS 2 Тб замість 3 ТБ SATA. Хоча я бачив багато людей, які кажуть, що вони прекрасно використовували диски SATA ....
Циклон

1
Диски SATA для ZFS насправді не є гарною сумішшю. Ви не знайдете багатьох людей, які рекомендують цю налаштування сьогодні. У масштабі, про який ви говорите (150 ТБ), це дорога і непотрібна помилка. Погляньте на це, однак .
ewwhite

Відповіді:


22

Розробіть правильний шлях, і ви зведете до мінімуму шанси втрати даних ZFS. Ти не пояснив, що ти зберігаєш у басейні. У моїх програмах він в основному обслуговує VMWare VMDK та експортує дзвінки через iSCSI. 150 ТБ не є тривіальною сумою, тому я б сперся на професіонала за порадою щодо масштабування.

Я ніколи не втрачав даних із ZFS.

Я вже випробував все інше:

Але через все це ніколи не було помітної втрати даних. Просто простої. Для того, щоб VMWare VMDK сидів над цим сховищем, після події часто були потрібні fsck або перезавантаження, але не гірше, ніж будь-який інший збій сервера.

Що стосується втрати пристрою на ZIL, це залежить від дизайну, того, що ви зберігаєте, а також від вашого шаблону вводу / виводу та запису. Пристрої ZIL, які я використовую, порівняно невеликі (4 ГБ-8 ГБ) і функціонують як кеш запису. Деякі люди дзеркально відображають свої пристрої ZIL. Використання пристроїв високого класу STEC SSD робить дзеркальне дзеркальне завищення. Замість цього я використовую одиночні картки DDRDrive PCIe. Плануйте захист акумулятора / ДБЖ та використовуйте карти SSD або PCIe із резервним резервом над конденсатором (аналогічно реалізаціям RAID-контролерів BBWC та FBWC ).

Більшість мого досвіду перебуває на сторонах Solaris / OpenSolaris та NexentaStor . Я знаю, що люди використовують ZFS на FreeBSD, але я не впевнений, наскільки відстають версії zpool та інші функції. Для чистого розгортання пам’яті я рекомендую пройти маршрут Nexentastor (і поговорити з досвідченим партнером ), оскільки це спеціально створена ОС і є більш критичні розгортання, що працюють на похідних Solaris, ніж FreeBSD.


Я оновив своє запитання ще якоюсь інформацією, але мені особливо цікаво дізнатися більше деталей щодо: «ніколи не помітна втрата даних» та що це означає / що стосується. Також цікаво дізнатися більше про відновлення цих несправних zpools, поводження з поганими NIC та навіть проблеми з дисками SATA та переходом на SAS (хоча ви будете раді дізнатися, я, швидше за все, перейду з 2 TB SAS над 3 TB SATA , за вашою рекомендацією).
Циклон

Непримітна втрата == кілька секунд даних про трансакцію або стан, що відповідає збоям . А погані NIC були виділені до одного хоста VMWare і призвели до проблем на рівні VM. Не основне сховище ZFS.
ewwhite

Зараз design the right wayпосилання розірвано.
Саураб Нанда

11

Я випадково переробив обидва ZIL на останній версії OpenSolaris, через що весь пул був безповоротно загублений. (Дійсно погана помилка з мого боку! Я не розумів, що втратити ZIL буде означати втрату басейну. На щастя, оговтався від резервного копіювання з простоєм.)

Оскільки версія 151a хоч (не знаю напевно, як це означає, що це версія ZPool), ця проблема була виправлена. І я можу засвідчити, що це працює.

Крім цього, я втратив дані ZERO на сервері 20 Тб - в тому числі через кілька подальших випадків помилок користувача, багаторазових відмов живлення, неправильного керування дисками, неправильних конфігурацій, численних несправних дисків тощо. Інтерфейси конфігурації на Solaris часто і безумно змінюються від версії до версії і представляють собою значну незмінну цілі для навичок, вона все ще є найкращим варіантом для ZFS.

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

Слово мудрим, якщо ви не хочете спускатися в пекло ACL, не використовуйте вбудований в ZFS сервер CIFS. Використовуйте Samba. (Ви сказали, що використовуєте NFS.)

Я не погоджуюся з аргументом SAS проти SATA, принаймні, із припущенням, що SAS завжди кращий перед SATA, для ZFS. Я не знаю, чи згадували цей коментар [и] швидкість обертання блюд, припущену надійність, швидкість інтерфейсу чи інший атрибут [s]. (А може бути, просто "вони коштують дорожче і, як правило, не використовуються споживачами, тому вони є вищими". Нещодавно опубліковане опитування галузі (все ще в новинах я впевнений) показало, що SATA насправді переживає SAS в середньому, принаймні з значний обсяг вибірки опитування. (шокувало мене, це точно). Я не можу згадати, чи це були "корпоративні" версії SATA, або споживачі, чи які швидкості - але, за моїм значним досвідом, підприємства та споживчі моделі не вдається одночасно статистично значущі показники. (Існує проблема того, що споживчі накопичувачі забирають занадто багато часу, щоб вичерпати час виходу з ладу, що, безумовно, важливо на підприємстві - але це мене не покусало, і я думаю, що це більше стосується апаратних контролерів, які можуть зайняти весь обсяг офлайн в таких випадках. Але це не проблема SAS проти SATA, і ZFS ніколи не підводив мене над цим. У результаті цього досвіду я зараз використовую суміш 1/3 корпоративних та 2/3 споживчих SATA-дисків .) Крім того, я не бачив жодного значного ефекту від цієї суміші SATA при правильному налаштуванні (наприклад, смужка тристоронніх дзеркал), але знову ж таки, у мене низький попит на IOPS, тому залежно від того, наскільки великий ваш магазин і типові випадки використання, YMMV. Я, безумовно, помітив, що вбудований кеш-пам’ять на одному диску має значення більше для проблем із затримкою, ніж швидкість обертання платівки в моїх випадках використання.

Іншими словами, це конверт з декількома параметрами: вартість, пропускна здатність, IOPS, тип даних, кількість користувачів, пропускна здатність адміністратора та загальні випадки використання. Сказати, що SAS - це завжди правильне рішення - це нехтувати великим всесвітом перестановок цих факторів.

Але так чи інакше, ZFS абсолютно гойдає.


3
Дякуємо, що знайшли час для відповіді. Ваш досвід роботи з ZFS відповідає моєму. Мої коментарі щодо вибору накопичувача були спеціально щодо близьколінійної SAS проти диска SATA. Основна відмінність - інтерфейс. Вони механічно рівноцінні. Зараз найкращою практикою в ZFS-land є уникання SATA через необхідність двопортових інтерфейсів, кращого виправлення помилок та керованих тайм-аутів, пропонованих SAS.
ewwhite

У кінцевому підсумку я працюю з 3 ТБ дисками SAS, але .... перед цим я обмотав разом близько 30 мішаних дисків (5 400 ГБ SATA, 12 750 ГБ SATS, 14 1 ТБ SAS), які я вклав у той самий розширений корпус SAS. Дійсно найгірший сценарій згідно. Ці накопичувачі також мали ~ 2-3 роки часу виконання. Потім я написав програму, яка проводила 8 потоків випадковим чином, читаючи написання та видалення файлів у пул. Я займався цим більше тижня. Прочитав і написав> 100 ТБ до басейну ... жодних проблем. AVG R / W 100-400MB / сек. Я підозрюю, що SATA над попередженнями SAS зараз може бути давньою новиною.
Циклон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.