Сценарии потери данных ZFS


27

Я рассчитываю на создание большого пула ZFS (150 ТБ +) и хотел бы услышать, как люди сталкиваются со сценариями потери данных из-за сбоя оборудования, в частности, различие между случаями, когда теряются только некоторые данные, и всей файловой системой ( если есть даже такое различие в ZFS).

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

Что произойдет, если устройство ZIL выходит из строя? Или только один из нескольких ЗИЛов?

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

Благодарность!

Обновить:

Мы делаем это по дешевке, так как мы малый бизнес (9 человек или около того), но мы генерируем достаточное количество изображений.

Данные в основном небольшие файлы, по моим подсчетам около 500 тыс. Файлов на ТБ.

Данные важны, но не критически важны. Мы планируем использовать пул ZFS для зеркалирования массива «живых» данных объемом 48 ТБ (используется в течение 3 лет или около того) и оставшуюся часть хранилища для «архивных» данных.

Общий пул будет использоваться с использованием NFS.

Предполагается, что стойка находится на резервной генераторной линии здания, и у нас есть два ИБП APC, способных питать стойку при полной нагрузке в течение 5 минут или около того.


2
Если вы еще не знаете, что делаете, найдите консультанта и / или получите несколько курсов. Я сомневаюсь, что все детали, которые вам нужны, могут быть описаны в одном простом ответе.
Лукас Кауфман

3
Таким образом, вы все еще планируете использовать дешевые SATA 7,2? Вздох
Chopper3

@ Chopper3 На самом деле, я намеренно не сказал этого ... Я серьезно рассматриваю покупку дисков SAS емкостью 2 ТБ вместо дисков SATA 3 ТБ. Хотя я видел много людей, которые говорили, что они используют диски SATA очень хорошо ....
Циклон,

1
SATA диски для ZFS не очень хорошая смесь. Вы не найдете много людей, рекомендующих эту установку в настоящее время. В масштабе, о котором вы говорите (150 ТБ), это дорогая и ненужная ошибка. Взгляните на это, хотя .
2012 года

Ответы:


22

Правильно спроектируйте, и вы уменьшите вероятность потери данных ZFS. Вы еще не объяснили, что вы храните в бассейне. В моих приложениях он в основном обслуживает VMWare VMDK и экспортирует zvols через 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, обработке неисправных сетевых адаптеров и даже проблемах с дисками SATA и переключении на SAS (хотя вы будете рады узнать, я, скорее всего, пойду с 2 ТБ SAS вместо 3 ТБ SATA по вашей рекомендации).
Циклон,

Незаметная потеря == несколько секунд транзакционных данных или состояние, устойчивое к сбоям . А плохие сетевые карты были изолированы от одного хоста VMWare, что приводило к проблемам на уровне VM. Не базовое хранилище ZFS.
Ewwhite

design the right wayСсылка сломана в настоящее время.
Саураб Нанда

11

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

Начиная с версии 151a (не знаю, как это означает, что означает версия ZPool), эта проблема была исправлена. И я могу засвидетельствовать, что это работает.

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

Я не только не потерял данные на ZFS (после моей ужасной ошибки), но и постоянно защищает меня. Я больше не испытываю порчу данных, которая мучила меня в течение последних 20 лет на любом количестве серверов и рабочих станций, и я этим занимаюсь. Молчаливое (или просто «довольно тихое») повреждение данных убивало меня много раз, когда данные скатывались из резервной копии, но фактически становилось поврежденным на диске. Или другие сценарии, когда резервные копии создавали резервные копии поврежденных версий. Это было гораздо более серьезной проблемой, чем просто огромная потеря данных за один раз, что в любом случае почти всегда поддерживается. По этой причине я просто люблю ZFS и не могу понять, почему контрольные суммы и автоматическое лечение не были стандартными функциями в файловых системах в течение десятилетия. (Конечно, у систем действительно жизни или смерти обычно есть другие способы обеспечения целостности,

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

Я не согласен с аргументом SAS против SATA, по крайней мере, предположение, что SAS всегда предпочтительнее, чем SATA, для ZFS. Я не знаю, ссылался ли этот комментарий [s] на скорость вращения диска, предполагаемую надежность, скорость интерфейса или какой-либо другой атрибут [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

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