Я рассчитываю на создание большого пула ZFS (150 ТБ +) и хотел бы услышать, как люди сталкиваются со сценариями потери данных из-за сбоя оборудования, в частности, различие между случаями, когда теряются только некоторые данные, и всей файловой системой ( если есть даже такое различие в ZFS).
Например: предположим, что vdev потерян из-за сбоя, например, из-за потери питания корпуса внешнего диска или из-за сбоя платы контроллера. Из того, что я прочитал, пул должен перейти в сбойный режим, но если vdev возвращается, пул должен восстановиться? или не? или если vdev частично поврежден, теряется ли весь пул, некоторые файлы и т. д.?
Что произойдет, если устройство ZIL выходит из строя? Или только один из нескольких ЗИЛов?
Действительно любые и все анекдоты или гипотетические сценарии, подкрепленные глубокими техническими знаниями, приветствуются!
Благодарность!
Обновить:
Мы делаем это по дешевке, так как мы малый бизнес (9 человек или около того), но мы генерируем достаточное количество изображений.
Данные в основном небольшие файлы, по моим подсчетам около 500 тыс. Файлов на ТБ.
Данные важны, но не критически важны. Мы планируем использовать пул ZFS для зеркалирования массива «живых» данных объемом 48 ТБ (используется в течение 3 лет или около того) и оставшуюся часть хранилища для «архивных» данных.
Общий пул будет использоваться с использованием NFS.
Предполагается, что стойка находится на резервной генераторной линии здания, и у нас есть два ИБП APC, способных питать стойку при полной нагрузке в течение 5 минут или около того.
источник
Ответы:
Правильно спроектируйте, и вы уменьшите вероятность потери данных 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.
источник
design the right wayСсылка сломана в настоящее время.Я случайно переписал оба 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 абсолютно потрясающая.
источник