Я стремлюсь создать большой пул ZFS (150 ТБ +), и я хотел бы услышать мнение людей о сценариях потери данных из-за неисправного оборудования, в частности, о различении случаев потери только некоторых данных и всей файловой системы ( если в ZFS вообще есть такое различие).
Например: предположим, что vdev потеряно из-за сбоя, например, из-за потери питания корпуса внешнего диска или выхода из строя карты контроллера. Из того, что я прочитал, пул должен перейти в аварийный режим, но если vdev возвращается, пул должен восстановиться? или не? или если vdev частично поврежден, теряется ли весь пул, некоторые файлы и т. д.?
Что будет при выходе из строя устройства ЗИЛ? Или просто один из нескольких ЗИЛов?
Приветствуются поистине любые анекдоты или гипотетические сценарии, подкрепленные глубокими техническими знаниями!
Спасибо!
Обновить:
Мы делаем это дешево, поскольку мы малый бизнес (около 9 человек), но мы генерируем изрядное количество данных изображений.
Данные в основном представляют собой небольшие файлы, по моим подсчетам, около 500 тыс. Файлов на ТБ.
Данные важны, но не критичны. Мы планируем использовать пул ZFS для зеркалирования 48 ТБ «живого» массива данных (используется в течение 3 лет или около того), а остальную часть хранилища использовать для «архивных» данных.
Общий пул будет использоваться по NFS.
Стойка предположительно находится на линии резервного генератора здания, и у нас есть два ИБП APC, способных обеспечить питание стойки при полной нагрузке в течение 5 минут или около того.
Дизайн правильный и вы сведете к минимуму вероятность потери данных ZFS. Однако вы не объяснили, что храните в бассейне. В моих приложениях он в основном обслуживает VMWare VMDK и экспортирует zvols через iSCSI. 150 ТБ - нетривиальная сумма, поэтому я бы обратился к профессионалу за советом по масштабированию.
Я никогда не терял данные с ZFS.
я иметь все остальное испытал:
Но при всем этом заметной потери данных не было. Просто время простоя. Для VMWare VMDK, находящегося поверх этого хранилища, после события часто требовались fsck или перезагрузка, но не хуже, чем сбой любого другого сервера.
Что касается потери устройства ЗИЛ, это зависит от конструкции, того, что вы храните, а также от ваших шаблонов ввода-вывода и записи. Устройства ЗИЛ, которые я использую, относительно малы (4-8 ГБ) и работают как кэш записи. Некоторые зеркалируют свои устройства ЗИЛ. Использование высокопроизводительных твердотельных накопителей STEC делает зеркалирование недоступным. Я использую сингл DDRDrive Карты PCIe вместо этого. Планируйте защиту аккумулятора / ИБП и используйте карты SSD или PCIe с резервным суперконденсатором (аналогично RAID-контроллеру). Реализации BBWC и FBWC).
Большая часть моего опыта была на Solaris / OpenSolaris и NexentaStor сторона вещей. Я знаю, что люди используют ZFS на FreeBSD, но я не уверен, насколько сильно отстают версии zpool и другие функции. Для развертывания чистого хранилища я бы рекомендовал пойти по маршруту Nexentastor (и поговорить с опытный партнер), так как это специально созданная ОС, и на производных от Solaris выполняется более критичное развертывание, чем на FreeBSD.
Я случайно перезаписал оба ZIL в последней версии OpenSolaris, что привело к безвозвратной потере всего пула. (Действительно серьезная ошибка с моей стороны! Я не понимал, что потеря ZIL будет означать потерю пула. К счастью, восстановлен из резервной копии с простоями.)
Однако, начиная с версии 151a (не знаю, что означает версия ZPool), эта проблема была исправлена. И я могу засвидетельствовать, что это работает.
Помимо этого, я потерял НОЛЬ данных на сервере емкостью 20 ТБ, в том числе из-за нескольких дополнительных случаев ошибок пользователя, множественных сбоев питания, неправильного управления дисками, неправильной конфигурации, большого количества неисправных дисков и т. Д. Несмотря на то, что управление и Интерфейсы конфигурации в Solaris часто и безумно меняются от версии к версии и представляют собой значительную постоянно меняющуюся цель навыков, это по-прежнему лучший вариант для ZFS.
Я не только не потерял данные на ZFS (после моей ужасной ошибки), но и постоянно меня защищает. Я больше не сталкиваюсь с повреждением данных, которое преследовало меня последние 20 лет на любом количестве серверов и рабочих станций, чем я занимаюсь. Тихое (или просто «довольно тихое») повреждение данных убивало меня много раз, когда данные сбрасывались из ротации резервных копий, но фактически оказывались поврежденными на диске. Или другие сценарии, в которых резервные копии содержат резервные копии поврежденных версий. Это была гораздо более серьезная проблема, чем просто потеря данных в большом объеме за один раз, которые почти всегда копируются. По этой причине я просто люблю ZFS и не могу понять, почему контрольные суммы и автоматическое лечение не были стандартными функциями в файловых системах вот уже десять лет. (Конечно, действительно смертельные системы обычно имеют другие способы обеспечения целостности, но все же целостность корпоративных данных тоже важна!)
Слово к мудрым, если вы не хотите спускаться в ад ACL, не используйте сервер CIFS, встроенный в ZFS. Используйте Samba. (Вы сказали, что используете NFS.)
Я не согласен с аргументом SAS против SATA, по крайней мере, с предположением, что SAS всегда предпочтительнее SATA для ZFS. Я не знаю, относились ли эти комментарии к скорости вращения диска, предполагаемой надежности, скорости интерфейса или каким-либо другим атрибутам. (Или, может быть, просто «они стоят дороже и обычно не используются потребителями, поэтому они лучше». Недавно опубликованное отраслевое исследование (я уверен, что все еще в новостях), показало, что SATA в среднем переживает SAS, по крайней мере, с значительный размер выборки опроса (меня это точно шокировало). Я не могу вспомнить, были ли это «корпоративные» версии SATA, или потребительские, или какие скорости - но, исходя из моего значительного опыта, корпоративные и потребительские модели терпят неудачу одновременно. статистически значимые показатели (хотя существует проблема, связанная с тем, что потребительские диски слишком долго отключаются от сбоя, что определенно важно для предприятия, но это меня не укусило, и я думаю, что это более актуально для аппаратных контроллеров, которые может в таких случаях отключить весь том. Но это не проблема SAS и SATA, и ZFS никогда не подводила меня в этом. В результате этого опыта я теперь использую сочетание 1/3 корпоративных и 2 / 3 потребительских диска SATA.) Кроме того, я не видел значительной производительности совпадение с этим сочетанием SATA при правильной настройке (например, полоса трехсторонних зеркал), но опять же, у меня низкий спрос на IOPS, поэтому в зависимости от размера вашего магазина и типичных вариантов использования YMMV. Я определенно заметил, что размер встроенного кеша для каждого диска имеет большее значение для проблем с задержкой, чем скорость вращения пластины в моих случаях использования.
Другими словами, это конверт с множеством параметров: стоимость, пропускная способность, количество операций ввода-вывода в секунду, тип данных, количество пользователей, административная пропускная способность и распространенные варианты использования. Сказать, что SAS всегда является правильным решением, - значит не принимать во внимание множество вариаций этих факторов.
Но в любом случае ZFS просто потрясающе.